CNSA 2.0-Konformität für Verteidigungsorganisationen: Migrations-Fahrplan

Im September 2022 veröffentlichte die Cybersecurity Directorate der NSA die Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) – eine Direktive, die vorschreibt, dass alle National Security Systems von klassischer Public-Key-Kryptografie auf Post-Quanten-Algorithmen nach einem festgelegten Zeitplan migrieren müssen. Für Verteidigungsorganisationen ist dies keine Forschungsfrage oder ein zukünftiges Planungselement: Beschaffungsanforderungen beinhalten bereits CNSA 2.0-Bereitschaftskriterien, und neue Systeme, die ab 2025 eingesetzt werden, müssen die vorgeschriebenen Algorithmen von Anfang an unterstützen.

Die Migrationsherausforderung ist erheblich. Klassische Public-Key-Kryptografie – RSA, Elliptische-Kurven-Kryptografie (ECC) und Diffie-Hellman – ist in der gesamten Verteidigungs-IT-Infrastruktur eingebettet: TLS-Endpunkte, VPN-Gateways, PKI-Zertifizierungsstellen, Schlüsselverwaltungssysteme, Firmware-Signierungspipelines und verschlüsselte Datenarchive. Der Ersatz dieser Abhängigkeiten in einer großen Organisation ist ein mehrjähriges Programm, das eine sorgfältige Sequenzierung, Anbieterkoordination und Risikomanagement während des Zeitraums erfordert, in dem klassische und Post-Quanten-Systeme interoperieren müssen.

Dieser Artikel legt einen praktischen Migrations-Fahrplan dar: Was CNSA 2.0 erfordert, welche Algorithmen welche ersetzen, wie der Übergang in einer Verteidigungsorganisation zu sequenzieren ist und was von Anbietern CNSA 2.0-fähiger Systeme zu fordern ist.

Was CNSA 2.0 erfordert und warum

Die kryptografische Bedrohung, die CNSA 2.0 antreibt, ist Shors Algorithmus – ein Quantenalgorithmus, der, wenn er auf einem ausreichend großen Quantencomputer ausgeführt wird, die mathematischen Probleme bricht, die RSA (ganzzahlige Faktorisierung), ECC (elliptischer Kurven-Diskreter-Logarithmus) und Diffie-Hellman (Diskreter Logarithmus) zugrunde liegen. Ein Quantencomputer, der Shors Algorithmus gegen 2048-Bit-RSA oder 256-Bit-ECC ausführen könnte, würde Millionen logischer Qubits mit niedrigen Fehlerraten benötigen. Diese Fähigkeit existiert heute nicht, aber glaubwürdige öffentliche Schätzungen verorten einen "kryptografisch relevanten Quantencomputer" (CRQC) irgendwo im Zeitraum 2030–2035.

Die "Harvest now, decrypt later" (HNDL)-Bedrohung verkürzt diesen Zeitplan für Verteidigungszwecke. Gegner, die heute verschlüsselten Datenverkehr sammeln – strategische Kommunikation, Geheimdienstberichte, Fähigkeitsbewertungen – können ihn speichern und entschlüsseln, sobald ein CRQC verfügbar wird. Die Vertraulichkeit von Daten, die heute mit klassischen Algorithmen verschlüsselt werden, hat daher ein effektives Ablaufdatum, das mit der CRQC-Verfügbarkeit korreliert. Für Daten mit Geheimhaltungsanforderungen, die in Jahrzehnten gemessen werden, ist dieses Ablaufdatum bereits eine gegenwärtige operative Sorge.

CNSA 2.0 begegnet dem, indem es einen spezifischen Satz von Post-Quanten-Algorithmen für NSS vorschreibt, mit einem Übergangszeitplan, der darauf ausgelegt ist sicherzustellen, dass die Migration vor der CRQC-Verfügbarkeit abgeschlossen wird. Die wichtigsten Vorgaben:

• ML-KEM (FIPS 203 / CRYSTALS-Kyber) – ersetzt RSA und ECDH für den gesamten Schlüsselaustausch. CNSA 2.0 schreibt ML-KEM-1024 (die höchste Sicherheitsparameterstufe) für NSS-Anwendungen vor.
• ML-DSA (FIPS 204 / CRYSTALS-Dilithium) – ersetzt RSA-PSS und ECDSA für digitale Signaturen in den meisten Anwendungen. Bietet schnelles Signieren und Verifizieren bei vernünftigen Schlüssel- und Signaturgrößen.
• SLH-DSA (FIPS 205 / SPHINCS+) – ein alternativer Signaturalgorithmus, der auf Hash-Funktionen statt auf Gittermathematik basiert. Wird dort eingesetzt, wo Diversität gegenüber gitterbasierten Algorithmen erforderlich ist oder wo gitterbasierte Algorithmen nicht zulässig sind. Signaturen sind deutlich größer als bei ML-DSA, aber die Sicherheit basiert auf gut verstandenen Hash-Funktionseigenschaften.
• LMS und XMSS – zustandsbehaftete hashbasierte Signaturverfahren, die für spezifische Anwendungsfälle zugelassen sind, insbesondere für die Firmware-Signierung in eingeschränkten Umgebungen. Erfordern sorgfältiges Zustandsmanagement, um die Wiederverwendung von Schlüsseln zu vermeiden.
• AES-256 und SHA-384 – aus CNSA 1.0 für symmetrische Verschlüsselung und Hashing beibehalten; diese sind durch Quantencomputer in praktischem Maßstab nicht gefährdet.

Veraltete Algorithmen, die unter CNSA 2.0 abgeschafft werden müssen, umfassen: RSA (alle Schlüsselgrößen, alle Anwendungen), ECDH und ECDSA (alle Kurven), Diffie-Hellman (klassisch und elliptisch) sowie SHA-256 für NSS-Anwendungen (wo SHA-384 jetzt vorgeschrieben ist). AES-128 und AES-192 werden ebenfalls zugunsten von AES-256 für NSS abgeschafft.

Zugelassene Algorithmen im Detail

ML-KEM (Module-Lattice Key Encapsulation Mechanism) basiert auf der Schwierigkeit des Module Learning With Errors (MLWE)-Problems – einem Gitterproblem, das kein bekannter Quanten- oder klassischer Algorithmus effizient löst. ML-KEM funktioniert als Schlüsselkapselungsmechanismus: Der Sender kapselt ein gemeinsames Geheimnis unter dem öffentlichen Schlüssel des Empfängers; der Empfänger entkapselt, um das gemeinsame Geheimnis wiederherzustellen. Das gemeinsame Geheimnis speist dann eine symmetrische Schlüsselableitungsfunktion. ML-KEM-1024 erzeugt öffentliche Schlüssel von 1.568 Bytes, Chiffretexte von 1.568 Bytes und gemeinsame Geheimnisse von 32 Bytes – größer als RSA-2048-Schlüssel (256 Bytes), aber für die meisten Protokollkontexte akzeptabel.

ML-DSA (Module-Lattice Digital Signature Algorithm) basiert auf der Schwierigkeit der Module Short Integer Solution (MSIS)- und MLWE-Probleme. ML-DSA-87 (die höchste Sicherheitsstufe, entsprechend der AES-256-Sicherheit) erzeugt öffentliche Schlüssel von 2.592 Bytes und Signaturen von 4.627 Bytes. Im Vergleich dazu erzeugt ECDSA P-256 64-Byte-Signaturen. Die größeren Signaturgrößen erfordern Anpassungen in Protokollen und Speichersystemen, die kompakte Signaturen vorausgesetzt hatten – Zertifikatsketten, Firmware-Images und bandbreitenbeschränkte Verbindungen benötigen Kapazitätsplanung.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) hat keine algebraische Struktur, die weder durch klassische noch durch Quantenalgorithmen über generische Hash-Funktionsangriffe hinaus ausgenutzt werden kann; seine Sicherheit reduziert sich vollständig auf die Kollisionsresistenz der zugrunde liegenden Hash-Funktion. Der Kompromiss liegt bei Leistung und Größe: SLH-DSA-SHA2-256s-Signaturen sind bei der niedrigsten Parameterstufe 29.792 Bytes groß, und das Signieren ist um Größenordnungen langsamer als ML-DSA. SLH-DSA ist als sekundärer Signaturalgorithmus geeignet, um Sicherheitsdiversität zu bieten, insbesondere für Firmware- und Software-Signierung, wo Signaturgröße und Signierhäufigkeit handhabbar sind.

Die vier Migrationsphasen

Eine gut strukturierte CNSA 2.0-Migration verläuft in vier Phasen. Organisationen können sich gleichzeitig in verschiedenen Phasen für unterschiedliche Systemtypen befinden – eine große Verteidigungsorganisation wird typischerweise die PKI-Migration in Phase 2 haben, während taktische Edge-Systeme noch in Phase 1 sind.

Phase 1 – Kryptografische Bestandsaufnahme. Bevor Migrationsarbeiten geplant werden können, muss die Organisation wissen, was sie hat. Die kryptografische Bestandsaufnahme umfasst: jeden TLS-Endpunkt und seine ausgehandelten Cipher Suites; jedes verwendete Zertifikat (Benutzer, Gerät, Dienst, Code-Signierung) und seinen Schlüsselalgorithmus sowie sein Ablaufdatum; jedes VPN-Gateway und seine IKEv2-Schlüsselaustauchkonfiguration; jedes Schlüsselverwaltungssystem, HSM und kryptografisches Token; jede Firmware-Signierungspipeline und ihren Signierungsschlüsseltyp; sowie jedes Datenarchiv, bei dem langfristige Vertraulichkeit erforderlich ist und der Verschlüsselungsschlüsselalgorithmus.

Automatisierte Tools helfen – TLS-Scanner (SSLyze, testssl.sh), SBOM-Analyse für kryptografische Bibliotheksabhängigkeiten und Zertifikatsverwaltungsplattformen mit Algorithmusberichten. Aber automatisierte Tools verpassen benutzerdefinierte Protokollimplementierungen, eingebettete Firmware-Krypto und anwendungsschichtige Kryptografie außerhalb der Standardbibliotheken. Eine manuelle Überprüfung der Architekturdokumentation und des Quellcodes ist für die Vollständigkeit erforderlich.

Phase 2 – Risikobasierte Priorisierung. Nicht alle kryptografischen Abhängigkeiten tragen das gleiche HNDL-Risiko. Die Priorisierung sollte zwei Dimensionen widerspiegeln: die Langlebigkeit und Sensitivität der geschützten Daten sowie die Machbarkeit einer zeitnahen Migration. Hochprioritäre Ziele sind Systeme, die langlebige klassifizierte Daten schützen, bei denen die HNDL-Exposition am höchsten ist: PKI-Root- und ausstellende CAs (deren Schlüssel den Vertrauensanker für die gesamte Organisation schützen), Schlüsselverwaltungsinfrastruktur (HSMs, die Hauptschlüssel für verschlüsselte Archive halten), strategische Kommunikationsverbindungen und alle Systeme, die Daten mit einer Geheimhaltungsanforderung von mehr als fünf Jahren verschlüsseln.

Niedrigere Priorität – aber dennoch vor 2030 erforderlich – haben Systeme mit häufigen Hardware-Erneuerungszyklen (taktische Plattformen, Endbenutzergeräte), bei denen PQC-Fähigkeit bei der nächsten natürlichen Erneuerung einbezogen werden kann, sowie interne Systeme, die nicht klassifizierte Daten schützen, bei denen das Quantenrisiko geringer ist.

Phase 3 – Hybrider Betrieb. Während der Migration werden Systeme sowohl mit CNSA 1.0 (klassischen) als auch CNSA 2.0 (Post-Quanten)-Gegenstücken interoperieren. Hybride Kryptografie – die Kombination klassischer und Post-Quanten-Algorithmen im selben Protokollaustausch – bietet Quantenresistenz für den aktuellen Datenverkehr, ohne dass alle Endpunkte gleichzeitig Post-Quanten-Algorithmen unterstützen müssen.

Bei einer hybriden TLS 1.3-Verbindung enthält der Client sowohl einen ECDHE-Schlüsselanteil als auch einen ML-KEM-Schlüsselanteil im ClientHello; der Server antwortet mit beiden. Der endgültige Sitzungsschlüssel wird aus beiden gemeinsamen Geheimnissen mithilfe einer Schlüsselableitungsfunktion abgeleitet. Ein Angreifer muss sowohl den klassischen als auch den Post-Quanten-Algorithmus brechen, um die Sitzung zu kompromittieren. Dieser "Gürtel und Hosenträger"-Ansatz wird von der NSA ausdrücklich für den Übergangszeitraum befürwortet.

Phase 4 – Vollständiger Übergang. Sobald alle Systeme Post-Quanten-Algorithmen unterstützen und der hybride Betrieb in der Produktion als stabil erwiesen wurde, werden klassische Cipher Suites und Zertifikatstypen zurückgezogen. Die Abschaffung muss mit allen interoperierenden Organisationen, Anbietern und Partnernationen koordiniert werden. Überwachung einrichten, um verbleibende klassische Algorithmusverhandlungen zu erkennen (was darauf hinweisen würde, dass ein System in der Bestandsaufnahme übersehen wurde oder ein Anbieter noch keine CNSA 2.0-fähige Software geliefert hat), und Abschaffungsmeilensteine gegen die Frist 2030 verfolgen.

Hochprioritäre Systeme und Migrationssequenzierung

Innerhalb des priorisierten Migrations-Backlogs erscheinen bestimmte Systemtypen konsequent als hochprioritär in nahezu allen Verteidigungsorganisationen und sollten unabhängig von organisatorischen Besonderheiten früh sequenziert werden.

Schlüsselverwaltungsinfrastruktur. HSMs und Schlüsselverwaltungsdienste (KMSes) sind Abhängigkeiten für die Migration fast aller anderen Systeme – Post-Quanten-Schlüssel müssen irgendwo generiert, gespeichert und verwaltet werden. Die Aktualisierung von HSM-Firmware zur Unterstützung von ML-KEM- und ML-DSA-Operationen und die Überprüfung, ob Schlüsselverwaltungs-APIs Post-Quanten-Schlüsseltypen für verbrauchende Anwendungen bereitstellen, ist Phase 1-2-Arbeit in jedem Migrationsprogramm. Dies ist auch der Bereich, in dem die Anbietereinbindung am kritischsten ist: HSM-Anbieter variieren erheblich in ihren PQC-Fahrplänen, und einige Hardwaregenerationen können nicht direkt aktualisiert werden.

PKI-Root- und ausstellende CAs. Die PKI-Vertrauenshierarchie unterstützt die zertifikatsbasierte Authentifizierung in der gesamten Organisation. Die Einrichtung von Post-Quanten-Root-CAs – und die Verteilung ihrer Vertrauensanker an alle abhängigen Parteien (Browser, Betriebssysteme, TLS-Clients, OCSP-Validatoren) – ist eine Voraussetzung für die Ausstellung von Post-Quanten-Zertifikaten an jedes System. Dies muss geschehen, bevor Post-Quanten-Zertifikate anderswo eingesetzt werden können. Ein Dual-Issuance-Modell, bei dem dieselbe CA sowohl klassische als auch Post-Quanten-Zertifikate für jedes Subjekt ausstellt, ermöglicht eine schrittweise Migration der abhängigen Parteien ohne Unterbrechung bestehender Vertrauensbeziehungen.

VPN-Gateways und verschlüsselte Kommunikationsplattformen. VPN-Gateways, die klassifizierte Netzwerkperimeter schützen, sind primäre HNDL-Ziele. IKEv2, das Schlüsselaustauschprotokoll, das in den meisten Enterprise-VPN-Lösungen verwendet wird, muss aktualisiert werden, um ML-KEM für den Schlüsselaustausch und ML-DSA für die Authentifizierung auszuhandeln. Die meisten Enterprise-VPN-Anbieter (Cisco, Palo Alto, Juniper, Check Point) haben PQC-Fahrplanitems, aber die Verfügbarkeit von Funktionen und die Konformität mit CNSA 2.0-Parametern variieren erheblich – dies ist eine kritische Anbieterqualifikationsfrage bei der Beschaffung.

Verschlüsselte Kommunikations- und Messaging-Plattformen. Systeme, die für strategische Befehlskommunikation, Geheimdienstverbreitung und missionskritische Koordination genutzt werden, sind hochprioritäre Ziele, weil die Sensitivität und Langlebigkeit des Datenverkehrs hoch ist. Corvus.Quantum, Corvus Intelligences Streaming-Plattform für die Verteidigung, ist für die CNSA 2.0-Ausrichtung konzipiert – mit ML-KEM für den Schlüsselaustausch und ML-DSA für die Nachrichtensignierung in seiner Streaming- und Messaging-Architektur sowie Unterstützung des hybriden Betriebs während des Übergangszeitraums.

Firmware-Signierungspipelines. Waffensysteme und militärische Hardwareplattformen verwenden digitale Signaturen zur Überprüfung der Firmware-Integrität. Diese Signaturen sind langlebig – der Signierungsschlüssel kann das gesamte Produktionsleben einer Plattform abdecken, das sich über ein Jahrzehnt oder länger erstreckt – und sind daher direkt dem HNDL-Risiko ausgesetzt. Neue Plattformen, die in die Produktion gehen, sollten von der ersten Lieferung an mit ML-DSA- oder SLH-DSA-Firmware-Signierung ausgeliefert werden. Aktive Plattformen erfordern eine Neu-Signierungskampagne für Firmware-Images, bei denen die Boot-Architektur eine Schlüsselrotation unterstützt; Plattformen, bei denen Signierungsschlüssel bei der Herstellung eingebrannt werden, erfordern eine explizite Risikokommentierung.

Wie kryptografische Abhängigkeiten inventarisiert werden

Die kryptografische Bestandsaufnahme ist konsequent die am meisten unterschätzte Phase von PQC-Migrationsprogrammen. Organisationen, die mit der Migration beginnen und davon ausgehen, dass die Bestandsaufnahme Wochen dauern wird, entdecken typischerweise, dass sie Monate erfordert, weil Kryptografie über mehr Systemschichten und mehr Code-Pfade hinweg eingesetzt wird, als ein einzelnes Team vollständige Sichtbarkeit hat.

Eine umfassende Inventarisierungsstrategie kombiniert vier Ansätze. Erstens, Netzwerkschichten-Erkennung: passive TLS-Verkehrsanalyse und aktive Überprüfung aller erreichbaren Endpunkte mithilfe von Tools, die ausgehandelte Cipher Suites und Zertifikatschlüsselalgorithmen identifizieren. Dies erfasst Webserver, API-Endpunkte, Load Balancer und Service-Mesh-Kommunikationen, die Standard-TLS verwenden. Zweitens, Enumeration der Zertifikatsverwaltungsplattform: Abfrage der CA-Hierarchie der Organisation und aller öffentlichen CT (Certificate Transparency)-Protokolle nach Zertifikaten mit den Namen der Organisation, Extraktion von Schlüsselalgorithmus und Ablauf für jedes. Drittens, SBOM-Analyse: Extraktion von Software-Stücklisten aus eingesetzten Anwendungen und Scan nach kryptografischen Bibliotheksabhängigkeiten (OpenSSL, BoringSSL, libgcrypt, NSS, Java-Krypto-Provider) und deren Versionen. Versionen kryptografischer Bibliotheken bestimmen, welche Algorithmen verfügbar sind und welche die Standardeinstellungen sind. Viertens, Überprüfung der Architekturdokumentation: Identifikation benutzerdefinierter Protokollimplementierungen, prozessinterner Schlüsselableitung, verschlüsselter Datenbankspalten und anwendungsschichtiger Kryptografie, die die Netzwerkabtastung nicht beobachten kann.

Das Ergebnis der Bestandsaufnahme sollte ein strukturiertes Register mit mindestens folgenden Angaben sein: Systemname, Art der kryptografischen Abhängigkeit (TLS, Zertifikat, KEM, Signatur, symmetrisch), Algorithmus und Schlüsselgröße, Bibliothek oder Implementierung, Datenklassifikation der geschützten Daten und geschätzte Migrationskomplexität. Dieses Register treibt die Priorisierung in Phase 2 an und liefert die Basislinie für die Verfolgung des Konformitätsfortschritts.

Anbieterfragen bei der Beschaffung

Verteidigungsorganisationen, die kommerzielle Standard-Software und -Hardware beschaffen, müssen die CNSA 2.0-Bereitschaft als Teil der Beschaffung bewerten. Die folgenden Fragen unterscheiden Anbieter mit echter PQC-Fähigkeit von solchen mit Fahrplanversprechen:

Algorithmus-Support-Spezifika. „Unterstützt Ihr Produkt ML-KEM-1024, ML-DSA-87 und SLH-DSA-SHA2-256s, wie in FIPS 203, 204 und 205 definiert?" Anbieter, die mit generischen „Post-Quanten-Support"-Behauptungen ohne spezifische FIPS-Bezeichnungen und Parameterebenen antworten, werden wahrscheinlich die spezifischen Anforderungen von CNSA 2.0 nicht erfüllen. Algorithmus-Support auf niedrigeren Parameterebenen (ML-KEM-512, ML-DSA-44) erfüllt nicht die von CNSA 2.0 für NSS vorgeschriebenen Sicherheitsstufen.

Verfügbarkeit hybrider Cipher Suites. „Unterstützt Ihre TLS-Implementierung hybriden ML-KEM + ECDHE-Schlüsselaustausch in einem einzigen Handshake?" Hybrid-Support ermöglicht es der Organisation, von der Quantenresistenz des aktuellen Datenverkehrs zu profitieren, ohne zu erfordern, dass alle interoperierenden Parteien die PQC-Migration gleichzeitig abschließen.

Schlüsselgrößen-Aufnahme. „Wie handhabt Ihr System die größeren Schlüssel- und Signaturgrößen von Post-Quanten-Algorithmen?" ML-DSA-87-Signaturen sind ungefähr 4,6 KB gegenüber ECDSA P-256's 64 Bytes. Systeme mit festgroßen Zertifikat- oder Signaturpuffern, Datenbankschemata mit festen kryptografischen Feldlängen oder Netzwerkprotokollen mit strengen MTU-Annahmen können architektonische Änderungen erfordern, um PQC-Schlüsselmaterial aufzunehmen.

Herkunft der kryptografischen Bibliothek. „Welche kryptografische Bibliothek liegt Ihrer PQC-Implementierung zugrunde, und wie häufig werden Versionen aktualisiert?" Post-Quanten-Implementierungen in OpenSSL, BoringSSL und Bouncy Castle reifen noch; der Update-Rhythmus des Anbieters bestimmt, wie schnell Sicherheits-Patches bereitgestellte Produkte erreichen.

Fahrplan nach 2030. „Was ist Ihr Plan für den reinen PQC-Betrieb nach 2030, wenn der hybride Modus und klassische Algorithmen abgeschafft werden?" Anbieter ohne einen konkreten Post-2030-Fahrplan stellen ein Konformitätsrisiko dar, das verwaltete Übergänge zum ungünstigsten Zeitpunkt erfordern wird – wenn die Frist unmittelbar bevorsteht.

Sechsstufiger CNSA 2.0-Migrationsplanungsprozess

Die folgenden Schritte destillieren die oben beschriebenen Migrationsphasen in eine umsetzbare Planungssequenz für Verteidigungs-IT- und Sicherheitsteams, die ein CNSA 2.0-Konformitätsprogramm starten.

Schritt 1 – Kryptografische Bestandsaufnahme durchführen. Setzen Sie TLS-Scanning, Zertifikatsverwaltungsberichte, SBOM-Analyse und Überprüfung der Architekturdokumentation in allen Systemen ein. Erstellen Sie ein strukturiertes Register jeder kryptografischen Abhängigkeit: Typ, Algorithmus, Schlüsselgröße, Bibliothek, Datenklassifikation und geschätzte Migrationskomplexität. Erwarten Sie, dass dieser Schritt 2 bis 6 Monate für eine mittelgroße bis große Verteidigungsorganisation dauert. Gehen Sie nicht ohne eine einigermaßen vollständige Bestandsaufnahme zur Planung über – Migrationspläne, die auf einer unvollständigen Bestandsaufnahme aufgebaut sind, werden hochprioritäre Systeme übersehen.

Schritt 2 – Risiko bewerten und Systeme priorisieren. Bewerten Sie jeden Bestandspunkt auf zwei Achsen: HNDL-Risiko (Sensitivität und Langlebigkeit der geschützten Daten) und Migrationsmachbarkeit (Teamfähigkeit, Anbieterbereitschaft, architektonische Komplexität). Erstellen Sie ein priorisiertes Migrations-Backlog mit geschätztem Aufwand, Abhängigkeiten zwischen den Elementen und Eigentümerzuweisungen. Elemente, die langlebige klassifizierte Daten mit geringer Migrationskomplexität schützen, sollten unabhängig von der Organisationspolitik ganz oben stehen.

Schritt 3 – Zuerst Schlüsselverwaltungs- und PKI-Infrastruktur aktualisieren. Migrieren Sie HSMs auf CNSA 2.0-fähige Firmware. Stellen Sie Post-Quanten-Root-CA-Zertifikate aus. Richten Sie Dual-Issuance-Fähigkeit ein. Verteilen Sie aktualisierte Vertrauensanker an abhängige Parteien. Diese Phase ist eine Abhängigkeit für alle nachfolgenden zertifikatsbasierten Migrationen und sollte unmittelbar nach Abschluss der Bestandsaufnahme ressourciert und begonnen werden.

Schritt 4 – Hybride Cipher Suites auf hochprioritären Netzwerkpfaden einsetzen. Aktivieren Sie ML-KEM-hybride Cipher Suites auf VPN-Gateways, klassifizierten Netzwerkperimetern und Kommunikationsplattformen. Dieser Schritt bietet sofortige HNDL-Risikoreduktion für den aktuellen Datenverkehr, ohne dass eine vollständige PQC-Bereitschaft aller Endpunkte erforderlich ist. Verhandlungsraten überwachen, um die Akzeptanz zu verfolgen.

Schritt 5 – Firmware-Signierung und Software-Lieferkette migrieren. Übergehen Sie Firmware-Signierungspipelines zu ML-DSA- oder SLH-DSA-Schlüsseln für alle Plattformen, die in die Produktion gehen. Führen Sie Neu-Signierungskampagnen für aktive Plattformen durch, wo architektonisch machbar. Aktualisieren Sie CI/CD-Code-Signing-Pipelines. Dokumentieren Sie eingeschränkte Plattformen als verwaltete kryptografische technische Schulden mit expliziter Risikoakzeptanz.

Schritt 6 – Vollständigen Übergang durchführen und klassische Algorithmen abschaffen. Sobald alle hochprioritären Systeme Post-Quanten-Algorithmen unterstützen und der hybride Betrieb stabil ist, beginnen Sie mit dem Zurückziehen klassischer Cipher Suites und Zertifikatstypen nach einem koordinierten Zeitplan mit interoperierenden Organisationen. Richten Sie ein Konformitäts-Dashboard ein. Zielen Sie auf die vollständige Abschaffung klassischer Algorithmen bis 2030 gemäß NSA-Leitlinien.

Weiterführende Lektüre

Für eine tiefergehende Abdeckung der zugrunde liegenden Post-Quanten-Algorithmen und ihrer Verteidigungsimplikationen, siehe Post-Quanten-Kryptografie für die Verteidigung: CNSA 2.0-Leitfaden. Für die Schlüsselverwaltungs- und Secrets-Infrastruktur, die der PQC-Migration zugrunde liegt, siehe Secrets-Management in Verteidigungs-CI/CD-Pipelines: Vault, HSM und Schlüsselrotation. Für Zero-Trust-Architektur als ergänzende Sicherheitsschicht, siehe Zero-Trust-Architektur für Militärnetzwerke: Grundsätze und Implementierung.