Laboratorium 5

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

Głównym celem zadania jest opanowanie mechanizmu asynchronicznych powiadomień transakcyjnych (Webhooks) w handlu elektronicznym oraz praktyczna demonstracja wyliczania i weryfikacji kodów uwierzytelniania wiadomości HMAC-SHA256. Studenci poznają zasady ochrony integralności danych przesyłanych pomiędzy operatorem płatności (bramką płatniczą) a systemem e-commerce.

W toku ćwiczenia zespół analizuje strukturę ładunku JSON generowanego przez bramkę, implementuje skrypt walidacji sygnatury w wierszu poleceń z użyciem OpenSSL oraz przeprowadza kontrolowaną symulację ataku manipulacji treścią powiadomienia (np. zmiana statusu płatności na COMPLETED lub podmienienie kwoty). Studenci weryfikują natychmiastowe wykrycie fałszerstwa przez mechanizm HMAC. Wynikiem prac jest zabezpieczony endpoint transakcyjny oraz sprawozdanie techniczne.

Spółka „TechMarket” Sp. z o.o. z Poznania prowadzi popularny sklep internetowy ze sprzętem komputerowym i elektroniką użytkową. Sklep korzysta z zewnętrznej bramki płatności online (odpowiednik PayU, Przelewy24 lub Tpay) do przyjmowania wpłat od klientów za pośrednictwem kart i szybkich przelewów.

Podczas rutynowego audytu bezpieczeństwa stwierdzono krytyczną podatność w module obsługi powiadomień asynchronicznych: adres URL powiadomień sklepu '/api/platnosci/webhook' przyjmował każde żądanie HTTP POST zawierające pole status=COMPLETED i automatycznie zlecał magazynowi wysyłkę towaru, nie weryfikując w ogóle kryptograficznej sygnatury nadawcy.

Oznacza to, że cyberprzestępca mógł wysłać spreparowane żądanie curl bezpośrednio do serwera sklepu, podszywając się pod operatora płatności i wymuszając wysyłkę drogiego laptopa za zamówienie, za które w rzeczywistości nie zapłacił ani grosza. Zarząd spółki nakazał natychmiastowe zablokowanie tej podatności.

Zespół studentów ma za zadanie zaimplementować i przetestować mechanizm weryfikacji podpisu HMAC-SHA256 zgodnie z oficjalnym standardem polskich bramek płatności. Uczestnicy konfigurują wspólny sekret transakcyjny (Second Key), generują poprawny webhook z sygnaturą, tworzą procedurę walidacyjną po stronie sklepu, a następnie przeprowadzają symulację ataku manipulacji kwotą i statusem.

W końcowym etapie prac zespół dokumentuje odporność sklepu na nieautoryzowane powiadomienia oraz formułuje zalecenia dotyczące bezpiecznego przechowywania kluczy API poza kodem źródłowym aplikacji.

1. Przygotowanie środowiska roboczego w systemie Linux: 'mkdir -p ~/lab5-webhook && cd ~/lab5-webhook'.
2. Weryfikacja dostępności pakietów OpenSSL, cURL oraz jq poleceniami 'openssl version' oraz 'jq --version'.
3. Zdefiniowanie poufnego klucza symetrycznego (Second Key) uzgodnionego pomiędzy sklepem a operatorem płatności: 'TajnyKluczSklepu2026!#PayU'.
4. Utworzenie pliku autentycznego powiadomienia transakcyjnego 'webhook_poprawny.json' zawierającego identyfikator zamówienia, kwotę 1999.00 PLN oraz status 'COMPLETED'.
5. Wygenerowanie przez operatora bramki poprawnej sygnatury HMAC-SHA256 za pomocą OpenSSL: 'openssl dgst -sha256 -hmac "TajnyKluczSklepu2026!#PayU" webhook_poprawny.json'.
6. Zapisanie wyliczonego skrótu heksadecymalnego do zmiennej środowiskowej 'PRAWIDLOWY_HMAC'.
7. Opracowanie skryptu weryfikacyjnego 'weryfikuj_webhook.sh' symulującego logikę serwera sklepu internetowego.
8. Wprowadzenie w skrypcie procedury: wyliczenie lokalnego HMAC z odebranego pliku JSON i porównanie z sygnaturą przekazaną w parametrze.
9. Wykonanie testu pozytywnego: uruchomienie skryptu z autentycznym plikiem i poprawną sygnaturą './weryfikuj_webhook.sh webhook_poprawny.json $PRAWIDLOWY_HMAC'.
10. Potwierdzenie komunikatu: '[SKLEP] WERYFIKACJA POZYTYWNA (200 OK): Sygnatura prawidłowa. Zamówienie przekazane do wysyłki'.
11. Przygotowanie spreparowanego powiadomienia 'webhook_falszywy.json' przez cyberprzestępcę (zamiana statusu z 'PENDING' na 'COMPLETED' przy kwocie 1.00 PLN).
12. Próba wysłania sfałszowanego powiadomienia z wykorzystaniem starej sygnatury autentycznej transakcji (atak Replay/Tampering).
13. Uruchomienie skryptu weryfikacyjnego ze sfałszowanym plikiem: './weryfikuj_webhook.sh webhook_falszywy.json $PRAWIDLOWY_HMAC'.
14. Zarejestrowanie natychmiastowego błędu: '[ALARM] BŁĄD WERYFIKACJI (401 Unauthorized): Sygnatura HMAC niepoprawna! Próba fałszerstwa powiadomienia'.
15. Przeanalizowanie dlaczego atakujący nie był w stanie wygenerować poprawnego HMAC (brak znajomości klucza 'TajnyKluczSklepu2026!#PayU').
16. Wykonanie testu podatności na modyfikację pojedynczego znaku w JSON (np. dodanie spacji lub zmiana groszy o 1) i demonstracja efektu lawinowego funkcji SHA-256.
17. Przetestowanie przesyłania sygnatury w nagłówku HTTP żądania cURL: 'curl -X POST -H "X-Signature: ..." -d @webhook_poprawny.json http://localhost/webhook'.
18. Zaprojektowanie bezpiecznego sposobu przechowywania klucza API w zmiennych środowiskowych serwera (pliki .env) zamiast w publicznym repozytorium Git.
19. Opracowanie tabelarycznego porównania mechanizmów: prosty token statyczny vs kryptograficzny kod HMAC-SHA256.
20. Sformułowanie wniosków technicznych dotyczących bezpieczeństwa integracji B2B w handlu elektronicznym.

Mechanizm HMAC (Hash-based Message Authentication Code, RFC 2104) łączy kryptograficzną funkcję skrótu (np. SHA-256) z tajnym kluczem symetrycznym. W przeciwieństwie do zwykłej sumy kontrolnej SHA-256, której obliczenie jest dostępne dla każdego, kod HMAC może obliczyć i zweryfikować wyłącznie podmiot znający tajny klucz.

W integracjach e-commerce (np. PayU, Przelewy24, Stripe) powiadomienie transakcyjne wysyłane jest w ciele żądania POST, a sygnatura HMAC umieszczana jest w dedykowanym nagłówku odpowiedzi (np. 'OpenPayu-Signature' lub 'X-Signature'). Sklep przed przetworzeniem zamówienia musi bezwzględnie przeliczyć HMAC z surowego ciągu bajtów żądania.

Poniżej przedstawiono przykładowy widok konsoli serwera Linux podczas generowania poprawnej sygnatury HMAC oraz demonstracji odrzucenia sfałszowanego webhooka:

Zwróć uwagę na problem kanoniczności danych JSON (JSON Canonicalization). W produkcyjnych systemach formatowanie tekstu (białe znaki, spacje, kolejność kluczy) może ulec zmianie podczas przesyłania przez sieć. Bramki płatności często wymagają wyliczania HMAC ze ściśle zdefiniowanego ciągu parametrów lub surowego strumienia bajtów odebranych z gniazda HTTP.

W sprawozdaniu wyjaśnij różnicę pomiędzy atakiem na integralność danych (Tampering) a atakiem powtórzeniowym (Replay Attack). Sam HMAC chroni przed modyfikacją treści, jednak ochrona przed ponownym przesłaniem tego samego poprawnego webhooka wymaga stosowania unikalnych identyfikatorów zamówień oraz wektorów Nonce (ćwiczenie 03).

1. Zrozumienie kryptograficznej zasady działania kodów uwierzytelniania wiadomości HMAC-SHA256.
2. Wykazanie bezpośredniego związku pomiędzy brakiem weryfikacji sygnatury webhooka a ryzykiem strat finansowych w sklepie e-commerce.
3. Rola wspólnego sekretu transakcyjnego (Shared Secret) w zapewnieniu autentyczności pochodzenia wiadomości.
4. Znaczenie efektu lawinowego funkcji SHA-256 w natychmiastowym wykrywaniu modyfikacji kwoty transakcji.
5. Dobre praktyki bezpiecznego zarządzania kluczami API i ich separacji od kodu źródłowego aplikacji.
6. Rekomendacje dotyczące audytu modułów płatności w sklepach internetowych zgodnie z wymogami PCI DSS.

Przykładowe wnioski (wzór do sprawozdania): Implementacja mechanizmu weryfikacji powiadomień Webhook za pomocą kodów HMAC-SHA256 udowodniła, że integralność komunikatów transakcyjnych jest warunkiem koniecznym do zabezpieczenia sklepu przed stratami finansowymi. Symulacja ataku polegającego na modyfikacji kwoty zamówienia w formacie JSON wykazała, że brak znajomości tajnego klucza (Shared Secret) uniemożliwia napastnikowi wygenerowanie poprawnego podpisu kryptograficznego. Wykorzystanie funkcji skrótu SHA-256 w konstrukcji HMAC gwarantuje, że zmiana chociażby jednego bajtu treści wywołuje drastyczną zmianę sygnatury w wyniku efektu lawinowego. Odrzucenie sfałszowanego powiadomienia statusem 401 Unauthorized uchroniło system przed nieuprawnioną wysyłką towaru. Wdrożona procedura w pełni realizuje wytyczne bezpieczeństwa transakcji elektronicznych określone w międzynarodowym standardzie PCI DSS.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Efekty uczenia się: W1, W4, U1, U2, U4, K1, K3.

Celem ćwiczenia jest praktyczne zrozumienie wymogów Silnego Uwierzytelniania Klienta (Strong Customer Authentication – SCA) wprowadzonego przez unijną dyrektywę PSD2 (Payment Services Directive 2) oraz standardy techniczne RTS EBA. Studenci poznają zasady działania trójskładnikowego modelu uwierzytelniania (wiedza, posiadanie, cecha klienta).

W toku laboratorium zespół implementuje i testuje mechanizm uwierzytelniania dwuskładnikowego (2FA) oparty na algorytmie jednorazowych haseł czasowych TOTP (Time-based One-Time Password, RFC 6238) za pomocą narzędzia Oathtool w systemie Linux. Studenci analizują koncepcję dynamicznego łączenia transakcji (Dynamic Linking), weryfikują odporność na phishing i ataki Man-in-the-Middle oraz przygotowują raport audytorski zgodności z PSD2.

Spółdzielczy Bank Finansowy „Vistula” w Płocku modernizuje portal bankowości elektronicznej dla klientów indywidualnych i korporacyjnych. Zgodnie z wytycznymi Komisji Nadzoru Finansowego (KNF) oraz art. 97 dyrektywy PSD2, bank musi bezwzględnie stosować Silne Uwierzytelnianie Klienta (SCA) przy każdym logowaniu do konta oraz przy autoryzacji elektronicznych operacji płatniczych.

Wcześniejszy mechanizm autoryzacji przelewów opierał się na papierowych kartach kodów jednorazowych (karty zdrapki) lub prostych hasłach SMS. Inspekcja bezpieczeństwa wykazała, że kody SMS są podatne na przechwycenie w wyniku ataku wymiany karty SIM (SIM-Swap Scam) oraz podatne na fałszywe strony pośredniczące (phishing z przejęciem sesji).

Zarząd banku podjął decyzję o wdrożeniu nowoczesnego mechanizmu 2FA opartego na standardzie TOTP (generatory programowe Google Authenticator / FreeOTP) zintegrowanego z dynamicznym łączeniem operacji: kod autoryzacyjny musi być kryptograficznie powiązany z kwotą przelewu i numerem rachunku odbiorcy.

Zespół studentów wciela się w inżynierów bezpieczeństwa bankowego. Zadanie polega na skonfigurowaniu generatora klucza sekretnego w formacie Base32, symulacji generowania 6-cyfrowych kodów TOTP w 30-sekundowych oknach czasowych, weryfikacji przesunięcia zegara (Clock Drift) oraz zaprojektowaniu schematu dynamicznego łączenia parametrów przelewu.

W końcowym etapie prac zespół przeprowadza audyt zgodności procedury z kryteriami niezależności składników uwierzytelniania oraz formułuje zalecenia dotyczące postępowania w przypadku utraty urządzenia uwierzytelniającego przez klienta.

1. Przygotowanie środowiska testowego na stacji Linux i instalacja narzędzia oathtool poleceniem 'sudo apt-get install -y oathtool' (lub weryfikacja dostępności).
2. Utworzenie bezpiecznego katalogu roboczego 'mkdir -p ~/lab5-sca && cd ~/lab5-sca'.
3. Wygenerowanie losowego, 160-bitowego (20 bajtów) klucza sekretnego w formacie Base32 dla konta klienta banku: 'openssl rand 20 | base32 | tr -d '=' | cut -c 1-32 > klient_secret.key'.
4. Wyświetlenie wygenerowanego sekretu (np. 'JBSWY3DPEHPK3PXPJBSWY3DPEHPK3PXP') i zrozumienie jego roli jako współdzielonego sekretu TOTP.
5. Wygenerowanie aktualnego, 6-cyfrowego kodu TOTP za pomocą narzędzia oathtool: 'oathtool --totp -b $(cat klient_secret.key)'.
6. Odnotowanie wartości kodu oraz zaobserwowanie zmiany kodu po upływie 30 sekund (zgodnie ze standardem RFC 6238).
7. Uruchomienie skryptu monitorującego generowanie kodów w czasie rzeczywistym z odliczaniem czasu do końca okna czasowego (Time Step).
8. Opracowanie skryptu weryfikacyjnego 'sprawdz_kod_bank.sh', który sprawdza poprawność kodu wprowadzonego przez klienta.
9. Wprowadzenie tolerancji błędu przesunięcia zegara (Window = 1, akceptacja kodu z poprzedniego i następnego okna 30s): 'oathtool --totp -b -w 1 $(cat klient_secret.key)'.
10. Przetestowanie poprawnego logowania: wprowadzenie aktualnego kodu i weryfikacja zatwierdzenia autoryzacji.
11. Przetestowanie próby użycia kodu przedawnionego (sprzed 2 minut) i potwierdzenie odrzucenia autoryzacji.
12. Zaimplementowanie wymogu dyrektywy PSD2 dotyczącego 'Dynamicznego Łączenia' (Dynamic Linking): połączenie parametrów przelewu (kwota 5000 PLN, rachunek odbiorcy PL611090...) z danymi uwierzytelniającymi.
13. Obliczenie kryptograficznego skrótu transakcji: 'HASH_TRANSAKCJI=$(echo -n "5000.00:PL61109010140000071219812874" | sha256sum | cut -c 1-8)'.
14. Wygenerowanie unikalnego kodu autoryzacji transakcyjnej z uwzględnieniem skrótu operacji.
15. Weryfikacja, że próba zmiany numeru rachunku odbiorcy powoduje całkowitą nieważność wygenerowanego kodu.
16. Analiza trójskładnikowego modelu SCA: identyfikacja elementu wiedzy (hasło do banku), elementu posiadania (smartfon z generatorem TOTP) oraz cechy klienta (biometria).
17. Przeanalizowanie podatności kodów TOTP na phishing w czasie rzeczywistym (Real-time Reverse Proxy / Evilginx) i omówienie standardu FIDO2/WebAuthn jako docelowej ochrony.
18. Opracowanie procedury awaryjnej: weryfikacja tożsamości klienta i procedury unieważnienia klucza TOTP w przypadku kradzieży telefonu.
19. Sporządzenie tabelarycznego zestawienia metod 2FA (SMS OTP, TOTP, Powiadomienie PUSH, Klucz FIDO2 U2F) pod kątem wygody i odporności na ataki.
20. Przygotowanie sprawozdania audytorskiego oceniającego zgodność wdrożonego rozwiązania z art. 97 PSD2 i wytycznymi EBA.

Algorytm TOTP (Time-based One-Time Password) jest wariantem algorytmu HOTP, w którym licznik zdarzeń został zastąpiony liczbą 30-sekundowych interwałów czasowych, jakie upłynęły od początku epoki Uniksa (1 stycznia 1970 r.). Wzór opiera się na funkcji: TOTP = Truncate(HMAC-SHA1(K, T)), gdzie T = floor(UnixTime / 30).

Wymóg 'Dynamicznego Łączenia' (Dynamic Linking) zdefiniowany w art. 97 ust. 2 dyrektywy PSD2 nakazuje, aby kod uwierzytelniający transakcję płatniczą był powiązany z kwotą transakcji oraz odbiorcą wskazanym przez płatnika. Zabezpiecza to klienta przed atakiem typu Man-in-the-Browser, w którym złośliwe oprogramowanie na komputerze podmienia numer konta w locie.

Poniżej przedstawiono przykładowy widok konsoli demonstrujący generowanie i walidację kodu TOTP oraz weryfikację z tolerancją okna czasowego za pomocą oathtool:

W praktyce bankowej klucz sekretny Base32 jest prezentowany klientowi w formie graficznego kodu QR podczas rejestracji urządzenia (format URI: 'otpauth://totp/BankVistula:jan.kowalski?secret=...&issuer=BankVistula'). Użytkownik skanuje kod aplikacją w telefonie, co automatycznie konfiguruje generator.

W środowisku serwerowym klucz sekretny użytkownika musi być bezwzględnie zaszyfrowany w bazie danych (np. za pomocą AES-256), a nie przechowywany w postaci otwartego tekstu. Dostęp do bazy kluczy powinien być chroniony sprzętowym modułem HSM.

1. Zrozumienie wymogów prawnych dyrektywy PSD2 i standardów RTS EBA w zakresie Silnego Uwierzytelniania Klienta (SCA).
2. Znajomość trzech kategorii składników uwierzytelniania (Wiedza, Posiadanie, Niezmienna cecha).
3. Praktyczne zrozumienie algorytmu TOTP (RFC 6238) i mechanizmu okien czasowych z tolerancją przesunięcia zegarów.
4. Rola dynamicznego łączenia transakcji (Dynamic Linking) w eliminacji podatności na modyfikację parametrów przelewu.
5. Identyfikacja słabości tradycyjnych kodów SMS w porównaniu z generatorami programowymi i sprzętowymi tokenami FIDO2.
6. Wytyczne dotyczące procedur zarządzania cyklem życia poświadczeń 2FA w systemach bankowości elektronicznej.

Przykładowe wnioski (wzór do sprawozdania): Analiza wymogów unijnej dyrektywy PSD2 potwierdziła, że tradycyjne uwierzytelnianie jednoskładnikowe oparte wyłącznie na haśle statycznym nie spełnia współczesnych standardów bezpieczeństwa bankowości internetowej. Implementacja standardu TOTP (RFC 6238) za pomocą narzędzia oathtool z powodzeniem połączyła element wiedzy (hasło klienta) z elementem posiadania (generator kodów w aplikacji mobilnej). Ograniczenie czasu ważności kodu jednorazowego do 30 sekund skutecznie zapobiega jego powtórnemu wykorzystaniu przez intruza w razie podsłuchania transmisji. Zastosowanie Silnego Uwierzytelniania Klienta (SCA) drastycznie ogranicza skuteczność masowych ataków phishingowych oraz wycieków baz danych poświadczeń. Wyniki zadania dowodzą, że wymogi regulacyjne PSD2 przyczyniły się do fundamentalnego podniesienia odporności europejskiego sektora płatności cyfrowych.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Kon4 Autoryzacja i uwierzytelnianie w systemach komputerowych. Efekty uczenia się: W1, W3, U1, U3, U4, K1, K2.

Celem zadania jest praktyczne zrozumienie zagrożenia atakami powtórzeniowymi (ang. Replay Attacks) w protokołach transakcji elektronicznych oraz opanowanie kryptograficznych technik ich mitygacji. Studenci dowiadują się, dlaczego samo szyfrowanie i podpis cyfrowy nie chronią przed ponownym przesłaniem przechwyconego pakietu autoryzacyjnego.

W trakcie laboratorium zespół analizuje mechanizm działania jednorazowych wektorów losowych (Nonce – Number used Once) oraz znaczników czasu (Timestamps) wbudowywanych w komunikaty płatnicze. Studenci implementują i testują procedurę walidacji unikalności wektora Nonce oraz sprawdzania okna ważności znacznika czasu w środowisku Linux CLI, a następnie symulują próbę podwójnego obciążenia rachunku klienta. Zadanie kończy się raportem technicznym.

Firma Pożyczkowa „Szybki-Kredyt” w Toruniu udostępnia aplikację mobilną umożliwiającą klientom zaciąganie krótkoterminowych pożyczek oraz zlecanie spłat rat kredytowych za pośrednictwem bezpiecznego API serwera transakcyjnego.

Podczas audytu kodu źródłowego systemu wykryto poważną podatność logiczną: endpoint API spłaty raty '/api/v1/pozyczka/splata' weryfikował poprawność podpisu kryptograficznego zlecenia, lecz nie rejestrował unikalnych identyfikatorów zapytań ani czasu ich nadania. W rezultacie, jeżeli nieuczciwy pracownik sieci lub osoba podsłuchująca ruch przechwyciła poprawnie podpisany pakiet zlecenia przelewu na kwotę 500 PLN, mogła wysłać ten sam pakiet dziesięciokrotnie, powodując wielokrotne pobranie środków z konta pożyczkobiorcy bez konieczności łamania szyfrów.

Taka luka stwarza bezpośrednie zagrożenie kradzieży środków oraz paraliżu operacyjnego instytucji finansowej. Zarząd spółki polecił zespołowi inżynierów wdrożenie standardu ochrony przed atakami powtórzeniowymi opartego na połączeniu 128-bitowego kryptograficznego wektora Nonce z krótkim oknem ważności znacznika czasu Timestamp (maksymalnie 60 sekund).

Zespół studentów ma za zadanie zaimplementować mechanizm pamięci podręcznej zużytych wektorów Nonce (Replay Cache) oraz procedurę odrzucania przeterminowanych lub zduplikowanych transakcji. Studenci przygotowują autentyczny komunikat transakcyjny, generują dla niego wektor Nonce i znacznik czasu, podpisują go kodem HMAC, a następnie symulują próbę ponownego wykonania tej samej operacji.

W podsumowaniu studenci analizują optymalizację pamięci podręcznej (usuwanie starych wektorów Nonce po wygaśnięciu okna czasowego) oraz formułują wytyczne dla programistów systemów bankowych i fintech.

1. Przygotowanie katalogu roboczego w środowisku Linux: 'mkdir -p ~/lab5-replay && cd ~/lab5-replay'.
2. Weryfikacja dostępności narzędzi 'openssl', 'date', 'awk' oraz 'grep'.
3. Zdefiniowanie tajnego klucza symetrycznego API: 'KluczInstytucjiFinansowej2026!'.
4. Przygotowanie struktury komunikatu transakcyjnego zawierającego parametry: 'id_klienta', 'kwota', 'rachunek_docelowy', 'timestamp' oraz 'nonce'.
5. Wygenerowanie 128-bitowego kryptograficznego wektora losowego Nonce za pomocą OpenSSL: 'NONCE=$(openssl rand -hex 16)'.
6. Pobranie aktualnego znacznika czasu w formacie uniksowym: 'TIMESTAMP=$(date +%s)'.
7. Złożenie pełnego komunikatu zlecenia spłaty raty: 'KOMUNIKAT="klient=98124&kwota=500.00&rachunek=PL551020...&ts=$TIMESTAMP&nonce=$NONCE"'.
8. Wyliczenie sygnatury HMAC-SHA256 z pełnego komunikatu: 'SIGNATURE=$(echo -n "$KOMUNIKAT" | openssl dgst -sha256 -hmac "KluczInstytucjiFinansowej2026!" | awk '{print $2}')'.
9. Utworzenie bazy pamięci podręcznej zużytych wektorów: 'touch ~/lab5-replay/used_nonces.db'.
10. Napisanie skryptu weryfikatora serwera transakcyjnego 'procesuj_transakcje.sh'.
11. Zaimplementowanie w skrypcie warunku 1: sprawdzenie poprawności sygnatury HMAC.
12. Zaimplementowanie w skrypcie warunku 2: sprawdzenie wieku znacznika czasu (odrzucenie jeśli obecny_czas - timestamp > 60 sekund lub timestamp z przyszłości).
13. Zaimplementowanie w skrypcie warunku 3: sprawdzenie obecności wektora Nonce w pliku 'used_nonces.db' (odrzucenie jeśli wektor już istnieje).
14. Zaimplementowanie rejestracji nowego wektora Nonce w bazie w przypadku pomyślnej weryfikacji.
15. Wykonanie testu pierwotnej transakcji: pomyślne zatwierdzenie zlecenia i obciążenie konta (status: 200 OK, Transakcja zrealizowana).
16. Symulacja ataku Replay: wysłanie dokładnie tego samego komunikatu z tą samą sygnaturą po raz drugi.
17. Zarejestrowanie reakcji serwera: wykrycie zduplikowanego wektora Nonce i natychmiastowe odrzucenie transakcji (status: 409 Conflict / Replay Attack Detected).
18. Symulacja próby ataku po upływie 2 minut z wygenerowanym nowym Nonce, lecz starym znacznikiem czasu: zarejestrowanie błędu przekroczenia okna czasowego (status: 408 Request Timeout / Stale Timestamp).
19. Przeanalizowanie procedury automatycznego czyszczenia bazy Nonce (usuwanie rekordów starszych niż 60 sekund w celu ochrony pamięci RAM serwera).
20. Sformułowanie wniosków końcowych dotyczących roli znaczników czasu i wektorów Nonce w protokołach finansowych (SWIFT, OAuth 2.0, Kerberos).

Wektor Nonce (Number used Once) jest unikalnym, losowym ciągiem znaków generowanym przez klienta dla każdego pojedynczego żądania. Serwer przechowuje odebrane wartości Nonce w szybkiej pamięci podręcznej (np. w pamięci Redis lub bazie in-memory). Ponowne pojawienie się tego samego identyfikatora jest jednoznacznym dowodem próby ataku powtórzeniowego.

Gdyby stosować wyłącznie wektory Nonce bez znaczników czasu, serwer musiałby przechowywać wszystkie kiedykolwiek użyte wektory w nieskończoność, co doprowadziłoby do przepełnienia pamięci RAM. Wprowadzenie znacznika czasu Timestamp ogranicza czas życia wektora Nonce (np. do 60 sekund). Po upływie 60 sekund żądanie jest odrzucane z powodu przeterminowania, a stary wektor Nonce można bezpiecznie usunąć z bazy.

Poniżej przedstawiono przykładowy widok konsoli serwera demonstrujący realizację pierwszej transakcji oraz zablokowanie natychmiastowej próby powtórzenia:

W systemach rozproszonych kluczowe znaczenie ma synchronizacja czasu serwerów za pomocą protokołu NTP (Network Time Protocol). Jeżeli zegar serwera aplikacji różni się od zegara bramki o więcej niż zdefiniowane okno czasowe, legalne transakcje będą odrzucane jako przeterminowane.

Wektor Nonce musi pochodzić z kryptograficznie bezpiecznego generatora liczb pseudolosowych (CSPRNG, np. '/dev/urandom' lub funkcja 'openssl rand'). Stosowanie przewidywalnych liczników sekwencyjnych (1, 2, 3...) pozwala atakującemu na odgadnięcie kolejnego wektora i przeprowadzenie ataku wyprzedzającego (Race Condition).

1. Zrozumienie istoty ataku powtórzeniowego (Replay Attack) i przyczyn, dla których szyfrowanie danych przed nim nie chroni.
2. Rola kryptograficznego wektora Nonce w zapewnieniu jednorazowości komunikatu transakcyjnego.
3. Współpraca znacznika czasu Timestamp z wektorem Nonce w optymalizacji zużycia pamięci podręcznej serwera.
4. Znaczenie synchronizacji zegarów sieciowych (NTP) w rozproszonych architekturach finansowych.
5. Analiza konsekwencji prawnych i finansowych podwójnego zaksięgowania środków w instytucjach pożyczkowych.
6. Rekomendacje dotyczące implementacji mechanizmów idempotencyjności w nowoczesnych interfejsach REST API.

Przykładowe wnioski (wzór do sprawozdania): Eksperymentalne badanie podatności transakcji finansowych wykazało, że nawet poprawnie zaszyfrowany i opatrzony kodem HMAC komunikat jest bezbronny wobec ataku powtórzeniowego (Replay Attack), jeżeli nie posiada mechanizmów unikalności czasowej. Wprowadzenie kryptograficznego wektora Nonce weryfikowanego w pamięci podręcznej serwera gwarantuje, że każde żądanie przelewu może zostać zrealizowane dokładnie jeden raz. Zastosowanie znacznika czasu (Timestamp) z rygorystycznym oknem tolerancji (np. 120 sekund) skutecznie chroni bazę danych przed nieograniczonym rozrostem rejestru zużytych identyfikatorów. Połączenie sumy HMAC z parametrami Nonce i Timestamp tworzy kompletny mechanizm zabezpieczający transakcję zarówno przed modyfikacją treści, jak i przed jej ponownym wysłaniem przez oszusta. Zaprojektowana architektura stanowi niezbędny standard we wszystkich nowoczesnych interfejsach API instytucji finansowych i bramek płatniczych.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Sieciowe systemy składowania danych i kontrola przepływu. Efekty uczenia się: W1, W4, U1, U2, U4, K1, K3.

Celem ćwiczenia jest praktyczne opanowanie zasad projektowania bezpiecznej architektury sieciowej oraz logicznej segmentacji strefy danych posiadaczy kart płatniczych (Cardholder Data Environment – CDE) w placówce handlowej zgodnie z rygorystycznymi wymogami międzynarodowego standardu PCI DSS 4.0. Studenci poznają reguły izolacji terminali POS na urządzeniu MikroTik RouterOS.

W trakcie laboratorium zespół konfiguruje dedykowaną wirtualną sieć lokalną (VLAN 30 – Strefa POS), konfiguruje serwer DHCP z restrykcyjnymi parametrami, wdraża reguły zapory sieciowej blokujące jakikolwiek ruch pomiędzy terminalami płatniczymi a stacjami biurowymi lub publiczną siecią Wi-Fi oraz konfiguruje bezpieczny tunel IPsec do centrum autoryzacji płatności. Zadanie kończy się audytem szczelności segmentacji za pomocą skanera Nmap oraz sprawozdaniem technicznym.

Spółdzielnia Handlowa „Społem-Centrum” w Bydgoszczy prowadzi sieć 12 supermarketów spożywczych. W każdym sklepie funkcjonuje od 6 do 10 stanowisk kasowych wyposażonych w stacjonarne terminale płatnicze POS podłączone do sieci przewodowej Ethernet, a także sieć komputerowa biura kierownika oraz bezprzewodowa sieć Wi-Fi dla klientów marketu.

Podczas audytu certyfikującego do standardu PCI DSS audytor bezpieczeństwa organizacji płatniczych Visa/Mastercard stwierdził rażące naruszenie Wymogu 1 („Instalowanie i utrzymywanie zabezpieczeń sieciowych”): terminale płatnicze POS pracowały w tej samej płaskiej podsieci 192.168.1.0/24 co stacje biurowe oraz punkty dostępowe Wi-Fi. W przypadku zainfekowania komputera w biurze trojanem szpiegującym, złośliwe oprogramowanie mogło podsłuchiwać pakiety sieciowe przesyłane z terminali kasowych.

Spółdzielni zagrożono nałożeniem miesięcznych kar finansowych w wysokości kilkunastu tysięcy euro oraz zablokowaniem możliwości akceptowania płatności bezgotówkowych. Zarząd zlecił pilną rekonfigurację routera brzegowego MikroTik RouterOS w celu stworzenia całkowicie odizolowanej strefy CDE.

Zespół studentów ma za zadanie zaimplementować bezpieczną architekturę sieciową na routerze MikroTik. Grupa tworzy odrębny interfejs VLAN 30 dla terminali POS, konfiguruje dedykowaną adresację IP (10.30.0.0/24), wdraża bezwzględną blokadę komunikacji pomiędzy VLAN 30 a pozostałymi sieciami marketu oraz zezwala terminalom wyłącznie na nawiązywanie szyfrowanych połączeń na porty serwerów autoryzacyjnych operatora płatności.

Końcowym etapem jest przeprowadzenie testów penetracyjnych szczelności zapory ze stacji biurowej oraz ze stacji w sieci Wi-Fi, potwierdzających całkowity brak widoczności terminali POS.

1. Zalogowanie się do konsoli routera MikroTik RouterOS za pomocą bezpiecznego terminala SSH lub oprogramowania WinBox.
2. Weryfikacja aktualnej konfiguracji interfejsów mostka sieciowego: '/interface bridge print'.
3. Utworzenie dedykowanego interfejsu VLAN dla terminali płatniczych POS: '/interface vlan add name=vlan30-pos vlan-id=30 interface=bridge comment="Strefa Kartowa PCI-DSS CDE"'.
4. Przypisanie dedykowanej puli adresowej dla strefy POS: '/ip address add address=10.30.0.1/24 interface=vlan30-pos network=10.30.0.0'.
5. Utworzenie puli adresów IP dla terminali kasowych: '/ip pool add name=pos-pool ranges=10.30.0.10-10.30.0.50'.
6. Skonfigurowanie dedykowanego serwera DHCP dla strefy CDE: '/ip dhcp-server add name=dhcp-pos interface=vlan30-pos address-pool=pos-pool lease-time=1d disabled=no'.
7. Skonfigurowanie sieci DHCP z bramą domyślną i bezpiecznymi serwerami DNS: '/ip dhcp-server network add address=10.30.0.0/24 gateway=10.30.0.1 dns-server=10.30.0.1'.
8. Zdefiniowanie listy adresowej dla zewnętrznych serwerów autoryzacji płatności (Payment Acquirer): '/ip firewall address-list add list=acquirer-servers address=195.150.200.5 comment="Centrum Autoryzacji Platnosci"'.
9. Wdrożenie reguły zezwalającej terminalom POS wyłącznie na ruch do autoryzowanych serwerów płatności na porcie 443/8443: '/ip firewall filter add chain=forward src-address=10.30.0.0/24 dst-address-list=acquirer-servers protocol=tcp dst-port=443,8443 action=accept comment="Zezwol na autoryzacje POS" place-before=1'.
10. Wdrożenie reguły zezwalającej na powracający ruch established/related: '/ip firewall filter add chain=forward connection-state=established,related action=accept place-before=0'.
11. Wdrożenie bezwzględnej blokady wszelkiego pozostałego ruchu wychodzącego ze strefy POS: '/ip firewall filter add chain=forward src-address=10.30.0.0/24 action=drop comment="Blokuj nieautoryzowany ruch z POS (PCI DSS)"'.
12. Wdrożenie bezwzględnej blokady wszelkiego ruchu wchodzącego do strefy POS z innych podsieci LAN i Wi-Fi: '/ip firewall filter add chain=forward dst-address=10.30.0.0/24 action=drop comment="Blokuj dostep do POS z biura i Wi-Fi"'.
13. Blokada dostępu ze strefy POS do interfejsu zarządzania routerem (WebFig/SSH/WinBox): '/ip firewall filter add chain=input in-interface=vlan30-pos action=drop comment="Blokuj zarzadzanie routerem ze strefy POS"'.
14. Włączenie filtrowania VLAN na mostku: '/interface bridge set bridge vlan-filtering=yes'.
15. Podłączenie stacji audytorskiej Linux/Windows do portu przypisanego do sieci biurowej (VLAN 10 lub domyślny LAN).
16. Wykonanie skanowania sieci POS za pomocą narzędzia Nmap: 'nmap -sS -p 1-1024 10.30.0.10' w celu weryfikacji braku widoczności terminala.
17. Potwierdzenie stanu portów jako 'filtered' oraz braku odpowiedzi ICMP echo (ping 10.30.0.10 -> Request timed out).
18. Podłączenie stacji testowej do portu VLAN 30 i weryfikacja poprawnego pobrania adresu z puli 10.30.0.x.
19. Weryfikacja możliwości nawiązania połączenia wyłącznie z adresem centrum autoryzacji płatności na porcie 443.
20. Sporządzenie raportu audytorskiego potwierdzającego spełnienie Wymogu 1 normy PCI DSS 4.0 wraz z diagramem segmentacji.

Zgodnie ze standardem PCI DSS (Payment Card Industry Data Security Standard) strefa danych posiadaczy kart (CDE) obejmuje wszystkie komponenty sieciowe, serwery i urządzenia, które przechowują, przetwarzają lub przesyłają dane kartowe (numery PAN, daty ważności). Prawidłowa segmentacja sieciowa za pomocą VLAN i reguł zapory ogniowej pozwala na radykalne zawężenie zakresu audytu wyłącznie do wyizolowanego segmentu CDE, obniżając koszty certyfikacji.

W systemie MikroTik RouterOS filtrowanie ruchu pomiędzy sieciami VLAN realizowane jest w łańcuchu 'forward' zapory sieciowej (/ip firewall filter). Kluczowa zasada bezpieczeństwa nakazuje stosowanie polityki 'Default Deny' – najpierw definiuje się precyzyjne reguły zezwalające na niezbędną komunikację biznesową, a na końcu umieszcza się bezwzględną regułę odrzucającą (drop) cały pozostały ruch.

Poniżej przedstawiono listing reguł filtrujących zapory MikroTik zabezpieczających strefę terminali POS zgodnie z PCI DSS:

Nigdy nie zezwalaj urządzeniom w strefie POS na swobodne korzystanie z publicznych serwerów DNS (np. 8.8.8.8). Zapytania DNS powinny być rozwiązywane wyłącznie przez lokalny router lub wyznaczony wewnętrzny serwer DNS w celu zapobiegania atakom zatruwania pamięci podręcznej DNS (DNS Cache Poisoning).

W środowisku sklepowym kable sieciowe łączące terminale kasowe z gniazdami sieciowymi powinny być zabezpieczone przed fizycznym odpięciem, a nieużywane porty w przełącznikach sieciowych muszą być bezwzględnie programowo wyłączone (disabled) lub przypisane do odizolowanego 'czarnego' VLAN-u (tzw. Blackhole VLAN).

1. Zrozumienie wymogów Wymogu 1 i 2 międzynarodowego standardu PCI DSS 4.0.
2. Rola logicznej segmentacji sieci (VLAN) w izolacji strefy danych kartowych (CDE) od sieci korporacyjnej i gościnnej.
3. Skuteczność polityki domyślnego blokowania (Default Deny) w eliminacji bocznego rozprzestrzeniania się zagrożeń (Lateral Movement).
4. Znaczenie ograniczenia ruchu wychodzącego wyłącznie do autoryzowanych adresów IP centrów rozliczeniowych.
5. Praktyczna weryfikacja szczelności reguł firewall za pomocą skanerów portów (Nmap).
6. Rekomendacje dotyczące okresowych przeglądów reguł zapory ogniowej w placówkach handlu detalicznego.

Przykładowe wnioski (wzór do sprawozdania): Zaprojektowanie bezpiecznej strefy danych kartowych (CDE) na routerze MikroTik wykazało kluczową rolę segmentacji sieciowej w spełnieniu rygorystycznych wymagań standardu PCI DSS. Fizyczna i logiczna izolacja terminali płatniczych POS w dedykowanym VLAN-ie uniemożliwia podsłuch transmisji przez zainfekowane stacje robocze personelu biurowego. Konfiguracja reguł zapory sieciowej odcinających bezpośredni ruch pomiędzy terminalami a siecią lokalną radykalnie zawęża wektory potencjalnego ataku. Zezwolenie wyłącznie na wychodzący ruch szyfrowany TLS do zautoryzowanych adresów IP centrum autoryzacji kart eliminuje ryzyko wycieku numerów PAN. Wdrożona polityka udowadnia, że precyzyjna separacja ruchu na poziomie przełączników i routerów brzegowych jest najtańszym i najskuteczniejszym środkiem ochrony infrastruktury płatniczej.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Architektura PKI i certyfikaty X.509. Efekty uczenia się: W4, U1, U2, U4, K1, K2.

Głównym celem zadania jest opanowanie zaawansowanego mechanizmu wzajemnego uwierzytelniania kryptograficznego mTLS (Mutual TLS / Two-Way SSL) w architekturze komunikacji maszyna-maszyna (M2M / B2B). Studenci poznają zasady konfiguracji serwera WWW Apache oraz klienta sieciowego cURL, w którym nie tylko serwer uwierzytelnia się przed klientem, lecz także klient musi przedstawić ważny certyfikat cyfrowy podpisany przez zaufany urząd CA.

W toku laboratorium zespół tworzy infrastrukturę certyfikatów dla platformy B2B, konfiguruje dyrektywy SSLVerifyClient oraz SSLCACertificateFile w serwerze Apache, generuje klucze i certyfikaty dla stacji klienta oraz przeprowadza testy dostępu. Studenci weryfikują zachowanie serwera w przypadku próby połączenia bez certyfikatu klienta lub z certyfikatem niepodpisanym przez uprawnione CA. Wynikiem prac jest w pełni zabezpieczony interfejs API oraz sprawozdanie techniczne.

Spółka FinTech „Pay-Gate Polska” w Warszawie świadczy usługi pośrednictwa płatności hurtowych dla platform e-commerce i sieci handlowych. Komunikacja pomiędzy serwerami sklepów internetowych a interfejsem API bramki płatniczej ('https://api.paygate.local/transakcje') służy do inicjowania przelewów wielotysięcznych kwot oraz pobierania raportów rozliczeniowych.

Dotychczasowe zabezpieczenie API opierało się wyłącznie na standardowym szyfrowaniu HTTPS (uwierzytelnienie jednostronne serwera) oraz tokenie Bearer API-Key przesyłanym w nagłówku żądania HTTP. W trakcie audytu bezpieczeństwa wykazano, że w przypadku wycieku tokena API (np. w wyniku błędu programisty publikującego kod w repozytorium GitHub), osoba trzecia może swobodnie łączyć się z API bramki z dowolnego miejsca na świecie i wykonywać operacje finansowe w imieniu sklepu.

Główny architekt bezpieczeństwa podjął decyzję o wdrożeniu wzajemnego uwierzytelniania mTLS dla wszystkich partnerów B2B. Od tej pory serwer bramki płatniczej akceptuje wyłącznie połączenia TCP od klientów, którzy w trakcie negocjacji TLS Handshake przedstawią ważny certyfikat klienta X.509 wystawiony bezpośrednio przez prywatny Urząd Certyfikacji operatora płatności.

Zespół studentów wciela się w inżynierów bezpieczeństwa wdrażających mTLS w środowisku Linux / Apache. Grupa ma za zadanie wygenerować certyfikat urzędu CA bramki, skonfigurować wirtualnego hosta Apache z wymogiem 'SSLVerifyClient require', wygenerować certyfikat kliencki dla sklepu partnerskiego oraz przetestować połączenia za pomocą narzędzia cURL z użyciem certyfikatów.

Końcowym etapem jest udowodnienie, że nawet posiadanie poprawnego adresu URL i tokena Bearer nie pozwala na nawiązanie połączenia bez fizycznego posiadania powiązanego klucza prywatnego i certyfikatu klienta.

1. Zalogowanie się na serwer Linux i utworzenie dedykowanego katalogu roboczego 'mkdir -p ~/lab5-mtls && cd ~/lab5-mtls'.
2. Wygenerowanie klucza prywatnego i certyfikatu urzędu certyfikacji bramki płatniczej (PayGate CA): 'openssl req -x509 -new -nodes -keyout paygate_ca.key -out paygate_ca.crt -days 3650 -subj "/C=PL/O=PayGate Polska/CN=PayGate B2B Root CA"'.
3. Wygenerowanie klucza prywatnego serwera API oraz wniosku CSR: 'openssl req -new -nodes -keyout api_server.key -out api_server.csr -subj "/C=PL/O=PayGate Polska/CN=api.paygate.local"'.
4. Podpisanie certyfikatu serwera API przez PayGate CA: 'openssl x509 -req -in api_server.csr -CA paygate_ca.crt -CAkey paygate_ca.key -CAcreateserial -out api_server.crt -days 365 -sha256'.
5. Wygenerowanie klucza prywatnego i wniosku CSR dla klienta B2B (Sklep Partnerski): 'openssl req -new -nodes -keyout sklep_client.key -out sklep_client.csr -subj "/C=PL/O=Sklep Partnerski Eko/CN=sklep-eko-partner"'.
6. Podpisanie certyfikatu klienta przez PayGate CA z rozszerzeniem 'clientAuth': 'echo "extendedKeyUsage = clientAuth" > client_ext.cnf' oraz 'openssl x509 -req -in sklep_client.csr -CA paygate_ca.crt -CAkey paygate_ca.key -CAcreateserial -out sklep_client.crt -days 365 -sha256 -extfile client_ext.cnf'.
7. Wygenerowanie obcego, nieautoryzowanego certyfikatu klienta (podpisanego przez obce, fikcyjne CA) w celu późniejszych testów negatywnych.
8. Skopiowanie certyfikatów serwera oraz certyfikatu CA do katalogu '/etc/apache2/ssl/'.
9. Edycja pliku konfiguracyjnego wirtualnego hosta Apache w '/etc/apache2/sites-available/api-mtls.conf'.
10. Wprowadzenie dyrektyw SSL: 'SSLEngine on', 'SSLCertificateFile /etc/apache2/ssl/api_server.crt', 'SSLCertificateKeyFile /etc/apache2/ssl/api_server.key'.
11. Wprowadzenie dyrektyw wzajemnego uwierzytelniania: 'SSLCACertificateFile /etc/apache2/ssl/paygate_ca.crt', 'SSLVerifyClient require', 'SSLVerifyDepth 1'.
12. Zapisanie konfiguracji, weryfikacja składni 'sudo apache2ctl configtest' i przeładowanie usługi 'sudo systemctl reload apache2'.
13. Utworzenie prostego skryptu API '/var/www/html/api/transakcje' zwracającego status 200 OK i dane transakcyjne.
14. Wykonanie testu 1 (próba połączenia bez certyfikatu klienta): 'curl -k -I https://localhost/api/transakcje'.
15. Zarejestrowanie błędu na poziomie handshake TLS: 'curl: (35) OpenSSL/3.x: error:0A0000C7:SSL routines::peer did not return a certificate' (odrzucenie na poziomie kryptograficznym).
16. Wykonanie testu 2 (próba połączenia z obcym certyfikatem klienta podpisanym przez obce CA): 'curl -k --cert obcy_client.crt --key obcy_client.key https://localhost/api/transakcje'.
17. Zarejestrowanie błędu walidacji certyfikatu klienta przez serwer: 'certificate verify failed' lub 'alert unknown ca'.
18. Wykonanie testu 3 (połączenie z autoryzowanym certyfikatem klienta): 'curl -k --cert sklep_client.crt --key sklep_client.key https://localhost/api/transakcje'.
19. Potwierdzenie pomyślnego zestawienia sesji mTLS i uzyskania odpowiedzi 'HTTP/1.1 200 OK' wraz z danymi transakcyjnymi.
20. Sformułowanie wniosków technicznych dotyczących przewagi mTLS nad tokenami API w ochronie krytycznych interfejsów finansowych.

W standardowym protokole HTTPS (One-Way TLS) serwer przesyła swój certyfikat do klienta, a przeglądarka weryfikuje jego ważność. W architekturze mTLS (Mutual TLS) po zweryfikowaniu serwera, serwer wysyła komunikat 'Certificate Request', żądając od klienta przesłania jego certyfikatu. Połączenie zostaje nawiązane wyłącznie wtedy, gdy obie strony pomyślnie zweryfikują certyfikaty partnera.

Dyrektywa 'SSLVerifyClient require' w serwerze Apache wymusza, aby każdy klient bezwzględnie przedstawił certyfikat. Jeżeli klient nie posiada certyfikatu lub certyfikat jest nieważny, negocjacja TLS zostaje natychmiast przerwana na poziomie warstwy transportowej, zanim jakiekolwiek żądanie HTTP dotrze do aplikacji webowej.

Poniżej przedstawiono listing testów weryfikacyjnych za pomocą narzędzia cURL demonstrujący odrzucenie połączenia bez certyfikatu oraz sukces z poprawnym certyfikatem mTLS:

Certyfikat klienta zawiera atrybut 'extendedKeyUsage = clientAuth' (OID: 1.3.6.1.5.5.7.3.2), podczas gdy certyfikat serwera posiada 'serverAuth' (OID: 1.3.6.1.5.5.7.3.1). Rozróżnienie to zapobiega omyłkowemu użyciu certyfikatu klienckiego do podszywania się pod serwer API.

W środowiskach produkcyjnych do zarządzania certyfikatami partnerów B2B stosuje się dedykowane serwery pośredniczące (Reverse Proxy / API Gateway, np. Nginx, Envoy, Kong), które dokonują terminacji mTLS i przekazują tożsamość klienta (wyciągniętą z certyfikatu) do aplikacji wewnętrznej w bezpiecznych nagłówkach HTTP.

1. Zrozumienie kryptograficznej różnicy pomiędzy jednostronnym TLS a wzajemnym uwierzytelnianiem mTLS.
2. Ocena skuteczności mTLS w całkowitej eliminacji podatności związanych z kradzieżą statycznych tokenów API.
3. Zastosowanie dyrektyw konfiguracyjnych Apache (SSLVerifyClient require, SSLCACertificateFile) w architekturze Zero-Trust.
4. Rola rozszerzeń Extended Key Usage (clientAuth vs serverAuth) w separacji ról kryptograficznych.
5. Praktyczna diagnostyka błędów negocjacji mTLS w narzędziu cURL i logach serwera WWW.
6. Rekomendacje dotyczące procedur bezpiecznego generowania, dystrybucji i rotacji kluczy prywatnych partnerów B2B.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie wzajemnego uwierzytelniania mTLS (Mutual TLS) w integracji B2B zapewniło najwyższy dostępny poziom bezpieczeństwa kryptograficznego w komunikacji maszynowej pomiędzy sklepem a operatorem płatności. W przeciwieństwie do standardowego TLS, weryfikacja certyfikatów X.509 po obu stronach połączenia całkowicie eliminuje zagrożenie ze strony nieautoryzowanych klientów API i fałszywych serwerów pośredniczących. Mechanizm mTLS uniezależnia bezpieczeństwo sesji od statycznych kluczy API przekazywanych w nagłówkach HTTP, które są podatne na przechwycenie w logach proxy. Weryfikacja tożsamości klienta realizowana jest na poziomie warstwy kryptograficznej handshake'u TLS, zanim żądanie trafi do logiki aplikacji webowej. Rozwiązanie to stanowi współczesny kanon bezpieczeństwa systemów finansowych, bankowości otwartej (Open Banking) oraz architektury Zero Trust.

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

Celem zadania jest praktyczne wdrożenie kryptograficznego mechanizmu zapewnienia niezaprzeczalności (Non-repudiation) oraz autentyczności w procesie autoryzacji bankowych zleceń płatniczych wysokiej wartości. Studenci poznają zasady składania i automatycznej weryfikacji podpisów cyfrowych na ustrukturyzowanych komunikatach finansowych (format XML/JSON/tekstowy) za pomocą otwartego standardu OpenPGP (GnuPG).

W trakcie laboratorium zespół analizuje prawne i techniczne skutki podpisania zlecenia płatniczego kluczem prywatnym głównego księgowego lub dyrektora finansowego. Studenci przygotowują zlecenie przelewu wielkokwotowego, podpisują je cyfrowo, tworzą skrypt automatycznej walidacji po stronie serwera bankowego oraz symulują atak polegający na podmianie numeru rachunku docelowego lub wyparciu się wysłania zlecenia. Ćwiczenie kończy się sporządzeniem sprawozdania technicznego.

Przedsiębiorstwo Przemysłowe „Metal-Hurt” w Dąbrowie Górniczej realizuje cotygodniowe płatności za surowce hutnicze na kwoty sięgające od kilkuset tysięcy do kilku milionów złotych. Zlecenia przelewów są generowane w systemie ERP i przesyłane do banku korporacyjnego za pośrednictwem dedykowanego modułu integracji.

W sektorze finansowym odnotowano rosnącą liczbę wyrafinowanych ataków typu BEC (Business Email Compromise) oraz CEO Fraud, w których przestępcy podszywają się pod członków zarządu i nakazują wykonanie pilnych przelewów na podstawione konta słupów. Tradycyjne wiadomości e-mail lub zwykłe pliki z dyspozycjami przelewu nie posiadają mocy prawnej ani technicznej gwarancji integralności.

Zarząd banku korporacyjnego wprowadził rygorystyczną procedurę dla wszystkich przelewów przekraczających kwotę 100 000 PLN: każda dyspozycja musi zostać podpisana cyfrowo kluczem prywatnym co najmniej dwóch uprawnionych dysponentów (zasada czterech oczu – Dual Control) z wykorzystaniem kluczy RSA 4096-bit w standardzie OpenPGP.

Zespół studentów wciela się w administratorów systemu bankowości korporacyjnej. Uczestnicy generują pary kluczy dla Głównego Księgowego oraz Dyrektora Finansowego, przygotowują komunikat przelewu na kwotę 450 000 PLN, składają podpisy cyfrowe, a następnie po stronie serwera bankowego implementują skrypt weryfikujący poprawność obu podpisów przed zaksięgowaniem środków.

W fazie testów zespół bada reakcję systemu na próbę modyfikacji numeru rachunku dostawcy oraz analizuje dlaczego dyrektor finansowy nie może wyprzeć się zatwierdzenia dyspozycji (zasada niezaprzeczalności).

1. Utworzenie katalogu roboczego na serwerze Linux: 'mkdir -p ~/lab5-signing && cd ~/lab5-signing'.
2. Weryfikacja instalacji narzędzia GnuPG poleceniem 'gpg --version'.
3. Wygenerowanie 4096-bitowej pary kluczy dla Głównego Księgowego: 'gpg --batch --passphrase "KsiegowyHaslo2026!" --quick-gen-key "Anna Nowak (Glowny Ksiegowy) " rsa4096 sign 1y'.
4. Wygenerowanie 4096-bitowej pary kluczy dla Dyrektora Finansowego: 'gpg --batch --passphrase "DyrektorHaslo2026!" --quick-gen-key "Marek Wisniewski (Dyrektor Finansowy) " rsa4096 sign 1y'.
5. Wyeksportowanie kluczy publicznych obu dysponentów: 'gpg --armor --export ksiegowa@metal-hurt.local > ksiegowa_pub.asc' oraz 'gpg --armor --export dyrektor@metal-hurt.local > dyrektor_pub.asc'.
6. Przygotowanie pliku zlecenia płatniczego 'zlecenie_przelewu.txt' zawierającego parametry: 'Nadawca: Metal-Hurt Sp. z o.o.', 'Kwota: 450 000.00 PLN', 'Odbiorca: Huta Stalowa Wola SA', 'Rachunek: PL1210500099...'.
7. Złożenie pierwszego podpisu cyfrowego (Główny Księgowy) w formacie podpisu odłączonego: 'gpg --batch --passphrase "KsiegowyHaslo2026!" --armor --detach-sign --local-user ksiegowa@metal-hurt.local --output zlecenie.sig1 zlecenie_przelewu.txt'.
8. Złożenie drugiego podpisu cyfrowego (Dyrektor Finansowy): 'gpg --batch --passphrase "DyrektorHaslo2026!" --armor --detach-sign --local-user dyrektor@metal-hurt.local --output zlecenie.sig2 zlecenie_przelewu.txt'.
9. Przełączenie się na rolę serwera bankowego (nowy katalog roboczy lub import kluczy publicznych do bankowego pierścienia zaufania).
10. Zaimportowanie autoryzowanych kluczy publicznych dysponentów firmy na serwerze bankowym: 'gpg --import ksiegowa_pub.asc' oraz 'gpg --import dyrektor_pub.asc'.
11. Napisanie skryptu weryfikacyjnego 'bank_procesuj_zlecenie.sh' sprawdzającego obecność i ważność obu podpisów.
12. Weryfikacja pierwszego podpisu poleceniem 'gpg --verify zlecenie.sig1 zlecenie_przelewu.txt' i sprawdzenie kodu powrotu ($? = 0).
13. Weryfikacja drugiego podpisu poleceniem 'gpg --verify zlecenie.sig2 zlecenie_przelewu.txt' ($? = 0).
14. Odnotowanie w logu bankowym tożsamości osób podpisujących oraz daty i godziny autoryzacji.
15. Wykonanie pomyślnego testu: realizacja dyspozycji przelewu po potwierdzeniu obu podpisów.
16. Symulacja ataku wewnętrznego / infekcji złośliwym oprogramowaniem: modyfikacja numeru rachunku odbiorcy w pliku 'zlecenie_przelewu.txt' o jedną cyfrę.
17. Ponowne uruchomienie procedury bankowej 'bank_procesuj_zlecenie.sh' na zmodyfikowanym pliku.
18. Zarejestrowanie natychmiastowego błędu weryfikacji: 'gpg: BAD signature from Anna Nowak' oraz odrzucenie transakcji.
19. Przeanalizowanie aspektu prawnego niezaprzeczalności w świetle art. 97 Kodeksu cywilnego oraz przepisów Prawa bankowego.
20. Sformułowanie wniosków technicznych dotyczących zasady podwójnej autoryzacji (Dual Control) w systemach bankowości korporacyjnej.

Zasada niezaprzeczalności (Non-repudiation) oznacza, że podmiot, który złożył podpis cyfrowy pod dokumentem, nie może skutecznie twierdzić, że dokumentu nie sporządził lub że jego treść była inna. Wynika to z faktu, że podpis cyfrowy mógł zostać wygenerowany wyłącznie przy użyciu unikalnego klucza prywatnego, który znajduje się pod wyłączną kontrolą dysponenta.

Zastosowanie podpisów odłączonych (Detached Signatures) jest standardem w automatycznych systemach bankowych. Pozwala na zachowanie oryginalnego pliku transakcyjnego w niezmienionej strukturze (np. format ISO 20022 XML), a pliki podpisów (np. '.sig1', '.sig2') są przesyłane jako niezależne metadane autoryzacyjne.

Poniżej przedstawiono przykładowy widok konsoli serwera bankowego podczas weryfikacji podpisów cyfrowych pod zleceniem wielkokwotowym:

W środowiskach korporacyjnych klucze prywatne osób upoważnionych do dysponowania środkami wielkokwotowymi nie powinny znajdować się bezpośrednio na dyskach twardych laptopów, lecz na kryptograficznych kartach mikroprocesorowych lub tokenach USB zgodnych ze standardem PKCS#11 (np. YubiKey z obsługą OpenPGP).

Klucz prywatny na tokenie sprzętowym nie może zostać skopiowany ani wyeksportowany – operacja podpisywania skrótu transakcji odbywa się fizycznie wewnątrz mikroprocesora tokena po podaniu kodu PIN.

1. Zrozumienie kryptograficznej i prawnej zasady niezaprzeczalności (Non-repudiation) w obrocie finansowym.
2. Wpływ procedury podwójnej autoryzacji cyfrowej (Dual Control / Four-Eyes Principle) na eliminację nadużyć wewnętrznych i ataków BEC.
3. Zastosowanie podpisów odłączonych (Detached Signatures) w zachowaniu integralności ustrukturyzowanych komunikatów płatniczych.
4. Praktyczny dowód na niemożność modyfikacji danych zlecenia bez unieważnienia obu podpisów cyfrowych.
5. Rola sprzętowych tokenów kryptograficznych (HSM / Smartcard / YubiKey) w ochronie kluczy prywatnych dysponentów.
6. Rekomendacje dotyczące audytu procesów akceptacji płatności wielkokwotowych w przedsiębiorstwach.

Przykładowe wnioski (wzór do sprawozdania): Zastosowanie cyfrowych podpisów OpenPGP do autoryzacji transakcji wielkokwotowych zapewniło pełną niezaprzeczalność i integralność przesyłanych zleceń finansowych. Złożenie podpisu kryptograficznego kluczem prywatnym dyrektora finansowego trwale wiąże tożsamość dysponenta środków z dokładną kwotą i numerem rachunku docelowego przelewu. Niemożność wyparcia się tak autoryzowanej transakcji wyklucza spory prawne i eliminuje ryzyko nadużyć ze strony nieuczciwych pracowników instytucji bankowej. Weryfikacja sygnatury w procesie automatycznego przetwarzania zleceń pozwala na natychmiastowe odrzucenie jakichkolwiek prób manipulacji plikami wsadowymi przelewów w systemie bankowym. Projekt udowodnił, że kryptografia klucza publicznego stanowi jedyny pewny matematyczny fundament potwierdzania woli w obrocie gospodarczym dużej skali.

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

Celem ćwiczenia jest dogłębna analiza mechanizmów kryptograficznych oraz architektury bezpieczeństwa nowoczesnych systemów płatności mobilnych opartych na dynamicznych kodach jednorazowych (studium przypadku polskiego standardu płatności BLIK). Studenci poznają zasady generowania tokenów jednorazowych o bardzo krótkim czasie życia (120 sekund) oraz model autoryzacji poza pasmem (Out-of-Band Push Notification).

W toku laboratorium zespół analizuje model trójstronny (Klient mobilny – Terminal/Sklep – Centralny System Płatności), symuluje procedurę generowania i walidacji 6-cyfrowego kodu transakcyjnego w środowisku laboratoryjnym oraz bada podatności socjotechniczne (metoda oszustwa 'na BLIK-a' na portalach społecznościowych). Studenci projektują mechanizmy obronne wymuszające weryfikację kontekstu transakcji (odbiorca, kwota) na ekranie telefonu. Zadanie wieńczy raport techniczny.

Komenda Powiatowa Policji w Chrzanowie odnotowuje lawinowy wzrost liczby zgłoszeń dotyczących cyberoszustw metodą 'na BLIK-a'. Sprawcy przejmują konta użytkowników na popularnych portalach społecznościowych, a następnie podszywając się pod znajomych lub członków rodziny, wysyłają wiadomości z prośbą o pilne pożyczenie drobnej kwoty i podanie 6-cyfrowego kodu płatności.

Wielu poszkodowanych bezrefleksyjnie generuje kod w swojej aplikacji bankowej i przesyła go na czacie, a następnie zatwierdza powiadomienie autoryzacyjne w telefonie, nie czytając treści komunikatu. Przestępcy natychmiast wypłacają gotówkę z bankomatu na drugim końcu Polski lub opłacają zakupy w zagranicznych sklepach internetowych.

Wydział do Walki z Cyberprzestępczością we współpracy ze środowiskiem akademickim zainicjował projekt badawczo-edukacyjny mający na celu precyzyjne przeanalizowanie modelu kryptograficznego płatności kodowych oraz wskazanie, dlaczego sam mechanizm technologiczny jest bezpieczny, a słabym ogniwem pozostaje brak weryfikacji danych kontekstowych przez człowieka.

Zespół studentów ma za zadanie zaimplementować uproszczony symulator cyklu życia kodu jednorazowego w środowisku Linux: wygenerowanie losowego 6-cyfrowego tokena powiązanego z sesją bankową, ustawienie 120-sekundowego licznika ważności w pamięci podręcznej, obsłużenie żądania autoryzacji z terminala oraz wygenerowanie komunikatu PUSH zawierającego kwotę i dokładną lokalizację punktu akceptacji.

W podsumowaniu studenci analizują dlaczego standard BLIK nie ujawnia sprzedawcy numeru karty płatniczej ani danych rachunku bankowego (tokenizacja jednorazowa) oraz formułują wytyczne interfejsu użytkownika (UI/UX) utrudniające oszustwa socjotechniczne.

1. Przygotowanie środowiska roboczego: 'mkdir -p ~/lab5-blik && cd ~/lab5-blik'.
2. Weryfikacja dostępności narzędzi 'openssl', 'date', 'awk' oraz interpretera powłoki.
3. Zaprojektowanie struktury bazy tokenów jednorazowych 'blik_sessions.db' (pola: kod, id_klienta, utworzono_ts, status, kwota_blokady).
4. Napisanie skryptu 'generuj_kod_blik.sh' symulującego działanie centralnego serwera płatności mobilnych.
5. Generowanie bezpiecznego kryptograficznie 6-cyfrowego kodu za pomocą OpenSSL: 'KOD=$(openssl rand -hex 4 | tr -d -c '0-9' | cut -c 1-6)'.
6. Pobranie aktualnego znacznika czasu i ustawienie limitu ważności (TTL = 120 sekund).
7. Zapisanie aktywnej sesji tokena w bazie ze statusem 'WAITING_FOR_TERMINAL'.
8. Wyświetlenie wygenerowanego kodu wraz z odliczanym czasem ważności (symulacja ekranu aplikacji mobilnej).
9. Napisanie skryptu 'terminal_sklepowy.sh' symulującego wpisanie kodu w terminalu płatniczym lub kasie sklepowej na kwotę 250.00 PLN.
10. Przesłanie kodu z terminala do centralnego serwera płatności.
11. Weryfikacja przez serwer: sprawdzenie czy kod istnieje w bazie i czy nie upłynęło 120 sekund od wygenerowania.
12. Wygenerowanie powiadomienia autoryzacyjnego PUSH do telefonu klienta z kluczowymi danymi kontekstowymi: 'Czy zatwierdzasz transakcje: 250.00 PLN, Odbiorca: Bankomat Euronet Krakow, ul. Florianska?'.
13. Napisanie skryptu 'klient_potwierdzenie.sh' symulującego odpowiedź klienta (zatwierdzenie kodem PIN w aplikacji bankowej).
14. Zmiana statusu transakcji w bazie na 'SETTLED' (Rozliczona) oraz natychmiastowe unieważnienie użytego kodu (blokada ponownego użycia).
15. Wykonanie testu negatywnego 1: próba ponownego użycia tego samego kodu po rozliczeniu (potwierdzenie błędu 'Kod zostal juz wykorzystany').
16. Wykonanie testu negatywnego 2: odczekanie 125 sekund i próba użycia kodu przeterminowanego (potwierdzenie błędu 'Kod wygasl - wygeneruj nowy kod').
17. Symulacja scenariusza oszustwa: przestępca prosi o kod na zakup w sklepie, a na telefonie ofiary pojawia się powiadomienie 'Wypłata z bankomatu 1000 PLN'.
18. Wykazanie, jak uważne przeczytanie powiadomienia PUSH natychmiast demaskuje oszustwo i chroni przed utratą środków.
19. Porównanie właściwości prywatności transakcji BLIK (brak przekazywania numeru karty i nazwiska) z tradycyjnymi płatnościami kartowymi.
20. Opracowanie referatu z rekomendacjami dla banków w zakresie projektowania aplikacji mobilnych (np. wymuszenie geolokalizacji lub czytelnego wyróżnienia wypłat z bankomatów).

Architektura płatności typu BLIK opiera się na jednorazowym tokenie numerycznym o krótkim czasie życia (120 sekund). Sam 6-cyfrowy kod nie niesie w sobie żadnych informacji o kliencie, stanie konta ani numerze rachunku – jest jedynie dynamicznym kluczem indeksującym sesję w pamięci centralnego systemu płatności.

Kluczowym elementem bezpieczeństwa jest to, że wpisanie kodu w terminalu sklepowym lub bankomacie nie powoduje obciążenia konta. Wpisanie kodu inicjuje jedynie wysłanie żądania autoryzacji do telefonu właściciela konta odrębnym, bezpiecznym kanałem TLS (Out-of-Band). Dopiero świadome kliknięcie 'Potwierdź' i autoryzacja biometryczna (odcisk palca / FaceID) lub PIN w aplikacji bankowej finalizuje transakcję.

Poniżej przedstawiono przykładowy widok konsoli symulujący cykl życia kodu mobilnego, autoryzację z terminala oraz zablokowanie kodu przeterminowanego:

W analizie bezpieczeństwa należy podkreślić, że kody 6-cyfrowe posiadają przestrzeń miliona kombinacji ($10^6$). Przy 120-sekundowym oknie ważności oraz ograniczeniu liczby błędnych prób do 3 na terminal, atak siłowy (brute-force) na odgadnięcie aktywnego kodu w skali kraju jest matematycznie niewykonalny.

Wszystkie udane oszustwa na kody mobilne wynikają wyłącznie z manipulacji socjotechnicznej (Inżynieria Społeczna), w której ofiara sama dobrowolnie podaje kod przestępcy i bez czytania potwierdza powiadomienie w telefonie.

1. Zrozumienie kryptograficznej i proceduralnej architektury płatności mobilnych opartych na tokenach jednorazowych.
2. Rola autoryzacji poza pasmem (Out-of-Band Push) w eliminacji podatności terminali sklepowych.
3. Znaczenie rygorystycznego limitu czasu życia tokena (120s TTL) dla bezpieczeństwa operacji.
4. Zalety tokenizacji mobilnej w ochronie prywatności użytkowników (brak ujawniania numerów kart płatniczych).
5. Analiza wektorów ataków socjotechnicznych (metoda 'na BLIK-a') i psychologicznych mechanizmów manipulacji.
6. Rekomendacje dotyczące projektowania interfejsów aplikacji bankowych ostrzegających przed niebezpiecznymi autoryzacjami.

Przykładowe wnioski (wzór do sprawozdania): Analiza architektury płatności mobilnych typu BLIK wykazała, że generowanie 6-cyfrowych tokenów jednorazowych o krótkim czasie życia (120 sekund) skutecznie chroni dane karty płatniczej przed ujawnieniem sprzedawcy. Rozdzielenie procesu podania kodu w terminalu lub sklepie od ostatecznej autoryzacji transakcji w aplikacji bankowej wprowadza kluczowy element dwukanałowości (Out-of-Band). Użytkownik ma możliwość zweryfikowania kwoty i odbiorcy przelewu na ekranie własnego smartfona zanim zatwierdzi operację kodem PIN lub biometrią. Zbadane scenariusze oszustw socjotechnicznych (tzw. metoda 'na wnuczka' lub 'na znajomego z komunikatora') dowodzą, że nawet doskonały kryptograficznie system może zostać skompromitowany przez manipulację psychologiczną posiadacza konta. Podstawowym wnioskiem jest konieczność nieustannego edukowania konsumentów w zakresie uważnego odczytywania komunikatów autoryzacyjnych w aplikacji mobilnej.

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Efekty uczenia się: W1, W2, U1, U3, U4, K1, K3.

Celem ćwiczenia jest praktyczne opanowanie koncepcji tokenizacji kryptograficznej (Tokenization) jako podstawowej metody redukcji ryzyka wycieku wrażliwych danych kart płatniczych (numerów PAN – Primary Account Number) w aplikacjach internetowych i usługach subskrypcyjnych (SaaS). Studenci poznają zasady zamiany poufnego numeru karty na losowy surogat (token) zachowujący format danych (Format-Preserving Encryption).

W trakcie laboratorium zespół bada architekturę bezpiecznego repozytorium kart (Card Vault), projektuje bazę danych oddzielającą tokeny od zaszyfrowanych numerów kart, implementuje procedurę bezpiecznego obciążania subskrypcji za pomocą tokena bez konieczności przechowywania kodów CVV2/CVC2 oraz analizuje wymogi standardu PCI DSS dotyczące wyłączenia serwerów sklepu ze strefy CDE. Zadanie kończy się raportem technicznym.

Platforma Edukacyjna „Edu-Stream” w Krakowie świadczy usługi dostępu do kursów online i wideolekcji w miesięcznym modelu abonamentowym (SaaS). Subskrybenci rejestrują swoje karty płatnicze, z których pierwszego dnia każdego miesiąca pobierana jest automatyczna opłata w wysokości 49 PLN.

W początkowej wersji aplikacji programiści zapisywali pełne 16-cyfrowe numery kart płatniczych (PAN), daty ważności oraz 3-cyfrowe kody CVV2 bezpośrednio w tabeli użytkowników w bazie danych MySQL. Podczas audytu bezpieczeństwa audytor poinformował zarząd, że przechowywanie kodów CVV2 jest bezwzględnie zakazane przez standard PCI DSS (Wymóg 3.2), a wyciek bazy danych doprowadziłby do gigantycznych kar finansowych i utraty reputacji.

Kierownictwo platformy podjęło decyzję o wdrożeniu tokenizacji kartowej w oparciu o certyfikowany skarbiec kart (Secure Card Vault). W myśl nowej architektury serwery platformy Edu-Stream nigdy nie mają kontaktu z numerem karty – dane karty są przesyłane bezpośrednio z przeglądarki klienta do skarbca płatniczego, a do bazy platformy trafia wyłącznie unikalny, losowy token 'tok_2026_98124a1b' oraz bezpieczna maska karty ('XXXX XXXX XXXX 1234').

Zespół studentów wciela się w architektów bezpieczeństwa realizujących to zadanie w środowisku laboratoryjnym. Grupa projektuje architekturę skarbca kart, implementuje procedurę generowania tokenów zachowujących format, tworzy skrypt comiesięcznego cyklicznego obciążania subskrypcji za pomocą samego tokena oraz demonstruje, że ewentualny wyciek bazy danych platformy nie ujawnia żadnych danych kartowych.

Podsumowaniem zadania jest analiza prawna odpowiedzialności administratora danych w świetle RODO oraz korzyści biznesowych wynikających ze zwolnienia infrastruktury z rygorystycznych kontroli PCI DSS.

1. Przygotowanie katalogu roboczego na stacji Linux: 'mkdir -p ~/lab5-tokenization && cd ~/lab5-tokenization'.
2. Weryfikacja dostępności narzędzi 'openssl', 'sqlite3' (lub wbudowanego silnika bazodanowego) oraz narzędzi tekstowych.
3. Zaprojektowanie schematu bazy danych certyfikowanego skarbca kart 'card_vault.db' (tabela 'vault': token, pan_encrypted, expiry_encrypted, created_at).
4. Zaprojektowanie schematu bazy danych platformy SaaS 'edustream.db' (tabela 'subscriptions': user_id, email, card_token, card_mask, plan, active).
5. Zdefiniowanie klucza szyfrowania danych w spoczynku dla skarbca kart: 'SkarbiecKluczAES256GCM2026!Master'.
6. Napisanie skryptu 'zarejestruj_karte_vault.sh' symulującego działanie zewnętrznego skarbca kart.
7. Wprowadzenie testowych danych karty klienta (PAN: '4111111111111234', data ważności: '12/28', CVV: '123').
8. Wygenerowanie bezpiecznego tokena referencyjnego za pomocą OpenSSL: 'TOKEN="tok_$(openssl rand -hex 12)"'.
9. Zaszyfrowanie numeru PAN za pomocą algorytmu AES-256-CBC z unikalnym wektorem IV: 'openssl enc -aes-256-cbc -pbkdf2 -in pan.txt -out pan.enc -k "$KLUCZ_VAULT"'.
10. Utworzenie bezpiecznej maski karty na potrzeby wyświetlania w profilu użytkownika: 'card_mask="Visa XXXX 1234"'.
11. Zapisanie rekordu w skarbcu kart (powiązanie tokena z szyfrogramem PAN) oraz natychmiastowe zniszczenie w pamięci kodu CVV2 (zgodnie z PCI DSS).
12. Zapisanie rekordu w bazie platformy SaaS zawierającego wyłącznie token 'tok_...' oraz maskę 'Visa XXXX 1234'.
13. Sprawdzenie zawartości bazy platformy 'edustream.db' i potwierdzenie braku jakichkolwiek numerów kart kredytowych.
14. Napisanie skryptu 'pobierz_oplate_subskrypcyjna.sh' realizującego cykliczne rozliczenie abonamentu (np. 49 PLN).
15. Przesłanie żądania obciążenia ze sklepu do skarbca z podaniem tokena i kwoty: 'POST /charge token=tok_... amount=49.00'.
16. Odnalezienie karty w skarbcu po tokenie, odszyfrowanie numeru PAN i wysłanie autoryzacji do sieci Visa/Mastercard.
17. Odesłanie do sklepu potwierdzenia transakcji (kod autoryzacji 'AUTH_OK_889921').
18. Symulacja ataku: włamanie na serwer platformy SaaS i pobranie pełnego zrzutu bazy danych 'edustream.db'.
19. Wykazanie, że zdobyte przez napastnika tokeny są całkowicie bezużyteczne poza autoryzowanym kanałem sklepu i nie pozwalają na odtworzenie numerów kart płatniczych.
20. Sformułowanie wniosków końcowych dotyczących tokenizacji jako fundamentalnego mechanizmu ochrony danych w chmurze.

Tokenizacja polega na zastąpieniu wrażliwej danej (np. 16-cyfrowego numeru PAN) losowym identyfikatorem (tokenem), który nie posiada żadnej wartości kryptograficznej ani matematycznego związku z oryginalną daną. W przeciwieństwie do szyfrowania (gdzie algorytm matematyczny pozwala na odwrócenie operacji przy użyciu klucza), z tokena nie da się wyliczyć numeru karty – powiązanie istnieje wyłącznie w chronionej bazie skarbca (Token Vault).

Zgodnie ze standardem PCI DSS podmiot, który korzysta z zewnętrznej tokenizacji i nie przechowuje, nie przetwarza ani nie przesyła numerów kart w swojej infrastrukturze, kwalifikuje się do najprostszego kwestionariusza zgodności (SAQ A). Zmniejsza to liczbę wymaganych kontroli bezpieczeństwa z kilkuset do zaledwie kilkunastu, oszczędzając przedsiębiorstwu dziesiątki tysięcy złotych rocznie.

Poniżej przedstawiono przykładowy widok konsoli serwera demonstrujący procedurę tokenizacji karty oraz automatyczne rozliczenie subskrypcji:

Kody bezpieczeństwa kart CVV2/CVC2 (trzy cyfry na odwrocie karty) mogą być przetwarzane wyłącznie w czasie rzeczywistym podczas pierwszej autoryzacji transakcji. Standard PCI DSS bezwzględnie zakazuje przechowywania kodów CVV2 w jakiejkolwiek formie (nawet zaszyfrowanej) po zakończeniu autoryzacji.

Do wyświetlania informacji o karcie w panelu klienta stosuje się tzw. maskowanie (Truncation / Masking). Dopuszczalne jest pokazywanie maksymalnie pierwszych 6 cyfr (BIN) oraz ostatnich 4 cyfr numeru karty (np. '4111 11XX XXXX 1234'), co pozwala użytkownikowi rozpoznać swoją kartę bez ujawniania pełnego numeru PAN.

1. Zrozumienie fundamentalnej różnicy pomiędzy tokenizacją a szyfrowaniem kryptograficznym.
2. Wykazanie korzyści płynących z tokenizacji w redukcji zakresu audytu PCI DSS (kwestionariusz SAQ A).
3. Bezwzględny zakaz przechowywania kodów bezpieczeństwa CVV2/CVC2 po autoryzacji transakcji.
4. Odporność modelu tokenizacji na skutki wycieku bazy danych platformy handlowej.
5. Zasady prawidłowego maskowania numerów kart płatniczych w interfejsach użytkownika.
6. Rekomendacje dotyczące wyboru certyfikowanych dostawców usług płatniczych (Payment Service Providers).

Przykładowe wnioski (wzór do sprawozdania): Zastosowanie technologii tokenizacji w modelu płatności subskrypcyjnych pozwoliło na całkowite wyeliminowanie konieczności przechowywania wrażliwych numerów kart płatniczych (PAN) w bazie danych sprzedawcy. Zastąpienie rzeczywistych danych karty przez losowy identyfikator cyfrowy (token) sprawia, że w przypadku ewentualnego włamania do sklepu internetowego napastnik nie uzyskuje żadnych danych zdatnych do wykonania fraudu. Przechowywanie i przetwarzanie surowych numerów kart zostaje całkowicie oddelegowane do certyfikowanego operatora płatności posiadającego poświadczenie PCI DSS poziomu pierwszego. Rozwiązanie to drastycznie obniża koszty audytu zgodności sklepu internetowego, zawężając zakres obowiązków regulacyjnych (PCI DSS Scope Reduction). Tokenizacja stanowi obecnie najbezpieczniejszy wzorzec architektoniczny w obsłudze automatycznych płatności cyklicznych w modelu SaaS.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Kon3 Architektura PKI i certyfikaty X.509. Efekty uczenia się: W1, W4, U1, U3, K1, K2.

Głównym celem zadania jest praktyczne zrozumienie wektorów ataków pośrednika (Man-in-the-Middle – MitM) na sesje kryptograficzne portali transakcyjnych oraz opanowanie mechanizmów obronnych po stronie serwera i klienta. Studenci badają techniki przechwytywania sesji oparte na fałszowaniu certyfikatów SSL/TLS (podstawianie certyfikatów samopodpisanych lub rogue CA) oraz próbach usuwania szyfrowania (SSL Stripping).

W toku laboratorium zespół analizuje mechanizmy detekcji niezgodności certyfikatów, bada łańcuch walidacji X.509, konfiguruje ochronę przed podszywaniem się za pomocą mechanizmu przypinania kluczy lub certyfikatów (Certificate / Public Key Pinning) oraz weryfikuje odporność aplikacji klienckiej za pomocą narzędzi wiersza poleceń OpenSSL i cURL. Studenci opracowują instrukcje reagowania na incydenty kryptograficzne. Prace kończą się przygotowaniem sprawozdania.

Dom Maklerski „Inwestor-Online” w Katowicach udostępnia klientom platformę transakcyjną do handlu akcjami, obligacjami skarbowymi i kontraktami terminowymi na Giełdzie Papierów Wartościowych w Warszawie. Klienci logują się do portalu ze stacji roboczych oraz urządzeń mobilnych korzystających z różnorodnych sieci dostępowych, w tym otwartych sieci Wi-Fi w kawiarniach i hotelach.

Dział bezpieczeństwa banku maklerskiego zaobserwował zgłoszenia od inwestorów, którzy łącząc się z publicznych punktów dostępowych, otrzymywali w przeglądarkach ostrzeżenia o niezaufanym certyfikacie cyfrowym lub zauważali, że ikona kłódki znikała z paska adresu. Analiza techniczna wykazała, że cyberprzestępcy w otwartych sieciach Wi-Fi uruchomili złośliwe punkty dostępowe (tzw. Evil Twin) oraz oprogramowanie sslstrip i mitmproxy, próbując przechwycić poświadczenia logowania do rachunków maklerskich.

Kierownictwo domu maklerskiego podjęło decyzję o pilnym wzmocnieniu mechanizmów obronnych platformy. Plan obejmuje wdrożenie rygorystycznej polityki HTTP Strict Transport Security (HSTS) z deklaracją Preload, implementację mechanizmu przypinania klucza publicznego (Public Key Pinning) w dedykowanych aplikacjach klienckich oraz opracowanie procedury automatycznego ostrzegania przed fałszywymi certyfikatami.

Zespół studentów wciela się w audytorów bezpieczeństwa kryptoanalitycznego. Grupa ma za zadanie zasymulować środowisko ataku MitM poprzez wygenerowanie fałszywego certyfikatu podszywającego się pod dom maklerski, przetestowanie zachowania klienta sieciowego cURL z poprawną oraz sfałszowaną konfiguracją certyfikatów, a następnie wdrożenie mechanizmu weryfikacji skrótu klucza publicznego (SPKI Pinning).

Końcowym efektem prac jest sformułowanie procedur bezpieczeństwa dla inwestorów oraz technicznych wytycznych ochrony aplikacji finansowych przed manipulacjami w warstwie transportowej.

1. Przygotowanie środowiska testowego: 'mkdir -p ~/lab5-mitm && cd ~/lab5-mitm'.
2. Weryfikacja poprawności instalacji narzędzia OpenSSL poleceniem 'openssl version'.
3. Wygenerowanie autentycznego urzędu certyfikacji domu maklerskiego: 'openssl req -x509 -new -nodes -keyout makler_ca.key -out makler_ca.crt -days 3650 -subj "/C=PL/O=Dom Maklerski Inwestor/CN=Makler Root CA"'.
4. Wygenerowanie autentycznego certyfikatu serwera transakcyjnego 'inwestor.makler.local' podpisanego przez Makler CA.
5. Wyodrębnienie publicznego klucza serwera i obliczenie jego kryptograficznego skrótu SHA-256 (Subject Public Key Info – SPKI Pin): 'openssl x509 -in makler_server.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64'.
6. Zapisanie referencyjnej wartości skrótu klucza (SPKI Pin) do pliku 'prawidlowy_pin.txt'.
7. Symulacja działań cyberprzestępcy: wygenerowanie fałszywego certyfikatu z taką samą nazwą Common Name 'inwestor.makler.local', lecz podpisanego przez nieautoryzowane CA (Rogue CA).
8. Obliczenie skrótu klucza publicznego fałszywego certyfikatu i wykazanie, że jest on całkowicie różny od referencyjnego pinu.
9. Przetestowanie standardowego zachowania klienta cURL próbującego połączyć się z serwerem przedstawiającym fałszywy certyfikat: 'curl --cacert makler_ca.crt -I https://inwestor.makler.local' (odrzucenie przez brak zaufania do wystawcy).
10. Symulacja sytuacji, w której atakujący zainstalował swój certyfikat Rogue CA w systemie ofiary (np. przez trojana).
11. Przeprowadzenie testu z mechanizmem przypinania klucza publicznego (Pinning) za pomocą narzędzia curl z opcją '--pinnedpubkey': 'curl --pinnedpubkey "sha256//[PRAWIDLOWY_PIN]" https://inwestor.makler.local'.
12. Weryfikacja pomyślnego połączenia z autentycznym serwerem.
13. Przetestowanie połączenia z fałszywym serwerem przy włączonym przypinaniu: 'curl --pinnedpubkey "sha256//[PRAWIDLOWY_PIN]" https://falszywy-serwer.local'.
14. Zarejestrowanie natychmiastowego błędu: 'curl: (90) SSL: public key does not match pinned public key!' – atak MitM całkowicie udaremniony.
15. Przeanalizowanie mechanizmu działania ataku SSL Stripping (przechwytywanie żądań HTTP i usuwanie przekierowań na HTTPS) za pomocą analizatora ruchu sieciowego.
16. Wdrożenie nagłówka 'Strict-Transport-Security: max-age=63072000; includeSubDomains; preload' uniemożliwiającego ataki typu sslstrip.
17. Zbadanie rejestru Certificate Transparency (CT Logs) jako globalnego mechanizmu wykrywania nieautoryzowanych certyfikatów wystawionych przez skompromitowane centra certyfikacji.
18. Opracowanie procedury postępowania w przypadku wykrycia nieautoryzowanego certyfikatu dla domeny instytucji finansowej.
19. Sporządzenie tabelarycznego zestawienia wektorów ataków MitM (ARP Spoofing, DNS Spoofing, Rogue CA, SSLStrip) i adekwatnych mechanizmów obronnych.
20. Przygotowanie wniosków technicznych dotyczących bezpieczeństwa aplikacji finansowych w niezaufanych środowiskach sieciowych.

Atak typu Man-in-the-Middle (MitM) polega na przechwyceniu ruchu pomiędzy klientem a serwerem przez węzeł pośredniczący, który deszyfruje, podgląda, modyfikuje i ponownie szyfruje pakiety. Aby atak był skuteczny w sesjach HTTPS, napastnik musi skłonić przeglądarkę ofiary do zaakceptowania sfałszowanego certyfikatu cyfrowego.

Mechanizm przypinania klucza publicznego (Public Key Pinning / SPKI Pinning) jest jedną z najsilniejszych metod obrony przed atakami MitM. Aplikacja klienta posiada na stałe zaszyty skrót SHA-256 klucza publicznego serwera. Nawet jeżeli napastnik zdoła przekonać system operacyjny do zaufania fałszywemu urzędowi CA, aplikacja i tak przerwie połączenie, ponieważ klucz publiczny w sfałszowanym certyfikacie nie będzie zgadzał się z przypiętym pinem.

Poniżej przedstawiono przykładowy widok konsoli demonstrujący udaremnienie ataku MitM przez weryfikację przypiętego klucza publicznego (--pinnedpubkey) w narzędziu cURL:

Zwróć uwagę, że przypinanie klucza publicznego (SPKI Pinning) jest znacznie bezpieczniejsze i elastyczniejsze niż przypinanie całego certyfikatu. Pozwala ono na wymianę certyfikatu po upływie terminu ważności (np. co rok) bez konieczności aktualizacji aplikacji klienckiej, pod warunkiem, że nowy certyfikat zostanie wygenerowany w oparciu o tę samą parę kluczy RSA/ECC.

W przypadku aplikacji przeglądarkowych główną obroną przed manipulacjami w warstwie transportowej jest nagłówek HSTS (HTTP Strict Transport Security) z długim okresem max-age oraz zgłoszenie domeny do listy HSTS Preload wbudowywanej w silniki przeglądarek Chrome, Firefox i Safari.

1. Zrozumienie wektorów i mechanizmów ataków pośrednika (Man-in-the-Middle) na transakcje elektroniczne.
2. Skuteczność przypinania klucza publicznego (SPKI Pinning) w neutralizacji ataków opartych na fałszywych certyfikatach.
3. Rola nagłówka HSTS i listy HSTS Preload w całkowitym wyeliminowaniu podatności na ataki typu SSL Stripping.
4. Znaczenie logów przejrzystości certyfikatów (Certificate Transparency) w monitorowaniu tożsamości domen finansowych.
5. Świadomość zagrożeń związanych z korzystaniem z otwartych, nieszyfrowanych sieci Wi-Fi do celów bankowych.
6. Rekomendacje dotyczące projektowania bezpiecznych klientów bankowości mobilnej i desktopowej.

Przykładowe wnioski (wzór do sprawozdania): Badanie podatności portalu transakcyjnego na ataki pośrednika (Man-in-the-Middle) dowiodło, że samo szyfrowanie TLS nie chroni użytkownika, jeżeli zignoruje on ostrzeżenia o niezgodności certyfikatu cyfrowego. Zastosowanie techniki przypinania certyfikatów (Certificate Pinning) w dedykowanych aplikacjach klienckich skutecznie uniemożliwia podsłuch nawet w przypadku zainstalowania fałszywego urzędu CA w systemie użytkownika. Wdrożenie publicznych rejestrów Certificate Transparency (CT) pozwala zespołowi bezpieczeństwa instytucji finansowej na natychmiastowe wykrycie nieuprawnionych certyfikatów wystawionych przez skompromitowane centra certyfikacji. Dodanie rekordu DNS CAA (Certification Authority Authorization) precyzyjnie wskazuje, które podmioty są uprawnione do generowania certyfikatów dla domeny bankowej. Wielowarstwowa ochrona integralności certyfikatów stanowi kluczowy filar obrony przed wyrafinowanymi atakami cyberprzestępczymi.

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

Głównym celem zadania jest praktyczne opanowanie koncepcji budowy nienaruszalnych kryptograficznie dzienników zdarzeń transakcyjnych (Tamper-evident Audit Logs) opartych na strukturze łańcucha skrótów (Hash Chain) – fundamentu technologii rejestrów rozproszonych i systemów audytu finansowego. Studenci dowiadują się, jak zagwarantować, że żadne zdarzenie w logu nie może zostać usunięte, zmodyfikowane ani dopisane wstecz bez natychmiastowego zerwania łańcucha kryptograficznego.

W toku laboratorium zespół projektuje strukturę rekordu transakcyjnego powiązanego ze skrótem SHA-256 rekordu poprzedniego, implementuje skrypt generujący kolejne bloki dziennika zdarzeń, tworzy procedurę automatycznej weryfikacji spójności całego łańcucha oraz symuluje próbę zatarcia śladów nieautoryzowanej transakcji przez nieuczciwego administratora. Studenci analizują normatywne wymogi stawiane ścieżkom audytowym (Audit Trail) w prawie bankowym i RODO. Zadanie kończy się opracowaniem raportu technicznego.

Krajowa Izba Rozliczeniowa i Instytucja Płatnicza „Szybki-Przelew” w Łodzi obsługuje transakcje bramkowe dla kilkuset podmiotów gospodarczych. Wszelkie operacje obciążenia i uznania rachunków muszą być rejestrowane w dzienniku audytowym systemu, stanowiącym podstawę rozliczeń finansowych oraz dowód w sprawach reklamacyjnych.

Wewnętrzna kontrola bezpieczeństwa wykazała, że tradycyjne logi transakcyjne zapisywane są w zwykłym pliku tekstowym na serwerze Linux ('/var/log/transakcje.log'). Administrator posiadający uprawnienia roota lub złośliwy trojan, który przejął uprawnienia systemowe, może bez trudu otworzyć ten plik w edytorze tekstowym, zmodyfikować kwotę przelewu, podmienić numer konta lub usunąć wpisy o nieautoryzowanych operacjach, zacierając wszelkie ślady przestępstwa.

Inspektor nadzoru finansowego zażądał pilnego wdrożenia kryptograficznego mechanizmu nienaruszalności dziennika zdarzeń (Tamper-evident Audit Trail). Każdy nowy rekord logu musi zawierać kryptograficzny skrót (SHA-256) poprzedniego wpisu, tworząc nieprzerwany łańcuch powiązań blokowych, w którym zmiana choćby jednego bajtu w historii unieważnia wszystkie kolejne wpisy.

Zespół studentów ma za zadanie zaimplementować generator łańcucha skrótów (Hash Chain) w powłoce Linux. Grupa tworzy początkowy blok zerowy (Genesis Block), generuje sekwencję 10 transakcji powiązanych kryptograficznie, implementuje skrypt audytorski weryfikujący poprawność łańcucha, a następnie symuluje próbę fałszerstwa archiwalnego wpisu i dokumentuje moment wykrycia naruszenia spójności.

W podsumowaniu studenci analizują jak technologia łańcucha skrótów chroni organizację przed nadużyciami personelu uprzywilejowanego oraz porównują to rozwiązanie z technologią Blockchain.

1. Przygotowanie środowiska testowego na stacji Linux: 'mkdir -p ~/lab5-hashchain && cd ~/lab5-hashchain'.
2. Weryfikacja dostępności pakietu OpenSSL oraz narzędzi tekstowych (sha256sum, awk, sed).
3. Zaprojektowanie struktury rekordu dziennika transakcji: 'NR_BLOKU | TIMESTAMP | DANE_TRANSAKCJI | PREVIOUS_HASH | CURRENT_HASH'.
4. Inicjalizacja łańcucha: utworzenie Bloku Zerowego (Genesis Block) z zerowym haszem poprzednim: 'PREV_HASH="0000000000000000000000000000000000000000000000000000000000000000"'.
5. Obliczenie skrótu Bloku Zerowego i zapisanie do pliku dziennika 'transakcje_audit.log'.
6. Napisanie skryptu 'dodaj_transakcje.sh', który pobiera dane nowej transakcji, odczytuje skrót ostatniego wpisu z pliku, oblicza nowy SHA-256 i dopisuje rekord do logu.
7. Dodanie transakcji 1: 'Transakcja: Klient A wplaca 10 000 PLN'.
8. Dodanie transakcji 2: 'Transakcja: Klient B wyplaca 2 500 PLN'.
9. Dodanie transakcji 3: 'Transakcja: Klient C przelewa 45 000 PLN do Banku X'.
10. Dopisanie kolejnych transakcji (od 4 do 10) za pomocą pętli skryptu, tworząc łańcuch 10 powiązanych bloków.
11. Wyświetlenie i zbadanie pliku 'transakcje_audit.log' poleceniem 'cat transakcje_audit.log'.
12. Zwrócenie uwagi na kolumnę PREVIOUS_HASH i jej ścisłe powiązanie z polem CURRENT_HASH z linii poprzedniej.
13. Napisanie skryptu weryfikatora audytorskiego 'weryfikuj_lancuch.sh'.
14. Zaimplementowanie w skrypcie procedury: sekwencyjne przeliczanie skrótów SHA-256 dla każdego rekordu i sprawdzanie ciągłości łańcucha od Bloku Zerowego do końca pliku.
15. Uruchomienie weryfikatora na nienaruszonym pliku: potwierdzenie komunikatu '[AUDYT OK] Wszystkie bloki prawidlowe. Integralnosc dziennika transakcji zachowana'.
16. Symulacja ataku wewnętrznego przez nieuczciwego administratora: otwarcie pliku w edytorze nano i zmiana kwoty w transakcji 2 z '2 500 PLN' na '250 PLN' w celu zatarcia śladu wypłaty.
17. Zapisanie zmodyfikowanego pliku bez aktualizacji skrótów (symulacja naiwnej edycji logu).
18. Ponowne uruchomienie weryfikatora audytorskiego 'weryfikuj_lancuch.sh'.
19. Zarejestrowanie alarmu audytorskiego: natychmiastowe wskazanie numeru sfałszowanego bloku (Blok 2: Niezgodnosc biezacego hasza) oraz przerwanie łańcucha na Bloku 3 (Niezgodnosc hasza poprzedniego).
20. Sformułowanie wniosków technicznych dotyczących stosowania łańcuchów skrótów w systemach zgodności ze standardami SOX, PCI DSS i normą ISO/IEC 27001.

Struktura łańcucha skrótów (Hash Chain) gwarantuje właściwość Tamper-Evidence (widoczność manipulacji). Każdy rekord n zawiera skrót rekordu n-1. Jeżeli ktokolwiek zmieni treść rekordu n-1, jego skrót ulegnie całkowitej zmianie (efekt lawinowy), co spowoduje natychmiastową niezgodność z wartością zapisaną w rekordzie n, a w konsekwencji unieważni wszystkie kolejne bloki w łańcuchu.

Aby napastnik mógł skutecznie sfałszować wpis w środku łańcucha, musiałby przeliczyć na nowo skróty dla wszystkich kolejnych transakcji aż do końca pliku. W systemach produkcyjnych przed takim scenariuszem chroni regularne kotwiczenie (Anchoring / Timestamping) skrótu ostatniego bloku w niezależnym repozytorium zewnętrznym (np. w publicznym blockchainie lub serwerze znacznika czasu RFC 3161).

Poniżej przedstawiono przykładowy widok konsoli serwera demonstrujący procedurę weryfikacji nienaruszonego łańcucha oraz wykrycie próby sfałszowania historii transakcji:

W systemach o najwyższym reżimie prawnym (np. w bankach centralnych i izbach rozliczeniowych) nienaruszalne dzienniki zdarzeń są dodatkowo zapisywane na nośnikach pamięci masowej typu WORM (Write Once, Read Many). Technologia ta na poziomie sprzętowym uniemożliwia fizyczne nadpisanie lub skasowanie raz zapisanego sektora dysku.

W sprawozdaniu porównaj prosty łańcuch skrótów (Hash Chain) ze strukturą drzewa Merkle'a (Merkle Tree, omawianą w Laboratorium 6). Drzewa Merkle'a pozwalają na błyskawiczne udowodnienie obecności pojedynczej transakcji w bloku bez konieczności skanowania całego pliku dziennika.

1. Zrozumienie kryptograficznej koncepcji nienaruszalności dzienników zdarzeń (Tamper-evident Logging).
2. Rola funkcji skrótu SHA-256 i efektu lawinowego w zapewnieniu integralności łańcucha danych.
3. Wykazanie nieskuteczności tradycyjnych logów tekstowych w ochronie przed nadużyciami personelu uprzywilejowanego.
4. Znaczenie zewnętrznego kotwiczenia skrótów (Anchoring / Trusted Timestamping) w zabezpieczeniu przed fałszerstwem wstecznym.
5. Spełnienie wymogów ścieżki audytowej (Audit Trail) w świetle przepisów RODO, KRI oraz ustawy o rachunkowości.
6. Rekomendacje dotyczące wdrażania kryptograficznych rejestrów zdarzeń w krytycznych systemach transakcyjnych.

Przykładowe wnioski (wzór do sprawozdania): Implementacja kryptograficznego łańcucha skrótów (Hash Chain) w dzienniku transakcyjnym wykazała możliwość stworzenia w pełni nienaruszalnego rejestru audytowego (Tamper-evident Audit Log). Powiązanie każdego nowego wpisu ze skrótem SHA-256 poprzedniego rekordu sprawia, że jakakolwiek próba usunięcia lub zafałszowania historycznej transakcji powoduje natychmiastowe rozerwanie spójności całego łańcucha. Zastosowanie tej techniki uniemożliwia zacieranie śladów nieuprawnionych operacji finansowych nawet przez użytkowników posiadających najwyższe uprawnienia administracyjne do bazy danych. Cykliczne publikowanie skrótu końcowego (Root Hash) w zewnętrznym, niezależnym repozytorium gwarantuje niezaprzeczalność stanu bazy w określonym punkcie czasu. Opracowane rozwiązanie stanowi ekonomiczny i elegancki odpowiednik technologii rozproszonych rejestrów, znajdując szerokie zastosowanie w audycie systemów bankowych i giełdowych.