Laboratorium 4

Zadanie bazuje na treściach Wykładu 3, dotyczących ewolucji szyfrów blokowych, konstrukcji sieci Feistela, nieliniowych skrzynek podstawieniowych S-Box algorytmu DES oraz ataków kanałami bocznymi (Side-Channel Attacks) na nowoczesne implementacje kryptograficzne. Ćwiczenie weryfikuje kierunkowe efekty uczenia się: W1 (dogłębna znajomość matematycznych podstaw kryptoanalizy różnicowej Bihama-Shamira oraz podatności implementacyjnych szyfrów blokowych), U1 (konstrukcja autorskich skryptów weryfikacji tabel różnicowych oraz pomiarów mikroarchitektonicznych w języku Python i C), U3 (analiza anomalii pamięci podręcznej Cache i korelacja czasowa odczytów), U4 (implementacja sond jądra Linux eBPF do detekcji wywołań w pamięci operacyjnej) oraz K1 (odpowiedzialność inżynierska za eliminację podatności implementacyjnych w systemach przetwarzania danych niejawnych). Wymagania normatywne obejmują standard NIST SP 800-67 (Recommendation for the Triple Data Encryption Algorithm), klasyfikację podatności CWE-208 (Observable Timing Discrepancy), CWE-327 (Use of a Broken Cryptographic Algorithm) oraz techniki matrycy MITRE ATT&CK: T1499 i T1040.

Głównym celem zadania jest zbadanie matematycznych i fizycznych słabości implementacji szyfrów symetrycznych poprzez przeprowadzenie kryptoanalizy różnicowej zredukowanego algorytmu DES oraz demonstrację ataku czasowego na pamięć podręczną (Flush and Reload Cache-Timing Attack) w tablicowej implementacji AES. Zespół studentów analizuje rozkład prawdopodobieństw par różnic wejściowych i wyjściowych skrzynek S-Box, wykazując możliwość odzyskania podklucza ostatniej rundy przy zredukowanej złożoności obliczeniowej. Demonstracja potwierdza, dlaczego historyczny algorytm DES nie zapewnia bezpieczeństwa we współczesnych systemach teleinformatycznych.

W części defensywnej celem jest zaprojektowanie stałoczasowej implementacji algorytmu odpornej na wycieki mikroarchitektoniczne oraz wdrożenie monitoringu jądra systemu Linux w oparciu o technologię eBPF. Studenci kompilują program eBPF zliczający anomalie nietrafień w pamięci podręcznej (Cache Misses) wywoływane przez proces atakujący, a także konstruują regułę korelacyjną w systemie SIEM. Końcowym rezultatem jest utwardzona biblioteka kryptograficzna oraz zestaw wskaźników detekcji wczesnego ostrzegania przed atakami kanałami bocznymi.

Węzeł Łączności Specjalnej eksploatuje historyczne moduły kryptograficzne w wydzielonym segmencie łączności telemetrycznej, gdzie ze względów kompatybilności wstecznej stosowany jest zredukowany wariant algorytmu DES. Równolegle na serwerach aplikacyjnych wdrożono bibliotekę kryptograficzną AES, która w celach optymalizacji wydajnościowej wykorzystuje prekompilowane tablice T-Tables umieszczone w pamięci RAM. Audytorzy bezpieczeństwa otrzymali zadanie weryfikacji odporności obu rozwiązań na techniki analizy kryptoanalitycznej i fizycznej.

W pierwszej fazie scenariusza zespół audytorski analizuje strukturę skrzynek S-Box algorytmu DES. Wykorzystując metodę kryptoanalizy różnicowej, studenci generują pary tekstów jawnych o ściśle określonej różnicy bitowej XOR i obserwują propagację różnic przez kolejne rundy sieci Feistela. Zjawisko nierównomiernego rozkładu par w tabeli par różnicowych (Difference Distribution Table - DDT) pozwala na odtworzenie 48-bitowego podklucza rundowego przy nakładzie pracy wielokrotnie niższym niż przeszukanie wyczerpujące całej przestrzeni kluczy.

W drugiej fazie studenci badają współczesną implementację tablicową algorytmu AES na stacji wielozadaniowej. Ponieważ indeksowanie tablic T-Tables zależy bezpośrednio od wartości bajtów klucza tajnego oraz tekstu jawnego, linie pamięci podręcznej procesora L1/L3 są ładowane w sposób zależny od przetwarzanych danych. Atakujący uruchomiony jako nieuprzywilejowany proces w tym samym systemie operacyjnym stosuje technikę Flush and Reload, mierząc precyzyjnie czas dostępu do linii pamięci za pomocą instrukcji asemblera RDTSC i odtwarzając klucz szyfrujący.

W fazie obronnej zespół Blue Team eliminuje wyciek czasowy poprzez wdrożenie kodu stałoczasowego (Constant-Time AES z instrukcjami AES-NI lub techniką Bitslicing), w którym czas wykonania operacji jest całkowicie niezależny od wartości przetwarzanych danych. Równolegle studenci wdrażają program monitorujący w technologii eBPF (Extended Berkeley Packet Filter), który śledzi liczniki wydajnościowe procesora PMU i generuje natychmiastowy alert SOC w przypadku wykrycia zmasowanych operacji usuwania linii pamięci podręcznej.

• Python 3 (moduły numpy, matplotlib, secrets): środowisko obliczeniowe do generowania tabeli DDT, symulacji sieci Feistela i estymacji prawdopodobieństw różnicowych.
• Kompilator GCC / Clang: środowisko do kompilacji niskopoziomowego kodu kryptoanalitycznego w języku C z obsługą wstawek asemblerowych x86-64.
• BCC (BPF Compiler Collection) / bpftrace: narzędzia do budowy i ładowania programów śledzących eBPF bezpośrednio do jądra Linux.
• Perf (Linux Performance Events): uniksowe narzędzie diagnostyczne do inspekcji sprzętowych liczników wydajnościowych procesora (Hardware PMU).
• OpenSSL CLI: pakiet narzędziowy do weryfikacji szybkości i poprawności szyfrowania blokowego w różnych trybach pracy.
• GDB: debugger procesów do precyzyjnej weryfikacji adresów tablic kryptograficznych w przestrzeni adresowej pamięci RAM.

1. Zbuduj środowisko robocze w systemie Linux wyposażone w kompilator GCC, pakiet Python 3 oraz narzędzia bcc i linux-tools.
2. Napisz skrypt w języku Python generujący pełną tabelę rozkładu różnic (DDT) o wymiarach 64x16 dla pierwszej skrzynki S-Box (S1) algorytmu DES.
3. Zidentyfikuj w wygenerowanej tabeli DDT kombinacje wejście-wyjście o najwyższym prawdopodobieństwie propagacji różnicy.
4. Zaimplementuj uproszczony model 3-rundowego szyfru Feistela z nieliniową funkcją rundy opartą o skrzynkę S1.
5. Wygeneruj zbiór 5000 par tekstów jawnych o zadanej różnicy początkowej delta-P i zaszyfruj je pod stałym kluczem rundowym.
6. Zastosuj algorytm kryptoanalizy różnicowej do przefiltrowania kandydatów na podklucz ostatniej rundy i wskaż poprawny klucz.
7. Skompiluj w języku C referencyjną implementację algorytmu AES wykorzystującą lookup tables (T-Tables) w pamięci operacyjnej.
8. Napisz moduł w języku C wykonujący pomiar czasu dostępu do pamięci za pomocą instrukcji asemblerowych rdtscp oraz clflush.
9. Uruchom procedurę Flush and Reload mierzącą różnice czasowe pomiędzy odczytem z pamięci podręcznej L1 a odczytem z pamięci RAM.
10. Wyznacz próg czasowy (Threshold w cyklach procesora) oddzielający trafienie w pamięć podręczną (Cache Hit) od nietrafienia (Cache Miss).
11. Zsynchronizuj proces szpiegujący z operacjami szyfrowania i odtwórz rozkład adresów pamięci powiązany z pierwszym bajtem klucza AES.
12. Napisz skrypt jądra w technologii bpftrace zliczający częstotliwość występowania zdarzeń cache-misses dla badanego procesu.
13. Zdefiniuj próg anomalii w sondzie eBPF wyzwalający ostrzeżenie o podejrzeniu ataku kanałem bocznym (Side-Channel Detection).
14. Przebuduj implementację AES z wykorzystaniem instrukcji wektorowych AES-NI i zweryfikuj stały czas wykonywania operacji.
15. Wykaż brak korelacji czasowej w nowej implementacji oraz zanik możliwości odzyskania klucza przez proces szpiegujący.
16. Zintegruj telemetrię eBPF z dziennikiem systemowym rsyslog i opracuj regułę Sigma wykrywającą anomalie mikroarchitektoniczne.
17. Sformułuj techniczne wnioski dotyczące ograniczeń szyfrów ze statycznymi skrzynkami podstawieniowymi w środowiskach wirtualnych.

Kryptoanaliza różnicowa opiera się na badaniu relacji pomiędzy różnicami tekstów jawnych (definiowanymi jako bitowy XOR) a odpowiadającymi im różnicami szyfrogramów. Skrzynki podstawieniowe S-Box są jedynym nieliniowym elementem algorytmu DES. Chociaż projektanci DES zoptymalizowali skrzynki pod kątem odporności na kryptoanalizę różnicową w pełnym wariancie 16-rundowym, warianty o zredukowanej liczbie rund (np. 3, 6 lub 8 rund) ulegają całkowitemu przełamaniu przy znikomej liczbie par tekstów wybranych.

W przypadku ataków czasowych na pamięć podręczną (Cache-Timing Attacks) kluczowym zjawiskiem jest różnica czasu dostępu do danych znajdujących się w pamięci podręcznej L1/L3 procesora (kilka do kilkunastu cykli zegarowych) w porównaniu z pobraniem danych bezpośrednio z magistrali pamięci DRAM (często powyżej 150-200 cykli). Instrukcja asemblera clflush unieważnia linię pamięci podręcznej, zmuszając proces ofiary do ponownego załadowania danych z RAM w momencie wykonania operacji kryptograficznej.

Do bezpiecznego wdrożenia algorytmów kryptograficznych we współczesnych systemach niezbędne jest stosowanie implementacji stałoczasowych (Constant-Time). W architekturze x86-64 oznacza to wykorzystanie dedykowanych instrukcji sprzętowych AES-NI (np. aesenc, aesenclast), które wykonują rundę szyfrującą w stałej liczbie cykli bez odwoływania się do zewnętrznych tablic w pamięci RAM.

Poniżej przedstawiono listingi obliczania tabeli DDT w języku Python, procedurę pomiaru czasu Flush and Reload w języku C oraz skrypt detekcyjny w technologii bpftrace.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Podstawy kryptoanalizy różnicowej: tabele rozkładu różnic dla skrzynek S-Box i propagacja różnic wejściowych XOR w algorytmie DES.
2. Mechanizm ataków czasowych na pamięć podręczną (Cache-Timing Attacks) w programowych implementacjach AES opartych na tablicach T-Tables.
3. Rola instrukcji stałoczasowych oraz sprzętowej akceleracji AES-NI w eliminacji wycieków czasowych kanału bocznego.
4. Wykorzystanie sond jądra Linux eBPF do niskonarzutowego monitorowania anomalii w pamięci podręcznej procesora w czasie rzeczywistym.
5. Opracowanie reguł detekcji w telemetrii eBPF identyfikujących masowe wywołania funkcji kryptograficznych o podejrzanych fluktuacjach czasowych.
6. Rekomendacje wycofania zredukowanych wariantów DES i migracji do algorytmów z wbudowaną odpornością bocznokanałową.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna kryptoanaliza różnicowa zredukowanego wariantu DES dowiodła, że nieliniowość skrzynek S-Box można skutecznie przełamać przy użyciu zaledwie kilkuset par wybranych tekstów jawnych o określonej różnicy XOR. Równoległe badanie podatności programowej biblioteki AES wykorzystującej tablice T-Tables wykazało wyraźny wyciek klucza w korelacji czasowej operacji odczytu z pamięci podręcznej L1 procesora. Zaimplementowanie telemetrii eBPF na poziomie jądra pozwoliło na rejestrację mikrosekundowych anomalii czasowych i wygenerowanie natychmiastowego alarmu o trwającym ataku Flush+Reload. Zastąpienie podatnej biblioteki implementacją stałoczasową opartą na wektorowych instrukcjach procesora AES-NI całkowicie wyeliminowało zależność czasu wykonywania operacji od wartości przetwarzanych danych. Uzyskane wyniki potwierdzają krytyczną konieczność audytu kodu kryptograficznego pod kątem podatności na kanały boczne w systemach łączności specjalnej.

Zadanie nawiązuje do Wykładu 3, dotyczącego trybów pracy szyfrów blokowych, schematów dopełnienia danych PKCS#7 / PKCS#5 oraz podatności wynikających z ujawniania statusu wyroczni deszyfrującej (Padding Oracle). Ćwiczenie weryfikuje efekty uczenia się: W1 (znajomość matematycznych i logicznych mechanizmów działania ataku Padding Oracle w trybie Cipher Block Chaining), U1 (samodzielne zaprogramowanie skryptu deszyfrującego bajt po bajcie w języku Python), U3 (analiza kodów odpowiedzi HTTP i pomiarów czasowych wyroczni aplikacyjnej), U4 (opracowanie sygnatur NIDS Suricata oraz reguł korelacyjnych Sigma dla logów serwera WWW) oraz K1 (odpowiedzialność za bezpieczeństwo tokenów uwierzytelniających i danych sesyjnych w systemach bankowości elektronicznej). Wymagania techniczne obejmują standard PKCS#7 (RFC 5652), wytyczne NIST SP 800-38A dotyczące trybów pracy szyfrów blokowych, klasyfikację CWE-209 (Generation of Error Message Containing Sensitive Information) oraz techniki MITRE ATT&CK: T1557 i T1539.

Celem zadania jest przeprowadzenie pełnej, kontrolowanej eksploatacji podatności Padding Oracle na szyfrogramie sesyjnym zabezpieczonym szyfrem AES w trybie CBC, doprowadzając do odzyskania tekstu jawnego bez znajomości klucza kryptograficznego. Zespół studentów analizuje reakcję podatnej aplikacji webowej, która ujawnia błąd nieprawidłowego dopełnienia (np. poprzez zróżnicowanie kodów HTTP 200 OK, 403 Forbidden oraz 500 Internal Server Error). Manipulując bajtami wektora inicjalizującego IV oraz kolejnych bloków szyfrogramu, studenci odszyfrowują token sesyjny bajt po bajcie.

W części defensywnej w formule Purple Team celem jest wdrożenie bezpiecznego uwierzytelnionego szyfrowania (Authenticated Encryption with Associated Data - AEAD, np. AES-GCM lub ChaCha20-Poly1305), całkowicie eliminującego atak wyroczni dopełnienia. Dodatkowo studenci projektują wielowarstwowy system detekcji: sygnaturę NIDS Suricata wykrywającą anomalne serie zapytań z manipulacją blokową oraz regułę Sigma identyfikującą masowe błędy deszyfrowania w dziennikach aplikacji. Wdrożona obrona zapewnia stały czas walidacji i weryfikację integralności kryptograficznej przed próbą deszyfrowania.

W portalu transakcyjnym Krajowego Systemu Obsługi Płatności stan sesji zalogowanego użytkownika jest przesyłany w ciasteczku HTTP pod postacią szyfrogramu AES-128-CBC. Aby zweryfikować uprawnienia klienta, serwer deszyfruje zawartość ciasteczka kluczem symetrycznym, sprawdza poprawność dopełnienia PKCS#7, a następnie parsuje zdekodowany obiekt JSON zawierający identyfikator użytkownika i poziom uprawnień roli administracyjnej.

Podczas audytu bezpieczeństwa teleinformatycznego stwierdzono, że serwer reaguje odmiennie w zależności od etapu przetwarzania: jeśli dopełnienie PKCS#7 jest niepoprawne, aplikacja zwraca błąd HTTP 500 z komunikatem PaddingException. Jeśli natomiast dopełnienie jest poprawne, lecz struktura JSON zawiera błędy, serwer zwraca kod HTTP 400, a przy poprawnym formacie kod HTTP 200. Taka różnica zachowania tworzy klasyczną wyrocznię dopełnienia (Padding Oracle), która pozwala adwersarzowi na odgadnięcie wartości bajtów tekstu jawnego.

Zespół laboratoryjny wciela się w rolę audytorów Red Team, których zadaniem jest skonstruowanie autorskiego narzędzia w języku Python. Narzędzie wysyła do serwera serię zmodyfikowanych bloków szyfrogramu, systematycznie sprawdzając 256 możliwych wartości dla każdego bajtu. Wykorzystując odpowiedź wyroczni, studenci odzyskują pełny tekst jawny ciasteczka sesyjnego, a następnie za pomocą techniki CBC Bit-Flipping modyfikują zawartość zaszyfrowanego tokenu tak, aby nadać swojemu kontu uprawnienia administratora bez znajomości klucza.

W odpowiedzi zespół Blue Team wdraża procedurę mitygacji: rekonfiguruje aplikację, zastępując podatny tryb CBC szyfrowaniem AEAD w trybie AES-GCM z 128-bitowym znacznikiem uwierzytelniającym GMAC. Równolegle studenci tworzą sygnaturę NIDS Suricata wykrywającą zmasowane serie zapytań o stałym prefiksie i zmiennym ostatnim bajcie oraz regułę Sigma alarmującą o anomalii powtarzających się błędów deszyfrowania z jednego adresu IP w oknie 60 sekund.

• Python 3 (biblioteki requests, cryptography, urllib3): środowisko do implementacji autorskiego skryptu ataku Padding Oracle oraz CBC Bit-Flipping.
• Aplikacja testowa w języku Python (Flask / FastAPI): symulator podatnego serwera transakcyjnego z wyrocznią dopełnienia PKCS#7.
• PadBuster: dedykowane zautomatyzowane narzędzie audytorskie do weryfikacji i eksploatacji podatności Padding Oracle w aplikacjach webowych.
• Suricata NIDS 7.0+: system inspekcji sieciowej do analizy korelacji częstotliwości zapytań HTTP i wykrywania prób eksploatacji.
• Sigma CLI: narzędzie do kompilacji uniwersalnych reguł detekcji dla dzienników serwera aplikacji.
• Wireshark: analizator protokołów sieciowych do inspekcji zapytań i odpowiedzi wyroczni w strumieniu HTTP.

1. Zainstaluj środowisko Python 3 z bibliotekami cryptography i requests na stacji audytorskiej.
2. Uruchom podatną aplikację webową szyfrującą stan sesji algorytmem AES-CBC z dopełnieniem PKCS#7.
3. Zaloguj się do aplikacji jako zwykły użytkownik i pobierz zaszyfrowane ciasteczko sesyjne z nagłówka Set-Cookie.
4. Zweryfikuj zachowanie aplikacji przy manualnej modyfikacji ostatniego bajtu szyfrogramu: zaobserwuj odpowiedź HTTP 500.
5. Przeanalizuj matematyczny mechanizm weryfikacji dopełnienia PKCS#7: wartości bajtów dopełnienia dla bloku 16-bajtowego.
6. Napisz autorski skrypt w języku Python realizujący pętlę odgadywania wartości pośredniej (Intermediary Value) dla ostatniego bloku.
7. Zaimplementuj algorytm iteracyjny testujący 256 kombinacji wartości bajtu wektora IV w celu uzyskania dopełnienia 0x01.
8. Oblicz wartość tekstu jawnego ostatniego bajtu ze wzoru: P[15] = IV[15] XOR I[15].
9. Rozszerz algorytm na odszyfrowanie pełnego bloku 16-bajtowego poprzez dynamiczne ustawianie dopełnienia wielobajtowego.
10. Przeprowadź zautomatyzowane odszyfrowanie wszystkich bloków szyfrogramu i wyświetl zrekonstruowany tekst jawny sesji.
11. Zastosuj technikę CBC Bit-Flipping w celu spreparowania nowego szyfrogramu zawierającego ciąg role=admin.
12. Wyślij zmodyfikowany szyfrogram do serwera i potwierdź uzyskanie nieuprawnionego dostępu administracyjnego.
13. Opracuj sygnaturę NIDS Suricata wykrywającą serię zapytań HTTP o identycznej długości ciasteczka ze statusem błędu 500.
14. Zdefiniuj regułę Sigma alarmującą o wystąpieniu powyżej 50 błędów deszyfrowania z jednego źródła IP w ciągu 1 minuty.
15. Przeprowadź refaktoryzację kodu aplikacji: zastąp tryb AES-CBC bezpiecznym trybem uwierzytelnionym AES-256-GCM.
16. Wykonaj test re-testowy za pomocą napisanego skryptu ataku i potwierdź całkowite zablokowanie wyroczni na etapie weryfikacji tagu GMAC.
17. Przygotuj kompleksowy raport laboratoryjny dokumentujący przebieg ataku, analizę wektora CVSS oraz listingi kodu naprawczego.

Dopełnienie PKCS#7 polega na dołączeniu do tekstu jawnego N bajtów o wartości równej N, tak aby długość wiadomości była wielokrotnością rozmiaru bloku (w AES jest to 16 bajtów). Jeśli brakuje 1 bajtu, dodawany jest bajt 0x01; jeśli brakuje 2 bajtów, dodawane są bajty 0x02, 0x02; jeśli tekst jest już wielokrotnością 16 bajtów, dodawany jest cały pełny blok 16 bajtów o wartościach 0x10. Podczas deszyfrowania w trybie CBC serwer deszyfruje blok szyfrogramu kluczem tajnym (uzyskując wartość pośrednią I), a następnie wykonuje operację XOR z poprzednim blokem szyfrogramu C[n-1] (lub wektorem IV dla pierwszego bloku).

Atakujący manipulując bajtami bloku C[n-1] może wymusić, aby po operacji XOR na serwerze powstało poprawne dopełnienie (np. 0x01). Gdy serwer nie zgłosi błędu dopełnienia, atakujący natychmiast poznaje wartość pośrednią: I[15] = C'[n-1][15] XOR 0x01. Znając wartość pośrednią I[15] oraz oryginalny szyfrogram C[n-1][15], atakujący natychmiast wylicza oryginalny tekst jawny: P[15] = I[15] XOR C[n-1][15]. Procedura ta powtarzana jest dla każdego bajtu od końca do początku bloku.

Jedynym skutecznym i definitywnym rozwiązaniem problemu Padding Oracle jest rezygnacja z nieautoryzowanych trybów szyfrowania (takich jak CBC czy CTR bez HMAC) na rzecz trybów uwierzytelnionych AEAD (np. AES-GCM, ChaCha20-Poly1305). W trybie AEAD znacznik integralności (Authentication Tag) jest weryfikowany w pierwszej kolejności, a jakiekolwiek zafałszowanie choćby jednego bitu szyfrogramu powoduje natychmiastowe odrzucenie pakietu przed wykonaniem operacji deszyfrowania.

Poniżej przedstawiono przykłady autorskiego skryptu wyroczni w języku Python, procedurę wdrożenia szyfrowania AES-GCM oraz regułę detekcji Suricata.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Matematyczny mechanizm ataku wyroczni dopełnienia (Padding Oracle Attack) w trybie AES-CBC z dopełnieniem PKCS#7.
2. Różnicowanie odpowiedzi serwera (błąd dopełnienia a błąd deserializacji) jako bezpośrednie źródło wycieku informacji.
3. Automatyzacja ataku za pomocą wyspecjalizowanych narzędzi: ekstrakcja bajtów wektora IV i deszyfracja ciasteczka sesyjnego blok po bloku.
4. Inżynieria sygnatur detekcyjnych w systemie Suricata: wykrywanie powtarzalnych żądań HTTP z mutacją ostatnich bajtów szyfrogramu.
5. Konstrukcja reguł Sigma dla logów serwera WWW: korelacja gwałtownego wzrostu błędów HTTP 500 w krótkim oknie czasowym z pojedynczego źródła IP.
6. Trwała remediacja podatności: zastąpienie trybu CBC szyfrowaniem uwierzytelnionym AEAD (AES-GCM) lub wzorcem Encrypt-then-MAC.

Przykładowe wnioski (wzór do sprawozdania): Eksploatacja ataku Padding Oracle w module sesyjnym portalu płatności dowiodła, że subtelna różnica w kodach błędów serwera pozwala na bezkluczowe odszyfrowanie ciasteczka sesyjnego użytkownika w niespełna trzystu zapytaniach na blok. Manipulując bajtami poprzedzającego bloku szyfrogramu, skrypt kryptoanalityczny zrekonstruował pełną strukturę tokenu JSON i podmienił identyfikator konta na profil administratora. W odpowiedzi na zidentyfikowany atak zespół obronny opracował sygnaturę Suricata wykrywającą anomalne serie zapytań z minimalnie zmienianymi wartościami ciasteczka w oknie milisekundowym. W logach serwera wdrożono regułę korelacyjną Sigma alarmującą o sekwencji ponad pięćdziesięciu błędów weryfikacji dopełnienia z jednego adresu IP w czasie minuty. Podatność zlikwidowano definitywnie poprzez migrację do trybu szyfrowania uwierzytelnionego AES-128-GCM, w którym błędy autentyczności powodują natychmiastowe odrzucenie pakietu przed rozpoczęciem deszyfracji.

Zadanie opiera się na zagadnieniach Wykładu 3 (Architektura PKI i hierarchia urzędów certyfikacji), Wykładu 4 (Mechanizmy uwierzytelniania i kontroli dostępu) oraz Wykładu 6 (Sprzętowe moduły bezpieczeństwa HSM i standardy ochrony fizycznej). Ćwiczenie weryfikuje kierunkowe efekty uczenia się: W4 (dogłębna znajomość architektury sprzętowych modułów bezpieczeństwa, specyfikacji interfejsu PKCS#11 oraz ochrony kluczy przed atakami zrzutu pamięci operacyjnej), U1 (zarządzanie tokenami kryptograficznymi przy użyciu narzędzi softhsm2-util oraz pkcs11-tool), U2 (konfiguracja dostawcy OpenSSL Provider PKCS#11 do obsługi operacji asymetrycznych), U3 (analiza forensyczna zrzutów pamięci RAM w poszukiwaniu materiału klucza) oraz K1 (odpowiedzialność inżynierska za bezpieczeństwo państwowych węzłów certyfikacji i bankowości). Zagadnienia normatywne obejmują specyfikację OASIS PKCS #11 Cryptographic Token Interface v2.40, standardy NIST FIPS 140-3 Level 3, kryteria Common Criteria EAL4+, klasyfikację podatności CWE-311 (Missing Encryption of Sensitive Data), CWE-522 (Insufficiently Protected Credentials) oraz techniki matrycy MITRE ATT&CK: T1552.004 i T1003.

Głównym celem zadania jest zaprojektowanie i wdrożenie infrastruktury kryptograficznej zintegrowanej z programowym modułem bezpieczeństwa HSM za pośrednictwem standardu PKCS#11 (SoftHSM2). Zespół studentów generuje wewnątrz wyizolowanego tokenu kryptograficznego nieekstrahowalny klucz prywatny Root CA z atrybutem uniemożliwiającym jego odczyt. Następnie studenci konfigurują silnik OpenSSL Provider PKCS#11, realizując proces podpisywania certyfikatów podrzędnych bez ujawniania materiału klucza w systemie operacyjnym. Ćwiczenie pozwala zrozumieć fizyczne i logiczne mechanizmy ochrony danych niejawnych w instytucjach zaufania publicznego.

W części weryfikacyjnej celem jest przeprowadzenie symulacji ataku Red Team polegającego na zrzucie pamięci operacyjnej RAM procesu serwera przez uprzywilejowanego użytkownika root. Zespół wykazuje brak obecności klucza w zrzutach pamięciowych oraz formułuje matematyczne i proceduryjne gwarancje bezpieczeństwa tokenu. Końcowym rezultatem jest opracowanie reguły Sigma dla systemu SIEM wykrywającej nieautoryzowane próby debugowania demonów kryptograficznych.

Krajowa Izba Rozliczeniowa wdraża nowy węzeł Głównego Urzędu Certyfikacji obsługującego infrastrukturę klucza publicznego dla bankowości elektronicznej. Zgodnie z rygorystycznymi wytycznymi normy Common Criteria EAL4+ oraz rozporządzeniem unijnym eIDAS, klucze nadrzędne Root CA nie mogą w żadnych okolicznościach istnieć w postaci jawnych plików w systemie operacyjnym. Wszelkie operacje kryptograficzne podpisywania certyfikatów muszą być delegowane do certyfikowanego modułu sprzętowego.

W trakcie analizy ryzyka zespół audytorski zidentyfikował zagrożenie ataku wewnętrznego lub kompromitacji serwera aplikacyjnego przez złośliwe oprogramowanie eskalujące uprawnienia do poziomu administratora root. Tradycyjnie przechowywane pliki PEM w katalogu /etc/ssl uległyby natychmiastowej eksfiltracji, powodując utratę zaufania do całego ekosystemu bankowego. Wdrożenie programowego emulatora HSM (SoftHSM2) ze standardem PKCS#11 stanowi etap wdrożeniowy przed instalacją fizycznych kart PCIe HSM.

Studenci wcielają się w rolę inżynierów bezpieczeństwa teleinformatycznego odpowiedzialnych za konfigurację izolowanego tokenu kryptograficznego. Generują 4096-bitową parę kluczy RSA bezpośrednio w module SoftHSM2, nadając atrybuty CKA_PRIVATE, CKA_SENSITIVE oraz CKA_EXTRACTABLE=FALSE. Zabezpieczają dostęp do slotu odrębnymi kodami Security Officer PIN oraz User PIN, uniemożliwiając nieuprawnionym procesom eksport parametrów d, p oraz q.

W fazie testów ofensywnych zespół audytorów wykonuje zrzut pamięci RAM procesu podpisującego za pomocą narzędzia gcore. Inspekcja buforów pamięciowych potwierdza, że w przestrzeni adresowej procesu OpenSSL znajdują się jedynie uchwyty sesyjne PKCS#11 oraz identyfikatory URI, podczas gdy właściwe operacje potęgowania modularnego wykonuje biblioteka tokenu. Całość wieńczy wdrożenie reguły Sigma monitorującej wywołania narzędzi inspekcji pamięci w systemie produkcyjnym.

• SoftHSM2: otwartoźródłowy programowy emulator modułu HSM zgodny ze specyfikacją interfejsu PKCS#11.
• OpenSC (narzędzie pkcs11-tool): pakiet narzędziowy do zarządzania obiektami, kluczami i certyfikatami w tokenach PKCS#11.
• OpenSSL 3.x z silnikiem PKCS#11: biblioteka kryptograficzna umożliwiająca podpisywanie certyfikatów z użyciem tokenów sprzętowych.
• GDB / gcore: niskopoziomowe debuggery uniksowe służące do wykonywania zrzutów pamięci operacyjnej badanych procesów.
• Strings i Hexdump: uniksowe narzędzia inspekcji binarnej do przeszukiwania zrzutów pamięci RAM pod kątem nagłówków kluczy PEM.
• Python 3 (moduł PyKCS11): środowisko skryptowe do automatyzacji weryfikacji atrybutów bezpieczeństwa obiektów w tokenie.

1. Zainstaluj w systemie operacyjnym Linux pakiety softhsm2, opensc, libengine-pkcs11-openssl oraz gdb.
2. Utwórz dedykowany katalog dla magazynu tokenów SoftHSM2 i skonfiguruj plik konfiguracyjny softhsm2.conf w profilu użytkownika.
3. Zainicjalizuj nowy slot tokenu kryptograficznego za pomocą narzędzia softhsm2-util z etykietą HSM-RootCA-Token.
4. Zdefiniuj silny kod administratora bezpieczeństwa (SO-PIN) oraz kod operatora (User-PIN) zgodnie z polityką haseł.
5. Wygeneruj 4096-bitową parę kluczy RSA wewnątrz tokenu z wykorzystaniem polecenia pkcs11-tool i identyfikatora ID 01.
6. Ustaw rygorystyczne atrybuty bezpieczeństwa klucza: CKA_PRIVATE=TRUE, CKA_SENSITIVE=TRUE oraz CKA_EXTRACTABLE=FALSE.
7. Zweryfikuj listę obiektów zarejestrowanych w tokenie, sprawdzając obecność klucza publicznego i prywatnego RootCA_Key.
8. Skonstruuj identyfikator PKCS#11 URI precyzyjnie wskazujący model tokenu, identyfikator klucza oraz kod PIN operatora.
9. Wystaw samopodpisany certyfikat urzędu nadrzędnego Root CA z wykorzystaniem polecenia openssl req i silnika PKCS#11.
10. Wygeneruj żądanie podpisania certyfikatu (CSR) dla urzędu podrzędnego Sub-CA na stacji roboczej.
11. Podpisz certyfikat urzędu podrzędnego za pomocą klucza nadrzędnego przechowywanego w module HSM i opcji openssl ca.
12. Zweryfikuj, że na dysku serwera powstał wyłącznie plik certyfikatu X.509, a klucz prywatny fizycznie nie istnieje w systemie plików.
13. Uruchom długotrwały proces kryptograficzny OpenSSL pod nadzorem debuggera i pobierz jego identyfikator PID.
14. Wykonaj zrzut pamięci RAM procesu podpisującego za pomocą narzędzia gcore do pliku zrzutu binarnego.
15. Przeszukaj zrzut pamięci poleceniem strings pod kątem fraz kluczowych BEGIN RSA PRIVATE KEY oraz parametrów d i p.
16. Potwierdź negatywny wynik przeszukania, dowodząc pełnej ochrony materiału klucza w przestrzeni adresowej procesu.
17. Opracuj regułę detekcji Sigma monitorującą uruchomienie narzędzi gcore i gdb wobec procesów kryptograficznych.

Moduł HSM (Hardware Security Module) to wyspecjalizowane urządzenie kryptograficzne zapewniające fizyczną i logiczną ochronę kluczy. Standard PKCS#11 (Cryptoki) definiuje niezależne od platformy API umożliwiające aplikacjom zlecanie operacji kryptograficznych (np. szyfrowanie, deszyfrowanie, generowanie podpisu) wewnątrz bezpiecznego mikrokontrolera. Klucz prywatny oznaczony atrybutem CKA_EXTRACTABLE=FALSE nie może zostać odczytany przez żadną funkcję interfejsu programistycznego.

W środowisku laboratoryjnym rolę fizycznego modułu HSM pełni biblioteka SoftHSM2. W pliku konfiguracyjnym softhsm2.conf definiuje się ścieżkę do katalogu magazynu tokenów. Narzędzie softhsm2-util służy do inicjalizacji tokenów, natomiast niskopoziomowe zarządzanie obiektami realizuje pkcs11-tool z pakietu OpenSC, wskazując bibliotekę libsofthsm2.so jako moduł PKCS#11.

Integracja z OpenSSL 3.x odbywa się za pomocą mechanizmu Provider PKCS#11 lub historycznego silnika Engine PKCS#11. Klucz prywatny w poleceniach OpenSSL jest wówczas reprezentowany nie przez ścieżkę do pliku, lecz przez ustandaryzowany ciąg PKCS#11 URI (RFC 7512). Dzięki temu aplikacje serwerowe mogą realizować uścisk dłoni TLS i wystawiać certyfikaty bez bezpośredniego dostępu do bajtów klucza.

Poniżej przedstawiono listingi inicjalizacji tokenu, generowania kluczy RSA wewnątrz modułu, wystawiania certyfikatu Root CA oraz regułę Sigma wykrywającą próby zrzutu pamięci.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Wymagania formalne normy Common Criteria EAL4+ oraz rozporządzenia eIDAS w zakresie fizycznej i logicznej ochrony kluczy urzędów CA.
2. Standard PKCS#11: definicja obiektów kryptograficznych oraz restrykcyjne atrybuty kluczy z blokadą ich ekstrakcji.
3. Konfiguracja modułu SoftHSM2 z bezpieczną pamięcią tokena i wymuszeniem autoryzacji kodami SO-PIN oraz User-PIN.
4. Integracja narzędzia OpenSSL z modułem PKCS#11 za pomocą standaryzowanych identyfikatorów PKCS#11 URI.
5. Ceremonia podpisywania certyfikatu pośredniego CA: delegowanie operacji kryptograficznych do HSM bez ujawniania klucza w pamięci systemu.
6. Procedury bezpiecznego tworzenia kopii zapasowych i odzyskiwania tokenów sprzętowych w instytucjach bankowych.

Przykładowe wnioski (wzór do sprawozdania): Implementacja infrastruktury Głównego Urzędu Certyfikacji w oparciu o moduł kryptograficzny PKCS#11 zagwarantowała bezwzględną nienaruszalność nadrzędnego klucza prywatnego Root CA. Utworzenie klucza wewnątrz tokena z atrybutem uniemożliwiającym ekstrakcję wyeliminowało ryzyko wycieku tożsamości bankowej nawet w przypadku pełnej kompromitacji systemu gospodarza. Podpisywanie certyfikatów podrzędnych odbywa się wyłącznie poprzez przekazywanie skrótów kryptograficznych do modułu za pośrednictwem bezpiecznego URI, a sam klucz nigdy nie opuszcza izolowanego obszaru pamięci. Wdrożenie procedury autoryzacji dwoma niezależnymi kodami PIN uniemożliwiło nieautoryzowane użycie klucza przez pojedynczego operatora. Przeprowadzona integracja spełnia najwyższe rygory międzynarodowych standardów Common Criteria EAL4+ oraz wytycznych eIDAS dla zaufanych usług certyfikacyjnych.

Zadanie bazuje na treściach Wykładu 3 (Asymetryczne algorytmy kryptograficzne - RSA, problem faktoryzacji liczb złożonych) oraz Wykładu 5 (Metody kryptoanalizy matematycznej i ataki na schematy paddingu). Ćwiczenie weryfikuje efekty uczenia się: W2 (dogłębna znajomość arytmetyki modularnej, ułamków łańcuchowych, twierdzenia Eulera oraz podstaw redukcji krat Coppersmitha), U1 (implementacja skryptów kryptoanalitycznych w języku Python z wykorzystaniem bibliotek gmpy2 i sympy), U3 (analiza wektorów ryzyka CVSS v4.0 w kontekście słabości implementacyjnych), U4 (wdrożenie bezpiecznych schematów dopełnienia RSA-OAEP i podpisów cyfrowych RSA-PSS) oraz K2 (krytyczna ocena parametrów matematycznych w systemach przetwarzania danych). Zagadnienia normatywne obejmują standardy PKCS#1 v1.5 vs RFC 8017 (PKCS#1 v2.2), zalecenia NIST SP 800-56B, klasyfikację słabości CWE-326 (Inadequate Encryption Strength) oraz techniki matrycy MITRE ATT&CK: T1110.002 i T1552.004.

Nadrzędnym celem zadania jest zbadanie matematycznych słabości implementacji kryptosystemu RSA wynikających z błędnego doboru parametrów oraz podatności paddingu. Zespół studentów analizuje atak Wienera wykorzystujący rozwinięcie ułamka e/N w ułamki łańcuchowe do natychmiastowej faktoryzacji modułu przy małym wykładniku prywatnym d. Ponadto studenci badają mechanizm ataku Coppersmitha z redukcją krat LLL dla małego wykładnika jawnego e=3 oraz mechanikę adaptacyjnego ataku wyroczni Bleichenbachera na schemat PKCS#1 v1.5. Ćwiczenie ugruntowuje wiedzę o konieczności zachowania rygorystycznych wymogów teoretycznych przy generacji kluczy asymetrycznych.

W części implementacyjnej studenci tworzą w języku Python skrypt faktoryzujący podatny klucz RSA w czasie ułamka sekundy. Zespół weryfikuje poprawność odzyskania wykładnika prywatnego d oraz liczb pierwszych p i q, a także testuje podatność serwera na zapytania wyroczni paddingu. Zadanie kończy się wdrożeniem bezpiecznych schematów dopełnienia RSA-OAEP i RSA-PSS oraz reguły Sigma identyfikującej certyfikaty ze słabym wykładnikiem jawnym.

Instytucja sektora publicznego przeprowadza kompleksowy audyt bezpieczeństwa archiwalnego systemu podpisywania dokumentów skarbowych wdrożonego kilkanaście lat temu. Ze względów ograniczonej mocy obliczeniowej ówczesnych kart kryptograficznych, programiści zastosowali niestandardowe parametry: mały wykładnik prywatny w celu przyspieszenia deszyfrowania oraz wykładnik jawny e=3. Zespół kryptoanalityków otrzymuje zadanie wykazania, że kompromitacja tych parametrów jest możliwa w warunkach laboratoryjnych.

W pierwszej części scenariusza analitycy badają przypadek klucza RSA z małym wykładnikiem prywatnym d spełniającym warunek Wienera: d mniejsze niż jedna trzecia pierwiastka czwartego stopnia z modułu N. Twierdzenie Wienera dowodzi, że iloraz k/d jest jednym z reduktów rozwinięcia ułamka e/N w ułamek łańcuchowy. Wykorzystując tę własność, atakujący nie musi wykonywać kosztownej faktoryzacji metodą sita ciał liczbowych, lecz odzyskuje klucz prywatny w czasie wielomianowym.

W drugiej fazie audytorzy analizują podatność komunikacji na atak Coppersmitha oraz atak adaptacyjny Bleichenbachera na schemat PKCS#1 v1.5 (atak ROBOT). Jeżeli serwer ujawnia błędy weryfikacji paddingu po deszyfrowaniu wiadomości, pełni rolę wyroczni orzekającej, czy odszyfrowany blok zaczyna się od bajtów 0x00 0x02. Odpowiednio dobrane zapytania z wybranym szyfrogramem pozwalają na zawężanie przedziału poszukiwanej wiadomości aż do jej pełnego odzyskania.

W fazie obronnej inżynierowie Blue Team opracowują procedurę automatycznego skanowania certyfikatów X.509 w całej domenie organizacji. Eliminują wszystkie klucze o długości modułu poniżej 3072 bitów oraz wykładniku e różnym od wartości standardowej 65537. Równolegle aplikacje zostają zmodyfikowane w celu wymuszenia probabilistycznych schematów dopełnienia RSA-OAEP oraz podpisów RSA-PSS, co definitywnie unieszkodliwia podatności wyroczni paddingu.

• Python 3 (gmpy2, sympy, cryptography): środowisko obliczeniowe do arytmetyki wielkich liczb, ułamków łańcuchowych i testów faktoryzacji.
• OpenSSL CLI: narzędzie do inspekcji parametrów kluczy asymetrycznych i weryfikacji formatu ASN.1 DER/PEM.
• SageMath: specjalistyczny pakiet matematyczny do analizy kratowej Coppersmitha i redukcji baz LLL.
• Bleichenbacher Test Suite: zbiór skryptów sprawdzających odporność implementacji TLS na atak ROBOT.
• TShark / Wireshark: analizator protokołów sieciowych do inspekcji kodów błędów uścisku dłoni TLS.
• Rsyslog / Auditd: demony telemetrii systemowej rejestrujące operacje generatorów kluczy w systemie Linux.

1. Zbuduj środowisko badawcze z interpreterem Python 3 oraz zoptymalizowanymi bibliotekami gmpy2 i sympy.
2. Zaimplementuj algorytm rozwinięcia liczby wymiernej e/N w nieskończony ułamek łańcuchowy.
3. Wyznacz ciąg reduktów ułamka łańcuchowego reprezentujących ułamki postaci k/d.
4. Zaimplementuj test kandydatów na klucz d: oblicz wartość funkcji Eulera phi oraz rozwiąż równanie kwadratowe dla p i q.
5. Wygeneruj podatną parę kluczy RSA o module 1024-bitowym ze sztucznie zredukowanym wykładnikiem d.
6. Wykonaj atak Wienera na wygenerowany klucz i zarejestruj czas faktoryzacji modułu N.
7. Porównaj odzyskany wykładnik d oraz czynniki p i q z wartościami rzeczywistymi użytymi podczas generacji.
8. Zbadaj warunki ataku Håstada dla małego wykładnika e=3 i tej samej wiadomości wysłanej do 3 różnych odbiorców.
9. Zastosuj Chińskie Twierdzenie o Resztach (CRT) do obliczenia wiadomości podniesionej do sześcianu w ciele liczb rzeczywistych.
10. Odzyskaj tekst jawny poprzez wyciągnięcie pierwiastka sześciennego bez znajomości żadnego z kluczy prywatnych.
11. Zaimplementuj uproszczony model serwera z wyrocznią PKCS#1 v1.5 zwracającą kod błędu w przypadku niepoprawnego paddingu.
12. Wykonaj serię adaptacyjnych zapytań kryptoanalitycznych Bleichenbachera zwężających przedział dopuszczalnego tekstu jawnego.
13. Napisz skrypt audytorski weryfikujący wszystkie certyfikaty X.509 w organizacji pod kątem wartości e mniejszej niż 65537.
14. Skonfiguruj bibliotekę cryptography w języku Python do wymuszenia szyfrowania asymetrycznego RSA-OAEP z funkcją skrótu SHA-256.
15. Przebuduj procedurę składania podpisów cyfrowych na standard probabilistyczny RSA-PSS zgodnie z RFC 8017.
16. Zdefiniuj regułę detekcji Sigma wykrywającą obecność certyfikatów z wykładnikiem publicznym e=3 w systemie plików.
17. Przygotuj raport techniczny prezentujący dowody matematyczne przeprowadzonych ataków oraz kalkulację wektora CVSS v4.0.

Algorytm RSA opiera się na trudności faktoryzacji liczby N = p * q. Bezpieczeństwo kryptosystemu zależy jednak ściśle od doboru parametrów. W 1990 roku Michael J. Wiener wykazał, że jeżeli wykładnik prywatny d spełnia relację d < (1/3) * N^(1/4), to ułamek k/d jest jednym z reduktów rozwinięcia e/N w ułamek łańcuchowy. W rezultacie atakujący może odzyskać klucz d w czasie wielomianowym, rozwiązując prosty układ równań kwadratowych dla każdego reduktu.

Z kolei mały wykładnik publiczny (np. e = 3), stosowany dawniej w celu optymalizacji prędkości szyfrowania i weryfikacji podpisu, stwarza podatność na atak Håstada oraz metody kratowe Coppersmitha. Jeżeli ta sama wiadomość zostanie zaszyfrowana pod trzema różnymi kluczami publicznymi o e=3, z Chińskiego Twierdzenia o Resztach wynika relacja c = m^3 mod (N1*N2*N3). Ponieważ m^3 < N1*N2*N3, deszyfrowanie sprowadza się do wyznaczenia zwykłego pierwiastka sześciennego w ciele liczb rzeczywistych.

Atak Bleichenbachera (znany także jako Million Message Attack lub podatność ROBOT) dotyczy deterministycznego dopełnienia PKCS#1 v1.5. Gdy serwer deszyfrujący ujawnia, czy odszyfrowany blok rozpoczyna się poprawnymi bajtami 0x00 0x02, pełni rolę wyroczni paddingu. Atakujący modyfikuje szyfrogram c' = c * s^e mod N i na podstawie reakcji serwera zawęża przedział nieznanej wiadomości m. Rozwiązaniem jest stosowanie schematu RSA-OAEP (Optimal Asymmetric Encryption Padding) oraz podpisów RSA-PSS.

Poniżej przedstawiono implementację ataku Wienera w języku Python, skrypt audytu parametrów kluczy oraz regułę Sigma alarmującą o słabych certyfikatach.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Kryptoanaliza małego wykładnika prywatnego: atak Wienera oparty na rozwinięciu ułamka ciągłego i faktoryzacja modułu RSA.
2. Zastosowanie twierdzenia Coppersmitha (redukcja baz krat LLL) do odzyskiwania tekstu jawnego przy małym wykładniku publicznym e=3.
3. Adaptacyjny atak z wybranym szyfrogramem Bleichenbachera na schemat dopełnienia PKCS#1 v1.5 w operacjach deszyfrowania RSA.
4. Wykorzystanie wyroczni dopełnienia PKCS#1 v1.5 w protokołach sieciowych do nieautoryzowanego odszyfrowania komunikacji.
5. Konieczność wycofania schematów PKCS#1 v1.5 i wdrożenie nowoczesnych standardów RSA-OAEP oraz RSA-PSS.
6. Audyt archiwalnych kluczy RSA w systemach państwowych pod kątem podatności na kryptoanalizę matematyczną i zgodności z NIST SP 800-131A.

Przykładowe wnioski (wzór do sprawozdania): Matematyczna kryptoanaliza archiwalnego modułu RSA wykazała krytyczną podatność zastosowanego algorytmu generowania kluczy na atak Wienera wynikający z doboru zbyt małego wykładnika prywatnego d. Wykorzystanie algorytmu rozwinięcia ułamka ciągłego pozwoliło na błyskawiczne odzyskanie klucza tajnego i bezproblemową faktoryzację 2048-bitowego modułu w ułamku sekundy. Równoległa symulacja adaptacyjnego ataku Bleichenbachera na schemat dopełnienia PKCS#1 v1.5 potwierdziła możliwość odzyskania tekstu jawnego podpisanego dokumentu skarbowego poprzez wysyłanie spreparowanych zapytań do wyroczni deszyfrującej. Doświadczenie dowiodło konieczności bezwzględnego wycofania przestarzałych schematów PKCS#1 v1.5 na rzecz algorytmów RSA-OAEP oraz RSA-PSS odpornych na ataki oparte na redukcji krat. Przeprowadzony audyt dostarczył bezspornych dowodów uzasadniających natychmiastową migrację strategicznych systemów skarbowych do nowoczesnych standardów kryptograficznych.

Zadanie opiera się na treściach Wykładu 3 (Algorytmy kryptograficzne i mechanizmy klucza publicznego) oraz Wykładu 6 (Kryptografia postkwantowa i trendy rozwoju nowoczesnych systemów ochrony). Ćwiczenie weryfikuje kierunkowe efekty uczenia się: W2 (dogłębna znajomość kryptografii opartej na strukturach kratowych oraz problemu uczenia z błędami Module-LWE), W4 (architektura hybrydowej infrastruktury klucza publicznego PQC w protokole TLS 1.3), U1 (integracja dostawcy oqsprovider z biblioteką OpenSSL 3.x), U3 (analiza narzutu telekomunikacyjnego oraz ocena ryzyka CVSS v4.0), U4 (projektowanie zabezpieczeń przed strategią Harvest Now, Decrypt Later oraz inżynieria sygnatur Suricata) oraz K1 (odpowiedzialność za strategiczne bezpieczeństwo państwowych systemów rozliczeniowych). Wymagania normatywne obejmują standardy NIST FIPS 203 (ML-KEM), NIST FIPS 204 (ML-DSA), wytyczne CNSA 2.0, standard X.509 RFC 5280, klasyfikację CWE-327 oraz techniki MITRE ATT&CK: T1557 i T1040.

Głównym celem zadania jest zaprojektowanie, wdrożenie i przetestowanie eksperymentalnego środowiska kryptografii postkwantowej opartego na standardach NIST FIPS 203 (ML-KEM) oraz FIPS 204 (ML-DSA). Studenci budują hybrydowy urząd certyfikacji X.509 z wykorzystaniem biblioteki OpenSSL 3.x oraz dostawcy Open Quantum Safe (OQS Provider). Zespół bada odporność komunikacji na długoterminowe zagrożenie Harvest Now, Decrypt Later (HNDL) poprzez zestawienie bezpiecznego kanału TLS 1.3 z hybrydową wymianą kluczy. Ćwiczenie pozwala zrozumieć zasady migracji współczesnych struktur PKI w kierunku algorytmów odpornych na komputery kwantowe.

W części audytorskiej studenci analizują wpływ kilkunastokrotnie większych rozmiarów kluczy kratowych na fragmentację jednostek MTU pakietów sieciowych TCP. Zespół bada nagłówki rozszerzenia key_share oraz opracowuje sygnaturę NIDS Suricata wykrywającą nieautoryzowane sesje TLS pozbawione enkapsulacji postkwantowej. Zadanie kończy się opracowaniem technicznego zestawienia porównawczego wydajności algorytmów klasycznych i postkwantowych.

Narodowy Bank Polski projektuje architekturę międzybankowej sieci rozliczeń natychmiastowych o 30-letnim horyzoncie poufności danych skarbowych. Ryzyko masowego rejestrowania transmisji sieciowych przez obce służby specjalne w celu ich późniejszego odszyfrowania po skonstruowaniu stabilnego komputera kwantowego (strategia Harvest Now, Decrypt Later) zmusza bank do natychmiastowego wdrożenia kryptografii kratowej. Zespół inżynierów ma uruchomić pilotażowy węzeł urzędu certyfikacji zgodny ze standardami NIST FIPS.

Dotychczas stosowane algorytmy RSA oraz krzywe eliptyczne ECDSA/ECDH opierają się na trudności faktoryzacji oraz problemie logarytmu dyskretnego, które ulegają natychmiastowemu załamaniu przy użyciu kwantowego algorytmu Shora. W odpowiedzi NIST zestandaryzował algorytmy oparte na trudności problemu uczenia z błędami na modułach krat (ML-LWE): ML-KEM do uzgadniania kluczy oraz ML-DSA do składania podpisów cyfrowych. Zespół laboratoryjny wdraża te mechanizmy w strukturach certyfikatów X.509.

Studenci konfigurują bibliotekę OpenSSL 3.x z modułem oqsprovider. Generują nadrzędny urząd certyfikacji PQC Root CA wykorzystujący algorytm podpisów ML-DSA-65 (Dilithium3), a następnie wystawiają certyfikat serwerowy dla domeny bankowej. W kolejnym kroku uruchamiają demonstracyjny serwer HTTPS negocjujący hybrydową wymianę kluczy X25519MLKEM768 łączącą klasyczną krzywą X25519 z algorytmem ML-KEM-768.

W fazie telemetrii i obrony analitycy Blue Team przechwytują uścisk dłoni TLS za pomocą narzędzia tshark i badają przyrost rozmiaru pakietu ClientHello oraz ServerHello. Ponieważ klucz publiczny ML-KEM-768 zajmuje 1184 bajty, studenci weryfikują potencjalne ryzyko fragmentacji IP. Na koniec konstruują sygnaturę Suricata NIDS oraz regułę Sigma do monitorowania wdrożenia standardów postkwantowych w całym segmencie bankowym.

• OpenSSL 3.x z oqsprovider: biblioteka kryptograficzna rozszerzona o obsługę algorytmów FIPS 203 i FIPS 204.
• TShark / Wireshark 4.2+: analizator protokołów z dekoderem postkwantowych grup wymiany kluczy TLS 1.3.
• Suricata NIDS 7.0+: system wykrywania intruzów analizujący nagłówki uścisku dłoni TLS.
• Python 3 (moduły cryptography, socket, ssl): środowisko do budowy skryptów testujących poprawność negocjacji PQC.
• Curl / Wget (skompilowane z liboqs): narzędzia konsolowe do generowania zapytań HTTP przez kanał postkwantowy.
• Tcpdump: uniksowe narzędzie do bezpośredniego zrzutu pakietów sieciowych z warstwy łącza danych.

1. Zbuduj środowisko robocze w systemie Linux wyposażone w pakiet OpenSSL 3.x oraz bibliotekę oqsprovider.
2. Sprawdź listę aktywnych dostawców poleceniem openssl list -providers i potwierdź załadowanie oqsprovider.
3. Wylistuj dostępne postkwantowe algorytmy podpisów oraz mechanizmy enkapsulacji klucza KEM.
4. Utwórz katalog roboczy i skonfiguruj plik konfiguracyjny openssl.cnf uwzględniający dostawcę OQS.
5. Wygeneruj klucz prywatny i samopodpisany certyfikat PQC Root CA z wykorzystaniem algorytmu ML-DSA-65.
6. Zweryfikuj strukturę wygenerowanego certyfikatu X.509 za pomocą polecenia openssl x509 -text.
7. Wygeneruj klucz prywatny i żądanie podpisania certyfikatu CSR dla serwera rozliczeń bankowych.
8. Podpisz certyfikat serwerowy kluczem nadrzędnym PQC Root CA i zweryfikuj poprawność łańcucha zaufania.
9. Uruchom testowy serwer TLS 1.3 poleceniem openssl s_server z obsługą hybrydowej grupy X25519MLKEM768.
10. Nawiąż połączenie testowe klientem openssl s_client i potwierdź wynegocjowanie grupy postkwantowej.
11. Przechwyć pakiety uścisku dłoni za pomocą narzędzia tshark i wyodrębnij pole supported_groups.
12. Zmierz rozmiar klucza publicznego przesyłanego w rozszerzeniu key_share dla algorytmu ML-KEM-768.
13. Porównaj całkowitą objętość pakietów uścisku dłoni sesji klasycznej ECDHE z sesją hybrydową PQC.
14. Opracuj sygnaturę Suricata NIDS wykrywającą obecność postkwantowej grupy ML-KEM w pakiecie ClientHello.
15. Opracuj drugą sygnaturę Suricata alarmującą o próbie nawiązania sesji wyłącznie klasycznym szyfrem RSA/ECC.
16. Przetestuj skuteczność reguł detekcyjnych, wywołując ruch z różnych stacji klienckich.
17. Przygotuj raport inżynierski podsumowujący analizę narzutu sieciowego oraz kalkulację wektora CVSS v4.0.

Kryptografia postkwantowa (PQC) obejmuje algorytmy matematyczne działające na klasycznych komputerach, których złamanie pozostaje niemożliwe nawet dla wielkoskalowego komputera kwantowego. Algorytm Shora pozwala na rozwiązanie problemu faktoryzacji oraz logarytmu dyskretnego w czasie wielomianowym, co unieważnia bezpieczeństwo RSA i krzywych eliptycznych. Fundamentem nowoczesnych standardów NIST stała się teoria krat (Lattice-based Cryptography), w szczególności problem uczenia z błędami (Learning With Errors - LWE).

Standard FIPS 203 (ML-KEM, wywodzący się z algorytmu Kyber) definiuje mechanizm enkapsulacji klucza (KEM), w którym nadawca generuje szyfrogram zawierający losowy klucz symetryczny, możliwy do odszyfrowania wyłącznie przez posiadacza klucza prywatnego. Z kolei standard FIPS 204 (ML-DSA, wywodzący się z Dilithium) realizuje podpisy cyfrowe oparte na kratach modułowych, zapewniając silną odporność na fałszowanie sygnatur.

W fazie przejściowej standardy międzynarodowe (CNSA 2.0, IETF) nakazują stosowanie schematów hybrydowych (np. X25519MLKEM768). Klucz sesyjny powstaje z połączenia sekretów uzyskanych z klasycznej krzywej X25519 oraz algorytmu ML-KEM. Zapewnia to odporność na ewentualne nieodkryte jeszcze wady nowych algorytmów kratowych, jednocześnie natychmiast chroniąc transmisję przed nagrywaniem w ramach ataku HNDL.

Poniżej przedstawiono listingi weryfikacji algorytmów w OpenSSL 3.x, generowania certyfikatu postkwantowego oraz sygnaturę NIDS Suricata wykrywającą negocjację PQC.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Zasada działania algorytmów opartych na kratach algebraicznych: problem Module-LWE stanowiący fundament FIPS 203 i FIPS 204.
2. Wdrożenie algorytmu ML-KEM do hermetyzacji kluczy oraz ML-DSA do generowania cyfrowych podpisów postkwantowych.
3. Konstrukcja struktur certyfikatów X.509 w wariancie hybrydowym: równoległe stosowanie tradycyjnych kluczy oraz algorytmów PQC.
4. Analiza wpływu rozmiaru kluczy publicznych i sygnatur PQC na protokoły sieciowe, narzut pamięciowy i fragmentację pakietów.
5. Zgodność ze standardami NIST PQC oraz wymaganiami unijnymi i krajowymi w perspektywie ochrony tajemnicy państwowej.
6. Metodyka testowania wydajności i weryfikacji poprawności łańcucha zaufania PQC za pomocą narzędzi OpenSSL z rozszerzeniem OQS Provider.

Przykładowe wnioski (wzór do sprawozdania): Zaprojektowanie i wdrożenie eksperymentalnej infrastruktury PKI opartej na standardach NIST FIPS 203 (ML-KEM) oraz FIPS 204 (ML-DSA) stanowi milowy krok w kierunku uodpornienia bankowości na zagrożenia ery komputerów kwantowych. W ramach laboratorium wygenerowano dwuwarstwowy łańcuch certyfikatów X.509, w którym certyfikat Root CA oraz certyfikaty węzłów rozliczeniowych wykorzystują postkwantowy algorytm podpisów cyfrowych ML-DSA-65. Analiza telemetryczna wykazała wzrost rozmiaru certyfikatu do około czterech kilobajtów, co wymagało odpowiedniego dostosowania buforów protokołu sieciowego w węzłach rozliczeń natychmiastowych. Pomiary wydajnościowe potwierdziły, że czas generowania i weryfikacji podpisów siatkowych jest porównywalny z klasycznym RSA-4096, zachowując przy tym pełną odporność na algorytm Shora. Opracowana architektura stanowi wzorzec gotowości na migrację postkwantową dla strategicznych instytucji finansowych w Polsce.

Zadanie opiera się na treściach Wykładu 3 (Kryptografia asymetryczna i krzywe eliptyczne) oraz Wykładu 4 (Mechanizmy uwierzytelniania, podpisy cyfrowe i generatory liczb losowych). Ćwiczenie weryfikuje efekty uczenia się: W2 (dogłębna znajomość arytmetyki punktów na krzywych eliptycznych secp256k1 i NIST P-256), W3 (matematyczna konstrukcja podpisu ECDSA oraz rola efemerycznej liczby losowej Nonce), U1 (implementacja skryptów kryptoanalitycznych w języku Python z wykorzystaniem modularnego odwrotności liczb), U3 (analiza podatności i kalkulacja wektorów CVSS v4.0), U4 (wdrożenie deterministycznego podpisu cyfrowego zgodnego z RFC 6979 oraz inżynieria reguł detekcyjnych Sigma) oraz K2 (krytyczna weryfikacja generatorów PRNG w modułach bezpieczeństwa). Standardy normatywne obejmują ANSI X9.62, RFC 6979, NIST FIPS 186-5, historyczną podatność CVE-2011-0695, słabość CWE-347 oraz techniki MITRE ATT&CK: T1552.004 i T1556.

Podstawowym celem zadania jest zbadanie matematycznych konsekwencji powtórzenia lub wycieku jednorazowej wartości losowej Nonce (k) w algorytmie podpisu cyfrowego ECDSA. Zespół studentów analizuje słabości generatorów liczb pseudolosowych oraz podatność modułów sprzętowych na ataki zakłóceniowe typu Fault Injection (np. celowe zaburzenia napięcia zasilania). W części ofensywnej studenci implementują w języku Python skrypt kryptoanalityczny natychmiast odzyskujący klucz prywatny podpisującego z dwóch przechwyconych podpisów cyfrowych o identycznej wartości parametru r. Ćwiczenie unaocznia krytyczne znaczenie absolutnej unikalności i nieprzewidywalności parametrów efemerycznych w kryptografii asymetrycznej.

W części defensywnej celem jest implementacja i weryfikacja standardu deterministycznego generowania podpisów RFC 6979 eliminującego wymóg zewnętrznego źródła losowości. Zespół opracowuje procedurę audytu kodu kryptograficznego oraz konstruuje regułę Sigma do monitorowania logów transakcyjnych pod kątem zduplikowanych wartości r. Całość prac wieńczy formalna analiza ryzyka oraz sformułowanie zaleceń inżynierskich dla bezpiecznych koprocesorów.

Krajowa platforma rozliczeń cyfrowych i znaków skarbowych eksploatuje węzeł zautomatyzowanego podpisywania transakcji typu Cold Storage. W module kryptograficznym odpowiadającym za generowanie podpisów ECDSA na krzywej secp256k1 zidentyfikowano błąd współbieżności wątków, który w połączeniu z anomaliami zasilania prowadzi do zainicjalizowania tej samej wartości liczby losowej k dla dwóch odrębnych komunikatów płatniczych. Zespół Purple Team ma przeprowadzić kontrolowaną symulację ataku i ocenić skutki podatności.

Matematyczna konstrukcja podpisu ECDSA opiera się na wyznaczeniu punktu R = k * G, z którego współrzędna r = R.x mod n staje się pierwszą częścią podpisu (r, s). Druga część podpisu dana jest wzorem s = k^(-1) * (z + r * d) mod n, gdzie z jest skrótem wiadomości, a d kluczem prywatnym. W sytuacji, gdy ta sama wartość k zostanie użyta do podpisania dwóch różnych wiadomości, parametr r pozostaje identyczny dla obu sygnatur, co stanowi jednoznaczny sygnał dla kryptoanalityka.

Analitycy Red Team odejmują równania obu podpisów stronami: s1 - s2 = k^(-1) * (z1 - z2) mod n, co pozwala bezpośrednio obliczyć nieznaną wartość k bez konieczności rozwiązywania trudnego problemu logarytmu dyskretnego. Po odzyskaniu wartości k, wyznaczenie klucza prywatnego d sprowadza się do jednej operacji arytmetycznej: d = (s1 * k - z1) * r^(-1) mod n. Atakujący uzyskuje pełny dostęp do portfela skarbowego instytucji.

W fazie Blue Team studenci wdrażają łatkę eliminującą podatność poprzez zastosowanie specyfikacji RFC 6979. W tym podejściu wartość k jest derywowana deterministycznie z hasha wiadomości oraz klucza prywatnego za pomocą konstrukcji HMAC-SHA256, co wyklucza powtórzenie parametru k dla różnych danych wejściowych. Równolegle inżynierowie konfigurują regułę Sigma wykrywającą w logach transakcyjnych powtarzające się wartości r w czasie rzeczywistym.

• Python 3 (ecdsa, gmpy2, cryptography): biblioteki programistyczne do arytmetyki krzywych eliptycznych i kryptoanalizy.
• OpenSSL CLI: narzędzie do inspekcji parametrów krzywych secp256k1 i generowania par kluczy EC.
• Wireshark / TShark: analizator pakietów do inspekcji przesyłanych podpisów cyfrowych w protokołach aplikacji.
• Auditd i Rsyslog: demony telemetrii systemowej do agregacji logów transakcyjnych węzła podpisu.
• SQLite / PostgreSQL: silnik bazy danych do przechowywania i przeszukiwania wygenerowanych podpisów.
• GDB / Valgrind: narzędzia diagnostyczne do inspekcji generatorów liczb pseudolosowych w pamięci RAM.

1. Zbuduj środowisko badawcze z interpreterem Python 3 oraz modułami ecdsa i gmpy2.
2. Zaimplementuj procedurę generowania kluczy na krzywej eliptycznej secp256k1 i pobierz rząd podgrupy n.
3. Przygotuj dwa odrębne komunikaty transakcyjne reprezentujące zlecenia wypłaty środków.
4. Oblicz skróty kryptograficzne SHA-256 obu wiadomości i przekształć je na liczby całkowite z1 i z2.
5. Zasymuluj usterkę generatora PRNG, przypisując stałą wartość liczby losowej k_fixed dla obu operacji podpisu.
6. Wygeneruj dwa podpisy ECDSA (r, s1) oraz (r, s2) i potwierdź, że wartość parametru r jest identyczna.
7. Napisz funkcję obliczającą odwrotność modularną przy użyciu rozszerzonego algorytmu Euklidesa.
8. Wyznacz wartość liczby losowej k z relacji k = (z1 - z2) * (s1 - s2)^(-1) mod n.
9. Odzyskaj klucz prywatny d z relacji d = (s1 * k - z1) * r^(-1) mod n.
10. Porównaj odzyskany klucz d z kluczem rzeczywistym ofiary i potwierdź stuprocentową zgodność bitową.
11. Przetestuj przypadek częściowego wycieku bitów Nonce (atak kratowy Hidden Number Problem z redukcją LLL).
12. Zaimplementuj generator deterministyczny zgodny z RFC 6979 oparty na konstrukcji HMAC-SHA256.
13. Wygeneruj serię 1000 podpisów przy użyciu RFC 6979 i potwierdź brak jakichkolwiek duplikatów parametru r.
14. Opracuj skrypt audytorski przeszukujący bazę transakcji pod kątem zduplikowanych wartości r.
15. Zdefiniuj regułę detekcji Sigma monitorującą zdarzenia weryfikacji podpisów w dziennikach aplikacji.
16. Wykonaj analizę wektora CVSS v4.0 uwzględniającą krytyczny wpływ na integralność i poufność kluczy.
17. Sformułuj techniczne wnioski dotyczące wyższości deterministycznych podpisów nad generatorami sprzętowymi PRNG.

Algorytm ECDSA (Elliptic Curve Digital Signature Algorithm) opiera się na trudności problemu logarytmu dyskretnego na krzywych eliptycznych (ECDLP). Dla danego punktu publicznego Q = d * G znalezienie klucza prywatnego d jest obliczeniowo niewykonalne. Jednak podpisanie każdej wiadomości wymaga wygenerowania ściśle tajnej, kryptograficznie losowej liczby k (Nonce). Wartość k musi być unikalna dla każdego podpisu – powtórzenie jej chociażby raz prowadzi do natychmiastowego ujawnienia klucza prywatnego.

Zjawisko to stało się przyczyną wielu historycznych incydentów bezpieczeństwa, w tym głośnego złamania zabezpieczeń konsoli Sony PlayStation 3 w 2010 roku (CVE-2011-0695). Programiści zastosowali wówczas stałą liczbę wybraną przez rzut kością zamiast prawdziwego generatora liczb pseudolosowych, co pozwoliło badaczom na wyznaczenie prywatnego klucza głównego producenta i podpisywanie dowolnego kodu nieautoryzowanego.

Odpowiedzią inżynierską na ten problem jest standard RFC 6979 (Deterministic Usage of the Digital Signature Algorithm and Elliptic Curve Digital Signature Algorithm). W standardzie tym liczba k nie jest pobierana z generatora losowego, lecz wyliczana deterministycznie z klucza prywatnego i hasha wiadomości. Gwarantuje to, że dla tej samej wiadomości powstaje ten sam podpis, a dla różnych wiadomości wartości k są całkowicie różne i nieprzewidywalne dla osób nieznających klucza prywatnego.

Poniżej przedstawiono implementację exploita kryptoanalitycznego w języku Python, porównanie z RFC 6979 oraz regułę detekcji Sigma.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Matematyka algorytmu ECDSA: powiązanie podpisu z jednorazową liczbą losową (kryptograficznym parametrem nonce).
2. Atak na powtórzenie nonce: natychmiastowe algebraiczne wyliczenie klucza prywatnego z dwóch podpisów o identycznej wartości r.
3. Kryptoanaliza częściowego wycieku nonce: rekonstrukcja klucza prywatnego za pomocą redukcji baz krat LLL.
4. Symulacja wstrzykiwania błędów (Fault Injection) podczas obliczeń skalarnych na eliptycznej krzywej secp256k1.
5. Implementacja deterministycznego generowania nonce zgodnie ze standardem RFC 6979 w oparciu o funkcję HMAC.
6. Zabezpieczenia sprzętowe i programowe przed atakami różnicowej analizy błędów: obligatoryjna weryfikacja podpisu przed emisją.

Przykładowe wnioski (wzór do sprawozdania): Symulacja programowego wstrzyknięcia błędu w proces generowania podpisów ECDSA na krzywej secp256k1 unaoczniła katastrofalne skutki ponownego użycia tego samego parametru nonce. Zaledwie dwa podpisy cyfrowe wygenerowane z tą samą wartością k pozwoliły na trywialne, algebraiczne obliczenie nadrzędnego klucza prywatnego węzła skarbowego w ułamku milisekundy. Doświadczenie wykazało ponadto, że nawet częściowy wyciek zaledwie kilku najmniej znaczących bitów nonce w serii kilkudziesięciu podpisów pozwala na odzyskanie klucza tajnego za pomocą redukcji baz krat LLL. Skutecznym środkiem zaradczym okazało się natychmiastowe zaimplementowanie deterministycznego schematu RFC 6979, który wylicza wartość nonce za pomocą kryptograficznego kodu HMAC z klucza i treści transakcji. Wprowadzenie obligatoryjnej weryfikacji poprawności podpisu przed jego wyemitowaniem całkowicie zneutralizowało ryzyko ataków typu Differential Fault Analysis.

Zadanie opiera się na treściach Wykładu 1 (Zagrożenia sieciowe i segmentacja stref zaufania), Wykładu 3 (Architektura PKI i cykl życia certyfikatów) oraz Wykładu 4 (Protokoły bezpiecznego uwierzytelniania sieciowego i kontrola dostępu). Ćwiczenie weryfikuje efekty uczenia się: W4 (dogłębna znajomość architektury Zero Trust, protokołu rejestracji certyfikatów SCEP RFC 8894 oraz standardu EAP-TLS RFC 5216), U2 (zarządzanie urządzeniami brzegowymi MikroTik RouterOS v7.x w trybie CLI oraz integracja z serwerem RADIUS), U3 (analiza telemetrii logów sieciowych i kalkulacja wektorów CVSS v4.0), U4 (projektowanie odpornej bramy brzegowej z automatyczną izolacją zagrożeń) oraz K1 (odpowiedzialność inżynierska za poufność teleinformatyczną administracji publicznej). Wymagania normatywne obejmują specyfikacje RFC 8894 (SCEP), RFC 7296 (IKEv2), RFC 5216 (EAP-TLS), klasyfikację CWE-295 (Improper Certificate Validation) oraz techniki matrycy MITRE ATT&CK: T1133 i T1556.

Nadrzędnym celem zadania jest zaprojektowanie i wdrożenie odpornej architektury dostępu brzegowego Zero Trust w oparciu o system MikroTik RouterOS v7.x. Zespół studentów konfiguruje automatyczną rejestrację i rotację certyfikatów kryptograficznych routera z wykorzystaniem protokołu SCEP (Simple Certificate Enrollment Protocol). Następnie studenci zestawiają bezpieczny tunel VPN w standardzie IKEv2 z dwukierunkowym uwierzytelnianiem EAP-TLS zintegrowanym z serwerem FreeRADIUS. Ćwiczenie pozwala zrozumieć zasady eliminacji haseł statycznych na rzecz tożsamości kryptograficznej w sieciach rozległych.

W części audytorskiej celem jest przeprowadzenie symulacji próby nawiązania połączenia przez skompromitowanego użytkownika z unieważnionym certyfikatem X.509. Studenci badają mechanizm weryfikacji list odwołań CRL w serwerze tożsamości oraz dynamiczną reakcję zapory ogniowej RouterOS blokującą podejrzany adres IP. Zadanie kończy się opracowaniem sygnatury Suricata NIDS wykrywającej odrzucenia autoryzacji w ruchu RADIUS.

Ministerstwo Cyfryzacji wdraża nowy standard bezpiecznego dostępu zdalnego dla operatorów Krajowego Schematu Identyfikacji Elektronicznej. Dotychczasowa architektura oparta na statycznych kluczach współdzielonych (Pre-Shared Keys) oraz manualnie wgrywanych certyfikatach generowała wysokie ryzyko kompromitacji poświadczeń i paraliżowała rotację kluczy. Zgodnie z wytycznymi bezpieczeństwa, węzły brzegowe muszą automatycznie odnawiać swoje tożsamości przez protokół SCEP.

Router brzegowy MikroTik RouterOS v7.x pełni rolę bramy VPN koncentrującej połączenia od mobilnych stacji klienckich (RoadWarrior). W celu realizacji założeń modelu Zero Trust (Nigdy nie ufaj, zawsze weryfikuj), każdy klient przed uzyskaniem dostępu do podsieci wewnętrznej musi uwierzytelnić się certyfikatem osobistym X.509 za pośrednictwem protokołu EAP-TLS. Wszelkie poświadczenia są weryfikowane w centralnym klastrze serwerów FreeRADIUS.

Studenci realizują konfigurację w konsoli RouterOS CLI. Definiują żądanie certyfikatu i harmonogram odpytywania serwera SCEP, zabezpieczając proces hasłem rejestracyjnym Challenge Password. Po uzyskaniu i podpisaniu certyfikatu tożsamości przez CA, konfigurują profil kryptograficzny IKEv2 z szyfrowaniem AES-256-GCM oraz grupą Diffiego-Hellmana ECP256. Wskazują serwer FreeRADIUS jako backend autoryzacyjny dla tożsamości EAP.

W fazie weryfikacji Red/Blue Team zespół testuje reakcję infrastruktury na próbę połączenia stacji ze skompromitowanym certyfikatem. Administrator unieważnia certyfikat na serwerze CA i odświeża listę CRL. Przy kolejnej próbie nawiązania tunelu serwer RADIUS zwraca pakiet Access-Reject, a skrypt w RouterOS dynamicznie dopisuje adres atakującego do czarnej listy firewall na 24 godziny. Zdarzenie zostaje zarejestrowane przez sensor Suricata.

• MikroTik RouterOS v7.x (CHR / x86): system operacyjny routera brzegowego z obsługą klienta SCEP i serwera IKEv2.
• FreeRADIUS 3.x: serwer tożsamości realizujący uwierzytelnianie EAP-TLS z weryfikacją list odwołań CRL.
• OpenXPKI / Dogtag SCEP Server: serwer PKI udostępniający interfejs protokołu SCEP do automatycznej rejestracji.
• Wireshark / TShark: analizator sieciowy do inspekcji uścisku dłoni IKEv2 oraz pakietów RADIUS Access-Request.
• Suricata NIDS 7.0+: system detekcji intruzów analizujący zdarzenia autoryzacji w segmencie serwerowym.
• OpenSSL CLI: narzędzie do zarządzania listami unieważnień CRL i weryfikacji łańcuchów certyfikatów.

1. Uruchom maszynę wirtualną MikroTik RouterOS v7.x i skonfiguruj adresację IP interfejsów sieciowych.
2. Zainstaluj i skonfiguruj serwer FreeRADIUS z obsługą modułu EAP-TLS oraz certyfikatów X.509.
3. Skonfiguruj szablon certyfikatu routera w menu /certificate z rozszerzeniem tls-server.
4. Zdefiniuj klienta SCEP w RouterOS CLI, wskazując URL serwera certyfikacji oraz hasło rejestracyjne.
5. Zweryfikuj pobranie certyfikatu nadrzędnego CA oraz pomyślne wystawienie certyfikatu tożsamości routera.
6. Skonfiguruj klienta RADIUS w RouterOS wskazującego adres IP serwera FreeRADIUS oraz tajny klucz współdzielony.
7. Utwórz profil IKEv2 z algorytmem haszującym SHA-256, szyfrowaniem AES-256 oraz grupą DH ECP256.
8. Zdefiniuj propozycję IPSec proposal z szyfrem uwierzytelnionym AES-256-GCM i grupą PFS ECP256.
9. Skonfiguruj peer IKEv2 w trybie pasywnym dedykowany dla klientów zdalnych RoadWarrior.
10. Zdefiniuj tożsamość identity wskazującą certyfikat SCEP routera oraz metodę autoryzacji eap-radius.
11. Utwórz pulę adresową IP i konfigurację trybu mode-config przydzielającą adresy podsieci wirtualnej VPN.
12. Nawiąż połączenie testowe z klienta zdalnego i przeanalizuj uścisk dłoni EAP-TLS w logach FreeRADIUS.
13. Zasymuluj incydent bezpieczeństwa: unieważnij certyfikat testowego klienta na serwerze urzędu certyfikacji.
14. Wygeneruj zaktualizowaną listę CRL i załaduj ją do pamięci demona FreeRADIUS.
15. Ponów próbę nawiązania połączenia z unieważnionym certyfikatem i zarejestruj odpowiedź Access-Reject.
16. Skonfiguruj skrypt w RouterOS dopisujący źródłowy adres IP odrzuconego klienta do dynamicznej listy blokującej firewall.
17. Opracuj sygnaturę Suricata NIDS wykrywającą anomalie odrzuceń autoryzacji EAP-TLS w sieci wewnętrznej.

Architektura Zero Trust zakłada brak domyślnego zaufania do jakiegokolwiek elementu sieci, niezależnie od jego fizycznej lokalizacji. W modelu tym tożsamość kryptograficzna (certyfikat X.509) zastępuje statyczne hasła i klucze PSK. Protokół SCEP (Simple Certificate Enrollment Protocol, RFC 8894) umożliwia urządzeniom sieciowym automatyczne wnioskowanie o certyfikaty tożsamości oraz ich cykliczną rotację przed upływem terminu ważności bez ingerencji administratora.

W systemie MikroTik RouterOS v7.x protokół SCEP jest zintegrowany bezpośrednio z podsystemem certyfikatów (/certificate scep-client). Router samodzielnie generuje parę kluczy asymetrycznych w pamięci chronionej, po czym przesyła żądanie PKCS#7 / PKCS#10 do serwera SCEP. Klucz prywatny routera nigdy nie opuszcza urządzenia.

Z kolei standard EAP-TLS (RFC 5216) w połączeniu z IKEv2 (RFC 7296) zapewnia najwyższy poziom bezpieczeństwa tuneli VPN. Podczas uścisku dłoni router uwierzytelnia się wobec klienta certyfikatem wystawionym przez SCEP, natomiast klient uwierzytelnia się certyfikatem osobistym. Router przekazuje komunikaty EAP do serwera RADIUS za pomocą protokołu EAP-RADIUS, umożliwiając centralną kontrolę stanu kont i unieważnień certyfikatów.

Poniżej przedstawiono listingi konfiguracji klienta SCEP i serwera IKEv2 w RouterOS CLI, inspekcję logów FreeRADIUS oraz sygnaturę Suricata.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Paradygmat Zero Trust Network Access w zarządzaniu infrastrukturą brzegową urządzeń sieciowych MikroTik RouterOS.
2. Protokół SCEP (RFC 8894): automatyzacja procesu wnioskowania, odnawiania i instalacji certyfikatów X.509.
3. Konfiguracja tuneli IKEv2 / IPsec z uwierzytelnianiem EAP-TLS z wykorzystaniem nowoczesnych algorytmów kryptograficznych.
4. Rygorystyczna weryfikacja certyfikatów klienckich: sprawdzanie statusu unieważnienia oraz pól tożsamości SAN.
5. Eliminacja podatności statycznych haseł Pre-Shared Keys oraz przestarzałych protokołów tunelowania sieciowego.
6. Zapewnienie ciągłości działania i bezprzerwowej rotacji certyfikatów w strategicznych węzłach łączności państwowej.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie architektury Zero Trust na routerach MikroTik RouterOS z wykorzystaniem protokołu SCEP wyeliminowało podatności związane z ręczną obsługą i długim cyklem życia poświadczeń. Zautomatyzowany potok odnawiania certyfikatów pozwolił na skrócenie ważności kluczy węzłowych do 30 dni bez konieczności angażowania personelu administratorskiego. Zestawienie tunelu IKEv2 z uwierzytelnianiem EAP-TLS zapewniło kryptograficzną pewność tożsamości stacji operatorskich oraz pełną odporność na ataki podsłuchu i manipulacji pakietami. Wykorzystanie nowoczesnych grup Diffie-Hellmana na krzywych eliptycznych zagwarantowało doskonałe utajnianie w przód dla całego przesyłanego ruchu administracyjnego. Przeprowadzone wdrożenie stanowi wzorcową realizację zaleceń pełnomocnika rządu ds. cyberbezpieczeństwa w zakresie ochrony dedykowanych węzłów sieciowych.

Zadanie opiera się na treściach Wykładu 3 (Architektura PKI i łańcuchy zaufania), Wykładu 4 (Uwierzytelnianie serwerów WWW i protokoły wymiany tożsamości) oraz Wykładu 6 (Protokoły bezpieczne i monitoring ekosystemu certyfikacji). Ćwiczenie weryfikuje efekty uczenia się: W4 (dogłębna znajomość rejestrów Certificate Transparency RFC 6962, kryptograficznych struktur Merkle Tree, protokołu DANE RFC 6698, DNSSEC oraz rozszerzenia TLS Must-Staple RFC 7633), U1 (implementacja demona monitorującego CT w języku Python), U3 (analiza logów audytowych i kalkulacja wektorów ryzyka CVSS v4.0), U4 (konfiguracja strefy DNSSEC i rekordów TLSA w serwerze DNS) oraz K1 (odpowiedzialność inżynierska za ochronę tożsamości domen i usług państwowych przed atakami Rogue CA). Standardy normatywne obejmują RFC 6962 (CT), RFC 6698 (DANE), RFC 7633 (TLS Must-Staple), historyczny incydent DigiNotar (CVE-2011-3389), słabość CWE-295 oraz techniki matrycy MITRE ATT&CK: T1588.004, T1584 i T1557.

Nadrzędnym celem zadania jest zbadanie podatności globalnego ekosystemu komercyjnych urzędów certyfikacji na ataki typu Rogue CA oraz wdrożenie wielowarstwowych mechanizmów obronnych uniezależniających domenę od zewnętrznych ośrodków zaufania. Zespół studentów opracowuje autorski skrypt w języku Python monitorujący publiczne rejestry Certificate Transparency (CT Logs) w czasie rzeczywistym. Ponadto studenci wdrażają twarde powiązanie tożsamości kryptograficznej serwera za pomocą rekordów TLSA protokołu DANE zabezpieczonych łańcuchem DNSSEC. Ćwiczenie uświadamia konieczność weryfikacji tożsamości cyfrowej na wielu niezależnych płaszczyznach teleinformatycznych.

W części wdrożeniowej studenci konfigurują w serwerze OpenSSL rozszerzenie TLS Must-Staple (RFC 7633) wymuszające dołączanie aktualnej odpowiedzi OCSP i uniemożliwiające ataki typu Soft-Fail. Zespół symuluje próbę podstawienia nieautoryzowanego certyfikatu przez skompromitowany urząd certyfikacji oraz weryfikuje jego natychmiastowe odrzucenie przez mechanizm walidacji DANE. Końcowym etapem jest konstrukcja reguły Sigma alarmującej zespół SOC o wykryciu niezatwierdzonego certyfikatu w rejestrach publicznych.

Bank Gospodarstwa Krajowego zarządza strategicznym portalem obsługi obligacji skarbowych i transferów międzyrządowych. W przeszłości incydenty takie jak kompromitacja urzędu DigiNotar udowodniły, że włamanie do pojedynczego zagranicznego ośrodka CA pozwala cyberprzestępcom lub wrogim służbom wywiadowczym na wystawienie w pełni zaufanego certyfikatu dla dowolnej domeny rządowej i przeprowadzenie ataku Man-in-the-Middle. Bank wdraża strategię eliminacji bezwzględnego zaufania do publicznych CA.

Pierwszą linią obrony jest zautomatyzowany monitoring rejestrów Certificate Transparency (RFC 6962). Wszystkie publicznie zaufane certyfikaty muszą zostać zarejestrowane w publicznych kryptograficznych strukturach drzew skrótów Merkle Tree prowadzonych przez niezależne podmioty. Analitycy Purple Team budują usługę w języku Python odpytującą interfejsy API rejestrów i alarmującą o wystawieniu jakiegokolwiek nowego certyfikatu dla domeny bgk.gov.pl.

Drugą, niepodważalną warstwą zabezpieczenia jest standard DANE (DNS-based Authentication of Named Entities, RFC 6698). Wykorzystując kryptograficznie podpisaną strefę DNSSEC, bank publikuje rekord TLSA wskazujący hash SHA-256 klucza publicznego (SPKI) autoryzowanego serwera. Przeglądarka internetowa walidująca rekord TLSA odrzuca każdy certyfikat pochodzący z obcego CA, nawet jeśli posiada on poprawny podpis root z magazynu systemowego.

Uzupełnieniem architektury obronnej jest rozszerzenie TLS Must-Staple (RFC 7633). W klasycznym modelu przeglądarki ignorują brak odpowiedzi serwera OCSP (zasada soft-fail), co pozwala atakującemu na zablokowanie ruchu sprawdzającego unieważnienie. Must-Staple wymusza regułę hard-fail: brak zszytej odpowiedzi OCSP Stapling w pakiecie uścisku dłoni skutkuje natychmiastowym zerwaniem połączenia przez klienta.

• Python 3 (moduły requests, cryptography): środowisko do budowy demona odpytującego API rejestrów Certificate Transparency.
• Bind9 / Unbound: serwer DNS z obsługą kryptograficznego podpisywania stref DNSSEC i rekordów TLSA.
• OpenSSL CLI: pakiet narzędziowy do ekstrakcji skrótów SPKI i generowania certyfikatów z rozszerzeniem Must-Staple.
• Delv / Dig: uniksowe narzędzia diagnostyczne do inspekcji rekordów DNSSEC oraz walidacji łańcucha RRSIG/DNSKEY.
• Suricata NIDS 7.0+: system wykrywania intruzów analizujący ruch DNS i uściski dłoni TLS pod kątem anomalii.
• Rsyslog i Logstash: komponenty telemetrii systemowej do przesyłania alertów o nowych certyfikatach do SIEM.

1. Zbuduj środowisko robocze z serwerem DNS Bind9 oraz stacją monitoringu wyposażoną w interpreter Python 3.
2. Zaprojektuj skrypt w języku Python odpytujący publiczne interfejsy API Certificate Transparency dla badanej domeny.
3. Zaimplementuj mechanizm filtrowania wyników porównujący odciski certyfikatów z listą autoryzowanych kluczy instytucji.
4. Przetestuj działanie skryptu monitorującego, wykrywając nowo zarejestrowany certyfikat testowy w czasie rzeczywistym.
5. Skonfiguruj podpisanie strefy domenowej bgk.local za pomocą mechanizmów DNSSEC (klucze ZSK i KSK).
6. Wyodrębnij klucz publiczny serwera X.509 w formacie Subject Public Key Info (SPKI) za pomocą polecenia openssl pkey.
7. Oblicz skrót SHA-256 wyodrębnionego klucza publicznego SPKI za pomocą narzędzia openssl dgst.
8. Utwórz rekord TLSA w strefie DNS o parametrach Usage 3, Selector 1, Matching 1 odpowiadających przypięciu SPKI.
9. Przeładuj strefę DNS i zweryfikuj poprawność rekordu oraz podpisów RRSIG za pomocą polecenia delv.
10. Skonfiguruj plik konfiguracyjny żądania certyfikatu OpenSSL, dodając OID rozszerzenia TLS Must-Staple (1.3.6.1.5.5.7.1.24).
11. Wystaw certyfikat z rozszerzeniem Must-Staple i zweryfikuj obecność flagi w poleceniu openssl x509 -text.
12. Uruchom testowy serwer HTTPS bez uruchomionej usługi OCSP Responder i zarejestruj reakcję klienta na brak zszycia OCSP.
13. Uruchom lokalny responder OCSP i potwierdź poprawne nawiązanie połączenia przy obecności poprawnej odpowiedzi Stapling.
14. Zasymuluj atak Rogue CA: wygeneruj certyfikat podpisany przez obce CA i spróbuj nawiązać połączenie z walidacją DANE.
15. Potwierdź natychmiastowe odrzucenie fałszywego certyfikatu przez mechanizm DANE pomimo poprawnego podpisu urzędu CA.
16. Opracuj regułę detekcji Sigma identyfikującą pojawienie się w logach wpisów o certyfikatach od niezatwierdzonych wystawców.
17. Sporządź raport inżynierski podsumowujący mechanizmy obrony przed atakami Rogue CA oraz analizę wektora CVSS v4.0.

Certificate Transparency (CT, RFC 6962) to otwarty standard audytu publicznych certyfikatów X.509. Centra certyfikacji są zobowiązane do rejestrowania każdego wystawionego certyfikatu w publicznych, niezmiennych dziennikach opartych na strukturze drzewa Merkle (Merkle Tree). Odpowiedzią rejestru jest znacznik czasu SCT (Signed Certificate Timestamp), który przeglądarki internetowe weryfikują podczas uścisku dłoni. Jeśli certyfikat nie znajduje się w rejestrze CT, współczesne przeglądarki uznają go za nieważny.

Standard DANE (DNS-based Authentication of Named Entities, RFC 6698) wykorzystuje infrastrukturę DNSSEC do bezpiecznego powiązania certyfikatu lub klucza publicznego z nazwą domenową. Wpis w rekordzie TLSA przyjmuje postać trzech parametrów numerycznych: Usage (np. 3 - Domain-issued certificate), Selector (np. 1 - Subject Public Key Info) oraz Matching Type (np. 1 - SHA-256). Dzięki DANE administrator domeny ma pełną kontrolę nad tym, jakie klucze są uznawane za autentyczne, unieszkodliwiając ataki fałszywych certyfikatów Rogue CA.

Z kolei rozszerzenie TLS Feature Must-Staple (RFC 7633) rozwiązuje fundamentalną słabość mechanizmów sprawdzania statusu odwołań certyfikatów. Klasyczny mechanizm OCSP w przypadku braku odpowiedzi serwera dopuszcza kontynuację połączenia (tzw. Soft-Fail), co pozwala atakującemu Man-in-the-Middle na zablokowanie ruchu do serwera OCSP. Certyfikat z flagą Must-Staple zmusza klienta do wymuszenia twardego błędu (Hard-Fail), jeżeli serwer nie dołączył ważnej odpowiedzi OCSP w uścisku dłoni.

Poniżej przedstawiono listing skryptu Pythona do monitorowania logów CT, procedurę wyznaczania rekordu TLSA w OpenSSL oraz regułę Sigma.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Analiza podatności hierarchicznego modelu PKI na kompromitację pojedynczego urzędu certyfikacji w globalnym łańcuchu zaufania.
2. Ciągły monitoring logów Certificate Transparency w czasie rzeczywistym w celu natychmiastowej detekcji nieautoryzowanych certyfikatów.
3. Rola rozszerzenia TLS Must-Staple w uniemożliwianiu ataków obniżenia poziomu bezpieczeństwa w weryfikacji unieważnień certyfikatów.
4. Integracja protokołu DANE z rekordami TLSA w strefie zabezpieczonej kryptograficznym podpisem DNSSEC.
5. Konfiguracja procedur automatycznego alarmowania i awaryjnego odwoływania certyfikatów w platformie SIEM banku.
6. Spełnienie wymogów bezpieczeństwa operacji skarbowych i transferów międzyrządowych w strategicznych instytucjach finansowych.

Przykładowe wnioski (wzór do sprawozdania): Zintegrowany audyt łańcucha zaufania PKI dla strategicznego portalu bankowego wykazał, że tradycyjny model weryfikacji certyfikatów wymaga uzupełnienia o mechanizmy obrony głębokiej. Wdrożenie zautomatyzowanego skanera rejestrów Certificate Transparency pozwoliło na wykrycie prób rejestracji certyfikatów dla domen bankowych w czasie poniżej trzech sekund od ich emisji. Zastosowanie rozszerzenia TLS Must-Staple w certyfikacie produkcyjnym uniemożliwiło napastnikowi zablokowanie procesu sprawdzania statusu unieważnienia w protokole OCSP. Równoległa publikacja rekordu TLSA w bezpiecznej strefie DNSSEC ostatecznie powiązała tożsamość serwera z domeną, neutralizując ryzyko kompromitacji komercyjnych urzędów CA. Połączenie tych trzech niezależnych technologii gwarantuje nienaruszalność rządowych transferów obligacji skarbowych na najwyższym poziomie odporności teleinformatycznej.

Zadanie opiera się na treściach Wykładu 2 (Podstawy ochrony informacji i wielopoziomowe modele zaufania), Wykładu 3 (Algorytmy asymetryczne, podział sekretu i arytmetyka ciał skończonych Galois) oraz Wykładu 6 (Trendy rozwoju kryptologii i bezpieczeństwo bezwarunkowe Shannona). Ćwiczenie weryfikuje efekty uczenia się: W2 (dogłębna znajomość arytmetyki ciał skończonych Z_p oraz interpolacji wielomianowej Lagrange'a), W3 (mechanika schematów progowych Shamira i pojęcie doskonałego bezpieczeństwa informacyjnego), U1 (implementacja algorytmu Shamir's Secret Sharing w języku Python z wykorzystaniem modułu gmpy2), U3 (analiza ryzyka CVSS v4.0 z metrykami środowiskowymi), U4 (projektowanie procedur komisyjnych i ceremonii kluczy w strukturach PKI) oraz K1 (odpowiedzialność inżynierska za eliminację pojedynczych punktów awarii i przeciwdziałanie zdradzie wewnętrznej). Wymagania normatywne obejmują standardy ANSI X9.69, zalecenia NIST SP 800-57, klasyfikację CWE-653, CWE-284 oraz techniki matrycy MITRE ATT&CK: T1552.004 i T1078.

Głównym celem zadania jest zbadanie matematycznych podstaw kryptografii progowej oraz implementacja algorytmu podziału sekretu Shamira (Shamir's Secret Sharing - SSSS) w schemacie (k-z-n) do ochrony klucza głównego Root CA. Studenci implementują procedurę rozbicia tajnego klucza prywatnego na n niezależnych udziałów w oparciu o wielomiany losowe w ciele liczb pierwszych. Zespół dowodzi matematycznie własności doskonałego bezpieczeństwa Shannona: zebranie mniej niż k udziałów nie ujawnia ani jednego bitu informacji o sekrecie. Ćwiczenie uczy projektowania wieloosobowej kontroli dostępu w środowiskach o krytycznym znaczeniu państwowym.

W części laboratoryjnej studenci tworzą w języku Python skrypt realizujący rekonstrukcję klucza w oparciu o interpolację Lagrange'a w punkcie zerowym dla zadanego kworum uczestników. Zespół przeprowadza symulację ceremonii kluczy, podpisując certyfikat podrzędny w pamięci odizolowanej stacji roboczej, a następnie bezpowrotnie niszcząc zrekonstruowany klucz w RAM. Zadanie kończy się opracowaniem reguły Sigma alarmującej o próbie wywołania operacji podpisu nadrzędnego poza zarejestrowaną sesją komisyjną.

Mennica Państwowa oraz Narodowy Bank Polski wdrażają infrastrukturę emisji suwerennego cyfrowego złotego opartego na certyfikatach skarbowych. Posiadanie klucza prywatnego nadrzędnego urzędu Root CA pozwala na autoryzację emisji nieograniczonej ilości środków płatniczych. Przepisy prawa bankowego oraz wytyczne nadzoru finansowego kategorycznie zabraniają, aby jakakolwiek pojedyncza osoba – w tym Prezes Zarządu lub Główny Administrator – dysponowała pełnym kluczem prywatnym.

Ryzyko związane z pojedynczym punktem zaufania (Single Point of Trust), szantażem, wrogim przejęciem lub zdradą wewnętrzną eliminuje się poprzez zastosowanie kryptograficznego schematu progowego Shamira o parametrach (k=3, n=5). Klucz prywatny Root CA zostaje podzielony na 5 odrębnych udziałów kryptograficznych przekazanych na kartach mikroprocesorowych 5 uprawnionym członkom komitetu emisyjnego.

Studenci wcielają się w rolę kryptologów odpowiedzialnych za realizację ceremonii podziału klucza na odciętej od sieci stacji typu air-gap. Generują losowy wielomian stopnia drugiego f(x) w ciele skończonym o dużym module pierwszym, którego wyrazem wolnym jest liczba reprezentująca klucz prywatny. Każdy z 5 depozytariuszy otrzymuje parę (x, f(x)). W trakcie regularnej pracy klucz prywatny fizycznie nie istnieje w żadnym urządzeniu ani systemie plików.

W momencie konieczności podpisania nowego certyfikatu emisyjnego zwoływane jest kworum minimum 3 członków zarządu. Program laboratoryjny rekonstruuje wartość klucza w zabezpieczonym buforze pamięci operacyjnej za pomocą wag interpolacyjnych Lagrange'a, wykonuje operację podpisania w OpenSSL, a następnie nieodwracalnie czyści bufor pamięci. Zespół demonstruje, że zmowa 2 członków zarządu jest bezużyteczna, gdyż dysponują nieskończoną liczbą możliwych rozwiązań układu równań.

• Python 3 (gmpy2, cryptography): środowisko obliczeniowe do wielkich liczb pierwszych i interpolacji wielomianowej.
• OpenSSL CLI: pakiet narzędziowy do weryfikacji operacji podpisywania certyfikatów zrekonstruowanym kluczem.
• Narzędzie Shred / Srm: uniksowe narzędzia do trwałego nadpisywania i niszczenia danych w pamięci masowej.
• GDB: debugger procesów do weryfikacji procedury oczyszczania buforów pamięci RAM (Zeroization).
• Auditd i Rsyslog: demony telemetrii systemowej do rejestrowania sesji ceremonialnych na stacji air-gap.
• Bash / Coreutils: standardowe środowisko powłoki uniksowej do automatyzacji procedur komisyjnych.

1. Przygotuj odizolowaną stację roboczą typu air-gap z zainstalowanym interpreterem Python 3 i biblioteką gmpy2.
2. Zdefiniuj bezpieczną liczbę pierwszą p o długości większej niż 4096-bitowy materiał klucza nadrzędnego Root CA.
3. Napisz funkcję generującą losowe współczynniki wielomianu stopnia k-1 w ciele Z_p z użyciem os.urandom.
4. Zaimplementuj procedurę dzielenia sekretu split_secret obliczającą punkty wielomianu (x, f(x)) dla n uczestników.
5. Wygeneruj 4096-bitowy klucz prywatny Root CA i przekształć jego reprezentację binarną na liczbę całkowitą.
6. Wykonaj podział klucza na n=5 udziałów w progowym schemacie k=3 i zapisz udziały do odrębnych plików.
7. Zaimplementuj algorytm rekonstrukcji sekretu recover_secret z wykorzystaniem interpolacji wielomianowej Lagrange'a.
8. Przeprowadź test rekonstrukcji przy użyciu poprawnego kworum 3 dowolnych udziałów (np. udział 1, 3 oraz 5).
9. Potwierdź zgodność odzyskanego klucza prywatnego z oryginałem za pomocą porównania bitowego SHA-256.
10. Przeprowadź symulację ataku: spróbuj odtworzyć klucz przy użyciu zaledwie 2 udziałów i zbadaj uzyskany wynik.
11. Wykryj, że uzyskana wartość jest pseudolosową liczbą, dowodząc doskonałego bezpieczeństwa informacyjnego Shannona.
12. Zintegruj zrekonstruowany klucz w pamięci z biblioteką OpenSSL i podpisz certyfikat podrzędny Urzędu Emisyjnego.
13. Zaimplementuj procedurę bezpiecznego czyszczenia buforów pamięci (Zeroization) nadpisującą zmienne zerami.
14. Zweryfikuj za pomocą debuggera GDB brak pozostałości materiału klucza w stercie procesu po zakończeniu operacji.
15. Opracuj procedurę regulaminową przeprowadzania ceremonii kluczy z podziałem ról komitetu kryptograficznego.
16. Zdefiniuj regułę detekcji Sigma monitorującą nieautoryzowane próby odwołania do procedur podpisu poza sesją kworum.
17. Przygotuj sprawozdanie techniczne zawierające dowód matematyczny twierdzenia Lagrange'a oraz kalkulację CVSS v4.0.

Schemat progowy Shamira (Shamir's Secret Sharing Scheme - SSSS) opiera się na fundamentalnej własności wielomianów: do jednoznacznego wyznaczenia wielomianu stopnia k-1 w ciele skończonym potrzeba dokładnie k punktów. W schemacie progowym (k, n) sekret S jest wyrazem wolnym wielomianu f(0) = S. Współczynniki a_1, a_2, ..., a_{k-1} są losowane w ciele skończonym Z_p, gdzie p jest dużą liczbą pierwszą większą niż sekret. Każdy uczestnik otrzymuje punkt (x_i, y_i), gdzie y_i = f(x_i) mod p.

Najważniejszą cechą schematu Shamira jest doskonałe bezpieczeństwo informacyjne (Information-Theoretic Security). Dysponując k-1 udziałami, dla każdej możliwej wartości sekretu S' istnieje dokładnie jeden wielomian stopnia k-1 przechodzący przez k-1 znanych punktów oraz punkt (0, S'). Oznacza to, że nawet przy nieograniczonej mocy obliczeniowej napastnik nie uzyskuje żadnej informacji o prawdziwym sekrecie.

Odtworzenie sekretu realizowane jest poprzez interpolację Lagrange'a w punkcie x = 0. Wzór interpolacyjny przyjmuje postać f(0) = sum_{j=0}^{k-1} y_j * l_j(0) mod p, gdzie l_j(0) jest bazowym wielomianem Lagrange'a obliczanym jako iloczyn (-x_m) * (x_j - x_m)^(-1) mod p dla wszystkich m != j. Wszystkie operacje dzielenia zastępuje się mnożeniem przez odwrotność modularną wyznaczoną rozszerzonym algorytmem Euklidesa.

Poniżej przedstawiono implementację schematu progowego Shamira w języku Python, procedurę podpisania certyfikatu oraz regułę detekcji Sigma.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Matematyczne podstawy schematu progowego Shamira: interpolacja wielomianowa Lagrange'a w ciele skończonym Galois GF(p).
2. Własność progowości (k, n): odzyskanie sekretu wymaga dokładnie k udziałów, a posiadanie mniejszej liczby nie daje żadnej wiedzy.
3. Zastosowanie schematu progowego do ochrony klucza nadrzędnego Root CA poprzez podział pomiędzy uprawnionych decydentów.
4. Koncepcja kryptograficznego wielopodpisu (Threshold Signatures) w autoryzacji strategicznych operacji finansowych.
5. Procedura bezpiecznej ceremonii scalania klucza w odizolowanym środowisku HSM bez zapisu udziałów w pamięci trwałej.
6. Zgodność z prawem bankowym, wymogami NBP i zaleceniami EBA w zakresie eliminacji pojedynczego punktu awarii.

Przykładowe wnioski (wzór do sprawozdania): Implementacja kryptograficznego schematu progowego Shamira o parametrach 3-z-5 całkowicie wyeliminowała ryzyko nadużycia lub kompromitacji klucza nadrzędnego Root CA przez pojedynczą osobę. Matematyczna właściwość interpolacji wielomianowej w ciele Galois gwarantuje, że posiadanie mniej niż trzech udziałów nie ujawnia napastnikowi ani jednego bitu chronionego sekretu. Klucz główny jest rekonstruowany wyłącznie w ulotnej pamięci modułu bezpieczeństwa podczas oficjalnych ceremonii emisji certyfikatów skarbowych, po czym natychmiast ulega wymazaniu. Rozdzielenie udziałów pomiędzy prezesa banku, audytora oraz oficerów bezpieczeństwa zapewnia pełną rozliczalność i wymusza fizyczną obecność większości uprawnionych decydentów. Zaprojektowane rozwiązanie stanowi niezłomny fundament bezpieczeństwa suwerennej infrastruktury emisyjnej, spełniający najsurowsze wytyczne Narodowego Banku Polskiego.

Zadanie opiera się na treściach Wykładu 1 (Klasyfikacja zagrożeń sieciowych i ataki Adversary-in-the-Middle), Wykładu 3 (Architektura PKI i protokoły bezpieczne) oraz Wykładu 6 (Trendy rozwoju kryptologii i telemetria jądra systemu operacyjnego). Ćwiczenie weryfikuje efekty uczenia się: W1 (anatomia ataków AiTM, mechanizmy degradacji wersji protokołów oraz techniki usuwania szyfrowania transportowego), W4 (specyfikacja strażnika Downgrade Sentinel w protokole TLS 1.3 RFC 8446), U1 (obsługa narzędzi pentestowych i diagnostycznych Bettercap i Wireshark), U3 (kalkulacja wektorów ryzyka CVSS v4.0 z metrykami środowiskowymi), U4 (inżynieria wielowarstwowej detekcji w technologiach Suricata NIDS, eBPF oraz SIEM Sigma) oraz K1 (odpowiedzialność inżynierska za ochronę infrastruktury krytycznej zgodnie z dyrektywą DORA i ustawą o KSC). Wymagania normatywne obejmują RFC 8446 (TLS 1.3), RFC 6797 (HSTS), RFC 7457, podatność POODLE Downgrade CVE-2014-3566, słabość CWE-319 oraz techniki matrycy MITRE ATT&CK: T1557.002, T1562.001 i T1040.

Nadrzędnym celem zadania jest przeprowadzenie pełnej, zintegrowanej operacji Purple Team weryfikującej odporność krytycznego węzła sieciowego na ataki manipulacji negocjacją szyfrowania (TLS Downgrade) oraz usuwania warstwy transportowej (SSL Stripping). Zespół Red Team wykonuje kontrolowaną symulację ataku typu Adversary-in-the-Middle, próbując wymusić użycie przestarzałych wersji protokołu TLS 1.0 oraz słabych szyfrów blokowych. Zespół Blue Team wdraża twarde mechanizmy obronne: wstępne ładowanie nagłówka HSTS Preload, politykę CSP oraz mechanizm Downgrade Sentinel zdefiniowany w standardzie TLS 1.3. Ćwiczenie uczy holistycznego łączenia kryptoanalizy ofensywnej z inżynierią detekcji i hardeningiem.

W części telemetrycznej inżynierowie wdrażają sondy jądra Linux eBPF monitorujące stany gniazd sieciowych oraz konstruują dedykowane sygnatury w systemie NIDS Suricata wykrywające obecność bajtów strażnika w pakietach ServerHello. Zespół integruje strumienie zdarzeń z regułą Sigma w systemie SIEM alarmującą o nieautoryzowanym renegocjowaniu połączeń. Całość prac dokumentuje formalny raport operacyjny Purple Team z kalkulacją wektora CVSS v4.0 uwzględniającego metryki środowiskowe infrastruktury krytycznej.

Główny Punkt Wymiany Ruchu Internetowego (IXP) w Warszawie koordynuje węzły dostępowe do infrastruktury krytycznej krajowych operatorów telekomunikacyjnych i sektora finansowego. W ramach audytu zgodności z unijną dyrektywą DORA oraz ustawą o Krajowym Systemie Cyberbezpieczeństwa (KSC), zespół Purple Team otrzymuje zadanie przetestowania odporności stacji operatorskich zarządzających węzłami na ataki na styku sieci lokalnej LAN.

W pierwszej fazie ćwiczenia specjaliści Red Team zajmują pozycję na ścieżce transmisyjnej za pomocą ataku ARP Poisoning i DNS Spoofing. Wykorzystując narzędzie Bettercap, uruchamiają moduł SSL Stripping, przechwytując żądania HTTP i podmieniając odnośniki HTTPS na połączenia otwarte. Równolegle atakujący próbują zmusić klienta i serwer do negocjacji podatnego protokołu TLS 1.0 z szyfrem 3DES-CBC w celu podsłuchania ciasteczek sesyjnych administratora.

W odpowiedzi inżynierowie Blue Team konfigurują serwer WWW w oparciu o najnowsze zalecenia kryptograficzne. Wdrażają nagłówek Strict-Transport-Security z dyrektywą preload i maksymalnym czasem ważności, co uniemożliwia przeglądarce wykonanie jakiegokolwiek połączenia nieszyfrowanego. Ponadto studenci badają strukturę uścisku dłoni TLS 1.3: w przypadku próby wymuszenia starszego protokołu serwer wysyła w ostatnich 8 bajtach pola ServerHello.random sekwencję Downgrade Sentinel (DOWNGRD\x01 dla TLS 1.2 lub DOWNGRD\x00 dla TLS 1.0), powodując natychmiastowe zerwanie sesji przez klienta.

Faza zamykająca operację Purple Team polega na budowie wielowarstwowej detekcji. Studenci piszą skrypt w technologii bpftrace (eBPF) zliczający wywołania funkcji handshake z nieobsługiwanymi wersjami protokołu, dodają sygnaturę Suricata NIDS wykrywającą ciąg znaków strażnika w ruchu sieciowym oraz konstruują regułę Sigma korelującą zdarzenia w dziennikach serwera WWW. Wspólne ćwiczenie kończy się demonstracją neutralizacji wektora ataku i eliminacją luki telekomunikacyjnej.

• Bettercap: specjalistyczna platforma audytorska do realizacji ataków ARP Spoofing i SSL Stripping w sieci LAN.
• Apache 2.4 / Nginx: serwery WWW ze wsparciem dla protokołu TLS 1.3 i nagłówków bezpieczeństwa HSTS.
• Suricata NIDS 7.0+: system inspekcji ruchu analizujący pole ServerHello pod kątem bajtów Downgrade Sentinel.
• BCC / bpftrace: narzędzia telemetrii jądra Linux w technologii eBPF do śledzenia parametrów kryptograficznych.
• Wireshark / TShark: analizator sieciowy do dekodowania poszczególnych pól uścisku dłoni protokołu TLS.
• Python 3 (Scapy): biblioteka do niskopoziomowego manipulowania pakietami TCP/IP i modyfikacji nagłówków.

1. Zbuduj środowisko laboratoryjne składające się z trzech maszyn wirtualnych: stacji ofiary, serwera WWW oraz węzła atakującego.
2. Skonfiguruj serwer Apache do obsługi protokołów TLS 1.2 oraz TLS 1.3 z certyfikatem domeny gov.local.
3. Uruchom narzędzie Bettercap na stacji atakującego i włącz wykrywanie hostów za pomocą polecenia net.probe on.
4. Zdefiniuj cel ataku ARP Poisoning i uruchom podszywanie się pod bramę domyślną za pomocą arp.spoof on.
5. Włącz moduł manipulacji ruchem HTTP i usuwania szyfrowania poleceniem set https.proxy.sslstrip true.
6. Wywołaj połączenie ze stacji ofiary do panelu administracyjnego i zaobserwuj przechwycenie poświadczeń w Bettercap.
7. Wdróż na serwerze WWW twardą politykę HSTS Preload z czasem ważności 2 lat oraz flagą includeSubDomains.
8. Dodaj nagłówek Content-Security-Policy z dyrektywą upgrade-insecure-requests wymuszającą bezpieczny transport.
9. Zweryfikuj zachowanie przeglądarki ofiary po wdrożeniu HSTS i potwierdź całkowite zablokowanie ataku SSL Stripping.
10. Przeprowadź próbę ataku TLS Downgrade, modyfikując wersję w pakiecie ClientHello do poziomu TLS 1.0.
11. Przeanalizuj w narzędziu Wireshark pole ServerHello.random i zidentyfikuj magiczne bajty strażnika DOWNGRD.
12. Potwierdź, że klient TLS 1.3 widząc wartość Downgrade Sentinel natychmiast zrywa połączenie błędem illegal_parameter.
13. Napisz skrypt w technologii bpftrace podpinający sondę pod funkcję jądra zliczającą renegocjacje połączeń TLS.
14. Opracuj sygnaturę sieciową Suricata NIDS wykrywającą ciąg bajtów strażnika DOWNGRD w pakiecie ServerHello.
15. Opracuj regułę Sigma identyfikującą w logach serwera żądania administracyjne przesyłane protokołem TLS 1.0 lub czystym HTTP.
16. Przetestuj działanie całego łańcucha detekcji i zweryfikuj wygenerowanie alertów o wysokim priorytecie w SOC.
17. Przygotuj raport inżynierski operacji Purple Team zawierający analizę telemetrii eBPF oraz wektor CVSS v4.0.

Atak SSL Stripping, zaprezentowany po raz pierwszy przez Moxie Marlinspike'a, polega na przechwyceniu ruchu pomiędzy użytkownikiem a serwerem i przezroczystej zamianie wszystkich odnośników HTTPS na nieszyfrowane HTTP. Użytkownik komunikuje się z atakującym otwartym tekstem, a napastnik utrzymuje szyfrowane połączenie HTTPS z serwerem docelowym. Jedyną skuteczną obroną przed tym atakiem jest mechanizm HSTS (HTTP Strict Transport Security, RFC 6797) z listą Preload, który wymusza na przeglądarce łączenie się wyłącznie przez HTTPS zanim jeszcze wyśle ona pierwsze zapytanie sieciowe.

Z kolei atak TLS Downgrade polega na ingerencji pośrednika w negocjację wersji protokołu lub zestawu szyfrów. Atakujący modyfikuje pakiety ClientHello, usuwając obsługę nowszych wersji (np. TLS 1.3) i zmuszając strony do renegocjacji podatnego standardu (np. TLS 1.0 lub szyfrów CBC podatnych na POODLE/Lucky13). W celu uniemożliwienia tego typu manipulacji, standard TLS 1.3 (RFC 8446) wprowadził mechanizm Downgrade Sentinel.

Mechanizm Downgrade Sentinel nakazuje serwerowi TLS 1.3, który z powodu żądania klienta musi wynegocjować starszą wersję protokołu, umieszczenie ściśle określonych 8 bajtów na końcu 32-bajtowego pola Random w komunikacie ServerHello. Dla wersji TLS 1.2 bajty te przyjmują wartość szesnastkową 44 4F 57 4E 47 52 44 01 (odpowiadającą napisowi ASCII DOWNGRD\x01), a dla wersji TLS 1.1 i TLS 1.0 – wartość DOWNGRD\x00. Klient obsługujący TLS 1.3 po wykryciu tych bajtów wie, że padł ofiarą manipulacji pośrednika i natychmiast zrywa połączenie.

Poniżej przedstawiono listingi wykonania ataku w Bettercap, konfigurację nagłówków HSTS w Apache, analizę pakietu ServerHello oraz sygnaturę Suricata i regułę Sigma.

Poniższa lista zawiera propozycje zagadnień i wniosków technicznych, które warto uwzględnić w sprawozdaniu z tego zadania:

1. Analiza technik manipulacji negocjacją parametrów TLS: wymuszanie obniżenia wersji protokołu oraz usuwanie bezpiecznych szyfrów.
2. Podatności mechanizmów wznawiania sesji TLS (TLS Session Tickets): przechwytywanie i analiza biletów sesyjnych.
3. Wykorzystanie sond jądra Linux eBPF do niskopoziomowego audytu parametrów handshake TLS w czasie rzeczywistym.
4. Inżynieria zaawansowanych reguł w systemie IDS Suricata: wykrywanie pakietów ClientHello ze zubożoną listą szyfrów.
5. Opracowanie reguł Sigma korelujących anomalie wynegocjowanych algorytmów z alertami sieciowymi w punkcie wymiany ruchu IXP.
6. Opracowanie zaleceń utwardzających warstwę kryptograficzną dla operatorów infrastruktury krytycznej podlegających dyrektywie DORA.

Przykładowe wnioski (wzór do sprawozdania): Zrealizowana operacja Purple Teaming w węźle wymiany ruchu internetowego obnażyła zaawansowane próby manipulacji pakietami ClientHello mające na celu wymuszenie podatnych zestawów szyfrów. Zespół czerwony zademonstrował możliwość obniżenia bezpieczeństwa sesji TLS poprzez selektywne usuwanie rozszerzeń kryptograficznych w locie przez złośliwy węzeł tranzytowy. Zastosowanie dedykowanego programu eBPF w jądrze systemu pozwoliło na przechwycenie parametrów negocjacji bezpośrednio na poziomie interfejsu sieciowego z zerowym narzutem na opóźnienia pakietów. Na podstawie zebranej telemetrii inżynierowie defensywni wdrożyli reguły Suricata, które natychmiast flagują połączenia próbujące negocjować przestarzałe parametry kryptograficzne. Wyniki ćwiczenia dostarczyły bezcennych danych operacyjnych, pozwalając na skuteczne uszczelnienie węzła szkieletowego zgodnie z wytycznymi unijnego rozporządzenia DORA.