Laboratorium 6

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Podpisy cyfrowe i funkcje skrótu. Efekty uczenia się: W3, U1, U2, U3, K1, K2.

Głównym celem zadania jest praktyczne zbadanie i weryfikacja fundamentalnych cech kryptograficznych funkcji skrótu: determinizmu, stałej długości wyjścia (digestu) oraz zjawiska efektu lawinowego (Avalanche Effect). Studenci poznają zasady działania algorytmu SHA-256 z rodziny SHA-2 w wierszu poleceń systemu Linux.

W toku ćwiczenia zespół bada zachowanie skrótu kryptograficznego w odpowiedzi na modyfikację pojedynczego bitu w danych wejściowych, mierzy stopień rozproszenia bitów (kryterium SAC – Strict Avalanche Criterion) oraz porównuje skrót SHA-256 dla danych o różnej wielkości (od 1 bajta do kilkunastu megabajtów). Studenci weryfikują właściwości jednokierunkowości (odporności na odzyskanie tekstu jawnego ze skrótu). Wynikiem prac jest raport analityczny oraz skrypty badawcze.

Wydawnictwo Cyfrowe „Edukacja Polska” Sp. z o.o. w Warszawie przygotowuje do publikacji elektroniczne wydania podręczników akademickich, skryptów laboratoryjnych oraz umowy autorskie z twórcami. Redakcja boryka się z problemem weryfikacji, czy recenzowane pliki tekstowe i umowy nie zostały przypadkowo zmodyfikowane w procesie redakcyjnym lub przez pracowników zewnętrznych.

Wielu młodszych pracowników nie rozumiało, dlaczego po zmianie pojedynczego znaku przestankowego lub dodaniu jednej spacji w wielostronicowym dokumencie, wyliczona suma kontrolna SHA-256 staje się całkowicie odmienna i nie wykazuje żadnego podobieństwa do sumy pierwotnej. Panowało błędne przekonanie, że drobna zmiana powinna powodować jedynie drobną zmianę skrótu.

Kierownik działu IT zlecił zespołowi studentów przeprowadzenie kontrolowanego eksperymentu dydaktyczno-audytorskiego. Zadanie polega na formalnym wykazaniu determinizmu funkcji skrótu (te same dane wejściowe zawsze dają ten sam skrót), udowodnieniu stałości rozmiaru wyjścia niezależnie od objętości wejścia oraz precyzyjnym zmierzeniu efektu lawinowego.

Studenci tworzą parę plików umów różniących się dokładnie jednym bitem, obliczają skróty SHA-256, konwertują skróty do postaci binarnej i zliczają liczbę bitów, które uległy zmianie, weryfikując zgodność z teoretycznym prawdopodobieństwem wynoszącym 50%.

W podsumowaniu zespół wyjaśnia, dlaczego efekt lawinowy jest kluczowy dla uniemożliwienia kryptoanalizy różnicowej oraz formułuje zalecenia dotyczące stosowania sum SHA-256 w kontroli wersji publikacji wydawniczych.

1. Przygotowanie katalogu roboczego na stacji roboczej Linux: 'mkdir -p ~/lab6-lawina && cd ~/lab6-lawina'.
2. Weryfikacja dostępności narzędzi 'sha256sum', 'xxd', 'python3' oraz 'wc' poleceniem 'which sha256sum xxd python3'.
3. Utworzenie pliku źródłowego 'umowa_v1.txt': 'echo -n "Wynagrodzenie autorskie wynosi 5000 PLN." > umowa_v1.txt'.
4. Utworzenie pliku zmodyfikowanego 'umowa_v2.txt' ze zmianą jednej cyfry: 'echo -n "Wynagrodzenie autorskie wynosi 5001 PLN." > umowa_v2.txt'.
5. Porównanie plików źródłowych za pomocą narzędzia 'diff umowa_v1.txt umowa_v2.txt' i odnotowanie minimalnej różnicy.
6. Zbadanie binarnej różnicy pomiędzy znakami '0' (ASCII 0x30, binarnie 00110000) a '1' (ASCII 0x31, binarnie 00110001) – dokładnie 1 bit różnicy na wejściu.
7. Obliczenie skrótu SHA-256 dla pliku v1: 'sha256sum umowa_v1.txt'.
8. Obliczenie skrótu SHA-256 dla pliku v2: 'sha256sum umowa_v2.txt'.
9. Odnotowanie, że skróty heksadecymalne nie mają ze sobą żadnych widocznych zbieżności.
10. Ponowne obliczenie skrótu dla 'umowa_v1.txt' i potwierdzenie identycznego wyniku (dowód determinizmu).
11. Utworzenie prostego skryptu Python 'zlicz_lawine.py' porównującego bity obu 256-bitowych skrótów.
12. Uruchomienie skryptu: 'python3 zlicz_lawine.py umowa_v1.txt umowa_v2.txt'.
13. Odczytanie wyniku pomiaru: odnotowanie liczby zmienionych bitów (np. 126 bitów na 256, co stanowi 49.22% różnicy).
14. Potwierdzenie zgodności wyniku z kryterium SAC (Strict Avalanche Criterion), które wymaga, aby każdy bit wyjściowy zmieniał się z prawdopodobieństwem bliskim 50%.
15. Przygotowanie pliku pustego 'pusty.txt' (0 bajtów) oraz dużego pliku binarnego 'duzy.iso' (10 MB): 'touch pusty.txt && dd if=/dev/urandom of=duzy.iso bs=1M count=10'.
16. Obliczenie skrótów SHA-256 dla pliku pustego oraz pliku 10 MB.
17. Weryfikacja właściwości stałej długości wyjścia: oba skróty mają dokładnie 256 bitów (32 bajty / 64 znaki heksadecymalne).
18. Przetestowanie właściwości jednokierunkowości: próba odgadnięcia tekstu jawnego dla znanego skrótu i wykazanie konieczności przeszukiwania przestrzeni wejściowej.
19. Sporządzenie tabelarycznego zestawienia badanych właściwości (determinizm, stała długość, efekt lawinowy) wraz z listingami wyników.
20. Sformułowanie wniosków końcowych do referatu laboratoryjnego dotyczących roli funkcji SHA-256 w kryptografii.

Efekt lawinowy (Avalanche Effect) jest fundamentalną właściwością silnych kryptograficznie funkcji skrótu oraz szyfrów blokowych. Został zdefiniowany przez Horsta Feistela jako cecha polegająca na tym, że zmiana pojedynczego bitu na wejściu wywołuje drastyczną, lawinową zmianę w wewnętrznych rundach algorytmu, skutkującą zmianą około połowy bitów na wyjściu.

Gdyby funkcja skrótu nie posiadała silnego efektu lawinowego, analityk kryptograficzny mógłby na podstawie niewielkich różnic w skrócie wyciągać wnioski o podobieństwie tekstów wejściowych (kryptoanaliza różnicowa). Dzięki efektowi lawinowemu skrót zachowuje się jak doskonała zmienna pseudolosowa.

Poniżej przedstawiono przykładowy widok konsoli serwera Linux podczas badania efektu lawinowego pomiędzy plikami różniącymi się jednym bitem:

Do szybkiej wizualizacji różnic heksadecymalnych w środowisku graficznym można wykorzystać darmowe narzędzie webowe CyberChef, wprowadzając moduł 'Generate all hashes' oraz 'Difference'.

Pamiętaj, że determinizm funkcji skrótu jest cechą bezwzględną: ta sama funkcja matematyczna zastosowana do tych samych danych na dowolnym komputerze na świecie zawsze zwróci dokładnie ten sam ciąg bajtów.

1. Zrozumienie i praktyczne potwierdzenie determinizmu oraz stałej długości wyjścia funkcji SHA-256.
2. Wykazanie matematycznej natury efektu lawinowego i jego znaczenia w uniemożliwieniu kryptoanalizy różnicowej.
3. Potwierdzenie zgodności działania algorytmu z kryterium Strict Avalanche Criterion (~50% zmienionych bitów).
4. Zrozumienie właściwości jednokierunkowości (Pre-image Resistance) funkcji skrótu.
5. Wpływ minimalnych zmian w plikach źródłowych na całkowitą zmianę skrótów weryfikacyjnych.
6. Rekomendacje dotyczące wykorzystania funkcji skrótu do wykrywania przypadkowych i celowych modyfikacji dokumentacji.

Przykładowe wnioski (wzór do sprawozdania): Przeprowadzony eksperyment laboratoryjny potwierdził fundamentalne właściwości matematyczne funkcji SHA-256, wykazując jej bezwzględny determinizm oraz stałą długość skrótu niezależnie od rozmiaru wejścia. Pomiar liczby zmienionych bitów przy modyfikacji pojedynczego znaku w tekście umowy wykazał zmianę ponad 50% bitów wyjściowych, potwierdzając spełnienie rygorystycznego kryterium Strict Avalanche Criterion (SAC). Wykazano, że tak silny efekt lawinowy skutecznie dezinformuje potencjalnego analityka, uniemożliwiając prowadzenie kryptoanalizy różnicowej na podstawie podobieństwa generowanych skrótów. Praktyczne próby odgadnięcia tekstu jawnego dla znanego skrótu dowiodły właściwości jednokierunkowości (odporności na odwrócenie) algorytmu. Wyniki ćwiczenia uzasadniają powszechne stosowanie funkcji SHA-256 jako nienaruszalnego cyfrowego odcisku palca plików w audycie i archiwizacji cyfrowej.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Podpisy cyfrowe i funkcje skrótu. Efekty uczenia się: W3, U1, U3, K1, K2.

Celem ćwiczenia jest praktyczne zrozumienie pojęcia kolizji kryptograficznej (Collision Vulnerability) oraz uświadomienie studentom przyczyn całkowitej dyskwalifikacji i wycofania algorytmu MD5 ze współczesnych zastosowań bezpieczeństwa. Studenci dowiadują się, dlaczego wystąpienie kolizji podważa zaufanie do podpisów cyfrowych i integralności danych.

W toku laboratorium zespół analizuje historyczne ataki na algorytm MD5 (prace Wang, Stevensa oraz narzędzie fastcoll), bada gotowe, spreparowane pary dokumentów prawnych o identycznej sumie MD5, lecz odmiennej treści, oraz weryfikuje ich sumy za pomocą nowoczesnych funkcji z rodziny SHA-2 (SHA-256). Studenci opracowują analizę ryzyka prawnego i technicznego dla instytucji nadal stosujących MD5. Zadanie kończy się raportem audytorskim.

Kancelaria Komornicza przy Sądzie Rejonowym w Płocku korzysta z archiwalnego systemu elektronicznego obiegu dokumentów egzekucyjnych i protokołów licytacji komorniczych. System ten został wdrożony w 2004 roku i do weryfikacji integralności skanów protokołów oraz oświadczeń dłużników nadal stosuje 128-bitowe sumy kontrolne MD5.

Nowo zatrudniony informator prawny zwrócił uwagę komornika na fakt, że algorytm MD5 został oficjalnie skompromitowany kryptograficznie już w 2004 roku, a współcześnie wygenerowanie dwóch różnych plików o identycznym skrócie MD5 zajmuje zaledwie kilkadziesiąt sekund na zwykłym laptopie za pomocą ogólnodostępnych narzędzi (atak kolizyjny).

Oznacza to, że nieuczciwa strona postępowania egzekucyjnego mogłaby przygotować dwa dokumenty o identycznej sumie MD5: jeden o treści 'Zgoda na spłatę długu w ratach 500 PLN' (podpisany przez wierzyciela), a drugi o treści 'Umorzenie całości zadłużenia 500 000 PLN'. Po uzyskaniu podpisu pod pierwszym dokumentem sprawca mógłby podmienić treść na drugi plik, a system archiwalny uznałby dokument za w pełni autentyczny z uwagi na zgodność sumy MD5.

Komornik zlecił zespołowi studentów przeprowadzenie demonstracji podatności na kolizję w warunkach laboratoryjnych. Studenci badają parę plików binarnych wygenerowanych za pomocą ataku kolizyjnego, sprawdzają ich sumy MD5 (wykazując identyczność) oraz weryfikują je sumami SHA-256 (wykazując natychmiastowe wykrycie różnicy).

W podsumowaniu zespół formułuje bezwzględne zalecenie natychmiastowej migracji wszystkich baz kancelarii do standardu SHA-256 lub SHA-3 oraz analizuje odpowiedzialność odszkodowawczą w przypadku fałszerstwa dokumentów.

1. Przygotowanie katalogu roboczego na stacji Linux: 'mkdir -p ~/lab6-md5-collision && cd ~/lab6-md5-collision'.
2. Weryfikacja dostępności narzędzi 'md5sum', 'sha256sum', 'xxd' oraz 'cmp'.
3. Pobranie lub wygenerowanie demonstracyjnej pary plików kolizyjnych MD5 (pliki 'umowa_A.bin' oraz 'umowa_B.bin').
4. Alternatywne utworzenie próbki danych z wykorzystaniem narzędzi edukacyjnych lub zestawu testowego kolizji Stevensa.
5. Obliczenie sumy kontrolnej MD5 dla pliku 'umowa_A.bin': 'md5sum umowa_A.bin'.
6. Obliczenie sumy kontrolnej MD5 dla pliku 'umowa_B.bin': 'md5sum umowa_B.bin'.
7. Zarejestrowanie krytycznej obserwacji: oba pliki posiadają dokładnie identyczny 128-bitowy skrót MD5 (np. '79054025255fb1a26e4bc422aef54eb4').
8. Porównanie zawartości obu plików za pomocą narzędzia binarnego: 'cmp -l umowa_A.bin umowa_B.bin | wc -l'.
9. Wykazanie, że pliki fizycznie różnią się na określonych pozycjach bajtowych pomimo identycznego skrótu MD5.
10. Zbadanie różnic w edytorze heksadecymalnym za pomocą xxd: 'xxd umowa_A.bin > a.hex' oraz 'xxd umowa_B.bin > b.hex' i 'diff -u a.hex b.hex'.
11. Obliczenie sum kontrolnych obu plików za pomocą nowoczesnego algorytmu SHA-256: 'sha256sum umowa_A.bin umowa_B.bin'.
12. Odnotowanie, że skróty SHA-256 są całkowicie różne i nie wykazują żadnej kolizji.
13. Obliczenie sum kontrolnych za pomocą algorytmu SHA-512 lub SHA-3 i potwierdzenie braku kolizji.
14. Przeanalizowanie różnicy pomiędzy atakiem na kolizję (Collision Attack – znalezienie dowolnych x i y takich, że H(x)=H(y)) a atakiem na przeciwobraz (Pre-image Attack – znalezienie x dla zadanego y).
15. Zbadanie historii incydentu wirusa Flame (2012 r.), w którym napastnicy użyli kolizji MD5 do podrobienia certyfikatu podpisu cyfrowego Microsoft Windows Update.
16. Sprawdzenie obecności algorytmu MD5 w procedurach kancelarii komorniczej i identyfikacja systemów podatnych na fałszerstwo.
17. Opracowanie planu migracji baz danych do standardu SHA-256 z jednoczesnym przeliczeniem sum kontrolnych dla dokumentów archiwalnych.
18. Przetestowanie polecenia weryfikacji integralności w PowerShell: 'Get-FileHash -Algorithm MD5' vs 'Get-FileHash -Algorithm SHA256'.
19. Sporządzenie tabelarycznego zestawienia odporności na kolizje dla MD5 ($2^{64} \rightarrow 2^{16}$ operacji praktycznych), SHA-1 ($2^{63}$) oraz SHA-256 ($2^{128}$).
20. Sformułowanie wniosków końcowych do referatu audytorskiego ze szczególnym uwzględnieniem skutków procesowych podważenia integralności dowodów.

Kolizja kryptograficzna zachodzi wtedy, gdy dwa różne ciągi danych wejściowych x oraz y (gdzie x != y) dają w wyniku dokładnie taki sam skrót: H(x) = H(y). Teoretycznie, ponieważ zbiór możliwych danych wejściowych jest nieskończony, a zbiór wartości skrótu jest skończony (dla MD5 wynosi $2^{128}$), kolizje muszą istnieć (zasada szufladkowa Dirichleta). Jednak w bezpiecznej funkcji skrótu znalezienie choćby jednej kolizji powinno być obliczeniowo niewykonalne.

W 2004 roku zespół prof. Xiaoyun Wang zaprezentował matematyczną metodę kryptoanalizy różnicowej, która drastycznie obniżyła złożoność znajdowania kolizji w MD5. Współczesne narzędzia (takie jak fastcoll Marca Stevensa) potrafią wygenerować parę kolizyjnych bloków w czasie ułamka sekundy na zwykłym smartfonie lub procesorze PC.

Poniżej przedstawiono przykładowy widok konsoli serwera Linux demonstrujący wystąpienie kolizji MD5 dla dwóch różnych plików oraz jej wykrycie przez SHA-256:

W praktyce sądowej i komorniczej posłużenie się dokumentem, którego integralność poświadczono wyłącznie sumą MD5, stwarza ogromne ryzyko prawne. Druga strona sporu może z łatwością powołać biegłego ds. informatyki śledczej, który wykaże podatność na kolizję i podważy autentyczność dowodu elektronicznego.

Wszystkie oficjalne zalecenia instytucji normalizacyjnych (NIST SP 800-131A, BSI, ENISA, CSIRT NASK) kategorycznie zakazują stosowania MD5 w podpisach cyfrowych, certyfikatach X.509 oraz weryfikacji integralności oprogramowania.

1. Zrozumienie zjawiska kolizji kryptograficznej i matematycznych przyczyn kompromitacji algorytmu MD5.
2. Wykazanie niebezpieczeństwa wynikającego ze stosowania MD5 w procedurach prawnych i kancelaryjnych.
3. Rola ataków kolizyjnych w podważaniu zaufania do podpisów cyfrowych (przypadek wirusa Flame).
4. Odporność rodziny SHA-2 (SHA-256, SHA-512) na współczesne techniki kryptoanalizy kolizyjnej.
5. Analiza prawna ważności dowodów elektronicznych w świetle przepisów Kodeksu postępowania cywilnego.
6. Wytyczne dotyczące procedur migracji archiwów danych do standardu SHA-256 w instytucjach zaufania publicznego.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna demonstracja wygenerowania dwóch odmiennych plików o identycznym skrócie MD5 za pomocą narzędzia fastcoll unaoczniła całkowitą kompromitację tego algorytmu w zastosowaniach bezpieczeństwa. Wykazano, że podatność na kolizje pozwala na sfabrykowanie dokumentu prawnego lub certyfikatu o złośliwej zawartości posiadającego identyczny skrót jak dokument w pełni autentyczny. Badanie potwierdziło, że pojęcie bezpieczeństwa funkcji skrótu ma charakter dynamiczny i algorytmy uznawane za silne w przeszłości stają się bezużyteczne wraz ze wzrostem mocy obliczeniowej i rozwojem kryptoanalizy. Zastosowanie algorytmu SHA-256 do tych samych plików kolizyjnych MD5 zwróciło całkowicie odmienne skróty, dowodząc jego pełnej odporności na znane wektory ataków. Ostatecznym wnioskiem inżynierskim jest bezwzględna konieczność wycofania algorytmu MD5 ze wszystkich systemów weryfikacji integralności i podpisów cyfrowych na rzecz rodziny SHA-2 i SHA-3.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Podpisy cyfrowe i funkcje skrótu. Efekty uczenia się: W1, W3, U1, U3, K1, K2.

Głównym celem zadania jest precyzyjne rozróżnienie pomiędzy niekryptograficznymi sumami kontrolnymi (kodami detekcyjnymi błędów transmisji, takimi jak CRC32) a kryptograficznymi funkcjami skrótu (takimi jak SHA-256). Studenci dowiadują się, dlaczego mechanizmy zaprojektowane do wykrywania przypadkowych zakłóceń w kablach sieciowych całkowicie zawodzą w konfrontacji z celowym działaniem człowieka (atakującym).

W toku laboratorium zespół bada matematyczne właściwości wielomianów CRC32 (liniowość, podatność na inwersję), przeprowadza kontrolowany atak manipulacji treścią pliku z jednoczesnym dopasowaniem sumy CRC32 (tzw. CRC Spoofing / Reverse CRC) oraz wykazuje, dlaczego analogiczny atak na funkcję SHA-256 jest obliczeniowo niemożliwy. Studenci analizują architekturę protokołów sieciowych i dyskowych. Wynikiem jest raport audytorski.

Firma Telekomunikacyjna „Net-Serwis” w Kielcach zarządza lokalnymi sieciami dostępowymi oraz serwerami plików FTP/TFTP wykorzystywanymi do dystrybucji aktualizacji oprogramowania układowego (firmware) dla domowych routerów abonenckich i modemów światłowodowych GPON.

W procedurze aktualizacji urządzeń stosowano weryfikację poprawności pobranego pliku za pomocą 32-bitowej sumy kontrolnej CRC32 (Cyclic Redundancy Check). Programiści zakładali, że jeżeli router przed instalacją oprogramowania sprawdzi zgodność sumy CRC32 z wartością zapisaną w nagłówku, to urządzenie jest w 100% chronione przed zainstalowaniem złośliwego oprogramowania.

Audytor bezpieczeństwa teleinformatycznego uświadomił zarządowi, że algorytm CRC32 jest kodem cyklicznym o charakterze czysto liniowym, stworzonym w latach 70. do wykrywania przypadkowych przekłamań bitów na łączach telefonicznych (np. szumów i zakłóceń elektromagnetycznych). Algorytm ten nie posiada żadnych właściwości kryptograficznych – napastnik może zmodyfikować kod firmware (np. dodając tylną furtkę / backdoor), a następnie dopisać na końcu pliku 4 odpowiednio dobrane bajty, aby suma CRC32 zmodyfikowanego pliku była co do bita identyczna z sumą oryginału.

Zespół studentów ma za zadanie przeprowadzić demonstrację ataku CRC Spoofing w środowisku laboratoryjnym: zmodyfikować testowy plik konfiguracyjny, wyliczyć bajty korekcyjne i oszukać weryfikator CRC32, a następnie udowodnić, że weryfikator oparty na funkcji SHA-256 natychmiast wykrywa każde fałszerstwo.

W podsumowaniu studenci formułują wytyczne modernizacji procedur aktualizacji firmware w urządzeniach sieciowych zgodnie z normami bezpieczeństwa telekomunikacyjnego.

1. Przygotowanie środowiska testowego na stacji Linux: 'mkdir -p ~/lab6-crc-vs-sha && cd ~/lab6-crc-vs-sha'.
2. Weryfikacja dostępności narzędzi 'cksum', 'gzip', 'sha256sum', 'xxd', 'python3'.
3. Utworzenie pliku źródłowego firmware 'router_config.bin': 'echo "ROUTER_CONFIG: ALLOW_REMOTE_ADMIN=0; FIREWALL=STRICT;" > router_config.bin'.
4. Obliczenie sumy kontrolnej CRC32 dla pliku źródłowego za pomocą narzędzia python z modułem zlib: 'python3 -c "import zlib; print(hex(zlib.crc32(open('router_config.bin','rb').read()) & 0xffffffff))"'.
5. Odnotowanie referencyjnej wartości CRC32 (np. '0x4f8b2c91').
6. Obliczenie referencyjnego skrótu SHA-256 dla pliku źródłowego: 'sha256sum router_config.bin'.
7. Symulacja ataku cyberprzestępcy: zmiana konfiguracji w pliku na złośliwą 'echo "ROUTER_CONFIG: ALLOW_REMOTE_ADMIN=1; FIREWALL=DISABLED;" > router_config_bad.bin'.
8. Obliczenie sumy CRC32 zmodyfikowanego pliku i potwierdzenie jej zmiany.
9. Uruchomienie skryptu kryptoanalitycznego CRC Spoofing 'dopasuj_crc32.py', który oblicza 4 bajty dopełnienia (padding), jakie należy dokleić na końcu zmodyfikowanego pliku, aby przywrócić pierwotną sumę CRC32.
10. Doklejenie wyliczonych bajtów korekcyjnych do pliku 'router_config_bad.bin'.
11. Ponowne obliczenie sumy CRC32 sfałszowanego pliku: 'python3 -c "import zlib; print(hex(zlib.crc32(open('router_config_bad.bin','rb').read()) & 0xffffffff))"'.
12. Zarejestrowanie sukcesu ataku na CRC32: sfałszowany plik z otwartym firewallem posiada dokładnie taką samą sumę CRC32 jak plik bezpieczny!
13. Przeprowadzenie weryfikacji sfałszowanego pliku za pomocą funkcji SHA-256: 'sha256sum router_config_bad.bin'.
14. Wykazanie, że skrót SHA-256 sfałszowanego pliku uległ całkowitej zmianie i fałszerstwo zostało bezbłędnie zdemaskowane.
15. Przeanalizowanie matematycznej przyczyny podatności CRC32 (liniowość operacji dzielenia wielomianowego w ciele GF(2)).
16. Zbadanie dlaczego w SHA-256 nie da się obliczyć bajtów korekcyjnych (złożoność $2^{256}$ – nieliniowe rundy kompresji).
17. Przetestowanie poleceń weryfikacji sum w systemie Windows: polecenie 'CertUtil -hashfile router_config.bin SHA256'.
18. Porównanie wydajności obliczeniowej CRC32 vs SHA-256 na dużym pliku 100 MB i analiza narzutu obliczeniowego.
19. Opracowanie tabelarycznego porównania: Zastosowanie, Odporność na celową manipulację, Koszt obliczeniowy dla CRC32, MD5, SHA-256 i HMAC.
20. Sformułowanie zaleceń inżynierskich: CRC32 wyłącznie do detekcji uszkodzeń nośników/kabli, SHA-256 z podpisem cyfrowym do kontroli autentyczności.

Suma kontrolna CRC (Cyclic Redundancy Check) jest kodem liniowym opartym na arytmetyce wielomianowej modulo 2. Została zaprojektowana wyłącznie do ochrony przed błędami przypadkowymi (ang. Random Bit Flips) występującymi na skutek szumów termicznych, zaników sygnału w kablu miedzianym czy uszkodzeń sektorów dysku twardego. W tym zadaniu sprawdza się doskonale, ponieważ jest niezwykle szybka i implementowana bezpośrednio w krzemie kart sieciowych (np. Ethernet Frame Check Sequence).

Z punktu widzenia bezpieczeństwa i kryptografii CRC32 ma wartość zerową. Z uwagi na liniowość wielomianu, znalezienie ciągu bajtów, który po dołączeniu do pliku zrównoważy wprowadzoną modyfikację i da pożądaną sumę CRC32, sprowadza się do rozwiązania prostego układu równań liniowych, co komputer wykonuje w ułamku milisekundy.

Poniżej przedstawiono przykładowy widok konsoli serwera demonstrujący oszukanie sumy CRC32 oraz skuteczne wykrycie manipulacji przez algorytm SHA-256:

W sprawozdaniu wyjaśnij dlaczego producenci płyt głównych, routerów czy kart graficznych do podpisywania aktualizacji BIOS/UEFI/Firmware stosują tzw. Secure Boot – mechanizm, w którym plik aktualizacji jest opatrzony podpisem cyfrowym RSA/ECDSA bazującym na skrócie SHA-256.

Pamiętaj, że sam skrót SHA-256 chroni przed modyfikacją pliku tylko wtedy, gdy odbiorca zna autentyczną sumę ze sprawdzonego, zaufanego źródła (np. przez szyfrowaną stronę HTTPS lub podpis cyfrowy).

1. Precyzyjne rozgraniczenie celów projektowych sum detekcyjnych (CRC) i funkcji kryptograficznych (SHA).
2. Praktyczna demonstracja ataku CRC Spoofing wynikająca z liniowości matematycznej algorytmów cyklicznych.
3. Wykazanie krytycznego błędu logicznego polegającego na stosowaniu CRC32 jako mechanizmu bezpieczeństwa IT.
4. Odporność funkcji SHA-256 na próby sterowania wyjściem i dopasowywania bajtów korekcyjnych.
5. Wpływ bezpiecznych procedur aktualizacji firmware (Secure Boot) na eliminację ataków łańcucha dostaw.
6. Rekomendacje dotyczące audytu urządzeń IoT i telekomunikacyjnych pod kątem mechanizmów weryfikacji oprogramowania.

Przykładowe wnioski (wzór do sprawozdania): Eksperyment porównawczy algorytmów CRC32 oraz SHA-256 unaocznił fundamentalną różnicę pomiędzy prostą sumą kontrolną a kryptograficzną funkcją skrótu. Wykazano, że algorytm CRC32 został zaprojektowany wyłącznie do wykrywania przypadkowych błędów transmisji sieciowej i z powodu swojej liniowości matematycznej pozwala na łatwe sfabrykowanie celowych modyfikacji pliku zachowujących tę samą sumę. Z kolei funkcja SHA-256 dzięki właściwościom jednokierunkowości i odporności na kolizje wyklucza możliwość spreparowania danych o z góry narzuconym skrócie przy użyciu realnych zasobów obliczeniowych. Zrozumienie tego podziału zapobiega rażącym błędom architektonicznym polegającym na stosowaniu sum kontrolnych CRC do weryfikacji autentyczności oprogramowania lub transakcji. Prawidłowy dobór algorytmu musi zawsze wynikać z modelu zagrożeń: błędy losowe wymagają kodów detekcyjnych, natomiast ochrona przed celowym atakiem wymaga silnej kryptografii.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Podpisy cyfrowe i funkcje skrótu. Efekty uczenia się: W1, W3, U1, U2, U4, K1, K2.

Celem ćwiczenia jest wykształcenie u studentów nawyków i praktycznych umiejętności weryfikacji autentyczności oraz integralności oprogramowania, bibliotek i obrazów systemów operacyjnych (pliki ISO) pobieranych z sieci Internet. Studenci poznają zasady posługiwania się plikami sum kontrolnych (SHA256SUMS) oraz mechanizmami kryptograficznego poświadczania list sum za pomocą podpisu GPG.

W trakcie laboratorium zespół analizuje zagrożenia związane z atakami na łańcuch dostaw oprogramowania (Supply Chain Attacks) oraz podmianą instalatorów na serwerach lustrzanych (Mirrors). Studenci weryfikują integralność obrazu instalacyjnego za pomocą poleceń Linux CLI (sha256sum -c) oraz narzędzi Windows (CertUtil, PowerShell Get-FileHash), a także badają integralność podpisanego pliku sum kontrolnych. Wynikiem jest procedura wdrożeniowa dla działu IT.

Szpital Specjalistyczny im. dr. Biegańskiego w Częstochowie modernizuje stacje robocze w pracowniach diagnostycznych i gabinetach lekarskich, instalując ujednolicony system operacyjny Linux z dedykowanym pakietem oprogramowania medycznego. Administratorzy pobierają obrazy płyt instalacyjnych ISO (o objętości kilku gigabajtów) z publicznych serwerów lustrzanych (mirrorów) w sieci akademickiej.

W przeszłości odnotowano globalne incydenty bezpieczeństwa (np. atak na dystrybucję Linux Mint w 2016 roku), w których cyberprzestępcy włamali się na serwer pobierania i podmienili oficjalny obraz ISO na wersję zawierającą złośliwe oprogramowanie szpiegujące i tylną furtkę (backdoor). Instalacja takiego systemu w szpitalu doprowadziłaby do natychmiastowego wycieku danych medycznych pacjentów.

Główny Inspektor Bezpieczeństwa Teleinformatycznego szpitala wprowadził bezwzględny zakaz uruchamiania jakichkolwiek instalatorów i obrazów ISO przed ich formalną weryfikacją kryptograficzną. Procedura wymaga sprawdzenia sumy kontrolnej SHA-256 obrazu oraz zweryfikowania podpisu cyfrowego GPG złożonego pod plikiem sum przez twórców dystrybucji.

Zespół studentów wciela się w administratorów systemowych realizujących tę procedurę w środowisku laboratoryjnym. Uczestnicy pobierają testowy obraz instalacyjny, weryfikują jego skrót SHA-256 z plikiem 'SHA256SUMS', importują oficjalny klucz publiczny wydawcy systemu, weryfikują podpis pliku sum 'SHA256SUMS.gpg', a następnie symulują próbę wstrzyknięcia złośliwego kodu do obrazu.

W końcowym etapie prac zespół opracowuje zautomatyzowany skrypt weryfikacyjny w PowerShell i Bash, eliminujący możliwość przypadkowego zainstalowania zmodyfikowanego systemu przez personel techniczny.

1. Przygotowanie katalogu roboczego: 'mkdir -p ~/lab6-iso-verify && cd ~/lab6-iso-verify'.
2. Weryfikacja dostępności narzędzi 'sha256sum', 'gpg', 'curl' oraz 'openssl'.
3. Utworzenie symulowanego pliku obrazu instalacyjnego systemu (np. 50 MB danych binarnych): 'dd if=/dev/urandom of=system_operacyjny.iso bs=1M count=50'.
4. Obliczenie referencyjnej sumy SHA-256 obrazu i zapisanie jej w standardowym formacie pliku dystrybucyjnego: 'sha256sum system_operacyjny.iso > SHA256SUMS'.
5. Zbadanie zawartości pliku 'SHA256SUMS' w edytorze tekstowym (skrót heksadecymalny + dwie spacje + nazwa pliku).
6. Wygenerowanie pary kluczy wydawcy oprogramowania (np. 'Oficjalny Zespol Wydawniczy ') za pomocą GnuPG.
7. Złożenie podpisu odłączonego pod plikiem sum kontrolnych: 'gpg --armor --detach-sign --output SHA256SUMS.gpg SHA256SUMS'.
8. Skompletowanie pakietu dystrybucyjnego: plik obrazu 'system_operacyjny.iso', plik sum 'SHA256SUMS' oraz podpis 'SHA256SUMS.gpg'.
9. Symulacja weryfikacji przez administratora na stacji roboczej Linux.
10. Krok A: weryfikacja autentyczności pliku sum za pomocą klucza publicznego wydawcy: 'gpg --verify SHA256SUMS.gpg SHA256SUMS'.
11. Potwierdzenie komunikatu 'Good signature from Oficjalny Zespol Wydawniczy' (potwierdzenie, że lista sum nie została sfałszowana).
12. Krok B: automatyczna weryfikacja integralności samego pliku ISO za pomocą narzędzia sha256sum: 'sha256sum -c SHA256SUMS'.
13. Potwierdzenie wyniku: 'system_operacyjny.iso: OK'.
14. Symulacja ataku na serwer lustrzany (Supply Chain Attack): cyberprzestępca modyfikuje 1 bajt wewnątrz obrazu ISO (wstrzyknięcie backdoora): 'echo -n "X" | dd of=system_operacyjny.iso bs=1 seek=1048576 count=1 conv=notrunc'.
15. Ponowne uruchomienie automatycznej weryfikacji: 'sha256sum -c SHA256SUMS'.
16. Zarejestrowanie alarmującego błędu: 'system_operacyjny.iso: FAILED / sha256sum: WARNING: 1 computed checksum did NOT match'.
17. Przeprowadzenie analogicznej weryfikacji z poziomu systemu Windows w PowerShell: 'Get-FileHash .\system_operacyjny.iso -Algorithm SHA256'.
18. Weryfikacja w wierszu poleceń Windows za pomocą wbudowanego narzędzia CertUtil: 'certutil -hashfile system_operacyjny.iso SHA256'.
19. Porównanie wyjścia tekstowego z oficjalną sumą kontrolną podaną przez producenta.
20. Opracowanie sprawozdania technicznego z wytycznymi procedur bezpiecznego pobierania oprogramowania w jednostkach ochrony zdrowia.

Weryfikacja integralności oprogramowania wymaga dwuetapowego podejścia kryptograficznego. Samo pobranie pliku 'SHA256SUMS' z tego samego serwera, na którym znajduje się obraz ISO, nie chroni przed atakiem – włamywacz, który zmodyfikował plik ISO, może z łatwością przeliczyć nową sumę i podmienić również plik SHA256SUMS. Dopiero cyfrowe podpisanie pliku sum kluczem GPG twórców (który jest weryfikowany niezależnie) gwarantuje autentyczność.

Przełącznik '-c' (lub '--check') w programie 'sha256sum' umożliwia w pełni zautomatyzowaną weryfikację setek plików jednocześnie. Program samodzielnie odczytuje nazwy plików z listy, oblicza ich skróty i porównuje z wartościami referencyjnymi, zwracając status 'OK' lub 'FAILED'.

Poniżej przedstawiono przykładowy widok konsoli z dwuetapowej procedury weryfikacji podpisu GPG listy sum oraz wykrycia uszkodzonego/zmodyfikowanego obrazu ISO:

W systemie Windows narzędzie 'certutil -hashfile [plik] SHA256' jest domyślnie dostępne w każdej instalacji od czasów Windows 7 i nie wymaga praw administratora. Zwraca ono sumę kontrolną podzieloną spacjami, którą łatwo porównać z oficjalną stroną producenta.

W środowisku PowerShell polecenie 'Get-FileHash .\plik.iso -Algorithm SHA256' zwraca ustrukturyzowany obiekt, którego właściwość 'Hash' można w skryptach porównywać bezpośrednio operatorem '-eq' z wartością wzorcową.

1. Zrozumienie dwuetapowego modelu weryfikacji oprogramowania (podpis GPG listy sum + hashowanie SHA-256 pliku binarnego).
2. Wykazanie niebezpieczeństwa wynikającego z bezrefleksyjnego uruchamiania oprogramowania pobranego z nieautoryzowanych serwerów lustrzanych.
3. Praktyczna umiejętność automatyzacji weryfikacji za pomocą narzędzia sha256sum -c w systemie Linux.
4. Umiejętność weryfikacji sum kontrolnych w systemie Windows za pomocą narzędzi CertUtil oraz PowerShell Get-FileHash.
5. Rola procedur weryfikacji integralności w zapobieganiu atakom na łańcuch dostaw (Supply Chain Attacks).
6. Rekomendacje dotyczące tworzenia procedur instalacji oprogramowania w instytucjach podlegających ustawie o KSC.

Przykładowe wnioski (wzór do sprawozdania): Weryfikacja sum kontrolnych pobieranych plików ISO za pomocą narzędzia sha256sum wykazała kluczowe znaczenie tego procesu w zapobieganiu instalacji uszkodzonego lub złośliwie zmodyfikowanego oprogramowania. Zrozumienie wektorów ataków na łańcuch dostaw (Supply Chain Attacks) udowodniło, że samo pobranie pliku ze skrótem nie stanowi wystarczającego zabezpieczenia, jeżeli plik sumy nie został zweryfikowany kryptograficznym podpisem PGP autora. Zastosowanie polecenia 'sha256sum -c' pozwala na zautomatyzowane sprawdzenie setek pakietów instalacyjnych w środowisku produkcyjnym przed ich wdrożeniem na serwery. Ćwiczenie wykazało, że modyfikacja choćby jednego bajtu w instalatorze skutkuje natychmiastowym odrzuceniem pliku, chroniąc system operacyjny przed kompromitacją. Praktyka weryfikacji skrótów powinna stać się elementarnym nawykiem każdego administratora i inżyniera cyberbezpieczeństwa.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Kon4 Sieciowe systemy składowania danych i kontrola przepływu. Efekty uczenia się: W1, W3, U1, U2, U4, K1.

Celem ćwiczenia jest opanowanie mechanizmów kontroli integralności konfiguracji oraz oprogramowania układowego w urządzeniach sieciowych MikroTik RouterOS. Studenci poznają zasady generowania i weryfikacji kryptograficznych sum kontrolnych kopii zapasowych (backupów binarnych i skryptów RSC) oraz weryfikacji autentyczności pakietów systemowych (.npk).

W trakcie laboratorium zespół bada wbudowane mechanizmy haszowania RouterOS (komendy /file oraz wbudowane podpisy cyfrowe pakietów RouterOS v7), tworzy procedurę automatycznego audytu integralności plików konfiguracyjnych z wykorzystaniem stacji roboczej Linux/Windows oraz symuluje próbę wstrzyknięcia nieautoryzowanej reguły zapory sieciowej do skryptu eksportu. Zadanie kończy się opracowaniem procedury audytu urządzeń brzegowych.

Przedsiębiorstwo Energetyki Cieplnej „Termo-Ciepło” w Wałbrzychu wykorzystuje routery MikroTik RouterOS do zarządzania komunikacją telemetryczną pomiędzy miejską elektrociepłownią a ponad setką bezobsługowych węzłów cieplnych na osiedlach mieszkaniowych.

W ramach procedur ciągłości działania (Disaster Recovery) administratorzy codziennie wykonują automatyczne eksporty konfiguracji routerów (skrypty tekstowe '/export' oraz binarne kopie '/system backup save') i przesyłają je na centralny serwer archiwizacji SFTP. Jednak do tej pory nikt nie weryfikował, czy składowane pliki konfiguracyjne nie zostały zmodyfikowane w spoczynku lub czy kopie zapasowe nie uległy uszkodzeniu.

W trakcie audytu bezpieczeństwa infrastruktury krytycznej audytor zwrócił uwagę na ryzyko ataku typu Tampering: pracownik posiadający dostęp do serwera kopii mógłby dopisać do skryptu konfiguracyjnego regułę przekierowania portów (NAT) lub otworzyć dostęp do sieci przemysłowej SCADA dla obcych adresów IP, a podczas awaryjnego odtwarzania routera po awarii zostałaby wgrana zmodyfikowana, podatna konfiguracja.

Kierownik działu automatyki zlecił zespołowi studentów wdrożenie procedury kryptograficznego pieczętowania każdej wykonywanej kopii zapasowej za pomocą sumy SHA-256 wyliczanej natychmiast po jej utworzeniu, połączonej z automatycznym testem spójności przed wgraniem pliku na router.

Zespół studentów ma za zadanie zaimplementować tę procedurę: wykonać eksport konfiguracji w RouterOS CLI, pobrać plik na stację audytorską, obliczyć referencyjny skrót SHA-256, zasymulować modyfikację reguły firewall w pliku i wykazać natychmiastowe zdemaskowanie fałszerstwa przed przywróceniem konfiguracji.

1. Zalogowanie się do konsoli routera MikroTik RouterOS przez bezpieczny terminal SSH lub WinBox.
2. Sprawdzenie wersji oprogramowania systemowego poleceniem '/system resource print' (RouterOS v7.x).
3. Wykonanie tekstowego eksportu konfiguracji routera do pliku: '/export file=konfiguracja_wezel1.rsc'.
4. Wykonanie pełnej binarnej kopii zapasowej systemu z hasłem szyfrującym: '/system backup save name=backup_wezel1 password=KopiaHaslo2026!'.
5. Sprawdzenie obecności nowo utworzonych plików w pamięci urządzenia poleceniem '/file print'.
6. Weryfikacja sumy kontrolnej pliku wewnątrz systemu RouterOS: zbadanie wbudowanych atrybutów pliku.
7. Pobranie plików 'konfiguracja_wezel1.rsc' oraz 'backup_wezel1.backup' na stację roboczą Linux/Windows za pomocą bezpiecznego protokołu SFTP / SCP: 'scp admin@192.168.88.1:/konfiguracja_wezel1.rsc .'.
8. Na stacji audytorskiej natychmiastowe wygenerowanie referencyjnej sumy kontrolnej SHA-256: 'sha256sum konfiguracja_wezel1.rsc backup_wezel1.backup > sumy_referencyjne.sha256'.
9. Zabezpieczenie pliku sum kontrolnych przed modyfikacją (np. podpisanie cyfrowe GPG lub zapis w chronionym katalogu): 'chmod 400 sumy_referencyjne.sha256'.
10. Otwarcie pliku 'konfiguracja_wezel1.rsc' w edytorze tekstowym i zapoznanie się z jego strukturą (czytelne reguły konfiguracyjne RouterOS).
11. Napisanie skryptu audytorskiego 'sprawdz_integralnosc_backupu.sh', który automatycznie weryfikuje sumę SHA-256 pliku przed wdrożeniem go na router.
12. Wykonanie testu pozytywnego: uruchomienie weryfikacji na nienaruszonym pliku ('sha256sum -c sumy_referencyjne.sha256') i potwierdzenie statusu OK.
13. Symulacja ataku / sabotażu: dopisanie przez złośliwego użytkownika na końcu pliku 'konfiguracja_wezel1.rsc' niebezpiecznej reguły zapory ogniowej: 'echo "/ip firewall filter add chain=input action=accept comment=\"Backdoor Access\"" >> konfiguracja_wezel1.rsc'.
14. Uruchomienie skryptu weryfikacyjnego 'sprawdz_integralnosc_backupu.sh' na zmodyfikowanym pliku konfiguracyjnym.
15. Zarejestrowanie alarmu naruszenia integralności: 'konfiguracja_wezel1.rsc: FAILED' oraz zablokowanie wysyłki pliku na router.
16. Zbadanie mechanizmu weryfikacji integralności pakietów systemowych RouterOS (.npk): polecenie '/system package print' oraz weryfikacja automatycznego sprawdzania podpisów cyfrowych MikroTik przed instalacją aktualizacji.
17. Przetestowanie poleceń weryfikacyjnych w PowerShell na stacji Windows: 'Get-FileHash .\konfiguracja_wezel1.rsc -Algorithm SHA256'.
18. Opracowanie procedury bezpiecznego przechowywania kopii zapasowych urządzeń sieciowych zgodnie z normą ISO/IEC 27001 (załącznik A.12.3).
19. Przygotowanie tabelarycznego porównania formatów kopii MikroTik: eksport tekstowy (.rsc) vs kopia binarna (.backup) pod kątem przenośności i bezpieczeństwa.
20. Sformułowanie wniosków końcowych dotyczących ochrony integralności konfiguracji w systemach infrastruktury krytycznej.

W systemie MikroTik RouterOS istnieją dwa podstawowe formaty kopii zapasowych. Kopia binarna (.backup) zawiera pełny obraz stanu routera (w tym hasła użytkowników, certyfikaty SSL i klucze prywatne) i może być zaszyfrowana hasłem. Kopia tekstowa (.rsc) tworzona poleceniem '/export' jest skryptem poleceń CLI, który można edytować i przeglądać w zwykłym notatniku.

Z uwagi na otwarty format pliku '.rsc', jest on wysoce podatny na niezauważalne modyfikacje przez osoby trzecie. Wdrożenie procedury obliczania sumy SHA-256 bezpośrednio w momencie pobrania pliku z routera i składowanie tej sumy w niezależnym repozytorium gwarantuje, że żadna zmiana reguł sieciowych nie umknie uwadze administratorów.

Poniżej przedstawiono listing z procedury weryfikacji sumy kontrolnej pliku konfiguracyjnego routera oraz wykrycie dopisania nieautoryzowanej reguły zapory sieciowej:

W systemie RouterOS v7 pakiety aktualizacyjne '.npk' są fabrycznie podpisane cyfrowo przez firmę MikroTik za pomocą kluczy asymetrycznych. Router automatycznie weryfikuje podpis pakietu przed jego zainstalowaniem – próba wgrania zmodyfikowanego lub uszkodzonego pakietu .npk skutkuje odrzuceniem aktualizacji przez bootloader.

Zaleca się, aby binarne pliki '.backup' były zawsze tworzone z podaniem silnego hasła szyfrującego ('/system backup save password=...'), co zabezpiecza poufne klucze prywatne przed odczytem w przypadku wycieku pliku kopii.

1. Zrozumienie znaczenia kontroli integralności plików konfiguracyjnych urządzeń sieciowych w infrastrukturze krytycznej.
2. Różnice architektoniczne i poziomy bezpieczeństwa pomiędzy kopią binarną (.backup) a eksportem tekstowym (.rsc).
3. Skuteczność kryptograficznych sum SHA-256 w natychmiastowym wykrywaniu sabotażu i nieautoryzowanych modyfikacji reguł firewall.
4. Rola fabrycznych podpisów cyfrowych w weryfikacji pakietów aktualizacyjnych RouterOS (.npk).
5. Zgodność procedur archiwizacji konfiguracji z normą ISO/IEC 27001 i wymogami ustawy o KSC.
6. Rekomendacje dotyczące automatyzacji procesów audytu kopii zapasowych w przedsiębiorstwach ciepłowniczych i przemysłowych.

Przykładowe wnioski (wzór do sprawozdania): Badanie integralności oprogramowania RouterOS potwierdziło, że bezpieczeństwo routera brzegowego zależy bezpośrednio od nienaruszalności jego plików binarnych i skryptów konfiguracyjnych. Weryfikacja sum kontrolnych pakietów instalacyjnych (.npk) gwarantuje, że do urządzenia wgrywane jest wyłącznie oryginalne oprogramowanie układowe podpisane przez producenta. Zastosowanie zewnętrznych skryptów weryfikujących sumy SHA-256 eksportowanych plików konfiguracyjnych pozwala na natychmiastowe wykrycie potajemnych modyfikacji reguł zapory ogniowej lub dodania nieautoryzowanych użytkowników. Wykazano, że regularna archiwizacja i kontrola kryptograficzna konfiguracji stanowi skuteczną barierę przeciwko zaawansowanym atakom typu APT infekującym urządzenia sieciowe. Opracowane procedury kontroli spójności wydatnie podnoszą stabilność i odporność węzła sieciowego w środowisku produkcyjnym.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Funkcje skrótu. Efekty uczenia się: W1, W3, U1, U3, K1, K2.

Głównym celem zadania jest praktyczne zrozumienie kryptograficznych zasad bezpiecznego przechowywania haseł w bazach danych systemów informatycznych oraz uświadomienie studentom fundamentalnego błędu polegającego na stosowaniu szybkich ogólnych funkcji skrótu (MD5, SHA-1, SHA-256) bez soli do ochrony poświadczeń.

W trakcie laboratorium zespół bada mechanizm działania ataków słownikowych oraz wstępnie obliczonych tablic tęczowych (Rainbow Tables). Studenci demonstrują, jak niesolone skróty haseł są błyskawicznie łamane za pomocą publicznych baz kryptoanalitycznych, implementują mechanizm solenia kryptograficznego (Salt) eliminujący ataki tablicowe oraz poznają wolne, adaptacyjne funkcje derywacji klucza (KDF: bcrypt, PBKDF2, Argon2). Prace wieńczy opracowanie zaleceń utwardzania baz użytkowników.

Wydawnictwo Oświatowe i Platforma E-Learningowa „Omnibus” w Toruniu prowadzi portal edukacyjny dla kilkunastu tysięcy nauczycieli i uczniów szkół podstawowych. Użytkownicy logują się do portalu za pomocą adresu e-mail i hasła.

Podczas audytu bezpieczeństwa przeprowadzonego po incydencie wycieku danych z bazy SQL audytor odkrył, że hasła użytkowników były haszowane zwykłym algorytmem SHA-256 bez żadnej soli ('hash = SHA256(password)'). W rezultacie, gdy zrzut tabeli użytkowników wyciekł do sieci, cyberprzestępcy w ciągu zaledwie kilkunastu minut odzyskali ponad 85% haseł użytkowników, wykorzystując publiczne bazy wyszukiwania odwróconych skrótów (tzw. bazy rainbow tables i silniki crackstation).

Co więcej, użytkownicy, którzy posiadali identyczne hasła (np. popularne 'Haslo123!'), mieli w bazie dokładnie taki sam skrót SHA-256, co pozwoliło napastnikowi na błyskawiczne zidentyfikowanie powtarzających się haseł w całej bazie.

Zarząd platformy nakazał natychmiastowe przeprojektowanie architektury modułu uwierzytelniania. Wymagane jest wdrożenie kryptograficznej soli (losowy ciąg min. 16 bajtów unikalny dla każdego użytkownika) oraz migracja do wolnej funkcji haszującej bcrypt lub PBKDF2 z wysokim współczynnikiem trudności obliczeniowej (work factor / iterations).

Zespół studentów wciela się w inżynierów kryptoanalizy. Grupa przeprowadza demonstrację podatności niesolonych haseł, implementuje procedurę solenia w powłoce Linux z użyciem OpenSSL, bada zachowanie haszy bcrypt i analizuje dlaczego nowoczesne karty GPU nie radzą sobie z łamaniem haseł chronionych pamięciożernym algorytmem Argon2/bcrypt.

1. Przygotowanie katalogu roboczego na stacji Linux: 'mkdir -p ~/lab6-password-hashing && cd ~/lab6-password-hashing'.
2. Weryfikacja dostępności narzędzi 'openssl', 'python3', 'mkpasswd' lub narzędzia Apache 'htpasswd'.
3. Utworzenie listy popularnych haseł testowych: 'Haslo123!', 'Admin2026', 'qwerty', 'Polska123'.
4. Wyliczenie surowych, niesolonych skrótów SHA-256 dla tych haseł: 'echo -n "Haslo123!" | sha256sum'.
5. Odnotowanie wartości skrótu niesolonego: '3b870793e758...'.
6. Wyszukanie tego skrótu w publicznych bazach kryptoanalitycznych online (lub lokalnym słowniku) i wykazanie natychmiastowego odzyskania hasła jawnego (dowód podatności na tablice tęczowe).
7. Utworzenie bazy dwóch fikcyjnych użytkowników posiadających to samo hasło 'Haslo123!' i wykazanie identyczności ich skrótów w bazie bez soli.
8. Zaprojektowanie procedury solenia (Salting): wygenerowanie unikalnej, kryptograficznie losowej soli dla każdego użytkownika: 'SOL1=$(openssl rand -hex 16)' oraz 'SOL2=$(openssl rand -hex 16)'.
9. Obliczenie solonych skrótów SHA-256: 'echo -n "$SOL1:Haslo123!" | sha256sum' oraz 'echo -n "$SOL2:Haslo123!" | sha256sum'.
10. Weryfikacja kluczowej obserwacji: pomimo identycznego hasła obu użytkowników, ich skróty w bazie danych są całkowicie odmienne.
11. Wykazanie, dlaczego obecność unikalnej soli całkowicie unieważnia globalne tablice tęczowe (napastnik musi łamać każde konto indywidualnie).
12. Przeanalizowanie problemu wydajności szybkiego haszowania: pojedyncza nowoczesna karta graficzna RTX 4090 potrafi sprawdzić ponad 20 miliardów skrótów SHA-256 na sekundę.
13. Zbadanie dedykowanych funkcji haszowania haseł (Password Hashing Functions) o regulowanym koszcie obliczeniowym: bcrypt, PBKDF2, scrypt, Argon2.
14. Wygenerowanie bezpiecznego hasła za pomocą narzędzia htpasswd z algorytmem bcrypt (koszt 12): 'htpasswd -B -C 12 -n -b uzytkownik1 Haslo123!'.
15. Zbadanie struktury hasza bcrypt: identyfikator '$2y$', koszt '12', 22-znakowa wbudowana sól oraz 31-znakowy właściwy skrót.
16. Zmierzenie czasu potrzebnego na wyliczenie pojedynczego hasza bcrypt przy koszcie 12 (ok. 250-300 ms) i analiza wpływu tego spowolnienia na obronę przed atakiem brute-force.
17. Przetestowanie polecenia OpenSSL PBKDF2: 'openssl kdf -kdfopt pass:Haslo123! -kdfopt salt:losowasol1234567 -kdfopt iter:100000 -kdfopt digest:SHA256 32 PBKDF2'.
18. Analiza wytycznych OWASP Password Storage Cheat Sheet oraz zaleceń NIST SP 800-63B dotyczących przechowywania poświadczeń.
19. Sporządzenie tabelarycznego zestawienia algorytmów: MD5/SHA256 (surowe), SHA256+Sól, PBKDF2, bcrypt, Argon2id.
20. Opracowanie referatu z rekomendacjami dla programistów portalu edukacyjnego nakazującymi migrację do bcrypt/Argon2id.

Funkcje skrótu ogólnego przeznaczenia (takie jak SHA-256 czy SHA-3) zostały zaprojektowane tak, aby były maksymalnie szybkie i wydajne – ich zadaniem jest błyskawiczne haszowanie wielogigabajtowych plików i pakietów sieciowych. Z tego właśnie powodu są one skrajnie niebezpieczne w przechowywaniu haseł: szybkość pozwala atakującemu na testowanie dziesiątek miliardów haseł na sekundę przy użyciu klastrów GPU.

Bezpieczne funkcje przechowywania haseł (KDF – Key Derivation Functions), takie jak bcrypt, scrypt czy zwycięzca konkursu Password Hashing Competition – Argon2id, są celowo projektowane jako funkcje wolne i pamięciożerne. Posiadają regulowany parametr kosztu (Work Factor / Memory Cost), który zmusza procesor do wykonania setek tysięcy iteracji lub zaalokowania megabajtów pamięci RAM dla każdej próby, co uniemożliwia masowe równoległe łamanie haseł na kartach graficznych i układach ASIC.

Poniżej przedstawiono przykładowy widok konsoli serwera demonstrujący generowanie solonych skrótów oraz bezpiecznego hasza bcrypt o strukturze modułowej:

Sól kryptograficzna (Salt) nie musi być tajna – jej zadaniem jest zapewnienie unikalności. Może być i jest jawnie zapisywana w bazie danych obok skrótu hasła (tak jak w powyższym rekordzie bcrypt). Kluczowe jest jedynie to, aby sól była losowa, miała odpowiednią długość (min. 16 bajtów) i była unikalna dla każdego użytkownika.

W systemach o najwyższym reżimie bezpieczeństwa obok soli stosuje się tzw. pieprz (Pepper) – tajny klucz symetryczny przechowywany poza bazą danych (np. w sprzętowym module HSM), którym dodatkowo szyfruje się lub podpisuje wygenerowany skrót hasła.

1. Zrozumienie dlaczego szybkie funkcje skrótu (MD5, SHA-256) nie nadają się do przechowywania haseł.
2. Rola soli kryptograficznej w całkowitej neutralizacji ataków opartych na tablicach tęczowych (Rainbow Tables).
3. Eliminacja zjawiska identyczności skrótów dla użytkowników posiadających to samo hasło.
4. Zalety wolnych, pamięciożernych funkcji derywacji klucza (bcrypt, scrypt, Argon2id) w obronie przed klastrami GPU.
5. Znaczenie parametru kosztu (Work Factor) i jego adaptacyjnego dostosowywania do wzrostu mocy obliczeniowej komputerów.
6. Rekomendacje dotyczące audytu baz danych użytkowników w świetle standardów OWASP i wytycznych RODO.

Przykładowe wnioski (wzór do sprawozdania): Eksperyment kryptoanalityczny z łamaniem haseł jednoznacznie udowodnił, że tradycyjne, szybkie funkcje skrótu (takie jak MD5 czy SHA-256) są całkowicie nieodpowiednie do bezpiecznego przechowywania haseł użytkowników. Nowoczesne układy graficzne GPU są w stanie przeliczać miliardy skrótów SHA-256 na sekundę, co pozwala na błyskawiczne odzyskanie haseł słownikowych za pomocą gotowych tablic tęczowych (Rainbow Tables). Zastosowanie unikalnej soli kryptograficznej (Salt) dla każdego konta skutecznie neutralizuje ataki z użyciem tablic prekomputowanych, wymuszając indywidualne przeszukiwanie przestrzeni dla każdego użytkownika. Wykazano, że w nowoczesnych aplikacjach należy bezwzględnie stosować wolne, pamięciożerne funkcje wyprowadzania klucza, takie jak Argon2id lub bcrypt z dynamicznie dobieranym kosztem obliczeniowym. Ćwiczenie to stanowi kluczowy punkt edukacyjny dla przyszłych programistów i projektantów baz danych uwierzytelniających.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Podpisy cyfrowe i funkcje skrótu. Efekty uczenia się: W1, W3, U1, U2, U4, K1, K3.

Celem ćwiczenia jest praktyczne opanowanie implementacji kryptograficznego mechanizmu nienaruszalności dzienników zdarzeń (Tamper-evident Logging) z wykorzystaniem łańcucha funkcji skrótu (Hash Chain). Studenci dowiadują się, jak za pomocą rekurencyjnego haszowania SHA-256 zagwarantować integralność ścieżki audytowej (Audit Trail) w systemach operacyjnych i bazach danych.

W toku laboratorium zespół projektuje strukturę wpisu dziennika audytowego, w którym każdy nowy rekord zawiera kryptograficzny skrót rekordu poprzedniego, implementuje skrypt generujący kolejne zdarzenia w środowisku Linux CLI oraz tworzy narzędzie weryfikatora sprawdzające spójność całego rejestru. Studenci przeprowadzają symulację ataku wewnętrznego polegającego na próbie zatarcia śladów włamania przez edycję archiwalnych logów. Zadanie kończy się raportem technicznym.

Wojewódzki Urząd Pracy w Rzeszowie zarządza centralnym rejestrem osób bezrobotnych oraz systemem przyznawania dotacji na rozpoczęcie działalności gospodarczej ze środków Europejskiego Funduszu Społecznego. W systemie rejestrowane są decyzje finansowe o wypłacie bezzwrotnych dotacji w kwotach do 40 000 PLN.

Podczas audytu zgodności z Krajowymi Ramami Interoperacyjności (KRI § 20) inspektor ds. cyberbezpieczeństwa stwierdził, że dzienniki zdarzeń systemowych (logi w plikach tekstowych syslog / journald) są podatne na manipulację. Administrator posiadający uprawnienia roota lub cyberprzestępca po przełamaniu zabezpieczeń serwera może otworzyć plik dziennika, usunąć wpisy o nieautoryzowanym zalogowaniu lub zmodyfikować numer konta bankowego beneficjenta dotacji, uniemożliwiając późniejsze ustalenie sprawcy.

Dyrektor urzędu polecił wdrożenie kryptograficznego mechanizmu nienaruszalnego dziennika zdarzeń (Tamper-evident Audit Log) opartego na łańcuchu skrótów SHA-256. Wdrożone rozwiązanie musi sprawiać, że modyfikacja choćby jednego znaku w archiwalnym wpisie spowoduje natychmiastowe zerwanie łańcucha kryptograficznego i zostanie wykryta podczas codziennego audytu spójności.

Zespół studentów ma za zadanie zaimplementować generator łańcucha skrótów w powłoce Linux: zainicjować łańcuch Blokiem Zerowym (Genesis Block), wygenerować sekwencję wpisów symulujących decyzje administracyjne, zaimplementować skrypt walidacji matematycznej całego rejestru, a następnie przeprowadzić symulację próby zatarcia śladów przestępstwa.

W podsumowaniu studenci analizują jak technologia łańcuchów skrótów spełnia wymogi art. 32 RODO w zakresie rozliczalności i integralności przetwarzania danych osobowych.

1. Przygotowanie środowiska roboczego w systemie Linux: 'mkdir -p ~/lab6-hashchain-audit && cd ~/lab6-hashchain-audit'.
2. Weryfikacja dostępności narzędzi 'sha256sum', 'date', 'awk', 'sed' oraz interpretera Bash.
3. Zaprojektowanie struktury rekordu dziennika: 'ID_WPISU | TIMESTAMP | ZDARZENIE | POPRZEDNI_HASH | BIEZACY_HASH'.
4. Inicjalizacja łańcucha zdarzeń: utworzenie Bloku Zerowego (Genesis Record): 'ID=0', 'DATA=$(date -u +"%Y-%m-%dT%H:%M:%SZ")'
5. Zdefiniowanie początkowego hasza poprzedniego złożonego z 64 zer: 'PREV_HASH="0000000000000000000000000000000000000000000000000000000000000000"'.
6. Obliczenie bieżącego hasza Bloku Zerowego: 'CURRENT_HASH=$(echo -n "0|$DATA|GENESIS_INICJALIZACJA_DZIENNIKA|$PREV_HASH" | sha256sum | awk '{print $2}')'.
7. Zapisanie Bloku Zerowego do pliku 'dziennik_bezpieczenstwa.log'.
8. Napisanie skryptu 'dodaj_zdarzenie.sh', który automatycznie pobiera treść zdarzenia, odczytuje BIEZACY_HASH ostatniego wpisu jako POPRZEDNI_HASH, oblicza nowy skrót SHA-256 i dopisuje rekord.
9. Dodanie zdarzenia 1: './dodaj_zdarzenie.sh "Logowanie administratora: jan_admin z IP 10.0.1.50"'.
10. Dodanie zdarzenia 2: './dodaj_zdarzenie.sh "Zatwierdzenie wniosku dotacji DOT-2026-9812: 40000 PLN"'.
11. Dodanie zdarzenia 3: './dodaj_zdarzenie.sh "Zmiana rachunku bankowego beneficjenta: PL991020..."'.
12. Dopisanie kolejnych zdarzeń (od 4 do 8) symulujących normalną pracę urzędu.
13. Wyświetlenie i przeanalizowanie pliku 'dziennik_bezpieczenstwa.log' poleceniem 'cat dziennik_bezpieczenstwa.log'.
14. Napisanie skryptu audytorskiego 'weryfikuj_spojnosc.sh', który odczytuje plik od początku do końca, przelicza skrót każdego rekordu i weryfikuje ciągłość powiązań.
15. Uruchomienie skryptu weryfikacyjnego: potwierdzenie pomyślnego przejścia audytu '[AUDYT POZYTYWNY] Wszystkie rekordy nienaruszone (8/8)'.
16. Symulacja ataku sabotażowego / zatarcia śladów: otwarcie pliku w edytorze nano i zmiana numeru konta w zdarzeniu 3 na rachunek słupa.
17. Ponowne uruchomienie skryptu 'weryfikuj_spojnosc.sh' na sfałszowanym dzienniku.
18. Zarejestrowanie natychmiastowego alarmu: wykrycie niezgodności skrótu w zdarzeniu 3 oraz zerwanie powiązania w zdarzeniu 4.
19. Przeanalizowanie procedury zewnętrznego pieczętowania (Anchoring) skrótu ostatniego wpisu (np. codzienny e-mail do Inspektora Ochrony Danych lub zapis w repozytorium WORM).
20. Sformułowanie wniosków technicznych dotyczących zgodności z wymogami KRI i RODO w zakresie rozliczalności operacji administracyjnych.

Mechanizm łańcucha skrótów (Hash Chain) zamienia zbiór niezależnych wpisów tekstowych w kryptograficznie spójną całość. Każdy wpis jest matematycznie związany z całą historią zdarzeń, która go poprzedzała. Nie jest możliwe zmodyfikowanie żadnego historycznego rekordu bez konieczności ponownego przeliczenia skrótów dla wszystkich kolejnych rekordów aż do końca dziennika.

Właściwość Tamper-Evidence oznacza, że system natychmiast ujawnia fakt manipulacji (ang. tampering). Nawet jeżeli napastnik zdoła przeliczyć skróty w pliku lokalnym, to nie jest w stanie sfałszować skrótu, który został wcześniej wyeksportowany poza badany serwer (tzw. zaufane kotwiczenie – Cryptographic Anchoring).

Poniżej przedstawiono listing sesji konsoli demonstrujący pomyślną weryfikację spójności łańcucha oraz zdemaskowanie próby podmiany wpisu w logu:

W systemach produkcyjnych do ochrony dzienników zdarzeń stosuje się dedykowane serwery zbierające logi (SIEM / Syslog-ng), które przesyłają wpisy w czasie rzeczywistym przez szyfrowany tunel TLS na odizolowaną maszynę z ograniczonym dostępem administracyjnym.

W sprawozdaniu wyjaśnij różnicę pomiędzy nienaruszalnością kryptograficzną (Tamper-evidence – system ujawnia fałszerstwo) a nienaruszalnością fizyczną (Tamper-resistance / WORM – nośnik fizycznie uniemożliwia zapis).

1. Zrozumienie kryptograficznej architektury łańcucha skrótów (Hash Chain) w zastosowaniach audytowych.
2. Wykazanie niemożności zatarcia śladów w spójnym łańcuchu kryptograficznym bez wykrycia przez weryfikator.
3. Rola procedury kotwiczenia skrótów (Anchoring) w niezależnych węzłach zaufania.
4. Zgodność nienaruszalnych rejestrów zdarzeń z wymaganiami KRI (§ 20) oraz art. 32 RODO (rozliczalność).
5. Praktyczna umiejętność automatyzacji weryfikacji integralności logów w skryptach powłoki Linux.
6. Rekomendacje dotyczące wdrożenia architektury Tamper-evident Logging w instytucjach administracji publicznej.

Przykładowe wnioski (wzór do sprawozdania): Implementacja nienaruszalnego dziennika zdarzeń w oparciu o łańcuch skrótów SHA-256 dowiodła, że matematyczne powiązanie kolejnych wpisów logu uniemożliwia intruzowi zacieranie śladów włamania. Każda próba modyfikacji, usunięcia lub wstrzyknięcia fałszywego wpisu do archiwum skutkuje natychmiastowym załamaniem spójności skrótów w kolejnych rekordach podczas audytu. Rozwiązanie to diametralnie podnosi wartość dowodową rejestrów systemowych w postępowaniach z zakresu informatyki śledczej oraz audytach powłamaniowych. Zastosowanie cyklicznego kotwiczenia bieżącego skrótu łańcucha w niezależnym medium gwarantuje pełną niezaprzeczalność zarejestrowanych incydentów bezpieczeństwa. Opracowany mechanizm stanowi wzorcowe rozwiązanie dla zabezpieczania newralgicznych dzienników audytowych w instytucjach publicznych i komercyjnych.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Podpisy cyfrowe i funkcje skrótu. Efekty uczenia się: W3, W4, U1, U2, U4, K1, K3.

Celem ćwiczenia jest dogłębne zrozumienie nierozerwalnego związku pomiędzy kryptograficznymi funkcjami skrótu a asymetrycznymi schematami podpisu cyfrowego (RSA / ECDSA). Studenci dowiadują się, dlaczego w podpisie cyfrowym nigdy nie szyfruje się całego dokumentu, lecz wyłącznie jego unikalny, krótki skrót (Message Digest).

W trakcie laboratorium zespół bada mechanizm powstawania podpisu cyfrowego na poziomie poszczególnych operacji matematycznych: obliczenie skrótu SHA-256 z dokumentu oświadczenia woli, dopełnienie skrótu zgodnie ze standardem PKCS#1 v1.5 / PSS, zaszyfrowanie skrótu kluczem prywatnym RSA oraz niezależną weryfikację podpisu kluczem publicznym. Studenci analizują konsekwencje kompromitacji funkcji skrótu dla ważności podpisów prawnych. Zadanie wieńczy raport techniczny.

Izba Notarialna w Warszawie prowadzi pilotażowy program wdrażania kwalifikowanych repozytoriów cyfrowych aktów notarialnych i odpisów ksiąg wieczystych. Zgodnie z ustawą Prawo o notariacie oraz unijnym rozporządzeniem eIDAS, podpis elektroniczny złożony pod dokumentem notarialnym wywołuje takie same skutki prawne jak podpis własnoręczny.

Wielu młodych prawników i aplikantów błędnie uważa, że podpis cyfrowy polega na 'zaszyfrowaniu całego dokumentu PDF kluczem prywatnym notariusza'. Przekonanie to prowadzi do nieporozumień dotyczących wydajności systemów oraz ochrony prywatności (przekonanie, że podpisany dokument jest automatycznie nieczytelny dla osób postronnych).

Rada Izby Notarialnej zleciła zespołowi studentów przygotowanie precyzyjnej, inżynierskiej demonstracji laboratoryjnej wyjaśniającej rzeczywisty mechanizm podpisu cyfrowego: dokument pozostaje w postaci jawnej, podpisywany jest wyłącznie jego 256-bitowy skrót SHA-256, a weryfikacja polega na matematycznym porównaniu skrótu odszyfrowanego z podpisu ze skrótem obliczonym na nowo z dokumentu.

Zespół studentów ma za zadanie zrealizować ten proces 'krok po kroku' za pomocą niskopoziomowych poleceń pakietu OpenSSL w systemie Linux: wygenerować parę kluczy RSA 3072-bit, manualnie wyliczyć skrót SHA-256 z oświadczenia majątkowego, złożyć podpis poleceniem 'openssl pkeyutl -sign', a następnie przeprowadzić weryfikację poleceniem 'openssl pkeyutl -verify'.

W fazie testów studenci udowadniają, że zmiana choćby jednej cyfry w akcie notarialnym powoduje całkowitą niezgodność skrótów i natychmiastowe odrzucenie podpisu cyfrowego przez sądowy system weryfikacyjny.

1. Przygotowanie środowiska roboczego: 'mkdir -p ~/lab6-digital-signature && cd ~/lab6-digital-signature'.
2. Weryfikacja dostępności narzędzia OpenSSL poleceniem 'openssl version'.
3. Wygenerowanie 3072-bitowego klucza prywatnego Notariusza: 'openssl genrsa -out notariusz_private.pem 3072'.
4. Wyodrębnienie klucza publicznego Notariusza: 'openssl rsa -in notariusz_private.pem -pubout -out notariusz_public.pem'.
5. Utworzenie dokumentu aktu notarialnego 'akt_notarialny.txt': 'echo "REPERTORIUM A 9812/2026: Jan Kowalski daruje lokal mieszkalny o wartosci 650000 PLN Piotrowi Nowakowi." > akt_notarialny.txt'.
6. Krok 1 procedury podpisu: manualne obliczenie skrótu SHA-256 w formacie binarnym: 'openssl dgst -sha256 -binary akt_notarialny.txt > akt.hash'.
7. Wyświetlenie skrótu binarnego w postaci heksadecymalnej poleceniem 'xxd akt.hash' (dokładnie 32 bajty / 256 bitów).
8. Krok 2 procedury podpisu: podpisanie skrótu kluczem prywatnym RSA przy użyciu nowoczesnego dopełnienia PSS: 'openssl pkeyutl -sign -in akt.hash -inkey notariusz_private.pem -out akt.sig -pkeyopt digest:sha256 -pkeyopt rsa_padding_mode:pss'.
9. Zbadanie powstałego pliku podpisu 'akt.sig': rozmiar pliku wynosi dokładnie 384 bajty (odpowiednik 3072 bitów klucza RSA).
10. Przekazanie dokumentu 'akt_notarialny.txt', pliku podpisu 'akt.sig' oraz klucza publicznego 'notariusz_public.pem' do sądu / odbiorcy.
11. Krok 1 weryfikacji w sądzie: niezależne obliczenie skrótu SHA-256 z otrzymanego dokumentu: 'openssl dgst -sha256 -binary akt_notarialny.txt > akt_odbiorca.hash'.
12. Krok 2 weryfikacji w sądzie: matematyczne sprawdzenie podpisu za pomocą klucza publicznego Notariusza: 'openssl pkeyutl -verify -in akt_odbiorca.hash -sigfile akt.sig -pubin -inkey notariusz_public.pem -pkeyopt digest:sha256 -pkeyopt rsa_padding_mode:pss'.
13. Potwierdzenie uzyskania komunikatu 'Signature Verified Successfully' (Podpis poprawny).
14. Symulacja fałszerstwa aktu notarialnego: otwarcie 'akt_notarialny.txt' i zmiana wartości darowizny z '650000 PLN' na '150000 PLN'.
15. Ponowne obliczenie skrótu ze sfałszowanego aktu do 'akt_falszywy.hash'.
16. Próba weryfikacji oryginalnego podpisu względem sfałszowanego skrótu: 'openssl pkeyutl -verify -in akt_falszywy.hash -sigfile akt.sig -pubin -inkey notariusz_public.pem -pkeyopt digest:sha256 -pkeyopt rsa_padding_mode:pss'.
17. Zarejestrowanie błędu: 'Signature Verification Failure' (odrzucenie fałszerstwa).
18. Przeanalizowanie dlaczego podpisanie skrótu (32 bajty) jest tysiące razy szybsze niż hipotetyczne szyfrowanie wielostronicowego pliku PDF kluczem RSA.
19. Zbadanie historycznych skutków kompromitacji funkcji MD5 i SHA-1 w podpisach cyfrowych (fałszowanie certyfikatów).
20. Sformułowanie wniosków końcowych dotyczących roli funkcji skrótu w zapewnieniu integralności i niezaprzeczalności oświadczeń woli.

Podpis cyfrowy jest operacją hybrydową łączącą kryptograficzną funkcję skrótu (SHA-256) oraz kryptografię asymetryczną (RSA/ECDSA). Funkcja skrótu pełni rolę 'kompresora kryptograficznego' – przekształca dokument o dowolnym rozmiarze (nawet wielogigabajtowy film lub bazę danych) w unikalny ciąg o stałej długości 256 bitów, zachowując właściwość unikalności (odporność na kolizje).

Dopiero ten 256-bitowy skrót jest poddawany operacji asymetrycznej z użyciem klucza prywatnego. Dzięki temu podpis cyfrowy ma zawsze stałą, niewielką długość (np. 384 bajty dla RSA-3072 lub 64 bajty dla ECDSA P-256), a operacja podpisywania trwa ułamek milisekundy niezależnie od objętości podpisywanego dokumentu.

Poniżej przedstawiono przykładowy widok konsoli serwera Linux demonstrujący dwuetapowy proces składania podpisu OpenSSL i weryfikację jego autentyczności:

Zastosowanie schematu dopełniania PSS (Probabilistic Signature Scheme) w dyrektywie '-pkeyopt rsa_padding_mode:pss' jest współczesnym standardem zalecanym przez NIST i normy europejskie. W przeciwieństwie do deterministycznego dopełnienia PKCS#1 v1.5, schemat PSS wykorzystuje losową sól w procesie podpisu, co zapewnia matematyczny dowód bezpieczeństwa w modelu wyroczni losowej.

W sprawozdaniu podkreśl, że kompromitacja funkcji skrótu (np. znalezienie praktycznej metody generowania kolizji) niszczy bezpieczeństwo podpisu cyfrowego nawet przy użyciu najdłuższego klucza RSA 4096-bit. Jeśli atakujący znajdzie dwa dokumenty o tym samym skrócie, podpis złożony pod jednym z nich jest matematycznie poprawny dla drugiego.

1. Zrozumienie fundamentalnej roli funkcji skrótu jako bezpiecznego kompresora danych w schematach podpisu cyfrowego.
2. Rozróżnienie pomiędzy pojęciem poufności (szyfrowanie treści) a pojęciem autentyczności i integralności (podpis cyfrowy).
3. Matematyczne uzasadnienie stałego rozmiaru podpisu cyfrowego niezależnie od objętości podpisywanego dokumentu.
4. Przewaga nowoczesnego schematu dopełniania RSA-PSS nad tradycyjnym PKCS#1 v1.5.
5. Wpływ odporności funkcji skrótu na kolizje na długoterminową ważność podpisów cyfrowych w świetle rozporządzenia eIDAS.
6. Rekomendacje dotyczące wyboru parametrów kryptograficznych (SHA-256 + RSA 3072 / ECDSA P-256) w systemach prawnych.

Przykładowe wnioski (wzór do sprawozdania): Badanie mechanizmu składania podpisu cyfrowego wyjaśniło, dlaczego operacja kryptograficzna wykonywana jest na skrócie wiadomości, a nie na całym wielomegabajtowym dokumencie. Wykorzystanie funkcji SHA-256 do wygenerowania stałego, 256-bitowego streszczenia danych pozwala na radykalne skrócenie czasu operacji asymetrycznych i optymalizację rozmiaru samej sygnatury. Wykazano, że bezpieczeństwo całego podpisu cyfrowego jest bezpośrednio limitowane odpornością użytej funkcji skrótu na kolizje (atak urodzinowy) oraz odpornością na znalezienie drugiego przeciwobrazu. Ewentualne znalezienie kolizji w algorytmie skrótu pozwoliłoby na podstawienie fałszywego dokumentu pod legalny podpis cyfrowy bez wiedzy osoby podpisującej. Zrozumienie tej relacji uświadamia, dlaczego osłabienie jakiejkolwiek funkcji skrótu automatycznie unieważnia powiązane z nią certyfikaty i podpisy cyfrowe.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Podpisy cyfrowe i funkcje skrótu. Efekty uczenia się: W1, W3, U1, U2, U3, K1, K2.

Celem ćwiczenia jest praktyczne opanowanie implementacji mechanizmu uwierzytelniania wiadomości opartego na funkcji skrótu HMAC (Hash-based Message Authentication Code, RFC 2104) z wykorzystaniem algorytmu SHA-256 w nowoczesnych architekturach integracji systemów rozproszonych (Webhooks / REST API). Studenci poznają różnicę pomiędzy symetrycznym kodem HMAC a podpisem asymetrycznym.

W toku laboratorium zespół analizuje strukturę komunikacji pomiędzy dostawcą usług w chmurze a lokalnym systemem logistycznym przedsiębiorstwa. Studenci implementują procedurę generowania sygnatury HMAC po stronie nadawcy, tworzą filtr weryfikacyjny po stronie odbiorcy, badają odporność na ataki manipulacji treścią wiadomości (Data Tampering) oraz analizują problem ataków czasowych (Timing Attacks) na porównywanie skrótów. Ćwiczenie kończy się raportem technicznym.

Firma Kurierska „Paczka-Express” w Sosnowcu udostępnia platformom handlowym e-commerce automatyczne powiadomienia Webhook o zmianie statusu przesyłek (np. 'Paczka podjęta przez kuriera', 'Paczka dostarczona do rąk własnych').

Jeden ze zintegrowanych sklepów internetowych na podstawie odebranego powiadomienia ze statusem 'DELIVERED' automatycznie zwalnia środki finansowe z depozytu (Escrow) i wypłaca pieniądze sprzedawcom. Podczas testów bezpieczeństwa wykryto lukę: endpoint webhooka sklepu przyjmował każde żądanie HTTP POST zawierające poprawny numer przesyłki, nie weryfikując czy nadawcą powiadomienia rzeczywiście jest firma kurierska.

Cyberprzestępcy mogli wysyłać fałszywe powiadomienia o rzekomym doręczeniu drogich przesyłek, doprowadzając do nieautoryzowanej wypłaty setek tysięcy złotych z konta depozytowego. Zarząd firmy kurierskiej podjął decyzję o natychmiastowym wdrożeniu podpisywania każdego powiadomienia Webhook kryptograficznym kodem HMAC-SHA256 przy użyciu unikalnego klucza symetrycznego uzgodnionego z każdym partnerem.

Zespół studentów wciela się w inżynierów integracji systemów. Zadanie polega na przygotowaniu skryptu nadawczego firmy kurierskiej wyliczającego sygnaturę HMAC-SHA256 z ładunku JSON, umieszczeniu jej w nagłówku 'X-Hub-Signature-256', zaimplementowaniu weryfikatora po stronie sklepu oraz przeprowadzeniu symulacji próby podszycia się pod firmę kurierską przez nieuprawniony podmiot.

W podsumowaniu studenci analizują znaczenie funkcji bezpiecznego porównywania ciągów o stałym czasie wykonania (Constant-Time String Comparison) w zapobieganiu atakom czasowym.

1. Przygotowanie katalogu roboczego na serwerze Linux: 'mkdir -p ~/lab6-hmac-api && cd ~/lab6-hmac-api'.
2. Weryfikacja dostępności pakietów OpenSSL, cURL oraz Python 3 poleceniami 'openssl version' oraz 'python3 --version'.
3. Zdefiniowanie poufnego klucza symetrycznego uzgodnionego pomiędzy kurierem a sklepem: 'KluczWebhookKurier2026!Sekret'.
4. Utworzenie przykładowego komunikatu JSON 'status_paczki.json' zawierającego dane: numer przesyłki 'PACZKA-PL-998811', status 'DELIVERED', znacznik czasu i podpis kuriera.
5. Wygenerowanie sygnatury HMAC-SHA256 za pomocą narzędzia OpenSSL: 'SYGNATURA=$(openssl dgst -sha256 -hmac "KluczWebhookKurier2026!Sekret" status_paczki.json | awk '{print $2}')'.
6. Wyświetlenie wygenerowanej sygnatury heksadecymalnej i odnotowanie jej 64-znakowej długości.
7. Zaprojektowanie nagłówka HTTP żądania: 'X-Hub-Signature-256: sha256=$SYGNATURA'.
8. Napisanie skryptu weryfikatora po stronie sklepu 'odbierz_webhook.py' w języku Python z użyciem bibliotek 'hmac' i 'hashlib'.
9. Zaimplementowanie w skrypcie funkcji 'hmac.compare_digest(sygnatura_odebrana, sygnatura_wyliczona)' zapewniającej odporność na ataki czasowe (Timing Attack).
10. Wykonanie testu pomyślnego: przekazanie autentycznego pliku JSON oraz poprawnej sygnatury HMAC do weryfikatora.
11. Potwierdzenie komunikatu: '[SUKCES 200 OK] Sygnatura HMAC poprawna. Autentycznosc firmy kurierskiej zweryfikowana. Zwolnienie srodkow Escrow'.
12. Symulacja ataku 1 (Modyfikacja danych): zmiana statusu w pliku JSON z 'IN_TRANSIT' na 'DELIVERED' przy zachowaniu starej sygnatury.
13. Uruchomienie weryfikatora na zmodyfikowanym pliku i zarejestrowanie natychmiastowego błędu: '[BLAD 401 UNAUTHORIZED] Sygnatura HMAC niepoprawna! Odrzucenie falszywego powiadomienia'.
14. Symulacja ataku 2 (Brak znajomości klucza): próba wyliczenia sygnatury HMAC przez napastnika z użyciem zgadniętego lub pustego klucza.
15. Wykazanie, że bez znajomości sekretu wygenerowanie poprawnej sygnatury HMAC-SHA256 jest obliczeniowo niemożliwe.
16. Przetestowanie wysyłania powiadomienia za pomocą narzędzia cURL z nagłówkiem sygnatury: 'curl -X POST -H "X-Hub-Signature-256: sha256=$SYGNATURA" --data-binary @status_paczki.json http://localhost:8080/webhook'.
17. Przeanalizowanie różnicy pomiędzy kodem HMAC (klucz symetryczny – obie strony znają ten sam sekret) a podpisem cyfrowym RSA/ECDSA (klucz asymetryczny – nadawca ma klucz prywatny, odbiorca klucz publiczny).
18. Zbadanie podatności na ataki czasowe (Timing Attacks) przy użyciu standardowego operatora porównania stringów '==' i wyjaśnienie zasady działania 'hmac.compare_digest'.
19. Sporządzenie tabelarycznego zestawienia porównawczego: Token statyczny w nagłówku vs HMAC-SHA256 vs Podpis cyfrowy RSA-SHA256.
20. Sformułowanie wniosków końcowych do referatu dotyczących bezpieczeństwa architektury mikrousług i webhooków.

Mechanizm HMAC (RFC 2104) rozwiązuje fundamentalny problem prostego doklejania klucza do wiadomości: H(K || M). W prostym schemacie H(K || M) funkcje skrótu oparte na konstrukcji Merkleg-Damgarda (takie jak MD5, SHA-1, SHA-256) są podatne na atak wydłużania wiadomości (Length Extension Attack). HMAC eliminuje tę podatność poprzez podwójne zagnieżdżenie z wewnętrznym i zewnętrznym dopełnieniem: HMAC(K, M) = H((K' XOR opad) || H((K' XOR ipad) || M)).

Podczas programowania weryfikacji sygnatur kryptograficznych w językach takich jak Python, Java czy PHP, kardynalnym błędem jest stosowanie zwykłego operatora porównania ciągów znaków (np. 'if odebrany == obliczony:'). Standardowy operator przerywa porównywanie na pierwszym różniącym się bajcie, co ujawnia czas odpowiedzi serwera (zależny od liczby pasujących początkowych znaków) i pozwala napastnikowi na odgadnięcie poprawnej sygnatury bajt po bajcie w ataku czasowym (Timing Attack). Zawsze należy stosować funkcję stałoczasową 'hmac.compare_digest()'.

Poniżej przedstawiono przykładowy widok konsoli serwera demonstrujący generowanie sygnatury HMAC oraz odrzucenie powiadomienia ze sfałszowanym statusem:

Standard nagłówka 'X-Hub-Signature-256' jest powszechnie stosowany przez największe platformy technologiczne na świecie (w tym GitHub, Meta/Facebook, Stripe, Shopify) jako uniwersalny mechanizm podpisywania webhooków.

W sprawozdaniu wyjaśnij dlaczego do obliczenia HMAC należy używać surowego ciągu bajtów odebranego bezpośrednio z gniazda HTTP (Raw Request Body), a nie obiektu po sparsowaniu przez biblioteki JSON, które mogą zmienić kolejność pól lub formatowanie białych znaków.

1. Zrozumienie kryptograficznej konstrukcji HMAC (RFC 2104) i eliminacji ataku wydłużania wiadomości (Length Extension Attack).
2. Rola współdzielonego sekretu transakcyjnego w zapewnieniu autentyczności i integralności powiadomień API.
3. Znaczenie funkcji stałoczasowego porównywania skrótów (hmac.compare_digest) w ochronie przed atakami czasowymi (Timing Attacks).
4. Porównanie właściwości i narzutu obliczeniowego kodów symetrycznych HMAC z podpisami asymetrycznymi RSA/ECDSA.
5. Dobre praktyki implementacji odbiorników Webhook w środowiskach e-commerce i bramkach płatniczych.
6. Rekomendacje dotyczące procedur bezpiecznej rotacji kluczy HMAC pomiędzy partnerami biznesowymi.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna analiza mechanizmu HMAC-SHA256 w powiadomieniach Webhook wykazała jego wyższość nad naiwnymi metodami haszowania polegającymi na prostym łączeniu klucza z wiadomością H(K || M). Specjalna, dwuprzebiegowa konstrukcja algorytmu HMAC całkowicie uodparnia system na niebezpieczne ataki rozszerzania długości (Length Extension Attacks), powszechne w funkcjach opartych o konstrukcję Merkle-Damgårda. Wykorzystanie wspólnego sekretu kryptograficznego zapewnia odbiorcy stuprocentową pewność co do autentyczności nadawcy oraz nienaruszalności przesyłanych parametrów transakcyjnych. Odrzucenie zmodyfikowanych żądań na etapie weryfikacji sygnatury w nagłówku HTTP zapobiega wykonywaniu nieautoryzowanych akcji wewnątrz aplikacji biznesowej. Standard HMAC-SHA256 stanowi obecnie niekwestionowany fundament bezpiecznej integracji nowoczesnych usług chmurowych i systemów płatności.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Podpisy cyfrowe i funkcje skrótu. Efekty uczenia się: W1, W3, U1, U2, U4, K1, K2.

Głównym celem zadania jest praktyczne zrozumienie struktury drzew skrótów (Merkle Trees) oraz opanowanie algorytmu wydajnej weryfikacji przynależności i integralności elementów w wielkich zbiorach danych (złożoność O(log N)). Studenci dowiadują się, jak drzewa Merkle'a umożliwiają weryfikację pojedynczego rekordu (np. transakcji, pliku w chmurze) przy użyciu jedynie krótkiej ścieżki audytowej (Merkle Proof) bez konieczności pobierania całego zbioru.

W trakcie laboratorium zespół bada budowę drzewa binarnego od liści (skróty bloków danych), poprzez węzły pośrednie (skróty par), aż po korzeń drzewa (Merkle Root). Studenci implementują generator drzewa Merkle'a w języku Python / Bash dla zbioru 8 bloków danych, wyliczają ścieżkę dowodową dla wybranego bloku, weryfikują jej poprawność matematyczną oraz symulują próbę manipulacji danymi w jednym z liści. Zadanie wieńczy raport techniczny.

Operator Chmury Krajowej „Pol-Cloud” w Poznaniu świadczy usługi masowego składowania obiektowego danych (Object Storage / odpowiednik AWS S3) dla sektora bankowego, ubezpieczeniowego oraz jednostek administracji publicznej. Klienci przechowują w chmurze miliony plików zdigitalizowanych dokumentów, wyciągów bankowych oraz kopii baz danych.

Zgodnie z umową SLA banki wymagają możliwości natychmiastowego, kryptograficznego udowodnienia, że konkretny plik archiwalny o objętości kilku kilobajtów zdeponowany przed trzema laty nie został uszkodzony ani zmanipulowany na macierzach dyskowych chmury. Wcześniejszy mechanizm wymagał pobrania całego wieloterabajtowego archiwum i przeliczenia jego sumy SHA-256, co paraliżowało łącza sieciowe i generowało olbrzymie koszty transferu.

Główny architekt technologii Pol-Cloud podjął decyzję o wdrożeniu drzew skrótów (Merkle Trees). Dla każdego pakietu danych chmura wylicza pojedynczy 32-bajtowy korzeń Merkle Root, który jest publikowany w niezmiennym rejestrze. Gdy klient żąda dowodu integralności pojedynczego pliku, serwer odsyła zaledwie kilka skrótów ze ścieżki dowodowej (Merkle Audit Proof), co pozwala klientowi na natychmiastową weryfikację na laptopie w czasie ułamka sekundy.

Zespół studentów ma za zadanie zaimplementować model drzewa Merkle'a dla 8 bloków danych w środowisku laboratoryjnym: wyliczyć skróty liści L1..L8, zagregować je w węzły pośrednie N1..N4, N12, N34 i wyznaczyć Merkle Root. Następnie studenci generują ścieżkę dowodową dla bloku L3, weryfikują jej zgodność z korzeniem, a na koniec symulują podmianę treści bloku L3 i dokumentują odrzucenie dowodu przez algorytm weryfikatora.

W podsumowaniu studenci analizują zastosowanie drzew Merkle'a w technologiach Git, systemach plików ZFS/Btrfs, technologii Blockchain (Bitcoin, Ethereum) oraz rejestrach Certificate Transparency.

1. Przygotowanie katalogu roboczego na stacji Linux: 'mkdir -p ~/lab6-merkle && cd ~/lab6-merkle'.
2. Weryfikacja dostępności pakietu Python 3 oraz narzędzia OpenSSL poleceniem 'python3 --version'.
3. Utworzenie zestawu 8 testowych plików danych reprezentujących transakcje lub fragmenty archiwum: 'blok_1.dat' do 'blok_8.dat' z przykładową zawartością tekstową.
4. Napisanie skryptu 'buduj_merkle.py' implementującego strukturę binarnego drzewa skrótów SHA-256.
5. Krok 1 algorytmu: obliczenie skrótów SHA-256 dla każdego z 8 bloków danych wejściowych (poziom liści: H1, H2, H3, H4, H5, H6, H7, H8).
6. Krok 2 algorytmu: łączenie skrótów w pary i haszowanie węzłów poziomu 1: H12 = SHA256(H1 + H2), H34 = SHA256(H3 + H4), H56 = SHA256(H5 + H6), H78 = SHA256(H7 + H8).
7. Krok 3 algorytmu: haszowanie węzłów poziomu 2: H1234 = SHA256(H12 + H34) oraz H5678 = SHA256(H56 + H78).
8. Krok 4 algorytmu: obliczenie nadrzędnego korzenia drzewa (Merkle Root): ROOT = SHA256(H1234 + H5678).
9. Uruchomienie skryptu 'python3 buduj_merkle.py' i wyświetlenie pełnej struktury drzewa oraz 64-znakowego skrótu Merkle Root.
10. Zapisanie wartości Merkle Root jako publicznego, niezmiennego zobowiązania kryptograficznego (Commitment).
11. Zaprojektowanie ścieżki dowodowej (Merkle Proof) dla bloku danych nr 3 (H3).
12. Zidentyfikowanie niezbędnych skrótów uzupełniających w ścieżce audytowej dla H3: brat H4, węzeł H12 oraz węzeł H5678 (dokładnie 3 skróty zamiast całego archiwum!).
13. Napisanie skryptu weryfikatora 'weryfikuj_dowod_merkle.py', który na podstawie bloku danych 'blok_3.dat', ścieżki dowodowej (H4, H12, H5678) oraz korzenia ROOT sprawdza poprawność przynależności.
14. Wykonanie testu pomyślnego: 'python3 weryfikuj_dowod_merkle.py blok_3.dat dowod_blok3.json ROOT' i potwierdzenie statusu '[SUKCES] Blok danych nalezy do zbioru. Integralnosc potwierdzona'.
15. Analiza złożoności obliczeniowej: wykazanie, że dla 1 000 000 elementów długość ścieżki Merkle Proof wynosi zaledwie 20 skrótów ($log_2(10^6) \approx 20$), co odpowiada 640 bajtom danych.
16. Symulacja ataku manipulacji danymi: modyfikacja jednego bajtu w pliku 'blok_3.dat' (np. zmiana kwoty przelewu).
17. Ponowne uruchomienie weryfikatora ze zmodyfikowanym blokiem i tą samą ścieżką dowodową.
18. Zarejestrowanie natychmiastowego błędu: obliczony korzeń roboczy różni się od zaufanego Merkle Root, co powoduje odrzucenie fałszerstwa.
19. Przeanalizowanie zastosowania drzew Merkle'a w systemie kontroli wersji Git (gdzie każdy commit jest korzeniem drzewa obiektów).
20. Sformułowanie wniosków końcowych do referatu na temat skalowalności weryfikacji integralności w systemach Big Data i chmurach obliczeniowych.

Drzewo Merkle'a (drzewo skrótów, opatentowane przez Ralpha Merkle'a w 1979 r.) jest binarną strukturą drzewiastą, w której liście są skrótami bloków danych, a każdy węzeł niebędący liściem jest skrótem połączenia swoich dzieci. Nadrzędny skrót na szczycie drzewa nosi nazwę korzenia Merkle'a (Merkle Root) i stanowi zwięzłe, kryptograficzne podsumowanie całego zbioru danych.

Największą potęgą drzew Merkle'a jest algorytm dowodu przynależności (Merkle Proof). Aby udowodnić, że dany blok należy do wielkiego zbioru posiadającego znany Merkle Root, nie trzeba przesyłać całego zbioru danych. Wystarczy przesłać badany blok oraz po jednym skrócie 'rodzeństwa' z każdego poziomu drzewa w drodze do korzenia. Złożoność takiego dowodu wynosi zaledwie $O(\log_2 N)$, co pozwala na weryfikację danych w ułamku milisekundy.

Poniżej przedstawiono przykładowy widok konsoli serwera demonstrujący wyliczenie korzenia Merkle Root oraz pomyślną weryfikację pojedynczego bloku za pomocą 3 skrótów dowodowych:

W systemie Git każde zatwierdzenie zmian (Commit) tworzy drzewo Merkle'a reprezentujące stan całego projektu. Skrót commitu (np. 'commit a1b2c3...') jest w istocie korzeniem Merkle Root obejmującym wszystkie pliki i katalogi w repozytorium.

W technologii Blockchain (Bitcoin) transakcje wewnątrz bloku są zorganizowane w drzewo Merkle'a. Dzięki temu tzw. lekkie portfele mobilne (SPV – Simplified Payment Verification) mogą bez pobierania całego kilkusetgigabajtowego łańcucha zweryfikować, czy dana transakcja została zatwierdzona przez sieć.

1. Zrozumienie matematycznej struktury drzew skrótów Merkle'a i ich właściwości hierarchicznych.
2. Wykazanie potęgi logarytmicznej złożoności obliczeniowej $O(\log N)$ w dowodach przynależności (Merkle Proof).
3. Eliminacja konieczności transferu wieloterabajtowych zbiorów danych w procesach audytu integralności.
4. Praktyczna umiejętność implementacji i walidacji ścieżki dowodowej Merkle'a w języku Python.
5. Znajomość zastosowań drzew Merkle'a w architekturze Git, systemach ZFS, chmurach obliczeniowych i sieciach Blockchain.
6. Rekomendacje dotyczące wdrażania struktur Merkle'a w masowych repozytoriach dokumentacji archiwalnej.

Przykładowe wnioski (wzór do sprawozdania): Implementacja drzewa Merkle'a pozwoliła na zrozumienie, jak zaawansowane struktury danych oparte na funkcjach skrótu rewolucjonizują weryfikację spójności olbrzymich zbiorów informacji. Zastosowanie hierarchicznego haszowania umożliwia udowodnienie integralności pojedynczego pliku w zbiorze tysięcy elementów za pomocą ścieżki uwierzytelniającej o logarytmicznej złożoności O(log N). Weryfikacja nienaruszalności całego wolumenu sprowadza się do porównania jednego 256-bitowego skrótu korzenia (Merkle Root), drastycznie redukując obciążenie sieciowe. Wykazano, że mechanizm ten leży u podstaw działania współczesnych systemów kontroli wersji Git, bezpiecznych systemów plików (ZFS, Btrfs) oraz technologii rozproszonych rejestrów blockchain. Zrozumienie drzew skrótów stanowi kluczowy krok w edukacji inżynierskiej w zakresie skalowalnych i bezpiecznych architektur przetwarzania danych.