Szyfrowanie post-kwantowe dla wojskowych strumieni wideo i audio

Operator drona prowadzi misję rozpoznawczą nad spornym terenem. Strumień wideo H.264 przesyłany jest przez łącze satelitarne, zaszyfrowany z DTLS/SRTP przy użyciu wymiany kluczy ECDHE. Na ziemi przeciwnik przechwytuje i przechowuje szyfrogramy — nie po to, by odszyfrować je dzisiaj, lecz by odszyfrować je w 2032 roku, gdy dostępny stanie się kryptograficznie istotny komputer kwantowy. Do tego czasu nagrania ujawnią luki w pokryciu sensorów, geometrię namierzania i wzorce patroli sił przyjaznych. Wartość wywiadowcza przechowywanego wideo nie maleje wraz z latami spędzonymi w zaszyfrowanej formie.

To jest problem „zbierz teraz, odszyfruj później" (HNDL) zastosowany do wojskowego wideo w czasie rzeczywistym. To nie jest scenariusz hipotetyczny. Przeciwnicy rozumiejący harmonogram kwantowy już teraz zbierają i archiwizują zaszyfrowane kanały ISR, wideo z dronów i ruch głosowy dowodzenia. Właściwą odpowiedzią nie jest czekanie na pojawienie się komputerów kwantowych przed migracją do kryptografii post-kwantowej — okno na ochronę danych w tranzycie jest teraz, zanim dojdzie do zbierania.

Dlaczego wideo z dronów i ISR jest najcenniejszym celem HNDL

Wywiad komunikacyjny (COMINT) ma oczywistą wartość HNDL, ale wideo ISR niesie inną klasę informacji. Pojedyncze nagranie z drona z jednej misji może ujawnić: dokładne pola widzenia sensorów (a więc martwe pola), precyzyjny czas i geometrię decyzji o namierzaniu, lokalizację i ruch sił przyjaznych widocznych w kadrze, a także wzorce operacyjne definiujące zachowanie jednostek w czasie. W przeciwieństwie do pojedynczej zaszyfrowanej wiadomości, wideo koduje trwałe informacje kontekstowe — przestrzenne, temporalne i behawioralne — które nagradzają długoterminowe zbieranie i analizę.

Okres przechowywania wideo ISR potęguje to ryzyko. Wiele programów obronnych archiwizuje surowe nagrania z dronów przez lata — do przeglądu działań po misji, dla zgodności prawnej, do eksploatacji wywiadowczej. Przeciwnik, który zbierze zaszyfrowane wideo ISR w 2026 roku i odszyfruje je w 2032 roku, nie czyta przestarzałych danych; czyta ustrukturyzowany historyczny zapis operacji sił przyjaznych. Wrażliwość tego zapisu nie maleje z czasem.

Kwantyfikując powierzchnię zbierania: pojedynczy dron MALE na 20-godzinnej misji przy standardowych bitrate'ach ISR (4–8 Mbps H.264) produkuje 36–72 GB skompresowanego wideo na jeden lot. Flota operująca nad spornym regionem generuje terabajty dziennie. To niezwykle atrakcyjny cel zbierania dla przeciwnika gotowego inwestować w długoterminowe przechowywanie i przyszłe możliwości deszyfrowania.

Stan obecny: DTLS/SRTP i TLS są klasycznie bezpieczne, ale podatne na zagrożenia kwantowe

Większość wojskowych potoków wideo z dronów używa jednego z dwóch modeli bezpieczeństwa transportu. Pierwszy to DTLS/SRTP: model oparty na WebRTC, gdzie DTLS 1.3 negocjuje klucze sesji przez UDP, a SRTP używa tych kluczy do szyfrowania każdego pakietu RTP. Drugi to serwer dystrybucji kluczy (KDS) zabezpieczony TLS: scentralizowana usługa wydająca klucze główne SRTP zarówno nadawcy, jak i odbiorcy przez interfejs API zabezpieczony TLS, z SRTP obsługującym szyfrowanie na poziomie pakietów. Oba modele ostatecznie opierają się na klasycznej wymianie Diffie-Hellmana lub krzywych eliptycznych Diffie-Hellmana dla fazy negocjacji klucza sesji.

ECDHE z X25519 (obecna najlepsza praktyka dla wymiany kluczy DTLS/TLS) zapewnia silne klasyczne bezpieczeństwo. Wobec przeciwnika kwantowego uruchamiającego algorytm Shora nie zapewnia żadnego bezpieczeństwa. Nie jest to słabość w implementacji algorytmu — to fundamentalna właściwość bazowego problemu matematycznego (logarytm dyskretny na krzywej eliptycznej), który algorytm Shora rozwiązuje w czasie wielomianowym. Zastąpienie X25519 większą krzywą (na przykład P-521) nie pomaga; algorytm Shora skaluje się efektywnie dla wszystkich rozmiarów parametrów krzywych eliptycznych.

Symetryczne szyfrowanie AES-256 (używane dla rzeczywistego ładunku pakietu SRTP) nie jest podobnie łamane przez komputery kwantowe. Algorytm Grovera redukuje efektywne bezpieczeństwo AES-256 do 128 bitów wobec kwantowego przeciwnika — nadal obliczeniowo niewykonalne do ataku siłowego. Pilność leży w wymianie kluczy, nie w szyfrze zbiorczym.

ML-KEM do wymiany kluczy wideo: integracja post-kwantowych KEM z SRTP

ML-KEM (Mechanizm Enkapsulacji Kluczy Oparty na Modulowych Kratach), standaryzowany jako FIPS 203 przez NIST i bazujący na algorytmie CRYSTALS-Kyber, jest post-kwantowym zamiennikiem fazy wymiany kluczy DTLS i TLS. KEM działa inaczej niż Diffie-Hellman: odbiorca generuje parę kluczy publiczny/prywatny i publikuje klucz publiczny; nadawca enkapsuluje losowy wspólny sekret za pomocą klucza publicznego; odbiorca dekapsuluje, aby odzyskać ten sam wspólny sekret. Żadna ze stron nie przesyła wspólnego sekretu w postaci jawnej, a przeciwnik przechwytujący szyfrogramy nie może odzyskać wspólnego sekretu bez klucza prywatnego odbiorcy — problem uważany za trudny nawet dla komputerów kwantowych.

Integracja z SRTP jest prosta na poziomie API. Uzgadnianie DTLS (lub wywołanie API KDS) produkuje wspólny sekret jak poprzednio; jedyną zmianą jest to, że wspólny sekret jest teraz wyprowadzany z enkapsulacji ML-KEM zamiast z wymiany ECDHE. Wspólny sekret jest wprowadzany do HKDF-SHA-384, aby wyprowadzić klucz główny i sól SRTP, podążając tą samą ścieżką wyprowadzania kluczy co klasyczny protokół. Format pakietu SRTP, obsługa numerów sekwencyjnych, obliczanie znacznika uwierzytelniania i szyfrowanie zbiorcze AES-256-GCM są niezmienione. Z perspektywy stosu RTP nic się nie zmieniło poza źródłem klucza głównego.

Wybór zestawu parametrów: ML-KEM-768 vs ML-KEM-1024

Zdefiniowane są trzy zestawy parametrów ML-KEM: ML-KEM-512 (poziom bezpieczeństwa równoważny AES-128), ML-KEM-768 (AES-192) i ML-KEM-1024 (AES-256). W przypadku aplikacji ISR wybór przebiega między ML-KEM-768 a ML-KEM-1024. Mandat NSA CNSA 2.0 określa ML-KEM-1024 dla Narodowych Systemów Bezpieczeństwa. ML-KEM-1024 produkuje klucz publiczny 1568 bajtów i szyfrogramu 1568 bajtów — oba większe niż 32-bajtowe udziały kluczy X25519, ale łatwo mieszczące się w uzgadnianiu DTLS lub odpowiedzi API HTTPS. Koszt wydajności w stosunku do ML-KEM-768 jest marginalny; dla decyzji, która będzie regulować bezpieczeństwo danych przez dekadę, ML-KEM-1024 jest właściwym wyborem dla klasyfikowanych aplikacji ISR.

Budżet opóźnienia: narzut PQC w strumieniowaniu w czasie rzeczywistym

Najczęstszym zastrzeżeniem wobec PQC w potokach wideo w czasie rzeczywistym jest opóźnienie. Obawa jest zrozumiała, ale błędna, gdy przeanalizuje się rzeczywiste liczby.

Generowanie kluczy ML-KEM-1024 na nowoczesnym procesorze x86-64 (implementacja zoptymalizowana pod AVX2, np. liboqs lub wbudowany BoringSSL) zajmuje około 0,3–0,5 ms. Enkapsulacja i dekapsulacja każda trwają poniżej 0,5 ms. Całkowity narzut round-trip dla wymiany kluczy PQC wynosi zatem poniżej 2 ms, wliczając czas round-trip sieci w sieci LAN o niskim opóźnieniu. Dla strumieni wideo już niosących 100–300 ms opóźnienia potoku kodeka i sieci (typowe dla taktycznych łączy satelitarnych) ten narzut jest w praktyce niemierzalny.

Wymiana kluczy to operacja jednorazowa na sesję, nie operacja na pakiet. Sesja wideo z drona trwająca 20 godzin wykonuje jedną enkapsulację ML-KEM na początku (i niewielką liczbę okresowych ponownych wygenerowań kluczy). Koszt per pakiet wynosi zero — szyfrowanie pakietów SRTP pozostaje AES-256-GCM z przyśpieszeniem sprzętowym (wiele Gbps na nowoczesnych procesorach). Post-kwantowe strumieniowanie wideo nie jest problemem wydajnościowym. Jest problemem integracyjnym.

Wdrożenie trybu hybrydowego: ECDHE + ML-KEM równolegle

W okresie przejściowym — gdy niektóre punkty końcowe obsługują ML-KEM, a inne nie — hybrydowe zestawy szyfrów są podejściem zatwierdzonym przez standardy. W trybie hybrydowym uzgadnianie DTLS lub TLS obejmuje zarówno udział klucza ECDHE (X25519), jak i enkapsulację klucza ML-KEM (ML-KEM-1024). Klucz sesji jest wyprowadzany z obu przez HKDF, według formuły: session_key = HKDF(X25519_shared_secret || ML-KEM_shared_secret, "hybrid-srtp-key"). Oba sekrety muszą być pomyślnie wyprowadzone, aby sesja mogła postępować.

Ta konstrukcja zapewnia to, co kryptografowie nazywają „podwójnym bezpieczeństwem": sesja jest bezpieczna kwantowo, jeśli ML-KEM jest bezpieczny, i klasycznie bezpieczna, jeśli X25519 jest bezpieczny. Atakujący musi złamać oba, aby odzyskać klucz sesji. NSA popiera tryb hybrydowy na okres przejściowy w wytycznych CNSA 2.0; w żaden sposób nie redukuje on klasycznego bezpieczeństwa.

Praktyczna korzyść dla systemów ISR polega na tym, że tryb hybrydowy można wdrożyć w całej flocie, zanim wszystkie stacje naziemne zostaną uaktualnione. Uaktualnione stacje naziemne negocjują hybrydowy zestaw szyfrów; starsze stacje cofają się do ECDHE. Strumienie o wysokiej wartości — te łączące post-kwantowe węzły C2 — uzyskują natychmiastową ochronę kwantową, przy zachowaniu wstecznej kompatybilności. Zobacz nasze szersze omówienie podejścia do migracji CNSA 2.0 dla systemów obronnych, zawierające pełny inwentarz algorytmów i harmonogram przejścia.

Apache Kafka jako szkielet strumieniowania dla dystrybucji ISR

SRTP punkt-do-punktu sprawdza się dla pojedynczych łączy dron–C2, ale operacyjna dystrybucja ISR to problem fan-out. Pojedynczy kanał z drona musi być jednocześnie konsumowany przez: główną stację roboczą C2, komórkę namierzania, zespół eksploatacji wywiadowczej, węzeł nagrywania archiwizujący misję i ewentualnie wyższe szczeble dowodzenia monitorujące operację. Zarządzanie N równoczesnymi sesjami SRTP od kodera do każdego konsumenta jest operacyjnie kruche i kryptograficznie zagmatwane — każda sesja ma niezależny materiał kluczowy, a zarządzanie dystrybucją i rotacją kluczy wśród N peerów jednocześnie tworzy tryby awaryjne.

Apache Kafka rozwiązuje ten problem architektoniczny. Każde źródło ISR publikuje do dedykowanego tematu Kafka (np. isr.drone.alpha-01.video, isr.sensor.ground.bravo). Grupy konsumentów — jedna na rolę (c2-display, targeting, exploitation, archive) — subskrybują niezależnie i utrzymują własne przesunięcia. Dodanie nowego konsumenta nie wymaga ponownego negocjowania z producentem; po prostu subskrybuje on istniejący temat. Odtwarzanie dla konsumentów dołączających z opóźnieniem (analityk namierzania, który dołącza w trakcie misji) jest wbudowaną możliwością Kafka, a nie autorską funkcją.

Model bezpieczeństwa post-kwantowego mapuje się czytelnie na tę architekturę. Każdy producent uwierzytelnia się w brokerze Kafka przez wzajemny TLS z hybrydowymi zestawami szyfrów ML-KEM, ustanawiając bezpieczny kwantowo kanał dla strumienia. Każdy konsument podobnie łączy się z brokerem przez TLS z hybrydowym ML-KEM. Broker przechowuje zaszyfrowane dane tematu na dysku pod szyfrowaniem AES-256 w spoczynku. Hierarchia kluczy — klucz sesji ML-KEM chroniący połączenie TLS niosące zaszyfrowane klatki wideo SRTP przechowywane w zaszyfrowanych segmentach dziennika Kafka AES-256 — zapewnia dogłębną obronę na każdej warstwie.

Partycjonowanie tematów i projektowanie grup konsumentów

W przypadku wdrożeń ISR z wieloma sensorami partycjonowanie w ramach tematu zapewnia skalowalność. Sensor o wysokiej przepustowości (pełne wideo ruchowe przy 8 Mbps) korzysta z jednej partycji na źródło, aby zachować kolejność klatek. Wiele sensorów o niższej przepustowości (telemetria, audio, wąskie pole widzenia) może współdzielić temat z partycjonowaniem według identyfikatora sensora. Grupy konsumentów powinny być zakresowane do ról operacyjnych, a nie poszczególnych stacji roboczych — pozwala to na przełączanie awaryjne stacji roboczych w ramach roli bez utraty ciągłości przesunięcia. Każda grupa konsumentów utrzymuje niezależny stan deszyfrowania; rotacja kluczy w jednej grupie nie wpływa na inne.

Corvus.Quantum: post-kwantowe strumieniowanie dla operacyjnej obrony

Corvus.Quantum to platforma Corvus Intelligence do bezpiecznej kwantowo dystrybucji audio i wideo w środowiskach obronnych. Implementuje architekturę opisaną w tym artykule — wymiana kluczy ML-KEM-1024 w trybie hybrydowym, szyfrowanie pakietów SRTP, fan-out Apache Kafka do dystrybucji wieloszczeblowej — jako zahartowany, operacyjnie przetestowany system, a nie prototyp badawczy.

Platforma została wdrożona w warunkach aktywnego konfliktu na Ukrainie, gdzie zarządza dystrybucją wideo ISR w czasie rzeczywistym dla stanowisk dowodzenia operujących pod presją walki elektronicznej. Priorytety projektowe ukształtowane przez to środowisko — opóźnienie od kamery do ekranu poniżej 200 ms pomimo spornych łączy, płynna degradacja przy odłączaniu konsumentów w trakcie strumienia, automatyczna rotacja kluczy bez przerywania strumienia i wdrożenie zdolne do pracy w sieci air-gap dla klasyfikowanych sieci — są walidowane produkcyjnie, a nie symulowane w laboratorium.

Corvus.Quantum integruje się z istniejącą infrastrukturą C2 opartą na ATAK poprzez interfejs wtyczki, umożliwiając przepływ wideo ISR do wspólnego obrazu operacyjnego wraz z danymi cursor-on-target. Szkielet Kafka obsługuje zarówno wdrożenia hostowane w chmurze, jak i lokalne air-gapped. Post-kwantowa wymiana kluczy jest domyślnie włączona; klasyczny fallback jest dostępny dla starszych punktów końcowych w hybrydowych okresach przejściowych. Dla organizacji zmagających się z wymaganiami sieci zero-trust dla środowisk wojskowych, wzajemne uwierzytelnianie TLS Corvus.Quantum dla każdego producenta i konsumenta spełnia weryfikację tożsamości urządzeń na warstwie strumieniowania bez dodatkowego oprogramowania pośredniczącego.

Ścieżka zamówień dla Corvus.Quantum jest dostępna przez rynek technologii obronnych Brave1 i bezpośredni kontrakt z Corvus Intelligence. Dokumentacja integracji technicznej jest dostępna pod NDA dla kwalifikowanych organizacji obronnych i głównych wykonawców.