Laboratorium 5

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. Wzajemne uwierzytelnianie mTLS.

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie mechanizmu wzajemnego uwierzytelniania w protokole TLS (Mutual TLS - mTLS) dla bezpiecznej komunikacji międzysystemowej B2B (Business-to-Business) oraz interfejsów otwartej bankowości (Open Banking API zgodnych z dyrektywą PSD2). Studenci badają zasady obustronnej weryfikacji tożsamości kryptograficznej, w której nie tylko serwer przedstawia swój certyfikat X.509 przeglądarce, ale również klient (bramka płatnicza, partner finansowy) musi wylegitymować się certyfikatem cyfrowym podpisanym przez zaufany urząd certyfikacji (Root/Intermediate CA).

W części praktycznej studenci konfigurują serwer WWW Nginx w trybie wymuszonego uwierzytelniania klientów (ssl_verify_client on), budują dedykowaną strukturę certyfikatów klienckich, implementują ekstrakcję pól tożsamości z certyfikatu (Subject DN, Serial Number) do nagłówków przekazywanych do aplikacji backendowej oraz badają zachowanie systemu w przypadku podłączenia nieautoryzowanego klienta (odrzucenie połączenia na etapie uzgadniania TLS bez angażowania aplikacji).

Krajowa Izba Płatnicza PaySwitch S.A. pośredniczy w rozliczaniu płatności natychmiastowych pomiędzy 15 bankami komercyjnymi w Polsce. Komunikacja pomiędzy serwerami banków a węzłem centralnym PaySwitch odbywa się za pośrednictwem interfejsów REST API przesyłających zlecenia transferu środków pieniężnych o wartości milionów złotych.

W dotychczasowym rozwiązaniu autoryzacja partnerów bankowych opierała się wyłącznie na statycznych kluczach API (API Key) przesyłanych w nagłówku HTTP Authorization przez standardowe połączenie HTTPS. Podczas incydentu bezpieczeństwa w jednym z banków doszło do wycieku klucza API z repozytorium kodu. Przestępcy, posługując się wykradzionym kluczem, próbowali wysyłać fałszywe dyspozycje przelewów bezpośrednio do węzła PaySwitch.

Chociaż atak został w porę udaremniony, audyt bezpieczeństwa zlecony przez KNF i Narodowy Bank Polski (NBP) wykazał, że uwierzytelnianie jednokierunkowe oparte na statycznym sekrecie jest całkowicie niewystarczające dla infrastruktury krytycznej rynku finansowego. Nakazano natychmiastowe wdrożenie bezwzględnego wzajemnego uwierzytelniania mTLS z certyfikatami sprzętowymi X.509.

W nowej architekturze serwer PaySwitch nawiązuje połączenie wyłącznie z tymi klientami, którzy w trakcie kryptograficznego powitania TLS przedstawią certyfikat wydany przez prywatne CA izby płatniczej, a numer seryjny certyfikatu znajduje się na aktywnej liście dopuszczonych instytucji.

Grupa laboratoryjna przyjmuje zadanie architektów bezpieczeństwa. Studenci muszą stworzyć lokalne CA, wygenerować certyfikat serwera i certyfikaty klientów bankowych, skonfigurować serwer Nginx do wymuszania weryfikacji certyfikatów klienckich (mTLS), zaimplementować przekazywanie tożsamości klienta do backendu oraz zweryfikować zablokowanie nieautoryzowanych połączeń za pomocą narzędzia cURL.

• Serwer WWW Nginx z modułem SSL i obsługą ssl_verify_client
• Narzędzie OpenSSL 3.x do zarządzania certyfikatami X.509 i kluczami
• Narzędzie cURL do testowania zapytań mTLS z opcjami --cert i --key
• Wireshark do analizy ramek CertificateRequest i CertificateVerify w protokole TLS
• Aplikacja backendowa Node.js / Python Flask odbierająca nagłówki tożsamości mTLS

1. Zbadanie przebiegu uścisków dłoni TLS 1.3 w trybie jednostronnym oraz w trybie wzajemnym mTLS.
2. Analiza ramki CertificateRequest wysyłanej przez serwer w celu zażądania certyfikatu klienta.
3. Utworzenie bezpiecznego, dedykowanego urzędu certyfikacji dla środowiska B2B: payswitch_ca.crt oraz payswitch_ca.key.
4. Wygenerowanie klucza i certyfikatu serwera Nginx podpisanego przez utworzone CA.
5. Wygenerowanie kluczy i certyfikatów klienckich dla dwóch banków: BankA (bankA.crt) oraz BankB (bankB.crt).
6. Skonfigurowanie serwera Nginx do weryfikacji certyfikatów klienckich: ssl_client_certificate /etc/ssl/ca/payswitch_ca.crt; ssl_verify_client on;.
7. Ustawienie głębokości weryfikacji łańcucha certyfikatów: ssl_verify_depth 2;.
8. Skonfigurowanie przekazywania danych tożsamości klienta z certyfikatu do backendu: proxy_set_header X-Client-DN $ssl_client_s_dn; proxy_set_header X-Client-Serial $ssl_client_serial;.
9. Przetestowanie nawiązania połączenia bez certyfikatu klienta za pomocą cURL: zaobserwowanie błędu handshake_failure (kod 400 Bad Request / brak certyfikatu).
10. Przetestowanie połączenia z certyfikatem wygenerowanym przez inne, niezaufane CA: weryfikacja natychmiastowego odrzucenia przez serwer.
11. Pomyślne nawiązanie bezpiecznego połączenia mTLS z użyciem właściwego certyfikatu: curl --cert bankA.crt --key bankA.key https://api.payswitch.local/transakcje.
12. Weryfikacja logów aplikacji backendowej: potwierdzenie odebrania nagłówków z tożsamością klienta CN=Bank A - Node 01.
13. Zbadanie wpływu mTLS na obciążenie procesora serwera i czas nawiązywania połączeń.
14. Zaprojektowanie procedury natychmiastowego unieważniania certyfikatu kompromitowanego banku (lista CRL / OCSP).
15. Analiza zgodności wdrożenia ze standardem PolishAPI (standard otwartej bankowości w Polsce) oraz wymogami dyrektywy PSD2.
16. Opracowanie instrukcji wdrożeniowej dla działów IT banków partnerskich.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z kompletnymi plikami konfiguracyjnymi Nginx i zrzutami z cURL.

W architekturze mTLS ogromną zaletą bezpieczeństwa jest to, że nieautoryzowany klient jest odrzucany już na etapie negocjacji warstwy kryptograficznej TLS (Transport Layer). Oznacza to, że żadne nieautoryzowane pakiety HTTP w ogóle nie docierają do serwera aplikacji ani bazy danych, co całkowicie uodparnia backend na ataki typu SQL Injection, XSS, czy przeciążenie zapytań (DDoS na warstwę aplikacji).

Poniżej przedstawiono przykładową konfigurację serwera Nginx wymuszającą mTLS dla endpointów transakcyjnych:

Próba nawiązania połączenia bez certyfikatu klienta kończy się błędem warstwy TLS:

Pomyślna autoryzacja banku partnerskiego za pomocą certyfikatu klienckiego X.509 i klucza prywatnego:

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

1. Zasada działania dwustronnego uzgadniania TLS (Mutual TLS): żądanie CertificateRequest i weryfikacja łańcucha zaufania klienta przez serwer.
2. Eliminacja podatności uwierzytelniania opartego wyłącznie na hasłach i statycznych tokenach API w komunikacji B2B.
3. Rola ograniczeń rozszerzeń X.509 (Extended Key Usage – Client Authentication vs Server Authentication).
4. Weryfikacja tożsamości klienta w warstwie aplikacji: ekstrakcja pól Subject DN oraz SAN (Subject Alternative Name) do precyzyjnej kontroli dostępu.
5. Konfiguracja serwera pośredniczącego: wymuszanie certyfikatów klienckich oraz dynamiczna obsługa unieważnień certyfikatów.
6. Spełnienie wymogów dyrektywy PSD2 oraz standardu PolishAPI dla bezpiecznych interfejsów dedykowanych w otwartej bankowości.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie wzajemnego uwierzytelniania mTLS w komunikacji pomiędzy bankiem a zewnętrznym dostawcą usług zapewniło kryptograficzną pewność tożsamości obu stron połączenia. Wymuszenie certyfikatów klienckich X.509 z dedykowanym rozszerzeniem Client Authentication wyeliminowało podatność interfejsu REST API na ataki podszywania się pod klienta oraz kradzież statycznych kluczy API. Serwer proxy po zweryfikowaniu nienaruszalności łańcucha zaufania przekazuje zweryfikowane atrybuty tożsamości podmiotu bezpośrednio do logiki biznesowej aplikacji bankowej. Weryfikacja statusu certyfikatów w czasie rzeczywistym zabezpieczyła interfejs przed próbami użycia poświadczeń wycofanych przez instytucję certyfikującą. Zaimplementowane rozwiązanie w pełni odpowiada specyfikacji technicznej PolishAPI oraz wymogom regulacyjnym nakładanym przez Europejski Urząd Nadzoru Bankowego w ramach dyrektywy PSD2.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Kryptografia asymetryczna. Infrastruktura klucza publicznego (PKI) i certyfikaty X.509.

Celem zadania jest zaprojektowanie, zbudowanie i skonfigurowanie w pełni funkcjonalnej, hierarchicznej infrastruktury klucza publicznego (Public Key Infrastructure - PKI) w środowisku korporacyjnym przy użyciu zaawansowanych możliwości narzędzia OpenSSL 3.x. Studenci poznają architekturę dwustopniowego urzędu certyfikacji składającego się z nadrzędnego urzędu certyfikacji (Root CA) trzymanego w trybie offline (odłączonego od sieci) oraz podrzędnego urzędu certyfikacji (Issuing / Intermediate CA) wystawiającego certyfikaty końcowe dla serwerów i użytkowników.

W ramach laboratorium studenci konfigurują pliki sterujące openssl.cnf, definiują restrykcyjne rozszerzenia X.509 v3 (Basic Constraints, Key Usage, Extended Key Usage, Subject Alternative Name - SAN), obsługują podpisywanie żądań CSR (Certificate Signing Request) oraz badają zasady zapobiegania atakom podszywania się pod urząd certyfikacji (CA impersonation) wynikającym z błędnego ustawienia flagi isCA.

Grupa Kapitałowa PolskieKoleje Cyfrowe S.A. zarządza infrastrukturą teleinformatyczną na dworcach, w pociągach oraz w centrach sterowania ruchem kolejowym. W spółce funkcjonuje ponad 3000 urządzeń sieciowych, serwerów bazodanowych oraz paneli operatorskich, które wymagają bezpiecznej komunikacji szyfrowanej TLS.

Dotychczas administratorzy na każdym serwerze generowali certyfikaty samopodpisane (Self-Signed Certificates). Skutkowało to powszechnym ignorowaniem ostrzeżeń o błędach certyfikatów przez pracowników ('kliknij Zaakceptuj ryzyko i kontynuuj'), co stwarzało idealne warunki do przeprowadzania ataków Man-in-the-Middle przez podstawienie fałszywego certyfikatu w sieci kolejowej.

Próba zakupu publicznych certyfikatów komercyjnych dla tysięcy wewnętrznych adresów IP i domen (.kolej.local) okazała się niemożliwa ze względów formalnych (publiczne urzędy CA nie mogą wystawiać certyfikatów dla domen nierzestawnych i prywatnych adresów IP RFC 1918) oraz nieuzasadniona ekonomicznie.

Zarząd PK Cyfrowe podjął decyzję o budowie własnego, korporacyjnego Urzędu Certyfikacji (Enterprise PKI). Główny klucz Root CA ma zostać wygenerowany na odizolowanej stacji bez dostępu do Internetu, zabezpieczony hasłem frazowym i zdeponowany w sejfie, natomiast bieżące operacje podpisywania ma realizować pośredni urząd certyfikacji Intermediate CA.

Zadaniem grupy laboratoryjnej jest stworzenie kompletnej struktury katalogów i plików konfiguracyjnych OpenSSL dla Root CA i Intermediate CA, wygenerowanie 4096-bitowego samopodpisanego certyfikatu Root CA (ważnego 10 lat), wygenerowanie certyfikatu Intermediate CA (ważnego 5 lat) podpisanego przez Root CA, a następnie wystawienie certyfikatów końcowych dla serwerów z obowiązkowym rozszerzeniem Subject Alternative Name (SAN).

• OpenSSL 3.x w środowisku Linux Debian / Ubuntu
• Narzędzie x509 / req / ca z pakietu OpenSSL CLI
• Narzędzie openssl verify do weryfikacji łańcucha zaufania certyfikatów
• Narzędzie certtool / dumpasn1 do analizy rozszerzeń X.509 v3
• Przeglądarka internetowa (Firefox / Chrome) do importu certyfikatu Root CA do magazynu zaufania

1. Zaprojektowanie hierarchii zaufania PKI: Root CA (offline) -> Intermediate CA (online) -> Certyfikaty końcowe (serwery WWW, bazy danych).
2. Utworzenie dedykowanej struktury katalogów dla Root CA: /root/ca (certs, crl, newcerts, private) oraz plików stanu: serial, index.txt.
3. Zredagowanie pliku konfiguracyjnego openssl.cnf dla Root CA z sekcją [ v3_ca ] (basicConstraints = critical, CA:true, keyUsage = critical, keyCertSign, cRLSign).
4. Wygenerowanie 4096-bitowego klucza prywatnego Root CA zabezpieczonego hasłem frazowym: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:4096 -aes256 -out private/ca.key.pem.
5. Utworzenie samopodpisanego certyfikatu głównego Root CA: openssl req -config openssl.cnf -key private/ca.key.pem -new -x509 -days 3650 -sha256 -extensions v3_ca -out certs/ca.cert.pem.
6. Utworzenie oddzielnej struktury katalogów dla pośredniego urzędu certyfikacji: /root/ca/intermediate.
7. Zredagowanie pliku openssl.cnf dla Intermediate CA z ograniczeniem ścieżki: basicConstraints = critical, CA:true, pathlen:0.
8. Wygenerowanie klucza prywatnego Intermediate CA (4096 bitów) oraz żądania podpisania certyfikatu (CSR): openssl req -config intermediate/openssl.cnf -new -sha256 -key intermediate/private/intermediate.key.pem -out intermediate/csr/intermediate.csr.pem.
9. Podpisanie certyfikatu Intermediate CA kluczem głównym Root CA: openssl ca -config openssl.cnf -extensions v3_intermediate_ca -days 1825 -notext -md sha256 -in intermediate/csr/intermediate.csr.pem -out intermediate/certs/intermediate.cert.pem.
10. Utworzenie łańcucha zaufania (CA Chain): połączenie certyfikatu pośredniego i głównego w jeden plik ca-chain.cert.pem.
11. Wygenerowanie klucza prywatnego dla serwera WWW stacja.kolej.local oraz żądania CSR.
12. Wprowadzenie obowiązkowych rozszerzeń SAN w pliku v3_req: subjectAltName = @alt_names z wpisami DNS.1, DNS.2 oraz IP.1.
13. Podpisanie certyfikatu serwera przez Intermediate CA: openssl ca -config intermediate/openssl.cnf -extensions server_cert -days 375 -notext -md sha256 -in csr/serwer.csr.pem -out certs/serwer.cert.pem.
14. Weryfikacja poprawności łańcucha certyfikatu za pomocą polecenia openssl verify -CAfile ca-chain.cert.pem certs/serwer.cert.pem.
15. Zaimportowanie certyfikatu Root CA do magazynu zaufanych urzędów certyfikacji w przeglądarce i weryfikacja braku ostrzeżeń bezpieczeństwa.
16. Opracowanie procedury bezpiecznego przechowywania klucza Root CA (wyłączenie maszyny wirtualnej, eksport na zaszyfrowany nośnik USB).
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z pełnymi plikami openssl.cnf i zrzutami certyfikatów.

Zwróćcie szczególną uwagę na rozszerzenie `basicConstraints`. Dla Root CA oraz Intermediate CA flaga ta musi bezwzględnie przyjmować wartość `CA:TRUE`. Dodatkowo dla Intermediate CA kluczowe jest zdefiniowanie parametru `pathlen:0`. Oznacza to, że Intermediate CA może wystawiać wyłącznie certyfikaty dla końcowych urządzeń i użytkowników, ale nie może utworzyć kolejnego, podrzędnego urzędu certyfikacji. Chroni to całą korporacyjną strukturę PKI przed niekontrolowanym rozrostem i potencjalną kompromitacją.

Poniżej przedstawiono procedurę podpisywania certyfikatu serwera z rozszerzeniem SAN przez Intermediate CA w OpenSSL:

Weryfikacja łańcucha certyfikatu oraz obecności rozszerzeń Subject Alternative Name (SAN):

Inspekcja bazy danych wystawionych certyfikatów urzędu w pliku index.txt:

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

1. Architektura hierarchicznej infrastruktury PKI: całkowita izolacja Root CA w środowisku offline oraz operacyjne urzędy pośrednie Intermediate CA.
2. Poprawne definiowanie ograniczeń podstawowych (Basic Constraints critical, CA:TRUE, pathlen:0) uniemożliwiające nieuprawnione tworzenie podrzędnych CA.
3. Precyzyjne definiowanie przeznaczenia kluczy (Key Usage: digitalSignature, keyCertSign, cRLSign) oraz rozszerzonych zastosowań certyfikatów.
4. Rygorystyczna obsługa żądań CSR oraz wymóg stosowania rozszerzenia Subject Alternative Name (SAN) dla certyfikatów serwerowych.
5. Opracowanie i egzekwowanie dokumentów polityki certyfikacyjnej (CP) oraz kodeksu postępowania certyfikacyjnego (CPS).
6. Procedury bezpiecznego niszczenia i ceremonii generowania kluczy (Key Ceremony) zgodnie z normą ISO/IEC 27001 i standardem WebTrust.

Przykładowe wnioski (wzór do sprawozdania): Budowa hierarchicznej infrastruktury PKI z fizycznie odizolowanym głównym urzędem certyfikacji wyeliminowała ryzyko całkowitej utraty zaufania w organizacji w razie incydentu na serwerze operacyjnym. Zastosowanie parametru pathlen równego zero w certyfikacie wystawcy pośredniego skutecznie uniemożliwiło tworzenie nieautoryzowanych, głębszych gałęzi łańcucha zaufania. Zautomatyzowanie przetwarzania żądań CSR z obligatoryjnym rozszerzeniem Subject Alternative Name rozwiązało problem błędów walidacji w nowoczesnych przeglądarkach internetowych ignorujących pole Common Name. Zdefiniowanie restrykcyjnych flag Key Usage zagwarantowało, że certyfikaty końcowe nie mogą posłużyć do podpisywania innych certyfikatów lub list unieważnień. Opracowany model stanowi fundament zaufania w korporacyjnej sieci wewnętrznej, w pełni spełniający wymogi rygorystycznych audytów bezpieczeństwa.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Kryptografia asymetryczna. Odwoływanie certyfikatów, listy CRL i protokół OCSP.

Celem zadania jest zbadanie, zaimplementowanie i przetestowanie dwóch kluczowych mechanizmów sprawdzania statusu unieważnienia certyfikatów X.509 w infrastrukturze PKI: list unieważnionych certyfikatów (Certificate Revocation List - CRL) oraz protokołu weryfikacji statusu w czasie rzeczywistym (Online Certificate Status Protocol - OCSP, RFC 6960). Studenci analizują wady i zalety obu rozwiązań: problem rosnącego rozmiaru i opóźnień aktualizacji list CRL w zestawieniu z problemami wydajnościowymi i wyciekiem prywatności zapytań w klasycznym OCSP.

W części praktycznej studenci symulują kompromitację klucza prywatnego serwera, unieważniają certyfikat w bazie urzędu CA, generują podpisaną listę CRL, uruchamiają lokalny responder OCSP za pomocą modułu openssl ocsp, a następnie konfigurują mechanizm automatycznego zszywania odpowiedzi (OCSP Stapling) w serwerze WWW Nginx/Apache. Projekt uczy eliminacji ataków z wykorzystaniem odwołanych poświadczeń.

Operator Krajowego Węzła Telemedycyny MedNet S.A. łączy ponad 500 szpitali i przychodni przesyłających dane o hospitalizacjach i zabiegach operacyjnych. Każdy serwer szpitalny autoryzuje się certyfikatem X.509. W ubiegłym miesiącu na jednym ze szpitalnych serwerów doszło do incydentu: administrator omyłkowo opublikował klucz prywatny serwera na publicznym kanale Discord podczas poszukiwania pomocy technicznej.

Mimo że administrator po 30 minutach usunął wpis, klucz został zindeksowany przez boty. Zespół bezpieczeństwa MedNet natychmiast zgłosił konieczność unieważnienia skompromitowanego certyfikatu. Okazało się jednak, że w korporacyjnym urzędzie CA listy CRL nie były publikowane od 90 dni, a serwer respondera OCSP w ogóle nie został uruchomiony.

W efekcie, mimo formalnego zgłoszenia kompromitacji, wszystkie pozostałe szpitale i bramki dostępowe weryfikujące certyfikat nadal traktowały go jako w 100% poprawny i zaufany. Napastnicy, posługując się przejętym kluczem, mogli przez kolejne tygodnie podszywać się pod serwer szpitalny i pobierać dane medyczne pacjentów.

Kierownictwo MedNet powierzyło grupie laboratoryjnej zadanie wdrożenia kompletnego i niezawodnego systemu unieważniania certyfikatów. Nowy system musi umożliwiać natychmiastowe odwołanie certyfikatu z podaniem formalnego powodu (reasonCode wg RFC 5280, np. keyCompromise), automatyczną publikację zaktualizowanych list CRL co 24 godziny oraz uruchomienie szybkiego respondera OCSP zintegrowanego z mechanizmem OCSP Stapling na serwerach brzegowych.

Studenci muszą przeprowadzić całą procedurę: odwołanie certyfikatu w CA, wygenerowanie listy CRL, przetestowanie zapytania OCSP za pomocą OpenSSL, skonfigurowanie Nginx do zszywania odpowiedzi oraz weryfikacja zablokowania dostępu dla unieważnionego klienta.

• OpenSSL 3.x z modułami ca, crl oraz ocsp
• Serwer WWW Nginx / Apache z obsługą ssl_stapling
• Narzędzie cURL do testowania odpowiedzi OCSP
• Przeglądarka internetowa z inspekcją stanu certyfikatów
• Skrypt Bash automatyzujący publikację list CRL na serwerze dystrybucyjnym

1. Zbadanie struktury listy unieważnionych certyfikatów CRL: numer seryjny unieważnionego certyfikatu, data odwołania, kod powodu (reasonCode).
2. Analiza powodów unieważnienia według RFC 5280: keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation.
3. Zbadanie protokołu OCSP (RFC 6960): binarny format żądania OCSPRequest i odpowiedzi OCSPResponse (statusy: good, revoked, unknown).
4. Przeprowadzenie symulacji kompromitacji: unieważnienie certyfikatu serwera portal.kolej.local za pomocą polecenia openssl ca -revoke.
5. Określenie powodu odwołania: flaga -crl_reason keyCompromise.
6. Wygenerowanie zaktualizowanej listy CRL podpisanej kluczem urzędu certyfikacji: openssl ca -gencrl -out crl/intermediate.crl.pem.
7. Inspekcja wygenerowanej listy CRL w czytelnym formacie tekstowym: openssl crl -in crl/intermediate.crl.pem -text -noout.
8. Uruchomienie lokalnego mikroserwera respondera OCSP za pomocą OpenSSL: openssl ocsp -index index.txt -port 8888 -rsigner certs/ocsp.cert.pem -rkey private/ocsp.key.pem -CA certs/ca-chain.cert.pem.
9. Wysłanie bezpośredniego zapytania OCSP z poziomu stacji audytora w celu weryfikacji statusu unieważnionego certyfikatu.
10. Zaobserwowanie odpowiedzi respondera OCSP: Cert Status: revoked z dokładnym czasem unieważnienia.
11. Zbadanie zalet mechanizmu OCSP Stapling (zszywanie OCSP): serwer sam pobiera odpowiedź OCSP i dołącza ją do uścisku TLS, eliminując opóźnienia klienta.
12. Konfiguracja OCSP Stapling w serwerze Nginx: ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate ca-chain.cert.pem;.
13. Weryfikacja obecności zszytej odpowiedzi OCSP za pomocą polecenia openssl s_client -connect target:443 -status.
14. Zbadanie rozszerzenia TLS Certificate Status Request (RFC 6066).
15. Przetestowanie zachowania przeglądarki w trybie Hard-Fail (odmowa połączenia, jeśli status OCSP wskazuje revoked).
16. Opracowanie procedury cyklicznego odnawiania bufora OCSP przed upływem pola nextUpdate.
17. Skompilowanie raportu laboratoryjnego z analizą wpisów CRL i zrzutami odpowiedzi OCSP.

Tradycyjna weryfikacja OCSP (Direct OCSP Query) stwarzała poważny problem prywatności: przy każdym wejściu użytkownika na stronę internetową jego przeglądarka wysyłała zapytanie do serwera urzędu certyfikacji (CA), ujawniając adres IP użytkownika oraz nazwę odwiedzanej domeny. Ponadto awaria serwera OCSP prowadziła do spowolnienia otwierania stron. Mechanizm OCSP Stapling całkowicie rozwiązuje oba te problemy: to serwer WWW okresowo odpytuje CA, pobiera kryptograficznie podpisaną odpowiedź i 'zszywa' ją z powitaniem TLS kierowanym do klienta.

Poniżej przedstawiono procedurę unieważnienia certyfikatu w bazie OpenSSL oraz weryfikację respondera OCSP:

Wysłanie zapytania OCSP z weryfikacją odpowiedzi za pomocą narzędzia OpenSSL ocsp:

Inspekcja wpisu unieważnienia wewnątrz listy CRL poleceniem openssl crl:

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

1. Porównanie mechanizmów odwoływania certyfikatów: statyczne listy unieważnień (CRL) w zestawieniu z protokołem sprawdzania statusu online (OCSP).
2. Wady skalowalności i ryzyko wycieku prywatności użytkowników w tradycyjnym modelu bezpośrednich zapytań klienta do serwera OCSP respondera.
3. Rola technologii OCSP Stapling (RFC 6066) w eliminacji zapytań wychodzących od klienta i znacznym skróceniu czasu trwania procedury TLS handshake.
4. Mechanizm OCSP Must-Staple jako skuteczne zabezpieczenie przed atakami obniżenia poziomu bezpieczeństwa w domyślnym trybie Soft-Fail.
5. Analiza różnic pomiędzy trybem weryfikacji Soft-Fail (priorytet dostępności) a Hard-Fail (bezwzględny priorytet bezpieczeństwa transakcyjnego).
6. Zarządzanie okresem ważności odpowiedzi OCSP (thisUpdate, nextUpdate) oraz optymalizacja buforowania w środowiskach wysokiej dostępności.

Przykładowe wnioski (wzór do sprawozdania): Badania empiryczne mechanizmów unieważniania certyfikatów wykazały, że tradycyjne listy CRL generują nieakceptowalne opóźnienia sieciowe oraz drastyczny wzrost zużycia pasma przy rosnącej skali infrastruktury. Zastosowanie protokołu OCSP skróciło czas weryfikacji, jednak naraziło historię odwiedzin użytkowników na ujawnienie w zapytaniach kierowanych do zewnętrznych serwerów urzędu certyfikacji. Optymalnym rozwiązaniem okazało się wdrożenie technologii OCSP Stapling, w której to serwer WWW okresowo pobiera podpisany kryptograficznie status certyfikatu i dołącza go do początkowego pakietu handshake. Wykorzystanie rozszerzenia TLS Must-Staple skutecznie zabezpieczyło klientów przed atakami blokowania odpowiedzi OCSP, które w domyślnym trybie Soft-Fail były ignorowane przez przeglądarki. Zaimplementowana konfiguracja łączy natychmiastową reakcję na wycofanie poświadczeń z najwyższą wydajnością i pełną ochroną prywatności użytkowników.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i integralności informacji. Standardy bezpieczeństwa branży płatniczej PCI DSS.

Celem zadania jest przeprowadzenie audytu technicznego i zaprojektowanie architektury kryptograficznej zgodnej z najnowszą wersją globalnego standardu bezpieczeństwa kart płatniczych PCI DSS v4.0 (Payment Card Industry Data Security Standard). Studenci analizują szczegółowe wymagania Wymogu 3 (Ochrona przechowywanych danych posiadaczy kart - Account Data) oraz Wymogu 4 (Ochrona danych posiadaczy kart za pomocą silnej kryptografii podczas transmisji przez otwarte, publiczne sieci).

W części inżynierskiej zadanie obejmuje opracowanie bezpiecznego potoku przetwarzania podstawowego numeru rachunku karty (Primary Account Number - PAN): implementację bezwzględnego zakazu przechowywania wrażliwych danych uwierzytelniających (SAD: kodów CVV2/CVC2, zawartości paska magnetycznego, kodów PIN), wdrożenie silnego szyfrowania AES-256-GCM dla przechowywanych numerów PAN, maskowania numerów kart (wyświetlanie wyłącznie pierwszych 6 i ostatnich 4 cyfr) oraz implementację architektury tokenizacji zastępującej numer karty losowym tokenem.

Spółka TravelPoland S.A. prowadzi ogólnopolski portal rezerwacji hoteli i biletów lotniczych. Klienci dokonują płatności kartami Visa i Mastercard bezpośrednio na stronie internetowej. W celu umożliwienia 'szybkich płatności jednym kliknięciem' przy kolejnych rezerwacjach, baza danych aplikacji zapisywała pełne 16-cyfrowe numery kart płatniczych (PAN), daty ważności oraz 3-cyfrowe kody CVV2 w zwykłej tabeli bazy MySQL w postaci nieszyfrowanego tekstu jawnego (Plaintext).

Podczas corocznego audytu Qualified Security Assessor (QSA) stwierdził drastyczne naruszenie standardu PCI DSS v4.0: Wymóg 3.2 bezwzględnie zabrania przechowywania danych SAD (Sensitive Authentication Data, w tym kodów CVV2) po zakończeniu autoryzacji transakcji, nawet w postaci zaszyfrowanej! Co więcej, brak szyfrowania numerów PAN w spoczynku i brak maskowania na ekranie konsultantów call-center stanowił bezpośrednie zagrożenie gigantycznymi karami finansowymi ze strony organizacji płatniczych oraz cofnięciem prawa do akceptacji kart.

Zarząd TravelPoland stanął przed widmem natychmiastowego zablokowania bramek płatniczych. Nakazano pilne wdrożenie zewnętrznego modułu tokenizacji oraz całkowite usunięcie numerów kart z baz danych systemów rezerwacyjnych.

Grupa laboratoryjna przyjmuje rolę audytorów i inżynierów PCI DSS. Zadaniem zespołu jest zaprojektowanie architektury Tokenizacji Kart Płatniczych (Card Tokenization Vault): numer PAN trafia wyłącznie do wyizolowanego, certyfikowanego sejfu danych (CDE - Cardholder Data Environment), gdzie jest szyfrowany algorytmem AES-256 z kluczem zarządzanym w sprzętowym module, a do pozostałych systemów rezerwacyjnych zwracany jest bezpieczny token alfanumeryczny pozbawiony wartości dla potencjalnego złodzieja.

Sprawozdanie musi zawierać algorytm maskowania numerów kart (Luhn Check + maskowanie), skrypt tokenizacji w języku Python, analizę prawno-techniczną wymogów PCI DSS v4.0 oraz procedurę natychmiastowego niszczenia kodów CVV2 z pamięci RAM.

• Python 3 z bibliotekami cryptography (AESGCM) i hashlib
• Baza danych PostgreSQL w wyizolowanym kontenerze Docker (symulacja Cardholder Data Environment - CDE)
• Narzędzie OpenSSL 3.x do generowania kluczy szyfrujących KEK (Key Encryption Key) i DEK (Data Encryption Key)
• Narzędzie do walidacji algorytmu Luhna (mod 10 algorithm)
• Darmowe narzędzia inspekcji baz danych pod kątem obecności niezaszyfrowanych numerów kart (pan-hunter / regex-audit)

1. Zbadanie struktury numeru karty płatniczej (PAN): BIN/IIN (pierwsze 6-8 cyfr), numer rachunku, cyfra kontrolna wyliczana algorytmem Luhna.
2. Zaimplementowanie algorytmu Luhna (Modulo 10) w języku Python do weryfikacji poprawności numerów testowych kart.
3. Analiza wymagań PCI DSS v4.0 Wymóg 3: co wolno przechowywać (PAN pod warunkiem szyfrowania/tokenizacji), a czego bezwzględnie nie wolno (SAD: CVV2, PIN, dane ścieżki magnetycznej).
4. Zaprojektowanie funkcji maskowania numeru karty (Truncation / Masking): wyświetlanie wyłącznie pierwszych 6 cyfr (identyfikacja banku) oraz ostatnich 4 cyfr (np. 4000 12** **** 1234).
5. Zaprojektowanie dwustopniowej hierarchii kluczy kryptograficznych: Data Encryption Key (DEK) szyfrujący dane oraz Key Encryption Key (KEK) szyfrujący klucz DEK.
6. Zaimplementowanie potoku szyfrowania numerów PAN algorytmem AES-256-GCM w wyizolowanej strefie bezpiecznego sejfu (Vault).
7. Opracowanie mechanizmu tokenizacji: generowanie unikalnego, losowego tokena format-preserving (np. tok_9f8a12b3c4d5) powiązanego z rekordem w sejfie.
8. Wdrożenie zasady natychmiastowego usuwania kodów CVV2 z pamięci aplikacji po uzyskaniu kodu autoryzacji z banku (Zeroization).
9. Zbadanie zakresu strefy CDE (Cardholder Data Environment): jak wdrożenie tokenizacji redukuje zakres audytu PCI DSS dla reszty infrastruktury spółki.
10. Zaprojektowanie rotacji kluczy szyfrujących DEK co 365 dni zgodnie z Wymogiem 3.6 PCI DSS.
11. Przygotowanie skryptu audytorskiego przeszukującego logi serwera WWW i bazy danych pod kątem przypadkowego zapisania numeru PAN w postaci otwartej.
12. Zbadanie wymogów Wymogu 4 PCI DSS: zakaz stosowania starych wersji protokołów TLS (bezwzględny wymóg min. TLS 1.2 z bezpiecznymi szyframi).
13. Opracowanie procedury postępowania w przypadku podejrzenia wycieku danych kartowych (Incident Response zgodny z PCI DSS).
14. Zaprojektowanie bezpiecznego interfejsu API sejfu tokenizacyjnego z wymuszeniem mTLS.
15. Przeprowadzenie testu penetracyjnego sejfu tokenów pod kątem możliwości odgadnięcia sekwencji tokenów.
16. Sformułowanie formalnego oświadczenia o zgodności z PCI DSS (Attestation of Compliance - AoC) dla zarządu.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z kodem modułu tokenizacji i diagramem strefy CDE.

W standardzie PCI DSS kluczowym pojęciem jest redukcja zakresu audytu (Scope Reduction). Jeśli firma przechowuje numery kart w głównym systemie rezerwacyjnym, cała sieć, wszystkie komputery, serwery, a nawet stacje robocze pracowników podlegają rygorystycznemu, niezwykle kosztownemu audytowi PCI DSS. Wdrożenie architektury tokenizacji pozwala zamknąć dane kartowe w miniaturowej, odizolowanej strefie sejfu (CDE Vault), co wyłącza 95% infrastruktury firmy z rygorów audytu, drastycznie zwiększając bezpieczeństwo i obniżając koszty.

Poniżej przedstawiono implementację modułu tokenizacji i maskowania numeru karty w języku Python:

Weryfikacja braku obecności kodów CVV2 w bazach danych aplikacji za pomocą skryptu przeszukującego tabele:

Test poprawności numeru karty za pomocą algorytmu Luhna w wierszu poleceń:

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

1. Wymagania sekcji 3 standardu PCI DSS v4.0 w zakresie bezwzględnej ochrony podstawowego numeru konta (PAN) w spoczynku i w transmisji sieciowej.
2. Dopuszczalne metody uniemożliwiania odczytania numerów PAN: silne szyfrowanie (AES-256), tokenizacja, haszowanie z solą oraz obcięcie (Truncation).
3. Bezwzględny zakaz przechowywania wrażliwych danych uwierzytelniających (SAD: kody CVV2/CVC2, dane paska magnetycznego, bloki PIN) po autoryzacji.
4. Architektura tokenizacji kart płatniczych: zastąpienie numeru PAN unikalnym tokenem w systemach sklepowych i izolacja skarbca kart (Card Data Vault).
5. Koncepcja podwójnej kontroli i podziału wiedzy (Split Knowledge / Dual Control) przy zarządzaniu kluczami szyfrującymi KEK i DEK.
6. Rola segmentacji sieciowej (Scoping) w redukcji obszaru podlegającego rygorystycznemu audytowi PCI DSS.

Przykładowe wnioski (wzór do sprawozdania): Audyt architektury przetwarzania płatności wykazał, że zastąpienie jawnych numerów PAN jednorazowymi tokenami w bazie zamówień sklepu drastycznie zredukowało zakres środowiska objętego rygorem audytu PCI DSS v4.0. Wrażliwe numery kart zostały odizolowane w certyfikowanym skarbcu danych, gdzie podlegają szyfrowaniu algorytmem AES-256-GCM z kluczami przechowywanymi w sprzętowym module HSM. Zgodnie z wymogiem 3.3 standardu wprowadzono mechanizm maskowania numerów kart w logach aplikacyjnych, pozostawiając czytelnymi jedynie pierwsze sześć oraz ostatnie cztery cyfry na potrzeby weryfikacji operacyjnej. Wdrożenie procedury Dual Control wyeliminowało możliwość nieautoryzowanego dostępu pojedynczego administratora do nadrzędnych kluczy szyfrujących. Zaprojektowane procedury całkowicie wykluczyły przechowywanie kodów CVV2 po zakończeniu procesu autoryzacji, zapewniając pełną zgodność z najnowszymi wytycznymi PCI Security Standards Council.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Uwierzytelnianie wieloskładnikowe w finansach.

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie przepływu transakcji elektronicznych z wykorzystaniem nowoczesnego protokołu 3-D Secure w wersji 2.2+ (EMV 3DS) oraz mechanizmów Silnego Uwierzytelniania Klienta (Strong Customer Authentication - SCA) wymaganego przez unijną dyrektywę PSD2 (Payment Services Directive 2). Studenci badają zasady podziału odpowiedzialności pomiędzy trzema domenami: domeną akceptanta (Acquirer Domain / 3DS Server), domeną interoperacyjności (Interoperability Domain / Directory Server - DS) oraz domeną wydawcy karty (Issuer Domain / Access Control Server - ACS).

W ramach laboratorium studenci analizują dwa podstawowe scenariusze transakcyjne: przepływ bezproblemowy oparty na analizie ryzyka (Frictionless Flow), w którym transakcja niskiego ryzyka jest zatwierdzana w ułamku sekundy bez angażowania użytkownika, oraz przepływ z wyzwaniem (Challenge Flow), wymuszający na kliencie potwierdzenie płatności w aplikacji mobilnej banku za pomocą dwóch niezależnych składników (wiedza, posiadanie, biometria). Zadanie uczy również obsługi wyłączeń spod SCA (Exemptions).

Krajowy Sklep Internetowy AGD-RTV 'MegaMarket24' odnotował w okresie przedświątecznym gwałtowny wzrost liczby oszustw transakcyjnych (Card-Not-Present Fraud) przeprowadzanych za pomocą skradzionych danych kart płatniczych. Sklep korzystał ze starego protokołu 3DS 1.0, który wyświetlał toporne okno ramki iframe z koniecznością podania hasła SMS, co powodowało porzucanie koszyków zakupowych przez ponad 35% klientów mobilnych.

Właściciele sklepu, chcąc zmniejszyć wskaźnik porzuceń, wyłączyli wymóg weryfikacji 3DS dla części transakcji. W rezultacie banki wydawcy kart zaczęły masowo odrzucać autoryzacje (błąd Soft Decline kod 65 - SCA Required), a dla zrealizowanych oszukańczych transakcji zastosowano mechanizm obciążenia zwrotnego (Chargeback Liability Shift) na niekorzyść sklepu, co przyniosło straty rzędu 450 000 zł.

Bank akceptujący (Acquirer) zażądał natychmiastowej integracji z najnowszym protokołem EMV 3-D Secure 2.2, który przekazuje do banku ponad 150 parametrów telemetrycznych dotyczących urządzenia klienta, umożliwiając bankom podejmowanie inteligentnych decyzji o zwolnieniu z uwierzytelniania (Frictionless) przy jednoczesnym zachowaniu pełnej ochrony przed oszustwami.

Zarząd MegaMarket24 powierzył grupie laboratoryjnej zadanie wdrożenia i przetestowania bezpiecznego potoku transakcyjnego 3DS 2.0 zintegrowanego z bramką płatniczą.

Zadaniem studentów jest zasymulowanie integracji z serwerem 3DS, zaimplementowanie zbierania telemetrii przeglądarki (Device Fingerprinting), obsługa komunikatu wyzwania (Challenge Flow) z silnym uwierzytelnieniem SCA oraz skonfigurowanie reguł wnioskowania o wyłączenia (np. transakcje niskiej wartości poniżej 30 EUR / 100 PLN oraz analiza ryzyka TRA - Transaction Risk Analysis).

• Środowisko testowe Python / Node.js z symulatorem bramki płatniczej EMV 3DS
• Narzędzie Burp Suite do analizy komunikatów AReq (Authentication Request) i ARes
• Przeglądarka internetowa z narzędziami deweloperskimi DevTools (analiza zdarzeń iframe 3DS)
• Narzędzie cURL do odpytywania API Directory Servera
• Darmowe karty testowe EMVCo (numery kart wymuszające ścieżkę Frictionless vs Challenge)

1. Analiza architektury trzech domen protokołu EMV 3-D Secure: Acquirer Domain, Interoperability Domain, Issuer Domain.
2. Zbadanie wymogów dyrektywy PSD2 oraz wytycznych EBA (European Banking Authority) w zakresie Strong Customer Authentication (SCA).
3. Zidentyfikowanie trzech kategorii składników SCA: wiedza (hasło/PIN), posiadanie (smartfon/token), biometria (odcisk palca/twarz).
4. Zaimplementowanie skryptu po stronie klienta zbierającego telemetrię urządzenia (Device Fingerprinting): rozdzielczość ekranu, strefa czasowa, nagłówek User-Agent, obsługa JavaScript.
5. Sformatowanie i wysłanie komunikatu żądania uwierzytelnienia (AReq - Authentication Request) z serwera 3DS do Directory Servera (DS).
6. Obsługa odpowiedzi ARes (Authentication Response) z oceną ryzyka transakcji (Transaction Status: Y - Frictionless, C - Challenge Required, N - Not Authenticated).
7. Symulacja ścieżki Frictionless Flow (transakcja zatwierdzona bez angażowania użytkownika, transakcja niskiego ryzyka).
8. Symulacja ścieżki Challenge Flow (wymuszenie drugiego składnika uwierzytelnienia).
9. Zaimplementowanie bezpiecznej ramki modalnej 3DS Method / Challenge Window w interfejsie płatności sklepu.
10. Obsługa powiadomienia Push w aplikacji mobilnej banku wydawcy (potwierdzenie kwoty i odbiorcy transakcji).
11. Odebranie i weryfikacja kryptograficznego wyniku weryfikacji (CRes - Challenge Response).
12. Pobranie kryptograficznego tokena uwierzytelnienia CAVV / AAV (Cardholder Authentication Verification Value).
13. Zbadanie mechanizmu przeniesienia odpowiedzialności finansowej (Liability Shift) z akceptanta na bank wydawcę.
14. Zaimplementowanie logiki obsługi błędów Soft Decline (odrzucenie przez bank z żądaniem ponowienia ze statusem SCA).
15. Wdrożenie reguł wnioskowania o wyłączenia (Exemptions): transakcje niskiej wartości (Low-Value Exemption < 30 EUR, max 5 transakcji z rzędu).
16. Zaprojektowanie monitorowania wskaźnika konwersji koszyka przed i po wdrożeniu 3DS 2.0.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z diagramem sekwencji komunikatów 3DS.

Protokół 3-D Secure w wersji 2.0 zrewolucjonizował płatności internetowe dzięki wprowadzeniu ścieżki Frictionless Flow. Zamiast męczyć klienta hasłami SMS przy każdym zakupie, sklep przesyła do banku wydawcy karty bogaty pakiet danych telemetrycznych (adres IP, geolokalizacja, historia zakupów, cyfrowy odcisk urządzenia). Na tej podstawie bankowe algorytmy uczenia maszynowego (AI Fraud Prevention) oceniają ryzyko w ułamku sekundy. Aż 85-90% legalnych transakcji przechodzi bez żadnego okna weryfikacyjnego (Frictionless), a użytkownik jest proszony o potwierdzenie biometryczne tylko w przypadku anomalii.

Poniżej przedstawiono przykładową strukturę komunikatu żądania uwierzytelnienia 3DS 2.0 (AReq) w formacie JSON:

Odpowiedź Directory Servera (ARes) wskazująca na konieczność przeprowadzenia wyzwania (Challenge Flow):

Pomyślne zakończenie wyzwania i wygenerowanie kryptograficznego tokena CAVV (Liability Shift):

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

1. Architektura protokołu 3-D Secure 2.0: integracja komponentów 3DS Server, Directory Server (DS) oraz Access Control Server (ACS) banku-wydawcy.
2. Realizacja wymogów silnego uwierzytelniania klienta (SCA – Strong Customer Authentication) na gruncie unijnej dyrektywy PSD2.
3. Różnice operacyjne pomiędzy ścieżką bezproblemową (Frictionless Flow) a ścieżką wyzwania (Challenge Flow) z biometrią w aplikacji mobilnej.
4. Wykorzystanie zaawansowanego profilowania urządzenia (Device Fingerprinting) w dynamicznym szacowaniu ryzyka transakcji płatniczej.
5. Mechanizmy dopuszczalnych wyłączeń z wymogu SCA (transakcje niskokwotowe, biali odbiorcy, niska stopa oszustw TRA).
6. Ochrona kryptograficzna komunikatów w protokole 3DS: szyfrowanie ładunków JSON Web Encryption oraz podpisywanie JSON Web Signature.

Przykładowe wnioski (wzór do sprawozdania): Wdrożenie protokołu 3-D Secure 2.0 w platformie e-commerce umożliwiło bezproblemowe pogodzenie wymogów silnego uwierzytelniania klienta z minimalizacją współczynnika odrzuconych koszyków zakupowych. Wykorzystanie zaawansowanego profilowania urządzenia oraz analizy ryzyka transakcji pozwoliło na skierowanie ponad 75% operacji na ścieżkę bezproblemową bez angażowania kupującego. W sytuacjach podwyższonego ryzyka system płynnie inicjuje ścieżkę Challenge Flow, przekierowując autoryzację do bankowej aplikacji mobilnej wykorzystującej biometrię i powiadomienia push. Zastosowanie podpisów cyfrowych JWS oraz szyfrowania JWE zagwarantowało nienaruszalność i poufność danych wymienianych pomiędzy komponentami 3DS. Implementacja stanowi wzorcowe wypełnienie przepisów unijnej dyrektywy PSD2 oraz wytycznych KNF w obszarze bezpieczeństwa płatności internetowych.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Kryptografia asymetryczna. Podpisy cyfrowe, standard eIDAS i formaty zaawansowane.

Celem zadania jest zbadanie prawnych, kryptograficznych i technicznych aspektów podpisu elektronicznego w Unii Europejskiej zgodnie z Rozporządzeniem Parlamentu Europejskiego i Rady (UE) nr 910/2014 (eIDAS). Studenci analizują trzy poziomy podpisów: zwykły podpis elektroniczny, zaawansowany podpis elektroniczny (AdES) oraz kwalifikowany podpis elektroniczny (QES), który na mocy prawa posiada skutek prawny równoważny podpisowi własnoręcznemu (art. 25 ust. 2 eIDAS).

W części praktycznej studenci implementują i badają trzy wiodące europejskie standardy formatów podpisów cyfrowych zdefiniowane przez ETSI: format XAdES (XML Advanced Electronic Signatures) dla dokumentów strukturalnych, format PAdES (PDF Advanced Electronic Signatures) dla dokumentów przenośnych PDF oraz format CAdES (CMS Advanced Electronic Signatures) dla plików binarnych. Projekt obejmuje integrację z kwalifikowanym znacznikiem czasu (Time-Stamp Authority - TSA wg RFC 3161) zapewniającym prawny dowód istnienia dokumentu w danym punkcie czasu oraz weryfikację długoterminową (LTV - Long-Term Validation).

Krajowy Rejestr Dłużników i Sąd Arbitrażowy przy Izbie Gospodarczej w Warszawie wdraża platformę elektronicznego składania pozwów i wydawania cyfrowych wyroków arbitrażowych. Każdy wyrok sądu musi zostać podpisany kwalifikowanym podpisem elektronicznym przez trzech arbitrów, a dokumentacja musi zachować ważność dowodową przed sądami powszechnymi przez okres minimum 20 lat.

W trakcie pilotażu sędziowie podpisywali pliki PDF prostym podpisem w programie Adobe Acrobat bez dołączania kwalifikowanego znacznika czasu oraz bez osadzania pełnego łańcucha certyfikatów i list CRL (brak profilu LTV / PAdES-B-LTA). Po upływie dwóch lat, gdy certyfikat jednego z sędziów wygasł, programy weryfikujące zaczęły wyświetlać czerwony komunikat ostrzegawczy 'Podpis jest nieprawidłowy lub certyfikat wygasł!'.

Strona przegrywająca proces zaskarżyła wyrok, podnosząc zarzut, że wyrok nie został skutecznie podpisany w czasie ważności certyfikatu, a brak niezależnego znacznika czasu uniemożliwia udowodnienie, czy podpis został złożony przed, czy po unieważnieniu certyfikatu arbitra. Sąd apelacyjny nakazał wstrzymanie egzekucji wyroku do czasu wyjaśnienia.

Dyrektor Sądu Arbitrażowego powołał zespół biegłych z zakresu kryptologii (grupę laboratoryjną) w celu opracowania i wdrożenia niezaprzeczalnego standardu podpisywania orzeczeń sądowych zgodnego ze standardem eIDAS PAdES-LTA.

Zadaniem studentów jest zbadanie formatów XAdES, PAdES i CAdES, zaimplementowanie procesu podpisywania dokumentu PDF za pomocą narzędzia OpenSSL / pyhanko / DSS (Digital Signature Service), skonfigurowanie pobierania kryptograficznego znacznika czasu z publicznego serwera TSA oraz przeprowadzenie weryfikacji poprawności podpisu w horyzoncie długoterminowym.

• Narzędzie OpenSSL 3.x z obsługą protokołu Time-Stamp Protocol (openssl ts)
• Python 3 z biblioteką pyHanko (zaawansowane podpisywanie PAdES-LTA)
• Narzędzie DSS (Digital Signature Service) – oficjalne otwartoźródłowe narzędzie Komisji Europejskiej
• Adobe Acrobat Reader / Foxit Reader do wizualnej inspekcji podpisu PAdES
• Publiczne serwery TSA (np. freetsa.org, serwery kwalifikowane KIR / Certum)

1. Analiza ram prawnych rozporządzenia eIDAS: definicja danych w postaci elektronicznej, podpis zaawansowany (art. 26) oraz kwalifikowany (art. 25).
2. Porównanie właściwości formatów ETSI: XAdES (dla plików XML), PAdES (dla plików PDF), CAdES (dla dowolnych plików binarnych).
3. Analiza poziomów profili podpisów: B-B (Basic), B-T (z dołączonym znacznikiem czasu), B-LT (z osadzonymi danymi walidacji CRL/OCSP), B-LTA (Long-Term Archival z rekurencyjnymi znacznikami czasu).
4. Zbadanie protokołu Time-Stamp Protocol (TSP, RFC 3161): mechanizm generowania zapytania TSRq i odpowiedzi TST.
5. Wygenerowanie zapytania o znacznik czasu dla dokumentu wyroku: openssl ts -query -data wyrok.pdf -sha256 -cert -out wyrok.tsq.
6. Wysłanie zapytania do publicznego/kwalifikowanego serwera TSA za pomocą cURL: curl -H "Content-Type: application/timestamp-query" --data-binary @wyrok.tsq https://freetsa.org/tsr > wyrok.tsr.
7. Weryfikacja kryptograficzna otrzymanego znacznika czasu: openssl ts -verify -in wyrok.tsr -data wyrok.pdf -CAfile tsa_ca.pem.
8. Podpisanie dokumentu PDF z użyciem biblioteki pyHanko z profilem PAdES-B-LT.
9. Osadzenie kwalifikowanego znacznika czasu oraz odpowiedzi OCSP bezpośrednio w strukturze pliku PDF (Dss / Document Security Store).
10. Otwarcie podpisanego pliku PDF w programie Adobe Acrobat Reader i weryfikacja statusu: Podpisano i wszystkie strony są nienaruszone, Dokument zawiera wbudowany znacznik czasu.
11. Sprawdzenie właściwości LTV (Włączono obsługę LTV - Long Term Validation).
12. Zademonstrowanie ataku modyfikacji: zmiana pojedynczej litery w treści wyroku za pomocą edytora binarnego i zaobserwowanie unieważnienia podpisu.
13. Zbadanie formatu XAdES-BES oraz XAdES-T za pomocą narzędzia European Commission DSS.
14. Opracowanie procedury konserwacji podpisów długoterminowych (Archive Timestamping) odnawianych co 10 lat przed osłabieniem algorytmów skrótu.
15. Sformułowanie opinii prawno-kryptograficznej dla sądu potwierdzającej ważność dokumentów po wygaśnięciu certyfikatu.
16. Przygotowanie wytycznych dla sekretariatu sądu dotyczących prawidłowego składania podpisów PAdES.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z analizą struktur ASN.1 znacznika czasu.

Kluczem do długoterminowej ważności podpisu elektronicznego (Long-Term Validation - LTV) jest profil PAdES-B-LTA. W tym profilu w momencie składania podpisu do struktury dokumentu PDF zostaje wstrzyknięty kryptograficzny znacznik czasu (RFC 3161) oraz kompletne listy CRL i odpowiedzi OCSP poświadczające, że w tej konkretnej sekundzie certyfikat sędziego był ważny i nienaruszony. Dzięki temu, nawet gdy po 10 latach certyfikat wygaśnie lub urząd CA zakończy działalność, weryfikator może z matematyczną pewnością stwierdzić, że w chwili podpisywania dokumentu wszystkie warunki prawne były spełnione.

Poniżej przedstawiono procedurę generowania i weryfikacji znacznika czasu RFC 3161 za pomocą OpenSSL:

Inspekcja treści znacznika czasu (Time-Stamp Token) za pomocą openssl ts -reply:

Podpisanie dokumentu PDF w standardzie PAdES-B-LTA za pomocą biblioteki pyHanko w Pythonie:

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

1. Ramy prawne i techniczne rozporządzenia eIDAS (UE 910/2014): poziomy podpisów elektronicznych (podpis zwykły, zaawansowany oraz kwalifikowany QES).
2. Porównanie standardów formatów podpisów cyfrowych: XAdES (dla plików XML), PAdES (dla dokumentów PDF) oraz CAdES (dla danych binarnych).
3. Rola kwalifikowanego znacznika czasu (RFC 3161) w dowodzeniu istnienia dokumentu przed określonym momentem w czasie i przed wygaśnięciem certyfikatu.
4. Ewolucja poziomów zabezpieczenia podpisu cyfrowego: od poziomu podstawowego do formatu długoterminowej walidacji archiwalnej (LTA).
5. Dołączanie pełnych danych walidacyjnych (łańcuch certyfikatów, odpowiedzi OCSP/CRL) w strukturze dokumentu w celu uniezależnienia od zewnętrznych serwerów PKI.
6. Skutki prawne kwalifikowanego podpisu elektronicznego: zrównanie w skutkach prawnych z podpisem własnoręcznym zgodnie z art. 25 eIDAS i art. 78[1] KC.

Przykładowe wnioski (wzór do sprawozdania): Zaimplementowanie mechanizmu podpisywania dokumentów w standardzie PAdES-LTA zapewniło pełną moc prawną elektronicznych umów handlowych na gruncie rozporządzenia eIDAS oraz polskiego Kodeksu cywilnego. Dołączenie do struktury pliku PDF kwalifikowanego znacznika czasu zgodnego z RFC 3161 jednoznacznie potwierdziło nienaruszalność dokumentu w chwili jego parafowania. Wzbogacenie podpisu o kompletne dane walidacyjne LTV, w tym pełen łańcuch certyfikatów oraz zweryfikowane odpowiedzi OCSP ze statusem Good, umożliwiło weryfikację podpisu nawet po wielu latach od wygaśnięcia certyfikatu subskrybenta. Wybór formatu PAdES pozwolił na zachowanie doskonałej integralności wizualnej dokumentu przy użyciu standardowych czytników PDF bez konieczności instalowania zewnętrznych wtyczek. Opracowany proces stanowi w pełni bezpieczny, bezpapierowy obieg dokumentacji korporacyjnej o najwyższym poziomie wiarygodności dowodowej przed sądem.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon3 Autoryzacja i uwierzytelnianie w systemach komputerowych. Ataki na kanały transakcyjne i podpis transakcji.

Celem zadania jest zbadanie zaawansowanych wektorów ataków złośliwego oprogramowania na transakcje bankowości elektronicznej, ze szczególnym uwzględnieniem trojanów bankowych klasy Man-in-the-Browser (MitB, np. ZeuS, SpyEye, Dridex) oraz zaprojektowanie kryptograficznych mechanizmów obronnych opartych na dynamicznym podpisywaniu parametrów transakcji (Dynamic Linking / Transaction Signing / WYSIWYS - What You See Is What You Sign) zgodnie z art. 66 dyrektywy PSD2.

Studenci analizują technikę ataku, w której trojan zainfekował przeglądarkę internetową klienta za pomocą złośliwego rozszerzenia lub hooków API (DOM Injection), modyfikując numer rachunku odbiorcy w ułamku sekundy przed wysłaniem formularza do banku, podczas gdy na ekranie klienta wyświetla się pierwotny, poprawny numer. W części naprawczej studenci implementują mechanizm podpisywania danych transakcji w zewnętrznym, niezależnym kanale mobilnym (Out-of-Band Mobile Signing) z kryptograficznym wiązaniem kwoty i numeru rachunku docelowego.

Prywatny Bank Handlowy 'PoloniaBank' odnotował falę reklamacji od klientów biznesowych, którzy twierdzili, że zlecili przelewy wynagrodzeń dla swoich pracowników lub kontrahentów, a środki finansowe trafiły na zupełnie inne, nieznane rachunki bankowe. Klienci zarzekali się, że przed kliknięciem 'Wyślij' widzieli na ekranie poprawne numery kont swoich partnerów handlowych.

Szczegółowa analiza śledcza (Forensics) przeprowadzona na komputerach poszkodowanych księgowych ujawniła obecność trojana bankowego Man-in-the-Browser ukrytego pod postacią niewinnej wtyczki do przeglądarki Chrome służącej do pobierania faktur PDF. Trojan monitorował aktywność na stronie banku; w momencie naciśnięcia przycisku zatwierdzenia przelewu, skrypt w ułamku milisekundy podmieniał wartość pola nr_konta w drzewie DOM na numer konta kontrolowany przez przestępców.

Co gorsza, dotychczasowy mechanizm autoryzacji SMS przesyłał kod w postaci: 'Kod autoryzacyjny do operacji: 819201'. Ponieważ treść SMS nie zawierała ani kwoty, ani numeru rachunku, zdezorientowana księgowa przepisywała kod z telefonu, nieświadomie autoryzując sfałszowany przelew na kwotę 250 000 zł.

Komisja Nadzoru Finansowego nakazała bankowi natychmiastowe wdrożenie mechanizmów Dynamicznego Wiązania Transakcji (Dynamic Linking) wynikających z norm RTS dyrektywy PSD2.

Grupa laboratoryjna przyjmuje zadanie zespołu bezpieczeństwa bankowego. Studenci muszą zasymulować atak MitB w środowisku testowym (skrypt wstrzykujący kod do DOM), a następnie zaprojektować i zaimplementować architekturę Transaction Signing: wyliczanie unikalnego kodu autoryzacyjnego powiązanego kryptograficznie (HMAC-SHA256) z kwotą i ostatnimi cyframi konta odbiorcy oraz wymuszenie prezentacji tych danych na ekranie niezależnego urządzenia autoryzującego.

• Środowisko testowe bankowości elektronicznej w Node.js/PHP
• Przeglądarka internetowa z narzędziem Tampermonkey / DevTools do symulacji infekcji MitB
• Aplikacja mobilna / emulator generowania kodów TOTP/OCRA (OATH Challenge-Response Algorithm RFC 6287)
• Python 3 z biblioteką hashlib do implementacji algorytmu Dynamic Linking
• Burp Suite do inspekcji modyfikowanych parametrów żądania HTTP

1. Zbadanie mechanizmu działania trojanów bankowych klasy Man-in-the-Browser (hooki API, modyfikacja obiektów DOM, fałszowanie formularzy w locie).
2. Zasymulowanie podatnego formularza przelewu bankowego bez dynamicznego wiązania danych.
3. Napisanie skryptu JavaScript (symulator trojana MitB) podmieniającego numer rachunku docelowego podczas zdarzenia onsubmit.
4. Wysłanie przelewu i udokumentowanie, że mimo poprawnego widoku na ekranie użytkownika, do serwera banku trafił podmieniony numer konta.
5. Analiza prawna i techniczna art. 66 dyrektywy PSD2 oraz wymogu Dynamic Linking (dynamicznego wiązania kodu uwierzytelniającego z kwotą i odbiorcą).
6. Zaprojektowanie algorytmu kryptograficznego Transaction Signing opartego na standardzie OATH OCRA (RFC 6287) lub HMAC-SHA256.
7. Implementacja funkcji wyliczającej skrót danych transakcji: H = HMAC_SHA256(Klucz_Klienta, Kwota || Nr_Konta || Znacznik_Czasu).
8. Zaprojektowanie kanału autoryzacji mobilnej (Push Notification): przesyłanie do smartfona klienta zaszyfrowanego pakietu z jawną prezentacją danych: 'Czy potwierdzasz przelew 50 000 PLN na konto ...1234?'.
9. Wdrożenie zasady WYSIWYS (What You See Is What You Sign): użytkownik zatwierdza transakcję na ekranie zaufanego urządzenia mobilnego, a nie w przeglądarce.
10. Wymuszenie generowania podpisu transakcji wewnątrz bezpiecznej enklawy smartfona (Secure Enclave / Keystore).
11. Zaimplementowanie weryfikacji podpisu transakcji po stronie serwera bankowego przed zleceniem przelewu w systemie Elixir.
12. Zademonstrowanie nieskuteczności ataku MitB po wdrożeniu zabezpieczeń: trojan podmienia numer konta w przeglądarce, ale podpis klienta dotyczy oryginalnego konta, co wywołuje natychmiastowy błąd weryfikacji kryptograficznej na serwerze.
13. Wdrożenie mechanizmu ochrony przed atakami powtórzeniowymi (Nonce / Replay Protection).
14. Zaprojektowanie procedury awaryjnego blokowania konta w przypadku wykrycia wielokrotnych niezgodności danych transakcji z podpisem.
15. Opracowanie kampanii edukacyjnej dla klientów: zasada bezwzględnego czytania danych transakcji w aplikacji autoryzacyjnej.
16. Sformułowanie wniosków dotyczących wyższości autoryzacji mobilnej nad prostymi kodami SMS.
17. Sporządzenie sprawozdania laboratoryjnego z kodem modułu Transaction Signing i zrzutami z symulacji ataku.

Standard Dynamic Linking (dynamicznego wiązania) wprowadzony przez PSD2 wymaga, aby kod uwierzytelniający był unikalny dla każdej konkretnej transakcji i ściśle powiązany z kwotą oraz odbiorcą. Oznacza to, że kod wygenerowany dla przelewu 100 zł na konto A jest matematycznie bezużyteczny dla przelewu 100 zł na konto B, ani dla przelewu 10 000 zł na konto A. Nawet jeśli trojan MitB zdoła przechwycić kod autoryzacyjny, nie może go użyć do sfałszowania żadnego innego przelewu.

Poniżej przedstawiono implementację algorytmu Dynamic Transaction Signing w języku Python:

Symulacja wstrzyknięcia złośliwego kodu przez trojana MitB w konsoli przeglądarki:

Odpowiedź serwera bankowego odrzucająca transakcję z naruszonym wiązaniem dynamicznym:

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

1. Analiza wektorów ataków złośliwego oprogramowania typu Man-in-the-Browser podmieniającego dane transakcji w locie w przeglądarce ofiary.
2. Koncepcja dynamicznego łączenia transakcji (Dynamic Linking) na gruncie PSD2: kryptograficzne powiązanie kodu autoryzacyjnego z rachunkiem i kwotą przelewu.
3. Rola zasady What You See Is What You Sign (WYSIWYS) w dedykowanych urządzeniach i bezpiecznych aplikacjach bankowości mobilnej.
4. Zastąpienie podatnych jednorazowych kodów SMS autoryzacją za pomocą powiadomień Mobile Push w odrębnym, szyfrowanym kanale transmisji.
5. Zastosowanie mechanizmów ochrony aplikacji mobilnej (RASP): detekcja środowiska zrootowanego, debuggera oraz złośliwych nakładek ekranowych.
6. Monitorowanie anomalii sesyjnych i behawioralnych w systemach Fraud Detection banku w celu automatycznego blokowania podejrzanych transferów środków.

Przykładowe wnioski (wzór do sprawozdania): Praktyczna analiza zachowania trojana bankowego typu Man-in-the-Browser wykazała, że złośliwy skrypt wstrzyknięty w proces przeglądarki jest w stanie niezauważalnie podmienić docelowy numer rachunku IBAN w formularzu przelewu. Tradycyjne hasła jednorazowe okazały się bezskuteczne, o ile użytkownik bezrefleksyjnie przepisywał kod autoryzacyjny bez weryfikacji danych operacji. Skutecznym środkiem obronnym okazało się wdrożenie mechanizmu dynamicznego łączenia, w którym kod uwierzytelniający jest kryptograficznie zależny od kwoty oraz docelowego numeru konta. Przeniesienie autoryzacji do bezpiecznej aplikacji mobilnej z technologią RASP i czytelną prezentacją szczegółów przelewu uniemożliwiło przeprowadzenie ataku nawet na zainfekowanym komputerze użytkownika. Zaprojektowana architektura eliminuje kluczowe wektory nadużyć finansowych i spełnia rygorystyczne wytyczne Rekomendacji KNF dotyczące bezpiecznej bankowości elektronicznej.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia integralności i autentyczności informacji. Podpisywanie żądań API.

Celem zadania jest zaprojektowanie, zaimplementowanie i przetestowanie bezpiecznego protokołu komunikacji międzysystemowej dla bramki płatności internetowych (Payment Gateway API) łączącej tysiące sklepów e-commerce z operatorem rozliczeniowym. Studenci badają anatomię ataków na interfejsy finansowe: ataki powtórzeniowe (Replay Attacks), ataki modyfikacji parametrów zamówienia (np. zmiana kwoty przelewu lub statusu płatności z PAID=false na PAID=true w locie) oraz podsłuch w kanale komunikacyjnym.

W ramach laboratorium studenci implementują mechanizm kryptograficznego podpisywania każdego żądania HTTP (Request Signing) za pomocą kodów uwierzytelniania wiadomości HMAC-SHA256, wdrożenie jednorazowych liczb losowych (Nonce) z pamięcią podręczną Redis oraz znaczników czasu (Timestamp Tolerance Window max. 300 sekund). Projekt uczy weryfikacji integralności ładunku JSON oraz bezpiecznego zarządzania współdzielonymi sekretami API.

Ogólnopolska sieć sklepów odzieżowych 'ModaOnline S.A.' zintegrowała swój sklep internetowy z nową bramką płatności natychmiastowych. Integracja opierała się na wywołaniach webhooków: po pomyślnym opłaceniu zamówienia przez klienta, serwer bramki płatności wysyłał żądanie POST na adres https://modaonline.pl/api/payment/webhook z treścią JSON: {"order_id": "ORD-9812", "status": "PAID", "amount": 450.00}.

Podczas audytu bezpieczeństwa testerzy przechwycili jedno legalne żądanie potwierdzenia płatności. Ponieważ webhook nie posiadał żadnego podpisu kryptograficznego ani weryfikacji tożsamości nadawcy, testerzy byli w stanie wysłać sfałszowane żądanie HTTP podające dowolny numer nieopłaconego zamówienia z parametrem "status": "PAID". Sklep natychmiast oznaczył zamówienie jako opłacone i przekazał towar do wysyłki magazynowej bez wpłynięcia ani jednego grosza na konto firmy.

Co gorsza, testerzy zademonstrowali atak powtórzeniowy (Replay Attack): przechwycili żądanie zwrotu środków (Refund API) i wysłali je do serwera bramki 100 razy z rzędu w pętli. Ponieważ interfejs nie kontrolował unikalności zapytań (brak Nonce), serwer bramki 100-krotnie wypłacił środki z rachunku sklepu na kartę klienta.

Dyrektor Finansowy spółki nakazał natychmiastowe zablokowanie wszystkich integracji webhookowych do czasu wdrożenia pancernego standardu bezpieczeństwa transakcji API wzorowanego na standardach Stripe i Amazon AWS API Signing.

Zadaniem grupy laboratoryjnej jest opracowanie bezpiecznego protokołu wymiany komunikatów: zaimplementowanie podpisywania całego ładunku JSON kluczem HMAC-SHA256, osadzenie sygnatury w nagłówku X-Signature, dodanie nagłówka ze znacznikiem czasu X-Timestamp (odrzucanie zapytań starszych niż 5 minut) oraz nagłówka X-Nonce (zapisywanego w bazie Redis na 10 minut w celu eliminacji duplikatów).

• Środowisko Node.js / Python 3 z bibliotekami hmac, hashlib, requests
• Baza danych Redis w kontenerze Docker do buforowania liczb Nonce
• Narzędzie Burp Suite / Postman do testowania ataków powtórzeniowych (Replay Attack)
• Narzędzie cURL do wysyłania precyzyjnie podpisanych żądań API
• Framework testowy pytest do automatyzacji testów bezpieczeństwa API

1. Zbadanie podatności niepodpisanego webhooka na ataki modyfikacji danych i podszywania się.
2. Zaprojektowanie struktury nagłówków bezpieczeństwa API: X-Signature, X-Timestamp, X-Nonce, X-Merchant-ID.
3. Zaimplementowanie algorytmu kanonizacji ładunku JSON (uporządkowanie kluczy, usunięcie białych znaków) w celu wyeliminowania rozbieżności skrótów.
4. Zbudowanie łańcucha do podpisu (String-to-Sign): Metoda || Ścieżka || X-Timestamp || X-Nonce || Sha256(Payload).
5. Wyliczenie sygnatury kryptograficznej: X-Signature = HMAC-SHA256(SecretKey, String-to-Sign).
6. Wdrożenie weryfikacji znacznika czasu po stronie odbiorcy: odrzucenie żądania z kodem HTTP 400, jeśli różnica czasu przekracza 300 sekund (|Time_Serwera - X-Timestamp| > 300).
7. Zaimplementowanie ochrony przed atakami powtórzeniowymi (Replay Protection): sprawdzenie w bazie Redis czy klucz nonce:X-Nonce już istnieje.
8. Zapisanie nowej wartości Nonce w Redis z czasem wygaśnięcia TTL = 600 sekund: SET nonce:<wartosc> 1 EX 600 NX.
9. Weryfikacja kryptograficzna sygnatury HMAC za pomocą stałoczasowej funkcji hmac.compare_digest.
10. Zademonstrowanie nieskuteczności ataku modyfikacji parametrów (np. zmiana kwoty z 450.00 na 4.50 powoduje niezgodność sygnatury HMAC).
11. Zademonstrowanie nieskuteczności ataku powtórzeniowego (ponowne wysłanie identycznego żądania kończy się błędem HTTP 409 Conflict - Nonce Already Used).
12. Opracowanie mechanizmu bezpiecznej rotacji kluczy sekretnych API (Secret Key Rotation) z jednoczesną obsługą dwóch kluczy w okresie przejściowym.
13. Zaprojektowanie logowania prób naruszenia integralności transakcji z alarmowaniem w systemie SIEM.
14. Napisanie zestawu testów jednostkowych i integracyjnych weryfikujących zachowanie bramki dla zapytań przeterminowanych i sfałszowanych.
15. Zdefiniowanie wytycznych bezpiecznej implementacji webhooków dla programistów platform e-commerce.
16. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z pełnymi kodami modułów weryfikacji i generowania podpisów.

Podczas weryfikacji sygnatur kryptograficznych HMAC w aplikacjach webowych kardynalnym błędem jest stosowanie zwykłego operatora porównania ciągów (np. `if ($sig == $expected_sig)` lub `if sig == expected_sig`). Zwykłe porównanie przerywa działanie na pierwszym niezgodnym bajcie, co tworzy kanał boczny podatny na atak czasowy (Timing Attack), w którym napastnik może odgadnąć poprawną sygnaturę bajt po bajcie. Należy bezwzględnie stosować stałoczasową funkcję porównania, taką jak `hash_equals()` w PHP lub `hmac.compare_digest()` w Pythonie.

Poniżej przedstawiono implementację bezpiecznego serwera weryfikującego podpis HMAC, znacznik czasu i unikalność Nonce w języku Python:

Próba wysłania powtórzonego żądania (Replay Attack) zostaje natychmiast odrzucona przez Redis Nonce Lock:

Próba modyfikacji kwoty transakcji w locie powoduje naruszenie podpisu HMAC-SHA256:

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

1. Anatomia protokołów komunikacji interfejsów płatniczych (Server-to-Server / Webhook) i ryzyko manipulacji parametrami zatwierdzenia transakcji.
2. Generowanie i weryfikacja kryptograficznego podpisu żądania API przy użyciu funkcji HMAC-SHA256 oraz tajnego klucza współdzielonego.
3. Standaryzacja i kanonizacja ładunku HTTP (Canonical Request String) w celu zapewnienia powtarzalności obliczeń skrótu po obu stronach interfejsu.
4. Zabezpieczenie przed atakami powtórzeniowymi (Replay Attacks) za pomocą unikalnych identyfikatorów żądania (Cryptographic Nonce) i rejestru w pamięci podręcznej.
5. Weryfikacja dopuszczalnego okna czasowego żądania (Timestamp Drift Window) w celu natychmiastowego unieważniania przechwyconych pakietów.
6. Ochrona symetrycznych kluczy integracyjnych bramki płatniczej w dedykowanych, korporacyjnych magazynach sekretów.

Przykładowe wnioski (wzór do sprawozdania): Zaprojektowanie protokołu podpisywania żądań API za pomocą algorytmu HMAC-SHA256 zapewniło pełną integralność i niezaprzeczalność powiadomień transakcyjnych wysyłanych przez bramkę płatniczą. Deterministyczna kanonizacja parametrów żądania HTTP przed obliczeniem skrótu wyeliminowała błędy weryfikacji wynikające z różnic w formatowaniu znaków białych lub kolejności pól JSON. Połączenie kryptograficznego znacznika czasu z pięciominutowym oknem tolerancji oraz unikalnego numeru nonce skutecznie uniemożliwiło realizację ataków powtórzeniowych. Zastosowanie szybkiego rejestru kluczy jednorazowych w pamięci podręcznej Redis pozwoliło na natychmiastowe odrzucanie duplikatów żądań bez obciążania głównej bazy danych. Wdrożony mechanizm zabezpiecza platformę e-commerce przed sztucznym zatwierdzaniem fikcyjnych zamówień i stanowi standard branżowy rekomendowany przez wiodących operatorów płatności.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon4 Bezpieczeństwo protokołów komunikacyjnych i sieci komputerowych. Audyt konfiguracji TLS.

Celem zadania jest przeprowadzenie rygorystycznego, zautomatyzowanego audytu bezpieczeństwa warstwy kryptograficznej TLS (Transport Layer Security) w węzłach bramek płatniczych oraz wdrożenie całościowego utwardzenia konfiguracji (Hardening) zgodnie z wytycznymi PCI SSC (Payment Card Industry Security Standards Council) oraz rekomendacjami NIST SP 800-52 Rev. 2. Studenci analizują historyczne i współczesne podatności protokołów bezpiecznych: Heartbleed (CVE-2014-0160), CCS Injection, POODLE, DROWN, FREAK, Logjam, ROBOT oraz ataki na renegocjację sesji.

W ramach laboratorium studenci wykorzystują zaawansowane narzędzia diagnostyczne wiersza poleceń (testssl.sh, sslscan, nmap ssl-enum-ciphers) oraz oficjalne API Qualys SSL Labs do zbadania odporności serwera produkcyjnego. Zadanie obejmuje eliminację słabych szyfrów (CBC, RC4, 3DES), wymuszenie obsługi wyłącznie bezpiecznych protokołów (TLS 1.2 i TLS 1.3), wdrożenie ochrony przed atakami typu downgrade oraz automatyzację audytu w potoku ciągłej integracji CI/CD.

Operator bramki płatniczej CashFlow Polska S.A. obsługuje integracje finansowe dla ponad 500 serwisów internetowych. W ramach corocznego audytu odnowienia certyfikacji PCI DSS Level 1, zewnętrzny audytor QSA przeprowadził skanowanie infrastruktury brzegowej bramki i wykrył szereg krytycznych uchybień konfiguracyjnych.

Na interfejsie API bramki nadal aktywna była obsługa protokołu TLS 1.0 oraz słabych zestawów szyfrów z algorytmem CBC podatnych na atak Lucky Thirteen. Dodatkowo serwer akceptował niebezpieczną renegocjację sesji inicjowaną przez klienta (Insecure Client-Initiated Renegotiation), co pozwalało napastnikowi na przeprowadzenie ataku DoS polegającego na wyczerpaniu mocy procesora serwera poprzez ciągłe wymuszanie kosztownych operacji asymetrycznych.

Brak wdrożenia nagłówka HSTS oraz brak wsparcia dla mechanizmu ALPN (Application-Layer Protocol Negotiation) spowodował obniżenie oceny w teście SSL Labs do kompromitującej oceny 'B'. Audytor QSA wydał warunkową opinię negatywną, wyznaczając 7 dni na doprowadzenie konfiguracji do stanu idealnego (ocena A+ w SSL Labs), w przeciwnym razie operatorowi groziło wstrzymanie możliwości przetwarzania transakcji kartowych.

Zarząd CashFlow powołał grupę laboratoryjną w celu przeprowadzenia audytu diagnostycznego, zidentyfikowania wszystkich słabych punktów konfiguracji oraz wdrożenia pancernego profilu kryptograficznego.

Studenci muszą przeprowadzić pełne skanowanie za pomocą narzędzia testssl.sh, zinterpretować raport podatności, zmodyfikować konfigurację serwera Nginx/Apache (wyłączenie TLS 1.0/1.1, usunięcie szyfrów CBC, włączenie HSTS i OCSP Stapling) oraz powtórzyć skanowanie w celu udokumentowania osiągnięcia najwyższego ratingu A+.

• Narzędzie audytorskie testssl.sh v3.0+ (skrypt Bash z kompletem testów podatności)
• Narzędzie sslscan oraz skrypty Nmap (ssl-enum-ciphers, ssl-cert)
• Klient API Qualys SSL Labs w języku Python (ssllabs-scan)
• Serwer WWW Nginx w środowisku Linux
• OpenSSL 3.x CLI do manualnej weryfikacji negocjacji szyfrów

1. Zbadanie wymagań PCI DSS v4.0 dotyczących kryptografii transmisyjnej (całkowity zakaz SSLv3, TLS 1.0 i TLS 1.1).
2. Uruchomienie wstępnego skanowania podatności serwera bramki za pomocą narzędzia testssl.sh --fast https://target.local.
3. Analiza raportu testssl.sh pod kątem znanych ataków kryptograficznych: Heartbleed, CCS, Ticketbleed, ROBOT, CRIME, BREACH, POODLE, DROWN, LOGJAM, BEAST, LUCKY13, RC4.
4. Wykrycie podatności na ataki renegocjacji: zbadanie parametru Secure Renegotiation oraz Client-initiated Renegotiation.
5. Przeprowadzenie enumeracji obsługiwanych zestawów szyfrów za pomocą skryptu Nmap: nmap --script ssl-enum-ciphers -p 443 target.local.
6. Zidentyfikowanie słabych szyfrów podlegających natychmiastowemu wycofaniu: szyfry z algorytmem CBC, 3DES, RC4 oraz szyfry bez własności Perfect Forward Secrecy.
7. Zmiana konfiguracji serwera Nginx: wymuszenie protokołów TLSv1.2 oraz TLSv1.3 (ssl_protocols TLSv1.2 TLSv1.3;).
8. Zdefiniowanie restrykcyjnej listy bezpiecznych szyfrów AEAD dla TLS 1.2: ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-RSA-CHACHA20-POLY1305.
9. Włączenie bezpiecznego negocjowania parametrów na krzywych eliptycznych: ssl_ecdh_curve X25519:secp256r1:secp384r1;.
10. Wdrożenie nagłówka HSTS z długim okresem buforowania i opcją preload: add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;.
11. Konfiguracja buforowania i zszywania odpowiedzi OCSP Stapling w celu optymalizacji uścisków dłoni.
12. Przeładowanie serwera Nginx i ponowne uruchomienie pełnego skanowania testssl.sh.
13. Weryfikacja wyeliminowania wszystkich podatności i uzyskania statusu Grade A+.
14. Zintegrowanie skanera testssl.sh z potokiem automatycznego testowania CI/CD w celu blokowania wdrożeń osłabiających kryptografię.
15. Opracowanie procedury kwartalnego przeglądu konfiguracji kryptograficznej zgodnie z wytycznymi KNF.
16. Sformułowanie formalnego raportu audytorskiego dla audytora QSA potwierdzającego spełnienie wymogów PCI DSS.
17. Podsumowanie wdrożenia w sprawozdaniu laboratoryjnym z pełnymi listingami przed i po utwardzeniu.

Uzyskanie najwyższego ratingu A+ w audytach bezpieczeństwa TLS (np. Qualys SSL Labs lub testssl.sh) wymaga spełnienia czterech bezwzględnych kryteriów: 1) Całkowite wyłączenie protokołów poniżej TLS 1.2, 2) Akceptowanie wyłącznie szyfrów zapewniających Forward Secrecy (wyłącznie zestawy ECDHE/DHE z szyfrowaniem AEAD, zero szyfrów CBC), 3) Prawidłowo skonfigurowany certyfikat z pełnym łańcuchem zaufania i aktywnym OCSP Stapling, oraz 4) Wdrożenie nagłówka HSTS z czasem ważności minimum 6 miesięcy (max-age >= 15768000) i flagą includeSubDomains.

Poniżej przedstawiono przykładowy wynik audytu bezpieczeństwa serwera bramki za pomocą narzędzia testssl.sh po wdrożeniu utwardzenia:

Ocena ogólna ratingu bezpieczeństwa wygenerowana przez skaner audytorski:

Weryfikacja obsługi ALPN (Application-Layer Protocol Negotiation) dla HTTP/2:

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

1. Metodyka zautomatyzowanego audytu konfiguracji TLS w środowiskach przetwarzających dane kartowe przy użyciu narzędzia testssl.sh i API SSL Labs.
2. Bezwzględna eliminacja przestarzałych wersji protokołów (SSL 2.0/3.0, TLS 1.0, TLS 1.1) oraz podatnych mechanizmów kompresji i renegocjacji sesji.
3. Dobór nowoczesnych zestawów szyfrów AEAD zapewniających doskonałe utajnianie w przód (ECDHE z krzywą X25519) oraz wysoki poziom bezpieczeństwa.
4. Wdrożenie rygorystycznej polityki HTTP Strict Transport Security (HSTS) z wymuszeniem parametru includeSubDomains i zgłoszeniem do listy HSTS Preload.
5. Monitorowanie wpisów Certificate Transparency w celu wczesnego wykrywania nieautoryzowanego wystawienia certyfikatów dla domen bramki płatniczej.
6. Ciągła weryfikacja podatności kryptograficznych w potokach DevSecOps pod kątem spełnienia wymagań rozdziału 4 standardu PCI DSS v4.0.

Przykładowe wnioski (wzór do sprawozdania): Zautomatyzowany audyt bezpieczeństwa przeprowadzony za pomocą narzędzia testssl.sh pozwolił na natychmiastowe zidentyfikowanie i wyeliminowanie niebezpiecznych luk w konfiguracji TLS węzła bramki płatniczej. Wyłączenie przestarzałego wsparcia dla protokołu TLS 1.0/1.1 oraz słabych szyfrów CBC całkowicie usunęło podatności na ataki Sweet32 i Lucky Thirteen, skutkując uzyskaniem najwyższej noty A+ w teście SSL Labs. Wymuszenie algorytmów TLS 1.3 z wymianą kluczy X25519 zagwarantowało pełne utajnianie w przód dla wszystkich transakcji kartowych. Skonfigurowanie nagłówka HSTS z okresem ważności dwóch lat oraz wpisaniem domeny na globalną listę Preload zablokowało wszelkie próby obniżenia poziomu połączenia do nieszyfrowanego HTTP. Otrzymana konfiguracja stanowi wzorzec bezpieczeństwa transmisji danych finansowych, w pełni odpowiadający rygorystycznym wytycznym punktu 4.1 normy PCI DSS v4.0.

Kon1 Rodzaje i źródła zagrożeń dla systemów teleinformatycznych. Metody i środki ochrony. Kon2 Warunki zapewnienia poufności i integralności informacji. Ochrona danych w portfelach cyfrowych.

Celem zadania jest zaprojektowanie kompleksowej architektury bezpieczeństwa aplikacji mobilnego portfela elektronicznego (E-Wallet / Digital Wallet) przechowującego wirtualne karty płatnicze, tokeny płatności zbliżeniowych NFC (HCE - Host Card Emulation) oraz saldo środków cyfrowych. Studenci badają zasady ochrony danych w urządzeniach mobilnych narażonych na ataki rootowania/jailbreaku, analizę pamięci RAM (Memory Dumping) oraz inżynierię wsteczną aplikacji (Reverse Engineering).

W części technicznej zadanie obejmuje wdrożenie wielowarstwowej ochrony: integrację z bezpieczną enklawą sprzętową procesora smartfona (Hardware Security Module / Secure Enclave w iOS / Android Keystore z obsługą StrongBox), generowanie kluczy asymetrycznych powiązanych z biometrią użytkownika (User Authentication Gatekeeper), szyfrowanie bazy danych portfela algorytmem SQLCipher (AES-256) oraz implementację mechanizmów ochrony przed modyfikacją kodu w czasie działania (RASP - Runtime Application Self-Protection).

Fintech 'SmartPay Polska' uruchomił aplikację mobilnego portfela elektronicznego dla systemów Android i iOS, umożliwiającą płatności zbliżeniowe w sklepach, przelewy P2P na numer telefonu oraz przechowywanie biletów komunikacji miejskiej. Portfel gromadził dane kart płatniczych oraz tokeny autoryzacyjne w lokalnej bazie danych SQLite na smartfonie.

W trakcie audytu bezpieczeństwa testerzy pobrali aplikację ze sklepu Google Play i uruchomili ją na zrootowanym smartfonie z zainstalowanym frameworkiem Frida. Za pomocą prostego skryptu hookującego funkcje jądra testerzy zrzucili zawartość bazy SQLite z pamięci telefonu, uzyskując dostęp do tokenów sesyjnych, historii transakcji, salda oraz niezaszyfrowanych kluczy prywatnych użytkowników.

Co więcej, wykazano, że aplikacja nie posiadała żadnych mechanizmów wykrywania debugera, nie sprawdzała integralności własnego pakietu APK, a klucze szyfrujące były wyprowadzane ze stałego ciągu znaków zapisanego w kodzie aplikacji (Hardcoded Key), co pozwalało każdemu złośliwemu oprogramowaniu zainstalowanemu na telefonie na kradzież środków z portfela.

Prezes SmartPay natychmiast zawiesił działanie aplikacji i powołał grupę audytorów (zespół laboratoryjny) w celu zaprojektowania od podstaw pancernej architektury bezpieczeństwa portfela mobilnego.

Zadaniem studentów jest zaprojektowanie schematu ochrony: wdrożenie bezpiecznego przechowywania kluczy w sprzętowej enklawie Android Keystore / Apple Secure Enclave (gdzie operacja kryptograficzna wymaga uwierzytelnienia biometrycznego), zaszyfrowanie bazy SQLite za pomocą SQLCipher (AES-256 z kluczem wygenerowanym w Keystore), wdrożenie mechanizmów wykrywania root/jailbreak oraz implementacja dynamicznej tokenizacji transakcji NFC.

• Android Studio / środowisko emulatora Android z obsługą Keystore i biometrii
• Biblioteka SQLCipher do pełnego szyfrowania baz danych SQLite algorytmem AES-256
• Framework Frida do symulacji ataków dynamicznych (Dynamic Binary Instrumentation)
• Narzędzie jadx-gui do analizy inżynierii wstecznej i weryfikacji zaciemniania kodu (Obfuscation)
• Python 3 z biblioteką pycryptodome do symulacji protokołu tokenizacji portfela

1. Zbadanie wektorów ataków na aplikacje portfeli mobilnych: zrootowane urządzenia, debugery, hookowanie pamięci (Frida/Xposed), klonowanie bazy danych.
2. Analiza architektury bezpiecznych enklaw sprzętowych: Android Keystore Provider, StrongBox Keymaster oraz Apple Secure Enclave.
3. Zaprojektowanie hierarchii kluczy portfela: klucz nadrzędny w sprzętowej enklawie -> klucz bazy danych SQLCipher -> tokeny transakcyjne.
4. Zaimplementowanie generowania 256-bitowego klucza AES w Android Keystore z flagą setUserAuthenticationRequired(true) (wymóg biometrii przy każdym użyciu).
5. Konfiguracja bazy danych SQLite z wykorzystaniem biblioteki SQLCipher (pełne szyfrowanie bazy danych AES-256-CBC z KDF PBKDF2 256 000 iteracji).
6. Zaimplementowanie bezpiecznego przekazywania klucza z Keystore do bazy SQLCipher bez pozostawiania śladów w pamięci RAM.
7. Wdrożenie mechanizmu ochrony przed analizą dynamiczną i modyfikacją kodu (RASP - Runtime Application Self-Protection).
8. Zaimplementowanie wykrywania środowiska zrootowanego (Root Detection): sprawdzanie obecności binarek su, Magisk, Superuser oraz testowanie właściwości ro.build.tags.
9. Zaimplementowanie wykrywania podłączenia debugera (Debug Detection) i hookingu ptrace.
10. Zaimplementowanie weryfikacji integralności podpisu cyfrowego aplikacji (Anti-Tampering) w celu ochrony przed przepakowaniem APK.
11. Zaprojektowanie protokołu tokenizacji płatności zbliżeniowych NFC (HCE): generowanie jednorazowych kluczy transakcyjnych LUK (Limited Use Keys).
12. Zbadanie mechanizmu automatycznego wygasania wirtualnych tokenów płatniczych po wykonaniu określonej liczby transakcji offline.
13. Przetestowanie odporności aplikacji: próba odczytania bazy SQLCipher za pomocą sqlite3 (potwierdzenie błędu file is not a database).
14. Próba zaatakowania aplikacji narzędziem Frida i zweryfikowanie natychmiastowego zakończenia działania aplikacji po wykryciu anomalii.
15. Wdrożenie zamazania pamięci RAM (Memory Zeroization) dla obiektów przechowujących dane kart po zakończeniu operacji.
16. Opracowanie procedury zdalnego unieważnienia portfela (Remote Wipe) w przypadku zgłoszenia kradzieży smartfona.
17. Skompilowanie raportu laboratoryjnego z diagramem architektury sprzętowej i kodem implementacyjnym.

W architekturze nowoczesnych portfeli cyfrowych kluczowym standardem jest oddelegowanie operacji kryptograficznych do bezpiecznej enklawy procesora (Secure Enclave / StrongBox). Aplikacja mobilna nigdy nie zna surowego klucza prywatnego ani klucza deszyfrującego bazę. Zamiast tego aplikacja żąda od systemu operacyjnego: 'Zaszyfruj/podpisz te dane za pomocą klucza X'. System operacyjny uruchamia moduł biometrii (odcisk palca), weryfikuje użytkownika sprzętowo i dopiero wtedy koprocesor kryptograficzny wykonuje operację, uniemożliwiając kradzież klucza nawet przy pełnym przejęciu kontroli nad systemem Android przez złośliwe oprogramowanie.

Poniżej przedstawiono przykładową implementację inicjalizacji zaszyfrowanej bazy SQLCipher z kluczem pobieranym ze sprzętowego Keystore w języku Kotlin/Java:

Próba odczytania zaszyfrowanej bazy portfela przez napastnika za pomocą standardowego narzędzia sqlite3:

Wykrycie próby podłączenia frameworka Frida przez moduł RASP i natychmiastowe zamknięcie aplikacji:

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

1. Architektura wielowarstwowej ochrony danych w portfelach cyfrowych: podział na rzeczywisty numer karty (FPAN) oraz stokenizowany numer urządzenia (DPAN).
2. Rola sprzętowych enklaw bezpieczeństwa (Secure Enclave, StrongBox Keymaster) w generowaniu i niewywłaszczalnym przechowywaniu kluczy kryptograficznych.
3. Emulacja karty w oprogramowaniu (Host Card Emulation – HCE) a bezpieczeństwo kryptograficzne tokenów płatniczych w transakcjach zbliżeniowych NFC.
4. Wymuszenie biometrycznego odblokowania klucza z powiązaniem kryptograficznym w sprzętowym module bezpieczeństwa urządzenia mobilnego.
5. Ochrona danych wrażliwych w spoczynku w bazie aplikacji mobilnej z wykorzystaniem bazy SQLCipher i kluczy z bezpiecznego magazynu Keystore.
6. Spełnienie wytycznych bezpieczeństwa organizacji płatniczych (konsorcjum EMVCo) oraz normy ochrony danych osobowych RODO w architekturze portfeli cyfrowych.

Przykładowe wnioski (wzór do sprawozdania): Zaprojektowanie architektury mobilnego portfela cyfrowego w oparciu o sprzętową enklawę bezpieczeństwa zagwarantowało całkowitą izolację kluczy kryptograficznych od systemu operacyjnego urządzenia. Zastąpienie rzeczywistego numeru karty dynamicznym tokenem urządzenia uniemożliwiło wykorzystanie przechwyconych danych transakcyjnych w innym kanale płatniczym. Każda operacja zbliżeniowa NFC z wykorzystaniem technologii HCE wymaga wygenerowania jednorazowego kryptogramu dynamicznego, którego odtworzenie przez podsłuchującego jest matematycznie niemożliwe. Wymuszenie autoryzacji biometrycznej chronionej sprzętowo zapobiegło realizacji płatności w przypadku fizycznej kradzieży odblokowanego smartfona. Wdrożone mechanizmy spełniają najwyższe standardy konsorcjum EMVCo i zapewniają użytkownikom maksymalne bezpieczeństwo środków finansowych.