Technik

Wie PublicEvidence im Hintergrund arbeitet

Fingerabdruck, Zeitstempel, Beweispaket: die Technik hinter PublicEvidence – verständlich erklärt, mit Datenfluss, Grenzen und Wegen zur unabhängigen Prüfung.

Stand: 29. Oktober 2026

Diese Seite beschreibt das technische Konzept. Noch nicht live verfügbare Funktionen sind als „Geplant“ oder „Entwurf“ gekennzeichnet.

IDEE

Ein Fingerabdruck. Ein Zeitstempel. Ein Beweis, der dir gehört.

Jede digitale Datei lässt sich in einen kurzen Code umrechnen – ihren Fingerabdruck. Ändert sich auch nur ein Zeichen, entsteht ein völlig anderer Code.

Diesen Fingerabdruck lassen wir von öffentlichen Systemen zeitlich festhalten. So lässt sich später belegen, dass es genau diese Datei spätestens zu einem bestimmten Zeitpunkt gab. Die Datei selbst bleibt bei dir.

Der Nachweis wird als Beweispaket gespeichert und gehört dir. Er ist mit offenen Werkzeugen prüfbar, auch ohne PublicEvidence.

Nur der Fingerabdruck wandert

Deine Datei, ihr Name und dein Passwort verlassen dein Gerät nicht.

Der Beweis liegt bei dir

Das Beweispaket ist unabhängig prüfbar und nicht an ein Konto gebunden.

Standards statt Eigenbau

OpenTimestamps, SHA-256 und offene Formate bleiben auch ohne uns nutzbar.

ABLAUF

Vom Klick zum prüfbaren Beweispaket

Datei wählen

Du wählst ein Dokument auf deinem Gerät. Es wird nicht hochgeladen.

Fingerabdruck berechnen

Dein Browser berechnet lokal einen SHA-256-Fingerabdruck der Datei.

Zeitstempel anfordern

Nur der Fingerabdruck geht an öffentliche Zeitstempeldienste. Sie verankern ihn in der Bitcoin-Blockchain.

Beweispaket sichern

Du lädst das Paket herunter, bewahrst es mit der Datei auf und kannst es später jederzeit prüfen.

Lebenszyklus eines Nachweises

Stufe	Was passiert
Erstellt	Fingerabdruck berechnet und Nachweisdatei erzeugt.
Eingereicht	Ein oder mehrere Calendar-Server haben den Fingerabdruck angenommen.
Verankert	Der Fingerabdruck steckt in einer Bitcoin-Transaktion und wurde in einen Block aufgenommen.
Verifiziert	Die gesamte Kette wurde unabhängig geprüft.

Zwischen „Eingereicht“ und „Verankert“ vergehen in der Regel einige Stunden, weil viele Fingerabdrücke gemeinsam in Bitcoin eingetragen werden.

Für Nerds: Sequenz im MVP

Browser                        PublicEvidence-Backend        Calendar-Server        Bitcoin
  | 1. Datei lokal einlesen          |                              |                    |
  | 2. SHA-256(Datei) = h            |                              |                    |
  | 3. Nachweis anfordern (h) ------>| 4. h weiterreichen ---------->|                    |
  |                                  |<-- 5. Pending-Proof ---------|                    |
  |<-- 6. Proof (.ots, pending) -----|                              | 7. sammeln, Merkle-|
  | 7. Download Beweispaket          |                              |    Baum, Tx ------>| Block
  |                     ... Stunden ...                              |                    |
  | 8. Upgrade anfragen ------------>| 9. Upgrade holen ----------->|                    |
  |<-- 10. vollstaendiger Proof -----|<-----------------------------|                    |
  | 11. Verifikation gegen Block-Header (lokal oder per Node/Explorer)

BAUSTEINE

Die Bausteine im Hintergrund

Jeder Baustein hat eine klare Aufgabe. Was noch nicht umgesetzt ist, ist ausdrücklich markiert.

Digitaler Fingerabdruck

Verfügbar

Ein SHA-256-Hash kennzeichnet die Datei eindeutig. Aus ihm lässt sich die Datei nicht zurückrechnen.

Technische Details

Hashfunktion SHA-256 (FIPS 180-4), 32 Byte, hexadezimale Darstellung.
Berechnung im Browser in einem Web Worker; große Dateien werden blockweise gehasht.
Dateiname, Datum und Größe fließen nicht in den Fingerabdruck ein – nur die Bytes.
Mehrere Dateien werden über ein kanonisches Manifest (RFC 8785) zusammengefasst.

Zeitstempel über OpenTimestamps

Verfügbar

Calendar-Server bündeln viele Fingerabdrücke in einem Merkle-Baum und verankern die Wurzel in einer Bitcoin-Transaktion.

Technische Details

Offenes Protokoll OpenTimestamps mit Open-Source-Referenzclient.
Zuerst entsteht eine Zusage (pending), nach der Bitcoin-Bestätigung folgt das Upgrade zum vollständigen Nachweis.
Mehrere unabhängige Calendar-Server werden parallel angefragt.
Aussage: Die Datei existierte spätestens zur Zeit des Blocks. Bitcoin-Blockzeiten sind keine präzisen UTC-Angaben.

Offizieller Zeitstempel

Geplant

Ein zugelassener europäischer Vertrauensdiensteanbieter bestätigt den Zeitpunkt mit einem qualifizierten Zeitstempel.

Technische Details

Standard RFC 3161; Antwort als signiertes Token (.tsr/.tst).
Rechtsrahmen eIDAS (VO (EU) Nr. 910/2014), Art. 41/42.
Übertragen wird nur der Fingerabdruck, nie die Datei.
PublicEvidence ist nicht selbst qualifizierter Vertrauensdiensteanbieter.

Beweispaket

Verfügbar

Ein Ordner mit Manifest, Zeitstempel, Prüfanleitung und – falls gebucht – dem offiziellen Token. Deine Datei ist nicht enthalten.

Technische Details

Offene oder dokumentierte Formate, damit die Prüfung ohne PublicEvidence möglich bleibt.
Enthält README, manifest.json, Prüfsummen, Blockchain-Nachweis und Prüfanleitung.
Fehlende Teile werden maschinenlesbar gekennzeichnet.
Keine Schlüssel oder Passwörter im Paket.

Commit & Reveal

Entwurf

Du kannst etwas festhalten, ohne den Inhalt zu zeigen, und ihn später freigeben. Ein geheimer Zufallswert verhindert, dass kurze Inhalte erraten werden.

Technische Details

commitment = SHA-256("PE-commit-v1" ‖ salt ‖ fileHash).
Gestempelt wird das Commitment, nicht der Datei-Hash.
Der Salt gehört nicht ins öffentliche Paket und muss wie ein Passwort verwahrt werden.

Verschlüsselung

Geplant

Dokumente werden auf deinem Gerät verschlüsselt, bevor sie gespeichert werden. Den Schlüssel kennst nur du.

Technische Details

AES-256-GCM über die Web Crypto API, keine eigene Kryptografie.
Passwortableitung mit Argon2id (WASM), Fallback PBKDF2-HMAC-SHA-256.
Blockweise Verschlüsselung mit authentifizierten Metadaten im Dateikopf.
Keine Wiederherstellung durch den Betreiber. Passwortverlust bedeutet Datenverlust.

Kopien an mehreren Orten

Geplant

Nachweise und verschlüsselte Dokumente lassen sich redundant ablegen. Fällt ein Ort aus, bleiben die anderen.

Technische Details

Adressierung über den SHA-256 des Chiffretexts (Content Addressing).
Standardmäßig wird nur der Nachweis verteilt, nicht das Dokument.
Jede Kopie wird beim Abruf erneut geprüft.
Verteilte Inhalte lassen sich technisch kaum zurückholen oder löschen.

DATENFLUSS

Was verlässt dein Gerät?

Im MVP verlässt nur der Fingerabdruck dein Gerät. Nicht die Datei, nicht ihr Name, nicht dein Passwort.

Daten	Bleibt lokal	An PublicEvidence	An Zeitstempeldienste
Deine Datei	✓	–	–
Dateiname, Größe, Datum	✓	–	–
Fingerabdruck / Commitment	✓	✓	✓
Beweispaket	✓	–	–
Salt, Passwort, Schlüssel	✓	–	–
IP-Adresse und Anfragezeitpunkt	–	✓	✓

PublicEvidence nimmt im MVP nur Hex-Strings fester Länge entgegen und speichert keine Dateien. Calendar-Server und Betreiber sehen technisch bedingt die IP-Adresse der Anfrage.

Für Nerds

Das Backend ist ein Relais zu den Calendar-Servern und speichert ausstehende Nachweise befristet.
Fingerabdrücke werden strikt validiert (^[0-9a-f]{64}$).
Keine Drittanbieter-Skripte, Schriften oder Analyse-Dienste im Frontend.
Logs enthalten keine Fingerabdrücke zusammen mit IP-Adressen länger als nötig.

VERTRAUEN

Wem musst du vertrauen?

Das Ziel ist, so wenig Vertrauen wie möglich in uns zu brauchen. Wo Vertrauen trotzdem nötig ist, steht es hier.

Du vertraust …	… für	Wie begrenzt
Mathematik (SHA-256, AES-256-GCM)	Fingerabdruck, Verschlüsselung	Standardisierte, vielfach geprüfte Verfahren
Bitcoin-Netzwerk	Zeitgrenze und Unveränderbarkeit des Eintrags	Dezentral; Block-Header sind unabhängig prüfbar
Calendar-Servern	Zusage bis zur Verankerung	Mehrere unabhängige Server; vollständig erst nach Verankerung
Qualifiziertem Anbieter (geplant)	Offizielle Zeitangabe	Zulassung in der EU Trusted List; Token und Zertifikate im Paket
Deinem Browser und Gerät	Korrekte lokale Berechnung	Eigene Verantwortung; Prüfung mit unabhängigen Werkzeugen möglich
PublicEvidence (Web-Frontend)	Auslieferung des Programmcodes	CSP, SRI, reproduzierbare Builds, später Offline-Client

Der ehrliche Punkt: Programmcode aus dem Web

Bei einer Webseite liefert der Server den Code, der deine Datei hasht oder verschlüsselt. Ein kompromittierter Server könnte schädlichen Code ausliefern. Das lässt sich verringern, aber nicht vollständig ausschließen.

Web-App

Du vertraust dem aktuell ausgelieferten Code.

Open-Source-Client

Code und Build sind öffentlich prüfbar; veröffentlichte Prüfsummen ermöglichen den Abgleich.

Signierter Offline-Client (geplant)

Unabhängig vom Webcode, empfohlen für besonders vertrauliche Dokumente.

PRÜFEN OHNE UNS

Selbst prüfen – ohne PublicEvidence

Du brauchst weder uns noch ein Konto. Mit frei verfügbarer Software kann jeder Nachweis geprüft werden.

Datei und Beweispaket bereithalten.
Fingerabdruck der Datei berechnen und mit manifest.json vergleichen.
Blockchain-Nachweis nach der Verankerung prüfen.
Optional den qualifizierten Zeitstempel prüfen (geplant).

Befehle (Beispiele)

1) Fingerabdruck berechnen

sha256sum vertrag.pdf
# macOS: shasum -a 256 vertrag.pdf
# Windows PowerShell:
Get-FileHash -Algorithm SHA256 vertrag.pdf

2) Nachweis aktualisieren

ots upgrade blockchain/proof.ots

3) Nachweis anzeigen und prüfen

ots info blockchain/proof.ots
ots verify blockchain/proof.ots

Prüfergebnisse

Ergebnis	Bedeutung
Bestanden	Fingerabdruck stimmt überein, Nachweis gültig, Zeitpunkt genannt.
Ausstehend	Noch nicht in einem Bitcoin-Block verankert – später aktualisieren.
Datei weicht ab	Die Datei ist nicht mehr die gestempelte Fassung.
Nicht prüfbar	Daten fehlen oder Infrastruktur ist nicht erreichbar.
Ungültig	Nachweis beschädigt oder passt nicht zum Paket.

Die konkreten Befehle werden vor dem Livegang mit echten Testnachweisen auf Linux, macOS und Windows geprüft. Eine Anleitung liegt dem Beweispaket bei.

SICHERHEIT

Sicherheit und Datenschutz

Wir bauen auf bewährte Standards, speichern so wenig wie möglich und benennen offen, was wir nicht können.

Manipulierter Webcode

CSP, Subresource Integrity, reproduzierbare Builds, signierte Releases und ein geplanter Offline-Client verringern das Risiko.

Bösartige Dateien

Dateiinhalte werden nicht auf dem Server verarbeitet. Im Browser findet nur Hashing statt.

Eingaben am Backend

Strikte Validierung, Größenlimits und parametrisierte Datenbankabfragen.

Missbrauch und Last

Rate Limits, begrenzte Parallelität und optionale Schutzmaßnahmen bei Auffälligkeiten.

Ausfall eines Calendar-Servers

Mehrere unabhängige Server, Wiederholungen und eine sichtbare Statusanzeige.

Lieferkette

Wenige, gepinnte Abhängigkeiten und automatisierte Prüfung vor jedem Release.

Datenschutz in der Praxis

Datensparsamkeit: keine Konten im MVP, keine Tracking-Cookies, keine Drittanbieter-Einbindungen.
Logs enthalten nur technisch Notwendiges und werden kurz aufbewahrt.
Die Blockchain enthält nur kryptografische Werte, keine Dateien oder Namen.
Hosting in der EU; Auftragsverarbeitung und Aufbewahrungsfristen werden vor dem Livegang dokumentiert.

GRENZEN

Was ein Nachweis kann – und was nicht

Ein Nachweis ist stark, aber nicht allmächtig. Diese Grenzen gehören zur Wahrheit dazu.

Thema	Was gilt
Was bewiesen wird	Eine bestimmte Datei existierte spätestens zu einem bestimmten Zeitpunkt und ist seither unverändert.
Was nicht bewiesen wird	Wahrheit des Inhalts, Urheberschaft, Eigentum, Identität, Ort oder Aufnahmedatum.
Zeitgenauigkeit	Blockchain: obere Zeitgrenze, keine präzise Uhrzeit. Qualifizierter Zeitstempel: signierte Zeitangabe des Ausstellers.
Wartezeit	Der vollständige Blockchain-Nachweis liegt in der Regel nach einigen Stunden vor.
Rechtliche Wirkung	Technischer Nachweis. Eine besondere gesetzliche Vermutung gibt es nur beim qualifizierten Zeitstempel.
Keine Beglaubigung	Kein Ersatz für Notar, Behörde, elektronische Signatur oder Rechtsberatung.
Scans	Ein Nachweis zeigt die Existenz des Scans, nicht die Echtheit der Urkunde.
Langzeit	Nachweise sind mit offenen Werkzeugen prüfbar. Eine aktive Langzeitbeweiserhaltung ist nicht Teil des MVP.
Kryptografische Alterung	Algorithmen können schwächer werden. Nachweise nennen ihr Verfahren; eine garantierte Erneuerung gibt es nicht.
Nicht rücknehmbar	Verankerte Nachweise und verteilte Kopien lassen sich nicht zurückholen.
Rolle von PublicEvidence	Softwareplattform für Nachweise – kein qualifizierter Vertrauensdiensteanbieter und kein Archivdienst im Rechtssinn.

Ob und wie ein Nachweis in einem Verfahren verwendet werden kann, entscheidet im Einzelfall das zuständige Gericht.

STANDARDS

Offene Standards und Quellen

PublicEvidence setzt auf dokumentierte, unabhängig prüfbare Verfahren.

Thema	Standard / Projekt
Hashfunktion	SHA-256, FIPS 180-4 (NIST)
Kanonisches JSON	RFC 8785 (JSON Canonicalization Scheme)
Zeitstempel (Blockchain)	OpenTimestamps (offenes Protokoll und Open-Source-Client)
Qualifizierter Zeitstempel	RFC 3161, eIDAS (EU) Nr. 910/2014, EU Trusted Lists
Verschlüsselung	AES-GCM (NIST SP 800-38D), Web Crypto API, Argon2 (RFC 9106)
Zufall	crypto.getRandomValues() (Web Crypto)
Webseitensicherheit	OWASP ASVS, Content Security Policy, Subresource Integrity
Langzeitnachweise	ETSI-Normen zu Evidence Records und Archiv-Zeitstempeln, RFC 4998

Ziel ist, Client und Prüfwerkzeug zu veröffentlichen. Lizenz und Zeitpunkt der Veröffentlichung sind noch offen.

ENTWICKLUNG

Technik-Roadmap

Die Reihenfolge folgt Risiko und Nutzen: zuerst der prüfbare Basisnachweis, dann Komfort und zusätzliche Schutzschichten.

Basis

Zuerst

Lokaler Fingerabdruck, OpenTimestamps-Nachweis, Download des Beweispakets, Aktualisierung und Prüfung ohne Konto.

Prüfung

Zuerst

Prüfseite im Browser, Offline-Anleitung und Testfälle mit manipulierten Dateien.

Geheimer Nachweis

Danach

Commit & Reveal mit Salt.

Offizieller Zeitstempel

Nach Freigabe

RFC-3161-Anbindung an einen externen QTSP, Token und Prüfdaten im Paket.

Verschlüsselung

Nach Prüfung

Clientseitige Verschlüsselung, offenes Format und Offline-Entschlüsselung.

Kopien

Nach Prüfung

Verteilte Ablage von Nachweisen, später von verschlüsselten Dokumenten.

Offline-Client

Später

Signierte Desktop- und CLI-Anwendung.

Eigener Aggregator

Bei Bedarf

Eigene Calendar-Infrastruktur bei hohem Volumen.

Die Roadmap beschreibt die geplante Reihenfolge, keine zugesagten Termine.

TECHNIK-FAQ

Fragen von Nerds

Warum Bitcoin und nicht eine eigene Blockchain?

Eine eigene Kette wäre nur so vertrauenswürdig wie ihr Betreiber. Bitcoin ist öffentlich, dezentral und vielfach beobachtet. PublicEvidence betreibt bewusst keine eigene Blockchain.

Kann PublicEvidence meine Daten lesen?

Im MVP erhalten wir nur den Fingerabdruck. Auch beim geplanten verschlüsselten Ablegen sollen wir den Klartext nicht lesen können. Wegen der Auslieferung des Webcodes gilt dieses Versprechen mit den Einschränkungen im Abschnitt Vertrauen.

Was, wenn die Calendar-Server ausfallen?

Der Nachweis wird bei mehreren Servern beantragt. Bereits verankerte Nachweise sind unabhängig von Calendar-Servern prüfbar. Nur die Aktualisierung eines ausstehenden Nachweises braucht einen Server.

Warum nicht einfach eine Signatur?

Eine Signatur belegt, wer etwas unterschrieben hat, nicht wann es mindestens existierte. Zeitstempel belegen die Existenz zu einem Zeitpunkt. Beides lässt sich kombinieren.

Was passiert, wenn SHA-256 irgendwann gebrochen wird?

Nachweise nennen ihren Algorithmus. Für ältere Nachweise ist eine Erneuerung durch zusätzliche Zeitstempel mit stärkeren Verfahren vorgesehen, solange der alte Nachweis noch als gültig gilt. Eine Garantie gibt es nicht.

Ist der Code offen?

Ziel ist ein offener Client und ein offenes Prüfwerkzeug mit öffentlicher Formatspezifikation. Lizenz und Zeitpunkt sind noch offen.

Warum nicht gleich alles über einen offiziellen Zeitstempeldienst?

Der offizielle Zeitstempel kostet Geld und bindet an einen Anbieter. Die Blockchain-Variante ist kostenlos und unabhängig. Beide ergänzen sich; der offizielle Zeitstempel ist für Fälle gedacht, in denen es auf gesetzliche Beweiswirkung ankommt.

Technik verstanden? Dann sichere den ersten Nachweis.

Kostenlos starten, ohne Konto. Deine Datei bleibt auf deinem Gerät.

Nachweis erstellen →Zur Startseite