Entwicklung der CNSA 2.0-Übergangsstrategien

Die Commercial National Security Algorithm Suite 2.0 ( CNSA 2.0 ) der National Security Agency ist der bisher detaillierteste Leitfaden einer US-Regierung für diesen Übergang. Während das National Security Memorandum 10 (NSM-10) das ambitionierte Ziel formuliert, nationale Sicherheitssysteme bis 2035 quantenresistent zu machen, setzt CNSA 2.0 dieses Ziel in konkrete Anweisungen um: Verwenden Sie ML-KEM-1024 für die Schlüsselerzeugung, ML-DSA-87 für Signaturen, unterstützen Sie diese Algorithmen bis zu bestimmten Stichtagen in Ihren Produkten und stellen Sie die Verwendung der alten Algorithmen anderer Anbieter ein.

Die Fristen rücken näher. Die erste Frist, die die Signierung von Software und Firmware betraf, forderte Organisationen auf, bis 2025 CNSA-2.0-Algorithmen zu bevorzugen – ein Meilenstein, der bereits verstrichen ist. Ab dem 1. Januar 2027 müssen alle Neubeschaffungen für nationale Sicherheitssysteme CNSA-2.0-Algorithmen unterstützen.

Dieser Blog erläutert die CNSA 2.0-Algorithmen, den vollständigen Zeitplan für den Übergang, die Durchsetzungsmechanismen, die diese Fristen verbindlich machen, und eine praktische Fünf-Phasen-Strategie für die Gestaltung der Migration, ohne Ihren Betrieb zu beeinträchtigen.

Post-Quanten-Codesignierung, definiert als: Signierung von Software und Firmware mit einem Algorithmus, der gegen Angriffe durch einen Quantencomputer resistent ist, derzeit ML-DSA (FIPS 204) oder der zustandsbehaftete Hash-basierte LMS/XMSS (NIST SP 800-208), typischerweise parallel zu einem klassischen Algorithmus während des Übergangs, sodass sowohl aktuelle als auch noch nicht aktualisierte Verifizierer das Artefakt weiterhin validieren können.

Wichtige Erkenntnisse

ML-KEM (FIPS 203) und ML-DSA (FIPS 204) sind nicht austauschbar: ML-KEM ist ein Schlüsselkapselungsmechanismus zur Erstellung gemeinsamer Geheimnisse, ML-DSA ist ein Signaturalgorithmus. Für die Codesignierung wird ML-DSA oder LMS/XMSS verwendet, niemals ML-KEM.
FIPS 203, 204 und 205 sind seit August 2024 endgültige NIST-Standards; NIST SP 800-208 (LMS/XMSS) ist seit 2020 endgültig. Was noch uneinheitlich ist, ist die Unterstützung durch das Ökosystem, die HSM-Firmware, die Zertifizierungsstellen und die Signaturprüfer.
Ein einzelnes, kombiniertes „zusammengesetztes“ Post-Quanten-/klassisches Signaturformat für X.509 ist noch ein IETF Internet-Draft (draft-ietf-lamps-pq-composite-sigs, noch kein RFC, Stand 2026); das heutige praktische Hybridmuster für die Codesignierung sind zwei parallele, getrennte Signaturen, keine zusammengesetzte Signatur.
Die Kompatibilität mit dem Verifizierer, nicht die Fähigkeit des Signierers, ist in der Regel der eigentliche Flaschenhals: Ein Artefakt kann heute mit ML-DSA signiert werden, aber nur von Plattformen verifiziert werden, die die Unterstützung dafür hinzugefügt haben.
Die Signierung von Software und Firmware ist die früheste Frist von CNSA 2.0 (empfohlen und bevorzugt: 2025, bereits verstrichen); siehe die datierte Übergangszeitleiste unten für alle anderen Systemkategorien.

Was CNSA 2.0 ist und warum es existiert

CNSA 2.0 ist die Richtlinie der NSA für kryptografische Algorithmen zum Schutz nationaler Sicherheitssysteme (NSS). Dazu gehören klassifizierte und nicht klassifizierte Systeme, die Informationen zur nationalen Sicherheit, militärische Führung und Kontrolle, Nachrichtendienste und verwandte Funktionen verarbeiten. Die Richtlinie wurde erstmals am 7. September 2022 veröffentlicht und im Dezember 2024 auf Version 2.1 aktualisiert, nachdem das NIST im August 2024 die endgültigen Post-Quantum -FIPS-Standards veröffentlicht hatte.

Der Grund für die Existenz von CNSA 2.0 liegt in einer einzigen, gut verstandenen Bedrohung. Die heute in nahezu allen Systemen verwendeten Public-Key-Algorithmen, RSA und Elliptische-Kurven-Kryptographie ( ECC ), basieren auf mathematischen Problemen, die klassische Computer in praktischer Zeit nicht lösen können. Ein ausreichend leistungsstarker Quantencomputer, der Shors Algorithmus ausführt, kann diese Probleme effizient lösen und somit RSA- und ECC-Signaturen und Schlüsselaustausche unsicher machen.

Dies birgt zwei unterschiedliche Risiken. Das erste ist zukunftsorientiert: Sobald ein kryptografisch relevanter Quantencomputer ( CRQC ) existiert, ist jedes System, das noch auf RSA oder ECC basiert, sofort angreifbar. Das zweite Risiko besteht bereits jetzt: Angreifer erfassen und archivieren verschlüsselte Daten und signierte Kommunikationen, um sie zu entschlüsseln oder zu fälschen, sobald ein CRQC verfügbar ist. Dies ist die sogenannte „Erfassen und später entschlüsseln“-Bedrohung. Sie bedeutet, dass Daten, deren Vertraulichkeitsanforderungen über den Zeitpunkt der CRQC-Einführung hinausgehen, bereits gefährdet sind – unabhängig davon, wie stark die heutige Verschlüsselung auch erscheinen mag.

CNSA 2.0 ersetzt die frühere CNSA 1.0- Suite, die auf RSA, ECDH, ECDSA und AES basierte. CNSA 2.0 behält die symmetrischen und Hash-Primitive bei, die weiterhin quantenresistent sind, und ersetzt die quantenanfälligen Public-Key-Algorithmen durch NIST-standardisierte Post-Quanten-Alternativen.

CNSA 2.0 Algorithmen-Suite

CNSA 2.0 legt exakte Algorithmen und, ganz entscheidend, exakte Parametersätze für jeden Anwendungsfall fest. Ein wesentliches Merkmal der Suite ist, dass sie ausschließlich die höchsten NIST- Sicherheitsstufen vorschreibt. Niedrigere Parametersätze sind, obwohl sie vom NIST standardisiert und für den allgemeinen Gebrauch freigegeben wurden, für nationale Sicherheitssysteme nicht zulässig.

Funktion	CNSA 2.0-Algorithmus	Standard	Notizen
Schlüsseleinrichtung	ML-KEM-1024	FIPS203	Früher CRYSTALS-Kyber; nur NIST-Sicherheitsstufe 5. ML-KEM-512 und ML-KEM-768 sind nicht für NSS zugelassen.
Digitale Signaturen (allgemein)	ML-DSA-87	FIPS204	Früher CRYSTALS-Dilithium; nur höchster Parametersatz. ML-DSA-44 und ML-DSA-65 sind für NSS nicht zulässig. Wird für alle Signierungen, einschließlich Software und Firmware, verwendet.
Software- und Firmware-Signierung	LMS oder XMSS	NIST-SP 800-208	Stateful hash-basierte Signaturen. Die NSA empfiehlt LMS mit SHA-256/192. ML-DSA-87 ist für diesen Anwendungsfall ebenfalls zugelassen.
Symmetrische Verschlüsselung	AES-256	FIPS197	Übernommen aus CNSA 1.0; quantenresistent bei 256-Bit-Schlüssellänge
Hashing	SHA-384 oder SHA-512	FIPS 180-4	CNSA 2.0 hat SHA-512 als zugelassene Option neben SHA-384 hinzugefügt.

Status der Standards: Was ist endgültig, was befindet sich noch in der Entwicklung?

Nicht alles, was als „post-quanten“ bezeichnet wird, befindet sich auf demselben Reifegrad, und die Vermischung eines finalisierten Algorithmenstandards mit einer noch in der Entwicklung befindlichen Ökosystemfunktion ist einer der häufigsten Planungsfehler. Es ist hilfreich, den Algorithmenstandard selbst von der umgebenden Infrastruktur zu trennen, die erst noch angepasst werden muss.

Artikel	Status	Seit / Notizen
FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)	Endgültige NIST-Standards	Veröffentlicht August 13, 2024
NIST SP 800-208 (LMS, XMSS)	Abschließende NIST-Empfehlung	Veröffentlicht Oktober 2020
Zusammengesetzte (einzelne, kombinierte) postquantenmechanische/klassische Signaturen für X.509	IETF Internet-Draft, noch kein RFC	Entwurf IETF-Lampen-PQ-Verbundsignalgeber, der bis 2026 aktiv überarbeitet wird; bauen Sie noch keine Produktionssysteme, die von einem stabilen Drahtformat ausgehen.
HSM-Firmware-Unterstützung für FIPS 203/204/205 und SP 800-208	Uneinheitlich, hersteller- und modellspezifisch	Die wichtigsten Hersteller stellten die erste Unterstützung für Firmware-Updates in den Jahren 2025 und 2026 bereit; bitte prüfen Sie dies modellspezifisch und gehen Sie nicht davon aus.
Unterstützung öffentlicher Codesignatur-CAs für ML-DSA/LMS-Zertifikatsprofile	Begrenzt und noch in der Entwicklung	Bitte vergewissern Sie sich bei Ihrer Zertifizierungsstelle, dass heute ein öffentlich vertrauenswürdiges PQC-Codesignaturzertifikat verfügbar ist.
Signaturprüfer für Betriebssysteme und Plattformen (z. B. Authenticode-Verifizierung)	PQC-Signaturen werden größtenteils noch nicht erkannt.	Deshalb ist die doppelte, parallele Unterzeichnung heute das gängige Verfahren und kein Ersatz für die klassische Unterschrift.

Übergangszeitleiste

CNSA 2.0 definiert zwei Meilensteine für jede Systemkategorie: ein Datum, ab dem Systeme CNSA-2.0-Algorithmen unterstützen und standardmäßig verwenden müssen, und ein Datum, ab dem die ausschließliche Verwendung von CNSA-1.0-Algorithmen nicht mehr zulässig ist. Der Zeitplan ist bewusst gestaffelt, um die Kategorien, die nach der Implementierung am schwierigsten zu aktualisieren sind, zuerst zu berücksichtigen.

Systemkategorie	Unterstützung und Bevorzugung	Ausschließlich verwenden
Software- und Firmware-Signierung	2025 (verabschiedet)	2030
Netzwerkgeräte (VPNs, Router)	2026	2030
Betriebssysteme	2027	2033
Webbrowser, Server, Cloud-Dienste	2025 (verabschiedet)	2033
Nischen- und Legacy-Ausrüstung	Aktualisieren oder ersetzen bis 2033	2033
Alle NSS (vollständiger Übergang)	Laufend	2035 (gemäß NSM-10)

Warum die Signierung von Software und Firmware die früheste Frist hat

Es ist kein Zufall, dass die Signierung von Software und Firmware die früheste Frist für die Unterstützung und Bevorzugung im gesamten CNSA 2.0-Zeitplan hat. Dafür gibt es einen spezifischen architektonischen Grund: Die Firmware-Vertrauensanker sind die am schwierigsten zu aktualisierenden Komponenten nach der Gerätebereitstellung.

Bei der Geräteherstellung werden die Firmware-Verifizierungsschlüssel häufig in die Hardware eingebettet, manchmal sogar so fest in den Chipsatz integriert, dass sie später nicht mehr geändert werden können. Basieren diese Schlüssel auf einem quantensicheren Algorithmus, trägt das Gerät diese Schwachstelle während seiner gesamten Betriebsdauer. Bei Geräten mit einer Lebensdauer von Jahrzehnten, wie beispielsweise militärischer Hardware, industriellen Steuerungen und eingebetteten Systemen, kann ein heute gewählter Signaturschlüssel noch lange im Einsatz sein, nachdem die Existenz eines CRQC (Critical Resource Quantity Certificate) erwartet wird.

Dies birgt ein kumulatives Risiko speziell für Firmware. Ein Angreifer, der den Signaturschlüssel entweder aus archiviertem Signaturverkehr oder durch direktes Knacken des Algorithmus mittels CRQC wiederherstellen kann, könnte manipulierte Firmware signieren, die von allen eingesetzten Geräten als legitim akzeptiert würde. Da Firmware unterhalb des Betriebssystems und jeglicher softwareseitigen Sicherheitskontrolle angesiedelt ist, zählt eine gefälschte Firmware-Signatur zu den gefährlichsten Angriffen überhaupt.

Aus diesem Grund hat die NSA Hersteller seit ihrer ursprünglichen Empfehlung von 2022, also weit vor dem breiteren Übergang, dringend aufgefordert, LMS und XMSS unverzüglich einzuführen . Zustandsbehaftete Hash-basierte Signaturen wie LMS und XMSS sind gut erforscht, basieren auf konservativen Sicherheitsannahmen und sind quantenresistent. Sie eignen sich besonders für Firmware, da Signiervorgänge selten und kontrolliert durchgeführt werden, was die operative Komplexität der Verwaltung zustandsbehafteter Schlüssel reduziert.

Für Unternehmen, die Produkte mit Firmware entwickeln, bedeutet dies, dass die Signaturinfrastruktur als Erstes migriert werden sollte. Geräte, die heute mit herkömmlicher Signatur ausgeliefert werden, tragen diese Sicherheitslücke auch in den 2030er Jahren und darüber hinaus weiter. Informationen zu den spezifischen Formaten, die eine Signaturplattform für diese Geräteflotte abdecken muss, finden Sie unter „ Wir haben jedes Format gezählt, das CodeSign Secure signieren kann“ . Wie die Wahl des Algorithmus mit der Herkunftsnachverfolgung zusammenhängt, erfahren Sie unter „Stärkung der Lieferkettensicherheit mit SLSA Level 3 und Code Signing“.

Hybride und parallele Gebärdenmuster

Der Begriff „Hybrid Signing“ wird oft ungenau verwendet, und die Unterscheidung zwischen seinen beiden tatsächlichen Bedeutungen ist wichtig für das, was Sie heute einsetzen können.

Duale, parallele, getrennte Signaturen sind das derzeit verfügbare praktische Muster: Das Artefakt wird zweimal signiert, einmal mit einem klassischen Algorithmus (RSA oder ECDSA) und einmal mit einem Post-Quanten-Algorithmus (ML-DSA oder LMS). Beide Signaturen werden als separate, unabhängige Signaturblöcke mit dem Artefakt übertragen. Ein Verifizierer, der nur den klassischen Algorithmus versteht, prüft dessen Signatur und ignoriert die ihm unbekannte. Ein Verifizierer, der für die Post-Quanten-Signatur aktualisiert wurde, kann beide prüfen. Da keine der Signaturen von der anderen abhängt, funktioniert dieses Muster auch in der heutigen heterogenen und teilweise aktualisierten Verifiziererlandschaft.

Zusammengesetzte Signaturen , eine einzelne kryptografische Signatur, die einen klassischen und einen Post-Quanten-Algorithmus mathematisch zu einem Wert verknüpft, stellen einen anderen und enger integrierten Ansatz dar und sind noch kein finaler Standard für die Verwendung mit X.509. Die entsprechende Spezifikation, draft-ietf-lamps-pq-composite-sigs, ist (Stand 2026) weiterhin ein IETF Internet-Draft und wird noch überarbeitet; sie ist noch kein RFC. Die Entwicklung von Produktionswerkzeugen für ein unfertiges Übertragungsformat birgt das Risiko, Zertifikate neu signieren oder ausstellen zu müssen, sobald sich das Format stabilisiert hat. Speziell für die Codesignierung sind duale parallele Signaturen derzeit die risikoärmere Wahl; zusammengesetzte Signaturen sollten beobachtet, aber noch nicht als Standard etabliert werden.

Migrationsabhängigkeiten

Bei einer CNSA 2.0-Signaturmigration gibt es eine festgelegte Reihenfolge der Abhängigkeiten, und ein Start außerhalb dieser Reihenfolge ist eine gängige Methode, um ein Pilotprojekt an einem Problem auszulassen, bei dem es eigentlich gar nicht um Signaturen ging.

Die Unterstützung des Zielalgorithmus (ML-DSA, LMS oder XMSS) durch die HSM-Firmware oder -Hardware muss zuerst bestätigt und gegebenenfalls aktualisiert werden; Sie können keine Schlüssel generieren oder verwenden, die vom HSM nicht unterstützt werden.
Die Unterstützung von Zertifizierungsstellen und Zertifikatsprofilen folgt als nächstes, falls der Anwendungsfall überhaupt ein Zertifikat erfordert (die Firmware-Signatur von LMS/XMSS verwendet häufig stattdessen eingebettete öffentliche Schlüssel). Vergewissern Sie sich, dass Ihre Zertifizierungsstelle ein Zertifikat ausstellen kann, das den von Ihnen beabsichtigten Algorithmus kodiert, bevor Sie davon ausgehen, dass dies möglich ist.
Es muss eine Toolchain für die Signatur und Unterstützung für die CI/CD-Integration vorhanden sein, die Pipeline muss in der Lage sein, den neuen Algorithmus über Ihre Signaturplattform oder HSM-API aufzurufen.
Die Unterstützung durch Verifizierer und Plattformen wird zuletzt geprüft, sollte aber konzeptionell zuerst bewertet werden: Wenn die Systeme, die die Signatur überprüfen, den neuen Algorithmus nicht erkennen können, ist die doppelte Signatur nicht optional, sondern die einzige Möglichkeit, das Artefakt verwendbar zu halten.
Erst wenn alle vier Phasen bestätigt sind, macht eine Pilotimplementierung Sinn; siehe dazu die Phasen der Übergangsarchitektur weiter unten.

Überprüfung der Kompatibilität

Dies ist die Einschränkung, die die meisten Übergangspläne unterschätzen. Ein Artefakt kann zwar heute noch korrekt mit ML-DSA oder LMS signiert werden, doch diese Signatur ist nur dann nützlich, wenn sie von einem System am anderen Ende verifiziert werden kann. Gängige Authenticode-basierte Verifizierungsverfahren auf Betriebssystemebene erkennen derzeit keine Post-Quanten-Signaturen. Die klassische Signatur eines doppelt signierten Artefakts wird daher in absehbarer Zeit von den meisten eingesetzten Verifizierern überprüft. Interne oder benutzerdefinierte Verifizierungstools können so aktualisiert werden, dass sie die Post-Quanten-Signatur explizit prüfen. Aus diesem Grund erfüllt die doppelte Signatur heute zwei unterschiedliche Zielgruppen gleichzeitig: Externe, unveränderte Verifizierer erhalten die ihnen bereits bekannte klassische Signatur, während interne oder zukunftsorientierte Verifizierungssysteme zusätzlich die Post-Quanten-Signatur für echte Quantenresistenz validieren können. Bevor Sie ein Pilotprojekt als repräsentativ für die Produktion betrachten, sollten Sie unbedingt prüfen, in welche Kategorie Ihre einzelnen Verifizierer fallen, anstatt dies anzunehmen.

Übergangsarchitektur

Die Migration zu CNSA 2.0 ist kein einzelnes Projekt mit einem definierten Ende. Es handelt sich um ein mehrjähriges Programm, das kryptografische Bestände, Infrastruktur, Signaturvorgänge und Governance umfasst. Die folgende Fünf-Phasen-Strategie bietet einen strukturierten Weg, den Organisationen an ihre jeweilige Größenordnung und ihren Zeitplan anpassen können.

Phase 1: Kryptografische Erkennung und Bestandsaufnahme

Kryptografie, die nicht identifiziert wurde, lässt sich nicht migrieren. Die erste und grundlegendste Phase besteht darin, ein vollständiges Inventar aller Stellen im Unternehmen zu erstellen, an denen klassische Kryptografie eingesetzt wird: jedes Zertifikat, jeder Signaturschlüssel, jeder TLS-Endpunkt und jede eingebettete kryptografische Abhängigkeit in Software und Hardware.

CBOM Secure von Encryption Consulting unterstützt Ihr Unternehmen bei der Erstellung eines Inventars für jedes kryptografische Asset. Dieses Inventar erfasst den verwendeten Algorithmus und die Parameter, den Einsatzort, die Abhängigkeiten, den Eigentümer und den möglichen Ersatzpfad. Kryptografische Abhängigkeiten sind oft an schwer zugänglichen Stellen verborgen: in Drittanbieterbibliotheken, Konfigurationen von Hardware-Sicherheitsmodulen, älteren Anwendungen und Herstellerprodukten mit intransparenten internen Abläufen.

Phase 2: Priorisierung und Risikobewertung

Nach der vollständigen Bestandsaufnahme besteht die nächste Phase darin, die Migration anhand von Risiko und Frist zu priorisieren. Der CNSA-2.0-Zeitplan gibt die Fristen vor, Organisationen sollten ihn jedoch durch eine eigene Risikobewertung ergänzen.

Die höchste Priorität haben Assets, die eine frühe CNSA-2.0-Frist mit einem langfristigen Gefährdungspotenzial verbinden. Firmware-Signaturschlüssel für Geräte mit einer Nutzungsdauer von mehreren Jahrzehnten stehen an erster Stelle: Sie weisen die früheste Frist und das längste Gefährdungsfenster auf. Daten und Signaturen, die Informationen mit hohen Anforderungen an Vertraulichkeit oder Integrität schützen, folgen an zweiter Stelle, aufgrund der Bedrohung durch das Prinzip „Erfassen und später entschlüsseln“. Assets mit niedrigerer Priorität haben kurze Lebenszyklen und spätere Fristen, bei denen das Warten auf ausgereiftere Tools ein geringes Risiko birgt.

Phase 3: Infrastruktur- und Werkzeugbereitschaft

Phase 3 bereitet die Infrastruktur für den Betrieb von CNSA 2.0 vor. Die zentrale Frage für die meisten Organisationen ist die HSM- Bereitschaft. CNSA 2.0 erfordert, dass Schlüssel in validierter Hardware geschützt werden, und die meisten älteren HSMs benötigen Firmware-Updates, um ML-KEM, ML-DSA, LMS und XMSS zu unterstützen.

Organisationen sollten für jedes HSM in ihrer Umgebung beim Hersteller bestätigen, ob die aktuelle Firmware die Schlüsselerzeugung, -speicherung und -signierung gemäß CNSA 2.0 unterstützt, ob die Firmware aktualisiert werden kann, um diese Unterstützung hinzuzufügen, oder ob ein Hardwareaustausch erforderlich ist, und wann die Veröffentlichung von Firmware gemäß FIPS 203, 204 und 205 geplant ist. Führende Hersteller wie Thales Luna, Entrust nShield und Utimaco liefern Firmware-Updates mit CNSA 2.0-Unterstützung für die Jahre 2025 und 2026 aus. Die Unterstützung variiert jedoch je nach Modell und muss daher überprüft werden.

Diese Phase umfasst auch die Überprüfung, ob Signatur-Toolchains, CI/CD-Pipelines , Zertifizierungsstellen und Verifizierungssysteme CNSA 2.0-Signaturen erzeugen und validieren können.

HSM-Bereitschaftscheckliste

Es wurde modellspezifisch geprüft, ob die aktuelle Firmware die ML-DSA- und/oder LMS/XMSS-Schlüsselgenerierung und -Signierung unterstützt, und nicht nur eine allgemeine Roadmap-Aussage des Herstellers angegeben.
Es wurde festgestellt, ob ein Firmware-Update die Unterstützung erweitert oder ob ein Hardwareaustausch erforderlich ist, und vom Hersteller wurde ein konkreter Zieltermin genannt.
Die Leistung des HSM unter den neuen Algorithmen wurde überprüft; größere Schlüssel und Signaturen können den Durchsatz auf eine Weise verändern, die es wert ist, vor der Festlegung eines Einführungszeitplans gemessen zu werden.
Bestätigt wurde die absturzsichere Zustandsverwaltung speziell für LMS/XMSS, da ein verlorener oder zurückgesetzter Signaturzustand den Schlüssel vollständig gefährden kann.
Es wurde überprüft, ob die Signaturplattform oder das CI/CD-Plugin, das vor dem HSM liegt, tatsächlich aktualisiert wurde, um den neuen Algorithmus aufzurufen, und nicht nur, ob das HSM selbst ihn unterstützt.

Phase 4: Hybrideinsatz und Pilotprojekt

Für den Übergang wird ein hybrider Einsatz anstelle eines sofortigen vollständigen Austauschs empfohlen. Hybride Signierung und hybrider Schlüsselaustausch nutzen parallel sowohl einen klassischen Algorithmus als auch einen CNSA 2.0-Algorithmus. Dadurch erhalten Systeme mit Post-Quanten-Verifizierung quantenresistenten Schutz, während ältere Systeme, die noch nicht migriert wurden, weiterhin funktionieren.

Phase 4 setzt dies durch Pilotprojekte in die Praxis um. Man beginnt mit einer kontrollierten, risikoärmeren Produktlinie oder einem System, implementiert hybride Signaturverfahren oder hybriden Schlüsselaustausch und validiert, dass die Artefakte und Verbindungen in der gesamten Verifizierungsinfrastruktur, auf die sie treffen werden, korrekt funktionieren. Hier treten die Sonderfälle zutage: Verifizierungstools, die CNSA 2.0-Signaturen noch nicht verstehen, Leistungseinbußen durch größere Schlüssel- und Signaturgrößen sowie Integrationsprobleme in der Signaturpipeline. Die Behebung dieser Probleme in einem Pilotprojekt ist deutlich kostengünstiger als deren Entdeckung im Produktivbetrieb.

Phase 5: Vollständige Migration und Stilllegung der Altsysteme

In der letzten Phase wird der validierte Ansatz auf die gesamte Umgebung ausgeweitet und die rein klassische Kryptografie schrittweise ersetzt. Mit zunehmender Reife der Verifizierungsinfrastruktur und der flächendeckenden Unterstützung von CNSA 2.0 in den Systemen der Organisation kann die klassische Komponente hybrider Implementierungen gemäß den im CNSA-2.0-Zeitplan festgelegten Fristen für die ausschließliche Nutzung außer Betrieb genommen werden.

Diese Phase umfasst auch die Stilllegung oder den Austausch von Nischen- und Altsystemen, die nicht vor Ort migriert werden können. CNSA 2.0 geht davon aus, dass dies bis 2033 abgeschlossen sein wird. Dabei handelt es sich oft um die ressourcenintensivsten Änderungen, die daher rechtzeitig vor dem Stichtag geplant werden sollten.

Test und Validierung

Über die in Phase 4 beschriebene Pilotphase hinaus verdienen einige spezifische Prüfungen eine explizite Testabdeckung, bevor ein Artefakt mit doppelten Vorzeichen in großem Umfang ausgeliefert wird:

Überprüfen Sie das Artefakt mit jedem Verifizierer, dem es in der Produktion tatsächlich begegnen wird, nicht nur mit demjenigen, der während der Entwicklung verwendet wurde, da das Verhalten der Verifizierer bei einer nicht erkannten zusätzlichen Signatur nicht auf allen Plattformen identisch sein muss.
Messen Sie den Einfluss der Größe größerer Post-Quanten-Schlüssel und Signaturen auf die Artefaktgröße, die Downloadzeit und alle größenbeschränkten Verteilungskanäle (insbesondere eingebettete Aktualisierungsmechanismen).
Prüfen Sie die Kompatibilität des Zeitstempels; ein vertrauenswürdiger Zeitstempel muss unabhängig davon, welchem Signaturalgorithmus er zugeordnet ist, gültig und überprüfbar bleiben.
Bei hohem Releasevolumen sollte der Durchsatz des Signierverfahrens unter dem neuen Algorithmus unter Last getestet werden, da ML-DSA und LMS/XMSS andere Leistungsmerkmale als RSA oder ECDSA aufweisen.

Rollback

Da die duale, parallele Signatur eine zweite, unabhängige Signatur hinzufügt, anstatt die erste zu ersetzen, ist ein Rollback während der Pilot- und frühen Einführungsphase vergleichsweise risikoarm: Sollte die hinzugefügte Post-Quanten-Signatur irgendwo im Feld einen unerwarteten Verifizierungsfehler verursachen, ist die klassische Signatur weiterhin vorhanden und gültig. Die Lösung besteht darin, die zweite Signatur für diesen Artefaktstrom nicht mehr anzuhängen, bis die Inkompatibilität behoben ist – es müssen keine neuen Artefakte ausgestellt oder widerrufen werden. Anders verhält es sich, sobald eine Umgebung ihr Datum für die „exklusive Nutzung“ erreicht hat und die klassische Signatur tatsächlich abgeschafft wurde. In diesem Fall bedeutet ein Rollback, die duale Signatur vorübergehend wieder zu aktivieren, während die zugrunde liegende Verifizierungslücke geschlossen wird. Dies ist ein weiterer Grund, die klassische Signatur nicht vollständig außer Betrieb zu nehmen, bis die Verifizierungsabdeckung für jeden Nutzer des Artefakts bestätigt und nicht nur angenommen wurde.

Wie Verschlüsselungsberatung helfen kann

Der Übergang zu CNSA 2.0 umfasst kryptografische Erkennung, Infrastrukturvorbereitung, Signaturvorgänge und langfristige Governance. Das Produktportfolio und die Beratungsleistungen von Encryption Consulting sind darauf ausgelegt, Organisationen in jeder Phase dieses Prozesses zu unterstützen.

PQC-Beratungsleistungen : Unsere Beratungsleistungen im Bereich Post-Quanten-Kryptografie bilden die strategische Grundlage für eine Migration zu CNSA 2.0. Wir unterstützen Unternehmen bei der Bewertung ihrer aktuellen kryptografischen Situation, der Erstellung eines auf den CNSA-2.0-Zeitplan abgestimmten Migrationsfahrplans, der Priorisierung von Assets nach Risiko und Frist sowie der Entwicklung einer agilen Krypto-Architektur, die sowohl diesen als auch zukünftige Übergänge ermöglicht.

CBOM Secure : Phase 1 jeder CNSA 2.0-Migration ist die Ermittlung, denn was man nicht sieht, kann nicht migriert werden. CBOM Secure führt eine kontinuierliche kryptografische Ermittlung in Ihrer gesamten Umgebung durch und erstellt ein vollständiges, aktuelles Inventar der Zertifikate, Schlüssel und kryptografischen Abhängigkeiten, die für die Migration erforderlich sind. Es identifiziert präzise, welche Assets quantenanfällige Algorithmen verwenden und in den CNSA 2.0-Übergang integriert werden müssen. So wird die grundlegende Ermittlungsphase von einem manuellen, fehleranfälligen Prozess in einen automatisierten, wiederholbaren Prozess umgewandelt.

CodeSign Secure : Da die Signierung von Software und Firmware die früheste CNSA 2.0-Frist beinhaltet, müssen viele Unternehmen hier zuerst aktiv werden. CodeSign Secure unterstützt die CNSA 2.0-Signaturalgorithmen im Produktivbetrieb: ML-DSA mit den erforderlichen Parameterstufen und LMS für die Firmware-Signierung, unterstützt durch FIPS-validierte HSMs von Thales, Entrust, Utimaco und Securosys. Die Plattform gewährleistet zudem den von der NSS-Signatur-Governance geforderten Schlüsselschutz, die rollenbasierte Zugriffskontrolle und die Protokollierung von Audits.

Fazit

CNSA 2.0 stellt den konkretsten und operativ spezifischsten Fahrplan für die Migration nach der Quantentechnologie dar, den je eine Regierung veröffentlicht hat. Er benennt exakte Algorithmen, exakte Parametersätze und exakte Termine und untermauert diese Termine mit Durchsetzungsmechanismen, die die Einhaltung zur Bedingung für Validierung, Zertifizierung und Beschaffung machen.

Organisationen, die diesen Übergang erfolgreich meistern werden, behandeln ihn als strukturiertes, mehrjähriges Programm: Sie ermitteln ihren kryptografischen Bestand, priorisieren nach Risiko und Frist, bereiten ihre Infrastruktur vor, setzen während des Übergangs hybride Ansätze ein und entwickeln Krypto-Agilität, um die nächste kryptografische Umstellung deutlich weniger aufwändig zu gestalten. Die Signaturinfrastruktur mit ihrer kurzen Frist und dem langen Zeitfenster ist hierfür der richtige Ausgangspunkt.

Bei Encryption Consulting sind unsere Beratungsleistungen und unser Produktportfolio – von CBOM Secure für die Erkennung bis hin zu CodeSign Secure für die CNSA 2.0-Signatur – darauf ausgerichtet, Sie auf Ihrem Weg von der ersten Bestandsaufnahme bis zur endgültigen Stilllegung zu unterstützen. Wenn Ihr Unternehmen seine CNSA 2.0-Bereitschaft prüft, helfen wir Ihnen gerne bei der Entwicklung der passenden Strategie.

Häufig gestellte Fragen

Ist ML-KEM dasselbe wie ML-DSA?

Nein. ML-KEM (FIPS 203) ist ein Schlüsselkapselungsmechanismus zur Erzeugung eines gemeinsamen Geheimnisses für die Verschlüsselung; ML-DSA (FIPS 204) ist ein Algorithmus für digitale Signaturen. Sie lösen unterschiedliche Probleme und sind nicht austauschbar. Für die Codesignierung wird ML-DSA oder das zustandsbehaftete, hashbasierte Verfahren LMS/XMSS verwendet, niemals ML-KEM.

Worin besteht der Unterschied zwischen hybriden und zusammengesetzten postquantenmechanischen Signaturen?

Hybrid bedeutet im heutigen Sinne zweier unabhängiger, paralleler Signaturen – einer klassischen und einer postquantenmechanischen –, die demselben Artefakt zugeordnet sind. Komposit bedeutet einen einzelnen Signaturwert, der beide Algorithmen mathematisch kombiniert; die entsprechende IETF-Spezifikation für zusammengesetzte ML-DSA-Signaturen ist (Stand 2026) noch ein Internet-Draft und kein finalisierter RFC.

Können aktuelle Signaturprüfprogramme heute eine ML-DSA- oder LMS-Signatur überprüfen?

Es hängt vollständig vom jeweiligen Verifizierer ab. Gängige Authenticode-basierte Verifizierungsverfahren auf Betriebssystemebene erkennen Post-Quanten-Signaturen größtenteils noch nicht. Daher ist die doppelte Signatur, bei der die klassische Signatur neben der neuen beibehalten wird, der praktikablere Ansatz, anstatt sie vollständig zu ersetzen.

Welche HSMs unterstützen heute CNSA 2.0-Algorithmen?

Führende Hersteller wie Thales Luna, Entrust nShield und Utimaco bieten CNSA 2.0-Unterstützung in den Firmware-Versionen 2025 und 2026 an. Die Unterstützung variiert jedoch je nach Modell. Bitte erkundigen Sie sich direkt beim Hersteller nach der aktuellen Firmware-Kompatibilität Ihres spezifischen HSM-Modells, anstatt von einer allgemeinen Unterstützung auszugehen.

Was passiert, wenn ein doppelt signiertes Artefakt irgendwo im Feld die Verifizierung nicht besteht?

Da die klassische Signatur weiterhin vorhanden und unabhängig ist, bleibt das Artefakt in der Regel für Verifizierer gültig, die ausschließlich die klassische Signatur prüfen. Die Reaktion besteht darin, das Hinzufügen der Post-Quanten-Signatur für diesen Artefaktstrom zu pausieren, bis die spezifische Inkompatibilität diagnostiziert ist; es werden keine Artefakte widerrufen oder neu ausgestellt.

Gestaltung der CNSA 2.0-Übergangsstrategien