Bezpieczeństwo klucza

Przepisy wykonawcze do Ustawy o podpisie elektronicznym definiują pojęcie bezpiecznego urządzenia do składania podpisów elektronicznych, składającego się z aplikacji podpisującej (program) i komponentu technicznego (najczęściej karty elektronicznej). W przepisach tych wiele miejsca poświęcono warunkom, jakie musi spełniać komponent techniczny, tak aby klucz służący do składania bezpiecznych podpisów elektronicznych nie znalazł się w posiadaniu osoby nieupoważnionej.

Jednak cel, któremu służą te wymagania, nie może być celem samym w sobie. Istotne jest nie to, czy nieupoważniona osoba wejdzie w posiadanie klucza prywatnego, lecz czy będzie mogła posługiwać się tym kluczem, tj. składać bezpieczne podpisy elektroniczne w imieniu prawowitego właściciela certyfikatu. Przed tym niestety nie chroni nawet idealny komponent techniczny, doskonale spełniający wszystkie wymagania wynikające z przepisów.

W dyskusji o bezpieczeństwie procesu składania podpisów elektronicznych przyjmuje się często milczące założenie, że dopóki nieuprawniona osoba nie wejdzie w posiadanie klucza prywatnego służącego do składania podpisów, dopóty system jest bezpieczny. Dlatego wymagania nałożone w przepisach na komponenty techniczne zapewniają wystarczające bezpieczeństwo klucza. Niestety, to jest błędne założenie, że stąd wynika bezpieczeństwo całego systemu.

Jeśli komputer, przy użyciu którego jest wykonywany bezpieczny podpis elektroniczny, stanie się dostępny dla osoby nieuprawnionej (np. w wyniku zainstalowania na nim wirusa lub konia trojańskiego), bezpieczeństwo systemu staje się iluzoryczne i to niezależnie od jakości zastosowanego komponentu technicznego. Każdy taki komponent (bez względu na klasę zabezpieczeń) działa bowiem na zlecenie aplikacji podpisującej. Innymi słowy, jeśli dostanie zlecenie złożenia podpisu od aplikacji działającej na komputerze, to je wykona. Dopóki aplikacja jest prawidłowa i dane podpisywane nie zostały zmienione przy przekazywaniu od aplikacji do komponentu, dopóty system funkcjonuje prawidłowo. Jeśli jednak w wyniku nieuprawnionej ingerencji w komputerze dane są zmieniane przy przesyłaniu od aplikacji do komponentu lub aplikacja jest fałszywa (choć wygląda jak oryginalna), to może się okazać, że użytkownik podpisał zupełnie inny dokument, niż zamierzał, lub że zamiast jednego podpisu, wykonał kilka: jeden pod właściwym dokumentem, resztę pod dokumentami fałszywymi, przygotowanymi przez fałszywą aplikację.

Bezpieczeństwo procesu składania bezpiecznego podpisu elektronicznego w dużym stopniu zależy od bezpieczeństwa aplikacji podpisującej i środowiska programowego, w którym działa ta aplikacja. Jest to nawet ważniejsze niż jakość komponentu technicznego.

Niestety, zapewnienie bezpieczeństwa systemu jest zagadnieniem niezwykle trudnym, zwłaszcza w przypadku komputerów domowych, podłączonych do Internetu i pozbawionych opieki wykwalifikowanego administratora. Osobom wystawiającym w takich warunkach bezpieczne podpisy elektroniczne pozostaje akceptacja zwiększonego ryzyka.

Przepisy czy rzeczywistość

Można zadać pytanie, co jest przyczyną tych problemów: przyjęte w Polsce przepisy czy natura bezpiecznych podpisów elektronicznych? Dlaczego większość tego typu problemów dotychczas nie ujawniała się w systemach posługujących się zwykłymi podpisami elektronicznymi, funkcjonujących od wielu lat również w naszym kraju?

W przepisach należałoby poprawić dwie rzeczy. Po pierwsze, ustalić, że standardowa deklaracja świadczącą o tym, iż dany certyfikat jest kwalifikowany (QCStatement) ma być obowiązkowo umieszczana w certyfikatach kwalifikowanych. Dzięki temu aplikacje komputerowe mogłyby automatycznie rozpoznawać rodzaj certyfikatu, z którym mają do czynienia. Po drugie, należałoby ustalić okres wystawiania list CRL/ARL przez kwalifikowane podmioty na jedną godzinę, nawet gdyby nie wystąpiły zawieszenia lub unieważnienia certyfikatów. Znacząco skróciłoby to maksymalny czas oczekiwania na aktualna listę CRL/ARL.

Pozostałe problemy wynikają z natury zjawiska, jakim jest posiadanie przez użytkownika klucza kryptograficznego i certyfikatu zastępującego dowód tożsamości i będącego jedynym uwierzytelnieniem w systemach informatycznych. Między systemami posługującymi się zwykłymi podpisami elektronicznymi a systemami opartymi na podpisach bezpiecznych występuje zasadnicza różnica. Te pierwsze są z reguły systemami zamkniętymi. Ich użytkownicy otrzymują certyfikaty do ściśle określonych celów (np. home-bankingu). Zarówno użytkownicy, jak i cele są znane centrum certyfikacji kluczy. Centra certyfikacji często są ściśle związane z systemami przetwarzania informacji. Kontrolując zarówno centrum certyfikacji, jak i system przetwarzający informacje, można tak skonstruować procedury pracy od strony informatycznej i organizacyjnej, by uciążliwości i konieczne do poniesienia koszty związane z zapewnieniem odpowiedniego poziomu bezpieczeństwa były minimalne.

Systemy oparte na bezpiecznym podpisie elektronicznym pozwalają na automatyczne wykorzystywanie tych podpisów do wszystkich zastosowań. Podmiot wydający certyfikaty nie wie, w jakich systemach certyfikat będzie używany. System posługujący się certyfikatami nie ma wpływu na unieważnianie certyfikatów, a jedynymi dostępnymi mechanizmami odmowy dostępu do wykonywania operacji w systemie stają się listy CRL. Niestety, taki komfort musi być okupiony wyższymi wymaganiami bezpieczeństwa, w tym większą uciążliwością stosowanych procedur.

Jacek Pokraśniewicz jest prezesem i współzałożycielem firmy ENIGMA Systemy Ochrony Informacji. Artykuł powstał na podstawie referatu wygłoszonego przez autora podczas tegorocznej VII Krajowej Konferencji Zastosowań Kryptografii ENIGMA 2003.