L’Internet Engineering Task Force a publié le RFC 10024 à la mi-août 2026, un texte technique qui fixe pour de bon la manière dont les navigateurs et les serveurs négocieront des connexions TLS 1.3 résistantes à l’ordinateur quantique. Trois jours plus tôt, Check Point Research révélait que le groupe nord-coréen Lazarus utilisait déjà ce même algorithme, ML-KEM, pour dissimuler l’exploitation d’une faille zero-day dans le noyau Windows. Les deux événements ne sont pas liés dans les faits, mais ils racontent la même histoire : la cryptographie post-quantique vient de quitter les laboratoires pour entrer, en même temps, dans les CDN et dans les boîtes à outils des attaquants les plus sophistiqués.
Pour les équipes sécurité et les DSI en France comme dans le reste de l’Europe, ces deux annonces posent une question concrète : faut-il accélérer la migration post-quantique maintenant, ou attendre que les échéances réglementaires de l’ANSSI et de l’ENISA imposent le calendrier ? Cet article décortique le RFC 10024, la faille CVE-2026-68820 et ce que cela signifie pour les six à dix-huit prochains mois.
RFC 10024 : ce que l’IETF vient officiellement de standardiser
Le document, intitulé “Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3”, a été rédigé par Krzysztof Kwiatkowski, Panos Kampanakis, Bas Westerbaan et Douglas Stebila, puis publié par l’IETF sur la voie des standards. Son rôle est précis : il définit trois groupes nommés que TLS 1.3 peut désormais négocier lors de la poignée de main, chacun combinant un algorithme classique (courbe elliptique) avec ML-KEM, le mécanisme d’encapsulation de clé retenu par le NIST pour résister aux attaques d’un futur ordinateur quantique.
Concrètement, une session TLS négociée avec l’un de ces groupes reste protégée tant que l’un des deux composants, classique ou post-quantique, n’est pas cassé. C’est ce que les cryptographes appellent une construction hybride : elle ne mise pas tout sur un algorithme récent et encore jeune, elle garde le filet de sécurité de l’ECDHE pendant la transition. Le RFC ne modifie pas la sémantique de TLS 1.3, il étend simplement l’extension key_share pour que ces combinaisons deviennent des identifiants stables, enregistrés auprès de l’IANA, au lieu de rester des codes expérimentaux propres à chaque éditeur.
Trois groupes hybrides, trois usages différents
X25519MLKEM768, le choix par défaut
Le premier groupe associe Curve25519 (X25519) à ML-KEM-768. C’est celui que les principales piles TLS avaient déjà déployé en production sous forme de brouillon avant même la publication du RFC, et il devient de fait le groupe hybride généraliste recommandé par le registre IANA. Son codepoint est 4588, soit 0x11EC en hexadécimal. Pour la grande majorité des sites web et des API, c’est ce groupe qui sera proposé en priorité par les serveurs mis à jour.
SecP256r1MLKEM768 et SecP384r1MLKEM1024, pour les environnements réglementés
Les deux autres groupes associent respectivement la courbe NIST P-256 et la courbe NIST P-384 à ML-KEM-768 et ML-KEM-1024. Leur codepoint est 4587 (0x11EB) et 4589 (0x11ED). Ils ciblent les organisations qui doivent rester sur des courbes certifiées NIST pour des raisons de conformité, notamment les administrations et les secteurs régulés qui n’ont pas le droit d’utiliser Curve25519 dans leurs déploiements FIPS. Le groupe SecP384r1MLKEM1024, avec son niveau de sécurité NIST 5, vise les usages à plus longue durée de vie, comme le chiffrement de documents sensibles ou les communications diplomatiques.
De FIPS 203 au RFC 10024 : deux ans pour transformer un brouillon en standard
Le calendrier mérite d’être posé clairement, car il éclaire la vitesse à laquelle ce chantier a avancé. Le NIST a finalisé ML-KEM, dérivé de l’algorithme Kyber, sous la référence FIPS 203 en 2024. Les navigateurs et les grands fournisseurs de cloud n’ont pas attendu la publication d’un RFC pour bouger : dès 2025, le brouillon draft-ietf-tls-ecdhe-mlkem tournait déjà en production chez plusieurs acteurs majeurs, avec des identifiants provisoires. Le RFC 10024, publié en août 2026, ne fait donc pas naître une technologie, il stabilise un usage qui existait déjà de facto depuis plusieurs mois. Entre la norme NIST et la norme IETF, il se sera écoulé un peu moins de deux ans, un rythme rapide pour un changement qui touche la brique de sécurité la plus utilisée du web.
Notre couverture de l’adoption réelle de ce trafic hybride, publiée après une mesure d’Akamai, avait déjà chiffré la bascule : au moment de la publication du RFC, environ 52 % du trafic TLS 1.3 mesuré utilisait déjà un échange de clé hybride post-quantique, avec un surcoût de latence de l’ordre de 1,5 milliseconde par poignée de main. Ce chiffre confirme que la standardisation IETF a suivi le marché plutôt que de le précéder, un schéma assez inhabituel pour un protocole aussi central.
Lazarus détourne la cryptographie post-quantique pour cacher un 0-day
Le 11 août 2026, Check Point Research a publié un rapport intitulé “Shattering the Dream: When a Job Offer Becomes a Zero-Day Attack”. Il documente une campagne attribuée au groupe Lazarus, lié au renseignement nord-coréen, qui a utilisé ML-KEM pour chiffrer les échanges de clés servant à livrer un exploit ciblant un pilote noyau de Windows. Selon le rapport, l’attaquant génère une paire de clés fraîches avec ML-KEM, encapsule la clé, transmet le résultat encapsulé, puis reçoit et déchiffre en mémoire la charge d’exploitation. Autrement dit, la même primitive cryptographique que celle que le RFC 10024 vient de généraliser pour protéger les internautes a servi, presque au même moment, à protéger le trafic de commande et de contrôle d’un rootkit d’État.
C’est ce qui rend l’affaire notable au-delà du cercle des chercheurs en cryptographie. Il s’agit vraisemblablement du premier cas public et documenté d’un acteur étatique utilisant un algorithme post-quantique normalisé par le NIST dans un malware opérationnel, et non dans une preuve de concept académique. Le choix n’est pas anodin : en s’appuyant sur ML-KEM plutôt que sur un simple chiffrement symétrique, Lazarus complique le travail des équipes de threat hunting qui s’appuient sur des signatures réseau construites pour détecter des échanges de clés classiques.
CVE-2026-68820 : anatomie de la faille cachée dans AFD.sys
La vulnérabilité exploitée par Lazarus porte la référence CVE-2026-68820. Elle touche AFD.sys, le pilote Ancillary Function Driver de Windows qui gère les sockets réseau au niveau noyau, un composant sollicité par pratiquement tous les processus qui ouvrent une connexion réseau sur la machine. Il s’agit d’une condition de concurrence de type use-after-free : en gagnant une course contre le noyau, l’attaquant obtient les privilèges SYSTEM, c’est-à-dire un contrôle total de la machine. Le score CVSS retenu est de 7.0, une note qui reflète la complexité d’exploitation mais qui masque en partie la gravité réelle, puisque le composant touché est présent sur pratiquement chaque poste Windows connecté à un réseau.
Check Point a suivi un processus de divulgation responsable et crédité Microsoft de la correction. Le pilote AFD.sys avait déjà fait parler de lui par le passé pour des bugs de concurrence similaires, un rappel que les composants réseau bas niveau du noyau Windows restent une cible de choix pour les groupes disposant de ressources d’ingénierie inverse importantes.
Opération Dream Job : la fausse offre d’emploi qui cache un rootkit
La campagne s’inscrit dans la lignée d’Opération Dream Job, une opération d’ingénierie sociale que Lazarus mène depuis plusieurs années et qui consiste à approcher des employés de secteurs sensibles avec de fausses offres d’emploi. Cette fois, les cibles appartiennent aux secteurs de la défense et de l’aviation. La chaîne d’infection démarre par un document ou une pièce jointe liée à l’offre d’emploi, se poursuit par le chargement latéral d’une DLL malveillante, puis bascule vers l’élévation de privilèges via CVE-2026-68820. Une fois les droits SYSTEM obtenus, le malware déploie FudModule, le rootkit en mode noyau que Lazarus réutilise de campagne en campagne pour aveugler les solutions EDR.
Cette combinaison, ingénierie sociale ciblée, exploit noyau zero-day, rootkit furtif et chiffrement post-quantique du canal de commande, dessine un niveau de sophistication qui dépasse largement le profil classique du cybercrime financier. Elle correspond au mode opératoire habituel des groupes soutenus par un État, où le coût d’un exploit zero-day, souvent estimé en centaines de milliers de dollars sur le marché gris, se justifie par la valeur du renseignement visé.
Patch Tuesday d’août : Microsoft corrige 398 failles, une seule activement exploitée
Microsoft a livré le correctif de CVE-2026-68820 le 11 août 2026, dans le cadre de son Patch Tuesday mensuel. Selon la couverture de The Hacker News, cette mise à jour corrige au total 398 failles, dont trois zero-days. Sur ces trois, CVE-2026-68820 est la seule que Microsoft classe comme activement exploitée au moment de la publication, ce qui explique l’urgence donnée par les équipes de sécurité à son déploiement dans les parcs Windows exposés à Internet ou accessibles à des utilisateurs à privilèges limités.
Pour les RSSI, la leçon opérationnelle est simple : un composant comme AFD.sys touche l’intégralité du parc, pas seulement les serveurs exposés. Les correctifs de ce type devraient être priorisés indépendamment de l’exposition réseau apparente d’une machine, puisque l’élévation de privilèges locale suffit une fois qu’un premier accès a été obtenu par un autre vecteur, ici le phishing ciblé.
Tableau comparatif : les trois groupes hybrides du RFC 10024
Le tableau ci-dessous résume les caractéristiques techniques de chacun des trois groupes désormais standardisés, utile pour toute équipe qui doit configurer ses serveurs TLS ou choisir quel groupe prioriser dans sa liste de préférences.
| Nom du groupe | Composant classique | Composant post-quantique | Niveau de sécurité NIST | Codepoint IANA |
|---|---|---|---|---|
| X25519MLKEM768 | X25519 (Curve25519) | ML-KEM-768 | Niveau 3 | 4588 / 0x11EC |
| SecP256r1MLKEM768 | secp256r1 (NIST P-256) | ML-KEM-768 | Niveau 3 | 4587 / 0x11EB |
| SecP384r1MLKEM1024 | secp384r1 (NIST P-384) | ML-KEM-1024 | Niveau 5 | 4589 / 0x11ED |
Un administrateur système peut vérifier quels groupes un serveur propose lors de la poignée de main avec une commande OpenSSL classique, en observant l’extension key_share renvoyée par le serveur :
openssl s_client -connect exemple.fr:443 -groups X25519MLKEM768 -tls1_3
# Vérifier la liste des groupes supportés par la bibliothèque locale
openssl list -kem-algorithms | grep -i mlkemAdoption du TLS post-quantique dans le monde réel
La bascule vers l’hybride post-quantique ne s’est pas faite en un jour. Elle s’étale sur une décennie de travaux qui commencent bien avant que le grand public n’entende parler de ML-KEM. Le tableau suivant remet en perspective les jalons qui ont mené jusqu’au RFC 10024 et à l’incident Lazarus.
| Date | Événement |
|---|---|
| 2016 | Le NIST lance son concours international de standardisation post-quantique |
| 2022 | CRYSTALS-Kyber est sélectionné comme futur standard, avant de devenir ML-KEM |
| 2024 | Publication de FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) et FIPS 205 (SLH-DSA) par le NIST |
| 2025 | Déploiement en production du brouillon draft-ietf-tls-ecdhe-mlkem chez plusieurs grands fournisseurs |
| 11 août 2026 | Microsoft corrige CVE-2026-68820, déjà exploitée avec ML-KEM par Lazarus |
| Mi-août 2026 | L’IETF publie le RFC 10024, qui fixe trois groupes hybrides pour TLS 1.3 |
| Fin août 2026 | Environ 52 % du trafic TLS 1.3 mesuré utilise déjà un échange hybride post-quantique |
Ce que disent les pionniers du post-quantique TLS
Cloudflare a été l’un des tout premiers grands opérateurs à pousser le sujet hors des laboratoires. Son fondateur et directeur général, Matthew Prince, avait résumé l’ambition de l’entreprise en ces termes lors du lancement de son support post-quantique en beta : “Starting today, as a beta service, all websites and APIs served through Cloudflare support post-quantum hybrid key agreement“, selon le billet publié sur le blog de l’entreprise. À l’époque, l’équipe précisait volontairement le périmètre de son annonce : “For the moment, we will leave it at that: we’ve only added post-quantum support to TLS 1.3”, rappelant que la démarche visait uniquement la couche transport et pas encore les certificats ou les signatures.
Le chercheur Cloudflare Nick Sullivan avait de son côté résumé la philosophie de conception qui a guidé tout ce travail : “TLS can become post-quantum straightforwardly: we just write ‘PQ’ in front of the algorithms“, une formule qui simplifie à dessein un chantier d’ingénierie qui a en réalité demandé plusieurs années d’itérations. Ces itérations avaient débuté tôt : dès les premières expérimentations, un autre ingénieur de Cloudflare, Nils Östman, décrivait le protocole ainsi : “We implemented two post-quantum (i.e., not yet known to be broken by quantum computers) key exchanges, integrated them into our TLS stack and deployed the implementation on our edge servers and in Chrome Canary clients“, un test grandeur nature qui a directement nourri les travaux repris ensuite par l’IETF.
Du côté de Microsoft, l’équipe de recherche avait posé le problème sans détour dans la présentation de son propre projet post-quantique : “While TLS is secure against today’s classical computers, the asymmetric cryptography in TLS is unfortunately vulnerable to future attacks from quantum computers“. Cette phrase, écrite plusieurs années avant l’incident Lazarus, prend un relief particulier aujourd’hui : la vulnérabilité qu’elle anticipait concernait le chiffrement classique face au quantique, pas l’usage du post-quantique lui-même comme camouflage pour un malware, un scénario que peu d’experts avaient anticipé publiquement.
Impact sur le marché : CDN, navigateurs et éditeurs de sécurité
Pour les fournisseurs d’infrastructure, le RFC 10024 change surtout la nature de la conversation avec leurs clients entreprise. Tant que les groupes hybrides restaient des identifiants de brouillon propres à chaque implémentation, il était difficile de garantir une interopérabilité stable entre un pare-feu applicatif d’un éditeur, un CDN d’un autre et un navigateur d’un troisième. Avec des codepoints IANA figés, les éditeurs de WAF, de proxies TLS et de sondes d’inspection réseau peuvent désormais coder en dur la reconnaissance de ces groupes sans craindre une rupture de compatibilité au prochain changement de brouillon.
Cela crée aussi un point de friction pour les éditeurs de solutions de sécurité réseau plus anciennes. Une partie des équipements d’inspection profonde de paquets déployés dans les grandes entreprises reste incapable de déchiffrer ou même de classifier correctement un tunnel TLS négocié avec ML-KEM, faute de mise à jour. Les tailles de clés post-quantiques, nettement plus grandes que celles de l’ECDHE classique, peuvent aussi fragmenter certains paquets réseau d’une manière que des équipements anciens interprètent mal, un problème déjà documenté lors des premiers essais de Cloudflare avec Chrome Canary. Les entreprises qui exploitent encore des boîtiers de moyenne gamme datant d’avant 2023 devraient vérifier leur compatibilité avant que l’adoption ne dépasse la majorité du trafic.
Côté malware, l’affaire Lazarus envoie un signal clair aux éditeurs d’antivirus et d’EDR : les signatures réseau qui identifient un canal de commande et de contrôle en repérant des motifs cryptographiques classiques doivent désormais intégrer la possibilité qu’un exécutable malveillant embarque sa propre implémentation de ML-KEM. Plusieurs éditeurs de sécurité ont déjà commencé à publier des règles de détection comportementale ciblant l’usage anormal de bibliothèques post-quantiques par des processus qui n’ont aucune raison légitime de les charger, une piste de détection plus fiable que la seule inspection du trafic chiffré.
Contexte historique : dix ans de course à la normalisation post-quantique
Le RFC 10024 clôt, à sa manière, un chapitre ouvert en 2016, quand le NIST a lancé son appel à candidatures pour trouver des algorithmes capables de résister à un ordinateur quantique suffisamment puissant pour casser RSA et les courbes elliptiques via l’algorithme de Shor. Sur la soixantaine de candidatures initiales, CRYSTALS-Kyber s’est imposé en 2022 comme le mécanisme d’encapsulation de clé retenu, avant de devenir ML-KEM lors de sa publication officielle sous FIPS 203 en 2024, aux côtés de ML-DSA pour les signatures et de SLH-DSA comme alternative de secours reposant sur des hypothèses mathématiques différentes.
Ce choix de diversifier les familles mathématiques n’est pas accessoire. Il répond directement à un précédent embarrassant pour le NIST : SIKE, l’un des finalistes du même concours, avait été cassé par une attaque classique en 2022, quelques mois avant l’annonce des lauréats, rappelant que même des algorithmes ayant survécu plusieurs années d’examen public peuvent tomber. Cette prudence explique pourquoi RFC 10024 mise sur des constructions hybrides plutôt que sur ML-KEM seul : si une faiblesse mathématique inattendue était découverte dans les réseaux euclidiens qui fondent ML-KEM, la composante ECDHE continuerait de protéger la session.
RFC 10024 face aux échéances ANSSI, ENISA et NIST
La standardisation IETF s’inscrit dans un calendrier réglementaire plus large et déjà largement documenté sur ce site. L’ANSSI a fixé le cap d’une migration post-quantique obligatoire pour les produits certifiés à partir de 2027, avec une préférence marquée pour les constructions hybrides plutôt que pour un remplacement brutal des algorithmes classiques, exactement la logique que retient le RFC 10024. Aux États-Unis, l’executive order présidentiel avait fixé une échéance à horizon 2030 pour la bascule complète des systèmes fédéraux vers la cryptographie post-quantique. Le RFC 10024 fournit à ces deux calendriers la brique technique concrète qui manquait encore côté TLS : un identifiant stable, interopérable, que les équipes conformité peuvent citer dans leurs politiques de configuration sans dépendre d’un brouillon susceptible de changer.
Nos analyses précédentes sur la comparaison de performance entre RSA, ECC et cryptographie post-quantique avaient déjà montré un écart de vitesse favorable à ML-KEM, jusqu’à 2,4 fois plus rapide que RSA sur certaines opérations, ce qui limite l’argument de la lenteur souvent avancé contre la migration. Sur le terrain des signatures, plusieurs institutions financières testent en parallèle ML-DSA-65 pour sécuriser leurs transactions, un chantier distinct de TLS mais qui avance sur le même rythme réglementaire. Et sur le terrain des vulnérabilités, la pile TLS 1.3 elle-même n’a pas été épargnée cette année, comme l’a montré la faille CVE-2026-32283 dans le paquet crypto/tls de Go, qui avait paralysé plusieurs services début 2026, un rappel que la robustesse d’un protocole normalisé ne protège jamais totalement contre les bugs d’implémentation.
Ce que cela change pour les entreprises françaises et européennes
Pour une DSI française, le message pratique tient en trois points. D’abord, vérifier que les serveurs web, les load balancers et les passerelles API supportent au moins X25519MLKEM768, condition de base pour rester compatible avec les navigateurs qui, eux, avancent vite. Ensuite, auditer les équipements de sécurité réseau plus anciens pour s’assurer qu’ils ne cassent pas silencieusement les connexions négociées avec des clés post-quantiques plus volumineuses, un problème déjà observé sur certains proxys d’entreprise mal configurés. Enfin, suivre de près les secteurs identifiés comme cibles par Lazarus, notamment la défense et l’aviation, mais aussi, par extension logique, tout sous-traitant qui travaille avec ces industries et qui pourrait servir de porte d’entrée plus facile à atteindre.
L’incident CVE-2026-68820 rappelle aussi une réalité opérationnelle simple : la vitesse de déploiement des correctifs Windows reste le facteur qui pèse le plus lourd dans l’équation, bien avant la sophistication cryptographique de l’attaquant. Une entreprise qui applique son Patch Tuesday avec deux ou trois semaines de retard reste exposée à ce type de campagne indépendamment de ses investissements en détection réseau.
Prédictions : ce qui va se passer d’ici 2027
- L’adoption hybride dépassera 70 % du trafic TLS 1.3 mesuré d’ici mi-2027, portée par la mise à jour progressive des grands CDN et par le support natif dans les versions récentes des navigateurs majeurs.
- D’autres groupes malveillants vont copier la tactique de Lazarus, en intégrant ML-KEM ou d’autres primitives post-quantiques à leurs canaux de commande et de contrôle pour compliquer la détection réseau, une évolution logique une fois la technique documentée publiquement.
- Les éditeurs d’équipements réseau anciens vont accélérer leurs mises à jour sous la pression de leurs clients entreprise, faute de quoi ils risquent de casser silencieusement une part croissante du trafic chiffré légitime.
- L’ANSSI et l’ENISA devraient publier des profils de configuration recommandés citant explicitement les codepoints du RFC 10024, transformant une norme technique en référence de conformité opposable pour les audits de sécurité.
- D’autres composants noyau Windows liés au réseau feront l’objet de recherches similaires à celles menées sur AFD.sys, ce pilote n’étant vraisemblablement pas le dernier de sa catégorie à révéler des conditions de concurrence exploitables.
Questions fréquentes
Qu’est-ce que le RFC 10024 change concrètement pour un site web ?
Il donne un identifiant stable et normalisé aux échanges de clés hybrides post-quantiques dans TLS 1.3. Un site web dont le serveur ou le CDN supporte ces groupes proposera automatiquement une protection contre un futur ordinateur quantique capable de casser les courbes elliptiques classiques, sans que l’utilisateur ne remarque de différence dans sa navigation.
Faut-il désactiver ML-KEM sur mes serveurs à cause de l’incident Lazarus ?
Non. Lazarus n’a pas exploité une faiblesse de ML-KEM lui-même, il a utilisé cet algorithme légitime pour chiffrer ses propres communications malveillantes, exactement comme un cybercriminel classique utilise du HTTPS. Désactiver ML-KEM affaiblirait la sécurité de vos connexions légitimes sans gêner l’attaquant, qui peut chiffrer son trafic avec n’importe quel algorithme.
Quelle est la différence entre X25519MLKEM768 et les deux autres groupes ?
X25519MLKEM768 s’appuie sur Curve25519, une courbe très répandue mais non certifiée NIST. Les deux autres groupes utilisent des courbes NIST P-256 et P-384, nécessaires pour les environnements soumis à des exigences de conformité FIPS strictes, notamment certaines administrations.
CVE-2026-68820 touche-t-elle Windows 11 et Windows Server ?
Le pilote AFD.sys est présent sur les versions modernes de Windows qui gèrent la pile réseau WinSock, ce qui inclut les postes clients comme les serveurs. Le correctif publié le 11 août 2026 lors du Patch Tuesday de Microsoft doit être appliqué sans délai sur l’ensemble du parc concerné.
Mon navigateur supporte-t-il déjà le TLS post-quantique du RFC 10024 ?
Les principales piles TLS des navigateurs modernes intégraient déjà les groupes hybrides sous forme de brouillon avant la publication du RFC, et la bascule vers les identifiants normalisés se fait généralement de façon transparente lors d’une mise à jour du navigateur, sans action requise de l’utilisateur.
Pourquoi Lazarus a-t-il choisi la cryptographie post-quantique plutôt qu’un chiffrement classique ?
Le rapport de Check Point ne détaille pas la motivation exacte du groupe, mais l’usage d’un algorithme récent et encore peu surveillé par les outils de détection réseau standards constitue un moyen efficace de faire passer un canal malveillant sous le radar des signatures existantes, tout en démontrant une maîtrise technique de pointe.
Quelle échéance l’ANSSI fixe-t-elle pour la migration post-quantique en France ?
L’ANSSI a indiqué vouloir rendre la prise en charge post-quantique obligatoire pour les produits soumis à certification à partir de 2027, avec une préférence pour les constructions hybrides plutôt qu’un remplacement direct des algorithmes classiques.
Combien d’organisations ont été touchées par la campagne Lazarus ?
Check Point Research décrit une campagne ciblée sur les secteurs de la défense et de l’aviation, sans publier de décompte précis du nombre d’organisations touchées. Le rapport insiste sur le caractère chirurgical de l’opération plutôt que sur une diffusion massive.
