Se défendre contre les menaces futures : Cloudflare passe au post-quantique

Les jours sont comptés pour le chiffrement que nous utilisons au quotidien. Ce n'est pas facile à prédire, mais quelque part d'ici 15 ou 40 ans, on devrait pouvoir fabriquer un ordinateur quantique suffisamment puissant pour être en mesure de déchiffrer pratiquement n'importe quelle donnée chiffrée dans l'Internet d'aujourd'hui.

Heureusement, il existe une solution : le chiffrement post-quantique (PQ) a été conçu d'une manière qui le sécurise contre la menace des ordinateurs quantiques. Il y a à peine trois mois, en juillet 2022, après une compétition mondiale qui aura duré six ans, le National Institute of Standards and Technology (NIST) aux États-Unis, connu pour l'AES et le SHA2, a annoncé le chiffrement post-quantique qu'il allait normaliser. Le NIST prévoit de publier les normes finales en 2024, mais nous souhaitons favoriser une adoption précoce du chiffrement post-quantique.

À compter d'aujourd'hui, et à titre de service en phase bêta l'ensemble des sites web et API servis par Cloudflare prennent en charge l'accord de clé hybride post-quantique. C'est actif par défaut¹ ; inutile de souscrire à quoi que ce soit. Cela signifie que si votre navigateur/application le prend en charge, la connexion à votre réseau est également sécurisée contre n'importe quel ordinateur quantique de l'avenir.

Nous proposons gratuitement ce chiffrement post-quantique : nous estimons que cette sécurité post-quantique doit devenir la nouvelle référence pour Internet.

Compte tenu de l'arrivée des ordinateurs quantiques se profilant à l'horizon, le déploiement du chiffrement quantique semble s'imposer comme une évidence, mais ce n'est pas sans risque. Pour commencer, il s'agit d'un chiffrement nouveau : même avec des années de surveillance étroite, il n'est pas impossible qu'une attaque catastrophique soit révélée un jour. C'est pourquoi nous déployons des systèmes hybrides : la combinaison d'un accord de clé testé et éprouvé avec un autre accord, d'un genre nouveau, qui ajoute la sécurité post-quantique.

Nous sommes avant tout inquiets de ce qui semple être un simple problème de faisabilité. Même si les protocoles utilisés pour sécuriser Internet sont conçus pour permettre des transitions en douceur comme celle-ci, de nombreux codes sont truffés de bugs ; toute tentative d'établir une connexion sécurisée post-quantique peut échouer pour de nombreuses raisons - par exemple, un dispositif peut ne pas comprendre les plus grandes clés post-quantiques et pour d'autres raisons encore inconnues parce que ces accords de clés post-quantiques sont tout nouveaux. Ces difficultés sont la raison pour laquelle il nous semble important de déployer rapidement la cryptographie post-quantique, afin que nous puissions, avec les navigateurs et autres clients, découvrir ces problèmes et y remédier.

Dans cet article de blog, nous allons expliquer comment TLS, le protocole utilisé pour sécuriser Internet, est conçu pour permettre une migration sécurisée et en douceur de la cryptographie utilisée. Ensuite, nous évoquerons les détails techniques de la cryptographie post-quantique que nous avons déployée et préciserons comment il est possible que dans la pratique, cela ne se fasse pas du tout en douceur. Nous terminerons cet article en expliquant comment vous pouvez créer un internet sécurisé post-quantique en nous aidant à tester cette nouvelle génération de cryptographie.

Lorsque vous parcourez un site web avec une connexion sécurisée, que ce soit à l'aide du protocole HTTP/1.1 ou du protocole QUIC, vous utilisez le protocole Transport Layer Security (TLS) sous le capot. Il existe deux versions majeures de TLS utilisées couramment aujourd'hui : le nouveau protocole TLS 1.3 (~90 %) et l'ancien TLS 1.2 (~10 %), qui est sur le déclin.

TLS 1.3 représente une amélioration considérable par rapport à TLS 1.2 : il est plus rapide, plus sécurisé, plus simple et plus flexible, exactement où il faut. Par conséquent, il est plus facile d'ajouter la sécurité post-quantique à la version TLS 1.3 qu'à la 1.2. Pour le moment nous en resterons là : nous n'avons ajouté la prise en charge post-quantique qu'à la version TLS 1.3.

À quoi sert donc le protocole TLS ? L'objectif est d'établir une connexion entre un navigateur et un site Web qui se caractérise ainsi

• Confidentialité et intégrité, personne ne peut lire ni modifier des données non détectées.

• Authenticité, vous savez que vous êtes connecté au bon site Web, pas à un imposteur.

Pour atteindre cet objectif, TLS utilise trois différents types de cryptographie.

• Le Chiffrement symétrique, ou plus précisément le chiffrement authentifié avec données associées (AEAD pour Authenticated Encryption With Associated Data), est l'outil polyvalent de la cryptographie : il est utilisé pour garantir la confidentialité et l'intégrité. Il s'agit d'un type de chiffrement simple : il compte une clé unique qui est utilisée pour chiffrer et déchiffrer les données. En l'absence de la bonne clé, vous ne pouvez pas déchiffrer les données, et toute tentative de modification de données chiffrée se traduit par une erreur au déchiffrement.

Dans TLS 1.3, ChaCha20-Poly1305 et AES128-GCM sont couramment utilisées actuellement.Qu'en est-il des attaques quantiques ? À première vue, il semble qu'on ait besoin de passer à des clés symétriques de 256 bits pour assurer une défense contre l'algorithme de Grover. Dans la pratique, toutefois, l'algorithme de Grover n'établit pas bien le parallèle, ainsi, les AEAD actuellement déployés feront l'affaire.

Donc, si on arrive à se mettre d'accord sur une clé partagée à utiliser avec le chiffrement symétrique, on est gagnant. Mais comment obtient-on une clé partagée ? Vous pouvez vous contenter de prendre une clé et de l'envoyer au serveur : n'importe quià l'écoute connaîtra également la clé. D'aucuns penseront qu'il s'agit là d'une tâche impossible, mais c'est là que se révèle toute la magie de la cryptographie asymétrique :

• Un accord de clé, également appelé échange de clé ou distribution de clé, est un protocole cryptographique dans lequel les deux parties peuvent se mettre d'accord sur une clé partagée sans risque d'interception ni de divulgation de données. Aujourd'hui, le protocole X25519 Elliptic Curve Diffie–Hellman (ECDH) est de facto l'accord de clé standard utilisé dans TLS 1.3. La sécurité de X25519 repose sur le problème du logarithme discret pour courbes elliptiques, qui est vulnérable aux attaques quantiques, car il est facile à résoudre par un ordinateur quantique cryptographiquement conforme utilisant l'algorithme de Shor. La solution est d'utiliser un accord de clé post-quantique, tel que Kyber.

Un accord de clé ne protège que contre un attaquant passif. Un attaquant actif qui peut intercepter et modifier les messages (MitM) est en mesure d'établir des clés séparées, partagées à la fois avec le serveur et le navigateur, en procédant à un nouveau chiffrement de toutes les données transmises. Pour résoudre ce problème, nous avons besoin de la pièce finale de cryptographie.

• Avec un algorithme de signature numérique, tel que RSA ou ECDSA, il existe deux clés : une clé publique et une clé privée. Il n'est possible de créer une signature pour un message qu'avec la clé privée. N'importe qui disposant de la clé publique correspondante peut vérifier que la signature est valide pour un message donné. Ces signatures numériques sont au cœur des certificats TLS qui sont utilisés pour authentifier les sites Web. RSA et ECDSA sont tous les deux vulnérables aux attaques quantiques. Nous ne les avons pas remplacés par des signatures post-quantiques, pas encore. En effet, cette authentification est moins urgente : nous aurons besoin qu'ils soient remplacés uniquement lorsqu'un ordinateur quantique suffisamment grand aura été fabriqué. En revanche n'importe quelle donnée sécurisée par un accord de clé vulnérable aujourd'hui peut-être stocké et déchiffré ultérieurement. Cela étant, même si nous sommes moins pressés par le temps en ce qui concerne l'authentification post-quantique, son déploiement sera très difficile.

Comment obtient-on le protocole TLS à partir de ces éléments constitutifs ?

Présentation générale de TLS 1.3

Une connexion TLS commence par une négociation qui authentifie le serveur et dérive une clé partagée. Le navigateur (client) commence par envoyer un message ClientHello qui contient une liste des AEAD, des algorithmes de signature, et les méthodes de gestion de clé prises en charge. Pour éviter un aller-retour, le client est autorisé à deviner ce que le serveur prend en charge et à commencer l'accord de clé en envoyant un ou plusieurs partages de clé client. Le client aura peut-être bien deviné (à gauche sur le diagramme ci-dessous), sinon il devra recommencer (à droite).

Flux du protocole TLS 1.3 d'authentification de serveur avec partage de clé client pris en charge à gauche et un message HelloRetryRequest à droite. 

Accord de clé

Avant d'expliquer le reste de cette interaction, examinons l'accord de clé : qu'est-ce qu'un partage de clé ? le fonctionnement de l'accord de clé est différent pour Kyber et pour X25519 : le premier correspond à un mécanisme d'encapsulation de clé (KEM), tandis que le deuxième est un accord de style DH (Diffie-Hellman). Le dernier est plus souple, mais pour TLS cela ne fait aucune différence.

La forme d'un accord de clé KEM et Diffie–Hellman dans TLS est la même. 

Dans les deux cas, le client envoie un partage de clé client au serveur. À partir de celui-ci le serveur génère la clé partagée ss. Le serveur renvoie alors le partage de clé serveur avec lequel le client peut également calculer la clé partagée.

Retour au flux TLS 1.3 : lorsque le serveur reçoit le message ClientHello, il prend un AEAD (chiffre), un algorithme de signature et un partage de clé client qu'il prend en charge. Il répond avec un message ServerHello qui contient l'AEAD choisi et le partage de clé serveur pour l'accord de clé sélectionné. Avec l'AEAD et la clé partagée verrouillée, le serveur commence à chiffrer les données (en vert dans le diagramme.)

Authentification

Avec l'AEAD et le partage de clé serveur, le serveur envoie une signature, la signature de négociations, sur la transcription de communication jusqu'à présent accompagnée d'un certificat (chaîne) pour la clé publique qui est utilisée pour créer la signature. Cela permet au client d'authentifier le serveur : il vérifie s'il peut faire confiance à l'autorité de certification (par exemple Let's Encrypt) qui a certifié la clé publique et si la signature est vérifiée pour les messages qu'il a envoyés et reçus jusqu'à présent. Cela permet non seulement d'authentifier le serveur, mais également de protéger contre les attaques de déclassement.

Protection contre les déclassements

Il nous est impossible de mettre à niveau tous les clients et serveurs vers la cryptographie post-quantique en même temps. Il y aura donc une période de transition au cours de laquelle seuls quelques clients et quelques serveurs prendront en charge la cryptographie post-quantique. La négociation d'accord de clé dans TLS 1.3 autorise la chose suivante : pendant la transition, les serveurs et les clients continueront de prendre en charge les accords de clé non post-quantique, et pourront y revenir au besoin.

Cette souplesse est appréciable mais elle fait également peur : si le client et le serveur prennent tous les deux en charge l'accord de clé post-quantique, nous devons donc être sûrs qu'ils négocient également l'accord de clé post-quantique. C'est le cas dans le protocole TLS 1.3, mais ce n'est pas évident : les partages de clé, le partage de clé choisi, et la liste des accords de clé pris en charge sont tous envoyés en texte brut. N'est-il pas possible pour un attaquant qui se trouve au milieu de retirer les accords de clé post-quantiques ? C'est ce qu'on appelle une attaque de déclassement.

C'est là qu'intervient la transcription : la signature de négociation s'applique à tous les messages reçus et envoyés par le serveur jusqu'à présent. Cela comprend les accords de clé pris en charge et l'accord de clé qui a été choisi. Si un attaquant modifie la liste des accords de clé pris en charge que le client envoie, le serveur le remarquera. Toutefois, le client vérifie la signature de négociation du serveur par rapport à la liste des accords de clé pris en charge qu'il a réellement envoyée et détecte l'éventuelle fraude.

Les problèmes d'attaque de déclassement sont beaucoup plus compliqués pour TLS 1.2, c'est l'une des raisons pour lesquelles nous hésitons à intégrer rétroactivement la sécurité post-quantique dans TLS 1.2.

Conclusion de la négociation

La dernière partie de la réponse du serveur est “server finished”, un code d'authentification de message (MAC) sur l'ensemble de la transcription jusqu'à présent. Le plus gros du travail a été effectué par la signature de négociation, mais dans les autres modes opératoires de TLS sans signature de négociations, tels que la reprise de session, c'est important.

Avec l'AEAD choisi et le partage de clé serveur, le client peut calculer la clé partagée et déchiffrer et vérifier la chaîne de certificat, la signature de négociation et le code MAC de négociation. Nous ne l'avons pas encore précisé, mais la clé partagée n'est pas utilisée directement pour le chiffrement. Au lieu de cela, elle est mélangée aux transcriptions de communication, afin que soient dérivées plusieurs clés spécifiques qui peuvent être utilisées pendant la négociation puis la connexion principale.

Pour conclure la négociation, le client envoie son propre code de négociation, puis il peut continuer à envoyer des données spécifiques à l'application chiffrées avec les clés dérivées au cours de la négociation.

Hello! Retry Request?

Ce que nous venons d'illustrer correspond au flux souhaité lorsqu'un client envoie une négociation prise en charge par le serveur. Ce n'est pas toujours le cas. Si le serveur n'accepte aucun des accords de clé qui lui sont présentés par le client, ce dernier en sera averti et la connexion interrompue.

S'il existe un accord de clé pris en charge par les deux, mais pour lequel le client n'a pas envoyé de partage de clé, le serveur répond par un message HelloRetryRequest (HRR) en demandant un partage de clé d'un accord de clé spécifique pris en charge par le client comme l'indique le diagramme sur la droite. À son tour, le client répond avec un nouveau ClientHello avec le partage de clé sélectionné.

L'histoire de ne s'arrête pas là : un serveur est également autorisé à envoyer un message HelloRetryRequest pour demander un autre accord de clé qu'il préfère à celui pour lequel le client a envoyé des partages. Par exemple, un serveur peut envoyer un message HelloRetryRequest à un accord de clé post-quantique si le client le prend en charge mais n'a pas envoyé de partage de clé pour celui-ci.

Les messages HelloRetryRequest sont rares actuellement. Presque tous les serveurs prennent en charge l'accord de clé X25519 et la plupart des clients (98 % à ce jour) envoient un partage de clé X25519. Auparavant, P-256 était la norme de facto et pendant longtemps de nombreux navigateurs envoyaient les deux partages de clé P-256 et X25519 pour éviter un message HelloRetryRequest. Nous allons en discuter plus tard, nous n'aurons peut-être pas les moyens d'envoyer deux partages de clé post-quantiques.

C'est la théorie

Le protocole TLS 1.3 est conçu pour offrir de la souplesse dans la cryptographie qu'il utilise, sans sacrifier la sécurité ou les performances, cela simplifie notre migration vers la cryptographie post-quantique. En théorie, c'est parfait, mais en pratique, cela pose de graves problèmes que nous allons détailler plus tard. Commençons par examiner les accords de clé que nous avons déployés.

S'il existe un accord de clé pris en charge par les deux, mais pour lequel le client n'a pas envoyé de partage de clé, le serveur répond par un message HelloRetryRequest (HRR) en demandant un partage de clé d'un accord de clé spécifique pris en charge par le client comme l'indique le diagramme sur la droite. À son tour, le client répond avec un nouveau ClientHello avec le partage de clé sélectionné.

Aujourd'hui, nous avons mis en place la prise en charge des accords de clé X25519Kyber512Draft00 et X25519Kyber768Draft00 à l'aide des identifiants TLS 0xfe30 et 0xfe31 respectivement. Ce sont exactement les mêmes accords que ceux que nous avons activés sur un nombre limité de zones en juillet de cette année.

Ces deux accords de clé sont une combinaison, un hybride, de l'accord classique X25519 et des nouveaux accords post-quantiques Kyber512 et Kyber768 respectivement et dans cet ordre. Cela signifie que même si Kyber s'avère non sécurisé, la connexion reste aussi sécurisée qu'avec X25519.

Kyber, pour l'instant, est le seul accord de clé que le NIST a retenu pour une normalisation. Kyber pèse très peu sur le temps processeur : il est plus rapide que le X25519 déjà connu pour sa rapidité. D'un autre côté, ses partages de clé sont plus volumineux :

		Taille des partages de clé (en octets)		Ops/sec (plus il y en a, mieux c'est)
Algorithme	PQ	Client	Serveur	Client	Serveur
Kyber512	✅	800	768	50 000	100 000
Kyber768	✅	1 184	1 088	31 000	70 000
X25519	❌	32	32	17 000	17 000

Comparaison de taille et performances en temps processeur entre X25519 et Kyber. Les performances varient considérablement selon la plateforme matérielle et les contraintes de mise en œuvre et ne sont données qu'à titre d'indication approximative.

Kyber devrait subir des modifications mineures, mais de manières incompatibles avec les précédentes versions avant la normalisation finale par le NIST en 2024. Par ailleurs, l'intégration avec le protocole TLS, notamment le choix et les détails de l'accord de clé hybride, n'est pas encore finalisée par le groupe de travail TLS. Une fois qu'elle le sera, nous ne tarderons pas à l'adopter.

C'est la raison pour laquelle nous ne prendrons pas en charge sur le long terme les accords de clé préliminaire annoncés aujourd'hui ; ils sont proposés à titre de service en phase bêta. Nous publierons des mises à jour sur notre déploiement sur pq.cloudflareresearch.com et l'annoncerons dans le cadre de la liste de diffusion sur la cryptographie post-quantique de l'IETF.

Maintenant que nous savons comment fonctionne la négociation TLS en théorie et que nous connaissons les accords de clé ajoutés, imaginons ce qui pourrait conduire à un échec.

Les protocoles sont souvent conçus dans une optique de flexibilité, mais si celle-ci n'est pas mise en pratique, elle est souvent perdue. C'est ce qu'on appelle l'ossification du protocole. Le déploiement de TLS 1.3 a été difficile en raison de plusieurs instances d'ossification. Citons l'exemple marquant qu'a été la négociation de la version de TLS : un champ de version indique dans le message ClientHello la dernière version prise en charge par le client. Une nouvelle version a été affectée à la version TLS 1.3, mais au cours des tests, il s'est avéré que de nombreux serveurs ne parvenaient pas à se replier correctement vers la TLS 1.2, ce qui se traduisait par une perte de la connexion. Comment remédier à l'ossification ?

Solution de contournement

Aujourd'hui, TLS 1.3 se fait passer pour la version TLS 1.2 jusqu'à intégrer de nombreux champs anciens dans le message ClientHello. La véritable négociation de la version est déplacée dans une nouvelle extension au message. Un serveur TLS 1.2 ignorera la nouvelle extension et poursuivra dans l'ignorance avec TLS 1.2, un serveur TLS 1.3 quant à lui récupèrera l'extension et poursuivra correctement avec la version TLS 1.3.

Lubrifier le protocole

Comment prévenir l'ossification ? Forts de cette expérience, les navigateurs afficheront régulièrement des versions factices dans ce nouveau champ de version, ainsi les serveurs dont le comportement n'est pas celui attendu seront repérés plus rapidement. Il en est ainsi pas uniquement pour le champ de la nouvelle version mais dans de nombreux autres au sein de la négociation TLS, et par anticipation pour les identifiants d'accord de clé. Actuellement, 40 % des navigateurs envoient deux partages de clé client : un X25519 et un autre à 1 octet avec bug.

Ce comportement est normalisé dans la RFC 8701: Generate Random Extensions And Sustain Extensibility (GREASE) et nous appelons ça lubrifier le protocole, comme dans « lubrifier les articulations » dans la métaphore d'Adam Langley pour qui les protocoles ont les articulations rouillées et ont besoin d'huile (grease en anglais signifiant graisse).

Ce mécanisme « grease » pour le partage apporte une amélioration, mais il n'est pas parfait car c'est la taille du partage de clé qui dans ce cas préoccupe le plus.

Les partages de clé post-quantiques sont volumineux. Les deux hybrides Kyber sont de 832 et 1 216 octets. Comparé à cela, X25519 est minuscule avec seulement 32 octets. Il n'est pas improbable que certaines mises en œuvre échouent en recevant des partages de clé si volumineux.

Notre plus gros souci concerne le partage de clé basé sur le Kyber768, plus volumineux. Un ClientHello avec un partage de clé basé sur le Kyber512 de 832 octets, plus petit donc, rentrera tout juste dans un paquet TCP classique. D'un autre côté, le partage de clé de type Kyber768 de 1 216 octets fragmentera généralement le ClientHello en deux paquets.

L'assemblage des paquets ensemble n'est pas gratuit : il exige que vous suiviez les messages partiels environnants. Généralement, cela se fait de manière transparente par la pile TCP du système d'exploitation, mais les dispositifs intermédiaires et équilibreurs de charge optimisés qui analysent chaque paquet séparément doivent (et il arrive qu'ils ne le fassent pas) assurer le suivi des connexions eux-mêmes.

La situation pour HTTP/3, qui est conçue sur QUIC, est particulièrement intéressante. Au lieu d'un simple numéro de port choisi par le client (comme c'est le cas avec TCP), un paquet QUIC provenant du client contient un ID de connexion qui est choisi par le serveur. Envisagez-le comme « Vos références » et « Nos références » dans un courrier traditionnel. Cela permet à un équilibreur de charge QUIC d'encoder dans l'ID de connexion la machine précise qui assure la connexion.

À l'ouverture de la connexion, le client QUIC ne sait pas quel ID de connexion souhaite le serveur et en envoie un au hasard. Si le client a besoin de plusieurs paquets initiaux, par exemple dans le cas d'un ClientHello volumineux, il utilise le même ID de connexion aléatoire. Même si les paquets initiaux multiples sont autorisés par la norme QUIC, il est possible qu'un équilibreur de charge QUIC ne s'y attende pas et ne soit pas en mesure de faire référence à une connexion TCP sous-jacente.

En dehors de ces pannes sérieuses, les défaillances passagères, telles que la dégradation des performances, sont également préoccupantes : si le chargement est trop lent, il est possible qu'il s'agisse avant tout d'une panne du site Web.

En 2019 dans le cadre d'une expérience menée conjointement avec Google, nous avions déployé deux accords de clé post-quantiques : CECPQ2, basé sur NTRU-HRSS et CECPQ2b, basé sur SIKE. NTRU-HRSS est très semblable à Kyber : il est un peu plus volumineux et plus lent. Les résultats de 2019 sont très prometteurs : X25519+NTRU-HRSS (ligne orange) est difficile à distinguer à partir de X25519 seul (ligne bleue).

Nous continuerons à observer de près les performances, en particulier celles qui sont à la traîne : nous souhaitons une transition harmonieuse pour tout le monde, du plus rapide au plus lent des clients sur Internet.

Internet est un système très hétérogène. Pour découvrir l'ensemble des problèmes, nous avons besoin de testeurs variés et en nombre suffisant. Nous travaillons avec les navigateurs pour ajouter la prise en charge de ces accords de clé, mais chaque réseau ne comportera pas forcément l'ensemble des navigateurs.

Ainsi, pour apporter votre contribution à Internet, essayez et faites en sorte qu'une petite partie de votre trafic à destination de domaines Cloudflare utilise ces nouvelles méthodes d'accord de clé. Nous avons des forks open source pour BoringSSL, Go et quic-go. Pour BoringSSL et Go, consultez l'échantillon de code ici. Si vous rencontrez des difficultés, écrivez-nous à l'adresse [email protected]. Nous discuterons du problème et des solutions de contournement dans le cadre du groupe de travail TLS de l'IETF.

La transition vers un internet sécurisé pour la technologie post-quantique est urgente, mais elle ne se fera pas sans difficulté. Aujourd'hui, nous avons déployé un accord de clé post-quantique préliminaire sur l'ensemble de nos serveurs, ce qui représente une portion mesurable d'Internet. Nous sommes donc en mesure de commencer à tester la grande migration dès maintenant. Nous espérons qu'en 2024, lorsque le NIST apportera la touche finale à Kyber, nous aurons préparé le terrain pour une transition harmonieuse vers un Internet post-quantique.

.....

¹Nous ne prenons en charge ces accords de clé post-quantique qu'au sein des protocoles basés sur TLS 1.3, notamment le HTTP/3. Une exception toutefois : à l'heure actuelle, nous désactivons ces échanges de clé hybrides pour les sites web en mode FIPS.