Kiedy komputery kwantowe złamią szyfrowanie RSA? Terminy, zagrożenia i plan działania dla IT

Wyobraź sobie zamek w drzwiach do skarbca, którego dorobienie klasycznymi metodami zajęłoby ślusarzowi więcej czasu, niż wynosi wiek wszechświata. Szyfrowanie RSA przez dziesięciolecia działało dokładnie w ten sposób. Oparto na nim fundamenty współczesnego bezpieczeństwa cyfrowego: od bezpiecznych połączeń ze stronami banków, przez weryfikację aktualizacji oprogramowania, po poufną komunikację korporacyjną. Mechanika tego zabezpieczenia wydawała się nie do podważenia, dopóki w fizyce komputerowej nie zaczęto przenosić praw mechaniki kwantowej ze sfery teorii do działających układów scalonych.

Problem polega na tym, że maszyny kwantowe nie rywalizują z klasycznymi serwerami w próbie „szybszego zgadywania” haseł. one grają w zupełnie inną grę matemayczną. Zrozumienie, w którym momencie ta technologiczna zmiana przestanie być eksperymentem naukowym, a stanie się wyzwaniem dla infrastruktury IT, wymaga odrzucenia nagłówków z serwisów informacyjnych i przyjrzenia się twardym realiom architektonicznym.

RSA pod presją komputerów kwantowych: co naprawdę jest zagrożone?

Podstawą bezpieczeństwa algorytmu RSA jest asymetria trudności dwóch prostych operacji matematycznych. Pomnożenie dwóch bardzo dużych liczb pierwszych jest dla klasycznego procesora zadaniem natychmiastowym. Rozłożenie wyniku tego mnożenia z powrotem na czynniki pierwsze (operacja zwana faktoryzacją) bez znajomości jednego z nich jest natomiast ekstremalnie trudne. Klasyczne komputery potrafią rozwiązywać to zadanie jedynie poprzez sprawdzanie ogromnej liczby możliwości, co przy długości klucza wynoszącej 2048 lub 4096 bitów wymagałoby tysięcy lat pracy potężnych superkomputerów.

Kiedy mówimy o zagrożeniu kwantowym, na scenę wkracza algorytm Shora. Opracowany w 1994 roku przez Petera Shora wzór matematyczny udowodnił, że komputery wykorzystujące właściwości kwantowe – takie jak superpozycja i interferencja – mogą faktoryzować duże liczby w czasie wielomianowym. Oznacza to dramatyczne skrócenie czasu potrzebnego na złamanie klucza. Zamiast tysięcy lat, odpowiednio sprawna maszyna kwantowa mogłaby złamać RSA w kilkanaście minut lub godzin.

Dlaczego RSA działa w klasycznym świecie

W środowisku klasycznym RSA służy przede wszystkim do dwóch celów: bezpiecznego uzgadniania klucza szyfrującego oraz składania podpisów cyfrowych. Gdy łączysz się ze stroną internetową przez protokół TLS, RSA (lub algorytmy oparte na krzywych eliptycznych, takie jak ECC) pozwala Twojej przeglądarce i serwerowi potwierdzić swoją tożsamość oraz bezpiecznie ustalić wspólny klucz dla symetrycznego szyfrowania AES. Podobnie wygląda kwestia podpisów oprogramowania – cyfrowa pieczęć na pliku wykonywalnym gwarantuje, że kod nie został zmodyfikowany przez osoby trzecie.

Warto wyraźnie rozróżnić dwa typy kryptografii:

• Kryptografia asymetryczna (RSA, ECC): opiera się na trudnych problemach matematycznych (faktoryzacja, logarytm dyskretny), które algorytm Shora potrafi skutecznie rozwiązywać. To ta gałąź jest bezpośrednio zagrożona całkowitym złamaniem.
• Kryptografia symetryczna (AES-128, AES-256): używa tego samego klucza do szyfrowania i odszyfrowywania. Komputery kwantowe zagrażają jej w mniejszym stopniu – algorytm Grovera pozwala przyspieszyć przeszukiwanie kluczy symetrycznych, ale jedynie zmniejsza efektywną siłę klucza o połowę. Oznacza to, że przejście z AES-128 na AES-256 zapewnia pełne bezpieczeństwo przed komputerami kwantowymi na dający się przewidzieć czas.

Kluczowym problemem dla działów IT jest fakt, że cała architektura zaufania w sieci – od certyfikatów X.509, przez dostępowy protokół SSH, po połączenia IPsec VPN – została zbudowana właśnie na kryptografii asymetrycznej. Jeśli fundament w postaci RSA upadnie, zawali się cała struktura zbudowanego na nim zaufania cyfrowego.

Wskazówka 1. Nie pytaj o jedną datę „upadku RSA” — buduj scenariusze ryzyka

Wokół tematu komputerów kwantowych powróciło pojęcie przypominające dawny „problem roku 2000” (Y2K). Często słyszy się pytania o konkretny rok, w którym RSA „zostanie oficjalnie wyłączone”. Szukanie jednej magicznej daty jest jednak błędem

— zagrożenie nie pojawi się bowiem w jednym, przewidywalnym momencie. Między demonstracją laboratoryjną a maszyną zdolną do złamania RSA-2048 stoi jeszcze długa droga: potrzeba dużej liczby logicznych kubitów, skutecznej korekcji błędów, stabilnego sprzętu oraz możliwości prowadzenia obliczeń wystarczająco długo. Dzisiejsze komputery kwantowe nie potrafią jeszcze realizować takiego ataku, ale infrastruktury kryptograficznej nie wymienia się z tygodnia na tydzień. Certyfikaty, urządzenia przemysłowe, systemy bankowe i aplikacje działające w terenie często mają cykl życia liczony w latach.

Rozsądniej jest więc pracować na scenariuszach. W wariancie ostrożnym organizacja zakłada, że przełom nastąpi później, niż przewidują najgłośniejsze zapowiedzi producentów sprzętu. W wariancie konserwatywnym przyjmuje, że przeciwnik dysponujący odpowiednią maszyną może pojawić się wcześniej, niż rynek zdąży wymienić certyfikaty, moduły HSM i oprogramowanie układowe. Nie chodzi o przewidywanie przyszłości z dokładnością do roku. Chodzi o odpowiedź na prostsze pytanie: ile czasu potrzebuje firma, aby wymienić kryptografię tam, gdzie zmiana będzie najtrudniejsza?

Dobrym punktem odniesienia jest pojęcie CRQC, czyli kryptograficznie istotnego komputera kwantowego. To nie dowolna maszyna kwantowa prezentowana w laboratorium, lecz system zdolny praktycznie złamać powszechnie używany algorytm asymetryczny. Ryzyko trzeba zestawić z okresem poufności danych. Jeśli dokumentacja projektowa, dane medyczne, tajemnice handlowe albo klucze do infrastruktury mają pozostać tajne przez wiele lat, migrację należy rozpocząć dużo przed pojawieniem się CRQC. Gdy dach zaczyna przeciekać, jest już za późno na spokojne projektowanie całego budynku.

RSA nie zniknie z dnia na dzień, lecz czas potrzebny na przygotowanie bezpiecznej migracji może okazać się dłuższy niż czas pozostały do realnego zagrożenia. Organizacja, która już teraz rozumie, gdzie używa kryptografii, jak długo chroni dane i jak wymienia algorytmy, zyska wybór zamiast działania pod presją.

Wskazówka 2. Zacznij od zagrożenia „zbierz dziś, odszyfruj później”

Wielu menedżerów IT popełnia błąd, zakładając, że złamanie RSA stanie się groźne dopiero wtedy, gdy sprawny komputer kwantowy fizycznie stanie w serwerowni atakującego. W rzeczywistości wektor ataku znany jako HNDL (Harvest Now, Decrypt Later) działa już teraz. Polega on na masowym przechwytywaniu i archiwizowaniu zaszyfrowanego ruchu sieciowego przez zagraniczne agencje wywiadowcze lub zorganizowane grupy przestępcze.

Atakujący nie potrafią odczytać tych danych dzisiaj, ale odkładają je na dyskach z myślą o momencie, w którym uruchomią algorytm Shora na maszynie klasy CRQC. Jeśli przesłane dziś informacje będą miały wartość biznesową, prawną lub strategiczną za 10 czy 15 lat, to bezpieczeństwo transakcji zostało złamane w momencie jej przechwycenia.

Przykładem są wrażliwe dane medyczne pacjentów, dokumentacja techniczna nowych patentaów czy poufne umowy handlowe. Jeśli ruch TLS zabezpieczający transakcję wykorzystuje algorytm RSA do wymiany kluczy, przechwycona dzisiaj sesja zostanie w przyszłości bez problemu odszyfrowana. Dlatego oceniając priorytety, nie zaczynaj od ochrony danych o krótkim czasie przydatności (jak jednorazowe kody SMS), lecz od kanałów przesyłających informacje o długim okresie poufności.

Wskazówka 3. Sporządź mapę kryptografii, zanim ogłosisz migrację

Nie można wymienić mechanizmów obronnych, nie wiedząc, gdzie dokładnie zostały wdrożone. Większość organizacji nie posiada inwentaryzacji używanej kryptografii (tzw. CBOM – Cryptographic Bill of Materials). RSA oraz algorytmy oparte na krzywych eliptycznych są często ukryte głęboko w zewnętrznych bibliotekach, archaicznych urządzeniach sieciowych czy kodzie aplikacji napisanych przez podwykonawców lata temu.

Zanim zaczniesz planować budżet na migrację postkwantową, wykonaj audyt ukierunkowany na identyfikację miejsc użycia algorytmów asymetrycznych. Zwróć szczególną uwagę na:

• Klucze zaszyte w kodzie i oprogramowaniu układowym (firmware): Urządzenia IoT, czujniki przemysłowe i stare moduły HSM często nie mają możliwości zdalnej aktualizacji algorytmów.
• Certyfikaty tożsamości i podpisy cyfrowe: Klucze główne CA, wewnętrzne PKI oraz certyfikaty SSL/TLS używane do komunikacji miedzy mikroserwisami.
• Zależności od firm trzecich: Usługi SaaS i partnerzy B2B, z którymi łączysz się przez szyfrowane tuneles IPsec lub interfejsy API.

Praktyczny sens tego kroku jest prosty: wykrycie klucza RSA-2048 zaszytego w mikrooprogramowaniu sterownika przemysłowego w momencie wycofania wsparcia dla RSA oznacza katastrofę. Wykrycie go dzisiaj daje czas na zaplanowanie wymiany sprzętu w ramach standardowego cyklu amortyzacji.

Wskazówka 4. Projektuj „crypto agility”, a nie jednorazową wymianę RSA na nowy algorytm

Zastąpienie RSA jednym konkretnym algorytmem postkwantowym (PQC) jest pułapką architektoniczną. Proces standaryzacji nowych algorytmów przez instytuty takie jak NIST (np. standardy ML-KEM czy ML-DSA) postępuje szybko, ale historia kryptografii pokazuje, że nowe matematyczne konstrukcje mogą ujawnić nieprzewidziane podatności już po wdrożeniu.

Rozwiązaniem jest elastyczność kryptograficzna (crypto agility). Oznacza to projektowanie systemów w taki sposób, aby zmiana algorytmu szyfrującego, długości klucza lub biblioteki matematycznej nie wymagała przepisywania całej aplikacji od zera ani przebudowy infrastruktury.

W praktyce programistycznej oznacza to oddzielenie logiki biznesowej od logiki bezpieczeństwa za pomocą warstw abstrakcji (API kryptograficznego). Gdy algorytm używany do zabezpieczania danych wyjdzie z użycia lub okaże się podatny na nowy typ ataku, zmiana powinna sprowadzać się do modyfikacji konfiguracji lub podmienienia jednej biblioteki, a nie ponownej kompilacji całego systemu.

Wskazówka 5. Wdróż podejście hybrydowe i przetestuj algorytmy PQC już teraz

Bezpieczna migracja z RSA na algorytmy odporne na komputery kwantowe nie nastąpi w trybie jednorazowego przełączenia. Nowe algorytmy kryptografii postkwantowej opierają się na innych problemach matematycznych (np. teorii krat), co sprawia, że generowane przez nie klucze i podpisy są znacznie większe, a operacje mogą być bardziej obciążające dla procesora.

Najbezpieczniejszym punktem wyjścia jest kryptografia hybrydowa. Polega ona na łączeniu sprawdzonych algorytmów klasycznych (np. ECC lub RSA) z nowymi standardami postkwantowymi w ramach jednej operacji szyfrowania lub wymiany klucza. Jeśli w nowym algorytmie PQC zostanie odnaleziona podatność klasyczna, dane wciąż chroni RSA. Jeśli komputery kwantowe osiągną dojrzałość, ochronę zapewnia komponent postkwantowy.

Nie czekaj na gotowe produkty komercyjne. Już teraz uruchom w środowisku testowym (sandbox) pilotażowe połączenia TLS wykorzystujące hybrydową wymianę kluczy. Sprawdź, jak większy rozmiar pakietów wpływa na opóźnienia w sieci, wydajność zapór sieciowych (firewall) oraz obciążenie serwerów aplikacji.

Plan działania dla IT: podsumowanie kroków

Zagrożenie kwantowe dla algorytmu RSA nie wymaga paniki, ale wymaga systematyczności. Przejście na bezpieczne mechanizmy kryptograficzne to największa zmiana architektoniczna w historii bezpieczeństwa cyfrowego.

Organizacje, które wyjdą z tego procesu zwycięsko, wykonają cztery proste zadania: zidentyfikują dane wymagające długoterminowej poufności przed atakami HNDL, skatalogują posiadaną kryptografię, wprowadzą warstwy abstrakcji w kodzie oraz przetestują rozwiązania hybrydowe w działaniu. Czas na wykonanie tych kroków jest teraz — zanim komputery kwantowe zaczną dyktować warunki gry.

1. Faza 1: Ocena podatności i priorytetyzacja danych – Identyfikacja zasobów informacyjnych o długim cyklu poufności narażonych na atak HNDL oraz określenie ich krytyczności dla organizacji.
2. Faza 2: Budowa rejestru CBOM – Skanowanie kodu źródłowego, bibliotek zewnętrznych, certyfikatów PKI oraz urządzeń sprzętowych w celu stworzenia kompletnej mapy wykorzystywanej kryptografii asymetrycznej.
3. Faza 3: Wdrożenie warstwy abstrakcji (Crypto Agility) – Oddzielenie logiki biznesowej aplikacji od konkretnych algorytmów szyfrujących poprzez standaryzowane interfejsy API.
4. Faza 4: Testy hybrydowe i sukcesywna migracja – Uruchomienie pilotażowych połączeń z hybrydową wymianą kluczy w środowisku testowym oraz weryfikacja ich wpływu na wydajność i opóźnienia sieciowe przed finalnym wdrożeniem produkcyjnym.

Wskazówka 6. Rozdziel problem szyfrowania danych od problemu podpisów i tożsamości

RSA pełni w firmach różne role, a każda z nich wymaga nieco innego planu migracji. Może zabezpieczać wymianę kluczy, służyć do podpisywania aktualizacji oprogramowania, uwierzytelniać serwery albo potwierdzać tożsamość użytkownika. Nie wystarczy więc stwierdzenie: „wymieniamy RSA”. Trzeba ustalić, gdzie i do czego jest wykorzystywane.

Szczególnie wymagające są podpisy cyfrowe. Zaszyfrowany ruch można często objąć nowym mechanizmem przy kolejnym zestawieniu połączenia, ale podpisany dokument, obraz firmware’u lub archiwum może pozostać w obiegu przez długi czas. Jeśli organizacja przechowuje podpisane umowy, repozytoria kodu albo aktualizacje urządzeń, powinna określić zasady ich ponownego podpisywania oraz weryfikacji historycznej.

Wyobraźmy sobie sterownik, który przed instalacją nowego oprogramowania sprawdza podpis producenta. Jeżeli urządzenie rozumie wyłącznie jeden stary format podpisu, sama zmiana certyfikatu po stronie producenta niczego nie rozwiąże. Potrzebna będzie aktualizacja mechanizmu weryfikacji, a czasem nawet wymiana sprzętu. Takie zależności najlepiej wykryć podczas inwentaryzacji, nie w dniu awarii lub audytu.

W planie migracji dobrze jest prowadzić osobne strumienie prac dla: ochrony transmisji, PKI i certyfikatów, podpisywania kodu, dostępu administracyjnego, VPN-ów oraz kopii zapasowych. Dzięki temu zespół nie miesza problemu przyszłej poufności danych z problemem wiarygodności podpisu czy zgodności urządzeń.

Wskazówka 7. Ustal właścicieli, kryteria wdrożenia i drogę wycofania zmian

Migracja postkwantowa nie jest wyłącznie zadaniem dla zespołu bezpieczeństwa. Administrator PKI może wymienić certyfikaty, ale nie zmieni bez wsparcia właściciela aplikacji biblioteki zaszytej w jej kodzie. Z kolei dział zakupów może zamówić nowe urządzenia, lecz potrzebuje jednoznacznych wymagań kryptograficznych zapisanych w umowie z dostawcą.

Przy każdym istotnym systemie przypisz osobę lub zespół odpowiedzialny za decyzję migracyjną. Rejestr powinien odpowiadać na kilka praktycznych pytań: jaki algorytm jest używany, do czego służy, kto zarządza kluczami, kiedy kończy się wsparcie produktu i czy istnieje aktualizacja umożliwiająca użycie mechanizmów PQC. Bez takiej odpowiedzialności CBOM szybko staje się poprawnym, lecz martwym arkuszem.

Testy hybrydowe muszą też mieć jasne kryteria sukcesu. Samo ustanowienie połączenia TLS nie dowodzi jeszcze gotowości systemu. Trzeba sprawdzić między innymi zachowanie starszych klientów, limity rozmiaru komunikatów, działanie inspekcji ruchu, proces odnawiania certyfikatów oraz możliwość monitorowania błędów. Równie ważny jest plan wycofania zmiany. Gdy po wdrożeniu okaże się, że część urządzeń nie negocjuje nowego mechanizmu, zespół powinien umieć bezpiecznie wrócić do zatwierdzonej konfiguracji awaryjnej.

To przypomina wymianę instalacji elektrycznej w działającym budynku. Nie wystarczy kupić nowe przewody; trzeba wiedzieć, który obwód zasila krytyczne urządzenia, kto ma klucze do pomieszczeń technicznych i co zrobić, jeśli po przełączeniu zgaśnie światło w ważnej części obiektu.

Co wpisać do wymagań dla dostawców

Nowe systemy kupowane dziś mogą pozostać w organizacji dłużej, niż zakłada pierwotny harmonogram projektu. Dlatego wymagania dotyczące odporności postkwantowej powinny pojawić się już w zapytaniach ofertowych, umowach i kryteriach odbioru. Nie chodzi o żądanie natychmiastowego użycia każdego nowego algorytmu, lecz o uniknięcie zakupu technologii, której nie da się później zmodernizować.

• Możliwość aktualizacji: dostawca powinien jasno określić, czy komponent obsługuje aktualizacje oprogramowania, bibliotek kryptograficznych i mechanizmów weryfikacji podpisów.
• Jawność używanej kryptografii: produkt nie powinien ukrywać algorytmów, długości kluczy ani sposobu zarządzania certyfikatami za ogólnym hasłem „szyfrowanie klasy wojskowej”.
• Obsługa standardowych interfejsów: zamknięte, własnościowe mechanizmy utrudniają wymianę algorytmów i zwiększają ryzyko uzależnienia od jednego producenta.
• Deklarowany cykl wsparcia: ważne jest nie tylko to, co system potrafi dziś, ale także jak długo dostawca będzie dostarczał poprawki i rozwijał obsługę nowych standardów.

Takie pytania są użyteczne także wobec usług chmurowych i partnerów B2B. Jeżeli firma wymieni własną konfigurację, ale połączenie z kluczowym kontrahentem nadal będzie ograniczone przez stare urządzenie VPN, ryzyko pozostanie w łańcuchu komunikacji. Bezpieczeństwo kanału jest tak mocne, jak jego najmniej modernizowalny element.

Komputery kwantowe nie wyznaczą jednej, wygodnej daty granicznej dla RSA. Dla zespołów IT ważniejsza jest inna data: dzień, w którym organizacja zacznie porządkować swoją kryptografię, zanim zostanie do tego zmuszona. Dobrze przygotowana migracja nie polega na nerwowym porzuceniu RSA, lecz na odzyskaniu kontroli nad kluczami, certyfikatami, zależnościami i możliwością bezpiecznej zmiany technologii. To właśnie ta zdolność pozostanie najcenniejszą ochroną, niezależnie od tempa rozwoju komputerów kwantowych.