We wrześniu 2022 roku Dyrekcja ds. Cyberbezpieczeństwa NSA opublikowała Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) — dyrektywę wymagającą, aby wszystkie Systemy Bezpieczeństwa Narodowego przeszły od klasycznej kryptografii klucza publicznego do algorytmów postkwantowych zgodnie z określonym harmonogramem. Dla organizacji obronnych nie jest to kwestia badawcza ani element przyszłego planowania: wymogi zamówień publicznych już uwzględniają kryteria gotowości do CNSA 2.0, a nowe systemy wdrażane od 2025 roku powinny obsługiwać wymagane algorytmy od pierwszego dnia.

Wyzwanie migracyjne jest znaczące. Klasyczna kryptografia klucza publicznego — RSA, kryptografia krzywych eliptycznych (ECC) i Diffie-Hellman — jest wbudowana w całą infrastrukturę IT sektora obronnego: punkty końcowe TLS, bramy VPN, urzędy certyfikacji PKI, systemy zarządzania kluczami, potoki podpisywania oprogramowania układowego i zaszyfrowane archiwa danych. Zastąpienie tych zależności w dużej organizacji to wieloletni program wymagający starannego sekwencjonowania, koordynacji z dostawcami i zarządzania ryzykiem w okresie, gdy systemy klasyczne i postkwantowe muszą współpracować.

Niniejszy artykuł przedstawia praktyczny plan migracji: czego wymaga CNSA 2.0, jakie algorytmy zastępują które, jak sekwencjonować przejście w organizacji obronnej i czego wymagać od dostawców systemów zgodnych z CNSA 2.0.

Czego wymaga CNSA 2.0 i dlaczego

Zagrożeniem kryptograficznym napędzającym CNSA 2.0 jest algorytm Shora — algorytm kwantowy, który uruchomiony na wystarczająco dużym komputerze kwantowym, łamie problemy matematyczne leżące u podstaw RSA (faktoryzacja liczb całkowitych), ECC (dyskretny logarytm krzywych eliptycznych) i Diffie-Hellmana (logarytm dyskretny). Komputer kwantowy zdolny do uruchomienia algorytmu Shora przeciwko 2048-bitowemu RSA lub 256-bitowemu ECC wymagałby milionów logicznych kubitów działających z niskim poziomem błędów. Taka zdolność nie istnieje dzisiaj, ale wiarygodne publiczne szacunki umieszczają „kryptograficznie istotny komputer kwantowy" (CRQC) gdzieś w przedziale lat 2030–2035.

Zagrożenie „zbieraj teraz, deszyfruj później" (HNDL) skraca ten harmonogram dla celów obronnych. Przeciwnicy gromadzący dziś zaszyfrowany ruch — komunikację strategiczną, raporty wywiadowcze, oceny zdolności — mogą go przechowywać i odszyfrować, gdy CRQC stanie się dostępny. Poufność danych zaszyfrowanych dziś klasycznymi algorytmami ma zatem efektywną datę wygaśnięcia skorelowaną z dostępnością CRQC. Dla danych z wymogami poufności mierzonymi w dekadach termin ten jest już bieżącym operacyjnym problemem.

CNSA 2.0 adresuje to przez nakazanie określonego zestawu algorytmów postkwantowych dla NSS, z harmonogramem przejścia zaprojektowanym tak, aby migracja zakończyła się przed dostępnością CRQC. Kluczowe nakazy:

  • ML-KEM (FIPS 203 / CRYSTALS-Kyber) — zastępuje RSA i ECDH we wszystkich zastosowaniach ustanawiania kluczy. CNSA 2.0 nakazuje ML-KEM-1024 (najwyższy zestaw parametrów bezpieczeństwa) dla aplikacji NSS.
  • ML-DSA (FIPS 204 / CRYSTALS-Dilithium) — zastępuje RSA-PSS i ECDSA w podpisach cyfrowych w większości aplikacji. Zapewnia szybkie podpisywanie i weryfikację przy rozsądnych rozmiarach klucza i podpisu.
  • SLH-DSA (FIPS 205 / SPHINCS+) — alternatywny algorytm podpisu oparty na funkcjach skrótu zamiast matematyki kratowej. Używany tam, gdzie wymagana jest różnorodność w stosunku do algorytmów opartych na kratach lub gdzie algorytmy kratowe nie są dozwolone. Podpisy są znacznie większe niż ML-DSA, ale bezpieczeństwo opiera się na dobrze zrozumianych właściwościach funkcji skrótu.
  • LMS i XMSS — stanowe schematy podpisu oparte na skrótach zatwierdzone do określonych przypadków użycia, szczególnie podpisywania oprogramowania układowego w środowiskach ograniczonych. Wymagają starannego zarządzania stanem, aby uniknąć ponownego użycia klucza.
  • AES-256 i SHA-384 — zachowane z CNSA 1.0 do szyfrowania symetrycznego i skrótowania; nie są zagrożone przez komputery kwantowe w praktycznej skali.

Przestarzałe algorytmy, które muszą być wycofane zgodnie z CNSA 2.0, obejmują: RSA (wszystkie rozmiary kluczy, wszystkie zastosowania), ECDH i ECDSA (wszystkie krzywe), Diffie-Hellman (klasyczny i krzywych eliptycznych) oraz SHA-256 dla aplikacji NSS (gdzie nakazany jest teraz SHA-384). AES-128 i AES-192 są również przestarzałe na rzecz AES-256 dla NSS.

Kluczowa obserwacja: Wiele zespołów IT w sektorze obronnym skupia się na terminie 2030 r. dla migracji istniejących systemów i pomija wymóg dotyczący nowych systemów z 2025 r. Od produktu oprogramowania lub platformy dostarczonej klientowi DoD po styczniu 2025 r. oczekuje się obsługi algorytmów CNSA 2.0. Produkty zbudowane wyłącznie na klasycznych bibliotekach kryptograficznych nie przejdą oceny zgodności z CNSA 2.0 w momencie dostawy, a nie w momencie materializacji zagrożenia kwantowego.

Zatwierdzone algorytmy w szczegółach

ML-KEM (Mechanism enkapsulacji klucza oparty na siatce modułowej) opiera się na trudności problemu Module Learning With Errors (MLWE) — problemu kratowego, który żaden znany algorytm kwantowy ani klasyczny nie rozwiązuje wydajnie. ML-KEM działa jako mechanizm enkapsulacji klucza: nadawca enkapsuluje wspólny sekret pod kluczem publicznym odbiorcy; odbiorca dekapsuluje, aby odzyskać wspólny sekret. Wspólny sekret inicjuje następnie symetryczną funkcję wyprowadzania klucza. ML-KEM-1024 produkuje klucze publiczne o rozmiarze 1568 bajtów, szyfrogramy o rozmiarze 1568 bajtów i wspólne sekrety o rozmiarze 32 bajtów — większe niż klucze RSA-2048 (256 bajtów), ale akceptowalne dla większości kontekstów protokołowych.

ML-DSA (Algorytm podpisu cyfrowego oparty na siatce modułowej) opiera się na trudności problemów Module Short Integer Solution (MSIS) i MLWE. ML-DSA-87 (najwyższy poziom bezpieczeństwa odpowiadający bezpieczeństwu AES-256) produkuje klucze publiczne o rozmiarze 2592 bajtów i podpisy o rozmiarze 4627 bajtów. Dla porównania ECDSA P-256 produkuje podpisy o rozmiarze 64 bajtów. Większe rozmiary podpisów wymagają dostosowania w protokołach i systemach przechowywania, które zakładały kompaktowe podpisy — łańcuchy certyfikatów, obrazy oprogramowania układowego i łącza ograniczone przepustowością wymagają planowania pojemności.

SLH-DSA (Bezstanowy algorytm podpisu cyfrowego oparty na skrótach) nie posiada struktury algebraicznej możliwej do wykorzystania przez algorytmy klasyczne ani kwantowe poza ogólnymi atakami na funkcje skrótu; jego bezpieczeństwo sprowadza się wyłącznie do odporności na kolizje bazowej funkcji skrótu. Kompromisem są wydajność i rozmiar: podpisy SLH-DSA-SHA2-256s mają 29 792 bajty przy najniższym zestawie parametrów, a podpisywanie jest o rzędy wielkości wolniejsze niż ML-DSA. SLH-DSA jest odpowiedni jako wtórny algorytm podpisu zapewniający różnorodność bezpieczeństwa, szczególnie do podpisywania oprogramowania układowego i programów, gdzie rozmiar podpisu i częstotliwość podpisywania są zarządzalne.

Cztery fazy migracji

Dobrze ustrukturyzowana migracja do CNSA 2.0 przebiega przez cztery fazy. Organizacje mogą jednocześnie znajdować się w różnych fazach dla różnych typów systemów — duża organizacja obronna będzie zazwyczaj miała migrację PKI w Fazie 2, podczas gdy taktyczne systemy brzegowe są jeszcze w Fazie 1.

Faza 1 — Inwentaryzacja kryptograficzna. Zanim można zaplanować jakiekolwiek prace migracyjne, organizacja musi wiedzieć, co posiada. Inwentaryzacja kryptograficzna obejmuje: każdy punkt końcowy TLS i jego wynegocjowane zestawy szyfrów; każdy certyfikat w użyciu (użytkownika, urządzenia, usługi, podpisywania kodu) wraz z algorytmem klucza i datą wygaśnięcia; każdą bramę VPN i konfigurację wymiany kluczy IKEv2; każdy system zarządzania kluczami, HSM i token kryptograficzny; każdy potok podpisywania oprogramowania układowego i typ klucza podpisywania; oraz każde archiwum danych, gdzie wymagana jest długoterminowa poufność i algorytm klucza szyfrowania.

Zautomatyzowane narzędzia pomagają — skanery TLS (SSLyze, testssl.sh), analiza SBOM dla zależności bibliotek kryptograficznych i platformy zarządzania certyfikatami z raportowaniem algorytmów. Jednak zautomatyzowane narzędzia pomijają niestandardowe implementacje protokołów, kryptografię oprogramowania układowego wbudowanego i kryptografię warstwy aplikacji poza standardowymi bibliotekami. Do kompletności wymagany jest ręczny przegląd dokumentacji architektury i kodu źródłowego.

Faza 2 — Priorytetyzacja oparta na ryzyku. Nie wszystkie zależności kryptograficzne niosą równe ryzyko HNDL. Priorytetyzacja powinna odzwierciedlać dwa wymiary: długowieczność i wrażliwość chronionych danych oraz wykonalność migracji w krótkim terminie. Cele o wysokim priorytecie to systemy chroniące długotrwałe niejawne dane, gdzie narażenie na HNDL jest największe: główne i wystawiające CA PKI (których klucze chronią kotwicę zaufania dla całej organizacji), infrastruktura zarządzania kluczami (HSM przechowujące klucze główne dla zaszyfrowanych archiwów), strategiczne łącza komunikacyjne i wszelkie systemy szyfrujące dane z wymogiem poufności przekraczającym pięć lat.

Niższy priorytet — ale nadal wymagany przed 2030 rokiem — mają systemy z częstymi cyklami wymiany sprzętu (platformy taktyczne, urządzenia końcowe), gdzie zdolność PQC można wbudować przy następnej naturalnej wymianie, oraz systemy wewnętrzne chroniące niesklasyfikowane dane, gdzie ryzyko kwantowe jest niższe.

Faza 3 — Operacja hybrydowa. Podczas migracji systemy będą współdziałać zarówno z odpowiednikami CNSA 1.0 (klasycznymi), jak i CNSA 2.0 (postkwantowymi). Kryptografia hybrydowa — łącząca klasyczne i postkwantowe algorytmy w tej samej wymianie protokołu — zapewnia odporność kwantową w bieżącym ruchu bez wymagania, aby wszystkie punkty końcowe jednocześnie obsługiwały algorytmy postkwantowe.

W hybrydowym połączeniu TLS 1.3 klient uwzględnia zarówno udostępnianie kluczy ECDHE, jak i ML-KEM w ClientHello; serwer odpowiada na oba. Końcowy klucz sesji jest wyprowadzany z obu wspólnych sekretów przy użyciu funkcji wyprowadzania klucza. Przeciwnik musi złamać zarówno klasyczny, jak i postkwantowy algorytm, aby skompromitować sesję. To podejście „pasa i szelek" jest wyraźnie popierane przez NSA na okres przejściowy.

Kluczowa obserwacja: Operacja hybrydowa to nie tylko tymczasowa wygoda — jest to dyscyplina zarządzania ryzykiem. Dopóki algorytmy postkwantowe nie zgromadzą lat kryptoanalizy porównywalnej z RSA i ECC, uruchamianie ich obok klasycznych algorytmów zapewnia, że nieprzewidziany postęp kryptanalityczny w matematyce kratowej nie skompromituje natychmiast wszystkich chronionych komunikacji.

Faza 4 — Pełne przejście. Gdy wszystkie systemy obsługują algorytmy postkwantowe i operacja hybrydowa okazała się stabilna w produkcji, zestawy szyfrów tylko klasycznych i typy certyfikatów są wycofywane. Wycofanie musi być skoordynowane ze wszystkimi współpracującymi organizacjami, dostawcami i krajami partnerskimi. Ustanów monitorowanie w celu wykrycia wszelkich pozostałych negocjacji algorytmów klasycznych (co wskazywałoby na system pominięty w inwentaryzacji lub na to, że dostawca nie dostarczył jeszcze oprogramowania zgodnego z CNSA 2.0) i śledź kamienie milowe wycofywania w stosunku do terminu 2030.

Systemy o wysokim priorytecie i sekwencjonowanie migracji

W priorytetowym zaległości migracyjnych, pewne typy systemów pojawiają się konsekwentnie jako o wysokim priorytecie praktycznie we wszystkich organizacjach obronnych i powinny być sekwencjonowane wcześnie niezależnie od specyfiki organizacyjnej.

Infrastruktura zarządzania kluczami. HSM i usługi zarządzania kluczami (KMS) są zależnościami dla migracji prawie każdego innego systemu — klucze postkwantowe muszą być gdzieś generowane, przechowywane i zarządzane. Aktualizacja oprogramowania układowego HSM do obsługi operacji ML-KEM i ML-DSA oraz weryfikacja, że API zarządzania kluczami udostępnia typy kluczy postkwantowych aplikacjom konsumenckim, to praca Fazy 1–2 w każdym programie migracyjnym. Jest to również miejsce, gdzie zaangażowanie dostawców jest najbardziej krytyczne: dostawcy HSM znacznie się różnią w swoich planach PQC, a niektóre generacje sprzętu nie mogą być aktualizowane na miejscu.

Główne i wystawiające CA PKI. Hierarchia zaufania PKI stanowi podstawę uwierzytelniania opartego na certyfikatach w całej organizacji. Ustanowienie postkwantowych głównych CA — i dystrybucja ich kotwic zaufania do wszystkich stron ufających (przeglądarek, systemów operacyjnych, klientów TLS, walidatorów OCSP) — jest warunkiem wstępnym wydawania postkwantowych certyfikatów dla dowolnego systemu. Musi to nastąpić zanim postkwantowe certyfikaty będą mogły być wdrożone w innym miejscu. Model podwójnego wystawiania, gdzie ten sam CA wydaje zarówno klasyczne, jak i postkwantowe certyfikaty dla każdego podmiotu, umożliwia stopniową migrację stron ufających bez naruszania istniejących relacji zaufania.

Bramy VPN i zaszyfrowane platformy komunikacyjne. Bramy VPN chroniące niejawne obwody sieciowe są głównymi celami HNDL. IKEv2, protokół wymiany kluczy używany w większości korporacyjnych rozwiązań VPN, musi zostać zaktualizowany do negocjowania ML-KEM w celu ustanowienia kluczy i ML-DSA do uwierzytelniania. Większość korporacyjnych dostawców VPN (Cisco, Palo Alto, Juniper, Check Point) ma elementy planu PQC, ale dostępność funkcji i zgodność parametrów CNSA 2.0 znacznie się różnią — jest to krytyczne pytanie kwalifikacyjne dostawcy przy zamówieniach.

Zaszyfrowane platformy komunikacyjne i przesyłania wiadomości. Systemy używane do strategicznej komunikacji dowodzenia, rozpowszechniania informacji wywiadowczych i koordynacji o znaczeniu krytycznym dla misji są celami o wysokim priorytecie, ponieważ wrażliwość i długowieczność ruchu jest wysoka. Corvus.Quantum, platforma przesyłania strumieniowego Corvus Intelligence dla sektora obronnego, jest zaprojektowana z myślą o zgodności z CNSA 2.0 — włączając ML-KEM do ustanawiania kluczy i ML-DSA do podpisywania wiadomości w swojej architekturze przesyłania strumieniowego i przesyłania wiadomości, obsługując operację hybrydową podczas okresu przejściowego.

Potoki podpisywania oprogramowania układowego. Systemy uzbrojenia i wojskowe platformy sprzętowe używają podpisów cyfrowych do weryfikacji integralności oprogramowania układowego. Podpisy te mają długi żywot — klucz podpisywania może obejmować cały cykl produkcyjny platformy, obejmując dekadę lub więcej — i dlatego są bezpośrednio narażone na ryzyko HNDL. Nowe platformy wchodzące do produkcji powinny być dostarczane z podpisywaniem oprogramowania układowego ML-DSA lub SLH-DSA od pierwszej dostawy. Platformy w eksploatacji wymagają kampanii ponownego podpisywania obrazów oprogramowania układowego tam, gdzie architektura rozruchu obsługuje rotację kluczy; platformy, gdzie klucze podpisywania są wbudowane przy produkcji, wymagają wyraźnej dokumentacji ryzyka.

Kluczowa obserwacja: Rotacja kluczy podpisywania oprogramowania układowego jest często architektonicznie niemożliwa dla wdrożonych platform bez wymiany sprzętu. Właściwą odpowiedzią nie jest odkładanie problemu, ale wyraźne udokumentowanie go w rejestrze ryzyka platformy, przypisanie właściciela ryzyka rezydualnego i zbudowanie harmonogramu wymiany sprzętu zamykającego lukę. Nieudokumentowany kryptograficzny dług techniczny jest najbardziej niebezpiecznym rodzajem.

Jak zinwentaryzować zależności kryptograficzne

Inwentaryzacja kryptograficzna jest konsekwentnie najbardziej niedocenianą fazą programów migracji PQC. Organizacje rozpoczynające migrację przy założeniu, że inwentaryzacja zajmie tygodnie, zazwyczaj odkrywają, że wymaga miesięcy, ponieważ kryptografia jest wdrożona na więcej warstwach systemowych i więcej ścieżkach kodu niż jakikolwiek pojedynczy zespół ma pełną widoczność.

Kompleksowa strategia inwentaryzacji łączy cztery podejścia. Po pierwsze, wykrywanie w warstwie sieciowej: pasywna analiza ruchu TLS i aktywne skanowanie wszystkich osiągalnych punktów końcowych przy użyciu narzędzi, które fingerprintują wynegocjowane zestawy szyfrów i algorytmy kluczy certyfikatów. Obejmuje to serwery WWW, punkty końcowe API, load balancery i komunikację sieciową usług korzystającą ze standardowego TLS. Po drugie, wyliczenie platformy zarządzania certyfikatami: odpytywanie hierarchii CA organizacji i wszelkich publicznych logów CT (Certificate Transparency) o certyfikaty zawierające nazwy organizacji, wyodrębnianie algorytmu klucza i daty wygaśnięcia dla każdego. Po trzecie, analiza SBOM: wyodrębnianie Software Bill of Materials z wdrożonych aplikacji i skanowanie pod kątem zależności bibliotek kryptograficznych (OpenSSL, BoringSSL, libgcrypt, NSS, dostawcy kryptografii Java) i ich wersji. Wersje bibliotek kryptograficznych określają, które algorytmy są dostępne i które są domyślne. Po czwarte, przegląd dokumentacji architektury: identyfikacja niestandardowych implementacji protokołów, wyprowadzania kluczy w procesie, zaszyfrowanych kolumn baz danych i kryptografii warstwy aplikacji, których skanowanie sieciowe nie może obserwować.

Wynikiem inwentaryzacji powinien być ustrukturyzowany rejestr zawierający co najmniej: nazwę systemu, typ zależności kryptograficznej (TLS, certyfikat, KEM, podpis, symetryczny), algorytm i rozmiar klucza, bibliotekę lub implementację, klasyfikację danych chronionych oraz szacowaną złożoność migracji. Rejestr ten napędza priorytetyzację Fazy 2 i stanowi punkt wyjścia do śledzenia postępów zgodności.

Pytania do dostawców podczas zamówień

Organizacje obronne zamawiające oprogramowanie i sprzęt komercyjny muszą ocenić gotowość do CNSA 2.0 jako część zamówień. Poniższe pytania odróżniają dostawców z rzeczywistą zdolnością PQC od tych z obietnicami w planach działania:

Szczegóły obsługi algorytmów. „Czy Twój produkt obsługuje ML-KEM-1024, ML-DSA-87 i SLH-DSA-SHA2-256s zgodnie z definicją w FIPS 203, 204 i 205?" Dostawcy, którzy odpowiadają ogólnymi twierdzeniami o „obsłudze postkwantowej" bez konkretnych oznaczeń FIPS i poziomów parametrów, prawdopodobnie nie spełnią konkretnych wymagań CNSA 2.0. Obsługa algorytmów na niższych poziomach parametrów (ML-KEM-512, ML-DSA-44) nie spełnia nakazanych przez CNSA 2.0 poziomów bezpieczeństwa dla NSS.

Dostępność hybrydowych zestawów szyfrów. „Czy Twoja implementacja TLS obsługuje hybrydową wymianę kluczy ML-KEM + ECDHE w jednym uzgadnianiu?" Obsługa hybrydowa umożliwia organizacji czerpanie korzyści z odporności kwantowej w istniejącym ruchu bez wymagania, aby wszystkie współpracujące strony jednocześnie zakończyły migrację PQC.

Dostosowanie rozmiaru klucza. „W jaki sposób Twój system obsługuje większe rozmiary kluczy i podpisów algorytmów postkwantowych?" Podpisy ML-DSA-87 mają około 4,6 KB w porównaniu z 64 bajtami ECDSA P-256. Systemy z buforami certyfikatów lub podpisów o stałym rozmiarze, schematami baz danych ze stałymi długościami pól kryptograficznych lub protokołami sieciowymi ze ścisłymi założeniami MTU mogą wymagać zmian architektonicznych do uwzględnienia materiału klucza PQC.

Pochodzenie biblioteki kryptograficznej. „Która biblioteka kryptograficzna leży u podstaw Twojej implementacji PQC i jaki jest cykl aktualizacji wersji?" Implementacje postkwantowe w OpenSSL, BoringSSL i Bouncy Castle nadal dojrzewają; cykl aktualizacji dostawcy określa, jak szybko łatki bezpieczeństwa docierają do wdrożonych produktów.

Plan działania po 2030 roku. „Jaki jest Twój plan czystej operacji PQC po 2030 roku, gdy tryb hybrydowy i algorytmy klasyczne zostaną wycofane?" Dostawcy bez konkretnego planu działania po 2030 roku stanowią ryzyko zgodności, które będzie wymagało zarządzanych przejść w najgorszym możliwym czasie — gdy termin jest bliski.

Sześcioetapowy proces planowania migracji do CNSA 2.0

Poniższe kroki destylują powyższe fazy migracji w wykonalną sekwencję planowania dla zespołów IT i bezpieczeństwa sektora obronnego rozpoczynających program zgodności z CNSA 2.0.

Krok 1 — Przeprowadź inwentaryzację kryptograficzną. Wdróż skanowanie TLS, raportowanie zarządzania certyfikatami, analizę SBOM i przegląd dokumentacji architektury we wszystkich systemach. Utwórz ustrukturyzowany rejestr każdej zależności kryptograficznej: typ, algorytm, rozmiar klucza, biblioteka, klasyfikacja danych i szacowana złożoność migracji. Oczekuj, że ten krok zajmie 2–6 miesięcy dla średniej lub dużej organizacji obronnej. Nie przystępuj do planowania bez stosunkowo kompletnej inwentaryzacji — plany migracji zbudowane na częściowej inwentaryzacji pominą systemy o wysokim priorytecie.

Krok 2 — Oceń ryzyko i nadaj priorytet systemom. Oceń każdy element inwentaryzacji na dwóch osiach: ryzyko HNDL (wrażliwość i długowieczność chronionych danych) oraz wykonalność migracji (zdolność zespołu, gotowość dostawcy, złożoność architektoniczna). Utwórz priorytetowe zaległości migracyjne z szacowanym nakładem pracy, zależnościami między elementami i przypisaniem właściciela. Elementy chroniące długotrwałe niejawne dane o niskiej złożoności migracji powinny być na górze niezależnie od polityki organizacyjnej.

Krok 3 — Najpierw zaktualizuj infrastrukturę zarządzania kluczami i PKI. Zmigruj HSM do oprogramowania układowego zgodnego z CNSA 2.0. Wydaj postkwantowe certyfikaty głównego CA. Ustanów zdolność podwójnego wystawiania. Dystrybuuj zaktualizowane kotwice zaufania do stron ufających. Ta faza jest zależnością dla wszystkich kolejnych migracji opartych na certyfikatach i powinna być zasilona zasobami i uruchomiona natychmiast po zakończeniu inwentaryzacji.

Krok 4 — Wdróż hybrydowe zestawy szyfrów na ścieżkach sieciowych o wysokim priorytecie. Włącz hybrydowe zestawy szyfrów ML-KEM na bramach VPN, niejawnych obwodach sieciowych i platformach komunikacyjnych. Ten krok zapewnia natychmiastowe zmniejszenie ryzyka HNDL w bieżącym ruchu bez wymagania pełnej gotowości PQC we wszystkich punktach końcowych. Monitoruj wskaźniki negocjacji w celu śledzenia adopcji.

Krok 5 — Zmigruj podpisywanie oprogramowania układowego i łańcuch dostaw oprogramowania. Przejdź na klucze ML-DSA lub SLH-DSA do podpisywania oprogramowania układowego dla wszystkich platform wchodzących do produkcji. Przeprowadź kampanie ponownego podpisywania dla platform w eksploatacji tam, gdzie jest to architektonicznie wykonalne. Zaktualizuj potoki podpisywania kodu CI/CD. Udokumentuj ograniczone platformy jako zarządzany kryptograficzny dług techniczny z wyraźną akceptacją ryzyka.

Krok 6 — Wykonaj pełne przejście i wycofaj klasyczne algorytmy. Gdy wszystkie systemy o wysokim priorytecie obsługują algorytmy postkwantowe i operacja hybrydowa jest stabilna, zacznij wycofywać zestawy szyfrów tylko klasycznych i typy certyfikatów zgodnie ze skoordynowanym harmonogramem ze współpracującymi organizacjami. Ustanów pulpit zgodności. Cel: pełne wycofanie klasycznych algorytmów do 2030 roku zgodnie z wytycznymi NSA.

Aby zapoznać się z głębszym omówieniem bazowych algorytmów postkwantowych i ich implikacji dla obronności, zob. Kryptografia postkwantowa dla obronności: przewodnik po CNSA 2.0. W kwestii infrastruktury zarządzania kluczami i sekretami stanowiącej podstawę migracji PQC zob. Zarządzanie sekretami w potokach CI/CD sektora obronnego: Vault, HSM i rotacja kluczy. Jako uzupełniającą warstwę bezpieczeństwa zob. architekturę zero-trust: Architektura zero-trust dla sieci wojskowych: zasady i implementacja.