Jak podpis cyfrowy dowodzi, kto go złożył

SpecSpec: RFC 5652RFC 5652SpecSpec: RFC 5280, §6RFC 5280 §6SpecSpec: RFC 3161, §1RFC 3161 §1

W skrócie

Podpis cyfrowy robi trzy rzeczy i warto je rozdzielić od samego początku: dowodzi, że bajty nie zostały zmienione, dowodzi, kto je podpisał, oraz — z niewielką pomocą — dowodzi kiedy. Ta strona buduje tę ideę od zera, tak by kryptografia przestała być czarną skrzynką.

Dlaczego to ma znaczenie

„Podpisane” to słowo, na którym ludzie opierają decyzje. Umowa, faktura, nota o wydaniu oprogramowania, które ktoś uruchomi. Jeśli wiesz tylko, że narzędzie wyświetliło zielony znacznik wyboru, to w istocie nie wiesz, co zostało udowodnione. Możesz mieć dowód, że bajty są nienaruszone, ale nie wiedzieć, czyj klucz je podpisał. Możesz mieć prawdziwego podpisującego, lecz certyfikat, który wygasł przed laty. Zrozumienie elementów składowych jest tym, co pozwala powiedzieć precyzyjnie, co oznacza prawidłowy podpis — i, równie użytecznie, czego nie oznacza.

Wersja skrócona

Wyobraź sobie zaklejoną kopertę z widocznym śladem naruszenia, z osobistą pieczęcią odciśniętą w klapie.

• Pieczęć jest unikalna dla jednej osoby i praktycznie niemożliwa do podrobienia. Każdy potrafi ją rozpoznać; tylko jej właściciel potrafi ją wykonać. To jest para kluczy: klucz prywatny, który masz tylko Ty, oraz klucz publiczny, który każdy może zobaczyć.
• Nie odciskasz pieczęci na całym dokumencie. Odciskasz ją na maleńkim, niemożliwym do podrobienia streszczeniu dokumentu — na skrócie. Zmień jeden bajt dokumentu, a streszczenie zmieni się całkowicie, więc pieczęć przestanie pasować.
• Podpisywanie to wytworzenie podpisu nad dokumentem za pomocą Twojego klucza prywatnego — nad skrótem w przypadku RSA i ECDSA albo nad samą treścią w przypadku EdDSA, które skrót wykonuje samo w środku. Weryfikowanie to przeprowadzenie kontroli algorytmu za pomocą Twojego klucza publicznego, podpisu i tej samej treści (jako skrótu lub bezpośrednio) — zwraca wynik prawidłowy lub nieprawidłowy. To matematyka, a nie zaufanie, łączy te dwa elementy.
• Certyfikat to część, która mówi, czyja to pieczęć. Bez niego masz dowód, że jakiś klucz podpisał bajty, ale nie to, że klucz należy do kogoś konkretnego.
• Znacznik czasu to część, która mówi kiedy. Własny zegar podpisującego to tylko twierdzenie; zaufany czas pochodzi od zewnętrznego urzędu.

Jak podchodzi do tego NextPDF

Zacznij od skrótu, bo wszystko inne na nim stoi. Kryptograficzna funkcja skrótu czyta dowolną ilość danych i tworzy krótki odcisk palca o stałej długości — dla podpisu PDF zwykle wartość 256-bitową. Użyteczność dają jej dwie właściwości: to samo wejście zawsze daje ten sam odcisk palca, a znalezienie innego wejścia o tym samym odcisku jest niewykonalne. Skrót jest więc wiernym substytutem dokumentu. Jeśli dwa skróty się zgadzają, bajty się zgadzają.

Teraz para kluczy. Klucz prywatny i klucz publiczny są matematycznie powiązane, ale w żadnym praktycznym czasie nie da się jednego wyprowadzić z drugiego. Tylko klucz prywatny może wytworzyć prawidłowy podpis, a tylko pasujący klucz publiczny może go sprawdzić. Podpisywanie wykorzystuje tę asymetrię: podpisujący stosuje operację z kluczem prywatnym do wejścia, które definiuje wybrany algorytm — skrótu treści dla RSA i ECDSA albo samej treści dla EdDSA, które skrót wykonuje wewnętrznie. Wynikiem jest wartość podpisu. Ponieważ wytworzyć ją mógł tylko posiadacz klucza prywatnego i ponieważ jest związana z tą treścią, dowodzi dwóch rzeczy naraz — że posiadacz podpisał i że bajty nie zmieniły się od tej chwili.

Weryfikacja odzwierciedla tę logikę. Weryfikator rekonstruuje to samo wejście — wykonując skrót dokumentu dla RSA i ECDSA albo biorąc treść bezpośrednio dla EdDSA — a następnie przeprowadza operację weryfikacji algorytmu podpisu na kluczu publicznym, wartości podpisu i tym wejściu. Operacja zwraca wynik prawidłowy lub nieprawidłowy — i jest to ten sam kształt niezależnie od tego, czy algorytmem jest RSA, ECDSA, czy EdDSA, choć tylko RSA da się przedstawić jako dosłowne „odzyskiwanie” skrótu. Prawidłowy oznacza nienaruszony i autentyczny. Nieprawidłowy oznacza, że coś się zmieniło albo użyto niewłaściwego klucza, a uczciwą odpowiedzią jest nieprawidłowy.

1. Prepare the inputRSA and ECDSA hash the document to a short, fixed-length fingerprint; EdDSA signs the content directly and hashes it internally. Either way, any change to the bytes changes what is signed.
2. Sign with the private keyThe signer applies a private-key operation to that input — the hash for RSA and ECDSA, the content for EdDSA. The output is the signature value; only the private-key holder could have produced it.
3. Reconstruct the inputThe verifier independently rebuilds the same input from the content — a recomputed hash for RSA and ECDSA, the content itself for EdDSA. This is what the verify operation checks against.
4. Verify with the public keyThe verifier runs the algorithm's verify operation on the public key, the signature value, and that input. The same shape works for RSA, ECDSA, and EdDSA.
5. Accept or rejectThe verify operation returns valid or invalid. Valid means the bytes are intact and the private-key holder signed them. Otherwise the result is invalid — no guessing.

How a digital signature is produced and then checked, from first principles. The signer produces a signature over the content with their private key — over a hash for RSA and ECDSA, or over the content directly for EdDSA; the verifier reconstructs the same input, then runs the algorithm's verify operation on the public key, the signature, and that input. A valid result proves the bytes are intact and that the private-key holder signed them.

W prawdziwym PDF NextPDF nie odciska pieczęci na widocznej stronie — odciska ją na zadeklarowanym zakresie bajtów i pakuje podpis jako odłączony obiekt CMS (SpecSpec: RFC 5652RFC 5652) umieszczony wewnątrz pliku (SpecSpec: ISO 32000-2, §12.8ISO 32000-2 §12.8). Jedno doprecyzowanie ma znaczenie: podpisujący nie podpisuje surowego skrótu treści bezpośrednio. Podpisuje mały zestaw atrybutów podpisanych, które zawierają skrót treści, dzięki czemu czas, typ treści oraz identyfikator certyfikatu podpisującego są zapieczętowane razem. Gdzie te bajty się znajdują i dlaczego zakres ma taki kształt, jest tematem Jak podpisy umieszczane są w PDF.

Jak dotąd matematyka dowodzi, że jakiś klucz podpisał te bajty. Nie mówi nic o tym, czyj to klucz. Tę lukę wypełnia dokładnie certyfikat. Certyfikat sam jest podpisanym oświadczeniem — od urzędu certyfikacji — że ten klucz publiczny należy do tego nazwanego podmiotu. Zaufanie do niego oznacza podążanie łańcuchem od certyfikatu podpisującego aż do urzędu, któremu postanowiłeś ufać, sprawdzając po drodze ważność każdego ogniwa (SpecSpec: RFC 5280, §6RFC 5280 §6). Bez tego łańcucha „podpisane” jest anonimowe. Z nim „podpisane” ma nazwisko.

Ostatnim elementem jest kiedy. Podpis może osadzić własny zadeklarowany czas podpisującego, lecz zegar, którego nie kontrolujesz, to twierdzenie, a nie dowód. Znacznik czasu z urzędu znacznika czasu (Time-Stamp Authority) wiąże skrót podpisu z chwilą, poświadczoną przez stronę, która nie ma interesu w dokumencie (SpecSpec: RFC 3161, §1RFC 3161 §1). To właśnie pozwala podpisowi pozostać znaczącym po wygaśnięciu certyfikatu podpisującego: możesz wykazać, że podpis istniał, gdy certyfikat był jeszcze ważny. Głębsze ujęcie znajduje się w Znaczniki czasu i zaufany czas.

Praktyczny przykład

Kształty poniżej to operacje koncepcyjne, zapisane wprost. Chodzi nie o wywołanie API — chodzi o zobaczenie, że podpisz i zweryfikuj są swoimi lustrzanymi odbiciami i że naruszony bajt z konstrukcji psuje dopasowanie.

<?php

declare(strict_types=1);

// SIGN — the holder of the private key seals the content.
// RSA and ECDSA sign a hash; EdDSA signs the content directly (hashing inside).
$signingInput = sign_input($content);            // a digest for RSA/ECDSA, the content for EdDSA
$signatureValue = private_key_transform(         // only the key holder can do this
    privateKey: $signerPrivateKey,
    input: $signingInput,
);

// VERIFY — anyone with the public key runs the algorithm's check.
$recomputedInput = sign_input($content);          // verifier rebuilds the same input
$intactAndAuthentic = signature_verify(           // RSA, ECDSA, EdDSA — same shape
    publicKey: $signerPublicKey,                  // taken from the certificate
    signatureValue: $signatureValue,
    input: $recomputedInput,                       // the freshly reconstructed input
);
// true  -> bytes unchanged AND signed by the private-key holder
// false -> a byte changed, or the wrong key — the honest answer is "invalid"

// The certificate answers a SEPARATE question: whose public key is this?
// The timestamp answers ANOTHER: when did this signature exist?
// "intact + authentic" alone proves neither identity nor time.

Sfałszowanie zmiany, która nadal się zweryfikuje, jest obliczeniowo niewykonalne. Skrót wiernie niesie treść, więc zmiana treści zmienia skrót, a operacja weryfikacji ją odrzuca — poza znalezieniem kolizji skrótu, którą wybrana funkcja jest zaprojektowana tak, by uczynić niepraktyczną.

Częste nieporozumienie

Częstym błędem jest odczytywanie „prawidłowego podpisu” jako „godnego zaufania dokumentu”. To nie jest to samo zdanie. Kryptografia dowodzi, że bajty są nienaruszone i że podpisał je posiadacz klucza prywatnego — i nic więcej. Dokument podpisany kluczem, o którym nigdy nie słyszałeś, poświadczony przez żaden urząd, który rozpoznajesz, może być nieskazitelnie „prawidłowy” i nic niewart. Tożsamość pochodzi z certyfikatu i jego łańcucha; czas pochodzi z zaufanego znacznika czasu. Zielony znacznik wyboru, który po cichu zwija to wszystko w jedną wartość logiczną, zdecydował za Ciebie, które pytania miały znaczenie. Znajomość elementów składowych jest tym, co pozwala zadać resztę.

Human-factors note:Human-factors note

Powodem, by rozdzielać te idee, nie jest pedanteria — chodzi o to, by słowo „podpisane” pozostało uczciwe. Integralność, tożsamość i czas to trzy odrębne dowody, ustanawiane trzema odrębnymi mechanizmami (skrótem wraz z parą kluczy, łańcuchem certyfikatów oraz urzędem znacznika czasu). Narzędzie, które raportuje je jako jedną flagę, jest łatwiejsze do odczytania i znacznie łatwiejsze do błędnego odczytania. NextPDF utrzymuje je rozdzielone, w swoim wyjściu i w swoich testach, dzięki czemu wynik mówiący „prawidłowy” można rozłożyć na dokładnie to, co zostało udowodnione.

Ograniczenia i granice

Ta strona wyjaśnia ideę podpisu cyfrowego, a nie pełną procedurę walidacji. Matematyka tutaj dowodzi integralności i autentyczności. Nie mówi sama z siebie, czy certyfikat podpisujący wydano temu, kogo masz na myśli, czy był ważny w chwili podpisywania, ani czy został później unieważniony — to pytania o ścieżkę certyfikacji i unieważnienie, a poprawna walidacja przeprowadza je wszystkie. Pełny zestaw kontroli znajduje się w Walidacja podpisu we właściwy sposób.

NextPDF buduje strukturę podpisu i przeprowadza kontrole kryptograficzne. Nie wybiera Twoich kotwic zaufania, nie ręczy za żaden urząd certyfikacji ani nie rozstrzyga o skutku prawnym podpisu — to zależy od Twojego wdrożenia, certyfikatu i jurysdykcji. Silnik dowodzi mechanizmu; decyzje o zaufaniu nałożone na niego należą do Ciebie.

To, co silnik dostarcza według poziomu, buduje się na zewnątrz od tego fundamentu:

Digital signature: integrity, identity, and trusted time — edition availability

Edition	Availability
Core	○ PAdES B-B: opisany tutaj mechanizm skrótu-i-podpisu, zapakowany jako odłączony obiekt CMS SignedData, plus walidacja ścieżki certyfikacji względem dostarczonej przez Ciebie kotwicy zaufania.
Pro	○ Dodaje PAdES B-T — zweryfikowany zaufany znacznik czasu RFC 3161 na wartości podpisu, dzięki czemu „kiedy” jest poświadczone, a nie deklarowane samodzielnie.
Enterprise	○ Dodaje profile długoterminowe (B-LT, B-LTA): osadzony materiał walidacyjny oraz znaczniki czasu dokumentu, które utrzymują dowody tożsamości i czasu możliwymi do odpowiedzenia przez lata.

Powiązane dokumenty

• Jak podpisy umieszczane są w PDF — gdzie wartość podpisu i jego zakres bajtów faktycznie znajdują się w pliku.
• Walidacja podpisu we właściwy sposób — pełny zestaw kontroli, które weryfikator musi przeprowadzić, poza matematyką z tej strony.
• Znaczniki czasu i zaufany czas — co dowodzi znacznik czasu RFC 3161 i dlaczego własny zegar podpisującego nim nie jest.
• Profile bazowe PAdES — który profil nakłada tożsamość, czas i materiał długoterminowy na ten fundament.

Słowniczek

• Skrót (digest) — krótki odcisk palca danych o stałej długości z kryptograficznej funkcji skrótu; każda zmiana danych zmienia go całkowicie.
• Para kluczy — powiązany klucz prywatny (trzymany wyłącznie przez podpisującego) i klucz publiczny (udostępniany swobodnie); tylko klucz prywatny może podpisać, a tylko pasujący klucz publiczny może zweryfikować.
• Podpisywanie — zastosowanie operacji z kluczem prywatnym do wejścia, które definiuje algorytm: skrótu treści dla RSA i ECDSA albo samej treści dla EdDSA (które skrót wykonuje wewnętrznie). W PDF tą treścią są atrybuty podpisane, które zawierają skrót dokumentu. Wynikiem jest wartość podpisu.
• Weryfikowanie — rekonstrukcja tego samego wejścia (przeliczonego skrótu albo treści bezpośrednio dla EdDSA), a następnie przeprowadzenie operacji weryfikacji algorytmu na kluczu publicznym, wartości podpisu i tym wejściu, aby uzyskać odpowiedź prawidłowy-lub-nieprawidłowy.
• Wartość podpisu — bajty, które wytwarza operacja z kluczem prywatnym; to, co weryfikator sprawdza względem świeżo zrekonstruowanego wejścia algorytmu (skrótu dla RSA i ECDSA, samej treści dla EdDSA).
• Certyfikat — podpisane oświadczenie wiążące klucz publiczny z nazwaną tożsamością; zaufane przez połączenie łańcuchem z urzędem, który akceptujesz (RFC 5280 §6).
• Kotwica zaufania — urząd certyfikacji, któremu postanowiłeś ufać; korzeń akceptowalnego łańcucha certyfikatów.
• Znacznik czasu (RFC 3161) — podpisany token z urzędu znacznika czasu (Time-Stamp Authority) wiążący skrót z wartością czasu, dający zaufany dowód kiedy.
• CMS SignedData — struktura Cryptographic Message Syntax (RFC 5652), która niesie wartość podpisu i certyfikat podpisującego.
• PAdES — PDF Advanced Electronic Signatures: rodzina profili ETSI do podpisywania PDF. Omówiona szczegółowo na stronach o podpisywaniu.