Intégrer la cryptographie post-quantique dans TLS

TLS (Transport Layer Security) protège le trafic en transit, mais pas sa confidentialité future. Un adversaire peut capturer aujourd’hui des sessions chiffrées, les archiver, puis attendre une capacité de calcul quantique suffisante pour casser les échanges de clés classiques. Pour les données dont le secret doit survivre plus de dix ans, attendre la panne annoncée revient à organiser le retard.

→ Lire l’explication complète de la marmotte

Store now, decrypt later : la dette de confidentialité

L’attaque store now, decrypt later ne vise pas une session TLS active. Elle consiste à intercepter passivement des flux, conserver les captures réseau, puis déchiffrer les archives quand une machine quantique pourra exécuter l’algorithme de Shor à l’échelle nécessaire. RSA (Rivest, Shamir, Adleman), Diffie-Hellman sur courbe elliptique et ECDSA (Elliptic Curve Digital Signature Algorithm) tomberaient alors dans la même catégorie : des mécanismes corrects aujourd’hui, mais dont la difficulté mathématique est vulnérable au calcul quantique.

La cible est donc la confidentialité rétrospective. Un échange TLS négocié en 2026 avec X25519 peut rester inviolable pendant des années par les moyens classiques, puis devenir lisible si sa capture a été conservée. La Perfect Forward Secrecy, ou confidentialité persistante, ne règle pas ce point : elle protège contre le vol ultérieur de la clé privée du serveur, pas contre la rupture de Diffie-Hellman lui-même.

La décision dépend de la durée de valeur des données, pas du calendrier public des ordinateurs quantiques. Secrets industriels, identifiants d’administration, archives RH, contrats, métadonnées diplomatiques et clés de récupération doivent être classés comme trafic à migrer maintenant. Une image de catalogue produit ou une requête publique à faible durée de vie peut attendre. La cryptographie adore les horizons lointains, jusqu’au moment où ils deviennent un incident de conservation.

Le modèle de menace doit inclure les points de collecte : proxy de sortie, liaison inter-sites, réseau opérateur, Wi-Fi d’entreprise, sonde légale ou illégale, miroir de port et sauvegarde de capture. Chiffrer TLS jusqu’au frontal ne suffit pas si le même flux est déchiffré puis journalisé en clair par une passerelle applicative. La page sur TLS couvre la poignée de main classique ; ici, le point critique est le remplacement progressif de son établissement de secret.

ML-KEM et ML-DSA : primitives NIST et coûts réels

Le NIST (National Institute of Standards and Technology) a standardisé ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) dans FIPS 203 (Federal Information Processing Standard). ML-KEM sert à établir un secret partagé entre client et serveur. Il remplace fonctionnellement l’échange Diffie-Hellman, sans être un Diffie-Hellman plus gros : le client encapsule un secret vers la clé publique du serveur, le serveur le décapsule avec sa clé privée.

Pour TLS, le profil de référence est ML-KEM-768. Sa clé publique fait 1 184 octets et son texte chiffré 1 088 octets. X25519 transporte une clé publique de 32 octets. Le prix est donc visible dans le premier aller-retour, dans les paquets fragmentés et dans les limites de certains équipements réseau. Le compromis central est net : gagner une confidentialité résistante à l’attaque quantique sur les flux archivables, payer davantage de bande passante, de mémoire et de complexité d’interopérabilité.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardisé dans FIPS 204, répond à un autre besoin : signer des certificats, des logiciels ou des assertions. ML-DSA-65 utilise une clé publique de 1 952 octets et produit des signatures de 3 309 octets. Une signature ECDSA P-256 tient généralement en 64 octets. Un certificat X.509 signé en ML-DSA grossit vite, et une chaîne de certificats grossit avec lui. Un paquet Ethernet n’a aucune sympathie particulière pour les ambitions académiques.

Il faut distinguer les deux chantiers. L’échange de clés post-quantique dans TLS traite la menace d’écoute différée et peut se déployer rapidement grâce aux groupes hybrides. Les certificats post-quantiques traitent l’authentification future, mais dépendent encore davantage des autorités de certification, des HSM (Hardware Security Module), des bibliothèques, des clients et des politiques de validation. Confondre les deux conduit souvent à attendre les certificats post-quantiques avant d’activer ML-KEM. C’est une mauvaise séquence.

Groupes hybrides TLS : la transition recommandée

Un groupe hybride combine une contribution classique et une contribution post-quantique dans la même poignée de main TLS. Le groupe X25519MLKEM768 associe X25519 à ML-KEM-768. Le secret de session est dérivé des deux secrets produits, avec un mécanisme de dérivation qui les lie au transcript TLS.

Cette construction garantit une propriété essentielle : la session reste protégée si au moins un des deux mécanismes demeure sûr. Si ML-KEM révèle une faiblesse cryptographique ou d’implémentation, X25519 conserve la sécurité contre un attaquant classique. Si X25519 devient cassable par calcul quantique, ML-KEM conserve la confidentialité post-quantique. Ce n’est pas un talisman marketing à deux logos, c’est une réduction de risque pendant une migration où les surprises sont statistiquement garanties.

La recommandation est d’activer X25519MLKEM768 en préférence, puis de conserver X25519 comme repli temporaire pour les pairs incapables de négocier le groupe hybride. Désactiver immédiatement X25519 seul casse des clients anciens sans rendre le parc plus post-quantique. À l’inverse, laisser le serveur choisir silencieusement un groupe classique avec un client moderne gaspille la migration.

Le repli doit être mesuré. Les journaux de terminaison TLS doivent exposer le groupe négocié, la version TLS et le nom du service virtuel. Une métrique agrégée par groupe permet de connaître la part effective de trafic hybride. Sans cette mesure, l’activation post-quantique devient une case cochée dans une slide, forme de vie connue pour survivre sans jamais toucher un paquet réseau.

L’hybride ne garantit pas l’authentification post-quantique. Un certificat ECDSA ou RSA peut encore être cassé dans le futur si une signature enregistrée doit être vérifiée longtemps après. Pour le trafic web courant, la priorité reste ML-KEM hybride. Pour les signatures à validité longue, les archives signées et les racines de confiance, la stratégie ML-DSA doit être traitée séparément avec la PKI expliquée.

Support TLS actuel et exemple OpenSSL

Les navigateurs Chromium négocient déjà des groupes hybrides fondés sur X25519 et ML-KEM-768 lorsque le serveur les annonce. Firefox dispose également d’un support post-quantique hybride sur les versions récentes. Le comportement exact dépend de la version, des politiques de distribution et des éventuels middleboxes qui cassent les extensions TLS inhabituelles. Safari et les clients embarqués exigent une validation explicite : supposer leur support depuis une matrice marketing est une méthode étonnamment efficace pour découvrir les limites d’un proxy.

Côté serveur, OpenSSL 3.5 apporte le support natif de ML-KEM et des groupes TLS hybrides. Les distributions peuvent toutefois livrer une version antérieure, appliquer des correctifs divergents ou construire Nginx, HAProxy et Apache avec une autre bibliothèque cryptographique. Vérifier la bibliothèque réellement liée au processus, pas celle installée sur le système. Les appliances TLS, bibliothèques Java, agents d’observabilité et proxies de service constituent souvent le vrai facteur limitant.

L’exemple suivant teste un serveur OpenSSL 3.5 avec un certificat de laboratoire classique. Le certificat n’est pas post-quantique, ce qui est volontaire : le test valide l’établissement hybride de secret, pas la migration des signatures.

# Générer une clé et un certificat de test valables un jour.
openssl req -x509 -newkey rsa:3072 -nodes -days 1 \
  -keyout server.key -out server.crt -subj "/CN=localhost"

# Démarrer TLS 1.3 en préférant le groupe hybride.
openssl s_server -accept 8443 -cert server.crt -key server.key \
  -tls1_3 -groups X25519MLKEM768:X25519

# Dans un second terminal, imposer le groupe hybride et vérifier la négociation.
openssl s_client -connect 127.0.0.1:8443 -tls1_3 \
  -groups X25519MLKEM768 -brief

La sortie doit indiquer TLS 1.3 et le groupe X25519MLKEM768. Un échec group not supported signale généralement une version OpenSSL trop ancienne, une compilation sans le support requis ou une orthographe de groupe différente selon la pile. Un échec après le ClientHello peut aussi révéler un équipement intermédiaire qui filtre les extensions ou ne tolère pas leur taille.

Ce test ne valide ni Nginx, ni un répartiteur de charge, ni une chaîne de proxy. Chaque terminaison TLS doit être testée séparément, y compris les chemins IPv6, les services d’administration et le mTLS (mutual TLS). Le mTLS ajoute la vérification d’un certificat client, détaillée dans la documentation mTLS, mais ne transforme pas automatiquement son échange de clés en mécanisme post-quantique.

Exploitation, attaques et limites de sécurité

ML-KEM ne protège pas les données déjà déchiffrées par le serveur, les journaux applicatifs, les exports analytiques ni les sauvegardes. Il ne protège pas non plus contre un serveur compromis qui lit les requêtes après terminaison TLS. La cryptographie de transport réduit la surface d’écoute, pas celle de l’application. La frontière de confiance doit rester documentée jusqu’au dernier point de déchiffrement.

Les clés ML-KEM de session sont éphémères dans TLS 1.3 et ne nécessitent pas de sauvegarde. Les clés de certificats, elles, restent des secrets de longue durée. Les conserver dans un HSM lorsque la politique de clé l’impose, contrôler les opérations de signature, journaliser les usages et tester la restauration des sauvegardes de configuration. Un HSM ne rend pas une signature ECDSA résistante au quantique ; il évite surtout que la clé sorte en balade dans un dump mémoire.

La rotation doit séparer trois objets : certificats, clés privées de certificats et configuration des groupes TLS. Changer un certificat n’active pas ML-KEM. Modifier les groupes TLS ne renouvelle pas un certificat. Cette distinction paraît triviale jusqu’à la première fenêtre de changement où tout le monde cherche le même bouton imaginaire.

Les attaques connues concernent aussi l’implémentation : erreurs de décapsulation, canaux auxiliaires de temps ou de cache, validation insuffisante des clés publiques, épuisement mémoire par de gros ClientHello et régression des équipements d’inspection TLS. Utiliser des bibliothèques maintenues, maintenir les correctifs cryptographiques, limiter la taille des requêtes entrantes et tester sous charge. Les algorithmes post-quantiques sont jeunes en production, pas en mathématiques : la différence compte.

🐝 Ce qui arrive si on s’en passe

Sans échange hybride, chaque session négociée reste une archive potentiellement lisible plus tard : la capture d’aujourd’hui ne peut pas être re-protégée rétroactivement, aucune rotation de certificat ni changement de version TLS n’annulant un flux déjà enregistré. L’absence de groupe post-quantique prive aussi d’un indicateur : sans métrique du groupe négocié, rien ne distingue une terminaison TLS modernisée d’une passerelle oubliée, et l’inventaire des points de déchiffrement (proxys, appliances, piles Java, agents) reste non testé. Les incompatibilités de taille de ClientHello et les middleboxes intolérants aux extensions inhabituelles se découvrent alors en urgence, au moment où la migration devient contrainte plutôt que planifiée. La confidentialité à horizon long des secrets industriels ou identifiants d’administration dépend d’un déploiement qui ne peut pas être rattrapé après coup.

🦫 Explication de la marmotte 🍫

Lorsqu’un navigateur contacte un serveur sécurisé, les deux côtés doivent fabriquer un secret temporaire commun. Ce secret sert ensuite à chiffrer les données échangées. Aujourd’hui, cette étape utilise souvent une méthode mathématique que les ordinateurs habituels ne savent pas casser dans un délai raisonnable. Un ordinateur quantique assez puissant pourrait cependant retrouver ce secret à partir d’un échange enregistré.

Le danger concerne donc les communications capturées maintenant. Un adversaire peut stocker ces captures sans les lire, puis les déchiffrer plus tard. Pour éviter cela, TLS peut ajouter une seconde méthode de création de secret, conçue pour résister aux calculs quantiques. Le navigateur et le serveur produisent alors deux secrets temporaires, un avec l’ancienne méthode et un avec la nouvelle. Le secret final dépend des deux.

Si l’ancienne méthode devient cassable par une machine quantique, la nouvelle continue de protéger la conversation. Si la nouvelle méthode présente un défaut découvert plus tard, l’ancienne conserve une protection contre les attaques actuelles. Cette double protection augmente la taille des premiers messages échangés et peut gêner des équipements trop anciens.

Les certificats servent à prouver l’identité du serveur et constituent un chantier distinct. Ils peuvent aussi employer de nouvelles signatures, mais celles-ci sont beaucoup plus volumineuses. La migration commence donc par protéger les échanges de secrets, mesurer les connexions réellement mises à niveau, puis traiter les certificats et les équipements qui bloquent encore.

Pages voisines

La citent

Intégrer la cryptographie post-quantique dans TLS

Elle cite

: les deux pages se citent l’une l’autre.

Intégrer la cryptographie post-quantique dans TLS

Intégrer la cryptographie post-quantique dans TLS

Store now, decrypt later : la dette de confidentialité

ML-KEM et ML-DSA : primitives NIST et coûts réels

Groupes hybrides TLS : la transition recommandée

Support TLS actuel et exemple OpenSSL

Exploitation, attaques et limites de sécurité

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines