Plan migracji post-quantum dla systemów krytycznych

Migracja post-quantum nie zaczyna się od wyboru algorytmu. Zaczyna się od ustalenia, gdzie organizacja używa kryptografii, jak długo dane muszą pozostać poufne i które produkty można w ogóle zmienić bez przerwania działania. Największym ryzykiem programu jest nie tyle brak pojedynczej biblioteki PQC, ile nieznane zależności, urządzenia bez ścieżki aktualizacji oraz protokoły, w których algorytm został zaszyty na stałe.

NIST zatwierdził FIPS 203, 204 i 205 13 sierpnia 2024 roku. Standardy obejmują ML-KEM do ustanawiania klucza oraz ML-DSA i SLH-DSA do podpisów. To wystarczający sygnał, by budować inwentaryzację, wymagania dla dostawców i kontrolowane wdrożenia. Nie trzeba znać daty powstania kryptograficznie istotnego komputera kwantowego, by usunąć architektoniczne blokady migracji.

Zbuduj inwentaryzację kryptografii z kontekstem

Lista certyfikatów TLS jest tylko fragmentem obrazu. Cryptography bill of materials powinien obejmować biblioteki, protokoły, certyfikaty, klucze, HSM, firmware, podpisy oprogramowania, archiwa, mechanizmy aktualizacji, kanały VPN, komunikację service-to-service oraz kryptografię warstwy aplikacyjnej. Każdy wpis potrzebuje właściciela, zastosowania, algorytmu, długości klucza, miejsca przechowywania, biblioteki lub urządzenia wykonującego operację i zależności zewnętrznych.

Inwentaryzacja powinna powstawać z kilku źródeł: skanów konfiguracji i kodu, telemetrii sieciowej, repozytoriów certyfikatów, katalogu usług oraz rozmów z właścicielami. Żadne z nich osobno nie jest kompletne. Wynik musi odróżniać kryptografię kontrolowaną przez organizację od tej dostarczanej przez chmurę, SaaS, system operacyjny lub sprzęt.

Każdy wpis powinien mieć także status pewności. Mechanizm wykryty w ruchu produkcyjnym daje inny dowód niż deklaracja właściciela, a biblioteka obecna w zależnościach nie musi być wykonywana. Niepewne rekordy trafiają do weryfikacji, zamiast znikać z raportu. Proces zmian powinien aktualizować inwentaryzację po dodaniu usługi, certyfikatu, biblioteki lub integracji. Jednorazowy arkusz zestarzeje się wcześniej niż program dotrze do najtrudniejszych urządzeń.

Ustal priorytet według horyzontu szkody

Nie wszystkie systemy wymagają tej samej kolejności. Dla poufności trzeba porównać oczekiwany czas ochrony danych z czasem potrzebnym na migrację i ryzykiem harvest-now-decrypt-later: napastnik może przechować zaszyfrowany ruch i próbować odszyfrować go w przyszłości. Dokument techniczny ważny przez kilka miesięcy ma inny profil niż dokumentacja medyczna, własność intelektualna czy materiały dotyczące infrastruktury.

Podpisy wymagają innej analizy. Istotne są okres ważności podpisanego artefaktu, możliwość ponownego podpisania, mechanizm aktualizacji klucza głównego i konsekwencje przyjęcia fałszywego firmware. Macierz priorytetów powinna uwzględniać trwałość danych, ekspozycję, krytyczność funkcji, gotowość dostawcy, trudność zmiany oraz możliwość bezpiecznego rollbacku.

Projektuj crypto-agility, nie jedną wymianę

NIST CSWP 39 Update 1 definiuje crypto-agility jako zdolność przyjęcia nowych algorytmów i wycofania podatnych bez zakłócenia działającego systemu. W praktyce oznacza to konfigurację algorytmów poza logiką biznesową, wersjonowanie formatów, negocjację możliwości, rotację kluczy oraz możliwość równoległego odczytu starszych danych w okresie przejściowym.

API kryptograficzne powinno ukrywać implementację, ale nie może ukrywać parametrów potrzebnych do audytu. Zespół musi wiedzieć, jaki algorytm faktycznie wykonał operację. Należy testować aktualizację polityki bez ponownego wdrażania całej aplikacji, a także zachowanie przy braku wspólnego zestawu algorytmów. Agile w nazwie nie oznacza dowolności: lista dozwolonych wariantów pozostaje kontrolowaną polityką bezpieczeństwa.

Dobierz wzorzec przejściowy do protokołu

Tryb hybrydowy, łączący mechanizm klasyczny i post-quantum, może ograniczyć ryzyko nowego algorytmu lub problemów interoperacyjności, ale nie jest uniwersalnym obowiązkiem. Zwiększa rozmiar wiadomości, złożoność negocjacji, wymagania dla bibliotek i liczbę możliwych stanów błędnych. Powinien wynikać z profilu protokołu, wymagań branżowych i analizy zagrożeń.

Pilotaż powinien mierzyć nie tylko poprawne szyfrowanie lub weryfikację podpisu. Potrzebne są testy latencji, przepustowości, rozmiaru certyfikatów i komunikatów, zużycia pamięci, zachowania po rotacji, kompatybilności pośredników oraz obsługi błędu. Warto zacząć od usługi, którą można odtworzyć w środowisku kontrolowanym i która ma znaczące, lecz ograniczone zależności.

Włącz PKI, kopie i urządzenia do programu

Migracja obejmuje cały cykl życia zaufania: generowanie, dystrybucję, walidację, rotację, unieważnienie i archiwizację. Zmiana algorytmu podpisu może wymagać nowych profili certyfikatów, aktualizacji validatorów, HSM, agentów i urządzeń brzegowych. Kopie zapasowe oraz długoterminowe archiwa trzeba sprawdzić pod kątem możliwości odczytu po wymianie komponentów.

Najtrudniejsze bywają systemy OT, sprzęt i produkty kupione z wieloletnim okresem wsparcia. Dla nich potrzebna jest decyzja: aktualizacja, warstwa pośrednia, izolacja, skrócenie okresu eksploatacji albo akceptacja ryzyka. Brak odpowiedzi dostawcy nie może kończyć oceny; staje się udokumentowaną luką wpływającą na zakupy i plan wymiany.

Zmień wymagania zakupowe i umowne

W zapytaniach do dostawców należy pytać o obsługiwane standardy, plan aktualizacji, zależności sprzętowe, interoperacyjność, mechanizm rollbacku i sposób dostarczenia dowodu testów. Ogólna deklaracja „quantum-ready” nie mówi, czy produkt implementuje zatwierdzony standard ani czy jego konfigurację można zmienić w istniejącym środowisku.

Wspólny dokument CISA, NSA i NIST o quantum readiness zaleca roadmapę, inwentaryzację, ocenę ryzyka i wczesne rozmowy z dostawcami. Umowy powinny zatem obejmować poprawki, telemetrię używanego wariantu, wsparcie migracji, termin wycofania algorytmów legacy oraz prawo do testów przed zmianą produkcyjną.

Zarządzaj falami, dowodami i rollbackiem

Każda fala migracji potrzebuje kryteriów wejścia i wyjścia. Przed wdrożeniem zespół potwierdza inwentaryzację, właściciela, zgodność bibliotek, plan kluczy, monitoring i rollback. Po wdrożeniu wykazuje, że ruch faktycznie używa oczekiwanego mechanizmu, błędy są widoczne, odtworzenie działa, a zależne systemy nie wróciły po cichu do słabszej konfiguracji.

Wyjątki muszą zawierać techniczną przyczynę, zastosowaną kompensację, właściciela oraz datę wygaśnięcia. Raport „procent systemów zgodnych z PQC” bez listy niewymienialnych komponentów może stworzyć fałszywe poczucie postępu. Lepszy obraz pokazuje, które funkcje pozostają narażone, dlaczego, jaki jest plan dostawcy i jaka decyzja inwestycyjna jest potrzebna.

Miary programu powinny obejmować pokrycie inwentaryzacją systemów krytycznych, udział zależności z potwierdzoną ścieżką aktualizacji, liczbę niewymienialnych komponentów, czas zmiany polityki kryptograficznej i wynik testów interoperacyjności. Wybrany przez NIST w marcu 2025 HQC ma być zapasowym KEM opartym na innej matematyce niż ML-KEM. NIST jednocześnie zalecił kontynuowanie migracji do standardów z 2024 roku, a nie oczekiwanie na finalizację HQC. Program powinien zachować możliwość kolejnej zmiany bez traktowania dzisiejszego wyboru jako ostatniego.

Źródła

• NIST: Approval of Three FIPS for Post-Quantum Cryptography
• CISA, NSA and NIST: Quantum-Readiness — Migration to Post-Quantum Cryptography
• NIST CSWP 39 Update 1: Considerations for Achieving Crypto Agility
• NIST Selects HQC as a Fifth Algorithm for Post-Quantum Encryption