Evidence Record Syntax

Dokumentationssprache

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[1] und die Spezifikation von ERS im XML-Format (XMLERS) im RFC 6283[2] im Jahr 2011 erfolgt unter Federführung der LTANS Working Group der Internet Engineering Task Force (IETF).[3][4]

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

Bearbeiten

Die Sicherung des Nachweises der Integrität eines elektronischen Dokuments kann durch eine Signierung erreicht werden. Wird ein 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

Bearbeiten

Das Signaturgesetz nimmt im § 6 (1) Bezug auf das Nachsignieren. Ergänzend definiert die Signaturverordnung 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.

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.

 
Hash-Baum A1 (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 sogenannten Hash-Bäumen gearbeitet. Für jedes in einem Content Repository (ECM) neu gespeicherten Dokument (Grafik „Hash-Baum“: 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 „Hash-Baum“: 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 (siehe A1 in Grafik „Hash-Baum“).

Um nun einen Evidence Record zu erhalten, muss der Hash-Baum zuerst reduziert werden. Die Liste dieser Hash-Werte wird durch Reduktion des vorher erzeugten geordneten Merkle-Hash-Baums [MER1980] erzeugt (siehe Grafik „Archivzeitstempel“). Dieser reduzierte Hash-Baum wird Archivzeitstempel genannt.[5]

 
Archivzeitstempel rA1

Dieser Archivzeitstempel enthält den reduzierten Hash-Baum mit jeweils nur den Hash-Werten, die benötigt werden um das jeweils nächste Kind berechnen zu können, sowie den Zeitstempel über den Wurzel Hash-Wert. Die Evidence Record Syntax ist im Format ASN.1.

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

Bearbeiten

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

 
Neusignierung des Zeitstempel 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.

 
Archivzeitstempel rA1 nach der Neusignierung im Fall der geschwächten Verschlüsselung mit dem neuen Archivzeitstempel rA2

Wenn der Verschlüsselungsalgorithmus des oben genannten Zeitstempels eines Evidence Record als bald geschwächt eingestuft ist, so muss der Zeitstempel des alten Archivzeitstempels mit einem Hashwert versehen und mit einem neuen Archiv-Zeitstempel versehen werden. Der neue Archiv-Zeitstempel DARF keinen reduzierten Hash-Baum enthalten, wenn der Zeitstempel nur einfach den vorherigen Zeitstempel schützt. Im Allgemeinen kann man jedoch eine Reihe von alten Archiv-Zeitstempeln sammeln und den neuen Hash-Baum mit den Hash-Werten des Inhalts ihrer Zeitstempel aufbauen.[6]

Der Evidence Record muss nun um den neuen Archiv-Zeitstempel angereichter werden (siehe Grafik).

 
Neusignierung mit Neuverhashung

Wenn der verwendete Hash-Algorithmus als bald geschwächt eingestuft ist, wird das Verfahren aufwändiger. Alle Dokumente, die durch den Evidence Record mit dem initialen Archiv-Zeitstempel geschützt werden, muss man erneut verhashen. 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. Der Hash-Baum wird wieder reduziert und der resultierende Archiv-Zeitstempel wird dem Evidence Record hinzugefügt.[7]

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 entlehnt.[8]

Interoperabilität

Bearbeiten

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

Bearbeiten

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.

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.

Einzelnachweise

Bearbeiten
  1. RFC: 4998 – Evidence Record Syntax (ERS). August 2007 (englisch).
  2. RFC: 6283 – Extensible Markup Language Evidence Record Syntax (XMLERS). Juli 2011 (englisch).
  3. IETF LTANS Working Group (Memento des Originals vom 10. Juli 2009 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.ietf.org
  4. LTANS Architecture Draft Specification
  5. RFC: 4998 – Evidence Record Syntax (ERS). August 2007, Abschnitt 4 (englisch).
  6. RFC: 4998 – Evidence Record Syntax (ERS). August 2007, Abschnitt 5.2 (englisch).
  7. RFC: 4998 – Evidence Record Syntax (ERS). August 2007, Abschnitt 5.2 (Point 1-5, englisch).
  8. Roßnagel, Schmücker: Beweiskräftige elektronische Archivierung. ISBN 3-87081-427-6.