Comment migrer vers la cryptographie post-quantique : ML-KEM, ML-DSA et approche hybride

Lorsque l’équipe comprend que le risque quantique est réel, le pendule passe souvent directement de « ce n’est pas mon problème » à « changeons tout maintenant ». Les deux extrêmes font obstacle. La migration vers la cryptographie post-quantique est un projet d'ingénierie avec séquence, priorité et soin, pas un bouton.

Une fois les normes NIST finalisées, il reste un endroit où migrer. ML-KEM s'occupe de l'établissement des clés, ML-DSA s'occupe de la signature numérique et SLH-DSA sert de signature de sauvegarde avec des fondements mathématiques différents. Savoir où aller représente la moitié de la bataille. L’autre moitié le fait sans casser ce qui fonctionne.

Ce texte est la feuille de route pragmatique : par où commencer, comment commander, à quoi veiller lors de la mise en œuvre et pourquoi la transition passe par une phase hybride.

Commencez par l'inventaire, pas par l'algorithme

La question « quel algorithme dois-je adopter » est tentante et prématurée. Avant cela vient une autre question : "Où est-ce que j'utilise la cryptographie aujourd'hui". La plupart des organisations répondent par le silence, et ce silence constitue le plus grand risque du projet.

Vous ne pouvez pas migrer ce que vous ne pouvez pas voir. Avant de toucher à une bibliothèque, vous avez besoin d'un inventaire cryptographique : où se trouvent les clés et les certificats, quelles bibliothèques et versions les applications utilisent, quels protocoles sous-tendent leurs connexions et quels fournisseurs et intégrations entrent dans cette chaîne.

Cette enquête définit l'ampleur réelle du problème et révèle des dépendances cachées, celles que personne n'a documentées mais qui arrêtent la production si elles sont altérées avec négligence. Je traite de l’inventaire en profondeur dans un article spécifique de la série, car c’est le fondement de tout ce qui vient après.

Sans inventaire, tout plan de migration n’est qu’une supposition. Avec l'inventaire, vous savez ce que vous avez, ce qui est critique et ce qui peut attendre.

Prioriser par validité et exposition des données

Tout migrer en même temps est coûteux, risqué et inutile. Le séquençage intelligent suit le risque, et le risque se concentre sur deux axes.

Le premier axe est la validité de la confidentialité. Les données qui doivent rester secrètes pendant de nombreuses années sont particulièrement menacées par le principe du « récolter maintenant, décrypter plus tard », la capture de données cryptées aujourd'hui pour les décrypter avec l'informatique quantique](/post/introducao-computacao-quantica-startups) dans le futur. Plus la validité du secret est longue, plus tôt il aura besoin d’une protection post-quantique.

Le deuxième axe est l’exposition. Les flux qui traversent des réseaux pouvant être capturés, les intégrations externes et tout ce qui négocie des clés sur Internet montent dans la file d'attente, car c'est là que se produit la récolte. Les systèmes internes, isolés et de faible valeur peuvent attendre.

Il existe également une différence d’urgence entre les deux utilisations du chiffrement. L'établissement clé, le territoire de ML-KEM, est une priorité absolue en raison de la récolte actuelle : les données capturées aujourd'hui pourront être lues plus tard. Les signatures numériques, territoire du ML-DSA, ont une urgence différente, car une signature contrefaite nécessite la machine quantique existant au moment de la fraude, pas avant. Cela ne le rend pas désactivable, en particulier pour les éléments de longue durée comme les certificats racine et la signature du micrologiciel, mais cela aide à organiser l'effort.

ML-KEM et ML-DSA : à quoi sert chacun

Cela vaut la peine de fixer les rôles afin de ne pas se tromper lors de la planification.

ML-KEM, FIPS 203, est un mécanisme d'encapsulation clé. En pratique, c'est ce qui établit la clé secrète partagée qui protège une connexion. C'est le remplacement direct de l'échange de clés qui dépend actuellement de RSA et ECC, et constitue donc la première cible de migration dans les flux sensibles.

ML-DSA, FIPS 204, est une signature numérique. Il garantit l'authenticité et l'intégrité : qu'une mise à jour logicielle provient de celui qu'elle prétend être, qu'un certificat est légitime, qu'un document n'a pas été altéré. Il entre dans les processus de migration PKI, de signature de code et de vérification.

SLH-DSA, FIPS 205, signe également, mais s'appuie sur le hachage, avec des prémisses différentes. Il est plus conservateur et tend à générer des abonnements plus importants. Il s’agit d’une réserve stratégique précieuse dont l’extrême longévité et la diversité des fondamentaux compensent le coût.

Notez que ces algorithmes ne vivent pas librement. Ils proviennent de bibliothèques, de bibliothèques de protocoles, de fournisseurs de cloud et de systèmes d'exploitation. Une grande partie de votre migration consistera à mettre à jour et à configurer ces dépendances à mesure qu'elles intègrent des normes, plutôt que d'implémenter le chiffrement manuellement.

L'approche hybride pendant la transition

Passer brusquement des algorithmes classiques aux algorithmes post-quantiques est risqué, et l’industrie a convergé vers une réponse plus sobre : le mode hybride.

Dans un échange de clé hybride, vous combinez l'algorithme classique tel qu'ECC avec l'algorithme post-quantique tel que ML-KEM, dérivant ainsi la clé de session des deux. La connexion n’est sécurisée que si les deux le sont. Cela constitue une garantie importante pendant la transition : vous bénéficiez d’une protection contre la menace quantique sans renoncer à la maturité de l’algorithme classique.

La logique est celle de la prudence. Les algorithmes post-quantiques sont robustes sur le papier, mais ont une portée opérationnelle bien inférieure à celle de RSA et ECC. Si une faiblesse d’implémentation ou un problème inattendu apparaît dans le composant post-quantique, le composant classique tient toujours la barre. Et si la menace quantique se matérialise, la composante classique tombe, mais la composante post-quantique maintient sa protection.

Le coût de l’hybride est réel : des clés et des poignées de main plus importantes, plus de traitement et de réglage des protocoles. Mais c’est la voie empruntée par les fournisseurs les plus sérieux, et l’adopter vous met en phase avec l’écosystème plutôt que contre lui.

Un soin de mise en œuvre qui sépare le sérieux du précipité

Un algorithme approuvé n’est pas synonyme de mise en œuvre sécurisée. C’est là que des projets bien intentionnés sont mis à mal.

N'implémentez pas vous-même la cryptographie post-quantique. Utilisez des bibliothèques matures, auditées et activement entretenues. Les paramètres de ces algorithmes sont sensibles et les détails de mise en œuvre, tels que les fuites sur les canaux secondaires, transforment un algorithme puissant en une protection contre les fuites. Il s’agit d’un travail d’expert et d’une révision de code, pas d’improvisation.

Prévoyez les nouvelles tailles. Les clés, signatures et messages de poignée de main post-quantiques sont plus volumineux que les messages classiques. Cela a un impact sur la taille des paquets, les limites du protocole, les certificats, le stockage et les performances. Les systèmes qui ont adopté une conception de petite taille peuvent se briser de manière subtile. Testez en charge et dans des conditions réelles de réseau.

Prenez soin des performances et de la compatibilité. La négociation d'algorithmes entre les clients et les serveurs à différentes étapes de la migration doit être planifiée, sinon vous perdez les connexions légitimes. Et assurez-vous d’une capacité de restauration : si une mise à jour post-quantique provoque un problème en production, vous avez besoin d’un moyen sûr de revenir en arrière, ce qui nous amène au sujet de la crypto-agilité.

Surtout, le design doit encore changer. La cryptographie post-quantique évoluera, les paramètres seront ajustés et vous ne voulez pas répéter un projet de plusieurs années à chaque changement. Ceux qui isolent le chiffrement derrière des couches bien définies modifient les algorithmes avec peu de changements. Celui qui répandra des chiffres dans le code en souffrira.