Cet article est le deuxième d'une série consacrée aux décisions techniques entourant la cryptographie post-quantique. La série a commencé la semaine dernière avec l'article sur la taille des signatures post-quantiques. Il n'est pas nécessaire d'avoir lu le premier article pour apprécier celui-ci.
Cette semaine, l'IETF a officiellement publié le dernier RFC nécessaire à la normalisation complète de l'établissement de clés post-quantique dans TLS. C'est donc le moment idéal pour examiner de plus près l'établissement de clés dans ce nouvel épisode.
Cet aspect de la migration est à la fois plus simple et plus compliqué. En résumé, la menace qui pèse sur l'établissement de clés est immédiate et il est urgent d'y répondre. Le défi technique est plus simple et la conception s'est mise en place sans trop de heurts. Voilà pour la partie simple. Côté compliqué, la NSA a choisi une voie qui va à l'encontre de la communauté technique et a créé à l'IETF une fracture qui persiste. Lisez la suite pour en savoir plus.
La menace du « Harvest Now, Decrypt Later »
Les protocoles cryptographiques comportent de nombreux éléments, mais ils doivent en général traiter trois aspects clés : l'authentification, l'établissement de clés et le chiffrement. Les algorithmes qui s'exécutent sur des ordinateurs quantiques ne représentent pas la même menace pour ces trois aspects. Contre l'authentification, par exemple, la menace ne se matérialise qu'au moment où l'authentification est nécessaire. Dans TLS, l'authentification est éphémère, nous ne sommes donc pas en danger immédiat. Nous ne le serons pas tant que les ordinateurs quantiques ne seront pas une réalité pratique.
Les ordinateurs quantiques n'auront pas vraiment d'impact sur le chiffrement, mais l'établissement de clés est attaqué dès aujourd'hui, bien avant que nous disposions d'un ordinateur quantique [pertinent sur le plan cryptographique] opérationnel. Un adversaire capable peut en effet collecter du trafic chiffré aujourd'hui, le conserver, puis le déchiffrer plus tard, lorsqu'il aura accès à un ordinateur quantique. Cette menace est mieux connue sous le nom de « harvest now, decrypt later », ou HNDL.
Compte tenu de cette asymétrie des menaces, il n'est pas surprenant que les travaux aient d'abord porté sur une nouvelle approche de l'établissement de clés. Google a d'ailleurs annoncé sa première expérimentation il y a presque exactement 10 ans. C'était à peu près au moment où le NIST commençait à préparer son concours de cryptographie post-quantique.
Dix ans plus tard, l'établissement de clés hybride domine
Aujourd'hui, tous les navigateurs modernes prennent en charge une approche hybride de l'établissement de clés, qui combine la cryptographie traditionnelle (fondée sur les courbes elliptiques) avec ML-KEM, l'algorithme retenu en premier par le NIST à cette fin. Trois variantes sont en usage : X25519MLKEM768, SecP256r1MLKEM768 et SecP384r1MLKEM1024. La construction est la même dans les trois cas, les principales différences portant sur les paramètres de courbe elliptique retenus et les niveaux de sécurité.
Sur le plan technique, ce nouvel établissement de clés repose sur les couches suivantes :
- Diffie-Hellman sur courbe elliptique (ECDH), présent dans la spécification TLS 1.3 depuis l'origine
- ML-KEM, normalisé par le NIST en 2024 (mais annoncé comme lauréat en 2022)
- RFC 9954 : Hybrid Exchange in TLS 1.3
- RFC 10024 : Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3
Pourquoi autant d'éléments ? Au départ, nous n'avions qu'ECDH. Il a ensuite fallu inventer ML-KEM pour faire face à la menace des ordinateurs quantiques. Comme ML-KEM est relativement récent et moins éprouvé, et comme la cryptographie sur courbes elliptiques est compacte et rapide, il a été décidé qu'une approche hybride offrirait la meilleure sécurité. Malheureusement, TLS ne permettait pas d'utiliser un établissement de clés hybride, d'où la conception de la RFC 9954. Enfin, la RFC 10024 a été produite pour relier le tout.
Notez aussi que les deux RFC précisent explicitement « for TLS 1.3 ». L'IETF fait de son mieux pour nous dire que ces travaux ne s'appliquent pas aux versions antérieures du protocole. TLS 1.2 est d'ailleurs gelé sur le plan fonctionnel (RFC 9851), et de nouveaux documents sont rédigés pour déprécier ce qui peut l'être (RFC 10015).
Selon Cloudflare, qui propose un tableau de bord suivant ce qu'il observe en matière de cryptographie post-quantique, environ 71 % du trafic humain qui arrive sur son CDN utilise un établissement de clés hybride et est donc protégé des menaces liées aux ordinateurs quantiques.
Voilà pour le chiffre en une, mais si vous faites défiler la page, vous verrez que seuls 11 % environ des serveurs d'origine bénéficient de la même protection. Après 10 ans de travail, nous sommes loin d'une prise en charge généralisée de l'établissement de clés résistant au quantique côté serveur. Ce premier chiffre (71 %) est flatteur, mais l'adversaire capable qui vous inquiète, lui, attaquera là où vous êtes faible, pas là où vous êtes fort.
Cela a demandé plus de travail qu'il n'y paraît
On pourrait croire que la question de l'établissement de clés a été réglée rapidement, mais ce n'est vrai que vu de loin. Comme indiqué plus haut, Google s'y est mis il y a longtemps. Cette première expérimentation, lancée en juillet 2016, s'est achevée en novembre de la même année. Elle a permis d'établir la faisabilité de l'approche.
La deuxième expérimentation a débuté fin 2019, dans le cadre d'une collaboration entre Cloudflare et Google. Elle utilisait la même approche hybride avec deux autres algorithmes, NTRU-HRSS et SIKE. Trois ans plus tard, SIKE a fini par être cassé. Ce qui a renforcé l'idée des hybrides.
Après la sélection de ML-KEM par le NIST, l'attention s'est portée sur son utilisation dans des constructions hybrides. Il a commencé à être intégré aux bibliothèques, et les éditeurs de navigateurs l'ont pris en charge. Cloudflare l'a activé en octobre 2022, avec les algorithmes « en cours de travaux » X25519Kyber512Draft00 et X25519Kyber768Draft00. Il a fallu deux ans de plus pour que ML-KEM soit normalisé, et tout le monde est ensuite passé à X25519MLKEM768 et consorts.
Impact de ML-KEM sur les performances de la poignée de main TLS
Dans l'épisode précédent, j'ai consacré tout l'article à la forte augmentation de la taille des signatures post-quantiques. Dans les faits, le passage à l'établissement de clés hybride a déjà accru la taille de la poignée de main TLS, d'environ 1 100 octets dans chaque sens.
En 2024, Google a fait état d'une augmentation médiane de 4 % de la latence de la poignée de main liée à ce changement. AWS a signalé une légère augmentation du temps de poignée de main en environnement contrôlé, en raison de besoins de calcul accrus. La conclusion principale est que la hausse de latence s'explique par le volume de données supplémentaires à transférer pour effectuer la poignée de main TLS, et cela pour environ 1 ko seulement. L'augmentation liée aux signatures ajoutera plus de dix fois ce volume.
La NSA n'aime pas la cryptographie hybride
La migration des algorithmes d'établissement de clés ressemble à une réussite, mais il y a un petit accroc : la National Security Agency américaine (la toute-puissante NSA) n'aime pas la cryptographie hybride.
En septembre 2022, la NSA a lancé sa Commercial National Algorithm Suite 2.0 (nouveau nom ; l'ancien était NSA Suite B). En soi, c'était une excellente initiative, qui a fixé tôt un calendrier de migration et clarifié les algorithmes à utiliser. Malheureusement, ses exigences en matière d'établissement de clés vont à l'encontre du reste du monde.
Dans la communauté technique, la plupart des acteurs [c'est mon impression, pas une mesure scientifique] préfèrent l'approche hybride pour la sécurité supplémentaire qu'elle apporte. Le sentiment est qu'il nous faut plus de temps pour accepter les nouveaux algorithmes post-quantiques et éprouver davantage leur sûreté. Les cryptographes sont par nature très prudents. Pour illustrer ce point, cette semaine a vu paraître deux articles de recherche intéressants, l'un entamant peut-être la sécurité des problèmes de réseaux euclidiens et l'autre celle de Classic McEliece. Rien n'est cassé pour l'instant, mais nous aimons rappeler que les attaques ne font que s'améliorer.
Cette division est surtout visible au sein du groupe de travail TLS de l'IETF, comme vous le dira toute personne qui suit la liste de diffusion. Le point de désaccord est le suivant : l'IETF doit-elle publier un RFC informatif documentant l'établissement de clés ML-KEM pur ? D'un côté, certains estiment que, du fait des exigences de la NSA, cet algorithme sera utilisé et que nous avons tous besoin de travailler à partir de la même spécification. De l'autre, certains font valoir que l'approche hybride est déjà déployée avec succès, alors pourquoi légitimer une approche moins sûre ?
Précisons que la direction actuelle est non seulement de classer ce travail comme informatif (donc pas une norme), mais aussi de le marquer comme non recommandé. Cela n'a pourtant pas suffi à éviter des discussions sans fin sur la liste. Ce document (draft-ietf-tls-mlkem-09) est actuellement en Last Call. Il est aussi déjà implémenté dans certains navigateurs, priorisé après les hybrides mais disponible pour les serveurs qui préfèrent l'approche ML-KEM pure.
Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.