← Zurück zu allen Artikeln

Hash-Ketten und Manipulationserkennung: wie ein einziges geändertes Byte ein ganzes Archiv entwertet

SealDoc Team · · 8 Min. Lesedauer

Wenn jemand sagt, ein Dokumentenarchiv sei “manipulationserkennbar”, ist die Aussage präzise: Jede Änderung an einem beliebigen Datensatz erzeugt eine erkennbare Inkonsistenz. Nicht manipulationssicher: Das ist eine andere und stärkere Aussage. Manipulationserkennbar heißt, dass Sie die Änderung finden können, wenn das Archiv verändert wurde.

Hash-Ketten sind die Standardkonstruktion, um diese Eigenschaft zu erreichen. Sie sind nicht neu (das Konzept ist Jahrzehnte älter als die Blockchain), werden aber häufig missverstanden, was sowohl zu übermäßigem Vertrauen als auch zu zu seltenem Einsatz führt.

Dieser Artikel erklärt, wie Hash-Ketten funktionieren, was sie garantieren, was sie nicht garantieren und warum die konkreten Implementierungsentscheidungen zählen.

Was ein kryptografischer Hash ist

Eine kryptografische Hash-Funktion nimmt eine Eingabe beliebiger Länge und erzeugt eine Ausgabe fester Länge, den sogenannten Hash oder Digest. SHA-384 erzeugt eine 384-Bit-Ausgabe (48 Byte), die üblicherweise als 96 Hexadezimalzeichen dargestellt wird.

Drei Eigenschaften machen Hash-Funktionen für die Manipulationserkennung nützlich:

Determinismus. Dieselbe Eingabe erzeugt immer dieselbe Ausgabe. Wenn Sie dasselbe Dokument zweimal hashen, erhalten Sie denselben Hash.

Lawineneffekt. Eine kleine Änderung der Eingabe erzeugt eine völlig andere Ausgabe. Ändern Sie ein Byte in einem Dokument von 10.000 Byte, entsteht ein Hash, der dem ursprünglichen in nichts ähnelt. Es gibt keine Möglichkeit vorherzusagen, wie der neue Hash aussehen wird.

Einwegfunktion. Aus einem Hash lässt sich die Eingabe rechnerisch nicht rekonstruieren. Sie können nicht vom Hash auf das Dokument zurückrechnen.

Die dritte Eigenschaft macht Hash-Ketten verbindlich: Sobald Sie einen Hash veröffentlichen oder festhalten, haben Sie sich auf den Inhalt festgelegt, der ihn erzeugt hat, ohne den Inhalt selbst preiszugeben.

Die Grundkonstruktion

Eine Hash-Kette verknüpft eine Abfolge von Ereignissen so, dass jedes Ereignis von allen vorherigen Ereignissen abhängt.

In der Implementierung von SealDoc enthält ein Nachweisereignis:

  • Den Ereignistyp (z. B. vault.ingested, anchor.rfc3161)
  • Eine Sequenznummer
  • Einen Zeitstempel
  • Ereignisspezifische Details (als kanonisches JSON)
  • Den Hash des vorherigen Ereignisses
  • Den Hash dieses Ereignisses, berechnet über alle oben genannten Felder

Der Hash jedes Ereignisses enthält den Hash des vorherigen Ereignisses. Um den Hash von Ereignis N zu reproduzieren, benötigen Sie also den exakten Inhalt von Ereignis N und den exakten Hash von Ereignis N-1. Der Hash von Ereignis N-1 hing von Ereignis N-2 ab, und so weiter zurück bis zum ersten Ereignis.

Das erste Ereignis verwendet einen festen Genesis-Wert als “vorherigen Hash”: eine allgemein bekannte Konstante, die jeder verifizieren kann.

So entsteht eine Kette, in der gilt:

Hash(Event 1) = H("vault.ingested" | seq:1 | ts:... | details:... | genesis)
Hash(Event 2) = H("anchor.rfc3161" | seq:2 | ts:... | details:... | Hash(Event 1))
Hash(Event 3) = H("vault.storage-lock.applied" | seq:3 | ts:... | details:... | Hash(Event 2))

Was passiert, wenn jemand sie manipuliert

Angenommen, ein Angreifer will die Details von Ereignis 1 ändern. Er ändert ein Feld im Ereignis und berechnet dann den Hash von Ereignis 1 neu. Der neue Hash unterscheidet sich vom ursprünglichen.

Der Hash von Ereignis 2 wurde aber mit dem ursprünglichen Hash von Ereignis 1 berechnet. Der Angreifer muss nun den Hash von Ereignis 2 mit dem neuen Hash von Ereignis 1 neu berechnen. Das ergibt einen anderen Hash für Ereignis 2.

Jetzt hat Ereignis 3 den falschen vorherigen Hash. Und so weiter für jedes nachfolgende Ereignis.

Um die Änderung unerkennbar zu machen, muss der Angreifer die Hashes jedes Ereignisses ab der manipulierten Stelle neu berechnen. In einem lokalen, in sich geschlossenen System ist das möglich. Die Kette allein verhindert das nicht.

Deshalb kommt es auf die Verankerung an.

Verankerung: die Kette extern verifizierbar machen

Eine Hash-Kette, die nur in Ihrer eigenen Datenbank existiert, beweist die Integrität innerhalb Ihres eigenen Systems. Ein Angreifer, der Ihre Datenbank kontrolliert, kann die gesamte Kette umschreiben. Die Kette muss an etwas verankert werden, das außerhalb Ihrer Kontrolle liegt.

Der Standardmechanismus ist ein RFC 3161-Zeitstempel. Der Ablauf sieht so aus:

  1. Zum Zeitpunkt der Dokumenterstellung den Hash des Nachweisereignisses berechnen.
  2. Diesen Hash an eine unabhängige Time Stamping Authority (TSA) senden.
  3. Die TSA signiert eine Antwort, die Ihren Hash, den Zeitstempel der TSA und die Identität der TSA enthält. Diese signierte Antwort ist das Zeitstempel-Token.
  4. Das Zeitstempel-Token zusammen mit der Hash-Kette speichern.

Das Zeitstempel-Token ist mit dem privaten Schlüssel der TSA signiert. Die Zertifikatskette der TSA ist öffentlich verifizierbar. Jeder, der das Dokument, den ursprünglichen Hash und das Zeitstempel-Token besitzt, kann unabhängig verifizieren, dass das Dokument zu diesem Zeitpunkt in diesem Zustand existierte, ohne Ihnen überhaupt vertrauen zu müssen.

Jetzt wird das Problem des Angreifers schwieriger. Um Ereignis 1 unerkennbar zu ändern, muss er:

  1. Das Ereignis ändern und alle nachgelagerten Hashes neu berechnen.
  2. Für den neuen Hash einen neuen RFC 3161-Zeitstempel von einer vertrauenswürdigen TSA beschaffen.

Der zweite Schritt ist rückwirkend unmöglich. Der Zeitstempel der TSA enthält eine Zeitangabe. Ein Zeitstempel, der behauptet, das geänderte Dokument habe zum ursprünglichen Zeitpunkt existiert, müsste von der TSA zu diesem ursprünglichen Zeitpunkt ausgestellt worden sein, und das kann der Angreifer im Nachhinein nicht arrangieren.

Das bedeutet “manipulationserkennbar” in der Praxis: nicht, dass eine Änderung auf physischer Ebene verhindert wird, sondern dass jede Änderung, die ein Angreifer unentdeckt lassen will, entweder die Kompromittierung der Signatur der unabhängigen TSA oder das Umschreiben der Vergangenheit erfordert, und beides ist rechnerisch undurchführbar.

Warum zwei Digests, und welcher wo

SHA-256 ist der am häufigsten verwendete Hash-Algorithmus für diese Art von Anwendung. SealDoc verwendet ihn für die Verarbeitungskette und das Pack-Manifest, und SHA-384 für das Evidence Ledger. Beide laufen für jedes Dokument; sie beantworten unterschiedliche Fragen.

Die Verarbeitungskette kann nicht frei wählen. Ihr Digest ist zugleich der Speicherschlüssel und der Nachrichtenabdruck, den die Time Stamping Authority signiert, sodass die Nachweislinie von den Bytes über den Abdruck bis zum Token verläuft. Ihn zu ändern hieße, jeden gespeicherten Locator und jedes vorhandene Token zu migrieren, und nicht, eine Einstellung umzuschalten.

Das Evidence Ledger entstand später und unterliegt keiner solchen Bindung, deshalb verwendet es den längeren Digest.

Der praktische Unterschied ist die Sicherheitsreserve. SHA-256 gilt derzeit als sicher, aber kryptografische Empfehlungen entwickeln sich weiter. SHA-384 gehört zur selben SHA-2-Familie und wird identisch berechnet, nur mit einem größeren internen Zustand. Für Archive mit langen Aufbewahrungsfristen (7 Jahre für EU-Umsatzsteuerrechnungen, bis zu 20 Jahre für bestimmte Unterlagen des öffentlichen Sektors) zählt diese zusätzliche Reserve.

Der längere Digest verringert außerdem die (ohnehin vernachlässigbare) Wahrscheinlichkeit von Hash-Kollisionen, bei denen zwei verschiedene Dokumente denselben Hash erzeugen. Für Compliance-Archive ist das eine wesentliche Eigenschaft: Zwei verschiedene Rechnungen sollten niemals dieselbe Kennung erzeugen.

Die Kette verifizieren

Die Verifizierung arbeitet vom neuesten Ereignis aus rückwärts. Bei einer Menge von Ereignissen in Sequenzreihenfolge:

  1. Für jedes Ereignis den Hash aus den gespeicherten Feldern neu berechnen: Ereignistyp, Sequenznummer, Zeitstempel, Details und vorheriger Hash.
  2. Den neu berechneten Hash mit dem gespeicherten Hash vergleichen. Stimmen sie überein, wurde der Ereignisinhalt seit der Berechnung des Hashes nicht verändert.
  3. Prüfen, ob der previousHash jedes Ereignisses mit dem gespeicherten Hash des vorangehenden Ereignisses übereinstimmt. Stimmen sie überein, ist die Kette ununterbrochen.
  4. Für jedes Ereignis mit einem RFC 3161-Zeitstempelanker das Zeitstempel-Token gegen die Zertifikatskette der TSA verifizieren.

Der Endpunkt GET /api/vault/{recordId}/verify von SealDoc berechnet jeden Hash neu, prüft jede Verkettung, verifiziert die Signaturen der Ereignisse und meldet den Zeitanker, mit einer Aufschlüsselung pro Ereignis:

{
  "chainValid": true,
  "eventCount": 3,
  "events": [
    {
      "sequenceNo": 1,
      "eventType": "vault.ingested",
      "hashVerified": true,
      "chainLinkVerified": true,
      "signaturePresent": true,
      "signatureVerified": true
    }
  ]
}

hashVerified bedeutet, dass der neu berechnete Hash mit dem gespeicherten Hash übereinstimmt. chainLinkVerified bedeutet, dass der Verweis auf den vorherigen Hash konsistent ist. signatureVerified bedeutet, dass die ECDSA-Signatur über den Ereignis-Hash mit dem bekannten Signaturschlüssel gültig ist.

Eine Kette, in der jedes Ereignis hashVerified: true und chainLinkVerified: true liefert, ist eine Kette, in der keine gespeicherten Daten verändert wurden. Die Anker-Zeitstempel liefern den externen, über die TSA verifizierbaren Nachweis, wann jedes Ereignis stattfand.

Was die Kette nicht garantiert

Manipulationserkennbarkeit ist eine spezifische und begrenzte Eigenschaft. Es lohnt sich, genau zu benennen, was sie abdeckt und was nicht.

Sie verhindert keine Löschung. Eine Hash-Kette erkennt Änderungen an vorhandenen Datensätzen, kann aber nicht erkennen, dass ein Datensatz gelöscht wurde. Wird Ereignis 2 aus einer Kette mit fünf Ereignissen vollständig entfernt, bricht die Kette, aber nur, wenn der Prüfer weiß, dass es fünf Ereignisse sein sollten und nicht vier. Löschung zu verhindern ist eine eigene Aufgabe der Speicherschicht, etwa durch WORM-Speicher.

Sie verhindert nicht, dass das Quellsystem lügt. Wurde das Dokument beschädigt, bevor es in die Pipeline gelangte, legt sich die Hash-Kette auf diese beschädigte Version fest. Die Kette beweist die Integrität ab dem Zeitpunkt der Aufnahme, nicht ab dem Zeitpunkt der Erstellung. Deshalb findet die Validierung (PDF/A-Konformitätsprüfung, Factur-X-Schemavalidierung) statt, bevor der Hash festgeschrieben wird.

Die Kette ist nur so stark wie ihre Anker. Eine Kette ohne externe RFC 3161-Anker ist ein sich selbst versiegelndes System. Sie beweist innere Konsistenz, aber keine zeitliche Bindung. Für jeden ernsthaften Compliance-Anwendungsfall sind Zeitstempel nötig, die bei einer unabhängigen TSA verankert sind.

Die praktische Konsequenz für Entwickler

Wenn Sie eine Dokumenten-Pipeline bauen und Manipulationserkennbarkeit brauchen, ist die Implementierung unkompliziert:

  1. Bei der Aufnahme einen Hash des Dokuments mit SHA-256 oder SHA-384 berechnen.
  2. Den Hash an eine RFC 3161-TSA senden und das zurückgegebene Zeitstempel-Token speichern.
  3. Für jedes nachfolgende Ereignis den Ereignis-Hash mit dem vorherigen Ereignis-Hash verknüpfen.
  4. Die Kette in Append-only-Speicher ablegen (keine Updates oder Löschungen auf der Ereignistabelle).
  5. Einen Verify-Endpunkt bereitstellen, der die Kette bei Bedarf neu berechnet und prüft.

Die konzeptionelle Komplexität ist gering. Die Implementierungskomplexität entsteht durch betriebliche Fragen: Schlüsselverwaltung, Zuverlässigkeit der TSA, Migration der Kette bei einem Wechsel des Hash-Algorithmus und der Umgang mit dem Fall, dass die Übermittlung an die TSA mitten in einer Transaktion fehlschlägt.

SealDoc übernimmt diese Aufgaben als Infrastruktur, sodass Pipelines, die Dokumente über die API leiten, die Kette erhalten, ohne sie selbst implementieren zu müssen. Wenn Sie sie aber selbst bauen, ist das oben Beschriebene die minimal tragfähige Konstruktion.

Der SealDoc Evidence Vault erzeugt für jedes Dokument ein Hash-verkettetes Ereignisprotokoll und fordert einen RFC 3161-Zeitstempel bei einer unabhängigen EU-Time-Stamping-Authority an. Kette und Zeitstempel sind über GET /api/vault/{recordId}/verify verifizierbar, ohne der SealDoc-Infrastruktur vertrauen zu müssen.

← Zurück zu allen Artikeln