Post-quantique sans big bang : migrer une flotte nœud par nœud

Une flotte de nœuds C2 (commandement et contrôle) ne se migre pas comme un parc de serveurs. Les nœuds sont déployés, parfois isolés, parfois hors de portée réseau pendant des semaines. Imposer une bascule cryptographique simultanée de toute la flotte crée une fenêtre de fragilité que personne ne sait dater. OC2-Edge traite la migration post-quantique autrement : des suites de signature auto-décrites, une politique d’exigence par nœud et un échange de clés hybride déjà actif sur le maillage. Cet article décrit le mécanisme, la limite assumée et l’alignement normatif.

La menace réelle : capturer aujourd’hui, déchiffrer demain

Le mécanisme de la menace quantique est connu ; seul son calendrier ne l’est pas. Un calculateur quantique cryptographiquement pertinent, dit CRQC (cryptographically relevant quantum computer), résoudrait les problèmes mathématiques qui fondent la cryptographie asymétrique actuelle : la factorisation pour RSA, le logarithme discret pour les courbes elliptiques. Aucune machine publique n’atteint ce seuil aujourd’hui.

L’attaque n’attend pourtant pas la machine. Dans le scénario « harvest now, decrypt later » (capturer maintenant, déchiffrer plus tard), un adversaire enregistre dès aujourd’hui le trafic chiffré qui l’intéresse, le stocke, puis le déchiffre le jour où un CRQC existe. La CISA (Cybersecurity and Infrastructure Security Agency), la NSA (National Security Agency) et le NIST (National Institute of Standards and Technology) décrivent ce scénario dans leur fiche commune de préparation quantique et recommandent d’engager la migration sans attendre la machine [6].

Ce scénario vise la confidentialité à long terme. Une position, un ordre d’opération ou un plan de fréquences capturés aujourd’hui peuvent conserver une valeur pendant des années : c’est la durée de vie du secret qui définit l’urgence, pas la date d’arrivée du CRQC. Le scénario ne vise pas l’authentification rétroactive. Une signature vérifiée aujourd’hui, pendant la session, authentifie cette session au moment où elle a lieu. Un adversaire qui casse la clé dans dix ans pourra forger de nouvelles signatures à ce moment-là ; il ne pourra pas revenir modifier ce qui a déjà été vérifié. Cette asymétrie ordonne la migration : l’échange de clés d’abord, les signatures selon la durée de vie des clés, l’authentification de session en dernier.

Trois suites de signature auto-décrites

OC2-Edge signe ses images système, ses modules et les métadonnées de son dépôt de mise à jour. Le format de signature ne présuppose aucun algorithme unique. Trois suites coexistent dans le code :

1. Ed25519 seul : la suite classique, spécifiée par la RFC 8032 [7], compacte et éprouvée ;
2. ML-DSA-65 seul : la suite post-quantique, normalisée par le NIST dans FIPS 204 [1] ;
3. hybride Ed25519 + ML-DSA-65 : deux signatures sur le même contenu, la vérification exigeant la validité des deux.

Chaque signature porte l’identifiant de sa suite. Le vérificateur lit cet identifiant avant toute opération cryptographique : il sait quelle suite a produit la signature, sans négociation préalable ni convention hors bande. Nous appelons cette propriété l’auto-description. Elle rend les artefacts durables : un module signé en début de migration reste vérifiable en fin de migration, quelle que soit la suite utilisée à la signature, tant que la politique du nœud vérificateur l’accepte.

La suite hybride couvre deux risques symétriques. ML-DSA-65 repose sur des hypothèses de réseaux euclidiens plus récentes que celles d’Ed25519, et ses implémentations sont jeunes. Ed25519, à l’inverse, tombera face à un CRQC. Une signature hybride reste sûre tant que l’une des deux composantes tient. L’ANSSI (Agence nationale de la sécurité des systèmes d’information) recommande cette hybridation pour toute la période de transition [4].

Une politique graduée : le durcissement nœud par nœud

La coexistence de suites ne signifie pas l’absence d’exigence. Chaque nœud applique une politique locale qui définit les suites acceptées à la vérification. La politique se durcit par crans :

1. accepter les trois suites : l’état initial, compatible avec tout l’existant ;
2. exiger une composante post-quantique : le nœud refuse une signature Ed25519 seule, accepte l’hybride et ML-DSA-65 seul ;
3. refuser toute suite purement classique : le nœud n’accepte plus que l’hybride ou ML-DSA-65 seul, selon la configuration.

Le passage d’un cran au suivant se décide et se déploie nœud par nœud. Un nœud durci refuse les artefacts sous son seuil et continue de vérifier ceux au-dessus. Les signataires publient en hybride dès que possible : leurs artefacts satisfont tous les crans à la fois. Il n’existe donc ni jour J, ni fenêtre où la flotte entière devrait être re-signée simultanément, ni état intermédiaire où un nœud ne saurait plus vérifier ses pairs. Une flotte hétérogène, avec des nœuds récents et des nœuds isolés mis à jour tardivement, reste opérable pendant toute la transition. C’est ce que nous entendons par migration sans big bang.

Le KEM hybride X25519MLKEM768 sur le maillage

La confidentialité, cible directe de « harvest now, decrypt later », ne peut pas attendre les crans de signature. Sur le maillage, OC2-Edge établit ses sessions avec le KEM (mécanisme d’encapsulation de clé) hybride X25519MLKEM768 : un échange X25519 classique et une encapsulation ML-KEM-768, normalisée dans FIPS 203 [2], combinés pour TLS (Transport Layer Security) 1.3 selon le draft de l’IETF [5]. Le secret de session dérive des deux échanges. Un adversaire qui enregistre le trafic aujourd’hui devra casser à la fois X25519 et ML-KEM-768 pour le déchiffrer demain. La protection contre la capture différée est donc effective dès maintenant, indépendamment de l’avancement des crans de signature de la flotte.

La limite dite : l’authentification de session TLS reste classique

L’authentification des sessions TLS du maillage, certificats et signature du handshake, reste classique : Ed25519 ou ECDSA. C’est un choix documenté, pas un angle mort, et il est rationnel aujourd’hui pour trois raisons.

1. La menace différée ne s’applique pas à cette fonction. L’authentification est une propriété du moment de la session : un CRQC futur ne falsifie pas rétroactivement un handshake déjà vérifié. La confidentialité de ces mêmes sessions est, elle, déjà protégée par le KEM hybride.
2. Le coût est immédiat et mesurable. Une signature ML-DSA-65 occupe 3309 octets, contre 64 octets pour Ed25519 [1] [7]. Sur des liaisons radio contraintes, alourdir chaque handshake se paie à chaque établissement de session.
3. L’écosystème des certificats post-quantiques n’est pas stabilisé. Le jour où il l’est, la mécanique existe déjà : les certificats rejoindront le même schéma de suites auto-décrites et de crans que les signatures d’artefacts.

Le risque résiduel est borné : il concerne un adversaire disposant d’un CRQC au moment même de la session, capable d’usurper une identité en temps réel, un scénario postérieur à celui de la capture différée. Ce point est suivi comme point ouvert dans PQC_MIGRATION.md.

Alignement : FIPS 204, FIPS 203, CNSA 2.0, ANSSI

Les choix d’OC2-Edge s’adossent à des références publiques.

• FIPS 204 normalise ML-DSA, la signature retenue [1]. FIPS 203 normalise ML-KEM, la composante post-quantique du KEM [2].
• CNSA 2.0, la suite d’algorithmes imposée par la NSA aux systèmes de sécurité nationale américains, prescrit la transition post-quantique avec un calendrier qui s’étend jusqu’à l’usage exclusif d’algorithmes post-quantiques en 2033 [3]. CNSA 2.0 retient ML-DSA-87 ; OC2-Edge retient ML-DSA-65, catégorie de sécurité 3 du NIST [1], un compromis entre marge de sécurité et taille des signatures sur liaisons contraintes. L’écart est assumé et documenté.
• L’ANSSI recommande l’hybridation systématique pendant la transition et demande aux organisations d’inventorier leurs usages cryptographiques avant de migrer [4]. La politique graduée fournit cet inventaire en pratique : chaque nœud déclare son cran, et l’état de migration de la flotte se lit au lieu de s’estimer.

Vérifier sur le dépôt

Le document PQC_MIGRATION.md du dépôt décrit les trois suites, l’identifiant de suite porté par chaque signature, les crans de politique et les points ouverts, dont l’authentification TLS. Le dépôt public, sous licence Apache-2.0, compte ~930 tests automatisés au vert. La lecture du document, puis du code, suffit à confronter cet article à ce qui est réellement implémenté.

Sources

1. NIST, « FIPS 204 : Module-Lattice-Based Digital Signature Standard », 2024, https://csrc.nist.gov/pubs/fips/204/final
2. NIST, « FIPS 203 : Module-Lattice-Based Key-Encapsulation Mechanism Standard », 2024, https://csrc.nist.gov/pubs/fips/203/final
3. NSA, « Announcing the Commercial National Security Algorithm Suite 2.0 », 2022, https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF
4. ANSSI, « Avis de l’ANSSI sur la migration vers la cryptographie post-quantique », 2022, complété en 2023, https://cyber.gouv.fr/publications/avis-de-lanssi-sur-la-migration-vers-la-cryptographie-post-quantique-0
5. IETF, groupe de travail TLS, « Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3 », draft-ietf-tls-ecdhe-mlkem, 2026, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
6. CISA, NSA et NIST, « Quantum-Readiness : Migration to Post-Quantum Cryptography », 2023, https://media.defense.gov/2023/Aug/21/2003284212/-1/-1/0/CSI-QUANTUM-READINESS.PDF
7. IETF, « RFC 8032 : Edwards-Curve Digital Signature Algorithm (EdDSA) », 2017, https://datatracker.ietf.org/doc/html/rfc8032