Hash-Verkettung: Wie Veränderungen in einer Prozesshistorie erkennbar werden

Was Hash-Verkettung bedeutet

Bei einer linearen Hashkette fließt in die Berechnung jedes neuen Hashwerts neben dem Inhalt des Eintrags auch der Hashwert seines Vorgängers ein. Dadurch wird die Reihenfolge Bestandteil der kryptografischen Bindung.

Wird ein früherer Eintrag nachträglich verändert, stimmt sein neu berechneter Hashwert nicht mehr mit dem im Folgeeintrag verwendeten Wert überein. Die Abweichung setzt sich entlang der nachfolgenden Kette fort. Ob eine intern stimmige Kette noch dem früheren Stand entspricht, hängt vom geschützten Vergleichswert ab.

Ein Hash ist ein digitaler Prüfwert fester Länge, der aus Daten beliebiger Länge berechnet wird. NIST beschreibt sichere Hashalgorithmen als Verfahren, deren Digests dazu verwendet werden können, Veränderungen an Nachrichten seit der Berechnung zu erkennen.^[1] Der Hash verschlüsselt die Daten nicht und erlaubt üblicherweise auch keine Rückgewinnung ihres Inhalts.

Wie eine einfache Hashkette aufgebaut ist

Der erste Eintrag enthält seine fachlichen Daten und einen definierten Startwert. Aus dieser festgelegten Darstellung wird der erste Hash berechnet. Der zweite Eintrag enthält seine eigenen Daten und den Hash des ersten Eintrags. Seine Berechnung bindet damit beide Stufen zusammen. Jeder weitere Eintrag setzt dieses Prinzip fort.

Vereinfacht lässt sich die Berechnung so ausdrücken:

Hash(n) = H(Daten(n) + Metadaten(n) + Hash(n−1))

Die tatsächliche Implementierung benötigt eine eindeutige Kodierung. Felder, Reihenfolge, Datentypen, Zeichensatz, Zeitzone und Umgang mit leeren Werten müssen festgelegt sein. Andernfalls können zwei Systeme denselben fachlichen Inhalt unterschiedlich serialisieren und verschiedene Hashwerte erzeugen.

Neben den Nutzdaten sollten alle Informationen einbezogen werden, deren unbemerkte Veränderung erkannt werden soll. Dazu können Ereigniskennung, Sequenznummer, Zeitangaben, Objektbezug, Ereignistyp und Versionskennung gehören. Nicht einbezogene Metadaten werden durch die Kette auch nicht geschützt.

Eine veränderte Kopie passt nicht mehr zum gesicherten Kettenstand

Ein fiktives Protokoll enthält die Einträge E-1 bis E-4. Für jeden Eintrag werden Ereigniskennung, Position, Zeitangabe, fachliche Nutzdaten und Vorgängerhash in einer festgelegten Kodierung gebunden. Nach E-4 wird der Endhash H-4 getrennt gegen unbemerkten Austausch geschützt.

In einer später vorgelegten Kopie wird der Messwert in E-3 geändert. Werden die mitgelieferten Hashwerte beibehalten, zeigt die erneute Berechnung eine Abweichung an dieser Stelle. Werden dagegen alle folgenden Hashwerte neu berechnet, kann die Kopie intern wieder zusammenpassen – ihr Endwert stimmt jedoch nicht mehr mit dem früher geschützten H-4 überein.

Der Vergleich bezieht sich nur auf die gebundene Darstellung. Wäre etwa die Einheit nicht einbezogen, würde die Kette ihre Veränderung nicht erkennen. Deshalb ist die Auswahl der geschützten Felder ebenso wichtig wie die Verkettungsformel.

Ein vertrauenswürdiger Anker macht die Prüfung belastbar

Der aktuelle Endhash verdichtet den verketteten Stand. Wird dieser Wert getrennt von den Einträgen geschützt, kann eine spätere Neuberechnung daran geprüft werden. Für die externe Datenverifikation muss dieser Bezugspunkt auch außerhalb des Ursprungssystems verlässlich zugänglich sein. Mögliche Anker sind ein signierter Checkpoint, ein geschütztes getrenntes System, ein Hardware-Sicherheitsmodul oder ein externer Zeitstempel.

Der Anker muss zum Prüfzeitraum passen. Ein heute gesicherter Endhash belegt nicht rückwirkend, dass die Kette bereits gestern denselben Stand hatte. Regelmäßige Prüfpunkte begrenzen den Zeitraum, in dem eine unbemerkte vollständige Neuberechnung möglich wäre.

RFC 5848 kombiniert für signierte Syslog-Nachrichten Hashwerte, Sequenzierung und kryptografisch signierte Blöcke. Das Verfahren soll unter anderem Nachrichtenintegrität, Herkunftsauthentisierung und die Erkennung fehlender Nachrichten unterstützen.^[2] Es zeigt, dass Hashwerte erst gemeinsam mit Schlüsseln, Signaturen, Reihenfolge und Prüfregeln einen umfassenderen Nachweis bilden.

Die Prüfdifferenz grenzt den Befund ein

Ein abweichender neu berechneter Wert zeigt, dass die vorgelegte Prüfeingabe nicht zum erwarteten Vergleichswert passt. Im Beispiel kann die Untersuchung beim geänderten Eintrag E-3 ansetzen. Die Ursache ist damit noch offen: unbeabsichtigte Änderung, Übertragungsfehler und gezielter Eingriff benötigen unterschiedliche weitere Belege.

Eine Prüfung sollte deshalb die verwendete Darstellung, den geprüften Abschnitt und den herangezogenen Referenzstand ausweisen. „Kette gültig“ ohne diese Angaben lässt offen, ob nur mit mitgelieferten Werten oder tatsächlich gegen einen geschützten früheren Stand verglichen wurde.

Fehlende und neu geordnete Einträge erkennen

Wenn Sequenznummer und vorheriger Hash in die Berechnung einfließen, kann das Entfernen eines Eintrags die Verbindung zwischen seinen Nachbarn brechen. Auch ein nachträgliches Vertauschen verändert die Berechnung der betroffenen Folge. Voraussetzung ist, dass die Prüfung beim bekannten Startpunkt beginnt und einen verlässlichen Endanker besitzt.

Lücken können dennoch unterschiedlich entstehen. Eine Nummer kann fehlen, weil ein Eintrag gelöscht wurde, weil die Übertragung nicht vollständig war oder weil eine Sequenz reserviert, aber nie geschrieben wurde. Die technische Erkennung ersetzt deshalb nicht die fachliche Untersuchung.

In verteilten Systemen gibt es möglicherweise keine einzige globale Reihenfolge. Dann können getrennte Ketten je Charge, Aufgabe, Gerät oder Datenstrom sinnvoller sein. Die Architektur muss festlegen, welche Einheit eine Kette bildet und wie ihre Anker zusammengeführt werden.

Welche Eigenschaften der Hashalgorithmus benötigt

Ein kryptografischer Hashalgorithmus soll für denselben Eingang stets denselben Digest erzeugen und bereits bei kleinen Änderungen einen deutlich anderen Wert liefern. Für die Integritätsprüfung sind insbesondere drei Widerstandseigenschaften relevant:

• Urbildresistenz: Aus einem gegebenen Hash soll sich kein passender ursprünglicher Eingang praktikabel bestimmen lassen.
• Zweiturbildresistenz: Zu einem bekannten Datensatz soll kein anderer Datensatz mit demselben Hash praktikabel gefunden werden können.
• Kollisionsresistenz: Es soll praktikabel nicht möglich sein, zwei unterschiedliche Eingänge mit identischem Hash zu konstruieren.

Die Sicherheit hängt vom verwendeten Algorithmus und seiner Parameterisierung ab. Ein selbst entwickeltes Prüfsummenverfahren oder ein veralteter Hashalgorithmus kann zwar technisch Werte erzeugen, aber keine angemessene kryptografische Belastbarkeit bieten. Algorithmen müssen deshalb identifizierbar und austauschbar sein.

FIPS 180-4 spezifiziert unter anderem die SHA-2-Familie. NIST hat am 7. März 2023 entschieden, den Standard zu überarbeiten und die SHA-1-Spezifikation daraus zu entfernen.^[1] Für eine langfristige Architektur folgt daraus: Nicht nur der Hashwert, sondern auch Algorithmus, Version und gegebenenfalls verwendete Parameter müssen erhalten bleiben.

Ein Wechsel des Hashverfahrens muss erkennen lassen, welchen zuvor geschützten Stand die neue Bindung umfasst. Eine bloße Neuberechnung der aktuell vorliegenden Daten würde den historischen Bezug nicht von selbst erhalten. RFC 4998 behandelt die Erneuerung von Archivzeitstempeln und Hashnachweisen für langfristige Evidenz.^[4] Wie ein Kettenstand in ein solches Langzeitverfahren eingeht, muss die Architektur festlegen.

Hash-Verkettung und Append-only Log ergänzen sich

Ein Append-only Log legt fest, dass neue Einträge ergänzt und frühere Einträge im vorgesehenen Anwendungsmodell nicht überschrieben werden. Hash-Verkettung liefert eine zusätzliche Prüfschicht: Sie kann Abweichungen an der gespeicherten Folge sichtbar machen.

Beide Prinzipien sind nicht identisch. Ein Log kann append-only geführt werden, ohne kryptografisch verkettet zu sein. Eine Hashkette kann wiederum über exportierte Dateien, Dokumentversionen oder andere geordnete Daten gebildet werden, die nicht selbst als Event Store organisiert sind.

Das Schreibmodell beantwortet, welche Veränderungen die Anwendung zulässt. Die Verkettung beantwortet, ob der später vorliegende Datenstand noch zu den gesicherten Prüfwerten passt. Für eine belastbare Historie müssen beide Ebenen mit Berechtigungen, Sicherung und Betrieb zusammenspielen.

Korrekturen dürfen die Kette nicht neu schreiben

Eine zulässige Berichtigung sollte nicht den ursprünglichen Eintrag verändern und sämtliche Folgehashes neu berechnen. Dadurch würde genau der Verlauf verschwinden, den die Kette erkennbar halten soll. Stattdessen wird die Korrektur als weiterer Eintrag an das Ende der relevanten Folge angehängt.

Das Korrekturereignis referenziert den betroffenen Ursprung und beschreibt neuen Inhalt, Grund, Identität und gegebenenfalls Prüfung. Sein eigener Hash bindet die Berichtigung in die fortlaufende Kette ein. Der aktuelle Zustand berücksichtigt beide Vorgänge.

Ein Audit Trail hält die fachlich und regulatorisch relevanten Änderungen nachvollziehbar. Hash-Verkettung kann dessen technische Integrität unterstützen, liefert aber nicht automatisch die erforderliche Bedeutung. Ein kryptografisch intakter Eintrag ohne verständlichen Änderungsgrund bleibt fachlich unzureichend.

Lineare Kette oder Hashbaum: der Prüfaufwand unterscheidet sich

Bei einer linearen Hashkette müssen für die Prüfung eines späten Endhashs häufig viele vorangehende Einträge erneut verarbeitet werden. Merkle-Bäume ermöglichen kompakte Nachweise für einzelne Einträge und für die Konsistenz zwischen Baumständen, wie RFC 9162 für Certificate Transparency beschreibt.^[5] Solche Nachweise lassen sich zusätzlich mit Signaturen und Zeitstempeln verbinden.

Technische Integrität ist nur eine Schicht

Datenintegrität umfasst Vollständigkeit, Konsistenz und Genauigkeit über den gesamten Datenlebenszyklus. Hash-Verkettung unterstützt die Erkennung nachträglicher Abweichungen, beantwortet aber nicht, ob der ursprüngliche Wert richtig erfasst wurde.

Auch fehlende Ereignisse können unbemerkt bleiben, wenn sie nie in die Kette gelangten. Erfassungsregeln, Schnittstellenkontrollen, Rollen, Zeitquellen, Backups und Wiederherstellungstests bleiben deshalb erforderlich. Die stärkste Kryptografie kann keinen Vorgang schützen, den das System nicht aufgezeichnet hat.

Was Hash-Verkettung nicht leistet

• Sie verhindert keine Änderung. Sie kann eine Abweichung bei der Prüfung erkennbar machen.
• Sie beweist keine fachliche Richtigkeit. Falsche Ausgangsdaten können korrekt verkettet sein.
• Sie identifiziert nicht automatisch den Verursacher. Dafür werden Authentisierung, Signaturen und Berechtigungsprotokolle benötigt.
• Sie ist keine Blockchain. Verteilung, Konsens und gemeinsames Register sind zusätzliche Eigenschaften. ^[3]
• Sie bleibt nicht wartungsfrei sicher. Algorithmen, Schlüssel und Langzeitnachweise müssen überwacht und erneuert werden.

Geschützt ist nur, was in die Bindung eingeht

Die Kopie im Beispiel lässt sich nur deshalb mit dem früheren Stand vergleichen, weil die Prüfdarstellung festliegt und H-4 getrennt geschützt wurde. Eine intern stimmige Folge allein wäre dafür zu wenig.

Bei der Bewertung einer Hash-Verkettung sind daher drei konkrete Gegenstände zu betrachten: die gebundenen Felder, die geordnete Folge und der gesicherte Referenzstand. Erst gemeinsam bestimmen sie, welche Veränderung eine spätere Prüfung erkennen kann.