TLS auf Post-Quanten-Kryptografie vorbereiten: Was gehört ins Inventar?

Erfassen Sie zur Vorbereitung einer TLS-Migration auf Post-Quanten-Kryptografie, wo quantenanfällige Public-Key-Algorithmen eingesetzt werden. Halten Sie fest, wer diese Systeme betreut und welche Änderungen ihre Clients unterstützen. Der Austausch von Zertifikaten ist nur ein Teil der Arbeit.

Veröffentlichte Standards

NIST hat im August 2024 drei Standards für Post-Quanten-Kryptografie fertiggestellt: ML-KEM für den Schlüsselaustausch sowie ML-DSA und SLH-DSA für digitale Signaturen. Diese Algorithmen erfüllen unterschiedliche Aufgaben.

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-Migrationsplan sollte deshalb nicht jedes Verschlüsselungsverfahren oder jeden Hash als gleichermaßen kompromittiert darstellen.

Der koordinierte EU-Fahrplan sieht vor, dass Mitgliedstaaten und beteiligte Organisationen den Übergang zu PQC gemeinsam planen. Europäische Beschaffungsteams können ihn für ihre Migrationsplanung heranziehen.

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 die künftige Signierung von Zertifikaten und Software.

SLH-DSA FIPS 205 Digitale Signaturen Ein hashbasierter Signaturstandard, der Algorithmenvielfalt bieten soll.

Schlüsselaustausch und Zertifikatsauthentifizierung

Planen Sie Schlüsselaustausch und Zertifikatsauthentifizierung getrennt. Sie verwenden unterschiedliche Algorithmen und haben eigene Kompatibilitätsanforderungen.

Sitzungsschlüssel vereinbaren

ClientServer

Übertragene Daten schützen

ECDHE · ML-KEM

Server authentifizieren

ClientServer

Identität anhand von Zertifikaten und Signaturen prüfen

X.509 · CertificateVerify

Postquanten-Schlüsselaustausch macht die Zertifikatskette nicht postquantensicher. Beide Bereiche müssen gesondert migriert werden.

Protokolle und Unterstützung

Schlüsselvereinbarung

Dies ist der Teil des TLS-Handshakes, der Sitzungsgeheimnisse erzeugt. Die hybride ECDHE-MLKEM-Schlüsselvereinbarung ist in RFC 10024 veröffentlicht; eigenständige benannte ML-KEM-Gruppen bleiben ein Entwurf. Beide hängen von der Unterstützung durch Clients, Server, Bibliotheken und Richtlinien ab.

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.

Nach der erforderlichen Vertraulichkeitsdauer priorisieren

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 Marketingwebsite, eine interne Verwaltungsoberfläche, ein Gehaltsportal und ein Endpunkt für Kundendatenexporte haben unterschiedliche Vertraulichkeitsanforderungen. Richten Sie die Reihenfolge der Migration danach aus.

Bei der Migration von Zertifikatsignaturen geht es um ein anderes Risiko: die künftige Authentifizierung, Vertrauensketten, Vorgaben der Root-Programme, das Verhalten von Certificate Transparency und die 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 nicht standardisierter Kyber-Versionen, 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 verwendeten Clients 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 migriert keine Endpunkte auf Post-Quanten-Kryptografie. Die Compliance-Arbeitsbereiche von Business und Custom zeigen Zertifikatsalgorithmen, Ergebnisse der TLS-Regelprüfungen und Nachweise mit Zeitstempel aus öffentlichen und internen Beobachtungen.

Nutzen Sie diese Beobachtungen zur Migrationsplanung. Erfassen Sie für jedes System das zuständige Team, den Anbieter, die Algorithmen und die Kompatibilitätsanforderungen.

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.