Der Trick ist kein kleinerer Algorithmus. MTCs ändern, wie Zertifikate ausgestellt werden, sodass die meisten Signaturen aus dem Handshake verschwinden, statt nur kleiner zu werden.

In unserem Beitrag zum quantensicheren Schlüsselaustausch in TLS haben wir die Authentifizierung ausgeklammert. Die Verschlüsselung war die dringende Hälfte, denn Harvest-now-decrypt-later-Angreifer können Traffic heute aufzeichnen und später entschlüsseln. Bei der Authentifizierung ist das anders, da sie nur während eines laufenden Handshakes angegriffen werden kann. Was heute aufgezeichnet wird, wird also nachträglich nicht verwundbar.

Zweitrangig ist sie deshalb nicht. Sobald ein kryptografisch relevanter Quantencomputer existiert, kann ein Angreifer den privaten Schlüssel einer Website zurückgewinnen, um sich als diese Website auszugeben, oder den privaten Schlüssel einer CA, um sich als jede beliebige Website auszugeben. Selbst eine Website, die ein Post-Quantum-Zertifikat ausliefert, bleibt angreifbar, solange Browser noch klassische Zertifikate akzeptieren. Und fällt die Authentifizierung, fällt auch die Vertraulichkeit, denn wer sich als Server ausgeben kann, kann einen Man-in-the-Middle-Angriff durchführen und alles mitlesen, mit oder ohne Post-Quantum-Schlüsselaustausch.

Das Web PKI zu verändern dauert Jahre, deshalb wird die Migration schon jetzt vorbereitet und nicht erst am Q-Day, dem Tag, an dem ein solcher Quantencomputer da ist.

Dieser fünfte und letzte Beitrag unserer PQC-Serie befasst sich mit MTCs, derzeit dem plausibelsten Weg zu einem quantensicheren Web PKI, und misst, was sie im Vergleich dazu kosten, einfach jede Signatur auf ein Post-Quantum-Verfahren umzustellen.

Die Schwachstelle dieses Modells ist, dass Browser über hundert CAs vertrauen und jede von ihnen ein gültiges Zertifikat für jede beliebige Domain ausstellen kann. Ihre Website ist damit nur so sicher wie die schwächste CA, und solche Vorfälle hat es bereits gegeben. 2011 wurde die niederländische CA DigiNotar kompromittiert und stellte Hunderte gefälschte Zertifikate aus, darunter eines für *.google.com, und der einzige Grund, warum das aufflog, war, dass Chrome die Schlüssel gepinnt hatte, die Googles Zertifikate verwenden sollten.

Als Gegenmassnahme wurde 2013 Certificate Transparency (CT) eingeführt. Die Idee ist, dass CAs jedes ausgestellte Zertifikat in öffentlichen, nur erweiterbaren Logs erfassen, damit jeder alle je für eine Domain ausgestellten Zertifikate sehen, betrügerische erkennen und die verantwortliche CA ermitteln kann. Und damit das auch wirklich geschieht, akzeptieren Browser wie Chrome und Safari ein Zertifikat nur, wenn es signierte Nachweise, sogenannte SCTs, von mindestens zwei unabhängigen Logs enthält.

Zusammengenommen enthält ein typischer TLS-Handshake heute fünf Signaturen und zwei öffentliche Schlüssel:

• die Signatur der Root-CA auf dem Zwischenzertifikat
• die Signatur der Intermediate-CA auf dem Server-Zertifikat
• zwei SCTs, die signierten Zusagen der CT-Logs, dass das Zertifikat erfasst wurde
• die Signatur des Servers über den Handshake (CertificateVerify)

Die beiden öffentlichen Schlüssel sind jene des Servers und der Intermediate-CA. Der Schlüssel der Root wird nicht gesendet, da der Browser ihn bereits hat, und dasselbe gilt für die Schlüssel der CT-Logs.

Das Problem ist, dass all diese Elemente noch auf RSA oder elliptischen Kurven beruhen, die ein kryptografisch relevanter Quantencomputer bricht. Die naheliegende Lösung ist also, jedes Element durch ein Post-Quantum-Pendant zu ersetzen, und genau das haben wir zuerst ausprobiert.

Auf der klassischen Seite haben wir unsere Kette so aufgebaut, wie die meisten Websites sie heute haben, mit CAs auf P-384 sowie Server-Schlüssel und CT-Logs auf P-256. Auf der Post-Quantum-Seite haben wir überall ML-DSA-44 verwendet, da es dasselbe Sicherheitsniveau von 128 Bit bietet wie P-256. Wie die Tabelle zeigt, sind seine Schlüssel aber etwa 20-mal und seine Signaturen fast 40-mal so gross.

Die Grösse explodiert regelrecht. Mit ML-DSA-44 wächst der Handshake von 5,7 KB auf 21,2 KB, fast das Vierfache von ECDSA. Fast alles davon entfällt auf die TLS-Nachricht Certificate, die die ganze Kette transportiert und mit ML-DSA-44 von 1,7 KB auf 13,5 KB anwächst, da die beiden Zertifikate und die beiden SCTs nun je eine 2’420-Byte-Signatur enthalten.

Bei der Zeit wird es interessanter. ECDSA braucht 47 ms, ML-DSA-44 dagegen 65 ms, also einen ganzen zusätzlichen «Round Trip». Die Kryptografie ist daran nicht schuld, denn Signieren und Verifizieren mit ML-DSA kostet nur wenige Millisekunden CPU-Zeit. Die Ursache ist das initiale Congestion Window von TCP, das jede Seite standardmässig daran hindert, im ersten Round Trip mehr als 10 Pakete, also etwa 14 KB, zu senden (RFC 6928), um das Netzwerk nicht zu überlasten. Mit ECDSA passt die Antwort des Servers locker hinein, mit ML-DSA-44 sind es aber schon fast 20 KB. Der Server muss also warten, bis der Client die ersten Pakete bestätigt hat, bevor er den Rest sendet, und das kostet einen weiteren Round Trip. Das ist ein Rückschritt, denn TLS 1.3 wurde so entworfen, dass der Handshake in einem einzigen Round Trip abgeschlossen ist, wo TLS 1.2 noch zwei brauchte.

Und es geht nicht nur um ein paar Millisekunden. Grössere Handshakes führen nachweislich auch unterwegs zu Problemen. Cloudflare beobachtete einen starken Anstieg von Fehlern bei Clients und Middleboxes, sobald Zertifikatsketten um mehr als 10 KB wuchsen. ML-DSA-44 fügt über 15 KB hinzu. Das kennen wir bereits vom Post-Quantum-Schlüsselaustausch, als manche Server und Middleboxes die Verbindung zurücksetzten, weil der ClientHello nicht mehr in ein einziges Paket passte. Browser sind genauso vorsichtig. 2024 bezeichnete das Chrome-Team rund 2 KB mehr im Handshake als «sehr schmerzhaft, aber plausibel» und rund 7 KB als «nicht plausibel, ausser ein kryptografisch relevanter Quantencomputer steht unmittelbar bevor».

Deshalb wird dieser Weg für das öffentliche Web nicht eingeschlagen. Chrome hat keine unmittelbaren Pläne, Post-Quantum-X.509-Zertifikate in seinen Root Store aufzunehmen, und wird sie nur in privaten PKIs unterstützen. Browser und CAs setzen auf etwas anderes, nämlich die meisten Signaturen loszuwerden.

Diese Struktur hat eine praktische Eigenschaft, denn um zu beweisen, dass ein Zertifikat im Baum enthalten ist, braucht es nur ein paar Hashes, den sogenannten Inclusion Proof, der selbst bei Millionen von Zertifikaten nur einige hundert Bytes gross bleibt.

Die CA signiert dann Teile dieses Baums, und unabhängige Cosigner, die eine Kopie des Baums führen, fügen ihre eigene Signatur hinzu, sodass die CA nicht verschiedenen Personen unterschiedliche Bäume zeigen kann. In regelmässigen Abständen, etwa stündlich, wird einer dieser signierten Teile als Landmark ausgewählt und den Browsern im Voraus zugestellt. Ein Zertifikat, das von einem Landmark abgedeckt ist, muss dann nur noch seinen kleinen Proof mitführen und gar keine Signatur. Und da der Baum öffentlich ist, bedeutet das Ausstellen eines Zertifikats bereits, es zu loggen, sodass Certificate Transparency gleich mitgeliefert wird.

Für Browser, die noch nicht die neuesten Landmarks haben, gibt es eine Rückfalllösung, das sogenannte Standalone-Zertifikat. Dabei trägt das Zertifikat die Signaturen selbst, von der CA und den Cosignern, zusammen mit seinem Inclusion Proof. Auch ein neues Zertifikat wird zunächst so verschickt, da es warten muss, bis der nächste Landmark die Browser erreicht. Deshalb empfiehlt der Draft, ein Zertifikat nach etwa 75% seiner Laufzeit zu erneuern, damit das neue bereits von einem Landmark abgedeckt ist, wenn das alte abläuft.

Jeder Browser entscheidet selbst, wie viele Cosignaturen er verlangt, sowohl für die Landmarks, die er im Voraus erhält, als auch in jedem Standalone-Zertifikat. Die Draft Policy von Chrome verlangt derzeit mindestens zwei, eine von der CA und eine von einem unabhängigen Mirror, beide in ML-DSA-44.

Um zu wissen, welches Zertifikat er senden soll, verlässt sich der Server auf den Browser, der in seiner ersten Nachricht mit der Extension Trust Anchor Identifiers auflistet, wem er vertraut. Diese Liste enthält sowohl die Landmarks, die er bereits hat, als auch die CAs, deren Standalone-Zertifikate er akzeptiert. Deckt einer der Landmarks das Zertifikat ab, sendet der Server die kleine Landmark-Version, andernfalls weicht er auf ein Standalone-Zertifikat einer CA aus, die der Browser unterstützt.

Wir haben uns also damit verbunden, um die Kosten von MTCs zu messen. Alle Verbindungen nutzten einen quantensicheren Schlüsselaustausch, und anders als bei unseren bisherigen Messungen handelt es sich um einen echten Server in China, was die längeren Handshake-Zeiten erklärt.

Das Landmark-Zertifikat ist das kleinste der drei und sogar kleiner als das heutige X.509-Zertifikat, genau wie Let’s Encrypt es angekündigt hat. Da es überhaupt keine Signatur trägt, schrumpft das Zertifikat auf etwa 470 Bytes, und der gesamte Handshake von 7,8 KB mit dem klassischen X.509-Zertifikat auf 4,8 KB. Beim Standalone-Zertifikat sieht es anders aus. Trustasia verwendet drei ML-DSA-44-Signaturen, eine von der CA und zwei von Cosignern, sodass allein das Zertifikat 7,3 KB wiegt und der Handshake 12,5 KB erreicht.

Diese Zahlen sind mit drei Vorbehalten zu lesen. Erstens ist der X.509-Handshake hier grösser als in unserem Labor, 7,8 KB statt 5,7 KB. Der ClientHello des Browsers ist etwa 480 Bytes grösser, da er einige zusätzliche Extensions enthält, darunter die Trust Anchor Identifiers, allein 186 Bytes, die aktuelle Chrome-Versionen standardmässig senden, auch ohne MTCs. Vor allem aber sendet der Server drei statt zwei Zertifikate, da die Root von Trustasia von einer älteren und breiter vertrauten RSA-Root gegensigniert ist. Zweitens stellt Trustasia so wenige MTC-Zertifikate aus, dass jedes allein in seinem Teil des Baums steht und sein Inclusion Proof daher leer ist. Für eine echte CA schätzt der Draft ihn auf 384 Bytes für ein Standalone- und 736 Bytes für ein Landmark-Zertifikat. Drittens tragen seine Standalone-Zertifikate drei Signaturen, wo die Draft Policy von Chrome nur zwei verlangt.

Bei der Zeit liegen die drei dagegen fast gleichauf, zwischen 610 und 623 ms, also etwa zwei Round Trips. Selbst mit dem Standalone-Zertifikat bleibt die Antwort des Servers bei rund 9,3 KB, unter den 14 KB des initialen Congestion Window, und braucht daher nie den zusätzlichen Round Trip, den wir in unserem Labor mit ML-DSA gesehen haben.

Die Zahlen sind allerdings noch nicht quantensicher, denn die Handshake-Signatur ist weiterhin ECDSA. In allen MTC-Zertifikaten, die wir in den Logs von Trustasia und Let’s Encrypt gefunden haben, ist der Schlüssel des Servers ein ECDSA-Schlüssel. Das ist zu erwarten, denn die Baseline Requirements des CA/Browser Forum erlauben heute nur RSA- und ECDSA-Schlüssel, und die Draft Policy von Chrome führt ML-DSA nur als Option auf.

Mit unseren Messungen lässt sich dennoch abschätzen, wie viel ein vollständig quantensicheres Deployment wiegen würde. Wir haben den ECDSA-Schlüssel des Servers durch ML-DSA-44 ersetzt, die Inclusion Proofs aus dem Draft hinzugefügt und nur die zwei Signaturen behalten, die Chrome für Standalone-Zertifikate verlangt. Ein Landmark-Handshake käme dann auf etwa 9,1 KB und ein Standalone-Handshake auf etwa 14,1 KB. In beiden Fällen würde die Antwort des Servers ins initiale Congestion Window passen.

Das Zitat von Let’s Encrypt gilt also nur so lange ganz, wie der Server-Schlüssel ECDSA bleibt. Sobald er auf ML-DSA wechselt, wird selbst ein Landmark-Handshake grösser als der heutige klassische.

Das Design selbst wirft zudem eine Datenschutzfrage auf. Da Landmarks nicht alle Browser gleichzeitig erreichen, unterscheidet sich die Liste, die ein Browser über die Extension Trust Anchor Identifiers ankündigt, von Benutzer zu Benutzer und liefert damit ein weiteres Merkmal für Browser-Fingerprinting.

Und schliesslich wurden MTCs für das Web PKI entworfen, wo die Browser die Landmarks an ihre Benutzer verteilen. In einer privaten PKI müssten Sie diese Verteilung selbst aufbauen, was zur Herausforderung werden könnte, besonders in der OT, wo Geräte selten aktualisiert werden oder gar nicht verbunden sind.

Bei privaten PKIs sieht es anders aus. Niemand migriert sie für Sie, aber dafür haben Sie auch mehr Freiheit. X.509 mit ML-DSA oder mit dem kürzlich standardisierten Composite ML-DSA ist oft die direkteste Option, besonders wenn Sie keine Certificate Transparency brauchen und daher auch keine SCTs mitführen müssen. MTCs bleiben interessant, aber die Umstellung ist aufwendiger, da Sie die Landmarks selbst an jeden Client verteilen müssen. Dafür ist das Logging fester Bestandteil der Zertifikatsausstellung, was nützlich sein könnte, um ein Inventar aufzubauen und die PQC-Transition für Compliance-Zwecke nachzuverfolgen. Am Ende hängt die richtige Wahl von Ihrer Infrastruktur ab: Brauchen Sie ein Log von allem, was Sie ausstellen? Können Sie Updates einfach an Ihre Clients verteilen? Und haben Ihre Clients Ihre Intermediate-CAs bereits gespeichert?

Post-Quantum-Zertifikate auszurollen ist allerdings nur die halbe Arbeit. Solange Clients noch klassische Zertifikate akzeptieren, können Angreifer einfach diese ins Visier nehmen, Sie müssen also bereit sein, sie abzuschalten. Und vor alldem müssen Sie wissen, wo Ihre Zertifikate und Schlüssel liegen und welche Systeme sie ausstellen und prüfen. Alles beginnt mit einem kryptografischen Inventar.