Evidence Record Syntax

Die Evidence Record Syntax, kurz ERS, ist ein Teil der Spezifikation des Long-Term Archiving and Notary Service, kurz LTANS. Er beschreibt das Datenformat für eine Nachweisdatei, den Evidence Record, der dazu dient, den Beweis für die Integrität eines in einem Langzeitarchiv gespeicherten Dokuments zu liefern. Die 2007 freigegebene Spezifikation der ERS im RFC 4998 und die Spezifikation von ERS im XML-Format (XMLERS) im RFC 6283 im Jahre 2011 erfolgt unter Federführung der LTANS Working Group der Internet Engineering Task Force (IETF).^[1][2]

Die Ideen für die ERS wurden im vom deutschen Bundesministerium für Wirtschaft und Arbeit geförderten Projekt ArchiSig entwickelt und anschließend zur Standardisierung in die IETF übergeben. In dem Projekt wurde u. a. auch die Tauglichkeit der Beweissicherung an beispielhaften Gerichtsverfahren erprobt.

Problemstellung

Die Sicherung des Nachweises der Integrität eines elektronischen Dokuments kann durch eine Signierung erreicht werden. Wird eine qualifizierter Zeitstempel genutzt, wird das "Wann lag welcher Inhalt vor" abgesichert. Eine qualifizierte, personenbezogene Signatur sichert dagegen das "Wer hat Was unterschrieben" ab, d.h. zusätzlich zur Integrität wird die Authentizität des Urhebers nachweisbar. Mithilfe des Signaturgesetzes sowie nachfolgender Änderungen in vielen anderen Gesetzestexten wie dem Bürgerlichen Gesetzbuch oder der Zivilprozessordnung wird das qualifiziert signierte, elektronische Dokument dem schriftlichen Dokument in der Beweiskraft gleichgestellt.

Das Problem ist die Alterung von Algorithmen, die zur Erzeugung einer elektronischen Signatur benutzt werden. Mit zunehmendem Alter sind die Algorithmen angreifbar, d. h. mit genügend Rechnerleistung könnte sich Jemand für einen Anderen ausgeben oder ein anderes Dokument zum bisherigen Hash-Wert erzeugen. Wann ein Algorithmus schwach wird, kündigt die zuständige Bundesnetzagentur an (siehe dazu auch den Artikel zum ArchiSig-Projekt). Ab diesem Zeitpunkt verlieren alle Dokumente, deren qualifizierte Signatur den Algorithmus genutzt haben, den hohen Beweiswert.

Gesetzlicher Rahmen

Das Signaturgesetz nimmt im § 6 (1) Bezug auf das Nachsignieren. Ergänzend definiert die Signaturverordung in §17 SigV, dass zum Nachsignieren zwingend qualifizierte Zeitstempel verwendet werden müssen. D.h. bevor eine elektronische Signatur durch schwach werden des Hash-Algorithmus und/oder des Verschlüsselungsalgorithmus ungültig wird, sind die zu signierenden Daten mit einem qualifizierten Zeitstempel nachzusignieren. Hierdurch wird der Beweiswert der Signatur erhalten.

Lösung

Im Fall nur weniger signierter Dokumenten ist ein manuelles, personenbezogenes Signieren vielleicht noch vorstellbar. Im Falle großer Dokumentenbestände ist eine Lösung gesucht, die standardisiert nachvollziehbar, schnell, weil automatisiert, und kostengünstig ist. Und genau hier setzt LTANS mit dem Evidence Record an.

Grafik 1: Archivzeitstempel A1 mit seinem Hash-Baum (hier ein Binärbaum)

Um den grundsätzlichen Aufbau des Evidence Records zu verstehen, muss zuerst die Art der Speicherung signierter Dokumente für eine Langzeitarchivierung besprochen werden. Die Neusignierung nutzt qualifizierte Zeitstempel. Damit aus Kosten- (3 bis 6 Cent pro Zeitstempel) und Zeitgründen nicht jedes Dokument einzeln mit einem Zeitstempel versorgt werden muss, wird mit so genannten Hash-Bäumen gearbeitet. Für jedes in einem Content Repository (ECM) neu gespeicherten Dokument (Grafik 1: d1 bis d4) wird ein Hash-Wert auf Basis des jeweils aktuellen, stärksten Hash-Algorithmus berechnet und in einem Hash-Baum auf der ersten Ebene aufgenommen (in der Grafik: h1,1 bis h1,4, die "erste Ziffer nummeriert den Hash-Baum, die zweite die laufende Nummer des Hash-Werts im Baum).

Ein Hash-Baum kann beliebig viele Hash-Werte aufnehmen, zudem ist die Arität des Baumes freigestellt. In der Praxis scheint sich ein tageweise gebildeter binärer oder ternärer Hash-Baum zu bewähren. Die Bildung des Hash-Baums erfolgt, indem zuerst 2 bis n Hash-Werte der 1. Ebene konkateniert und diese Byte-Folge zu einem neuen Hash-Wert (Kind) berechnet werden (Beispiel in der Grafik 1: h1,5=H(h1,1|h1,2)). Dieses Verfahren wird solange fortgesetzt, bis in der letzten Ebene nur noch ein Hash-Wert übrig bleibt. Dieser Hash-Wert wird dann mit einem qualifizierten Zeitstempel signiert. Das gesamte Konstrukt, Hash-Baum und Signatur wird dann Archivzeitstempel (Grafik A1: mit der 1 für den ersten Hash-Baum) genannt.

Grafik 2: Reduzierter Archivzeitstempel

Wird nun eins der Dokumente für die Beweisführung vor Gericht benötigt, so wird eine Kopie des Dokuments aus dem Content Repository geholt und sein Evidence Record erstellt. Da die Datenmenge des gesamten Hash-Baums sehr groß sein kann, wird ein sogenannter reduzierter Archivzeitstempel (Grafik 2: rA1) gebildet und neben den Prüfergebnissen der Signaturen im Evidence Record gespeichert. Der reduzierte Archivzeitstempel enthält jeweils nur die Hash-Werte, um das jeweils nächste Kind wieder berechnen zu können, sowie den Zeitstempel über den Hash-Wert der höchsten Ebene. Die Evidence Record Syntax ist im Format ASN.1 aufgebaut und ist für ungeübte Augen wenig lesbar und soll daher an dieser Stelle nicht weiter dargestellt werden.

Ergänzende Hinweise:

Das qualifizierte Signieren von Dokumenten kann in drei Varianten erfolgen:

1. Das Dokument wird anschließend von einer Signaturdatei (gemäß RFC 3852) begleitet
2. Die Signaturdatei ist in einem PDF/A-formatierten Dokument eingebettet
3. Das Dokument ist in der Signaturdatei eingebettet

Während in den Fällen 2 und 3 für nur ein Objekt ein Hash-Wert im Baum enthalten ist, müssen im ersten Fall zwei Objekte, das Dokument und die begleitend Signaturdatei behandelt werden. Da im Fall 3 für die Ansicht des Dokuments dieses erst aus dem Kontainer extrahiert werden muss, spricht für eine einfachere Handhabung die Nutzung von in PDF/A eingebettete Signaturen.

Der oben genannte Zeitstempel sollte die gleiche Stärke besitzen wie die Signaturdateien, für die entsprechende Hash-Werte im Baum enthalten sind. Andernfalls wird die Auslegung der Neusignierung komplizierter.

Zwei Verfahren der Neusignierung

Der Evidence Record wird umfangreicher, sobald das erste Mal neusigniert werden musste. Hierbei müssen zwei Verfahren der Neusignierung unterschieden werden.

Grafik 3: Neusignierung des Archivzeitstempels im Fall der geschwächten Verschlüsselung

Bei der Erstellung einer Signatur wird mit einem bestimmten Hash-Algorithmus ein Hash-Wert für das Dokument berechnet. Hash-Werte auf Basis desselben Algorithmus sind gleich groß und deutlich kleiner als das Dokument selbst; dennoch ist es sehr unwahrscheinlich, dass zwei Dokumente denselben Hash-Wert haben. Dieser Hash-Wert wird anschließend im Chip auf der Signaturkarte mit dem dort "eingravierten" privaten, einmaligen Schlüssel verschlüsselt und zusammen mit den ebenfalls auf der Karte befindlichen Zertifikatsdaten in die Signaturdatei geschrieben.

Grafik 4: Reduzierter Archivzeitstempel nach der Neusignierung im Fall der geschwächten Verschlüsselung

Wenn der Verschlüsselungsalgorithmus des oben genannten Zeitstempels als bald geschwächt eingestuft ist, so muss nur der Zeitstempel des Hash-Baums erneut mit einem Zeitstempel signiert werden. Dabei kann so verfahren werden, dass für alle vorhandenen Archivzeitstempel ein Hash-Wert berechnet wird und dieser in einem neuen Hash-Baum aufgenommen wird, für den abschließend ein Archivzeitstempel erzeugt wird.

Der Evidence Record für ein Dokument muss nun auch die Daten des reduzierten Archivzeitstempels des neuen Hash-Baums mit den Hash-Werten der alten Archivzeitstempel mit berücksichtigen, so wie es die Grafik 4 zeigt.

Grafik 5: Neusignierung mit Neuverhashung

Wenn der verwendete Hash-Algorithmus als bald geschwächt eingestuft ist, wird das Verfahren aufwändiger, da dann sämtliche Dokumente nochmals aus dem Content Repository geholt und erneut verhasht werden müssen. Dabei wird so verfahren, dass der neue Hash-Wert mit den ebenfalls neu erstellten Hash-Werten seiner reduzierten Archivzeitstempel konkateniert wird und für diese Byte-Folge ein weiterer Hash-Wert berechnet wird. Dieser wird dann in einen neuen Hash-Baum aufgenommen, der dann abschließend wieder mit einem Zeitstempel signiert wird.

Es ist selbsterklärend, dass der Evidence Record nach jeder Neusignierung umfangreicher wird.

Hinweis: Die Grafiken sind Abbildungen aus dem Buch Beweiskräftige elektronische Archivierung von Roßnagel und Schmücker (ISBN 3-87081-427-6) entlehnt.

Interoperabilität

Da der Evidence Record den Nachweis der Integrität über einen langen Zeitraum ermöglichen soll, ist eine Interoperabilität zwischen Systemen, die einen solchen Record erzeugen, zwingend. Die Betreiber von Langzeitarchiven müssen damit rechnen, dass das aktuelle System durch ein anderes zu ersetzen ist. D. h. die enthaltenen Daten müssen exportiert und wieder importiert werden. Da nicht nur die Dokumente und ihre Signaturdatei sondern auch ihre Evidence Records übertragen werden muss, ist ein Einlesen auch der Records in die interne Datenstruktur des Zielsystems zwingend erforderlich.

Umsetzungen

Die auf dem Markt angebotenen Systeme (siehe ArchiSig), die Hash-Bäume und Evidence Records erzeugen als auch die Neusignierung wie oben beschrieben durchführen, werden von ihren Herstellern als ArchiSig-konform bezeichnet.

Kritik

Da das hier vorgestellte Verfahren zugegebenermaßen nicht ganz einfach ist, gibt es neben den Verfechtern des Verfahrens auch kritische Stimmen. Diese fordern, dass das Neusignieren von Dokumenten, die in einem elektronischen Archiv liegen, nicht notwendig sein sollte, siehe dazu auch den Artikel zum ArchiSig-Projekt.

Weblinks

• ArchiSig-Projektseite

Einzelnachweise

1. ↑ IETF LTANS Working Group
2. ↑ LTANS Architecture Draft Specification