Quantum safe: jak przygotować firmę na kryptografię postkwantową bez paniki

Dlaczego temat „quantum safe” pojawia się właśnie teraz

Komputery kwantowe: między hype’em a realistyczną perspektywą czasową

Komputery kwantowe od lat są nośnym hasłem marketingowym. Sygnały z rynku – prototypy IBM, Google, firm chińskich – tworzą wrażenie, że „za chwilę” wszystko, co dziś zaszyfrowane, stanie się publiczne. To uproszczenie. Pomiędzy pokazowym eksperymentem a stabilną, skalowalną maszyną zdolną łamać realne systemy RSA/ECC jest przepaść technologiczna. Problem w tym, że nie wiadomo, kiedy dokładnie zostanie zasypana.

Rozsądne analizy wskazują, że kryptograficznie istotne komputery kwantowe (czyli takie, które z użyciem algorytmu Shora mogą łamać popularne długości kluczy RSA/ECC) to horyzont raczej lat niż dekad, ale z dużą niepewnością. Perspektywa 5–15 lat pojawia się w wielu raportach, jednak nie ma tu twardych gwarancji – ani w jedną, ani w drugą stronę. To wystarcza, by poważne organizacje zaczęły planować migrację, ale za mało, by uzasadnić paniczne ruchy.

Sceptyczne podejście polega na rozdzieleniu pytania „kiedy” od pytania „jak szybko muszę się przygotować”. W praktyce, nawet jeśli „dzień kwantowy” nastąpi później niż sądzimy, cykle życia systemów, kontraktów i architektury IT są na tyle długie, że odłożenie tematu na „po następnym projekcie” w praktyce oznacza brak przygotowania.

Co dokładnie zagraża obecnym systemom kryptograficznym

Kryptografia, z której korzysta większość firm, opiera się na dwóch filarach:

• kryptografia asymetryczna – klucze publiczne/prywatne (RSA, ECC) wykorzystywane do podpisów cyfrowych, uwierzytelniania, wymiany kluczy (TLS, VPN, PKI);
• kryptografia symetryczna – ten sam klucz do szyfrowania i deszyfrowania (np. AES), stosowana do szyfrowania danych „w spoczynku” i „w tranzycie”.

Teoretyczne i praktyczne badania wskazują, że głównym celem komputerów kwantowych będą algorytmy asymetryczne. Algorytm Shora pozwala w czasie wielomianowym rozkładać liczby na czynniki pierwsze i rozwiązywać problem logarytmu dyskretnego, co uderza bezpośrednio w RSA i ECC. To oznacza załamanie bezpieczeństwa PKI, protokołów wymiany kluczy i podpisów opartych na tych fundamentach.

Dla kryptografii symetrycznej ryzyko jest mniejsze, ale niezerowe. Algorytm Grovera może przyspieszać przeszukiwanie przestrzeni kluczy mniej więcej do pierwiastka z rozmiaru, co praktycznie przekłada się na konieczność zwiększenia długości kluczy symetrycznych (np. preferowanie AES-256 zamiast AES-128). To nie jest rewolucja, raczej korekta parametrów.

W efekcie zagrożone są głównie te elementy, gdzie używany jest RSA lub ECC: certyfikaty TLS, VPN IPsec/SSL, podpisy dokumentów, S/MIME, SSH z kluczami RSA/ECDSA, komunikacja IoT z certyfikatami urządzeń, wewnętrzne CA w organizacji, systemy podpisu kodu (code signing). Jeżeli w architekturze IT nie ma świadomości, gdzie te elementy występują, trudniej będzie zaplanować jakąkolwiek sensowną strategię „quantum safe”.

Efekt „harvest now, decrypt later”: dane zagrożone już dziś

Nawet jeśli praktycznych ataków kwantowych jeszcze nie ma, część danych traci bezpieczeństwo już teraz z innego powodu. Atak „harvest now, decrypt later” polega na przechwytywaniu i archiwizowaniu zaszyfrowanego ruchu lub danych dziś, z zamiarem odszyfrowania ich w przyszłości, gdy pojawi się wystarczająco silny komputer kwantowy.

Jeżeli:

• dane mają długi czas wymaganej poufności (np. dokumentacja medyczna, dane wywiadowcze, tajemnice przedsiębiorstwa, dane wojskowe, własność intelektualna),
• są przesyłane lub przechowywane z użyciem RSA/ECC (np. TLS z RSA/ECDHE, VPN, S/MIME),
• oraz istnieje rozsądne przypuszczenie, że ktoś może te dane masowo przechwytywać,

to ryzyko jest realne już dziś. Przeciwnik nie musi łamać szyfrowania w czasie rzeczywistym. Wystarczy, że gromadzi zaszyfrowany materiał i czeka, aż technologia dogoni jego ambicje. Dla wielu firm to ryzyko jest nadal teoretyczne, ale dla instytucji państwowych, finansów, dużych korporacji z cennym IP – to konkretna pozycja w rejestrze ryzyk.

Kto faktycznie powinien czuć presję czasu

Nie każde przedsiębiorstwo jest w tej samej sytuacji. Presja czasu rośnie tam, gdzie:

• dane mają ekstremalnie długi horyzont poufności (10–30 lat lub więcej),
• przeciwnicy są zmotywowani i dobrze finansowani (państwa, duże grupy przestępcze),
• infrastruktura ma długi cykl życia (systemy przemysłowe, energetyka, telekomunikacja, sprzęt IoT w polu przez kilkanaście lat).

Do grupy o najwyższej presji czasu należą najczęściej:

• sektor publiczny i obronny – dane wywiadowcze, rejestry obywateli, komunikacja dyplomatyczna, tajemnice państwowe;
• sektor finansowy – transakcje, dane klientów, klucze infrastruktury płatniczej, podpisy transakcyjne;
• zdrowie – dokumentacja medyczna z bardzo długim okresem przechowywania;
• R&D, sektor high-tech – własność intelektualna, projekty, plany produktów.

Typowa firma handlowa czy e‑commerce, która przetwarza dane o krótkim cyklu życia i nie jest pierwszoplanowym celem wywiadów państwowych, ma więcej czasu. Dla takich organizacji sensowna strategia to planowane, stopniowe włączanie wymagań „quantum safe” do nowo projektowanych systemów, zamiast gwałtownych i kosztownych migracji „na już”.

Granica między nauką a marketingiem strachu

Rynek bezpieczeństwa szybko podchwycił hasło „quantum safe”. Pojawiają się rozwiązania reklamowane jako „w 100% odporne na komputery kwantowe” albo „zabezpieczające firmę na kolejne 50 lat”. Z technicznego punktu widzenia takie obietnice są trudne do uzasadnienia. Algorytmy postkwantowe wciąż są badane, a nowe ataki kryptograficzne pojawiają się regularnie.

Zdrowe podejście zakłada:

• opieranie się na standardach i rekomendacjach instytucji takich jak NIST, ETSI, IETF, ENISA, zamiast na autorskich „przełomowych” rozwiązaniach pojedynczych vendorów,
• unikanie zarówno paraliżu decyzyjnego („czekamy, aż wszystko będzie pewne”), jak i kupowania wszystkiego, co ma naklejkę PQC,
• traktowanie „quantum safe” jako procesu zarządzania ryzykiem, a nie jednorazowego zakupu magicznej technologii.

Granica między uczciwą troską o przyszłe zagrożenia a marketingiem strachu przebiega najczęściej tam, gdzie dostawca zaczyna obiecywać pełną pewność w świecie, w którym jej po prostu nie ma. Organizacja powinna być przygotowana, ale nie sterowana wyłącznie lękiem.

Podstawy: jak działają obecne mechanizmy kryptografii a gdzie wchodzi kwant

Krótkie przypomnienie: kryptografia symetryczna i asymetryczna

W większości organizacji dział bezpieczeństwa bazuje na kilku głównych mechanizmach kryptograficznych, choć nie zawsze jest to jasno opisane w architekturze.

Kryptografia symetryczna:

• ten sam klucz służy do szyfrowania i deszyfrowania danych (np. AES-256);
• jest bardzo szybka i wydajna, nadaje się do szyfrowania dużych ilości danych (dyski, backupy, ruch sieciowy po zestawieniu sesji);
• problemem jest bezpieczna dystrybucja kluczy – jak przekazać klucz drugiej stronie, żeby nikt go nie podsłuchał.

Kryptografia asymetryczna (klucze publiczne/prywatne):

• klucz publiczny może znać każdy, klucz prywatny pozostaje tajny;
• umożliwia podpisy cyfrowe (kluczem prywatnym) i wymianę kluczy symetrycznych (np. w TLS);
• jest wolniejsza i zwykle używana do małych fragmentów danych (np. klucze sesyjne, skróty dokumentów);
• opiera się na trudnościach obliczeniowych (faktoryzacja, logarytm dyskretny), które są właśnie celem komputerów kwantowych.

Na tym fundamencie budowane są protokoły takie jak TLS (HTTPS), IPsec, SSH, S/MIME, czy systemy PKI (Public Key Infrastructure), bez których nie ma zaufania do komunikacji i podpisów cyfrowych w firmie.

Dlaczego komputery kwantowe uderzają głównie w asymetrię

Algorytm Shora wykorzystuje właściwości obliczeń kwantowych do efektywnego rozwiązywania problemów matematycznych, na których opiera się bezpieczeństwo RSA i ECC. W świecie klasycznym rozkładanie bardzo dużych liczb na czynniki pierwsze jest praktycznie niewykonalne w rozsądnym czasie. W świecie kwantowym – przy założeniu odpowiednio dużego i stabilnego komputera – czas potrzebny na złamanie tych problemów radykalnie spada.

Konsekwencje są dość proste:

• RSA i ECC przestają być bezpieczne założeniowo, niezależnie od długości klucza (powyżej pewnego poziomu mniejsza rola ma długość, większa podatność konstrukcji na Shora);
• wszystko, co używa RSA/ECC do uwierzytelniania, podpisu czy wymiany kluczy, musi mieć alternatywę postkwantową;
• kryptografia symetryczna (AES, ChaCha20) oraz funkcje skrótu (SHA-2, SHA-3) mogą nadal być bezpieczne, o ile dostosuje się parametry (długości kluczy, długości skrótów).

Algorytm Grovera z kolei nie „łamie” szyfrów symetrycznych w tradycyjnym sensie; przyspiesza przeszukiwanie przestrzeni kluczy. Efekt jest mniej dramatyczny: dla AES-128 efektywna siła spada w uproszczeniu do poziomu, który odpowiada AES-64 w świecie klasycznym. Stąd zalecenia, by w scenariuszach wymagających długiej poufności przechodzić na AES-256.

Które protokoły i standardy wymagają uwagi w kontekście quantum safe

Gdy spojrzy się na typową infrastrukturę firmy, lista potencjalnych punktów problemowych w kontekście kryptografii postkwantowej szybko rośnie:

• TLS/HTTPS – klienci (przeglądarki, aplikacje mobilne) negocjują z serwerem parametry połączenia, używając obecnie RSA/ECDHE do wymiany kluczy i uwierzytelniania;
• VPN (IPsec, SSL VPN) – wykorzystują zestawy algorytmów opartych na RSA/ECC do ustanowienia tunelu;
• PKI / certyfikaty X.509 – hierarchie certyfikatów oparte na RSA/ECC, z łańcuchami zaufania sięgającymi wielu lat wstecz;
• podpisy dokumentów – kwalifikowane podpisy elektroniczne, podpisy wewnętrzne, podpisy kodu (code signing) oparte na RSA/ECC;
• SSH – klucze RSA, ECDSA, Ed25519 do administrowania serwerami;
• IoT i urządzenia wbudowane – certyfikaty urządzeń, mechanizmy update’u OTA, autoryzacja w chmurze;
• sprzęt HSM – moduły bezpieczeństwa sprzętowego zaprojektowane z myślą o klasycznych algorytmach.

Nie oznacza to, że wszystkie te elementy trzeba natychmiast wymienić. Oznacza natomiast, że trzeba wiedzieć, gdzie są i jak są używane. Bez tej wiedzy nie da się zaplanować ani skalować strategii przejścia na PQC (post-quantum cryptography).

„Quantum safe” vs „quantum resistant”: niuanse języka

W materiałach marketingowych często pojawiają się określenia „quantum safe” i „quantum resistant”. W praktyce używane są zamiennie, ale dobrze jest rozumieć konsekwencje ich stosowania.

Z punktu widzenia inżyniera:

• quantum resistant – algorytmy lub protokoły, dla których nie jest znany skuteczny atak kwantowy; odporność jest oparta na aktualnym stanie wiedzy, ale nie daje absolutnej gwarancji;
• quantum safe – rozwiązania, które nie używają mechanizmów znanych jako podatne na ataki kwantowe (np. brak RSA/ECC w krytycznych częściach protokołu), oraz uwzględniają zwiększone parametry dla symetrii.

Co już wiadomo: standardy NIST PQC i inne prace normalizacyjne

Dlaczego wszyscy patrzą na NIST

Przez ostatnie lata wiele instytucji i firm publikowało własne propozycje algorytmów „odpornych na kwant”. Większość organizacji nie ma jednak zasobów, aby samodzielnie oceniać ich bezpieczeństwo. Stąd tak duża rola NIST PQC – wieloletniego procesu standaryzacji algorytmów postkwantowych prowadzonego przez amerykański National Institute of Standards and Technology.

Kluczowe elementy tego procesu z punktu widzenia praktyka:

• wielostopniowa selekcja kandydatów (kilkadziesiąt algorytmów na starcie, kilka finalnych),
• otwarta analiza przez środowisko naukowe – algorytmy są publicznie dostępne, a ich projektanci muszą odpowiadać na zgłaszane ataki i uwagi,
• koncentracja na dwóch głównych zastosowaniach: wymiana kluczy / KEM (Key Encapsulation Mechanism) oraz podpisy cyfrowe.

Rezultat: zamiast dziesiątek „cudownych” propozycji, organizacje dostają krótką listę algorytmów rekomendowanych do szerokiego wdrożenia, wraz z dokumentacją, implementacjami referencyjnymi i profilami bezpieczeństwa.

Główne algorytmy NIST PQC – co realnie trafi do systemów

Na moment przygotowywania strategii migracji postkwantowej warto znać nazwy kilku algorytmów, bo zaczną się pojawiać w ofertach vendorów, dokumentacji API i parametrach protokołów.

Dla wymiany kluczy (KEM):

• CRYSTALS‑Kyber – obecnie główny kandydat dla szerokiego zastosowania. Oparty na problemach z kratami (LWE/MLWE). Ma dobre kompromisy pomiędzy bezpieczeństwem, wydajnością i rozmiarem kluczy. W praktyce będzie prawdopodobnie pierwszym wyborem w TLS, VPN i protokołach tunelujących.

Dla podpisów cyfrowych:

• CRYSTALS‑Dilithium – również konstrukcja kratowa, przewidywany „koń roboczy” dla podpisów ogólnego przeznaczenia (certyfikaty, podpisy kodu, podpisy transakcyjne);
• FALCON – szybszy i z mniejszymi podpisami niż Dilithium, ale trudniejszy implementacyjnie i bardziej wymagający względem błędów; ciekawy dla zastosowań o krytycznych ograniczeniach przepustowości;
• SPHINCS+ – podpisy oparte na funkcjach skrótu, z długimi podpisami i kluczami, ale bardzo konserwatywnym modelem bezpieczeństwa (bez dodatkowych założeń algebraicznych). Często postrzegany jako „koło ratunkowe” tam, gdzie akceptuje się większe rozmiary.

Istnieją inne algorytmy (np. dla zastosowań „niszowych” lub specyficznych sektorowo), lecz powyższe zestawy będą w praktyce pojawiać się najczęściej w standardowych bibliotekach kryptograficznych.

Co poza NIST: ETSI, IETF, ENISA i reszta układanki

NIST decyduje, „jakie” algorytmy są akceptowalne, ale to dopiero połowa problemu. Trzeba je jeszcze wpisać w istniejące protokoły i procesy regulacyjne.

Do najważniejszych inicjatyw należą:

• IETF – prace nad wprowadzaniem PQC do TLS, IPsec, SSH, X.509. Pojawiają się drafty opisujące:
  • tzw. hybrydowe zestawy szyfrów (np. ECDHE + Kyber w jednym handshaku TLS),
  • nowe rozszerzenia certyfikatów z kluczami PQC,
  • formaty dla hybrydowych podpisów (klasyczny + PQC).
• ETSI (m.in. grupa ETSI QSC) – rekomendacje dla telekomunikacji, 5G, IoT, z naciskiem na praktyczne wdrażanie w sieciach operatorskich i sprzęcie sieciowym.
• ENISA – wytyczne dotyczące zarządzania ryzykiem postkwantowym, horyzontów czasowych oraz zaleceń dla sektora publicznego i krytycznej infrastruktury w UE.
• Organy nadzorcze i regulacyjne (np. EBA, ESMA, krajowe nadzory) – coraz częściej pytają dużych graczy finansowych i operatorów o plany migracji do PQC, wpisując temat w szersze ramy ciągłości działania i odporności cyfrowej (np. DORA).

Pułapka, w którą łatwo wpaść: wdrożenie „jakiegoś” algorytmu PQC przed ustaleniem formatu protokołów i wymagań branżowych. Późniejsza zgodność z normami może wymagać drugiej migracji. Dlatego przy systemach mających długi cykl życia lepiej ściśle trzymać się profili publikowanych przez IETF, ETSI lub odpowiednie gremia sektorowe, nawet jeśli oznacza to chwilowe opóźnienie.

Stabilność standardów: jak bardzo to jest „gotowe”

Choć algorytmy NIST są na zaawansowanym etapie standaryzacji, obrazu nie można traktować jako całkowicie zamkniętego.

• Prowadzone są dalsze analizy kryptograficzne – możliwe są korekty parametrów, ograniczenia użycia w niektórych scenariuszach lub modyfikacje implementacji.
• Niektóre zastosowania (np. bardzo małe urządzenia IoT, karty SIM, specjalizowane układy w przemyśle) mogą wymagać alternatywnych algorytmów o mniejszych kluczach lub innym profilu zasobów.
• Może pojawić się druga fala standardów PQC, adresująca wnioski z pierwszych wdrożeń masowych.

Bezpieczna strategia to unikanie przywiązania całej architektury do jednego, konkretnego algorytmu. Zamiast tego warto projektować systemy tak, aby łatwo było podmieniać i dołączać nowe prymitywy kryptograficzne w ramach tego samego protokołu i interfejsów.

Ocena ekspozycji organizacji: kto naprawdę ma problem i jak go zmierzyć

Dwa kluczowe wymiary: horyzont poufności i czas migracji

Nie każda organizacja jest w takim samym stopniu zagrożona przez rozwój komputerów kwantowych. Najbardziej praktyczny sposób oceny ekspozycji to zestawienie dwóch pytań:

1. Przez ile lat dane muszą pozostać poufne? (horyzont poufności)
2. Ile lat zajmie pełna migracja infrastruktury kryptograficznej do PQC? (horyzont migracji)

Jeśli czas potrzebny do migracji jest zbliżony do lub dłuższy niż wymagany okres poufności danych, organizacja musi zacząć działać znacznie wcześniej. To właśnie w takich środowiskach najgroźniejszy jest scenariusz „zapisz teraz, odszyfruj później”.

Mapa ryzyka „harvest now, decrypt later”

Oceniając ryzyko, zwykle pojawia się uproszczenie: „naszych danych nikt nie będzie trzymał tyle lat, żeby czekać na komputer kwantowy”. W niektórych branżach to może być częściowo prawdziwe, ale są obszary, gdzie jest dokładnie odwrotnie.

W pierwszym kroku przydaje się prosta klasyfikacja:

• Dane krótkoterminowo wrażliwe – ich ujawnienie po kilku latach nie zmienia wiele (np. część danych operacyjnych, logi transakcyjne bez danych osobowych). Dla nich ryzyko postkwantowe jest mniejsze, o ile horyzont poufności faktycznie jest krótki.
• Dane średnioterminowo wrażliwe – ważne przez 3–10 lat (część danych finansowych, umów handlowych, niektóre dane o klientach). Tu decyzja „jak szybko” wchodzić w PQC zależy od realnej oceny, kiedy spodziewamy się użytecznych ataków kwantowych.
• Dane długoterminowo wrażliwe – istotne przez 10, 20 lat i dłużej: dane zdrowotne, rejestry obywateli, dokumentacja techniczna strategicznych systemów, klucze root CA, dane wywiadowcze. W tych obszarach ryzyko „harvest now, decrypt later” jest jak najbardziej realne.

Nie chodzi o apokaliptyczne scenariusze, lecz o uczciwe spojrzenie na to, czy ktoś mógłby chcieć gromadzić ruch i zaszyfrowane archiwa już dziś, licząc na przyszłą możliwość złamania RSA/ECC. Służby wywiadowcze – tak. Przeciętny cyberprzestępca polujący na dane kart płatniczych – raczej nie.

Identyfikacja krytycznych łańcuchów zaufania

Kolejny krok to spojrzenie na łańcuchy zaufania w organizacji – czyli miejsca, gdzie kompromitacja jednego klucza lub komponentu pozwala przejąć kontrolę nad dużą częścią systemu.

Typowe przykłady:

• Główne urzędy certyfikacji (root CA, sub-CA) w wewnętrznej lub publicznej PKI. Kompromitacja takiego klucza pozwala wystawiać fałszywe certyfikaty, a w konsekwencji prowadzić zaawansowane ataki MITM, fałszować podpisy kodu, dokumentów, itp.
• Klucze podpisywania kodu (code signing) używane przy dystrybucji oprogramowania, obrazów systemów, firmware’u. Atakujący, który po latach „odblokuje” klucz podpisujący stary firmware, może spróbować wstrzyknąć złośliwe aktualizacje do urządzeń, które wciąż ufają temu kluczowi.
• Podpisy długoterminowych dokumentów – umowy, zgody regulacyjne, dokumentacja techniczna, które mogą być później weryfikowane w sporach sądowych. Jeżeli użyte mechanizmy podpisu zostaną załamane, rodzi się pytanie o wartość dowodową takich dokumentów.

W takich miejscach sama wymiana algorytmu często nie wystarczy. Potrzebne jest podejście obejmujące notaryzację, znaczniki czasowe, mechanizmy archiwizacji i ponownego podpisywania, tak aby zapobiec podważeniu całej historii zaufania.

Różne działy, różne priorytety

Ocena ekspozycji nie jest wyłącznie zadaniem zespołu bezpieczeństwa. Różne obszary biznesowe mają różne perspektywy:

• IT / bezpieczeństwo infrastruktury skupia się na protokołach (TLS, VPN, SSH), urządzeniach sieciowych, certyfikatach serwerowych;
• działy produktowe i R&D – na tym, jak długo będą wspierać swoje produkty, jakie aktualizacje bezpieczeństwa muszą gwarantować i co się stanie, jeśli klienci zażądają „quantum safe” w przetargach;
• obszar prawny i compliance – na wymaganiach archiwizacji dokumentów, ważności podpisów kwalifikowanych, zgodności z regulacjami sektorowymi;
• zarząd – na ryzyku reputacyjnym, potencjalnych kosztach „spóźnionej migracji” i oczekiwaniach regulatorów.

Bez wspólnego języka między tymi grupami ryzyko jest zwykle niedoszacowane lub źle ulokowane. Przykład z praktyki: dział IT uspokaja, że „TLS można zmienić w rok”, podczas gdy dział odpowiedzialny za produkty medyczne musi wspierać sprzęt w polu przez kilkanaście lat i nie ma możliwości łatwej aktualizacji firmware’u.

Jak przekuć ocenę ekspozycji w plan działania

Po zebraniu powyższych informacji warto zbudować prostą, ale utrzymywaną w czasie mapę priorytetów:

1. Wyszczególnić obszary wymagające poufności > 10 lat i mające krytyczne łańcuchy zaufania.
2. Określić realny czas migracji dla każdego z tych obszarów (uwzględniając cykl życia urządzeń, systemów, kontrakty).
3. Zaznaczyć punkty, które już dziś mogą zostać uodpornione częściowo:
   • np. wprowadzenie hybrydowych rozwiązań (klasyczny + PQC),
   • zwiększenie parametrów symetrycznych (AES‑256, dłuższe klucze HMAC),
   • modyfikacja procedur archiwizacji i ponownego podpisywania.

Taka mapa powinna być elementem szerszej strategii zarządzania ryzykiem, a nie jednorazowym ćwiczeniem do prezentacji. Co kilka lat założenia co do rozwoju technologii kwantowej i stanu standardów PQC będą się zmieniać – plan musi mieć miejsce na korekty.

Inwentaryzacja kryptografii: najtrudniejszy, a najczęściej pomijany krok

Dlaczego większość organizacji nie wie, gdzie ma kryptografię

W praktyce niewiele firm ma pełną, aktualną mapę użycia kryptografii. Wynika to z kilku powodów:

• kryptografia jest „zaszyta” w bibliotekach i frameworkach – programiści używają domyślnych ustawień, nie dokumentując, jakie algorytmy i parametry są stosowane;
• wiele systemów to „kupione pudełka” (appliance, SaaS, oprogramowanie zamknięte), gdzie szczegóły kryptografii są niejawne lub opisane ogólnikowo;
• brak wspólnej odpowiedzialności – nikt nie czuje się właścicielem tematu „co, gdzie i jak szyfruje dane”;

Źródła informacji: od „spisu certyfikatów” po analizę binarek

Przy inwentaryzacji kuszące jest ograniczenie się do prostej listy: „certyfikaty TLS, VPN, podpisy kodu”. To daje poczucie porządku, ale zwykle odsłania tylko wierzchołek góry lodowej. Sensowny przegląd wymaga połączenia kilku źródeł danych:

• Rejestry certyfikatów i PKI – wewnętrzne CA, systemy zarządzania certyfikatami, inventory z load balancerów i reverse proxy. To dobre miejsce startu, bo obejmuje większość publicznie wystawionej kryptografii (serwery, API, VPN).
• Skany infrastruktury – narzędzia typu nmap, sslyze czy komercyjne skanery TLS, które enumerują wspierane protokoły, algorytmy i długości kluczy na portach produkcyjnych i testowych. Tu wychodzą „zapomniane” serwisy i stare protokoły.
• Przeglądy kodu i zależności – wyszukiwanie wywołań bibliotek kryptograficznych w repozytoriach (np. BouncyCastle, OpenSSL, CryptoAPI), ale też konfiguracji frameworków (Spring Security, .NET, biblioteki JWT).
• Analiza binarek i firmware’u – w systemach wbudowanych i „pudełkach” (UTM, IoT, kontrolery przemysłowe) nie ma alternatywy: trzeba sięgnąć do obrazów firmware’u, aktualizacji, dokumentacji producenta i – jeśli to konieczne – testów w czarnej skrzynce.

Sam spis certyfikatów serwerowych pokazuje, gdzie organizacja używa RSA/ECC na zewnątrz, ale kompletnie pomija np. wewnętrzne tokeny JWT, szyfrowanie baz danych, schematy backupu czy podpisywanie artefaktów CI/CD. Bez tych obszarów plan migracji będzie iluzją.

Jak ustrukturyzować katalog kryptografii

Zebrane informacje szybko zamieniają się w chaos, jeśli nie zostaną ułożone według kilku powtarzalnych kryteriów. W praktyce sprawdza się prosty model opisujący każdy „użytek kryptografii” jako rekord z co najmniej następującymi polami:

• komponent / system / usługa – gdzie to działa (nazwa aplikacji, usługa sieciowa, moduł mikrousługi, urządzenie);
• funkcja kryptograficzna – co dokładnie robi (szyfrowanie danych w spoczynku, szyfrowanie w transmisji, podpis cyfrowy, hashowanie, KDF, protokół uwierzytelnienia);
• algorytm i parametry – RSA/ECDSA/ECDH, długość klucza, krzywa eliptyczna, AES‑XTS/GCM/CBC, HMAC‑SHA‑256 itp.;
• miejsce przechowywania kluczy – HSM, TPM, plik w systemie, baza danych, chmura KMS, karta inteligentna;
• zależność od zewnętrznych dostawców – czy algorytmy i klucze kontroluje organizacja, czy „przychodzą” z zewnątrz (SaaS, moduł sprzętowy, biblioteka firm trzecich);
• horyzont poufności danych – jaki okres trzeba zachować poufność / ważność podpisów dla danych obsługiwanych przez ten komponent;
• ocena krytyczności łańcucha zaufania – czy dany element może „pociągnąć za sobą” inne (root CA, klucze podpisywania kodu, klucze federacyjne SSO).

Taki katalog nie musi być perfekcyjny przy pierwszym podejściu. Kluczowe jest, aby od początku był projektowany jako obiekt żywy – regularnie aktualizowany wraz ze zmianami w architekturze, a nie excel do jednorazowej prezentacji.

Strategia „od zewnątrz do środka” kontra „od najstarszego do krytycznego”

Organizacje zwykle zaczynają inwentaryzację od tego, co widać i co jest najprostsze do skanowania – publiczne endpointy TLS, VPN, ewentualnie wewnętrzne usługi HTTP. To ma sens jako pierwszy krok, ale nie wystarcza, jeśli celem jest odporność postkwantowa w obszarach o długim horyzoncie poufności.

Praktyczne podejście często łączy dwie perspektywy:

• „od zewnątrz do środka” – najpierw wszystko, co wystawia interfejs na świat (Internet) lub do szerokiej sieci wewnętrznej (VPN, portale pracownicze, usługi międzycentrowe);
• „od najstarszego do krytycznego” – równolegle lista systemów:
  • o najdłuższym przewidywanym czasie życia (systemy przemysłowe, medyczne, infrastruktura krytyczna);
  • z największym wpływem w razie złamania (PKI, SSO, systemy płatnicze, repozytoria kodu, CI/CD).

W jednej z dużych firm przemysłowych dopiero spojrzenie na „najstarsze i najbardziej upierdliwe do aktualizacji” systemy ujawniło, że krytyczne sterowniki linii produkcyjnej łączą się z centralnym systemem planowania z użyciem protokołu niestandardowego, zabezpieczonego kombinacją TLS 1.0 i własnego szyfrowania na bazie RSA‑1024. Analiza od strony „publicznych endpointów” nigdy by tego nie odsłoniła.

Typowe „ciemne miejsca” w inwentaryzacji kryptografii

Nawet przy rzetelnym podejściu część obszarów zostaje pominięta, bo nie kojarzą się z klasycznym „szyfrowaniem danych”. Najczęstsze przykłady:

• tokeny i sesje aplikacyjne – JWT, SAML, tokeny OAuth, bilety Kerberos, sesje podpisywane kluczem aplikacyjnym. Często używają kluczy długo żyjących, które po przejęciu mogą umożliwić fałszowanie tożsamości.
• mechanizmy licencjonowania i aktywacji – podpisy cyfrowe lub szyfrowanie używane do kontroli licencji bywa wdrażane „poza standardami” i nie aktualizowane przez lata.
• szyfrowanie w backupach i archiwach – narzędzia do backupu, które od dawna działają „same z siebie”, nierzadko korzystają z domyślnych, słabszych parametrów lub własnych formatów kontenerów szyfrowanych.
• komunikacja M2M i „protokół własny” – różnego rodzaju tunelowanie, szyfrowanie na poziomie aplikacji, autorskie implementacje TLS/SSH, biblioteki „CryptoX.jar” napisane kiedyś na wewnętrzne potrzeby.
• kanały administracyjne – zdalne zarządzanie urządzeniami (zarówno przez operatorów, jak i vendorów), przeważnie z silnym uwierzytelnieniem, ale nie zawsze z aktualnymi protokołami.

Te obszary są istotne nie tylko przez ryzyko bezpośredniego złamania, lecz także dlatego, że zwykle bardzo trudno je aktualizować. To dokładnie ta kategoria, gdzie czas migracji łatwo zbliża się do horyzontu poufności.

Jak rozmawiać z dostawcami o kryptografii (bez popadania w marketing „quantum ready”)

Znaczna część kryptografii w organizacji jest de facto zarządzana przez dostawców: producentów sprzętu, dostawców SaaS/PaaS, integratorów. Tu pojawia się kolejny problem: odpowiedzi typu „jesteśmy quantum ready” lub „stosujemy najnowsze standardy” nie zawierają informacji potrzebnych do rzetelnej oceny ryzyka.

Przydaje się zestaw konkretnych pytań, które można wpisać do RFI/RFP lub rozmów technicznych:

• Jakich algorytmów klucza publicznego używacie dziś (RSA, ECC – które krzywe, jakie długości)?
• Czy macie plany wsparcia PQC (konkretnie: NIST‑PQC – które algorytmy, w jakim horyzoncie czasowym, z jakimi ograniczeniami)?
• Czy interfejsy/protokoły są projektowane z myślą o algorytmic agility (możliwość dołożenia PQC/hybrydy bez zmiany protokołu „od zera”)?
• Jak wygląda cykl życia kluczy (generowanie, rotacja, przechowywanie, HSM/KMS) i czy uwzględnia scenariusz przejścia na PQC?
• Jakie są zewnętrzne certyfikacje lub audyty (FIPS, Common Criteria, raporty niezależnych firm), które dotykają obszaru kryptografii?

Jeśli dostawca nie jest w stanie udzielić precyzyjnych odpowiedzi lub unika tematu PQC, oznacza to po prostu, że organizacja nie ma kontroli nad istotnym fragmentem swojego łańcucha zaufania. To nie dyskwalifikuje automatycznie rozwiązania, ale powinno znaleźć odzwierciedlenie w mapie ryzyka i planach migracji.

Narzędzia automatyczne kontra ręczna analiza: gdzie przebiega granica

Naturalny odruch to „kupić skaner”, który w magiczny sposób zinwentaryzuje kryptografię w całej organizacji. Automatyzacja jest potrzebna, ale ma wyraźne granice:

• skanery protokołów dobrze sprawdzają konfigurację TLS/SSH/IPsec, ale nie wiedzą nic o tym, co dzieje się wewnątrz aplikacji (np. jak są szyfrowane pola w bazie danych, jak wygląda podpis JWT);
• analiza kodu statycznego pozwala wykryć wywołania kryptografii w repozytoriach, ale zwykle nie rozumie całego kontekstu (np. długości kluczy przekazywanej parametrami konfiguracyjnymi);
• narzędzia SCA (Software Composition Analysis) pokażą, że projekt używa np. OpenSSL 1.1.1, ale nie powiedzą, które dokładnie funkcje i tryby szyfrowania są aktywnie używane.

Granica zwykle przebiega tam, gdzie wchodzi logika biznesowa i specyficzne protokoły wewnętrzne. Tam konieczna jest ręczna analiza architektury, dokumentacji oraz rozmowy z zespołami deweloperskimi i administratorami. Z perspektywy postkwantowej te właśnie „niestandardowe” fragmenty często są najbardziej kłopotliwe przy migracji.

Priorytetyzacja luk postkwantowych: nie wszystko trzeba ruszać od razu

Po pierwszym pełniejszym spisie kryptografii pojawia się inny problem: lista potencjalnych zmian jest tak długa, że paraliżuje działanie. Potrzebne jest ostre cięcie według kryteriów ryzyka postkwantowego, a nie według „brzydoty” technologicznej.

Jednym z prostszych modeli priorytetyzacji jest macierz łącząca trzy wymiary:

• znaczenie biznesowe – jakie dane lub procesy chroni dany mechanizm (i z jakim horyzontem poufności);
• rola w łańcuchu zaufania – czy jego złamanie pozwoli „podrobić” inne komponenty (CA, SSO, podpisy kodu);
• czas potrzebny na migrację – jak trudne będzie wprowadzenie zmian (dostęp do kodu, zależność od vendorów, cykle life‑cycle urządzeń).

System z niskim znaczeniem biznesowym, małym wpływem na łańcuch zaufania i łatwą ścieżką aktualizacji może spokojnie poczekać. Z kolei komponent z wysoką krytycznością i długim horyzontem poufności, którego zmiana wymaga wieloletnich projektów (np. wymiana urządzeń w terenie), powinien trafić na szczyt listy, nawet jeśli „technicznie” dziś jeszcze działa poprawnie.

Łączenie inwentaryzacji PQC z innymi porządkami w bezpieczeństwie

Ryzyko postkwantowe rzadko występuje w izolacji. Tam, gdzie kryptografia jest przestarzała, zwykle znajdą się też inne problemy: brak rotacji kluczy, słabe procedury backupu, braki w logowaniu czy brak aktualizacji bezpieczeństwa. Łączenie inwentaryzacji PQC z innymi inicjatywami porządkowymi bywa skuteczniejsze niż osobny, „modny” projekt postkwantowy.

Przykładowe synergie:

• projekty Zero Trust / modernizacja tożsamości – przy wymianie SSO, federacji i IAM i tak dotyka się kluczy i protokołów; można od razu ocenić, jak te komponenty przejdą na PQC;
• modernizacja PKI – migracja z wewnętrznych CA „samoróbek” na zarządzane rozwiązania to moment, kiedy łatwiej dodać algorytmic agility i przygotować strukturę pod PQC;
• upgrade infrastruktury sieciowej – wymiana firewalli, VPN, load balancerów to okazja, by sprawdzić wsparcie dla hybryd TLS oraz plan vendorski dotyczący PQC.

Z perspektywy zarządu lepiej brzmi plan: „porządkujemy PKI i przygotowujemy ją na PQC” niż „robimy osobny projekt postkwantowy”. Z perspektywy bezpieczeństwa rezultat bywa ten sam, o ile priorytety są ułożone z uwzględnieniem realnych horyzontów poufności i czasu migracji.

Najczęściej zadawane pytania (FAQ)

Co to znaczy, że kryptografia jest „quantum safe” (postkwantowa)?

Określenie „quantum safe” odnosi się do algorytmów i architektur kryptograficznych zaprojektowanych tak, aby były odporne zarówno na ataki klasyczne, jak i na ataki z użyciem realnych komputerów kwantowych. Chodzi głównie o zastąpienie lub uzupełnienie dzisiejszych algorytmów asymetrycznych (RSA, ECC) takimi mechanizmami, których nie da się praktycznie złamać przy użyciu algorytmu Shora.

Nie oznacza to „100% bezpieczeństwa na 50 lat”, tylko zmniejszenie konkretnego rodzaju ryzyka. Algorytmy postkwantowe nadal są badane, pojawiają się nowe ataki kryptograficzne, a standardy (np. NIST) wciąż się stabilizują. „Quantum safe” to raczej kierunek i proces niż pojedynczy produkt z naklejką PQC.

Kiedy komputery kwantowe realnie zagrożą RSA i ECC?

Dostępne analizy sugerują horyzont raczej lat niż dziesięcioleci – szacunki 5–15 lat pojawiają się najczęściej, ale z dużym marginesem błędu. Nikt nie ma twardej daty: przejście od demonstracji laboratoryjnych do stabilnych, skalowalnych maszyn zdolnych łamać praktyczne długości kluczy RSA/ECC to nadal otwarty problem inżynieryjny.

Dla planowania w firmie ważniejsze jest inne pytanie: jak długo muszą pozostać poufne twoje dane i jak długo żyją twoje systemy. Jeśli system ma stać w produkcji 10–15 lat, a dane muszą być tajne równie długo, to odkładanie tematu „aż kwanty będą bliżej” zwyczajnie sprawi, że obudzisz się za późno.

Jakie algorytmy szyfrowania są najbardziej zagrożone przez komputery kwantowe?

Głównym celem są algorytmy asymetryczne oparte na faktoryzacji i logarytmie dyskretnym: przede wszystkim RSA i standardowe krzywe eliptyczne (ECC). To one stoją za:

• certyfikatami TLS/HTTPS i VPN (IPsec/SSL),
• podpisami cyfrowymi dokumentów i kodu,
• S/MIME, SSH z kluczami RSA/ECDSA,
• certyfikatami urządzeń IoT i wewnętrznymi CA.

Kryptografia symetryczna (np. AES) i funkcje skrótu są w lepszej sytuacji. Algorytm Grovera przyspiesza atak „brute force”, ale nie łamie konstrukcji wprost. W praktyce oznacza to konieczność stosowania dłuższych kluczy (np. AES‑256 zamiast AES‑128), a nie rewolucję całej technologii.

Na czym polega atak „harvest now, decrypt later” i czy powinienem się nim przejmować?

Model „harvest now, decrypt later” zakłada, że atakujący dziś masowo przechwytuje zaszyfrowany ruch (TLS, VPN, S/MIME itp.), archiwizuje go, a odszyfrowaniem zajmie się dopiero wtedy, gdy pojawi się odpowiednio silny komputer kwantowy. Nie musi więc łamać kryptografii w czasie rzeczywistym.

Ten scenariusz jest szczególnie istotny, jeśli:

• twoje dane mają długi wymagany czas poufności (10+ lat),
• jesteś realistycznym celem dobrze finansowanych przeciwników (wywiady państwowe, duże grupy przestępcze),
• korzystasz intensywnie z RSA/ECC w transmisji i uwierzytelnianiu.

Dla lokalnego e‑sklepu ryzyko zwykle jest niższe niż dla banku czy firmy z cennym IP. Ale jeśli wiesz, że ktoś mógłby chcieć archiwizować twoje szyfrowane komunikaty, to przygotowania do „quantum safe” są tematem na dziś, nie na „kiedyś”.

Kto naprawdę powinien spieszyć się z wdrożeniem kryptografii postkwantowej?

Największą presję czasu mają organizacje, które łączą trzy cechy: bardzo długi horyzont poufności danych, silnych przeciwników oraz infrastrukturę o długim cyklu życia. Typowo są to:

• administracja publiczna, obrona, służby – dane wywiadowcze, rejestry obywateli, komunikacja dyplomatyczna, tajemnice państwowe,
• sektor finansowy – transakcje, klucze infrastruktury płatniczej, podpisy transakcyjne,
• ochrona zdrowia – dokumentacja medyczna przechowywana dekadami,
• R&D, high‑tech – własność intelektualna, projekty, plany produktów.

Firmy handlowe, typowy e‑commerce czy mniejsze usługi B2C zwykle mają więcej czasu i mogą podejść do tematu ewolucyjnie: zacząć uwzględniać wymagania postkwantowe w nowych systemach, zamiast robić gwałtowne migracje całej infrastruktury w ciągu roku.

Jak praktycznie przygotować firmę na kryptografię postkwantową bez paniki?

Punkt startowy to inwentaryzacja: ustalenie, gdzie w twojej infrastrukturze występują RSA i ECC (TLS, VPN, PKI, podpis kodu, IoT, poczta, systemy partnerskie). Bez tej mapy każda „strategia kvantowa” będzie zgadywaniem. Kolejny krok to ocena, które systemy mają najdłuższy czas życia i obsługują dane o wysokiej wrażliwości.

Dalsze działania zwykle obejmują:

• włączanie wymagań „crypto‑agile” w nowe projekty (możliwość łatwej podmiany algorytmów),
• przejście na mocniejsze parametry w kryptografii symetrycznej (np. AES‑256),
• śledzenie i wdrażanie standardów z NIST, ETSI, IETF zamiast pojedynczych „magicznych” rozwiązań vendorów,
• pilotaże rozwiązań hybrydowych (klasyczne + postkwantowe mechanizmy w jednym protokole), gdy standardy dojrzeją.

Kluczowa jest sekwencja: najpierw świadomość i plan, dopiero potem zakupy produktów z etykietą „PQC”. Odwrotna kolejność to typowa pułapka.

Jak rozpoznać marketing strachu wokół „quantum safe” i uniknąć przepłacania?

Czerwonym sygnałem są obietnice typu „w 100% odporne na komputery kwantowe”, „gwarancja bezpieczeństwa na 50 lat” czy „jedno wdrożenie i temat kryptografii masz z głowy”. W świecie, w którym algorytmy wciąż są badane, a nowe ataki regularnie się pojawiają, takie deklaracje są mało wiarygodne.

Rozsądne podejście opiera się na:

• standardach i rekomendacjach (NIST, ETSI, IETF, ENISA) zamiast autorskich „przełomów”,
• transparentnej analizie ryzyka zamiast straszenia „jutro wszystkie wasze dane wyciekną”,

Źródła

• Post-Quantum Cryptography: Finalist Algorithms. National Institute of Standards and Technology (NIST) (2022) – Przegląd i wybór algorytmów postkwantowych, kontekst migracji PQC
• NISTIR 8105: Report on Post-Quantum Cryptography. National Institute of Standards and Technology (NIST) (2016) – Analiza zagrożeń dla RSA/ECC, opis algorytmów Shora i Grovera
• ETSI GR QSC 001: Quantum-Safe Cryptography and Security. European Telecommunications Standards Institute (ETSI) (2015) – Rekomendacje migracji do kryptografii odpornej na komputery kwantowe