Wir bauen eine postquantensichere Zertifizierungsstelle mit Merkle Tree Certificates auf

Wenn Sie eine Adresse in Ihren Browser eingeben, woher wissen Sie dann, dass Sie mit der richtigen Website verbunden sind? Die Web Public Key Infrastructure (WebPKI) ist ein komplexes, verteiltes Ökosystem aus Richtlinien, Protokollen und Infrastrukturbetreibern. Sie schafft die Vertrauensgrundlage dafür, dass Sie nicht auf eine falsche oder schädliche Website umgeleitet werden. In den vergangenen Jahrzehnten hat dieses Ökosystem erhebliche Veränderungen durchlaufen. Eine davon ist die Einführung von Transparenz: Alle Zertifikate müssen inzwischen in öffentlichen Zertifikatstransparenz-Logs erfasst werden. Nun steht die WebPKI vor einer weiteren Herausforderung: Quantencomputer, die heutige kryptografische Verfahren brechen können, rücken näher. Deshalb stellen wir unsere Kryptografie bis 2029 auf postquantensichere Verfahren (PQ-Kryptografie) um.

Diese Umstellung ist jedoch nicht einfach: Würden wir die bisherige Kryptografie in Zertifikaten lediglich durch postquantensichere Verfahren ersetzen, käme es bei einem Einsatz im gesamten Internet zu inakzeptablen Leistungseinbußen. Deshalb brauchen wir einen neuen Ansatz für die WebPKI, bei dem Transparenz von Anfang an ein fester Bestandteil ist. Zugleich muss das neue System postquantensichere Signaturen auch in großem Umfang effizient verarbeiten können.

Merkle Tree Certificates (MTCs) finden inzwischen breite Unterstützung in der Branche und haben sich als Ansatz für die weitere Entwicklung herauskristallisiert. Nach einem erfolgreichen experimentellen Einsatz gemeinsam mit Chrome treibt Cloudflare die Arbeit an MTCs in diesem Jahr mit voller Kraft voran.

Heute haben wir angekündigt, dass Cloudflare eine eigene Zertifizierungsstelle (CA) aufbaut. Diese CA wird auch MTCs ausstellen. Wir streben ihre Aufnahme in den neu eingeführten Quantum-resistant Root Store von Chrome für Anfang 2027 an. Im Rahmen unserer Mission, zum Aufbau eines besseren Internets beizutragen, und getreu unserer Tradition, die stärkste verfügbare Kryptografie kostenlos anzubieten, werden wir die standardmäßige Ausstellung von MTCs kostenlos bereitstellen. Mit einer CA, die sowohl klassische Zertifikate als auch MTCs ausstellt, können wir standardmäßig die sicherste verfügbare Authentifizierungsmethode einsetzen. So ermöglichen wir einem großen Teil des Internets einen reibungslosen Umstieg auf postquantensichere Authentifizierung bei hoher Leistungsfähigkeit.

Das aktuelle Vertrauensökosystem

Um zu verstehen, was sich durch MTCs verändert, sehen wir uns zunächst an, wie Vertrauen im heutigen Web funktioniert.

Auf der Clientseite betreiben Browserhersteller Root-Programme für ihre Browser, die hier als TLS-Clients fungieren. Diese Programme legen die Richtlinien fest, die Zertifizierungsstellen einhalten müssen, um als vertrauenswürdig anerkannt zu werden. Auf der Serverseite übernehmen CAs eine zentrale Rolle: Sie betreiben die Infrastruktur zur Zertifikatsausstellung, prüfen die Kontrolle über eine Domain und bestätigen die Zuordnung eines Domainnamens zu einem öffentlichen Schlüssel.

Wie überprüfen wir aber, ob CAs die Regeln einhalten? Hier kommt die Zertifikatstransparenz (Certificate Transparency, CT) ins Spiel. Sie macht die Zertifikatsausstellung öffentlich überprüfbar. Wenn eine CA ein Zertifikat ausstellt, muss sie es auch in mindestens zwei öffentliche Logs eintragen. Cloudflare betreibt seit 2016 die CT-Log-Familie Nimbus und führt mit Raio eine neue Familie statischer CT-Logs ein.

Das CT-Ökosystem macht Zertifikate zwar öffentlich einsehbar. Das allein garantiert jedoch nicht, dass sie korrekt ausgestellt wurden oder sicher verwendet werden können. Monitoring hilft dabei, indem es die Log-Einträge mit den Erwartungen der Domaininhaber abgleicht und verdächtige Aktivitäten meldet. Cloudflare hat das Certificate Transparency Monitoring 2019 eingeführt und kürzlich allgemein verfügbar gemacht. Außerdem veröffentlichen wir umfangreiche Messdaten zu Zertifikaten auf der Certificate Transparency-Seite von Cloudflare Radar, die früher als Merkle Town bekannt war.

Wenn Unternehmen ihre Server auf postquantensichere Authentifizierung umstellen, wird CT-Monitoring noch wichtiger, um mögliche Rückstufungen auf klassische Authentifizierung zu erkennen. Domaininhaber, die ihre Domains bereits umgestellt haben, sollten CT-Logs auf unerwartet ausgestellte klassische Zertifikate überwachen. So können sie verhindern, dass Clients durch einen böswillig herbeigeführten Downgrade auf weniger sichere Authentifizierung zurückfallen.

Ein Problem des heutigen Systems ist, dass Transparenz erst nachträglich ergänzt wurde. Das führt zu Schwierigkeiten bei der Skalierung. Zertifikate werden häufig mehrfach und in unterschiedlichen Formen in verschiedenen Logs erfasst. Monitoring-Systeme müssen deshalb jedes Log herunterladen und verarbeiten, um keine Zertifikatsausstellung zu übersehen. Das kann teuer werden – und erschwert es, eine vielfältige Landschaft von Log-Betreibern zu fördern, die das gesamte Internet abdecken kann. Nach unseren Schätzungen werden PQ-Signaturen die Datenmenge, die CT-Logs speichern müssen, auf das 40-Fache erhöhen. Diese Skalierungsprobleme und die damit verbundenen Fehlanreize bilden den Kern des Skalierungsproblems bei postquantensicheren Zertifikaten.

Das Skalierungsproblem bei postquantensicheren Zertifikaten

Wir haben ausführlich über die Herausforderungen bei der Skalierung postquantensicherer Kryptografie geschrieben. Kurz gesagt: Um die Serverauthentifizierung im gesamten Internet zu ermöglichen, muss die WebPKI rund eine Milliarde TLS-Server authentifizieren können, ohne den öffentlichen Schlüssel jedes einzelnen Servers vorab auf jedem Client zu hinterlegen. Traditionell lösen CAs dieses Problem mithilfe von Zertifikatsketten, über die das Vertrauen weitergegeben wird. Im Laufe der Zeit sind jedoch weitere Verfahren hinzugekommen, etwa Prüfungen auf Widerruf und Zertifikatstransparenz. Dadurch müssen zusätzliche öffentliche Schlüssel und Signaturen übertragen werden – in einem typischen TLS-Handshake sind es fünf Signaturen und zwei Schlüssel. PQ-Signaturen sind etwa 40-mal so groß wie klassische Signaturen. Der zusätzliche Datenumfang würde bei einem Einsatz in großem Umfang erhebliche Kosten für Clients, CAs, Logs und Monitoring-Systeme verursachen.

Hier kommen Merkle Tree Certificates (MTCs) ins Spiel. Der Spezifikationsentwurf der PLANTS-Arbeitsgruppe der IETF beschreibt eine Architektur für kompakte, effiziente und postquantensichere Zertifikate. MTCs bündeln Zertifikate in einem Merkle-Tree, der nur um neue Einträge erweitert werden darf (Append-only). So kann eine CA die Wurzel des Trees signieren, statt jedes Zertifikat einzeln zu signieren. Browser und andere Clients können dann mithilfe eines kompakten Inklusionsbeweises – einer Folge kryptografischer Hashwerte, die die Aufnahme in den Tree belegt – prüfen, ob ein Zertifikat zum signierten Treekopf gehört. Eine zentrale Idee hinter MTCs lautet: „Nicht erst ausstellen und dann protokollieren, sondern durch das Protokollieren ausstellen.“ Durch die Kopplung von Ausstellung und Protokollierung wird Transparenz zu einer Voraussetzung für den Betrieb statt zu einer nachträglichen Ergänzung.

Die Rolle einer Zertifizierungsstelle in einer neu gestalteten PKI

Wir entwickeln die Infrastruktur zur Ausstellung von MTCs als festen Bestandteil unserer neuen Cloudflare-CA. Dabei müssen wir die neuen Anforderungen der Root-Programme für postquantensichere Zertifikate berücksichtigen und gleichzeitig die Software für Ausstellung und Spiegelung entwickeln. Parallel dazu bauen wir die Einrichtungen, Betriebsabläufe und Compliance-Strukturen einer klassischen CA auf – eine anspruchsvolle Aufgabe!

Der Vorteil ist, dass wir die Anforderungen und die Architektur dieser neuen, postquantensicheren PKI von Anfang an berücksichtigen können. Wir richten unsere Infrastruktur an den Werten und dem globalen Netzwerk von Cloudflare aus. Dabei wollen wir den Aufbau so transparent wie möglich gestalten.

Sehen wir uns die für MTCs angepasste Architektur an:

Im Vergleich zum klassischen CA-Ökosystem bleiben die Aufgaben einer CA weitgehend gleich: Sie prüft die Kontrolle über eine Domain, bestätigt die Zuordnung zu einem öffentlichen Schlüssel und stellt Zertifikate aus. Der wesentliche Unterschied besteht darin, dass die CA im MTC-Ökosystem Zertifikate nicht mehr direkt signiert und anschließend protokolliert. Stattdessen betreibt sie ein Transparenz-Log auf Grundlage eines Merkle-Trees. Ein Inklusionsbeweis belegt, dass ein Zertifikat in diesem Tree enthalten ist, und ermöglicht dessen Überprüfung anhand eines vertrauenswürdigen, signierten Treezustands. CAs werden außerdem Dienste zur Spiegelung und Mitunterzeichnung betreiben, sogenannte Mirroring Cosigners. Diese speichern eine Kopie der Ausstellungs-Logs, prüfen, dass neue Einträge lediglich angehängt und bestehende Einträge nicht verändert werden, und stellen die Transparenz und Verfügbarkeit der Logs für das gesamte Ökosystem sicher.

MTCs ausstellen

MTCs gibt es in zwei Varianten. Beide lassen sich im X.509-Zertifikatsformat kodieren, das heutige Clientsoftware bereits erkennt – allerdings mit einem „ungewöhnlichen“ Signaturalgorithmus. Bei der eigenständigen Variante enthält das Signaturfeld des Zertifikats einen mitunterzeichneten Treekopf eines Ausstellungs-Logs und einen Inklusionsbeweis. Dieser besteht aus einer Folge von Hashwerten und belegt, dass das Zertifikat im Log enthalten ist. Können Clients die mitunterzeichneten Treeköpfe außerhalb der TLS-Verbindung erhalten (Out-of-band), etwa über den Aktualisierungsmechanismus ihres Browsers, lässt sich stattdessen die Landmark-relative Variante verwenden. Deren Signaturfeld enthält nur den kompakten Inklusionsbeweis und keine umfangreichen postquantensicheren Signaturen.

Zur Veranschaulichung betrachten wir die Ausstellung eines eigenständigen Zertifikats. Benötigt eine Website ein Zertifikat für ihre Domain, kann ihr Betreiber es über das Automatic Certificate Management Environment (ACME)-Protokoll bei einer CA beantragen. ACME regelt Zertifikatsanfragen, die Prüfung der Kontrolle über eine Domain und die Abläufe bei der Ausstellung. Cloudflares ACME-Infrastruktur wird auf einem Fork von Boulder basieren, der weitverbreiteten und bewährten ACME-Software hinter Let’s Encrypt. Let’s Encrypt arbeitet aktiv an der Unterstützung von MTCs in Boulder. Wir planen, einen eigenen Fork zu pflegen, der diese Änderungen aus dem ursprünglichen Projekt mit Cloudflare-spezifischen Anpassungen kombiniert. Wo möglich, werden wir unsere Verbesserungen auch in das ursprüngliche Projekt einbringen.

Geht bei der MTC-CA eine Anfrage zur Zertifikatsausstellung ein, prüft ihr ACME-Server, ob der Antragsteller tatsächlich die Kontrolle über die Domain hat. Nach erfolgreicher Prüfung serialisiert die CA die Daten und fügt sie einem Log hinzu, das ausschließlich um neue Einträge erweitert werden darf.

Nachdem der MTC-Eintrag zum Ausstellungs-Log hinzugefügt wurde, berechnet die CA den aktualisierten Zustand des Logs und signiert einen Checkpoint, der diesen Zustand beschreibt. Der Checkpoint bestätigt, dass die CA sämtliche Einträge ausgestellt hat, die bis zu diesem Zeitpunkt im Merkle-Tree des Logs enthalten sind.

Anschließend sendet die CA den aktualisierten Log-Zustand und den neuen Checkpoint an einen vertrauenswürdigen Mitunterzeichner. Dieser speichert dauerhaft eine Kopie des Ausstellungs-Logs und prüft, dass der neue Zustand ausschließlich durch das Anhängen neuer Einträge entstanden ist, mit dem vorherigen Tree konsistent ist und korrekt aufgebaut wurde. Die zusätzliche Mitunterzeichnung gibt Clients und Monitoring-Systemen die Gewissheit, dass eine weitere vertrauenswürdige Partei denselben Log-Zustand gesehen und überprüft hat. Sie bestätigt damit, dass die CA verschiedenen Teilen des Ökosystems keine voneinander abweichenden Ansichten der Zertifikatsausstellung präsentiert. Außerdem bleiben die ausgestellten Zertifikate für das Monitoring verfügbar, selbst wenn das Ausstellungs-Log der CA nicht erreichbar ist.

Der Richtlinienentwurf für das Quantum-resistant Root Program von Chrome schreibt mindestens zwei Mitunterzeichnungen vor: eine von einem durch Chrome anerkannten Mirroring Cosigner, den eine eigenständige Organisation betreibt, und eine von der ausstellenden MTC-CA selbst. Deshalb werden wir die Ausstellungs-Logs anderer CAs im Pilotprogramm spiegeln und für unsere eigenen ausgestellten Zertifikate mindestens eine unabhängige Mitunterzeichnung verlangen.

Wir werden unseren Mirroring Cosigner in Azul implementieren, unserem quelloffenen, auf Rust basierenden Transparenz-Log. Für größtmögliche Interoperabilität wird er das tlog-mirror-Protokoll von c2sp unterstützen.

Sobald die Mitunterzeichnung eines Mirroring Cosigners vorliegt, erstellt die CA ein MTC mit den Mitunterzeichnungen, dem öffentlichen Schlüssel des Servers und einem Inklusionsbeweis. Anschließend sendet sie das MTC an den Server, der es für TLS verwenden kann.

PQ-Signaturen effizient bereitstellen mit der Landmark-Optimierung

Eigenständige Zertifikate funktionieren zwar, übertragen beim TLS-Handshake aber weiterhin umfangreiche PQ-Signaturen. Das begrenzt ihre Effizienz. Die entscheidenden Leistungsverbesserungen des MTC-Ansatzes ergeben sich durch Landmark-relative Zertifikate.

Statt mit jedem Zertifikat Mitunterzeichnungen zu übertragen, können CAs eine Folge von Teilbäumen, die sämtliche aktiven Zertifikate im Log abdecken, als Landmark festlegen. Diese Teilbäume verteilen sie zusammen mit den Daten zu ihrer Authentifizierung über einen separaten Aktualisierungsdienst an die Clients. Während des TLS-Handshakes authentifiziert der Browser den Server, indem er prüft, ob dessen Zertifikatsdaten – einschließlich Domainname und öffentlichem Schlüssel – in einem vertrauenswürdigen Teilbaum des CA-Logs enthalten sind. Verknüpft der Inklusionsbeweis das Zertifikat mit einer mitunterzeichneten Landmark und weist der Server während des TLS-Handshakes nach, dass er den zugehörigen privaten Schlüssel besitzt, weiß der Client, dass er mit dem richtigen Server kommuniziert.

Durch die regelmäßige Übertragung dieser Signaturen und Tree-Metadaten außerhalb der TLS-Verbindungen kann eine kleine Anzahl von Signaturen für MTC-Zertifikatsgruppen effizient Milliarden von Zertifikaten einer CA abdecken. Landmarks sind bei einem Einsatz in großem Umfang zwar effizienter, machen eigenständige MTCs aber nicht überflüssig. Clients können frisch installiert sein, zwischenzeitlich offline gewesen sein oder das benötigte Landmark-Update noch nicht erhalten haben. Deshalb müssen Server weiterhin auf eigenständige Zertifikate zurückgreifen können.

MTCs in der Praxis und die Ergebnisse unseres Experiments mit Chrome

In diesem Jahr haben wir gemeinsam mit Chrome getestet, ob MTCs in der Kommunikation zwischen Client und Server praktikabel sind. Dafür betrieben wir eine „Bootstrap-CA“, also eine simulierte Zertifizierungsstelle, die den Ausstellungsprozess nachbildete. Sie stellte MTCs für ausgewählte Domains im kostenlosen Cloudflare-Tarif aus. Diese MTCs waren durch eine klassische Zertifikatskette abgesichert und wurden an 50 % der Nutzer von Chrome Beta 146 ausgeliefert. Im Laufe des Experiments haben wir erfolgreich Milliarden von MTCs ausgeliefert.

Bei TLS zeigte sich, dass der typische Fall sehr effizient ist: Mit einem Landmark-relativen Zertifikat müssen beim Handshake nur ein öffentlicher Schlüssel, eine Signatur und ein Inklusionsbeweis von weniger als 1 kB übertragen werden. Ließ sich mit dem Client kein Landmark-relatives Zertifikat aushandeln, griffen wir im Experiment auf die klassische Zertifikatskette zurück, statt ein eigenständiges MTC auszuliefern. Auch bei der Zertifikatstransparenz verändern MTCs die Skalierungseigenschaften: Das Log muss nur Hashwerte öffentlicher Schlüssel speichern. Einzelne Einträge benötigen keine eigenen Signaturen, da die Signatur des Treekopfs das gesamte Log abdeckt. So wird eine Vervielfachung der Zertifikatseinträge vermieden: Das Ausstellungs-Log der CA ist die maßgebliche Quelle für sämtliche von ihr ausgestellten Zertifikate, und Systeme, die das Log auswerten, müssen jedes Zertifikat nur einmal abrufen.

Das Ergebnis: MTCs funktionieren in der Praxis! Mit Landmark-relativen MTCs waren TLS-Handshakes im Median 9 % schneller als mit einer klassischen Zertifikatskette. Zugegeben: Ein Großteil dieses Vorteils entsteht dadurch, dass die Zwischenzertifikate entfallen. Da wir MTCs mit klassischen Signaturen getestet haben, erwarten wir bei postquantensicheren Signaturen eine noch größere Verbesserung. Die Ergebnisse und die umfangreiche branchenweite Zusammenarbeit an MTCs in der PLANTS-Arbeitsgruppe der IETF haben uns überzeugt. Deshalb haben wir im vergangenen Monat, also im August 2026, damit begonnen, das Experiment auslaufen zu lassen.

Wie es mit MTCs weitergeht

Wir freuen uns, dass unser Experiment mit Chrome gezeigt hat, dass MTCs in der Praxis funktionieren. Besonders freuen wir uns darauf, künftig als reguläre CA Zertifikate auszustellen.

Es bleiben jedoch grundlegende Fragen, die wir nur durch ein groß angelegtes Experiment gemeinsam mit dem gesamten PKI-Ökosystem beantworten können. Können unabhängige Monitoring-Systeme MTC-Ausstellungs-Logs in dem Umfang verarbeiten und überprüfen, der im produktiven Betrieb anfällt? Werden genügend unterschiedliche CAs und Mitunterzeichner entstehen, um die für ein resilientes System notwendige Vielfalt zu gewährleisten? Wie sollten Browser die Leistungsvorteile kompakter Landmark-relativer MTCs gegen die erforderlichen Ausweichmöglichkeiten für Clients ohne aktuelle Landmarks abwägen? MTCs haben sich als maßgeblicher Ansatz für postquantensichere Authentifizierung etabliert. Um ihre Eignung im produktiven Betrieb in der Größenordnung des gesamten Internets nachzuweisen, müssen jedoch unterschiedliche Root-Programme, Browserhersteller, CAs, Betreiber von Mirrors, Monitoring-Systeme und die weitere Community zusammenarbeiten.

Wir betrachten es als Privileg, an dieser nächsten Entwicklungsphase der WebPKI mitzuwirken, und nehmen die Verantwortung für den Betrieb einer CA-Infrastruktur ernst. CAs nehmen im Vertrauensökosystem eine privilegierte Stellung ein. Browser, Domaininhaber und Endnutzer verlassen sich darauf, dass sie Identitäten korrekt überprüfen, Signaturschlüssel schützen, Richtlinien einhalten und zuverlässig arbeiten. Bevor Browser der Cloudflare-CA bei der Ausstellung von MTCs vertrauen können, müssen wir ihre Aufnahme in den Quantum-resistant Root Store von Chrome beantragen und ein strenges Prüfverfahren durchlaufen. Wir begrüßen diese Prüfung und legen an uns selbst dieselben hohen Maßstäbe an wie an jede andere CA, der die Sicherheit des Internets mit anvertraut wird. Wir hoffen, dass weitere CAs entstehen, die die Einführung von MTCs unterstützen, und freuen uns auf die Zusammenarbeit mit allen Browserherstellern, die MTCs einsetzen möchten.