Certificats résistants au quantique : comment ML-DSA alourdit la chaîne de confiance du web

La vérification de clés a fait les manchettes, et elle les méritait. La clé de session que votre navigateur négocie aujourd’hui est déjà hybride. Mais un échange de clés ne protège que la conversation. Ce qui indique à votre navigateur que le serveur est bel et bien celui de votre banque, c’est une signature de certificat, et cette signature repose encore sur RSA ou ECDSA, deux schémas qu’un ordinateur quantique assez puissant pourrait falsifier. Remplacer ces signatures par ML-DSA est la tâche la plus ardue, et c’est là que Chrome et Windows passent de la théorie à la pratique.

Avant de lire : Les standards du NIST et la menace « récolter maintenant, déchiffrer plus tard » sont expliqués dans La bombe à retardement quantique : pourquoi les nouvelles normes de chiffrement du NIST ne peuvent pas attendre. Le déploiement de l’échange de clés dans les navigateurs est couvert dans Votre navigateur est déjà passé à l’ère quantique. Cet article traite de l’autre moitié : les signatures.

Table des matières

• La falsification suit une autre horloge
• Le passager devient plus lourd
• Le piège de l’amplification
• La sortie de secours de Chrome : les certificats à arbre de Merkle
• Windows doit parler la même langue
• Là où la migration cale
• Sources

La falsification suit une autre horloge

L’échange de clés comporte une menace rétroactive : on enregistre le trafic aujourd’hui, on le déchiffre en 2035. Les signatures ne fonctionnent pas ainsi. Un certificat falsifié ne compte qu’au moment où il sert à se faire passer pour un serveur, ce qui signifie qu’un attaquant a besoin d’un ordinateur quantique fonctionnel à ce moment précis, pas une décennie plus tôt. L’échéance semble donc plus lointaine, et c’est précisément le piège. Personne ne se fait congédier pour avoir reporté une migration d’authentification, jusqu’au jour où quelqu’un doit la casser.

Le passager devient plus lourd

Un certificat TLS, c’est essentiellement deux choses : une clé publique et une signature de l’autorité qui s’en porte garante. Une clé ECDSA P-256 classique fait 64 octets, et ses signatures tournent autour de 70 octets. ML-DSA-44, le plus petit paramètre du NIST, transporte une clé publique de 1 312 octets et une signature de 2 420 octets. ML-DSA-65 grimpe à 1 952 et 3 309 octets. L’enveloppe est restée la même. On a simplement remplacé le timbre par une caisse de transport.

Saviez-vous qu’une clé publique ML-DSA-44 et sa signature totalisent environ 3 700 octets? La paire RSA-2048 qu’elle remplace fait 512 octets. C’est à peu près sept fois plus de charge utile pour le même travail.

Une vraie chaîne comprend au minimum une feuille et un intermédiaire, et chacun transporte sa propre clé et la signature de son émetteur. Une seule feuille ML-DSA-44 dépasse déjà 3 ko avant même qu’on compte les noms et les extensions. Ajoutez un intermédiaire et la chaîne franchit les 6 ko avant que le serveur ait dit quoi que ce soit d’utile.

Le piège de l’amplification

QUIC contient une règle destinée à empêcher qu’un serveur serve de canon à trafic pour des paquets usurpés. Tant que l’adresse du client n’est pas validée, le serveur ne peut pas envoyer plus de trois fois les octets reçus. Le premier paquet d’un client fait au moins 1 200 octets, donc le serveur dispose d’environ 3 600 octets pour répondre avant d’être forcé d’attendre. Les chaînes de certificats classiques tiennent dans ce budget. Les chaînes ML-DSA, non, et la poignée de main cale pour un aller-retour supplémentaire (RFC 9000, section 8.1).

Les certificats ont toujours été la partie la plus spectaculaire d’une poignée de main TLS. Maintenant, ils sont aussi les plus lourds, et les allers-retours sont la seule chose qu’Internet ne peut pas acheter en tirant davantage de fibre.

La sortie de secours de Chrome : les certificats à arbre de Merkle

La solution évidente consiste à garder X.509 et à changer l’algorithme. La solution moins évidente, que Cloudflare et Chrome testent publiquement, ce sont les Merkle Tree Certificates. Au lieu que chaque certificat porte sa propre signature, une autorité de certification regroupe les certificats dans un grand arbre et ne signe que la racine, à intervalles réguliers. Le serveur envoie ensuite une preuve d’inclusion : les hachages frères qui relient son certificat à cette racine. Pour un arbre d’environ deux milliards d’entrées, cela représente 31 hachages de 32 octets, soit à peu près un kilo-octet, sans aucune signature ML-DSA par certificat.

Voici un fait amusant qui rend le concept moins exotique : les journaux de Certificate Transparency, dont le web dépend déjà, reposent sur le même type d’arbre de Merkle (RFC 6962). L’idée n’est pas étrangère à la plomberie du web.

Le hic, c’est la confiance. Le navigateur doit maintenant accepter un nouveau type d’objet, et le programme de racines de Chrome devient le gardien des arbres reconnus. Je pense que c’est là que la migration devient politique. Celui qui définit l’objet de confiance post-quantique décidera qui pourra émettre des certificats pour les vingt prochaines années.

L’horloge tourne déjà. Selon le projet de résolution SC-081 du CA/Browser Forum, la durée de validité maximale des certificats TLS publics tombe à 200 jours le 15 mars 2026, puis à 100 jours en 2027 et à 47 jours d’ici 2029. Des durées plus courtes signifient plus d’émissions, plus de signatures et plus de chances qu’une lourde chaîne ML-DSA atterrisse dans vos journaux. Quarante-sept jours semble un chiffre raisonnable, jusqu’à ce qu’on réalise qu’il faut renouveler à peu près toutes les six semaines, pour toujours.

Windows doit parler la même langue

La pile cryptographique de Windows, CNG, remonte à Windows Vista en 2007, et Microsoft y ajoute des primitives post-quantiques, dont ML-KEM et ML-DSA, par les mises à jour 2025 de Windows 11 et de Windows Server. Avoir l’algorithme dans la bibliothèque est la partie facile. Les chaînes de certificats qu’une entreprise fait réellement tourner sont une autre histoire : PKI interne, Active Directory Certificate Services, cartes à puce, signature de pilotes, appareils VPN. Chacun a son propre analyseur, ses propres hypothèses sur la taille des clés, et un fournisseur qui livre un micrologiciel une fois par année si vous avez de la chance.

Quiconque a vu un certificat interne expirer un vendredi après-midi sait déjà comment ça va se passer. Personne n’a une liste complète de tous les certificats émis par son entreprise, et le tableur qui prétend en être une est toujours faux.

Là où la migration cale

La critique facile de ML-DSA, c’est qu’il est gras. La critique plus sérieuse, c’est que les alternatives ne sont pas propres non plus. Falcon, en voie de normalisation sous le nom FN-DSA, produit des signatures d’environ 660 octets à son plus petit niveau, ce qui réglerait une bonne partie du problème de poids. Mais la signature de Falcon repose sur de l’arithmétique à virgule flottante, et une virgule flottante à temps constant est exactement le genre de détail qui tourne mal sur de petites puces embarquées. SLH-DSA, l’option basée sur le hachage de la FIPS 205, est prudente et bien comprise, mais ses plus petites signatures frôlent les 8 ko. Chaque option vous offre quelque chose et vous facture ailleurs.

Mon avis franc : la première vague de certificats ML-DSA sera lourde, lente et surtout invisible, logée dans des PKI privées et dans des micrologiciels qui ne seront jamais mis à jour. Le web public s’en sortira probablement, grâce aux arbres de Merkle et à la réduction des durées de validité. Le thermostat intelligent sur votre mur, lui, ne s’en sortira pas, et c’est la partie à laquelle personne ne budgète.

Sources

• NIST FIPS 204, Module-Lattice-Based Digital Signature Standard (ML-DSA), août 2024 : tailles des clés publiques et des signatures pour ML-DSA-44 et ML-DSA-65
• NIST FIPS 205 (SLH-DSA) et projet de FIPS 206 (FN-DSA, basé sur Falcon)
• RFC 9000, QUIC : A UDP-Based Multiplexed and Secure Transport, section 8.1 (validation d’adresse et limite d’amplification de 3x)
• RFC 6962, Certificate Transparency (construction du hachage d’arbre de Merkle)
• CA/Browser Forum, projet de résolution SC-081 : calendrier de réduction de la durée de validité des certificats
• Publications de Chrome et de Cloudflare Research sur les Merkle Tree Certificates et les certificats post-quantiques (2025)
• Blogue Windows Developer de Microsoft et notes de version de Windows sur les algorithmes post-quantiques de CNG (2025)
• Documentation Microsoft sur CNG (Cryptography API: Next Generation), introduite avec Windows Vista (2007)