Beweispaket prüfen, ohne dem Anbieter zu vertrauen

Ein Beweispaket ist nur dann etwas wert, wenn du es offline prüfen kannst, mit Werkzeugen, die ohnehin auf dem Rechner liegen, und gegen einen Vertrauensanker, den du selbst beschaffst, statt gegen einen, der im Paket mitgereist ist. Wenn die Prüfung an dem Tag aufhört zu funktionieren, an dem der Lieferant sein Geschäft einstellt, hältst du keinen Beweis in der Hand. Du hältst ein Abonnement.

Das Wichtigste in Kürze

• Ein Beweispaket muss es einem Fremden ermöglichen, die Aussage von Grund auf nachzurechnen. Dazu braucht es vier Dinge: dein Dokument, das Zeitstempel-Token, den Pfad vom Hash deines Dokuments zurück zur gestempelten Wurzel und eine Anleitung für jemanden, der von alldem noch nie gehört hat. Nur das Dokument bleibt bei dir.

• Ein Merkle-Baum ist zuerst eine Entscheidung für den Datenschutz und erst danach eine für die Geschwindigkeit. Eine flache Liste würde dich zwingen, die Hashes aller anderen Dokumente herauszugeben, die an diesem Tag verankert wurden, auch die fremder Personen.

• Nach eIDAS Artikel 41 Absatz 2 gilt für einen qualifizierten elektronischen Zeitstempel die Vermutung der Richtigkeit von Datum und Uhrzeit und der Unversehrtheit der gebundenen Daten. Die Vermutung steht in Artikel 41, nicht in Artikel 42.

• Die Aufbewahrung der Beweise beträgt bei PDFengine standardmäßig zwanzig Jahre und wird getrennt davon festgelegt, wie lange das Dokument selbst aufbewahrt wird.

• Bewahre die Original-Bytes genau so auf, wie du sie erhalten hast. Erneutes Speichern zerstört die Übereinstimmung, und der niederländische Staatsrat hat erlebt, dass genau das in der eigenen Verarbeitungskette der Gerichte passiert ist.

Die Gegenseite prüft ihre eigene Kopie, nie unsere: Ein Paket mit unserer Kopie des Dokuments würde immer nur etwas über unsere Kopie beweisen.

Was gehört in ein Beweispaket, und warum?

Vier Dinge müssen vorhanden sein, bevor ein Fremder die Aussage nachrechnen kann. Das Dokument selbst. Das Token, das einen Hash an einen Zeitpunkt bindet. Der Pfad vom Hash dieses Dokuments hinauf zur gestempelten Wurzel. Und eine schriftliche Anleitung, denn ein Dritter, der die Konstruktion erraten muss, prüft nichts.

Eines der vier fehlt in dem, was wir schicken, und zwar das Dokument. Im Normalfall enthält das Paket vier Dateien: proof.json, README.txt, timestamp.tsr und die Zwischenzertifikate in tsa-chain.pem. Die letzten beiden erscheinen, sobald die Runde tatsächlich gestempelt wurde und die Zeitstempelstelle ihre Kette geliefert hat.

Die Begründung für das fehlende Dokument ist unbequem, aber stichhaltig. Ein Paket mit unserer Kopie würde nur etwas über unsere Kopie beweisen. Die strittige Kopie liegt auf deinem Schreibtisch, also gehört sie bei der Prüfung neben diese Dateien. Daraus folgen zwei Nebeneffekte: Ein durchgesickerter Link gibt kein Mandantenmaterial preis, und das Paket bleibt klein genug, um als E-Mail-Anhang verschickt zu werden.

proof.json enthält den SHA-256 des Dokuments, seine Position im Baum, die Geschwisterhashes mit der vermerkten linken oder rechten Seite, den Wurzelhash, den Namen der Zeitstempelstelle und eine ausgeschriebene Regel dafür, wie Blätter und Knoten verknüpft werden. Dieser letzte Punkt ist wichtiger, als er aussieht. Ohne ihn muss ein Dritter raten, wie der Baum gebaut wurde, und Raten ist keine Prüfung.

Warum ein Merkle-Baum statt einer flachen Liste?

Wegen des Datenschutzes, nicht wegen des Durchsatzes. Diese Reihenfolge ist das ganze Argument.

Angenommen, die Dokumente eines Tages würden als flache Liste verankert, wobei die Wurzel ein Hash über diese Liste wäre. Um zu beweisen, dass dein Vertrag darin war, müsstest du die Liste reproduzieren. Die ganze. Das hieße, der Gegenseite die Hashes aller anderen an diesem Tag gestempelten Dokumente zu übergeben, auch derjenigen von Personen, die mit deinem Streit nichts zu tun haben. Du würdest eine Kundenliste preisgeben, um einen Punkt zu einem einzigen PDF zu gewinnen.

Ein Baum beseitigt das Problem. Du lieferst nur die Knoten, die direkt neben deinem Pfad nach oben liegen. Jede Verdopplung des Stapels fügt genau einen weiteren Geschwisterhash hinzu, ein arbeitsreicher Tag kostet also ein paar zusätzliche Zeilen in einer JSON-Datei statt eines Offenlegungsvorfalls.

Die Verankerung läuft einmal täglich um 03:00 Uhr Europe/Amsterdam. Eine Runde, ein Baum, ein Aufruf bei der Zeitstempelstelle, egal ob die Runde vier Dokumente umfasst oder viertausend. Nur der Wurzelhash verlässt das Haus. Diese Sparsamkeit macht es möglich, dass die tägliche Runde alles abdeckt, was eingegangen ist, und nicht nur die Dokumente, die jemand zu markieren daran gedacht hat. Ein bestimmtes PDF auf Anforderung zu stempeln, ist eine eigene, kostenpflichtige Aktion: Das erledigt das Tool für qualifizierte Zeitstempel, jeweils eine Datei nach der anderen.

Warum bleibt der Beweis bestehen, wenn die Datei längst weg ist?

Weil Aufzeichnung und Dokument verschiedene Objekte mit verschiedener Lebensdauer sind, und wir behandeln sie bewusst so.

Ein Beweisdatensatz besteht aus einem Hash, einer Blattposition, einer kurzen Liste von Geschwisterhashes und einem Verweis auf seine Runde. Ein paar hundert Bytes, ohne nennenswerte Speicherkosten. Das Dokument, das er beschreibt, ist eine andere Sache: Es folgt der üblichen Aufbewahrungsfrist und wird planmäßig bereinigt, wie es sein soll.

Die Aufbewahrung der Beweise beträgt hier standardmäßig zwanzig Jahre und wird unabhängig von der Aufbewahrung der Dateien konfiguriert. Das Löschen des Ergebnisses entfernt den Hash-Datensatz nicht. Fünf Jahre nach Abschluss einer Sache, wenn das PDF längst gelöscht ist, geht die Rechnung noch immer auf, sofern die andere Partei ihre Kopie behalten hat.

Hier verbiegen sich die Anreize eines Lieferanten unauffällig. Liegt dein Beweis im Archiv eines anderen, braucht er dich als zahlenden Kunden dieses Archivs, und unbegrenzter Speicherplatz ist dann keine Großzügigkeit mehr, sondern das Schloss.

Warum fehlt das Root-Zertifikat absichtlich?

Weil die Validierung eines Tokens gegen ein Root-Zertifikat, das im selben Umschlag ankam, eine Integritätsprüfung im Kostüm einer Vertrauensprüfung ist.

Überlege, was du da testest. Die Kette in tsa-chain.pem zeigt, dass das Token in sich stimmig ist. Gut. Aber die Stimmigkeit mit einem Root-Zertifikat, das wir dir gegeben haben, beweist nur, dass wir mit uns selbst stimmig sind. Wer das Token fälschen kann, kann auch das Root-Zertifikat daneben fälschen. Die Prüfung gelingt, die Schlussfolgerung ist wertlos, und das Ganze sieht aus wie eine echte Verifikation.

Die Abfolge hat deshalb drei Schritte:

1. Beschaffe das Root-Zertifikat selbst, aus der Veröffentlichung der Zeitstempelstelle oder über den EU Trusted List Browser. proof.json nennt die Stelle, du weißt also, wessen Root-Zertifikat du suchst. Unsere ist Disig a.s. in der Slowakei.

2. Berechne den Wurzelhash aus dem SHA-256 deines Dokuments und den Geschwisterhashes neu, nach der in proof.json ausgeschriebenen Regel, und prüfe dann, ob dein Ergebnis dem dort festgehaltenen Wurzelhash entspricht.

3. Verifiziere das Token über diesen Wurzelhash:

openssl ts -verify -digest <root_hash> -in timestamp.tsr \

-untrusted tsa-chain.pem -CAfile <root you fetched yourself>

Die naheliegende Gegenfrage lautet, woher du weißt, dass du das richtige Root-Zertifikat beschafft hast. Das musst du nicht vorher wissen: Verweist du den Befehl auf das falsche, schlägt er fehl, statt stillschweigend durchzulaufen. Das Root-Zertifikat signiert entweder die Kette hinter deinem Token oder eben nicht.

Dieselbe Überlegung gilt für das Wort „qualifiziert“. Eine Richtlinienkennung in einem Token ist eine Selbstauskunft dessen, der das Token gebaut hat. Der qualifizierte Status ergibt sich stattdessen aus dem Eintrag eines Anbieters in einer nationalen Vertrauensliste, die öffentlich und ohne uns lesbar ist. Unser Dienst ist dort für TSA/QTST mit dem Status „granted“ aufgeführt. Sieh nach.

Warum fasst die Verankerung die Datei nie an?

Weil der Hash über Bytes berechnet wird und das Zurückschreiben des Ergebnisses ins Dokument diese Bytes verändern würde.

Es ist eine kleine Schleife, in die erstaunlich viele Produkte geraten. Das Dokument wird gehasht, ein Anker wird eingeholt, und dann wird dieser Anker hilfsbereit ins PDF gestempelt, damit der Leser ihn sieht. Das gespeicherte PDF passt jetzt nicht mehr zum soeben verankerten Hash. Der Beweis macht sich im Moment seiner Bekanntgabe selbst ungültig. Deshalb bleibt die gespeicherte Datei Byte für Byte identisch: nichts wird hineingeschrieben, nichts neu gespeichert, nichts optimiert. Die Aufzeichnung liegt neben dem Dokument, nie darin.

Dieselbe Disziplin gilt weiter vorn in der Kette. Nach RFC 3161 geht nur der Message Imprint an die Zeitstempelstelle, und ein signiertes Token über diesen Imprint kommt zurück. Bei vertraulichem Material ist das oft der Grund, warum das Gespräch überhaupt möglich ist.

Was muss die empfangende Partei tun, und was macht den Nachweis kaputt?

Bewahre das Originaldokument genau so auf, wie es angekommen ist. Speichere es nicht neu. Öffne es nicht in Acrobat, um zu speichern. Schicke es nicht durch einen Konverter, um es für die Akte aufzuräumen. Ein Hash über Bytes ist unnachgiebig, und erneutes Speichern schreibt Bytes um, selbst wenn sich sichtbar nichts geändert hat.

Das niederländische Verfahrensrecht weist aus eigenen Gründen in dieselbe Richtung. Artikel 156a der Zivilprozessordnung (Wetboek van Burgerlijke Rechtsvordering) erlaubt es, eine elektronische Urkunde elektronisch aufzubewahren, sofern die Aufbewahrung eine unveränderte Wiedergabe des Inhalts für einen dem Zweck entsprechenden Zeitraum ermöglicht. Unveränderte Wiedergabe ist der Maßstab, den dein Archivierungsschritt erfüllen muss. Ein gut gemeintes erneutes Speichern verfehlt ihn unbemerkt.

Dieses Versagen ist nicht theoretisch. In ECLI:NL:RVS:2024:4237 versuchte der Staatsrat, eine elektronisch signierte Haftanordnung zu validieren, und erhielt eine Fehlermeldung. Das Sachverständigengutachten vom 3. September 2024 erklärte den Grund: Nach der Signatur hatte das Ministerium die Datei an die Gerichte geschickt, wo sie in ein Format für die digitale Archivierung umgewandelt wurde. Diese Umwandlung beschädigte, in den Worten der Entscheidung selbst, Informationen in dem Teil der Datei, in dem die elektronische Signatur sitzt.

Lies die Abfolge noch einmal. Die Signatur war in Ordnung; der Sachverständige hat sie im Original validiert. Der Archivierungsschritt erzeugte die defekte Kopie, und diese defekte Kopie kam in die digitale Akte. Die Entscheidung nennt nicht, in welches Format umgewandelt wurde, also tun wir es auch nicht.

Die Regel für alle, die ein Dokument mit angehängtem Beweis erhalten: Lege die empfangenen Bytes unangetastet ab und arbeite mit einem Duplikat. Hast du schon darüber gespeichert? Bitte den Absender um das Original.

Wie schneidet das im Vergleich zu einem Dokumentzeitstempel in Adobe Acrobat ab?

Der Dokumentzeitstempel von Acrobat ist ein echter Mechanismus, und ein Dritter kann ihn prüfen. Die Unterschiede betreffen, wo der Beweis liegt, wer die Zeitquelle auswählt und was mit dem Dokument geschieht.

Welche Acrobat-Ausgaben und -Tarife welche Signaturfunktionen enthalten, muss Adobe selbst angeben, auf den eigenen Preisseiten. Wir werden keine Zahlen nennen, die sich verändern.

Keine der beiden Spalten ist hier der Bösewicht. Wenn du bereits weißt, welcher Zeitstempelstelle du vertraust und warum, ist der in Acrobat eingebaute Weg respektabel. Die meisten scheitern an diesem zweiten Halbsatz.

Was beweist dieses Paket nicht?

Dass das Dokument spätestens zu dem im Token festgehaltenen Zeitpunkt existierte und sich seither nicht verändert hat. Das ist die gesamte Aussage, und sie zu überdehnen ist der Weg, in einer Verhandlung an Glaubwürdigkeit zu verlieren.

Es beweist nicht, wer das Dokument erstellt hat. In der Konstruktion steckt keine Identität: keine Signatur, niemand, der für die Urheberschaft einsteht. Urheberschaft ist eine Frage der Signatur, und unsere rechtliche Übersicht zeigt, wo diese Grenze verläuft. Es beweist auch nicht, dass der Inhalt wahr ist. Eine sorgfältig verankerte Rechnung für nie erbrachte Arbeit bleibt eine verankerte Lüge.

Ein Anker ist eine Obergrenze, nie eine Geburtsurkunde. Existierte spätestens am. Nicht: erstellt am. Wir führen eine Liste mit Formulierungen, die in unseren eigenen Texten verboten sind, und „erstellt am“ steht darauf, neben „rechtsgültig“ und „zertifiziert“. Die enge Fassung übersteht den Gerichtssaal. Die Marketingfassung nicht.

Innerhalb dieser Grenzen ist der Wert echt. Artikel 41 Absatz 2 knüpft an einen qualifizierten Zeitstempel die Vermutung richtiger Zeit und unversehrter gebundener Daten. In der Praxis liegt die Last damit bei dem, der das Datum bestreiten will.

Häufig gestellte Fragen

Muss ich mein Dokument an die Zeitstempelstelle schicken?

Nein. Nach RFC 3161 sendet der Client nur den Message Imprint, also einen Hash. Das Dokument verlässt deine Umgebung nie, weshalb dieses Verfahren auch für vertrauliches Material taugt, das du nicht auf eine Validierungswebsite hochladen könntest.

Kann ich das noch prüfen, wenn PDFengine nicht mehr existiert?

Ja, und genau deshalb enthält das Paket ein Token und keinen Link. Alles, was die Prüfung braucht, liegt im Paket, dazu ein Root-Zertifikat, das du von der Zeitstempelstelle oder aus der Vertrauensliste holst, und das Werkzeug ist openssl und nicht unsere Software. In unserer README steht die Prüfseite aus Höflichkeit ganz unten, unter dem Offline-Befehl.

Kann jemand einfach das Erstellungsdatum in einem PDF ändern?

Ja. Erstellungs- und Änderungsdatum in einem PDF sind gewöhnliche Metadatenfelder, die sich ohne besondere Kenntnisse umschreiben lassen, und die Rechneruhr kann zurückgestellt werden, bevor das Dokument überhaupt erzeugt wird. Ein Datum, auf das man sich verlassen kann, muss deshalb von außerhalb der Datei kommen, signiert von einer Partei, die kein Interesse daran hat.

Ich habe die Datei geöffnet und gespeichert. Habe ich den Beweis zerstört?

Für diese Kopie wahrscheinlich ja. Speichern schreibt Bytes um, selbst wenn sich sichtbar nichts geändert hat, und der Hash deckt Bytes ab. Geh zurück zur Kopie genau so, wie du sie erhalten hast, und bitte den Absender, sie dir erneut zu schicken, falls sie weg ist. Ein Fingerabdruck-Vergleich kann immer noch anzeigen, ob sich der Inhalt verschoben hat, auch wenn das eine schwächere Aussage ist als eine Byte-Übereinstimmung.

Warum ist das Root-Zertifikat nicht im Paket enthalten?

Weil ein Root-Zertifikat, das mit dem Token gereist ist, nichts über das Token beweist. Die Validierung dagegen ist eine Integritätsprüfung, die sich als Vertrauensprüfung ausgibt. Hole das Root-Zertifikat vom Anbieter oder aus dem EU Trusted List Browser und verifiziere dann dagegen.

Was bedeutet das für das Dokument auf deinem Schreibtisch?

Wenn über ein Dokument eines Tages gestritten werden könnte, ist der nützliche Zeitpunkt jetzt, solange noch niemand streitet. Fixiere die Bytes, lass sie verankern, behalte die empfangene Kopie unangetastet. Die Diskussion verlagert sich dann von „glauben wir dieser Datei“ zu „was steht in dieser Datei“.

Hast du ein Dokument mit angehängtem Beweis erhalten? /verify akzeptiert eine Datei, einen Hash oder einen Prüfcode und meldet die Ergebnisse getrennt, statt sie in einem einzigen grünen Haken zusammenzuziehen. Es ist eine Erleichterung, und die Seite sagt das auch. Die Befehle im Paket sind der Beweis.

Daan van Tongeren ist der Gründer von PDFengine, wo er das hier beschriebene Beweispaket entworfen hat, einschließlich der README-Zeile, die dir sagt, dass du dem Root-Zertifikat darin nicht trauen sollst. Korrekturen oder der Bericht über einen Fall, in dem das in der Praxis schiefgegangen ist, sind willkommen über die Kontaktseite.