Was Verifizierung bedeutet
Die Verifizierung ist bewusst einfach und deterministisch: Sie prüft, ob der Beweis byte- identisch mit der ursprünglich erfassten Aufzeichnung ist und ob die kryptografischen Zeitanker noch gültig sind. Sie beurteilt nicht den Wahrheitsgehalt oder wer recht hat — sie verifiziert die Integrität.
Unter der Haube ist jeder GPA-Beweis in vier unabhängigen Integritätsschichten verankert — Datei-Hashes, einer Append-only-Hash-Kette, einem Bitcoin-OpenTimestamps-Anker und einem eIDAS-qualifizierten Zeitstempel. Die Verifizierung prüft sie. Eine Manipulation an einer davon — selbst das Umformatieren von JSON-Leerzeichen — lässt die Prüfung scheitern.
Methode 1 — Eine Proof-ID verifizieren (online)
Eine Proof-ID ist ein dauerhafter Identifikator für eine erfasste Aufzeichnung. Jeder mit der Proof-ID (oder dem Beweis-Link) kann sie online über das öffentliche Prüftool verifizieren — kein Konto, keine Installation, keine Einrichtung.
- Öffnen Sie die Prüftool-Seite.
- Fügen Sie die Proof-ID ein oder öffnen Sie den Beweis-Link direkt.
- Prüfen Sie das Ergebnis — erfasste Artefakte plus Integritätsstatus über alle vier Schichten.
Das Prüftool rendert die erfassten Artefakte nebeneinander mit ihrem Integritätsstatus:
- den erfassten Screenshot, den extrahierten Text und die Quell-/finale URL
- Erfassungszeitstempel und Inhalts-Fingerabdrücke (SHA-256)
- Bitcoin-Anker-Status (verankerter Block + Transaktion, falls bestätigt)
- eIDAS-Qualified-Timestamp-Status (TSA-Name, Zeit, Signaturgültigkeit)
Nutzen Sie das öffentliche Prüftool, um eine Proof-ID zu prüfen, oder laden Sie ein Beweis-ZIP für die vollständige mehrschichtige Verifizierung hoch.
Methode 2 — Ein Beweis-ZIP verifizieren
Die ZIP-Verifizierung ist für das Teilen und die langfristige Archivierung gemacht. Sie kann auf zwei Arten durchgeführt werden: online über das Prüftool (Drop-in-Upload, sofortiger Bericht) oder vollständig offline mit der zweisprachigen README im ZIP und gängigen Open-Source-Werkzeugen.
Online — Drop-in-Upload
Wenn Sie Internetzugang haben und nur eine schnelle Antwort möchten, übernimmt das Prüftool den gesamten Prozess für Sie:
- Öffnen Sie die Prüftool-Seite.
- Ziehen Sie das Beweis-ZIP in den Upload-Bereich (kein Entpacken nötig).
- Erhalten Sie einen Bericht pro Schicht — Dateiintegrität, Hash-Kette, eIDAS-Zeitstempel, Bitcoin-Anker — jeweils als BESTANDEN oder GESCHEITERT markiert.
Offline — kein GPA, kein Internet, kein Konto
Jede externe Abhängigkeit, die die Verifizierung benötigt, ist im ZIP selbst gebündelt: das Manifest, die Hash-Ketten-Einträge, die Bitcoin-OpenTimestamps-Quittung, die vollständige Zertifikatskette der qualifizierten TSA und ein eingefrorener Snapshot der EU-Vertrauensliste. Die zweisprachige (Englisch + Tschechisch) README.md im ZIP ist die maßgebliche Referenz für die Offline-Verifizierung. Sie haben zwei Optionen:
Ein Befehl führt alle vier Offline-Schichten plus drei zusätzliche strukturelle Prüfungen aus (OTS-Quittungsstruktur, TLS-Leaf-Bindung, eIDAS-Asset-Bindung). Reines Python, keine GetProofAnchor-Server beteiligt.
Einmal mit pip installieren, dann auf ein beliebiges Beweis-ZIP zeigen. Exit-Code 0 = alle Schichten bestanden; andernfalls ungleich null mit einer Aufschlüsselung pro Schicht.
Manuelles Verfahren — ein Schritt pro Schicht
Möchten Sie jeden Schritt selbst ausführen? Die zweisprachige README im ZIP dokumentiert das maßgebliche Vier-Schritte-Verfahren mit kopierbaren Befehlen — ein Schritt pro Integritätsschicht:
- Schritt 1 — Dateiintegrität — Ein python3-Skript liest die manifest.json, berechnet den SHA-256 jeder Datei im Paket neu und vergleicht. BESTANDEN = nichts wurde hinzugefügt, entfernt oder verändert.
- Schritt 2 — eIDAS-qualifizierter Zeitstempel — openssl ts -verify prüft das RFC-3161-Token gegen die zeitgestempelte Nutzlast mit der gebündelten TSA-Zertifikatskette. (Eine reine Python-Alternative ist für Umgebungen ohne openssl enthalten.) BESTANDEN = die Daten existierten zum gestempelten Zeitpunkt, signiert von der in der EU-Vertrauensliste eingetragenen qualifizierten TSA.
- Schritt 3 — Bitcoin-OpenTimestamps-Anker — Der ots-Client verifiziert die Quittung gegen die Bitcoin-Blockchain (oder laden Sie sie auf opentimestamps.org hoch oder prüfen Sie die Transaktion in einem öffentlichen Block-Explorer wie mempool.space). BESTANDEN = der Kettenkopf wurde in einen bestimmten Bitcoin-Block eingebunden.
- Schritt 4 — Hash-Kette — Ein python3-Skript durchläuft chain/proof_chain.jsonl, berechnet jeden Eintrags-Hash aus prev_hash, Ereignistyp, Proof-ID und Daten-Hash neu und bestätigt die Verknüpfung zur chain_head.json. BESTANDEN = das interne Ereignisprotokoll ist intakt.
Alle 4 BESTANDEN → das Paket ist kryptografisch intakt. Der Bitcoin-Schritt ist der einzige, der Netzwerkzugang benötigt (oder Sie verifizieren die Transaktions-ID stattdessen in einem öffentlichen Explorer). Die Schritte 1, 2 und 4 funktionieren vollständig offline.
Drei Open-Source-Werkzeuge decken das gesamte Offline-Verfahren ab:
python3— alles funktioniert unter Linux, macOS und Windows. Verwendet für die Schritte 1, 2 (Alternativpfad) und 4.openssl— Standard unter Linux/macOS; unter Windows nutzen Sie Git Bash oder WSL. Verwendet für die maßgebliche eIDAS-Verifizierung (Schritt 2).ots(aus pip install opentimestamps-client) — für den Bitcoin-Anker (Schritt 3). Optional — Sie können auch verifizieren, indem Sie die Quittung auf opentimestamps.org hochladen oder die Bitcoin-Transaktion in einem Block-Explorer prüfen.
Möchten Sie genau wissen, welche Datei im ZIP von jedem Schritt verwendet wird? Siehe das Tutorial Beweis-ZIP — jede Datei darin.
So interpretieren Sie die Ergebnisse
Die Ergebnisse sind deterministisch. Übereinstimmung bedeutet, der Beweis ist byte-identisch mit der ursprünglichen Aufzeichnung und alle Integritätsschichten bestehen. Verändert bedeutet, mindestens eine Schicht ist gescheitert — dem Beweis kann nicht als Original vertraut werden.
Wenn Sie Verändert sehen, sagt Ihnen der Bericht pro Schicht genau, welche Schicht gescheitert ist — das reicht meist aus, um nachzuweisen, dass das Paket nicht der ursprünglich exportierte Beweis ist.
- der SHA-256 einer einzelnen Datei weicht vom Manifest ab → diese Datei wurde bearbeitet (z. B. ein Screenshot-Pixel geändert, Text ersetzt oder eine JSON-Datei umformatiert)
- ein Ketten-Eintrags-Hash stimmt nicht überein → jemand versuchte, ein Ereignis in der Beweis-Historie einzufügen, zu entfernen oder zu verändern
- eIDAS-Signatur ungültig oder Imprint-Fehlanpassung → die zeitgestempelte Nutzlast wurde verändert oder das TSR wurde ausgetauscht
- Bitcoin-Anker-Verifizierung scheitert → die OpenTimestamps-Quittung bindet nicht mehr denselben Kettenkopf ein (oder die Quittung selbst wurde manipuliert)
Was die Verifizierung nicht tut
- Sie bewertet nicht den Wahrheitsgehalt — nur, ob der erfasste Inhalt intakt und die Zeitanker gültig sind.
- Sie ersetzt keinen Rechtsbeistand.
- Sie entscheidet nicht über die Verwertbarkeit — das bestimmen Behörden und Rechtsordnung.
- Sie behebt kein Verändert-Ergebnis. Sobald ein ZIP manipuliert wurde, verifiziert nur das ursprüngliche (unmanipulierte) ZIP.
Die Verifizierung beantwortet nur: „Ist dieser Beweis original und unverändert, und ist sein Zeitanker kryptografisch gültig?“
Weiter mit: Beweis-ZIP — jede Datei darin, offline verifizierbar.
Keine Rechtsberatung. Die Verwertbarkeit hängt von der Rechtsordnung und den Umständen ab.