Laboratorium 6

Kon2 Kryptograficzne algorytmy i funkcje skrótu. Własności jednokierunkowości, odporności na kolizje i efektu lawinowego. Kon3 Mechanizmy integralności danych i bezpieczne implementacje funkcji haszujących.

Celem zadania jest empiryczne zbadanie i porównanie fundamentalnych właściwości kryptograficznych jednokierunkowych funkcji skrótu: determinizmu, kompresji do stałego rozmiaru wyjściowego (digest), odporności na znajdowanie przeciwobrazu (pre-image resistance) oraz efektu lawinowego (avalanche effect). Studenci analizują współczesne algorytmy z rodziny SHA-2 (SHA-256, SHA-512), SHA-3 (Keccak z funkcją gąbki / sponge construction) oraz BLAKE2b/BLAKE3, weryfikując ich wydajność obliczeniową i losowość rozkładu bitów.

W części praktycznej studenci implementują skrypt analityczny w języku Python obliczający odległość Hamminga (Hamming distance) pomiędzy skrótami wiadomości różniących się zaledwie jednym bitem (Single Bit Flip). Analizują rozkład statystyczny zmienionych bitów na wyjściu (oczekiwane 50% zmienionych bitów zgodnie z kryterium SAC – Strict Avalanche Criterion), badają brak korelacji oraz weryfikują podatność starych sum kontrolnych (CRC32) na proste próby odwrócenia.

Laboratorium Kryptoanalizy i Certyfikacji Bezpieczeństwa Oprogramowania otrzymało zlecenie audytu nowo projektowanego systemu blockchain dla rejestru ksiąg wieczystych. Zespół deweloperski rozważa wybór optymalnej funkcji skrótu dla nagłówków bloków i drzew transakcji.

W pierwotnym prototypie programiści użyli prostych sum kontrolnych CRC32 oraz niesprawdzonej autorskiej funkcji mieszającej opartej na operacjach XOR i przesunięciach bitowych, argumentując to rzekomą optymalizacją prędkości na mikrokontrolerach. Pierwsze testy penetracyjne wykazały, że zmiana kluczowych danych transakcji (np. numeru konta odbiorcy) powodowała zmianę zaledwie kilku bitów sumy wyjściowej, co umożliwiło łatwe fałszowanie wpisów.

Główny architekt bezpieczeństwa nakazał natychmiastowe przeprowadzenie rygorystycznego badania kryptograficznego i zastąpienie autorskiego rozwiązania certyfikowanymi algorytmami NIST (SHA-256, SHA-3) oraz nowoczesnymi algorytmami drzewiastymi (BLAKE3).

Aby zweryfikować właściwości kryptograficzne nowych kandydatów, konieczne jest przeprowadzenie testów laboratoryjnych sprawdzających odległość Hamminga, efekt lawinowy oraz czas przetwarzania dużych strumieni danych na maszynach x86_64 z akceleracją sprzętową Intel SHA Extensions.

Zespół laboratoryjny wciela się w rolę audytorów kryptograficznych. Studenci muszą przygotować środowisko testowe w Pythonie i Bashu, przeprowadzić testy odwracania bitów, wyznaczyć empiryczne histogramy zmian bitowych, ocenić spełnienie kryterium SAC i sformułować oficjalne rekomendacje architektoniczne.

• Narzędzia konsolowe Linux: sha256sum, sha3sum, b2sum, openssl
• Środowisko Python 3 z bibliotekami hashlib, binascii, matplotlib (lub math)
• Narzędzie perf / time do benchmarkingu wydajności algorytmów haszujących na CPU
• Narzędzie hexdump / xxd do binarnej inspekcji bitów wejściowych i wyjściowych
• Kompilator GCC do badania instrukcji sprzętowych Intel SHA Extensions (opcjonalnie)

1. Zapoznanie się z definicją kryptograficznej funkcji skrótu, kryterium SAC (Strict Avalanche Criterion) oraz konstrukcjami Merkle-Damgårda i Sponge.
2. Wygenerowanie pliku testowego message1.txt o ustalonej treści (np. ciąg 1024 bajtów).
3. Utworzenie pliku message2.txt różniącego się od message1.txt dokładnie jednym bitem na ustalonej pozycji (np. zmiana litery 'a' na 'b' lub operacja XOR z maską 0x01).
4. Obliczenie sum SHA-256 dla obu plików przy pomocy narzędzia sha256sum.
5. Wizualne i binarne porównanie obu 256-bitowych skrótów w reprezentacji szesnastkowej i binarnej.
6. Napisanie skryptu w języku Python obliczającego wagę Hamminga (liczbę zapalonych bitów) różnicy XOR pomiędzy dwoma skrótami.
7. Uruchomienie testu odwrócenia pojedynczego bitu dla 1000 losowych próbek i wyznaczenie średniego procentu zmienionych bitów wyjściowych (cel: ~50%).
8. Powtórzenie badania dla algorytmu SHA3-256 (funkcja gąbki Keccak) i porównanie rozkładu.
9. Powtórzenie badania dla algorytmu BLAKE2b / BLAKE3 i zbadanie właściwości dyfuzji.
10. Wykonanie analogicznego testu dla niekryptograficznej sumy CRC32 i zaobserwowanie drastycznego braku efektu lawinowego.
11. Zmierzenie czasu haszowania pliku o rozmiarze 1 GB dla SHA-256, SHA-512, SHA3-256 oraz BLAKE2b przy użyciu polecenia time.
12. Zbadanie wykorzystania sprzętowej akceleracji instrukcji Intel SHA Extensions (sprawdzenie flag procesora w /proc/cpuinfo).
13. Sporządzenie tabeli porównawczej: rozmiar skrótu, czas wykonania, odległość Hamminga, podatność na zbieżność stanów pośrednich.
14. Ocena ryzyka zastosowania poszczególnych algorytmów w systemie rejestracji transakcji blockchain.
15. Zdefiniowanie kryteriów wyboru pomiędzy SHA-256 a SHA-3 w oparciu o zalecenia NIST SP 800-107 i FIPS 202.
16. Weryfikacja implementacji testowej na różnych zestawach danych wejściowych (tekst, plik binarny, pusty ciąg znaków).
17. Sformułowanie wniosków końcowych w sprawozdaniu laboratoryjnym z dołączeniem wykresów rozkładu odległości Hamminga.

Efekt lawinowy (Avalanche Effect) jest kluczową własnością dobrej kryptograficznej funkcji skrótu. Oznacza on, że zmiana nawet pojedynczego bitu w danych wejściowych powoduje zmianę średnio 50% bitów w wygenerowanym skrócie w sposób całkowicie pseudolosowy i nieprzewidywalny. Jeżeli funkcja nie wykazuje tej cechy, napastnik może wnioskować o strukturze danych wejściowych na podstawie korelacji w skrótach.

Poniżej znajduje się skrypt w języku Python demonstracyjny obliczający odległość Hamminga pomiędzy skrótami SHA-256 dla danych różniących się jednym bitem:

Przykładowe wykonanie testu w terminalu Linux:

Dla porównania w CRC32 zmiana pojedynczego bitu powoduje zmianę sumy w sposób całkowicie deterministyczny i silnie skorelowany z wielomianem generatora.

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

1. Weryfikacja spełnienia ścisłego kryterium lawinowego (Strict Avalanche Criterion – SAC): zmiana pojedynczego bitu wejścia skutkująca mutacją średnio 50% bitów wyjścia.
2. Porównanie architektury kompresji Merkle-Damgårda (SHA-256) z konstrukcją gąbki (Sponge Construction) algorytmu SHA-3.
3. Analiza wydajności i właściwości kryptograficznych nowoczesnej rodziny BLAKE2/BLAKE3 opartej na rdzeniu szyfru strumieniowego ChaCha.
4. Matematyczne właściwości funkcji jednokierunkowych: odporność na przeciwobraz oraz odporność na drugi przeciwobraz.
5. Równomierność rozkładu entropii i eliminacja klastrowania wartości wyjściowych w przestrzeni haszowania.
6. Praktyczne zastosowanie testów statystycznych w ocenie jakości i nieprzewidywalności generatorów skrótów kryptograficznych.

Przykładowe wnioski (wzór do sprawozdania): Eksperymentalne badanie efektu lawinowego na próbie miliona losowych ciągów wejściowych potwierdziło doskonałe spełnienie kryterium SAC przez algorytmy SHA-256, SHA-3 oraz BLAKE2b. Zmiana zaledwie jednego, najmniej znaczącego bitu danych wejściowych powodowała za każdym razem nieprzewidywalną mutację od 48% do 52% bitów wyjściowego skrótu. Testy wydajnościowe wykazały znaczną przewagę algorytmu BLAKE2b, który na 64-bitowych procesorach osiągał niemal trzykrotnie wyższą przepustowość niż SHA-256 przy zachowaniu identycznego marginesu bezpieczeństwa. Analiza konstrukcji gąbki w SHA-3 potwierdziła jej wrodzoną odporność na ataki rozszerzenia długości bez konieczności stosowania zewnętrznych opakowań HMAC. Uzyskane wyniki jednoznacznie dowodzą, że badane funkcje skrótu gwarantują pełną pseudolosowość i brak jakichkolwiek korelacji statystycznych pomiędzy wejściem a wyjściem.

Kon2 Algorytmy skrótu MD5 i SHA-1. Historia kompromitacji, ataki kolizyjne i wycofanie ze standardów. Kon3 Odporność na kolizje (Collision Resistance) i atak urodzinowy w kryptografii.

Celem zadania jest praktyczne zademonstrowanie kompromitacji algorytmów MD5 i SHA-1 poprzez wygenerowanie rzeczywistych kolizji kryptograficznych (Collision Attack) oraz zbadanie ich katastrofalnych skutków dla bezpieczeństwa dokumentów cyfrowych, certyfikatów i oprogramowania. Studenci poznają mechanizmy ataku kolizyjnego (znalezienie dwóch różnych wiadomości M1 != M2 takich, że H(M1) = H(M2)) oraz ataku z wybranym prefiksem (Chosen-Prefix Collision).

W części praktycznej studenci wykorzystują narzędzie Fastcoll do wygenerowania pary różnych plików binarnych o identycznym skrócie MD5 w czasie poniżej kilkunastu sekund. Następnie badają słynny atak SHAttered z 2017 roku (Google / CWI Amsterdam), analizując strukturę dwóch plików PDF o zupełnie odmiennej zawartości wizualnej i identycznym skrócie SHA-1, a na koniec wdrażają procedury migracji do bezpiecznych funkcji SHA-256 i SHA-3 w systemach weryfikacji dokumentów.

Kancelaria Prawno-Notarialna LexIntegritas wdrożyła przed dziesięcioma laty elektroniczny system archiwizacji umów handlowych i pełnomocnictw. Dla każdego skanowanego lub generowanego dokumentu PDF system obliczał i zapisywał w bazie danych skrót MD5 oraz SHA-1 jako dowód nienaruszalności i autentyczności.

Podczas głośnego sporu sądowego o realizację kontraktu budowlanego o wartości 12 milionów złotych jedna ze stron przedłożyła aneks do umowy diametralnie zmieniający warunki płatności i kary umowne. Weryfikacja bazy danych wykazała, że zarówno oryginalny aneks (korzystny dla inwestora), jak i sfałszowany aneks (korzystny dla wykonawcy) posiadały dokładnie ten sam skrót MD5!

Biegły sądowy z zakresu informatyki śledczej stwierdził, że wykonawca wykorzystał publicznie dostępne algorytmy generowania kolizji MD5 (Fastcoll) wstrzykując specjalnie dobrane bloki różnicowe do struktury formatu dokumentu, co z punktu widzenia systemu archiwum uwiarygodniło sfałszowany dokument.

Incydent wywołał kryzys w kancelarii. Władze nakazały audyt wszystkich zarchiwizowanych dokumentów, wycofanie przestarzałych algorytmów MD5 i SHA-1 oraz opracowanie wytycznych dla sądów i instytucji finansowych dotyczących kryteriów dopuszczalności dowodów cyfrowych.

Studenci wcielają się w rolę biegłych informatyki śledczej. Ich zadaniem jest odtworzenie ataku kolizyjnego na MD5 za pomocą Fastcoll, przetestowanie ataku SHAttered na plikach PDF, analiza heksadecymalna bloków kolizyjnych oraz opracowanie bezpiecznego modułu walidacji opartego na SHA-256 z detekcją prób wstrzykiwania wektorów kolizyjnych.

• Narzędzie Fastcoll (Marc Stevens) do szybkiego generowania kolizji MD5
• Zestaw plików referencyjnych ataku SHAttered (shattered-1.pdf, shattered-2.pdf)
• Narzędzia konsolowe Linux: md5sum, sha1sum, sha256sum, cmp, diff, xxd
• Przeglądarka dokumentów PDF (evince, qpdf) do weryfikacji renderingu
• Środowisko Python do analizy heksadecymalnej różnic w blokach kolizyjnych

1. Skompilowanie lub zainstalowanie narzędzia Fastcoll w środowisku Linux.
2. Wygenerowanie pary plików binarnych col1.bin i col2.bin za pomocą polecenia fastcoll.
3. Zmierzenie czasu generowania kolizji na procesorze wielordzeniowym.
4. Obliczenie sum MD5 dla obu wygenerowanych plików i weryfikacja ich całkowitej identyczności.
5. Obliczenie sum SHA-256 dla obu plików i potwierdzenie, że SHA-256 bezbłędnie rozróżnia oba pliki.
6. Porównanie zawartości binarnej obu plików za pomocą cmp -l col1.bin col2.bin oraz hexdump / xxd.
7. Zidentyfikowanie dokładnych lokalizacji i wartości zmodyfikowanych bajtów (bloki różnicowe w algorytmie Wang et al.).
8. Pobranie referencyjnych dokumentów ataku SHAttered (shattered-1.pdf i shattered-2.pdf).
9. Weryfikacja sum kontrolnych plików PDF: potwierdzenie identycznego skrótu SHA-1 oraz różnych skrótów SHA-256.
10. Otwarcie obu plików PDF w przeglądarce dokumentów i zaobserwowanie drastycznie różnej zawartości wizualnej.
11. Analiza struktury wewnętrznej formatu PDF pod kątem umieszczenia bloków kolizyjnych w obiektach strumieniowych (Streams).
12. Zbadanie konsekwencji ataku typu Chosen-Prefix Collision dla certyfikatów X.509 (słynny atak Rogue CA z 2008 roku).
13. Zaprojektowanie reguły detekcji prób wykorzystania kolizji SHA-1 w systemach kontroli dokumentów.
14. Przeprowadzenie analizy ryzyka dalszego stosowania MD5 i SHA-1 w systemach dziedzinowych kancelarii.
15. Opracowanie planu bezpiecznej rehaszacji archiwum dokumentów cyfrowych do standardu SHA-256 / SHA-3.
16. Sformułowanie zaleceń i podsumowanie wyników w sprawozdaniu laboratoryjnym.

Atak kolizyjny polega na wyznaczeniu dwóch różnych wiadomości M1 != M2 dających ten sam skrót H(M1) = H(M2). W przypadku MD5 dzięki pracy prof. Xiaoyun Wang i Marca Stevensa (Fastcoll) kolizję można wygenerować na zwykłym laptopie w zaledwie kilka sekund.

Poniżej przedstawiono przykładową sesję terminala generującą kolizję MD5:

Dla SHA-1 atak SHAttered wymagał około 9 trylionów obliczeń SHA-1 (równoważnik 110 lat pracy pojedynczego GPU), jednak wygenerowano dwa działające pliki PDF o identycznym skrócie SHA-1: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a.

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

1. Mechanizm generowania kolizji identycznych prefiksów (Identical-Prefix Collision) w algorytmie MD5 za pomocą narzędzia Fastcoll w czasie zaledwie kilku sekund.
2. Analiza przełomowego ataku SHAttered na funkcję SHA-1: konstrukcja dwóch odmiennych plików PDF o identycznym skrócie kryptograficznym.
3. Różnica kryptoanalityczna pomiędzy atakiem kolizyjnym (dowolne dwa wejścia) a atakiem na drugi przeciwobraz (podrobienie konkretnego dokumentu).
4. Praktyczne implikacje kompromitacji funkcji skrótu dla podpisów cyfrowych X.509 i integralności umów cyfrowych.
5. Bezwzględny wymóg eliminacji MD5 i SHA-1 z łańcuchów certyfikatów, repozytoriów kodu oraz sum kontrolnych oprogramowania.
6. Zastosowanie algorytmów z rodziny SHA-2 (SHA-256, SHA-512) oraz SHA-3 jako bezpiecznych zamienników spełniających współczesne normy bezpieczeństwa.

Przykładowe wnioski (wzór do sprawozdania): Praktyczne wygenerowanie kolizji MD5 za pomocą programu Fastcoll w niespełna trzy sekundy na standardowym laptopie dobitnie unaoczniło całkowitą katastrofę bezpieczeństwa tego algorytmu. Przeprowadzona analiza ataku SHAttered wykazała, że spreparowanie dwóch dokumentów PDF o identycznym skrócie SHA-1 pozwala na podpisanie przez ofiarę nieszkodliwego pisma i późniejsze podstawienie sfałszowanego kontraktu finansowego. Doświadczenie dowiodło fundamentalnej różnicy pomiędzy kolizją a atakiem na drugi przeciwobraz, wskazując jednocześnie, że w systemach podpisu elektronicznego podatność na kolizje jest absolutnie dyskwalifikująca. Kompromitacja struktury Merkle-Damgårda w starszych haszach umożliwiła tworzenie sfałszowanych certyfikatów X.509, co historycznie zaobserwowano w zaawansowanym ataku Flame. Wyniki eksperymentu w pełni uzasadniają formalne wycofanie algorytmów MD5 i SHA-1 przez instytucje standaryzacyjne oraz zakaz ich stosowania w obrocie prawnym.

Kon2 Różnice pomiędzy niekryptograficznymi kodami detekcyjnymi (CRC, Adler, Fletcher) a kryptograficznymi funkcjami skrótu. Kon3 Integralność danych w warstwie transmisji a ochrona przed celową manipulacją (Malleability).

Celem zadania jest jednoznaczne zdefiniowanie i praktyczne zademonstrowanie różnic pomiędzy technicznymi kodami detekcyjnymi (Cyclic Redundancy Check – CRC32, Adler-32, kody Hamminga) a kryptograficznymi funkcjami skrótu (SHA-256, SHA-512, BLAKE2). Kody CRC zaprojektowano wyłącznie do wykrywania losowych błędów transmisji (zakłócenia elektromagnetyczne w łączach sieciowych, uszkodzone sektory dyskowe), a ich matematyczna liniowość sprawia, że są bezużyteczne wobec celowych modyfikacji danych przez napastnika.

W części praktycznej studenci przeprowadzają kontrolowaną manipulację plikiem konfiguracyjnym lub transakcyjnym, celowo modyfikując kwotę transakcji lub uprawnienia użytkownika, a następnie za pomocą prostych obliczeń algebraicznych (w oparciu o algebrę wielomianów nad ciałami Galois GF(2)) doklejają 4 bajty kompensacyjne, które sprawiają, że zmodyfikowany plik posiada DOKŁADNIE TAKĄ SAMĄ sumę CRC32 jak oryginał. Następnie studenci dowodzą, dlaczego nieliniowość i właściwości SHA-256 czynią taki atak obliczeniowo niemożliwym.

System automatyki przemysłowej SCADA w elektrociepłowni miejskiej przesyła pliki konfiguracyjne z parametrami ciśnienia i temperatury kotłów parowych z dyspozytorni do lokalnych sterowników PLC. Weryfikacja integralności przesyłanych plików bazowała na standardowej sumie CRC32 osadzonej w nagłówku pakietu.

Młodszy administrator sieci założył, że skoro CRC32 wykrywa 99,99% błędów transmisji na kablu Ethernet, to w pełni zabezpiecza także plik przed sabotażem i złośliwą modyfikacją.

Podczas testów penetracyjnych (Red Team) audytorzy bezpieczeństwa przejęli ruch sieciowy pomiędzy stacją inżynierską a sterownikiem PLC. Zmodyfikowali w pliku konfiguracyjnym dopuszczalny próg temperatury awaryjnego wyłączenia kotła z 250°C na 850°C, a na końcu pliku dokleili 4 bajty wyliczone prostym skryptem CRC32 spoofing. Sterownik PLC zweryfikował sumę CRC32 jako w 100% poprawną i przyjął krytycznie niebezpieczną konfigurację.

Raport z testów wywołał alarm w zarządzie przedsiębiorstwa ciepłowniczego. Nakazano natychmiastowe wdrożenie kryptograficznych funkcji skrótu SHA-256 oraz zbadanie wszystkich procedur weryfikacji danych w sieci przemysłowej.

Zespół laboratoryjny wciela się w rolę inżynierów cyberbezpieczeństwa OT/IT. Zadaniem studentów jest odtworzenie podatności CRC32: spreparowanie fałszywego pliku z zachowaniem identycznej sumy CRC32, zbadanie matematycznych przyczyn liniowości CRC32, porównanie zachowania z SHA-256 oraz wdrożenie bezpiecznego mechanizmu weryfikacji w Pythonie.

• Narzędzia konsolowe Linux: cksum, crc32, sha256sum, python3
• Narzędzie spoof-crc32 / skrypt manipulacji CRC32 w Pythonie
• Edytor heksadecymalny (hexedit, xxd) do podglądu doklejanych bajtów kompensacyjnych
• Moduł Pythona zlib (funkcja zlib.crc32) oraz hashlib (hashlib.sha256)

1. Przygotowanie oryginalnego pliku konfiguracyjnego kocioł_cfg.ini zawierającego parametry: max_temp=250 oraz alert_level=CRITICAL.
2. Obliczenie sumy CRC32 oraz skrótu SHA-256 dla pliku oryginalnego.
3. Zmiana wartości max_temp=250 na max_temp=850 w pliku zmodyfikowanym.
4. Obliczenie nowej sumy CRC32 i odnotowanie jej niezgodności z oryginałem.
5. Analiza matematycznej właściwości liniowości CRC32: CRC(A xor B) = CRC(A) xor CRC(B).
6. Napisanie skryptu w języku Python wyliczającego 4-bajtowy ciąg kompensacyjny (patch bytes) dołączany na końcu pliku.
7. Dołączenie wyliczonych bajtów na koniec zmodyfikowanego pliku kocioł_cfg_sfałszowany.ini.
8. Weryfikacja sumy CRC32 zmodyfikowanego pliku za pomocą narzędzia crc32 lub zlib: potwierdzenie 100% zgodności z oryginałem!
9. Weryfikacja skrótu SHA-256 zmodyfikowanego pliku: potwierdzenie, że SHA-256 wykrywa modyfikację bez najmniejszego problemu.
10. Zbadanie złożoności obliczeniowej ataku pre-image na CRC32 (złożoność O(1) dzięki algebrze wielomianów) vs SHA-256 (złożoność O(2^256)).
11. Symulacja weryfikacji pliku przez sterownik PLC w obu wariantach (CRC32 vs SHA-256).
12. Przetestowanie innych sum kontrolnych (Adler-32, Fletcher-16) pod kątem podatności na odwracanie.
13. Analiza standardów przemysłowych IEC 62443 w zakresie integralności oprogramowania układowego i konfiguracji.
14. Zaprojektowanie bezpiecznego formatu pliku konfiguracyjnego z kryptograficznym podpisem lub skrótem SHA-256.
15. Przeprowadzenie testów regresyjnych odporności nowego mechanizmu.
16. Opracowanie sprawozdania z listingami kodu w Pythonie i analizą matematyczną liniowości wielomianów.

Kody CRC są liniowe nad ciałem Galois GF(2). Oznacza to, że dla dowolnych danych można łatwo obliczyć wektor korekcyjny, który po doklejeniu na końcu pliku zresetuje rejestr przesuwny sumatora CRC do żądanej wartości wyjściowej. Jest to elementarna właściwość algebraiczna, a nie błąd implementacyjny.

Poniższy skrypt w języku Python demonstruje, jak doklejenie 4 bajtów pozwala wymusić identyczną sumę CRC32 po dowolnej modyfikacji treści:

Wynik weryfikacji w konsoli Linux:

Mimo identycznej sumy CRC32, skrót SHA-256 bezwzględnie dowodzi, że pliki są różne.

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

1. Podstawowe różnice w przeznaczeniu: kody detekcyjne (CRC32, Fletcher) do wykrywania błędów transmisji vs kryptograficzne funkcje skrótu do obrony przed fałszowaniem.
2. Liniowość matematyczna wielomianu CRC32 i podatność na ataki manipulacji danymi (Malleability): technika wstecznego obliczania sumy i dopełniania bajtów.
3. Demonstracja bezproblemowej podmiany kwoty w pliku transakcyjnym z zachowaniem identycznej sumy CRC32 za pomocą wstrzyknięcia bajtów korekcyjnych.
4. Odporność algorytmu SHA-256 na próby generowania przeciwobrazu i brak możliwości selektywnego korygowania zawartości pliku.
5. Analiza wydajnościowa i sprzętowe wsparcie instrukcji CRC32 w procesorach a narzut obliczeniowy kryptograficznych funkcji haszujących.
6. Zasady bezpiecznego projektowania protokołów: separacja warstwy integralności fizycznej (CRC) od warstwy integralności danych biznesowych (SHA/HMAC).

Przykładowe wnioski (wzór do sprawozdania): Praktyczna manipulacja plikiem tekstowym potwierdziła, że matematyczna liniowość kodu CRC32 pozwala na trywialne podrobienie sumy kontrolnej po zmianie danych transakcyjnych poprzez doklejenie zaledwie czterech bajtów korygujących. Zastosowanie narzędzia do inżynierii wstecznej wielomianu CRC umożliwiło sfałszowanie salda przelewu w pliku bez wywołania alarmu w systemie weryfikującym wyłącznie sumy cykliczne. Z kolei próba przeprowadzenia analogicznej operacji dla algorytmu SHA-256 zakończyła się całkowitym niepowodzeniem ze względu na brak analitycznych metod odwracania nieliniowych rund kompresji. Doświadczenie jednoznacznie udowodniło, że kody CRC są zaprojektowane wyłącznie do detekcji przypadkowych zakłóceń w medium transmisyjnym i nie stanowią żadnej bariery przed świadomym adwersarzem. W warstwach biznesowych i protokołach wyższego rzędu integralność danych musi być bezwzględnie poświadczana kryptograficznymi funkcjami skrótu.

Kon3 Integralność w łańcuchu dostaw oprogramowania (Software Supply Chain Security). Kon2 Kryptograficzne funkcje skrótu połączone z asymetrycznym podpisem cyfrowym.

Celem zadania jest opanowanie profesjonalnych procedur weryfikacji integralności i autentyczności oprogramowania dystrybuowanego w sieciach publicznych (obrazy systemów operacyjnych ISO, archiwa tar.gz/zip, skrypty instalacyjne bash/sh, kontenery Docker) z wykorzystaniem kryptograficznych funkcji skrótu (SHA-256, SHA-512) oraz podpisów odłączonych GPG (Detached Signatures). Studenci analizują zagrożenia wynikające z pobierania plików instalacyjnych wyłącznie przez HTTP/HTTPS bez weryfikacji sum oraz ryzyko kompromitacji serwera lustrzanego (mirror compromise).

W części praktycznej studenci konfigurują pełny proces weryfikacji: pobierają oficjalny plik sum SHA256SUMS oraz odłączony podpis cyfrowy SHA256SUMS.gpg (np. dystrybucji Debian/Ubuntu), importują klucz publiczny wydawcy z zaufanego serwera kluczy, weryfikują odcisk palca (fingerprint) klucza niezależnym kanałem, sprawdzają kryptograficzną autentyczność pliku sum za pomocą gpg --verify, a na końcu automatycznie weryfikują sumy skrótów pobranych obrazów za pomocą sha256sum --check --ignore-missing.

Firma FinTech PayData zarządza klastrem 120 serwerów bazodanowych przetwarzających transakcje kartowe. W ramach rutynowej rozbudowy infrastruktury administrator pobrał obraz instalacyjny systemu operacyjnego Linux oraz pakiety oprogramowania pośredniczącego z zewnętrznego, niesprawdzonego serwera lustrzanego (mirror) znalezionego na forum dyskusyjnym.

Administrator zignorował zalecenie weryfikacji sum skrótów SHA-256 i podpisów cyfrowych GPG, wychodząc z założenia, że skoro połączenie z serwerem lustrzanym było szyfrowane (HTTPS), to pliki są bezpieczne i wolne od modyfikacji.

W rzeczywistości serwer lustrzany był skompromitowany przez grupę APT. Do obrazu instalacyjnego wstrzyknięto złośliwy moduł jądra (rootkit) oraz zmodyfikowany demon SSH z backdoorowym kluczem uniwersalnym. Po zainstalowaniu systemu na serwerach produkcyjnych doszło do wycieku 500 tysięcy numerów kart płatniczych.

Audyt powłamaniowy ujawnił, że weryfikacja sumy SHA-256 pliku ISO ujawniłaby fałszerstwo w 5 sekund, a weryfikacja podpisu cyfrowego GPG wydawcy dystrybucji uniemożliwiłaby uruchomienie jakiegokolwiek sfałszowanego pakietu.

Grupa laboratoryjna wciela się w zespół cyberbezpieczeństwa wdrażający politykę Zero-Trust dla łańcucha dostaw oprogramowania. Studenci tworzą rygorystyczne procedury weryfikacji sum skrótów SHA-256/SHA-512, automatyzują sprawdzanie podpisów GPG za pomocą skryptów wdrożeniowych Bash oraz badają mechanizmy ochrony przed atakami typu man-in-the-middle na repozytoria.

• Narzędzia GNU coreutils: sha256sum, sha512sum, md5sum
• GnuPG (GPG v2) do weryfikacji podpisów cyfrowych i zarządzania pękiem kluczy
• Klient cURL / wget do pobierania artefaktów i plików sum kontrolnych
• Skrypt powłoki Bash do automatyzacji bezpiecznej weryfikacji w potoku CI/CD

1. Pobranie referencyjnego pliku dystrybucyjnego (np. mini.iso, pliku archiwum tar.gz) wraz z plikami SHA256SUMS oraz SHA256SUMS.gpg.
2. Wyświetlenie zawartości pliku SHA256SUMS i analiza jego formatu (skrót hex, spacja/gwiazdka, nazwa pliku).
3. Próba bezpośredniej weryfikacji sumy: sha256sum --check SHA256SUMS.
4. Analiza problemu: dlaczego sama weryfikacja SHA256SUMS nie wystarcza, jeżeli plik sum pobrano z tego samego niesprawdzonego serwera co obraz?
5. Pobranie klucza publicznego wydawcy dystrybucji (Signing Key) z zaufanego serwera kluczy (keyserver.ubuntu.com lub keyringu dystrybucji).
6. Weryfikacja pełnego odcisku palca (Fingerprint) klucza za pomocą gpg --fingerprint i porównanie go z oficjalnym kanałem HTTPS wydawcy.
7. Weryfikacja podpisu cyfrowego pliku sum kontrolnych: gpg --verify SHA256SUMS.gpg SHA256SUMS.
8. Zinterpretowanie wyników weryfikacji GPG: 'Good signature from ...' oraz ostrzeżenia 'WARNING: This key is not certified with a trusted signature!'.
9. Wyjaśnienie modelu Web of Trust w GPG i roli lokalnego oznaczania zaufania klucza (trust level).
10. Przeprowadzenie symulacji ataku: zmiana jednego bajtu w pobranym pliku ISO.
11. Ponowne uruchomienie sha256sum --check SHA256SUMS i zaobserwowanie komunikatu FAILED.
12. Przeprowadzenie symulacji podmiany pliku sum SHA256SUMS (zgodnego z fałszywym obrazem) i weryfikacja za pomocą GPG (wykrycie BŁĘDNEGO PODPISU - BAD signature).
13. Opracowanie uniwersalnego skryptu bash verify_software.sh automatyzującego ten dwuetapowy proces (GPG -> SHA-256).
14. Zbadanie nowoczesnych mechanizmów weryfikacji kontenerów i oprogramowania: Sigstore / Cosign oraz notacji TUF (The Update Framework).
15. Analiza wymagań normy PN-EN ISO/IEC 27001 w obszarze zarządzania podatnościami technicznymi i łańcuchem dostaw.
16. Przygotowanie raportu laboratoryjnego z pełnymi logami weryfikacji i opisem procedury CI/CD.

Sama suma skrótu (SHA-256) chroni wyłącznie przed przypadkowym uszkodzeniem pliku lub napastnikiem, który nie potrafi podmienić pliku sum. Jeżeli napastnik kontroluje serwer pobierania (mirror compromise), podmieni zarówno plik binarny, jak i towarzyszący mu plik sum SHA-256! Dlatego integralność pliku sum musi być zagwarantowana kryptograficznym podpisem cyfrowym (GPG).

Typowa procedura weryfikacji w terminalu Linux składa się z dwóch kroków:

Jeżeli którykolwiek bajt pliku ulegnie modyfikacji, sha256sum natychmiast zgłosi błąd:

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

1. Wektory zagrożeń w łańcuchu dostaw oprogramowania: podsłuch transmisji, ataki DNS Poisoning oraz kompromitacja serwerów lustrzanych (Mirrors).
2. Niewystarczalność samych sum kontrolnych SHA-256 pobieranych z tego samego serwera HTTP co pliki binarne (ryzyko jednoczesnej podmiany przez intruza).
3. Rola asymetrycznego podpisu cyfrowego GPG (odłączony podpis Detached Signature) w gwarantowaniu autentyczności pochodzenia i tożsamości wydawcy.
4. Weryfikacja klucza publicznego wydawcy: sprawdzanie odcisków palców (Key Fingerprint) w zaufanych kanałach Out-of-Band oraz w sieci zaufania.
5. Automatyzacja bezpiecznej weryfikacji paczek w menedżerach pakietów (APT, RPM) za pomocą podpisanych repozytoriów i sum kontrolnych.
6. Opracowanie standardowych procedur weryfikacji obrazów ISO systemów operacyjnych przed ich instalacją na serwerach produkcyjnych.

Przykładowe wnioski (wzór do sprawozdania): Analiza bezpieczeństwa potoku dystrybucji oprogramowania wykazała, że weryfikacja plików wyłącznie na podstawie sum kontrolnych SHA-256 pobranych z tej samej strony WWW jest całkowicie nieskuteczna w przypadku przejęcia serwera przez intruza. Napastnik podmieniający obraz instalacyjny może bez przeszkód zaktualizować również udostępniony plik z sumami skrótów, oszukując nieświadomego administratora. Dopiero wdrożenie odłączonych podpisów cyfrowych GPG powiązanych z niezależnie zweryfikowanym kluczem publicznym dewelopera zapewniło niezaprzeczalny dowód autentyczności oprogramowania. Zastosowanie procedury weryfikacji odcisku palca klucza za pośrednictwem zaufanego kanału zewnętrznego wyeliminowało ryzyko ataku podszywania się pod oficjalne repozytorium. Wprowadzenie rygorystycznego wymogu sprawdzania podpisów cyfrowych przed uruchomieniem kodu stanowi fundamentalną praktykę obrony przed atakami na łańcuch dostaw.

Kon3 Monitorowanie integralności plików (File Integrity Monitoring – FIM) i wykrywanie nieautoryzowanych modyfikacji. Kon4 Zarządzanie bezpieczeństwem urządzeń sieciowych MikroTik RouterOS i ochrona konfiguracji.

Celem zadania jest zaprojektowanie, wdrożenie i przetestowanie zintegrowanego systemu monitorowania integralności plików (File Integrity Monitoring – FIM) w infrastrukturze korporacyjnej opartej na serwerach Linux oraz routerach brzegowych MikroTik RouterOS. Studenci poznają zasady działania baz danych skrótów referencyjnych (baseline database) zawierających metadane plików (rozmiar, uprawnienia, inode, czas mtime) oraz kryptograficzne skróty SHA-256 krytycznych binariów i plików konfiguracyjnych.

W części praktycznej studenci wdrażają narzędzie AIDE (Advanced Intrusion Detection Environment) na serwerze Linux, konfigurują reguły skanowania dla katalogów systemowych (/etc, /bin, /sbin), generują bezpieczną bazę wzorcową aide.db, symulują atak polegający na podmienie binarki systemowej (/bin/login) lub modyfikacji pliku /etc/shadow, a następnie wykrywają nieautoryzowaną ingerencję. Równolegle na urządzeniu MikroTik RouterOS badają mechanizmy weryfikacji integralności pakietów systemowych (.npk) oraz automatyzują sprawdzanie sum skrótów eksportowanych kopii zapasowych konfiguracji.

Regionalny Szpital Wojewódzki zarządza infrastrukturą sieciową łączącą oddziały szpitalne, laboratoria analityczne oraz serwery Elektronicznej Dokumentacji Medycznej (EDM). Infrastruktura opiera się na klastrze serwerów Linux oraz routerach brzegowych MikroTik RouterOS zarządzających tunelami VPN IPsec.

W wyniku ataku phishingowego napastnik uzyskał uprawnienia lokalnego użytkownika na jednym z serwerów aplikacyjnych, a następnie dokonał eskalacji uprawnień do poziomu root. W celu utrzymania stałego dostępu (persistence) intruz zmodyfikował plik /bin/su oraz dołożył złośliwy klucz SSH do /root/.ssh/authorized_keys, nie zmieniając przy tym daty modyfikacji plików (timestamp stomping).

Tradycyjny antywirus nie wykrył żadnego złośliwego oprogramowania, ponieważ zmodyfikowane narzędzia były standardowymi narzędziami Linuksa z wstrzykniętym kodem. Incydent został wykryty przypadkowo dopiero po 3 miesiącach, gdy skradziono dane 40 000 pacjentów.

Zespół CSIRT NASK zarekomendował pilne wdrożenie systemu FIM (File Integrity Monitoring) opartego na kryptograficznych funkcjach skrótu, ze składowaniem wzorcowej bazy na nośniku tylko do odczytu (read-only) oraz cyklicznym audytem konfiguracji routerów brzegowych.

Zespół laboratoryjny przyjmuje rolę inżynierów bezpieczeństwa. Studenci konfigurują narzędzie AIDE, generują bazę wzorcową, przeprowadzają symulację zaawansowanego ataku z manipulacją czasem mtime, dowodzą skuteczności detekcji opartej na SHA-256 oraz wdrażają procedurę weryfikacji integralności pakietów na routerze MikroTik.

• Narzędzie AIDE (Advanced Intrusion Detection Environment) w systemie Linux
• GNU coreutils (sha256sum, touch, chmod, stat)
• Urządzenie lub maszyna wirtualna MikroTik RouterOS v7 (CHR)
• Klient SSH do RouterOS oraz konsola WinBox
• Skrypt bash integrujący raporty FIM z powiadomieniami bezpieczeństwa

1. Zainstalowanie pakietu aide w systemie Linux (apt install aide / dnf install aide).
2. Przeanalizowanie pliku konfiguracyjnego /etc/aide/aide.conf oraz zdefiniowanych grup reguł (np. BIN = p+i+n+u+g+s+b+m+c+sha256).
3. Skonfigurowanie monitorowania katalogów krytycznych: /bin, /sbin, /etc, /root/.ssh.
4. Zainicjalizowanie wzorcowej bazy danych integralności: aide --init (generowanie aide.db.new).
5. Aktywowanie bazy wzorcowej poprzez przeniesienie pliku do aide.db.
6. Zabezpieczenie bazy referencyjnej: ustawienie atrybutu niezmienności chattr +i aide.db lub skopiowanie na nośnik tylko do odczytu.
7. Wykonanie testowego sprawdzenia integralności: aide --check i potwierdzenie braku naruszeń.
8. Symulacja ataku intruza: dodanie nowego użytkownika do /etc/passwd lub dopisanie klucza do /root/.ssh/authorized_keys.
9. Wykonanie zaawansowanej manipulacji: podmienienie pliku binarnego i przywrócenie oryginalnych dat mtime i atime za pomocą touch -r.
10. Uruchomienie skanowania aide --check i szczegółowa analiza wygenerowanego raportu naruszeń.
11. Zbadanie, w jaki sposób funkcja skrótu SHA-256 zdemaskowała modyfikację binarki pomimo fałszowania dat systemowych.
12. Zalogowanie do routera MikroTik RouterOS i weryfikacja integralności zainstalowanych pakietów systemowych (/system package print).
13. Wygenerowanie kopii zapasowej konfiguracji MikroTik: /export file=backup_config oraz /system backup save name=full_backup.
14. Pobranie plików kopii przez SFTP na stację audytową i wygenerowanie ich skrótów SHA-256 do bazy referencyjnej.
15. Napisanie zadania cron / systemd timer w Linuksie wykonującego automatyczny nocny audyt integralności z wysyłką alertów e-mail.
16. Analiza zgodności wdrożenia FIM z normą PCI DSS (wymóg 11.5) oraz wytycznymi KRI.
17. Skompilowanie raportu laboratoryjnego zawierającego zrzuty raportów AIDE i RouterOS.

Narzędzie AIDE oblicza kryptograficzne skróty (domyślnie SHA-256 oraz SHA-512) dla każdego monitorowanego pliku. Napastnik może łatwo sfałszować czas modyfikacji pliku (mtime) za pomocą polecenia `touch -d` lub `touch -r`, jednak nie jest w stanie sfałszować skrótu kryptograficznego zawartości bez znajomości kolizji dla SHA-256.

Przykładowe polecenia wdrożeniowe AIDE w systemie Linux:

W MikroTik RouterOS weryfikację integralności pakietów wykonuje się poleceniem `/system/package/verify` lub poprzez kontrolę sum skrótów wyeksportowanych plików konfiguracyjnych w potoku CI/CD.

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

1. Zasada działania systemów FIM (File Integrity Monitoring): tworzenie bazowej sygnatury systemu (Baseline Snapshot) i okresowe skanowanie różnicowe.
2. Konfiguracja narzędzia AIDE: monitorowanie atrybutów plików (uprawnienia, mtime, inode, rozmiar) oraz skrótów kryptograficznych SHA-256 i SHA-512.
3. Zabezpieczenie bazy referencyjnej FIM przed modyfikacją przez intruza posiadającego uprawnienia roota: nośniki tylko do odczytu lub zdalne repozytoria.
4. Wykrywanie zaawansowanych technik ukrywania rootkitów i modyfikacji krytycznych bibliotek systemowych oraz modułów uwierzytelniania PAM.
5. Monitorowanie integralności konfiguracji urządzeń sieciowych MikroTik RouterOS za pomocą automatycznego eksportu i kryptograficznego haszowania skryptów.
6. Spełnienie wymogów punktu 11.5 standardu PCI DSS v4.0 oraz wytycznych KSC w obszarze wczesnego wykrywania nieautoryzowanych modyfikacji systemów.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie systemu monitorowania integralności plików AIDE pozwoliło na natychmiastowe wykrycie potajemnie wstrzykniętych backdoorów oraz modyfikacji bibliotek dynamicznych na testowym serwerze Linux. Szczegółowy raport różnicowy precyzyjnie wskazał nie tylko zmieniony skrót SHA-256 pliku konfiguracyjnego, ale także manipulacje czasem modyfikacji i uprawnieniami pliku. Zabezpieczenie bazy referencyjnej poprzez jej podpisanie kluczem prywatnym i przeniesienie na zewnętrzny serwer logów uniemożliwiło intruzowi zatuszowanie zmian po uzyskaniu praw roota. W środowisku routerów MikroTik zautomatyzowane porównywanie skrótów eksportu konfiguracji umożliwiło błyskawiczne wychwycenie nieautoryzowanych reguł NAT i kont VPN. Rozwiązanie to spełnia rygorystyczne wymagania sekcji 11.5 normy PCI DSS v4.0 w zakresie ciągłego nadzoru nad nienaruszalnością krytycznych plików systemowych.

Kon2 Bezpieczne jednokierunkowe funkcje wyprowadzania klucza (KDF) i haszowania poświadczeń tożsamości. Kon3 Techniki solenia (salt), rozciągania klucza (key stretching) oraz odporność na pamięć (memory-hardness).

Celem zadania jest szczegółowe zbadanie mechanizmów bezpiecznego haszowania haseł i zrozumienie, dlaczego szybkie kryptograficzne funkcje skrótu (takie jak MD5, SHA-1, a nawet surowy SHA-256) są śmiertelnie niebezpieczne w zastosowaniach uwierzytelniania ze względu na gigantyczną wydajność współczesnych procesorów graficznych (GPU) i układów dedykowanych (ASIC), osiągających miliardy prób na sekundę. Studenci badają ewolucję dedykowanych funkcji haszowania haseł: od tradycyjnego solenia, przez PBKDF2 (NIST), bcrypt (OpenBSD), scrypt (zależność od pamięci), aż po zwycięzcę Password Hashing Competition – algorytm Argon2 (w wariancie Argon2id).

W części praktycznej studenci implementują testy wydajnościowe i analityczne w Pythonie z wykorzystaniem bibliotek passlib oraz argon2-cffi. Dobierają parametry kosztu obliczeniowego (time cost), pamięciowego (memory cost / memory-hardness) oraz wielowątkowości (parallelism) w taki sposób, aby czas weryfikacji pojedynczego hasła na serwerze wynosił optymalne 200–500 ms, uniemożliwiając równoległe ataki słownikowe i brute-force w wypadku wycieku bazy danych użytkowników.

Platforma e-commerce SklepPolski.pl posiada 1,2 miliona zarejestrowanych kont klientów. Zespół programistów w 2018 roku zaimplementował mechanizm rejestracji i logowania, zapisując w bazie MySQL hasła haszowane pojedynczym wywołaniem SHA-256 z dołączonym statycznym ciągiem znaków (tzw. pieprzem w kodzie źródłowym, bez unikalnej soli dla każdego użytkownika).

W wyniku ataku SQL Injection na moduł recenzji produktów napastnicy pobrali pełny zrzut tabeli użytkowników zawierający adresy e-mail i skróty SHA-256. Następnie, wykorzystując klaster 8 kart graficznych NVIDIA RTX 4090 i narzędzie Hashcat, przestępcy łamali skróty z prędkością 80 miliardów prób na sekundę. W ciągu niespełna 4 godzin odzyskali hasła w postaci jawnej dla ponad 78% użytkowników serwisu.

Wyciek doprowadził do fali przejęć kont w serwisach bankowych i pocztowych ze względu na powszechne zjawisko reutylizacji haseł (password reuse). Urząd Ochrony Danych Osobowych (UODO) wszczął postępowanie, zarzucając administratorowi brak wdrożenia odpowiednich środków technicznych i organizacyjnych (art. 32 RODO).

Zarząd spółki zlecił natychmiastowe przeprojektowanie architektury uwierzytelniania i migrację bazy danych do nowoczesnego standardu Argon2id rekomendowanego przez OWASP, ENISA i NIST.

Grupa laboratoryjna wciela się w zespół architektów bezpieczeństwa aplikacji. Zadaniem studentów jest empiryczne porównanie odporności algorytmów MD5, SHA-256, PBKDF2, bcrypt i Argon2id, dobór bezpiecznych parametrów pracy dla środowiska produkcyjnego, zaprojektowanie bezpiecznej procedury migracji użytkowników w locie (Just-In-Time password re-hashing) oraz symulacja obciążenia serwera.

• Środowisko Python 3 z bibliotekami passlib, bcrypt, argon2-cffi, hashlib
• Narzędzie benchmarku czasu CPU i zużycia pamięci RAM (time, memory_profiler)
• Narzędzie Hashcat / John the Ripper (opcjonalnie do analizy przepustowości ataków)
• Baza danych SQLite / PostgreSQL do testów migracji poświadczeń w locie

1. Zainstalowanie wymaganych modułów Pythona: pip install argon2-cffi bcrypt passlib.
2. Napisanie skryptu benchmarkującego czas obliczenia 1000 skrótów dla: MD5, SHA-256, SHA-512.
3. Przeliczenie szacowanego czasu złamania 8-znakowego hasła w ataku brute-force na klastrze GPU dla czystego SHA-256.
4. Analiza budowy soli kryptograficznej (salt): unikalność na użytkownika, ochrona przed atakiem tęczowych tablic (Rainbow Tables).
5. Zbadanie algorytmu PBKDF2-HMAC-SHA256: badanie wpływu liczby iteracji (od 1 000 do 600 000 iteracji wg zaleceń OWASP).
6. Zbadanie algorytmu bcrypt: analiza parametru work factor (od 10 do 14) i maksymalnej długości hasła wejściowego (72 bajty).
7. Zbadanie algorytmu scrypt: analiza parametrów N (koszt CPU/RAM), r (rozmiar bloku), p (równoległość).
8. Szczegółowa analiza budowy Argon2id: wariant hybrydowy łączący odporność na ataki czasowe (Argon2d) i ataki kanałami bocznymi (Argon2i).
9. Wyznaczenie optymalnych parametrów Argon2id dla serwera: time_cost=3, memory_cost=65536 (64 MB), parallelism=4.
10. Zmierzenie czasu weryfikacji hasła dla tak dobranych parametrów Argon2id (cel: ~250-300 ms).
11. Wyjaśnienie, dlaczego wymaganie 64 MB pamięci RAM dla pojedynczego hasza całkowicie paraliżuje akceleratory GPU i układy ASIC.
12. Zaimplementowanie mechanizmu automatycznej migracji haseł użytkowników podczas logowania (Just-In-Time re-hashing ze starego SHA-256 na Argon2id).
13. Zaprojektowanie polityki reakcji na wyciek bazy danych i procedury resetu haseł.
14. Analiza zaleceń NIST SP 800-63B oraz wytycznych OWASP Password Storage Cheat Sheet.
15. Zbadanie odporności schematu na ataki typu Denial of Service (DoS na endpoint logowania poprzez celowe wysyłanie tysięcy zapytań o haszowanie).
16. Zaprojektowanie ogranicznika przepustowości (Rate Limiter) chroniącego proces haszowania Argon2id.
17. Sporządzenie raportu z wykresami czasów obliczeń i rekomendacjami wdrożeniowymi.

Szybkie funkcje skrótu (SHA-256) są doskonałe do sprawdzania integralności gigabajtowych plików ISO, ale są katastrofalnym wyborem do haseł. Karta graficzna RTX 4090 potrafi wykonać ponad 20 miliardów operacji SHA-256 na sekundę, podczas gdy dla Argon2id (z pamięcią 64 MB) przepustowość ta spada do zaledwie kilkunastu lub kilkudziesięciu prób na sekundę!

Poniżej znajduje się implementacja w języku Python bezpiecznego haszowania za pomocą Argon2id z biblioteką argon2-cffi:

Wygenerowany ciąg w bazie ma postać: `$argon2id$v=19$m=65536,t=3,p=4$salt$hash`, co zawiera w sobie wszystkie informacje niezbędne do weryfikacji bez konieczności utrzymywania dodatkowych kolumn na sól.

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

1. Analiza podatności szybkich funkcji skrótu (MD5, SHA-1, SHA-256) na masowo równoległe łamanie haseł za pomocą klastrów GPU i układów ASIC.
2. Rola kryptograficznej soli (Salt): unikalność per użytkownik, eliminacja ataków z użyciem tablic tęczowych i równoległego haszowania słowników.
3. Ewolucja funkcji rozciągania klucza (Key Stretching): iteracyjność w PBKDF2 vs algorytm bcrypt i jego techniczne ograniczenie do 72 bajtów hasła.
4. Właściwości funkcji pamięciożernych (Memory-Hard Functions): algorytm scrypt oraz hybrydowy standard Argon2id łączący odporność na GPU z ochroną przed kanałami bocznymi.
5. Strojenie parametrów kosztu (Memory Cost, Time Cost, Parallelism) w Argon2id w celu zbalansowania czasu logowania z oporem wobec ataków siłowych.
6. Zgodność z rekomendacjami OWASP Password Storage Cheat Sheet oraz standardem NIST SP 800-63B dotyczącymi bezpiecznego przechowywania danych uwierzytelniających.

Przykładowe wnioski (wzór do sprawozdania): Badania laboratoryjne odporności funkcji haszujących na łamanie sprzętowe za pomocą oprogramowania Hashcat wykazały całkowitą nieprzydatność tradycyjnych algorytmów SHA-256, które nowoczesne układy GPU przetwarzają z prędkością miliardów prób na sekundę. Wdrożenie algorytmu Argon2id z parametrami kosztu pamięci 64 MB oraz 3 iteracjami drastycznie podniosło koszt obliczeniowy ataku, uniemożliwiając napastnikowi efektywne wykorzystanie równoległych procesorów graficznych i układów ASIC. Wariant Argon2id okazał się bezkonkurencyjny, skutecznie łącząc odporność na ataki czasowe znaną z Argon2d z ochroną przed atakami kanału bocznego oferowaną przez Argon2i. Prawidłowe zastosowanie kryptograficznie silnej, losowej soli dla każdego hasła z osobna całkowicie zneutralizowało ryzyko ataków z użyciem prekompilowanych tablic tęczowych. Otrzymana konfiguracja magazynu haseł stanowi wzorcowe wdrożenie rekomendacji OWASP i zapewnia najwyższy dostępny obecnie poziom ochrony tożsamości użytkowników.

Kon3 Niezaprzeczalność i integralność zdarzeń w systemach teleinformatycznych. Łańcuchy skrótów. Kon1 Zapewnienie rozliczalności i ochrona przed zatarciem śladów przez intruza w logach systemowych.

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie mechanizmu kryptograficznego łańcucha skrótów (Hash Chain / Blockchain-like logging) w celu zagwarantowania nienaruszalności i wykrywalności modyfikacji (tamper-evidence) w rejestrach zdarzeń bezpieczeństwa (audit logs). Studenci badają matematyczną strukturę łańcucha, w którym każdy nowy wpis w logu zawiera skrót SHA-256 poprzedniego rekordu, czas zdarzenia (timestamp) oraz treść operacji, tworząc nierozerwalne wiązanie kryptograficzne uniemożliwiające dyskretne usunięcie, podmianę lub wstrzyknięcie wpisu wstecz.

W części praktycznej studenci budują w języku Python aplikację bezpiecznego rejestratora logów transakcyjnych dla systemu bankowego, implementują algorytm weryfikacji integralności całego łańcucha od bloku genezy (genesis entry), a następnie symulują próbę zatarcia śladów przez nieuczciwego administratora lub intruza (edycja jednego wpisu w środku pliku). Studenci dowodzą, że każda modyfikacja unieważnia wszystkie kolejne skróty w łańcuchu (efekt domina), a zastosowanie periodycznego podpisywania nagłówka łańcucha kluczem asymetrycznym zapobiega również przeliczeniu łańcucha na nowo przez napastnika.

Dom Maklerski InvestCapital przechowuje rejestry zleceń giełdowych i transakcji papierami wartościowymi w scentralizowanym systemie logowania Syslog/Elasticsearch. Zgodnie z wytycznymi Komisji Nadzoru Finansowego (KNF) oraz rozporządzeniem MAR, wszelkie modyfikacje pozycji maklerskich muszą być w sposób nienaruszalny i bezsprzeczny rejestrowane w celu wykrywania nadużyć (insider trading, spoofing zleceń).

W trakcie wewnętrznego śledztwa dotyczącego podejrzanych transakcji na akcjach spółki technologicznej okazało się, że nielojalny główny administrator baz danych, działając w porozumieniu z maklerem, zmodyfikował pliki dziennika systemowego na serwerze Linux. Wyciął ze środka logu trzy wpisy rejestrujące zlecenia kupna złożone przed publikacją poufnego komunikatu giełdowego, nie pozostawiając w standardowych plikach tekstowych żadnego śladu manipulacji.

W wyniku braku kryptograficznego powiązania wpisów Komisja Nadzoru Finansowego nie była w stanie jednoznacznie dowieść winy podejrzanych w sądzie, a dom maklerski został ukarany wielomilionową grzywną za rażące zaniedbania w obszarze kontroli wewnętrznej i integralności danych audytowych.

Kierownictwo pionu bezpieczeństwa nakazało zaprojektowanie i wdrożenie mechanizmu nienaruszalnych rejestrów typu Tamper-evident Audit Log opartego na kryptograficznym łańcuchu skrótów SHA-256 z automatyczną weryfikacją spójności i niezależnym kotwiczeniem stanu.

Studenci wcielają się w rolę architektów bezpieczeństwa systemów audytowych. Ich zadaniem jest opracowanie formatu wpisów (JSON / CSV), implementacja algorytmu powiązań skrótów H_i = SHA256(H_{i-1} || T_i || D_i), napisanie narzędzia audytowego weryfikującego stan rejestru, przeprowadzenie ataku polegającego na modyfikacji rekordu oraz zabezpieczenie przed przeliczeniem łańcucha za pomocą cyfrowego podpisu stanu (state checkpoint signing).

• Środowisko Python 3 z bibliotekami hashlib, json, datetime
• Narzędzia Linux: sha256sum, diff, jq do operacji na plikach JSON
• Narzędzie OpenSSL do asymetrycznego podpisywania punktów kontrolnych (checkpoints)
• Edytor tekstu / hex do symulacji fałszowania wpisów w dzienniku

1. Zaprojektowanie struktury rekordu dziennika audytowego w formacie JSON Lines (JSONL).
2. Zdefiniowanie pól rekordu: index, timestamp, event_type, actor, details, prev_hash, current_hash.
3. Utworzenie bloku genezy (Genesis Record) z ustalonym stałym prev_hash (np. 64 zera).
4. Zaimplementowanie w Pythonie modułu dopisującego zdarzenia z automatycznym wyliczaniem skrótu bieżącego: current_hash = SHA256(index + timestamp + event_type + actor + details + prev_hash).
5. Wygenerowanie przykładowego dziennika zawierającego 100 zdarzeń maklerskich.
6. Napisanie modułu weryfikatora verify_log_chain.py sprawdzającego rekurencyjnie poprawność każdego skrótu i zgodność ze wskaźnikiem prev_hash.
7. Pomyślne przetestowanie nienaruszonego dziennika i potwierdzenie integralności 100/100 wpisów.
8. Symulacja sabotażu administratora: zmiana kwoty transakcji lub wykasowanie rekordu nr 42 za pomocą edytora tekstu.
9. Uruchomienie weryfikatora i zaobserwowanie natychmiastowego wykrycia uszkodzenia łańcucha dokładnie na rekordzie 42.
10. Wyjaśnienie, dlaczego modyfikacja rekordu 42 unieważnia wszystkie skróty od 42 do 100 (efekt domina).
11. Symulacja zaawansowanego ataku: napastnik modyfikuje rekord 42 i przelicza na nowo wszystkie skróty w łańcuchu aż do końca pliku.
12. Wprowadzenie mechanizmu kotwiczenia stanu (State Checkpointing / Notarization): cykliczne podpisywanie bieżącego current_hash kluczem prywatnym RSA/ECDSA zewnętrznego serwera znacznika czasu (TSA).
13. Weryfikacja podpisanego checkpointu z użyciem OpenSSL dgst -verify.
14. Wykazanie, że zewnętrznie zakotwiczony punkt kontrolny całkowicie uniemożliwia przeliczenie łańcucha przez lokalnego administratora.
15. Analiza zgodności z wymogami KNF, KSC (Krajowy System Cyberbezpieczeństwa) oraz art. 32 RODO (rozliczalność).
16. Przetestowanie wydajności zapisu i weryfikacji dla zbioru 100 000 rekordów.
17. Podsumowanie wyników w sprawozdaniu laboratoryjnym z dołączeniem kodu źródłowego i logów detekcji manipulacji.

Łańcuch skrótów (Hash Chain) gwarantuje, że nie można zmienić ani usunąć żadnego wcześniejszego rekordu bez unieważnienia wszystkich późniejszych wpisów. Jest to ta sama koncepcja, która stanowi fundament technologii Blockchain i Git.

Przykładowa implementacja weryfikatora łańcucha logów w języku Python:

Wynik działania weryfikatora po zmodyfikowaniu wpisu w środku logu:

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

1. Architektura kryptograficznego łańcucha skrótów (Hash Chain): włączanie skrótu poprzedniego rekordu do obliczania skrótu bieżącego wpisu audytowego.
2. Własność dowodliwości manipulacji (Tamper-Evidence): natychmiastowe wykrywanie usunięcia, wstawienia lub edycji dowolnego wpisu historycznego w logach.
3. Rola bloku genezy (Genesis Block) oraz kryptograficznego kotwiczenia bieżącego wierzchołka łańcucha w zewnętrznych, niezmiennych repozytoriach.
4. Zastosowanie asymetrycznego podpisu cyfrowego lub kwalifikowanego znacznika czasu na regularnych punktach kontrolnych łańcucha (Checkpoints).
5. Ochrona przed zatarciem śladów przez administratora (Insider Threat) i zapewnienie pełnej rozliczalności zdarzeń w informatyce śledczej.
6. Zastosowanie technologii niemutowalnych rejestrów w spełnianiu wymogów prawnych rozporządzenia RODO i Ustawy o Krajowym Systemie Cyberbezpieczeństwa.

Przykładowe wnioski (wzór do sprawozdania): Implementacja kryptograficznego łańcucha skrótów w module rejestracji zdarzeń bezpieczeństwa całkowicie wyeliminowała możliwość niezauważalnego zatarcia śladów w logach przez intruza posiadającego uprawnienia administratora. Każdy nowy wpis w dzienniku jest nierozerwalnie powiązany ze skrótem SHA-256 poprzedniego rekordu, tworząc jednokierunkową strukturę odporną na manipulacje wstecz. Dowolna próba modyfikacji treści pojedynczego zdarzenia lub wycięcia linii z logu powoduje natychmiastowe zerwanie łańcucha w trakcie automatycznej procedury weryfikacji spójności. Dodatkowe okresowe publikowanie bieżącego wierzchołka łańcucha na zewnętrznym serwerze czasu zagwarantowało niezaprzeczalność chronologii zdarzeń. Zaprojektowane rozwiązanie stanowi potężne narzędzie w informatyce śledczej, zapewniając pełną wartość dowodową rejestrów audytowych w postępowaniach sądowych.

Kon2 Algorytmy uwierzytelniania wiadomości MAC i HMAC. Konstrukcja Merkle-Damgårda. Kon3 Podatności prostych konstrukcji H(key || message) na atak rozszerzenia długości (Length Extension Attack).

Celem zadania jest dogłębne zrozumienie mechanizmu działania kodów uwierzytelniania wiadomości (Hash-based Message Authentication Code – HMAC, RFC 2104) oraz zbadanie krytycznej luki w naiwnych schematach uwierzytelniania opartych o proste doklejenie klucza do wiadomości w postaci H(key || data). Studenci analizują wewnętrzną architekturę funkcji skrótu opartych na konstrukcji Merkle-Damgårda (MD5, SHA-1, SHA-256, SHA-512) i poznają anatomię ataku rozszerzenia długości (Length Extension Attack), w którym napastnik, znając wyłącznie H(key || data) oraz długość klucza, może bez znajomości samego klucza wygenerować poprawny skrót dla nowej wiadomości H(key || data || padding || malicious_data).

W części praktycznej studenci przeprowadzają symulację ataku rozszerzenia długości na podatną aplikację API za pomocą dedykowanego narzędzia HashPump. Następnie implementują poprawny, odporny kryptograficznie mechanizm HMAC-SHA256 wykorzystujący dwukrotne haszowanie z dopełnieniem klucza do długości bloku za pomocą stałych opad i ipad: HMAC(K, m) = H((K xor opad) || H((K xor ipad) || m)), dowodząc dlaczego ta konstrukcja całkowicie unieszkodliwia atak.

Agencja Marketingowa LeadMedia udostępnia klientom interfejs API do pobierania statystyk kampanii reklamowych. Autoryzacja zapytań HTTP opierała się na parametrze podpisu signature przekazywanym w adresie URL, np.: /api/download?user=klient123&role=user&sig=6a2b...

Młodszy programista, nie posiadając wykształcenia kryptograficznego, zaimplementował weryfikację podpisu w sposób intuicyjny: sig = sha256(secret_key + query_string). Założył, że skoro tajny klucz serwera (secret_key) jest znany tylko serwerowi, nikt z zewnątrz nie będzie w stanie sfabrykować poprawnego podpisu.

W trakcie audytu bezpieczeństwa testerzy penetracyjni zidentyfikowali zastosowanie konstrukcji SHA-256(key || data). Wykorzystując fakt, że stan wewnętrzny algorytmu SHA-256 po przetworzeniu bloku odpowiada wartości skrótu pośredniego, użyli narzędzia HashPump. Dokleili do parametrów zapytania ciąg &role=admin i w oparciu o stan wyliczony z legalnego podpisu uzyskali w 100% poprawny skrót SHA-256, uzyskując pełne uprawnienia administratora w systemie bez łamania klucza tajnego.

Incydent unaocznił zarządowi spółki niebezpieczeństwo samodzielnego projektowania prymitywów kryptograficznych. Zalecono natychmiastowe usunięcie autorskiego algorytmu i zastąpienie go standardem HMAC-SHA256 zgodnym z FIPS 198-1 i RFC 2104.

Zespół laboratoryjny przyjmuje rolę analityków bezpieczeństwa aplikacji webowych. Studenci analizują mechanizm Merkle-Damgårda, wykonują atak Length Extension za pomocą HashPump, analizują pakiety w Burp Suite / curl, a następnie implementują bezpieczną weryfikację HMAC-SHA256 w Pythonie oraz porównują odporność na ten atak algorytmu SHA-3 (Keccak z architekturą gąbki).

• Narzędzie HashPump do demonstracji ataku rozszerzenia długości
• Środowisko Python 3 z modułem hmac i hashlib
• Narzędzie cURL do wysyłania spreparowanych zapytań HTTP
• OpenSSL (polecenie openssl dgst -sha256 -hmac) do generowania poprawnych podpisów HMAC
• Narzędzie Wireshark / Burp Suite do inspekcji nagłówków i parametrów URL

1. Zapoznanie się z architekturą dopełnienia Merkle-Damgårda (MD-strengthening) i pojęciem wektora inicjalizacyjnego (IV).
2. Napisanie w Pythonie podatnego serwera API weryfikującego żądania konstrukcją signature = sha256(SECRET_KEY + data).
3. Wygenerowanie legalnego żądania API dla użytkownika: data = 'user=student&role=guest'.
4. Pobranie poprawnego podpisu wygenerowanego przez serwer dla tego żądania.
5. Zainstalowanie lub skompilowanie narzędzia HashPump (lub użycie biblioteki hashpumpy w Pythonie).
6. Skonfigurowanie parametrów ataku: oryginalne dane, oryginalny skrót, długość tajnego klucza (np. 16 bajtów) oraz dane dopisywane ('&role=admin').
7. Wygenerowanie przez HashPump nowego ciągu danych z wstrzykniętym dopełnieniem hex oraz nowego skrótu SHA-256.
8. Wysłanie spreparowanego żądania do podatnego serwera API za pomocą cURL.
9. Potwierdzenie, że serwer zaakceptował sfałszowany podpis i przyznał uprawnienia administratora!
10. Analiza matematyczna: dlaczego konstrukcja H(key || data) jest z natury podatna na kontynuację stanu wewnętrznego funkcji kompresującej.
11. Zaimplementowanie standardowego kodu uwierzytelniania HMAC-SHA256 wg RFC 2104 z użyciem modułu hmac w Pythonie.
12. Przeanalizowanie wewnętrznej budowy HMAC: stałe ipad (0x36) oraz opad (0x5c) i dwuetapowe haszowanie H((K xor opad) || H((K xor ipad) || data)).
13. Próba powtórzenia ataku HashPump na endpoint zabezpieczony HMAC-SHA256: wykazanie całkowitej nieskuteczności ataku.
14. Zbadanie zachowania funkcji SHA-3 (Keccak) – dlaczego architektura gąbki jest z natury odporna na Length Extension Attack nawet bez HMAC (KMAC).
15. Porównanie wydajności obliczeniowej HMAC-SHA256 vs czyste SHA-256.
16. Opracowanie bezpiecznych rekomendacji dla programistów REST API w organizacji.
17. Sporządzenie sprawozdania laboratoryjnego z pełnym zapisem ataku i listingami kodu zabezpieczającego.

Konstrukcja Merkle-Damgårda przetwarza dane w 512-bitowych blokach. Wynik poprzedniego bloku staje się wektorem inicjalizacyjnym (IV) dla kolejnego bloku. Skrót końcowy to po prostu stan rejestrów po ostatnim bloku. Jeśli znamy ten skrót i długość danych, możemy potraktować ten skrót jako IV i bez znajomości klucza dopisać kolejny blok danych!

Demonstracja działania narzędzia HashPump w konsoli Linux:

Wysłanie spreparowanego zapytania przez cURL skutkuje przyznaniem uprawnień admina w podatnym API.

Rozwiązaniem jest zastosowanie standardowego HMAC (RFC 2104):

Konstrukcja HMAC haszuje klucz dwukrotnie z wewnętrznym i zewnętrznym paddingiem, co całkowicie blokuje możliwość kontynuacji stanu hashującego.

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

1. Podatność naiwnych konstrukcji uwierzytelniania H(klucz || wiadomość) opartych na algorytmach o strukturze Merkle-Damgårda (MD5, SHA-1, SHA-256).
2. Matematyczny mechanizm ataku rozszerzenia długości (Length Extension Attack): wykorzystanie stanu rejestrów funkcji jako wektora dla doklejonych danych.
3. Praktyczna demonstracja ataku za pomocą narzędzia HashPump: sfałszowanie uprawnień użytkownika w tokenie autoryzacyjnym bez znajomości klucza tajnego.
4. Konstrukcja kodu HMAC (RFC 2104): dwuprzebiegowe haszowanie z dopełnieniami wewnętrznymi i zewnętrznymi oraz matematyczny dowód odporności.
5. Analiza odporności nowoczesnych funkcji skrótu SHA-3 oraz BLAKE2 na ataki rozszerzenia długości wynikająca z ich architektury wewnętrznej.
6. Rekomendacje projektowe dla twórców protokołów i API dotyczące wyboru standaryzowanych algorytmów uwierzytelniania wiadomości.

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzona demonstracja ataku rozszerzenia długości za pomocą narzędzia HashPump bezspornie udowodniła, że naiwne łączenie klucza tajnego z wiadomością w konstrukcji H(key || message) stwarza krytyczną podatność w systemach autoryzacyjnych. Znając jedynie skrót SHA-256 legalnego żądania i jego długość, napastnik był w stanie dokleić do tokena nieuprawnione uprawnienia administratora i wygenerować poprawny skrót bez jakiejkolwiek znajomości tajnego klucza serwera. Zastąpienie wadliwej konstrukcji standaryzowanym kodem HMAC-SHA256 całkowicie udaremniło ten wektor ataku dzięki dwukrotnemu przetwarzaniu danych z dopełnieniami ipad oraz opad. Analiza teoretyczna potwierdziła, że dopiero zagnieżdżona struktura HMAC skutecznie ukrywa stan rejestrów wewnętrznych kompresora Merkle-Damgårda. Wyniki laboratorium jednoznacznie wskazują, że autorskie konstrukcje kryptograficzne nie powinny być nigdy stosowane w zastępstwie sprawdzonych standardów takich jak RFC 2104.

Kon4 Bezpieczeństwo protokołów komunikacyjnych i interfejsów programistycznych REST API. Kon3 Odporność na ataki czasowe (Timing Attacks) w weryfikacji sygnatur kryptograficznych.

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie produkcyjnego mechanizmu ochrony powiadomień asynchronicznych (Webhooks) oraz transakcji API z wykorzystaniem podpisów HMAC-SHA256, sygnatur czasowych (timestamps) oraz funkcji porównywania w stałym czasie (constant-time comparison). Studenci badają zasady zabezpieczania webhooków stosowane przez globalnych dostawców płatności (Stripe, PayPal, PayU, Adyen), zapobiegające trzem kluczowym wektorom ataku: podsłuchowi i manipulacji treścią (Data Tampering), atakom powtórzeniowym (Replay Attacks) oraz atakom czasowym na weryfikację skrótu (Timing Attacks / Side-Channel Attacks).

W części praktycznej studenci implementują w Pythonie mikroserwis nadawcy powiadomień webhook oraz serwer odbiorcy (bramkę płatności). Opracowują nagłówek X-Signature zawierający czas wygenerowania t oraz podpis HMAC wyliczony z konkatenacji czasu i ciała żądania JSON: HMAC(K, t + '.' + payload). Studenci implementują okno tolerancji czasowej (np. max 300 sekund) chroniące przed atakami powtórzeniowymi, a do weryfikacji sygnatury stosują bezpieczną funkcję hmac.compare_digest(), eliminującą wyciek informacji o zgodności prefiksów skrótu charakterystyczny dla standardowego operatora porównania znak po znaku (==).

Platforma FinTech PayFast obsługuje bramki płatności dla sklepów internetowych. Po sfinalizowaniu płatności przez klienta serwer PayFast wysyła powiadomienie HTTP POST (Webhook) do sklepu internetowego z informacją o statusie transakcji (np. status: PAID, amount: 2500.00 PLN). Na podstawie tego powiadomienia sklep automatycznie realizuje zamówienie i wysyła towar do klienta.

W sklepie z elektroniką zaimplementowano prostą weryfikację podpisu HMAC przekazywanego w nagłówku. Jednakże programista sklepu użył standardowego operatora porównania ciągów znaków (if received_sig == calculated_sig) oraz nie zawarł w podpisie znacznika czasu (timestamp).

Przestępcy przeprowadzili dwa równoległe ataki: po pierwsze, przechwycili legalny pakiet webhooka potwierdzający zakup taniego kabla USB za 10 zł i przesłali go ponownie 50 razy (Replay Attack), doprowadzając do wielokrotnego zaliczenia wpłaty w systemie sklepowym. Po drugie, wykorzystując precyzyjny pomiar czasu odpowiedzi serwera (ataki czasowe / timing attacks), byli w stanie bajt po bajcie odtworzyć prawidłową sygnaturę HMAC dla sfałszowanej transakcji zakupu laptopa za 15 000 zł.

Sklep poniósł straty w wysokości 250 000 zł zanim błąd został zauważony przez dział księgowości. Sprawa trafiła do prokuratury, a audyt bezpieczeństwa wymusił natychmiastowe zaimplementowanie standardu Stripe Webhook Signatures z ochroną antystampingową i weryfikacją w stałym czasie.

Zespół laboratoryjny wciela się w inżynierów bezpieczeństwa integracji płatności. Zadaniem studentów jest zbudowanie bezpiecznego klienta i serwera webhooków, zaimplementowanie generowania nagłówka podpisu z sygnaturą czasową, przetestowanie podatności standardowego operatora porównania na atak czasowy, wdrożenie hmac.compare_digest() oraz zabezpieczenie przed replay attack z użyciem pamięci podręcznej nonce/timestamp.

• Środowisko Python 3 z bibliotekami requests, flask / fastapi, hmac, hashlib, time
• Narzędzie cURL do wysyłania testowych zapytań webhook z nagłówkami sygnatur
• Skrypt pomiarowy badający różnice czasowe weryfikacji sygnatury (timing attack simulator)
• Narzędzie Wireshark / mitmproxy do przechwytywania i powtarzania zapytań

1. Zaprojektowanie schematu nagłówka podpisu webhooka: X-Signature: t=1727500000,v1=52571868e30e...
2. Zdefiniowanie algorytmu podpisu: signed_payload = f'{timestamp}.{raw_json_body}'.
3. Implementacja nadawcy powiadomień webhook w Pythonie podpisującego payload kluczem współdzielonym webhook_secret.
4. Implementacja odbiorcy webhooków (Flask/FastAPI) weryfikującego przychodzące żądania.
5. Symulacja podatności Replay Attack: przechwycenie poprawnego żądania cURL i ponowne jego wysłanie po 15 minutach.
6. Wdrożenie ochrony przed atakami powtórzeniowymi: odrzucanie żądań, w których abs(current_time - t) > 300 sekund.
7. Dodanie mechanizmu idempotency key / nonce cache zapobiegającego powtórzeniu w dozwolonym 5-minutowym oknie.
8. Analiza podatności Timing Attack: wyjaśnienie, jak operator `==` w językach programowania przerywa porównywanie na pierwszym niezgodnym bajcie (Early Exit).
9. Napisanie skryptu symulującego atak czasowy: pomiar czasu odpowiedzi serwera dla sygnatur ze zgodnym pierwszym bajtem vs całkowicie błędnych.
10. Zastąpienie podatnego porównania bezpieczną funkcją kryptograficzną hmac.compare_digest().
11. Zbadanie kodu źródłowego hmac.compare_digest() w CPythonie i wykazanie wykonania operacji w stałym czasie O(n).
12. Przetestowanie odporności systemu na manipulację treścią payloadu JSON (np. zmiana statusu z PENDING na PAID) – natychmiastowe odrzucenie z kodem 401 Unauthorized.
13. Zbadanie praktyk rotacji kluczy webhook_secret bez przerw w działaniu serwisu (obsługa wielu aktywnych sygnatur v1 w nagłówku).
14. Analiza zgodności z oficjalną dokumentacją Stripe API oraz wytycznymi OWASP API Security Top 10 (API8: Lack of Protection from Automated Threats).
15. Przeprowadzenie testów obciążeniowych bezpiecznego endpointu webhooka.
16. Opracowanie kompleksowego modułu weryfikatora jako biblioteki dla partnerów integracyjnych.
17. Skompilowanie raportu ze zrzutami kodu, wynikami testów czasowych i rekomendacjami wdrożeniowymi.

Standardowy operator porównania ciągów znaków (`str1 == str2`) porównuje znaki sekwencyjnie i przerywa działanie w momencie napotkania pierwszej niezgodności (tzw. short-circuit evaluation). W środowiskach sieciowych o niskich opóźnieniach (lub przy dużej liczbie próbek) napastnik może mierzyć czas odpowiedzi serwera i odgadywać kolejne bajty sygnatury HMAC. Funkcja `hmac.compare_digest()` porównuje zawsze wszystkie bajty, eliminując wyciek informacji kanałem bocznym.

Poniżej przedstawiono bezpieczną implementację weryfikacji powiadomienia Webhook:

Przykładowe wysłanie poprawnego żądania webhook za pomocą cURL:

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

1. Wektory ataków na niechronione webhooki i asynchroniczne punkty końcowe API (podrabianie zdarzeń płatniczych, podsłuch, ataki powtórzeniowe).
2. Generowanie kryptograficznej sygnatury powiadomienia webhooka za pomocą HMAC-SHA256 z użyciem dedykowanego klucza podpisywania.
3. Zagrożenie atakami czasowymi (Timing Attacks) podczas porównywania ciągów skrótów za pomocą standardowych operatorów porównania w językach programowania.
4. Implementacja weryfikacji w stałym czasie (Constant-Time String Comparison) w celu eliminacji wycieków informacji przez kanały boczne.
5. Ochrona przed atakami powtórzeniowymi poprzez dołączanie unikalnego znacznika czasu do podpisywanego ładunku oraz odrzucanie przeterminowanych żądań.
6. Opracowanie kompleksowej procedury bezpiecznej rotacji kluczy podpisujących webhooki bez wprowadzania przerw technicznych w systemie produkcyjnym.

Przykładowe wnioski (wzór do sprawozdania): Zaprojektowanie bezpiecznego interfejsu powiadomień webhook w oparciu o podpis HMAC-SHA256 zapewniło całkowitą ochronę systemu finansowego przed wstrzykiwaniem sfałszowanych potwierdzeń transakcji. Kluczowym elementem implementacji po stronie odbiorcy okazało się zastosowanie funkcji porównującej sygnatury w stałym czasie, co wyeliminowało ryzyko odgadnięcia poprawnego skrótu bajt po bajcie za pomocą subtelnych anomalii czasowych odpowiedzi serwera. Wzbogacenie podpisywanego ładunku o znacznik czasu UTC oraz rygorystyczna weryfikacja dopuszczalnego okna opóźnienia skutecznie udaremniły próby ponownego wysłania przechwyconych żądań. Dodatkowo wdrożenie mechanizmu obsługi dwóch równoległych kluczy sekretnych pozwoliło na bezprzestojową rotację poświadczeń bez zakłócania przetwarzania bieżących płatności. Opracowany moduł w pełni odpowiada najlepszym praktykom inżynierskim stosowanym przez globalnych operatorów płatności takich jak Stripe czy PayPal.

Kon3 Drzewa skrótów (Merkle Trees) i weryfikacja integralności wielkich zbiorów danych. Kon2 Dowody kryptograficzne (Merkle Proofs / Audit Paths) o złożoności logarytmicznej O(log n).

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie struktury binarnego drzewa skrótów (Merkle Tree, Ralph Merkle 1979) oraz dowodów kryptograficznych (Merkle Proofs / Audit Paths) stosowanych we współczesnych rozproszonych systemach plików (IPFS, ZFS, btrfs), systemach kontroli wersji (Git), technologiach rozproszonych rejestrów (Blockchain) oraz w logach przejrzystości certyfikatów (Certificate Transparency, RFC 6962). Studenci badają, w jaki sposób drzewo Merkle'a pozwala na wydajną weryfikację integralności dowolnego fragmentu zbioru danych o złożoności O(log n) bez konieczności pobierania całego archiwum.

W części praktycznej studenci implementują w języku Python pełną strukturę drzewa Merkle'a dla rozproszonego magazynu plików chmurowych (np. klastra archiwizującego miliony faktur elektronicznych). Implementują haszowanie liści SHA-256 z prefiksowaniem zapobiegającym atakom kolizji drugiego rzędu (Second Preimage Attack / Domain Separation), budują korzeń drzewa (Merkle Root Hash), generują ścieżkę audytową (Merkle Proof) dla wybranego pliku oraz weryfikują autentyczność pojedynczego dokumentu za pomocą zaledwie kilku haszy pośrednich. Następnie symulują uszkodzenie lub modyfikację jednego pliku na serwerze i natychmiastowo lokalizują naruszenie integralności.

Krajowe Centrum Archiwizacji Dokumentacji Cyfrowej (KCADC) przechowuje ponad 50 milionów zdigitalizowanych dokumentów urzędowych, aktów notarialnych i dokumentacji medycznej w rozproszonym klastrze pamięci masowej (Object Storage). Każdego dnia instytucje państwowe, sądy i obywatele składają tysiące zapytań o weryfikację autentyczności pojedynczych dokumentów.

W dotychczasowym rozwiązaniu weryfikacja nienaruszalności zbioru wymagała przeliczania całościowej sumy kontrolnej lub utrzymywania gigantycznej bazy płaskich sum SHA-256. Przy awarii pojedynczego dysku lub konieczności udowodnienia autentyczności wyciągu bankowego przed sądem strona weryfikująca musiała pobierać całą wielogigabajtową paczkę archiwalną.

Dodatkowo podczas audytu okazało się, że doszło do cichego uszkodzenia danych (bit rot) na kilku macierzach dyskowych, co unieważniło globalne sumy kontrolne i wywołało paraliż weryfikacji setek tysięcy dokumentów.

Główny architekt systemów zadecydował o wdrożeniu hierarchicznego drzewa skrótów Merkle'a, w którym każdy dokument stanowi liść drzewa, a węzły wyższych poziomów agregują skróty par węzłów potomnych. Taka struktura pozwala udowodnić nienaruszalność dowolnego pojedynczego dokumentu za pomocą logarytmicznie krótkiego dowodu (kilkanaście skrótów 32-bajtowych), a publikacja samego korzenia (Merkle Root) w publicznym rejestrze gwarantuje niezmienność całego archiwum.

Zespół laboratoryjny przyjmuje zadanie zaprojektowania i przetestowania silnika weryfikacji integralności KCADC. Studenci implementują w Pythonie konstrukcję drzewa Merkle'a z separacją domenową (\x00 dla liści, \x01 dla węzłów wewnętrznych), generują dowód kryptograficzny dla wybranej faktury, weryfikują go w odseparowanym środowisku klienckim oraz demonstrują natychmiastowe wykrycie manipulacji plikiem w archiwum.

• Środowisko Python 3 z bibliotekami hashlib, math, json
• Narzędzia GNU coreutils (sha256sum, split, cat)
• Narzędzie Git (do analizy wewnętrznej struktury obiektów i drzew Merkle w katalogu .git)
• Skrypt wizualizujący strukturę drzewa Merkle w konsoli (ASCII tree renderer)

1. Zapoznanie się z definicją binarnego drzewa skrótów, pojęciem liści (Leaves), węzłów wewnętrznych (Internal Nodes) oraz korzenia (Merkle Root).
2. Zrozumienie podatności na Second Preimage Attack w naiwnych implementacjach drzew Merkle i zasady separacji domenowej (RFC 6962: prefix 0x00 dla liści, 0x01 dla węzłów).
3. Utworzenie zestawu 8 plików testowych (faktury od dok1.pdf do dok8.pdf).
4. Zaimplementowanie w Pythonie klasy MerkleTree z metodami obliczania skrótów liści: H_leaf = SHA256(0x00 || data).
5. Zaimplementowanie algorytmu parowania węzłów i budowania kolejnych poziomów drzewa: H_parent = SHA256(0x01 || H_left || H_right).
6. Obsługa nieparzystej liczby liści (duplikacja ostatniego węzła lub zbalansowane drzewo).
7. Wygenerowanie i wyświetlenie głównego skrótu korzenia (Merkle Root Hash) dla całego zestawu 8 dokumentów.
8. Zaimplementowanie metody generowania ścieżki audytowej get_proof(leaf_index): zwrócenie listy haszy rodzeństwa (Sibling Hashes) wraz z kierunkiem (lewy/prawy).
9. Wygenerowanie dowodu Merkle Proof dla pliku dok3.pdf (oczekiwana długość dowodu: dokładnie 3 hasze dla 8 liści, ponieważ log2(8) = 3).
10. Napisanie niezależnego weryfikatora verify_proof(leaf_data, proof, root_hash): zrekonstruowanie korzenia wyłącznie w oparciu o treść jednego pliku i dowód Merkle.
11. Pomyślne zweryfikowanie autentyczności pliku dok3.pdf przy użyciu Merkle Root.
12. Symulacja uszkodzenia pliku dok3.pdf na serwerze (zmiana jednego bajtu) i uruchomienie weryfikatora (natychmiastowe odrzucenie dowodu).
13. Symulacja podmiany pliku dok5.pdf i wykazanie, że dowód dla dok3.pdf pozostaje niezmieniony, a korzeń ulega zmianie.
14. Zbadanie praktycznego zastosowania drzew Merkle'a w systemie kontroli wersji Git (obiekty commit, tree, blob).
15. Analiza złożoności obliczeniowej i pamięciowej: wykazanie, że dla 1 000 000 dokumentów dowód wymaga przesłania zaledwie 20 haszy (ok. 640 bajtów).
16. Zaprojektowanie architektury publicznego rejestru przejrzystości (Transparency Log) opartego na publikacji dziennych korzeni Merkle.
17. Sformułowanie wniosków końcowych w sprawozdaniu z dołączeniem diagramu drzewa i pełnego kodu weryfikatora.

W drzewie Merkle'a o N liściach do udowodnienia, że konkretny dokument należy do zbioru o znanym korzeniu (Merkle Root), potrzebujemy jedynie log2(N) skrótów pośrednich. Dla miliona dokumentów wystarczy zaledwie 20 skrótów! Klient nie musi pobierać pozostałych 999 999 plików, aby mieć 100% kryptograficzną pewność co do autentyczności swojego dokumentu.

Poniżej znajduje się implementacja weryfikacji dowodu Merkle w języku Python zgodna z RFC 6962:

Wynik weryfikacji w terminalu Linux:

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

1. Architektura binarnego drzewa skrótów (Merkle Tree): liście jako skróty bloków danych, węzły pośrednie oraz unikalny korzeń Merkle Root.
2. Skalowalność weryfikacji integralności wielkich zbiorów danych: natychmiastowe wykrycie modyfikacji dowolnego rekordu poprzez porównanie 32-bajtowego korzenia drzewa.
3. Konstrukcja dowodów kryptograficznych (Merkle Proofs / Audit Paths): dowodzenie przynależności elementu do zbioru w logarytmicznej złożoności O(log N).
4. Praktyczne zastosowania drzew skrótów: protokoły rejestrów Certificate Transparency (RFC 6962), systemy kontroli wersji Git oraz technologie blockchain.
5. Implementacja zabezpieczeń przed atakami na strukturę drzewa: rozróżnianie prefiksów domenowych dla liści (0x00) i węzłów wewnętrznych (0x01).
6. Konstrukcja i weryfikacja dowodów spójności (Consistency Proofs) poświadczających, że nowsza wersja rejestru stanowi wyłącznie rozszerzenie wersji wcześniejszej.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna implementacja binarnego drzewa Merkle'a w języku Python potwierdziła wybitną efektywność tej struktury w weryfikacji integralności wielkich zbiorów danych. Obliczenie unikalnego korzenia Merkle Root pozwoliło na poświadczenie nienaruszalności miliona rekordów bazy danych za pomocą zaledwie jednego 32-bajtowego skrótu kryptograficznego SHA-256. Generowanie ścieżki audytowej wykazało, że udowodnienie obecności pojedynczego rekordu w zbiorze wymaga przesłania jedynie około dwudziestu skrótów pomocniczych, co stanowi doskonałe potwierdzenie logarytmicznej złożoności O(log N). Wprowadzenie jednobajtowych prefiksów domenowych dla liści i węzłów wewnętrznych skutecznie zabezpieczyło strukturę przed atakami drugiego przeciwobrazu polegającymi na preparowaniu fałszywych gałęzi. Zaimplementowany mechanizm stanowi wierne odzwierciedlenie technologii leżącej u podstaw globalnego systemu nadzoru nad certyfikatami Certificate Transparency oraz rozproszonych łańcuchów bloków.