La contrefaçon venue de demain : signer sa chaîne logicielle avec ML-DSA

Points clés

• La menace qui pèse sur les logiciels signés n’est pas « récolter puis déchiffrer », c’est « récolter puis contrefaire ». Un attaquant qui enregistre aujourd’hui votre micrologiciel signé en ECDSA pourra contrefaire ses signatures avec un ordinateur quantique cryptographiquement pertinent plus tard, et les appareils à longue durée de vie accepteront la contrefaçon au démarrage. C’est pourquoi le CNSA 2.0 de la NSA exige que la signature logicielle privilégie les algorithmes post-quantiques dès 2025 et les utilise exclusivement d’ici 2030, l’une des échéances d’usage exclusif les plus rapprochées de la suite CNSA 2.0.
• La série en deux volets d’AWS (12 octobre 2026) est le premier guide de bout en bout d’un fournisseur infonuagique pour la signature post-quantique de la chaîne logicielle : autorité de certification racine ML-DSA-87 et subordonnée ML-DSA-65 dans AWS Private CA, clés de signature de code ML-DSA dans les modules matériels d’AWS KMS, IAM Roles Anywhere pour les agents de compilation externes, et des nomenclatures logicielles (SBOM) enveloppées dans des déclarations in-toto pour que le manifeste des dépendances soit lié cryptographiquement à l’image qu’il décrit.
• La moitié « application » est là où les politiques vivent ou meurent. Les trois variantes ML-DSA partagent un seul algorithme de signature (ML_DSA_SHAKE_256), donc la clé de condition kms:SigningAlgorithm ne peut les distinguer. La clé de condition kms:KeySpec le peut, sur CreateKey, Sign, Verify et GetPublicKey. Une politique ciblant une variante écrite contre la mauvaise clé de condition est un processus documenté qui n’applique rien.
• Une liste de refus de la variante exclue laisse une brèche par défaut : tout ce qui n’est pas encore évalué passe. Une liste d’autorisation des variantes approuvées est fermée par défaut, mais exige une mise à jour de la politique pour chaque nouvelle variante. C’est le compromis d’entretien que l’article appelle l’agilité cryptographique : changer ce qu’on autorise sans réingénierie la façon de l’appliquer.

Imaginez un micrologiciel signé en ECDSA P-256 et livré à un parc d’appareils embarqués en 2026. Les appareils vérifient la signature à chaque démarrage. Ils resteront sur le terrain pendant 15 ans, et personne ne pourra les rappeler pour les re-signer. En 2035, un ordinateur quantique cryptographiquement pertinent entre en service. Un attaquant produit une signature d’apparence valide sur un micrologiciel trafiqué, et chaque appareil du parc l’accepte comme authentique au prochain redémarrage.

C’est le scénario qui ouvre le premier volet de la série d’AWS, et c’est la bonne ouverture. Presque toute la conversation post-quantique tourne autour de la confidentialité : récolter maintenant, déchiffrer plus tard. Un fil récent sur r/cryptography soutenait que la priorité est inversée, que l’authentification est la vraie inquiétude, sous le nom de « faire confiance maintenant, exploiter plus tard ». Un commentateur a bien résumé l’argument du moment : la confidentialité doit être corrigée avant la capture des données, tandis que l’authentification doit seulement être corrigée avant la contrefaçon. Pour la signature, la fenêtre dangereuse est la contrefaçon, pas la récolte. Les artefacts que vous signez aujourd’hui doivent rester dignes de confiance pendant toute leur durée de vie opérationnelle.

Ce qu’AWS a vraiment livré

Le premier volet construit le pipeline. Le second fait tenir les choix d’algorithmes. Le schéma de signature est ML-DSA, l’algorithme de signature numérique fondé sur les réseaux euclidiens modulaires normalisé comme NIST FIPS 204. L’architecture compte cinq piliers, et chacun remplace une dépendance classique par une dépendance résistante au quantique :

1. Gestion des clés ML-DSA dans AWS KMS. Les clés de signature sont générées et conservées dans des modules de sécurité matériels de niveau 3 FIPS 140-3. La clé privée ne quitte jamais le HSM.
2. Hiérarchie de certificats ML-DSA dans AWS Private CA. Une AC racine ML-DSA-87 (validité de 10 ans, catégorie de sécurité 5 du NIST) émet vers une AC subordonnée ML-DSA-65 (5 ans, catégorie 3). La grosse clé protège l’ancre la plus durable; la plus petite signe les certificats émis chaque jour.
3. Identité de charge de travail résistante au quantique. Les agents de compilation hors AWS (Jenkins, exécuteurs auto-hébergés) s’authentifient d’habitude avec des identifiants RSA ou ECDSA. IAM Roles Anywhere avec des certificats ML-DSA remplace cette dépendance classique et rattache l’identité du signataire à la même racine de confiance résistante au quantique. Une note honnête : le TLS qui transporte la demande authentifie toujours le point de terminaison AWS à l’ancienne. Le transport est hors sujet ici.
4. Signature des artefacts. Les binaires, les images de conteneurs et les paquets sont signés avec la clé ML-DSA de KMS. Deux modes de message comptent. La plupart des artefacts dépassent la limite de 4 096 octets de KMS, donc le réglage par défaut du pipeline devrait être EXTERNAL_MU : calculer le représentant de message de 64 octets en externe avec OpenSSL 3.5, puis ne passer que lui à KMS. RAW n’est sûr que pour les entrées de taille fixe, comme le condensé de manifeste d’image de 71 caractères, parce qu’un artefact qui tient aujourd’hui dépassera la limite demain.
5. Attestation des SBOM. La SBOM est enveloppée dans une déclaration in-toto qui nomme l’artefact par son condensé, et la déclaration est signée avec la même clé de signature de code.

Deux détails du premier volet méritent l’attention, parce que c’est le genre de chose qu’une équipe rate en silence. D’abord, comme la clé privée KMS ne quitte jamais le HSM, on ne peut pas générer la CSR de signature de code avec OpenSSL en local. On construit la structure « à signer » de la CSR, on la signe à distance avec aws kms sign, et on assemble le résultat en code. Il n’existe pas de chemin en CLI seule; l’article pointe vers un exemple Java comme implémentation de référence.

Ensuite, la liaison de la SBOM. Signer le fichier SBOM prouve que l’inventaire n’a pas été trafiqué, mais ne prouve pas quel artefact la SBOM décrit. Un attaquant détenant une SBOM signée légitimement pour une image saine pourrait la présenter à côté d’une autre image signée. Attacher la SBOM comme référent OCI (Open Container Initiative) ne ferme pas cette brèche, parce que le champ subject du référent est fixé par qui le pousse. C’est un mécanisme de découverte, pas une liaison cryptographique. La liaison doit se trouver dans les octets signés. C’est ce que fait la déclaration in-toto : le condensé de l’image est dans le contenu signé, et le vérificateur contrôle le condensé du sujet résolu depuis le registre, jamais depuis la déclaration. Une SBOM permutée ou un condensé permuté échoue. Sur r/devsecops ce mois-ci, un praticien a tracé la ligne exactement là : la vraie question n’est pas de savoir si vous avez une SBOM, c’est si les métadonnées parviennent jusqu’à une décision d’application, liées à la même identité d’actif que la décision. Les équipes ont dépassé le goulot de la visibilité. Elles veulent de l’application, pas un autre tableau de bord.

La moitié vérification que la plupart des équipes sautent

Un pipeline de signature, c’est moitié construction, moitié vérification. Le premier volet donne au flux de vérification de vraies dents : distribuer la chaîne de confiance à chaque point de vérification, contrôler le certificat avec -purpose codesign (un simple contrôle de chaîne accepte aussi les certificats clients des agents de compilation émis par la même AC, donc l’usage compte), épingler le sujet du signataire attendu, et résoudre le condensé depuis le registre. Au déploiement, un contrôleur d’admission Kubernetes s’exécute avant la planification de tout pod et rejette les images sans référent de signature ML-DSA valide ou dont l’attestation SBOM ne nomme pas l’image. Une note de production qui vaut le détour : un registre liste les référents sans ordre fiable, et une image re-signée en a plus d’un. Un vérificateur devrait contrôler chaque référent du type et accepter si au moins un se vérifie. Ne prendre que le premier peut rejeter une image correctement signée. Cela ne peut jamais en accepter une non signée.

Brisez votre propre garde-fou

Voici maintenant la partie dont cet article parle vraiment. Le second volet s’adresse aux équipes de sécurité et de gouvernance qui décident quels algorithmes le pipeline, et tout le reste de l’organisation, peuvent utiliser. La politique d’exemple : l’organisation a normalisé sur ML-DSA-65 et ML-DSA-87 et veut tenir ML-DSA-44 à l’écart. Non pas parce que ML-DSA-44 est faible. C’est un jeu de paramètres entièrement normalisé, catégorie 2 du NIST, le plus petit et le plus rapide des trois, bien adapté aux appareils contraints et à la signature à haut volume. L’exclusion est une décision de normalisation, et l’article le dit franchement.

Le mécanisme qui rend la politique réelle est la clé de condition kms:KeySpec. C’est le détail technique le plus important de la série, alors le voici deux fois. AWS KMS expose trois spécifications de clé ML-DSA, ML_DSA_44, ML_DSA_65, ML_DSA_87, et les trois utilisent un seul algorithme de signature : ML_DSA_SHAKE_256. Une condition de politique écrite contre kms:SigningAlgorithm ne peut donc pas distinguer les variantes. kms:KeySpec reflète la vraie variante de la clé et est évalué sur CreateKey, Sign, Verify, GetPublicKey, et même ReplicateKey. Empêcher la création de clés ML-DSA-44 est le contrôle unique le plus solide : si aucune clé ML-DSA-44 KMS n’existe, aucune ne peut servir, et aucune ne peut devenir la clé sujet d’un certificat.

Le laboratoire ci-dessous est un modèle pédagogique de cette logique d’application. Choisissez une forme de politique et une clé de condition, faites passer cinq demandes de signature réalistes dans la politique, et regardez ce qui survit. La cinquième demande est une hypothétique ML-DSA-128, un substitut pour toute variante que personne n’a encore évaluée.

Les couches derrière le laboratoire

Le simulateur montre une seule SCP. L’article en superpose quatre, chacune couvrant un périmètre différent :

• Politique de contrôle de service (SCP) à la racine de l’organisation ou sur une unité organisationnelle (OU). Le contrôle préventif le plus large : refuser kms:CreateKey et le trio d’utilisation (Sign, Verify, GetPublicKey) partout où kms:KeySpec vaut ML_DSA_44. Un refus explicite dans une SCP ne peut être outrepassé par aucune politique IAM des comptes membres. Deux pièges : garder le refus d’utilisation limité à ces trois actions, pas à kms:*, sinon vous vous enfermez hors de DescribeKey, DisableKey et ScheduleKeyDeletion pour les clés mêmes que vous voulez supprimer. Et les SCP ne s’appliquent pas au compte de gestion, donc n’y faites pas tourner de charges de signature en espérant que le garde-fou tienne.
• Politique IAM et frontières d’autorisations. Le pendant au niveau du principal pour un contrôle par compte ou par rôle. Une frontière s’ouvre avec une autorisation sur tout, puis refuse la création ML-DSA-44; un refus dans une frontière ne peut être outrepassé par une politique attachée. Mais une frontière ne lie que les principaux qui la portent, donc il faut un mécanisme qui l’impose à chaque principal : l’article esquisse une SCP qui refuse la création de rôles ou d’utilisateurs sans la frontière approuvée, refuse la suppression des frontières, et sonde la dérive.
• Politiques de clés KMS. Un filet côté ressource sur une clé précise. Même refus kms:KeySpec, avec un élément Principal ajouté. Protège la clé elle-même pendant que la SCP donne la couverture à l’échelle de l’organisation.
• Contrôles de détection. CloudTrail journalise le KeySpec sur CreateKey et l’algorithme de signature sur CreateCertificateAuthority, ce qui en fait le détecteur efficace au moment de la création. Des règles AWS Config personnalisées signalent la dérive. Supprimer une clé qu’on ne trouve pas est difficile; AWS KMS n’a pas de filtre serveur par spécification de clé, donc on énumère avec ListKeys et on inspecte chacune, ou on utilise Config pour tenir l’inventaire. Rappelez-vous ce que coûte la suppression : il est difficile de savoir quelles données une clé a signées si on ne l’a pas suivi, et supprimer une clé utilisée rend ses signatures invérifiables.

Là où aucune clé de condition n’existe, l’article est honnête sur les limites. acm-pca:CreateCertificateAuthority prend l’algorithme à la création mais n’expose aucune clé de condition d’algorithme, donc l’application se déplace dans le pipeline d’approvisionnement : restreindre qui peut l’appeler, figer l’algorithme dans le modèle approuvé, et détecter la dérive avec CloudTrail et Config. Un détail discret : Private CA copie la clé sujet depuis la CSR sans valider son algorithme, donc épinglez l’algorithme de clé de la CSR dans le même pipeline. L’import et le téléversement de certificats (acm:ImportCertificate, iam:UploadServerCertificate) ne connaissent pas du tout l’algorithme; refusez-les là où ils ne sont pas requis. Les écouteurs d’équilibreurs de charge référencent les certificats par ARN, donc aucune SCP ne peut inspecter l’algorithme du certificat au moment de l’association. Le contrôle, c’est le matériau lui-même : sans AC ML-DSA-44, sans clé ML-DSA-44 KMS, et avec l’import contrôlé, aucun certificat ML-DSA-44 ne peut être émis ni associé.

Puis la question de l’agilité, qui est vraiment une question d’entretien. Une liste de refus qui nomme la variante exclue est une liste d’autorisation de tout ce qu’elle ne nomme pas. Une nouvelle variante devient utilisable jusqu’à ce que quelqu’un la remarque et l’ajoute. C’est exactement ce que démontre la demande ML-DSA-128 du laboratoire. L’alternative écrit la condition contre l’ensemble approuvé : un refus sur toute variante ML-DSA hors de {ML_DSA_65, ML_DSA_87} est fermé par défaut sur l’inconnu, au prix d’une mise à jour de la politique avant que quiconque puisse utiliser quelque chose de nouveau. Les deux formes sont légitimes. Le choix est de savoir si vous préférez bloquer d’abord et approuver ensuite, ou remarquer d’abord et décider ensuite.

Les devoirs de conformité

Trois échéances en font un problème d’aujourd’hui plutôt que d’un jour.

CNSA 2.0. La suite d’algorithmes 2.0 de la NSA exige que les systèmes de sécurité nationale américains privilégient les signatures résistantes au quantique pour les logiciels et micrologiciels dès 2025 (en vigueur), rend toutes les nouvelles acquisitions conformes au CNSA 2.0 à partir du 1er janvier 2027, et impose l’usage exclusif d’ici 2030. La signature porte l’une des dates d’usage exclusif les plus rapprochées de la suite CNSA 2.0, parce que les racines de confiance des micrologiciels sont les plus difficiles à mettre à jour après déploiement. Une nuance pour les prudents : quand ML-DSA sert à signer sur des systèmes NSS, le CNSA 2.0 ne permet que ML-DSA-87 (les schémas à base de hachage avec état LMS et XMSS sont aussi approuvés pour cet usage). Le ML-DSA-65 des exemples de signature de code de l’article convient aux charges commerciales, mais n’est pas permis sur les NSS.

Le règlement européen sur la cyberrésilience. Le règlement s’applique pleinement le 11 décembre 2027. Les produits mis sur le marché européen doivent protéger l’intégrité des données stockées, transmises et traitées contre toute manipulation non autorisée, et les fabricants doivent fournir des mécanismes pour distribuer les mises à jour en sécurité. Une SBOM signée accompagnant chaque version, construite comme le premier volet la construit, c’est à quoi ressemble cette obligation en pratique. Les devoirs de déclaration des vulnérabilités sont en vigueur depuis le 11 septembre 2026 : la fenêtre entre aujourd’hui et l’application complète est la période de migration, pas une période de grâce.

PCI DSS 4.0. L’exigence 12.3.3 impose, depuis mars 2025, que les suites de chiffrement et les protocoles cryptographiques en usage soient documentés et révisés au moins une fois par an, avec un inventaire à jour. Étiqueter les clés ML-DSA face aux clés traditionnelles dans KMS et suivre la progression de la migration transforme l’architecture de l’article en preuve pour cette exigence.

Pour les artefacts qui doivent rester vérifiables au-delà de l’expiration d’un certificat, l’article liste trois approches : une validité de certificat plus longue en PKI privée, l’horodatage de confiance selon la RFC 3161 auprès d’une autorité d’horodatage (AWS n’en exploite pas de gérée), ou la re-signature avec un nouveau certificat avant expiration. Les artefacts à longue durée de vie sont précisément ceux que vise la menace de contrefaçon différée : choisissez-en une délibérément.

Les limites honnêtes

Quatre mises en garde. L’article en énonce trois; la quatrième est la mienne.

D’abord, ML-DSA-44 n’est pas le méchant. L’exclusion de l’article est de la normalisation, et les petites signatures et la vitesse de ML-DSA-44 en font le bon choix pour les appareils contraints, la signature à haut volume et les charges sensibles à la bande passante. Une politique qui l’exclut devrait dire pourquoi en langage clair, sinon les ingénieurs y liront un jugement de sécurité et la contourneront.

Ensuite, la menace de contrefaçon différée vise la queue à longue durée de vie. Une image de conteneur redéployée chaque semaine n’a pas la même fenêtre qu’un micrologiciel gravé dans un compteur. Dimensionnez la migration sur la queue, pas sur la moyenne.

Puis, les contrôles gouvernent les API des services AWS, pas la cryptographie sur le calcul que vous contrôlez. La signature ML-DSA-44 avec OpenSSL sur une instance EC2, l’authentification par clé publique hybride ssh-mldsa44-ed25519, et les certificats importés échappent aux SCP et à IAM. La série est de la défense en profondeur pour les services qu’elle couvre, pas un périmètre.

Enfin, des mathématiques réglées ne règlent pas l’ingénierie. Un fil sur r/crypto cet été a vérifié par machine une implémentation ML-DSA déployée contre FIPS 204 et trouvé un bogue d’un seul caractère dans un décodeur d’indices qui acceptait des indices non canoniques. Les praticiens se sont divisés sur ce que cela signifie, mais la leçon pratique a survécu à l’argument : les algorithmes normalisés ont quand même besoin de tests hostiles, et les suites de vecteurs de test comme Wycheproof sont l’atténuation. Un plan de migration qui fait confiance à la norme et saute les tests est un demi-plan.

Une question ouverte que personne ne peut trancher pour vous : la date. Aucune source crédible ne vous dira quand arrivera un ordinateur quantique cryptographiquement pertinent, et les échéances ci-dessus sont tarifées contre cet inconnu. C’est pourquoi les premières dates d’usage exclusif visent d’abord les artefacts à la plus longue durée de vie.

Commencez là où l’article vous dit de commencer : créez une première clé ML-DSA dans KMS et signez un artefact de test. Puis étendez à l’infrastructure à clés publiques (PKI), branchez IAM Roles Anywhere pour vos agents de compilation externes, et ajoutez les signatures ML-DSA à vos flux de conteneurs et de SBOM. Le pipeline est la moitié du travail. L’autre moitié, c’est le laboratoire de politiques que vous venez d’exécuter : faire tenir les choix d’algorithmes pendant que les comptes, les équipes et les normes changent.

L’article d’AWS est de la documentation fournisseur pour des services AWS, ce qui est à la fois sa force et sa limite. Les motifs d’application se transfèrent : quel que soit votre ensemble approuvé, et où que vivent vos clés, la question est la même. Votre politique peut-elle nommer la variante que vous avez exclue, et quelque chose le remarquerait-il si elle ne le pouvait pas ?

Sources principales

1. Quantum-resistant signing on AWS, Part 1: Build a software supply chain with ML-DSA (AWS Security Blog)
2. Quantum-resistant signing on AWS, Part 2: Enforce your ML-DSA algorithm policy with SCPs and IAM (AWS Security Blog)
3. FIPS 204 : norme de signature numérique fondée sur les réseaux euclidiens modulaires (NIST)
4. CNSA 2.0 : guide complet des exigences PQC de la NSA (postquantum.com)
5. Le règlement européen sur la cyberrésilience : ce que les équipes d'ingénierie doivent faire pour être conformes (Cloudsmith)
6. Clés ML-DSA dans AWS KMS (Documentation AWS)