Chrome setzt auf Merkle-Tree-Zertifikate: So soll HTTPS quantensicher werden

Google plant, die Sicherheitsarchitektur des Webs grundlegend weiterzuentwickeln: Statt klassische X.509-Zertifikate mit Post-Quanten-Kryptografie nachzurüsten, setzt Chrome auf ein neues Zertifikatsformat namens Merkle-Tree-Certificates (MTCs). Die Umstellung soll HTTPS-Verbindungen gegen zukünftige Angriffe durch Quantencomputer wappnen – und dabei die Bandbreiteneffizienz gegenüber bisherigen Lösungsansätzen erheblich verbessern. Die Internet Engineering Task Force (IETF) hat zu diesem Zweck bereits eine eigene Arbeitsgruppe eingerichtet, an der Google aktiv mitwirkt.

Warum klassische Zertifikate an ihre Grenzen stoßen

Quantenresistente Kryptografiealgorithmen bringen ein strukturelles Problem mit sich: Sie erzeugen deutlich größere Datenpakete als klassische Verfahren. Bei traditionellen X.509-Zertifikaten würde ihr Einsatz die Zertifikatsketten in TLS-Verbindungen erheblich aufblähen – mit spürbaren Leistungseinbußen für das gesamte Web als Folge.

Aus diesem Grund hat Chrome entschieden, keine Post-Quanten-Kryptografie in klassische X.509-Zertifikate im Chrome Root Store einzuführen. Stattdessen entwickelt Google gemeinsam mit Partnern ein neues Zertifikatsmodell: Merkle-Tree-Certificates, kurz MTCs. Diese werden derzeit in der IETF-Arbeitsgruppe „PKI, Logs, And Tree Signatures“ (PLANTS) standardisiert, die sich explizit den Bandbreiten- und Leistungsherausforderungen moderner quantenresistenter Kryptografie widmet.

Das Grundprinzip von MTCs unterscheidet sich wesentlich vom bisherigen Ansatz:

• Eine Zertifizierungsstelle (CA) signiert einen einzigen „Tree Head“, der potenziell Millionen von Zertifikaten repräsentiert
• Das an den Browser übermittelte „Zertifikat“ ist lediglich ein schlanker kryptografischer Aufnahmenachweis in diesen Baum
• Die serialisierte Signaturkette der klassischen PKI-Infrastruktur entfällt vollständig
• Der Umfang der beim TLS-Handshake übertragenen Authentifizierungsdaten wird auf ein absolutes Minimum reduziert

Damit entkoppelt das MTC-Modell die kryptografische Sicherheitsstärke von der tatsächlichen Datenmenge, die zwischen Server und Browser ausgetauscht wird – ein technischer Vorteil, der mit wachsenden Schlüssellängen künftiger Post-Quanten-Algorithmen zunehmend an Bedeutung gewinnt.

Transparenz als strukturelle Eigenschaft – nicht als Zusatz

Ein zentrales Merkmal des MTC-Ansatzes ist die eingebaute Zertifikatstransparenz. Im bestehenden Certificate-Transparency-Ökosystem (CT) ist die Protokollierung von Zertifikaten eine ergänzende Anforderung, die beim TLS-Handshake zusätzlichen Overhead verursacht. Bei MTCs ist Transparenz dagegen eine untrennbare Eigenschaft des Ausstellungsprozesses selbst: Es ist technisch ausgeschlossen, ein Zertifikat auszustellen, ohne es in einen öffentlichen Baum einzutragen.

Das bedeutet in der Praxis: Die Sicherheitseigenschaften, die das heutige CT-System bietet – öffentliche Nachvollziehbarkeit jedes ausgestellten Zertifikats – sind bei MTCs ohne zusätzliche Datenübertragung beim Verbindungsaufbau gewährleistet. Dieser Ansatz macht Zertifikatsmissbrauch strukturell schwieriger, weil jede Ausstellung zwingend öffentlich und prüfbar ist.

Drei Phasen bis zur vollständigen Einführung

Chrome verfolgt einen klar definierten, stufenweisen Einführungsplan, der den laufenden Betrieb des Webs zu keinem Zeitpunkt beeinträchtigen soll:

• Phase 1 (laufend): In Zusammenarbeit mit Cloudflare wird eine Machbarkeitsstudie im realen Internetverkehr durchgeführt. Jede MTC-basierte Verbindung wird dabei durch ein herkömmliches, vertrauenswürdiges X.509-Zertifikat als Fallback abgesichert. Diese Absicherung ermöglicht es, Leistungsgewinne unter realen Bedingungen zu messen und die Zuverlässigkeit der MTC-Ausstellung zu überprüfen – ohne dass Nutzer dabei ein verändertes oder unsichereres Verbindungsverhalten erleben.
• Phase 2 (Q1 2027): Nach erfolgreicher Validierung der Kerntechnologie sollen CT-Log-Betreiber, die bis spätestens 1. Februar 2026 mindestens ein als „verwendbar“ eingestuftes Log in Chrome betreiben, zur Teilnahme an der ersten öffentlichen MTC-Einführung eingeladen werden. Diese Betreiber wurden bewusst als erste Zielgruppe gewählt: Sie verfügen bereits über die hochverfügbare Infrastruktur und die operative Erfahrung, die für den Betrieb globaler Sicherheitsdienste erforderlich ist. Da MTCs zudem erhebliche architektonische Überschneidungen mit CT aufweisen, sind sie technisch besonders gut für diesen Schritt geeignet.
• Phase 3 (Q3 2027): Parallel zu Phase 2 sollen die Anforderungen für die Aufnahme weiterer Zertifizierungsstellen in den neu einzurichtenden „Chrome Quantum-resistant Root Store“ (CQRS) finalisiert werden. Dieses neue Root-Programm unterstützt ausschließlich MTCs und ist damit speziell auf die Anforderungen eines post-quantum-fähigen Webs ausgerichtet. Es wird zunächst parallel zum bestehenden Chrome Root-Programm betrieben, um einen kontrollierten Übergang mit minimalen Risiken zu gewährleisten. Zusätzlich wird in dieser Phase eine Option eingeführt, mit der Websites sich aktiv für eine ausschließliche Nutzung quantenresistenter Zertifikate entscheiden können.

Neue Anforderungen an das CA-Ökosystem

Die Einführung des CQRS ist für Google auch Anlass, strukturelle Reformen im Umgang mit Zertifizierungsstellen voranzutreiben. Das Ziel: ein moderneres, transparenteres und robusteres Fundament für das gesamte TLS-Ökosystem. Geplante Maßnahmen umfassen:

• Ausschließliche Nutzung von ACME-Workflows, um Komplexität zu reduzieren und die kryptografische Agilität sicherzustellen, die für eine schnelle Reaktion auf neue Bedrohungen notwendig ist
• Modernisierung des Widerrufsstatus-Frameworks als Ersatz für veraltete CRL-Mechanismen, mit einem Fokus auf Ereignisse, bei denen Schlüssel tatsächlich kompromittiert wurden
• Erforschung öffentlich nachprüfbarer Domain-Control-Validierung (DCV), bei der Validierungsnachweise dauerhaft und für jede Partei unabhängig überprüfbar verfügbar sind – das schafft ein offenes Modell von „DCV-Monitoren“ ohne zentrale Kontrollinstanz
• Reformiertes CA-Aufnahmemodell, das nachgewiesene Betriebsqualität priorisiert: Neue CA-Kandidaten sollen ihre Zuverlässigkeit zunächst als Mirroring Cosigner und DCV-Monitore unter Beweis stellen, bevor sie als vertrauenswürdige Aussteller zugelassen werden
• Weiterentwicklung der Drittüberwachung hin zu kontinuierlicher, extern überprüfbarer Kontrolle – als Ergänzung oder perspektivisch als Ersatz für die bislang üblichen jährlichen Drittprüfungen

Diese Maßnahmen zielen insgesamt darauf ab, das Vertrauen in Zertifizierungsstellen nicht allein auf formalen Zulassungsprozessen, sondern auf nachgewiesener und kontinuierlich überprüfbarer Leistung zu begründen.

Parallelbetrieb sichert den Übergang

Google betont ausdrücklich, dass das bestehende Chrome Root-Programm mit seinen aktuellen CA-Partnern während der gesamten Übergangsphase vollständig unterstützt wird. Geplante Root-Rotationen sollen sicherstellen, dass bestehende, nicht-quantenresistente Hierarchien stabil bleiben und die Anforderungen des Chrome Root-Programms weiterhin erfüllen.

Noch für das laufende Jahr plant Google zudem, traditionelle X.509-Zertifikate mit quantenresistenten Algorithmen für private PKIs zu unterstützen – also für Infrastrukturen, die nicht im öffentlichen Chrome Root Store verankert sind. Parallel dazu soll die Arbeit an MTCs in internationalen Standardisierungsgremien wie der IETF und C2SP fortgeführt werden, um sicherzustellen, dass die gewonnenen Erkenntnisse in offene Standards einfließen und Chrome die Normänderungen entsprechend abbildet.

Hier geht’s weiter

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky

Folgen Sie uns auf Mastodon

Hamsterrad Rebell – Cyber Talk