Laboratorium 4

Kon2 Podstawy kryptograficznej ochrony informacji. Kon3 Symetryczne i niesymetryczne algorytmy szyfrowania. Kon5 Szyfrowanie konwencjonalne; model i klasyczne techniki szyfrowania. Efekty uczenia się: W2, U1, U3, K1, K2.

Głównym celem zadania jest praktyczne zrozumienie ograniczeń klasycznej kryptografii symetrycznej na przykładzie standardu Data Encryption Standard (DES) oraz demonstracja przewagi nowoczesnego standardu Advanced Encryption Standard (AES). Studenci poznają zasady szyfrowania blokowego z wykorzystaniem bezpłatnego pakietu OpenSSL w wierszu poleceń systemu Linux.

W toku ćwiczenia zespół analizuje przestrzeń klucza 56-bitowego w algorytmie DES pod kątem odporności na współczesne ataki siłowe (brute-force) oraz bada różnice pomiędzy trybami szyfrowania blokowego: podatnym trybem ECB (Electronic Codebook) a bezpiecznym trybem CBC (Cipher Block Chaining). Studenci porównują narzut wydajnościowy obu algorytmów za pomocą modułu 'openssl speed'. Efektem prac jest raport techniczny uzasadniający konieczność bezwzględnego wycofania algorytmu DES z systemów przetwarzania danych.

Biuro Usług Finansowo-Księgowych „Fiskus” z Radomia przechowuje archiwalne zestawienia płacowe i bazy wynagrodzeń klientów zabezpieczone procedurą kryptograficzną opracowaną na początku lat 2000. Procedura ta wykorzystuje algorytm DES w trybie CBC do archiwizacji comiesięcznych deklaracji podatkowych i danych kadrowych.

W trakcie audytu zgodności z normą ISO/IEC 27001 oraz przepisami art. 32 RODO zewnętrzny audytor wskazał, że algorytm DES nie spełnia współczesnych wymagań bezpieczeństwa z uwagi na zbyt małą efektywną długość klucza (56 bitów). Taka przestrzeń kluczy może zostać przeszukana w czasie zaledwie kilkunastu minut przy użyciu niedrogich macierzy układów FPGA lub współczesnych kart graficznych.

Właściciel biura zlecił zespołowi studentów przeprowadzenie kontrolowanej analizy porównawczej. Zadanie polega na zaszyfrowaniu testowego pliku danych kadrowych za pomocą algorytmu DES oraz za pomocą nowoczesnego algorytmu AES-256 w trybie CBC, a następnie porównaniu integralności danych po deszyfracji oraz zbadaniu odporności obu rozwiązań.

Dodatkowo zespół bada podatność trybu ECB na ujawnianie struktury danych wejściowych, demonstrując dlaczego tryb ten nie zapewnia poufności danych powtarzalnych. Studenci badają wymogi OpenSSL 3.x, w którym algorytm DES został domyślnie przeniesiony do modułu przestarzałego (legacy provider), co wymusza świadome włączenie flagi wstecznej kompatybilności.

Końcowym efektem prac grupy jest opracowanie wytycznych migracji zasobów archiwalnych biura do standardu AES-256 oraz sformułowanie procedury weryfikacji sum kontrolnych SHA-256 gwarantującej nienaruszalność odtworzonych baz płacowych.

1. Zalogowanie się na stację roboczą z systemem Linux i sprawdzenie wersji zainstalowanego pakietu OpenSSL poleceniem 'openssl version'.
2. Utworzenie katalogu roboczego 'mkdir -p ~/lab4-des-aes && cd ~/lab4-des-aes'.
3. Utworzenie pliku testowego 'kadry_place.csv' zawierającego przykładowe dane osobowe (PESEL, imię, nazwisko, kwota wynagrodzenia brutto).
4. Wygenerowanie referencyjnej sumy kontrolnej SHA-256 dla pliku źródłowego: 'sha256sum kadry_place.csv > kadry_place.sha256'.
5. Podjęcie próby zaszyfrowania pliku za pomocą DES w OpenSSL 3.x poleceniem: 'openssl enc -des-cbc -in kadry_place.csv -out kadry_des.enc -k TajneHaslo123' i zaobserwowanie ewentualnego błędu braku dostępu do algorytmu legacy.
6. Włączenie modułu legacy provider w OpenSSL 3.x i poprawne zaszyfrowanie: 'openssl enc -des-cbc -provider legacy -provider default -in kadry_place.csv -out kadry_des.enc -k TajneHaslo123'.
7. Zbadanie struktury pliku zaszyfrowanego 'kadry_des.enc' za pomocą narzędzia file oraz hexdump: 'xxd kadry_des.enc | head -n 4' i odnotowanie nagłówka Salted__.
8. Zaszyfrowanie tego samego pliku źródłowego za pomocą nowoczesnego standardu AES-256 w trybie CBC: 'openssl enc -aes-256-cbc -pbkdf2 -in kadry_place.csv -out kadry_aes.enc -k TajneHaslo123'.
9. Porównanie rozmiarów plików zaszyfrowanych 'kadry_des.enc' (wielokrotność 8 bajtów - blok DES 64 bity) oraz 'kadry_aes.enc' (wielokrotność 16 bajtów - blok AES 128 bitów).
10. Odszyfrowanie pliku zaszyfrowanego DES do pliku tymczasowego: 'openssl enc -d -des-cbc -provider legacy -provider default -in kadry_des.enc -out kadry_des_dec.csv -k TajneHaslo123'.
11. Weryfikacja integralności odszyfrowanego pliku DES za pomocą sumy kontrolnej: 'sha256sum -c kadry_place.sha256' z podstawieniem pliku wynikowego.
12. Przeprowadzenie testu deszyfracji z podaniem błędnego hasła: 'openssl enc -d -des-cbc -provider legacy -provider default -in kadry_des.enc -out /dev/null -k ZleHaslo' i analiza komunikatu błędu 'bad decrypt'.
13. Odszyfrowanie pliku AES-256: 'openssl enc -d -aes-256-cbc -pbkdf2 -in kadry_aes.enc -out kadry_aes_dec.csv -k TajneHaslo123'.
14. Potwierdzenie zgodności sumy kontrolnej SHA-256 dla pliku odszyfrowanego z AES: 'sha256sum kadry_aes_dec.csv'.
15. Utworzenie pliku z powtarzalnym tekstem 'powtorzenia.txt' i zaszyfrowanie go za pomocą AES w trybie ECB: 'openssl enc -aes-256-ecb -pbkdf2 -in powtorzenia.txt -out powtorzenia_ecb.enc -k Haslo'.
16. Zbadanie wyniku poleceniem 'xxd powtorzenia_ecb.enc' i zaobserwowanie powtarzających się identycznych 16-bajtowych bloków szyfrogramu.
17. Zaszyfrowanie tego samego pliku w trybie CBC z wektorem IV: 'openssl enc -aes-256-cbc -pbkdf2 -in powtorzenia.txt -out powtorzenia_cbc.enc -k Haslo' i weryfikacja losowości bloków.
18. Przeprowadzenie testu wydajnościowego algorytmów poleceniem 'openssl speed des-cbc aes-256-cbc'.
19. Zarejestrowanie liczby przetworzonych bajtów na sekundę dla różnych rozmiarów bloków (16B, 64B, 256B, 1024B, 8192B) i analiza przewagi sprzętowej akceleracji AES-NI.
20. Sformułowanie wniosków technicznych dotyczących wycofania DES i rekomendacji pełnego wdrożenia AES-256-GCM/CBC.

W najnowszych wersjach pakietu OpenSSL (od wersji 3.0) algorytmy uważane za kryptograficznie przestarzałe i niebezpieczne (w tym DES, 3DES, RC4, MD4) zostały wyłączone z domyślnego dostawcy kryptograficznego. Aby z nich skorzystać, konieczne jest jawne dołączenie flagi '-provider legacy' obok '-provider default'. Jest to celowe działanie twórców biblioteki mające zapobiec przypadkowemu stosowaniu słabych szyfrów w nowych wdrożeniach.

Zwróć uwagę na flagę '-pbkdf2' przy szyfrowaniu AES. Wymusza ona użycie standardu Password-Based Key Derivation Function 2 (RFC 2898) z odpowiednią liczbą iteracji funkcji skrótu i solą kryptograficzną, co radykalnie zwiększa odporność hasła na ataki słownikowe z użyciem tablic tęczowych.

Poniżej przedstawiono przykładowy widok konsoli serwera Linux podczas szyfrowania pliku algorytmem DES i AES oraz weryfikacji sum kontrolnych SHA-256:

W trybie ECB (Electronic Codebook) każdy blok tekstu jawnego jest szyfrowany niezależnie tym samym kluczem. Jeśli w dokumencie powtarza się ten sam ciąg znaków o długości bloku, w szyfrogramie powstaną identyczne bloki szyfrogramu (słynny eksperyment z pingwinem Tuxem). Tryb CBC (Cipher Block Chaining) eliminuje tę wadę poprzez operację XOR z poprzednim blokiem szyfrogramu lub wektorem inicjalizacyjnym IV.

W sprawozdaniu przedstaw matematyczne uzasadnienie podatności klucza 56-bitowego: przestrzeń $2^{56} \approx 7.2 \times 10^{16}$ kombinacji w porównaniu do $2^{256} \approx 1.15 \times 10^{77}$ kombinacji w standardzie AES-256.

1. Wykazanie teoretycznej i praktycznej podatności algorytmu DES wynikającej z 56-bitowej długości klucza.
2. Zrozumienie decyzji twórców biblioteki OpenSSL o umieszczeniu DES w module legacy w wersji 3.x.
3. Porównanie właściwości trybów szyfrowania blokowego (podatność ECB na analizę wzorców vs bezpieczeństwo CBC).
4. Rola wektora inicjalizacyjnego (IV) i mechanizmu dopełniania (PKCS#7 padding) w szyfrowaniu blokowym.
5. Wpływ sprzętowej akceleracji instrukcji AES-NI na współczesną wydajność szyfrowania symetrycznego.
6. Rekomendacje dotyczące migracji przestarzałych archiwów kryptograficznych zgodnie z wytycznymi KSC i RODO.

Przykładowe wnioski (wzór do sprawozdania): Eksperymentalne badanie algorytmu DES jednoznacznie wykazało, że przestrzeń klucza wynosząca zaledwie 56 bitów czyni go całkowicie bezużytecznym we współczesnych systemach ochrony informacji z powodu podatności na ataki siłowe (Brute-Force). Zastosowanie nowoczesnego standardu AES z kluczem 256-bitowym oferuje astronomiczny poziom bezpieczeństwa, wykluczający możliwość złamania szyfru metodą przeszukiwania przestrzeni kluczy przy użyciu jakiejkolwiek znanej technologii obliczeniowej. Pomiary wydajnościowe w bibliotece OpenSSL udowodniły, że algorytm AES jest nie tylko nieporównywalnie bezpieczniejszy, ale również znacznie szybszy obliczeniowo dzięki sprzętowemu wsparciu instrukcji procesora AES-NI. Zrozumienie roli wektorów inicjalizujących (IV) w trybie blokowym CBC wyjaśniło konieczność zapewnienia ich losowości dla każdego szyfrowanego bloku. Przeprowadzone ćwiczenie stanowi przekonujący dowód na to, dlaczego algorytmy kryptograficzne podlegają nieuchronnemu procesowi starzenia i muszą być terminowo zastępowane nowymi standardami.

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

Celem ćwiczenia jest opanowanie praktycznych umiejętności stosowania kryptografii asymetrycznej (klucza publicznego) w komunikacji elektronicznej z wykorzystaniem otwartego standardu OpenPGP i narzędzia GnuPG (GPG). Studenci uczą się tworzenia pary kluczy asymetrycznych (klucz prywatny i publiczny), zarządzania lokalnym pierścieniem kluczy oraz bezpiecznej wymiany kluczy publicznych.

W toku ćwiczenia zespół realizuje scenariusz szyfrowania wiadomości i załączników prawnych za pomocą klucza publicznego odbiorcy oraz ich bezbłędnego odszyfrowywania za pomocą chronionego hasłem klucza prywatnego. Studenci weryfikują właściwości poufności komunikacji asymetrycznej w świetle tajemnicy adwokackiej i przepisów RODO. Wynikiem prac jest zestaw skonfigurowanych kluczy oraz sprawozdanie wdrożeniowe.

Kancelaria Prawna „Lex-Protect” w Lublinie reprezentuje klientów w sporach gospodarczych, sprawach patentowych oraz fuzjach przedsiębiorstw. Prawnicy kancelarii codziennie przesyłają pocztą elektroniczną projekty umów, opinie prawne oraz poufne zeznania świadków do współpracujących radców prawnych i biegłych sądowych.

Do tej pory załączniki e-mail były przesyłane w postaci niezaszyfrowanych plików PDF lub prostych archiwów ZIP zabezpieczonych krótkim hasłem przekazywanym tym samym kanałem pocztowym. Dziekan Okręgowej Rady Adwokackiej podczas szkolenia z cyberbezpieczeństwa przypomniał o bezwzględnym obowiązku zachowania tajemnicy zawodowej i wskazał, że standardowa poczta SMTP nie gwarantuje poufności na serwerach pośredniczących.

Kierownictwo kancelarii podjęło decyzję o wdrożeniu standardu OpenPGP do szyfrowania wszelkiej zewnętrznej korespondencji poufnej. Każdy prawnik i współpracownik kancelarii musi posiadać własną, unikalną parę kluczy RSA o długości minimum 3072 bitów.

Zespół studentów wciela się w administratorów bezpieczeństwa wdrażających to rozwiązanie na dwóch stacjach roboczych (reprezentujących mecenasa i współpracującego rzecznika patentowego). Studenci generują klucze w programie GnuPG, eksportują klucze publiczne w formacie tekstowym ASCII-Armor (.asc), wymieniają je pomiędzy maszynami, importują do lokalnych baz zaufania i przeprowadzają testy szyfrowania wiadomości tekstowych oraz plików binarnych.

Końcowym elementem zadania jest analiza procedur awaryjnych: wygenerowanie certyfikatu unieważnienia klucza (Revocation Certificate) na wypadek kradzieży laptopa prawnika oraz zdefiniowanie polityki bezpiecznego przechowywania kopii zapasowej klucza prywatnego.

1. Weryfikacja instalacji narzędzia GnuPG na stacji roboczej Linux/Windows poleceniem 'gpg --version'.
2. Utworzenie dedykowanego katalogu roboczego 'mkdir -p ~/gpg-lab && cd ~/gpg-lab'.
3. Uruchomienie kreatora generowania pary kluczy asymetrycznych poleceniem 'gpg --full-generate-key'.
4. Wybór rodzaju klucza: opcja domyślna '(1) RSA and RSA' (klucz do szyfrowania i podpisu).
5. Określenie długości klucza: wprowadzenie wartości '3072' lub '4096' bitów dla zapewnienia długoterminowego bezpieczeństwa.
6. Zdefiniowanie okresu ważności klucza: wprowadzenie '1y' (ważność 1 rok) w celu wymuszenia okresowej rotacji.
7. Wprowadzenie tożsamości użytkownika: Imię i nazwisko (np. 'Mecenas Jan Kowalski'), adres e-mail ('j.kowalski@lexprotect.local') oraz komentarz opcjonalny ('Kancelaria Lex-Protect').
8. Wprowadzenie silnego, co najmniej 16-znakowego hasła chroniącego klucz prywatny (passphrase).
9. Weryfikacja wygenerowanego klucza w lokalnym magazynie poleceniem 'gpg --list-keys'.
10. Odnotowanie identyfikatora klucza (Key ID) oraz odcisku palca (Fingerprint) o długości 40 znaków heksadecymalnych.
11. Wygenerowanie pliku certyfikatu unieważnienia klucza: 'gpg --output uniewaznienie_kowalski.rev --gen-revoke j.kowalski@lexprotect.local'.
12. Wyeksportowanie klucza publicznego do pliku tekstowego z opcją ASCII-Armor: 'gpg --armor --export j.kowalski@lexprotect.local > klucz_publiczny_kowalski.asc'.
13. Zbadanie zawartości pliku 'klucz_publiczny_kowalski.asc' i zaobserwowanie nagłówka '-----BEGIN PGP PUBLIC KEY BLOCK-----'.
14. Powtórzenie procedury generowania pary kluczy dla drugiego uczestnika (np. 'Rzecznik Anna Nowak', 'a.nowak@lexprotect.local').
15. Wymiana kluczy publicznych pomiędzy uczestnikami (zaimportowanie klucza partnera poleceniem 'gpg --import klucz_publiczny_nowak.asc').
16. Weryfikacja odcisku palca zaimportowanego klucza: 'gpg --fingerprint a.nowak@lexprotect.local' i telefoniczne potwierdzenie zgodności ze współpracownikiem.
17. Utworzenie poufnego dokumentu 'opinia_prawna.txt' i zaszyfrowanie go kluczem publicznym odbiorcy: 'gpg --armor --encrypt --recipient a.nowak@lexprotect.local opinia_prawna.txt'.
18. Zaobserwowanie utworzenia pliku 'opinia_prawna.txt.asc' i próba otwarcia go w edytorze tekstowym (potwierdzenie nieczytelności szyfrogramu).
19. Przekazanie pliku zaszyfrowanego do odbiorcy i jego pomyślne odszyfrowanie kluczem prywatnym: 'gpg --decrypt opinia_prawna.txt.asc > odszyfrowana_opinia.txt' po podaniu poprawnego hasła passphrase.
20. Sformułowanie wniosków technicznych dotyczących zarządzania kluczami asymetrycznymi w organizacji prawniczej.

W kryptografii klucza publicznego klucz publiczny służy wyłącznie do szyfrowania wiadomości i może być bezpiecznie udostępniony każdemu (np. opublikowany na stronie internetowej kancelarii lub wysłany na publiczny serwer kluczy). Klucz prywatny służy do deszyfracji i pod żadnym pozorem nie może opuścić stacji roboczej właściciela ani zostać udostępniony osobom trzecim.

Opcja '--armor' (lub '-a') nakazuje programowi GnuPG wygenerowanie wyniku w formacie ASCII-Armor (kodowanie Radix-64). Pozwala to na bezpośrednie wklejenie zaszyfrowanego tekstu do treści zwykłej wiadomości e-mail lub komunikatora bez ryzyka uszkodzenia bajtów binarnych przez serwery pocztowe.

Poniżej przedstawiono przykładowy widok konsoli podczas eksportu klucza publicznego, szyfrowania dokumentu prawniczego oraz jego odszyfrowania:

Klucz prywatny GPG w systemie Linux jest przechowywany w katalogu domowym użytkownika w '~/.gnupg/private-keys-v1.d/'. Prawa dostępu do tego katalogu muszą być bezwzględnie ustawione na 700 ('drwx------').

Certyfikat unieważnienia (Revocation Certificate) wygenerowany na początku należy zapisać na bezpiecznym, odłączonym nośniku (np. zaszyfrowanym pendrive w sejfie kancelarii). Jeśli laptop mecenasa zostanie zgubiony lub skradziony, opublikowanie certyfikatu unieważnienia poinformuje kontrahentów, aby przestali szyfrować wiadomości tym kluczem.

1. Zrozumienie asymetrii ról klucza publicznego (szyfrowanie) i klucza prywatnego (deszyfracja).
2. Ocena skuteczności standardu OpenPGP w zabezpieczeniu tajemnicy korespondencji na serwerach pocztowych pośredniczących (End-to-End Encryption).
3. Rola hasła passphrase w ochronie klucza prywatnego przechowywanego na dysku stacji roboczej.
4. Znaczenie procedury weryfikacji odcisku palca (Fingerprint) w eliminacji podatności na atak Man-in-the-Middle przy wymianie kluczy.
5. Konieczność generowania i bezpiecznego archiwizowania certyfikatów unieważnienia kluczy (Revocation Certificate).
6. Wymogi formalno-prawne dotyczące ochrony tajemnicy adwokackiej i danych klientów zgodnie z RODO.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie narzędzia GnuPG w kancelarii prawnej udowodniło wyższość kryptografii asymetrycznej w rozwiązywaniu odwiecznego problemu bezpiecznej dystrybucji kluczy pomiędzy stronami korespondencji. Szyfrowanie wiadomości kluczem publicznym odbiorcy gwarantuje, że wyłącznie posiadacz odpowiadającego mu klucza prywatnego chronionego silnym hasłem frazowym jest w stanie odczytać poufne akta sprawy. Zastosowanie bezpiecznych algorytmów asymetrycznych (RSA-4096 lub Ed25519) skutecznie chroni treść pism procesowych przesyłanych przez niezaufane serwery pośredniczące w sieci Internet. Zrozumienie koncepcji sieci zaufania (Web of Trust) oraz weryfikacji odcisków palców kluczy (Key Fingerprints) pozwoliło wyeliminować zagrożenie podszywania się pod klienta kancelarii przez osoby trzecie. Opanowanie obsługi GPG stanowi dla przyszłych prawników i audytorów niezbędną umiejętność zapewniającą praktyczną realizację ustawowego obowiązku zachowania tajemnicy zawodowej.

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

Celem zadania jest praktyczne zrozumienie kryptograficznego mechanizmu podpisu cyfrowego, który zapewnia niezaprzeczalność, integralność oraz autentyczność dokumentów elektronicznych. Studenci poznają relację pomiędzy kryptograficzną funkcją skrótu (SHA-256/SHA-512) a kluczem prywatnym nadawcy.

W trakcie laboratorium zespół realizuje scenariusz podpisywania dokumentów tekstowych oraz plików binarnych za pomocą podpisu otoczonego (clearsign) oraz podpisu odłączonego (detached signature). Studenci przeprowadzają kontrolowany eksperyment manipulacji zawartością podpisanego pliku (ang. tampering), demonstrując natychmiastowe wykrycie modyfikacji przez procedurę weryfikacyjną GnuPG. Wynikiem jest raport analizujący prawne i techniczne skutki podpisu cyfrowego.

Wydawnictwo Naukowe „Akademia-Press” w Krakowie zawiera ze swoimi autorami i recenzentami umowy wydawnicze oraz protokoły odbioru dzieł w formie elektronicznej. Dokumenty te zawierają oświadczenia woli dotyczące przeniesienia autorskich praw majątkowych oraz ustalenia honorariów autorskich.

W przeszłości doszło do sporu sądowego, w którym nieuczciwy współpracownik twierdził, że treść wysłanego przez niego mailowo aneksu do umowy została zmodyfikowana na serwerze pocztowym wydawnictwa. Zwykły plik PDF czy dokument Worda nie posiada wbudowanych mechanizmów uniemożliwiających edycję, a wykazanie pierwotnego brzmienia pliku bez podpisu kryptograficznego było w procesie sądowym niezwykle trudne.

Kierownictwo wydawnictwa zdecydowało o wprowadzeniu standardu podpisywania cyfrowego wszystkich protokołów odbioru i aneksów za pomocą narzędzia GnuPG przed ich przesłaniem do drugiej strony. Rozwiązanie to ma zagwarantować pełną niezaprzeczalność pochodzenia dokumentu oraz natychmiastowe wykrywanie jakiejkolwiek zmiany choćby pojedynczego przecinka lub cyfry w tekście.

Zespół studentów wciela się w role redaktora naczelnego oraz autora publikacji. Studenci przygotowują wzorcowy protokół odbioru dzieła, podpisują go kluczem prywatnym autora, przesyłają do weryfikacji, a następnie symulują próbę nieautoryzowanej zmiany kwoty wynagrodzenia w podpisanym pliku, analizując reakcję oprogramowania weryfikującego.

W końcowym etapie prac zespół analizuje różnicę pomiędzy podpisem clearsign (czytelnym dla człowieka z doklejonym blokiem PGP) a podpisem odłączonym (.sig/.asc), przydatnym do podpisywania dużych plików instalacyjnych i obrazów ISO.

1. Przygotowanie środowiska roboczego GnuPG z parą kluczy wygenerowaną w zadaniu 02 lub wygenerowanie nowego klucza dla Autora.
2. Utworzenie pliku z oświadczeniem woli: 'echo "Niniejszym przenosze autorskie prawa majatkowe do monografii na Wydawnictwo za kwote 5000 PLN." > umowa_autorska.txt'.
3. Złożenie podpisu cyfrowego w formacie czytelnym tekstowo (Clearsigned Message): 'gpg --clearsign umowa_autorska.txt'.
4. Zbadanie powstałego pliku 'umowa_autorska.txt.asc' w edytorze tekstowym i odnotowanie znaczników '-----BEGIN PGP SIGNED MESSAGE-----' oraz '-----BEGIN PGP SIGNATURE-----'.
5. Przeprowadzenie poprawnej weryfikacji podpisu cyfrowego poleceniem: 'gpg --verify umowa_autorska.txt.asc'.
6. Odnotowanie w wyniku weryfikacji komunikatu 'gpg: Good signature from "Autor..."' oraz daty i godziny złożenia podpisu.
7. Symulacja ataku manipulacji treścią (tampering): otwarcie pliku 'umowa_autorska.txt.asc' w edytorze nano i zmiana kwoty z '5000 PLN' na '9000 PLN' bez modyfikacji bloku podpisu.
8. Zapisanie zmodyfikowanego pliku i ponowna próba weryfikacji: 'gpg --verify umowa_autorska.txt.asc'.
9. Zarejestrowanie alarmującego komunikatu błędu: 'gpg: BAD signature from... [ultimate]' oraz 'verification failed'.
10. Przywrócenie oryginalnej treści i weryfikacja ponownego uzyskania statusu 'Good signature'.
11. Przygotowanie pliku binarnego (np. obrazu okładki książki): 'dd if=/dev/urandom of=okladka_monografii.bin bs=1M count=2'.
12. Złożenie podpisu odłączonego (Detached Signature) w formacie binarnym: 'gpg --detach-sign okladka_monografii.bin'.
13. Złożenie podpisu odłączonego w formacie ASCII-Armor: 'gpg --armor --detach-sign okladka_monografii.bin'.
14. Zbadanie struktury plików: obecność pliku danych 'okladka_monografii.bin' oraz zewnętrznego pliku podpisu 'okladka_monografii.bin.asc'.
15. Przeprowadzenie weryfikacji podpisu odłączonego: 'gpg --verify okladka_monografii.bin.asc okladka_monografii.bin'.
16. Zmiana jednego bajtu w pliku binarnym 'okladka_monografii.bin' za pomocą edytora heksadecymalnego lub polecenia 'echo "x" >> okladka_monografii.bin'.
17. Ponowna weryfikacja podpisu odłączonego i zaobserwowanie natychmiastowego zgłoszenia naruszenia integralności ('BAD signature').
18. Przeanalizowanie roli kryptograficznej funkcji skrótu SHA-256 w procesie podpisu cyfrowego (podpisywany jest skrót pliku, a nie cały plik).
19. Zestawienie różnic prawnych pomiędzy zaawansowanym podpisem cyfrowym GPG a kwalifikowanym podpisem elektronicznym w rozumieniu unijnego rozporządzenia eIDAS.
20. Sformułowanie wniosków końcowych na temat niezaprzeczalności oświadczeń woli w obrocie cyfrowym.

Podpis cyfrowy nie szyfruje treści pliku, lecz zapewnia jego integralność i autentyczność. W procesie podpisywania program GnuPG najpierw oblicza kryptograficzny skrót (hash) dokumentu za pomocą bezpiecznej funkcji skrótu (domyślnie SHA-256 lub SHA-512), a następnie szyfruje ten krótki skrót kluczem prywatnym nadawcy.

W procesie weryfikacji odbiorca deszyfruje otrzymany skrót kluczem publicznym nadawcy, samodzielnie oblicza skrót z otrzymanego dokumentu i porównuje obie wartości. Jeśli choćby jeden bit w dokumencie uległ zmianie, obliczony skrót będzie całkowicie inny (efekt lawinowy), co skutkuje wyświetleniem komunikatu 'BAD signature'.

Poniżej przedstawiono przykładowy widok konsoli demonstrujący pomyślną weryfikację podpisu oraz wykrycie próby fałszerstwa kwoty w umowie:

W podpisie 'clearsign' treść dokumentu pozostaje w pełni czytelna w zwykłym notatniku czy przeglądarce, co ułatwia ludziom zapoznanie się z tekstem przed weryfikacją techniczną. Należy jednak pamiętać, że programy pocztowe mogą czasami automatycznie zamieniać znaki końca linii (CRLF na LF), co może spowodować fałszywy alarm błędu podpisu.

Dla oprogramowania, sterowników czy obrazów płyt ISO standardem jest podpis odłączony (Detached Signature z rozszerzeniem .sig lub .asc), dzięki czemu użytkownik pobiera oryginalny plik binarny oraz mały, kilkusetbajtowy plik z podpisem.

1. Zrozumienie kryptograficznej zasady działania podpisu cyfrowego (hashowanie dokumentu + szyfrowanie skrótu kluczem prywatnym).
2. Praktyczny dowód na natychmiastowe wykrywanie modyfikacji treści (tampering) przez algorytmy kryptograficzne.
3. Znaczenie podpisu cyfrowego dla zapewnienia niezaprzeczalności (Non-repudiation) oświadczeń woli nadawcy.
4. Porównanie formatów podpisu: podpis otoczony (clearsign) a podpis odłączony (detached signature).
5. Świadomość różnic regulacyjnych pomiędzy podpisem PGP a kwalifikowanym podpisem elektronicznym (eIDAS / polska ustawa o usługach zaufania).
6. Rekomendacje dotyczące wdrożenia podpisów cyfrowych w procesach obiegu dokumentacji w przedsiębiorstwach.

Przykładowe wnioski (wzór do sprawozdania): Praktyczne składanie i weryfikacja podpisów cyfrowych GPG pozwoliły na dogłębne zrozumienie fundamentalnej różnicy pomiędzy poufnością (szyfrowaniem) a autentycznością i niezaprzeczalnością informacji. Zastosowanie podpisu cyfrowego, polegającego na zaszyfrowaniu skrótu dokumentu kluczem prywatnym nadawcy, jednoznacznie wiąże tożsamość autora z określoną treścią oświadczenia woli. Eksperyment polegający na modyfikacji pojedynczego znaku w podpisanym pliku umowy natychmiast wywołał alarm błędu weryfikacji sygnatury w poleceniu 'gpg --verify', potwierdzając matematyczną wrażliwość mechanizmu na naruszenie integralności. Wykazano, że podpis odłączony (Detached Signature) stanowi doskonałe rozwiązanie do poświadczania nienaruszalności plików binarnych, obrazów ISO oraz oprogramowania bez ingerencji w strukturę samego pliku. Opanowanie tej technologii ma kluczowe znaczenie inżynierskie dla wdrażania bezpiecznego, bezpapierowego obiegu dokumentów w administracji i gospodarce cyfrowej.

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, K3.

Celem ćwiczenia jest opanowanie kompleksowej procedury budowy i zarządzania lokalną architekturą infrastruktury klucza publicznego (Public Key Infrastructure – PKI) opartej o hierarchiczny model zaufania X.509. Studenci uczą się tworzyć główny urząd certyfikacji (Root CA) oraz realizować pełny cykl życia certyfikatów serwerowych przy użyciu narzędzia OpenSSL.

W toku laboratorium zespół konfiguruje strukturę katalogową urzędu, generuje klucze asymetryczne RSA, tworzy żądania podpisania certyfikatów (CSR), weryfikuje ich poprawność, podpisuje certyfikaty z odpowiednimi rozszerzeniami X.509v3 (w tym Subject Alternative Name – SAN) oraz przeprowadza weryfikację łańcucha zaufania poleceniem 'openssl verify'. Studenci analizują wymogi prawne i normatywne stawiane wewnętrznym centrom zaufania. Prace kończą się przygotowaniem sprawozdania technicznego.

Centrum Medyczne „Medica-Profil” w Gnieźnie posiada rozbudowaną sieć wewnętrzną łączącą 18 gabinetów specjalistycznych, laboratorium analityczne, pracownię rentgenowską oraz lokalny serwer bazy danych Elektronicznej Dokumentacji Medycznej (EDM). Wszystkie stacje robocze pracują w domenie lokalnej 'medica.local'.

Wdrażane nowe oprogramowanie medyczne oraz system przesyłania cyfrowych zdjęć rentgenowskich (PACS) wymagają bezwzględnego szyfrowania TLS oraz wzajemnego uwierzytelniania serwerów i stacji diagnostycznych. Z uwagi na zamknięty charakter sieci placówki zakup kilkudziesięciu certyfikatów komercyjnych od zewnętrznych centrów certyfikacji generowałby niepotrzebne, wysokie koszty roczne, a dodatkowo publiczne CA nie wystawiają certyfikatów dla domen lokalnych (np. .local).

Dyrektor przychodni podjął decyzję o uruchomieniu wewnętrznego, autonomicznego Urzędu Certyfikacji (Root CA). Zadaniem urzędu jest wystawianie zaufanych certyfikatów X.509 dla wewnętrznych serwerów EDM, serwera PACS oraz routerów sieciowych, z jednoczesnym wdrożeniem certyfikatu głównego do magazynów zaufania na wszystkich komputerach personelu.

Zespół studentów wciela się w administratorów bezpieczeństwa PKI powołanych przez placówkę. Do zadań grupy należy skonfigurowanie dedykowanego pliku 'openssl.cnf', utworzenie bazy danych wystawionych certyfikatów, wygenerowanie 4096-bitowej pary kluczy Root CA, obsłużenie wniosku CSR nadesłanego przez administratora serwera EDM oraz wystawienie certyfikatu serwera zgodnego z najnowszymi standardami przeglądarek (deklaracja SAN).

Końcowym etapem jest udokumentowanie procedury weryfikacji integralności i autentyczności wystawionego certyfikatu, wykazanie poprawności łańcucha certyfikacji oraz opracowanie polityki ochrony klucza prywatnego Root CA.

1. Zalogowanie się na stację roboczą Linux i utworzenie dedykowanej struktury katalogowej urzędu certyfikacji: 'mkdir -p ~/medica-ca/{certs,crl,newcerts,private,requests}'.
2. Ustawienie restrykcyjnych uprawnień dla katalogu kluczy prywatnych: 'chmod 700 ~/medica-ca/private'.
3. Zainicjowanie bazy danych urzędu CA poleceniami: 'touch ~/medica-ca/index.txt' oraz 'echo 1000 > ~/medica-ca/serial'.
4. Przygotowanie dedykowanego pliku konfiguracyjnego 'ca.cnf' definiującego politykę urzędu, domyślny czas ważności (365 dni) oraz wymagane pola tożsamości.
5. Wygenerowanie 4096-bitowego klucza prywatnego urzędu Root CA zabezpieczonego silnym hasłem passphrase: 'openssl genrsa -aes256 -out ~/medica-ca/private/medica_root.key 4096'.
6. Wygenerowanie samopodpisanego certyfikatu głównego Root CA o ważności 10 lat: 'openssl req -config ca.cnf -key ~/medica-ca/private/medica_root.key -new -x509 -days 3650 -sha256 -extensions v3_ca -out ~/medica-ca/certs/medica_root.crt'.
7. Wprowadzenie atrybutów urzędu: Country Name (PL), Organization Name (Centrum Medyczne Medica-Profil), Common Name (Medica-Profil Wewnetrzne Root CA).
8. Weryfikacja zawartości certyfikatu Root CA poleceniem: 'openssl x509 -noout -text -in ~/medica-ca/certs/medica_root.crt'.
9. Na stacji serwera EDM (lub w osobnym katalogu) wygenerowanie 2048-bitowego klucza prywatnego serwera WWW: 'openssl genrsa -out ~/medica-ca/requests/edm_server.key 2048'.
10. Utworzenie żądania podpisania certyfikatu (CSR) dla serwera EDM: 'openssl req -new -key ~/medica-ca/requests/edm_server.key -out ~/medica-ca/requests/edm_server.csr'.
11. Wprowadzenie w CSR identyfikatora serwera: Common Name = 'edm.medica.local'.
12. Przygotowanie pliku rozszerzeń 'edm_ext.cnf' zawierającego sekcję 'subjectAltName = DNS:edm.medica.local,IP:192.168.1.100' oraz 'extendedKeyUsage = serverAuth'.
13. Podpisanie wniosku CSR serwera kluczem głównym Root CA: 'openssl x509 -req -in ~/medica-ca/requests/edm_server.csr -CA ~/medica-ca/certs/medica_root.crt -CAkey ~/medica-ca/private/medica_root.key -CAcreateserial -out ~/medica-ca/certs/edm_server.crt -days 365 -sha256 -extfile edm_ext.cnf'.
14. Wprowadzenie hasła do klucza Root CA i autoryzacja wystawienia certyfikatu serwera.
15. Weryfikacja wpisu w bazie wystawionych certyfikatów: sprawdzenie aktualizacji pliku 'serial' i wpisu w 'index.txt'.
16. Odczytanie właściwości wystawionego certyfikatu serwera i upewnienie się o obecności rozszerzenia SAN: 'openssl x509 -noout -text -in ~/medica-ca/certs/edm_server.crt | grep -A 2 "Subject Alternative Name"'.
17. Przeprowadzenie formalnej weryfikacji kryptograficznego łańcucha zaufania poleceniem: 'openssl verify -CAfile ~/medica-ca/certs/medica_root.crt ~/medica-ca/certs/edm_server.crt'.
18. Potwierdzenie uzyskania komunikatu 'edm_server.crt: OK'.
19. Zasymulowanie próby weryfikacji certyfikatu przy użyciu obcego, niepowiązanego certyfikatu CA i odnotowanie błędu walidacji łańcucha.
20. Opracowanie sprawozdania technicznego zawierającego schemat hierarchii PKI, listingi operacyjne oraz zalecenia procedury unieważniania certyfikatów (listy CRL).

W infrastrukturze klucza publicznego certyfikat X.509 jest cyfrowym dokumentem wiążącym tożsamość podmiotu (np. nazwę serwera) z jego kluczem publicznym. Podpis urzędu certyfikacji złożony pod tym dokumentem poświadcza, że klucz publiczny rzeczywiście należy do deklarowanego właściciela.

Rozszerzenie Subject Alternative Name (SAN) jest krytycznym elementem współczesnych certyfikatów serwerowych. Przeglądarki internetowe całkowicie zignorowały dawne pole Common Name (CN) jako kryterium walidacji domeny. Jeśli w certyfikacie zabraknie wpisu SAN dopasowanego do wpisywanego adresu, przeglądarka zablokuje połączenie z błędem braku dopasowania tożsamości.

Poniżej przedstawiono przykładowy widok konsoli z procedury podpisania certyfikatu serwera medycznego oraz pomyślnej weryfikacji łańcucha zaufania:

Klucz prywatny głównego urzędu Root CA ('medica_root.key') jest fundamentem bezpieczeństwa całej placówki. Jeśli klucz ten zostanie skompromitowany, napastnik może wystawiać fałszywe certyfikaty dla dowolnych serwisów i przeprowadzać niewykrywalne ataki Man-in-the-Middle. W środowiskach o wysokim rygorze maszyna Root CA jest całkowicie odłączona od sieci fizycznej (tzw. air-gap).

W systemie Windows wdrożenie certyfikatu Root CA do komputerów personelu wykonuje się za pomocą konsoli przystawki 'certlm.msc' (Magazyn Komputera -> Zaufane główne urzędy certyfikacji) lub centralnie poprzez usługę Active Directory Group Policy.

1. Zrozumienie architektury Public Key Infrastructure (PKI) i roli certyfikatów X.509 w uwierzytelnianiu podmiotów sieciowych.
2. Wykazanie korzyści ekonomicznych i organizacyjnych płynących z wdrożenia prywatnego Root CA w sieciach zamkniętych (LAN/intranet).
3. Rola i struktura żądania podpisania certyfikatu (CSR) w bezpiecznym rozdziale ról administratora serwera i operatora CA.
4. Bezwzględna konieczność stosowania rozszerzenia Subject Alternative Name (SAN) we współczesnych standardach internetowych.
5. Praktyczna weryfikacja hierarchii kryptograficznej za pomocą polecenia openssl verify.
6. Wytyczne dotyczące ochrony klucza prywatnego Root CA oraz procedur unieważniania certyfikatów (listy CRL).

Przykładowe wnioski (wzór do sprawozdania): Samodzielne zbudowanie lokalnej infrastruktury klucza publicznego (PKI) w przychodni lekarskiej wyjaśniło złożoność procesów zarządzania cyklem życia tożsamości cyfrowych w organizacji. Poprawna konfiguracja rozszerzeń X.509 v3 (Basic Constraints, Extended Key Usage) zapobiegła powszechnym błędom konfiguracyjnym, gwarantując, że certyfikaty stacji roboczych nie mogą być wykorzystane do nieuprawnionego wystawiania certyfikatów podrzędnych. Wykorzystanie certyfikatów klienckich do wzajemnego uwierzytelniania w systemie EDM radykalnie podniosło poziom bezpieczeństwa dostępu do wrażliwych baz pacjentów. Zrozumienie roli list unieważnień certyfikatów (CRL) wykazało konieczność ciągłego monitorowania ważności uprawnień i natychmiastowego blokowania kluczy w razie kompromitacji stacji lub odejścia pracownika. Projekt udowodnił, że wewnętrzne środowisko PKI oparte na otwartych bibliotekach OpenSSL stanowi w pełni funkcjonalne i bezkosztowe rozwiązanie dla małych i średnich jednostek ochrony zdrowia.

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

Celem ćwiczenia jest uświadomienie studentom różnic w odporności kryptograficznej mechanizmów zabezpieczania skompresowanych archiwów plików oraz nabycie praktycznych umiejętności bezpiecznego pakowania danych za pomocą bezpłatnego oprogramowania 7-Zip (CLI i GUI). Studenci badają podatność klasycznego algorytmu ZipCrypto na ataki ze znanym tekstem jawnym (Known-Plaintext Attack) oraz ataki siłowe.

W trakcie laboratorium zespół tworzy archiwa zabezpieczone przestarzałym mechanizmem ZipCrypto oraz nowoczesnym standardem AES-256 z szyfrowaniem nagłówków archiwum (ukrywanie nazw plików). Studenci analizują strukturę wewnętrzną archiwów, testują odporność na próby podejrzenia metadanych bez znajomości hasła oraz przeprowadzają audyt procedur archiwizacji dokumentacji finansowej. Zadanie wieńczy raport wdrożeniowy.

Agencja Pracy Tymczasowej „Kariera-Plus” w Katowicach przetwarza miesięcznie dane osobowe i rozliczenia podatkowe ponad tysiąca pracowników tymczasowych delegowanych do zakładów produkcyjnych. Pliki z bazami płacowymi, numerami rachunków bankowych oraz umowami zlecenie są raz w miesiącu pakowane do archiwów ZIP i przesyłane do zewnętrznej centrali rozliczeniowej.

Rutynowy audyt bezpieczeństwa wykazał, że pracownicy działu kadr do kompresji danych używają wbudowanego w system Windows domyślnego kreatora archiwów ZIP lub starszych programów kompresujących ze standardowym algorytmem ZipCrypto. Algorytm ten został opracowany w 1989 roku i posiada krytyczną wadę konstrukcyjną – dysponując zaledwie kilkoma bajtami znanego tekstu jawnego (np. standardowym nagłówkiem pliku PDF czy DOCX), można odzyskać klucze wewnętrzne archiwum w czasie zaledwie kilku minut przy użyciu darmowego oprogramowania pkcrack.

Co więcej, standardowy format ZIP szyfruje jedynie zawartość plików, pozostawiając ich nazwy, rozmiary oraz strukturę katalogów w postaci jawnej. Każda osoba posiadająca dostęp do pliku archiwum może dokładnie sprawdzić, czyje nazwiska znajdują się na liście płac.

Zarząd agencji zlecił zespołowi studentów przeprowadzenie demonstracji podatności archiwów ZipCrypto oraz wdrożenie bezpiecznej procedury opartej na darmowym narzędziu 7-Zip wykorzystującym standard szyfrowania AES-256 z parametrem szyfrowania nagłówków (opcja -mhe=on).

Zespół przygotowuje zestawienie porównawcze, demonstruje różnicę w widoczności metadanych w obu formatach oraz opracowuje instrukcję postępowania dla personelu kadr eliminującą ryzyko wycieku danych w transporcie.

1. Weryfikacja instalacji narzędzia 7-Zip w systemie Linux ('p7zip-full') lub Windows ('7z.exe') poleceniem '7z --help'.
2. Utworzenie katalogu roboczego 'mkdir -p ~/lab4-7zip && cd ~/lab4-7zip'.
3. Przygotowanie zestawu poufnych dokumentów kadrowych: 'lista_plac_maj.xlsx', 'umowy_zlecenie.pdf', 'rejestr_rachunkow.csv'.
4. Zaszyfrowanie plików w tradycyjnym formacie ZIP za pomocą przestarzałego algorytmu ZipCrypto (symulacja procedury legacy): '7z a -tzip -mem=ZipCrypto -pTajneHaslo archiwum_podatne.zip *.xlsx *.pdf *.csv'.
5. Zbadanie struktury pliku 'archiwum_podatne.zip' bez podawania hasła poleceniem '7z l archiwum_podatne.zip'.
6. Odnotowanie krytycznej obserwacji: nazwy wszystkich plików, ich rozmiary oraz daty modyfikacji są w pełni widoczne dla każdego obserwatora.
7. Utworzenie bezpiecznego archiwum w formacie 7z z wykorzystaniem algorytmu AES-256 bez ukrywania nagłówków: '7z a -t7z -pTajneHaslo archiwum_aes_jawne.7z *.xlsx *.pdf *.csv'.
8. Sprawdzenie listowania plików poleceniem '7z l archiwum_aes_jawne.7z' (nazwy plików nadal widoczne).
9. Utworzenie w pełni utwardzonego archiwum z szyfrowaniem nagłówków (opcja -mhe=on): '7z a -t7z -mhe=on -pTajneHaslo archiwum_aes_poufne.7z *.xlsx *.pdf *.csv'.
10. Próba wylistowania zawartości utwardzonego archiwum bez znajomości hasła: '7z l archiwum_aes_poufne.7z'.
11. Zarejestrowanie monitu o hasło: program odmawia wyświetlenia nawet nazw plików bez uprzedniego podania poprawnego hasła.
12. Wprowadzenie błędnego hasła i zaobserwowanie błędu 'Cannot open encrypted archive. Wrong password?'.
13. Pomyślne wylistowanie i rozpakowanie archiwum po podaniu poprawnego hasła: '7z x -pTajneHaslo archiwum_aes_poufne.7z -o./rozpakowane/'.
14. Weryfikacja sum kontrolnych SHA-256 wypakowanych dokumentów z plikami źródłowymi: 'sha256sum -c referencyjne.sha256'.
15. Porównanie nagłówków plików 'archiwum_podatne.zip' oraz 'archiwum_aes_poufne.7z' za pomocą narzędzia xxd/hexdump.
16. Analiza podatności algorytmu ZipCrypto na atak Bihama-Kocha (Known-Plaintext Attack) z wykorzystaniem narzędzia pkcrack.
17. Obliczenie czasu łamania hasła 8-znakowego w ZipCrypto vs AES-256 z wykorzystaniem nowoczesnych narzędzi kryptoanalitycznych (Hashcat).
18. Przetestowanie procedury szyfrowania z poziomu graficznego interfejsu 7-Zip GUI w systemie Windows z zaznaczeniem opcji 'Zaszyfruj nazwy plików'.
19. Sporządzenie tabelarycznego porównania mechanizmów: ZipCrypto vs AES-256 (długość klucza, widoczność metadanych, odporność na kryptoanalizę).
20. Opracowanie procedury bezpiecznego przekazywania haseł do archiwów poza pasmem (np. SMS, komunikator szyfrowany) zamiast w tej samej wiadomości e-mail.

W formacie archiwum standardu ZIP informacja o strukturze katalogów i nazwach plików (Central Directory) znajduje się na końcu pliku i zgodnie ze specyfikacją PKWARE nie podlega szyfrowaniu. Pozwala to programom archiwizującym na szybkie wyświetlenie spisu zawartości, ale stanowi poważny wyciek metadanych (Metadata Leakage).

Format 7z z opcją '-mhe=on' (Encrypt Header) szyfruje całą strukturę Central Directory za pomocą 256-bitowego klucza AES. Dopóki użytkownik nie poda prawidłowego hasła, plik archiwum wygląda jak całkowicie losowy ciąg danych binarnych, uniemożliwiając nawet stwierdzenie ile plików i jakiego typu znajduje się wewnątrz.

Poniżej przedstawiono przykładowy widok konsoli demonstrujący blokadę podglądu metadanych w archiwum 7z z aktywną opcją '-mhe=on':

Przesyłanie hasła do archiwum w treści tej samej wiadomości e-mail jest kardynalnym błędem niweczącym sens szyfrowania. W przypadku przechwycenia wiadomości przez niepowołaną osobę, napastnik uzyskuje jednocześnie szyfrogram i klucz. Hasło należy przekazywać innym kanałem komunikacji (Out-of-Band), np. telefonicznie lub przez szyfrowany komunikator Signal.

Darmowy program 7-Zip jest oprogramowaniem Open Source (licencja GNU LGPL), co oznacza, że może być legalnie i bezpłatnie wykorzystywany w firmach, instytucjach publicznych oraz placówkach komercyjnych bez żadnych opłat licencyjnych.

1. Wykazanie krytycznych podatności archiwów zabezpieczonych przestarzałym algorytmem ZipCrypto.
2. Zrozumienie zjawiska wycieku metadanych i ocena korzyści płynących z szyfrowania nagłówków archiwum (-mhe=on).
3. Przewaga algorytmu AES-256 w formacie 7z nad standardowym szyfrowaniem ZIP.
4. Wpływ procedur przekazywania haseł poza pasmem (Out-of-Band) na rzeczywisty poziom bezpieczeństwa danych.
5. Analiza zgodności procedur archiwizacji dokumentacji kadrowej z art. 32 RODO.
6. Rekomendacje dotyczące standaryzacji oprogramowania 7-Zip w całej strukturze przedsiębiorstwa.

Przykładowe wnioski (wzór do sprawozdania): Eksperyment porównawczy archiwizatorów obnażył krytyczną podatność klasycznego algorytmu ZipCrypto na atak ze znanym tekstem jawnym (Known Plaintext Attack), umożliwiający złamanie hasła narzędziem bkcrack w zaledwie kilka minut. W przeciwieństwie do przestarzałych mechanizmów, implementacja algorytmu AES-256 w programie 7-Zip z funkcją wyprowadzania klucza PBKDF2 zapewnia pełną odporność na kryptoanalizę i ataki słownikowe. Kluczową zaletą formatu 7z okazała się opcja szyfrowania nagłówków (Header Encryption), która całkowicie uniemożliwia intruzowi poznanie nazw plików, ich rozmiarów czy struktury katalogów przed podaniem hasła. Zastosowanie silnych haseł frazowych w połączeniu z AES-256 gwarantuje spełnienie rygorystycznych wymogów ochrony dokumentacji płacowej i numerów PESEL wynikających z przepisów RODO. Przeprowadzone ćwiczenie stanowi ważną lekcję uświadamiającą, że sam fakt zabezpieczenia pliku hasłem nie gwarantuje bezpieczeństwa, jeżeli użyto przestarzałego algorytmu kryptograficznego.

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.

Celem ćwiczenia jest praktyczne opanowanie zarządzania cyfrowymi certyfikatami klucza jawnego X.509 w systemie sieciowym MikroTik RouterOS CLI. Studenci poznają zasady generowania wewnętrznego urzędu certyfikacji (CA) na routerze, wystawiania i podpisywania certyfikatów serwerowych oraz ich powiązywania z bezpiecznymi usługami zarządzania urządzeniem (API-SSL, www-ssl, SSTP).

W trakcie laboratorium zespół bada architekturę magazynu certyfikatów RouterOS, analizuje flagi stanu certyfikatu (flagi K, T, A), realizuje procedurę eksportu certyfikatów publicznych oraz importu zaufanych certyfikatów Root CA. Studenci weryfikują działanie szyfrowanego kanału administracyjnego i utwardzają router przed atakami w warstwie zarządzania. Wynikiem jest w pełni zabezpieczona brama sieciowa oraz sprawozdanie z wdrożenia.

Regionalne Centrum Kształcenia Ustawicznego w Sosnowcu zarządza rozproszoną siecią łączącą budynek główny z pracowniami warsztatowymi za pośrednictwem routerów MikroTik RouterOS. Z uwagi na wymogi bezpieczeństwa centralny router placówki musi obsługiwać szyfrowane połączenia administracyjne oraz szyfrowane tunele VPN dla pracowników zdalnych.

W trakcie audytu stwierdzono, że na routerze wykorzystywane są tymczasowe certyfikaty wygenerowane bez zachowania hierarchii zaufania, a usługi zarządzania (takie jak API oraz WinBox) korzystają z nieszyfrowanych portów, co stwarza ryzyko przechwycenia sesji administracyjnej przez studentów w pracowniach komputerowych.

Administrator sieci otrzymał polecenie uporządkowania gospodarki certyfikatami w systemie RouterOS: utworzenia formalnego wewnętrznego urzędu certyfikacji (RouterOS CA), wygenerowania certyfikatu dla bezpiecznego interfejsu WWW (www-ssl) oraz certyfikatu dla bezpiecznego interfejsu API (api-ssl), z bezwzględnym wyłączeniem usług nieszyfrowanych.

Zespół studentów podejmuje się realizacji tego zadania w środowisku laboratoryjnym. Uczestnicy logują się do konsoli RouterOS, tworzą strukturę certyfikatów, podpisują je za pomocą wewnętrznego CA urządzenia, eksportują certyfikat główny do pliku i instalują go na stacji roboczej administratora.

Końcowym etapem jest weryfikacja: poprawne zestawienie bezpiecznej sesji HTTPS na porcie 443, pomyślne połączenie z usługą api-ssl na porcie 8729 oraz potwierdzenie braku możliwości nawiązania połączenia na portach nieszyfrowanych.

1. Zalogowanie się do konsoli routera MikroTik RouterOS za pomocą bezpiecznego terminala SSH lub programu WinBox.
2. Weryfikacja aktualnej listy certyfikatów w systemie poleceniem '/certificate print'.
3. Usunięcie ewentualnych przestarzałych certyfikatów tymczasowych poleceniem '/certificate remove [find]'.
4. Utworzenie definicji głównego certyfikatu urzędu Root CA: '/certificate add name=MikroTik-Root-CA common-name="RCKU Sosnowiec Root CA" key-size=4096 days-valid=3650 key-usage=key-cert-sign,crl-sign'.
5. Podpisanie certyfikatu Root CA wewnątrz systemu RouterOS: '/certificate sign MikroTik-Root-CA'.
6. Zatwierdzenie procesu podpisania klawiszem Enter i odczekanie na wygenerowanie 4096-bitowej pary kluczy.
7. Sprawdzenie flag certyfikatu Root CA poleceniem '/certificate print' i upewnienie się o obecności flag 'K' (Private Key) oraz 'T' (Trusted).
8. Utworzenie szablonu certyfikatu dla usług serwerowych: '/certificate add name=Router-Server-Cert common-name=192.168.88.1 key-size=2048 days-valid=730 key-usage=digital-signature,key-encipherment,tls-server'.
9. Podpisanie certyfikatu serwera przy użyciu wcześniej utworzonego certyfikatu Root CA: '/certificate sign Router-Server-Cert ca=MikroTik-Root-CA'.
10. Weryfikacja w '/certificate print detail', czy certyfikat serwerowy poprawnie wskazuje na urząd 'MikroTik-Root-CA' jako wystawcę.
11. Wyeksportowanie certyfikatu publicznego Root CA do pamięci urządzenia: '/certificate export-certificate MikroTik-Root-CA export-passphrase="" type=pem'.
12. Weryfikacja obecności wyeksportowanego pliku w magazynie plików routera poleceniem '/file print where name~"cert"'.
13. Przypisanie certyfikatu serwerowego do usługi www-ssl: '/ip service set www-ssl certificate=Router-Server-Cert disabled=no port=443'.
14. Włączenie bezpiecznej usługi API-SSL z powiązaniem do certyfikatu serwera: '/ip service set api-ssl certificate=Router-Server-Cert disabled=no port=8729'.
15. Deaktywacja nieszyfrowanych usług zarządzania: '/ip service set www disabled=yes' oraz '/ip service set api disabled=yes'.
16. Pobranie wyeksportowanego pliku certyfikatu 'cert_export_MikroTik-Root-CA.crt' na stację roboczą klienta Windows (za pomocą WinBox lub SFTP).
17. Zaimportowanie certyfikatu Root CA do magazynu 'Zaufane główne urzędy certyfikacji' w systemie Windows.
18. Otwarcie w przeglądarce internetowej adresu 'https://192.168.88.1' i potwierdzenie pełnego zaufania do certyfikatu routera (zielona kłódka bez monitów o błędzie).
19. Przetestowanie dostępności portów za pomocą polecenia PowerShell 'Test-NetConnection -ComputerName 192.168.88.1 -Port 8729' (potwierdzenie aktywności api-ssl).
20. Sformułowanie wniosków końcowych dotyczących bezpieczeństwa zarządzania urządzeniami sieciowymi w instytucjach edukacyjnych.

System MikroTik RouterOS posiada w pełni funkcjonalny, wbudowany silnik PKI, który eliminuje konieczność korzystania z zewnętrznych serwerów Linux do generowania certyfikatów dla potrzeb routera. Umożliwia to stworzenie kompletnej hierarchii dwustopniowej (Root CA -> Certyfikat Usługi) bezpośrednio z poziomu konsoli sieciowej.

Flaga 'K' (Private Key) oznacza, że w pamięci routera znajduje się klucz prywatny danego certyfikatu, co jest niezbędne do działania usług serwerowych. W przypadku wyeksportowania certyfikatu publicznego dla klientów klucz prywatny nigdy nie jest dołączany, chyba że administrator jawnie poda parametr 'export-passphrase'.

Poniżej przedstawiono listing sesji konsoli RouterOS obrazujący procedurę podpisywania certyfikatu serwera przez wewnętrzne CA oraz konfigurację usług:

Podczas eksportu certyfikatu Root CA poleceniem '/certificate export-certificate MikroTik-Root-CA export-passphrase=""' brak hasła oznacza, że eksportowany jest wyłącznie publiczny certyfikat X.509 (plik .crt). Jest to w pełni bezpieczne i taki plik można bezpiecznie rozpowszechniać wśród pracowników.

W przypadku wdrożeń produkcyjnych warto zdefiniować parametr 'crl-download-url' umożliwiający routerowi i klientom sprawdzanie aktualnej listy odwołanych certyfikatów.

1. Zrozumienie możliwości wbudowanego silnika PKI w systemie sieciowym MikroTik RouterOS.
2. Rola dwustopniowej hierarchii zaufania (Root CA -> Certyfikat końcowy) w zarządzaniu infrastrukturą sieciową.
3. Znaczenie flag atrybutów klucza (key-usage: key-cert-sign vs tls-server) w standardzie X.509.
4. Wpływ wyłączenia nieszyfrowanych usług zarządzania (HTTP port 80, API port 8728) na redukcję powierzchni ataku.
5. Praktyczne aspekty integracji certyfikatów urządzeń sieciowych z systemowymi magazynami zaufania Windows.
6. Wytyczne dotyczące ochrony urządzeń brzegowych w placówkach sektora edukacji i administracji publicznej.

Przykładowe wnioski (wzór do sprawozdania): Ćwiczenie praktyczne na platformie MikroTik RouterOS wykazało, że nowoczesne systemy sieciowe posiadają wbudowane, zaawansowane podsystemy kryptograficzne zdolne do samodzielnego generowania i obsługi certyfikatów X.509. Prawidłowe zdefiniowanie ról i flag certyfikatu (server, client) zapobiega błędom negocjacji sesji w bezpiecznych usługach sieciowych, takich jak SSTP czy API-SSL. Wykazano, że klucze prywatne przechowywane w pamięci urządzenia muszą być bezwzględnie chronione przed nieautoryzowanym eksportem poprzez stosowanie haseł szyfrujących plik kopii zapasowej. Zastąpienie domyślnych certyfikatów unikalnymi poświadczeniami kryptograficznymi eliminuje zagrożenie fałszowania tożsamości routera w sieci korporacyjnej. Opanowanie składni poleceń zarządzania certyfikatami w CLI RouterOS stanowi podstawową umiejętność każdego inżyniera sieciowego dbającego o bezpieczną komunikację urządzeń brzegowych.

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

Głównym celem zadania jest praktyczne zrozumienie architektury kryptosystemów hybrydowych, stanowiących fundament współczesnego bezpiecznego Internetu (w tym protokołów TLS, PGP oraz SSH). Studenci dowiadują się, dlaczego szyfrowanie asymetryczne (RSA) nie nadaje się do bezpośredniego przetwarzania dużych wolumenów danych i w jaki sposób łączy się je z wydajnym szyfrowaniem symetrycznym (AES).

W ramach laboratorium zespół projektuje i manualnie realizuje procedurę szyfrowania hybrydowego: wygenerowanie jednorazowego klucza sesyjnego AES-256, zaszyfrowanie nim dużego pliku binarnego (np. obrazu dysku lub bazy danych), zaszyfrowanie samego klucza sesyjnego kluczem publicznym RSA odbiorcy oraz bezpieczne spakowanie pakietu kryptograficznego. Studenci weryfikują proces odwrotny i analizują narzut obliczeniowy. Zadanie kończy się opracowaniem raportu technicznego.

Wojewódzkie Centrum Krwiodawstwa i Krwiolecznictwa w Kielcach generuje cotygodniowe zaszyfrowane zrzuty baz danych krwiodawców, stanów magazynowych koncentratów krwinek oraz wyników badań wirusologicznych o objętości przekraczającej kilkaset megabajtów. Pakiety te muszą być bezpiecznie przekazywane do centralnego repozytorium Ministerstwa Zdrowia.

Młodszy programista zaproponował zaszyfrowanie całego pliku bazy danych bezpośrednio kluczem publicznym RSA ministerstwa. Podczas próby wykonania polecenia 'openssl rsautl -encrypt' operacja zakończyła się natychmiastowym błędem 'data too large for key size'. Zespół zdał sobie sprawę, że algorytm RSA może zaszyfrować jedynie dane o rozmiarze mniejszym niż długość klucza (dla RSA 2048 z dopełnieniem OAEP jest to maksymalnie 214 bajtów).

Kierownik działu IT polecił wdrożenie klasycznego schematu szyfrowania hybrydowego, który łączy nieograniczoną pojemność i szybkość symetrycznego szyfru AES-256-CBC z bezpieczną dystrybucją klucza zapewnianą przez asymetryczny algorytm RSA.

Zespół studentów ma za zadanie zaimplementować tę procedurę w powłoce systemu Linux. Grupa tworzy parę kluczy RSA (odbiorcy), generuje losowy klucz sesyjny AES za pomocą generatora kryptograficznego '/dev/urandom', szyfruje plik danych algorytmem AES, szyfruje klucz sesyjny kluczem publicznym RSA, a następnie przeprowadza pełny proces deszyfracji po stronie odbiorcy.

W podsumowaniu studenci analizują zysk wydajnościowy podejścia hybrydowego w stosunku do czystej kryptografii asymetrycznej oraz wskazują analogię do mechanizmu TLS Handshake.

1. Zalogowanie się na stację Linux i utworzenie katalogu 'mkdir -p ~/lab4-hybrid && cd ~/lab4-hybrid'.
2. Wygenerowanie 2048-bitowej pary kluczy RSA Odbiorcy: 'openssl genrsa -out odbiorca_private.pem 2048'.
3. Wyodrębnienie klucza publicznego RSA Odbiorcy: 'openssl rsa -in odbiorca_private.pem -pubout -out odbiorca_public.pem'.
4. Przygotowanie dużego pliku testowego danych medycznych (np. 10 MB): 'dd if=/dev/urandom of=baza_krwi.dat bs=1M count=10'.
5. Obliczenie referencyjnej sumy kontrolnej SHA-256: 'sha256sum baza_krwi.dat > baza_krwi.sha256'.
6. Wygenerowanie kryptograficznie bezpiecznego, losowego 256-bitowego (32 bajty) klucza sesyjnego: 'openssl rand 32 > klucz_sesyjny.bin'.
7. Wygenerowanie losowego 128-bitowego (16 bajtów) wektora inicjalizacyjnego IV: 'openssl rand 16 > iv.bin'.
8. Konwersja klucza i wektora IV do postaci heksadecymalnej za pomocą xxd: 'KEY_HEX=$(xxd -p -c 32 klucz_sesyjny.bin)' oraz 'IV_HEX=$(xxd -p -c 16 iv.bin)'.
9. Zaszyfrowanie pliku bazy danych algorytmem AES-256 w trybie CBC przy użyciu wygenerowanego klucza i IV: 'openssl enc -aes-256-cbc -in baza_krwi.dat -out baza_krwi.enc -K $KEY_HEX -iv $IV_HEX'.
10. Zaszyfrowanie pliku klucza sesyjnego kluczem publicznym RSA odbiorcy przy użyciu bezpiecznego dopełnienia OAEP: 'openssl pkeyutl -encrypt -pubin -inkey odbiorca_public.pem -in klucz_sesyjny.bin -out klucz_sesyjny.enc -pkeyopt rsa_padding_mode:oaep'.
11. Zaszyfrowanie pliku wektora IV (lub dołączenie go w postaci jawnej do pakietu, gdyż IV nie musi być tajny): 'openssl pkeyutl -encrypt -pubin -inkey odbiorca_public.pem -in iv.bin -out iv.enc -pkeyopt rsa_padding_mode:oaep'.
12. Skompletowanie pakietu kryptograficznego: plik zaszyfrowanych danych 'baza_krwi.enc', zaszyfrowany klucz 'klucz_sesyjny.enc' oraz 'iv.enc'.
13. Symulacja przesłania pakietu do odbiorcy i usunięcie z pamięci zmiennych '$KEY_HEX' i '$IV_HEX'.
14. Rozpoczęcie procedury deszyfracji po stronie Odbiorcy: odszyfrowanie klucza sesyjnego kluczem prywatnym RSA: 'openssl pkeyutl -decrypt -inkey odbiorca_private.pem -in klucz_sesyjny.enc -out odszyfrowany_klucz.bin -pkeyopt rsa_padding_mode:oaep'.
15. Odszyfrowanie wektora IV kluczem prywatnym RSA: 'openssl pkeyutl -decrypt -inkey odbiorca_private.pem -in iv.enc -out odszyfrowany_iv.bin -pkeyopt rsa_padding_mode:oaep'.
16. Pobranie wartości heksadecymalnych odszyfrowanego klucza i IV: 'DEC_KEY_HEX=$(xxd -p -c 32 odszyfrowany_klucz.bin)' oraz 'DEC_IV_HEX=$(xxd -p -c 16 odszyfrowany_iv.bin)'.
17. Odszyfrowanie pliku danych algorytmem AES-256-CBC: 'openssl enc -d -aes-256-cbc -in baza_krwi.enc -out baza_krwi_odszyfrowana.dat -K $DEC_KEY_HEX -iv $DEC_IV_HEX'.
18. Weryfikacja integralności odzyskanego pliku: 'sha256sum baza_krwi_odszyfrowana.dat' i porównanie z plikiem 'baza_krwi.sha256'.
19. Potwierdzenie bezbłędnej zgodności sum kontrolnych (status OK).
20. Sformułowanie wniosków technicznych dotyczących analogii pomiędzy ręczną procedurą hybrydową a automatycznym protokołem TLS/SSL.

Kryptografia asymetryczna (RSA) opiera się na złożonych operacjach modularnych na olbrzymich liczbach pierwszych, co sprawia, że jest ona od 1000 do 10000 razy wolniejsza od kryptografii symetrycznej (AES). Ponadto maksymalny rozmiar bloku danych, jaki można zaszyfrować kluczem RSA, jest ściśle ograniczony rozmiarem modułu n (dla klucza 2048-bitowego jest to 256 bajtów minus narzut dopełnienia OAEP).

Rozwiązaniem tego problemu jest schemat hybrydowy (ang. KEM/DEM – Key Encapsulation Mechanism / Data Encapsulation Mechanism). Dane o dowolnym rozmiarze szyfruje się błyskawicznym algorytmem AES za pomocą losowego klucza sesyjnego, a powolny algorytm RSA służy wyłącznie do zaszyfrowania tego malutkiego, 32-bajtowego klucza sesyjnego.

Poniżej przedstawiono przykładowy widok konsoli z procedury szyfrowania hybrydowego oraz weryfikacji sumy kontrolnej po deszyfracji:

Zawsze stosuj dopełnienie OAEP (Optimal Asymmetric Encryption Padding) przy operacjach szyfrowania kluczem RSA. Starszy schemat dopełniania PKCS#1 v1.5 posiada udowodnione teoretyczne podatności na ataki typu Padding Oracle (atak Bleichenbachera).

Wektor inicjalizacyjny IV (Initialization Vector) w trybie CBC nie musi być tajny – jego jedynym zadaniem jest zapewnienie losowości pierwszego bloku szyfrogramu. Może być przesłany jawnym tekstem obok pliku zaszyfrowanego, jednak w naszym ćwiczeniu zaszyfrowanie go stanowi dobrą praktykę ochrony spójności parametrów.

1. Zrozumienie matematycznych i wydajnościowych przyczyn stosowania kryptosystemów hybrydowych.
2. Wykazanie ograniczeń rozmiaru danych wejściowych w algorytmie RSA w zależności od długości klucza.
3. Rola jednorazowego klucza sesyjnego (Session Key) w bezpiecznym przetwarzaniu dużych zbiorów danych.
4. Znaczenie bezpiecznych schematów dopełniania (RSA-OAEP) w ochronie przed kryptoanalizą.
5. Praktyczne powiązanie ćwiczenia z mechanizmami działania protokołów TLS/HTTPS, SSH oraz PGP.
6. Wytyczne dotyczące zabezpieczenia krytycznych baz danych sektora ochrony zdrowia przed wyciekiem w transporcie.

Przykładowe wnioski (wzór do sprawozdania): Realizacja procedury szyfrowania hybrydowego pozwoliła na praktyczne zrozumienie synergii pomiędzy potężną wydajnością algorytmów symetrycznych a elastycznością dystrybucji kluczy w kryptografii asymetrycznej. Zastosowanie losowego klucza jednorazowego AES-256 do zaszyfrowania dużego wolumenu danych rozwiązało problem ograniczeń rozmiaru bloku oraz powolności obliczeniowej algorytmu RSA. Zaszyfrowanie samego klucza symetrycznego kluczem publicznym RSA odbiorcy zapewniło stuprocentową poufność kanału wymiany bez konieczności wcześniejszego uzgadniania wspólnego sekretu. Wykazano, że mechanizm ten stanowi faktyczny fundament działania współczesnych protokołów bezpiecznej transmisji, w tym TLS, PGP oraz szyfrowanych komunikatorów. Przeprowadzenie całej procedury za pomocą pojedynczych poleceń OpenSSL udowodniło, że studenci w pełni rozumieją matematyczny i inżynierski obieg kluczy w architekturze hybrydowej.

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

Celem ćwiczenia jest opanowanie bezpiecznego mechanizmu uwierzytelniania asymetrycznego w protokole Secure Shell (SSH) pomiędzy stacją roboczą klienta Windows a serwerem Linux. Studenci poznają zasady generowania par kluczy kryptograficznych (w standardzie Ed25519 oraz RSA), bezpiecznego transferu klucza publicznego do pliku authorized_keys oraz konfiguracji demona OpenSSH.

W toku laboratorium zespół analizuje podatności tradycyjnego uwierzytelniania hasłowego na ataki siłowe (brute-force) i przechwytywanie poświadczeń. Studenci wdrażają procedurę bezwzględnego wyłączenia logowania hasłem w pliku 'sshd_config', wymuszając wyłączną autoryzację kluczem asymetrycznym chronionym hasłem passphrase. Ćwiczenie kończy się weryfikacją z poziomu konsoli PowerShell oraz przygotowaniem referatu wdrożeniowego.

Regionalny Software House „Dev-Cloud” w Gliwicach zarządza serwerami aplikacyjnymi i bazami danych dla klientów z sektora bankowego i medycznego. Administratorzy łączą się ze środowiskami produkcyjnymi Linux za pośrednictwem protokołu SSH (port 22).

W analizie logów systemowych ('/var/log/auth.log') stwierdzono setki tysięcy nieudanych prób logowania na konto 'root' oraz popularne nazwy kont administracyjnych, pochodzących z botnetów skanujących Internet. Dotychczasowa polityka dopuszczała uwierzytelnianie hasłem, co przy przypadkowym użyciu słabego hasła przez jednego z programistów mogło doprowadzić do przejęcia serwera produkcyjnego.

Dyrektor ds. bezpieczeństwa wydał zarządzenie nakazujące natychmiastowe wdrożenie uwierzytelniania opartego na kryptografii asymetrycznej (klucz publiczny/prywatny) oraz całkowite zablokowanie możliwości logowania hasłem ('PasswordAuthentication no').

Zespół studentów ma za zadanie zrealizować to utwardzenie w środowisku laboratoryjnym. Uczestnicy generują na stacji roboczej Windows nowoczesną parę kluczy opartą na krzywych eliptycznych (Ed25519) za pomocą wbudowanego w Windows klienta OpenSSH, przesyłają klucz publiczny na serwer Linux, konfigurują uprawnienia w katalogu '~/.ssh/' i modyfikują konfigurację usługi sshd.

W fazie testów zespół potwierdza, że logowanie z użyciem klucza prywatnego przebiega bez przeszkód, natomiast próba zalogowania bez klucza lub z obcej stacji roboczej jest natychmiast odrzucana przez serwer bez pytania o hasło.

1. Uruchomienie konsoli PowerShell na stacji roboczej Windows z uprawnieniami zwykłego użytkownika.
2. Weryfikacja dostępności wbudowanego klienta SSH poleceniem 'ssh -V'.
3. Wygenerowanie nowoczesnej pary kluczy asymetrycznych opartych na krzywych eliptycznych Ed25519: 'ssh-keygen -t ed25519 -C "programista@devcloud.local"'.
4. Wskazanie domyślnej lokalizacji zapisu klucza ('C:\Users\Uzytkownik\.ssh\id_ed25519').
5. Wprowadzenie i potwierdzenie silnego hasła zabezpieczającego klucz prywatny (passphrase).
6. Zbadanie zawartości katalogu '.ssh' na stacji Windows: identyfikacja klucza prywatnego 'id_ed25519' oraz klucza publicznego 'id_ed25519.pub'.
7. Wyświetlenie zawartości klucza publicznego poleceniem 'Get-Content ~\.ssh\id_ed25519.pub'.
8. Zalogowanie się na serwer Linux przy użyciu dotychczasowego hasła: 'ssh student@192.168.1.100'.
9. Utworzenie na serwerze Linux katalogu konfiguracji SSH użytkownika: 'mkdir -p ~/.ssh && chmod 700 ~/.ssh'.
10. Przesłanie klucza publicznego z Windows na serwer Linux za pomocą narzędzia scp: 'scp ~\.ssh\id_ed25519.pub student@192.168.1.100:~/.ssh/temp_key.pub'.
11. Na serwerze Linux dopisanie klucza do autoryzowanych hostów: 'cat ~/.ssh/temp_key.pub >> ~/.ssh/authorized_keys && rm ~/.ssh/temp_key.pub'.
12. Ustawienie rygorystycznych uprawnień dla pliku kluczy na serwerze: 'chmod 600 ~/.ssh/authorized_keys'.
13. W nowym oknie PowerShell na stacji Windows przetestowanie logowania kluczem: 'ssh student@192.168.1.100'.
14. Odnotowanie monitu o hasło klucza prywatnego (passphrase) i potwierdzenie pomyślnego zalogowania bez pytania o hasło konta systemowego Linux.
15. Na serwerze Linux otwarcie do edycji pliku konfiguracyjnego demona SSH: 'sudo nano /etc/ssh/sshd_config' (lub utworzenie pliku w '/etc/ssh/sshd_config.d/hardening.conf').
16. Wprowadzenie restrykcyjnych dyrektyw: 'PasswordAuthentication no', 'PubkeyAuthentication yes', 'PermitEmptyPasswords no'.
17. Przetestowanie poprawności składni konfiguracji sshd poleceniem 'sudo sshd -t'.
18. Przeładowanie usługi demona SSH poleceniem 'sudo systemctl reload sshd'.
19. Przeprowadzenie testu negatywnego: próba logowania ze stacji bez klucza lub z wymuszeniem hasła 'ssh -o PubkeyAuthentication=no student@192.168.1.100' i zaobserwowanie błędu 'Permission denied (publickey)'.
20. Opracowanie sprawozdania technicznego z analizą przewagi kryptografii Ed25519 nad tradycyjnym RSA 2048.

Algorytm Ed25519 (oparty na krzywej Edwardsa Curve25519) jest obecnie rekomendowanym standardem dla kluczy SSH. W porównaniu do tradycyjnego algorytmu RSA 2048, klucze Ed25519 są niezwykle zwięzłe (klucz publiczny ma zaledwie 68 znaków), zapewniają wyższy poziom bezpieczeństwa kryptograficznego (odpowiednik RSA 3072-bit), są odporne na ataki czasowe (Side-Channel Attacks) oraz generują się i negocjują błyskawicznie.

Uprawnienia do katalogu '~/.ssh' (700) oraz pliku 'authorized_keys' (600) w systemie Linux są ściśle weryfikowane przez demona OpenSSH (mechanizm 'StrictModes'). Jeśli plik posiada uprawnienia zapisu dla grupy lub innych użytkowników, demon SSH ze względów bezpieczeństwa odmówi logowania kluczem, traktując konfigurację jako podatną na modyfikację przez osoby trzecie.

Poniżej przedstawiono przykładowy widok konsoli z procedury generowania klucza Ed25519 w PowerShell oraz testu blokady logowania hasłem:

W systemie Windows kluczem prywatnym można zarządzać za pomocą wbudowanej usługi 'OpenSSH Authentication Agent' (ssh-agent). Pozwala to na jednorazowe odblokowanie klucza po starcie systemu i automatyczne logowanie do wielu serwerów bez konieczności wpisywania hasła passphrase przy każdym połączeniu.

Zawsze miej otwartą jedną działającą sesję SSH na serwerze podczas przeładowywania demona 'sshd'. W razie błędu w konfiguracji nie zostaniesz odcięty od serwera i będziesz mógł natychmiast poprawić plik konfiguracyjny.

1. Zrozumienie kryptograficznej przewagi uwierzytelniania kluczem asymetrycznym nad podatnymi hasłami statycznymi.
2. Wpływ wyłączenia 'PasswordAuthentication no' na całkowite wyeliminowanie ryzyka skutecznego ataku Brute-Force na port SSH.
3. Zalety algorytmu krzywych eliptycznych Ed25519 w porównaniu z klasycznym algorytmem RSA.
4. Kluczowa rola mechanizmu 'StrictModes' i rygorystycznych uprawnień systemu plików Linux (chmod 700 / 600).
5. Praktyczna umiejętność konfiguracji bezpiecznego dostępu administracyjnego z poziomu systemu Windows.
6. Wytyczne dotyczące zarządzania kluczami prywatnymi pracowników i procedur ich unieważniania przy rotacji kadr.

Przykładowe wnioski (wzór do sprawozdania): Migracja z uwierzytelniania hasłowego na uwierzytelnianie kluczem asymetrycznym w usłudze OpenSSH całkowicie eliminuje podatność serwera na masowe ataki siłowe (Brute-Force) oraz ataki słownikowe. Wybór nowoczesnej krzywej eliptycznej Ed25519 zapewnił nie tylko najwyższy poziom bezpieczeństwa kryptograficznego, ale także zwięzły rozmiar klucza i błyskawiczny czas nawiązywania połączenia. Prawidłowe skonfigurowanie uprawnień systemu plików w katalogu ~/.ssh (prawa 700 dla katalogu i 600 dla pliku authorized_keys) okazało się krytycznym warunkiem poprawnego działania demona sshd. Obowiązkowe zabezpieczenie klucza prywatnego na stacji roboczej silnym hasłem frazowym (Passphrase) chroni serwer przed włamaniem nawet w razie kradzieży samego pliku klucza z dysku administratora. Bezwzględne wyłączenie dyrektywy 'PasswordAuthentication' w pliku konfiguracyjnym stanowi fundamentalną zasadę utwardzania (hardeningu) każdego serwera produkcyjnego Linux.

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

Celem ćwiczenia jest opanowanie umiejętności projektowania i wdrażania bezpiecznego tunelu wirtualnej sieci prywatnej (VPN) z wykorzystaniem protokołu Secure Socket Tunneling Protocol (SSTP) w systemie MikroTik RouterOS z autoryzacją opartą na certyfikatach cyfrowych X.509. Studenci uczą się zabezpieczać ruch tranzytowy pomiędzy oddziałami firmy za pośrednictwem publicznej sieci Internet.

W trakcie laboratorium zespół bada architekturę protokołu SSTP, który enkapsuluje ruch PPP wewnątrz standardowej sesji TLS na porcie 443 TCP, co umożliwia bezproblemowe pokonywanie zapór ogniowych i serwerów NAT. Studenci generują certyfikaty, konfigurują serwer SSTP, profil PPP oraz konto użytkownika w RouterOS, a następnie zestawiają szyfrowane połączenie ze stacji Windows. Zadanie kończy się analizą sprawności tunelu i sprawozdaniem technicznym.

Przedsiębiorstwo Geodezyjne „Geo-Pomiar” w Tarnowie posiada centralę biurową oraz trzy terenowe bazy pomiarowe zlokalizowane w różnych miastach województwa. Geodeci w terenie korzystają z mobilnego Internetu LTE i muszą codziennie przesyłać wielogigabajtowe chmury punktów skaningu laserowego oraz operaty do serwera plików w centrali.

Dotychczasowe próby zestawienia tradycyjnych tuneli IPsec lub PPTP kończyły się niepowodzeniem z uwagi na rygorystyczne blokady protokołów GRE i ESP stosowane przez operatorów sieci komórkowych oraz hotelowe punkty dostępowe Wi-Fi. Z kolei transmisja nieszyfrowana była wykluczona ze względu na poufność danych państwowego zasobu geodezyjnego.

Administrator sieci zaproponował wdrożenie protokołu SSTP (Secure Socket Tunneling Protocol). Ponieważ protokół ten korzysta ze standardowego portu HTTPS 443 i szyfrowania TLS z certyfikatem cyfrowym, pakiety tunelu są nieodróżnialne od zwykłego, bezpiecznego ruchu przeglądarki WWW i bez przeszkód przechodzą przez wszelkie zapory sieciowe i mechanizmy NAT.

Zespół studentów wciela się w inżynierów sieciowych wdrażających serwer SSTP na centralnym routerze MikroTik RouterOS. Grupa ma za zadanie wygenerować certyfikat serwera VPN podpisany przez lokalny urząd CA, skonfigurować pulę adresów IP dla klientów tunelu ('sstp-pool'), aktywować serwer SSTP z wymuszeniem silnego szyfrowania AES oraz skonfigurować natywnego klienta VPN w systemie Windows 11.

Końcowym etapem jest weryfikacja stabilności połączenia, przetestowanie routingu pakietów do sieci lokalnej centrali oraz analiza bezpieczeństwa sesji w dziennikach systemowych RouterOS.

1. Zalogowanie się do routera MikroTik RouterOS w centrali za pomocą bezpiecznego terminala SSH lub WinBox.
2. Weryfikacja obecności poprawnego certyfikatu serwera z flagą 'tls-server' w '/certificate print' (wygenerowanego w zadaniu 06).
3. Utworzenie dedykowanej puli adresów IP dla łączących się klientów VPN: '/ip pool add name=sstp-pool ranges=10.10.50.10-10.10.50.50'.
4. Utworzenie profilu PPP definiującego parametry tunelu: '/ppp profile add name=sstp-profile local-address=10.10.50.1 remote-address=sstp-pool dns-server=10.10.50.1 use-encryption=yes'.
5. Utworzenie konta użytkownika VPN (Secret) dla pracownika terenowego: '/ppp secret add name=geodeta_adam password=SstpTajneHaslo2026! profile=sstp-profile service=sstp'.
6. Aktywacja serwera SSTP z powiązaniem do certyfikatu cyfrowego: '/interface sstp-server server set enabled=yes port=443 default-profile=sstp-profile certificate=Router-Server-Cert force-aes=yes authentication=mschap2'.
7. Weryfikacja statusu serwera SSTP poleceniem '/interface sstp-server server print'.
8. Sprawdzenie reguł zapory sieciowej i dodanie reguły akceptującej ruch SSTP na porcie 443 interfejsu WAN: '/ip firewall filter add chain=input protocol=tcp dst-port=443 action=accept comment="Zezwol na SSTP VPN" place-before=1'.
9. Upewnienie się, że certyfikat Root CA routera został zaimportowany do zaufanych certyfikatów na stacji Windows klienta.
10. W systemie Windows 11 otwarcie 'Ustawienia -> Sieć i internet -> VPN -> Dodaj połączenie VPN'.
11. Wprowadzenie parametrów połączenia: Dostawca VPN (Windows wbudowany), Nazwa połączenia ('Centrala Geo-Pomiar SSTP'), Nazwa lub adres serwera ('192.168.88.1' lub nazwa FQDN zgodna z CN certyfikatu).
12. Wybór typu sieci VPN: 'Protokół SSTP (Secure Socket Tunneling Protocol)'.
13. Wprowadzenie danych logowania: nazwa użytkownika 'geodeta_adam' oraz skonfigurowane hasło.
14. Zapisanie połączenia i kliknięcie przycisku 'Połącz'.
15. Obserwacja negocjacji sesji TLS, weryfikacji certyfikatu serwera i zestawienia tunelu.
16. Sprawdzenie przydzielonego adresu IP na stacji Windows poleceniem 'ipconfig' (odnotowanie nowego adaptera PPP z adresem z puli 10.10.50.x).
17. W konsoli RouterOS weryfikacja aktywnego połączenia poleceniem '/ppp active print' oraz '/interface sstp-server print'.
18. Przeprowadzenie testu łączności: wykonanie polecenia 'ping 10.10.50.1' ze stacji klienta Windows do routera centrali.
19. Przetestowanie odporności tunelu na podsłuch w programie Wireshark: potwierdzenie, że cały ruch VPN jest enkapsulowany w pakietach TLSv1.2/1.3.
20. Sformułowanie wniosków technicznych dotyczących zalet protokołu SSTP w pokonywaniu restrykcyjnych zapór sieciowych.

Protokół SSTP został opracowany przez firmę Microsoft i jest natywnie obsługiwany przez każdy system Windows od czasów Windows Vista, co eliminuje konieczność instalowania dodatkowego oprogramowania klienckiego (jak w przypadku OpenVPN czy WireGuard). W RouterOS obsługa SSTP jest w pełni zintegrowana ze stosem PPP i modułem certyfikatów X.509.

Kluczowym warunkiem pomyślnego nawiązania połączenia SSTP w systemie Windows jest zgodność nazwy wpisywanej w polu 'Nazwa lub adres serwera' z atrybutem Common Name (CN) lub Subject Alternative Name (SAN) w certyfikacie routera. Ponadto system klienta musi bezwzględnie ufać urzędowi CA, który ten certyfikat wystawił – w przeciwnym razie Windows przerwie połączenie z błędem 0x800B0109.

Poniżej przedstawiono listing aktywnej sesji SSTP w konsoli RouterOS oraz wynik konfiguracji interfejsu sieciowego klienta:

Opcja 'force-aes=yes' w konfiguracji serwera SSTP wymusza stosowanie silnego szyfrowania AES zamiast przestarzałego algorytmu RC4 (MPPE-40). Zawsze należy upewnić się, że opcja ta jest włączona w środowiskach produkcyjnych.

W przypadku, gdy router MikroTik pełni jednocześnie funkcję serwera WWW (WebFig) oraz serwera SSTP na tym samym adresie IP, współdzielenie portu 443 jest obsługiwane przez RouterOS automatycznie – żądania VPN są kierowane do demona SSTP, a ruch HTTP do panelu webowego.

1. Zrozumienie działania tunelu VPN opartego na protokole SSTP i enkapsulacji TLS.
2. Zalety SSTP w pokonywaniu zapór sieciowych (Firewall Traversal) w porównaniu do IPsec i PPTP.
3. Kluczowa rola infrastruktury PKI i poprawnej walidacji łańcucha certyfikatów w zestawianiu połączeń SSTP.
4. Wpływ wymuszenia szyfrowania AES na poufność i integralność przesyłanych danych projektowych.
5. Praktyczna konfiguracja natywnego klienta VPN w systemie Windows bez oprogramowania firm trzecich.
6. Wytyczne dotyczące bezpiecznego routingu i separacji ruchu zdalnych pracowników od sieci produkcyjnej.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie tunelu VPN typu SSTP opartego o certyfikaty X.509 na urządzeniach MikroTik RouterOS potwierdziło wysoką skuteczność tego rozwiązania w łączeniu odległych oddziałów przedsiębiorstwa. Wykorzystanie protokołu SSTP hermetyzowanego w standardowym porcie HTTPS (TCP 443) gwarantuje bezproblemowe przenikanie przez restrykcyjne zapory sieciowe i mechanizmy translacji adresów NAT u operatorów telekomunikacyjnych. Zastosowanie certyfikatów klucza publicznego wyeliminowało konieczność stosowania współdzielonych sekretów (Preshared Keys), zapewniając odporność na ataki podsłuchu i fałszowania tożsamości węzłów sieciowych. Pomiary przepustowości wykazały stabilne transfery danych przy znikomym narzucie procesora routera na operacje kryptograficzne. Utworzenie szyfrowanego połączenia punkt-punkt zabezpieczyło wewnętrzny ruch bazodanowy i plikowy przed jakąkolwiek ingerencją w publicznej sieci Internet.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Kon2 Warunki zapewnienia poufności i autentyczności informacji. Kon3 Algorytmy kryptograficzne i zestawy szyfrów. Efekty uczenia się: W1, W2, U1, U3, K1, K2.

Głównym celem zadania jest wykształcenie u studentów krytycznych umiejętności audytu i identyfikacji przestarzałych, podatnych algorytmów kryptograficznych w systemach teleinformatycznych. Studenci badają mechanizmy znanych ataków kryptograficznych na klasyczne szyfry symetryczne: atak Meet-in-the-Middle na podwójny DES, atak Sweet32 na szyfry z blokiem 64-bitowym (3DES, Blowfish) oraz podatności szyfru strumieniowego RC4.

W toku laboratorium zespół analizuje historyczne i współczesne wytyczne organizacji normalizacyjnych (NIST, ENISA, KSC), przeprowadza testy audytorskie konfiguracji kryptograficznej za pomocą narzędzi wiersza poleceń oraz opracowuje profesjonalną matrycę deprecjacji algorytmów. Studenci formułują zalecenia utwardzania infrastruktury IT zgodnie ze standardami PCI DSS 4.0 i Rekomendacjami KNF. Prace kończą się obroną sprawozdania.

Spółdzielczy Bank Oszczędnościowy „Zaufanie” w Bielsku-Białej przygotowuje się do corocznego zewnętrznego audytu bezpieczeństwa teleinformatycznego wymaganego przez Urząd Komisji Nadzoru Finansowego (UKNF) oraz organizacje płatnicze Visa i Mastercard (standard PCI DSS).

Wstępny skan podatności sieci wewnętrznej i aplikacji bankowości elektronicznej ujawnił niepokojące pozostałości historycznych konfiguracji: w starszych modułach bankomatowych (ATM) nadal dopuszczone jest stosowanie algorytmu Triple-DES (3DES), a w konfiguracji części serwerów aplikacyjnych nie wyłączono obsługi szyfru strumieniowego RC4.

Audytor wiodący wskazał, że stosowanie algorytmów z 64-bitowym blokiem (DES, 3DES) naraża transakcje na atak Sweet32 (CVE-2016-2183), w którym po przesłaniu około $2^{32}$ bloków dochodzi do kolizji w trybie CBC, umożliwiającej odzyskanie ciasteczek sesyjnych użytkowników. Z kolei szyfr RC4 cierpi na poważne wady rozkładu prawdopodobieństwa pierwszych bajtów strumienia klucza (ataki Bar Mitzvah i Fluhrer-Mantin-Shamir).

Zespół studentów wciela się w audytorów bezpieczeństwa powołanych przez zarząd banku do sporządzenia kompleksowego raportu kryptoanalitycznego. Do zadań grupy należy przeprowadzenie symulacji laboratoryjnej obrazującej ograniczenia 64-bitowego bloku danych, zbadanie parametrów zestawów szyfrów w pakiecie OpenSSL oraz opracowanie tabeli wycofania przestarzałych algorytmów z harmonogramem wdrożenia standardów AES-256-GCM oraz ChaCha20-Poly1305.

Podsumowaniem zadania jest sformułowanie formalnego stanowiska dla zarządu banku z uzasadnieniem konieczności wymiany starych modułów kryptograficznych HSM.

1. Zalogowanie się na stację roboczą Linux i przygotowanie środowiska audytorskiego OpenSSL.
2. Weryfikacja listy dostępnych szyfrów w systemie poleceniem 'openssl ciphers -v "ALL:COMPLEMENTOFALL" | grep -E "DES|3DES|RC4"'.
3. Zidentyfikowanie zestawów szyfrów uznawanych współcześnie za niebezpieczne i podatne.
4. Przeanalizowanie specyfikacji ataku Sweet32: obliczenie paradoksu dnia urodzin dla bloku 64-bitowego ($2^{32} \approx 4$ mld bloków = 32 GB danych).
5. Porównanie progu kolizji bloku 64-bitowego z blokiem 128-bitowym w AES ($2^{64} \approx 1.8 \times 10^{19}$ bloków = miliardy terabajtów).
6. Przeprowadzenie testu szyfrowania algorytmem 3DES w OpenSSL: 'openssl enc -des-ede3-cbc -provider legacy -provider default -in /dev/urandom -out test_3des.enc -K 0123456789abcdef0123456789abcdef0123456789abcdef -iv 0123456789abcdef' (dla krótkiej próbki danych).
7. Zbadanie prędkości działania 3DES za pomocą polecenia 'openssl speed des-ede3'.
8. Porównanie prędkości 3DES z nowoczesnym AES-128-GCM: 'openssl speed -evp aes-128-gcm'.
9. Odnotowanie drastycznej dysproporcji wydajnościowej: trzykrotne szyfrowanie DES obciąża procesor bez akceleracji sprzętowej, podczas gdy AES-GCM jest kilkadziesiąt razy szybszy dzięki modułom AES-NI i CLMUL.
10. Przeanalizowanie mechanizmu ataku Meet-in-the-Middle (MitM) na podwójny DES (2DES), wyjaśniającego dlaczego efektywna siła 2DES wynosi zaledwie 57 bitów, a nie 112 bitów.
11. Zbadanie podatności szyfru RC4: demonstracja niejednorodności rozkładu statystycznego początkowych bajtów (Biased Keystream).
12. Przetestowanie polecenia OpenSSL symulującego połączenie z serwerem i weryfikację, czy akceptuje on szyfry 3DES: 'openssl s_client -connect localhost:443 -cipher "3DES"'.
13. Potwierdzenie błędu negocjacji 'handshake failure' na poprawnie utwardzonym serwerze.
14. Opracowanie matrycy oceny algorytmów kryptograficznych: Algorytm, Rozmiar bloku, Długość klucza, Znane ataki, Status zgodności (NIST/PCI DSS).
15. Przypisanie statusu 'WYCOFANY / ZAKAZANY' dla: DES, 2DES, 3DES, RC4, Blowfish, MD5, SHA-1.
16. Przypisanie statusu 'ZALECANY' dla: AES-GCM (128/256 bit), AES-XTS (dla dysków), ChaCha20-Poly1305, SHA-256, SHA-384, SHA-3.
17. Przeanalizowanie wytycznych NIST Special Publication 800-131A Rev. 2 zakazujących stosowania 3DES od 31 grudnia 2023 r.
18. Opracowanie procedury bezpiecznej wymiany kluczy w bankowych terminalach POS zgodnie z wymogami KNF.
19. Przygotowanie zestawienia argumentów technicznych i prawnych dla zarządu banku uzasadniających konieczność audytu sprzętowych modułów bezpieczeństwa (HSM).
20. Sformułowanie końcowych wniosków referatu audytorskiego na obronę laboratoryjną.

Atak Sweet32 (CVE-2016-2183) opiera się na paradoksie dnia urodzin. W każdym szyfrze blokowym działającym w trybie CBC, po zaszyfrowaniu około $2^{n/2}$ bloków (gdzie n to rozmiar bloku w bitach) istnieje 50% prawdopodobieństwo wystąpienia identycznego bloku szyfrogramu. Dla szyfrów o małym bloku 64-bitowym (DES, 3DES, Blowfish) próg ten wynosi zaledwie $2^{32}$ bloków, czyli około 32 GB danych przesyłanych w ramach jednej sesji TLS, co współcześnie jest wielkością łatwą do osiągnięcia.

W przypadku algorytmu AES rozmiar bloku wynosi 128 bitów (niezależnie od tego, czy klucz ma 128, 192 czy 256 bitów). Próg kolizji dla bloku 128-bitowego wynosi $2^{64}$ bloków, co odpowiada eksabajtom danych i w praktyce całkowicie eliminuje podatność na ataki typu Sweet32.

Poniżej przedstawiono przykładowe zestawienie wyników testu wydajnościowego 'openssl speed' obrazujące kolosalną różnicę w przepustowości pomiędzy przestarzałym 3DES a nowoczesnym AES-GCM:

W sprawozdaniu wyjaśnij dlaczego potrójny DES (Triple-DES / TDEA) z trzema różnymi kluczami (3TDES, klucz 168 bitów) zapewnia efektywny poziom bezpieczeństwa zaledwie 112 bitów. Wynika to z ataku typu Meet-in-the-Middle, który redukuje złożoność obliczeniową z $2^{168}$ do $2^{112}$.

Instytucje finansowe podlegają rygorystycznym regulacjom PCI DSS 4.0. Zgodnie z tym standardem użycie szyfrów DES/3DES jest kategorycznie zabronione w strefie przetwarzania danych kartowych (CDE – Cardholder Data Environment) i skutkuje natychmiastowym odebraniem certyfikatu zgodności.

1. Zrozumienie mechanizmu ataku Sweet32 i matematycznych ograniczeń algorytmów z 64-bitowym blokiem danych.
2. Wykazanie teoretycznej wady podwójnego DES w oparciu o atak Meet-in-the-Middle (MitM).
3. Analiza kompromitacji szyfru strumieniowego RC4 pod kątem ataków statystycznych na strumień klucza.
4. Przewaga nowoczesnych algorytmów AEAD (AES-GCM, ChaCha20-Poly1305) w zakresie jednoczesnego zapewnienia poufności i integralności.
5. Znaczenie regulacji sektorowych (PCI DSS 4.0, Rekomendacje KNF) w eliminacji przestarzałych mechanizmów kryptograficznych.
6. Rekomendacje dotyczące audytu i wycofania podatnych algorytmów ze sprzętowych modułów bezpieczeństwa (HSM) banku.

Przykładowe wnioski (wzór do sprawozdania): Kompleksowa analiza kryptoanalityczna przestarzałych szyfrów symetrycznych wykazała ich strukturalne wady, które całkowicie dyskwalifikują je ze stosowania we współczesnych systemach teleinformatycznych. Algorytm 3DES, mimo wydłużenia klucza, pozostaje bezbronny wobec ataków kolizyjnych na krótki 64-bitowy blok danych (atak Sweet32), co prowadzi do ujawnienia ciasteczek sesyjnych w ruchu HTTPS. Szyfr strumieniowy RC4 wykazuje udokumentowane odchylenia statystyczne w początkowych bajtach pseudolosowego strumienia (biases), umożliwiając zrekonstruowanie tekstu jawnego po podsłuchaniu odpowiedniej liczby sesji. Współczesne standardy kryptograficzne, na czele z AES-GCM oraz ChaCha20-Poly1305, łączą szyfrowanie z integralnością danych (AEAD), wykluczając ataki modyfikacji kryptogramu. Ostatecznym wnioskiem audytorskim jest konieczność ciągłego przeglądu stosowanych bibliotek kryptograficznych zgodnie z aktualnymi zaleceniami agencji bezpieczeństwa NIST i ENISA.