Sprawdzenie podpisu cyfrowego

Sprawdzenie podpisu cyfrowego to weryfikacja, czy dokument nie został zmieniony po jego podpisaniu.

Mechanizm działania asymetrycznej kryptografii i funkcji skrótu

Pojęcie to opiera się na matematycznych podstawach kryptografii asymetrycznej oraz deterministycznych, jednokierunkowych funkcji skrótu. Proces weryfikacji to odwrócenie operacji kryptograficznych dokonywanych podczas składania podpisu. Głównym założeniem jest istnienie matematycznie powiązanej pary kluczy: prywatnego, przechowywanego w tajemnicy i służącego do wygenerowania podpisu, oraz publicznego, który służy do jego sprawdzenia i jest ogólnodostępny, na przykład w publicznych repozytoriach. Gdy oprogramowanie klienta otrzymuje podpisany plik lub strumień danych, wykonuje dwie niezależne operacje przetwarzania. Po pierwsze, dedykowany algorytm deszyfruje dołączony do pliku blok kryptogramu podpisu, używając do tego celu klucza publicznego nadawcy. Wynikiem tej operacji jest pierwotny skrót (hash) dokumentu, wygenerowany na stacji nadawcy w momencie jego podpisywania. Zastosowanie mają tu standardowe algorytmy takie jak RSA (Rivest-Shamir-Adleman) z odpowiednim schematem dopełniania bloku danych, na przykład PSS (Probabilistic Signature Scheme) lub nowsze algorytmy oparte na matematyce krzywych eliptycznych, jak ECDSA (Elliptic Curve Digital Signature Algorithm). Wymagają one precyzyjnych implementacji bibliotek matematycznych do obsługi dużych liczb pierwszych.

Po drugie, oprogramowanie lokalne samodzielnie oblicza skrót otrzymanego dokumentu bit po bicie, wykorzystując tę samą funkcję skrótu, której zadeklarowano użycie w nagłówku podpisu. Obecnie branżowym standardem są funkcje z rodziny SHA-2 (np. SHA-256, SHA-384, SHA-512) lub nowsze z rodziny SHA-3. Starsze funkcje jednokierunkowe, takie jak MD5 czy SHA-1, są zdeprecjonowane i wycofane z użycia przez instytuty standaryzujące z powodu udowodnionej matematycznej podatności na ataki kolizyjne, które teoretycznie pozwalają na wygenerowanie dwóch zupełnie różnych plików o tym samym, identycznym skrócie.

Ostatnim etapem procesu jest binarne porównanie obu uzyskanych wartości skrótów. Zgodność obliczonego skrótu ze skrótem odszyfrowanym z kryptogramu stanowi jednoznaczny matematyczny dowód, że plik zachował integralność i nie uległ żadnej, nawet najmniejszej modyfikacji na poziomie pojedynczego bitu danych od momentu podpisania. Dodatkowo, poprawne, bezbłędne odszyfrowanie struktury kluczem publicznym potwierdza autentyczność pochodzenia pliku, gdyż tylko i wyłącznie posiadacz odpowiadającego mu klucza prywatnego mógł ten kryptogram prawidłowo wygenerować.

Architektura infrastruktury klucza publicznego (PKI) w systemach klienckich

Samo matematyczne potwierdzenie zgodności skrótów pliku nie jest w żadnym wypadku wystarczające do uznania dokumentu elektronicznego za wiarygodny w obrocie prawnym lub biznesowym. System weryfikujący musi mieć pewność, że klucz publiczny użyty do weryfikacji faktycznie należy do konkretnego podmiotu lub obywatela wskazanego w strukturze dokumentu. Realizuje to globalna Infrastruktura Klucza Publicznego (PKI). Klucz publiczny jest w niej dystrybuowany w formie certyfikatu cyfrowego, sformatowanego najczęściej zgodnie ze standardem X.509 (np. v3). Dokument ten zawiera zakodowane dane właściciela, zakres dozwolonych zastosowań klucza (Key Usage) oraz sam jest podpisany kluczem nadrzędnym przez zaufany Urząd Certyfikacji (CA).

Podczas sprawdzania podpisu, system operacyjny klienta, biblioteka kryptograficzna lub dedykowana aplikacja parsująca (np. przeglądarka plików PDF obsługująca standardy ISO 32000) buduje i analizuje łańcuch zaufania (certificate chain). Proces ten polega na iteracyjnej weryfikacji certyfikatu podpisującego dokument za pomocą certyfikatu pośredniego CA, a następnie za pomocą głównego certyfikatu, tak zwanego Root CA. Certyfikaty główne są preinstalowane na poziomie systemu operacyjnego w wydzielonych bezpiecznych magazynach certyfikatów systemów Windows, w pękach kluczy środowiska macOS czy w niezależnych repozytoriach przeglądarek internetowych. Brak odpowiedniego certyfikatu Root CA w lokalnym systemie nieodwracalnie przerywa proces weryfikacji z błędem braku ścieżki zaufania, traktując plik jako potencjalnie niebezpieczny.

Elementem architektury o krytycznym znaczeniu jest dynamiczne sprawdzenie statusu odwołania certyfikatu w momencie składania podpisu. Operacja ta odbywa się w warstwie sieciowej z wykorzystaniem zapytań o listy unieważnionych certyfikatów (CRL) lub poprzez asynchroniczny protokół OCSP (Online Certificate Status Protocol). Oprogramowanie łączy się po protokole HTTP/HTTPS z dedykowanymi serwerami urzędu certyfikacji, aby jednoznacznie potwierdzić, że w danej sekundzie czasu UTC klucz prywatny nadawcy nie widniał w rejestrach jako zgubiony, skradziony lub skompromitowany.

Ze względu na to, że certyfikaty klucza publicznego mają z góry określony czas ważności (zazwyczaj od jednego roku do maksymalnie trzech lat), pliki wymagające wieloletniej, długoterminowej archiwizacji wprowadzają mechanizmy formatów zaawansowanych takich jak PAdES (PDF Advanced Electronic Signatures) czy XAdES (XML Advanced Electronic Signatures). Formaty te, zgodnie ze standardami ETSI, pozwalają na osadzanie bezpośrednio w pliku niezależnych znaczników czasu (Time-Stamps) pobieranych z zewnętrznych, zaufanych serwerów czasu (TSA) zgodnych z protokołem RFC 3161. Kryptograficzny znacznik czasu to cyfrowy dowód istnienia konkretnego ciągu danych w danym, precyzyjnym punkcie na osi czasu. Weryfikator na stacji roboczej sprawdza, czy sam podpis został złożony przed upływem daty ważności certyfikatu podpisującego, co pozwala oprogramowaniu na pomyślną walidację kryptograficzną dokumentu nawet po całkowitym wygaśnięciu ważności klucza asymetrycznego, którym pierwotnie posłużył się nadawca.

Trudności sprzętowe i programowe procesów uwierzytelniania

Błędy występujące podczas prób sprawdzenia poprawności oraz autentyczności dokumentów na stacjach roboczych wynikają z kilku oddzielnych kategorii czynników, obejmujących środowisko sieciowe, systemowe oraz lokalną konfigurację stacji roboczej. Najczęstszym problemem leżącym na poziomie samego oprogramowania operacyjnego jest stopniowa dezaktualizacja systemowego magazynu certyfikatów zaufanych. Instalacje systemów z rodziny Windows pozbawione z różnych powodów dostępu do centralnej usługi Windows Update mogą po pewnym czasie nie dysponować nowymi kluczami głównymi wprowadzonymi przez globalne instytucje certyfikujące, co bezpośrednio skutkuje oznaczaniem poprawnie podpisanych plików zewnętrznych jako całkowicie niewiarygodnych. System operacyjny interpretuje wówczas prawidłowy ciąg kryptograficzny jako wystawiony przez nieznany podmiot.

Kolejna specyficzna grupa problemów technicznych dotyczy oprogramowania pośredniczącego (middleware), które jest niezbędne do obsługi krajowych podpisów kwalifikowanych na komputerach klienckich. Wprawdzie z teoretycznego punktu widzenia sama operacja weryfikacji podpisu opiera się wyłącznie na kluczach publicznych niewymagających obecności tokena sprzętowego w porcie klienta, proces ten w skomplikowanych środowiskach biznesowych często zachodzi w złożonych aplikacjach klienckich współdzielących w pamięci RAM te same biblioteki kryptograficzne (np. pliki współdzielone DLL implementujące branżowy standard PKCS#11 lub zaawansowane interfejsy Cryptography API: Next Generation (CNG) oraz Key Storage Providers (KSP) w systemach Windows). Przypadkowe konflikty wersji tych bibliotek współdzielonych, czy instalacja wielu nakładających się na siebie aplikacji od różnych dostawców podpisów elektronicznych na jednym systemie plików, często prowadzą do poważnych błędów alokacji pamięci lub całkowitego zawieszania się procesów systemowych w momencie parsowania struktury drzewiastej ASN.1 osadzonych certyfikatów.

Patrząc z punktu widzenia ewolucji interfejsów sprzętowych autoryzacji, należy odnotować kwestię urządzeń peryferyjnych starszej generacji. Historycznie, operacje kryptograficzne w rozproszonych systemach lokalnych w dużej mierze opierały się na dedykowanych czytnikach kart podłączanych przez asynchroniczne porty szeregowe RS-232, a w starszych modelach laptopów poprzez złącza standardu PCMCIA i ExpressCard. W bardzo starym sprzęcie komputerowym weryfikacja plików często wymagała sprzętowej obecności nośnika w czytniku w celu fizycznego dostępu do zablokowanych certyfikatów pośrednich. Obecnie zgłoszenia do serwisów dotyczące problemów komunikacyjnych z takimi archaicznymi interfejsami są już rzadkością w branży, ponieważ cały konsumencki rynek IT bezpowrotnie przeszedł na urządzenia bazujące na uniwersalnej magistrali USB oraz bezstykowe interfejsy zbliżeniowe zgodne z technologią NFC. W utrzymywanych z konieczności starych, 32-bitowych systemach operacyjnych brak cyfrowo podpisanych sterowników dla obecnie produkowanych tokenów sprzętowych całkowicie paraliżuje działanie współczesnych, lokalnych aplikacji e-urzędu oraz platform bankowych.

Usterki czytników kryptograficznych i modułów zabezpieczeń w diagnozie warsztatowej

Choć zjawisko sprawdzenia poprawności matematycznej plików kojarzy się użytkownikom z zagadnieniem czysto programowym, niejednokrotnie docelowa usterka uniemożliwiająca ten proces leży bezpośrednio w fizycznej warstwie sprzętowej stacji roboczej klienta. Złożone aplikacje księgowe i zintegrowane systemy prawnicze często uzależniają poprawne działanie swoich wewnętrznych modułów weryfikacyjnych od ogólnej spójności oraz stabilności całego sprzętowego środowiska wykonawczego. Uszkodzenia mechaniczne zewnętrznych portów USB lub zwarcie linii przesyłu danych (D+ / D-) uniemożliwiają dwukierunkową komunikację z tokenami kryptograficznymi, co automatycznie blokuje start powiązanych usług systemowych próbujących odczytać struktury danych. Warszawskie Pogotowie Komputerowe rutynowo diagnozuje tego typu awarie warstwy fizycznej poprzez pomiary rezystancji interfejsów bezpośrednio na płytach głównych i precyzyjne wlutowywanie nowych gniazd komunikacyjnych w miejsce wyeksploatowanych złączy.

Współczesne laptopy zaliczane do klasy biznesowej wyposażone są często w zintegrowane wewnętrzne czytniki kart inteligentnych (Smart Card). Urządzenia te komunikują się z kontrolerem mostka południowego płyty głównej po wewnętrznej magistrali USB lub w nowszych rozwiązaniach za pomocą linii PCIe. Mechaniczne uszkodzenia sprężystych styków wewnątrz samego slotu czytnika na skutek jego intensywnej, codziennej eksploatacji powodują stany nieustalone oraz zwarcia sygnałowe. Usterki te destabilizują działanie sterowników kontrolera w jądrze systemu, wywołując krytyczne błędy znane jako Blue Screen of Death (BSOD) w trakcie każdej próby wywołania przez użytkownika dowolnej funkcji kryptograficznej z poziomu oprogramowania. Warsztatowa naprawa sprzętowa tego modułu polega zazwyczaj na głębokim demontażu elementów obudowy laptopa i wymianie elastycznej taśmy sygnałowej wraz z całym zamkniętym czytnikiem.

Ważnym fizycznym komponentem mającym kluczowy wpływ na zaawansowane operacje weryfikacji i szyfrowania jest dedykowany układ scalony TPM (Trusted Platform Module). Sprzętowe moduły szyfrujące, bezpośrednio wlutowane w strukturę laminatu płyty głównej lub na stałe zintegrowane z logiką głównego procesora (w wariantach fTPM/PTT), przechowują i chronią klucze asymetryczne używane przez system do rutynowego utrzymania sprzętowej integralności samego środowiska OS. W rzadkich przypadkach uszkodzenia komórek wewnętrznej pamięci flash należącej do układu TPM, systemowy podsystem kryptograficzny Windows bez przerwy zgłasza błędy inicjalizacji podzespołu. Sprzętowa diagnoza serwisowa w tego typu scenariuszach obejmuje procedurę programowania i aktualizacji mikrokodu oprogramowania układowego BIOS/UEFI, czyszczenie logicznego stanu struktury TPM, a w przypadku potwierdzenia trwałych, nienaprawialnych uszkodzeń elektronicznych krzemu - fizyczne przelutowanie układu lub przeinstalowanie systemu w konfiguracji wykluczającej sprzętową integrację modułu.