Fast jedes Zertifikat im Internet beruht heute auf RSA oder elliptischen Kurven. Ein ausreichend großer Quantencomputer könnte beide Verfahren brechen und damit Signaturen fälschen. Deshalb hat die US-Normungsbehörde NIST 2024 neue, quantensichere Signaturverfahren standardisiert, allen voran ML-DSA. Doch ihre Schlüssel und Signaturen sind viel größer, und das macht die Umstellung der Zertifikate schwierig. Dieser Artikel erklärt die neuen Verfahren, rechnet das Größenproblem vor, stellt hybride Zertifikate und Merkle Tree Certificates vor und nennt die Zeitpläne.

Warum Quantencomputer Zertifikate bedrohen

Die Sicherheit von RSA beruht darauf, dass sich große Zahlen nicht effizient in Primfaktoren zerlegen lassen, die von ECDSA auf dem diskreten Logarithmus auf elliptischen Kurven. Der Shor-Algorithmus löst beide Probleme auf einem genügend großen, fehlerkorrigierten Quantencomputer effizient. Einen solchen Rechner gibt es noch nicht; zum Stand siehe Quantencomputer einfach erklärt.

Bei Zertifikaten ist die Gefahr anders gelagert als bei der Verschlüsselung:

• Verschlüsselung ist schon heute bedroht, weil Angreifer Daten jetzt mitschneiden und später entschlüsseln können („harvest now, decrypt later“).
• Signaturen lassen sich erst fälschen, wenn der Quantencomputer existiert. Wer dann den Schlüssel einer CA berechnet, kann aber beliebige Zertifikate ausstellen. Weil die Umstellung von Root Stores und Geräten Jahre dauert, muss sie trotzdem jetzt beginnen.

Einen Überblick gibt Post-Quanten-Kryptografie.

Die neuen Verfahren: ML-DSA, SLH-DSA und FN-DSA

Im August 2024 veröffentlichte das NIST drei Standards:

• FIPS 203, ML-KEM: Schlüsselvereinbarung, also für die Verschlüsselung.
• FIPS 204, ML-DSA: Signaturen auf Basis von Gittern (früher CRYSTALS-Dilithium). Das wichtigste Verfahren für künftige Zertifikate.
• FIPS 205, SLH-DSA: Signaturen, die nur auf Hashfunktionen beruhen (früher SPHINCS+). Sehr konservativ, aber mit großen Signaturen.

Ein viertes Verfahren, FN-DSA (Falcon) mit kleineren Signaturen, bereitet das NIST als FIPS 206 vor. Die Größen im Vergleich (öffentlicher Schlüssel / Signatur):

• ECDSA P-256: 64 / etwa 64 bis 72 Byte
• RSA-2048: 256 / 256 Byte
• ML-DSA-44: 1.312 / 2.420 Byte
• ML-DSA-65: 1.952 / 3.309 Byte
• ML-DSA-87: 2.592 / 4.627 Byte
• SLH-DSA-128s: 32 / 7.856 Byte

Zu Schlüsseltypen siehe Schlüsselpaar und CSR erstellen.

Das Größenproblem: Rechenbeispiel

Bei jedem HTTPS-Verbindungsaufbau überträgt der Server mehrere Signaturen und Schlüssel: die Handshake-Signatur, die Signaturen im Endzertifikat und im Zwischenzertifikat, zwei SCTs aus den Certificate-Transparency-Protokollen sowie zwei öffentliche Schlüssel. Eine grobe Schätzung, wenn alles auf ML-DSA-44 umgestellt würde:

• 5 Signaturen · 2.420 Byte = 12.100 Byte
• 2 Schlüssel · 1.312 Byte = 2.624 Byte
• zusammen 14.724 Byte, also rund 14,4 KiB

Mit ECDSA P-256 sind es heute etwa 5 · 72 + 2 · 65 = 490 Byte, also rund 30-mal weniger. Das ist mehr als Kosmetik: Ein Server darf zu Beginn einer Verbindung nur etwa 10 Pakete mit je 1.460 Byte Nutzdaten senden, rund 14.600 Byte, bevor er auf eine Bestätigung warten muss. Liegt der Handshake darüber, kostet jede neue Verbindung eine zusätzliche Rundreise durchs Netz. Zu Datenmengen siehe Bit und Byte, zu TCP TCP und UDP.

Drei Wege zu quantensicheren Zertifikaten

• Reine Post-Quanten-Zertifikate: Ein normales X.509-Zertifikat mit ML-DSA-Schlüssel und ML-DSA-Signatur. Für private PKIs, Geräte und Firmennetze ist das der naheliegende Weg; Google hat angekündigt, solche Zertifikate in privaten PKIs zu unterstützen. Wie eine eigene CA funktioniert, erklärt Eigene CA betreiben.
• Hybride (composite) Zertifikate: Ein Zertifikat enthält zwei Schlüssel und zwei Signaturen, etwa ML-DSA und ECDSA. Es bleibt sicher, solange eines der beiden Verfahren hält, falls bei den neuen Verfahren doch noch Schwächen entdeckt werden. Die IETF arbeitet an dem Standard, er wird aber noch größer.
• Merkle Tree Certificates: Google und Cloudflare erproben derzeit ein neues Format. Statt jedes Zertifikat einzeln zu signieren, signiert die CA einen Baum mit Millionen Zertifikaten auf einmal, und der Browser bekommt nur einen kurzen Nachweis, dass das Zertifikat im Baum steht, ähnlich wie bei Certificate Transparency. Chrome plant, solche Zertifikate ab 2027 in einem eigenen, quantensicheren Root Store zu akzeptieren, und will klassische X.509-Zertifikate mit Post-Quanten-Signaturen vorerst nicht in den öffentlichen Chrome Root Store aufnehmen.

Was heute schon quantensicher ist

Bei der Verschlüsselung ist die Umstellung schon weit: Die großen Browser und viele Server handeln TLS-Verbindungen inzwischen hybrid mit X25519 und ML-KEM aus (Verfahren X25519MLKEM768). Daten, die heute mitgeschnitten werden, sind damit auch gegen künftige Quantencomputer geschützt. Die Signaturen in Zertifikaten sind dagegen noch klassisch; das genügt, solange es keinen passenden Quantencomputer gibt. Wie der Handshake abläuft, steht in wie funktioniert HTTPS.

Zeitpläne für die Umstellung

• NIST (USA): Der im Oktober 2026 veröffentlichte Bericht IR 8547 erklärt RSA, ECDSA und die klassischen Schlüsselvereinbarungen nach 2030 für veraltet und nach 2035 für nicht mehr zulässig.
• EU: Ein 2025 abgestimmter Fahrplan der Mitgliedstaaten sieht vor, bis Ende 2026 mit der Umstellung zu beginnen, besonders kritische Anwendungen bis Ende 2030 umzustellen und möglichst alle Systeme bis 2035.
• Chrome: Merkle Tree Certificates sollen ab dem ersten Quartal 2027 mit Betreibern von CT-Protokollen erprobt werden, der eigene Root Store dafür ist für das dritte Quartal 2027 geplant.

Für Firmen heißt das: jetzt ein Inventar aller Zertifikate und Schlüssel anlegen, auf kurze Laufzeiten und Automatisierung setzen und Systeme so bauen, dass sich Algorithmen austauschen lassen (Krypto-Agilität). Mit 47 Tagen Laufzeit ab 2029 ist ein Wechsel auf neue Verfahren in wenigen Wochen erledigt; siehe Zertifikatslaufzeit einfach erklärt.

Ausprobieren mit OpenSSL

Ab Version 3.5 unterstützt OpenSSL ML-DSA, ML-KEM und SLH-DSA direkt. Ein Testschlüssel und ein selbstsigniertes Testzertifikat entstehen so:

openssl genpkey -algorithm ML-DSA-65 -out pq.key
openssl req -new -x509 -key pq.key -subj "/CN=pq-test" -days 30 -out pq.pem
openssl x509 -in pq.pem -noout -text

Die Ausgabe zeigt einen öffentlichen Schlüssel von 1.952 Byte. Ältere OpenSSL-Versionen, etwa 3.0 aus Ubuntu 24.04, kennen diese Verfahren noch nicht.

Häufige Fragen

Muss ich jetzt etwas an meiner Website ändern? Nein. Öffentliche CAs stellen noch keine quantensicheren Website-Zertifikate aus. Wichtig ist, Zertifikate automatisch zu erneuern, damit der spätere Wechsel ohne Handarbeit klappt.

Ist meine HTTPS-Verbindung heute schon quantensicher? Die Verschlüsselung in aktuellen Browsern meist ja, dank hybrider Schlüsselvereinbarung mit ML-KEM. Die Echtheitsprüfung per Zertifikat noch nicht, was aber erst mit einem echten Quantencomputer zum Problem wird.

Warum nimmt man nicht einfach längere RSA-Schlüssel? Der Shor-Algorithmus bricht auch sehr lange RSA-Schlüssel mit vertretbarem Mehraufwand. Längere Schlüssel verschieben das Problem nur.

Sind die neuen Verfahren sicher? Sie wurden über acht Jahre öffentlich geprüft. Weil sie jünger sind als RSA, setzen viele für den Übergang auf hybride Lösungen, die beide Verfahren kombinieren.

Fazit

Quantencomputer würden RSA und ECDSA brechen und damit Zertifikatssignaturen fälschbar machen. Die Nachfolger ML-DSA und SLH-DSA sind seit 2024 standardisiert, aber ihre großen Signaturen machen Zertifikatsketten rund 30-mal größer. Deshalb entstehen neben reinen Post-Quanten-Zertifikaten hybride Zertifikate und Merkle Tree Certificates. Bis 2035 soll die Umstellung abgeschlossen sein. Mehr in der Übersicht Verschlüsselung und IT-Sicherheit.

Quellen und weiterführende Links

• FIPS 204: Module-Lattice-Based Digital Signature Standard (NIST)
• NIST IR 8547: Transition to Post-Quantum Cryptography Standards (NIST)
• Cultivating a robust and efficient quantum-safe HTTPS (Google)
• Coordinated Implementation Roadmap for the transition to PQC (EU-Kommission)