Poziom: ocena 3.0 - podstawy kryptografii asymetrycznej i podpisów cyfrowych

Zestaw 10 praktycznych zadań laboratoryjnych do wykonania w trakcie zajęć (90–100 minut).
Kierunek: Informatyka, semestr 7, przedmiot: Kryptologia.
Podstawa materiałowa: wykład część 4 (kryptografia asymetryczna - RSA, ECC, Diffie-Hellman i podpisy cyfrowe).

1. 01.Generowanie par kluczy RSA i analiza ich struktury ASN.1 oraz formatu PEM w OpenSSL i CyberChef
2. 02.Szyfrowanie i deszyfrowanie asymetryczne RSA oraz analiza dopełnienia PKCS#1 v1.5 i OAEP
3. 03.Podstawowa wymiana kluczy Diffiego-Hellmana (DH) w narzędziu konsolowym OpenSSL i kalkulatorze WWW
4. 04.Podatność protokołu Diffiego-Hellmana na atak Man-in-the-Middle (MitM) przy braku uwierzytelnienia
5. 05.Generowanie par kluczy i inspekcja parametrów kryptografii krzywych eliptycznych (ECC: P-256 vs Curve25519)
6. 06.Uzgadnianie klucza w protokole Elliptic Curve Diffie-Hellman (ECDH / X25519) w OpenSSL i CyberChef
7. 07.Tworzenie i weryfikacja podpisów cyfrowych RSA w formatach PKCS#1 v1.5 oraz RSA-PSS
8. 08.Podpisy cyfrowe oparte na krzywych eliptycznych ECDSA i Ed25519 w OpenSSL
9. 09.Praktyczne badanie kolizji skrótów SHA-1 w podpisach cyfrowych na przykładzie pary SHAttered
10. 10.Prosty model szyfrowania hybrydowego: kapsułkowanie klucza AES-GCM kluczem publicznym RSA

Cel

Celem zadania jest praktyczne zapoznanie się z procedurą generowania asymetrycznych par kluczy algorytmu RSA o długości 2048 oraz 4096 bitów. Student bada wewnętrzną strukturę matematyczną klucza zapisanego w formacie PEM, dekoduje strukturę ASN.1 DER za pomocą narzędzi OpenSSL oraz CyberChef i identyfikuje składowe n, e, d, p, q oraz wykładniki CRT.

Scenariusz – opis

Zadanie rozpoczynasz od otwarcia konsoli linuksowej JSLinux Alpine z biblioteką OpenSSL oraz serwisu CyberChef w przeglądarce internetowej. Kryptografia asymetryczna opiera się na parze powiązanych matematycznie kluczy, z których jeden jest udostępniany publicznie, a drugi musi pozostać ściśle tajny. W algorytmie RSA klucz opiera się na iloczynie dwóch wielkich liczb pierwszych p oraz q, które tworzą moduł publiczny n. Standardowo jako wykładnik publiczny e stosuje się liczbę pierwszą Fermata F4 równą 65537, która umożliwia efektywne obliczanie potęg modularnych. Klucz prywatny d jest odwrotnością modularną wykładnika e względem funkcji Eulera fi(n), co wynika z rozszerzonego algorytmu Euklidesa. W systemach produkcyjnych klucze kryptograficzne są kodowane w standardzie ASN.1 z serializacją DER i opakowywane w czytelny format PEM z nagłówkami BASE64.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz w przeglądarce terminal JSLinux Alpine oraz serwis CyberChef.
2. W konsoli JSLinux wygeneruj klucz prywatny RSA 2048-bit: openssl genpkey -algorithm RSA -out rsa_priv_2048.pem -pkeyopt rsa_keygen_bits:2048.
3. Wyświetl zawartość pliku klucza poleceniem: cat rsa_priv_2048.pem.
4. Wyeksportuj klucz publiczny: openssl pkey -in rsa_priv_2048.pem -pubout -out rsa_pub_2048.pem.
5. Wyświetl zawartość wygenerowanego klucza publicznego: cat rsa_pub_2048.pem.
6. Wykonaj pełną inspekcję składowych klucza prywatnego: openssl rsa -in rsa_priv_2048.pem -text -noout.
7. Zanotuj wartości modułu n, wykładnika e (0x10001), wykładnika d oraz czynników pierwszych prime1 i prime2.
8. Wykonaj inspekcję klucza publicznego: openssl rsa -pubin -in rsa_pub_2048.pem -text -noout.
9. Przekonwertuj klucz PEM do formatu binarnego DER: openssl rsa -in rsa_priv_2048.pem -outform DER -out rsa_priv.der.
10. Zbadaj strukturę ASN.1 w konsoli poleceniem: openssl asn1parse -in rsa_priv_2048.pem.
11. Wklej zawartość pliku rsa_priv_2048.pem do narzędzia CyberChef i użyj operacji Parse ASN.1.
12. Wygeneruj klucz o długości 4096 bitów mierząc czas: time openssl genpkey -algorithm RSA -out rsa_priv_4096.pem -pkeyopt rsa_keygen_bits:4096 (raportuj tylko czas względny 4096 vs 2048 na tym samym hoście; awaryjnie, gdy emulator zamula, użyj 3072 bitów: -pkeyopt rsa_keygen_bits:3072).
13. Zabezpiecz klucz prywatny hasłem: openssl rsa -in rsa_priv_2048.pem -aes256 -out rsa_priv_enc.pem.
14. Sprawdź nagłówki zaszyfrowanego pliku PEM poleceniem cat rsa_priv_enc.pem i zidentyfikuj deklarację algorytmu szyfrowania klucza.
15. Wykonaj zrzuty ekranu drzewa ASN.1 w CyberChef oraz wyjścia tekstowego openssl rsa -text.
16. Sporządź tabelę porównawczą rozmiarów kluczy 2048 i 4096 bitów w formatach PEM i DER oraz czasów ich generowania.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie matematycznej budowy pary kluczy RSA: roli modułu n, wykładnika e, wykładnika d oraz liczb pierwszych p i q.
• Znajomość struktury formatu PEM (Base64) oraz binarnego formatu ASN.1 DER (PKCS#1 i PKCS#8).
• Praktyczna umiejętność bezpiecznego wyodrębniania klucza publicznego oraz zabezpieczania klucza prywatnego szyfrem symetrycznym.
• Świadomość narzutu wydajnościowego generowania kluczy o długości 4096 bitów w stosunku do standardu 2048 bitów (czasy raportowane wyłącznie względnie na tym samym hoście; wariant awaryjny 3072 bity).

Cel

Celem zadania jest praktyczne zbadanie procesu szyfrowania i deszyfrowania asymetrycznego RSA przy użyciu narzędzia OpenSSL pkeyutl oraz serwisu CyberChef. Student bada wpływ schematów dopełnienia (PKCS#1 v1.5 oraz OAEP ze skrótem SHA-256) na postać szyfrogramu oraz wyznacza maksymalny dopuszczalny rozmiar tekstu jawnego dla zadanego modułu n.

Scenariusz – opis

W tym laboratorium przeanalizujesz proces szyfrowania asymetrycznego za pomocą klucza publicznego RSA i deszyfrowania kluczem prywatnym. Podstawowa formuła matematyczna szyfruje liczbę całkowitą m reprezentującą wiadomość według wzoru c = m^e mod n. W praktyce surowe potęgowanie bez dopełnienia jest skrajnie niebezpieczne, gdyż jest deterministyczne i podatne na ataki algebraiczne. Z tego powodu każda wiadomość musi zostać uzupełniona losowym paddingiem przed wykonaniem operacji modularnej. Historyczny standard PKCS#1 v1.5 wprowadza dopełnienie losowymi bajtami niezerowymi, jednak okazał się podatny na ataki wyroczni paddingu. Nowoczesnym i rekomendowanym standardem jest OAEP (Optimal Asymmetric Encryption Padding), który łączy maskowanie losowe z funkcją skrótu.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Przygotuj w JSLinux klucz prywatny rsa_priv_2048.pem oraz publiczny rsa_pub_2048.pem.
2. Utwórz plik z testową wiadomością: echo -n 'Poufna wiadomosc laboratoryjna' > msg.txt.
3. Zaszyfruj wiadomość z paddingiem PKCS#1 v1.5: openssl pkeyutl -encrypt -pubin -inkey rsa_pub_2048.pem -in msg.txt -out msg_pkcs1.enc.
4. Sprawdź rozmiar szyfrogramu: ls -l msg_pkcs1.enc (powinno być dokładnie 256 bajtów).
5. Zaszyfruj tę samą wiadomość ponownie do pliku msg_pkcs1_kopia.enc i porównaj sumy: sha256sum msg_pkcs1*.enc.
6. Odszyfruj plik kluczem prywatnym: openssl pkeyutl -decrypt -inkey rsa_priv_2048.pem -in msg_pkcs1.enc -out msg_dec.txt.
7. Zweryfikuj zgodność odzyskanego tekstu: diff msg.txt msg_dec.txt.
8. Zaszyfruj wiadomość z użyciem OAEP i SHA-256: openssl pkeyutl -encrypt -pubin -inkey rsa_pub_2048.pem -in msg.txt -out msg_oaep.enc -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256.
9. Odszyfruj szyfrogram OAEP: openssl pkeyutl -decrypt -inkey rsa_priv_2048.pem -in msg_oaep.enc -out msg_oaep_dec.txt -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256.
10. Wygeneruj plik o dopuszczalnym rozmiarze granicznym 190 bajtów: head -c 190 /dev/urandom > msg_190.bin.
11. Zaszyfruj plik 190-bajtowy w schemacie OAEP SHA-256 i potwierdź sukces operacji.
12. Wygeneruj plik o rozmiarze 191 bajtów: head -c 191 /dev/urandom > msg_191.bin.
13. Spróbuj zaszyfrować plik 191-bajtowy i zarejestruj komunikat błędu: data too large for key size.
14. W CyberChef załaduj klucz publiczny i wykonaj operację RSA Encrypt w trybie OAEP.
15. Zmodyfikuj 1 bajt w pliku msg_oaep.enc za pomocą edytora lub polecenia sed/dd i spróbuj go odszyfrować.
16. Zanotuj komunikat błędu deszyfrowania uszkodzonego szyfrogramu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie, dlaczego szyfrowanie asymetryczne RSA produkuje szyfrogram o stałej długości równej długości modułu n.
• Praktyczna weryfikacja losowości paddingu PKCS#1 v1.5 oraz standardu OAEP uniemożliwiającej ataki deterministyczne.
• Precyzyjne wyznaczenie limitu rozmiaru tekstu jawnego w schemacie OAEP w zależności od rozmiaru modułu i funkcji skrótu.
• Wykazanie mechanizmu detekcji uszkodzenia szyfrogramu przy weryfikacji struktury paddingu podczas deszyfrowania.
• Zasada normatywna: nowe systemy tylko OAEP, PKCS#1 v1.5 wyłącznie do odczytu danych historycznych (por. 5.0/zad. 4 Bleichenbacher).

Cel

Celem zadania jest praktyczne przećwiczenie klasycznego protokołu uzgadniania kluczy Diffiego-Hellmana (DH). Student bada strukturę parametrów grupy (liczba pierwsza p oraz generator g), generuje klucze asymetryczne dla dwóch niezależnych stron (Alice i Bob) oraz oblicza wspólny sekret sesyjny w narzędziu OpenSSL i prostym kalkulatorze modularnym online.

Scenariusz – opis

Protokół Diffiego-Hellmana opublikowany w 1976 roku zrewolucjonizował kryptografię, umożliwiając uzgodnienie wspólnego sekretu przez publiczny kanał. Bezpieczeństwo protokołu opiera się na trudności obliczeniowej problemu logarytmu dyskretnego DLP w ciele liczb pierwszych Z_p^*. Strony przed rozpoczęciem komunikacji muszą ustalić wspólne parametry dziedzinowe: wielką liczbę pierwszą p oraz generator grupy g. Każda ze stron losuje swój prywatny wykładnik: Alice wybiera tajną wartość a, natomiast Bob wybiera tajną wartość b. Następnie strony obliczają swoje publiczne wykładniki: Alice wysyła A = g^a mod p, a Bob przesyła B = g^b mod p. Obie strony są w stanie niezależnie obliczyć ten sam wspólny sekret: K = B^a mod p = A^b mod p = g^(a*b) mod p.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Uruchom konsolę JSLinux Alpine w oknie przeglądarki.
2. Wygeneruj parametry grupy DH 2048-bit: openssl genpkey -genparam -algorithm DH -out dh_params.pem -pkeyopt dh_paramgen_prime_len:2048 (mierz czas time; plan B przy zamulaniu: użyj gotowych parametrów RFC 3526 MODP-2048).
3. Wyświetl strukturę parametrów DH: openssl pkeyparam -in dh_params.pem -text -noout.
4. Zidentyfikuj moduł p (liczba pierwsza) oraz generator g (wartość 2).
5. Wygeneruj parę kluczy dla Alice: openssl genpkey -paramfile dh_params.pem -out alice_key.pem.
6. Wyodrębnij klucz publiczny Alice: openssl pkey -in alice_key.pem -pubout -out alice_pub.pem.
7. Wygeneruj parę kluczy dla Boba: openssl genpkey -paramfile dh_params.pem -out bob_key.pem.
8. Wyodrębnij klucz publiczny Boba: openssl pkey -in bob_key.pem -pubout -out bob_pub.pem.
9. Oblicz wspólny sekret po stronie Alice: openssl pkeyutl -derive -inkey alice_key.pem -peerkey bob_pub.pem -out secret_alice.bin.
10. Oblicz wspólny sekret po stronie Boba: openssl pkeyutl -derive -inkey bob_key.pem -peerkey alice_pub.pem -out secret_bob.bin.
11. Porównaj sumy SHA-256 obu plików: sha256sum secret_alice.bin secret_bob.bin.
12. Zbadaj długość wyznaczonego sekretu: ls -l secret_*.bin (256 bajtów odpowiadające 2048 bitom).
13. Otwórz kalkulator modularny online lub konsolę Pythona w JSLinux: python3.
14. Wykonaj miniaturowy test DH: p=23; g=5; a=6; b=15; A = pow(g, a, p); B = pow(g, b, p); Ka = pow(B, a, p); Kb = pow(A, b, p); print(A, B, Ka, Kb).
15. Potwierdź zgodność wartości Ka i Kb równych 2.
16. Wykonaj zrzuty ekranu poleceń konsoli oraz tabeli parametrów do sprawozdania.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie matematycznej zasady działania protokołu Diffiego-Hellmana opartego na potęgowaniu modularnym.
• Praktyczna umiejętność generowania parametrów grupy, kluczy stron oraz derywacji wspólnego sekretu w OpenSSL.
• Dowód na to, że pasywny podsłuchiwacz znający wartości p, g, A, B nie jest w stanie wyznaczyć K bez rozwiązania DLP.
• Zrozumienie relacji pomiędzy długością liczby pierwszej p a długością wynikowego sekretu sesyjnego.

Cel

Celem zadania jest praktyczne zademonstrowanie fundamentalnej luki protokołu Diffiego-Hellmana, jaką jest podatność na atak Man-in-the-Middle (MitM) przy braku uwierzytelnienia stron. Student symuluje trzech uczestników komunikacji (Alice, Bob oraz aktywny napastnik Mallory) i dowodzi, że napastnik może podsłuchiwać i modyfikować cały szyfrowany ruch.

Scenariusz – opis

Klasyczny protokół Diffiego-Hellmana zapewnia poufność wyłącznie przed pasywnym obserwatorem kanału komunikacyjnego. Zasadniczym problemem protokołu jest całkowity brak uwierzytelnienia nadawcy klucza publicznego. Gdy w kanale pojawi się aktywny adwersarz Mallory, może przechwycić klucze publiczne Alice i Boba. Mallory generuje własną parę kluczy DH i podstawia swój klucz publiczny M w miejsce kluczy prawowitych uczestników. W rezultacie Alice uzgadnia wspólny klucz z Mallorym, a Bob uzgadnia zupełnie inny wspólny klucz z Mallorym. Mallory staje się pośrednikiem zdolnym do odszyfrowania każdej wiadomości, jej potajemnej modyfikacji i ponownego zaszyfrowania.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. W terminalu JSLinux wygeneruj parametry DH: openssl genpkey -genparam -algorithm DH -out dh_params.pem -pkeyopt dh_paramgen_prime_len:2048.
2. Wygeneruj klucze Alice: openssl genpkey -paramfile dh_params.pem -out alice_key.pem && openssl pkey -in alice_key.pem -pubout -out alice_pub.pem.
3. Wygeneruj klucze Boba: openssl genpkey -paramfile dh_params.pem -out bob_key.pem && openssl pkey -in bob_key.pem -pubout -out bob_pub.pem.
4. Wygeneruj klucze Mallory'ego: openssl genpkey -paramfile dh_params.pem -out mallory_key.pem && openssl pkey -in mallory_key.pem -pubout -out mallory_pub.pem.
5. Przeprowadź derywację klucza Alice (Alice myśli, że łączy się z Bobem): openssl pkeyutl -derive -inkey alice_key.pem -peerkey mallory_pub.pem -out k_am1.bin.
6. Przeprowadź derywację Mallory dla połączenia z Alice: openssl pkeyutl -derive -inkey mallory_key.pem -peerkey alice_pub.pem -out k_am2.bin.
7. Sprawdź tożsamość klucza Alice-Mallory: cmp k_am1.bin k_am2.bin.
8. Przeprowadź derywację klucza Boba (Bob myśli, że łączy się z Alice): openssl pkeyutl -derive -inkey bob_key.pem -peerkey mallory_pub.pem -out k_bm1.bin.
9. Przeprowadź derywację Mallory dla połączenia z Bobem: openssl pkeyutl -derive -inkey mallory_key.pem -peerkey bob_pub.pem -out k_bm2.bin.
10. Sprawdź tożsamość klucza Bob-Mallory: cmp k_bm1.bin k_bm2.bin.
11. Upewnij się, że klucze obu kanałów są różne: cmp k_am1.bin k_bm1.bin (powinien zgłosić różnicę).
12. Utwórz wiadomość Alice: echo 'Przelew: 1000 PLN do Boba' > msg_orig.txt.
13. Wyprowadź 32-bajtowe klucze AES: sha256sum k_am1.bin | cut -d' ' -f1 > k_am.hex && sha256sum k_bm1.bin | cut -d' ' -f1 > k_bm.hex.
14. Zaszyfruj wiadomość kluczem Alice-Mallory: openssl rand -out iv.bin 16 && openssl enc -aes-256-cbc -in msg_orig.txt -out c_alice.enc -K $(cat k_am.hex) -iv $(xxd -p iv.bin | tr -d '\n') (IV jawny, losowy dla każdego szyfrowania; stałe IV zerowe zabronione).
15. Jako Mallory odszyfruj wiadomość, zmień treść na sfałszowaną i zaszyfruj kluczem Bob-Mallory.
16. Jako Bob odszyfruj wiadomość i zarejestruj udaną manipulację bez wykrycia błędu kryptograficznego.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Empiryczny dowód na podatność czystego protokołu DH na atak pośrednika Man-in-the-Middle.
• Zrozumienie, że protokoły kryptograficzne muszą zapewniać nie tylko poufność, ale także uwierzytelnienie tożsamości.
• Wiedza o tym, w jaki sposób napastnik MitM rozdziela jedną sesję na dwa niezależne tunele kryptograficzne.
• Zrozumienie mechanizmu obrony przed MitM w protokołach SSL/TLS poprzez podpisywanie parametrów DH kluczem certyfikatu X.509.

Cel

Celem zadania jest praktyczne zapoznanie się ze strukturą kluczy kryptografii krzywych eliptycznych (ECC). Student porównuje standardowe krzywe Weierstrassa (NIST P-256) z nowoczesnymi krzywymi Montgomery'ego (Curve25519), bada strukturę punktu bazowego G, klucza prywatnego d oraz klucza publicznego Q = d*G za pomocą narzędzi OpenSSL i CyberChef.

Scenariusz – opis

Kryptografia krzywych eliptycznych (ECC) stanowi fundament współczesnych bezpiecznych komunikatorów i protokołów internetowych. Główną zaletą ECC jest oferowanie równoważnego poziomu bezpieczeństwa przy dramatycznie krótszych kluczach niż w przypadku RSA. Przykładowo 256-bitowy klucz na krzywej eliptycznej zapewnia poziom bezpieczeństwa odpowiadający 3072-bitowemu kluczowi RSA. W ECC klucz prywatny d jest po prostu losową liczbą całkowitą z przedziału rzędu grupy punktów. Klucz publiczny Q jest punktem na krzywej o współrzędnych (x, y) powstałym w wyniku operacji wielokrotnego dodawania punktu bazowego Q = d * G. Odwrócenie tej operacji wymaga rozwiązania problemu logarytmu dyskretnego na krzywych eliptycznych (ECDLP), co jest obliczeniowo nieosiągalne.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Otwórz emulator JSLinux Alpine w oknie przeglądarki.
2. Wyświetl dostępne krzywe eliptyczne: openssl ecparam -list_curves | head -n 25.
3. Zlokalizuj krzywą prime256v1 (NIST P-256) na liście.
4. Wygeneruj parę kluczy na krzywej prime256v1: openssl ecparam -name prime256v1 -genkey -noout -out ec_p256_priv.pem.
5. Wyeksportuj klucz publiczny: openssl ec -in ec_p256_priv.pem -pubout -out ec_p256_pub.pem.
6. Zbadaj strukturę składowych klucza: openssl ec -in ec_p256_priv.pem -text -noout.
7. Zanotuj wartość 256-bitowego klucza prywatnego oraz współrzędne x i y punktu publicznego.
8. Sprawdź klucz publiczny: openssl ec -pubin -in ec_p256_pub.pem -text -noout.
9. Wygeneruj klucz na nowoczesnej krzywej X25519: openssl genpkey -algorithm X25519 -out x25519_priv.pem.
10. Wyeksportuj klucz publiczny X25519: openssl pkey -in x25519_priv.pem -pubout -out x25519_pub.pem.
11. Wyświetl strukturę klucza X25519: openssl pkey -in x25519_priv.pem -text -noout.
12. Przekonwertuj klucze do formatu DER: openssl ec -in ec_p256_priv.pem -outform DER -out p256.der && openssl pkey -in x25519_priv.pem -outform DER -out x25519.der.
13. Porównaj rozmiary plików DER: ls -l *.der.
14. Wklej plik ec_p256_pub.pem do CyberChef i uruchom Parse ASN.1, identyfikując OID krzywej 1.2.840.10045.3.1.7.
15. Wykonaj zrzuty ekranu parametrów w konsoli JSLinux oraz w CyberChef.
16. Opracuj tabelę porównawczą długości kluczy ECC w zestawieniu z kluczami RSA pod kątem bitów bezpieczeństwa NIST.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie reprezentacji kluczy ECC: klucz prywatny jako skalar d, klucz publiczny jako punkt Q na krzywej eliptycznej.
• Identyfikacja nieskompresowanego formatu punktu z prefiksem 0x04 i współrzędnymi x, y.
• Świadomość ogromnej redukcji rozmiaru kluczy w ECC w stosunku do RSA przy zachowaniu tego samego poziomu bezpieczeństwa.
• Praktyczna umiejętność posługiwania się poleceniami openssl ecparam, ec oraz genpkey dla krzywych Weierstrassa i Montgomery'ego.

Cel

Celem zadania jest praktyczne zbadanie protokołu wymiany kluczy na krzywych eliptycznych ECDH (Elliptic Curve Diffie-Hellman). Student przeprowadza procedurę uzgadniania sekretu sesyjnego na krzywej X25519 oraz P-256 pomiędzy dwiema stronami przy użyciu OpenSSL oraz weryfikuje proces derywacji klucza symetrycznego w narzędziu CyberChef.

Scenariusz – opis

Protokół ECDH stanowi adaptację klasycznego schematu Diffiego-Hellmana do algebry grup punktów na krzywych eliptycznych. Zamiast potęgowania modularnego w ciele liczb pierwszych, uczestnicy wykonują mnożenie skalarne punktu na krzywej. Alice generuje prywatny skalar d_A oraz klucz publiczny Q_A = d_A * G, a Bob generuje d_B oraz Q_B = d_B * G. Wspólny sekret powstaje w wyniku pomnożenia cudzego punktu publicznego przez własny prywatny skalar: K = d_A * Q_B = d_B * Q_A = d_A * d_B * G. Współrzędna x wynikowego punktu K jest następnie przekształcana w symetryczny klucz sesyjny za pomocą funkcji skrótu KDF. Dzięki wyjątkowej szybkości i małym narzutom komunikacyjnym protokół ECDH (w szczególności efemeryczny ECDHE) dominuje w standardzie TLS 1.3.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. W konsoli JSLinux wygeneruj klucz X25519 Alice: openssl genpkey -algorithm X25519 -out a_xpriv.pem.
2. Wyeksportuj klucz publiczny Alice: openssl pkey -in a_xpriv.pem -pubout -out a_xpub.pem.
3. Wygeneruj klucz X25519 Boba: openssl genpkey -algorithm X25519 -out b_xpriv.pem.
4. Wyeksportuj klucz publiczny Boba: openssl pkey -in b_xpriv.pem -pubout -out b_xpub.pem.
5. Wykonaj derywację ECDH Alice: openssl pkeyutl -derive -inkey a_xpriv.pem -peerkey b_xpub.pem -out sec_a.bin.
6. Wykonaj derywację ECDH Boba: openssl pkeyutl -derive -inkey b_xpriv.pem -peerkey a_xpub.pem -out sec_b.bin.
7. Zweryfikuj zgodność obu sekretów: cmp sec_a.bin sec_b.bin.
8. Oblicz sumy kontrolne: sha256sum sec_a.bin sec_b.bin.
9. Wygeneruj klucze na krzywej P-256: openssl ecparam -name prime256v1 -genkey -noout -out a_p256.pem && openssl ec -in a_p256.pem -pubout -out a_p256pub.pem.
10. Wygeneruj klucze Boba na P-256: openssl ecparam -name prime256v1 -genkey -noout -out b_p256.pem && openssl ec -in b_p256.pem -pubout -out b_p256pub.pem.
11. Wykonaj derywację na P-256 po obu stronach i porównaj uzyskane sekrety.
12. Wylicz klucz symetryczny: sha256sum sec_a.bin | cut -d' ' -f1 > aes_key.hex.
13. Zaszyfruj wiadomość testową wyliczonym kluczem AES: openssl enc -aes-256-cbc -in a_xpub.pem -out test.enc -K $(cat aes_key.hex) -iv 00112233445566778899aabbccddeeff.
14. Odszyfruj wiadomość za pomocą aes_key.hex i zweryfikuj integralność.
15. W CyberChef odtwórz deszyfrowanie AES z użyciem uzyskanego klucza szesnastkowego.
16. Wykonaj zrzuty ekranu z konsoli oraz sporządź tabelę porównawczą ECDH na X25519 i P-256.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie zasady działania protokołu ECDH opartego na przemienności mnożenia skalarnego punktów.
• Praktyczna umiejętność derywacji wspólnego sekretu z kluczy X25519 oraz NIST P-256 w OpenSSL.
• Zrozumienie konieczności przepuszczenia surowego sekretu przez funkcję KDF (dydaktycznie SHA-256; produkcyjnie HKDF z solą i info wg RFC 5869, por. 5.0/zad. 6).
• Wykazanie ogromnej przewagi wydajnościowej i komunikacyjnej ECDH nad klasycznym protokołem DH.

Cel

Celem zadania jest praktyczne opanowanie procedury generowania oraz weryfikacji podpisów cyfrowych RSA zgodnie ze schematem Hash-then-Sign. Student bada różnice pomiędzy deterministycznym standardem dopełnienia PKCS#1 v1.5 a probabilistycznym schematem RSA-PSS przy użyciu poleceń narzędzia OpenSSL w emulatorze JSLinux oraz serwisu CyberChef.

Scenariusz – opis

Podpis cyfrowy jest kryptograficznym odpowiednikiem podpisu odręcznego, zapewniającym autentyczność, integralność oraz niezaprzeczalność. Ze względów bezpieczeństwa i wydajności nie podpisuje się bezpośrednio całego dokumentu, lecz stosuje paradygmat Hash-then-Sign. Dokument jest najpierw redukowany do stałego skrótu kryptograficznego (np. SHA-256), a następnie skrót ten jest przetwarzany kluczem prywatnym nadawcy. Odbiorca weryfikuje podpis za pomocą klucza publicznego nadawcy, sprawdzając czy odtworzony skrót zgadza się ze skrótem otrzymanego pliku. W klasycznym standardzie PKCS#1 v1.5 podpis jest w pełni deterministyczny: ten sam dokument podpisany tym samym kluczem daje identyczny podpis. Nowoczesny standard RSA-PSS (Probabilistic Signature Scheme) wprowadza losową sól (salt) i funkcję maskującą MGF1, zapewniając dowodliwe bezpieczeństwo.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Uruchom maszynę JSLinux Alpine i upewnij się, że posiadasz rsa_priv_2048.pem oraz rsa_pub_2048.pem.
2. Utwórz plik z umową: echo 'Oficjalna tresc deklaracji laboratoryjnej studenta' > umowa.txt.
3. Wygeneruj podpis PKCS#1 v1.5 ze skrótem SHA-256: openssl dgst -sha256 -sign rsa_priv_2048.pem -out sig_pkcs1.bin umowa.txt.
4. Zweryfikuj podpis kluczem publicznym: openssl dgst -sha256 -verify rsa_pub_2048.pem -signature sig_pkcs1.bin umowa.txt.
5. Potwierdź obecność komunikatu 'Verified OK'.
6. Zmodyfikuj treść umowy: echo 'Sfałszowana tresc deklaracji' > umowa_mod.txt.
7. Spróbuj zweryfikować stary podpis dla zmodyfikowanego pliku: openssl dgst -sha256 -verify rsa_pub_2048.pem -signature sig_pkcs1.bin umowa_mod.txt.
8. Zarejestruj komunikat błędu 'Verification Failure'.
9. Wygeneruj drugi podpis PKCS#1 v1.5: openssl dgst -sha256 -sign rsa_priv_2048.pem -out sig_pkcs1_b.bin umowa.txt.
10. Porównaj oba podpisy: cmp sig_pkcs1.bin sig_pkcs1_b.bin (pliki są identyczne).
11. Wygeneruj podpis RSA-PSS: openssl dgst -sha256 -sign rsa_priv_2048.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:32 -sigopt rsa_mgf1_md:sha256 -out sig_pss1.bin umowa.txt.
12. Wygeneruj drugi podpis RSA-PSS dla tego samego pliku: openssl dgst -sha256 -sign rsa_priv_2048.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:32 -sigopt rsa_mgf1_md:sha256 -out sig_pss2.bin umowa.txt.
13. Porównaj oba podpisy PSS: cmp sig_pss1.bin sig_pss2.bin (pliki różnią się).
14. Zweryfikuj oba podpisy PSS: openssl dgst -sha256 -verify rsa_pub_2048.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:32 -sigopt rsa_mgf1_md:sha256 -signature sig_pss1.bin umowa.txt (jawny saltlen 32 i mgf1 SHA-256 zapobiegają rozjazdom między wersjami OpenSSL).
15. W CyberChef załaduj klucz publiczny i sprawdź weryfikację podpisu z operacją Verify RSA Signature.
16. Wykonaj zrzuty ekranu i opracuj zestawienie wniosków w sprawozdaniu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie paradygmatu Hash-then-Sign i roli funkcji skrótu w zapewnieniu efektywności i bezpieczeństwa podpisów.
• Wykazanie natychmiastowego wykrywania jakiejkolwiek modyfikacji treści podpisanego dokumentu.
• Rozróżnienie właściwości deterministycznego paddingu PKCS#1 v1.5 oraz probabilistycznego RSA-PSS.
• Praktyczna umiejętność podpisywania plików i weryfikacji podpisów narzędziami OpenSSL i CyberChef.

Cel

Celem zadania jest praktyczne zbadanie podpisów cyfrowych na krzywych eliptycznych przy użyciu algorytmów ECDSA (krzywa NIST P-256) oraz Ed25519 (EdDSA). Student analizuje strukturę formatu ASN.1 DER sygnatury ECDSA (para liczb r i s), porównuje ją ze stałą sygnaturą 64-bajtową w Ed25519 oraz bada szybkość i niezawodność obu rozwiązań w OpenSSL.

Scenariusz – opis

Podpisy oparte na krzywych eliptycznych stanowią współczesny standard zabezpieczeń w systemach operacyjnych, kryptowalutach i protokole SSH. Algorytm ECDSA stanowi adaptację klasycznego schematu DSA do grup punktów na krzywych eliptycznych Weierstrassa. Sygnatura ECDSA składa się z pary liczb całkowitych (r, s), które w formatach standardowych są serializowane w strukturze ASN.1 Sequence. Z powodu zmiennej długości liczb r i s oraz narzutu ASN.1 rozmiar wynikowego podpisu ECDSA P-256 waha się zazwyczaj w granicach 70-72 bajtów. Algorytm Ed25519 oparty na skręconej krzywej Edwardsa eliminuje wady ECDSA, oferując całkowicie deterministyczny podpis o stałej długości 64 bajtów. W Ed25519 podpis nie wymaga zewnętrznego generatora liczb losowych podczas podpisywania, co eliminuje katastrofalne błędy wycieku klucza.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. W konsoli JSLinux wygeneruj klucz P-256: openssl ecparam -name prime256v1 -genkey -noout -out p256_key.pem && openssl ec -in p256_key.pem -pubout -out p256_pub.pem.
2. Wygeneruj klucz Ed25519: openssl genpkey -algorithm ED25519 -out ed_key.pem && openssl pkey -in ed_key.pem -pubout -out ed_pub.pem.
3. Utwórz plik testowy: echo 'Dane autoryzacyjne transakcji elektronicznej' > doc.txt.
4. Podpisz plik za pomocą ECDSA: openssl dgst -sha256 -sign p256_key.pem -out sig_ecdsa.der doc.txt.
5. Zweryfikuj podpis ECDSA: openssl dgst -sha256 -verify p256_pub.pem -signature sig_ecdsa.der doc.txt.
6. Potwierdź komunikat 'Verified OK'.
7. Zbadaj strukturę ASN.1 podpisu ECDSA: openssl asn1parse -inform DER -in sig_ecdsa.der.
8. Odczytaj długości całkowite liczb r i s w wyjściu asn1parse.
9. Podpisz plik za pomocą Ed25519: openssl pkeyutl -sign -inkey ed_key.pem -in doc.txt -out sig_ed.raw.
10. Zweryfikuj podpis Ed25519: openssl pkeyutl -verify -pubin -inkey ed_pub.pem -sigfile sig_ed.raw -in doc.txt.
11. Sprawdź dokładny rozmiar pliku podpisu Ed25519: ls -l sig_ed.raw (dokładnie 64 bajty).
12. Podpisz ten sam plik ponownie: openssl pkeyutl -sign -inkey ed_key.pem -in doc.txt -out sig_ed_k2.raw.
13. Porównaj oba podpisy Ed25519: cmp sig_ed.raw sig_ed_k2.raw (pliki są identyczne).
14. Wykonaj test negatywny: podmień 1 B w sig_ed.raw (dd) i potwierdź odrzucenie weryfikacji pkeyutl -verify (Failure) - ramka: dgst robi hash+sign w jednym (ECDSA), pkeyutl robi surowy sign/verify (wymagany dla Ed25519).
15. Uruchom benchmark prędkości w OpenSSL: openssl speed ecdsap256.
16. Wykonaj zrzuty ekranu drzewa ASN.1 oraz wyników weryfikacji obu podpisów.
17. Opracuj podsumowanie porównujące bezpieczeństwo deterministycznego Ed25519 z losowym ECDSA.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie struktury podpisów ECDSA jako pary (r, s) kodowanej w sekwencji ASN.1 DER.
• Zrozumienie zalet architektury Ed25519: stały 64-bajtowy rozmiar podpisu, wysoka odporność na ataki czasowe i wbudowany determinizm.
• Praktyczna umiejętność podpisywania danych i weryfikacji podpisów ECDSA i EdDSA narzędziami OpenSSL.
• Świadomość przewagi wydajnościowej nowoczesnych krzywych Edwardsa nad tradycyjnymi podpisami RSA i ECDSA.

Cel

Celem zadania jest praktyczne zbadanie skutków złamania odporności na kolizje funkcji skrótu SHA-1 dla ważności podpisów cyfrowych. Student analizuje parę plików kolizyjnych SHAttered, weryfikuje ich sumy kontrolne SHA-1 oraz SHA-256, a następnie dowodzi, że podpis cyfrowy oparty na SHA-1 jest formalnie poprawny dla dwóch zupełnie różnych dokumentów.

Scenariusz – opis

Bezpieczeństwo schematu podpisu Hash-then-Sign opiera się bezpośrednio na odporności funkcji skrótu na kolizje. Odporność na kolizje oznacza, że znalezienie dwóch dowolnych różnych wiadomości m1 != m2 takich, że H(m1) = H(m2), musi być obliczeniowo niewykonalne. W lutym 2017 roku zespół badaczy z CWI Amsterdam i Google ogłosił atak SHAttered, generując pierwszą praktyczną kolizję SHA-1 dla dwóch plików PDF. Oba pliki PDF mają całkowicie różną zawartość wizualną (jeden ma niebieskie tło, a drugi czerwone), lecz posiadają dokładnie ten sam 160-bitowy skrót SHA-1. Jeśli użytkownik podpisze cyfrowo dokument m1 za pomocą algorytmu opartego na SHA-1, ten sam podpis będzie matematycznie poprawny dla dokumentu m2. Oznacza to całkowitą utratę niezaprzeczalności i możliwość bezkarnego podmienienia podpisanej umowy na fałszywy dokument.

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. Uruchom konsolę JSLinux Alpine.
2. Pobierz lub wygeneruj parę bloków kolizyjnych SHA-1 (samo jądro kolizji, kilka kB z oficjalnego repo SHAttered wraz z hashami SHA-256 do weryfikacji - nie pełne 422 kB PDF-y).
3. Sprawdź sumy SHA-1 obu plików: sha1sum shattered-1.pdf shattered-2.pdf.
4. Potwierdź, że oba hashe SHA-1 są całkowicie identyczne (38762cf7f55934b34d179ae6a4c80cadccbb7f0a).
5. Sprawdź sumy SHA-256 obu plików: sha256sum shattered-1.pdf shattered-2.pdf.
6. Potwierdź, że hashe SHA-256 są zupełnie różne.
7. Sprawdź różnice binarne w plikach poleceniem: cmp -l shattered-1.pdf shattered-2.pdf | wc -l.
8. Wygeneruj klucz testowy RSA: openssl genpkey -algorithm RSA -out rsa_shattered.pem && openssl pkey -in rsa_shattered.pem -pubout -out rsa_shat_pub.pem.
9. Podpisz plik shattered-1.pdf przy użyciu SHA-1: openssl dgst -sha1 -sign rsa_shattered.pem -out sig_shat.bin shattered-1.pdf.
10. Zweryfikuj podpis pod shattered-1.pdf: openssl dgst -sha1 -verify rsa_shat_pub.pem -signature sig_shat.bin shattered-1.pdf.
11. Zweryfikuj TEN SAM podpis pod shattered-2.pdf: openssl dgst -sha1 -verify rsa_shat_pub.pem -signature sig_shat.bin shattered-2.pdf.
12. Zarejestruj sukces weryfikacji 'Verified OK' dla drugiego, niepodpisanego dokumentu.
13. Podpisz plik shattered-1.pdf przy użyciu SHA-256: openssl dgst -sha256 -sign rsa_shattered.pem -out sig_sha256.bin shattered-1.pdf.
14. Spróbuj zweryfikować podpis SHA-256 pod shattered-2.pdf i zarejestruj błąd 'Verification Failure'.
15. W CyberChef porównaj działanie SHA-1 i SHA-256 na obu wektorach testowych.
16. Wykonaj zrzuty ekranu i opracuj analizę wpływu kolizji na certyfikaty X.509.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Praktyczny dowód na to, że kolizja funkcji skrótu pozwala na sfałszowanie podpisu cyfrowego pod zupełnie innym dokumentem.
• Zrozumienie fundamentalnego znaczenia odporności na kolizje (Collision Resistance) dla niezaprzeczalności podpisów.
• Wykazanie, że funkcja SHA-256 skutecznie chroni przed atakiem, generując całkowicie odmienne skróty dla pary SHAttered.
• Świadomość historycznych konsekwencji ataku SHAttered dla wycofania SHA-1 ze wszystkich gałęzi bezpieczeństwa IT.

Cel

Celem zadania jest praktyczna implementacja i analiza klasycznego modelu szyfrowania hybrydowego (KEM + DEM). Student łączy zalety szyfrowania asymetrycznego RSA (bezpieczna dystrybucja klucza bez wcześniejszego sekretu) z wydajnością i integralnością szyfrowania symetrycznego AES-256-GCM przy użyciu narzędzi konsolowych OpenSSL oraz serwisu CyberChef.

Scenariusz – opis

W praktyce kryptograficznej algorytmy asymetryczne (jak RSA) są zbyt wolne do bezpośredniego szyfrowania dużych plików i strumieni danych. Ponadto algorytmy asymetryczne posiadają sztywne limity rozmiaru danych wejściowych, ograniczone wielkością klucza. Z tego względu we współczesnych protokołach stosuje się model szyfrowania hybrydowego (ang. Hybrid Encryption). Model ten dzieli się na dwa komponenty: mechanizm kapsułkowania klucza KEM oraz mechanizm kapsułkowania danych DEM. W fazie KEM nadawca generuje losowy, jednorazowy klucz symetryczny i szyfruje go kluczem publicznym odbiorcy. W fazie DEM właściwe dane o dowolnym rozmiarze są szyfrowane wygenerowanym kluczem symetrycznym przy użyciu wydajnego algorytmu AEAD (np. AES-GCM).

Co ma wykonać student / grupa

Przykładowe kroki do wykonania jako sugestia

1. W konsoli JSLinux upewnij się, że posiadasz parę kluczy rsa_pub_2048.pem oraz rsa_priv_2048.pem.
2. Wygeneruj duży plik testowy o rozmiarze 5 MB: dd if=/dev/urandom of=plik_duzy.bin bs=1M count=5.
3. Sprawdź rozmiar pliku poleceniem ls -lh plik_duzy.bin.
4. Wygeneruj losowy 256-bitowy klucz sesyjny AES: openssl rand -out sesja.key 32.
5. Wygeneruj losowy 12-bajtowy wektor IV: openssl rand -out sesja.iv 12.
6. Przekonwertuj klucz i IV do formatu hex: xxd -p sesja.key | tr -d '\n' > k.hex && xxd -p sesja.iv | tr -d '\n' > iv.hex.
7. Zaszyfruj plik symetrycznie za pomocą AES-256-GCM: openssl enc -aes-256-gcm -in plik_duzy.bin -out plik_c.bin -K $(cat k.hex) -iv $(cat iv.hex) (AEAD z tagiem; nie CBC bez tagu).
8. Zakapsułkuj klucz sesyjny kluczem publicznym RSA w trybie OAEP: openssl pkeyutl -encrypt -pubin -inkey rsa_pub_2048.pem -in sesja.key -out kapsula.enc -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256.
9. Sprawdź rozmiary plików: ls -lh plik_c.bin kapsula.enc.
10. Odkapsułkuj klucz sesyjny kluczem prywatnym RSA: openssl pkeyutl -decrypt -inkey rsa_priv_2048.pem -in kapsula.enc -out klucz_odyskany.key -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256.
11. Zweryfikuj tożsamość klucza sesyjnego: cmp sesja.key klucz_odyskany.key.
12. Przygotuj hex odzyskanego klucza: xxd -p klucz_odyskany.key | tr -d '\n' > k_rec.hex.
13. Odszyfruj plik symetryczny: openssl enc -d -aes-256-gcm -in plik_c.bin -out plik_odyskany.bin -K $(cat k_rec.hex) -iv $(cat iv.hex).
14. Sprawdź integralność danych wyjściowych: cmp plik_duzy.bin plik_odyskany.bin.
15. Wykonaj test AEAD: podmień 1 B w plik_c.bin i potwierdź odrzucenie deszyfrowania (InvalidTag).
16. W CyberChef przetestuj procedurę odszyfrowania kapsuły klucza oraz właściwego szyfrogramu.
17. Wykonaj zrzuty ekranu poleceń i opracuj schemat przepływu danych KEM/DEM w sprawozdaniu.

Sugerowane wnioski i podsumowanie - co student ma osiągnąć

Sprawozdanie z realizacji zadania musi zawierać następujące kluczowe wnioski i osiągnięcia:

• Zrozumienie fundamentalnej architektury szyfrowania hybrydowego łączącej mechanizmy KEM i DEM.
• Praktyczna umiejętność bezpiecznego kapsułkowania klucza symetrycznego za pomocą asymetrycznego algorytmu RSA-OAEP.
• Wykazanie braku ograniczeń na rozmiar szyfrowanych danych dzięki wykorzystaniu szyfrów symetrycznych.
• Zrozumienie, w jaki sposób model hybrydowy stanowi podstawę protokołów PGP, S/MIME, TLS oraz nowoczesnych standardów PQC.