Le secret ne tient pas à un algorithme plus compact. Les MTCs revoient la façon dont les certificats sont émis, si bien que la plupart des signatures disparaissent du handshake.

Dans notre article sur l’échange de clés post-quantique dans TLS, nous avions mis l’authentification de côté. L’urgence était ailleurs, car un attaquant «harvest-now-decrypt-later» peut enregistrer le trafic dès aujourd’hui et le déchiffrer plus tard. L’authentification, elle, ne peut être attaquée que pendant un handshake en cours. Rien de ce qui est enregistré aujourd’hui ne devient vulnérable après coup.

Ce n’est pas pour autant un sujet secondaire. Le jour où un ordinateur quantique cryptographiquement pertinent existera, un attaquant pourra retrouver la clé privée d’un site web pour se faire passer pour lui, ou celle d’une CA pour se faire passer pour n’importe quel site web. Même un site web qui sert un certificat post-quantique restera exposé tant que les navigateurs accepteront des certificats classiques. Et une fois l’authentification tombée, la confidentialité suit, car en usurpant le serveur, l’attaquant peut mener une attaque man-in-the-middle et tout lire, échange de clés post-quantique ou non.

Faire évoluer la Web PKI prend des années. Voilà pourquoi la migration se prépare dès maintenant, et non au Q-Day, le jour où un tel ordinateur quantique arrivera.

Ce cinquième et dernier article de notre série sur la PQC s’intéresse aux MTCs, aujourd’hui la piste la plus crédible vers une Web PKI résistante au quantique, et mesure ce qu’ils coûtent face à la solution la plus simple, qui consiste à passer chaque signature en post-quantique.

Le point faible de ce modèle, c’est que les navigateurs font confiance à plus d’une centaine de CA, et que chacune peut émettre un certificat valide pour n’importe quel domaine. Votre site n’est donc jamais plus sûr que la plus faible d’entre elles, et les incidents ne relèvent pas de la théorie. En 2011, la CA néerlandaise DigiNotar a été compromise et a émis des centaines de faux certificats, dont un pour *.google.com. Si la fraude a été découverte, c’est uniquement parce que Chrome avait épinglé les clés que les certificats de Google devaient utiliser.

Pour y remédier, la Certificate Transparency (CT) a vu le jour en 2013. Le principe est simple. Les CA inscrivent chaque certificat émis dans des journaux publics, où l’on peut ajouter des entrées mais jamais en effacer. Chacun peut ainsi consulter tous les certificats émis pour un domaine, repérer les faux et identifier la CA responsable. Et pour que la règle soit respectée, des navigateurs comme Chrome et Safari n’acceptent un certificat que s’il porte des preuves signées, les SCT, provenant d’au moins deux journaux indépendants.

Au total, un handshake TLS typique transporte aujourd’hui cinq signatures et deux clés publiques :

• la signature de la root CA sur le certificat intermédiaire
• la signature de l’intermediate CA sur le certificat du serveur
• deux SCT, par lesquels les journaux CT s’engagent à avoir enregistré le certificat
• la signature du serveur sur le handshake (CertificateVerify)

Les deux clés publiques sont celles du serveur et de l’intermediate CA. La clé de la root CA n’est pas envoyée, le navigateur l’ayant déjà, et il en va de même pour celles des journaux CT.

Le problème, c’est que tous ces éléments reposent sur RSA ou sur les courbes elliptiques, qu’un ordinateur quantique cryptographiquement pertinent sait casser. La solution qui vient naturellement à l’esprit est de remplacer chacun d’eux par un équivalent post-quantique. C’est ce que nous avons testé en premier.

Côté classique, nous avons construit notre chaîne comme celle de la plupart des sites aujourd’hui, avec des CA en P-384, et une clé serveur et des journaux CT en P-256. Côté post-quantique, nous avons mis ML-DSA-44 partout, puisqu’il offre le même niveau de sécurité de 128 bits que P-256. Mais comme le montre le tableau, ses clés sont environ 20 fois plus lourdes, et ses signatures près de 40 fois.

La taille explose. Avec ML-DSA-44, le handshake passe de 5,7 Ko à 21,2 Ko, près de quatre fois plus qu’avec ECDSA. L’essentiel vient du message TLS Certificate, qui transporte toute la chaîne et grimpe de 1,7 Ko à 13,5 Ko, puisque les deux certificats et les deux SCT portent désormais chacun une signature de 2 420 octets.

C’est sur la durée que les choses deviennent intéressantes. ECDSA boucle le handshake en 47 ms, ML-DSA-44 en 65 ms, soit un aller-retour réseau complet de plus. La cryptographie n’y est pour rien, signer et vérifier avec ML-DSA ne coûtant que quelques millisecondes de CPU. Le coupable, c’est la fenêtre de congestion initiale de TCP. Pour ne pas saturer le réseau, chaque côté ne peut envoyer par défaut que 10 paquets, environ 14 Ko, lors du premier aller-retour (RFC 6928). Avec ECDSA, la réponse du serveur tient largement dans cette limite. Avec ML-DSA-44, elle frôle déjà les 20 Ko. Le serveur doit donc attendre que le client accuse réception des premiers paquets avant d’envoyer la suite, d’où un aller-retour supplémentaire. C’est un retour en arrière, puisque TLS 1.3 a justement été conçu pour boucler le handshake en un seul aller-retour, là où TLS 1.2 en demandait deux.

Et l’enjeu dépasse quelques millisecondes. Des handshakes plus lourds provoquent aussi des pannes en chemin. Cloudflare a constaté une nette hausse des échecs côté clients et middleboxes dès que les chaînes de certificats grossissaient de plus de 10 Ko. ML-DSA-44 en ajoute plus de 15. Nous l’avions déjà vu avec l’échange de clés post-quantique, quand certains serveurs et middleboxes coupaient la connexion parce que le ClientHello ne tenait plus dans un seul paquet. Les navigateurs ne sont pas moins prudents. En 2024, l’équipe de Chrome jugeait 2 Ko de plus dans le handshake «très pénible, mais plausible», et 7 Ko «inenvisageable, à moins qu’un ordinateur quantique cryptographiquement pertinent ne soit réellement imminent».

Pour le web public, ce n’est donc pas la voie retenue. Chrome n’a aucun projet à court terme d’accepter des certificats X.509 post-quantiques dans son magasin de racines, et ne les prendra en charge que dans les PKI privées. Navigateurs et CA misent sur une autre approche, qui consiste à se débarrasser de la plupart des signatures.

Tout l’intérêt de cette structure est que quelques hashes suffisent pour prouver qu’un certificat s’y trouve. Cette preuve d’inclusion ne pèse que quelques centaines d’octets, même pour des millions de certificats.

La CA signe ensuite des portions de cet arbre, et des cosignataires indépendants, qui conservent une copie de l’arbre, y apposent leur propre signature. La CA ne peut ainsi pas montrer un arbre différent selon son interlocuteur. À intervalles réguliers, par exemple toutes les heures, l’une de ces portions signées devient un landmark et est envoyée aux navigateurs à l’avance. Un certificat couvert par un landmark n’a alors besoin que de sa petite preuve, sans la moindre signature. Et comme l’arbre est public, émettre un certificat revient déjà à le journaliser, et la Certificate Transparency est offerte d’office.

Pour les navigateurs qui n’ont pas encore reçu les derniers landmarks, il existe une solution de repli, le certificat standalone. Celui-ci embarque lui-même les signatures de la CA et des cosignataires, en plus de sa preuve d’inclusion. C’est aussi sous cette forme qu’un nouveau certificat est d’abord envoyé, le temps que le prochain landmark arrive dans les navigateurs. Le draft recommande donc de renouveler un certificat aux trois quarts de sa durée de vie, pour que le nouveau soit déjà couvert par un landmark à l’expiration de l’ancien.

Chaque navigateur fixe le nombre de cosignatures qu’il exige, aussi bien sur les landmarks reçus à l’avance que dans chaque certificat standalone. La politique provisoire de Chrome en demande pour l’instant au moins deux, une de la CA et une d’un miroir indépendant, toutes deux en ML-DSA-44.

Pour choisir quel certificat envoyer, le serveur s’en remet au navigateur. Dès son premier message, celui-ci indique à qui il fait confiance grâce à l’extension Trust Anchor Identifiers. Cette liste contient à la fois les landmarks dont il dispose et les CA dont il accepte les certificats standalone. Si l’un des landmarks couvre le certificat, le serveur envoie la version landmark, bien plus légère. Sinon, il se rabat sur un certificat standalone d’une CA que le navigateur reconnaît.

Nous nous y sommes donc connectés pour mesurer ce que coûtent les MTCs. Toutes les connexions utilisaient un échange de clés post-quantique. Contrairement à nos mesures précédentes, il s’agit cette fois d’un vrai serveur, hébergé en Chine, d’où des handshakes nettement plus longs.

Le certificat landmark est le plus léger des trois, et même plus léger que le X.509 actuel, comme l’annonçait Let’s Encrypt. Sans aucune signature, il tombe à environ 470 octets, et le handshake complet passe de 7,8 Ko avec le certificat X.509 classique à 4,8 Ko. Le certificat standalone, c’est une autre histoire. Trustasia y place trois signatures ML-DSA-44, une de la CA et deux de cosignataires, si bien que le certificat pèse à lui seul 7,3 Ko et que le handshake atteint 12,5 Ko.

Ces chiffres sont toutefois à nuancer sur trois points. D’abord, le handshake X.509 est ici plus lourd que dans notre lab, 7,8 Ko au lieu de 5,7 Ko. Le ClientHello du navigateur compte environ 480 octets de plus, car il contient quelques extensions supplémentaires, dont les Trust Anchor Identifiers, 186 octets à eux seuls, que les versions récentes de Chrome envoient par défaut, même sans MTCs. Mais surtout, le serveur envoie trois certificats au lieu de deux, la root CA de Trustasia étant contre-signée par une root CA RSA plus ancienne et plus largement reconnue. Ensuite, Trustasia émet si peu de certificats MTC que chacun se retrouve seul dans sa portion de l’arbre, avec une preuve d’inclusion vide. Pour une vraie CA, le draft l’estime à 384 octets pour un certificat standalone, et à 736 octets pour un certificat landmark. Enfin, ses certificats standalone portent trois signatures, là où la politique provisoire de Chrome n’en exige que deux.

Côté durée, en revanche, les trois se valent, entre 610 et 623 ms, soit environ deux allers-retours. Même avec le certificat standalone, la réponse du serveur reste autour de 9,3 Ko, sous les 14 Ko de la fenêtre de congestion initiale. Pas d’aller-retour supplémentaire, contrairement à ML-DSA dans notre lab.

Ces chiffres ne sont toutefois pas encore post-quantiques, car la signature du handshake reste en ECDSA. Dans tous les certificats MTC que nous avons trouvés dans les journaux de Trustasia et de Let’s Encrypt, la clé du serveur est en ECDSA. Rien d’étonnant, puisque les Baseline Requirements du CA/Browser Forum n’autorisent aujourd’hui que RSA et ECDSA, et que la politique provisoire de Chrome ne cite ML-DSA qu’en option.

Nos mesures permettent tout de même d’estimer le poids d’un déploiement entièrement post-quantique. Nous avons remplacé la clé ECDSA du serveur par ML-DSA-44, ajouté les preuves d’inclusion du draft, et gardé seulement les deux signatures que Chrome exige pour les certificats standalone. Un handshake landmark atteindrait alors environ 9,1 Ko, et un handshake standalone environ 14,1 Ko. Dans les deux cas, la réponse du serveur tiendrait dans la fenêtre de congestion initiale.

La promesse de Let’s Encrypt ne tient donc pleinement que tant que la clé du serveur reste en ECDSA. Dès qu’elle passe à ML-DSA, même un handshake landmark devient plus lourd que le handshake classique d’aujourd’hui.

La conception elle-même pose aussi une question de vie privée. Les landmarks n’arrivent pas dans tous les navigateurs au même moment. La liste qu’un navigateur annonce via l’extension Trust Anchor Identifiers varie donc d’un utilisateur à l’autre, et fournit un élément de plus pour le fingerprinting.

Enfin, les MTCs ont été pensés pour la Web PKI, où ce sont les navigateurs qui distribuent les landmarks à leurs utilisateurs. Dans une PKI privée, cette distribution serait à construire soi-même, ce qui peut vite devenir un casse-tête, en particulier en OT, où les équipements sont rarement mis à jour, voire pas connectés du tout.

Pour les PKI privées, la donne est différente. Personne ne les migrera à votre place, mais vous avez aussi plus de marge de manœuvre. Un certificat X.509 en ML-DSA, ou en ML-DSA composite, standardisé tout récemment, est souvent la voie la plus directe, surtout si vous n’avez pas besoin de Certificate Transparency, et donc d’aucun SCT dans vos certificats. Les MTCs gardent leur intérêt, mais la transition demande plus d’efforts, puisque c’est à vous de distribuer les landmarks à chaque client. En contrepartie, chaque certificat émis est automatiquement journalisé, ce qui peut s’avérer utile pour construire un inventaire et suivre la transition PQC à des fins de conformité. Au bout du compte, tout dépend de votre infrastructure : avez-vous besoin de garder une trace de tout ce que vous émettez ? Pouvez-vous facilement déployer des mises à jour sur vos clients ? Vos clients disposent-ils déjà de vos intermediate CA ?

Mais déployer des certificats post-quantiques ne représente que la moitié du travail. Tant que les clients acceptent les certificats classiques, un attaquant n’a qu’à viser ceux-là, il faut donc être prêt à les désactiver. Et avant même d’en arriver là, il faut savoir où se trouvent vos certificats et vos clés, et quels systèmes les émettent et les vérifient. Tout commence par un inventaire cryptographique.