Conformité CNSA 2.0 pour les organisations de défense : feuille de route de migration

En septembre 2022, la Direction de la cybersécurité de la NSA a publié la Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) — une directive exigeant que tous les systèmes de sécurité nationale (NSS) passent de la cryptographie à clé publique classique aux algorithmes post-quantiques selon un calendrier défini. Pour les organisations de défense, il ne s'agit pas d'une question de recherche ni d'un élément de planification future : les exigences d'approvisionnement intègrent déjà des critères de conformité CNSA 2.0, et les nouveaux systèmes déployés à partir de 2025 sont censés prendre en charge les algorithmes mandatés dès le premier jour.

Le défi de la migration est considérable. La cryptographie à clé publique classique — RSA, la cryptographie sur courbes elliptiques (ECC) et Diffie-Hellman — est intégrée dans toute l'infrastructure informatique de défense : points de terminaison TLS, passerelles VPN, autorités de certification PKI, systèmes de gestion des clés, pipelines de signature de firmware et archives de données chiffrées. Remplacer ces dépendances dans une grande organisation est un programme pluriannuel exigeant un séquençage minutieux, une coordination avec les fournisseurs et une gestion des risques pendant la période où les systèmes classiques et post-quantiques doivent interopérer.

Cet article présente une feuille de route de migration pratique : ce que CNSA 2.0 exige, quels algorithmes remplacent lesquels, comment séquencer la transition dans une organisation de défense et ce qu'il faut exiger des fournisseurs proposant des systèmes compatibles CNSA 2.0.

Ce que CNSA 2.0 exige et pourquoi

La menace cryptographique à l'origine de CNSA 2.0 est l'algorithme de Shor — un algorithme quantique qui, lorsqu'il est exécuté sur un ordinateur quantique suffisamment grand, résout les problèmes mathématiques sous-jacents à RSA (factorisation des entiers), ECC (logarithme discret sur courbe elliptique) et Diffie-Hellman (logarithme discret). Un ordinateur quantique capable d'exécuter l'algorithme de Shor contre RSA-2048 ou ECC-256 bits nécessiterait des millions de qubits logiques fonctionnant avec de faibles taux d'erreur. Cette capacité n'existe pas aujourd'hui, mais des estimations publiques crédibles situent un « ordinateur quantique cryptographiquement pertinent » (CRQC) quelque part dans la fenêtre 2030–2035.

La menace « collecter maintenant, déchiffrer plus tard » (HNDL) réduit ce délai pour les besoins de la défense. Les adversaires qui collectent aujourd'hui du trafic chiffré — communications stratégiques, rapports de renseignement, évaluations de capacités — peuvent le stocker et le déchiffrer une fois qu'un CRQC sera disponible. La confidentialité des données chiffrées aujourd'hui avec des algorithmes classiques a donc une date d'expiration effective corrélée à la disponibilité du CRQC. Pour les données dont les exigences de confidentialité se mesurent en décennies, cette expiration est déjà une préoccupation opérationnelle présente.

CNSA 2.0 répond à cela en mandatant un ensemble spécifique d'algorithmes post-quantiques pour les NSS, avec un calendrier de transition conçu pour garantir que la migration soit achevée avant la disponibilité du CRQC. Les mandats clés :

• ML-KEM (FIPS 203 / CRYSTALS-Kyber) — remplace RSA et ECDH pour tout établissement de clés. CNSA 2.0 mandate ML-KEM-1024 (le jeu de paramètres de sécurité le plus élevé) pour les applications NSS.
• ML-DSA (FIPS 204 / CRYSTALS-Dilithium) — remplace RSA-PSS et ECDSA pour les signatures numériques dans la plupart des applications. Offre une signature et une vérification rapides avec des tailles de clés et de signatures raisonnables.
• SLH-DSA (FIPS 205 / SPHINCS+) — un algorithme de signature alternatif basé sur des fonctions de hachage plutôt que sur des mathématiques de réseaux. Utilisé lorsqu'une diversité par rapport aux algorithmes basés sur les réseaux est requise, ou lorsque ces derniers ne sont pas autorisés. Les signatures sont significativement plus grandes que ML-DSA, mais la sécurité repose sur des propriétés de fonctions de hachage bien comprises.
• LMS et XMSS — schémas de signature à base de hachage avec état approuvés pour des cas d'usage spécifiques, notamment la signature de firmware dans des environnements contraints. Requièrent une gestion soigneuse de l'état pour éviter la réutilisation des clés.
• AES-256 et SHA-384 — conservés de CNSA 1.0 pour le chiffrement symétrique et le hachage ; ceux-ci ne sont pas menacés par les ordinateurs quantiques à une échelle pratique.

Les algorithmes dépréciés qui doivent être supprimés progressivement dans le cadre de CNSA 2.0 comprennent : RSA (toutes tailles de clés, toutes applications), ECDH et ECDSA (toutes courbes), Diffie-Hellman (classique et sur courbe elliptique) et SHA-256 pour les applications NSS (où SHA-384 est désormais mandaté). AES-128 et AES-192 sont également dépréciés au profit de AES-256 pour les NSS.

Les algorithmes approuvés en détail

ML-KEM (Mécanisme d'encapsulation de clé sur réseau modulaire) est basé sur la difficulté du problème Module Learning With Errors (MLWE) — un problème de réseau qu'aucun algorithme quantique ou classique connu ne résout efficacement. ML-KEM fonctionne comme un mécanisme d'encapsulation de clé : l'expéditeur encapsule un secret partagé sous la clé publique du destinataire ; le destinataire décapsule pour récupérer le secret partagé. Ce secret partagé alimente ensuite une fonction de dérivation de clé symétrique. ML-KEM-1024 produit des clés publiques de 1 568 octets, des textes chiffrés de 1 568 octets et des secrets partagés de 32 octets — plus grands que les clés RSA-2048 (256 octets), mais acceptables pour la plupart des contextes de protocole.

ML-DSA (Algorithme de signature numérique sur réseau modulaire) est basé sur la difficulté des problèmes Module Short Integer Solution (MSIS) et MLWE. ML-DSA-87 (le niveau de sécurité le plus élevé, correspondant à la sécurité AES-256) produit des clés publiques de 2 592 octets et des signatures de 4 627 octets. À titre de comparaison, ECDSA P-256 produit des signatures de 64 octets. Les tailles de signature plus importantes nécessitent des ajustements dans les protocoles et les systèmes de stockage qui supposaient des signatures compactes — les chaînes de certificats, les images firmware et les liaisons à bande passante limitée nécessitent une planification de capacité.

SLH-DSA (Algorithme de signature numérique sans état basé sur le hachage) n'a aucune structure algébrique exploitable par des algorithmes classiques ou quantiques au-delà des attaques génériques sur les fonctions de hachage ; sa sécurité se réduit entièrement à la résistance aux collisions de la fonction de hachage sous-jacente. La contrepartie est la performance et la taille : les signatures SLH-DSA-SHA2-256s font 29 792 octets avec le jeu de paramètres le plus bas, et la signature est plusieurs ordres de grandeur plus lente que ML-DSA. SLH-DSA est approprié comme algorithme de signature secondaire pour assurer la diversité de sécurité, notamment pour la signature de firmware et de logiciels où la taille des signatures et la fréquence de signature sont gérables.

Les quatre phases de migration

Une migration CNSA 2.0 bien structurée se déroule en quatre phases. Les organisations peuvent se trouver dans des phases différentes simultanément pour différents types de systèmes — une grande organisation de défense aura généralement la migration PKI en Phase 2 tandis que les systèmes de bord tactiques sont encore en Phase 1.

Phase 1 — Inventaire cryptographique. Avant que tout travail de migration puisse être planifié, l'organisation doit savoir ce qu'elle possède. L'inventaire cryptographique englobe : chaque point de terminaison TLS et ses suites de chiffrement négociées ; chaque certificat en cours d'utilisation (utilisateur, appareil, service, signature de code) et son algorithme de clé et sa date d'expiration ; chaque passerelle VPN et sa configuration d'échange de clés IKEv2 ; chaque système de gestion des clés, HSM et jeton cryptographique ; chaque pipeline de signature de firmware et son type de clé de signature ; et chaque archive de données où une confidentialité à long terme est requise et l'algorithme de clé de chiffrement.

Les outils automatisés aident — scanners TLS (SSLyze, testssl.sh), analyse SBOM pour les dépendances de bibliothèques cryptographiques, et plateformes de gestion des certificats avec rapports d'algorithmes. Mais les outils automatisés ratent les implémentations de protocoles personnalisés, la cryptographie de firmware embarqué et la cryptographie au niveau applicatif en dehors des bibliothèques standard. Une revue manuelle de la documentation d'architecture et du code source est nécessaire pour être exhaustif.

Phase 2 — Priorisation basée sur les risques. Toutes les dépendances cryptographiques ne présentent pas le même risque HNDL. La priorisation doit refléter deux dimensions : la longévité et la sensibilité des données protégées, et la faisabilité d'une migration à court terme. Les cibles hautement prioritaires sont les systèmes protégeant des données classifiées à longue durée de vie où l'exposition HNDL est la plus élevée : les autorités de certification racine et émettrices PKI (dont les clés protègent l'ancre de confiance de toute l'organisation), l'infrastructure de gestion des clés (HSM détenant les clés maîtresses des archives chiffrées), les liaisons de communications stratégiques et tout système chiffrant des données avec une exigence de confidentialité supérieure à cinq ans.

Moins prioritaires — mais toujours requis avant 2030 — sont les systèmes avec des cycles de renouvellement matériel fréquents (plateformes tactiques, appareils des utilisateurs finaux) où la capacité PQC peut être intégrée lors du prochain renouvellement naturel, et les systèmes internes protégeant des données non classifiées où le risque quantique est moindre.

Phase 3 — Fonctionnement hybride. Durant la migration, les systèmes interopèreront avec des homologues CNSA 1.0 (classiques) et CNSA 2.0 (post-quantiques). La cryptographie hybride — combinant des algorithmes classiques et post-quantiques dans le même échange de protocole — offre une résistance quantique sur le trafic actuel sans exiger que tous les points de terminaison prennent en charge simultanément les algorithmes post-quantiques.

Dans une connexion TLS 1.3 hybride, le client inclut à la fois un partage de clé ECDHE et un partage de clé ML-KEM dans le ClientHello ; le serveur répond avec les deux. La clé de session finale est dérivée des deux secrets partagés à l'aide d'une fonction de dérivation de clé. Un adversaire doit casser les deux algorithmes, classique et post-quantique, pour compromettre la session. Cette approche « ceinture et bretelles » est explicitement approuvée par la NSA pour la période de transition.

Phase 4 — Transition complète. Une fois que tous les systèmes prennent en charge les algorithmes post-quantiques et que le fonctionnement hybride s'est avéré stable en production, les suites de chiffrement et les types de certificats exclusivement classiques sont retirés. La dépréciation doit être coordonnée avec toutes les organisations en interopération, les fournisseurs et les nations partenaires. Établir une surveillance pour détecter toute négociation résiduelle d'algorithme classique (ce qui indiquerait un système qui a été manqué dans l'inventaire ou qu'un fournisseur n'a pas encore livré de logiciel compatible CNSA 2.0), et suivre les jalons de dépréciation par rapport à l'échéance de 2030.

Systèmes prioritaires et séquençage de la migration

Dans le backlog de migration priorisé, certains types de systèmes apparaissent systématiquement comme hautement prioritaires dans pratiquement toutes les organisations de défense et doivent être séquencés tôt, indépendamment des spécificités organisationnelles.

Infrastructure de gestion des clés. Les HSM et les services de gestion des clés (KMS) sont des dépendances pour la migration de presque tous les autres systèmes — les clés post-quantiques doivent être générées, stockées et gérées quelque part. La mise à niveau du firmware HSM pour prendre en charge les opérations ML-KEM et ML-DSA, et la vérification que les API de gestion des clés exposent les types de clés post-quantiques aux applications consommatrices, constituent un travail de Phase 1–2 dans tout programme de migration. C'est également là que l'engagement avec les fournisseurs est le plus critique : les fournisseurs de HSM varient significativement dans leurs feuilles de route PQC, et certaines générations de matériel ne peuvent pas être mises à niveau en place.

Autorités de certification racine et émettrices PKI. La hiérarchie de confiance PKI sous-tend l'authentification basée sur les certificats dans toute l'organisation. Établir des autorités de certification racine post-quantiques — et distribuer leurs ancres de confiance à toutes les parties utilisatrices (navigateurs, systèmes d'exploitation, clients TLS, validateurs OCSP) — est un prérequis pour émettre des certificats post-quantiques pour tout système. Cela doit se produire avant que des certificats post-quantiques puissent être déployés ailleurs. Un modèle de double émission, où la même autorité de certification émet des certificats classiques et post-quantiques pour chaque sujet, permet une migration progressive des parties utilisatrices sans rompre les relations de confiance existantes.

Passerelles VPN et plateformes de communications chiffrées. Les passerelles VPN protégeant les périmètres de réseaux classifiés sont des cibles HNDL primaires. IKEv2, le protocole d'échange de clés utilisé dans la plupart des solutions VPN d'entreprise, doit être mis à jour pour négocier ML-KEM pour l'établissement des clés et ML-DSA pour l'authentification. La plupart des fournisseurs VPN d'entreprise (Cisco, Palo Alto, Juniper, Check Point) ont des éléments PQC dans leur feuille de route, mais la disponibilité des fonctionnalités et la conformité aux paramètres CNSA 2.0 varient significativement — c'est une question de qualification critique des fournisseurs lors des approvisionnements.

Plateformes de communications et de messagerie chiffrées. Les systèmes utilisés pour les communications de commandement stratégique, la diffusion du renseignement et la coordination de missions critiques sont des cibles hautement prioritaires car la sensibilité et la longévité du trafic sont élevées. Corvus.Quantum, la plateforme de streaming de Corvus Intelligence pour la défense, est conçue pour l'alignement CNSA 2.0 — intégrant ML-KEM pour l'établissement des clés et ML-DSA pour la signature des messages dans son architecture de streaming et de messagerie, prenant en charge le fonctionnement hybride durant la période de transition.

Pipelines de signature de firmware. Les systèmes d'armes et les plateformes matérielles militaires utilisent des signatures numériques pour vérifier l'intégrité du firmware. Ces signatures sont à longue durée de vie — la clé de signature peut couvrir toute la durée de production d'une plateforme, sur une décennie ou plus — et sont donc directement exposées au risque HNDL. Les nouvelles plateformes entrant en production devraient être livrées avec une signature de firmware ML-DSA ou SLH-DSA dès la première livraison. Les plateformes en service nécessitent une campagne de re-signature des images firmware là où l'architecture de démarrage prend en charge la rotation des clés ; les plateformes où les clés de signature sont fusionnées à la fabrication nécessitent une documentation explicite des risques.

Comment inventorier les dépendances cryptographiques

L'inventaire cryptographique est systématiquement la phase la plus sous-estimée des programmes de migration PQC. Les organisations qui commencent la migration en supposant que l'inventaire prendra des semaines découvrent généralement qu'il faut des mois, parce que la cryptographie est déployée à travers plus de couches systémiques et plus de chemins de code qu'aucune équipe n'en a une visibilité complète.

Une stratégie d'inventaire complète combine quatre approches. Premièrement, la découverte au niveau réseau : analyse passive du trafic TLS et analyse active de tous les points de terminaison accessibles à l'aide d'outils qui identifient les suites de chiffrement négociées et les algorithmes de clés des certificats. Cela capture les serveurs web, les points de terminaison API, les équilibreurs de charge et les communications de maillage de services qui utilisent TLS standard. Deuxièmement, l'énumération via la plateforme de gestion des certificats : interrogation de la hiérarchie CA de l'organisation et de tous les journaux CT (Certificate Transparency) publics pour les certificats portant les noms de l'organisation, extraction de l'algorithme de clé et de la date d'expiration pour chacun. Troisièmement, l'analyse SBOM : extraction des nomenclatures logicielles (Software Bill of Materials) des applications déployées et analyse des dépendances de bibliothèques cryptographiques (OpenSSL, BoringSSL, libgcrypt, NSS, fournisseurs de cryptographie Java) et de leurs versions. Les versions de bibliothèques cryptographiques déterminent quels algorithmes sont disponibles et lesquels sont les valeurs par défaut. Quatrièmement, la revue de la documentation d'architecture : identification des implémentations de protocoles personnalisés, de la dérivation de clés en cours de traitement, des colonnes de bases de données chiffrées et de la cryptographie au niveau applicatif que l'analyse réseau ne peut pas observer.

Le résultat de l'inventaire doit être un registre structuré comprenant au minimum : le nom du système, le type de dépendance cryptographique (TLS, certificat, KEM, signature, symétrique), l'algorithme et la taille de la clé, la bibliothèque ou l'implémentation, la classification des données protégées et la complexité estimée de la migration. Ce registre guide la priorisation de la Phase 2 et fournit la base de référence pour suivre la progression de la conformité.

Questions aux fournisseurs lors des approvisionnements

Les organisations de défense qui approvisionnent des logiciels et du matériel commerciaux sur étagère doivent évaluer la conformité CNSA 2.0 dans le cadre de l'approvisionnement. Les questions suivantes distinguent les fournisseurs dotés d'une capacité PQC réelle de ceux qui font des promesses sur leur feuille de route :

Spécificités de la prise en charge des algorithmes. « Votre produit prend-il en charge ML-KEM-1024, ML-DSA-87 et SLH-DSA-SHA2-256s tels que définis dans FIPS 203, 204 et 205 ? » Les fournisseurs qui répondent avec des affirmations génériques de « prise en charge post-quantique » sans désignations FIPS spécifiques et niveaux de paramètres ne sont probablement pas en mesure de satisfaire les exigences spécifiques de CNSA 2.0. La prise en charge des algorithmes à des niveaux de paramètres inférieurs (ML-KEM-512, ML-DSA-44) ne satisfait pas les niveaux de sécurité mandatés par CNSA 2.0 pour les NSS.

Disponibilité des suites de chiffrement hybrides. « Votre implémentation TLS prend-elle en charge l'échange de clés hybride ML-KEM + ECDHE dans une seule négociation ? » La prise en charge hybride permet à l'organisation de commencer à bénéficier de la résistance quantique sur le trafic existant sans exiger que toutes les parties en interopération aient achevé simultanément leur migration PQC.

Accommodation des tailles de clés. « Comment votre système gère-t-il les tailles de clés et de signatures plus importantes des algorithmes post-quantiques ? » Les signatures ML-DSA-87 font approximativement 4,6 Ko contre 64 octets pour ECDSA P-256. Les systèmes avec des tampons de certificat ou de signature de taille fixe, des schémas de bases de données avec des longueurs de champs cryptographiques fixes, ou des protocoles réseau avec des hypothèses MTU strictes peuvent nécessiter des modifications architecturales pour accueillir le matériel de clé PQC.

Provenance de la bibliothèque cryptographique. « Quelle bibliothèque cryptographique sous-tend votre implémentation PQC, et quelle est la cadence de mise à jour des versions ? » Les implémentations post-quantiques dans OpenSSL, BoringSSL et Bouncy Castle sont encore en cours de maturation ; la cadence de mise à jour du fournisseur détermine la rapidité avec laquelle les correctifs de sécurité parviennent aux produits déployés.

Feuille de route post-2030. « Quelle est votre plan pour le fonctionnement en mode PQC pur après 2030, quand le mode hybride et les algorithmes classiques seront dépréciés ? » Les fournisseurs sans feuille de route concrète post-2030 représentent un risque de conformité qui nécessitera des transitions gérées au pire moment — lorsque l'échéance est imminente.

Processus de planification de migration CNSA 2.0 en six étapes

Les étapes suivantes distillent les phases de migration ci-dessus en une séquence de planification actionnable pour les équipes informatiques et de sécurité de la défense qui démarrent un programme de conformité CNSA 2.0.

Étape 1 — Réaliser un inventaire cryptographique. Déployer l'analyse TLS, les rapports de gestion des certificats, l'analyse SBOM et la revue de la documentation d'architecture sur tous les systèmes. Produire un registre structuré de chaque dépendance cryptographique : type, algorithme, taille de clé, bibliothèque, classification des données et complexité estimée de la migration. Prévoir que cette étape prendra 2 à 6 mois pour une organisation de défense de taille moyenne à grande. Ne pas procéder à la planification sans un inventaire raisonnablement complet — les plans de migration basés sur un inventaire partiel manqueront des systèmes hautement prioritaires.

Étape 2 — Évaluer les risques et prioriser les systèmes. Évaluer chaque élément de l'inventaire selon deux axes : le risque HNDL (sensibilité et longévité des données protégées) et la faisabilité de la migration (capacité de l'équipe, disponibilité des fournisseurs, complexité architecturale). Produire un backlog de migration priorisé avec l'effort estimé, les dépendances entre les éléments et l'attribution des responsables. Les éléments protégeant des données classifiées à longue durée de vie avec une faible complexité de migration doivent être en tête, indépendamment de la politique organisationnelle.

Étape 3 — Mettre à niveau la gestion des clés et l'infrastructure PKI en premier. Migrer les HSM vers un firmware compatible CNSA 2.0. Émettre des certificats d'autorité de certification racine post-quantiques. Établir la capacité de double émission. Distribuer les ancres de confiance mises à jour aux parties utilisatrices. Cette phase est une dépendance pour toutes les migrations ultérieures basées sur des certificats et doit être financée et lancée immédiatement après la réalisation de l'inventaire.

Étape 4 — Déployer des suites de chiffrement hybrides sur les chemins réseau à haute priorité. Activer les suites de chiffrement hybrides ML-KEM sur les passerelles VPN, les périmètres de réseaux classifiés et les plateformes de communications. Cette étape offre une réduction immédiate du risque HNDL sur le trafic actuel sans nécessiter une pleine conformité PQC sur tous les points de terminaison. Surveiller les taux de négociation pour suivre l'adoption.

Étape 5 — Migrer la signature de firmware et la chaîne d'approvisionnement logicielle. Passer les pipelines de signature de firmware aux clés ML-DSA ou SLH-DSA pour toutes les plateformes entrant en production. Mener des campagnes de re-signature pour les plateformes en service là où c'est architecturalement faisable. Mettre à jour les pipelines de signature de code CI/CD. Documenter les plateformes contraintes comme dette technique cryptographique gérée avec une acceptation de risque explicite.

Étape 6 — Exécuter la transition complète et déprécier les algorithmes classiques. Une fois que tous les systèmes hautement prioritaires prennent en charge les algorithmes post-quantiques et que le fonctionnement hybride est stable, commencer à retirer les suites de chiffrement et les types de certificats classiques selon un calendrier coordonné avec les organisations en interopération. Établir un tableau de bord de conformité. Viser la dépréciation complète des algorithmes classiques d'ici 2030, conformément aux directives de la NSA.

Lectures complémentaires

Pour une couverture plus approfondie des algorithmes post-quantiques sous-jacents et de leurs implications pour la défense, voir Cryptographie post-quantique pour la défense : guide CNSA 2.0. Pour l'infrastructure de gestion des clés et des secrets qui sous-tend la migration PQC, voir Gestion des secrets dans les pipelines CI/CD de défense : Vault, HSM et rotation des clés. Pour l'architecture zero-trust comme couche de sécurité complémentaire, voir Architecture zero-trust pour les réseaux militaires : principes et mise en œuvre.