Préparer TLS à la cryptographie post-quantique : que faut-il inventorier ?

Pour préparer la migration de TLS vers la cryptographie post-quantique, repérez les usages d’algorithmes à clé publique vulnérables aux attaques quantiques. Identifiez les équipes qui gèrent ces systèmes et les changements compatibles avec leurs clients. Le remplacement des certificats n’est qu’une partie du travail.

Normes publiées

Le NIST a finalisé trois normes de cryptographie post-quantique en août 2024 : ML-KEM pour l’établissement de clés, ML-DSA et SLH-DSA pour les signatures numériques. Ces algorithmes répondent à des usages différents.

Le sujet concerne surtout la cryptographie asymétrique : RSA, DSA, ECDSA, EdDSA, DH sur corps fini et ECDH. Le chiffrement symétrique et les fonctions de hachage ne sont pas affectés de la même façon. Un plan de préparation TLS ne doit donc pas présenter chaque suite cryptographique ou chaque fonction de hachage comme également compromise.

La feuille de route coordonnée de l’UE prévoit une transition vers la PQC préparée par les États membres et les organisations concernées. Les acheteurs européens peuvent s’y référer pour planifier leur migration.

Algorithme Norme Rôle Note opérationnelle

ML-KEM FIPS 203 Établissement des clés La famille d’algorithmes la plus directement concernée par les travaux sur l’échange de clés TLS.

ML-DSA FIPS 204 Signatures numériques Concerne les futurs mécanismes de signature des certificats et des logiciels.

SLH-DSA FIPS 205 Signatures numériques Une norme de signature fondée sur le hachage, qui permet de disposer d’une autre famille d’algorithmes.

Établissement de clés et authentification par certificat

Planifiez séparément l’établissement de clés et l’authentification par certificat : ces deux fonctions utilisent des algorithmes différents et ont leurs propres contraintes de compatibilité.

Établir les clés de session

ClientServeur

Protéger les données échangées

ECDHE · ML-KEM

Authentifier le serveur

ClientServeur

Vérifier son identité grâce aux certificats et signatures

X.509 · CertificateVerify

L’utilisation d’un échange de clés post-quantique ne rend pas la chaîne de certificats post-quantique. Ce sont deux migrations distinctes.

Protocoles et prise en charge

Établissement des clés

Il s’agit de la partie de la négociation TLS qui crée les secrets de session. L’établissement de clés hybride ECDHE-MLKEM est publié dans la RFC 10024 ; les groupes nommés ML-KEM autonomes restent un projet. Les deux dépendent de la prise en charge par les clients, les serveurs, les bibliothèques et les règles applicables.

Authentification par certificat

Il s’agit de la chaîne de certificats X.509 utilisée pour authentifier le serveur. Des RFC existent pour les identifiants ML-DSA, SLH-DSA et ML-KEM dans X.509, mais ce n’est pas la même chose que la prise en charge en production des certificats de serveur TLS de confiance publique.

Prioriser selon la durée de confidentialité des données

À court terme, une raison importante de préparer la transition vers la PQC est le risque « collecter maintenant, déchiffrer plus tard » : un attaquant peut enregistrer aujourd’hui du trafic chiffré et tenter de le déchiffrer ultérieurement si un ordinateur quantique pertinent pour la cryptanalyse devient disponible. Ce risque est particulièrement important lorsque les données doivent rester confidentielles pendant des années.

Un site marketing, une interface d’administration interne, un portail de paie et un service d’export de données clients ont des exigences de confidentialité différentes. Appuyez-vous sur ces exigences pour prioriser leur migration.

La migration des signatures de certificats répond à un autre risque. Elle concerne l’authentification future, les chaînes de confiance, les règles des programmes racines, le comportement de Certificate Transparency et la compatibilité des clients. Elle ne permet pas de déchiffrer un trafic déjà enregistré.

Ce que les équipes peuvent faire dès maintenant

Recensez les usages de RSA, ECDSA, EdDSA, DH sur corps fini et ECDH dans les certificats, les points de terminaison TLS, les équipements, les répartiteurs de charge, les VPN et les services gérés.
Consignez quels systèmes assurent la terminaison TLS, quels certificats ils présentent, quelles équipes en ont la responsabilité et quels fournisseurs contrôlent la pile cryptographique.
Classez les données selon leur durée de confidentialité. Les données confidentielles qui doivent le rester longtemps modifient les priorités ; ce n’est généralement pas le cas des courtes sessions web publiques.
Demandez aux fournisseurs des dates précises et le nom exact des mécanismes pris en charge : ML-KEM plutôt que les versions de Kyber antérieures à sa normalisation, ML-DSA, SLH-DSA, TLS hybride, validation d’algorithme CAVP, validation de module FIPS 140-3 si nécessaire, ainsi que le comportement en cas de rétrogradation ou de repli.
Ne testez TLS hybride que lorsque la population de clients est connue et qu’un retour arrière est simple. Mesurez la latence, la taille de la négociation, le comportement des équipements intermédiaires et l’observabilité.
Évitez de considérer la réémission de certificats comme un plan de migration. Les règles applicables aux certificats publics et la compatibilité des clients restent importantes.

Ce qu’il ne faut pas faire

Acheter un produit seulement parce qu’il se prétend « résistant aux attaques quantiques ».
Remplacer tous les certificats publics avant que les navigateurs, autorités de certification et clients ne prennent en charge les algorithmes concernés.
Supposer qu’un échange de clés PQC fournit aussi des signatures de certificats PQC.
Traiter la PQC et la distribution quantique de clés comme un seul et même projet de migration.
Négliger la responsabilité, le renouvellement et l’hygiène TLS des certificats existants au motif que la PQC paraît plus stratégique.

La place de Nocert

Nocert n’émet pas de certificats et ne réalise pas la migration des services vers la cryptographie post-quantique. Les espaces Compliance de Business et Custom présentent les algorithmes des certificats, les résultats des contrôles TLS et les preuves horodatées issus des observations publiques et internes.

Utilisez ces observations pour préparer votre migration. Pour chaque système, consignez l’équipe responsable, le fournisseur, les algorithmes et les contraintes de compatibilité.

Sources primaires

Cette note est basée sur les normes NIST PQC et les conseils de migration, les travaux de l’IETF TLS et X.509, les exigences de base du CA/Browser Forum et la feuille de route PQC coordonnée par l’UE.