La cryptographie que nous utilisons aujourd'hui pour sécuriser les certificats numériques repose sur des problèmes mathématiques que les ordinateurs classiques ne savent pas résoudre efficacement.
RSA repose sur la factorisation d'entiers. Soit N = p * q, où p et q sont de grands nombres premiers. Retrouver p et q à partir de N seul est calculatoirement infaisable pour les machines classiques. Le meilleur algorithme classique connu (General Number Field Sieve) s'exécute en temps sous-exponentiel : O(exp((64/9 * n)^(1/3) * (log n)^(2/3))), où n = log2(N).
ECDSA repose sur le problème du logarithme discret sur courbes elliptiques. Soit un point Q = k * G sur une courbe E définie sur un corps fini Fp. Retrouver le scalaire k à partir de Q et G est calculatoirement difficile. La meilleure attaque classique (rho de Pollard) s'exécute en O(sqrt(n)) où n est l'ordre du groupe.
L'algorithme de Shor change fondamentalement l'équation. Sur un ordinateur quantique, la factorisation d'entiers et le logarithme discret sont tous deux résolubles en temps polynomial : O((log N)^3). Une clé RSA de 4096 bits qui prendrait aux ordinateurs classiques plus que l'âge de l'univers à factoriser pourrait être cassée en quelques heures.
Ce n'est plus une hypothèse théorique. C'est un calendrier.
Le compte à rebours est public
En 2024, le NIST a finalisé ses trois premiers standards de cryptographie post-quantique.
FIPS 203 (ML-KEM) pour l'encapsulation de clés. FIPS 204 (ML-DSA, anciennement Dilithium) pour les signatures numériques. FIPS 205 (SLH-DSA, anciennement SPHINCS+) pour les signatures stateless.
La même année, la NSA a publié la version 2.0 de CNSA (Commercial National Security Algorithm Suite). Les échéances sont explicites et catégorisées.
D'ici 2030, la signature logicielle et les équipements réseau traditionnels devront utiliser exclusivement les algorithmes CNSA 2.0. D'ici 2033, les services web, systèmes d'exploitation et équipements restants devront avoir achevé la transition. L'objectif final est une résistance quantique complète sur tous les systèmes de sécurité nationale d'ici 2035.
Ces échéances ne concernent pas uniquement le secteur gouvernemental. Elles définissent la trajectoire pour l'ensemble de l'écosystème. Les régulateurs européens, l'ANSSI en France, le BSI en Allemagne, suivent des trajectoires similaires.
"Harvest now, decrypt later" : la menace qui commence aujourd'hui
L'argument classique consiste à dire que les ordinateurs quantiques capables de casser RSA-2048 n'existent pas encore. C'est exact.
Mais le modèle de menace ne commence pas le jour où la machine existe. Il commence le jour où les données sont capturées.
Un adversaire étatique ou un acteur avancé peut intercepter et stocker du trafic chiffré aujourd'hui. Des échanges TLS. Des VPN. Des communications sensibles. Ces données sont incompréhensibles maintenant, mais elles sont patientes.
Le jour où un ordinateur quantique sera opérationnel, tout ce qui a été capturé pourra être déchiffré rétroactivement.
Pour les organisations qui manipulent des données à longue durée de vie (propriété intellectuelle, secrets industriels, données médicales, informations classifiées), la fenêtre de vulnérabilité est déjà ouverte.
Ce risque porte un nom : "harvest now, decrypt later". Et il ne concerne pas le futur. Il concerne le présent.
Les certificats sont au centre de la transition
Quand on parle de transition post-quantique, on pense d'abord au chiffrement des communications. TLS, VPN, messagerie.
Mais les certificats numériques X.509 sont le socle de toute cette infrastructure. Ils portent les clés publiques. Ils authentifient les serveurs, les utilisateurs, les machines. Ils signent le code, les documents, les timestamps.
Chaque certificat contient un algorithme de signature. Si cet algorithme devient vulnérable, le certificat ne prouve plus rien.
La transition post-quantique pour une PKI ne se limite pas à "changer l'algorithme de la CA". Elle implique plusieurs dimensions.
Les autorités de certification doivent pouvoir émettre avec de nouveaux algorithmes. Les templates de certificats doivent supporter les nouvelles tailles de clés et les nouveaux OIDs. Les clients (navigateurs, applications, systèmes) doivent pouvoir valider ces certificats. Les chaînes de confiance doivent être reconstruites ou étendues.
Et tout cela doit se faire progressivement, sans casser l'existant.
Trois stratégies de migration, pas une seule
La communauté cryptographique a identifié plusieurs approches pour la transition. Leur maturité varie. Certaines sont standardisées, d'autres encore en draft. Chacune répond à des contraintes différentes.
Certificats classiques avec algorithmes PQC
L'approche la plus directe. On remplace RSA ou ECDSA par ML-DSA ou SLH-DSA dans les certificats. La structure X.509 reste identique, seul l'algorithme change.
L'avantage est la simplicité conceptuelle. L'inconvénient est que les clients qui ne supportent pas encore ces algorithmes rejetteront le certificat. C'est un big bang.
Certificats liés (RFC 9763)
Cette approche émet deux certificats liés pour chaque identité. Un certificat classique (RSA ou ECDSA) et un certificat post-quantique (ML-DSA). Les deux sont liés via une extension RelatedCertificate qui contient un hash du certificat apparié, créant un lien cryptographique vérifiable.
Le client choisit le certificat qu'il peut valider. S'il supporte le PQC, il utilise le certificat post-quantique. Sinon, il se rabat sur le classique. La transition est progressive et rétrocompatible.
Cette approche suppose que l'infrastructure PKI peut gérer des paires de CA (une classique et une PQC) et émettre les deux certificats de manière atomique.
Certificats composites (draft IETF)
Un seul certificat contient deux clés et deux signatures. Une classique et une post-quantique, combinées dans un OID composite unique.
Le certificat est valide si au moins une des deux signatures est vérifiable. La sécurité est maximale : même si l'un des deux algorithmes est cassé, l'autre protège encore.
Les OIDs composites comme id-MLDSA44-ECDSA-P256-SHA256 ou id-MLDSA65-ECDSA-P384-SHA512 sont actuellement à l'état de draft à l'IETF. Ils ne sont pas encore finalisés et pourraient évoluer.
Cette approche est conceptuellement la plus robuste mais aussi la moins mature. Elle nécessite que les clients comprennent les OIDs composites, et le manque de standardisation finale limite aujourd'hui son adoption en production. Elle reste pertinente pour des pilotes et de la R&D.
Signatures alternatives (extensions X.509 AltSignature)
Une quatrième approche utilise les extensions altSignatureAlgorithm et altSignatureValue définies dans ITU-T X.509 (édition 2019). Le certificat porte une signature principale avec un algorithme (par exemple ECDSA) et embarque une seconde signature alternative avec un autre algorithme (par exemple ML-DSA) directement dans les extensions X.509.
Contrairement aux certificats composites, AltSignature ne définit pas de nouvel OID combiné. Elle réutilise les mécanismes d'extension X.509 standards. Un client qui comprend les extensions valide les deux signatures. Un client qui ne les comprend pas les ignore simplement et valide la signature principale seule.
Cela rend AltSignature intrinsèquement rétrocompatible : les clients existants continuent de fonctionner, tandis que les clients mis à jour bénéficient de la vérification post-quantique.
Toutefois, cette approche introduit un risque subtil. Si un client ne valide que la signature principale (classique) et ignore complètement la signature alternative, la protection post-quantique est effectivement absente. Le certificat paraît hybride mais n'offre qu'une sécurité classique. Inversement, un attaquant capable de forger une signature classique pourrait fabriquer un certificat qui passe la validation sur les clients qui ne vérifient que la signature principale. La garantie de sécurité dépend entièrement de l'implémentation client, ce qui est difficile à imposer dans un écosystème hétérogène.
AltSignature est actuellement supporté par certains outils PKI et fait l'objet d'évaluations par plusieurs organismes de normalisation. Cette approche offre un chemin de migration pragmatique mais nécessite une attention particulière au comportement de validation côté client.
L'inventaire cryptographique : première étape non négociable
Avant de migrer quoi que ce soit, il faut savoir ce qu'on a.
Combien de certificats sont actifs dans l'organisation. Quels algorithmes et quelles tailles de clés sont utilisés. Quelles autorités de certification les ont émis. Quand ils expirent. Quels systèmes en dépendent.
Cet inventaire cryptographique semble trivial. En pratique, il est rarement complet.
Les certificats se trouvent dans des endroits multiples. Les serveurs web, les load balancers, les bases de données, les APIs internes, les IoT devices, les postes de travail, les smartcards, les HSMs, les keystores Java, les secrets Kubernetes.
Sans inventaire exhaustif, toute planification de migration est approximative. On ne peut pas prioriser ce qu'on ne connaît pas.
Un inventaire cryptographique complet permet de répondre à une question simple : quel pourcentage de nos certificats utilise des algorithmes vulnérables au quantique, et dans combien de temps expirent-ils ?
La crypto-agilité : concevoir pour le changement
La crypto-agilité est la capacité d'une infrastructure à changer d'algorithme cryptographique sans refonte majeure.
En théorie, tout le monde est d'accord. En pratique, très peu d'infrastructures PKI sont crypto-agiles.
Une CA qui ne supporte que RSA n'est pas crypto-agile. Un template de certificat qui impose un algorithme unique n'est pas crypto-agile. Un workflow d'émission qui assume un format de clé fixe n'est pas crypto-agile. Un CLM qui ne peut pas orchestrer plusieurs types de CA n'est pas crypto-agile.
La crypto-agilité se construit à plusieurs niveaux.
Au niveau des CA, elles doivent pouvoir émettre avec plusieurs familles d'algorithmes. Au niveau du CLM, il doit pouvoir router les demandes vers la bonne CA selon l'algorithme requis. Au niveau des protocoles d'émission, ACME et EST doivent supporter les nouveaux types de clés. Au niveau de l'inventaire, il faut visualiser la répartition algorithmique et planifier la migration.
L'écosystème n'est pas prêt. Et c'est normal
Les algorithmes sont standardisés. Mais entre un standard NIST et un certificat ML-DSA validé par un navigateur en production, il y a un écosystème entier qui doit évoluer.
Aujourd'hui, la réalité est la suivante.
OpenSSL 3.5 (publié en avril 2025) intègre un support natif pour ML-KEM, ML-DSA et SLH-DSA, avec ML-KEM comme key-share TLS 1.3 par défaut. Toutefois, la majorité des systèmes en production utilisent encore des versions antérieures qui nécessitent le provider OQS pour tout support PQC. Les navigateurs supportent l'échange de clés hybride ML-KEM en TLS, mais ne valident pas encore les signatures PQC dans les certificats X.509. Les HSMs de quelques vendors commencent à supporter ML-DSA, souvent via des firmwares spécifiques non généralisés. Les langages et frameworks (Java, Go, Python) disposent de librairies expérimentales, pas de support natif dans leurs bibliothèques standards. Les équipements réseau, load balancers, et reverse proxies ne valident pas les signatures post-quantiques. Les protocoles d'automatisation comme ACME et EST ne spécifient pas encore de profils PQC.
Ce décalage entre la maturité des algorithmes et la maturité de l'écosystème est normal. Il s'est produit pour chaque transition cryptographique précédente : SHA-1 vers SHA-2, RSA-1024 vers RSA-2048, TLS 1.0 vers TLS 1.2.
Cela ne signifie pas qu'il faut attendre. Cela signifie que la phase actuelle est celle de la préparation, pas du déploiement massif. Inventorier, architecturer pour la crypto-agilité, lancer des pilotes internes sur des périmètres non critiques. Quand l'écosystème sera prêt, les organisations qui auront préparé leur PKI pourront basculer. Les autres devront tout faire en urgence.
Ce que la transition va concrètement exiger
Pour les équipes PKI, la transition post-quantique va se traduire en actions concrètes.
Créer de nouvelles autorités de certification avec des algorithmes PQC, en parallèle des CA classiques existantes. Définir des profils de certificats qui supportent les nouveaux algorithmes, tout en maintenant la compatibilité avec l'existant. Mettre en place un mécanisme d'émission dual ou composite pour les cas où la rétrocompatibilité est nécessaire. Adapter les chaînes de confiance pour que les clients puissent valider les nouvelles CA. Automatiser le renouvellement pour que le basculement se fasse progressivement, certificat par certificat, au fil des expirations. Monitorer la couverture PQC dans l'inventaire pour suivre l'avancement de la migration.
Ce n'est pas un projet ponctuel. C'est une transformation progressive qui va s'étaler sur plusieurs années.
Les erreurs à éviter
Plusieurs erreurs sont prévisibles dans cette transition.
Attendre que les standards soient "définitifs". Les trois premiers FIPS sont finalisés. Les OIDs composites sont en cours mais suffisamment stables pour des pilotes. Attendre la perfection, c'est accumuler de la dette technique.
Traiter la migration comme un projet uniquement crypto. C'est un projet d'infrastructure. Il implique les équipes PKI, les équipes DevOps, les équipes sécurité, et les équipes applicatives.
Vouloir tout migrer en une fois. La transition sera progressive. Commencer par les certificats internes les moins critiques, valider le workflow, puis étendre.
Ignorer l'inventaire. Sans cartographie complète des certificats existants, la planification est impossible. C'est la première étape, non négociable.
Oublier l'automatisation. La transition va multiplier les types de certificats et les workflows. Sans ACME ou EST pour automatiser, la charge opérationnelle sera insoutenable.
Le bon moment pour commencer
La question n'est pas de savoir si la transition post-quantique va arriver. Les standards sont publiés. Les calendriers sont fixés. Les régulateurs avancent.
La question est de savoir si votre PKI est prête à l'absorber.
Cela commence par trois actions.
Dresser l'inventaire cryptographique de vos certificats actifs. Évaluer la crypto-agilité de votre infrastructure PKI actuelle. Lancer un pilote sur un périmètre limité avec des certificats PQC ou hybrides.
Les organisations qui commencent maintenant auront le temps de migrer progressivement. Les autres devront le faire dans l'urgence quand les deadlines réglementaires arriveront.
Et dans l'urgence, on ne fait pas de bonnes architectures.
Références
- FIPS 203 : ML-KEM (NIST, août 2024)
- FIPS 204 : ML-DSA (NIST, août 2024)
- FIPS 205 : SLH-DSA (NIST, août 2024)
- RFC 9763 : Related Certificates for Use in Multiple Authentications (IETF, 2025)
- Composite ML-DSA Internet-Draft (IETF LAMPS WG)
- CNSA 2.0 Algorithm Suite (NSA)
- Position de l'ANSSI sur la transition post-quantique (ANSSI)
