Vorstellung existierender Standards und Konzepte

Transkript

1 Vorstellung existierender Standards und Konzepte Tobias Gondrom, Head of Security Team Open Text Corporation

2 existierende Standards und Konzepte Überblick zu Standards im Kontext der Bedürfnisse der Kliniken Evidence Record Syntax (RFC4998) weitere IETF Aktivitäten ArchiSafe XML

3 weitere Standards und Schnittstellen im Kontext bereits lange verfügbar: Zeitstempel (RFC3161) relativ einfach, u.u. teuer ( und Perfomance) bei akkreditierten TS für große Dokumentmengen, keine persönliche Signatur (keine formelle Willenserklärung) Digitale Signaturen CMS (Cryptographic Message Syntax, RFC3852) und XML Signaturen (persönliche oder auch Massen -signaturen) Anscheinsbeweis gem. ZPO 371a Abs. 1 und 2, Integration mit Fachanwendungen, ggf. Zertifizierung der Komponenten und Anwendung im Fall von Massensignaturen ggf. besondere rechtliche Begutachtung der Anwendung Verifikation von Signaturen nicht immer vollständig kompatibel gelöst langfristige Standard-Dokumentformate wie PDF/a, TIFF und Unicode. allgemeine Schnittstellen wie Web-Services, SOAP und WebDAV Proprietäre Schnittstellen zwischen bestehenden Systemkomponenten z.b. SAP ArchiveLink > 3rd party content repository/ecm/archive Anbindung von Signaturdiensten über proprietäre Mechanismen Anbindung von externen Workflowsystemen Anbindung von DMS/ECM/Archiven über proprietäre Schnittstellen Migration von Daten aus einem System in ein anderes durch Verbindung von proprietären Schnittstellen individuelle Workflows

4 Evidence Record Syntax (RFC4998) Überblick über LTANS und ERS Baumstruktur Signaturerneuerung Signaturen, Zeitstempel und Verifikation Fragen, Diskussion und Implementierung

5 Überblick über LTANS und ERS LTANS (Long Term Archiving and Notary Services): WG der IETF (Internet Engineering Task Force) gegründet 2003, Standards: Protokolle und Datenstrukturen zur sicheren Aufbewahrung und Bearbeitung von Dokumenten ERS: Evidence Record Syntax inspiriert durch die Ergebnisse aus dem ArchiSig Projekt des BMWi ( ) verabschiedet als RFC 4998 (Standard) eine XML-Variante XMLERS ist zur Zeit in

6 Evidence Record Syntax (RFC 4998) erlaubt Konservierung digitaler Daten und Signaturen mittels kryptographischer Technik Signaturerneuerung mittels Zeitstempel und bäume (siehe auch ArchiSig) gemäß SigV 17 Intention als Sicherungsmittel, keine Willenserklärung, kann auch als Massenzeitstempel / Massensignatur zur Sicherung von gescannten Dokumentmengen verwendet werden (siehe Klinik Braunschweig) Standard des Datenformat für Signaturerneuerungen, deren Beweisdaten und Prüfbarkeit ergänzt die bestehenden Standards TS (RFC3161) und CMS um die Langzeitsicherheit und Erneuerung bei gefährdeten Algorithmen verwendet die bestehenden CMS und TS Standards

7 17 Signatur Verordnung 17 Zeitraum und Verfahren zur langfristigen Datensicherung Daten mit einer qualifizierten elektronischen Signatur sind nach 6 Abs. 1 Satz 2 des Signaturgesetzes neu zu signieren, wenn diese für längere Zeit in signierter Form benötigt werden, als die für ihre Erzeugung und Prüfung eingesetzten Algorithmen und zugehörigen Parameter als geeignet beurteilt sind. In diesem Falle sind die Daten vor dem Zeitpunkt des Ablaufs der Eignung der Algorithmen oder der zugehörigen Parameter mit einer neuen qualifizierten elektronischen Signatur zu versehen. Diese muss mit geeigneten neuen Algorithmen oder zugehörigen Parametern erfolgen, frühere Signaturen einschließen und einen qualifizierten Zeitstempel tragen.

8 Evidence Record Syntax ERS besteht im wesentlichen aus einem baum und einem Zeitstempel, die in rekursiven Strukturen (bei Erneuerung) verwendet werden Datenstruktur ist in ASN.1 encoded eine XML Variante ist zur Zeit in Vorbereitung, aber noch nicht stabil (!) Schutz bei drohendem Verfall der Sicherheitseigenschaften der Algorithmen im Zeitstempel und baum Zeitstempelerneuerung baumerneuerung

9 Evidence Record Syntax ArchiveTimeStamp besteht im wesentlichen aus einem baum kombiniert mit einem Zeitstempel (genannt ArchiveTimeStamp ) Datenstruktur ist in ASN.1 encoded zum leichteren Transport wird der baum reduziert auf die für ein Objekt oder eine Objektgruppe erforderlichen Beweisdaten h 1.1 =H(d 1 ) Document d 1 h 1.1 =H(d 1 ) Document d 1 h 1.5 =H(h 1.1 h 1.2 ) h 1.2 =H(d 2 ) Document d 2 h 1.2 =H(d 2 ) Timestamp TS 1 =TSP(h 1.7 ) h 1.6 =H(h 1.3 h 1.4 ) h 1.3 =H(d 3 ) Document d 3 Reduced archive timestamp h 1.6 =H(h 1.3 h 1.4 ) h 1.4 =H(d 4 ) Document d 4 Timestamp TS 1 =TSP(h 1.7 ) A 1 ra 1

10 Zeitstempel Erneuerung Event: Any algorithm in timestamp gets weak Method h 2.1 hash timestamp with normal hash algorithm H and include hashvalue in new archive timestamp Properties no access to data objects H only few (at minimum 1) timestamps for a whole archive Reduction: ArchiveTimeStampChain SEQUENCE of ArchiveTimeStamp d 1 TS 2 TS 1 A 2 A 1 Reduced archive timestamp by timestamp renewal h 2.1 TS 2 Reduced initial archive timestamp h 1.1 h 1.1 TS 1 d 1 ra 2 ra 1

11 baum Erneuerung Event: Algorithm of Tree gets weak Method (for each data object) build Archive Timestamp chain A include hash of (hash of chain + hash of data object) in 3 new Archive Timestamp H' Properties need to access data objects but: avoidable by easy to implement redundancy and pre-hashing strategies Reduction: ArchiveTimeStampSequence SEQUENCE of ArchiveTimeStampChain h 2.1 TS 2 TS 3 h 3.1 h 3.1 h 1.1 TS 1 ra 2 ra 1 d 1 Reduced archive timestamp by hashtree renewal Reduced archive timestamps d 1 h 3.1 TS 3 h 2.1 TS 2 h 1.1 TS 1 ra 3 ra 2 ra 1

12 Signaturen, Zeitstempel und Signierte Dokumente Verifikation Signaturen innerhalb eines Containers mit der Datei selbst (z.b. CMS, PKCS#7, XML Signatur, ) Signaturen als externe Datei beide Formen können digitale Signaturen, Zeitstempel und Verifikationsdaten beinhalten Zeitstempel empfohlen im Standardformat RFC 3161 (TSP)

13 Verifikationsdaten für Dokumente: alle Zertifikate der Kette bis hoch zur root ein frühestens zum Signaturzeitpunkt durchgeführter OCSP oder CRL für die Zertifikate bei Zertifikaten innerhalb eines akkreditierten Trust Center kann ggf. auf ein OCSP oder CRL verzichtet werden (nicht bei Zertifikaten von natürlichen Personen!) (öffentliches Interesse => Umkehrschluß) fehlende Verifikationsdaten sollten bei der Eingangsvalidierung (bei der Sie zur Signatur-Verifikation sowieso eingeholt werden müssen) in den Container integriert werden und mit archiviert werden für Archivzeitstempel verwendete Zeitstempel sollten mindestens das Sicherheitsniveau der gespeicherten Signaturen haben => empfohlen akkreditierte Zeitstempel Verifikationsdaten: alle Zertifikate bis hoch zur root sollten in den Zeitstempel integriert werden bei Aufbewahrungszeiten gesichert kleiner 5 bzw. 30 Jahre kann man auf die Speicherung der Verifikationsdaten von einem akkr. TC ggf.. verzichten

14 weiterführende Dokumente Drafts: draft-ietf-ltans-xmlers draft-ietf-ltans-validate draft-ietf-ltans-ari draft-ietf-ltans-ltap Bücher: Beweiskräftige elektronische Archivierung - Bieten elektronische Signaturen Rechtssicherheit? Herausgeber: Alexander Roßnagel, Paul Schmücker "Das elektronisch signierte Dokument als Mittel zur Beweissicherung - Frau Dr. Stefanie Fischer-Dieskau

15 weitere relevante IETF Aktivitäten Working Group: LTANS (Long-term archiving and notary services) DSSC: Data Structure for Security Suitabilities of Cryptographic Algorithms Algorithmeneignung und Gültigkeit geplant veröffentlicht durch NIST und Bundesnetzagentur XMLERS: XML representation of ERS, benötigt noch mehrere Monate bis zur Verabschiedung LTAP: Long-term archive protocol möglicherweise ähnlich zu Bedarf für ArchiSafe XML

16 ArchiSafe XML als Basisgedanke für uniformen Datenaustausch zwischen Systemen Format des Datenpaketes: XML-Container mit definierten Top-Level Strukturen soll ebenfalls das Transport-Protokoll definiert werden (heute teilweise Austauschverzeichnis, in Zukunft, HTTP, Web Service?)