Prenez de l’avance avec la cryptographie quantique sécurisée

Bonjour, je suis Cathie de l’équipe d’ingénierie en cryptographie. Cette vidéo explique comment mettre en œuvre la cryptographie quantique sécurisée.

Vous créez des applications qui occupent une place privilégiée dans la vie des gens. Votre app peut avoir accès à des données utilisateur personnelles sensibles. Elle utilise donc la cryptographie pour les protéger.

Mais l’essor de l’informatique quantique menace la sécurité de cette cryptographie, avec des attaques quantiques qui affaiblissent ou invalident de nombreux algorithmes très utilisés. Pour devancer ce risque, vous devez passer à la cryptographie quantique. Pour commencer, je couvrirai différentes attaques quantiques visant la cryptographie, les protocoles affectés et la cryptographie quantique sécurisée comme moyen de défense. Puis, j’expliquerai comment protéger les données réseau contre ces attaques à l’aide du chiffrement quantique sécurisé dans TLS. Enfin, j’aborderai comment protéger les protocoles personnalisés avec les nouvelles API quantiques sécurisées de CryptoKit.

Commençons par les attaques quantiques visant la cryptographie.

Imaginons une app qui a accès à des données personnelles sensibles comme des dossiers médicaux, des adresses et des photos. Elle utilise la cryptographie pour protéger ces données. Par exemple, elle les charge sur un serveur pour les sauvegarder et les synchroniser entre les appareils. Ces données sont protégées avec TLS. Pour ce cas de figure et bien d’autres, la cryptographie est essentielle à la sécurité des données utilisateur.

Cependant, elle est menacée par les attaques quantiques. Cela inclut le chiffrement, qui assure la confidentialité des données, et les signatures, qui garantissent l’authenticité des données. Les experts s’accordent à dire que certaines attaques quantiques sont déjà justifiées même s’il n’existe pas encore d’ordinateurs quantiques suffisamment puissants pour les exploiter.

Par exemple, un attaquant peut d’ores et déjà récolter des données chiffrées pour les déchiffrer plus tard. Voici comment l’attaque pourrait fonctionner.

Reprenons l’exemple d’app qui doit envoyer au serveur des données utilisateur sensibles telles que des dossiers médicaux, des adresses et des photos. Elle chiffre ces données avec TLS et les envoie. Un attaquant observant le réseau peut récolter ces données chiffrées et les stocker. Il ne peut pas encore les déchiffrer, mais il peut attendre d’avoir accès à terme à un ordinateur quantique suffisamment puissant pour les déchiffrer et accéder aux données utilisateur sensibles.

Ce type d’attaque affecte les données chiffrées auxquelles un attaquant peut accéder, en particulier les données en transit. Elle affecte les apps qui envoient des données à un serveur, les synchronisent entre divers appareils ou les envoient sur le réseau. Cela viole la confidentialité, car l’attaquant peut lire le trafic réseau après le déchiffrement. Les attaquants peuvent d’ores et déjà récolter les données sur le réseau. Nous devons donc nous préparer dès maintenant à atténuer ce type d’attaque. La collecte immédiate de données pour un déchiffrement ultérieur est une attaque passive. Voyons maintenant un exemple d’attaque active, où l’attaquant avec un ordinateur quantique est activement impliqué dans le protocole.

Imaginez une app dont la clé de signature est liée à l’utilisateur. Cette clé permet d’authentifier l’utilisateur auprès du serveur à l’aide d’une signature.

Un attaquant observant le trafic réseau intercepte cette signature. À l’aide d’un ordinateur quantique suffisamment puissant, il invalide la cryptographie et vole la clé de signature. Il utilise la clé volée pour créer une signature, qu’il envoie au serveur pour usurper l’identité de l’utilisateur. Le serveur accepte la signature de l’attaquant comme si elle provenait de l’utilisateur. L’attaquant effectue ensuite des actions au nom de cet utilisateur.

Cette attaque active affecte les signatures. Elle compromet l’authenticité, car l’attaquant peut falsifier l’authentification et agir au nom de la victime. Elle affecte les apps qui authentifient les utilisateurs, notamment avec WebAuth et l’authentification multifacteur, ou qui authentifient des données, notamment avec la signature des ressources. La menace est future, car il n’existe pas encore d’ordinateurs quantiques suffisamment puissants pour exploiter cette attaque. Mais ces ordinateurs se profilent à l’horizon.

Les attaques quantiques sont une réelle menace à la sécurité de la cryptographie. Pour les devancer, la communauté de la cryptographie s’est concentrée sur la création et la normalisation de nouveaux algorithmes sécurisés, connus sous le nom de cryptographie quantique. Ces algorithmes sont prêts à être adoptés dès aujourd’hui. Ils fonctionnent sur les ordinateurs non quantiques d’aujourd’hui, mais resteront à l’abri des attaques exécutées par les ordinateurs standard ou quantiques. Je vais entrer dans les détails, mais gardez à l’esprit que même si la cryptographie est complexe, les correctifs sont simples.

La cryptographie se divise en cryptographie à clé publique et cryptographie à clé symétrique.

Ces catégories sont affectées différemment par les attaques quantiques. Les stratégies d’atténuation ne sont donc pas les mêmes. Commençons par la cryptographie à clé publique, qui inclut le chiffrement à clé publique et les signatures. La cryptographie à clé publique repose sur des problèmes mathématiques comme RSA et le logarithme discret sur courbe elliptique, qui nécessitent trop de calcul pour être résolus par les ordinateurs standard.

Cependant, les ordinateurs quantiques seront capables de résoudre ces problèmes bien plus rapidement en invalidant ces algorithmes. Ils doivent donc être remplacés par des algorithmes quantiques sécurisés dont la difficulté de calcul ne pourra être résolue par aucun ordinateur, standard ou quantique.

Le chiffrement quantique sécurisé implique le chiffrement à clé publique hybride post-quantique, ou chiffrement HPKE post-quantique.

La signature quantique sécurisée implique des signatures hybrides post-quantiques. Ces deux structures hybrides post-quantiques combinent de nouveaux algorithmes post-quantiques avec des algorithmes classiques actuels. L’invalidation d’une structure hybride nécessite l’invalidation de l’algorithme post-quantique et l’algorithme classique. Les structures hybrides offrent donc les meilleures garanties de sécurité et sont recommandées par Apple pour la cryptographie quantique sécurisée. La cryptographie à clé symétrique inclut le chiffrement à clé symétrique et les codes d’authentification des messages. Ces algorithmes se basent également sur des problèmes mathématiques difficiles pour les ordinateurs standard. Mais ces problèmes sont traités par les ordinateurs quantiques très différemment des algorithmes standard à clé publique. Les ordinateurs quantiques ne peuvent obtenir qu’une réduction faible et constante de la sécurité de ces problèmes. Ils ne font qu’affaiblir la cryptographie à clé symétrique. Les algorithmes à clé symétrique sécurisés de manière standard peuvent donc être sécurisés quantiquement en doublant la taille de leur clé.

Remplacez le chiffrement avec des clés de 128 bits par des clés de 256 bits. Par exemple, passez d’AES-128 à AES-256. Pour revenir aux attaques quantiques dont j’ai parlé, la priorité avec la cryptographie quantique sécurisée est de se défendre contre la collecte immédiate de données pour un déchiffrement ultérieur. En effet, les données en transit chiffrées que les protocoles envoient pourraient déjà être récoltées à cet effet. Pour vous défendre, adoptez le chiffrement quantique sécurisé des données en transit. Ceci est essentiel si votre protocole gère des données utilisateur sensibles.

La protection contre ce type d’attaque est si importante qu’Apple l’a déjà faite pour iMessage.

iMessage protège les conversations utilisateur sensibles envoyées sur le réseau. Pour devancer les attaques quantiques, dans iOS 17.4, Apple a lancé iMessage PQ3, qui est à la pointe de la messagerie quantique sécurisée à grande échelle. Le protocole cryptographique iMessage a été entièrement remanié pour assurer un chiffrement sécurisé quantique hybride de toutes les clés lors des conversations. Lisez le blog d’Apple sur la sécurité pour en savoir plus sur la motivation et le design d’iMessage PQ3. Bien qu’iMessage PQ3 révolutionne la messagerie quantique sécurisée à grande échelle, la protection des données réseau va bien au-delà. La plupart des données réseau, y compris tout le trafic HTTPS, sont protégées par TLS. Voyons comment défendre ces données contre les attaques quantiques en passant au protocole TLS quantique sécurisé.

TLS 1.3 inclut une mise à niveau du chiffrement quantique sécurisé évitant que les données réseau ne soient collectées pour être déchiffrées ultérieurement. Cette mise à niveau utilise un échange de clés quantique sécurisé, qui résulte des efforts de normalisation du National Institute of Standards and Technology et de l’Internet Engineering Task Force. Le chiffrement quantique sécurisé dans TLS a déjà été adopté par les principaux fournisseurs de services. Vous pouvez d’ores et déjà l’activer et l’utiliser.

À partir d’iOS 26, le chiffrement quantique sécurisé dans TLS est activé par défaut sur les systèmes d’exploitation Apple, pour les API réseau recommandées, URLSession et Network.framework. Comme avec le protocole TLS standard, la communication entre le client et le serveur de terminaison TLS est protégée.

Abandonnez les API de mise en réseau héritées, telles que Secure Transport, car elles ne prendront pas en charge le TLS quantique. Les piles réseau personnalisées peuvent être plus difficiles à mettre à niveau. C’est une excellente occasion de passer à URLSession ou de sauvegarder votre pile réseau avec Network.framework.

Pour que le chiffrement quantique sécurisé dans TLS fonctionne entre les appareils et vos serveurs, vous devez aussi l’activer côté serveur. La majorité des développeurs utilisent un fournisseur d’hébergement de contenu ou de site web. La plupart prennent déjà en charge le chiffrement quantique sécurisé dans TLS. Il peut être activé par défaut, ou vous pouvez facilement l’activer avec une modification de configuration. Lors du déploiement de vos propres serveurs, vous devez mettre à niveau explicitement vos bibliothèques et votre configuration TLS. Pour en savoir plus, lisez la documentation sur la préparation du réseau au chiffrement quantique sécurisé dans TLS.

Il se peut que vous utilisiez des services système, qui chiffrent les données entre les appareils et les serveurs Apple. Apple montre l’exemple. Dans iOS 26, le chiffrement quantique sécurisé dans TLS sera activé côté client et déployé côté serveur dans ces services système. CloudKit stocke les données de votre app dans iCloud et les synchronise sur tous vos appareils et sur le Web.

Avec les notifications push Apple, votre app fournit aux utilisateurs un contenu pertinent et opportun.

Le relais privé iCloud protège le DNS et tout trafic HTTP non chiffré dans l’app. Ces services système permettent tous un chiffrement quantique sécurisé dans TLS.

Les apps Apple intégrées gérant des données utilisateur sensibles, comme Safari, Météo et Maps, s’apprêtent aussi à prendre en charge le chiffrement quantique sécurisé dans TLS. C’est maintenant au tour de votre app.

Pour la plupart des développeurs, l’utilisation du chiffrement quantique sécurisé dans TLS suffit à éviter la collecte immédiate de données pour un déchiffrement ultérieur. Cependant, TLS n’est pas le seul moyen de protéger les données en transit. Vous avez peut-être des protocoles de chiffrement personnalisés, où vous utilisez directement des API de chiffrement pour protéger les données. Si c’est le cas, optez pour des API de cryptographie quantique sécurisée à la place.

Pour ce faire, faites le point sur votre utilisation actuelle de la cryptographie. Identifiez les endroits où vos protocoles utilisent la cryptographie avec impact quantique, comme les données chiffrées en transit et les signatures. Planifiez la mise à jour de ces protocoles pour qu’ils utilisent la cryptographie quantique sécurisée à la place. Puis, utilisez CryptoKit pour mettre en œuvre ces mises à jour, grâce aux nouvelles API quantiques sécurisées.

CryptoKit est un framework Swift disponible sur toutes les plates-formes Apple, avec des API pour les algorithmes de cryptographie. Dans iOS 26, CryptoKit inclut de nouvelles API quantiques sécurisées qui sont performantes, faciles à utiliser et sécurisées. Elles offrent une protection supplémentaire contre les attaques par timing et par canal auxiliaire en appliquant une exécution matériellement isolée avec Secure Enclave. Elles offrent également des garanties d’exactitude, car les implémentations de base sont formellement vérifiées. Elles sont ainsi fonctionnellement équivalentes aux spécifications standardisées.

Prenons un exemple illustrant le fonctionnement des nouvelles API de CryptoKit : l’app Escalade dont les données en transit sont protégées avec un protocole de cryptographie personnalisé.

Imaginons que vous créiez une app qui a accès aux données de santé d’un utilisateur, à ses itinéraires et à des photos prises lors d’une sortie d’escalade. Vous souhaitez fournir le chiffrement complet de ces données aux autres appareils de l’utilisateur. Il s’agit d’informations sensibles, auxquelles le serveur et les attaquants ne doivent pas avoir accès. Pour ce faire, créez un protocole personnalisé qui chiffre les données vers les autres appareils de l’utilisateur et relaie les données chiffrées via le serveur.

Le protocole TLS quantique sécurisé ne suffit pas ici, car TLS protège la communication entre le client et le serveur de terminaison TLS. Dans cet exemple, vous ne voulez pas révéler les données utilisateur au serveur.

Toute app chiffrant les données en transit, comme l’app Escalade, doit utiliser le chiffrement quantique sécurisé pour éviter la collecte immédiate de données pour un déchiffrement ultérieur.

À partir d’iOS 26, CryptoKit prend en charge une API de chiffrement quantique sécurisé basée sur le chiffrement à clé publique hybride post-quantique. Ce chiffrement est idéal pour votre app Escalade. Il protégera vos données utilisateur sensibles contre les attaques quantiques. Voyons un exemple de code pour montrer comment utiliser cette nouvelle API.

L’expéditeur et le destinataire définissent la suite de chiffrement HPKE post-quantique à partir de X-Wing. J’expliquerai X-Wing plus en détail après la démo de l’exemple de code. Du côté du destinataire, vous créez une paire de clés X-Wing. Si votre app utilise le chiffrement HPKE standard avec CryptoKit, passer au chiffrement HPKE post-quantique revient à modifier la suite de chiffrement et le type de clé. Les sections spécifiques à l’API HPKE quantique sécurisée sont ces premières lignes.

Le destinataire partage sa clé publique.

Vous créez ensuite l’expéditeur avec la clé publique du destinataire et créez le destinataire avec la clé encapsulée de l’expéditeur.

L’expéditeur crée un texte chiffré en chiffrant les données utilisateur sensibles, telles que les données de santé, les itinéraires ou les photos, ainsi que les métadonnées authentifiées. Il l’envoie au destinataire.

Le destinataire déchiffre le texte chiffré en l’ouvrant avec les mêmes métadonnées authentifiées.

Désormais, les données utilisateur de la sortie d’escalade sont passées de l’appareil de l’expéditeur à celui du destinataire avec un chiffrement quantique sécurisé complet.

Comme nous l’avons vu, le chiffrement quantique sécurisé nécessite le chiffrement HPKE post-quantique. Cela établit la clé partagée HPKE à l’aide du mécanisme d’encapsulation de clé, ou KEM, de X-Wing.

Le chiffrement HPKE post-quantique et X-Wing sont des structures hybrides post-quantiques : ils combinent des algorithmes post-quantiques et standard pour optimiser la sécurité.

ML-KEM est le composant post-quantique du mécanisme KEM de X-Wing et d’autres mécanismes KEM post-quantiques. ML-KEM a une surcharge de chiffrement plus élevée que ses homologues standard. Mais ses performances sont comparables ou supérieures à celles de ses homologues standard. CryptoKit utilise une implémentation formellement vérifiée de ML-KEM, qui s’est révélée fonctionnellement équivalente à la spécification normalisée FIPS 203. Il prend également en charge Secure Enclave. Vous pouvez donc appliquer une exécution matériellement isolée pour les opérations ML-KEM.

Nous avons vu comment chiffrer les données à l’aide de chiffrement HPKE post-quantique, une API de haut niveau disponible dans CryptoKit. Pour implémenter vos propres protocoles cryptographiques, par exemple pour prendre en charge une spécification de protocole, CryptoKit offre des API quantiques sécurisées de bas niveau.

Le chiffrement HPKE post-quantique utilise X-Wing pour l’encapsulation des clés, qui utilise ML-KEM comme composant post-quantique. CryptoKit prend désormais tout cela en charge en tant qu’API de chiffrement. De même, les signatures quantiques sécurisées utilisent ML-DSA comme composant post-quantique. CryptoKit prend aussi en charge ML-DSA en tant qu’API de signature. Comme ML-KEM, l’implémentation de ML-DSA prend en charge Secure Enclave.

L’API ML-DSA permet de créer des signatures hybrides post-quantiques au niveau du code de l’application.

Les API CryptoKit s’exécutent côté client, sur l’appareil. Certains protocoles nécessitent une interopérabilité cryptographique entre le client et le serveur. L’un des moyens les plus simples pour ce faire est d’utiliser Swift Crypto sur le serveur. Swift Crypto est une bibliothèque Swift qui offre la compatibilité des API avec CryptoKit pour les serveurs pour un développement transparent. Cela inclut la compatibilité serveur pour toutes les API quantiques sécurisées prises en charge par CryptoKit dans iOS 26. Comme ces API quantiques sécurisées sont des implémentations de protocoles standardisés, vous pouvez utiliser n’importe quelle bibliothèque compatible avec les normes côté serveur. Avec ces nouvelles API quantiques sécurisées dans CryptoKit et Swift Crypto, vous avez les outils nécessaires pour protéger votre app des attaques quantiques grâce à la cryptographie quantique sécurisée. Consultez l’exemple de code dans les ressources vidéo pour obtenir d’autres exemples d’utilisation de ces nouvelles API.

Vous savez maintenant comment protéger les données de votre app contre les attaques quantiques. D’abord, vérifiez que vos données réseau sont protégées par le chiffrement quantique sécurisé dans TLS. Cela est facile, surtout si vous utilisez les API de mise en réseau recommandées, qui l’activent par défaut.

Mettez à jour la configuration du serveur pour activer ce chiffrement côté serveur.

Pour les protocoles de chiffrement personnalisés, utilisez les nouvelles API quantiques sécurisées de CryptoKit. Utilisez le chiffrement HPKE post-quantique pour chiffrer les données, comme dans l’exemple de l’app Escalade.

Les attaques quantiques ne sont pas une possibilité lointaine. Elles sont déjà pertinentes, et pour les devancer, nous devons adopter la cryptographie quantique. Sautez le pas !