Merkle Tree Certificates : la troisième itération de la PKI du Web

Au cours des trois derniers mois, j’ai exploré la cryptographie post-quantique, son impact sur Internet et la manière dont elle redéfinit la cryptographie et la sécurité réseau. Dans cet article, le septième et dernier de la série, je m’intéresse à la refonte de l’authentification sur le Web grâce aux Merkle Tree Certificates (MTC).

Au départ, il n’existait que la PKI d’Internet, qui couvrait toute l’authentification publique entre logiciels clients et serveurs de toutes sortes. Si le terme ne vous est pas familier, PKI signifie Public Key Infrastructure (infrastructure à clés publiques). Malgré le mot « public » dans son nom, une PKI n’a pas besoin d’être publique ou ouverte à tous, mais la PKI d’Internet l’est.

L’histoire de la naissance de la PKI d’Internet est fascinante, mais elle se résume essentiellement à un ingénieur des débuts de Netscape, Kipp Hickman, qui a mis trois mois à tout concevoir. Au passage, ce temps comprenait la création de la première version de Secure Sockets Layer (SSL) et de la PKI d’Internet (en s’appuyant sur X.509, qui existait déjà). Il semblerait que ce dernier volet (l’authentification) ait été en grande partie pensé après coup. Grâce au travail de Kipp, Netscape a ouvert l’ère des communications sécurisées, et le monde a suivi.

Ce premier système a fonctionné pendant une dizaine d’années, mais les failles ont fini par devenir trop importantes pour être ignorées. Le CA/Browser Forum, un groupement sectoriel réunissant autorités de certification et navigateurs, a été créé en 2005 et a publié en 2007 son premier document pour commencer à encadrer l’émission des certificats. Ce travail se poursuit depuis.

En parallèle, les éditeurs de navigateurs, Google en tête, ont commencé à exercer un contrôle croissant sur ce qui est considéré comme sûr. Les navigateurs se sont mis à exploiter les certificats d’une manière légèrement différente, ce qui a conduit à la création de la PKI du Web. Au début, les différences étaient minimes. Une nouvelle technologie, Certificate Transparency (CT), est devenue obligatoire en 2018 et a profondément transformé la PKI du Web. Cet ajout a marqué la deuxième itération de la PKI du Web, celle que nous connaissons aujourd’hui. La récente suppression de l’authentification client a été le dernier changement à consolider ces différences.

Je vais entrer dans les détails dans un instant, mais la décision de repenser la PKI du Web se résume à trois problèmes majeurs :

1. L’écosystème CT actuel est déjà fragile
2. La réduction prévue de la durée de vie des certificats risque fort de le faire céder
3. Les signatures post-quantiques, plus volumineuses, vont l’achever

En résumé, la migration post-quantique est le déclencheur qui nous permettra de justifier le travail nécessaire pour que tout fonctionne beaucoup plus facilement. Il y aura beaucoup de travail nouveau, mais nous ne jetons pas pour autant tout ce que nous avons appris jusqu’ici.

Le rôle de Certificate Transparency (CT) est de garantir une visibilité totale sur l’émission de certificats dans le monde entier. Pour cela, les certificats sont enregistrés dans des journaux CT, protégés par la cryptographie. Les journaux CT sont ainsi devenus un élément essentiel de l’authentification sur le Web.

Comme tous les grands navigateurs et de nombreux systèmes d’exploitation exigent désormais CT, un certificat ne peut pas être émis s’il n’est pas journalisé. Il nous faut donc des journaux CT hautement disponibles, capables d’absorber les pics d’émission mondiaux, et même davantage. Nous n’avons pas connu de panne majeure jusqu’ici, mais si vous suivez les bonnes listes de diffusion, vous savez qu’il y a eu des difficultés. Cela inquiète les acteurs du secteur.

Les décisions déjà prises vont aggraver la situation. D’ici 2029, la durée de vie maximale autorisée des certificats passera à seulement 47 jours, contre un an, une limite elle-même assez récente. Nous passerons donc d’une émission annuelle à une émission mensuelle, soit une multiplication par 12.

D’autres réductions de durée de vie pourraient également être introduites. La politique précoce d’Apple en matière d’authentification post-quantique, par exemple, n’autorise que 7 jours. On ne sait pas encore si cette limite ne s’applique qu’à la phase d’essai ou si elle a vocation à être généralisée. Si elle est maintenue, cela représente une nouvelle multiplication par 4 par rapport à l’émission mensuelle, jusqu’ici la plus courte. Au total, environ 50 fois la charge actuelle de l’écosystème CT en nombre d’émissions.

L’augmentation du nombre de certificats n’est qu’une partie du problème. Comme je l’expliquais dans un article précédent, les signatures et algorithmes à clé publique post-quantiques sont beaucoup plus volumineux, ce qui pourrait à lui seul multiplier par 10 à 20 la taille des certificats (et des journaux CT). Multipliez les deux, et vous comprendrez pourquoi le secteur s’inquiète.

La troisième itération, sous la forme des Merkle Tree Certificates (MTC), est conçue pour y remédier.

La différence la plus importante des MTC est qu’ils unissent X.509 et CT. Dans le modèle actuel, CT est un module complémentaire. La journalisation des certificats dans CT est une étape distincte. Les organisations qui émettent les certificats ne sont pas celles qui les journalisent dans CT. Il s’agit d’une faiblesse structurelle, qui entraîne un désalignement des incitations.

Avec les MTC, chaque autorité de certification exploite une instance d’un journal CT (de nouvelle génération) et y inscrit ses certificats. Vous entendrez souvent dire qu’elles vont « émettre par journalisation ». Là où il y avait deux étapes, il n’y en a plus qu’une. Avec ce changement, chaque autorité de certification doit désormais aussi participer à l’écosystème CT ; il n’y a pas d’autre moyen.

Comme les MTC sont émis par journalisation, les précertificats, actuellement exigés par CT, ne sont plus nécessaires. Désormais, un seul objet sera journalisé. Ce changement réduit la complexité opérationnelle et pourrait diviser jusqu’à deux la taille des journaux CT. (Les plus grandes autorités de certification soumettent aujourd’hui à la fois des précertificats et des certificats à CT.)

Un aspect important de CT est que l’émission des certificats est attestée (witnessing) et répliquée par des tiers. Nous ne faisons confiance à aucune organisation isolée pour bien faire les choses. Dans CT v1, les certificats sont enregistrés un par un. Un journal CT contient toutes sortes de certificats émis par différentes autorités. De plus, n’importe qui peut soumettre un certificat à enregistrer dans le journal.

Avec les MTC, l’attestation et la réplication se font au niveau du journal. Les autorités de certification émettent les certificats en les inscrivant dans leurs propres journaux. Ceux-ci sont signés, puis attestés et répliqués par lots. Un journal miroir est identique au journal d’origine. Cela présente de réels avantages :

• Les opérations par lots sont plus simples et plus efficaces.
• Les tiers ne peuvent plus soumettre de certificats arbitraires, ce qui limite les doublons (certificats enregistrés inutilement) et évite de surcharger les journaux CT.
• Les moniteurs n’ont plus besoin de surveiller tous les journaux CT du monde pour obtenir tous les certificats ; il leur suffit de surveiller une seule instance, voire de répartir la charge entre plusieurs instances du même journal.

Comme tous les émetteurs de MTC sont aussi des opérateurs de journaux MTC, ils devraient s’associer à d’autres autorités de certification aux volumes d’émission comparables pour répliquer mutuellement leurs certificats.

Aux débuts de CT, chaque journal n’avait qu’une seule instance, et cela a bien fonctionné pendant un temps. Les premiers journaux étaient annuels, car une fois tous les certificats d’un journal expirés, il n’était plus nécessaire de les conserver. Mais les journaux annuels sont devenus trop volumineux, et des fragments (shards) plus petits (par exemple sur des intervalles de 6 mois) ont été ajoutés.

La création et la gestion des fragments de journaux CT représentent une charge opérationnelle continue et importante. Les opérateurs passent beaucoup de temps à créer et gérer les fragments, puis à les supprimer. Les nouveaux fragments doivent ensuite être surveillés et validés en collaboration avec les principaux utilisateurs (les éditeurs de navigateurs). Enfin, leurs informations doivent être propagées jusqu’aux utilisateurs finaux.

Les MTC prennent en charge l’élagage des journaux. Grâce à la façon dont les journaux sont construits en interne (et à la conception de la validation cryptographique), il est possible de supprimer entièrement les parties expirées. Ce changement sera très apprécié par les personnes chargées de veiller à ce que l’écosystème fonctionne, et fonctionne bien.

Dans la conception actuelle de CT, chaque entrée contient la clé publique associée et la signature de l’autorité de certification. Ces éléments sont aujourd’hui petits, mais leur taille va exploser avec la PQC. Avec les MTC, les clés publiques sont omises et remplacées par la combinaison d’un identifiant d’algorithme et d’un hachage. Les signatures de l’autorité de certification sont également exclues (car les journaux MTC sont signés par lots).

Ce changement réduit considérablement la taille des journaux CT, d’autant plus qu’il n’y aura plus de précertificats et qu’il ne sera plus possible de journaliser des certificats arbitraires.

Nous avons vu que les MTC faciliteront grandement la prise en charge des aspects de transparence de l’authentification sur le Web. La plupart des analyses se concentrent toutefois sur la réduction de la taille des handshakes TLS. Pour comprendre ce problème, je vous invite à lire mon article précédent sur la taille des signatures post-quantiques et leur impact sur les performances réseau. Vous apprécierez peut-être aussi cet article complémentaire, consacré aux éléments qui étayent ces affirmations sur les performances.

Les Merkle Tree Certificates existent sous deux formes. La première est dite autonome (standalone) et équivaut à peu près, dans sa forme, aux certificats que nous connaissons aujourd’hui (X.509 + CT).

Dans les certificats autonomes, les signatures sont remplacées par une preuve d’inclusion, une structure fondée sur le hachage qui remplit un rôle similaire. Point essentiel : si les preuves d’inclusion sont plus volumineuses que les signatures RSA et EC actuelles (environ 384 octets), elles sont bien plus petites que les signatures post-quantiques. Les MTC autonomes sont donc beaucoup plus légers pris individuellement.

Autre changement : les MTC sont émis directement par des autorités de certification de confiance, si bien que les certificats intermédiaires ne sont plus nécessaires dans le handshake TLS, ce qui réduit encore la taille.

Les certificats autonomes sont simples sur le plan conceptuel, mais ils ne suffisent pas à ramener la taille des handshakes TLS post-quantiques au niveau actuel. Pour faire mieux, il faut aller plus loin et accepter une complexité nettement plus grande. C’est l’objet de la seconde forme que peuvent prendre les MTC : les Landmark-Relative Certificates.

Les certificats autonomes sont plus petits, mais ils doivent toujours contenir des signatures, très volumineuses dans le monde post-quantique. Les Landmark-Relative Certificates (LRC) sont bien plus petits, car leur seul mécanisme d’authentification est une preuve d’inclusion ; ils ne contiennent aucune signature. La preuve d’inclusion des LRC n’est pas la même que celle des certificats autonomes : elle est un peu plus volumineuse, mais pas énormément (environ 736 octets, soit à peu près le double).

Il y a toutefois un hic. Pour fonctionner, les LRC ont besoin de preuves d’inclusion émises par rapport à des landmarks (points de repère), c’est-à-dire des groupes (sous-arbres) de certificats émis. Pour authentifier ces preuves d’inclusion, les agents utilisateurs doivent disposer au préalable d’informations sur les landmarks correspondants, ce qui signifie qu’ils doivent en permanence récupérer quelque chose quelque part pour chaque autorité de certification à laquelle ils font confiance. Aïe.

Si vous êtes un utilisateur final, rien de tout cela ne vous concernera. La prise en charge des LRC implique beaucoup de complexité supplémentaire, mais celle-ci sera gérée et « payée » par les développeurs d’agents utilisateurs et les opérateurs de serveurs. Pour ces derniers, l’espoir est que l’essentiel soit pris en charge par les logiciels d’automatisation, via ACME.

Les Landmark-Relative Certificates sont une optimisation. Quand tout se passe bien, les handshakes TLS sont courts et rapides. Sinon, les agents utilisateurs se rabattent sur les certificats autonomes : c’est plus lent, mais rien ne casse.

Point positif : selon Cloudflare, les LRC offrent des performances supérieures de 9 % à celles des chaînes de certificats classiques actuelles. Le gain serait bien plus important par rapport aux certificats autonomes, et nettement supérieur par rapport à d’hypothétiques chaînes de certificats X.509 + ML-DSA que nous ne voulons pas utiliser sur l’Internet public.

Cela dit, sur les réseaux privés, qui sont des environnements contrôlés et disposent souvent d’une connectivité bien plus rapide, les écarts de performances pourraient être moins marqués. Une simple évolution de X.509 intégrant ML-DSA pourrait très bien suffire.

Après tout cela, essayons de déterminer combien de certificats il nous faudrait pour obtenir des performances optimales. Aujourd’hui, la configuration la plus robuste consiste à disposer de deux certificats : un certificat EC, plus rapide, et un certificat RSA, largement pris en charge.

Pour neutraliser la menace des ordinateurs quantiques cryptographiquement pertinents, nous devrons passer à l’authentification post-quantique via les MTC. Au minimum, cela implique de prendre en charge les certificats autonomes. Il nous en faudra donc au moins trois, pour servir à la fois les agents utilisateurs modernes et ceux qui sont à la traîne.

Malheureusement, avec un seul certificat autonome, les performances de nos handshakes TLS seront inférieures à celles d’aujourd’hui. C’est peut-être acceptable, mais pour y remédier, nous devrons aussi prendre en charge les Landmark-Relative Certificates. Et il nous en faudra deux, pas un seul.

Il nous faudra donc au moins cinq certificats par service.

Plusieurs raisons expliquent l’existence de certificats autonomes et de Landmark-Relative Certificates. Les certificats autonomes peuvent être créés dès l’émission. Les LRC, en revanche, sont produits par lots et ne sont donc pas immédiatement disponibles. Vous devrez attendre un certain temps (par exemple 1 heure) avant de pouvoir en obtenir un qui corresponde à votre certificat autonome.

Ce n’est pas tout. Comme nous l’avons vu, pour qu’un LRC soit authentifié, les agents utilisateurs doivent d’abord récupérer des informations auprès de l’autorité de certification. (Indirectement, via un service de mise à jour de l’agent utilisateur.) Les agents utilisateurs ne surveilleront pas l’apparition de nouveaux landmarks en continu ; ils ne les récupéreront que périodiquement. En outre, ils peuvent rester hors ligne pendant un certain temps. Par conséquent, les agents utilisateurs ne disposeront généralement pas des landmarks les plus récents.

En résumé : 1) il vous faut un certificat autonome pour tout le monde, 2) un Landmark-Relative Certificate plus ancien pour la plupart des agents utilisateurs, et 3) un certificat landmark plus récent, qui deviendra progressivement votre certificat principal à mesure que les agents utilisateurs se mettront à jour.

Imaginez un peu devoir faire tout cela manuellement. Pas étonnant que nous ayons besoin d’ACME… l’automatisation est le seul moyen d’y parvenir. Et même ainsi, le diagnostic des problèmes d’authentification et de performances deviendra plus difficile. Une surveillance continue, pour détecter les problèmes au plus tôt, deviendra nécessaire pour un éventail beaucoup plus large d’organisations.