Merkle Tree Certificates: Die dritte Iteration der Web-PKI

In den letzten drei Monaten habe ich mich mit Post-Quanten-Kryptografie beschäftigt: mit ihren Auswirkungen auf das Internet und damit, wie sie den Stand von Kryptografie und Netzwerksicherheit verändert. In diesem Blogbeitrag, meinem siebten und letzten der Reihe, sehe ich mir an, wie die Web-Authentifizierung mit Merkle Tree Certificates (MTCs) neu konzipiert wird.

Am Anfang gab es nur die Internet-PKI, die sämtliche öffentliche Authentifizierung zwischen Client- und Serversoftware aller Art abdeckte. Falls Sie mit dem Begriff nicht vertraut sind: PKI steht für Public Key Infrastructure. Trotz des Wortes „Public“ im Namen müssen PKIs nicht öffentlich oder für alle zugänglich sein – die Internet-PKI ist es aber.

Die Entstehungsgeschichte der Internet-PKI ist faszinierend, lässt sich aber im Kern auf einen frühen Netscape-Ingenieur zurückführen, Kipp Hickman, der drei Monate brauchte, um alles auszuarbeiten. Übrigens umfasste diese Zeit die Arbeit an der ersten Version von Secure Sockets Layer (SSL) und an der Internet-PKI (aufbauend auf X.509, das es bereits gab). Der letztere Teil (die Authentifizierung) war Berichten zufolge weitgehend ein nachträglicher Einfall. Mit Kipps Arbeit läutete Netscape das Zeitalter der sicheren Kommunikation ein, und die Welt zog nach.

Dieses erste System funktionierte etwa ein Jahrzehnt lang, doch irgendwann waren die Risse zu groß, um sie zu ignorieren. Das CA/Browser Forum, ein Branchenverband aus CAs und Browserherstellern, wurde 2005 gegründet und veröffentlichte 2007 sein erstes Dokument, um die Zertifikatsausstellung zu formalisieren. Diese Arbeit dauert bis heute an.

Parallel dazu begannen die Browserhersteller – größtenteils angeführt von Google –, zunehmend zu bestimmen, was als sicher gilt. Browser verarbeiteten Zertifikate auf leicht andere Weise, was zur Entstehung der Web-PKI führte. Anfangs waren die Unterschiede gering. Eine neue Technologie namens Certificate Transparency (CT) wurde 2018 verpflichtend und veränderte die Web-PKI grundlegend. Damit begann die zweite Iteration der Web-PKI, die wir heute nutzen. Die kürzliche Abschaffung der Client-Authentifizierung war die letzte Änderung, die die Unterschiede festigte.

Auf die Details gehe ich gleich ein, aber die Entscheidung, die Web-PKI neu zu konzipieren, lässt sich auf die folgenden drei zentralen Probleme zurückführen:

1. Das bestehende CT-Ökosystem ist schon jetzt fragil
2. Die geplante Verkürzung der Zertifikatslaufzeiten wird es sehr wahrscheinlich überlasten
3. Die größeren Post-Quanten-Signaturen werden ihm den Rest geben

Kurz gesagt: Die Post-Quanten-Migration ist der Auslöser, der den Aufwand rechtfertigt, damit alles deutlich reibungsloser läuft. Es wird viel neue Arbeit anfallen, aber wir werfen nicht alles über Bord, was wir bisher gelernt haben.

Certificate Transparency (CT) soll vollständige Transparenz über die weltweite Zertifikatsausstellung gewährleisten. Dazu werden Zertifikate in CT-Logs protokolliert, die kryptografisch geschützt sind. Dadurch sind CT-Logs zu einem entscheidenden Bestandteil der Web-Authentifizierung geworden.

Da alle großen Browser und viele Betriebssysteme inzwischen CT voraussetzen, können Zertifikate nur ausgestellt werden, wenn sie protokolliert werden. Wir brauchen also hochverfügbare CT-Logs, die die weltweiten Ausstellungsspitzen bewältigen – und noch etwas mehr. Größere Ausfälle gab es bisher zwar nicht, aber wer die richtigen Mailinglisten verfolgt, weiß, dass es Herausforderungen gab. Das macht die Beteiligten nervös.

Bereits getroffene Entscheidungen werden die Lage verschärfen. Bis 2029 wird die maximal zulässige Zertifikatslaufzeit auf nur noch 47 Tage verkürzt – von einem Jahr, was selbst erst seit relativ kurzer Zeit gilt. Damit wechseln wir von jährlicher zu monatlicher Ausstellung, eine Verzwölffachung.

Möglicherweise kommen weitere Laufzeitverkürzungen hinzu. Apples frühe Richtlinie für Post-Quanten-Authentifizierung erlaubt beispielsweise nur 7 Tage. Ob das nur für die Testphase gilt oder auch für den Regelbetrieb vorgesehen ist, ist unklar. Bleibt es dabei, kommt zur bisher kürzesten, monatlichen Ausstellung noch einmal eine Vervierfachung hinzu. Insgesamt wäre das etwa das 50-Fache der aktuellen Last auf dem CT-Ökosystem, gemessen an der Zahl der Ausstellungen.

Die höhere Zahl an Zertifikaten ist nur ein Teil davon. Wie Sie sich vielleicht aus meinem früheren Beitrag erinnern, sind Post-Quanten-Signaturen und -Public-Key-Algorithmen deutlich größer, was allein schon zu einer 10- bis 20-fachen Zunahme der Größe von Zertifikaten (und CT-Logs) führen könnte. Multiplizieren Sie beides, und Sie verstehen, warum die Beteiligten nervös sind.

Die dritte Iteration in Form von Merkle Tree Certificates (MTCs) ist als Lösung gedacht.

Der wichtigste Unterschied bei MTCs besteht darin, dass sie X.509 und CT verbinden. Im derzeitigen Modell ist CT ein Zusatz. Die Protokollierung von Zertifikaten in CT ist ein separater Schritt. Die Organisationen, die Zertifikate ausstellen, sind andere als die, die sie in CT protokollieren. Das ist eine strukturelle Schwäche und führt zu falschen Anreizen.

Bei MTC betreibt jede CA eine Instanz eines CT-Logs (der nächsten Generation) und schreibt Zertifikate hinein. Man hört oft den Satz, dass CAs künftig „durch Protokollierung ausstellen“. Wo es zuvor zwei Schritte gab, gibt es jetzt nur noch einen. Durch diese Änderung muss sich jede CA auch am CT-Ökosystem beteiligen; anders geht es nicht.

Da MTCs durch Protokollierung ausgestellt werden, sind Precertificates, die in CT derzeit erforderlich sind, nicht mehr nötig. Künftig wird nur noch ein Objekt protokolliert. Das senkt die betriebliche Komplexität und kann die Größe der CT-Logs um bis zur Hälfte reduzieren. (Die größten CAs reichen derzeit sowohl Precertificates als auch Zertifikate bei CT ein.)

Ein wichtiger Aspekt von CT ist, dass die Zertifikatsausstellung von Dritten bezeugt (Witnessing) und gespiegelt wird. Wir vertrauen nicht darauf, dass eine einzelne Organisation das Richtige tut. In CT v1 werden Zertifikate einzeln erfasst. Ein CT-Log enthält eine Vielzahl von Zertifikaten verschiedener CAs. Zudem kann jeder ein Zertifikat zur Aufnahme in das Log einreichen.

Bei MTC finden Witnessing und Spiegelung auf Log-Ebene statt. CAs stellen Zertifikate aus, indem sie sie in ihren eigenen Logs protokollieren. Diese werden signiert und dann stapelweise bezeugt und gespiegelt. Ein Spiegel-Log ist mit dem Original-Log identisch. Das hat einige große Vorteile:

• Stapelverarbeitung ist schlanker und effizienter.
• Dritte können keine beliebigen Zertifikate mehr einreichen. Das vermeidet doppelte Arbeit (unnötig erfasste Zertifikate) und eine Überlastung der CT-Logs.
• Monitore müssen nicht mehr alle CT-Logs weltweit überwachen, um alle Zertifikate zu erhalten; sie müssen nur eine Instanz überwachen oder können die Last sogar auf mehrere Instanzen desselben Logs verteilen.

Da alle MTC-Aussteller zugleich MTC-Log-Betreiber sind, werden sie sich voraussichtlich mit anderen CAs mit ähnlichem Ausstellungsvolumen zusammentun, um gegenseitig ihre Zertifikate zu spiegeln.

In den Anfangstagen von CT hatte jedes Log nur eine Instanz, und das funktionierte eine Zeit lang gut. Die ersten Logs waren jährlich angelegt, denn sobald alle Zertifikate in einem Log abgelaufen waren, musste man sie nicht mehr aufbewahren. Irgendwann wurden die Jahres-Logs jedoch zu groß, also kamen kleinere Shards (z. B. in 6-Monats-Intervallen) hinzu.

Das Anlegen und Verwalten der CT-Log-Shards verursacht eine erhebliche, dauerhafte Betriebslast. Betreiber verbringen viel Zeit damit, Shards zu erstellen, zu verwalten und wieder abzubauen. Neue Shards müssen dann in Zusammenarbeit mit den wichtigsten Abnehmern (den Browserherstellern) überwacht und validiert werden. Anschließend müssen ihre Informationen an die eigentlichen Endnutzer verteilt werden.

MTCs unterstützen Log-Pruning. Dank des internen Aufbaus der Logs (und des Designs der kryptografischen Validierung) lassen sich abgelaufene Teile vollständig entfernen. Das wird eine sehr willkommene Änderung für alle sein, die dafür sorgen müssen, dass das Ökosystem läuft – und zwar gut.

Im aktuellen CT-Design enthält jeder Eintrag den zugehörigen öffentlichen Schlüssel und die CA-Signatur. Diese sind derzeit klein, doch mit PQC wird ihre Größe explodieren. Bei MTCs werden öffentliche Schlüssel weggelassen und durch eine Kombination aus Algorithmuskennung und Hash ersetzt. Auch CA-Signaturen entfallen (da MTC-Logs stapelweise signiert werden).

Diese Änderung verringert die Größe der CT-Logs erheblich, zumal es künftig keine Precertificates mehr geben wird und beliebige Zertifikate nicht mehr protokolliert werden können.

Wir haben gesehen, dass MTCs die Transparenzaspekte der Web-Authentifizierung deutlich leichter handhabbar machen. Die meisten Beiträge konzentrieren sich jedoch auf die geringere Größe von TLS-Handshakes. Um dieses Problem zu verstehen, empfehle ich Ihnen meinen früheren Beitrag über die Größe von Post-Quanten-Signaturen und ihre Auswirkungen auf die Netzwerkperformance. Interessant ist vielleicht auch dieser Folgebeitrag, der sich mit den Belegen für die Performance-Aussagen befasst.

Merkle Tree Certificates gibt es in zwei Formen. Die eine heißt Standalone und entspricht in ihrer Form in etwa den Zertifikaten, wie wir sie heute kennen (X.509 + CT).

In Standalone-Zertifikaten werden Signaturen durch einen Inclusion Proof ersetzt, eine hashbasierte Struktur, die einen ähnlichen Zweck erfüllt. Entscheidend ist: Inclusion Proofs sind zwar größer als die heutigen RSA- und EC-Signaturen (mit etwa 384 Byte), aber deutlich kleiner als Post-Quanten-Signaturen. Dadurch sind Standalone-MTCs einzeln betrachtet deutlich kleiner.

Es gibt noch eine weitere Änderung. MTCs werden direkt von vertrauenswürdigen CAs ausgestellt, sodass im TLS-Handshake keine Zwischenzertifikate mehr nötig sind – was die Größe weiter verringert.

Standalone-Zertifikate sind konzeptionell unkompliziert, reichen aber nicht aus, um die Größe von PQC-TLS-Handshakes auf das heutige Niveau zu bringen. Wenn wir es besser machen wollen, müssen wir mehr tun und die Komplexität erheblich erhöhen. Das geschieht über die zweite Form, die MTCs annehmen können: Landmark-Relative Certificates.

Standalone-Zertifikate sind kleiner, müssen aber weiterhin Signaturen enthalten, die in der Post-Quanten-Welt sehr groß sind. Landmark-Relative Certificates (LRCs) sind deutlich kleiner, weil ihr einziger Authentifizierungsmechanismus ein Inclusion Proof ist; sie enthalten keine Signaturen. Der Inclusion Proof in LRCs ist nicht derselbe wie in Standalone-Zertifikaten und daher etwas größer, aber nicht dramatisch (etwa 736 Byte, ungefähr das Doppelte).

Es gibt allerdings einen Haken. Damit LRCs funktionieren, brauchen sie Inclusion Proofs, die gegen Landmarks ausgestellt werden – Gruppen (Teilbäume) ausgestellter Zertifikate. Damit User Agents diese Inclusion Proofs authentifizieren können, müssen sie vorab Informationen über die entsprechenden Landmarks haben. Das bedeutet, dass sie für jede CA, der sie vertrauen, laufend etwas von irgendwoher abrufen müssen. Autsch.

Als Endnutzer wird Sie das alles nicht kümmern. Die Unterstützung von LRCs bringt viel zusätzliche Komplexität mit sich, doch diese werden die Entwickler von User Agents und die Serverbetreiber tragen und „bezahlen“. Für Letztere besteht die Hoffnung, dass das meiste davon von Automatisierungssoftware über ACME übernommen wird.

Landmark-Relative Certificates sind eine Optimierung. Wenn alles klappt, sind TLS-Handshakes kurz und schnell. Andernfalls greifen User Agents auf Standalone-Zertifikate zurück – das ist langsamer, aber es geht nichts kaputt.

Positiv ist: Laut Cloudflare bieten LRCs eine um 9 % bessere Performance als die klassischen Zertifikatsketten, die wir heute verwenden. Gegenüber Standalone-Zertifikaten wäre der Vorteil deutlich größer, und gegenüber theoretischen X.509 + ML-DSA-Zertifikatsketten, die wir im öffentlichen Internet nicht einsetzen wollen, erheblich größer.

In privaten Netzwerken, die kontrollierte Umgebungen sind und oft eine viel schnellere Netzwerkanbindung haben, fallen die Performance-Unterschiede allerdings möglicherweise weniger ins Gewicht. Eine schlichte Weiterentwicklung von X.509 um ML-DSA könnte dort völlig ausreichen.

Versuchen wir nach alledem herauszufinden, wie viele Zertifikate wir für optimale Performance benötigen könnten. Heute ist die robusteste Konfiguration, zwei Zertifikate zu haben: ein schnelleres EC-Zertifikat und das breit unterstützte RSA-Zertifikat.

Um die Bedrohung durch kryptografisch relevante Quantencomputer zu neutralisieren, müssen wir über MTCs auf Post-Quanten-Authentifizierung umstellen. Das bedeutet mindestens die Unterstützung von Standalone-Zertifikaten. Wir brauchen also mindestens drei, um sowohl moderne als auch nachhinkende User Agents zu unterstützen.

Leider wird die TLS-Handshake-Performance mit nur einem Standalone-Zertifikat schlechter sein als heute. Vielleicht ist das in Ordnung – wenn wir das aber beheben wollen, müssen wir auch Landmark-Relative Certificates unterstützen. Und davon brauchen wir zwei, nicht nur eines.

Wir brauchen also mindestens fünf Zertifikate pro Dienst.

Es gibt mehrere Gründe, warum es überhaupt Standalone- und Landmark-Relative Certificates gibt. Standalone-Zertifikate können sofort bei der Ausstellung erstellt werden. LRCs hingegen werden stapelweise erzeugt und sind daher nicht sofort verfügbar. Stattdessen müssen Sie eine gewisse Zeit (z. B. 1 Stunde) warten, bis Sie eines erhalten, das zu Ihrem Standalone-Zertifikat passt.

Das ist noch nicht alles. Wie erwähnt, müssen User Agents zunächst Informationen von der CA abrufen, bevor ein LRC authentifiziert werden kann. (Indirekt, über einen Update-Dienst des User Agents.) User Agents werden nicht laufend nach neuen Landmarks suchen, sondern sie nur in regelmäßigen Abständen abrufen. Außerdem können sie zeitweise offline sein. Daher verfügen User Agents in der Regel nicht über die neuesten Landmarks.

Zusammengefasst: 1) Sie brauchen ein Standalone-Zertifikat für alle, 2) ein älteres Landmark-Relative Certificate für die meisten User Agents und 3) ein neueres Landmark-Zertifikat, das nach und nach zu Ihrem Hauptzertifikat wird, sobald die User Agents aufholen.

Stellen Sie sich nur vor, all das manuell zu erledigen. Kein Wunder, dass wir ACME brauchen … Automatisierung ist der einzige Weg, wie das funktionieren kann. Und selbst dann wird die Fehlersuche bei Authentifizierungs- und Performance-Problemen schwieriger. Kontinuierliches Monitoring, um Probleme frühzeitig zu erkennen, wird für einen deutlich größeren Kreis von Organisationen notwendig sein.