Threat-Model, offen gelegt
Was wortlaut beweist.
Und was nicht.
Wir stellen dieses Threat-Model bewusst an den Anfang. Der Einwand kam aus der Fachöffentlichkeit selbst, und er ist berechtigt. Ihn vorwegzunehmen macht uns glaubwürdiger, nicht schwächer.
Die zentrale Unterscheidung
Integrität ist nicht Authentizität.
Ein kryptografischer Hash (SHA-256 über die Rohbytes) plus Fremdarchivierung beweist: „Dieser Wortlaut ist seit dem Moment des Archivierens unverändert, und genau dieses Zitat wurde wiedergefunden." Das ist Integrität ab Archivierung.
Er beweist nicht, dass die Quelle im Moment der Erfassung echt war (Deepfake, gefälschtes Konto, manipuliertes Dokument), dass tatsächlich die angegebene Person das Gesagte geäußert hat, oder dass niemand die Übertragung manipuliert hat (Man-in-the-Middle). Das ist Authentizität der Quelle — ein eigenständiges Problem, das vor dem Hashen liegt. Wer beides in einen Topf wirft, verspricht zu viel. Wir tun das nicht.
Auf einen Blick
Was wir beweisen — und was nicht.
| Frage | Beweist wortlaut das? | Wodurch |
|---|---|---|
| Ist der Wortlaut seit der Erfassung unverändert? | Ja, kryptografisch | SHA-256 über Rohbytes, WORM-Ledger, /verify |
| War dieser Wortlaut zum Zeitpunkt T unter Quelle Q öffentlich abrufbar? | Ja, mehrfach bezeugt | Zeitstempel + Wayback + archive.today + eigenes WORM |
| Wurde nachträglich rückdatiert oder umgeschrieben? | Nein — das wird sichtbar | Append-only-Log, unabhängige Archive, externe Verankerung |
| Gibt die Maschine je einen umformulierten Text aus? | Nein, ausgeschlossen | Ausgabe = nur wörtliche DB-Spans, kein generierter Fließtext |
| War die Quelle im Erfassungsmoment authentisch (kein Deepfake)? | Nein — kein absoluter Beweis | aber erschwert & sichtbar gemacht durch die Kette unten |
| Ist die Aussage inhaltlich „wahr" / „richtig"? | Nein — nicht unsere Aufgabe | Die Maschine urteilt nicht; sie belegt Wortlaut & Herkunft |
Die beiden „Nein" in den unteren Zeilen sind kein Versäumnis, sondern eine bewusste Grenze. wortlaut ist eine Chain of Custody (Beweiskette), kein Richter. Die Stärke liegt nicht in einem einzelnen magischen Beweis, sondern in der Konvergenz unabhängiger Belege plus Transparenz über die eigene Grenze. Ein Fälscher müsste nicht ein Glied brechen, sondern mehrere unabhängige gleichzeitig — und selbst dann würde die Abweichung zwischen den Zeugen zum Alarm.
Die Beweiskette
Fünf Glieder, kein Silver Bullet.
Gegen das Authentizitäts-Problem vor dem Hashen setzen wir keine einzelne Lösung, sondern eine Kette. Jedes Glied hebt die Messlatte für Fälschung.
- Erfassungs-Provenienz — das WOHER. Wir hashen nicht nur den Inhalt, sondern archivieren den Kontext der Erfassung mit: Quell-URL, TLS-Zertifikatskette der Quelldomain (belegt, dass wirklich mit dem verifizierten Kanal gesprochen wurde), HTTP-Header, exakter Zeitstempel, Version des Erfassungs-Agenten.
- Vertrauenswürdiger Zeitstempel + Append-only-Log — das WANN. Ein manipulationssicheres, nur-anhängendes Ledger mit vertrauenswürdigem Zeitstempel schließt nachträgliches Rückdatieren aus. Optional extern verankert (z. B. OpenTimestamps — nur der Hash, batch-weise, keine Inhalte, DSGVO-neutral).
- Mehrere unabhängige Zeugen — das WER-BEZEUGT-ES. Jede Erfassung geht gleichzeitig an mehrere unabhängige Dritte (Wayback, archive.today) plus eigenes WORM. Weichen die Kopien voneinander ab, ist genau das ein Manipulations-Alarm — kein einzelner Archiv-Betreiber ist alleiniger Vertrauensanker.
- Verankerung an offiziellen Kanälen + native Signaturen. Wir erfassen nur aus verifizierbaren Quellen (amtliche Parlaments-/Pressekanäle, verifizierte Konten). Wo die Quelle selbst signiert (signierte PDFs, DKIM bei E-Mail), archivieren und prüfen wir diese Signatur mit — das hebt „öffentlich abrufbar" näher an „nachweislich von der Quelle".
- Offenes Threat-Model. Wir sagen ausdrücklich, was wortlaut beweist und was nicht. Diese Seite ist dieses Glied.
Konkrete Angriffe
Was die Kette leistet.
| Angriff | Rein per Hash abgedeckt? | Was die Kette leistet |
|---|---|---|
| Nachträgliche Änderung eines archivierten Zitats | Ja | Hash-Mismatch bei /verify, sofort erkennbar |
| Rückdatieren / heimliches Umschreiben der Historie | Teilweise | Append-only + externe Verankerung + unabhängige Archive machen es sichtbar |
| Deepfake / gefälschtes Video oder Audio als Quelle | Nein | Verankerung an offiziellen Kanälen (4) + Konvergenz mehrerer Zeugen (3); Restrisiko bleibt und wird benannt |
| Gefälschte / gespoofte Quell-Website | Nein | TLS-Kette + Erfassungs-Provenienz (1) bindet an das echte WOHER |
| Man-in-the-Middle beim Scrapen | Nein | TLS-Prüfung (1) + mehrere unabhängige Erfassungspfade (3) |
| Fake-„Quellen" ins Korpus einschleusen (Poisoning) | — | Nur verifizierte Ingest-Adapter; nicht-amtliche Zuordnung braucht Human-Verify, bevor sie zitierfähig ist |
| „Fasse zusammen" → erfundenes Zitat | Nicht nötig | Architektur schließt es aus: Ausgabe = nur wörtliche DB-Spans, das LLM formuliert nie den zitierfähigen Text |
Ehrlich bleibt ehrlich
Die Grenzen, die wir offen nennen.
Ein hinreichend perfekter Deepfake, der über einen offiziellen, verifizierten Kanal verbreitet wird, würde von uns als authentisch archiviert — wortlaut belegt dann korrekt, dass er dort stand, nicht, dass er echt ist. Diese Unterscheidung geben wir immer transparent mit.
Absolute Quell-Authentizität ist kein technisch lösbares Einzelproblem. Wir liefern Nachvollziehbarkeit und Konvergenz, nicht Allwissenheit. Genau deshalb bleibt der menschliche Faktor (Human-Verify für nicht-amtliche Zuordnungen) Teil des Systems, nicht wegautomatisiert.
Mehr im offenen technischen Threat-Model und in der Rechts-Dokumentation. Diese Frage — Integrität vs. Authentizität — ist unser erstes offenes Architektur-Thema. Wer an deterministischen Event-Ledgern, Beweisketten oder Threat-Modeling arbeitet, ist genau richtig: mitbauen.