Préparer son infrastructure à la cryptographie post-quantique

En bref

#

• Le risque post-quantique n’est pas immédiat, mais le scénario Harvest Now, Decrypt Later est déjà réaliste.
• Les données à longue durée de vie (backups, secrets, archives) sont les premières concernées.
• La stratégie actuelle est l’hybridation : garder une protection classique tout en ajoutant une protection post-quantique.
• OpenSSH supporte déjà des mécanismes hybrides modernes (ML-KEM).
• Le vrai défi est opérationnel : compatibilité, MTU, performances et migration progressive.

Un backup de coffre-fort, une capture VPN, un dump de base de données, une archive Git privée : ce sont des données qui peuvent rester sensibles longtemps après leur création. C’est là que le sujet post-quantique devient concret pour l’infra.

Le problème n’est pas qu’un ordinateur quantique va casser vos accès demain matin. Le vrai sujet, c’est que certaines données capturées aujourd’hui peuvent garder de la valeur pendant dix ou vingt ans, surtout quand elles sont protégées par des mécanismes asymétriques classiques.

Le risque Harvest Now, Decrypt Later

#

On entend souvent : “Un ordinateur quantique capable de briser le RSA, ça n’existe pas encore.” C’est vrai. Mais l’attaque “Harvest Now, Decrypt Later” (ou “Store Now, Decrypt Later”) est une menace réelle et actuelle.

Imaginez un scénario classique : un acteur malveillant (ou une agence de renseignement) intercepte et enregistre aujourd’hui tout le trafic chiffré de votre VPN, de vos sessions SSH, ou de vos accès cloud. Pour l’instant, ce flux de données n’est qu’un bruit inutile, un amas de bits illisibles. Mais si vos fichiers protégés (configurations de production, secrets industriels, données de santé, backups de coffre-forts) doivent rester confidentiels pendant 10 ou 20 ans, le danger est déjà là.

Si, dans dix ou quinze ans, le matériel quantique devient capable de casser RSA/ECC à grande échelle, ces archives de trafic “capturé” pourront être déchiffrées. Vos secrets de 2024 deviendront les vulnérabilités de 2040. Pour un administrateur qui gère des données de longue durée, la sécurité post-quantique n’est pas une option futuriste. C’est une question de gestion du risque, de confidentialité à long terme, et de préparation progressive face à des exigences réglementaires qui tendent à se durcir.

Le défi de la cryptographie post-quantique (PQC) n’est pas de comprendre les réseaux de modules ou le problème Learning With Errors (LWE). Le vrai défi, pour une équipe infra, est plus banal et plus important : intégrer de nouveaux algorithmes sans casser la compatibilité, sans dégrader les performances, et surtout sans provoquer des incidents de production.

Pourquoi l’hybridation est l’approche actuelle

#

Le remplacement brutal de l’ECC ou du RSA par des algorithmes post-quantiques serait une approche risquée. Les nouveaux algorithmes (comme ML-KEM, anciennement Kyber) sont récents. S’ils s’avéraient présenter une faille mathématique majeure dans deux ans, toute votre infrastructure serait vulnérable.

C’est pourquoi la communauté s’est accordée sur une approche pragmatique : l’hybridation. Elle ne rend pas une architecture magique, mais elle évite de remplacer brutalement une primitive éprouvée par une primitive plus récente.

L’idée est de combiner deux mécanismes de partage de clés dans un même “handshake” :

1. Un mécanisme classique (ex: X25519) : Il garantit que votre sécurité ne descend pas en dessous de ce que vous avez aujourd’hui. Si le nouvel algorithme échoue, le vieux protocole assure la protection.
2. Un mécanisme post-quantique (ex: ML-KEM) : Il apporte la barrière supplémentaire contre l’ordinateur quantique.

Exemple pratique avec OpenSSH

#

Si vous utilisez OpenSSH, ces mécanismes existent déjà dans les versions récentes. Depuis OpenSSH 9.0, des échanges de clés hybrides post-quantiques sont progressivement introduits et étendus.

Initialement, OpenSSH a introduit sntrup761x25519-sha512@openssh.com (Streamlined NTRU Prime + X25519). Depuis OpenSSH 9.9, mlkem768x25519-sha256 est également disponible, et OpenSSH 10.0 l’utilise par défaut pour l’échange de clés. Cet algorithme repose sur ML-KEM, standardisé par le NIST sous le nom FIPS 203.

Pour vérifier quels algorithmes hybrides sont disponibles sur votre système :

# Lister les KEX supportés, filtrer les implémentations post-quantiques
ssh -Q kex | grep -Ei "mlkem|sntrup"

Si mlkem768x25519-sha256 apparaît, vous pouvez forcer son utilisation pour tester :

# Tester une connexion avec l'algorithme hybride ML-KEM + X25519
ssh -o KexAlgorithms=mlkem768x25519-sha256 user@remote-host

En tant qu’admin, vérifiez quels algorithmes sont réellement négociés lors de vos sessions critiques. Ici, on parle bien du Key Exchange SSH, pas des clés d’authentification utilisateur comme RSA ou Ed25519. Si vous voyez toujours uniquement ecdh-sha2-nistp256 ou diffie-hellman-group14-sha1 dans vos traces de connexion, vous êtes en zone à moderniser.

Impact opérationnel : taille des handshakes et MTU

#

Attention, ce changement n’est pas gratuit. Passer à de la cryptographie post-quantique a un coût technique à anticiper : la taille des données.

Les clés, les signatures et certains messages post-quantiques sont plus volumineux que leurs équivalents ECC. Un échange elliptique comme X25519 tient dans quelques dizaines d’octets. Un échange hybride avec ML-KEM ajoute des données qui peuvent faire passer le handshake à plusieurs kilo-octets.

Le risque pour vos réseaux ? La fragmentation IP.

Si vos tunnels VPN (WireGuard, IPsec) ou vos flux TLS passent par des liens avec une MTU (Maximum Transmission Unit) restreinte (par exemple via du PPPoE ou de l’encapsulation cloud), l’augmentation de la taille des paquets de handshake peut entraîner :

• Des paquets de handshake plus gros que prévu.
• Des problèmes de Path MTU Discovery sur les réseaux où l’ICMP est filtré.
• Le rejet de fragments par certains pare-feu ou équipements intermédiaires.
• Des timeouts difficiles à diagnostiquer : le handshake commence, puis la session n’aboutit jamais.

À vérifier avant déploiement : avant de déployer massivement des protocoles hybrides sur un réseau complexe, vérifiez la robustesse de votre gestion de la fragmentation et, si nécessaire, baissez légèrement la MTU de vos interfaces de tunnel pour laisser de la place aux nouveaux payloads.

Un point à ne pas mélanger avec RSA/ECC : le chiffrement symétrique ne casse pas de la même manière. Shor vise surtout les problèmes mathématiques utilisés par RSA et les courbes elliptiques. Grover peut réduire théoriquement la marge de sécurité d’un chiffrement symétrique, mais AES-256 garde une marge confortable. En pratique, le risque prioritaire reste souvent l’asymétrique qui protège les clés, les sessions ou les archives.

Audit post-quantique de l’infrastructure

#

Comment savoir si votre infrastructure est prête ? Voici un tableau d’audit pour vos services les plus critiques. L’idée est de hiérarchiser vos actions par niveau de risque.

La lecture utile est simple : P0/P1 pour ce qui protège des données longues durées ou des accès d’administration, P2/P3 pour ce qui dépend surtout du support des outils et des bibliothèques.

Automatiser l’audit

#

Ne faites pas cet audit à la main pour chaque serveur. Utilisez les outils que vous utilisez déjà pour vos scans de vulnérabilités.

Scanner vos serveurs Web (Nginx/Caddy)

#

Vous pouvez utiliser nmap et openssl pour vérifier ce que votre proxy TLS expose réellement aujourd’hui.

# Lister les versions TLS et suites de chiffrement visibles depuis l'extérieur
nmap --script ssl-enum-ciphers -p 443 votre-service.com

# Vérifier le certificat, la version TLS 1.3 et les paramètres négociés
openssl s_client -connect votre-service.com:443 -servername votre-service.com -tls1_3 </dev/null

Regardez au minimum :

• la version TLS négociée ;
• l’algorithme de signature du certificat ;
• les suites de chiffrement encore acceptées ;
• la présence de TLS 1.0/1.1 ou de suites faibles.

Aujourd’hui, l’objectif réaliste n’est pas de “forcer du post-quantique” sur Nginx en production. Il est d’abord de supprimer l’ancien, de garder TLS 1.3 propre, puis de suivre le support des groupes hybrides dans OpenSSL, BoringSSL, nginx, Caddy et vos CDN.

Sur un parc réel, cette étape vaut déjà le temps passé. Un proxy encore ouvert à TLS 1.0 ou à des suites faibles est un problème plus immédiat qu’un manque de ML-KEM.

Scanner vos accès SSH

#

Utilisez ssh-audit, ssh -Q kex ou une inspection manuelle de la configuration pour vérifier la présence d’algorithmes de Key Exchange modernes et hybrides.

Commandes d’audit rapide

#

Quelques commandes concrètes pour prendre le pouls de votre infrastructure :

# Vérifier la version d'OpenSSH installée
ssh -V

# Voir les algorithmes KEX réellement négociés lors d'une connexion
ssh -vv user@host 2>&1 | grep kex

ssh -V vous indique la version du client et donc les familles d’algorithmes susceptibles d’être disponibles. ssh -vv avec le grep sur kex révèle quel algorithme de Key Exchange a été choisi lors du handshake — utile pour vérifier que l’hybridation est bien négociée et non contournée.

Forcer l’hybridation côté serveur ou client

#

Pour désactiver explicitement les KEX legacy et forcer l’hybridation, vous pouvez restreindre la liste dans sshd_config (serveur) ou ssh_config (client) :

# sshd_config — forcer uniquement les algorithmes hybrides
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com

# ssh_config — même politique côté client
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com

Appliquez avec systemctl reload sshd, puis testez immédiatement depuis une session parallèle pour éviter de vous retrouver verrouillé à l’extérieur si le serveur ne supporte pas les algorithmes imposés. À déployer d’abord sur un sous-ensemble de serveurs, jamais en masse.

C’est le genre de changement à tester sur une machine de bord ou un serveur non critique avant de toucher au bastion principal. La crypto post-quantique ne sert à rien si la première conséquence est de perdre l’accès d’administration.

Rotation de clés et durée de vie dans un contexte post-quantique

#

Le post-quantique impose aussi de repenser la durée de vie des clés asymétriques. Une clé RSA-4096 ou Ed25519 émise aujourd’hui ne sera pas protégée contre l’algorithme de Shor demain. Pour les artefacts sensibles, visez une rotation annuelle des clés de chiffrement et une expiration des certificats de l’ordre de 6 à 12 mois — voire 30 jours pour les workloads cloud éphémères. Cela limite la fenêtre d’exposition effective si l’infrastructure n’est pas encore migrée vers l’hybridation et réduit la valeur des archives récupérées par un attaquant.

Erreurs à éviter

#

La migration post-quantique doit rester progressive. Quelques erreurs classiques peuvent créer plus d’incidents qu’elles n’en résolvent :

• Forcer ML-KEM partout sans vérifier la version des clients, des serveurs et des middleboxes.
• Supprimer tous les algorithmes de repli SSH avant d’avoir testé une session parallèle.
• Confondre chiffrement symétrique et asymétrique : AES-256 n’est pas cassé par Shor comme RSA ou ECC, même si Grover réduit théoriquement sa marge.
• Lancer une migration globale sans inventaire des certificats, clés SSH, archives, VPN et dépendances TLS.
• Oublier les sauvegardes anciennes : ce sont souvent elles qui gardent le plus longtemps des secrets protégés par de vieilles clés.

Conclusion

#

La transition post-quantique ne demande pas de devenir un expert en mathématiques. Elle demande surtout de savoir où la cryptographie asymétrique est utilisée, combien de temps les données doivent rester confidentielles, et quels composants peuvent être mis à jour sans casser la production.

Commencez par les sauvegardes, les accès d’administration, les certificats et les tunnels. Le reste peut suivre progressivement, au rythme du support réel dans les clients, les bibliothèques TLS et les équipements réseau. C’est moins spectaculaire qu’une migration globale, mais beaucoup plus proche de la manière dont une infra tient réellement dans le temps.

Sources

#

• NIST Post-Quantum Cryptography Standardization
• NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
• OpenSSH Release Notes (9.0 / 10.0)
• OpenSSH: Post-Quantum Cryptography
• CISA: Quantum-Readiness, Migration to Post-Quantum Cryptography
• IETF draft on hybrid ML-KEM key exchange for SSH