Post-Quanten-Kryptographie ist nicht länger theoretisch: Ihre Migrations-Roadmap

Im August 2024 veröffentlichte NIST die ersten finalen Post-Quanten-Kryptographie-Standards seiner Geschichte: FIPS 203 (ML-KEM, basierend auf CRYSTALS-Kyber), FIPS 204 (ML-DSA, basierend auf CRYSTALS-Dilithium) und FIPS 205 (SLH-DSA, basierend auf SPHINCS+). Diese Standards schließen einen mehrjährigen Standardisierungsprozess ab, der einen globalen Kryptographie-Wettbewerb, öffentliche Überprüfungen und mehrere Runden der Kryptoanalyse umfasste. Post-Quanten-Kryptographie ist kein Forschungsproblem mehr – sie ist ein Engineering- und Migrationsproblem.

Warum die Dringlichkeit jetzt real ist – nicht in 10 Jahren

Die gängige Darstellung der Post-Quanten-Kryptographie suggeriert, dass die Migration warten kann, bis Quantencomputer leistungsfähig genug sind, um RSA und Elliptische-Kurven-Kryptographie zu brechen – eine Fähigkeit, die die meisten Schätzungen 10 bis 20 Jahre entfernt sehen. Diese Darstellung ist gefährlich falsch, und der Grund ist ein Bedrohungsmodell namens „Harvest Now, Decrypt Later“ (HNDL).

Staatliche Gegner und ausgefeilte Bedrohungsakteure sammeln bereits heute verschlüsselten Netzwerkverkehr. TLS-Sitzungen, VPN-Tunnel, verschlüsselte E-Mails und sensible API-Aufrufe werden aufgezeichnet und gespeichert. Die verschlüsselten Daten sind heute unverständlich, aber wenn um 2035 oder 2040 ein ausreichend leistungsfähiger Quantencomputer verfügbar wird, kann dieser gespeicherte Verkehr rückwirkend entschlüsselt werden.

Das bedeutet, dass Daten, die heute mit RSA-2048 oder ECDH P-256 verschlüsselt werden – falls sie in 15 Jahren noch geheim sein müssen – aus Sicht der langfristigen Vertraulichkeit bereits effektiv kompromittiert sind. Regierungskommunikation, Daten der nationalen Sicherheit, Finanztransaktionshistorien, Gesundheitsakten und langfristige vertragliche Vereinbarungen fallen alle in diese Kategorie. Für Organisationen mit langen Datenklassifikationsanforderungen hat die Migrationsuhr bereits vor Jahren zu ticken begonnen.

Was die NIST-Standards tatsächlich vorgeben

Die drei finalisierten Standards decken unterschiedliche kryptographische Funktionen ab:

FIPS 203 / ML-KEM (ehemals CRYSTALS-Kyber) ist ein Key-Encapsulation-Mechanismus – der quantenresistente Ersatz für RSA- und Diffie-Hellman-Schlüsselaustausch in Protokollen wie TLS. Er basiert auf der Härte des Module-Learning-With-Errors-Problems, einer gitterbasierten mathematischen Struktur, die als resistent gegen klassische und Quantenangriffe gilt. ML-KEM gibt es in drei Parametersätzen: ML-KEM-512 (vergleichbare Sicherheit wie AES-128), ML-KEM-768 (vergleichbar mit AES-192) und ML-KEM-1024 (vergleichbar mit AES-256).

FIPS 204 / ML-DSA (ehemals CRYSTALS-Dilithium) ist ein digitales Signaturschema – der Ersatz für ECDSA- und RSA-Signaturen, die in Code-Signing, Zertifizierungsstellen, E-Mail-Signierung und Authentifizierungstoken verwendet werden. Ebenfalls gitterbasiert bietet es starke Sicherheit mit relativ kompakten Schlüssel- und Signaturgrößen.

FIPS 205 / SLH-DSA (ehemals SPHINCS+) ist ein hashbasiertes Signaturschema. Hashbasierte Signaturen haben eine längere Tradition kryptoanalytischer Prüfung als gitterbasierte Verfahren, was SLH-DSA zu einer konservativen Backup-Option für Organisationen macht, die Diversität in ihren kryptographischen Grundlagen wünschen. Der Nachteil sind größere Signaturgrößen.

NIST standardisiert außerdem FALCON (jetzt FN-DSA) als viertes Signaturschema, optimiert für eingeschränkte Umgebungen. Es bietet kleinere Signaturen als ML-DSA, hat aber komplexere Implementierungsanforderungen.

Die Migrationskomplexität, die die meisten Organisationen unterschätzen

Kryptographische Migration klingt nach einem Bibliothekstausch – alte Algorithmen durch neue ersetzen –, ist aber in der Praxis eher ein mehrjähriges Infrastruktur-Audit. Kryptographie ist in jeder Ebene des Stacks einer Organisation eingebettet: TLS-Zertifikatsketten, SSH-Hostschlüssel, Code-Signing-Pipelines, Hardware Security Modules (HSMs), Firmware-Signing, S/MIME-E-Mail-Verschlüsselung, VPN-Protokolle, JWT-Signierschlüssel, Datenbankverschlüsselung, Backup-Verschlüsselung und mehr.

Viele dieser Systeme bieten keine einfachen Konfigurationsknöpfe zum Wechseln von Algorithmus-Familien. HSMs benötigen Firmware-Updates oder Hardware-Austausch, um neue Algorithmen zu unterstützen. Zertifizierungsstellen und PKI-Infrastruktur müssen neu aufgebaut oder aktualisiert werden. Lieferanten und Partner vorgelagert und nachgelagert müssen dieselben Algorithmen unterstützen, damit gegenseitige Authentifizierung funktioniert. Industrielle Steuerungssysteme, eingebettete Geräte und IoT-Hardware mit einer Betriebsdauer von 10–15 Jahren werden möglicherweise nie quantenresistente Firmware erhalten.

Das Krypto-Agilitätsprinzip – Systeme so zu entwerfen, dass kryptographische Primitive ohne Architekturänderungen ausgetauscht werden können – ist die richtige Antwort für neue Systeme, aber die meisten Organisationen arbeiten mit Systemen, die ohne dieses Prinzip gebaut wurden. Nachträgliche Krypto-Agilität erfordert dieselbe Erkennungs- und Inventarisierungsarbeit wie die Migration selbst.

Hybride Schemata: Die praktische Brücke

IETF und wichtige TLS-Implementierungen haben sich auf hybriden Schlüsselaustausch als Migrationsstrategie für TLS geeinigt: Kombination eines klassischen Algorithmus (ECDH) mit einem Post-Quanten-Algorithmus (ML-KEM) in einem einzigen Handshake, sodass die Sitzung geschützt ist, solange einer der Algorithmen sicher ist. Dieser Ansatz schützt sowohl vor unentdeckten Schwächen in den neuen Post-Quanten-Algorithmen als auch vor Harvest-Now-Decrypt-Later-Angriffen mit Quantencomputern.

Google testet hybriden Schlüsselaustausch in Chrome seit 2023 mit einer Kombination aus X25519 und ML-KEM-768, bezeichnet als X25519MLKEM768. Cloudflare hat es in seinem Edge-Netzwerk bereitgestellt. Die neuesten Versionen von BoringSSL, OpenSSL 3.x (über den OQS-Provider) und LibreSSL unterstützen hybride Schemata. Für TLS ist der Migrationspfad einigermaßen klar, und die Tooling-Landschaft reift schnell.

Bei Signaturschemata ist die Migration langsamer, da Zertifikate von vertrauenswürdigen CAs neu ausgestellt werden müssen. Das Certificate Authority / Browser Forum (CA/B Forum) arbeitet an Standards für Post-Quanten-Zertifikate, aber die Massenauslieferung von PQ-signierten Zertifikaten ist wahrscheinlich noch 3–5 Jahre von breiter Browser- und OS-Trust-Store-Unterstützung entfernt.

Ihr Migrations-Priorisierungs-Framework

Nicht alles muss gleichzeitig migrieren. Ein risikobasierter Ansatz priorisiert nach zwei Dimensionen: wie sensibel die Daten sind und wie lange sie vertraulich bleiben müssen.

Beginnen Sie mit dem Schlüsselaustausch in extern ausgerichteten TLS: Dies ist die höchste HNDL-Exposition, das Tooling ist heute verfügbar, und hybride Schemata bedeuten, dass Sie klassische Algorithmen nicht aufgeben müssen. Ein Upgrade auf eine TLS-Bibliothek mit ML-KEM-Unterstützung und die Aktivierung von hybridem Schlüsselaustausch in Ihren Load Balancern und API-Gateways ist kurzfristig umsetzbar.

Als nächstes inventarisieren Sie Ihre PKI- und Zertifikatsinfrastruktur. Identifizieren Sie alle Zertifizierungsstellen – intern und extern – und deren Algorithmus-Konfigurationen. Planen Sie die operative Komplexität des Betriebs paralleler PKI (klassisch und Post-Quanten) während der Übergangsphase, da nicht alle Clients sofort PQ-Zertifikate unterstützen werden.

Bewerten Sie Ihre HSM-Flotte. Die meisten vor 2022 hergestellten HSMs unterstützen ML-KEM oder ML-DSA nicht nativ. HSM-Anbieter wie Thales, Entrust und Utimaco haben PQC-Roadmaps veröffentlicht, aber Hardware-Austauschzyklen sind lang und Budgetgenehmigungen dauern. Beginnen Sie jetzt mit diesen Beschaffungsgesprächen.

Langlebige Geheimnisse sind das Migrationsziel mit höchster Priorität. Verschlüsselungsschlüssel, die archivierte Daten schützen, Root-CA-Private-Keys, langfristige VPN-Anmeldeinformationen und Code-Signing-Keys, die Software über mehrere Jahre authentifizieren, benötigen dringend quantenresistenten Schutz. RSA-verschlüsselte Backups aus dem Jahr 2024 werden 2040 noch von einem Quantengegner wiederherstellbar sein.

Was Sie dieses Quartal umsetzen sollten

Aktivieren Sie hybriden Schlüsselaustausch in TLS für externe Endpunkte – sowohl serverseitig (nginx, HAProxy, Cloudflare, AWS ALB) als auch clientseitig, wo Sie den TLS-Stack kontrollieren. Testen Sie die Kompatibilität mit Ihrer bestehenden Client-Basis, bevor Sie breit ausrollen. Führen Sie ein Inventar aller kryptographischen Assets mit Tools wie Venafi oder HashiCorp Vaults PKI Secrets Engine durch. Binden Sie Ihren HSM-Anbieter zu dessen PQC-Zeitplan ein. Bewerten Sie, ob Daten, die Sie heute verschlüsseln, eine Vertraulichkeitsanforderung über 2035 hinaus haben. Informieren Sie Ihren CISO oder die Sicherheitsführung mit einer schriftlichen Risikobewertung, die die HNDL-Exposition quantifiziert – die meisten Sicherheitsbudgets reagieren schneller auf konkrete Risikodarstellungen als auf abstrakte Zeitachsenargumente.

Post-Quanten-Kryptographie ist kein Problem, das sich durch Warten von selbst löst. Die Standards sind final, das Tooling existiert für die höchstprioren Anwendungsfälle, und die Harvest-Now-Decrypt-Later-Bedrohung ist real und aktuell. Organisationen, die jetzt mit ihrem Migrationsinventar beginnen, werden Jahre Vorlauf für eine methodische Umsetzung haben. Diejenigen, die warten, bis Quantencomputer sichtbar Produktionssysteme bedrohen, werden unter Notfallbedingungen arbeiten.