Migration PKI Post-Quantique : Feuille de Route DSI

La PKI — Infrastructure à Clé Publique — est la colonne vertébrale cryptographique de tout système d'information moderne. Elle gère les certificats qui authentifient les serveurs (TLS), les utilisateurs (authentification par certificat), les applications (signature de code), les emails (S/MIME) et les documents (signatures numériques). C'est précisément parce que la PKI est omniprésente qu'elle représente le chantier de migration post-quantique le plus complexe, mais aussi le plus critique. Un certificat PKI compromis par un ordinateur quantique n'invalide pas seulement une connexion : il peut invalider rétroactivement des années de signatures numériques, ouvrir des failles dans l'ensemble de la chaîne d'authentification, et remettre en cause la valeur probante de contrats et documents signés électroniquement. Pour les DSI français qui doivent planifier la période 2025-2030, la migration PKI post-quantique n'est pas une option : c'est le chantier fondateur à partir duquel toutes les autres migrations s'organisent.

Comprendre la PKI comme fondation cryptographique du SI

Avant d'aborder la migration, rappelons pourquoi la PKI est si centrale. Toute communication sécurisée dans un SI moderne repose ultimement sur la confiance envers une autorité de certification (CA). Lorsque votre navigateur se connecte à votre intranet en HTTPS, il vérifie le certificat du serveur, remonte la chaîne de certification jusqu'à un certificat CA racine qu'il connaît et auquel il fait confiance. Cette chaîne de confiance n'est valide que si :

• La clé privée de chaque CA dans la chaîne n'a jamais été compromise.
• Les algorithmes de signature utilisés sont toujours considérés sûrs.
• Les certificats n'ont pas expiré.

Si un ordinateur quantique peut casser la clé privée RSA de votre CA racine (ou la recalculer à partir de la clé publique, qui est publique dans le certificat racine), toutes les signatures émises par cette CA depuis sa création sont potentiellement falsifiables. Un adversaire disposant d'un CRQC pourrait signer de faux certificats au nom de votre CA, empoisonner votre PKI et se faire passer pour n'importe quel serveur de votre SI.

Pourquoi migrer la PKI en premier

L'effet de levier de la CA racine

La CA racine est l'actif cryptographique le plus sensible du SI. Elle signe les certificats des CA intermédiaires, qui signent les certificats des serveurs et des utilisateurs. Sa clé privée est généralement stockée dans un HSM hors ligne, avec des durées de vie de 20 ans. Si cette clé est RSA-4096, elle sera vulnérable à un CRQC capable de traiter des clés de cette taille — ce qui arrivera plus tôt qu'une clé RSA-2048 n'y résistera, mais l'arrivera quand même.

Migrer la CA racine vers un algorithme post-quantique entraîne automatiquement la migration de toute la chaîne de certification en aval. C'est l'effet de levier maximal : un seul changement à la racine se propage à l'ensemble de la PKI.

Les durées de vie et le risque HNDL

Une CA racine avec une durée de vie de 20 ans et une clé RSA crée le risque HNDL maximal : la clé publique de cette CA est accessible à quiconque télécharge le certificat racine (qui est par définition public). Dès aujourd'hui, un adversaire peut enregistrer cette clé publique et attendre de disposer d'un CRQC pour calculer la clé privée correspondante. Si un CRQC devient disponible en 2033 et que votre CA racine court jusqu'en 2035, la fenêtre de vulnérabilité est réelle.

La politique de cryptographie ISO 27001 doit explicitement limiter la durée de vie des clés asymétriques à l'horizon de sécurité post-quantique estimé, ou prévoir un renouvellement anticipé.

Les certificats hybrides : la solution de transition

La migration PKI ne peut pas être instantanée. Pendant plusieurs années, des clients anciens (navigateurs non mis à jour, systèmes embarqués, partenaires non migrés) ne comprendront que les algorithmes classiques RSA et ECDSA. Supprimer ces algorithmes du jour au lendemain casserait les connexions de ces clients.

Principe du certificat hybride

Un certificat hybride contient deux paires de clés : une classique (RSA-2048 ou ECDSA P-256) et une post-quantique (ML-DSA-65). Il est signé avec les deux algorithmes — par la CA classique et par la CA post-quantique. Un client classique ne voit que la signature RSA/ECDSA et valide normalement. Un client post-quantique utilise la signature ML-DSA, qui offre la protection contre les attaques quantiques.

Le standard technique pour les certificats composites est le draft IETF `draft-ietf-lamps-pq-composite-sigs`, en cours de finalisation. DigiCert, Entrust et Keyfactor proposent déjà des implémentations expérimentales. La finalisation du standard est attendue pour 2025-2026.

Architecture PKI hybride

Pour déployer une PKI hybride, il faut :

• Une CA racine classique existante (RSA ou ECC) — à conserver temporairement.
• Une nouvelle CA racine post-quantique (ML-DSA) — à créer.
• Des CA intermédiaires émettant des certificats composites, signés par les deux CA racines.
• Une infrastructure de distribution (CDP, OCSP, AIA) mise à jour pour les deux chaînes.

Cette architecture double PKI est temporaire : une fois que tous les clients seront capables de traiter les certificats ML-DSA purs, la CA classique sera retirée. La durée de cette période de transition est estimée entre 5 et 10 ans.

Feuille de route PKI post-quantique 2025-2030

Phase 1 (2025-2026) : Préparation et infrastructure

Audit de la PKI existante : inventaire complet de toutes les CA (racine, intermédiaires, émettrices), de leurs algorithmes, durées de vie et usages. Cartographie de tous les systèmes qui consomment des certificats PKI. Identification des HSM et de leur roadmap PQC.

Qualification des HSM : les HSM actuels (Thales nShield, Utimaco CryptoServer, SafeNet Luna) doivent être vérifiés pour leur support de ML-DSA. La plupart des modèles récents offrent ce support via mise à jour firmware. Les modèles anciens devront être remplacés — planifiez ce remplacement avec un délai de 12 à 18 mois (cycle d'appel d'offres, livraison, intégration, tests).

Mise à jour de l'ADCS ou de la solution PKI : Microsoft Active Directory Certificate Services (ADCS) devrait intégrer le support ML-DSA dans Windows Server 2025 et ses mises à jour. Les solutions PKI commerciales (EJBCA, Keyfactor) ont des feuilles de route claires pour 2025-2026. Planifiez les mises à jour de votre solution PKI.

Formation des équipes PKI : les opérateurs de CA, les administrateurs de HSM et les équipes DevOps consommatrices de certificats doivent être formés aux concepts PQC et aux nouveaux workflows de gestion de certificats hybrides.

Phase 2 (2026-2027) : Déploiement pilote et CA hybride

Création d'une CA racine PQC hors production : dans un environnement de test, créer une CA racine ML-DSA-87, des CA intermédiaires hybrides, et émettre des certificats de test. Valider le processus d'émission, la distribution (CRL, OCSP), l'installation sur les serveurs web et l'acceptation par les navigateurs.

Pilote TLS hybride : déployer les certificats hybrides sur 10 à 20 serveurs représentatifs (mix de serveurs web internes et exposés, d'APIs, de serveurs d'authentification). Monitorer pendant 3 à 6 mois les erreurs de connexion, les performances et l'acceptation client.

Pilote authentification client : pour les organisations utilisant l'authentification par certificat client (accès VPN, accès applicatif), tester les certificats hybrides côté client sur un groupe pilote d'utilisateurs. Identifier les systèmes de validation qui ne supportent pas encore les certificats composites.

Phase 3 (2027-2029) : Migration en production

Création de la CA racine PQC de production : cérémonies de création de CA, génération des clés dans les HSM PQC, signature croisée avec la CA racine classique existante pour assurer l'interopérabilité, distribution du nouveau certificat racine dans les trust stores.

Migration progressive des CA intermédiaires : renouvellement des CA intermédiaires en certificats hybrides, déploiement par domaine fonctionnel (serveurs web, authentification, signature de code).

Renouvellement des certificats feuilles : remplacement progressif de tous les certificats de serveur, d'authentification et de signature par des certificats hybrides ML-DSA. Ce renouvellement peut être largement automatisé via les outils ACME (Let's Encrypt protocol), les intégrations DevOps (HashiCorp Vault, cert-manager Kubernetes), et les agents Keyfactor ou Venafi.

La procédure de gestion des changements doit être appliquée à chaque étape, avec des tests de retour arrière documentés.

Phase 4 (2029-2030) : Consolidation et retrait du classique

Retrait des certificats RSA/ECDSA purs : une fois que tous les clients connus supportent les certificats ML-DSA, commencer le retrait des algorithmes classiques des suites cipher et des profils de certificats.

Déclassement de la CA racine classique : révocation et archivage de la CA racine RSA, nettoyage des trust stores.

Audit de conformité post-quantique : vérification que l'ensemble du SI utilise uniquement des algorithmes post-quantiques approuvés, à l'exception des systèmes legacy documentés et isolés.

Microsoft, DigiCert, Let's Encrypt et PQC : état des lieux

Microsoft

Microsoft a annoncé son engagement envers la cryptographie post-quantique dans plusieurs documents publics. Windows Server 2025 intègre les mises à jour des bibliothèques cryptographiques (CNG - Cryptography Next Generation) pour supporter ML-KEM et ML-DSA. Azure Key Vault a annoncé une roadmap pour les clés post-quantiques. L'Active Directory Certificate Services sera mis à jour pour émettre des certificats ML-DSA, probablement en 2026. La politique de sécurité réseau doit anticiper ces mises à jour dans les environnements Microsoft.

DigiCert

DigiCert est le pionnier des certificats hybrides post-quantiques parmi les CAs publiques. Dès 2022, DigiCert émettait des certificats expérimentaux ML-DSA + ECDSA. En 2024, l'entreprise a annoncé la disponibilité générale des certificats hybrides pour ses clients enterprise. DigiCert est également impliqué dans les travaux IETF de standardisation des certificats composites — ses implémentations sont donc proches du standard final.

Let's Encrypt

Let's Encrypt, l'AC gratuite utilisée par des millions de sites web, a annoncé son intention de supporter les certificats ML-DSA lorsque les standards seront finalisés et que les navigateurs les supporteront. La feuille de route précise n'est pas encore publiée, mais la communauté ACME travaille sur les extensions protocolaires nécessaires. Pour les serveurs web publics utilisant Let's Encrypt, la migration sera probablement transparente via la mise à jour automatique des clients certbot.

Autres autorités de certification françaises

CertEurope, Certigna et Chambersign — les principales ACs françaises pour les usages réglementés (signature électronique qualifiée eIDAS) — n'ont pas encore publié de feuilles de route PQC détaillées. Pour les usages eIDAS (signature qualifiée, cachets qualifiés), attendez les orientations de l'ANSSI et de l'ACPR sur les délais de migration. Les certificats eIDAS qualifiés nécessitent une re-qualification de l'AC — processus long et coûteux. Anticipez des délais supplémentaires par rapport aux certificats internes.

TLS 1.3 + PQC : la combinaison cible

TLS 1.3, finalisé en 2018, est conçu avec une meilleure séparation entre l'authentification (certificats) et l'échange de clés (Diffie-Hellman). Cette séparation facilite la migration post-quantique :

• Échange de clés : remplacé par ML-KEM-768 (ou hybride X25519+ML-KEM). Configurable via les groupes TLS 1.3 — un seul changement de configuration sur le serveur.
• Authentification : certificat ML-DSA ou hybride. Nécessite une CA émettant des certificats ML-DSA — le chantier PKI décrit plus haut.
• Protection des données : AES-256-GCM ou ChaCha20-Poly1305 — déjà post-quantiquement sûrs, pas de changement nécessaire.

Les extensions TLS pour le PQC sont en cours de standardisation à l'IETF (RFC en preparation). La compatibilité avec les équipements d'inspection TLS (firewalls next-gen, proxies SSL) doit être vérifiée auprès de chaque fournisseur — certains équipements ne reconnaissent pas encore les nouveaux identifiants de groupes TLS et bloquent silencieusement les connexions hybrides.

Gestion des sous-traitants et de la chaîne d'approvisionnement PKI

La PKI d'entreprise inclut souvent des cas d'usage impliquant des tiers : certificats émis pour des serveurs hébergés chez des prestataires, certificats d'authentification utilisés par des partenaires, certificats de signature pour des échanges EDI. La migration post-quantique doit être coordonnée avec ces tiers.

Le registre des sous-traitants doit intégrer une colonne "maturité PQC" et les dates d'engagement de migration. Les clauses contractuelles avec les prestataires hébergeant des serveurs avec vos certificats doivent inclure des exigences de compatibilité avec les certificats hybrides et un délai de migration.

Pour les échanges avec des partenaires utilisant mutuellement des certificats d'authentification (authentification mutuelle TLS, EDI X12/EDIFACT signé), des protocoles de coordination bilatérale sont nécessaires — ni l'un ni l'autre ne peut migrer seul sans casser les échanges.

Cas spécifiques : OT, IoT et systèmes embarqués

Les systèmes industriels (OT/SCADA) et les équipements IoT représentent le cas le plus difficile de la migration PKI post-quantique. Ces systèmes ont des contraintes que les systèmes IT classiques n'ont pas :

• Ressources limitées : les microcontrôleurs et systèmes embarqués ont des capacités de calcul et de mémoire insuffisantes pour certains algorithmes PQC (ML-DSA produit des signatures de 2,4 ko, problématique pour des protocoles contraints).
• Durées de vie longues : les équipements industriels ont des durées de vie de 15 à 25 ans — bien au-delà de l'horizon CRQC.
• Impossibilité de mise à jour : certains systèmes embarqués ne peuvent pas recevoir de mises à jour logicielles post-déploiement.
• Protocoles propriétaires : des protocoles industriels non standardisés peuvent ne pas supporter les nouvelles suites crypto.

Pour ces systèmes, la stratégie recommandée est la gateway PQC : un boîtier intermédiaire qui gère la couche cryptographique post-quantique côté réseau IT et présente une interface classique à l'équipement embarqué. Des solutions comme celles de Thales ou Fortanix implémentent cette architecture. Alternativement, des algorithmes PQC optimisés pour les systèmes contraints (CRYSTALS-Kyber avec des paramètres réduits, McEliece pour les équipements très contraints en calcul) peuvent être envisagés.

Pour approfondir, consultez les recommandations officielles : NIST Post-Quantum Cryptography et le guide de l'ANSSI sur les mécanismes cryptographiques.

FAQ

Quand dois-je renouveler ma CA racine pour la passer en post-quantique ?

Si votre CA racine expire avant 2030 et que vous devez la renouveler de toute façon, c'est le moment idéal pour la passer en ML-DSA ou hybride. Si elle court jusqu'en 2035 ou au-delà, ne l'attendez pas — planifiez un renouvellement anticipé entre 2027 et 2028 pour être en avance sur l'horizon CRQC probable. La recommandation de l'ANSSI est de commencer les démarches de migration PKI dès maintenant, avec des pilotes en 2026 et une migration complète avant 2030.

Est-ce que Let's Encrypt va migrer automatiquement mes certificats vers PQC ?

Let's Encrypt prévoit de supporter ML-DSA lorsque les standards seront stabilisés et les navigateurs compatibles. La migration sera probablement automatique via le client ACME (certbot) qui renouvellera les certificats avec les nouveaux algorithmes. Cependant, si votre serveur n'est pas compatible avec les nouvelles suites cipher (OpenSSL trop ancien, par exemple), le renouvellement pourrait échouer. Maintenez votre stack TLS à jour pour faciliter cette transition.

Les certificats hybrides sont-ils acceptés par tous les navigateurs ?

En 2026, les certificats hybrides composites (format IETF) ne sont pas encore standardisés et ne sont pas acceptés nativement par les navigateurs principaux. Des pilotes expérimentaux existent chez DigiCert et Google. La standardisation complète et l'adoption par les navigateurs sont attendues pour 2026-2027. En attendant, les déploiements de certificats hybrides se font dans des environnements contrôlés (PKI interne, authentification mutuelle TLS) où les clients peuvent être configurés pour accepter ces certificats.

Quel est l'impact des certificats ML-DSA sur les performances de mes serveurs ?

ML-DSA-65 génère des signatures plus lourdes (2,4 ko contre 64 octets pour ECDSA P-256) et est légèrement plus lent en vérification. Pour un serveur web standard, l'impact sur les performances est inférieur à 5% pour le handshake TLS — négligeable en pratique. L'impact est plus significatif pour des services à très fort volume de connexions courtes (APIs REST à haute fréquence, CDN). Dans ces cas, des benchmarks spécifiques sont recommandés avant déploiement en production.