Post-Quantum ohne aufgeblähte Handshakes: Let’s Encrypts neuer Weg

Let’s Encrypt hat erstmals einen konkreten Fahrplan für quantensichere Zertifikate vorgelegt. Die Zertifizierungsstelle will dafür auf sogenannte Merkle Tree Certificates (MTCs) setzen, statt bestehende X.509-Zertifikate einfach mit größeren Post-Quantum-Signaturen zu versehen. Eine Testumgebung soll Ende 2026 starten, ein produktionsreifes Angebot 2027 folgen. Neu ist weniger das Bekenntnis zur Post-Quantum-Kryptografie als die Festlegung auf einen bestimmten technischen Weg.

Let’s Encrypt zählt zu den weltweit wichtigsten Zertifizierungsstellen für automatisiert ausgestellte TLS-Zertifikate. Die Debatte um quantensichere Kryptografie läuft seit Jahren, drehte sich bislang aber vor allem um den Schlüsselaustausch. Dahinter steht die Sorge, dass Angreifer verschlüsselten Datenverkehr heute mitschneiden und später mit Quantencomputern entschlüsseln könnten. Die Absicherung von Zertifikaten und Signaturen galt lange als weniger dringlich, weil ein Angreifer dafür schon während der laufenden Kommunikation einen leistungsfähigen Quantencomputer bräuchte. Mit den inzwischen vom US-Standardisierungsinstitut NIST verabschiedeten Verfahren und den Migrationsplänen von Google und Cloudflare rückt nun auch die Authentifizierung in den Vordergrund.

Festlegung mit Signalwirkung

Künftig sollen Merkle Tree Certificates der bevorzugte Weg sein, um das Web-PKI quantensicher zu machen. An den nötigen Standards arbeitet Let’s Encrypt bereits in der IETF-Arbeitsgruppe PLANTS mit – die Ausstellung der MTCs wird zudem über eine ACME-Erweiterung abgewickelt. Die Entscheidung wiegt schwer, denn mit Hunderten Millionen aktiven Zertifikaten prägt die Organisation die technische Entwicklung der Web-PKI maßgeblich.

Dabei steht Let’s Encrypt nicht allein. Cloudflare und Chrome testen MTCs bereits in einem Feldversuch gegen echten Internet-Traffic, und Chrome hat den Ansatz zu seinem bevorzugten Weg für quantensichere Zertifikate im öffentlichen Web erklärt.

Hinter der Wahl steckt ein handfestes Problem quantensicherer Signaturen: Sie brauchen deutlich mehr Platz als heutige Verfahren. Let’s Encrypt verweist auf ML-DSA-44, einen der NIST-Standards. Dessen Signaturen sind mit rund 2.420 Bytes etwa 38-mal größer als die heute verbreiteten ECDSA-P256-Signaturen (64 Bytes). Würde man Zertifikate und Zertifikatsketten unverändert auf solche Verfahren umstellen, würden einzelne TLS-Handshakes auf über 10 Kilobyte anschwellen. Das würde Verbindungen verlangsamen und in manchen Netzen sogar die Fehlerrate erhöhen.

Wie Merkle Tree Certificates funktionieren

Merkle Tree Certificates gehen deshalb einen anderen Weg: Statt jedes Zertifikat einzeln zu signieren, fasst die Zertifizierungsstelle viele Zertifikate in einem Merkle-Baum zusammen. Signiert wird nicht jedes einzelne Zertifikat, sondern nur die Wurzel des Baums. Clients erhalten anschließend einen kompakten Nachweis darüber, dass ein bestimmtes Zertifikat zu diesem Baum gehört.

Das Prinzip kennen viele Administratoren aus anderen Bereichen – etwa Git-Repositories, Certificate-Transparency-Logs oder Blockchains. Einzelne Objekte werden dort nicht jeweils separat abgesichert, sondern über einen Baum auf einen gemeinsamen kryptografischen Anker zurückgeführt.

Kleinere Handshakes trotz größerer Signaturen

Nach Angaben von Let’s Encrypt schrumpfen die Authentifizierungsdaten im TLS-Handshake dadurch deutlich. Browser sollen dafür regelmäßig sogenannte Landmarks aktualisieren, die als Referenzpunkte für die Prüfung dienen. Im Regelfall genügt dann eine Signatur, ein öffentlicher Schlüssel und ein Merkle-Nachweis. So lässt sich der zusätzliche Ballast quantensicherer Signaturen weitgehend vermeiden.

Auch die Certificate Transparency profitiert von dem Ansatz. Heute stellt eine Zertifizierungsstelle ein Zertifikat zunächst aus und veröffentlicht es danach in separaten Transparenzprotokollen. Bei MTCs gehört die Transparenz dagegen zum Zertifikatsmodell selbst: Weil jedes Zertifikat Teil eines veröffentlichten Merkle-Baums ist, kann es gar nicht erst außerhalb dieser Struktur existieren. Ausstellung und Protokollierung rücken damit zusammen.

Bekannte Technik, lange Übergangsphase

Neuland ist die Technik für Let’s Encrypt nicht. Die Organisation betreibt seit 2019 eigene Certificate-Transparency-Logs, die ebenfalls auf Merkle-Bäumen basieren. Mit dem Betrieb solcher Strukturen im großen Maßstab hat sie also bereits Erfahrung.

Für Nutzer ändert sich vorerst nichts. Bestehende Zertifikate stellt Let’s Encrypt weiterhin wie gewohnt aus und verlängert sie automatisch. Die Umstellung hängt zudem von mehreren Faktoren ab: Neben der Standardisierung durch die IETF müssen Browser, Kryptobibliotheken, ACME-Clients und die Root-Programme der Browserhersteller die neuen Verfahren unterstützen.

Beim Schlüsselaustausch drängt die Zeit

Bei der Authentifizierung lässt sich die Umstellung also noch in Ruhe vorbereiten – beim Schlüsselaustausch drängt Let’s Encrypt dagegen zur Eile. Hier greift das Szenario „heute mitschneiden, später entschlüsseln“ (auch „harvest now, decrypt later“ genannt), weshalb jede Verbindung ohne quantensicheren Schlüsselaustausch ein Risiko darstellt.

Server-Betreibern rät Let’s Encrypt deshalb, hybriden Post-Quantum-Schlüsselaustausch (X25519MLKEM768) zu aktivieren. Große Browser und Betriebssysteme unterstützen das Verfahren bereits; es auf dem Server einzuschalten, sei eine der wirkungsvollsten Maßnahmen, die man in diesem Jahr ergreifen könne.

Festlegung auf einen Migrationspfad

Die Ankündigung markiert damit weniger den Start quantensicherer Zertifikate als die Festlegung auf einen konkreten Migrationspfad. Setzt sich MTC durch, dürfte das eine der größten strukturellen Änderungen der Web-PKI seit Certificate Transparency und dem ACME-Protokoll werden. Die Details hat Let’s Encrypt in einem Blogeintrag zur Post-Quantum-Zukunft veröffentlicht.

(fo)