Wie eine digitale Signatur beweist, wer signiert hat

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

Auf einen Blick

Eine digitale Signatur tut drei Dinge, und es lohnt sich, sie von Anfang an auseinanderzuhalten: Sie beweist, dass die Bytes nicht verändert wurden, sie beweist, wer sie signiert hat, und – mit etwas Hilfe – sie beweist wann. Diese Seite baut diese Idee aus dem Nichts auf, sodass die Kryptografie aufhört, eine Blackbox zu sein.

Warum das wichtig ist

„Signiert“ ist ein Wort, auf das Menschen Entscheidungen stützen. Ein Vertrag, eine Rechnung, eine Release-Notiz für Software, die jemand ausführen wird. Wenn Sie nur wissen, dass ein Werkzeug ein grünes Häkchen gezeigt hat, wissen Sie nicht wirklich, was bewiesen wurde. Sie haben vielleicht einen Beweis, dass die Bytes intakt sind, aber keine Ahnung, wessen Schlüssel sie signiert hat. Sie haben vielleicht einen echten Unterzeichner, aber ein Zertifikat, das vor Jahren abgelaufen ist. Die Einzelteile zu verstehen ist es, was Sie präzise sagen lässt, was eine gültige Signatur bedeutet – und, ebenso nützlich, was sie nicht bedeutet.

Die Kurzfassung

Stellen Sie sich einen manipulationssicheren Umschlag mit einem in die Lasche gedrückten persönlichen Siegel vor.

• Das Siegel ist für eine Person einzigartig und faktisch unmöglich zu fälschen. Jeder kann es erkennen; nur sein Inhaber kann es erzeugen. Das ist das Schlüsselpaar: ein privater Schlüssel, den nur Sie halten, und ein öffentlicher Schlüssel, den jeder sehen kann.
• Sie drücken das Siegel nicht über das ganze Dokument. Sie drücken es über eine winzige, nicht fälschbare Zusammenfassung davon – einen Hash. Ändern Sie ein Byte des Dokuments, und die Zusammenfassung ändert sich vollständig, sodass das Siegel nicht mehr passt.
• Signieren bedeutet, mit Ihrem privaten Schlüssel eine Signatur über das Dokument zu erzeugen – über den Hash bei RSA und ECDSA oder über den Inhalt selbst bei EdDSA, das sein Hashing intern durchführt. Verifizieren bedeutet, die Prüfung des Algorithmus mit Ihrem öffentlichen Schlüssel, der Signatur und demselben Inhalt (als Hash oder direkt) auszuführen – sie ergibt gültig oder ungültig. Mathematik, nicht Vertrauen, verbindet die beiden.
• Ein Zertifikat ist der Teil, der sagt, wessen Siegel das ist. Ohne es haben Sie bewiesen, dass ein Schlüssel die Bytes signiert hat, aber nicht, dass der Schlüssel zu jemand Bestimmtem gehört.
• Ein Zeitstempel ist der Teil, der sagt, wann. Die eigene Uhr eines Unterzeichners ist nur eine Behauptung; vertrauenswürdige Zeit kommt von einer externen Stelle.

Wie NextPDF daran herangeht

Beginnen Sie mit dem Hash, denn alles andere steht darauf. Eine kryptografische Hashfunktion liest eine beliebige Datenmenge und erzeugt einen kurzen Fingerabdruck fester Länge – für eine PDF-Signatur typischerweise einen 256-Bit-Wert. Zwei Eigenschaften machen ihn nützlich: Dieselbe Eingabe ergibt stets denselben Fingerabdruck, und es ist nicht praktikabel, eine andere Eingabe mit demselben zu finden. Ein Hash ist also ein getreuer Stellvertreter für das Dokument. Stimmen zwei Hashes überein, stimmen die Bytes überein.

Nun das Schlüsselpaar. Ein privater und ein öffentlicher Schlüssel sind mathematisch verknüpft, aber Sie können den einen aus dem anderen in keiner praktikablen Zeitspanne ableiten. Nur der private Schlüssel kann eine gültige Signatur erzeugen, und nur der passende öffentliche Schlüssel kann sie prüfen. Das Signieren nutzt diese Asymmetrie: Der Unterzeichner wendet eine Privatschlüssel-Operation auf die Eingabe an, die der gewählte Algorithmus definiert – den Hash des Inhalts bei RSA und ECDSA oder den Inhalt direkt bei EdDSA, das intern hasht. Das Ergebnis ist der Signaturwert. Weil nur der Inhaber des privaten Schlüssels ihn hätte erzeugen können und weil er an diesen Inhalt gebunden ist, beweist er zwei Dinge auf einmal – der Inhaber hat signiert, und die Bytes haben sich seither nicht bewegt.

Die Verifikation spiegelt diese Logik. Der Verifizierer rekonstruiert dieselbe Eingabe – das Dokument hashen bei RSA und ECDSA oder den Inhalt direkt nehmen bei EdDSA – und führt dann die Verify-Operation des Signaturalgorithmus auf dem öffentlichen Schlüssel, dem Signaturwert und dieser Eingabe aus. Die Operation ergibt gültig oder ungültig – und das ist dieselbe Gestalt, ob der Algorithmus RSA, ECDSA oder EdDSA ist, auch wenn nur RSA so dargestellt werden kann, als „gewinne“ es den Hash buchstäblich zurück. Gültig bedeutet intakt und authentisch. Ungültig bedeutet, dass sich etwas geändert hat oder der falsche Schlüssel verwendet wurde, und die ehrliche Antwort ist ungültig.

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.

In einer echten PDF drückt NextPDF das Siegel nicht über die sichtbare Seite – es drückt es über einen deklarierten Bereich von Bytes und verpackt die Signatur als detached CMS-Objekt (SpecSpec: RFC 5652RFC 5652), das in der Datei platziert wird (SpecSpec: ISO 32000-2, §12.8ISO 32000-2 §12.8). Eine Verfeinerung ist wichtig: Der Unterzeichner signiert nicht den rohen Inhalts-Hash direkt. Er signiert einen kleinen Satz von signierten Attributen, die den Hash des Inhalts enthalten, sodass die Zeit, der Inhaltstyp und die Zertifikatskennung des Unterzeichners allesamt zusammen versiegelt werden. Wo diese Bytes liegen und warum der Bereich so geformt ist, wie er ist, ist Thema von Wie Signaturen in einem PDF liegen.

So weit beweist die Mathematik, dass ein Schlüssel diese Bytes signiert hat. Sie sagt nichts darüber, wessen Schlüssel. Genau diese Lücke füllt ein Zertifikat. Ein Zertifikat ist selbst eine signierte Aussage – von einer Zertifizierungsstelle –, dass dieser öffentliche Schlüssel zu diesem benannten Subjekt gehört. Ihm zu vertrauen bedeutet, der Kette vom Zertifikat des Unterzeichners bis zu einer Stelle zu folgen, der zu vertrauen Sie sich entschieden haben, und dabei die Gültigkeit jedes Glieds zu prüfen (SpecSpec: RFC 5280, §6RFC 5280 §6). Ohne diese Kette ist „signiert“ anonym. Mit ihr hat „signiert“ einen Namen.

Das letzte Stück ist wann. Eine Signatur kann die eigene behauptete Zeit des Unterzeichners einbetten, aber eine Uhr, die Sie nicht kontrollieren, ist eine Behauptung, kein Beweis. Ein Zeitstempel von einer Zeitstempelstelle bindet einen Hash der Signatur an einen Zeitpunkt, bezeugt von einer Partei, die kein Interesse am Dokument hat (SpecSpec: RFC 3161, §1RFC 3161 §1). Das ist es, was eine Signatur auch nach Ablauf des Zertifikats des Unterzeichners aussagekräftig bleiben lässt: Sie können zeigen, dass die Signatur existierte, während das Zertifikat noch gültig war. Die tiefere Behandlung steht in Zeitstempel und vertrauenswürdige Zeit.

Praktisches Beispiel

Die folgenden Gestalten sind die konzeptionellen Operationen, schlicht geschrieben. Der Punkt ist kein API-Aufruf – es geht darum zu sehen, dass Signieren und Verifizieren Spiegelbilder sind und dass ein manipuliertes Byte die Übereinstimmung von Natur aus zerstört.

<?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.

Eine Änderung zu fälschen, die dennoch verifiziert, ist rechnerisch nicht praktikabel. Der Hash trägt den Inhalt getreu, sodass eine Änderung des Inhalts den Hash ändert und die Verify-Operation sie ablehnt – abgesehen davon, eine Hash-Kollision zu finden, was die gewählte Funktion gezielt unpraktikabel macht.

Häufiges Missverständnis

Der häufige Fehler ist, „gültige Signatur“ als „vertrauenswürdiges Dokument“ zu lesen. Das sind nicht dieselben Sätze. Die Kryptografie beweist, dass die Bytes intakt sind und dass der Inhaber des privaten Schlüssels sie signiert hat – mehr nicht. Ein Dokument, das mit einem Schlüssel signiert wurde, von dem Sie nie gehört haben, bezeugt von keiner Stelle, die Sie anerkennen, kann tadellos „gültig“ und nichts wert sein. Identität kommt vom Zertifikat und seiner Kette; Zeit kommt von einem vertrauenswürdigen Zeitstempel. Ein grünes Häkchen, das all dies stillschweigend in einen einzigen Booleschen Wert faltet, hat an Ihrer Stelle entschieden, welche Fragen wichtig waren. Die Einzelteile zu kennen ist es, was Sie die übrigen stellen lässt.

Human-factors note:Human-factors note

Der Grund, diese Ideen zu trennen, ist keine Pedanterie – es ist, damit das Wort „signiert“ ehrlich bleibt. Integrität, Identität und Zeit sind drei verschiedene Beweise, hergestellt durch drei verschiedene Mechanismen (ein Hash plus ein Schlüsselpaar, eine Zertifikatskette und eine Zeitstempelstelle). Ein Werkzeug, das sie als ein einziges Flag meldet, ist leichter zu lesen und weit leichter falsch zu lesen. NextPDF hält sie getrennt, in seiner Ausgabe und in seinen Tests, sodass ein Ergebnis, das „gültig“ sagt, sich in genau das auspacken lässt, was bewiesen wurde.

Grenzen und Abgrenzungen

Diese Seite erklärt die Idee einer digitalen Signatur, nicht das vollständige Validierungsverfahren. Die Mathematik hier beweist Integrität und Authentizität. Sie sagt Ihnen für sich allein nicht, ob das Signaturzertifikat dem ausgestellt wurde, den Sie meinen, ob es zum Signaturzeitpunkt gültig war oder ob es später gesperrt wurde – das sind Fragen des Zertifikatspfads und der Sperrung, und eine korrekte Validierung führt sie alle aus. Der vollständige Prüfsatz steht in Eine Signatur korrekt validieren.

NextPDF baut die Signaturstruktur auf und führt die kryptografischen Prüfungen durch. Es wählt nicht Ihre Vertrauensanker, bürgt für keine Zertifizierungsstelle und entscheidet nicht über die Rechtswirkung einer Signatur – das hängt von Ihrem Deployment, dem Zertifikat und der Rechtsordnung ab. Die Engine beweist den Mechanismus; die darauf aufbauenden Vertrauensentscheidungen liegen bei Ihnen.

Was die Engine je nach Stufe ausliefert, baut nach außen auf diesem Fundament auf:

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

Edition	Availability
Core	○ PAdES B-B: the hash-and-sign mechanism described here, packaged as a detached CMS SignedData object, plus certificate-path validation against a trust anchor you supply.
Pro	○ Adds PAdES B-T — a verified RFC 3161 trusted timestamp on the signature value, so the “when” is attested rather than self-claimed.
Enterprise	○ Adds the long-term profiles (B-LT, B-LTA): embedded validation material and document timestamps that keep the identity and time proofs answerable for years.

Verwandte Dokumente

• Wie Signaturen in einem PDF liegen – wo der Signaturwert und sein Byte-Bereich tatsächlich in der Datei liegen.
• Eine Signatur korrekt validieren – der vollständige Satz an Prüfungen, den ein Verifizierer ausführen muss, über die Mathematik dieser Seite hinaus.
• Zeitstempel und vertrauenswürdige Zeit – was ein RFC 3161-Zeitstempel beweist und warum die eigene Uhr eines Unterzeichners es nicht ist.
• PAdES-Baseline-Profile – welches Profil Identität, Zeit und Langzeitmaterial auf dieses Fundament legt.

Glossar

• Hash (Digest) – ein kurzer Fingerabdruck fester Länge von Daten aus einer kryptografischen Hashfunktion; jede Änderung der Daten ändert ihn vollständig.
• Schlüsselpaar – ein verknüpfter privater Schlüssel (nur vom Unterzeichner gehalten) und öffentlicher Schlüssel (frei geteilt); nur der private Schlüssel kann signieren, und nur der passende öffentliche Schlüssel kann verifizieren.
• Signieren – die Privatschlüssel-Operation auf die Eingabe anwenden, die der Algorithmus definiert: einen Hash des Inhalts bei RSA und ECDSA oder den Inhalt direkt bei EdDSA (das intern hasht). In einer PDF ist dieser Inhalt die signierten Attribute, die den Hash des Dokuments enthalten. Das Ergebnis ist der Signaturwert.
• Verifizieren – dieselbe Eingabe rekonstruieren (ein neu berechneter Hash oder der Inhalt direkt bei EdDSA) und dann die Verify-Operation des Algorithmus auf dem öffentlichen Schlüssel, dem Signaturwert und dieser Eingabe ausführen, um eine Gültig-oder-ungültig-Antwort zu erhalten.
• Signaturwert – die Bytes, die die Privatschlüssel-Operation erzeugt; das, was ein Verifizierer gegen die frisch rekonstruierte Algorithmus-Eingabe prüft (ein Digest bei RSA und ECDSA, der Inhalt selbst bei EdDSA).
• Zertifikat – eine signierte Aussage, die einen öffentlichen Schlüssel an eine benannte Identität bindet; vertraut durch Verkettung zu einer Stelle, die Sie anerkennen (RFC 5280 §6).
• Vertrauensanker – eine Zertifizierungsstelle, der zu vertrauen Sie sich entschieden haben; die Wurzel einer akzeptablen Zertifikatskette.
• Zeitstempel (RFC 3161) – ein signiertes Token einer Zeitstempelstelle, das einen Hash an einen Zeitwert bindet und vertrauenswürdigen Beweis für wann liefert.
• CMS SignedData – die Cryptographic-Message-Syntax-Struktur (RFC 5652), die den Signaturwert und das Zertifikat des Unterzeichners trägt.
• PAdES – PDF Advanced Electronic Signatures: die ETSI-Profilfamilie zum Signieren von PDFs. Ausführlich behandelt auf den Signierseiten.