Laboratorium 6
Zadania laboratoryjne dla studentów 7 semestru IT - ocena 5.0

Poziom: ocena 5.0 - zaawansowana kryptoanaliza pamięci masowej, ataki sprzętowe i migracja postkwantowa

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ęść 6 (sieciowe systemy składowania danych: SAN, NAS i macierze RAID).

Wskazówki dla studenta i zasady realizacji:

  • Zadania na ocenę 5.0 wymagają głębokiej wiedzy kryptoanalitycznej, modelowania zaawansowanych wektorów ataków oraz inżynierii bezpieczeństwa systemów pamięci masowej: ataku bit-flipping na niespójny integralnościowo tryb szyfrowania dyskowego AES-XTS w sektorach metadanych ext4, kryptoanalizy bocznego kanału deduplikacji po stronie klienta i wdrożenia protokołu Proof of Ownership (PoW), kryptoanalitycznej ekstrakcji harmonogramu kluczy AES z pamięci RAM w ataku Cold Boot, oceny bezpieczeństwa architektury BitLocker z atakiem podsłuchu magistrali SPI modułu TPM 2.0, ślepej rekonstrukcji macierzy RAID 5 bez metadanych (Blind RAID Recovery) opartej na entropii Shannona i korelacji XOR, modelowania odporności na ataki ransomware za pomocą niezmiennych migawek WORM (Retention Lock) i podpisów RSA, progowego dzielenia klucza głównego macierzy KEK za pomocą schematu Shamira (k, n) nad ciałami skończonymi, procedury krypto-niszczenia danych (Crypto-Shredding) z matematycznym dowodem nieodwracalności, demonstracji ataków podsłuchu i wstrzykiwania komend SCSI w sieciach SAN oraz projektu postkwantowego hybrydowego magazynu archiwizacji długoterminowej opartego na algorytmie kratowym ML-KEM-768 (FIPS 203) i drzewach Merkle.
  • Wszystkie zadania są w pełni wykonalne bez praw administratora na systemie Windows - wykorzystują interpreter Python 3 z bibliotekami kryptograficznymi oraz nowoczesną konsolę narzędziową w środowisku JSLinux Fedora 33 (Linux) Console lub na lokalnej stacji roboczej. W tym laboratorium stosujemy wersję systemu „Fedora 33 (Linux) Console” ze strony https://bellard.org/jslinux/ (start: vm.html?cpu=riscv64&url=fedora33-riscv.cfg&mem=256, CPU riscv64, 256 MB RAM, Console). Dla spójności z częścią 3.0 nie stosujemy tu Alpine Linux. Uwaga: Fedora riscv64 bootuje dłużej — poczekaj na login i pracuj jako root.
  • Każde zadanie realizowane jest w czasie 90–100 minut w trakcie zajęć laboratoryjnych.
  • Wymagania formalne sprawozdania laboratoryjnego:
    • Strona tytułowa zawierająca: imię i nazwisko studenta, numer albumu, kierunek, semestr, grupę laboratoryjną, rok akademicki, numer i temat laboratorium, numer oraz nazwę realizowanego zadania, deklarowaną ocenę (5.0).
    • Opis konfiguracji środowiska badawczego, wersji bibliotek oraz wykorzystanych poleceń.
    • Szczegółowy opis wykonanych czynności, uzasadnienie wyboru narzędzi, kod źródłowy autorskich skryptów kryptoanalitycznych w Pythonie, zrzuty ekranu oraz wklejone fragmenty danych dokumentujące rzetelne wykonanie pracy.
    • Struktura raportu: spis treści, spis ilustracji (z numerami i podpisami), spis tabel (z numerami i podpisami) oraz wykaz źródeł literaturowych i internetowych.
Kryptologia
lab 6 - 5.0
Spis
Spis zadań laboratoryjnych na ocenę 5.0
01/10
Zadanie 1. Kryptoanalityczny atak bit-flipping na niespójny integralnościowo tryb szyfrowania dyskowego AES-XTS w sektorach metadanych ext4
🖥️ Wymagane środowisko:
System: Windows + JSLinux Fedora 33 (Linux) Console (Python 3)
Oprogramowanie: przeglądarka + Python 3
Podstawa wykładowa: Część 6 - slajdy 10, 11, 35, 36, 43: brak uwierzytelnienia w standardzie IEEE 1619 (AES-XTS), plastyczność szyfru, struktura superblocku i i-węzła ext4, ukierunkowane manipulacje bitami (bit-flipping) w szyfrogramie w celu eskalacji uprawnień (UID/GID = 0) bez naruszenia pozostałych metadanych.

Cel

Celem zadania jest przeprowadzenie zaawansowanego kryptoanalitycznego ataku manipulacji bitowej (bit-flipping attack) na wolumen blokowy zaszyfrowany w trybie AES-XTS. Student analizuje podatność wynikającą z braku kodu uwierzytelniającego wiadomość (MAC), lokalizuje przesunięcie binarne rekordu i-węzła (inode) w sektorze dyskowym i demonstruje, jak modyfikując szyfrogram w spoczynku zmienić identyfikator właściciela pliku (UID=1000 na UID=0 root) przy zachowaniu poprawności montowania systemu plików.

Scenariusz – opis

Standard IEEE 1619 definiujący tryb AES-XTS został powszechnie zaadaptowany w systemach dm-crypt, BitLocker oraz FileVault z uwagi na brak narzutu rozmiarowego na szyfrowanym nośniku. Projektanci standardu podjęli jednak świadomy kompromis inżynierski, rezygnując z kryptograficznej ochrony integralności danych (AEAD) na poziomie pojedynczych sektorów. Oznacza to, że tryb XTS chroni wyłącznie poufność informacji, pozostając podatnym na kryptoanalityczne ataki manipulacji szyfrogramem (malleability attacks).

W trybie XTS zmiana bitów w szyfrogramie 16-bajtowego bloku niszczy ten pojedynczy blok podczas deszyfrowania, przekształcając go w pseudolosowy szum. Kluczową właściwością jest jednak fakt, że pozostałe bloki wewnątrz tego samego sektora oraz sąsiednie sektory deszyfrują się w sposób całkowicie poprawny. Jeżeli atakujący z fizycznym dostępem do nośnika zna strukturę metadanych systemu plików (np. ext4), może wykorzystać tę cechę do przeprowadzenia celowanego ataku.

Tablica i-węzłów w systemie ext4 przechowuje informacje o prawach dostępu, w tym 16-bitowe pola UID oraz GID właściciela pliku. Atakujący może manipulować sektorami mapującymi pliki wykonywalne lub skrypty konfiguracyjne (np. /etc/shadow lub skrypt setuid). Odpowiednio spreparowana zmiana bitów w szyfrogramie może zmienić uprawnienia lub wymusić wykonanie kodu z uprawnieniami administratora po zamontowaniu wolumenu. Zrozumienie tej podatności uświadamia inżynierom, że samo szyfrowanie wolumenu bez mechanizmów Secure Boot i ochrony integralności dm-integrity nie gwarantuje bezpieczeństwa.

W tym zadaniu zmapujesz strukturę binarną i-węzła w zaszyfrowanym obrazie XTS i przeprowadzisz udany atak eskalacji uprawnień w środowisku laboratoryjnym.

Co ma wykonać student / grupa

Pracę rozpoczynasz od utworzenia skryptu w języku Python w dedykowanym katalogu xts_exploit_lab. Tworzysz wirtualny dysk o rozmiarze 10 megabajtów, formatujesz go w standardzie LUKS z szyfrem aes-xts-plain64 i zakładasz system plików ext4. Na zamontowanym wolumenie tworzysz plik binarny exploit.sh należący do zwykłego użytkownika o identyfikatorze UID = 1000. Zamykasz kontener kryptograficzny, uzyskując dostęp do surowego, zaszyfrowanego pliku obrazu dyskowego.

Piszesz skrypt analityczny w Pythonie, który lokalizuje sektor odpowiadający tablicy i-węzłów (inode table) badanej grupy bloków. Wyznaczasz dokładny offset binarny 16-bajtowego bloku przechowującego pola i_uid oraz i_mode dla twojego pliku. Modyfikujesz bity w szyfrogramie tego bloku, celowo wprowadzając pseudolosową permutację deszyfrowanego bloku i-węzła. Otwierasz wolumen LUKS poprawnym hasłem i montujesz system plików, obserwując zachowanie sterownika jądra.

Weryfikujesz, że sterownik ext4 odczytał zmanipulowany blok metadanych, interpretując zniekształcone bity jako UID = 0 (root) lub nadając uprawnienia setuid. Demonstrujesz, w jaki sposób brak uwierzytelnienia pozwolił na wykonanie pliku z uprawnieniami roota pomimo braku znajomości klucza Master Key. W sprawozdaniu przedstawiasz analizę wektora ataku oraz wskazujesz architekturę dm-integrity (SHA-256HMAC) jako jedyne skuteczne rozwiązanie ochronne.

Przykładowe kroki do wykonania jako sugestia

  1. W terminalu utwórz katalog roboczy: mkdir -p ~/xts_attack && cd ~/xts_attack.
  2. Utwórz wirtualny dysk: dd if=/dev/zero of=luks_target.img bs=1M count=10.
  3. Zainicjalizuj partycję LUKS2 w trybie XTS: cryptsetup luksFormat --type luks2 --cipher aes-xts-plain64 --batch-mode luks_target.img (hasło: HasloTestowe123).
  4. Otwórz kontener: cryptsetup luksOpen luks_target.img cel_xts.
  5. Utwórz system plików ext4: mkfs.ext4 -O ^has_journal /dev/mapper/cel_xts.
  6. Zamontuj system plików: mkdir -p /mnt/xts_target && mount /dev/mapper/cel_xts /mnt/xts_target.
  7. Utwórz plik testowy ze skryptem: echo '#!/bin/sh' > /mnt/xts_target/run.sh && echo 'whoami' >> /mnt/xts_target/run.sh.
  8. Ustaw właściciela na zwykłego użytkownika: chown 1000:1000 /mnt/xts_target/run.sh && chmod 755 /mnt/xts_target/run.sh.
  9. Sprawdź numer i-węzła pliku: ls -i /mnt/xts_target/run.sh (np. i-węzeł 12).
  10. Odmontuj wolumen i zamknij kontener: umount /mnt/xts_target && cryptsetup luksClose cel_xts.
  11. Utwórz skrypt w Pythonie: nano exploit_xts.py.
  12. W skrypcie załaduj surowy obraz luks_target.img w trybie r+b.
  13. Oblicz offset tablicy i-węzłów w grupie bloków 0 (sektor danych z przesunięciem payload_offset z nagłówka LUKS).
  14. Zmodyfikuj 16 bajtów szyfrogramu odpowiadających początkowi struktury i-węzła 12 (odwróć bity w szyfrogramie bloku).
  15. Zapisz zmiany w surowym pliku obrazu bez otwierania kontenera.
  16. Otwórz kontener ponownie: cryptsetup luksOpen luks_target.img cel_xts (kontener otwiera się bez żadnego błędu).
  17. Zamontuj wolumen i wyświetl uprawnienia pliku: mount /dev/mapper/cel_xts /mnt/xts_target && ls -l /mnt/xts_target/run.sh.
  18. Zanotuj, że prawa i właściciel pliku uległy zmianie na skutek deszyfrowania zniekształconego bloku XTS bez wykrycia naruszenia integralności.
  19. Wykonaj zrzuty ekranu poleceń, kodu w Pythonie oraz zmodyfikowanych atrybutów i-węzła w systemie operacyjnym.

Kontrola zaliczenia (checklist):

  1. Przeprowadzono bit-flipping na XTS na wektorze ze startera: bez klucza zmieniono UID 1000→0 w inode ext4 (superblock spójny, mount OK).
  2. Wykazano różnicę: XTS sam (manipulacja niewidoczna) vs XTS+dm-integrity/HMAC (odrzut); dołączono oba logi i offsety.
  3. Dołączono log ataku (sektor, offset inode, delta) + kod łatki (dm-integrity, montowanie z weryfikacją).
  4. Opisano w 3–5 zdaniach kompromis: IEEE 1619 bez MAC, eskalacja z fizycznym dostępem, koszt integrity.

Wariant offline (fallback): Praca w pełni offline na wektorach ze startera w lokalnym Pythonie 3 bez sieci; dołącz kod ataku, log rekonstrukcji oraz opis kompromisu bezpieczeństwo–wydajność i wytyczne hardeningu.

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 fundamentalnego braku ochrony integralności (plastyczności) w standardzie szyfrowania dyskowego IEEE 1619 (AES-XTS).
  • Praktyczne wykazanie możliwości manipulacji metadanymi systemu plików bez znajomości klucza głównego wolumenu.
  • Identyfikacja wektora ataku eskalacji uprawnień w systemach z fizycznym dostępem do nośników w spoczynku.
  • Uzasadnienie konieczności stosowania warstwy dm-integrity z kryptograficznymi sumami HMAC w środowiskach wysokiego bezpieczeństwa.
Zadanie 1 - ilustracja
02/10
Zadanie 2. Kryptoanaliza deduplikacji po stronie klienta (Client-Side Deduplication) i atak bocznego kanału ujawniający pliki użytkowników
🖥️ Wymagane środowisko:
System: Windows + JSLinux Fedora 33 (Linux) Console (Python 3)
Oprogramowanie: przeglądarka + Python 3
Podstawa wykładowa: Część 6 - slajdy 41, 42, 43: deduplikacja po stronie klienta w usługach chmurowych (Dropbox, Google Drive), boczny kanał czasowy i transferowy (Side-Channel Attack), atak słownikowy na istnienie pliku (Confirmation Attack), protokół dowodu posiadania Proof of Ownership (PoW) oparty na drzewach Merkle.

Cel

Celem laboratorium jest kryptoanaliza podatności bocznego kanału w chmurowych systemach składowania implementujących naiwną deduplikację po stronie klienta (Client-Side Deduplication). Student modeluje atak polegający na sprawdzaniu obecności plików innych użytkowników w chmurze bez prawa dostępu do nich (poprzez analizę odpowiedzi serwera na wysłany skrót SHA-256), a następnie implementuje kryptograficzny protokół Proof of Ownership (PoW) oparty na drzewie Merkle, wymuszający udowodnienie fizycznego posiadania całego pliku.

Scenariusz – opis

Dostawcy usług chmurowych magazynowania danych (np. Dropbox czy usługi archiwizacji) masowo wdrażają deduplikację po stronie klienta. W modelu tym klient przed wysłaniem pliku oblicza jego skrót kryptograficzny SHA-256 i przesyła go do serwera chmurowego jako zapytanie wstępne.

Jeżeli serwer posiada już w swojej bazie blok o identycznym skrócie, natychmiast anuluje transfer sieciowy i przypisuje plik do konta użytkownika. Z punktu widzenia optymalizacji sieciowej rozwiązanie to oszczędza gigabajty przepustowości, lecz z perspektywy bezpieczeństwa tworzy krytyczny boczny kanał. Atakujący nieposiadający dostępu do poufnego pliku ofiary może wygenerować kandydata tekstu (np. standardowy szablon umowy z podstawionym nazwiskiem) i obliczyć jego skrót.

Wysyłając zapytanie o ten skrót, atakujący otrzymuje natychmiastową informację zwrotną: czy plik istnieje w chmurze, a w skrajnym przypadku natychmiast uzyskuje do niego dostęp. Atak ten przekształca usługę składowania w wyrocznię ujawniającą obecność wrażliwych dokumentów, list płac lub poufnych baz danych. Standardowym rozwiązaniem kryptograficznym eliminującym tę podatność jest protokół dowodu posiadania Proof of Ownership (PoW) zdefiniowany przez Haleviego.

W protokole PoW serwer rzuca wyzwanie pseudolosowe (pseudorandom challenge), wymagając od klienta ujawnienia fragmentów liści drzewa Merkle wyliczonego z całego pliku. Posiadanie samego skrótu SHA-256 nie pozwala na skonstruowanie poprawnej odpowiedzi, co uniemożliwia przeprowadzenie ataku słownikowego.

W tym zadaniu zaimplementujesz wektor ataku bocznego kanału na naiwną deduplikację oraz zbudujesz odporny protokół PoW w języku Python.

Co ma wykonać student / grupa

Pracę rozpoczynasz od utworzenia skryptu pow_dedup_lab.py w środowisku roboczym emulatora lub stacji roboczej. Definiujesz klasę VulnerableCloudService implementującą naiwną deduplikację po stronie klienta z indeksem skrótów SHA-256. Zasymulujesz sytuację, w której ofiara wysyła do chmury poufny dokument medyczny o znanej strukturze z unikalnym numerem PESEL. Tworzysz klasę Attacker, która przeprowadza atak słownikowy (Confirmation Attack): iteruje po wąskiej przestrzeni parametrów i wysyła skróty do serwera.

Mierzysz czas odpowiedzi oraz status serwera (Transfer Skipped vs Upload Required), bezbłędnie identyfikując obecność pliku ofiary. W drugim etapie projektujesz bezpieczną architekturę SecureCloudService implementującą interaktywny protokół Proof of Ownership. W nowym protokole klient zgłaszający chęć deduplikacji musi najpierw przedstawić korzeń drzewa Merkle Root wyliczonego z bloków badanego pliku. Serwer generuje losowe wyzwanie złożone z indeksów k bloków i żąda od klienta przesłania zawartości tych bloków wraz ze ścieżkami Merkle Proof.

Weryfikujesz, że atakujący dysponujący jedynie 32-bajtowym skrótem pliku ponosi porażkę w teście wyzwania i zostaje zablokowany. Testujesz pomyślne uwierzytelnienie uczciwego klienta, który posiada pełny plik na dysku i generuje poprawne dowody kryptograficzne. Dokumentujesz zrzuty ekranu z przebiegu ataku na podatną chmurę oraz raport bezpieczeństwa protokołu PoW w sprawozdaniu.

Przykładowe kroki do wykonania jako sugestia

  1. W terminalu utwórz katalog roboczy: mkdir -p ~/pow_lab && cd ~/pow_lab.
  2. Utwórz plik skryptu w języku Python: nano pow_attack.py.
  3. Zaimportuj moduły standardowe: hashlib, os, random, time.
  4. Zaimplementuj klasę VulnerableStorage z metodą query_hash(sha256_sum) zwracającą True jeśli blok istnieje w bazie.
  5. Zasymuluj upload dokumentu ofiary: doc = b'POUFNA DIAGNOZA MEDYCZNA: PACJENT ID 98234 NOWOTWOR NEGATYWNY'.
  6. Zarejestruj skrót SHA-256 dokumentu ofiary w usłudze VulnerableStorage.
  7. Zaimplementuj atakującego AttackerConfirmation: generuj w pętli warianty dokumentu dla ID od 98230 do 98240.
  8. Dla każdego kandydata oblicz skrót i wyślij zapytanie do serwera: czy_istnieje = server.query_hash(h).
  9. Zanotuj sukces ataku: atakujący wykrył, że dokument dla ID 98234 istnieje w chmurze bez pobierania pliku.
  10. Zaimplementuj bezpieczną klasę PoWStorage: serwer dzieli plik logicznie na 64 bloki i pamięta Merkle Root.
  11. Gdy klient twierdzi, że posiada plik o danym Merkle Root, serwer losuje 4 indeksy bloków: indices = random.sample(range(64), 4).
  12. Klient musi odesłać zawartość wskazanych 4 bloków oraz dowody Merkle Proof (hasze sąsiadów do korzenia).
  13. Zaimplementuj metodę weryfikacji serwera: sprawdź spójność dowodów ze znanym Merkle Root.
  14. Wykaż, że atakujący znający jedynie Merkle Root lub skrót SHA-256 nie jest w stanie wygenerować brakujących bloków (prawdopodobieństwo oszustwa rzędu 2^-128).
  15. Zweryfikuj działanie protokołu dla uczciwego klienta posiadającego plik źródłowy: poprawna deduplikacja i autoryzacja.
  16. Porównaj narzut komunikacyjny protokołu PoW z przesyłaniem pełnego pliku przez sieć WAN.
  17. Wykonaj zrzuty ekranu kodu, symulacji ataku słownikowego oraz weryfikacji odporności schematu PoW.
  18. Sformułuj wnioski dla architektury systemów chmurowych dotyczące konieczności wdrożenia PoW (RFC 7343 / Halevi et al.).

Kontrola zaliczenia (checklist):

  1. Wykazano boczny kanał dedup na wektorze ze startera: probingiem ujawniono obecność cudzego pliku (oszczędność = sygnał) bez odczytu treści.
  2. Wykazano różnicę: naiwny client-side (wyciek) vs proof-of-ownership Merkle (odrzut bez dowodu); dołączono logi czasów/rozmiarów.
  3. Dołączono log ataku (confirmation oracle) + kod łatki (PoW, losowe progi, szyfrowanie przed dedup).
  4. Opisano w 3–5 zdaniach kompromis: pasmo vs prywatność, Merkle-PoW jako bramka, koszt protokołu.

Wariant offline (fallback): Praca w pełni offline na wektorach ze startera w lokalnym Pythonie 3 bez sieci; dołącz kod ataku, log rekonstrukcji oraz opis kompromisu bezpieczeństwo–wydajność i wytyczne hardeningu.

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 natury bocznego kanału informacyjnego w naiwnej deduplikacji po stronie klienta (Client-Side Deduplication).
  • Praktyczna umiejętność przeprowadzenia ataku potwierdzenia pliku (Confirmation Attack) ujawniającego dane wrażliwe.
  • Opanowanie implementacji kryptograficznego protokołu dowodu posiadania (Proof of Ownership) opartego na drzewach Merkle.
  • Świadomość konieczności łączenia optymalizacji wydajnościowej z rygorami dowodowymi w architekturach chmurowych.
Zadanie 2 - ilustracja
03/10
Zadanie 3. Analiza podatności ataku Cold Boot na klucze deszyfrujące w pamięci RAM i ekstrakcja rozszerzonych kluczy AES z zrzutu pamięci masowej
🖥️ Wymagane środowisko:
System: Windows + JSLinux Fedora 33 (Linux) Console (Python 3)
Oprogramowanie: przeglądarka + Python 3
Podstawa wykładowa: Część 6 - slajdy 11, 35, 36: remanencja pamięci DRAM (Cold Boot Attack), przechowywanie kluczy Master Key dm-crypt / BitLocker w pamięci operacyjnej jądra, struktura harmonogramu kluczy AES (AES Key Schedule), odzyskiwanie klucza głównego ze szczątkowych rund klucza w Pythonie.

Cel

Celem ćwiczenia jest kryptoanalityczna rekonstrukcja klucza szyfrowania dyskowego AES ze zrzutu pamięci operacyjnej RAM pobranego w symulowanym ataku Cold Boot. Student analizuje strukturę harmonogramu kluczy AES-128/256 (Key Schedule), implementuje algorytm przeszukiwania obrazu pamięci pod kątem relacji algebraicznych pomiędzy kolejnymi rundami klucza (Round Keys) oraz odzyskuje 256-bitowy klucz główny wolumenu pomimo częściowej degradacji bitów w pamięci RAM.

Scenariusz – opis

Szyfrowanie wolumenów blokowych dm-crypt / LUKS oraz BitLocker chroni dane w spoczynku, gdy komputer jest całkowicie wyłączony. W momencie zamontowania partycji klucz deszyfrujący Master Key musi jednak zostać załadowany do pamięci operacyjnej RAM procesora w celu wykonywania operacji w locie. Powszechne przekonanie, że pamięć DRAM natychmiast traci zawartość po odcięciu zasilania, zostało obalone słynnym atakiem Cold Boot autorstwa Haldermana i współpracowników.

Kondensatory komórek pamięci RAM zachowują ładunek przez kilkadziesiąt sekund w temperaturze pokojowej, a po schłodzeniu ciekłym azotem lub sprężonym gazem nawet przez wiele minut. Atakujący może fizycznie zresetować maszynę, uruchomić lekki system ratunkowy z pamięci USB i zrzucić pełną zawartość pamięci RAM do pliku binarnego. W surowym zrzucie pamięci gigabajtowej odnalezienie losowego 256-bitowego klucza AES wydaje się zadaniem niemożliwym bez znajomości sygnatury.

Jednak biblioteki kryptograficzne i sterowniki jądra nie przechowują wyłącznie 32 bajtów klucza głównego, lecz pełny harmonogram kluczy rozszerzonych (Key Schedule). Dla algorytmu AES-256 harmonogram składa się z 15 podkluczy rundowych o łącznej długości 240 bajtów połączonych ścisłymi zależnościami matematycznymi (funkcje SubBytes, RotWord, Rcon). Ta redundantna struktura algebraiczna tworzy charakterystyczny wzorzec, który pozwala algorytmom kryptoanalitycznym odnaleźć klucz w megabajtach szumu pamięci.

W tym zadaniu zaimplementujesz weryfikator harmonogramu kluczy AES w Pythonie, przeszukasz zrzut pamięci i zrekonstruujesz klucz wolumenu dyskowego.

Co ma wykonać student / grupa

Pracę rozpoczynasz od utworzenia skryptu cold_boot_hunter.py w katalogu roboczym środowiska Python. Analizujesz specyfikację algorytmu rozszerzania klucza AES-256 zdefiniowaną w standardzie FIPS 197. Implementujesz funkcję rozwijania klucza aes256_key_schedule(key), która z 32-bajtowego klucza generuje 60 słów 32-bitowych (15 podkluczy rundowych). Implementujesz funkcję weryfikacji algebraic_check(candidate_bytes), która sprawdza, czy badany fragment 240 bajtów spełnia równania rotacji i nieliniowych podstawień S-Box AES.

Tworzysz realistyczny model pamięci RAM: generujesz plik obrazu o rozmiarze 10 megabajtów wypełniony losowym szumem i fragmentami struktur systemowych. W losowym miejscu obrazu pamięci wstrzykujesz poprawnie wygenerowany harmonogram kluczy AES-256 aktywnego wolumenu LUKS. Symulujesz degradację termiczną pamięci DRAM po odcięciu zasilania: w rozszerzonym kluczu losowo odwracasz 2% bitów (zjawisko decay w Cold Boot). Uruchamiasz napisanego łowcę kluczy w Pythonie, który skanuje pamięć RAM w oknie przesuwnym, obliczając metrykę błędu dopasowania do relacji FIPS 197.

Algorytm bezbłędnie lokalizuje offset uszkodzonego harmonogramu i wykorzystuje redundancję 15 rund do korekcji błędnych bitów i odzyskania oryginalnego 256-bitowego klucza. Weryfikujesz odzyskany klucz, otwierając zaszyfrowany wolumen laboratoryjny za pomocą opcji cryptsetup luksOpen --master-key-file. Sporządzasz pełną dokumentację kryptoanalityczną, dołączając kod źródłowy i analizę mechanizmów obronnych (np. TRESOR, eliminacja kluczy z DRAM do rejestrów CPU).

Przykładowe kroki do wykonania jako sugestia

  1. W terminalu utwórz katalog roboczy: mkdir -p ~/coldboot_lab && cd ~/coldboot_lab.
  2. Utwórz plik skryptu: nano coldboot_analyzer.py.
  3. Zaimportuj moduły: os, sys, struct, random.
  4. Zdefiniuj tablicę podstawień S-BOX oraz stałe rund RCON dla algorytmu AES zgodnie ze standardem FIPS 197.
  5. Zaimplementuj funkcję sub_word(w) oraz rot_word(w) operujące na 32-bitowych słowach.
  6. Zaimplementuj pełny harmonogram rozszerzania klucza: expand_key_256(key_32bytes) generujący 240 bajtów podkluczy.
  7. Wygeneruj prawdziwy 256-bitowy klucz główny: master_key = os.urandom(32).
  8. Rozwiń klucz do 240-bajtowego harmonogramu rund: expanded_schedule = expand_key_256(master_key).
  9. Utwórz 10-megabajtowy plik symulujący zrzut pamięci RAM: ram_dump = bytearray(os.urandom(10 * 1024 * 1024)).
  10. Wstrzyknij harmonogram w losowym miejscu zrzutu: offset = random.randint(1000000, 8000000); ram_dump[offset:offset+240] = expanded_schedule.
  11. Zasymuluj degradację bitów pamięci DRAM (bit decay 1.5%): przekłam losowe bity w harmonogramie.
  12. Zaimplementuj funkcję scoringową score_schedule(candidate_240b) zliczającą naruszenia równań AES Key Schedule.
  13. Zaimplementuj skaner przeszukujący ram_dump z krokiem 4 bajtów (wyrównanie słowa w pamięci).
  14. Wyświetl raport skanera: wykryto kandydata klucza na zidentyfikowanym offsecie z minimalną liczbą błędów.
  15. Zaimplementuj procedurę korekcji błędów rekonstruującą początkowe 32 bajty (Round Key 0 i Round Key 1) z nieuszkodzonych rund późniejszych.
  16. Potwierdź pełną zgodność odzyskanego klucza z oryginałem: assert recovered_key == master_key.
  17. Wykonaj zrzuty ekranu kodu, logów wykrycia harmonogramu w zrzucie RAM oraz pomyślnej rekonstrukcji klucza.
  18. Sformułuj wnioski opisujące technologie mitygacji ataku Cold Boot (szyfrowanie pamięci RAM AMD SME/Intel TME oraz rejestry TRESOR).

Kontrola zaliczenia (checklist):

  1. Odzyskano klucz AES z RAM na wektorze ze startera: ze zdegenerowanego dumpu (błędy bitowe) zrekonstruowano key schedule i Master Key.
  2. Wykazano różnicę: RAM bez ochrony (klucz odzyskiwany) vs TME/TRESOR (brak klucza w RAM); dołączono log rekonstrukcji.
  3. Dołączono log skanowania (redundancja schedule) + kod łatki (memory encryption, scrub, wyłączanie hibernacji).
  4. Opisano w 3–5 zdaniach kompromis: remanencja DRAM, algebra schedule jako latarnia, koszt TME.

Wariant offline (fallback): Praca w pełni offline na wektorach ze startera w lokalnym Pythonie 3 bez sieci; dołącz kod ataku, log rekonstrukcji oraz opis kompromisu bezpieczeństwo–wydajność i wytyczne hardeningu.

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 fizycznych i kryptograficznych mechanizmów ataku Cold Boot na pamięć operacyjną serwera.
  • Świadomość redundancji algebraicznej w harmonogramie kluczy AES (Key Schedule) ułatwiającej detekcję klucza w RAM.
  • Praktyczna umiejętność rekonstrukcji klucza głównego ze zdegenerowanego zrzutu pamięci w języku Python.
  • Znajomość nowoczesnych sprzętowych mechanizmów obronnych: Total Memory Encryption (TME) oraz TRESOR.
Zadanie 3 - ilustracja
04/10
Zadanie 4. Kryptoanalityczna ocena architektury BitLocker: analiza interakcji z układem TPM, rejestrów PCR i atak podsłuchu magistrali TPM
🖥️ Wymagane środowisko:
System: Windows + JSLinux Fedora 33 (Linux) Console (Python 3)
Oprogramowanie: przeglądarka + Python 3
Podstawa wykładowa: Część 6 - slajdy 11, 35, 36: architektura BitLocker, układ TPM 2.0, rejestry konfiguracji platformy PCR, zapieczętowanie klucza (Sealing / Unsealing), klucz VMK (Volume Master Key) i FVEK (Full Volume Encryption Key), wektor ataku podsłuchu magistrali SPI/LPC podczas rozruchu platformy.

Cel

Celem zadania jest przeprowadzenie audytu kryptograficznego i modelowania wektora ataku podsłuchu magistrali sprzętowej na mechanizm BitLocker z układem TPM. Student analizuje łańcuch zaufania mierzony w rejestrach PCR (PCR 0-7), dekonstruuje strukturę kluczy VMK oraz FVEK, modeluje atak przechwycenia klucza deszyfrującego przesyłanego otwartym tekstem po magistrali SPI/LPC między procesorem a TPM podczas startu systemu oraz projektuje skuteczne środki zaradcze (TPM + PIN / Enhanced BitLocker).

Scenariusz – opis

Architektura Microsoft BitLocker stanowi dominujący standard ochrony danych w spoczynku w korporacyjnych środowiskach Windows. Domyślna konfiguracja BitLocker opiera się na module bezpiecznej platformy TPM (Trusted Platform Module) w trybie TPM-only bez konieczności wpisywania hasła rozruchowego. W trybie tym układ TPM mierzy integralność kolejnych faz startowych platformy (firmware UEFI, tablica partycji, bootloader) i zapisuje skróty w rejestrach PCR.

Główny klucz wolumenu VMK (Volume Master Key) jest zaszyfrowany i zapieczętowany w pamięci TPM (TPM Sealing) z polityką dopuszczającą odszyfrowanie tylko przy poprawnych wartościach PCR. Jeżeli wartości rejestrów PCR są zgodne ze stanem referencyjnym, moduł TPM automatycznie odpieczętowuje klucz VMK i przesyła go do procesora głównego. Kluczowym punktem krytycznym tej architektury jest fizyczna magistrala łącząca dedykowany układ TPM z chipsetem płyty głównej (magistrala SPI lub LPC).

Większość tradycyjnych wdrożeń TPM nie szyfruje transmisji na magistrali, przesyłając odszyfrowany klucz VMK w postaci jawnego tekstu. Atakujący dysponujący fizycznym dostępem do płyty głównej może podłączyć niedrogie urządzenie analizatora stanów logicznych (np. Raspberry Pi Pico lub Saleae Logic) do linii danych SPI.

Podczas startu systemu rejestruje się przebiegi magistrali i bez trudu ekstrahuje jawny klucz VMK, co pozwala na natychmiastowe odszyfrowanie dysku bez łamania TPM. Zrozumienie tego wektora ataku uświadamia konieczność wdrożenia uwierzytelniania dwuskładnikowego (TPM + PIN) lub mechanizmu TPM Parameter Encryption.

W tym zadaniu dokonasz dekonstrukcji ramek transmisyjnych TPM SPI, przeanalizujesz hierarchię kluczy VMK/FVEK i zamodelujesz atak podsłuchu magistrali w Pythonie.

Co ma wykonać student / grupa

Pracę rozpoczynasz od utworzenia pliku tpm_bus_sniff.py w środowisku roboczym. Analizujesz specyfikację protokołu komunikacyjnego TCG PC Client Platform TPM Profile dla magistrali SPI. Definiujesz ramki transakcji SPI: bajt komendy (odczyt/zapis), 24-bitowy adres rejestru oraz strumień danych odpowiedzi. W pliku skryptu modelujesz strukturę danych BitLocker: sektor metadanych zawierający nagłówek FVE (Full Volume Encryption), strukturę klucza FVEK zaszyfrowaną kluczem VMK.

Symulujesz procedurę rozruchu: procesor wysyła do TPM komendę TPM2_CC_Unseal z uchwytem obiektu klucza i parametrami sesji. Generujesz realistyczny zrzut cyfrowy rejestracji linii zegara SCK, wyboru układu CS oraz linii danych MOSI/MISO magistrali SPI. Piszesz parser w Pythonie, który dekoduje zarejestrowane stany logiczne, rekonstruuje bajty transakcji i filtruje pakiety komendy TPM2_Unseal. Zdekodowujesz strukturę odpowiedzi TPM2B_SENSITIVE_DATA, ekstrahując surowy 256-bitowy klucz VMK przesyłany w jawnym strumieniu bajtów.

Używasz wyodrębnionego klucza VMK do odszyfrowania właściwego klucza dyskowego FVEK za pomocą algorytmu AES Key Unwrap (RFC 3394). Wykazujesz, że wdrożenie kodu PIN (tryb TPM+PIN) blokuje komendę Unseal przed wprowadzeniem poświadczenia przez użytkownika, neutralizując podsłuch. Sporządzasz pełny raport z audytu podatności z diagramami magistrali i zaleceniami konfiguracyjnymi zasad grupy GPO w sprawozdaniu.

Przykładowe kroki do wykonania jako sugestia

  1. W terminalu utwórz katalog roboczy: mkdir -p ~/bitlocker_lab && cd ~/bitlocker_lab.
  2. Utwórz plik skryptu analizatora: nano tpm_sniffer.py.
  3. Zaimportuj moduły standardowe: struct, hashlib, os z biblioteki cryptography.hazmat.primitives.keywrap.
  4. Zdefiniuj hierarchię kluczy BitLocker: FVEK (Full Volume Encryption Key, 256-bit) oraz VMK (Volume Master Key, 256-bit).
  5. Zaszyfruj FVEK kluczem VMK za pomocą algorytmu AES Key Wrap (RFC 3394) i zapisz strukturę metadanych.
  6. Zasymuluj rejestrację magistrali SPI podczas rozruchu: utwórz strumień bajtów zawierający komendy odczytu rejestru TPM_DATA_FIFO_0 (adres 0xD40024).
  7. W strumieniu bajtów umieść nagłówek odpowiedzi TPM 2.0: tag TPM_ST_SESSIONS, parametr rozmiaru, kod sukcesu TPM_RC_SUCCESS.
  8. W ciele odpowiedzi umieść strukturę TPM2B_SENSITIVE_DATA zawierającą jawny 32-bajtowy klucz VMK.
  9. Napisz funkcję parse_spi_stream( stream) wyszukującą sekwencje komendy TPM2_CC_Unseal (kod 0x0000015E).
  10. Uruchom parser na zarejestrowanym zrzucie magistrali i wyodrębnij przechwycony klucz VMK.
  11. Wyświetl wyodrębniony klucz VMK w formacie heksadecymalnym: print('Przejęty klucz VMK:', vmk_recovered.hex()).
  12. Użyj przejętego VMK do odpakowania klucza dyskowego: fvek_unwrapped = aes_key_unwrap(vmk_recovered, encrypted_fvek).
  13. Zweryfikuj zgodność odzyskanego FVEK z oryginalnym kluczem użytym do szyfrowania partycji.
  14. Zaimplementuj symulację trybu TPM + PIN: wykaż, że bez podania autoryzacji sesji komenda Unseal zwraca błąd TPM_RC_AUTH_FAIL.
  15. Zaimplementuj symulację ochrony TPM Parameter Encryption: zaszyfruj odpowiedź Unseal kluczem sesji bazującym na Endorsement Key (EK).
  16. Wykonaj zrzuty ekranu kodu, zdekodowanych ramek SPI oraz procesu odzyskania klucza FVEK.
  17. Sformułuj techniczne zalecenia wzmocnienia konfiguracji BitLocker dla stacji roboczych w organizacji.

Kontrola zaliczenia (checklist):

  1. Zauditowano BitLocker+TPM na modelu ze startera: łańcuch PCR 0–7, FVEK owinięty VMK (seal), podsłuch SPI/LPC wyciąga VMK w trybie TPM-only.
  2. Wykazano różnicę: TPM-only (podsłuch działa) vs TPM+PIN (bez PIN bezużyteczne); dołączono ramki TPM 2.0 i logi.
  3. Dołączono log dekonstrukcji + kod łatki (TPM+PIN, PCR pinning, anti-tamper).
  4. Opisano w 3–5 zdaniach kompromis: wygoda bez PIN vs sprzętowy podsłuch, sealing do PCR.

Wariant offline (fallback): Praca w pełni offline na wektorach ze startera w lokalnym Pythonie 3 bez sieci; dołącz kod ataku, log rekonstrukcji oraz opis kompromisu bezpieczeństwo–wydajność i wytyczne hardeningu.

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 architektury kryptograficznej BitLocker: rozróżnienie pomiędzy kluczami FVEK i VMK oraz rola TPM Sealing.
  • Identyfikacja fizycznego wektora ataku podsłuchu magistrali SPI/LPC w domyślnej konfiguracji TPM-only.
  • Praktyczna umiejętność dekonstrukcji ramek protokołu TPM 2.0 i ekstrakcji kluczy deszyfrujących w Pythonie.
  • Świadomość konieczności stosowania uwierzytelniania wieloskładnikowego (TPM + PIN) w celu ochrony przed atakami sprzętowymi.
Zadanie 4 - ilustracja
05/10
Zadanie 5. Rekonstrukcja danych z uszkodzonej macierzy RAID 5 bez metadanych (Blind RAID Reconstruction) z wykorzystaniem analizy entropii i parzystości XOR
🖥️ Wymagane środowisko:
System: Windows + JSLinux Fedora 33 (Linux) Console (Python 3)
Oprogramowanie: przeglądarka + Python 3
Podstawa wykładowa: Część 6 - slajdy 13, 16, 20, 22, 23: przypadek utraty kontrolera sprzętowego i metadanych macierzy RAID 5, nieznany rozmiar paska (stripe size), nieznana kolejność dysków i typ rotacji parzystości (left/right symmetric/asymmetric), kryptoanalityczny algorytm rekonstrukcji w Pythonie oparty na analizie entropii Shannona i korelacji parzystości XOR.

Cel

Celem laboratorium jest opracowanie i wdrożenie w języku Python zaawansowanego algorytmu rekonstrukcji macierzy RAID 5 bez znajomości metadanych (tzw. Blind RAID Recovery). Student analizuje zbiór surowych obrazów dyskowych pochodzących z uszkodzonej macierzy, wykorzystuje testy korelacji parzystości XOR oraz analizę entropii Shannona do automatycznego wykrycia wielkości paska, kolejności dysków w macierzy oraz typu rotacji parzystości, a następnie scala spójny logiczny obraz systemu plików.

Scenariusz – opis

Awaria sprzętowego kontrolera macierzy w serwerze często uniemożliwia odzyskanie konfiguracji, gdy nowy kontroler nie rozpoznaje metadanych poprzednika. W informatyce śledczej i procedurach odzyskiwania po katastrofie analityk dysponuje jedynie surowymi zrzutami binarnymi poszczególnych dysków. Brak wiedzy o kolejności nośników w obudowie, wielkości jednostki paska (stripe unit size) oraz typie rotacji parzystości paraliżuje proces montowania.

W macierzach RAID 5 stosuje się cztery główne schematy dystrybucji parzystości: left-symmetric, left-asymmetric, right-symmetric oraz right-asymmetric. Ręczne testowanie wszystkich permutacji jest niemożliwe przy dużych wolumenach, dlatego konieczne jest zastosowanie metod kryptoanalitycznych. Podstawowym narzędziem detekcji bloków parzystości jest analiza zależności XOR - w każdym poprawnie zestawionym pasku suma bitowa wszystkich bloków wynosi zero.

Dodatkowo analiza entropii Shannona pozwala odróżnić bloki parzystości od bloków danych: bloki parzystości łączące różne pliki wykazują niemal maksymalną entropię. Z kolei bloki danych zawierające metadane systemu plików lub wypełnienia zerowe charakteryzują się specyficznymi spadkami entropii i powtarzalnymi strukturami. Połączenie testów korelacji XOR ze statystyczną analizą entropii umożliwia w pełni automatyczne zrekonstruowanie geometrii macierzy RAID 5.

W tym zadaniu zbudujesz algorytm śledczy w Pythonie, który na podstawie 'ślepych' obrazów dysków bezbłędnie zidentyfikuje geometrię macierzy i odtworzy dane.

Co ma wykonać student / grupa

Pracę rozpoczynasz od utworzenia środowiska testowego blind_raid_lab w systemie Linux. Przygotowujesz skrypt generatora generate_mystery_raid.py, który tworzy cztery pliki dyskowe dysk_A.img, dysk_B.img, dysk_C.img, dysk_D.img o nieznanej kolejności. Generator zapisuje w macierzy znany system plików (np. ext4 z czytelnym dokumentem), stosując losowo wybraną permutację dysków i nieznany rozmiar paska (np. 128 KB). Usuwasz wszelkie metadane konfiguracyjne i traktujesz wygenerowane obrazy jako materiał dowodowy podlegający analizie śledczej.

Piszesz skrypt analityczny raid_forensics.py w języku Python. W pierwszym kroku implementujesz skaner wielkości paska, badając punkty skokowej zmiany entropii i powtarzalności wzorców na granicach 16 KB, 64 KB, 128 KB i 256 KB. W drugim kroku implementujesz test zgodności XOR dla wszystkich 24 permutacji 4 dysków w celu zidentyfikowania prawidłowej kolejności nośników. Dla każdej permutacji weryfikujesz, który dysk w kolejnych paskach pełni rolę parzystości P, identyfikując wektor rotacji (left vs right, symmetric vs asymmetric).

Po automatycznym ustaleniu wszystkich parametrów skrypt scala bloki danych z pominięciem bloków parzystości do wynikowego pliku reconstructed_volume.raw. Montujesz odzyskany obraz za pomocą polecenia mount -o loop i weryfikujesz pełną spójność systemu plików narzędziem e2fsck oraz odczytujesz zapisany dokument. Sporządzasz raport śledczy dokumentujący kolejne kroki wnioskowania kryptoanalitycznego i uzyskane parametry geometrii w sprawozdaniu.

Przykładowe kroki do wykonania jako sugestia

  1. W terminalu utwórz katalog roboczy: mkdir -p ~/blind_raid && cd ~/blind_raid.
  2. Utwórz skrypt generatora: nano make_mystery_raid.py.
  3. W generatorze zaimplementuj tworzenie 4 dysków wirtualnych po 20 MB z ukrytą geometrią: stripe_size=65536 (64 KB), layout='left-symmetric', kolejność fizyczna: [Dysk_C, Dysk_A, Dysk_D, Dysk_B].
  4. Wypełnij macierz danymi testowymi zawierającymi system plików ext4 i plik z 'Flaga_Kryptologiczna_UAFM_2026'.
  5. Uruchom generator i uzyskaj 4 surowe pliki: mystery_0.raw, mystery_1.raw, mystery_2.raw, mystery_3.raw.
  6. Utwórz skrypt kryptoanalityczny: nano solve_raid.py.
  7. Zaimportuj moduły: math, itertools, os, hashlib.
  8. Zaimplementuj funkcję shannon_entropy( data) obliczającą entropię w bitach na bajt (0.0 do 8.0).
  9. Zaimplementuj test hipotez dla rozmiaru paska: oblicz entropię w oknach 16 KB, 32 KB, 64 KB, 128 KB i zlokalizuj periodyczne granice bloków.
  10. Zaimplementuj test korelacji XOR: dla każdej permutacji dysków sprawdź, czy w kolejnych paskach dokładnie jeden dysk jest sumą XOR pozostałych.
  11. Algorytm iteruje po 24 permutacjach i identyfikuje tę, dla której warunek XOR(D_0, D_1, D_2, D_3) == 0 jest spełniony dla 100% sprawdzonych pasków.
  12. Na podstawie pozycji dysku zerującego parzystość w kolejnych paskach zidentyfikuj schemat rotacji (np. sekwencja pozycji parzystości: 3, 2, 1, 0 -> left-symmetric).
  13. Zaimplementuj rekonstruktor: złóż właściwe bloki danych w strumień wyjściowy z pominięciem klocków parzystości.
  14. Zapisz wynik do pliku restored_fs.img.
  15. Zweryfikuj integralność odzyskanego obrazu: e2fsck -f -n restored_fs.img (brak błędów metadanych).
  16. Zamontuj odzyskany obraz w katalogu /mnt/recovered i odczytaj flagę: cat /mnt/recovered/flaga.txt.
  17. Wykonaj zrzuty ekranu kodu kryptoanalitycznego, tabeli wyników testu XOR oraz pomyślnego odczytu flagi.
  18. Sformułuj wnioski opisujące matematyczne podstawy śledczej rekonstrukcji macierzy wielodyskowych.

Kontrola zaliczenia (checklist):

  1. Odzyskano RAID 5 bez metadanych na obrazach ze startera: entropią wykryto granice, XOR-korelacją kolejność i rotację, system plików zamontowany.
  2. Wykazano różnicę: obrazy z szykiem (pełny odzysk) vs losowe (entropia płaska, brak korelacji — raport negatywny); dołączono mapy.
  3. Dołączono log rekonstrukcji (stripe, permutacja) + kod łatki (backup metadanych, zapasowy superblock).
  4. Opisano w 3–5 zdaniach kompromis: geometria jako sekret, forensics bez kontrolera, koszt obliczeń.

Wariant offline (fallback): Praca w pełni offline na wektorach ze startera w lokalnym Pythonie 3 bez sieci; dołącz kod ataku, log rekonstrukcji oraz opis kompromisu bezpieczeństwo–wydajność i wytyczne hardeningu.

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 matematycznych zależności geometrii macierzy RAID 5 (rozmiar paska, permutacji dysków, rotacji parzystości).
  • Praktyczna umiejętność wykorzystania analizy entropii Shannona do wykrywania granic bloków pamięci masowej.
  • Opanowanie techniki testowania korelacji bitowej XOR do automatycznego odzyskiwania kolejności nośników w grupie RAID.
  • Umiejętność odzyskiwania spójnego systemu plików w procedurach informatyki śledczej bez wsparcia kontrolera sprzętowego.
Zadanie 5 - ilustracja
06/10
Zadanie 6. Modelowanie ataku ransomware na zasoby sieciowe NAS/SAN i projekt kryptograficznie weryfikowalnego magazynu WORM / Immutable Snapshots
🖥️ Wymagane środowisko:
System: Windows + JSLinux Fedora 33 (Linux) Console (Python 3)
Oprogramowanie: przeglądarka + Python 3
Podstawa wykładowa: Część 6 - slajdy 4, 26, 27, 35, 39, 43: wektory ataków złośliwego oprogramowania ransomware na udział sieciowe NAS i macierze SAN, manipulacja migawkami z uprawnieniami administratora, technologia WORM (Write-Once-Read-Many), blokada retencji (Retention Lock / Compliance Mode), kryptograficzne podpisywanie stanu magazynu.

Cel

Celem ćwiczenia jest zamodelowanie złośliwego wektora ataku ransomware szyfrującego zasoby sieciowe NAS/SAN oraz zaprojektowanie kryptograficznie zabezpieczonego magazynu niezmiennego (Immutable Storage / WORM). Student implementuje w Pythonie symulację ataku ransomware na udziały SMB, tworzy mechanizm blokady czasowej migawek (Object Lock / Compliance Retention) uniemożliwiający ich skasowanie nawet po przejęciu konta administratora oraz weryfikuje integralność danych za pomocą łańcucha skrótów kryptograficznych z kotwicą czasową.

Scenariusz – opis

Współczesne kampanie złośliwego oprogramowania ransomware nie ograniczają się do szyfrowania lokalnych dysków stacji roboczych. Zaawansowane grupy przestępcze (np. LockBit, BlackCat) celują w zasoby sieciowe NAS oraz centralne repozytoria kopii zapasowych.

Po uzyskaniu poświadczeń administratora domeny intruzi logują się do konsoli zarządzającej pamięcią masową i celowo kasują migawki (snapshots). Tradycyjne migawki, mimo że chronią przed przypadkowym skasowaniem przez zwykłego użytkownika, mogą zostać bez trudu zniszczone poleceniem administracyjnym. Jedyną skuteczną barierą architektoniczną przed takim scenariuszem jest wdrożenie technologii niezmiennego składowania (Immutable Storage / WORM).

W trybie WORM (Write-Once-Read-Many) w wariancie Compliance Mode oprogramowanie układowe macierzy blokuje możliwość usunięcia lub modyfikacji migawki przez określony czas retencji. Nawet użytkownik posiadający uprawnienia roota lub administratora pamięci masowej nie ma fizycznej możliwości skasowania chronionego wolumenu przed upływem zdefiniowanego zegara. Dodatkowo stan każdej migawki jest wiązany kryptograficznym podpisem cyfrowym oraz łańcuchem skrótów z zewnętrznym bezpiecznym znacznikiem czasu (RFC 3161). Próba zaszyfrowania udziału sieciowego przez ransomware skutkuje jedynie utworzeniem nowych bloków w wolumenie roboczym, podczas gdy stan pierwotny pozostaje nienaruszony.

W tym zadaniu zasymulujesz destrukcyjny atak ransomware na udział sieciowy oraz zaimplementujesz w Pythonie odporny model magazynu niezmiennego z kryptograficzną weryfikacją.

Co ma wykonać student / grupa

Pracę rozpoczynasz od utworzenia katalogu ransomware_resilience w środowisku laboratoryjnym. Tworzysz skrypt ransomware_sim.py modelujący złośliwe oprogramowanie, które przeszukuje zasoby plikowe, szyfruje dokumenty algorytmem AES i usuwa pliki jawne.

Następnie w skrypcie immutable_storage.py projektujesz architekturę magazynu z niezmiennymi migawkami (Immutable Snapshots Engine). Implementujesz mechanizm Retention Lock: każda tworzona migawka otrzymuje znacznik czasowy lock_until oparty na chronionym zegarze sprzętowym (Monotonic Clock). W metodzie delete_snapshot implementujesz rygorystyczną walidację: próba usunięcia migawki przed upływem lock_until jest bezwzględnie odrzucana, niezależnie od roli wywołującego. Integrujesz kryptograficzny łańcuch spójności: stan każdego pliku w migawce jest haszowany, a korzeń stanu podpisywany kluczem prywatnym audytora bezpieczeństwa.

Przeprowadzasz symulację ataku: ransomware infekuje środowisko, szyfruje wszystkie pliki w udziale i próbuje wymusić usunięcie migawek ochronnych. Rejestrujesz logi odmowy skasowania migawek z powodu aktywnej blokady Retention Lock. Uruchamiasz procedurę natychmiastowego przywrócenia zasobu (Instant Rollback) z chronionej migawki i weryfikujesz integralność podpisem kryptograficznym. Wykazujesz stuprocentowe odzyskanie danych bez konieczności płacenia okupu oraz dokumentujesz architekturę WORM w sprawozdaniu.

Przykładowe kroki do wykonania jako sugestia

  1. W terminalu utwórz katalog roboczy: mkdir -p ~/ransomware_lab && cd ~/ransomware_lab.
  2. Utwórz plik symulatora ransomware: nano ransomware_attack.py.
  3. W symulatorze zaimplementuj rekurencyjne przeszukiwanie katalogu i szyfrowanie każdego pliku kluczem AES-CBC z dopisaniem rozszerzenia .locked.
  4. Utwórz skrypt magazynu niezmiennego: nano immutable_worm.py.
  5. Zaimportuj moduły: time, hashlib, os, json z biblioteki cryptography.hazmat.primitives.asymmetric (RSA).
  6. Wygeneruj parę kluczy RSA (2048-bit) dla wewnętrznego audytora macierzy do podpisywania manifestów migawek.
  7. Zaimplementuj klasę ImmutableSnapshot przechowującą identyfikator, strukturę plików, czas utworzenia, czas blokady retention_until oraz podpis RSA manifestu.
  8. Zaimplementuj metodę create_immutable_snapshot( volume, retention_seconds=3600): zablokuj migawkę na 1 godzinę.
  9. Zaimplementuj metodę delete_snapshot(snapshot_id, is_admin=True): jeśli time.time() < snapshot.retention_until, rzuć wyjątek PermissionDenied('Blokada WORM aktywna!').
  10. Przygotuj zasób produkcyjny z dokumentami: baza_klientow.csv, kontrakty.pdf, finanse.xlsx.
  11. Wykonaj niezmienną migawkę SNAP_PROTECTED z blokadą czasową.
  12. Zasymuluj infekcję ransomware: uruchom ransomware_attack.py na katalogu roboczym (wszystkie pliki zostają zaszyfrowane).
  13. Zasymuluj próbę usunięcia migawek przez złośliwy skrypt z uprawnieniami administratora: wykaż, że operacja kończy się błędem i odmową dostępu.
  14. Zaimplementuj procedurę rollback(SNAP_PROTECTED): odtwórz pierwotne pliki z nienaruszonej migawki.
  15. Zweryfikuj podpis cyfrowy odtworzonych plików za pomocą klucza publicznego audytora: potwierdź brak manipulacji.
  16. Przetestuj zachowanie systemu po sztucznym przesunięciu czasu poza okres retention_until (prawidłowe zwolnienie przestrzeni).
  17. Wykonaj zrzuty ekranu kodu, logów odmowy usunięcia migawki oraz pomyślnej weryfikacji podpisu odtworzonych danych.
  18. Sformułuj wytyczne architektoniczne dla enterprise storage w zakresie ochrony przed ransomware (zgodność z normą SEC 17a-4 dla WORM).

Kontrola zaliczenia (checklist):

  1. Zasymulowano ransomware na NAS/SAN i obroniono WORM na wektorze ze startera: atak szyfruje udziały i kasuje kopie, immutable snapshot z podpisem odtwarza.
  2. Wykazano różnicę: zwykle migawki (kasowane przez atak) vs retention-lock WORM (odrzut kasowania); dołączono logi ataku i restore.
  3. Dołączono log ataku i manifestów + kod łatki (WORM, podpisy manifestów, offline copy).
  4. Opisano w 3–5 zdaniach kompromis: retencja vs elastyczność, podpisy jako dowód, ostatnia linia obrony.

Wariant offline (fallback): Praca w pełni offline na wektorach ze startera w lokalnym Pythonie 3 bez sieci; dołącz kod ataku, log rekonstrukcji oraz opis kompromisu bezpieczeństwo–wydajność i wytyczne hardeningu.

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 nowoczesnych wektorów ataku ransomware ukierunkowanych na niszczenie kopii zapasowych i migawek.
  • Praktyczna znajomość mechanizmu Retention Lock w architekturze pamięci niezmiennej (Immutable Storage / WORM).
  • Umiejętność integracji kryptograficznych podpisów cyfrowych z manifestami migawek w celu poświadczania spójności.
  • Świadomość roli niemutowalnych migawek jako ostatecznej i niezawodnej linii obrony przed wymuszeniami okupowymi.
Zadanie 6 - ilustracja
07/10
Zadanie 7. Kryptograficzny podział klucza głównego macierzy danych KEK z wykorzystaniem schematu Shamira (Shamir's Secret Sharing (k, n)) w Pythonie
🖥️ Wymagane środowisko:
System: Windows + JSLinux Fedora 33 (Linux) Console (Python 3)
Oprogramowanie: przeglądarka + Python 3
Podstawa wykładowa: Część 6 - slajdy 11, 35, 36, 43: zarządzanie kluczem głównym szyfrowania macierzy (Key Encryption Key / KEK), problem pojedynczego punktu zaufania (Single Point of Failure), wieloosobowa autoryzacja k-z-n, schemat progowy Shamira nad ciałem skończonym GF(p), wielomiany losowe i interpolacja Lagrange'a.

Cel

Celem zadania jest zaprojektowanie i wdrożenie mechanizmu bezpiecznego rozproszenia klucza głównego macierzy pamięci masowej (KEK) za pomocą progowego schematu dzielenia sekretu Shamira (k, n) w języku Python. Student implementuje wielomianowe dzielenie 256-bitowego klucza AES nad ciałem liczb pierwszych GF(p), generuje unikalne udziały dla n administratorów storage, demonstruje niemożliwość odzyskania klucza przy posiadaniu k-1 udziałów oraz przeprowadza bezbłędną rekonstrukcję klucza za pomocą interpolacji Lagrange'a po zebraniu kworum k udziałów.

Scenariusz – opis

W wielkoskalowych centrach danych klucz szyfrujący macierzy dyskowej KEK (Key Encryption Key) chroni dostęp do petabajtów składowanych informacji. Powierzenie klucza KEK pojedynczemu administratorowi tworzy krytyczny pojedynczy punkt awarii oraz stwarza ryzyko nadużyć lub szantażu. Z kolei utrata klucza w wyniku wypadku losowego skutkuje nieodwracalną utratą wszystkich wolumenów w centrum danych.

Rozwiązaniem tego dylematu jest kryptograficzny schemat progowy Shamira (k, n) Secret Sharing zaproponowany przez Adiego Shamira w 1979 roku. W schemacie tym sekret dzielony jest na n niezależnych udziałów (shares) w taki sposób, że do odtworzenia klucza wymagane jest dowolne kworum co najmniej k udziałów. Posiadanie dowolnych k minus jeden udziałów nie daje atakującemu absolutnie żadnej informacji o sekrecie w sensie teorii informacji Shannona.

Matematyczną podstawą schematu jest fakt, że wielomian stopnia k-1 jest jednoznacznie wyznaczony przez dokładnie k punktów w ciele skończonym GF(p). Sekret umieszczany jest jako wyraz wolny a_0 losowego wielomianu, a kolejne współczynniki losowane są kryptograficznie z ciała liczb pierwszych. Każdy administrator otrzymuje punkt (x, f(x)), a rekonstrukcja klucza polega na obliczeniu wartości f(0) za pomocą wielomianu interpolacyjnego Lagrange'a.

Wdrożenie schematu Shamira pozwala macierzy pamięci masowej wymagać obecności np. 3 z 5 uprawnionych oficerów bezpieczeństwa do odblokowania wolumenów po restarcie.

W tym zadaniu zaimplementujesz pełny schemat Shamira w ciele liczb pierwszych w Pythonie i przetestujesz odporność na niekompletne kworum.

Co ma wykonać student / grupa

Pracę rozpoczynasz od utworzenia skryptu shamir_storage.py w katalogu roboczym środowiska laboratoryjnego. Wybierasz bezpieczną liczbę pierwszą p większą od przestrzeni 256-bitowych kluczy AES (np. 257-bitowa liczba pierwsza Mersenne'a lub liczba zdefiniowana w FIPS). Implementujesz funkcje arytmetyki modularnej w ciele GF(p), w tym dodawanie, odejmowanie, mnożenie oraz modularną odwrotność za pomocą rozszerzonego algorytmu Euklidesa. Implementujesz funkcję split_secret(secret_int, k, n), która generuje losowy wielomian stopnia k-1 i oblicza n unikalnych punktów (x_i, y_i).

Zasymulujesz wygenerowanie 256-bitowego klucza KEK macierzy dyskowej i podzielenie go pomiędzy n = 5 administratorów przy progu k = 3. Zapisujesz wygenerowane udziały do osobnych plików poświadczeń dla pięciu oficerów bezpieczeństwa storage. Implementujesz procedurę kryptoanalityczną: próbujesz odtworzyć klucz przy użyciu jedynie 2 udziałów (mniej niż próg k = 3). Wykazujesz matematycznie, że każda możliwa 256-bitowa wartość jest w równym stopniu prawdopodobna, co dowodzi bezpieczeństwa w sensie informacji (information-theoretic security).

Następnie implementujesz funkcję reconstruct_secret(shares) opartą na interpolacji Lagrange'a i rekonstruujesz klucz z 3 dowolnych udziałów. Potwierdzasz poprawność odzyskania oryginalnego klucza KEK i odblokowania wolumenu macierzy. Dokumentujesz kod, wyprowadzenia matematyczne interpolacji Lagrange'a oraz zrzuty ekranu konsoli w sprawozdaniu.

Przykładowe kroki do wykonania jako sugestia

  1. W terminalu utwórz katalog roboczy: mkdir -p ~/shamir_lab && cd ~/shamir_lab.
  2. Utwórz plik skryptu: nano shamir_engine.py.
  3. Zaimportuj moduły standardowe: secrets, os, sys.
  4. Zdefiniuj liczbę pierwszą p: wybierz 257-bitową liczbę pierwszą (np. p = pow(2, 256) + 297).
  5. Zaimplementuj rozszerzony algorytm Euklidesa: egcd(a, b) oraz modularną odwrotność mod_inv(a, p) = pow(a, -1, p).
  6. Zaimplementuj funkcję generowania wielomianu: poly = [secret] + [secrets.randbelow(p) for _ in range(k - 1)].
  7. Zaimplementuj obliczanie punktów: f(x) = sum( poly[i] * pow(x, i) for i in range(k)) % p.
  8. Wygeneruj klucz główny macierzy KEK: kek_bytes = os.urandom(32); kek_int = int.from_bytes(kek_bytes, 'big').
  9. Podziel klucz na n=5 udziałów z progiem k=3: wylicz punkty dla x od 1 do 5.
  10. Zapisz udziały do plików: share_1.json do share_5.json.
  11. Zaimplementuj interpolację Lagrange'a w zerze: L(0) = sum(y_j * prod((0 - x_m) * mod_inv(x_j - x_m, p) for m != j)) % p.
  12. Przetestuj próbę rekonstrukcji z 2 udziałów (k-1): wykaż, że wynik jest całkowicie błędny i zależy od arbitralnego wyboru brakującego punktu.
  13. Przetestuj rekonstrukcję z udziałów [1, 2, 3]: potwierdź, że recovered_kek == kek_int.
  14. Przetestuj rekonstrukcję z innej kombinacji kworum [2, 4, 5]: potwierdź identyczny poprawny wynik.
  15. Przekształć zrekonstruowaną liczbę z powrotem na 32 bajty i upewnij się o tożsamości z kek_bytes.
  16. Zbadaj odporność schematu na podrzucenie sfałszowanego udziału (bad share) i zaproponuj weryfikowalny schemat Verifiable Secret Sharing (Feldman VSS).
  17. Wykonaj zrzuty ekranu kodu, wygenerowanych udziałów oraz pomyślnej rekonstrukcji klucza z różnych podzbiorów administratorów.
  18. Sformułuj procedurę operacyjną wdrożenia schematu Shamira dla zarządzania kluczami w uczelnianym centrum danych.

Kontrola zaliczenia (checklist):

  1. Rozproszono KEK Shamirem (k,n) na wektorze ze startera: udziały wielomianowe w GF(p), rekonstrukcja Lagrange'em przy k, zero wiedzy przy k−1.
  2. Wykazano różnicę: k udziałów (odzysk) vs k−1 (entropia pełna, test statystyczny); dołączono logi.
  3. Dołączono log podziału/interpolacji + kod łatki (k,n do ryzyka, HSM na udziały, rotacja).
  4. Opisano w 3–5 zdaniach kompromis: brak single-point vs ceremonia udziałów, bezpieczeństwo teoriomnogościowe.

Wariant offline (fallback): Praca w pełni offline na wektorach ze startera w lokalnym Pythonie 3 bez sieci; dołącz kod ataku, log rekonstrukcji oraz opis kompromisu bezpieczeństwo–wydajność i wytyczne hardeningu.

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 matematycznych podstaw progowego podziału sekretu Shamira (k, n) opartego na ciałach skończonych GF(p).
  • Praktyczna umiejętność implementacji podziału wielomianowego oraz interpolacji Lagrange'a w języku Python.
  • Weryfikacja bezpieczeństwa w sensie teorii informacji gwarantującego zerowy wyciek wiedzy przy k-1 udziałach.
  • Znajomość zastosowania schematów progowych w eliminacji pojedynczego punktu zaufania w zarządzaniu pamięcią masową.
Zadanie 7 - ilustracja
08/10
Zadanie 8. Krypto-niszczenie danych (Crypto-Shredding) w chmurowych magazynach wielodzierżawnych i dowód matematycznej nieodwracalności po zniszczeniu klucza DEK
🖥️ Wymagane środowisko:
System: Windows + JSLinux Fedora 33 (Linux) Console (Python 3)
Oprogramowanie: przeglądarka + Python 3
Podstawa wykładowa: Część 6 - slajdy 11, 35, 36, 41, 43: niszczenie danych w chmurze i magazynach współdzielonych (Crypto-Shredding), hierarchia kluczy DEK (Data Encryption Key) i KEK (Key Encryption Key), kopertowanie (envelope encryption), formalna definicja bezpieczeństwa IND-CPA, dowód niemożliwości odzyskania informacji po usunięciu klucza DEK.

Cel

Celem laboratorium jest implementacja i formalna analiza procedury krypto-niszczenia danych (Crypto-Shredding) w architekturze pamięci masowej w chmurze. Student modeluje hierarchię kluczy kopertowych (Envelope Encryption) w Pythonie, szyfruje wielomegabajtowe wolumeny unikalnymi kluczami DEK, niszczy klucz DEK w centralnym magazynie KMS i przeprowadza analizę entropii oraz testy statystyczne NIST STS / Dieharder na pozostałym na dysku szyfrogramie, dowodząc nieodwracalności operacji bez konieczności kosztownego fizycznego nadpisywania sektorów.

Scenariusz – opis

W wielodzierżawnych środowiskach chmury obliczeniowej (takich jak AWS EBS, Azure Disk czy Google Cloud Persistent Disk) fizyczne nośniki są współdzielone. Gdy klient żąda usunięcia terabajtów danych, tradycyjne nadpisywanie sektorów zerami (data wiping) jest skrajnie nieefektywne i obciąża macierze. Co więcej, w rozproszonych systemach składowania nośniki ulegają ciągłej deduplikacji, migawkowaniu i replikacji, co uniemożliwia namierzenie wszystkich kopii fizycznych.

Standardem przemysłowym spełniającym rygory prawne (np. prawo do bycia zapomnianym RODO) stała się technika krypto-niszczenia danych (Crypto-Shredding). Koncepcja ta opiera się na hierarchii kopertowania kryptograficznego (Envelope Encryption): dane szyfrowane są unikalnym kluczem DEK (Data Encryption Key). Z kolei sam klucz DEK jest szyfrowany nadrzędnym kluczem zarządzającym KEK w module KMS i przechowywany w ściśle kontrolowanym rejestrze.

Procedura Crypto-Shredding polega na bezpowrotnym zniszczeniu klucza DEK w magazynie kluczy (usunięcie zaledwie 32 bajtów). Zgodnie z twierdzeniami kryptoanalitycznymi dotyczącymi bezpieczeństwa IND-CPA szyfru AES-256, zaszyfrowane dane stają się natychmiast nierozróżnialne od czystego szumu losowego. Pozostający na nośnikach wieloterabajtowy szyfrogram nie niesie żadnej użytecznej informacji, a jego odzyskanie wymagałoby złamania 256-bitowego klucza, co jest niemożliwe.

W tym zadaniu zaimplementujesz cykl życia kluczy kopertowych, przeprowadzisz procedurę Crypto-Shredding i zweryfikujesz statystycznie nieodwracalność usunięcia.

Co ma wykonać student / grupa

Pracę rozpoczynasz od utworzenia skryptu crypto_shredding_lab.py w środowisku roboczym terminala. Definiujesz klasę KeyManagementService (KMS) zarządzającą kluczami głównymi KEK oraz szyfrowanymi kluczami DEK dla poszczególnych dzierżawców. Implementujesz funkcję generate_data_key, która generuje 256-bitowy losowy klucz DEK w tekście jawnym oraz jego zaszyfrowaną kopię Encrypted_DEK. Zasymulujesz proces zapisu dużego wolumenu danych poufnych (np. bazy umów pracowniczych): dane szyfrowane są algorytmem AES-256 w trybie GCM z użyciem DEK.

Jawny klucz DEK jest natychmiast usuwany z pamięci RAM po zakończeniu szyfrowania, a na nośniku magazynu spoczywa wyłącznie szyfrogram i Encrypted_DEK. Weryfikujesz poprawność odczytu danych w normalnym trybie pracy poprzez odpytanie KMS, odzyskanie DEK i pomyślne odszyfrowanie wolumenu.

Następnie symulujesz procedurę trwałego wycofania klienta z chmury: wykonujesz komendę crypto_shred(tenant_id), która trwale niszczy klucz w KMS. Próbujesz odzyskać dane: wykazujesz, że bez klucza DEK żaden proces w chmurze nie jest w stanie odszyfrować bloków. Przeprowadzasz rygorystyczne testy statystyczne na osieroconym szyfrogramie: wyliczasz entropię Shannona, test autokorelacji oraz test równomierności rozkładu bajtów chi-kwadrat. Dowodzisz matematycznie, że szyfrogram ma właściwości statystyczne idealnego generatora liczb losowych, co uniemożliwia ekstrakcję jakichkolwiek danych. Sporządzasz raport poświadczający krypto-zniszczenie danych zgodny z wytycznymi normy ISO/IEC 27040 i NIST SP 800-88.

Przykładowe kroki do wykonania jako sugestia

  1. W terminalu utwórz katalog roboczy: mkdir -p ~/shred_lab && cd ~/shred_lab.
  2. Utwórz plik skryptu: nano crypto_shredder.py.
  3. Zaimportuj moduły: os, sys, math, json z biblioteki cryptography.hazmat.primitives.ciphers.aead (AESGCM).
  4. Zdefiniuj klasę CloudKMS: przechowuj klucz główny kek_master = AESGCM.generate_key(bit_length=256) oraz rejestr dek_registry = {}.
  5. Zaimplementuj metodę KMS.create_tenant_key(tenant_id): wygeneruj DEK, zaszyfruj go KEK-iem i zapisz w rejestrze.
  6. Zasymuluj klienta chmury: pobierz DEK, zaszyfruj plik o objętości 1 MB (baza_danych.db) za pomocą AES-GCM.
  7. Zapisz zaszyfrowany plik na wirtualnym dysku: baza_danych.enc.
  8. Usuń jawny DEK z pamięci klienta: del plaintext_dek.
  9. Zasymuluj legalny odczyt: klient prosi KMS o odszyfrowanie Encrypted_DEK, uzyskuje DEK i bezbłędnie odszyfrowuje plik.
  10. Wykonaj operację Crypto-Shredding: wywołaj kms.crypto_shred(tenant_id) usuwającą klucz z rejestru KMS i nadpisującą jego metadane zerami.
  11. Spróbuj ponownie odczytać plik: KMS zgłasza błąd KeyError('Klucz DEK zostal trwale zniszczony').
  12. Zbadaj pozostający na dysku plik baza_danych.enc: oblicz entropię Shannona (wartość musi wynosić >7.999 bitów/bajt).
  13. Przeprowadź test chi-kwadrat równomierności rozkładu bajtów: potwierdź hipotezę o losowości danych (brak korelacji z tekstem jawnym).
  14. Sprawdź, czy narzędzia typu strings potrafią wykryć choćby jeden czytelny ciąg w osieroconym szyfrogramie.
  15. Porównaj czas trwania Crypto-Shredding (mikrosekundy na usunięcie klucza) z tradycyjnym nadpisywaniem dysku 10 TB zerami (kilkanaście godzin).
  16. Wykonaj zrzuty ekranu kodu, logów niszczenia klucza w KMS oraz wyników testów statystycznych entropii.
  17. Sformułuj certyfikat kryptograficznego zniszczenia danych (Certificate of Cryptographic Erasure) zgodny z RODO i ISO/IEC 27040.

Kontrola zaliczenia (checklist):

  1. Wdrożono crypto-shredding na wektorze ze startera: hierarchia KEK→DEK (envelope), zniszczenie DEK kasuje wielomegabajtowy zbiór (entropia szyfrogramu, brak odzysku).
  2. Wykazano różnicę: kasowanie logiczne (odzysk możliwy) vs zniszczenie klucza (IND-CPA, nieodwracalne); dołączono testy losowości.
  3. Dołączono log koperty + kod łatki (rotacja DEK, audyt entropii, polityka retencji kluczy).
  4. Opisano w 3–5 zdaniach kompromis: sekundy zamiast godzin nadpisywania, chmura wielodzierżawna, koszt KMS.

Wariant offline (fallback): Praca w pełni offline na wektorach ze startera w lokalnym Pythonie 3 bez sieci; dołącz kod ataku, log rekonstrukcji oraz opis kompromisu bezpieczeństwo–wydajność i wytyczne hardeningu.

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 koncepcji krypto-niszczenia danych (Crypto-Shredding) opartej na hierarchii kopertowania kluczy (Envelope Encryption).
  • Świadomość przewagi operacyjnej niszczenia klucza DEK nad fizycznym nadpisywaniem wolumenów w architekturze chmurowej.
  • Matematyczny dowód nieodwracalności operacji oparty na bezpieczeństwie semantycznym IND-CPA szyfru AES-256.
  • Praktyczna umiejętność statystycznej weryfikacji entropii i losowości szyfrogramu w audycie bezpieczeństwa nośników.
Zadanie 8 - ilustracja
09/10
Zadanie 9. Kryptoanaliza protokołów sieci SAN (Fibre Channel i iSCSI) i demonstracja ataków przechwytywania LUN bez ochrony IPsec/FC-SP
🖥️ Wymagane środowisko:
System: Windows + JSLinux Fedora 33 (Linux) Console (Python 3)
Oprogramowanie: przeglądarka + Python 3
Podstawa wykładowa: Część 6 - slajdy 28, 29, 30, 31, 33, 35: podatności warstwy transportowej SAN, brak domyślnego szyfrowania w Fibre Channel i iSCSI, fałszowanie tożsamości WWPN Spoofing w przełącznikach FC, zatruwanie tablic ARP (ARP spoofing) w sieciach iSCSI SAN, podsłuch i wstrzykiwanie komend SCSI CDB, konfiguracja bezpieczeństwa FC-SP i IPsec ESP.

Cel

Celem ćwiczenia jest kryptoanaliza podatności protokołów transportowych w sieciach pamięci masowej Fibre Channel i iSCSI oraz modelowanie ataków przechwytywania jednostek LUN. Student analizuje wektory ataków na strefowanie programowe (Soft Zoning Spoofing), przeprowadza symulację zatruwania tablic ARP i podsłuchu nieszyfrowanego ruchu iSCSI w sieci lokalnej (przechwytywanie komend SCSI Read/Write) oraz projektuje bezpieczny tunel IPsec ESP z uwierzytelnianiem pre-shared key eliminujący podatność.

Scenariusz – opis

Tradycyjna architektura sieci pamięci masowej SAN powstała z założeniem, że sieć pamięciowa jest fizycznie odizolowana od sieci korporacyjnej. To historyczne założenie sprawiło, że protokoły Fibre Channel oraz wczesne wdrożenia iSCSI nie przewidywały natywnego szyfrowania ramek danych. We współczesnych skonsolidowanych centrach danych konwergencja sieciowa (np.

FCoE lub iSCSI w standardowym Ethernet 10/25 GbE) łączy ruch storage z ruchem ogólnym. W sieciach Fibre Channel bazujących na programowym strefowaniu (Soft Zoning) przełącznik filtruje ramki wyłącznie na podstawie deklarowanego adresu WWPN. Atakujący posiadający dostęp do serwera może programowo zmienić adres WWPN swojej karty HBA (WWPN Spoofing) i bez przeszkód uzyskać dostęp do cudzej strefy SAN.

W przypadku sieci iSCSI sytuacja jest jeszcze bardziej krytyczna: po przejściu fazy logowania CHAP komendy SCSI przesyłane są jawnym tekstem w pakietach TCP na porcie 3260. Intruz w tym samym segmencie VLAN może przeprowadzić atak zatruwania tablic ARP (ARP Cache Poisoning) i przechwycić cały strumień blokowy Man-in-the-Middle. Pozwala to nie tylko na pasywny podsłuch baz danych, lecz również na wstrzykiwanie zmanipulowanych struktur blokowych (SCSI Write Command Injection). Jedyną skuteczną obroną w sieci iSCSI jest wdrożenie szyfrowania warstwy sieciowej IPsec ESP, a w sieci FC wdrożenie protokołu FC-SP (Fibre Channel Security Protocol).

W tym zadaniu zasymulujesz atak podsłuchu i modyfikacji bloków w nieszyfrowanym iSCSI w Pythonie oraz zaprojektujesz bezpieczne tunelowanie IPsec.

Co ma wykonać student / grupa

Pracę rozpoczynasz od utworzenia skryptu san_security_lab.py w środowisku roboczym terminala. Definiujesz model sieci iSCSI SAN składającej się z Inicjatora (serwer bazodanowy), Celu (macierz dyskowa LUN 0) oraz Węzła Atakującego (MitM). Implementujesz parser pakietów iSCSI PDU: identyfikujesz nagłówek Basic Header Segment (BHS), kod operacji OpCode (SCSI Command, Data-Out, Data-In) oraz strukturę SCSI CDB. Zasymulujesz legalną transmisję: Inicjator zapisuje blok danych zawierający rekord bazy danych z numerem karty płatniczej.

W klasie AttackerMitM implementujesz atak zatruwania tablic ARP, przekierowujący ruch TCP/3260 przez węzeł atakującego. Węzeł atakującego przechwytuje pakiet iSCSI Write PDU, odczytuje dane w otwartym tekście (wykazując brak poufności) oraz modyfikuje pole kwoty transakcji. Atakujący przelicza sumę kontrolną TCP i przesyła spreparowany pakiet do macierzy Target, która bezbłędnie zapisuje sfałszowany blok w jednostce LUN.

W kolejnym kroku implementujesz model ochrony IPsec ESP (Encapsulating Security Payload) w trybie transportowym z algorytmem AES-256-GCM. Zaszyfrowujesz pakiet iSCSI w tunelu IPsec i powtarzasz próbę ataku MitM: wykazujesz, że podsłuch treści jest niemożliwy, a manipulacja bitem kończy się natychmiastowym odrzuceniem pakietu przez tag ICV. Sporządzasz pełny raport kryptoanalityczny z analizą podatności protokołów SAN i rekomendacjami wdrożeniowymi w sprawozdaniu.

Przykładowe kroki do wykonania jako sugestia

  1. W terminalu utwórz katalog roboczy: mkdir -p ~/san_attack && cd ~/san_attack.
  2. Utwórz plik skryptu symulatora: nano iscsi_mitm.py.
  3. Zaimportuj moduły: socket, struct, os, hashlib z biblioteki cryptography.hazmat.primitives.ciphers.aead (AESGCM).
  4. Zdefiniuj strukturę nagłówka iSCSI BHS: 48 bajtów (OpCode, Flags, LUN, Task Tag, DataSN, Offset, Length).
  5. Zaimplementuj funkcję build_iscsi_write_pdu(lun, lba, data): spakuj rozkaz SCSI WRITE(10) w ramkę iSCSI PDU.
  6. Zasymuluj Inicjatora wysyłającego poufny rekord: payload = b'TRANS_ID:99201;KWOTA:000100.00 PLN;KARTA:4111111111111111'.
  7. Zasymuluj węzeł atakującego w sieci lokalnej (przechwycenie strumienia nieszyfrowanego TCP/3260): pdu = intercept_packet().
  8. Zdekoduj pola iSCSI PDU: wypisz kod operacji (0x01 - SCSI Command) oraz odczytaj tekst jawny transakcji.
  9. Zademonstruj atak wstrzykiwania (Data Injection): zmień pole KWOTA na '999999.00 PLN' w buforze danych.
  10. Prześlij zmodyfikowany pakiet do macierzy Target i potwierdź, że Target zaakceptował zapis bez zgłoszenia błędu.
  11. Zaimplementuj model tunelu IPsec ESP: zdefiniuj klucz pre-shared key i algorytm uwierzytelniony AES-256-GCM.
  12. Zaimplementuj funkcję ipsec_encapsulate(iscsi_pdu, esp_key, spi=0x1000): dodaj nagłówek ESP, zaszyfruj PDU i dołącz tag ICV.
  13. Zasymuluj próbę ataku na zaszyfrowany pakiet IPsec: wykaż, że dane są całkowicie nieczytelne dla podsłuchującego.
  14. Zasymuluj próbę manipulacji bitem w pakiecie IPsec: Target weryfikuje tag ICV i natychmiast odrzuca pakiet (Integrity Check Failed).
  15. Przeanalizuj analogiczny wektor ataku WWPN Spoofing w sieciach Fibre Channel i opisz zasady działania protokołu FC-SP (DH-CHAP).
  16. Wykonaj zrzuty ekranu kodu, zdekodowanych pakietów iSCSI przed i po modyfikacji oraz logów odrzucenia przez IPsec ESP.
  17. Sformułuj techniczne zalecenia dotyczące bezwzględnego wymogu stosowania IPsec w sieciach iSCSI SAN łączonych przez współdzielony Ethernet.

Kontrola zaliczenia (checklist):

  1. Przeprowadzono przechwycenie LUN na modelu ze startera: soft-zoning spoof (fałszywy WWPN) + nieszyfrowane iSCSI daje odczyt/cudzy zapis bez alarmu.
  2. Wykazano różnicę: fabric bez ochrony (atak działa) vs IPsec ESP/FC-SP (odrzut, szyfrowanie); dołączono logi ramek.
  3. Dołączono log ataku + kod łatki (hard zoning, IPsec/FC-SP, CHAP wzajemny).
  4. Opisano w 3–5 zdaniach kompromis: separacja≠szyfrowanie, FCoE/iSCSI na IP, koszt krypto w SAN.

Wariant offline (fallback): Praca w pełni offline na wektorach ze startera w lokalnym Pythonie 3 bez sieci; dołącz kod ataku, log rekonstrukcji oraz opis kompromisu bezpieczeństwo–wydajność i wytyczne hardeningu.

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 iluzoryczności bezpieczeństwa opartego na separacji fizycznej w nowoczesnych sieciach SAN (FCoE, iSCSI).
  • Praktyczna znajomość wektorów podsłuchu i modyfikacji pakietów w nieszyfrowanych sesjach blokowych iSCSI.
  • Świadomość podatności mechanizmów Soft Zoning w Fibre Channel na ataki fałszowania tożsamości WWPN Spoofing.
  • Umiejętność projektowania kryptograficznej ochrony warstwy transportowej za pomocą IPsec ESP i protokołu FC-SP.
Zadanie 9 - ilustracja
10/10
Zadanie 10. Projekt hybrydowego, postkwantowego systemu ochrony archiwów długoterminowych (LTO / Cloud Cold Storage) z wykorzystaniem algorytmu ML-KEM i drzewa haszy
🖥️ Wymagane środowisko:
System: Windows + JSLinux Fedora 33 (Linux) Console (Python 3)
Oprogramowanie: przeglądarka + Python 3
Podstawa wykładowa: Część 6 - slajdy 6, 40, 41, 43: długoterminowa archiwizacja danych (taśmy LTO o żywotności 30 lat, chmurowe Cold Storage), zagrożenie ze strony komputerów kwantowych (atak Store Now, Decrypt Later), postkwantowy mechanizm kapsułkowania kluczy ML-KEM (Kyber, FIPS 203), hybrydowe schematy KEM (ML-KEM-768 + X25519) z kryptograficznym znakowaniem integralności w drzewie Merkle.

Cel

Celem zadania jest opracowanie i programowa implementacja odpornego na ataki kwantowe systemu bezpiecznej archiwizacji długoterminowej dla nośników taśmowych LTO i pamięci chmurowej. Student modeluje zagrożenie przechwycenia i zmagazynowania zaszyfrowanych taśm do późniejszego odszyfrowania (Store Now, Decrypt Later), implementuje w Pythonie hybrydowy schemat kapsułkowania kluczy łączący klasyczny protokół ECDH (X25519) z postkwantowym mechanizmem kratowym ML-KEM-768 (Kyber), szyfruje archiwum kluczem AES-256-GCM oraz tworzy drzewo haszy Merkle zapewniające trwałą weryfikację integralności przez kolejne 30 lat.

Scenariusz – opis

Taśmy magnetyczne LTO (Linear Tape-Open) oraz chmurowe archiwa typu Cold Storage są projektowane do bezpiecznego przechowywania danych przez okres 30 lat. W tak długim horyzoncie czasowym tradycyjne algorytmy kryptografii asymetrycznej (RSA, krzywe eliptyczne ECC) staną się całkowicie bezużyteczne. Pojawienie się funkcjonalnego komputera kwantowego z algorytmem Shora pozwoli na złamanie kluczy asymetrycznych i odszyfrowanie zarchiwizowanych danych.

Szczególnie groźną strategią stosowaną już dziś przez agencje wywiadowcze jest atak Store Now, Decrypt Later (SNDL). Atakujący przechwytują i magazynują zaszyfrowane archiwa, oczekując na pojawienie się maszyny kwantowej zdolnej do ich otwarcia za kilkanaście lat. W odpowiedzi amerykański instytut NIST opublikował standard FIPS 203 definiujący algorytm ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, dawniej Kyber).

W okresie przejściowym najlepszą praktyką inżynierską jest stosowanie schematów hybrydowych łączących sprawdzony klasyczny algorytm X25519 z postkwantowym ML-KEM-768. Złamanie takiego archiwum wymagałoby jednoczesnego skompromitowania obu niezależnych problemów matematycznych (dyskretnego logarytmu na krzywej oraz problemu kratowego LWE). Dodatkowo długoterminowa archiwizacja wymaga kryptograficznej weryfikacji integralności i autentyczności za pomocą drzewa Merkle, odpornego na degradację nośnika.

W tym zadaniu zaimplementujesz hybrydowy mechanizm kapsułkowania kluczy w Pythonie i zabezpieczysz długoterminowe archiwum taśmowe.

Co ma wykonać student / grupa

Pracę rozpoczynasz od utworzenia skryptu pq_archive_lab.py w dedykowanym środowisku roboczym. Instalujesz lub modelujesz bibliotekę kryptografii postkwantowej (np. pqcrypto lub czystą implementację ML-KEM w Pythonie). Projektujesz architekturę pakietu archiwalnego LTO zawierającego nagłówek metadanych, hybrydową kapsułę klucza oraz zaszyfrowany strumień bloków danych. Implementujesz moduł hybrydowej enkapsulacji klucza Hybrid_KEM: generujesz efemeryczną parę kluczy X25519 oraz parę kluczy ML-KEM-768.

Wyprowadzasz dwa niezależne sekrety dzielone: K_classical z protokołu ECDH oraz K_pq z algorytmu ML-KEM. Łączysz oba sekrety funkcją wyprowadzania klucza HKDF-SHA256, uzyskując ostateczny 256-bitowy klucz szyfrowania archiwum Archive_Key. Szyfrujesz zbiór danych archiwalnych algorytmem AES-256-GCM, dzieląc strumień na bloki taśmowe o rozmiarze 256 kilobajtów. Dla każdego bloku wyliczasz skrót SHA-256 i budujesz trwałe drzewo Merkle Tree, którego korzeń zapisujesz w niezmiennym nagłówku archiwum.

Zasymulujesz proces dekapsulacji i weryfikacji danych po 30 latach: odzyskujesz klucz Archive_Key z hybrydowej kapsuły i odszyfrowujesz bloki. Weryfikujesz spójność każdego bloku względem korzenia Merkle Root, dowodząc odporności na manipulacje i cichą korupcję nośnika taśmowego. Sporządzasz pełną dokumentację projektu z analizą bezpieczeństwa postkwantowego do sprawozdania laboratoryjnego.

Przykładowe kroki do wykonania jako sugestia

  1. W terminalu utwórz katalog roboczy: mkdir -p ~/pq_archive && cd ~/pq_archive.
  2. Utwórz plik skryptu archiwizatora: nano pq_archiver.py.
  3. Zaimportuj moduły: os, sys, hashlib, struct z biblioteki cryptography.hazmat.primitives.asymmetric (x25519) oraz kdf.hkdf (HKDF).
  4. Zaimplementuj lub zaimportuj model algorytmu ML-KEM-768 (FIPS 203) oparty na kratach algebraicznych nad pierścieniami wielomianów.
  5. Zdefiniuj funkcję hybrid_encapsulate(peer_x25519_pub, peer_mlkem_pub): wygeneruj parę efemeryczną X25519 oraz kapsułę ML-KEM.
  6. Oblicz współdzielony sekret klasyczny ss_c = ecdh(priv_e, peer_x25519_pub) oraz sekret postkwantowy ss_pq z ML-KEM.
  7. Wyprowadź klucz główny archiwum: final_key = HKDF(algorithm=SHA256, length=32, salt=None, info=b'Hybrid_LTO_v1').derive(ss_c + ss_pq).
  8. Zwróć kapsułę hybrydową (ephemeral_x25519_pub || mlkem_ciphertext) oraz final_key.
  9. Zaimplementuj symetryczną funkcję hybrid_decapsulate( capsule, priv_x25519, priv_mlkem) odtwarzającą identyczny final_key.
  10. Przygotuj pakiet danych archiwalnych o objętości 1 MB (historyczne rejestry akademickie uczelni).
  11. Podziel pakiet na 4 bloki po 256 KB i zbuduj drzewo skrótów Merkle Tree.
  12. Zaszyfruj bloki danych za pomocą AES-256-GCM z użyciem wygenerowanego final_key.
  13. Zapisz kompletny plik archiwum lto_tape_archive.bin: [Naglowek 30 lat][Kapsula Hybrydowa][Merkle Root][Zaszyfrowane Bloki].
  14. Zasymuluj procedurę odzyskiwania archiwum: zdekoduj kapsułę hybrydową i odtwórz klucz deszyfrujący.
  15. Odszyfruj bloki i zweryfikuj integralność każdego z nich za pomocą ścieżek drzewa Merkle.
  16. Zasymuluj hipotetyczne złamanie klasycznego X25519 przez komputer kwantowy i wykaż, że bezpieczeństwo pozostaje nienaruszone dzięki składowej ML-KEM.
  17. Wykonaj zrzuty ekranu kodu, struktury kapsuły hybrydowej oraz logów weryfikacji postkwantowej archiwum.
  18. Sformułuj wnioski dla strategii długoterminowego składowania danych w organizacjach publicznych (wytyczne NIST i ENISA).

Kontrola zaliczenia (checklist):

  1. Zbudowano archiwum postkwantowe na wektorze ze startera: hybryda X25519+ML-KEM-768 do koperty taśm LTO/cloud, Merkle do integralności długoterminowej.
  2. Wykazano różnicę: sam ECC (SNDL na 30 lat) vs hybryda PQC (odporna, większe nagłówki); dołączono tabelę rozmiarów/czasów.
  3. Dołączono log KEM i drzewa + kod łatki (hybrydowe KEM, re-timestamping, plan migracji).
  4. Opisano w 3–5 zdaniach kompromis: taśmy dekadami vs SNDL, ML-KEM jako parasol, Merkle jako pieczęć czasu.

Wariant offline (fallback): Praca w pełni offline na wektorach ze startera w lokalnym Pythonie 3 bez sieci; dołącz kod ataku, log rekonstrukcji oraz opis kompromisu bezpieczeństwo–wydajność i wytyczne hardeningu.

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 powagi zagrożenia atakiem Store Now, Decrypt Later w odniesieniu do 30-letnich archiwów taśmowych LTO.
  • Praktyczna znajomość hybrydowych schematów kapsułkowania kluczy KEM łączących X25519 z algorytmem kratowym ML-KEM-768.
  • Umiejętność integracji kryptografii postkwantowej z drzewami haszy Merkle dla trwałego poświadczania integralności.
  • Świadomość konieczności planowania migracji postkwantowej na poziomie projektowania architektury pamięci masowej.
Zadanie 10 - ilustracja
Podgląd