Ressourcen Post-Quanten · Juli 2026

Die Post-Quanten-Bereitschaft für TLS besteht hauptsächlich aus Inventarisierungsarbeiten

Post-Quanten-Kryptografie ist nicht mehr nur ein Forschungsthema. Die TLS-Migration ist jedoch kein einmaliges Projekt zum Austausch von Zertifikaten. Für die meisten Infrastrukturteams besteht die sinnvolle Arbeit heute darin, den Einsatz quantenanfälliger Public-Key-Kryptografie, die Verantwortlichen und die Systeme zu erfassen, die sich ändern lassen, ohne Clients zu beeinträchtigen.

Was ist eigentlich standardisiert?

NIST hat im August 2024 die ersten drei Standards für Post-Quanten-Kryptografie finalisiert. Die Namen sind wichtig, weil sie unterschiedliche Aufgaben beschreiben. ML-KEM dient der Schlüsselvereinbarung. ML-DSA und SLH-DSA sind für digitale Signaturen vorgesehen. Sie sind nicht austauschbar.

Betroffen ist vor allem die asymmetrische Kryptografie: RSA, DSA, ECDSA, EdDSA, Finite-Field-DH und ECDH. Symmetrische Verschlüsselung und Hashfunktionen sind nicht in gleicher Weise betroffen. Ein TLS-Bereitschaftsplan sollte deshalb nicht jedes Verschlüsselungsverfahren oder jeden Hash als gleichermaßen kompromittiert darstellen.

Für europäische Käufer ist dies zunehmend auch ein Governance- und Planungsthema. Der von der EU koordinierte Fahrplan stellt PQC als einen Übergang dar, der über Mitgliedstaaten und Interessengruppen hinweg geplant werden sollte, und nicht als isolierten Produktwechsel.

Algorithmus Standard Rolle Betriebshinweis
ML-KEM FIPS 203 Schlüsselvereinbarung Die Algorithmenfamilie, die für Arbeiten am TLS-Schlüsselaustausch am unmittelbarsten relevant ist.
ML-DSA FIPS 204 Digitale Signaturen Relevant für zukünftige Zertifikats- und Softwaresignaturpfade.
SLH-DSA FIPS 205 Digitale Signaturen Ein hashbasierter Signaturstandard, der Algorithmenvielfalt bieten soll.

Bei TLS gibt es zwei getrennte Migrationsbereiche

TLS-Teams sollten die Schlüsselvereinbarung von der Zertifikatauthentifizierung trennen. Wer beides vermischt, erhält schnell einen Bereitschaftsplan, der überzeugend klingt, sich aber nicht umsetzen lässt.

Schlüsselvereinbarung

Dies ist der Teil des TLS-Handshakes, der Sitzungsgeheimnisse erstellt. Der hybride ECDHE-MLKEM-Pfad ist in der IETF weiter fortgeschritten als eigenständige benannte ML-KEM-Gruppen, aber beide sind immer noch auf Client-, Server-, Bibliotheks- und Richtlinienunterstützung angewiesen.

Zertifikatauthentifizierung

Dies ist die X.509-Zertifikatskette, die zur Authentifizierung des Servers verwendet wird. RFCs gibt es für ML-DSA-, SLH-DSA- und ML-KEM-Bezeichner in X.509, aber das ist nicht dasselbe wie Unterstützung im Produktivbetrieb für öffentlich vertrauenswürdige TLS-Serverzertifikate.

Das tatsächliche Risiko ist nicht bei jedem System gleich

Ein wichtiger kurzfristiger Grund, den Umstieg auf PQC zu planen, ist das Szenario „jetzt sammeln, später entschlüsseln“: Ein Angreifer kann verschlüsselten Datenverkehr heute aufzeichnen und später zu entschlüsseln versuchen, falls ein kryptografisch relevanter Quantencomputer verfügbar wird. Das Risiko ist besonders relevant, wenn Daten jahrelang vertraulich bleiben müssen.

Eine Marketing-Website, eine interne Administrationsoberfläche, ein Gehaltsabrechnungsportal und ein Endpunkt für den Export von Kundendaten haben nicht dieselbe Vertraulichkeitsdauer. Alle TLS-Endpunkte als gleich dringend zu behandeln, ist kein Risikomodell; es ist eine Warteschlange, die sich nicht priorisieren lässt.

Die Migration von Zertifikatsignaturen stellt ein anderes Risiko dar. Es geht um zukünftige Authentifizierung, Vertrauensketten, Richtlinien der Root-Programme, das Verhalten von Certificate Transparency und Client-Kompatibilität. Bereits aufgezeichneter Datenverkehr wird dadurch nicht entschlüsselt.

Was Fachteams jetzt tun können

  • Inventarisieren Sie, wo RSA, ECDSA, EdDSA, Finite-Field-DH und ECDH in Zertifikaten, TLS-Endpunkten, Appliances, Loadbalancern, VPNs und verwalteten Diensten vorkommen.
  • Zeichnen Sie auf, welche Systeme TLS terminieren, welche Zertifikate sie vorlegen, welche Teams dafür verantwortlich sind und welche Anbieter den Kryptografie-Stack kontrollieren.
  • Klassifizieren Sie Daten nach ihrer Vertraulichkeitsdauer. Langfristig vertrauliche Daten verändern die Priorität; bei kurzen öffentlichen Websitzungen ist das normalerweise nicht der Fall.
  • Fragen Sie Anbieter nach konkreten Terminen und Bezeichnungen für die Unterstützung: ML-KEM anstelle von Kyber vor der Standardisierung, ML-DSA, SLH-DSA, hybrides TLS, CAVP-Algorithmusvalidierung, FIPS-140-3-Modulvalidierung, sofern erforderlich, und Downgrade- oder Fallback-Verhalten.
  • Testen Sie hybrides TLS nur dort, wo die Clientpopulation bekannt und ein Rollback einfach ist. Messen Sie Latenz, Handshake-Größe, Middlebox-Verhalten und Beobachtbarkeit.
  • Vermeiden Sie es, die Neuausstellung von Zertifikaten als Migrationsplan zu betrachten. Die öffentliche Zertifikatsrichtlinie und die Clientkompatibilität sind weiterhin wichtig.

Was Sie nicht tun sollten

  • Ein Produkt kaufen, nur weil es als „quantensicher“ bezeichnet wird.
  • Alle öffentlichen Zertifikate ersetzen, bevor Browser, Zertifizierungsstellen und Clients die betreffenden Algorithmen unterstützen.
  • Annehmen, dass ein PQC-Schlüsselaustausch zugleich PQC-Zertifikatsignaturen liefert.
  • PQC und Quantenschlüsselverteilung so behandeln, als wären sie dasselbe Migrationsprojekt.
  • Zuständigkeiten, Erneuerung und TLS-Hygiene bestehender Zertifikate vernachlässigen, weil PQC strategischer klingt.

Wo Nocert ansetzt

Nocert stellt keine Zertifikate aus und macht einen Endpunkt nicht von selbst post-quantenfähig. Die Compliance-Workspaces von Business und Custom haben eine engere Aufgabe: Sie halten die Sicherheitslage von Zertifikaten und TLS über öffentliche und interne Beobachtungen hinweg sichtbar, einschließlich Zertifikatsalgorithmen, Feststellungen zu TLS-Richtlinien und mit Zeitstempel versehenen Nachweisen.

So lässt sich die Post-Quanten-Bereitschaft im normalen TLS-Betrieb statt in einer separaten Tabelle verfolgen. Das Ergebnis sollte eine Liste von Systemen, Verantwortlichen, Anbietern, Algorithmen und Migrationsbeschränkungen sein, nicht ein pauschales „quantensicher“-Label.

Primärquellen

Dieser Hinweis basiert auf den PQC-Standards und Migrationsleitfäden des NIST, der Arbeit der IETF zu TLS und X.509, den Baseline Requirements des CA/Browser Forum und dem von der EU koordinierten PQC-Fahrplan.