Migrer la signature de code vers ML-DSA : un plan concret

La signature de code ne suit pas le même calendrier que TLS. Le trafic enregistré n'est protégé que par l'échange de clés, c'est pourquoi ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) en mode hybride passe en premier dans ce domaine. Une signature n'a besoin de résister à la falsification que tant que son ancre de confiance est active, mais le vérificateur qui la contrôle peut rester dans un chargeur d'amorçage pendant une décennie, et vous ne pouvez pas corriger un vérificateur avec une mise à jour que ce vérificateur est incapable de vérifier. C'est ce délai de mise en œuvre, et non l'urgence de la menace, qui explique pourquoi les calendriers officiels placent tôt la signature des logiciels et des micrologiciels : la NSA, avec CNSA 2.0 (Commercial National Security Algorithm Suite 2.0), exige l'usage exclusif de ML-DSA-87 ou de LMS/XMSS pour la signature des logiciels et des micrologiciels d'ici fin 2030 pour les National Security Systems américains, soit trois ans avant les navigateurs, les serveurs, les services cloud et les systèmes d'exploitation.

Pourquoi les échéances de signature précèdent celles de l'échange de clés

Le principe « collecter maintenant, déchiffrer plus tard » ne s'applique pas aux signatures. Personne ne peut enregistrer une signature aujourd'hui et s'en servir plus tard pour en falsifier une nouvelle. L'exposition est différente : un attaquant doté de capacités quantiques, capable de retrouver une clé privée de signature à partir de sa clé publique, pourrait signer un micrologiciel auquel votre parc installé fait encore confiance. La parade consiste à installer un vérificateur post-quantique dans ce parc bien avant que la clé ne devienne falsifiable, et les parcs installés évoluent lentement.

Trois caractéristiques font de la signature le chantier le plus long. Premièrement, les vérificateurs sont partout et souvent immuables : étages d'amorçage en ROM, éléments sécurisés, outils de provisionnement isolés du réseau, équipements chez les clients, installeurs hors ligne. Deuxièmement, les ancres de confiance sont embarquées : changer d'algorithme implique de distribuer de nouvelles clés publiques par un canal lui-même signé. Troisièmement, la dernière mise à jour qu'un appareil accepte sous l'ancien algorithme est celle qui doit lui apprendre le nouveau : un appareil retiré de votre chaîne de mise à jour avant ce moment restera classique pour toujours. Planifiez explicitement cette décision de fin de vie plutôt que de la découvrir en 2030.

Rien de tout cela ne suppose de prédire la date d'apparition d'un ordinateur quantique pertinent pour la cryptographie. Les dates ci-dessous proviennent de politiques et de recommandations publiées, et c'est à elles que votre feuille de route d'ingénierie des versions doit se conformer.

ML-DSA, SLH-DSA, LMS et XMSS : choisir selon le cas d'usage

Le NIST a publié FIPS 204 (ML-DSA, Module-Lattice-Based Digital Signature Algorithm) et FIPS 205 (SLH-DSA, Stateless Hash-Based Digital Signature Algorithm) comme normes définitives le 13 août 2024 (FIPS 204, FIPS 205). Les schémas à base de hachage avec état LMS et XMSS sont approuvés par NIST SP 800-208. CNSA 2.0 désigne ML-DSA-87 et LMS/XMSS pour la signature des logiciels et des micrologiciels, avec SHA-384 ou SHA-512 pour le hachage.

Pour la plupart des chaînes de publication, ML-DSA est le choix par défaut, car il est sans état et peut donc fonctionner sans risque dans un système de CI distribué comportant plusieurs signataires. Les schémas avec état sont intéressants pour les chargeurs d'amorçage contraints, mais la règle opérationnelle est impitoyable : l'état du signataire ne doit jamais être dupliqué, ce qui exclut les instantanés ordinaires de machines virtuelles, les clones de secours à chaud et la restauration d'un hôte de signature depuis une sauvegarde. Si vous ne pouvez pas le garantir dans votre environnement, choisissez un schéma sans état.

La taille compte, ce qui n'était pas le cas avec ECDSA. Les clés publiques et les signatures post-quantiques sont nettement plus volumineuses, et les signatures SLH-DSA le sont davantage encore. Consultez les tableaux de paramètres de FIPS 204 et FIPS 205 avant de dimensionner un champ de signature dans un en-tête de micrologiciel, une partition flash, un schéma de manifeste ou un budget de mise à jour à distance. Un champ de signature à largeur fixe dans un format d'image existant est un obstacle fréquent, et il relève d'un changement de format, non d'un changement cryptographique.

Le vérificateur d'abord : un ordre de mise à jour immuable

La séquence ci-dessous constitue l'ensemble du plan. Les étapes 2 et 3 doivent être achevées sur tout le parc avant le début de l'étape 5.

1. Inventorier les vérificateurs, pas seulement les signataires. Recensez chaque endroit où une signature est contrôlée : chargeurs d'amorçage, éléments sécurisés, gestionnaires de paquets, frameworks d'installation, agents de mise à jour, contrôleurs d'admission, outils de provisionnement, scripts de validation des partenaires. Notez ceux que vous pouvez mettre à jour, par quel canal, et ceux qui sont figés.
2. Ajouter la vérification post-quantique tout en acceptant encore l'algorithme classique. Le nouveau vérificateur doit être tolérant : accepter les anciennes signatures, accepter les nouvelles, et consigner celle qu'il a vue.
3. Livrer ce vérificateur par le canal existant signé de manière classique, puis distribuer les nouvelles ancres de confiance. Mesurez la couverture avec une télémétrie réelle, par appareil et par version, et non par supposition.
4. Enrôler les clés de signature dans du matériel et faire fonctionner de bout en bout une chaîne de signature parallèle hors production, y compris la révocation et l'horodatage.
5. Commencer la double signature des artefacts de production une fois que le vérificateur tolérant équipe l'écrasante majorité du parc.
6. Exiger les signatures post-quantiques uniquement lorsque la télémétrie montre que les anciens vérificateurs ont disparu, avec une décision écrite pour les retardataires : support étendu, remplacement sur site ou fin de vie documentée.
7. Abandonner la signature classique en dernier, et conserver la capacité de signer à nouveau les artefacts archivés afin que les anciennes versions restent vérifiables avec le nouveau schéma.

Double signature : les deux modes, et le piège

La double signature consiste à associer deux signatures indépendantes (l'une classique, l'autre post-quantique) au même artefact, généralement dans un format de conteneur qui prend en charge plusieurs emplacements de signature. Vérifiez si le vôtre le permet avant de concevoir quoi que ce soit d'autre : certains formats acceptent nativement plusieurs signataires, d'autres exigent une signature détachée transmise séparément ou une révision du format.

La décision de conception déterminante est la politique de vérification. En mode permissif, un vérificateur accepte l'artefact si l'une ou l'autre des signatures est valide, ce qui préserve le fonctionnement des anciens clients mais signifie que votre sécurité effective est celle du plus faible des deux algorithmes. En mode strict, le vérificateur exige les deux, ce qui renforce la sécurité mais crée un risque de disponibilité : une seule erreur dans l'une ou l'autre chaîne bloque toutes les publications. Le parcours habituel est le mode permissif pendant le déploiement, le mode strict une fois le parc prêt, puis le post-quantique seul. Formalisez la politique par classe de vérificateur et par type d'artefact, et rendez explicites les dates de transition : c'est précisément le type de changement d'algorithme planifié que la crypto-agilité est censée rendre routinier.

Prise en charge par les HSM, la PKI et les outils : vérifier, ne pas supposer

La prise en charge des signatures post-quantiques progresse rapidement dans les modules matériels de sécurité, les autorités de certification et les outils de signature, et les versions requises diffèrent selon les produits, voire selon les branches de micrologiciel d'un même produit. Ne considérez pas un billet de blog d'un fournisseur comme un engagement. Demandez les notes de version et le dossier de validation, et testez en préproduction. Voici les questions à poser par écrit :

• Le micrologiciel du HSM implémente-t-il ML-DSA, avec quels jeux de paramètres, et existe-t-il une version validée FIPS 140-3 ou une feuille de route datée pour l'obtenir ? Si CNSA 2.0 vous concerne, le jeu de paramètres pertinent est ML-DSA-87.
• Est-il accessible via l'interface utilisée par votre chaîne (mécanisme PKCS#11, types d'objets KMIP, API de KMS cloud, SDK du fournisseur), et les clés peuvent-elles être générées dans le matériel sans jamais être exportées ?
• Pour LMS ou XMSS : la génération des clés et l'avancement de l'état sont-ils effectués à l'intérieur du module cryptographique, sans aucun mécanisme susceptible de dupliquer l'état, comme l'exige SP 800-208 ?
• Votre autorité de certification peut-elle émettre des certificats avec des clés de sujet post-quantiques, et signer des données de révocation que vos vérificateurs accepteront ? Les hiérarchies peuvent nécessiter une chaîne post-quantique parallèle plutôt qu'une modification sur place.
• Votre autorité d'horodatage prend-elle en charge le nouvel algorithme, afin que les signatures restent vérifiables après l'expiration des certificats ?
• Vos outils de signature et de transparence des artefacts, vos systèmes de construction de paquets et vos bibliothèques de vérification le prennent-ils en charge dans les versions exactes que vous déployez ? OpenSSL, par exemple, requiert la version 3.5 ou ultérieure pour les groupes TLS ML-KEM ; pour la prise en charge des signatures, consultez les notes de version de la version précise que vous livrez, dans l'environnement de signature comme dans celui de vérification.
• Débit et latence : des signatures plus volumineuses et de nouveaux chemins de code modifient le temps de signature par artefact et la taille des téléchargements. Effectuez des mesures avec votre volume réel de publications.

Les dates à prendre en compte

Ce qui suit est fourni à titre d'information et ne constitue pas un conseil juridique. Le statut compte autant que la date : un projet n'est pas une norme, et des recommandations adressées aux États membres ne constituent pas une obligation pour les entreprises.

Sources primaires : OMB M-26-15, la feuille de route coordonnée de mise en œuvre de l'UE, la FAQ PQC de l'ANSSI, les calendriers de migration du NCSC britannique et NIST IR 8547 ipd. Pour CNSA 2.0, les sources publiées sont la FAQ CNSA 2.0 v2.1 (décembre 2024) et l'avis CNSA 2.0 Algorithms (30 mai 2025).

Les fabricants de produits doivent également noter que le Cyber Resilience Act (règlement sur la cyberrésilience), Regulation (EU) 2024/2847, Annex I, Part I (2)(e), exige de protéger la confidentialité au moyen de mécanismes conformes à l'état de l'art et ne nomme pas d'algorithmes post-quantiques ; ses obligations de signalement s'appliquent à partir du 11 septembre 2026 et il s'applique pleinement à partir du 11 décembre 2027 (EUR-Lex). Considérez la mise à jour sécurisée et la vérification des signatures comme faisant partie de cette argumentation sur l'état de l'art, et tenez l'inventaire des clés de signature dans le même registre que le reste de votre cryptographie.

Commencez par ce que vous pouvez mesurer dès aujourd'hui

La migration de la signature est un programme pluriannuel à l'échelle du parc : commencez donc par les deux actions peu coûteuses, à savoir une liste de tous les vérificateurs dont vous êtes responsable avec leur canal de mise à jour, et une chaîne de signature de préproduction qui produit de bout en bout un artefact doublement signé. En parallèle, confirmez que le transport utilise déjà l'échange de clés hybride, puisque c'est là que le trafic enregistré est en jeu et que la correction relève d'un changement de configuration plutôt que d'un déploiement sur tout le parc. Vous pouvez analyser votre domaine avec PQC Status pour savoir si vos hôtes de publication, de mise à jour et d'artefacts négocient X25519MLKEM768, quelles versions de TLS et quelles suites de chiffrement ils proposent, et à quoi ressemble leur chaîne de certificats. L'analyse décrit uniquement la configuration TLS visible de l'extérieur : il ne s'agit pas d'une certification, et elle n'inspecte pas votre chaîne de signature de code ; associez-la donc à l'inventaire des vérificateurs décrit plus haut.