Komputery kwantowe w kryptografii: kiedy RSA przestanie chronić dane i jak wdrożyć post-quantum security?

Wyobraźmy sobie organizację, która przechowuje dzisiejszą korespondencję szyfrowaną, dokumentację medyczną, projekty technologiczne albo archiwalne umowy. System działa poprawnie, certyfikaty są ważne, a połączenia TLS mają aktualne konfiguracje. Problem polega na tym, że ktoś może skopiować zaszyfrowany ruch już teraz i spróbować go odszyfrować dopiero wtedy, gdy pojawi się wystarczająco potężny komputer kwantowy. Hasło „bezpieczne obecnie” nie musi więc oznaczać „bezpieczne przez cały wymagany okres poufności”.

Najważniejsze pytanie nie brzmi wyłącznie: kiedy RSA przestanie być bezpieczne? Równie istotne jest to, ile czasu organizacja potrzebuje na wykrycie zależności od RSA, wybór nowych algorytmów, aktualizację urządzeń, zmianę protokołów, testy i przeprowadzenie kontrolowanej migracji. Kryptografia postkwantowa nie jest pojedynczym przełącznikiem, który można aktywować w piątek po południu. To proces obejmujący architekturę, oprogramowanie, sprzęt, certyfikaty, dostawców i zarządzanie kluczami. ^[4]

RSA nie przestanie działać z dnia na dzień — problem zaczyna się dużo wcześniej

Najkrótsza odpowiedź na pytanie „kiedy RSA przestanie chronić dane?”

Nie da się wiarygodnie wskazać jednej daty, w której RSA nagle przestanie chronić wszystkie dane. Obecnie nie istnieje powszechnie dostępny komputer kwantowy zdolny do praktycznego złamania produkcyjnych kluczy RSA używanych w bankowości, administracji, chmurze czy systemach przemysłowych. Jednocześnie nie oznacza to, że można bezterminowo odłożyć migrację. Prognozy dotyczące rozwoju odpornych na błędy komputerów kwantowych obarczone są dużą niepewnością, a sama migracja dużych organizacji może trwać wiele lat.

Trzeba rozdzielić dwa momenty. Pierwszy to techniczne przełamanie algorytmu, czyli sytuacja, w której komputer kwantowy dysponuje odpowiednią liczbą logicznych kubitów, korekcją błędów i oprogramowaniem pozwalającym odzyskać klucz prywatny z klucza publicznego w praktycznym czasie. Drugi to praktyczna utrata zaufania do RSA. Może nastąpić wcześniej, gdy organizacje uznają, że ryzyko nagłego postępu technologicznego, przechwytywania danych i długiego cyklu modernizacji jest zbyt duże, aby dalej opierać na RSA nowe systemy.

Właśnie dlatego pytanie o „koniec RSA” powinno prowadzić do decyzji o rozpoczęciu przygotowań, a nie do oczekiwania na komunikat o pierwszym udanym ataku. Jeżeli firma odkryje zależność od RSA dopiero po pojawieniu się maszyny zdolnej do jego przełamania, nie będzie już migrować w spokojnych warunkach. Będzie próbowała wymienić certyfikaty, biblioteki, urządzenia, formaty podpisów i procedury pod presją czasu. Kryptografia wyjątkowo nie lubi pośpiechu, zwłaszcza gdy kluczowe urządzenie ma instrukcję aktualizacji przypominającą powieść techniczną.

Praktyczna zasada jest prosta: im dłużej dane muszą pozostać poufne lub podpis musi zachować wiarygodność, tym wcześniej trzeba rozpocząć analizę. Organizacja, która przechowuje informacje istotne przez kilka miesięcy, może mieć inny harmonogram niż podmiot chroniący dokumentację medyczną, tajemnice technologiczne, dane państwowe albo archiwa finansowe przez kilkanaście czy kilkadziesiąt lat.

Dlaczego zagrożenie dotyczy także danych zebranych dzisiaj?

Scenariusz harvest now, decrypt later, czyli „zbierz teraz, odszyfruj później”, zakłada, że atakujący przechwytuje i przechowuje zaszyfrowaną komunikację, nawet jeśli nie potrafi jej obecnie odczytać. Gdy w przyszłości uzyska odpowiednie możliwości obliczeniowe albo skradnie klucz prywatny, może wrócić do zgromadzonych materiałów. Dla danych o krótkim terminie ważności taki atak może być nieopłacalny. Dla informacji, których ujawnienie po latach nadal będzie szkodliwe, ryzyko jest znacznie poważniejsze. ^[2]

Do grupy danych długoterminowo wrażliwych mogą należeć:

• dokumentacja medyczna i informacje o stanie zdrowia,
• dane finansowe oraz historia transakcji,
• projekty nowych produktów i technologie objęte tajemnicą przedsiębiorstwa,
• umowy, dokumenty strategiczne i korespondencja zarządcza,
• dane państwowe, wojskowe i infrastrukturalne,
• klucze używane do odszyfrowywania wieloletnich archiwów,
• podpisane dokumenty, których autentyczność będzie weryfikowana w przyszłości.

Późniejsze wdrożenie kryptografii postkwantowej nie cofnie faktu, że ktoś mógł wcześniej skopiować zaszyfrowany materiał. Wymiana certyfikatu w 2035 roku zabezpieczy przyszłą komunikację, ale nie zmieni kopii przechwyconego połączenia z 2026 roku. Dlatego klasyfikacja danych powinna obejmować nie tylko ich wartość dzisiaj, lecz także wymagany okres poufności.

Przykład jest praktyczny: komunikat operacyjny, którego znaczenie wygasa po kilku godzinach, nie wymaga takiego samego planu jak dokumentacja projektu, który ma pozostać tajny do czasu uzyskania patentu, a następnie jeszcze przez wiele lat. W pierwszym przypadku kluczowe może być szybkie stosowanie aktualnych, silnych konfiguracji. W drugim trzeba ocenić, czy stosowany obecnie mechanizm wymiany kluczy nie naraża całego archiwum na przyszłe odszyfrowanie.

Co organizacja powinna ustalić na początku?

Pierwszy etap nie polega na kupieniu produktu z etykietą „quantum safe”. Trzeba najpierw ustalić, gdzie RSA faktycznie występuje i jakie zadania wykonuje. Może być używany bezpośrednio w kodzie, ale częściej pojawia się za pośrednictwem biblioteki TLS, certyfikatu serwera, bramy VPN, systemu PKI, urządzenia HSM, podpisu elektronicznego, poczty, aplikacji chmurowej albo sprzętu sieciowego.

Na początku dobrze odpowiedzieć na cztery pytania:

1. Gdzie wykorzystywana jest kryptografia asymetryczna? Czy chodzi o wymianę kluczy, podpisy, uwierzytelnianie, certyfikaty, czy kilka tych funkcji równocześnie?
2. Które dane wymagają najdłuższej ochrony? Nie wystarczy lista systemów. Potrzebna jest informacja o okresie poufności i konsekwencjach ujawnienia.
3. Czy można wymienić komponent kryptograficzny bez przebudowy systemu? Wymiana biblioteki w aplikacji może być prosta, ale zmiana algorytmu w urządzeniu przemysłowym lub podpisie zapisanym w firmware bywa znacznie trudniejsza.
4. Czy dostawcy mają plan migracji? Dotyczy to dostawców chmury, VPN, systemów ERP, urządzeń sieciowych, HSM, platform podpisu i oprogramowania używanego przez partnerów.

Odpowiedzi pozwalają odróżnić systemy wymagające natychmiastowego planu od tych, które mogą zostać objęte późniejszą falą modernizacji. Bez tej selekcji organizacja może wydać środki na pilotaż w miejscu o niewielkim znaczeniu, pomijając archiwum lub urządzenie, którego aktualizacja trwa dwa lata.

Skąd bierze się problem: komputery kwantowe uderzają w RSA inaczej niż klasyczne ataki

RSA opiera się na problemie trudnym dla klasycznych komputerów

RSA korzysta z własności dużych liczb. W uproszczeniu łatwo jest pomnożyć dwie duże liczby pierwsze, natomiast odtworzenie tych czynników na podstawie wyniku jest dla klasycznego komputera bardzo trudne, gdy liczby mają odpowiednio duży rozmiar. Na tej asymetrii opiera się konstrukcja klucza publicznego i prywatnego. Klucz publiczny można udostępniać, a klucz prywatny powinien pozostać tajny.

Nie oznacza to, że RSA jest magiczną tarczą. Złamanie matematycznych założeń algorytmu to tylko jeden z możliwych sposobów utraty bezpieczeństwa. W praktyce problemy często wynikają z kradzieży klucza prywatnego, błędów w generatorze liczb losowych, niewłaściwego przechowywania sekretów, przestarzałych protokołów, złej walidacji certyfikatów albo podatnej implementacji. Komputer kwantowy nie jest potrzebny, jeśli klucz zostanie zapisany w publicznym repozytorium lub pozostawiony na niezaszyfrowanym dysku.

Ta różnica ma znaczenie dla planu ochrony. Migracja do kryptografii postkwantowej nie zastąpi podstawowego zarządzania kluczami, segmentacji, kontroli dostępu, aktualizacji systemów i monitorowania. Algorytm odporny na znane ataki kwantowe może zostać całkowicie zniweczony przez wyciek klucza, podatność w aplikacji lub zaufanie do fałszywego certyfikatu. ^[3]

Warto przeczytać również powiązany artykuł: Praca zdalna 2030 – jakie technologie ją zdominują?.

Rola algorytmu Shora

Algorytm Shora jest kluczowym powodem, dla którego komputery kwantowe są traktowane jako zagrożenie dla RSA. W odpowiednio dużej, tolerującej błędy maszynie kwantowej może on rozwiązywać problemy matematyczne, na których opiera się faktoryzacja oraz część mechanizmów używanych przez kryptografię klucza publicznego, znacznie efektywniej niż znane algorytmy klasyczne.

Ważne jest jednak precyzyjne rozróżnienie między teorią a możliwościami obecnych urządzeń. Demonstracja działania algorytmu na małych liczbach albo eksperyment z niewielką liczbą kubitów nie oznacza, że można zaatakować certyfikat używany przez bank, serwer administracji lub urządzenie przemysłowe. Praktyczne przełamanie RSA wymagałoby dużej liczby logicznych kubitów, a nie tylko kubitów fizycznych, oraz skutecznej korekcji błędów. Różnica między tymi pojęciami jest zasadnicza: pojedynczy logiczny kubit może wymagać wielu fizycznych kubitów, zależnie od jakości sprzętu i zastosowanego kodu korekcji.

Dlatego nie należy traktować każdej informacji o „przełomowym komputerze kwantowym” jako zapowiedzi natychmiastowego końca RSA. Z drugiej strony nie można używać braku takiego ataku jako argumentu za bezczynnością. Rozwój sprzętu, korekcji błędów, kompilatorów i technik ataku może postępować nierównomiernie. Decyzje bezpieczeństwa powinny uwzględniać nie tylko najbardziej optymistyczny scenariusz, lecz także czas potrzebny na migrację i wartość chronionych danych.

RSA to nie cały krajobraz kryptografii

Kryptografia asymetryczna jest wykorzystywana między innymi do wymiany kluczy, uwierzytelniania stron połączenia i podpisów cyfrowych. RSA jest jednym z przykładów, obok kryptografii krzywych eliptycznych i innych mechanizmów opartych na problemach matematycznych, które mogą zostać zaatakowane przez odpowiednio duży komputer kwantowy. Zastąpienie RSA wyłącznie innym klasycznym algorytmem asymetrycznym nie rozwiązuje więc problemu źródłowego. ^[1]

Inaczej wygląda sytuacja szyfrowania symetrycznego, takiego jak AES, oraz funkcji skrótu. Algorytmy kwantowe mogą zmniejszyć margines bezpieczeństwa niektórych mechanizmów symetrycznych i skrótów, ale nie prowadzą do identycznego, gwałtownego scenariusza jak algorytm Shora wobec RSA. W praktyce analizuje się odpowiedni dobór długości klucza, parametrów i konstrukcji protokołu. Nie oznacza to, że można pominąć szyfrowanie symetryczne, lecz że jego migracja ma inną charakterystykę.

Od diagnozy do decyzji — jak ocenić, czy organizacja jest gotowa na post-quantum security

Po ustaleniu, gdzie występuje kryptografia asymetryczna, trzeba przejść od listy systemów do oceny zależności. Sama informacja, że aplikacja korzysta z TLS albo certyfikatu, jest zbyt ogólna. Należy wiedzieć, jaki algorytm działa w konkretnym połączeniu, kto zarządza kluczem, jak długo obowiązuje certyfikat i czy można wymienić komponent bez zmiany całego produktu.

Gotowość do migracji nie oznacza jeszcze, że wszystkie systemy używają algorytmów postkwantowych. Oznacza raczej, że organizacja:

• potrafi wskazać najważniejsze zastosowania kryptografii klucza publicznego,
• zna właścicieli systemów, kluczy, certyfikatów i procesów podpisu,
• rozumie, które dane wymagają wieloletniej ochrony,
• ma informacje o ograniczeniach technicznych i umowach z dostawcami,
• może przetestować wymianę algorytmów bez ryzyka dla produkcji,
• posiada plan reagowania na zmianę standardów lub pojawienie się nowych podatności.

Inwentaryzacja musi pokazywać zależności, a nie tylko nazwy produktów

Najbardziej użyteczny inwentarz kryptograficzny nie jest prostą listą serwerów. Powinien pokazywać relacje między aplikacją, protokołem, biblioteką, certyfikatem, urządzeniem i procesem biznesowym. W przeciwnym razie można wiedzieć, że organizacja ma kilkaset certyfikatów, ale nadal nie wiedzieć, które z nich są osadzone w aplikacji mobilnej, które są generowane przez HSM, a które znajdują się w urządzeniach, których producent nie przewidział do aktualizacji.

Dla każdego istotnego zastosowania warto zapisać co najmniej:

• system lub urządzenie, w którym używany jest mechanizm kryptograficzny,
• algorytm, parametry, biblioteki i wersje oprogramowania,
• funkcję algorytmu: wymiana kluczy, szyfrowanie, podpis, uwierzytelnianie lub integralność,
• miejsce przechowywania kluczy i sposób ich rotacji,
• zależności od certyfikatów, urzędów certyfikacji i zewnętrznych usług,
• właściciela technicznego oraz właściciela biznesowego,
• czas potrzebny na zmianę konfiguracji lub aktualizację komponentu,
• konsekwencje niedostępności systemu podczas migracji.

Warto uzupełnić taką ewidencję o informacje z kilku źródeł: skanowanie konfiguracji, analizę kodu, dane z systemów PKI i HSM, dokumentację dostawców, wyniki testów oraz rozmowy z zespołami utrzymującymi aplikacje. Żadne pojedyncze źródło nie daje pełnego obrazu. Automatyczne narzędzie może wykryć certyfikat RSA, ale nie zawsze rozpozna klucz zapisany w firmware, algorytm dostarczany przez bibliotekę aplikacyjną albo format podpisu obsługiwany przez system partnera.

Klasyfikacja danych wyznacza kolejność działań

Nie każdy system wymaga migracji w tym samym terminie. Priorytet powinien wynikać z połączenia kilku czynników: czasu wymaganego zachowania poufności, wartości danych, ekspozycji systemu, trudności wymiany komponentu oraz długości cyklu życia rozwiązania.

Wysoki priorytet mają zwykle systemy, które jednocześnie chronią dane o długim okresie wrażliwości i korzystają z mechanizmów klucza publicznego podczas transmisji lub archiwizacji. Dotyczy to na przykład kanałów między organizacjami, repozytoriów dokumentów strategicznych, systemów zarządzających długowiecznymi kluczami oraz urządzeń wdrażanych na wiele lat bez łatwej możliwości aktualizacji.

Przydatny może być prosty model oceny. Każdemu systemowi przypisuje się ocenę w kilku kategoriach:

1. Okres ochrony danych — od krótkotrwałej wartości do poufności wymaganej przez dziesięciolecia.
2. Znaczenie biznesowe — od systemu pomocniczego do procesu, którego awaria zatrzymuje działalność.
3. Ekspozycja — od środowiska izolowanego do publicznie dostępnej usługi lub kanału z wieloma partnerami.
4. Trudność migracji — od wymiany konfiguracji do zmiany sprzętu, firmware’u, formatu danych lub umów.
5. Zależność od dostawcy — od pełnej kontroli wewnętrznej do produktu, dla którego termin aktualizacji jest nieznany.

Wynik nie musi być skomplikowanym modelem matematycznym. Jego celem jest uzasadnienie kolejności prac. System o wysokiej wartości danych i długim cyklu życia powinien trafić do planu wcześniej niż usługa, której informacje tracą znaczenie po kilku godzinach, nawet jeśli ta druga jest łatwiejsza do zaktualizowania.

Jeśli chcesz pogłębić ten wątek, sprawdź też: Cyberbezpieczeństwa do 2030 roku: prognozy ekspertów.

Wybór technologii powinien uwzględniać funkcję, a nie tylko etykietę „post-quantum”

Kryptografia postkwantowa obejmuje różne mechanizmy i zastosowania. Innego rozwiązania wymaga uzgadnianie klucza w połączeniu sieciowym, innego podpis kodu, a jeszcze innego długoterminowa walidacja dokumentów. Nie należy więc pytać wyłącznie, czy produkt jest „odporny na komputery kwantowe”. Trzeba ustalić, jaką funkcję realizuje dany algorytm, jaki ma profil wydajności i czy pasuje do istniejącego protokołu.

W praktyce ocenia się między innymi:

• rozmiar kluczy publicznych, kluczy prywatnych i podpisów,
• czas generowania kluczy, wykonywania operacji i weryfikacji,
• zużycie pamięci oraz przepustowość,
• zgodność z używanymi protokołami i bibliotekami,
• bezpieczeństwo implementacji i dostępność niezależnych audytów,
• wsparcie w HSM, modułach TPM, urządzeniach sieciowych i systemach chmurowych,
• status standaryzacji oraz plan utrzymania rozwiązania przez dostawcę.

W mechanizmach wymiany kluczy często rozważa się konfiguracje hybrydowe, w których klasyczny mechanizm i mechanizm postkwantowy współpracują w jednym protokole. Ich sens polega na ograniczeniu ryzyka związanego z nieznaną jeszcze słabością jednego z komponentów, ale hybryda nie jest automatycznie bezpieczna. Trzeba sprawdzić, czy protokół prawidłowo łączy wyniki obu mechanizmów, czy implementacje nie obniżają bezpieczeństwa oraz czy obie strony połączenia obsługują tę samą konfigurację.

W obszarze podpisów kryteria są inne. Duży podpis może być akceptowalny w procesie podpisywania artefaktów oprogramowania, ale problematyczny w certyfikacie przesyłanym przez urządzenie o ograniczonej pamięci. Z kolei dokument podpisywany na wiele lat wymaga nie tylko algorytmu, lecz także wiarygodnego procesu znakowania czasem, przechowywania materiału dowodowego i późniejszej weryfikacji.

Jak przełożyć ocenę na kontrolowany plan migracji?

Najbezpieczniej traktować migrację jako program kilku powiązanych działań, a nie pojedynczą zmianę parametru w konfiguracji. Plan powinien obejmować środowiska testowe, pilotaż, pomiar skutków, wdrożenie etapowe oraz możliwość powrotu do poprzedniej konfiguracji, jeśli nowy mechanizm spowoduje problemy operacyjne.

Najpierw trzeba przygotować crypto-agility

Crypto-agility, czyli zdolność do wymiany algorytmu bez przebudowy całej aplikacji, jest jednym z najważniejszych celów przygotowań. W systemie o słabej elastyczności algorytm bywa zapisany w wielu miejscach: w kodzie, schemacie bazy danych, formacie certyfikatu, regułach walidacji i dokumentacji integracyjnej. Każda zmiana wymaga wtedy osobnego projektu.

Przygotowanie elastycznej architektury może obejmować:

• oddzielenie operacji kryptograficznych od logiki biznesowej,
• centralne zarządzanie politykami i konfiguracją algorytmów,
• unikanie wpisywania nazw algorytmów na stałe w wielu modułach,
• wersjonowanie formatów kluczy, certyfikatów i podpisów,
• automatyzację generowania, rotacji i unieważniania certyfikatów,
• testy zgodności dla kilku obsługiwanych konfiguracji,
• monitorowanie użycia przestarzałych algorytmów.

Elastyczność nie oznacza, że aplikacja powinna akceptować dowolny algorytm. Przeciwnie: dozwolone konfiguracje powinny być kontrolowane przez politykę bezpieczeństwa. Celem jest możliwość zaplanowanej zmiany, a nie pozostawienie szerokiego wyboru komponentom, które mogą zostać wykorzystane do obniżenia poziomu ochrony.

Pilotaż powinien sprawdzać rzeczywiste ograniczenia

Dobry pilotaż nie polega na uruchomieniu nowego algorytmu w odizolowanym laboratorium i uznaniu, że problem został rozwiązany. Powinien obejmować scenariusz zbliżony do produkcji: rzeczywisty typ klienta, rzeczywisty sposób wydawania certyfikatów, typowe obciążenie, monitoring, procedurę odnowienia oraz obsługę błędów.

W pilotażu należy zmierzyć między innymi:

• wpływ większych kluczy lub podpisów na przepustowość i opóźnienia,
• zachowanie urządzeń o ograniczonej pamięci i mocy obliczeniowej,
• zgodność z systemami partnerów i starszymi klientami,
• działanie zapasowych ścieżek komunikacji,
• możliwość odtworzenia kluczy i certyfikatów po awarii,
• reakcję systemów monitoringu, SIEM i narzędzi audytowych,
• czas potrzebny na unieważnienie oraz ponowne wydanie materiału kryptograficznego.

Warto zacząć od usługi o znaczeniu kontrolowanym, ale nie od systemu całkowicie sztucznego. Dzięki temu organizacja sprawdzi zarówno parametry techniczne, jak i współpracę zespołów, proces zatwierdzania zmian oraz komunikację z dostawcą.

Dostawcy muszą dostarczyć konkretne informacje

Ogólna deklaracja producenta, że produkt jest „quantum-ready”, nie wystarcza do planowania. Dostawca powinien wskazać, jakie komponenty obejmuje deklaracja, które wersje oprogramowania są wspierane, jakie mechanizmy są używane oraz kiedy będzie dostępna aktualizacja dla konkretnych modeli i edycji produktu.

W rozmowie z dostawcą warto zapytać:

• czy produkt wykrywa użycie RSA lub innych klasycznych mechanizmów klucza publicznego,
• czy obsługuje algorytmy postkwantowe i konfiguracje hybrydowe,
• czy zmiana algorytmu wymaga wymiany sprzętu lub migracji danych,
• jakie są ograniczenia rozmiaru kluczy, certyfikatów i podpisów,
• jak długo producent będzie dostarczał poprawki bezpieczeństwa,
• czy istnieje udokumentowana procedura aktualizacji i powrotu do poprzedniej wersji,
• jak zmiana wpływa na interoperacyjność z innymi produktami,
• czy dostawca przeprowadził testy zgodności z uznanymi profilami i standardami.

Odpowiedzi powinny trafić do dokumentacji zakupowej, umów i planów odnowienia produktów. Jeżeli urządzenie będzie działać przez kilkanaście lat, brak deklaracji dotyczącej aktualizacji kryptografii jest ryzykiem architektonicznym, a nie wyłącznie niedogodnością techniczną.

Najważniejsze wnioski

• Nie da się wskazać jednej daty, w której RSA przestanie chronić wszystkie dane.
• Komputery kwantowe mogą w przyszłości zagrozić RSA, ale obecne urządzenia nie są zdolne do praktycznego łamania produkcyjnych kluczy.
• Scenariusz „zbierz teraz, odszyfruj później” jest szczególnie istotny dla danych wymagających wieloletniej poufności.
• Przygotowania należy rozpocząć od inwentaryzacji zastosowań RSA, klasyfikacji danych i oceny zależności od dostawców.
• Kryptografia postkwantowa jest procesem obejmującym protokoły, certyfikaty, biblioteki, sprzęt, PKI i zarządzanie kluczami.
• Nowe algorytmy nie zastępują podstawowych zabezpieczeń, takich jak kontrola dostępu, aktualizacje i ochrona kluczy prywatnych.

Źródła

• [1] NIST NCCoE – Post-Quantum Cryptography — Migration to Post-Quantum Cryptography FAQ ↑
• [2] CISA, NSA i NIST – Quantum-Readiness: Migration to Post-Quantum Cryptography ↑
• [3] NIST Computer Security Resource Center – Post-Quantum Cryptography ↑
• [4] NIST – Transition to Post-Quantum Cryptography Standards — NIST IR 8547 ↑