11/04/2025
Cybersecurity Insights
La cryptographie post-quantique dans TLS (1/2) – L’échange de clés
Equipe SEAL
TLS est un protocole permettant d’assurer la confidentialité et l’intégrité des échanges entre un client et un serveur et à minima l’authenticité du serveur. Dernièrement, la cryptographie post-quantique (abrégée PQC) y a été intégrée.
Ce premier billet se concentrera sur l’échange de clé. Un billet suivant portera sur les signatures et le chiffrement du flux de données.
Les spécificités de TLS1.3
La dernière version de TLS est la 1.3, sortie en 2018. Les principales améliorations entre TLS1.2 et TLS1.3 sont la réduction du nombre d’échanges dans la poignée de main pour une meilleure efficacité et le chiffrement d’une partie de la poignée de main. Une autre différence concerne les suites de chiffrement. Jusqu’à TLS1.2, les suites négociées par le client et le serveur incluaient, pour chaque communication :
- Un mécanisme d’échange de clé ;
- Un mécanisme d’authentification ;
- Un mécanisme de chiffrement symétrique assurant la confidentialité et l’intégrité ;
- Une fonction de hachage pour les dérivations de secrets.
Voici un exemple de suite de chiffrement dans TLS1.2 : TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.
Dans TLS1.3, les suites de chiffrement incluent seulement :
- Un algorithme de chiffrement assurant la confidentialité et l’intégrité ;
- Une fonction de hachage.
Les mécanismes d’échange de clé et d’authentification sont spécifiés dans des extensions. Voici les cinq suites de chiffrement définies par l’IANA pour TLS1.3 :
- TLS_AES_256_GCM_SHA384 ;
- TLS_CHACHA20_POLY1305_SHA256 ;
- TLS_AES_128_GCM_SHA256 ;
- TLS_AES_128_CCM_8_SHA256 ;
- TLS_AES_128_CCM_SHA256.
L’attaque Store Now Decrypt Later
Bien qu’aucun ordinateur quantique efficace ne semble exister pour le moment, il est important d’utiliser le plus tôt possible des algorithmes post-quantiques. En effet, un attaquant pourrait stocker des communications dont l’échange de clé et les données chiffrées. Si l’attaquant a accès, par la suite, à un ordinateur quantique permettant de retrouver les clés de session négociées, il pourra alors déchiffrer l’ensemble des communications stockées . C’est pourquoi il est nécessaire de se protéger dès maintenant des attaques pouvant être réalisées par un ordinateur quantique.
L’hybridation
Utiliser des algorithmes post-quantiques permet donc de se protéger des attaques Store Now Decrypt Later, mais il peut être difficile de leur accorder une confiance totale. L’hybridation est un compromis combinant un algorithme traditionnel avec un algorithme post-quantique.
L’intégration de la PQC dans l'échange de clé de TLS
Pour permettre d’utiliser de la cryptographie post-quantique dans TLS, plusieurs contraintes ont été énoncées. En voici les principales :
- Aucun aller-retour ne doit être ajouté dans la poignée de main.
- L’utilisation de nouveaux algorithmes ne doit pas être excessivement couteuse.
- Les clients et les serveurs utilisant ces nouveaux algorithmes doivent rester rétro compatibles avec les autres parties n’utilisant pas ces algorithmes.
La cryptographie post-quantique ne concerne que les échanges de clés dans un premier temps. Adapter les extensions précisant les mécanismes d’échange de clé est donc suffisant. Plus précisément, seules les extensions supported_groups et key_share sont impactées. L’intégration du post-quantique dans TLS est (relativement) facile ; il n’est donc pas nécessaire de mettre à jour le protocole avec une version 1.4 ou 2.0. Les deux paragraphes suivants détaillent comment ces deux extensions sont modifiées.
L’extension supported_groups
L’extension key_share
Cette extension est utilisée pour le partage des clés publiques dans le cas d’un échange de clés Diffie-Hellman classique, mais pour un KEM elle est utilisée pour stocker la clé publique dans le Client Hello et le chiffré dans le Server Hello. Lorsqu’un mécanisme hybride est choisi les données hybrides sont transmises dans cette extension également .
Comme chaque combinaison d’échange de clés est considérée comme une nouvelle méthode d’échange de clés unique, les clés de chacun des algorithmes sous-jacents sont concaténées. Les tailles de chaque clé étant connue à l’avance, aucun codage supplémentaire n’est nécessaire pour indiquer la longueur des données. Il est important que la clé publique de chaque algorithme soit générée de manière indépendante. Il est cependant possible de réutiliser une clé publique pour différents groupes en la dupliquant . Cette duplication ne pose pas de problème de sécurité car une seule clé publique sera finalement utilisée mais elle peut augmenter significativement la taille de l’extension key_share.
La règle pour l’ordre des données est de respecter l’ordre dans le nom du groupe. Par exemple pour le groupe SecP384r1MLKEM1024, les données relatives à SecP384r1 seront placées en première position et celle relatives à MLKEM1024 en seconde. Cependant, quand un des deux groupes n’est pas reconnu par le NIST, comme c’est le cas pour x25519 (cf section 3.2.2.1 du NIST SP 800-186), ces données sont placées en dernières.
Après l’échange de clé hybride, deux clés de 32 octets sont connues par le client et le serveur. Chacun doit calculer la clé de session avec une fonction de dérivation KDF : session_key = HKDF(PSK,k1||k2), où PSK signifie Pre Shared Key. Cette clé pré-partagée peut être issue d’une session TLS1.3 précédente ou avoir été partagée de manière indépendante du protocole en amont de l’établissement de la session courante. Cette dérivation est indispensable ; sa suppression expose à des attaques si un oracle de décapsulation existe.
L’analyse d’une poignée de main TLS avec de la PQC
Pour analyser une telle poignée de main, il faut un client et un serveur qui soient tous deux compatibles.
La compatibilité des clients et des serveurs
Côté client, de nombreux navigateurs offrent des suites hybrides ; c’est notamment le cas des navigateurs Chromium (Google Chrome, Microsoft Edge, …) mais aussi de Firefox. Par défaut, ces navigateurs proposent le groupe X25519MLKEM768. Il est possible de désactiver ce groupe dans les paramètres des navigateurs.
- Pour Firefox : dans about:config avec la variable tls.enable_kyber qui contrairement à ce que son nom indique offre bien un schéma hybride avec MLKEM et non avec Kyber.
- Pour Google Chrome : dans chrome://flags avec #enable-tls12-kyber et #use-ml-kem. Attention le flag #enable-tls12-kyber est expérimental et permet d’utiliser le groupe X25519Kyber768Draft00 si #use-ml-kem est désactivé.
Côté serveur, les sites web hébergés chez Cloudflare acceptent les groupes hybrides.
La page https://pq.cloudflareresearch.com/ permet de savoir facilement si notre navigateur est compatible post-quantique.
L’analyse d’une capture avec Wireshark
En écoutant une communication avec Wireshark entre un navigateur et un site web compatible PQC (comme celui d’Amossys !), il est possible de regarder en détails les extensions key_share et supported_groups. Dans le Client Hello, comme attendu, le groupe X25519MLKEM768 est bien proposé ; c’est le groupe inconnu 0x11ec sur la photo car l’outil Wireshark, utilisé pour obtenir la capture réseau, ne l’identifie pas pour le moment.
Dans key_share, les clés publiques de MLKEM768 et de X25519 sont envoyées ; leur taille concaténée est bien cohérente à celle attendue. Dans cette extension le numéro du groupe apparaît en décimal et non en hexadécimal comme dans supported_groups.
Dans la réponse du serveur, le groupe choisi est bien X25519MLKEM768 et la taille des données échangées correspond bien à la taille des chiffrés concaténées.
La cryptographie post-quantique est donc bien présente et utilisée dans TLS1.3 au niveau des échanges de clés !
Et les signatures post-quantiques ?
