TSP (Time Stamp Protocol)
ITpedia
W roku 2001 IETF opublikowało standard protokołu oznaczania czasem TSP (Time Stamp Protocol) - RFC 3161. Zdefiniowano w nim również format zapytania przesyłanego do urzędu znacznika czasu TSA (Time Stamping Authority). Zaleta mechanizmu oznaczania czasem polega na tym, że dokumenty nigdy nie opuszczają komputera klienta i nie są przesyłane w formie jawnej. Do serwera TSA jest przesyłany jedynie skrót kryptograficzny oznaczanego pliku lub jego podpis cyfrowy, który już zawiera ten skrót. Wartość funkcji skrótu może być wyliczana przez użytkownika samodzielnie (np. w OpenSSL, z użyciem funkcji PHP „SHA1” itp.) lub za pomocą dostarczonego programu klienckiego TSA (przykład tworzenia funkcji skrótu, zapytań do TSA i weryfikacji znaczników w OpenSSL - http://www.signet.pl/instrukcje/tsa_openssl.pdf).
Zgodnie ze specyfikacją techniczną, opublikowaną przez ETSI (TS 101 861) także w 2001 r., urząd znacznika czasu powinien zapewniać obsługę algorytmów haszujących (hash algorithm): SHA-1 (Secure Hash Algorithm), RIPEMD-160 i MD5 (Message Digest 5 Algorithm), z czego zalecane jest używanie dwóch pierwszych. Nie zaleca się algorytmu MD5, ponieważ w 1996 r. stwierdzono jego kolizyjność. Wymienione funkcje, zwane również jednokierunkową funkcją skrótu, wyliczają skrót kryptograficzny pliku binarnego (np. dokumentu lub podpisu elektronicznego), tworząc tzw. Unikalny odcisk palca (fingerprint). W przyszłości powinna być dodana także obsługa algorytmów SHA-256 i SHA-512. Jednokierunkowe funkcje haszujące zapewniają integralność oznaczanych danych. Dodatkową zaletą jest fakt, że skrót dowolnego pliku ma stałą długość, tj. 16 bajtów (MD5) lub 20 bajtów (SHA-1 oraz RIPEMD-160). Aby było możliwe wyliczenie funkcji skrótu SHA-1, wartość pliku nie może przekraczać 264 bitów, czyli 4 x 109 GB.
Następnie jest tworzone odpowiednio sformatowane żądanie znacznika czasu TSQ (Time Stamp Request), zawierające numer wersji TSQ, rodzaj zastosowanej funkcji skrótu oraz otrzymaną wartość w postaci ciągu bitów, którego długość musi być zgodna z zastosowanym algorytmem haszującym. TSQ może zawierać również liczbę losową, numer polityki, zgodnie z którą ma być wystawiona odpowiedź, oraz żądanie dołączenia do niej klucza publicznego TSA.
Tak utworzone żądanie jest przesyłane do wskazanego TSA. Według standardu TSA powinien zapewniać co najmniej obsługę Time Stamp Protocol przez HTTP. Dobrze, gdy możliwe są również inne sposoby komunikacji, np. na poziomie SSL, TCP, FTP czy e-maila.
Po otrzymaniu zgłoszenia serwer TSA sprawdza, czy jego format jest poprawny. Jeżeli weryfikacja przebiegła pozytywnie, TSA pobiera aktualną wartość czasu z zaufanego śródła czasu i generuje znacznik czasu (token) dla danego obiektu. Do klienta jest zwracana podpisana wiadomość w postaci paczki CMS (Cryptographic Message Syntax). Jej format jest zgodny ze standardem PKCS#7 (Public-Key Cryptography Standards) - RFC 2630, zaproponowanym przez RSA Labs. Zawiera ona informację o realizacji żądania TSQ. Może też informować, czy znacznik czasu został: przyznany, przyznany z modyfikacjami, odrzucony, oczekuje na realizację, niedługo nastąpi jego unieważnienie lub już nastąpiło (np. z powodu utraty ważności certyfikatu wystawcy). Token znacznika czasu zawiera unikatowy identyfikator, wartość czasu oznaczenia, dopuszczalny błąd czasu, numer seryjny, wartość funkcji skrótu oznaczanego dokumentu, nazwę TSA oraz numer polityki certyfikacji, zgodnie z którą został wystawiony. Czas wykorzystywany do oznaczania nie może różnić się od wzorcowego źródła czasu o więcej niż 1 s.
Token jest podpisywany przy użyciu klucza prywatnego TSA, wygenerowanego specjalnie dla usługi znakowania czasem. Klucze te muszą być przechowywane z zachowaniem najsurowszych zasad bezpieczeństwa. Ich kompromitacja powoduje utratę ważności wystawianych znaczników. TSA może stosować odmienne klucze, w zależności od numeru polityki, stosowanych algorytmów lub oferty handlowej. Cała operacja jest rejestrowana w bazie danych i w każdej chwili użytkownik może z niej pobrać kopie wystawionych znaczników.
Weryfikacja znacznika czasu
Po otrzymaniu znacznika czasu, należy przeprowadzić jego weryfikację. Pomyślny jej wynik gwarantuje, że otrzymany znacznik dotyczy właściwego pliku, ma poprawny format, jest podpisany za pomocą ważnego klucza, zawarty w nim format daty jest poprawny, został wystawiony wg właściwej polityki i podczas transmisji nie nastąpiło przekłamanie. Jeżeli którykolwiek z wymienionych elementów jest błędny, taki znacznik należy odrzucić. Sprawdzenia można dokonać albo w programie klienckim TSA, albo przy użyciu ogólnie dostępnego oprogramowania (OpenSSL). Klient powinien także sprawdzać aktualność otrzymanej daty. Jeżeli dysponuje lokalnym zaufanym źródłem czasu, może porównać wartość otrzymaną w znaczniku z czasem bieżącym.
Aby ustrzec się przed opóźnieniami powodowanymi m.in. atakami typu man-in-the-middle, można umieszczać w zapytaniu TSQ wygenerowaną liczbę losową (nonce). Musi ona być na tyle duża, aby istniało wysokie prawdopodobieństwo, iż została wygenerowana tylko raz. Wartość nonce otrzymana w odpowiedzi musi być identyczna z wygenerowaną. Określając maksymalny czas odpowiedzi, należy uwzględnić opóźnienia związane ze stosowanymi metodami komunikacji.
Znacznik czasu ma skończony okres ważności, związany z czasem ważności certyfikatu, służącego do jego wystawienia. Przed utratą ważności danego znacznika należy uzyskać dla niego znacznik czasu poświadczony nowym certyfikatem, ważnym dłużej niż poprzedni. Tak wystawiony znacznik potwierdza istnienie w danym momencie znacznika czasu i jego podpisu elektronicznego.
Odpowiedzialność prawna
Ustawodawca polski dopuszcza znakowanie czasem. „Podpis elektroniczny może być znakowany czasem” - zgodnie z art. 7 Ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (DzU 2001 Nr 130, poz. 1450) - „Znakowanie czasem przez kwalifikowany podmiot świadczący usługi certyfikacyjne wywołuje w szczególności skutki prawne daty pewnej w rozumieniu przepisów kodeksu cywilnego”. Przepis ten informuje: „Uważa się, że podpis elektroniczny znakowany czasem przez kwalifikowany podmiot świadczący usługi certyfikacyjne został złożony nie później niż w chwili dokonywania tej usługi. Domniemanie to istnieje do dnia utraty ważności zaświadczenia certyfikacyjnego wykorzystywanego do weryfikacji tego znakowania. Przedłużenie istnienia domniemania wymaga kolejnego znakowania czasem podpisu elektronicznego wraz z danymi służącymi do poprzedniej weryfikacji przez kwalifikowany podmiot świadczący tę usługę”.
Podpis elektroniczny, podobnie jak własnoręczny, z momentem podpisania powinien być ważny prawnie na czas nieokreślony. Jednak z technicznego punktu widzenia podpis cyfrowy zawarty w certyfikacie służącym do weryfikacji podpisu elektronicznego ważny jest jedynie przez określony czas. Chcąc zapewnić niepodważalność podpisu, fakt podpisania należałoby rejestrować, np. w elektronicznym notariacie (Electronic Notary). Osoba weryfikująca podpis powinna sprawdzić jego istnienie na liście odwołanych certyfikatów CRL (Certificate Revocation List). Lista CRL w momencie sprawdzania dotyczy niestety stanu przeszłego. Aby zmniejszyć odstęp pomiędzy jego unieważnieniem a opublikowaniem w CRL, można wykorzystywać protokół OCSP (Online Certificate Status Protocol), sprawdzający na bieżąco status certyfikatu. Panaceum na powyższe mankamenty wydaje się znakowanie czasem. Pomimo że znacznik czasu jest usankcjonowany legislacyjnie, zgłaszane są argumenty, iż brak jest prawnych regulacji dotyczących funkcjonowania urzędów TSA, tzn. brak wyznaczonych wzorców czasu, polityki bezpieczeństwa itp.
