Embed Size (px)
DESCRIPTION
Ein Vortrag von auf dem ECM-Forum zur CeBIT 2014 Referenten: Andreas Weise, partner management, secrypt GmbH Markus Schuster, Leiter Vertrieb, intarsys consulting GmbH Sven Rüscher, Produktmanager Governikus LZA, Governikus GmbH & Co. KG / bremen online services GmbH & Co. KG Weitere Informationen unter:http://ecm-navigator.de/termine/nachsignatur-interoperabilitaet-und-loesungen
Citation preview
Nachsignatur, Interoperabilität und Lösungen
Hannover, 13.03.2014
www.bitkom.org www.digitalewelt.org
Andreas Weise
Mitglied des BITKOM AK Signaturen
partner management, secrypt GmbH
+49 (30) 7565978 - 0 [email protected]
Ihre Referenten
Markus Schuster
Vorsitzender des BITKOM AK Signaturen
Leiter Vertrieb, intarsys consulting GmbH +49 (721) 38479 - 0 [email protected]
Sven Rüscher
Mitglied des BITKOM AK Signaturen
Produktmanager Governikus LZA, Governikus GmbH & Co. KG
+49 (421) 204 95 - 0 [email protected]
Inhalt
3
1. Aufgabe eines Nachsignatur - Moduls
2. Grundlage des Interoperabilitätstest Nachsignatur
3. Ergebnisse und Ausblick
www.bitkom.org www.digitalewelt.org
1. Aufgabe eines Nachsignatur - Moduls
Ich habe mein Ladenlokal für 20 Jahre gemietet. Den Vertrag hat
der Beklagte digital signiert. Jetzt soll ich ausziehen weil ein
Konkurrent bereit ist das Doppelte zu bezahlen.
Ein derartiger Vertrag existiert nicht. Und überhaupt, die digitale Signatur
ist 10 Jahre alt – so etwas bricht heute jeder PDA!
Signaturerneuerung? Nein. Wieso ?
Sie sagt bestimmt die Wahrheit aber ohne Beweis sind mit die Hände
gebunden.
Signaturen ohne kryptografischen Wert: Die Horrorvision
5
Stimmt. Klägerin sind Sie Ihrer Pflicht zur Erneuerung digitaler Signaturen
gemäß §6 SigG und §17 SigV nachgekommen ?
Die Signatur hat damit ihren kryptografischen Beweiswert verloren!
Ob der verwendete Hashalgorithums und oder die verwendete Schlüssellänge die vorher genannten Ansprüche erfüllen, hängt im Wesentlichen davon ab, wann die Signatur erfolgt ist
Die Bundesnetzagentur veröffentlicht im Bundesanzeiger eine Übersicht über die Algorithmen und zugehörigen Parameter, die zur Erzeugung von Signaturschlüsseln, zum Hashen zu signierender Daten oder zur Erzeugung und Prüfung qualifizierter elektronischer Signaturen als geeignet anzusehen sind, sowie den Zeitpunkt, bis zu dem die Eignung jeweils gilt. Die Eignung ist jährlich sowie bei Bedarf neu zu bestimmen
Ein wesentlicher Faktor: Zeit
6
Schlüssellänge Kryptografische Algorithmen
Hashwert
Im Rahmen des Projektes ArchiSig wurden Konzepte für eine sichere und beweiskräftige Langzeitarchivierung elektronisch signierter Dokumente entwickelt, die ihren Niederschlag im internationalen Standard LTANS/ERS gefunden haben. Hierbei handelt es sich um Konzepte
zur Bestimmung von Verifikationsdaten, die für eine erfolgreiche Beweisführung erforderlich sind, und zu ihrer Integration in signierte Dokumente
zur Signaturerneuerung durch elektronische Archivzeitstempelung
zur Berücksichtigung der Sicherheitseignung kryptografischer Algorithmen
zur Transformation unterschriebener Papierdokumente in elektronische Dokumente und ihrer öffentlichen Beglaubigung
Konzepte zur Langzeitbeweiswerterhaltung
7
4 Dokumente:
4 Hash Werte:
2 Hash Werte:
1 Hash Wert:
1 Zeitstempel:
Das Konzept: Hash-Bäume für mehr Effizienz
Die Evidence Record Syntax (RFC 4998), 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 erfolgte unter Federführung der LTANS Working Group der Internet Engineering Task Force (IETF)
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
Der Evidence Record enthält alle benötigten Informationen der durchgeführten Beweissicherung und wird damit beim Datenaustausch benötigt
Der Evidence Record ist auch Bestandteil einer TR-ESOR Lösung
Evidence Record Syntax
9
www.bitkom.org www.digitalewelt.org
2. Grundlage des Interoperabilitätstest Nachsignatur
Die Projekterfahrung mit Langzeitarchivierungssystemen zeigt, dass eine Implementierung gemäß RFC 4998 nicht ausreichend ist, um die Austauschbarkeit eines LZA-Systems mit vertretbarem Aufwand zu gewährleisten. Dazu lässt die RFC zu viel Interpretationsspielraum
Diese Lücke soll das Testkonzept „Interoperabilität LZA-Systeme“ füllen, um dem Betreiber eines LZA-Systems langfristigen Investitionsschutz zu bieten. Zudem bietet es den teilnehmenden Herstellern die Möglichkeit, eine einheitlich akzeptierte Interpretation der RFC zu finden und zudem durch die Schirmherschafft des BITKOM einen effizienten Verbreitungskanal für ermittelte Ergebnisse zu nutzen
Testkonzept „Interoperabilität LZA-Systeme“
11
Test in 3 Stufen
Kann Dokument, Signatur und eRecord, konform zu RFC 4998 (Evidence Record Syntax), exportiert werden?
Kann der eRecord von anderen Systemen geprüft werden?
Kann ein eRecord in ein anderes System importiert werden?
Interoperabilität
Auf Basis der Datenformate
Bei den Interoperabilitätstests beschränken wir uns zunächst auf die Interoperabilität auf Basis der Datenformate, weil nur diese durch die RFC definiert wird
Durchführung
12
Schirmherr für den Interoperabilitätstest ist der BITKOM
Realisiert wird der Test durch eine Testsuite, die in der initialen Phase aus Testdaten für jedes zu testende LZA-
System besteht. Jeder Teilnehmer muss den Mindestumfang an Testdaten zur Verfügung stellen. Die Testdaten
müssen mit dem gerade aktuellen LZA-System des Herstellers erstellt worden sein. Kann er aus nachvollziehbaren
Gründen bestimmte Testdaten nicht liefern, können Ausnahmen zugelassen werden
Die mit Hilfe dieser Testdaten ermittelten Testergebnisse führen im besten Fall – wenn alle Testfälle erfolgreich
durchgeführt wurden - zu der Aussage, dass die verwendeten LZA-Systeme kompatibel sind. Ermittelte Testfehler
sollen unter den Teilnehmern diskutiert werden und zu einer einheitlich abgestimmten Interpretation der RFC
4998 führen und sich in der Implementierung der teilnehmenden LZA-Systeme niederschlagen
Sobald eine einheitliche Interpretation von RFC 4998 durch die Teilnehmer abgestimmt ist, kann der zugehörige
Testdatensatz zusätzlich/alternativ zur Verfügung gestellt werden
Die Behandlung der mit den Testdaten ermittelten Testergebnisse unterliegt jederzeit der Entscheidungshoheit
der jeweiligen Lieferanten der Testdaten
Ablauf und Teilnahmebedingungen
13
Die definierten Testfälle sollen sicherstellen, dass die Daten von einem LZA-System in ein anderes – welches auch das eigene sein kann - migriert werden können
Testdaten erstellen
Die mit nachfolgendem Ablauf erzeugten ERs dienen als Testdaten für das eigene System und alle Fremdsysteme
Hashbäume gemäß Vorgabe mit dem LZA-System erstellen
ERs exportieren
Zu erzeugende Testdaten
Testdaten werden in ASN-1 Format gemäß RFC4998 zur Verfügung gestellt ohne etwaige XML-Kapselung
Verschiedene Kombinationen aus Zeitstempel- und Hashwerterneuerungen
Testdefinition
14
www.bitkom.org www.digitalewelt.org
3. Ergebnisse und Ausblick
Stand der Tests
16
Mit Governikus, secrypt, Fraunhofer SIT und intarsys nehmen bereits vier der führenden Hersteller für Signaturlösungen in Deutschland teil
Testdaten wurden zwischen den Unternehmen erfolgreich ausgetauscht. Jeder der Teilnehmer hat Zugriff auf die Daten der Beteiligten erhalten
Verifikations-Interoperabilität-Test wurden von allen Teilnehmern durchgeführt
Auch Daten von nicht beteiligten Anbietern wurden zum Teil in Tests und Analyse einbezogen
Ergebnis
17
Bei allen Anbietern wurde der RFC an bestimmten Stellen unterschiedlich interpretiert. Wie zu erwarten war, traten zunächst Interoperabilitätsprobleme auf
Nach gemeinsamer inhaltlicher Betrachtung und Austausch der Ergebnisse konnte ein weitgehend einheitliches Verständnis herbeigeführt werden
Die Testdaten wurden zu verschiedenen Testfällen mit steigender Komplexität ausgetauscht
Ergebnis
18
Alle Teilnehmer haben sich sehr flexibel gezeigt und sind auch vor Anpassungen des eigenen Codes nicht zurückgeschreckt
Durch die enge Zusammenarbeit konnte bereits eine vollständige Kompatibilität bei der Interpretation und Verifikation der Testdaten zwischen zwei Anbietern hergestellt werden
Nur noch kleine Anpassungen bis das für alle Teilnehmer gilt
Ausblick
19
Weitere Tests werden durchgeführt, mit dem Ziel eine Interoperabilität auch für den Import der ERS-Daten zwischen allen teilnehmenden Anbietern zu erreichen
Weitere Mitglieder sollen in die Testgruppe aufgenommen werden
Bestehende Datenaustauschwege sollen fest etabliert und die bestehenden und hinzukommenden Kontakte regelmäßig gepflegt werden
www.bitkom.org www.digitalewelt.org
Weitere Informationen unter www.ecm-navigator.de
Ihr Ansprechpartner in der BITKOM-Geschäftsstelle
Willi Engel
Bereichsleiter ECM
030.27576 201 [email protected]
