Pour sécuriser internet contre les ordinateurs quantiques, Google ressort une idée mathématique de 1979
Pour sécuriser internet contre les ordinateurs quantiques, Google ressort une idée mathématique de 1979 :
les arbres de Merkle vont refonder la sécurité HTTPS d'ici 2027
Google vient d'annoncer un programme ambitieux pour rendre les certificats HTTPS résistants aux ordinateurs quantiques. La solution, développée en collaboration avec Cloudflare et l'IETF, ne consiste pas à simplement greffer de nouveaux algorithmes sur l'infrastructure existante — elle en repense l'architecture de fond en comble, en s'appuyant sur une structure mathématique vieille de quatre décennies : les arbres de Merkle.
La menace des ordinateurs quantiques sur la cryptographie n'est pas nouvelle. Depuis des années, chercheurs et ingénieurs sécurité alertent sur ce que l'on appelle la « Q-Day » — le jour hypothétique où un ordinateur quantique suffisamment puissant sera capable de casser les algorithmes à clé publique sur lesquels repose l'essentiel de la sécurité d'internet. RSA, ECDSA, Diffie-Hellman : autant de piliers qui s'effondreraient comme des châteaux de cartes face à l'algorithme de Shor.
La réponse de la communauté cryptographique a été rapide : le NIST a standardisé plusieurs algorithmes post-quantiques, dont ML-DSA (anciennement CRYSTALS-Dilithium) et SLH-DSA (anciennement SPHINCS+). Ces algorithmes sont mathématiquement robustes face aux attaques quantiques. Mais ils souffrent d'un défaut rédhibitoire pour un déploiement à grande échelle sur le web : leur taille.
Une signature ML-DSA peut peser environ 2 400 octets, et les signatures SLH-DSA peuvent atteindre plusieurs dizaines de kilooctets. Pour comparaison, une signature ECDSA P-256 ne fait que 64 octets — soit un facteur multiplicatif d'environ 37. Dans le contexte d'une poignée de mains TLS, où ces données transitent à chaque connexion sécurisée, cette inflation est catastrophique.
Un simple remplacement à l'identique aurait un impact notable sur les performances et n'offrirait aucun bénéfice en matière de sécurité avant la Q-Day. Ce qui en fait une proposition difficile à activer par défaut dès aujourd'hui. Et pourtant, le temps presse : les attaques de type « harvest now, decrypt later » consistent à intercepter dès maintenant des données chiffrées pour les déchiffrer plus tard, une fois les machines quantiques disponibles. L'horloge tourne.
Merkle à la rescousse : la beauté d'une idée des années 1970
Google s'appuie sur un concept inventé par Ralph Merkle à la fin des années 1970 pour contourner le problème de taille. Le principe des arbres de Merkle (Merkle Trees) est élégant : au lieu d'apposer une signature post-quantique sur chaque certificat individuellement, une Autorité de Certification (CA) ne signe qu'une seule fois la « racine » de l'arbre, appelée Tree Head. Cette racine représente synthétiquement l'ensemble des certificats regroupés dans l'arbre.
Dans ce modèle, une CA signe un unique « Tree Head » représentant potentiellement des millions de certificats, et le « certificat » transmis au navigateur n'est qu'une preuve d'inclusion légère dans cet arbre.
Cette preuve d'inclusion — ou Merkle proof — est compacte par nature. Sa taille est logarithmique par rapport au nombre de certificats : même un arbre contenant des milliards de certificats ne nécessiterait que quelques centaines d'octets de données de preuve. La grande signature post-quantique, lourde par essence, n'existe qu'une seule fois, au niveau de la racine, et peut être mise en cache ou distribuée hors bande. Ce qui transite lors de la poignée de mains TLS, c'est uniquement la preuve d'inclusion, compacte et efficace.
Si le client est suffisamment à jour, la poignée de mains TLS ne nécessite qu'une signature, une clé publique et une preuve d'inclusion Merkle. Le résultat : une empreinte réseau comparable — voire inférieure — à celle des certificats X.509 classiques, tout en offrant une résistance quantique complète.
PLANTS : le cadre IETF qui officialise la démarche
Cette approche ne relève pas du projet isolé d'une seule entreprise. L'Internet Engineering Task Force (IETF) a récemment créé un groupe de travail dédié, baptisé PKI, Logs, And Tree Signatures (PLANTS), dont l'objectif est d'adresser les défis de performance et de bande passante que la taille accrue de la cryptographie résistante aux quantas introduit dans les connexions TLS nécessitant la Certificate Transparency (CT).
Les Merkle Tree Certificates (MTS) ont débuté comme un draft individuel, draft-davidben-tls-merkle-tree-certs, et ont depuis été adoptés par le groupe de travail PLANTS de l'IETF. Les cinq co-auteurs du draft sont issus de Google, Cloudflare et Geomys — un signal fort de la convergence de l'industrie autour de cette approche.
Les MTC ne se contentent pas de résoudre le problème de taille. Avec les MTC, la transparence est une propriété fondamentale de l'émission : il est impossible d'émettre un certificat sans l'inclure dans un arbre public. Les propriétés de sécurité de l'écosystème CT actuel sont donc incluses par défaut, sans ajouter de surcharge supplémentaire à la poignée de mains TLS. La Certificate Transparency, aujourd'hui implémentée comme une couche additionnelle coûteuse en bande passante, devient intrinsèque au mécanisme.
Le plan de déploiement de Google : trois phases d'ici 2027
Google a présenté une feuille de route structurée en trois phases pour Chrome.
La Phase 1 est déjà en cours : en collaboration avec Cloudflare, Google conduit une étude de faisabilité pour évaluer les performances et la sécurité des connexions TLS reposant sur les MTC. Pour garantir une expérience transparente et sécurisée aux utilisateurs Chrome qui pourraient rencontrer un MTC, chaque connexion MTC est doublée d'un certificat X.509 traditionnel et de confiance pendant cette expérience. Concrètement, environ 1 000 certificats TLS ont été enrôlés dans le nouveau système pour évaluation.
La Phase 2, prévue pour le premier trimestre 2027, consistera à inviter les opérateurs de logs Certificate Transparency disposant d'au moins un log « utilisable » dans Chrome avant le 1er février 2026 à participer au bootstrapping initial des MTC publics. Google justifie ce choix par leur expérience opérationnelle des services à haute disponibilité et leurs similarités architecturales avec l'infrastructure MTC.
La Phase 3, ciblée pour le troisième trimestre 2027, introduira le Chrome Quantum-resistant Root Store (CQRS), un store de confiance moderne conçu spécifiquement pour les MTC. googleblog Ce nouveau store fonctionnera en parallèle du Chrome Root Store existant, garantissant une transition gérée sans rupture pour les utilisateurs.
Un chantier qui va bien au-delà des algorithmes
Ce qui est frappant dans l'approche de Google, c'est qu'elle ne se limite pas à substituer des algorithmes. L'équipe Chrome profite de cette transition pour remettre à plat plusieurs aspects de l'infrastructure PKI web qui avaient accumulé de la dette technique.
Parmi les évolutions envisagées : la généralisation des workflows ACME-only pour réduire la complexité et garantir l'agilité cryptographique, la refonte du modèle de révocation pour remplacer les CRL hérités, l'exploration de la validation de contrôle de domaine « reproductible » permettant à n'importe qui de vérifier indépendamment la légitimité d'une validation, et l'évolution du modèle de supervision des CA pour privilégier une surveillance continue et vérifiable externe plutôt que des audits annuels par tiers.
Google précise également qu'il prévoit de supporter les certificats X.509 traditionnels avec des algorithmes résistants aux quantas pour les PKI privées — c'est-à-dire non incluses dans le Chrome Root Store — plus tard cette année
Les enjeux pour l'écosystème
La décision de Google de ne pas ajouter de certificats X.509 post-quantiques au Chrome Root Store est structurante pour l'ensemble de l'industrie. Elle signifie que les autorités de certification qui voudront rester dans le périmètre de confiance de Chrome devront migrer vers l'architecture MTC, adopter les workflows ACME, et satisfaire aux nouvelles exigences opérationnelles du Chrome Quantum-resistant Root Program.
Pour les équipes d'infrastructure et de sécurité des entreprises, la transition vers les MTC impliquera des mises à jour des outils de gestion de certificats, des systèmes de monitoring, et potentiellement des appareils ou logiciels ne supportant pas les nouveaux mécanismes de validation hors bande. Les environnements air-gapped ou les clients TLS très contraints qui ne peuvent pas synchroniser régulièrement un état de transparence seront particulièrement impactés.
Il reste enfin une question ouverte : le calendrier. Les migrations prennent toujours plus de temps que prévu. À en croire certains ingénieurs, si nous voulons préserver un internet universellement privé et sécurisé, nous avons besoin d'une solution post-quantique suffisamment performante pour être activée par défaut dès aujourd'hui. Selon eux, l'urgence est réelle, et la fenêtre de déploiement sereine se referme progressivement au fur et à mesure que les progrès en informatique quantique s'accélèrent.
Sources : Google, Cloudflare
Et vous ?
La décision de Google d'exclure les certificats X.509 post-quantiques du Chrome Root Store va-t-elle accélérer ou fragmenter la transition vers la cryptographie résistante aux quantas ? Les autres navigateurs (Firefox, Safari) suivront-ils le même chemin ou maintiendront-ils le X.509 comme standard ?
Voir aussi :
sans altérer les performances de l'application
Répondre avec citation
Partager