Analyse Signaturverfahren für Open Government Data

Transkript

1 Dokumentation Analyse Signaturverfahren für Open Government Data Version 1.0, Klaus Stranacher Zusammenfassung: Open Government Data (OGD) gewinnt immer mehr an Bedeutung sowohl national durch die Plattform data.gv.at als auch im EUweiten Kontext durch die aktualisierte PSI-Richtlinie. Fragen der Integrität und Authentizität der veröffentlichten Daten wurde bisher ausgeklammert. Ein Konzept zur Erhöhung der Vertrauenswürdigkeit der Daten wurde im Projekt OpenData und elektronische Dokumente vorgestellt und nutzt elektronische Signaturen als Mittel zum Zweck. Darauf basierend analysiert und untersucht das vorliegende Dokument mögliche Signaturverfahren für OGD-Datenformate. E-Government Innovationszentrum Inffeldgasse 16/a, A-8010 Graz Tel Fax Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

2 Inhaltsverzeichnis 1 Einleitung Signaturformate Einleitung CAdES Signaturen Einleitung Struktur Eignung XAdES Signaturen Einleitung Struktur Eignung PAdES Signaturen Einleitung Struktur Eignung OGD Datenformate Strukturierte Datenformate CSV XML KML GML SHP SVG Nicht strukturierte Datenformate PDF ZIP Signaturfähigkeit Zusammenfassung Einleitung 2

3 Abbildungsverzeichnis Abbildung 1.1 Grundprinzip vertrauenswürdiges OGD [Stra12]... 4 Abbildung 2.1 SignedData Containertyp Abbildung 2.2 XMLDSIG Struktur Abbildung 2.3 XAdES-BES/EPES Struktur Abbildung 2.4 PDF-Signatur Abbildung 3.1 SVG-Grafik Abbildung 3.1 PDF-Struktur Abbildung 3.2 ZIP-Struktur Einleitung 3

4 1 Einleitung Open Government Data (OGD) ist zurzeit eines der großen Themen im Bereich des E- Government. Mit data.gv.at steht hierzu auch eine umfangreiche Plattform mit aktuell Datensätzen und 171 registrierten Anwendungen zur Verfügung. Mit der aktualisierten PSI-Richtlinie wurde auch auf EU-Ebene ein Rahmenwerk geschaffen um zukünftige OGD-Entwicklungen auf eine gemeinsame Basis zu stellen. Eine Thematik, die bisher nicht bzw. nur sehr rudimentär betrachtet wurde, ist die Integrität und Authentizität der veröffentlichten Daten. Im Projekt OpenData und elektronische Dokumente [Stra12] wurde hierzu ein Konzept vorgestellt, das die Vertrauenswürdigkeit von OGD erhöht. Zum Einsatz kommen hierbei elektronische Signaturen. Abbildung 1.1 veranschaulicht dieses Prinzip. In der Domäne der OGD- Bereitstellerin bzw. des OGD-Bereitstellers befindet sich die Original Datenquelle. Diese Daten werden von der Bereitstellerin bzw. vom Bereitsteller signiert und an einer entsprechenden Stelle veröffentlicht. Die OGD-Bezieherin bzw. der OGD-Bezieher kann nun die Signatur über die Daten prüfen. Bei einer positiven Signaturprüfung sind die Daten authentisch (=von der angegebenen Stelle herausgegeben) und integritätsgesichert (=die Daten sind unverändert). Beliebige (nicht vertrauenswürdige) Domäne SIGNATUR PRÜFUNG Domäne Open Data Bereitsteller/in Domäne Open Data Bezieher/in Lorem ipsum Lorem dolor ipsum sit amet, Lorem dolor ipsum consetetur sit amet, dolor sadipscing consetetur sit amet, elitr, sadipscing consetetur sed diam elitr, sadipscing nonumy sed diam elitr, eirmod nonumy sed diam tempor eirmod invidunt nonumy tempor eirmod invidunt tempor invidunt SIGNATUR ERSTELLUNG Lorem ipsum Lorem dolor ipsum sit amet, Lorem dolor ipsum consetetur sit amet, dolor sadipscing consetetur sit amet, elitr, sadipscing consetetur sed diam elitr, sadipscing nonumy sed diam elitr, eirmod nonumy sed diam tempor eirmod invidunt nonumy tempor eirmod invidunt tempor invidunt Original Datenquelle Vertrauenswürdiges Open Data Abbildung 1.1 Grundprinzip vertrauenswürdiges OGD [Stra12] 1 Stichtag: Einleitung 4

5 Das vorgestellte Konzept befasst sich allerdings nicht mit konkreten Signaturverfahren bzw. Signaturformaten. In diesem Projekt wurde evaluiert welche OGD Datenformate eingesetzt werden und welche Signaturverfahren bzw. Signaturformate sich zur Signatur dieser OGD-Datenformate eignen. Der Rest dieses Dokuments ist daher wie folgt aufgebaut. Abschnitt 2 befasst sich mit möglichen Signaturverfahren für OGD. Der folgende Abschnitt 3 gibt einen Überblick über eingesetzte OGD Datenformate und ihre Signaturfähigkeit. Abschnitt 4 fasst die Ergebnisse zusammen und gibt Empfehlungen welches Signaturformat sich für welches OGD Datenformat eignet. Einleitung 5

6 2 Signaturformate 2.1 Einleitung Die rechtliche und organisatorische Basis für elektronische Signaturen im E-Government Kontext ist durch die EU Signaturrichtlinie [Euro00] und ihre nationale Umsetzung im österreichischen Signaturgesetz [SigG10] gegeben. Das Signaturgesetz legt dabei unterschiedliche Ausprägungen von Signaturen mit unterschiedlichen Rechtswirkungen fest. So ist eine fortgeschrittene elektronische Signatur, die mit einer sicheren Signaturerststellungseinheit erstellt wurde und auf einem qualifizierten Zertifikate beruht, der handschriftlichen Unterschrift, bis auf wenige Ausnahmen, gleichgestellt. Durch die große Anzahl an unterschiedlichen Signaturformaten sowohl standardisierte als auch proprietäre entstanden Interoperabilitätsprobleme, speziell im grenzüberschreitenden Kontext. Um hier zu einer Harmonisierung beizutragen und folglich die Interoperabilität zu steigern, wurde von der Europäischen Kommission Referenzformate für fortgeschrittene elektronische Signaturen definiert. Diese Referenzformate sind in der EU Kommissionsentscheidung 2011/130/EU [Euro11] festgelegt. Für die Analyse der Signaturformate sind daher auch nur diese Referenzformate von besonderem Interesse. Die Referenzformate sind: 1. CAdES-BES/EPES Signaturen 2. XAdES-BES/EPES Signaturen 3. PAdES-BES/EPES (Teil 3) Signaturen In den folgenden Abschnitten werden diese drei Formate detaillierter betrachtet und untersucht. 2.2 CAdES Signaturen Einleitung CAdES steht für CMS Advanced Electronic Signature und ist ein ETSI-Standard, der auf CMS (Cryptographic Message Syntax) basiert und als ETSI TS [CAdES] 2 veröffentlicht ist. Ziel dieses Standards war es CMS dahingehende zu erweitern, um den Anforderungen für fortgeschrittene elektronischen Signaturen aus der EU Signaturrichtlinie gerecht zu werden. 2 Es gibt hierbei mehrere Versionen diese Standards. Wir verweisen an dieser Stelle auf jene Version, die in der EU Kommissionsentscheidung 2011/130/EU zu den Referenzformaten festgelegt ist. Signaturformate 6

7 Das Basisformat CMS basiert dabei auf PKCS#7 und ist im RFC 5652 [RFC5652] spezifiziert. CMS erlaubt sowohl das Verschlüsseln als auch das Signieren von Daten. Die CMS Spezifikation sieht vor, dass sämtliche Daten in so genannten ContentInfo-Containern abgelegt werden. Die Daten selbst werden dabei ASN.1 3 codiert. Diese Container können ineinander verschachtelt werden und enthalten einen Containertyp, wobei folgende Typen unterstützt werden: Data: Dieser Typ bezeichnet beliebige Daten SignedData: Bezeichnet signierte Daten (siehe Abschnitt 2.2.2) EnvelopedData und EncryptedData: Mit diesem Typ werden verschlüsselte Daten gekennzeichnet. DigestData: Damit wird gekennzeichnet, wenn Daten um einen zusätzlichen Hashwert zur Integritätssicherung, erweitert werden. AuthenticatedData: Damit sind Daten gekennzeichnet, die mit einem MAC 4 gesichert sind. In anderen RFCs sind auch weitere Containertypen definiert, wie beispielsweise der Typ SignedAndEnvelopedData [RFC2315]. Das ermöglicht es Daten zuerst zu signieren und anschließend zu verschlüsseln 5. Für CAdES wurden nun, basierend auf CMS, Erweiterungen spezifiziert, die es ermöglichen fortgeschrittene elektronische Signaturen abzubilden. Die CAdES- Spezifikation [CAdES]definiert dabei mehrere Formate, die in der folgenden Tabelle 1 angeführt sind. Tabelle 1 CAdES Signaturformate. Format Beschreibung CAdES-BES (Basic Electronic Signature) Ist stark äquivalent zu CMS, mit dem Unterschied, dass das Signaturzertifikat zusätzlich durch die Signatur geschützt ist. 3 Abstract Syntax Notation 1. Ist eine Beschreibungssprache zur Definition, Strukturierung und Repräsentation von Daten. 4 Message Authentication Code. 5 Eine fast idente Möglichkeit bietet hier die CMS Spezifikation selbst, indem man einen SignedData-Container in einen EnvelopedData-Container aufnimmt. Signaturformate 7

8 CAdES-EPES (Explicit Policy-based Electronic Signature) Erweitert CMS bzw. CAdES-BES dahingehend, dass eine explizite Signatur-Richtlinie angegeben werden kann. Die Richtlinie ist mitsigniert ist und muss bei der Signaturprüfung angewendet werden. CAdES-T (Electronic signature with Time) Ist eine BES oder EPES Signatur plus einen Signaturzeitpunkt von einem vertrauenswürdigen Zeitstempeldienst. CAdES-C (Electronic Signature with Complete validation data references) Hierbei werden zusätzlich Referenzen auf alle verwendeten Zertifikate der Zertifikatskette angeführt. CAdES-X (EXtended Long format) Long Zusätzlich zu CAdES-C werden hier die konkreten Werte der Zertifikate und die konkreten Werte der Revozierungs-Informationen hinzugefügt. CAdES-A (Archival Form) Erweitert CAdES-X Long um einen oder mehrere Archiv-Zeitstempel um zukünftigen Schwächen der kryptographischen Verfahren vorzubeugen. Im folgenden Abschnitt wird der Containertyp für signierte Daten als auch die CAdES- Erweiterungen für das BES bzw. EPES Format beschrieben Struktur Dieser Abschnitt befasst sich detaillierter mit dem Containertyp SignedData. Abbildung 2.1 zeigt dabei den Aufbau bzw. die Struktur dieses Typs, der aus folgenden Elementen besteht: Version: Repräsentiert die Versionsnummer der Spezifikation bzw. dieses Containertyps. DigestAlgorithms: Gibt eine Sammlung der Hashalgorithmen an, die innerhalb von signerinfos verwendet werden. EncapsulatedContentInfo: Repräsentiert die signierten Daten und gibt neben den signierten Daten (Container: econtent) auch den Typ der Daten (Container: econtenttype) an. Sind die signierten Daten in diesem Container enthalten, dann handelt es sich um eine enveloping Signatur. Ist der Container Signaturformate 8

9 econtent leer, so handelt es sich um eine detached Signatur und die Daten befinden sich extern. Certificates: Beinhaltet (optional) Zertifikate, die zur Signaturprüfung herangezogen werden. Crls: Beinhaltet (optional) Informationen über den (Widerrufs-)status von Zertifikaten. SignerInfos: Repräsentiert die eigentliche Signatur und hat den Containertyp SignerInfo. Abbildung 2.1 zeigt ebenso diesen SignerInfo Typ, der aus folgenden Elementen aufgebaut ist: Version: Repräsentiert die Versionsnummer der Spezifikation bzw. dieses Containertyps. SignerIdentifier: Spezifiert das Signaturzertifikat bzw. den öffentlichen Schlüssel. DigestAlgorithm: Gibt den Hashalgorithmus an, der zur Erzeugung des Hashwertes verwendet wurde. SignedAttributes: Sind zusätzlich signierte Attribute, die in die Signatur miteinbezogen sind. Innerhalb dieser signierten Attribute sind jene Werte vorhanden, die für eine CAdES-BES 6 bzw. CAdES-EPES 7 Signatur notwendig sind. SignatureAlgoritm: Spezifiziert den verwendeten Signaturalgorithmus. Signature: Repräsentiert den Signaturwert. UnsignedAttributes: Sind zusätzliche Attribute, die jedoch nicht in die Signatur miteingebunden sind Eignung Mittels CAdES-Signaturen können prinzipiell beliebige Daten signiert werden, da die zu signierenden Daten als binäre Strings behandelt werden und das Format der Daten keinen Einfluss hat. 6 Zum Beispiel: Attribut signingtime, das den Signaturzeitpunkt angibt. 7 Zum Beispiel: Attribut: id-aa-ets-sigpolicyid, dass die Signatur-Richtlinie spezifiziert. Signaturformate 9

10 SignedData version digestalgorithms... encapsulatedcontentinfo certificates... SignerInfo version signeridentifier digestalgorithm signedattributes... crls... signaturealgorithm signature signerinfos... unsignedattributes... Abbildung 2.1 SignedData Containertyp. 2.3 XAdES Signaturen Einleitung Analog zu CAdES wurde der Standard XAdES ins Leben gerufen um basierend auf XML-Signaturen (XMLDSIG) fortgeschrittene elektronische XML-basierte Signaturen zu ermöglichen. XAdES steht hierbei für XML Advanced Electronic Signature und ist, ebenso wie CAdES, ein ETSI Standard, veröffentlich unter ETSI TS [XAdES] 8. Analog zu CAdES wurden in XAdES ebenso mehrere Formate definiert. Deren Bedeutung folgt dabei jenen, die in Tabelle 1 angegeben sind. Für unsere Anwendungsfälle sind wiederum nur die Referenzformate XAdES-BES bzw. XAdES-EPES von Bedeutung. Der folgende Abschnitt beschreibt detaillierter den Aufbau und die Struktur von XMLDSIG bzw. XAdES. 8 Es gibt hierbei mehrere Versionen diese Standards. Wir verweisen an dieser Stelle auf jene Version, die in der EU Kommissionsentscheidung 2011/130/EU zu den Referenzformaten festgelegt ist. Signaturformate 10

11 2.3.2 Struktur XMLDSIG ist ein Standard für XML-basierte Signaturen und ist als de-facto Standard als W3C-Empfehlung spezifiziert [XMLDSIG]. Abbildung 2.2 veranschaulicht die prinzipielle Struktur einer XMLDSIG Signatur. Sie besteht aus folgenden Elementen: SignedInfo: Dieses Element kapselt sämtliche Informationen zur Signatur und ist jenes Element über das die Signatur berechnet wird. o CanonicalizationMethod: Definiert einen Kanonisierungsalgorithmus, der dazu dient eine Datennormalisierung 9 über das SignedInfo-Element durchzuführen. o SignatureMethod: Definiert den Signaturalgorithmus mit dem die Daten signiert sind o Reference: Es können ein oder mehrere Referenzen auf signierte Daten angegeben werden. Die Angabe erfolgt dabei über das Attribut URI. Es können hierbei, wie bei CAdES, enveloping und detached Signaturen erzeugt werden. Zusätzlich werden auch enveloped 10 Signaturen unterstützt. Abgesehen von dem Attribute URI können bzw. müssen noch folgende Elemente angegeben werden: Transforms: Optional können Transformationen angegeben werden. Diese werden vor der Hashberechnung auf die in der URI angegebenen Daten angewendet. Das Endresultat dieser Transformationen ist dann der Input für die Hashberechnung. DigestMethod: Spezifiziert den Hashalgorithmus. DigestValue: Repräsentiert den berechneten Hashwert. SignatureValue: Repräsentiert den Signaturwert über das SignedInfo-Element (inklusive der Hashwerte der Referenzen). KeyInfo: Ist ein optionales Element und beinhaltet üblicherweise das Signatorzertifikat. Object: In diesem Element befinden sich Datenobjekte, die normalerweise über einen Referenz in SignedInfo referenziert sind. 9 Diese Kanonisierung eliminiert beispielsweise Whitespaces aus dem SignedInfo-Element, die bei einer Signaturprüfung ansonsten zu Problemen führen können. 10 Hierbei umschließen die signierten Daten die Signatur, d.h. die Signatur ist in den Daten eingebettet. Signaturformate 11

12 Abbildung 2.2 XMLDSIG Struktur. Die, auf dieser Struktur aufbauenden, XAdES Erweiterungen werden durch eine zusätzliche Referenz umgesetzt. Diese zusätzliche Referenz verweist auf ein (weiteres) Objekt, dass die so genannten XAdES-Eigenschaften beinhaltet. Diese Eigenschaften definieren zusätzliche Werte zur Signatur, wie sie u.a. für die Erfüllung der Anforderungen an fortgeschrittene elektronische Signaturen benötigt werden. Abbildung 2.3 zeigt die Struktur einer XAdES-BES/EPES Signatur, wobei das angegeben Objekt diese XAdES-Eigenschaften repräsentiert. Diese XAdES-Properties bestehen aus folgenden signierten Eigenschaften 11 : Signing Time: Beinhaltet den Zeitpunkt der Signaturerstellung im UTC-Format. SingingCertificate: Dieses Element enthält eine eindeutige Referenz auf das Signatorzertifikat. SignaturePolicyIdentifier: Optional, für eine XAdES-EPES Signatur, kann eine Signatur-Richtlinie angegeben werden. DataObjectFormat: In diesem Element wird der MIME-Type der signierten Daten mitgeliefert Eignung XAdES-Signaturen eignen sich offensichtlich speziell für XML-basierte bzw. text-basierte Daten. Andere Daten lassen sich prinzipiell auch über eine Base64-Codierung signieren. Dies hat jedoch eindeutige Performance-Nachteile. 11 Es werden hier nur Eigenschaften angeführt, die laut EU Kommissionsentscheidung 2011/130/EU [Euro11] benötigt werden. Signaturformate 12

13 Abbildung 2.3 XAdES-BES/EPES Struktur. 2.4 PAdES Signaturen Einleitung PAdES steht für PDF Advanced Electronic Signatures und ist ebenso ein ETSI-Standard, der als ETSI TS [PAdES] 12 veröffentlicht ist. Der Standard setzt dabei auf dem PDF- Standard [PDF] auf und umfasst Einschränkungen und Erweiterungen um den Anforderungen für fortgeschrittene elektronische Signaturen zu genügen. Dafür wurden in PAdES Teil 3 Profile für PAdES-BES und PAdES-EPES Signaturen spezifiziert. Für Langzeitanwendungen sind entsprechende Profile in PAdES Teil 4 standardisiert. Der folgende Abschnitt befasst sich detaillierter mit der Struktur von PDF-Signaturen und darauf aufbauend mit PAdES-Signaturen Struktur Der PDF-Standard [PDF] legt fest inwiefern Signaturen in PDF-Dokumente eingebettet werden können. Durch diese Einbettung sind nur enveloped Signaturen möglich, 12 Es gibt hierbei mehrere Versionen diese Standards. Wir verweisen an dieser Stelle auf jene Version, die in der EU Kommissionsentscheidung 2011/130/EU zu den Referenzformaten festgelegt ist. Signaturformate 13

14 enveloping oder detached Signaturen werden nicht unterstützt. Die Signatur selbst basiert dabei auf CMS und wird mittels eines so genannten Signature Directory in das PDF Dokument eingebettet (siehe hierzu auch Abbildung 2.4). Das Signature Directory besteht dabei aus zwei Einträgen. Der erste Eintrag ist eine ByteRange und der zweite enthält die eigentliche Signatur. Die ByteRange gibt dabei an welche Bytes in einem PDF Dokument signiert sind. Da die Signatur selbst im PDF Dokument enthalten ist, muss diese ausgenommen werden. D.h. im abgebildeten Beispiel sind die Bytes 520 bis 870 von der Signatur ausgenommen und werden für die Signaturberechnung auf Null gesetzt. Diese Nullwerte werden nach dem Signaturvorgang mit den Signaturdaten aufgefüllt. PDF Dokument Byte 0 PDF Inhalt =Signatur (nicht mitsigniert) Signature Directory ByteRange Contents: CMS/CAdES Signatur %EOF 1100 Abbildung 2.4 PDF-Signatur. PAdES-Signaturen bedienen sich hierbei desselben Mechanismus des Einbettens der Signatur über das Signature Directory. Im Gegensatz zu herkömmlichen PDF-Signaturen wird jedoch anstatt einer CMS-Signatur eine CAdES-Signatur eingebettet. Um nun eine PAdES-BES bzw. PAdES-EPES Signatur zu erstellen muss einen entsprechende CAdES-BES bzw. CAdES-EPES Signatur erstellt werden. Signaturformate 14

15 2.4.3 Eignung PAdES-Signaturen eignen sich prinzipiell nur für PDF-Dateien. Mittels XFA 13 (XML Forms Architecture) würden sich prinzipiell auch XML-Daten signieren lassen, hat jedoch in der Praxis keine Relevanz. 13 Hiermit lassen sich XML-kodierte Daten in PDF-Dokumenten übertragen. Signaturformate 15

16 3 OGD Datenformate Im Bereich von Open Government Data wird eine Reihe von unterschiedlichen Datenformaten eingesetzt. Die Palette reicht hier von simplen textbasierten Formaten, über strukturierte Daten zu Containerformaten. Teils sind diese Datenformate für den allgemeinen Einsatz gedacht (z.b. CSV) oder sie sind auf bestimmte Einsatzgebiete beschränkt (z.b. geographische Datenformate, wie GML). Prinzipiell kann man bei Datenformaten zwischen strukturierten und nicht strukturierten Daten unterscheiden. Strukturierte Daten erfüllen eines der wichtigsten Grundprinzipien von Open Government Data und sind maschinenlesbar und somit geeignet zur maschinellen Weiterverarbeitung. Im Gegensatz dazu bieten nicht strukturierte Datenformate diese Möglichkeit nicht oder nur in einem beschränktem Ausmaß. Sie werden größtenteils dazu benutzt die Daten visuell ansprechend darzustellen. Sowohl bei strukturierten als auch nicht strukturierten Format kommen teils auch Containerformate zum Einsatz. Hier besteht das Datenformat nicht nur aus einer Datei, sondern aus mehreren. Diese Dateien werden dann in einem eigenen Container zusammengefasst und sind danach somit in sich abgeschlossen. Die folgenden Abschnitte befassen sich nun mit den wichtigsten und gängigsten Datenformate, die innerhalb von Open Government Data eingesetzt werden. Anmerkung: Schnittstellen, die teils fälschlicherweise auch als Datenformat bezeichnet werden, werden nicht behandelt. Das trifft insbesondere auf folgende Schnittstellen zu: WMS (Web Map Service), WFS (Web Feature Service), JSON (JavaScript Object Notation), RSS (Really Simple Syndication) und WMTS (Web Map Tile Service). 3.1 Strukturierte Datenformate CSV Einleitung CSV steht für Comma-separated values und ist eine Textdatei, die es ermöglicht einfach strukturierte Daten auszutauschen. Das Format ist allgemein gültig, d.h. es können prinzipiell beliebige Daten damit übertragen werden, insofern sie einer einfachen Struktur folgen Struktur CSV wird in [RFC4180] grundlegend beschrieben. Die Strukturierung erfolgt dabei über folgende Trennzeichen: OGD Datenformate 16

17 Trennzeichen um Datensätze voneinander zu trennen. Im Allgemeinen ist dies der Zeilenumbruch. Zeichen zur Trennung der Datenfelder. Generell wird hierfür das Komma-Zeichen verwendet. Es können aber auch Semikolon, Doppelpunkt, etc. eingesetzt werden. Detaillierte Angaben zum Format, insbesondere der einzelnen Datenfelder, werden von CSV nicht vorgegeben. Das betrifft insbesondere Vorgaben für Datums- und Zeitangaben. Listing 3.1 zeigt ein Beispiel einer CSV-Datei. Als Trennzeichen für die Datenfelder dient ein Semikolon und zur Trennung der Datensätze wird ein Zeilenumbruch verwendet. Weiters befindet sich in der ersten Zeile die Spaltenüberschriften. Name;BLZ;Konto;Betrag;Verwendungszweck Max Mustermann;12000; ;1000;Miete Erika Mustermann;35444; ;500;Versicherung Listing 3.1 CSV-Beispiel Signaturmöglichkeiten Da CSV Daten textbasiert sind, lassen sie sich sowohl mit CAdES und XAdES signieren. Welcher Signaturvariante der Vorzug gegeben wird hängt dabei vom konkreten Anwendungsfall ab XML Einleitung XML steht für exentsible Markup Language und ist eine Auszeichnungssprache, die von W3C spezifiziert ist [XML]. Die Spezifikation hat formell den Status einer Empfehlung, ist aber seit vielen Jahren ein de-facto Standard. XML ist ein reines Textformat, bietet jedoch die Möglichkeit der strukturierten Beschreibung unterschiedlichster Daten. Die entsprechenden Regeln hierzu sind in der Spezifikation angeführt Struktur Listing 3.2 zeigt ein einfaches Beispiel einer XML-Datei. Sie enthält Daten zur vorliegenden Projektdokumentation, wie die Struktur des Dokuments, die einzelnen Abschnitte und wie viele Seiten der Abschnitt hat. Die Strukturierung erfolgt mittels eigener Elemente, so genannter Tags, wie beispielsweise <abschnitt> oder <name>. Ein XML-Dokument, das den grundlegenden Regel (z.b.: es gibt immer ein Start-Tag und ein Ende-Tag) folgt wird als wohlgeformt bezeichnet. OGD Datenformate 17

18 Um nun die Struktur für bestimmte XML-Daten vorzugeben, können XML Schemen herangezogen werden. Ein XML Schema gibt dabei beispielsweise vor, dass das Element abschnitt zwei Kindelement name und seiten besitzen muss und selber ein Kindelement des Wurzelements projektdokumentation ist. Es können hierbei sehr komplexe Strukturen aufgebaut werden. Folgt eine bestimmte XML-Datei einem Schema so wird diese Datei als gültig bezeichnet. Um ein bestimmtes Schema gegenüber anderen Schemen abzugrenzen 14, werden so genannte Namensräume vergeben. In Listing 3.2 ist das urn:namespace:projektdoku. <?xml version="1.0" encoding="utf -8"?> <ns:projektdokumentation xmlns:ns="urn:namespace:projektdoku"> <ns:abschnitt> <ns:name>einleitung</ns:name> <ns:seiten>2</ns:seiten> </ns:abschnitt> <ns:abschnitt> <ns:name>signaturformate</ns:name> <ns:seiten>9</ns:seiten> </ns:abschnitt> <ns:abschnitt> <ns:name>ogd Datenformat</ns:name> <ns:seiten>11</ns:seiten> </ns:abschnitt> <ns:abschnitt> <ns:name>signaturfähigkeit</ns:name> <ns:seiten>3</ns:seiten> </ns:abschnitt> </ns:projektdokumentation > Listing 3.2 XML-Beispiel Signaturmöglichkeiten Für XML-Daten eignen sich offensichtlich XAdES-Signaturen perfekt. Prinzipiell können XML-Daten auch mit CAdES signiert werden. Dies erscheint aber wenig sinnvoll und wird in der Praxis auch nicht angewendet KML Einleitung KML 15 ist die Abkürzung für Keyhole Markup Language und ist ein, auf XML basierende, Auszeichnungssprache für Geodaten basierend auf Google Earth und Google Maps. Diese Sprache ist dabei sehr mächtig, da sie neben geographischen Informationen (wie Punkte, Linien, Bilder, etc.) auch bestimmte Sachverhalte auf Geodaten abbilden 14 Es könnte beispielsweise unterschiedliche Schemen für Projektdokumentation geben. 15 Auch als KMZ bekannt, wobei KMZ einen ZIP-komprimierte KML-Datei darstellt. OGD Datenformate 18

19 kann. Es ist beispielsweise möglich die Informationen für die Verkehrsauslastung in bestimmten Regionen in einer KML-Datei abzuspeichern. KML wurde anfangs von der Firma Keyhole entwickelt, inzwischen wurde bzw. wird sie von Google weiterentwickelt und ist in [KML] spezifiziert. Im einfachsten Anwendungsfall werden über KML so genannte Ortsmarken genutzt um bestimmte Orte zu markieren. Weitere komplexer Anwendungsfälle sind beispielsweise detaillierte Karten und Modelle um Wetter oder Erdbebenaktivitäten zu kennzeichnen Struktur Listing 3.3 zeigt eine beispielhafte KML-Datei. Darin wird eine Karte referenziert, die als Ortsmarke den Grazer Hauptplatz markiert. Die Angabe der Ortsmarke erfolgt über das Element Placemark und besteht aus folgenden Kindelementen: styleurl: Referenziert einen Stil, der angibt wie die Ortsmarke angezeigt werden soll. name: Repräsentiert den Namen der Ortsmarke. description: Enthält eine (optionale) Beschreibung der Ortsmarke. Point: Enthält die Koordinaten der Ortsmarke. Das nachfolgende Style Element definiert den Stil wie das Icon der Ortsmarke aussieht. <?xml version= 1.0 encoding= UTF-8?> <kml xmlns=' <Document> <name>graz</name> <description><![cdata[karte Graz]]></description> <Folder> <name>ortsmarken</name> <Placemark> <styleurl>#icon-503-ff7c2f</styleurl> <name>graz Hauptplatz</name> <description><![cdata[der Grazer Hauptplatz]]></description> <Point> <coordinates> , ,0.0</coordinates> </Point> </Placemark> </Folder> <Style id='icon-503-ff7c2f'> <IconStyle> <color>ff2f7cff</color> <scale>1.1</scale> <Icon> OGD Datenformate 19

20 <href> </Icon> </IconStyle> </Style> </Document> </kml> Listing 3.3 KML-Beispiel Signaturmöglichkeiten KML basiert auf XML. Dadurch eignet sich XAdES sehr gut als Signaturformat. Für die komprimierte Variante als KMZ-Datei würde aber prinzipiell auch das CAdES-Format geeignet sein GML Einleitung GML ist ebenso wie KML eine Auszeichnungssprache für Geodaten. GML steht dabei für Geography Markup Language und ist in [GML] spezifiziert. Sie basiert, ebenso wie KML, auf XML. GML dient der standardisierten Kodierung von geographischen Informationen. D.h. GML wird dazu genutzt um Objekte (wie Straßen, Häuser, Brücken, etc.) inkl. ihrer Eigenschaften zu beschreiben. In Kontrast dazu dient KML dazu der Visualisierung geographischer Informationen (über Ortsmarken beispielsweise). So kann zum Beispiel das GML-Objekt Grazer Hauptplatz über eine KML Ortsmarke visualisiert werden Struktur Listing 3.4 zeigt eine beispielhafte GML-Datei. Sie zeigt, ausschnittsweise, einen Zählbezirk der Stadt Salzburg. Der Zählbezirk Neustadt (Element ogdsbg:name) mit dem Code 50 (Element ogdsbg:code) wird dabei mittels eines Polygons eingegrenzt. Über das Element gml:polygon/gml:exterior/gml:linearring/gml:poslist wird mit den Startkoordinaten ein Polygon gezogen, dass wiederum im Startpunkt endet. <?xml version= 1.0 encoding= UTF-8?> <gml:featuremembers> <ogdsbg:zaehlbezirk gml:id="zaehlbezirk.576"> <ogdsbg:geometrie> <gml:multisurface srsdimension="2" srsname="urn:xogc:def:crs:epsg:4326"> <gml:surfacemember> <gml:polygon srsdimension="2"> <gml:exterior> <gml:linearring srsdimension="2"> <gml:poslist> OGD Datenformate 20

21 [...] </gml:posList> </gml:linearring> </gml:exterior> </gml:polygon> </gml:surfacemember> </gml:multisurface> </ogdsbg:geometrie> <ogdsbg:code>50</ogdsbg:code> <ogdsbg:name>neustadt</ogdsbg:name> </ogdsbg:zaehlbezirk> </gml:featuremembers> Listing 3.4 GML-Beispiel Signaturmöglichkeiten GML basiert auf XML. Dadurch eignet sich XAdES sehr gut als Signaturformat. Prinzipiell kann man auch die GML-Datei Base64-kodieren und dann mittels CAdES signieren. Dieser Zugang ist aber praktisch nicht sinnvoll SHP Einleitung SHP bedeutet Shapefile und wurde vom Environmental Systems Research Institute spezifiziert. Es ist ein Vektor-Datenformat für Geodaten. Durch seinen langen Bestand und die weite Verbreitung im GIS 16 -Umfeld hat SHP sich als de-facto Standard in diesem Bereich herauskristallisiert. SHP repräsentiert dabei beispielsweise Flüsse, Seen oder Brücken über Vektor-Funktionen, wie Punkt, Linien oder Polygone Struktur SHP besteht nicht aus einer einzelnen Datei sondern aus zumindest folgenden drei Dateien SHP-Datei: Diese Datei dient zur Speicherung der Geometriedaten. DBF-Datei: Enthält die Sachdaten in Format für die Datenbankapplikation dbase. SHX-Datei: Beinhaltet einen Index zur Verknüpfung der Sachdaten. Optionale Dateien beinhalten beispielsweise Metadaten oder weitere Indizes um verschieden Attribute und Werte wiederzufinden. Alle diese Dateien werden üblicherweise in einem gemeinsamen Containerformat, wie beispielsweise ZIP, zur Verfügung gestellt. 16 Geographische Informationssysteme. OGD Datenformate 21

22 Signaturmöglichkeiten Durch das zur Verfügung stellen in einem Containerformat eignen sich CAdES-Signatur am besten zur Sicherung der Integrität und Authentizität. Auch an dieser Stelle könnte man prinzipiell wieder die Base64-Kodierung mittels XAdES signieren. Das ist aber wiederum weder sinnvoll noch praktikabel SVG Einleitung SVG ist die Abkürzung für Scalable Vector Graphics und ist als W3C Empfehlung unter [SVG] spezifiziert. Dieses Format dient der Beschreibung (zweidimensionaler) Vektorgrafien. SVG ist dabei XML basiert, kann jedoch auch komprimiert gespeichert werden Struktur SVG unterscheidet prinzipiell drei Elementtypen: aus grafischen Primitiven (wie Linie, oder Rechteck)aufgebaute Vektorgrafiken, eingebundenen Rastergrafiken und Textelementen. Listing 3.5 zeigt beispielhaft eine SVG-Datei einer einfachen Vektorgrafik (siehe auch Abbildung 3.1), die aus drei grafischen Primitiven aufgebaut ist. In diesem Listing wird zuerst ein Rechteck mit den angegebenen Koordinaten sowie Länge und Breite gezeichnet. Anschließend wird eine horizontale Linie mit Start- und Endpunkt angegeben. Abschließend wird mit einem Polygon ein Dreieck mit den entsprechenden Koordinaten gezeichnet. <?xml version="1.0" encoding="utf-8"?> <svg xmlns=" version="1.1" baseprofile="full" width="600px" height="600px" viewbox=" "> <rect x="250" y="100" width="100" height="500" fill="white" stroke="black" stroke-width="10px"/> <line x1="0" y1="300" x2="600" y2="300" stroke="black" stroke-width="10px"/> <polygon points=" " fill="white" stroke="black" stroke-width="10px"/> </svg> Listing 3.5 SVG-Beispiel Abbildung 3.1 SVG-Grafik. OGD Datenformate 22

23 Signaturmöglichkeiten SVG basiert auf XML. Dadurch eignet sich XAdES sehr gut als Signaturformat. Für die komprimierte Variante würde aber prinzipiell auch das CAdES-Format geeignet sein. 3.2 Nicht strukturierte Datenformate PDF Einleitung PDF steht für Portable Document Format und ist ein seit vielen Jahren etablierter Standard. Seit der Version 1.7 ist PDF ein ISO-Standard und unter [PDF] veröffentlicht. Der PDF-Standard ist sehr umfangreich und basiert auf PostScript. Der Hauptzweck von PDF ist stark auf die Repräsentation und Visualisierung von elektronischen Inhalten fokussiert. Auch erlaubt PDF die Einbindung von Formularen, Kommentaren und dynamischen Inhalten Struktur Abbildung 3.2 zeigt den prinzipiellen Aufbau eines PDF-Dokuments, der aus folgenden vier Teilen besteht: Objekte: Ein PDF Dokument besteht im Allgemein aus Datenstrukturen, die aus Basistypen von Objekte zusammengesetzt sind. PDF definiert u.a. folgende Basistypen: Boolsche Werte, Zahlenwerte, Zeichenketten und Dictionaries. Es gibt hierbei direkte (Objekte, die in ein anderes Objekt eingebunden sind) oder indirekte Objekte. Indirekte Objekte erhalten eine Objekt- und Generierungs- Nummer. Eine Index-Tabelle referenziert dabei auf diese indirekten Objekte. Dieser Ansatz erlaubt es auch inkrementelle Aktualisierung eines PDF-Dokuments vorzunehmen ohne das gesamte Dokument neu zu schreiben. Datei Struktur: Diese Struktur bestimmt wie die Objekte im PDF Dokument abgespeichert, ausgelesen und verändert werden. Die Struktur ist dabei unabhängig von der semantischen Bedeutung der Objekte. Dokument Struktur: Die Dokument Struktur spezifiziert (hierarchisch) wie die Basis- Objekttypen (Seiten, Schriften, Anmerkungen, etc.) im Dokument repräsentiert werden. Content Streams: Diese Streams enthalten eine Sequenz an Instruktionen, die das Aussehen der Seite bestimmen. OGD Datenformate 23

24 PDF Dokument Objekte Datei Struktur Content Streams Dokument Struktur Abbildung 3.2 PDF-Struktur Signaturmöglichkeiten Für PDF-Daten eignen sich offensichtlich PAdES-Signaturen perfekt. Prinzipiell könnte man auch die PDF-Daten Base64 codieren und mittels XAdES signieren. Dieser Variante erscheint aber weder sinnvoll noch praktikabel ZIP Einleitung Das ZIP-Dateiformat dient zweierlei Zwecken. Zum einen wird es als Containerformat genutzt um mehrere Dateien und Verzeichnis zusammenzufassen. Andererseits dient es auch der Komprimierung der enthaltenen Dateien. Das Format gibt es seit 1989 und hat sich schnell zu einem weltweiten Standard herauskristallisiert und ist unter [ZIP] spezifiziert Struktur Abbildung 3.3 zeigt den grundsätzlichen Aufbau einer ZIP-Datei, der aus folgenden Komponenten besteht: Dateien 1 bis n: Diese Dateien repräsentieren die Daten, die in der ZIP-Datei enthalten sind und besteht aus folgenden Unter-Komponenten: o Header: Beinhaltet Informationen zur Dekodierung der Dateiinhalte. o Daten: Die komprimierten Dateiinhalte. o Beschreibung: Optional können noch weitere Beschreibungen angegeben werden, wie beispielsweise Prüfsummen. Entschlüsselungsinformationen: Optional befinden sich an dieser Stelle Informationen zur Entschlüsselung der Daten, insofern die Daten bei der Erstellung der ZIP-Datei verschlüsselt wurden. Zentrales Verzeichnis: Enthält eine Liste aus Dateiheadern, die Informationen wie Dateiname, Dateigröße und Prüfsumme enthalten. EOF: EOF bezeichnet das Dateiende und inkludiert den Abschluss des zentralen und anderer Verzeichnisse. OGD Datenformate 24

25 ZIP Datei Datei 1 Header Daten Beschreibung Datei n Entschlüsselungsinformationen Zentrales Verzeichnis %EOF Abbildung 3.3 ZIP-Struktur Signaturmöglichkeiten ZIP-Daten eignen können prinzipiell wieder Base64-kodiert mittels XAdES signiert werden. Für den praktischen Einsatz eigen sich jedoch CAdES-Signaturen weit besser. OGD Datenformate 25

26 4 Signaturfähigkeit Im den vorhergehenden Abschnitten wurde die gängigsten OGD-Datenformate analysiert speziell hinsichtlich ihrer Signaturfähigkeit. Tabelle 2 fasst die Ergebnisse zusammen. Es konnte für jedes OGD-Datenformat zumindest ein sinnvolles und praktikables Signaturformat gefunden werden. Wobei speziell XAdES und CAdES je nach OGD Format die beste Wahl sind. PAdES-Signaturen sind hierbei nur für PDF- Daten geeignet. Tabelle 2 Signaturfähigkeit. Format Kurzbeschreibung CAdES XAdES PAdES CSV Text basiertes Format mit der Möglichkeit x einer einfach strukturierten Angabe der Daten über Trennzeichen. XML Text basiertes Format mit der Möglichkeit x x sehr komplexe Strukturen über XML- Elemente abzubilden. KML/KMZ XML basiertes Geodatenformat speziell für 17 x Google Earth und Google-Maps GML XML basiertes Geodatenformat zur x x Beschreibung von Objekten und deren Eigenschaften SHP Geodatenformat speziellen für den Einsatz x x in GIS-Anwendungen und aus mehreren Dateien bestehend SVG XML basiertes Format für skalierbare 18 x Vektorgrafiken PDF Datei im weltweit etablierten PDF-Format x x ZIP Containerformat in dem beliebige Dateien komprimiert gespeichert werden können x x 17 Prinzipiell eignet sich XAdES für KML besser. Für die ZIP-komprimierte Variante (KMZ) kommt aber auch CAdES in Frage. 18 Prinzipiell eignet sich XAdES für SVG besser. Für die ZIP-komprimierte Variante kommt aber auch CAdES in Frage. Signaturfähigkeit 26

27 5 Zusammenfassung In diesem Projekt wurde mögliche und passende Signaturformate für ein vertrauenswürdiges Open Government Data untersucht. Der Fokus wurde dabei auf die Referenzformate CAdES, XAdES und PAdES der EU Kommissionsentscheidung 2011/130EU [Euro11] gelegt. Für die gängigsten OGD Datenformat wurde zumindest jeweils ein Referenz-Signaturformat gefunden, womit die Daten authentisch und integritätsgesichert veröffentlicht werden können. Basierend auf den Ergebnissen dieser Untersuchung wird im Projekt Umsetzung Vertrauenswürdiges OGD ein Demonstrator entwickelt, der sich signierter öffentlicher Daten bedient und das Konzept für eine vertrauenswürdiges OGD untermauert. Zusammenfassung 27

28 Dokumentenhistorie Version Datum Autor(en) Anmerkung K.Stranacher Erstversion K.Stranacher Abschnitt K.Stranacher Abschnitt K.Stranacher Update Abschnitt 3, Abschnitt 4, Finalisierung Zusammenfassung 28

29 Referenzen [CAdES] ETSI, Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures (CAdES), TS , V [Euro00] European Union, Directive 1999/93/EC of the European Parliament and of the Council of 13 December 1999 on a Community framework for electronic signatures, Official Journal L 13, pp [Euro03] European Union (2003) Directive 2003/98/EC of the European Parliament and the Council of 17 November 2003 on the re-use of public sector information. [Euro06] Richtlinie 2006/123/EG des Europäischen Parlaments und des Rates vom 12. Dezember 2006 über Dienstleistungen im Binnenmarkt. [Euro10] European Commission, Communication from the Commission to the European Parliament, the Council, the European Economic and Social Committee and the Committee of the Regions A Digital Agenda for Europe, COM/2010/0245, [Euro11] European Commission Decision, Establishing minimum requirements for the cross-border processing of documents signed electronically by competent authorities under Directive 2006/123/EC of the European Parliament and of the Council on services in the internal market, notified under document C(2011) 1081, 2011/130/EU, [GML] Open Geospatial Consortium Inc., Geography Markup Language (GML) Extended schemas and encoding rules, Version: 3.3.0, [KML] Open Geospatial Consortium Inc., KML, Version: 2.2.0, [PAdES] ETSI, Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles; Part 3: PAdES Enhanced - PAdES-BES and PAdES-EPES Profiles, TS , V [PDF] ISO, Document management - Portable document format - Part 1: PDF 1.7, ISO :2008 [RFC2315] B. Kaliski, RFC 2315, PKCS #7: Cryptographic Message Syntax, Version 1.5, [RFC4180] Y. Shafranovich, RFC 4180, Common Format and MIME Type for Comma- Separated Values (CSV) Files, [RFC5652] R. Housley, RFC 5652, Cryptographic Message Syntax (CMS), [SHP] Environmental Systems Research Institute, ESRI Shapefile Technical Description, Juli 1998 [SigG10] Bundesgesetz über elektronische Signaturen (Signaturgesetz - SigG) StF: BGBl. I Nr. 190/1999, letzte Änderung: BGBl. I Nr. 75/2010 [StKZ13] K. Stranacher, V. Krnjic, T. Zefferer, Trust and Reliability for Public Sector Data, in Proceedings of International Conference on e-business and e- Government 2013, Issue 73, 2013, pp [Stra12] K. Stranacher, EGIZ Projekt-Dokumentation OpenData und elektronische Dokumente, Version 1.0, 14.November 2012 [SVG] Dahlström et al., Scalable Vector Graphics (SVG) 1.1 (Second Edition), W3C Empfehlung, Version 1.1, [XAdES] ETSI, Electronic Signatures and Infrastructures (ESI); XML Advanced Electronic Signatures (XAdES), TS , V [XML] Bray et al., Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation, 26 November Zusammenfassung 29

30 [XMLDSIG] W3C Empfehlung, XML Signature Syntax and Processing (Second Edition), 2008, [ZIP] PKWARE Inc., ZIP File Format Specification, Version: 6.2.0, Zusammenfassung 30