Post-Quanten-Schlüsselaustausch, zehn Jahre später

Dieser Beitrag ist der zweite einer Serie über die technischen Entscheidungen rund um die Post-Quanten-Kryptografie. Die Serie begann letzte Woche mit dem Artikel über die Größe von Post-Quanten-Signaturen. Sie müssen den ersten Artikel nicht gelesen haben, um diesen zu verstehen.

Diese Woche hat die IETF den letzten RFC veröffentlicht, der für die vollständige Standardisierung des Post-Quanten-Schlüsselaustauschs in TLS nötig war. Es passt also gut, dass wir uns in dieser Folge den Schlüsselaustausch genauer ansehen.

Dieser Teil der Migration ist zugleich einfacher und komplizierter. Kurz gesagt: Die Bedrohung für den Schlüsselaustausch besteht sofort, und es besteht dringender Handlungsbedarf. Die technische Aufgabe ist einfacher, und das Design kam mit vergleichsweise wenig Streit zustande. So weit der einfache Teil. Komplizierter wird es dadurch, dass die NSA einen Weg gewählt hat, der dem Kurs der technischen Community widerspricht und in der IETF einen bis heute bestehenden Riss verursacht hat. Lesen Sie weiter.

Kryptografische Protokolle bestehen aus vielen Teilen, müssen aber im Kern drei Aspekte abdecken: Authentifizierung, Schlüsselaustausch und Verschlüsselung. Algorithmen, die auf Quantencomputern laufen, bedrohen diese drei Aspekte nicht in gleichem Maß. Gegen die Authentifizierung etwa wird die Bedrohung erst in dem Moment real, in dem authentifiziert wird. In TLS ist die Authentifizierung flüchtig, wir sind also nicht unmittelbar gefährdet. Das ändert sich erst, wenn Quantencomputer praktisch verfügbar sind.

Auf die Verschlüsselung werden Quantencomputer kaum Einfluss haben, doch der Schlüsselaustausch wird schon heute angegriffen, lange bevor es einen funktionsfähigen [kryptografisch relevanten] Quantencomputer gibt. Denn ein fähiger Angreifer kann verschlüsselten Datenverkehr heute sammeln, aufbewahren und später entschlüsseln, sobald er Zugang zu einem Quantencomputer hat. Diese Bedrohung ist besser bekannt als „harvest now, decrypt later“, kurz HNDL.

Angesichts dieser Asymmetrie überrascht es nicht, dass die Arbeit zuerst beim Schlüsselaustausch ansetzte. Google kündigte sein erstes Experiment vor fast genau 10 Jahren an. Ungefähr zu dieser Zeit begann das NIST mit der Planung seines Wettbewerbs zur Post-Quanten-Kryptografie.

Heute unterstützen alle modernen Browser einen hybriden Schlüsselaustausch, der klassische Kryptografie (auf Basis elliptischer Kurven) mit ML-KEM kombiniert, dem Algorithmus, den das NIST hierfür als ersten ausgewählt hat. Im Einsatz sind drei Varianten: X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024. Die Konstruktion ist in allen drei Fällen dieselbe, die Unterschiede liegen vor allem in den gewählten Parametern der elliptischen Kurve und im Sicherheitsniveau.

Technisch besteht dieser neue Schlüsselaustausch aus folgenden Schichten:

• Elliptic Curve Diffie-Hellman (ECDH), von Anfang an Teil der TLS-1.3-Spezifikation
• ML-KEM, 2024 vom NIST standardisiert (als Gewinner bereits 2022 verkündet)
• RFC 9954: Hybrid Exchange in TLS 1.3
• RFC 10024: Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3

Warum so viele Bausteine? Am Anfang gab es nur ECDH. Dann mussten wir ML-KEM erfinden, um der Bedrohung durch Quantencomputer zu begegnen. Weil ML-KEM recht neu und noch nicht so erprobt ist und weil Kryptografie mit elliptischen Kurven klein und schnell ist, entschied man sich für einen hybriden Ansatz als sicherste Lösung. Leider gab es in TLS keine Möglichkeit für einen hybriden Schlüsselaustausch, also musste RFC 9954 entworfen werden. Schließlich wurde RFC 10024 erstellt, um alles zu verbinden.

Beachten Sie auch, dass beide RFCs ausdrücklich „for TLS 1.3“ nennen. Die IETF versucht damit deutlich zu machen, dass diese Arbeiten nicht für frühere Protokollversionen gelten. TLS 1.2 befindet sich im Feature-Freeze (RFC 9851), und es entstehen neue Dokumente, um zu verwerfen, was verworfen werden kann (RFC 10015).

Laut Cloudflare, das ein Dashboard zur beobachteten Post-Quanten-Kryptografie betreibt, nutzen rund 71 % des menschlichen Datenverkehrs auf dem eigenen CDN einen hybriden Schlüsselaustausch und sind damit vor Quantencomputer-Bedrohungen geschützt.

Das ist die Schlagzeile. Scrollt man weiter, sieht man jedoch, dass nur etwa 11 % der Origin-Server denselben Schutz haben. Nach 10 Jahren Arbeit sind wir serverseitig noch weit von einer flächendeckenden Unterstützung quantenresistenter Verfahren entfernt. Die erste Zahl (71 %) klingt gut, aber der fähige Angreifer, um den Sie sich sorgen, greift dort an, wo Sie schwach sind, nicht dort, wo Sie stark sind.

Man könnte meinen, der Schlüsselaustausch sei schnell geklärt gewesen, doch das sieht nur aus der Ferne so aus. Wie erwähnt, hat Google früh begonnen. Das erste Experiment startete im Juli 2016 und endete im November desselben Jahres. Dabei wurde die Machbarkeit des Ansatzes belegt.

Das zweite Experiment begann Ende 2019 als Zusammenarbeit von Cloudflare und Google. Es nutzte denselben hybriden Ansatz mit zwei anderen Algorithmen, NTRU-HRSS und SIKE. Drei Jahre später wurde SIKE gebrochen. Das hat die Idee der Hybride bestärkt.

Nach der Auswahl von ML-KEM durch das NIST lag der Fokus auf hybriden Konstruktionen. Der Algorithmus fand seinen Weg in die Bibliotheken, und die Browser-Hersteller ergänzten die Unterstützung. Cloudflare aktivierte ihn im Oktober 2022 mit den Entwurfsalgorithmen X25519Kyber512Draft00 und X25519Kyber768Draft00. Es dauerte weitere zwei Jahre, bis ML-KEM standardisiert war, danach wechselten alle zu X25519MLKEM768 und Verwandten.

In der vorherigen Folge ging es im gesamten Artikel um den deutlichen Zuwachs bei Post-Quanten-Signaturgrößen. In der Praxis hat bereits der Wechsel zum hybriden Schlüsselaustausch den TLS-Handshake vergrößert, um etwa 1.100 Byte je Richtung.

2024 meldete Google dadurch eine im Median 4 % höhere Handshake-Latenz. AWS berichtete in einer kontrollierten Umgebung von einer leicht längeren Handshake-Zeit aufgrund des höheren Rechenaufwands. Die wichtigste Erkenntnis: Die zusätzliche Latenz entsteht durch die größere Datenmenge, die für den TLS-Handshake übertragen werden muss, und das bei nur rund 1 kB. Der Zuwachs durch Signaturen wird mehr als das Zehnfache hinzufügen.

Die Migration der Schlüsselaustauschverfahren wirkt wie eine Erfolgsgeschichte, doch es gibt eine Unebenheit: Die US-amerikanische National Security Agency (die allmächtige NSA) mag keine hybride Kryptografie.

Im September 2022 veröffentlichte die NSA ihre Commercial National Algorithm Suite 2.0 (neuer Name; zuvor hieß sie NSA Suite B). An sich war das ein guter Schritt, denn er legte früh einen Migrationsfahrplan fest und schuf Klarheit darüber, welche Algorithmen zu verwenden sind. Leider laufen die Anforderungen an den Schlüsselaustausch dem Rest der Welt zuwider.

In der technischen Community bevorzugen die meisten [mein Eindruck, keine wissenschaftliche Messung] den hybriden Ansatz wegen der zusätzlichen Sicherheit. Der Tenor: Wir brauchen mehr Zeit, um die neuen Post-Quanten-Algorithmen anzunehmen und weiter auf Sicherheit zu prüfen. Kryptografen sind von Natur aus sehr konservativ. Passend dazu erschienen diese Woche zwei interessante Forschungsarbeiten, eine, die die Sicherheit von Gitterproblemen ankratzen könnte, und eine zu Classic McEliece. Noch ist nichts gebrochen, aber wir sagen gern: Angriffe werden nur besser.

Am sichtbarsten ist die Spaltung in der TLS-Arbeitsgruppe der IETF, wie Ihnen jeder bestätigen wird, der die Mailingliste verfolgt. Der Streitpunkt: Soll die IETF einen informativen RFC zum reinen ML-KEM-Schlüsselaustausch veröffentlichen? Die eine Seite sagt, wegen der NSA-Anforderungen werde dieser Algorithmus ohnehin eingesetzt, und alle bräuchten dieselbe Spezifikation. Die andere Seite sagt, der hybride Ansatz sei bereits erfolgreich im Einsatz, warum also einem weniger sicheren Verfahren Legitimität verleihen?

Zur Klarstellung: Die aktuelle Richtung ist, diese Arbeit nicht nur als informativ (also nicht als Standard) einzustufen, sondern sie auch als nicht empfohlen zu kennzeichnen. Selbst das hat endlose Diskussionen auf der Liste nicht verhindert. Das Dokument (draft-ietf-tls-mlkem-09) befindet sich derzeit im Last Call. Es ist außerdem bereits in einigen Browsern implementiert, nachrangig zu den Hybriden, aber verfügbar für Server, die den reinen ML-KEM-Ansatz bevorzugen.