Crypto-agility: projektowanie systemów obronnych do wymiany algorytmów

Większość systemów obronnych nie ulega awarii dlatego, że ich kryptografia była słaba w momencie wdrożenia. Ulegają awarii, ponieważ kryptografia pozostawała niezmieniona, podczas gdy świat się zmieniał. Algorytm, który był solidny w momencie wdrożenia, staje się przestarzały, następnie odradzany, a potem zakazany — a system, który go zakodował na stałe, wymaga teraz wieloletniego, wielodostawczego programu inżynierskiego, by zmienić jeden prymityw. Crypto-agility to dyscyplina budowania systemów tak, aby wymiana algorytmu była zadaniem konfiguracyjnym i wdrożeniowym, a nie przeprojektowaniem. Ponieważ migracja do kryptografii postkwantowej jest teraz stałym wymogiem dla danych obronnych o długim czasie życia, zwinność nie jest już udoskonaleniem — jest warunkiem wstępnym przetrwania następnego przejścia bez ponownego wdrożenia systemu.

Czym naprawdę jest crypto-agility

Crypto-agility to właściwość systemu, która pozwala mu zmieniać algorytmy, rozmiary kluczy i protokoły bez przebudowy zależnej od nich aplikacji. Test jest prosty: ile czasu i ile linii kodu zajmuje zastąpienie jednego algorytmu innym? W systemie nieelastycznym odpowiedź brzmi „otwieramy projekt ponownie", ponieważ nazwa algorytmu, długość klucza i zestaw parametrów są rozsiane po logice aplikacji, formatach serializacji, szablonach certyfikatów i procedurach obsługi protokołów. W systemie elastycznym odpowiedź brzmi „zmieniamy politykę", ponieważ każda z tych decyzji została wyeksternalizowana do konfiguracji w momencie budowania systemu.

Zwinność nie jest tym samym co posiadanie dobrej biblioteki kryptograficznej. Program może korzystać z najlepiej recenzowanej dostępnej biblioteki i nadal być całkowicie sztywny, ponieważ aplikacja wywołuje konkretną funkcję — RSA_sign, nazwaną krzywą, stały skrót — bezpośrednio z kodu biznesowego. Możliwość wymiany biblioteki nie pomaga, jeśli miejsca wywołań nie są wymienne. Zwinność jest właściwością architektoniczną całego systemu, a nie cechą jednej zależności.

Dlaczego systemy obronne potrzebują tego teraz

W zamówieniach obronnych zderzają się dwie osie czasu. Pierwsza to okres eksploatacji platformy. Pojazd bojowy, rodzina radiostacji lub zestaw systemów dowodzenia i kontroli ma działać przez dwadzieścia do czterdziestu lat. W tym czasie standardy kryptograficzne zmienią się kilkakrotnie — przejście od SHA-1, deprecacja 1024-bitowego RSA i przejście na uwierzytelnione szyfrowanie nastąpiły w ciągu jednego pokolenia platformy. Każdy algorytm wbudowany w system dziś będzie przestarzały na długo przed wycofaniem sprzętu.

Druga oś czasu to zagrożenie kwantowe. Kryptograficznie istotny komputer kwantowy złamałby kryptografię RSA i krzywych eliptycznych, a strategia „zbieraj teraz, odszyfruj później" oznacza, że przeciwnicy mogą przechwytywać dzisiejszy zaszyfrowany ruch i przechowywać go do czasu, aż taka maszyna powstanie. Dane obronne z wielodekadowymi wymaganiami dotyczącymi poufności są zatem już narażone, choć komputer kwantowy jeszcze nie istnieje. Odpowiedź normalizacyjna — CNSA 2.0 i zestaw postkwantowy NIST — wyznacza sztywne terminy migracji. System bez zwinności nie może dotrzymać tych terminów bez ponownego opracowania inżynierskiego, którego harmonogram nie przewiduje. Analizę modelu zagrożeń i osi czasu leżących u podstaw tego zagadnienia znajdziesz w naszej analizie zagrożenia ze strony komputerów kwantowych dla łączności obronnej.

Zacznij od inwentaryzacji kryptograficznej

Nie można migrować tego, czego nie widać, i nie można uniezależnić od algorytmów tego, czego się nie zlokalizowało. Pierwszym produktem każdego programu crypto-agility jest inwentaryzacja kryptograficzna — coraz częściej formalizowana jako kryptograficzny wykaz materiałów, czyli CBOM. Jest to kompletny katalog każdego miejsca, w którym system używa kryptografii: każdego algorytmu i trybu, każdej długości klucza, każdego certyfikatu i jego wystawcy, wersji protokołów negocjowanych na każdym interfejsie, bibliotek implementujących prymitywy, a przede wszystkim — danych, które każda instancja chroni i jak długo muszą pozostać poufne.

Inwentaryzacja prawie zawsze przynosi więcej niespodzianek, niż program się spodziewa. Kryptografia ukrywa się w oprogramowaniu układowym, do którego nikt nie ma źródeł, w binarnych bibliotekach stron trzecich o nieudokumentowanych wyborach algorytmów, w sprzętowych modułach bezpieczeństwa o stałych możliwościach i w domyślnych ustawieniach protokołów negocjowanych w czasie wykonywania, a nie wybieranych na etapie projektowania. Użyteczna inwentaryzacja rejestruje pewność odkrycia i właściciela dla każdego wpisu, odróżniając „odczytaliśmy to w źródle" od „zaobserwowaliśmy to w sieci" od „poinformował nas dostawca". Musi być żywym artefaktem regenerowanym przez potok budowania, a nie jednorazowym audytem, który staje się nieaktualny dzień po opublikowaniu.

Od inwentaryzacji do priorytetu ryzyka

Inwentaryzacja to nie tylko mapa — jest wejściem do ustalania priorytetów. Dwa atrybuty decydują o kolejności migracji: czas życia poufności chronionych danych oraz narażenie kanału. Dane, które muszą pozostać tajne przez trzydzieści lat i przechodzą przez zewnętrzne łącze, migrujemy jako pierwsze, ponieważ dokładnie na nie celuje strategia „zbieraj teraz, odszyfruj później". Dane krótkotrwałe w wewnętrznym, fizycznie chronionym segmencie mogą poczekać. Bez inwentaryzacji taki triaż jest niemożliwy, a program albo migruje wszystko jednocześnie (co jest niewykonalne finansowo), albo migruje najprostsze rzeczy jako pierwsze (co pozostawia dane o najwyższym ryzyku narażone najdłużej).

Warstwa abstrakcji algorytmów

Strukturalnym rdzeniem elastycznego systemu jest warstwa abstrakcji algorytmów — dostawca kryptograficzny lub interfejs usługi, który leży między kodem aplikacji a konkretnymi implementacjami. Kod aplikacji nigdy nie podaje nazwy algorytmu. Zamiast tego wyraża intencję: „podpisz tę wiadomość", „ustal klucz sesji z tym węzłem", „zaszyfruj ten rekord w spoczynku". Obok intencji odwołuje się do nazwanej polityki — na przykład signing.c2-link.v3 — a warstwa abstrakcji rozwiązuje tę politykę do konkretnego algorytmu, długości klucza i zestawu parametrów w czasie wykonywania.

Zysk polega na tym, że wymiana algorytmu staje się edycją polityki. Zmiana signing.c2-link.v3 z podpisu krzywej eliptycznej na podpis postkwantowy to zmiana konfiguracji wdrażana per środowisko, bez edycji kodu wywołującego i bez ponownej kompilacji aplikacji wysyłającej żądanie podpisu. Ta sama pośredniość pozwala programowi uruchamiać różne algorytmy w różnych teatrach operacyjnych lub dla różnych poziomów tajności z jednego pliku binarnego, a także przeprowadzać etapową migrację — stara polityka na produkcji, nowa polityka na testach — bez rozwidlania bazy kodu.

Właściwe zaprojektowanie interfejsu ma znaczenie. Powinien być na tyle abstrakcyjny, żeby deweloperzy aplikacji nie mogli go przypadkowo ominąć (bez furtki „daj mi surowy klucz AES", która ponownie zakodowuje wybór na stałe), i powinien eksponować metadane algorytmu, by wywołujący mogli rejestrować, która polityka została zastosowana. HSM, magazyn kluczy i mechanizmy rotacji żyją za tą warstwą; w kwestii operacyjnej strony tej tematyki — zapoznaj się z naszym przewodnikiem po zarządzaniu sekretami w potokach CI/CD dla obronności.

Wersjonowanie protokołów, certyfikatów i przechowywanych danych

Zwinność w miejscu wywołania jest konieczna, ale niewystarczająca. Artefakty kryptograficzne przeżywają moment ich tworzenia — rekord zaszyfrowany dziś może być odszyfrowywany za piętnaście lat, certyfikat wystawiony teraz jest weryfikowany przez węzły przez cały okres ważności, a sesja protokołu jest negocjowana między dwoma systemami o różnych harmonogramach aktualizacji. Każdy z nich musi zawierać wystarczające metadane, aby przetrwać zmianę algorytmu.

Protokoły. Formaty przesyłane przez sieć muszą zawierać jawne identyfikatory algorytmów i pola wersji, aby dwa węzły mogły wynegocjować wspólny algorytm, a nie zakładać konkretny. Protokół, który zakodowuje na stałe „podpis to ECDSA-P384", nie może być uaktualniony bez jednoczesnego złamania wszystkich wdrożonych węzłów — dzień zmiany, który jest operacyjnie niemożliwy w przypadku sił w terenie. Protokół, który negocjuje „obsługuję te zestawy algorytmów, ty obsługujesz tamte, zgadzamy się na najsilniejszy wspólny", uaktualnia się sprawnie w miarę jak węzły migrują we własnym tempie.

Certyfikaty. Profile certyfikatów muszą uwzględniać nowe identyfikatory algorytmów podpisu i kapsułkowania kluczy, a ścieżka walidacji nie może odrzucać nieznanego, ale zatwierdzonego polityką algorytmu. Sama infrastruktura klucza publicznego potrzebuje elastycznego korzenia: jeśli urząd certyfikacji może wydawać certyfikaty tylko jednego algorytmu, PKI staje się wąskim gardłem niezależnie od tego, jak elastyczne są węzły końcowe.

Przechowywane dane. Każdy zaszyfrowany rekord lub podpisany obiekt musi rejestrować, który algorytm i klucz go chronił. Bez tego znacznika przyszły system nie może odszyfrować ani zweryfikować danych archiwalnych po zmianie aktywnego algorytmu — dane stają się nieczytelne nie dlatego, że klucz zaginął, ale dlatego, że system zapomniał, jakiego schematu użył. Te metadane sprawiają, że migracja jest odwracalna i pozwalają na współistnienie starego i nowego szyfrogramu podczas przejścia.

Etapowy plan migracji

Mając inwentaryzację, warstwę abstrakcji i wersjonowane artefakty na miejscu, sama migracja staje się kontrolowaną, odwracalną sekwencją, a nie dniem zmiany. Wykonalny plan przebiega w pięciu fazach.

Faza 1 — inwentaryzacja. Zbuduj i zautomatyzuj CBOM, a wpisy posortuj według czasu życia poufności i narażenia. Ta faza tworzy zaległości migracyjne i ujawnia zależności, które w przeciwnym razie spowodowałyby awarie w terenie.

Faza 2 — abstrakcja. Wprowadź warstwę abstrakcji algorytmów i przekieruj przez nią każde istniejące wywołanie kryptograficzne. Żadna logika aplikacji nie powinna wywoływać algorytmu bezpośrednio. Na końcu tej fazy system nie jest bezpieczniejszy niż wcześniej, ale jest teraz zmienny — co jest warunkiem wstępnym wszystkiego, co nastąpi.

Faza 3 — tryby hybrydowe. Skonfiguruj warstwę do równoległego uruchamiania algorytmu klasycznego i postkwantowego — na przykład hybrydowego ustalania klucza łączącego wymianę krzywych eliptycznych z mechanizmem kapsułkowania klucza opartym na sieciach. Połączona konstrukcja pozostaje bezpieczna, jeśli którykolwiek komponent zostanie później złamany, co zabezpiecza zarówno przed kwantowym złamaniem algorytmu klasycznego, jak i nieprzewidzianą słabością nowszego postkwantowego. Wdrażaj tryby hybrydowe per środowisko za polityką, walidując interoperacyjność z systemami sojuszniczymi i regulowanymi przez STANAG przed zmianą jakiegokolwiek ustawienia domyślnego.

Faza 4 — priorytetowa migracja. Korzystając z porządku ryzyka w inwentaryzacji, najpierw migruj dane o długim okresie poufności i narażone zewnętrznie, a następnie schodź do danych wewnętrznych o krótkim czasie życia. Mierz pokrycie względem CBOM na każdym kroku, aby program mógł dokładnie raportować, jaka część danych wysokiego ryzyka jest chroniona kryptografią postkwantową. Szczegółowe sekwencjonowanie zgodności dla tej fazy jest przedstawione w mapie drogowej migracji CNSA 2.0.

Faza 5 — wycofanie. Usuwaj algorytm wyłącznie klasyczny dopiero po ponownym zaszyfrowaniu lub ponownym wygenerowaniu kluczy dla każdego zależnego węzła i każdej ścieżki przechowywanych danych zgodnie z nową polityką — co inwentaryzacja i znaczniki przechowywanych danych pozwalają zweryfikować, a nie zakładać. Wycofanie jest ostatnim krokiem dokładnie dlatego, że jest jedynym nieodwracalnym; wszystko wcześniej można cofnąć, jeśli interoperacyjność lub wydajność się pogorszy.

Typowe błędy

Trzy błędy powtarzają się w programach. Pierwszym jest traktowanie zwinności jak wymiany biblioteki — podłączenie biblioteki obsługującej postkwantowe przy jednoczesnym pozostawieniu bezpośrednich wywołań algorytmów w kodzie aplikacji, co daje system tak samo nieelastyczny jak poprzednio. Drugim jest migracja przed inwentaryzacją, co gwarantuje pominięte zależności ujawniające się jako awarie w terenie, gdy niekatalogowany węzeł lub komponent oprogramowania układowego nie może wynegocjować nowego algorytmu. Trzecim jest zbyt wczesne usunięcie starego algorytmu, zanim wszystkie przechowywane rekordy i wszystkie węzły zostaną zmigrowane, co sprawia, że dane archiwalne stają się niemożliwe do zweryfikowania lub odczytu. Każdemu z tych błędów zapobiega ta sama dyscyplina: najpierw inwentaryzacja, abstrakcja przed migracją i wycofanie na końcu.

Co to oznacza dla zamówień

Crypto-agility jest najtańsza, gdy jest wymagana przy udzielaniu zamówienia, i najdroższa, gdy jest retrofitowana do systemu w terenie. Programy specyfikujące nowe oprogramowanie obronne powinny wymagać warstwy abstrakcji algorytmów, utrzymywanego kryptograficznego wykazu materiałów i wersjonowanych artefaktów kryptograficznych jako kryteriów odbioru — nie jako przyszłych udoskonaleń. Systemy projektowane dziś przeżyją przejście postkwantowe i co najmniej jedno kolejne. Budowanie ich tak, aby tanio wymieniały algorytmy, to różnica między zmianą konfiguracji a programem ponownego wdrożenia.