Znaczniki czasu i zaufany czas

Spec Spec: RFC 3161 RFC 3161 Spec Spec: RFC 5816 RFC 5816 Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 Evidence § Standard-backed Evidence: Standard-backed

W skrócie

Znacznik czasu nie zapisuje informacji „kiedy to podpisano”. Potwierdza coś węższego i mocniejszego: że określony fragment danych istniał przed określoną chwilą, a poświadcza to strona niebędąca podpisującym. Na tym rozróżnieniu opiera się cała wartość zaufanego czasu, choć bywa ono często źle rozumiane.

Dlaczego to ma znaczenie

Czas podpisania zapisany w podpisie to po prostu wartość zadeklarowana przez komputer podpisującego. Zegar może wskazywać błędny czas, przypadkowo albo celowo. Jeśli jedynym dowodem na to, kiedy, jest własne oświadczenie podpisującego, podpisujący może dowolnie antydatować lub postdatować dokument. Podpis złożony certyfikatem unieważnionym wczoraj można przedstawić tak, jakby powstał w zeszłym roku. „Kiedy” to nie szczegół. Rozstrzyga, czy podpis złożony za pomocą wygasłego już lub unieważnionego certyfikatu nadal jest ważny. A jeśli zaufany czas jest błędny, każdy argument o długoterminowej ważności oparty na nim się załamuje.

Wersja skrócona

• Czas podpisania podany przez podpisującego to deklaracja, a nie dowód. Można go z łatwością sfałszować.
• Znacznik czasu RFC 3161 to podpisany token z urzędu znacznika czasu (TSA), wiążący skrót Twoich danych z czasem urzędu TSA.
• To, co potwierdza, jest precyzyjne: dane istniały przed czasem podanym przez urząd TSA. Nie dokładny moment utworzenia, lecz górną granicę.
• Token odzwierciedla nonce oraz odcisk wiadomości z żądania, więc nie może być powtórką ani odnosić się do innych danych.
• Znacznik czasu dokumentu stosuje ten sam mechanizm do całego pliku PDF, zakotwiczając wszystko, co znajduje się pod nim — podpis oraz osadzone w nim dowody walidacji — w zaufanej chwili.

Jak podchodzi do tego NextPDF

NextPDF traktuje znacznik czasu jako coś, co należy zweryfikować, a nie tylko uzyskać. Samo zażądanie tokenu to mniejsza część pracy. Stanowisko silnika jest jednoznaczne: niezweryfikowany token nie stanowi dowodu.

Gdy silnik dodaje znacznik czasu do podpisu, wysyła do urzędu TSA skrót danych oraz świeży losowy nonce, nigdy zaś same dane. Zwrócony token jest następnie sprawdzany pod kątem pełnego zestawu właściwości, które nadają mu znaczenie: status odpowiedzi urzędu to „granted”, nonce w tokenie zgadza się z wysłanym, odcisk wiadomości w tokenie zgadza się z wysłanym skrótem, podpis kryptograficzny samego tokenu przechodzi weryfikację, typ zawartości tokenu to typ znacznika czasu, a podany czas mieści się w dopuszczalnej tolerancji. Każda rozbieżność oznacza twardy błąd z typowaną przyczyną. Nie ma ścieżki „wygląda wystarczająco blisko”. Znacznik czasu dokumentu podlega tej samej regule, zastosowanej do całego pliku, a nie do wartości pojedynczego podpisu.

1. Hash the data Only a digest of the signature value (or the whole PDF, for a document timestamp) is computed — never the data itself.
2. Send hash + nonce The digest and a fresh random nonce go to the Time-Stamp Authority.
3. TSA returns a token A signed token binds the digest to the TSA’s genTime and echoes the nonce.
4. Verify the token Status granted, nonce matches, message imprint matches, token signature verifies, time within tolerance.
5. Conclude an upper bound The data provably existed before the TSA’s stated time — attested by a party that is not the signer.

Jak uzyskuje się zaufany znacznik czasu i co on potwierdza: do urzędu TSA wysyłany jest skrót wraz z nonce, urząd TSA zwraca podpisany token wiążący ten skrót ze swoim czasem, a weryfikator potwierdza to powiązanie, zanim potraktuje je jako dowód, że dane istniały przed tym czasem.

Co mówią dowody

Evidence § Standard-backed Evidence: Standard-backed Definicja jest precyzyjna. Spec Spec: ISO/IEC 18014-2, §3 ISO/IEC 18014-2 §3 definiuje usługę znacznika czasu jako taką, która dostarcza dowodu, że element danych istniał przed określonym punktem w czasie — górnej granicy, a nie momentu utworzenia. Spec Spec: ISO/IEC 18014-2, §7 ISO/IEC 18014-2 §7 definiuje strukturę TSTInfo tokenu: odcisk wiadomości (skrót danych objętych żądaniem), czas wygenerowania, numer seryjny oraz opcjonalny nonce. Spec Spec: ISO/IEC 18014-2, §6 ISO/IEC 18014-2 §6 określa wniosek, jaki weryfikator może wyciągnąć po pomyślnej weryfikacji: że element danych istniał przed czasem zapisanym w tokenie — nic więcej i nic mniej.

W formacie PDF Spec Spec: ISO 32000-2, §12.8.5 ISO 32000-2 §12.8.5 określa znacznik czasu dokumentu: zakres bajtów obejmuje cały plik z wyłączeniem wartości Contents, ten skrót jest wysyłany do urzędu znacznika czasu, a zwrócony token RFC 3161 — zaktualizowany przez Spec Spec: RFC 5816 RFC 5816 — jest umieszczany w Contents. To ta sama dyscyplina zakresu bajtów co w przypadku podpisu, tylko zastosowana do czasu zamiast do tożsamości. Z kolei Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 wyjaśnia, dlaczego ma to znaczenie dla trwałości: to właśnie zaufany czas pozwala walidatorowi udowodnić, że podpis był wiarygodny w dniu jego złożenia, nawet po wygaśnięciu certyfikatu.

Silnik NextPDF wysyła skrót i nonce, nigdy zaś same dane, po czym weryfikuje zwrócony token pod kątem statusu, nonce, odcisku wiadomości, podpisu tokenu, typu zawartości oraz tolerancji czasu, zanim potraktuje go jako dowód.

Human-factors note: Human-factors note

Strona zaczyna się od precyzyjnego stwierdzenia — znacznik czasu potwierdza, że dane istniały przed danym czasem, według strony trzeciej — ponieważ najczęstszym i najbardziej kosztownym błędem jest tutaj wyolbrzymianie go do „dowodu dokładnego momentu podpisania”. Podanie najpierw prawdziwego, węższego stwierdzenia to ostrzeżenie, które zapobiega nadużyciu, umieszczone przed opisem mechanizmu.

Przykład praktyczny

Tokenu znacznika czasu nie tworzy się ręcznie. Liczy się punkt styku z zaufaniem. Urząd TSA trzeba skonfigurować i chronić, ponieważ jego czas staje się Twoim dowodem.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// Asking for any level at or above B-T requires a TSA.
$level = SignatureLevel::PAdES_B_T;
$level->requiresTimestamp(); // true → a Time-Stamp Authority must be supplied

// The TSA endpoint, its transport security, and its trust anchor are
// deployment-supplied. The engine sends a hash plus a fresh nonce — never the
// document — and verifies the returned token before the signature is accepted.
// A token that fails any check (status, nonce, imprint, signature, time)
// is a hard error, not a warning.

Istotne jest tu to, że silnik wysyła skrót, a nie dokument, dzięki czemu urząd TSA nigdy nie widzi treści. Weryfikuje też odpowiedź. Urząd TSA, którego nie możesz uwierzytelnić, nie zapewnia zaufanego czasu. To tylko kolejny zegar.

Częste nieporozumienie

Pułapką jest odczytywanie znacznika czasu jako „to zostało podpisane dokładnie o 14:32 tego dnia”. Nie jest to stoper mierzący czynność podpisania. Potwierdza, że dane istniały nie później niż w czasie wskazanym przez urząd TSA, który stanowi górną granicę wyznaczoną przez stronę trzecią. Utworzenie mogło nastąpić w dowolnej chwili przed tym czasem. Drugą pułapką jest założenie, że dowolny serwer znaczników czasu zapewnia zaufany czas. Token, którego podpisu nie możesz zweryfikować albo który pochodzi od urzędu, któremu nie ufasz, niczego nie potwierdza. To zegar, któremu nie masz powodu wierzyć. Zaufany czas pochodzi od urzędu TSA, który możesz uwierzytelnić, oraz z tokenu, który zweryfikowałeś, a nie z samego faktu poproszenia serwera o liczbę.

Ograniczenia i granice

NextPDF buduje żądanie, wysyła wyłącznie skrót i weryfikuje zwrócony token. Nie ręczy za urząd, który za nim stoi. Dokładność urzędu TSA, ważność jego własnego certyfikatu oraz jego wiarygodność to właściwości usługi i konfiguracji Twojego wdrożenia, a nie silnika. Znacznik czasu wiąże skrót z czasem. Nie mówi nic o znaczeniu danych, tożsamości podpisującego ani o tym, czy certyfikat podpisującego był ważny. To osobne kontrole opisane w Prawidłowa walidacja podpisu. Silnik nie jest w stanie uczynić niewiarygodnego urzędu TSA wiarygodnym. Ta strona nie przypisuje też znacznikowi czasu żadnej konkretnej mocy prawnej; zależy ona od statusu urzędu TSA oraz od jurysdykcji. Sposób, w jaki zaufany czas jest ponownie wykorzystywany, aby utrzymać weryfikowalność podpisu przez dziesięciolecia, opisano w Walidacja długoterminowa.

Dostępność znakowania czasem w poszczególnych planach:

RFC 3161 timestamping (signature timestamp and document timestamp) — edition availability

Edition	Availability
Core	○ Not in this edition
Pro	○ PAdES B-T — zweryfikowany znacznik czasu RFC 3161 na wartości podpisu, względem urzędu TSA dostarczonego przez wdrożenie.
Enterprise	○ Dodaje znacznik czasu dokumentu używany przez B-LT oraz B-LTA do zakotwiczenia osadzonych dowodów walidacji oraz do napędzania pętli odnawiania archiwalnego.

Powiązana dokumentacja

• Walidacja długoterminowa — jak znacznik czasu dokumentu pieczętuje osadzone dowody i z czasem jest odnawiany.
• Profile bazowe PAdES — gdzie w sekwencji poziomów znajdują się znacznik czasu podpisu (B-T) oraz znacznik czasu dokumentu (B-LTA).
• Podpisy kwalifikowane, wyjaśnienie — jak kwalifikowany znacznik czasu wpisuje się w obraz zaufania eIDAS.

Słowniczek

• Znacznik czasu (RFC 3161) — podpisany token z urzędu TSA, wiążący skrót danych z czasem urzędu TSA i potwierdzający, że dane istniały przed tym czasem.
• Urząd znacznika czasu (TSA) — zaufana usługa, która wydaje tokeny znaczników czasu.
• TSTInfo — struktura zawartości tokenu: odcisk wiadomości, czas wygenerowania, numer seryjny oraz opcjonalny nonce.
• Odcisk wiadomości — skrót danych znakowanych czasem, odzwierciedlony w tokenie.
• Nonce — świeża wartość losowa wysyłana wraz z żądaniem i odzwierciedlona w tokenie, dzięki czemu odpowiedź nie może być powtórką.
• Znacznik czasu dokumentu — znacznik czasu RFC 3161 obejmujący cały plik PDF (zaktualizowany przez RFC 5816), zakotwiczający podpis i jego dowody w zaufanej chwili.