Was ist das Beweis-ZIP?
Das Beweis-ZIP ist ein portables, in sich geschlossenes Paket, das Sie aus jedem Beweis exportieren können. Formatkennung:
getproofanchor-evidence-4. Ein typisches Paket hat rund 30 Dateien in 6 Verzeichnissen; die Größe hängt von der Seite ab (typischerweise 5–15 MB ohne Video; bis zu 100–150 MB mit aktiviertem Video und vollständigen HAR-Archiven). Es ist dafür gemacht, Ihr Konto zu verlassen — zum Archivieren, Anhängen an eine Fallakte, Einreichen bei einem Regulierer oder Senden an einen externen Prüfer.
Das entscheidende Merkmal ist nicht „einfach exportieren“ — es ist, dass das Paket später vollständig offline verifiziert werden kann, mit nur gängigen Open-Source-Werkzeugen. Keine Internetverbindung, kein GetProofAnchor-Dienst, kein Konto.
Jede externe Abhängigkeit, die die Verifizierung benötigen könnte, ist im ZIP selbst eingefroren: das kryptografische Manifest, die Hash-Ketten-Einträge des Beweises, die Bitcoin-OpenTimestamps-Quittung, die vollständige Zertifikatskette der qualifizierten TSA und sogar ein Snapshot der EU-Vertrauensliste (LOTL), der beweist, dass die TSA zum Zeitpunkt des Stempelns offiziell anerkannt war. Würde GetProofAnchor morgen verschwinden, würde Ihr Beweis-ZIP dennoch genau gleich verifizieren — von jedem, überall, mit einem Laptop und Python.
Was tatsächlich darin steckt (jede Datei, nach Zweck gruppiert)
Öffnen Sie das ZIP und Sie sehen etwa Folgendes — rund 30 Dateien in sechs Verzeichnissen. Sie sind hier danach gruppiert, was sie tun: erfasster Inhalt, Erfassungskontext, Netzwerk-Identitätsbeweise, die kryptografischen Integritätsschichten und menschenlesbare Dokumente.
Was die Seite zum Erfassungszeitpunkt tatsächlich war.
screenshot.png— Ganzseiten-Screenshot, gerendert zum Erfassungszeitpunkt, erfasst von Playwright (Chromium) bei 1280px Viewport-Breite mit vollständigem Höhen-Scrollpage.html— das erfasste DOM/HTML zum Erfassungszeitpunkt — nützlich zur Inspektion von Struktur, Links und tatsächlich ausgelieferten Skriptencontent.txt— extrahierter Klartext-Inhalt — was ein Leser auf der Seite tatsächlich gesehen hätte, von Markup befreitcapture.webm— Bildschirmaufnahme der gesamten Erfassungssitzung im WebM/VP9-Format. Erfasst jeden dynamischen Inhalt, Animationen oder Interaktionen (wie die Consent-Dialog-Behandlung), die ein statischer Screenshot nicht zeigen kann. Nützlicher Beweis für zeitbasierte oder interaktive Inhalte.
Wie die Erfassung geschah — der Audit-Trail.
proof.json— die Hauptbeweisaufzeichnung: Proof-ID, Quell-URL, finale URL nach Weiterleitungen, Erfassungszeitstempel, alle SHA-256-Fingerabdrücke (Inhalt, Screenshot, Roh-HTML), Erfassungsmodus (Server/Browser), eIDAS-Status, Anker-Infocapture/capture_meta.json— detaillierte forensische Metadaten über die Erfassung selbst: Erfassungs-Engine (Playwright + Browser-Version), User-Agent, Viewport, vollständige Seitenabmessungen nach Lazy-Load-Scrolling, automatisch behandelte Consent-Dialoge und die verwendete Methode, genutzte KI-Aufrufe, Scroll-Durchläufe, Bild-Ladestatus, visueller Qualitätswert, Erfolgsurteilcapture/capture_meta.sha256— SHA-256 der capture_meta.json separat gespeichert — von der eIDAS-Nutzlast referenziert, sodass die Erfassungs-Metadaten ebenfalls vom qualifizierten Zeitstempel abgedeckt sind
Wer die Seite tatsächlich ausgeliefert hat, was von wo geladen wurde und welche IPs für die Domain antworteten (nach ISO/IEC 27037 § 6.4–6.5).
network/capture.har— HTTP-Archiv (HAR-1.2-Spezifikation) jeder Netzwerkanfrage, die der Browser während der Erfassung machte: URL, Methode, Anfrage-/Antwort-Header, Statuscode, Antwortgröße, MIME-Typ, vollständige Timing-Aufschlüsselung (DNS, Connect, TLS, Send, Wait, Receive). Lässt einen Prüfer genau sehen, welche Assets, Skripte, Tracker, Drittanbieter-Aufrufe und Weiterleitungen beteiligt waren.network/network_evidence.json— menschenlesbare Indexdatei (Formatkennung getproofanchor-network-evidence-1): Ziel-URL, Hostname, Erfassungszeit und Flags, die anzeigen, welche Netzwerk-Beweisdateien vorhanden sind. Eine schnelle Orientierungsdatei für forensische Prüfer.network/tls.json— menschenlesbare Handshake-Metadaten in JSON: TLS-Version (z. B. TLSv1.3), Cipher Suite, antwortende Server-IP, SNI, Zertifikats-Gültigkeitszeitraum, alle Subject Alternative Names, vollständige Ketten-Fingerabdrücke (SHA-256 + SHA-1), Hostname-Übereinstimmungs-Flag, OCSP-Status — alles, was ein Prüfer braucht, um die Verbindung zu inspizieren, ohne X.509 zu parsen.tls/leaf_cert.pem— das Leaf-X.509-Zertifikat des Servers in PEM-Form, wie es während des TLS-Handshakes präsentiert wurde. Der SHA-256 dieser Datei ist in die eIDAS-Nutzlast eingebunden — sodass die kryptografische Identität des Servers zusammen mit dem Seiteninhalt zeitgestempelt wird.tls/chain.pem— die vollständige Zwischen- + Root-Zertifikatskette in PEM-Form. Lässt einen Prüfer das Leaf-Zertifikat offline bis zu einer bekannten öffentlichen CA validieren. Der SHA-256 dieser Datei ist ebenfalls in die eIDAS-Nutzlast eingebunden.network/dns.json— Multi-Resolver-DNS-Auflösung zum Erfassungszeitpunkt, unabhängig gegen Cloudflare (1.1.1.1), Google (8.8.8.8) und Quad9 (9.9.9.9) abgefragt: A-, AAAA-, CNAME-Einträge mit TTLs. Wenn mehrere Resolver übereinstimmen, ist das ein starker Beweis, dass die Domain zu diesem Zeitpunkt tatsächlich auf diese IPs auflöste.network/rdap.json— RDAP-Abfrageergebnis (moderner WHOIS-Ersatz): Domain-Inhaber, Registrar, Registrierungsdatum, Ablaufdatum, Datum der letzten Änderung, Nameserver, Status-Flags. Stellt fest, wer die Domain zum Erfassungszeitpunkt kontrolliert.
Diese Dateien beantworten zusammen die Fragen, die ein feindliches Kreuzverhör stellen wird: Wer kontrollierte diese Domain? Welche IP antwortete tatsächlich für sie? Welches Zertifikat präsentierte der Server, und war seine Identität in den Zeitstempel eingebunden?
Jede Schicht ist unabhängig. Wer eine aushebelt, bricht die anderen nicht.
manifest.json— die Integritätsbasis: SHA-256-Hash jeder anderen Datei im Paket + Kettenkopf + Anker- und eIDAS-Metadaten. Die Verifizierung beginnt immer hier. Jedes geänderte Byte in einer Datei lässt die Prüfung scheitern.
chain/proof_chain.jsonl— die Ereignisse dieses Beweises in der globalen SHA-256-Hash-Kette (ein JSON-Objekt pro Zeile: seq, event_type, prev_hash, data_hash, entry_hash, created_at). Das Einfügen oder Verändern eines früheren Eintrags bricht die Kette.chain/chain_head.json— Snapshot des Kettenkopfs, an den dieser Beweis verankert wurde — die seq-Nummer und der Eintrags-Hash. Verwendet zur Verifizierung der letzten Verknüpfung der Kette.
anchor/anchor_payload.json— die minimale Datenstruktur, die in Bitcoin eingebunden wurde: Kettenkopf-Hash + beobachtete UTC-Zeit + Formatversion. Vor dem Stempeln kanonisch gehasht.anchor/anchor_receipt.ots— binäre OpenTimestamps-Quittung mit dem Merkle-Pfad zurück zu einer Bitcoin-Transaktion. Nach Bestätigung wird der Zeitstempel vom gesamten Bitcoin-Netzwerk bewahrt — nicht von GetProofAnchor.
Zehn Dateien bilden zusammen ein vollständiges, in sich geschlossenes eIDAS-Verifizierungskit.
timestamp/eidas.tsr— binäre RFC-3161-TimeStampResp des qualifizierten Vertrauensdiensteanbieters — CMS-signiert, im selben Standard-PKI-Format, das EU-Gerichte und Regulierer verwendentimestamp/eidas_payload.json— die exakten Daten, die zeitgestempelt wurden, in kanonischem JSON (sortierte Schlüssel, keine Leerzeichen). Bindet 8 SHA-256-Fingerabdrücke in den qualifizierten Zeitstempel: content_sha256, raw_html_sha256, screenshot_sha256, capture_meta_sha256, video_sha256, har_sha256, tls_leaf_pem_sha256, tls_chain_pem_sha256 — plus source_url, final_url, captured_at, proof_id. Formatkennung: getproofanchor-eidas-stamp-5. Jedes forensische Artefakt im Paket ist in einen einzigen qualifizierten Zeitstempel eingebunden.timestamp/eidas_payload.sha256— SHA-256 der obigen Nutzlast. Genau dieser Hash ist der in den RFC-3161-Zeitstempel eingebettete Imprint, der den Zeitstempel kryptografisch mit den erfassten Daten verknüpft.timestamp/eidas_meta.json— übergeordneter eIDAS-Status: Anbietername (derzeit SK ID Solutions, Estland), TSA-URL, exakte Zeitstempel-Zeit, Statustimestamp/<proof_id>.tsa_signer_cert.pem— X.509-Zertifikat der tatsächlichen TSA-Zeitstempeleinheit, die den Zeitstempel signiert hat — das Leaf-Zertifikat in PEM-Formtimestamp/<proof_id>.tsa_certs.pem— die vollständige PEM-Zertifikatskette: Signierer + Zwischen-CA + Root-CA. Ermöglicht die Offline-Validierung der Kette, ohne etwas abzurufen.timestamp/<proof_id>.tsa_certs.json— dieselbe Kette in JSON-Form (Subjects, Aussteller, Seriennummern, Gültigkeitszeiträume, SHA-256-Fingerabdrücke) — leicht lesbar ohne PEM-Parsingtimestamp/<proof_id>.qualified_context.json— Kontext, der die TSA mit der EU-Vertrauensliste verknüpft: die Quell-LOTL-URL (eu-lotl.xml von ec.europa.eu), exakte Download-Zeit, SHA-256 und welche Länder-TSL(s) in diesem Paket gebündelt sind. Formatkennung: getproofanchor-eidas-qualified-context-2.timestamp/tsl/<COUNTRY>.xml— EU-Mitgliedstaaten-Vertrauensliste in XML-Form (z. B. EE.xml für eine estnische TSA, CZ.xml für die tschechische usw.). Dies ist die ETSI-Standard-Länder-TSL, die beweist, dass die TSA zum Stempelzeitpunkt offiziell als qualifizierter Vertrauensdiensteanbieter nach eIDAS anerkannt war. Die obige qualified_context.json erklärt, welche Länder-TSLs gebündelt wurden und warum.timestamp/<proof_id>.eidas_verification_report.json— interner eIDAS-Verifizierungsbericht (Formatkennung getproofanchor-eidas-tsr-summary-1), erstellt zum Stempelzeitpunkt: Status (granted), Policy-OID 0.4.0.2023.1.1, Hash-Algorithmus, Imprint-Digest in Hex, signature_verified-Flag, vollständige Zusammenfassung der TSA-Zertifikatskette.
Für Menschen, nicht für Maschinen.
README.md— zweisprachige (Englisch + Tschechisch) Verifizierungsanleitung für forensische Sachverständige. Führt durch alle 4 Verifizierungsschritte mit kopierbaren Befehlen für nur python3, openssl und den ots-Client.report.pdf— menschenlesbarer Beweisbericht (~1 MB). Formatierte Zusammenfassung mit Proof-ID, erfassten URLs, Zeitstempeln, allen SHA-256-Fingerabdrücken, Blockchain-Anker-Info, eIDAS-Status — geeignet für Fallakten und Ausdrucke.
Vier unabhängige Integritätsschichten
Das Vertrauen ist kein einzelner Mechanismus. Es sind vier unabhängige Schichten, jede durch eigene Dateien im ZIP gestützt. Wer eine einzelne Schicht aushebelt, bricht die anderen nicht — und ein Angreifer müsste alle vier gleichzeitig aushebeln, einschließlich Bitcoin zu brechen und eine EU-qualifizierte TSA-Signatur zu fälschen, um einen einzigen Beweis zu fälschen.
Hash jeder Datei im Paket. Wenn sich ein Byte einer Datei ändert — selbst das Umformatieren von JSON-Leerzeichen — scheitert die Verifizierung.
Dateien: manifest.json
Die Ereignisse dieses Beweises leben in einer globalen SHA-256-Kette. Jeder Eintrag enthält den Hash des vorherigen. Das Einfügen oder Verändern eines früheren Eintrags bricht die Kette mathematisch.
Dateien: chain/*
Der Kettenkopf wird über OpenTimestamps in der Bitcoin-Blockchain verankert. Nach Bestätigung wird der Zeitstempel vom gesamten Bitcoin-Netzwerk bewahrt. Rückdatieren wird undurchführbar.
Dateien: anchor/*
RFC-3161-Zeitstempel einer EU-qualifizierten TSA, mit der vollständigen Zertifikatskette und einem eingefrorenen EU-Vertrauenslisten-Snapshot. Rechtlich in EU/EWR nach Verordnung (EU) 910/2014 anerkannt.
Dateien: timestamp/*
Alle 4 Verifizierungen BESTANDEN → das Paket ist kryptografisch intakt, nicht nur vertrauenswürdig. Jede Schicht kann auch unabhängig verifiziert werden, um eine bestimmte Eigenschaft zu beweisen: Dateiintegrität, Kettenkonsistenz, Existenzzeitpunkt (zweifach — durch Bitcoin und durch die EU-akkreditierte TSA).
So verifizieren Sie (das 4-Schritte-Verfahren)
Die zweisprachige
README.md
im ZIP führt Sie mit kopierbaren Befehlen durch die Verifizierung. Der Prozess entspricht eins zu eins den vier obigen Integritätsschichten:
- Schritt 1 — Dateiintegrität — Ein python3-Skript liest die manifest.json, berechnet den SHA-256 jeder Datei neu und vergleicht. BESTANDEN = nichts im Paket wurde hinzugefügt, entfernt oder verändert.
- Schritt 2 — eIDAS-qualifizierter Zeitstempel — openssl ts -verify gegen eidas.tsr + eidas_payload.json + die gebündelte tsa_certs.pem. (Eine reine Python-Alternative ist für Umgebungen ohne openssl enthalten.) BESTANDEN = die erfassten Daten existierten zum gestempelten Zeitpunkt, und die Signatur stammt von der im EU-Vertrauenslisten-Snapshot eingetragenen qualifizierten TSA.
- Schritt 3 — Bitcoin-Anker — ots verify anchor/anchor_receipt.ots -d <payload_sha> — oder laden Sie die Quittung auf opentimestamps.org hoch oder prüfen Sie die Bitcoin-Transaktion direkt in einem öffentlichen Block-Explorer. 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 | event_type | proof_id | data_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 erfordert zusätzlich Netzwerkzugang (oder verifizieren Sie alternativ einfach die Transaktions-ID in einem öffentlichen Explorer); die Schritte 1, 2 und 4 funktionieren vollständig offline.
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 die Bitcoin-OpenTimestamps-Verifizierung (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.
Best Practices für das Teilen
- Teilen Sie das ZIP genau so, wie es exportiert wurde. Nicht neu zippen, Dateien umbenennen oder „aufräumen“. Die Verifizierung hängt davon ab, dass jeder Dateipfad und jedes Byte identisch mit dem Erzeugten ist.
- Speichern Sie nach Möglichkeit auf Nur-Lese- oder Write-once-Medien. Hilft, die Beweiskette nachzuweisen, falls der Beweis später angefochten wird.
- Halten Sie Proof-ID und Erfassungszeitstempel in Ihren Notizen oder auf dem Deckblatt sichtbar. Sie sind auch in der proof.json und report.pdf enthalten, aber eine Schnellreferenz erleichtert die Navigation in Fallakten.
- Verweisen Sie Prüfer auf die README.md im ZIP. Sie enthält kopierbare Verifizierungsbefehle auf Englisch und Tschechisch und erklärt genau, was jedes BESTANDEN bedeutet.
- Extrahieren Sie keine einzelnen Dateien zum Weiterleiten. Die Verifizierung erfordert das vollständige Paket — Manifest, Kette, Anker, eIDAS-Kit. Senden Sie immer das komplette ZIP.
Exportieren Sie ein Beweis-ZIP aus einem Beweis und verifizieren Sie es dann. Sie sehen genau, wie streng die Integritätsprüfungen sind — und wie das Paket sogar vollständig offline verifiziert.
Keine Rechtsberatung. Die Verwertbarkeit hängt von der Rechtsordnung und den Umständen ab.
Weiter mit: Browser-Widget — installieren, API-Schlüssel verbinden, hinter dem Login erfassen (Enterprise & Business).