PQC StatusSur un VPN, la partie exposée à un futur attaquant quantique est l'échange de clés, et non le chiffrement des données. Pour IPsec, deux mécanismes IETF publiés sont utilisables dès aujourd'hui : la RFC 9370, qui permet à IKEv2 de négocier des échanges de clés supplémentaires afin qu'un KEM (mécanisme d'encapsulation de clé) post-quantique s'exécute aux côtés d'un groupe classique, et la RFC 8784, qui intègre une clé prépartagée post-quantique dans la dérivation de clés d'IKEv2. Le protocole WireGuard ne comporte lui-même aucun échange de clés post-quantique : sa clé symétrique prépartagée optionnelle de 32 octets est donc le seul levier disponible au sein du protocole.
Pourquoi l'échange de clés passe en premier
Un tunnel IPsec comporte deux couches. ESP (Encapsulating Security Payload) protège les données avec un algorithme symétrique, généralement AES-256-GCM. Les algorithmes symétriques et les fonctions de hachage ne sont pas cassés par l'algorithme de Shor, et l'algorithme de Grover explique pourquoi AES-256 est privilégié pour une protection à long terme. La couche IKE (Internet Key Exchange) est différente : IKEv2, tel que publié dans la RFC 7296, dérive ses clés d'un échange Diffie-Hellman, or le Diffie-Hellman sur courbes elliptiques et le Diffie-Hellman sur corps finis sont cassés par l'algorithme de Shor sur un ordinateur quantique suffisamment puissant, quelle que soit la taille du groupe.
Cela compte dès maintenant en raison de la menace « récolter maintenant, déchiffrer plus tard » (HNDL) : un attaquant qui enregistre aujourd'hui le trafic chiffré d'un tunnel n'a besoin que de voir tomber l'échange de clés plus tard pour le lire. Les tunnels site à site transportant des données dont la durée de confidentialité est longue (dossiers médicaux, documents juridiques, plans industriels, données de paiement) en sont l'exemple le plus net. L'authentification est une question distincte. L'authentification des pairs IKEv2 par certificats RSA ou ECDSA ne doit résister qu'à un attaquant présent au moment de la négociation : les signatures peuvent donc migrer après l'échange de clés, mais elles doivent bel et bien migrer.
Les trois mécanismes disponibles aujourd'hui
| Mécanisme | Spécification | Ce qu'il change | Ce qu'il exige |
|---|---|---|---|
| Échanges de clés supplémentaires IKEv2 | RFC 9370, via l'échange IKE_INTERMEDIATE de la RFC 9242 | Un KEM post-quantique est négocié dans le protocole, en plus du groupe classique | Prise en charge par les deux pairs, une méthode d'échange de clés enregistrée pour le KEM, la fragmentation IKEv2 |
| Intégration d'une clé prépartagée post-quantique (PPK) | RFC 8784 | Un secret à forte entropie est intégré à la dérivation de clés IKEv2, de sorte qu'un échange enregistré ne suffit pas | Distribution hors bande, stockage et renouvellement d'une PPK par paire de pairs |
| Clé prépartagée WireGuard | Documentation du protocole WireGuard (option PresharedKey) | Une clé symétrique de 32 octets est intégrée à la clé de chaînage de la négociation | Distribution hors bande par paire de pairs, aucune négociation dans le protocole |
| Protection de la charge utile ESP | AES-256-GCM | Rien : déjà hors de portée de l'algorithme de Shor | Privilégier AES-256 pour une protection à long terme |
RFC 9370 : échanges de clés supplémentaires dans IKEv2
IKEv2 de base négocie exactement une méthode d'échange de clés, dans l'échange IKE_SA_INIT. La RFC 9370 ajoute jusqu'à sept types de transformation d'échange de clés supplémentaires (notés couramment ADDKE1 à ADDKE7), négociés dans la même proposition puis exécutés dans un ou plusieurs échanges IKE_INTERMEDIATE, le type d'échange défini par la RFC 9242. Les secrets partagés obtenus sont combinés dans le matériel de clé de la SA IKE : conserver un groupe classique comme premier échange de clés et ajouter un KEM en ADDKE1 produit donc un schéma hybride, qu'un attaquant doit casser des deux côtés. L'hybridation est ce que recommandent l'ANSSI et le BSI, et c'est le choix prudent tant que les implémentations post-quantiques sont jeunes.
Le KEM à demander est ML-KEM, normalisé par le NIST dans FIPS 203 le 13 août 2024. ML-KEM-768 est le jeu de paramètres intermédiaire courant ; CNSA 2.0 exige ML-KEM-1024. La liste de référence des identifiants de méthodes d'échange de clés IKEv2 est le registre IANA des paramètres IKEv2, et les travaux de spécification de ML-KEM pour IKEv2 sont menés au sein du groupe de travail IETF IPSECME : consultez donc le registre et la documentation de votre implémentation plutôt que de vous fier à un numéro de transformation cité dans un article.
Deux conséquences opérationnelles. D'abord, les clés publiques et les chiffrés ML-KEM sont bien plus volumineux qu'un point de courbe elliptique : la fragmentation des messages IKEv2 (RFC 7383) devrait donc être activée. L'une des raisons pour lesquelles la RFC 9370 utilise IKE_INTERMEDIATE est que ces échanges peuvent être fragmentés, contrairement à IKE_SA_INIT. Ensuite, la syntaxe des propositions diffère selon les implémentations et les versions, et l'orthographe du mot-clé désignant un échange de clés supplémentaire post-quantique n'est pas portable. Vérifiez-la dans la documentation de votre version exacte :
# Illustrative shape only, not a portable configuration line.
# Order: encryption - integrity/PRF - classical group - additional key exchange 1
# aes256gcm16 - prfsha384 - <classical group> - <ML-KEM as ADDKE1>
# The keyword for the additional key exchange depends on the implementation
# and its version. Take it from that version's documentation.Des vérifications en lecture seule sur une passerelle Linux, avant et après une modification, montrent ce que le noyau a réellement installé :
# List the IPsec security associations and the ESP algorithms in use
ip -s xfrm state
# Show the installed IPsec policies
ip xfrm policyTestez d'abord en préproduction, avec les pairs que vous utilisez réellement, et conservez une proposition purement classique comme solution de repli documentée jusqu'à ce que tous les pairs aient migré.
RFC 8784 : intégrer une clé prépartagée post-quantique
La RFC 8784 emprunte une autre voie. L'initiateur signale sa prise en charge par une notification USE_PPK, et une clé prépartagée post-quantique, identifiée par un PPK_ID, est intégrée à la dérivation de clés de la SA IKE. Un attaquant qui enregistre l'échange puis casse plus tard la partie Diffie-Hellman ne peut toujours pas dériver les clés de session sans la PPK. Son intérêt tient précisément au fait qu'elle ne requiert aucun nouvel algorithme asymétrique : de nombreuses piles IKEv2 déployées en sont capables.
Ses limites sont opérationnelles plutôt que cryptographiques. La PPK doit présenter une véritable entropie et être générée par une source aléatoire appropriée, et non saisie par un humain. Elle doit être distribuée, stockée et renouvelée hors bande, par paire de pairs, ce qui constitue la difficulté à grande échelle. Elle ne rend pas l'authentification des pairs post-quantique. Enfin, la RFC 8784 permet de rendre la PPK obligatoire ou optionnelle : si elle est optionnelle, un pair qui n'envoie pas USE_PPK obtient simplement une SA classique. Lorsque les deux extrémités la prennent en charge, configurez-la comme obligatoire, et journalisez les pairs ayant négocié une PPK afin de pouvoir prouver la couverture plutôt que de la supposer.
WireGuard aujourd'hui
La négociation de WireGuard repose sur Curve25519 : l'échange de clés est donc vulnérable au quantique, de la même manière qu'IKEv2 avec un groupe classique. Le protocole ne possède, par conception, ni couche de négociation ni agilité algorithmique : il n'existe donc aucun échange de clés post-quantique à activer. Ce qui existe, c'est la clé symétrique prépartagée optionnelle, intégrée à la négociation, que la documentation du protocole WireGuard présente comme une atténuation face à un attaquant qui enregistre le trafic maintenant et s'attaque aux clés publiques plus tard.
# Generate one 32 byte pre-shared key per peer pair
wg genpsk
# In a wg-quick configuration file, add it to the peer section
# [Peer]
# PublicKey = <peer public key>
# PresharedKey = <output of wg genpsk>
# AllowedIPs = 10.0.0.2/32Traitez le résultat comme un secret doté d'un cycle de vie : unique par paire, transmis par un canal de confiance, renouvelé et consigné dans votre inventaire de clés. Certains projets exécutent un démon externe qui effectue séparément un échange de clés post-quantique et actualise périodiquement la valeur PresharedKey (Rosenpass est un exemple open source de ce modèle). WireGuard reste ainsi inchangé, au prix d'un composant supplémentaire à déployer, surveiller et auditer. Si vous avez besoin d'une négociation dans le protocole d'un KEM normalisé, IPsec avec la RFC 9370 est la voie qui existe aujourd'hui.
Ce qu'il faut demander à vos fournisseurs de VPN
| Question | Pourquoi c'est important |
|---|---|
| Quelles méthodes d'échange de clés post-quantiques l'implémentation IKE prend-elle en charge, dans quelle version de firmware, et sous quels identifiants de méthode d'échange de clés IANA ? | Transforme un argument marketing en élément vérifiable et consignable |
| Implémentez-vous la RFC 9370 avec la RFC 9242, la RFC 8784, ou les deux ? | Un KEM hybride négocié dans le protocole et l'intégration manuelle d'une PPK répondent au problème différemment |
| L'échange de clés est-il hybride, et avec quel jeu de paramètres ML-KEM ? | L'hybridation est la posture recommandée ; CNSA 2.0 exige ML-KEM-1024 |
| L'implémentation est-elle validée au regard de FIPS 203, ou utilise-t-elle un module validé ? | Exigé par certains régimes d'achat et d'audit |
| La fragmentation IKEv2 est-elle activée, et quel est l'effet mesuré sur la fréquence de renouvellement des clés, la charge CPU et le temps d'établissement des tunnels ? | Des charges utiles KEM plus volumineuses modifient la taille des paquets IKE et la charge des passerelles |
| Que se passe-t-il lorsqu'un pair ne prend pas en charge l'échange post-quantique, et cela peut-il être journalisé ou déclencher une alerte ? | Vous avez besoin de visibilité sur tout repli silencieux vers une SA purement classique |
| Quels tests d'interopérabilité ont été réalisés avec les pairs précis que nous utilisons (passerelles cloud, équipements de partenaires, clients d'accès distant) ? | C'est sur l'interopérabilité d'IKEv2 hybride que les déploiements achoppent |
| Quelle est la feuille de route pour l'authentification post-quantique des pairs (certificats ML-DSA) ? | L'échange de clés d'abord, les signatures ensuite, mais les deux sont nécessaires |
| Le matériel actuel en bénéficiera-t-il, ou seulement la prochaine génération ? | Des accélérateurs cryptographiques dimensionnés pour les courbes elliptiques pourraient ne pas prendre en charge ML-KEM |
| Quels éléments écrits fournirez-vous : notes de version, rapports de test, configuration prise en charge ? | C'est ce qui alimente votre inventaire cryptographique |
Les échéances applicables aux équipements réseau
Les passerelles VPN sont explicitement mentionnées dans un calendrier. CNSA 2.0 de la NSA, qui s'applique aux National Security Systems américains, fixe l'usage exclusif de son jeu d'algorithmes (dont ML-KEM-1024) d'ici fin 2030 pour la signature de logiciels et de firmwares ainsi que pour les équipements réseau traditionnels, et d'ici fin 2033 pour les navigateurs et serveurs web, les services cloud, les systèmes d'exploitation et les équipements de niche. Les équipements réseau font partie du premier groupe.
Ailleurs, la BSI TR-02102-1 (version 2026-01, publiée le 23 janvier 2026) recommande un accord de clés post-quantique hybride et ne considère l'accord de clés classique utilisé seul comme acceptable que jusqu'à fin 2031, ou fin 2030 pour les besoins de protection très élevés ; il s'agit d'une ligne directrice technique, non d'une réglementation. L'ANSSI rend l'hybridation obligatoire dans son périmètre réglementé (qualification de produits, Diffusion Restreinte, SAIV et SIIV) et précise que ses recommandations post-quantiques ne constituent pas encore des obligations réglementaires en dehors de ce périmètre (FAQ PQC de l'ANSSI). La feuille de route de mise en œuvre coordonnée de l'UE v1.1 (23 juin 2025) demande des inventaires cryptographiques et des feuilles de route nationales d'ici fin 2026, ainsi que la migration des cas d'usage à haut risque d'ici fin 2030 ; il s'agit d'orientations coordonnées destinées aux États membres, non d'une réglementation contraignante pour les entreprises. Au Royaume-Uni, le NCSC (20 mars 2025) attend un recensement et un plan initial d'ici 2028, les migrations les plus prioritaires d'ici 2031 et un achèvement d'ici 2035. NIST IR 8547 reste un projet public initial : il propose de déprécier après 2030 les algorithmes offrant une sécurité de 112 bits, comme RSA-2048, et d'interdire après 2035 tous les algorithmes à clé publique vulnérables au quantique.
Notre lecture, proposée à titre d'interprétation et non de conseil juridique : un tunnel site à site de longue durée transportant des données réglementées correspond au type de cas d'usage à haut risque que ces calendriers visent en priorité, ce qui place le parc VPN en tête de file, même lorsque le texte relève de la recommandation plutôt que de l'obligation.
Prochaine étape
Commencez par l'inventaire, car c'est ce que demande chacun de ces textes : recensez chaque tunnel, la version d'IKE, le groupe d'échange de clés négocié, les algorithmes ESP, la méthode d'authentification et la durée de confidentialité des données transportées. Choisissez ensuite un tunnel à faible risque entre deux pairs que vous maîtrisez et testez une proposition hybride en préproduction, en conservant un repli classique.
PQC Status teste TLS, et non IKEv2 : il ne vous indiquera donc pas ce que votre passerelle négocie sur les ports UDP 500 et 4500. Il reste toutefois le moyen le plus rapide de vérifier tout ce qu'un parc VPN expose en HTTPS : portails web des équipements, frontaux SSL-VPN, interfaces d'administration et d'enrôlement. Lancez une analyse gratuite de ces noms d'hôte avec PQC Status pour savoir s'ils proposent déjà un échange de clés hybride ML-KEM, puis adressez les questions ci-dessus au fournisseur de chaque passerelle.