Long-Term Archiving and Notary Service

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Long-Term Archiving and Notary Service ist ein Begriff aus der Kryptologie.

Von 2003 bis 2011 arbeitete die gleichnamige Working Group[1] innerhalb der Internet Engineering Task Force (IETF) an Spezifikationen rund um das Thema der Nachweisfähigkeit der Integrität von elektronischen Dokumenten, speziell signierten, im Kontext der Langzeitarchivierung. Das erste Ziel war es, die im ArchiSig-Projekt gewonnenen Konzepte in einen Standard zu überführen. Nach einer weiteren Phase der Anforderungsanalyse für ein Archivsystem, das entsprechende Services zur Verfügung stellt,[2] wurden dann weitere Austauschformate sowie Protokolle spezifiziert.

Anforderungen an ein Long-Term Archive Service

[Bearbeiten | Quelltext bearbeiten]

Das primäre Ziel eines Long-Term Archive Service ist die Sicherung des Nachweises eines Anspruchs, der in einem elektronischen Dokument beurkundet wird, zu einem beliebigen Zeitpunkt in der Zukunft. Ein Long-Term Archive Service muss daher Anwendungsfälle wie Testamente, Landbesitzurkunden, medizinische Daten, Kriminalfallakten, persönliche Urkunden oder Verträge elektronisch unterstützen. Ein Long-Term Archive Service muss von unterschiedlichen Anwendern wie Organisationen, Einwohner, Richtern oder Notaren in gleicherweise genutzt werden können:

  • Eine Firma speichert Verträge auf dem System eines Dienstleisters
  • Ein Krankenhaus speichert medizinische Daten in einem internen System.
  • Eine Privatperson möchte den Beweis erbringen, dass er ein bestimmtes Dokument zu einem bestimmten Zeitpunkt besessen hat, z. B. zwecks Beweises einer Urheberschaft oder eines Vertragszusatzklausel
  • Ein Gesetzeshüter will seine Kriminalfallakten derart speichern, dass dessen Integrität auch noch Jahre später demonstriert werden kann

Für jedes der genannte Beispiele gibt es das komplementäre Beispiel eines Empfängers, z. B. eine Firma erhält den Vertrag im Streitfall zugeschickt oder ein Gesetzeshüter stellt Material für eine Anklage zusammen.

Aufgrund des Langzeitaspekts muss ein Long-Term Archive Service damit umgehen können, dass benutzte Techniken mit der Zeit altern. Das gilt für

Im Falle der Alterung muss daher ein Long-Term Archive Service in der Lage sein,

  • Daten von dem bisherigen Medien auf ein anderes verlustfrei zu migrieren oder zumindest inklusive der zugehörigen Indexdaten zu exportieren
  • die Transformation eines Dokuments in ein anderes Format inkl. der Behandlung von Signaturen ordnungsgemäß durchzuführen (siehe auch den Weblink zum Projekt TransiDoc)
  • signierten Dokumenten mit einem Zeitstempel neuzusignieren (bisher nur in Deutschland rechtlich eingefordert)

Diese ordnungsgemäße Durchführung dieser Services müssen auch nach Jahren lückenlos nachgewiesen werden können (→ Notary Service).

Publizierte Spezifikationen

[Bearbeiten | Quelltext bearbeiten]
LTANS – Long-Term Archive Service Requirements
Die LTANS Working Group ging nach der Veröffentlichung der Anforderungen (RFC 4810[3]) im Jahr 2006 das Thema des Nachweises der Integrität und Authentizität von signierten Dokumenten an.
LTANS-ERS
Ergebnis war die Veröffentlichung des RFC 4998[4] mit der Beschreibung des Evidence Record Syntax im Jahr 2007, der das Datenformat des lückenlosen Nachweises eines signierten Dokuments inklusive seiner Neusignierungen.
LTANS-ERS-SCVP
Der anschließend veröffentlichte RFC 5276[5] spezifiziert die Schnittstelle zu dem Service, bei dem ein Evidence Record zu einem Objekt angefordert wird. Das Objekt wurde zuvor schon einmal in diesem als SCVP-Service genannten System registriert. Sämtliche Zertifikate (Zertifikatspfad) inklusive der Sperrlisten, die während der ersten Verifikation von den Zertifizierungsdiensteanbietern erhalten wurden, werden von dem SCVP-Service für zukünftige Anfragen gespeichert.
LTANS-XMLERS
Der Spezifikation von RFC 4998[4] folgend, wurde 2011 ebenfalls ein äquivalenter Standard RFC 6283[6] im XML-Format verabschiedet. Beide (RFC 4998 und RFC 6283) sind in ihrer Funktion gleichwertig, sichern den lückenlosen Nachweis eines signierten Dokuments inklusive seiner Neusignierungen und unterscheiden sich hauptsächlich durch die jeweils von ihnen genutzten Formate (RFC 4998 nutzt ANS.1, RFC 6283 nutzt XML).

Spezifikationen in Bearbeitung

[Bearbeiten | Quelltext bearbeiten]

Die LTANS Working Group arbeitet an den folgenden weiteren RFCs:

LTANS-DSSC
Die Spezifikation Data Structure for the Security Suitability of Cryptographic Algorithms[7] beschreibt die Datenstruktur einer Information über die Stärke eines Kryptographischen Algorithmus in der Vergangenheit, der Gegenwart als auch der Zukunft, wie sie von einer Organisation wie der Bundesnetzagentur zur Verfügung gestellt werden soll. Stand heute werden die Algorithmenstärken in einem PDF-Dokument jährlich von der Bundesnetzagentur im Kontext des Signaturgesetzes veröffentlicht und manuell in SCVP-Systemen eingepflegt werden. Mit der DSSC-formatierten Datei sollen SCVP-Systeme zukünftig in der Lage sind, entsprechende Information automatisiert zu verarbeiten.
LTANS-LTAP
Das Long-term Archive Protocol[8] dient als einheitliche Schnittstelle, um seitens einer Anwendung Daten mit einem Long-term Archive Service auszutauschen, z. B. um sie zur Aufbewahrung zu übergeben, nach ihnen zu suchen oder sie für eine Anzeige wiederzubeschaffen.

Bisher umgesetzt wurde hauptsächlich die Evidence Record Syntax inklusive entsprechender Datenhaltung in einer SQL-Datenbank durch deutschen Hersteller von Signaturanwendungskomponenten (siehe Artikel Evidence Record Syntax) mit bisher eigenen, proprietären Schnittstellen.

Seit 2010 existieren Lösungen, bei denen die Beweiswerte direkt im Dokumentencontainer abgelegt und versiegelt werden. Proprietäre, separate Systeme zur Verwaltung der Evidence Records können dadurch komplett entfallen.[9]

Die Technische Richtlinie TR-03125[10] des BSI ([Bundesamt für Sicherheit in der Informationstechnik]) nutzt die Evidence Record Syntax zur Beweisführung und erlaubt entsprechende Zertifizierungen[11] auf der Basis des Schutzprofils (Protection Profile)[12] ArchiSafe.[13][14]

Zur Kritik am Neusignieren qualifiziert signierter Dokumente, die in einem elektronischen Archiv gespeichert sind, siehe den Artikel ArchiSig.

Ob sich der Internet-Draft LTANS-LTAP durchsetzen wird, mag bezweifelt werden. Inzwischen haben sich alle marktbeherrschenden Hersteller wie IBM, SAP, Microsoft, EMC und ORACLE zur Definition des Standards CMIS unter der Oberhoheit der Organization for the Advancement of Structured Information Standards (OASIS) zusammengefunden. Der Content Management Interoperability Service (siehe Weblink) legt auf Basis des SOAP als auch REST-Protokolls fest, wie Anwendungen Content in entsprechende Repositories (u. a. auch Archive) in Aktenstrukturen in Bezug auf Zugriffsrechte ablegen, suchen und wiederfinden können.

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. 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
  2. LTANS Status Page
  3. RFC 4810 – Long-Term Archive Service Requirements. März 2007 (englisch).
  4. a b RFC 4998 – Evidence Record Syntax (ERS). August 2007 (englisch).
  5. RFC 5276 – Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records. August 2008 (englisch).
  6. RFC 6283 – Extensible Markup Language Evidence Record Syntax (XMLERS). Juli 2011 (englisch).
  7. Data Structure for the Security Suitability of Cryptographic Algorithms – LTANS-DSSC. Internet-Draft.
  8. Long-term Archive Protocol – LTANS-LTAP. Internet-Draft.
  9. Produktbeschreibung: SecDocs - Beweiserhaltene Langzeitarchivierung
  10. BSI TR-03125 Beweiswerterhaltung kryptographisch signierter Dokumente (Memento des Originals vom 28. September 2011 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.bsi.bund.de
  11. BSI-DSZ-CC-0685-2012. bsi.bund.de @1@2Vorlage:Toter Link/www.bsi.bund.de (Seite nicht mehr abrufbar, festgestellt im April 2019. Suche in Webarchiven)  Info: Der Link wurde automatisch als defekt markiert. Bitte prüfe den Link gemäß Anleitung und entferne dann diesen Hinweis.
  12. Common Criteria Protection Profile for an ArchiSafe Compliant Middleware for Enabling the Long-Term Preservation of Electronic Documents (ACM PP). @1@2Vorlage:Toter Link/www.bsi.bund.de (Seite nicht mehr abrufbar, festgestellt im April 2019. Suche in Webarchiven)  Info: Der Link wurde automatisch als defekt markiert. Bitte prüfe den Link gemäß Anleitung und entferne dann diesen Hinweis. bsi.bund.de
  13. ArchiSafe-Modul. (PDF) bsi.bund.de
  14. Certification Report BSI-CC-PP-0049-2008. (Memento des Originals vom 30. Januar 2012 im Internet Archive; PDF; 543 kB)  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.commoncriteriaportal.org commoncriteriaportal.org