Analyse Signaturverfahren für Open Government Data
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Analyse Signaturverfahren
Dokumentation
für Open Government
Data
Version 1.0, 21.11.2013
Klaus Stranacher – klaus.stranacher@egiz.gv.at
Zusammenfassung: Open Government Data (OGD) gewinnt immer mehr an
Bedeutung – sowohl national durch die Plattform data.gv.at als auch im EU-
weiten 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.
Das E-Government Innovationszentrum ist eine gemeinsame
E-Government
Einrichtung des Bundeskanzleramtes und der TU-Graz
Innovationszentrum
Inffeldgasse 16/a, A-8010 Graz
Tel. +43 316 873 5514
Fax. +43 316 873 5520
E-Mail post@egiz.gv.at
www.egiz.gv.atInhaltsverzeichnis
1 Einleitung .................................................................................................................................... 4
2 Signaturformate......................................................................................................................... 6
2.1 Einleitung ............................................................................................................................. 6
2.2 CAdES Signaturen .............................................................................................................. 6
2.2.1 Einleitung .................................................................................................................. 6
2.2.2 Struktur ...................................................................................................................... 8
2.2.3 Eignung ..................................................................................................................... 9
2.3 XAdES Signaturen ............................................................................................................. 10
2.3.1 Einleitung ................................................................................................................ 10
2.3.2 Struktur .................................................................................................................... 11
2.3.3 Eignung ................................................................................................................... 12
2.4 PAdES Signaturen ............................................................................................................. 13
2.4.1 Einleitung ................................................................................................................ 13
2.4.2 Struktur .................................................................................................................... 13
2.4.3 Eignung ................................................................................................................... 15
3 OGD Datenformate ................................................................................................................ 16
3.1 Strukturierte Datenformate ............................................................................................. 16
3.1.1 CSV.......................................................................................................................... 16
3.1.2 XML .......................................................................................................................... 17
3.1.3 KML .......................................................................................................................... 18
3.1.4 GML ......................................................................................................................... 20
3.1.5 SHP........................................................................................................................... 21
3.1.6 SVG ......................................................................................................................... 22
3.2 Nicht strukturierte Datenformate ................................................................................... 23
3.2.1 PDF .......................................................................................................................... 23
3.2.2 ZIP ............................................................................................................................ 24
4 Signaturfähigkeit ..................................................................................................................... 26
5 Zusammenfassung .................................................................................................................. 27
Einleitung 2Abbildungsverzeichnis Abbildung 1.1 – Grundprinzip vertrauenswürdiges OGD [Stra12] ......................................... 4 Abbildung 2.1 – SignedData Containertyp. ........................................................................... 10 Abbildung 2.2 – XMLDSIG Struktur. ........................................................................................... 12 Abbildung 2.3 – XAdES-BES/EPES Struktur. ............................................................................... 13 Abbildung 2.4 – PDF-Signatur. .................................................................................................. 14 Abbildung 3.1 – SVG-Grafik. ..................................................................................................... 22 Abbildung 3.1 – PDF-Struktur. .................................................................................................... 24 Abbildung 3.2 – ZIP-Struktur. ...................................................................................................... 25 Einleitung 3
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 aktuell1
1043 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 Domäne
Open Data Open Data
Bereitsteller/in Bezieher/in
Lorem ipsum Lorem ipsum
Lorem
dolor ipsum
sit amet, Lorem
dolor ipsum
sit amet,
Lorem
dolor ipsum
sit amet, Lorem
dolor ipsum
sit amet,
consetetur consetetur
dolor sit amet,
consetetur dolor sit amet,
consetetur
sadipscing elitr, SIGNATUR sadipscing elitr,
conseteturelitr,
sadipscing conseteturelitr,
sadipscing
sed diam ERSTELLUNG sed diam
sadipscing elitr,
sed diam sadipscing elitr,
sed diam
nonumy eirmod nonumy eirmod
sed diam
nonumy sed diam
temporeirmod
invidunt nonumy
temporeirmod
invidunt
nonumy
temporeirmod
invidunt nonumy
temporeirmod
invidunt
tempor invidunt tempor invidunt
Original Vertrauenswürdiges
Datenquelle Open Data
Abbildung 1.1 – Grundprinzip vertrauenswürdiges OGD [Stra12]
1 Stichtag: 21.11.2013
Einleitung 4Das 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
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
2.2.1 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 101 733 [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 6Das 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 MAC4
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üsseln5.
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 Ist stark äquivalent zu CMS, mit dem Unterschied,
(Basic Electronic Signature) 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 7CAdES-EPES Erweitert CMS bzw. CAdES-BES dahingehend, dass
(Explicit Policy-based eine explizite Signatur-Richtlinie angegeben werden
Electronic Signature) kann. Die Richtlinie ist mitsigniert ist und muss bei der
Signaturprüfung angewendet werden.
CAdES-T Ist eine BES oder EPES Signatur plus einen
(Electronic signature with Signaturzeitpunkt von einem vertrauenswürdigen
Time) Zeitstempeldienst.
CAdES-C Hierbei werden zusätzlich Referenzen auf alle
(Electronic Signature with verwendeten Zertifikate der Zertifikatskette
Complete validation data angeführt.
references)
CAdES-X Long Zusätzlich zu CAdES-C werden hier die konkreten
(EXtended Long format) Werte der Zertifikate und die konkreten Werte der
Revozierungs-Informationen hinzugefügt.
CAdES-A Erweitert CAdES-X Long um einen oder mehrere
(Archival Form) 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.
2.2.2 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 8eContent 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-BES6 bzw. CAdES-EPES7 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.
2.2.3 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 9SignedData
version
SignerInfo
digestAlgorithms
... version
signerIdentifier
encapsulatedContentInfo
digestAlgorithm
certificates signedAttributes
... ...
crls signatureAlgorithm
...
signature
signerInfos unsignedAttributes
... ...
Abbildung 2.1 – SignedData Containertyp.
2.3 XAdES Signaturen
2.3.1 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 101 903 [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 102.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 Datennormalisierung9 ü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 11Abbildung 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 Eigenschaften11:
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.
2.3.3 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 12Abbildung 2.3 – XAdES-BES/EPES Struktur. 2.4 PAdES Signaturen 2.4.1 Einleitung PAdES steht für PDF Advanced Electronic Signatures und ist ebenso ein ETSI-Standard, der als ETSI TS 102 778[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. 2.4.2 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, 12Es 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
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
Signature Directory
ByteRange
520
Contents:
=Signatur
CMS/CAdES
(nicht mitsigniert)
Signatur
870
%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 142.4.3 Eignung PAdES-Signaturen eignen sich prinzipiell nur für PDF-Dateien. Mittels XFA13 (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
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 3.1.1 CSV 3.1.1.1 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. 3.1.1.2 Struktur CSV wird in [RFC4180] grundlegend beschrieben. Die Strukturierung erfolgt dabei über folgende Trennzeichen: OGD Datenformate 16
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;123456789;1000;Miete
Erika Mustermann;35444;987654321;500;Versicherung
Listing 3.1 – CSV-Beispiel
3.1.1.3 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.
3.1.2 XML
3.1.2.1 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.
3.1.2.2 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 oder .
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 17Um 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 abzugrenzen14, werden so
genannte Namensräume vergeben. In Listing 3.2 ist das urn:namespace:projektdoku.
Einleitung
2
Signaturformate
9
OGD Datenformat
11
Signaturfähigkeit
3
Listing 3.2 – XML-Beispiel
3.1.2.3 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.
3.1.3 KML
3.1.3.1 Einleitung
KML15 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 18kann. 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.
3.1.3.2 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.
Graz
Ortsmarken
#icon-503-FF7C2F
Graz Hauptplatz
15.438237190246582,47.07094025083358,0.0
ff2F7CFF
1.1
OGD Datenformate 19http://www.gstatic.com/mapspro/images/stock/503-wht-
blank_maps.png
Listing 3.3 – KML-Beispiel
3.1.3.3 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.
3.1.4 GML
3.1.4.1 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.
3.1.4.2 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.
47.8088577855618 13.040666193380558
OGD Datenformate 20[...] 47.8088577855618 13.040666193380558
50
Neustadt
Listing 3.4 – GML-Beispiel
3.1.4.3 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.
3.1.5 SHP
3.1.5.1 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 GIS16-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.
3.1.5.2 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 213.1.5.3 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. 3.1.6 SVG 3.1.6.1 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. 3.1.6.2 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. Listing 3.5 – SVG-Beispiel Abbildung 3.1 – SVG-Grafik. OGD Datenformate 22
3.1.6.3 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
3.2.1 PDF
3.2.1.1 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.
3.2.1.2 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 23PDF Dokument
Objekte
Datei Content
Struktur Streams
Dokument
Struktur
Abbildung 3.2 – PDF-Struktur.
3.2.1.3 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.
3.2.2 ZIP
3.2.2.1 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.
3.2.2.2 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 24ZIP Datei
Datei 1
Header
Daten
Beschreibung
Datei n
Entschlüsselungs-
informationen
Zentrales Verzeichnis
%EOF
Abbildung 3.3 – ZIP-Struktur.
3.2.2.3 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 254 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 x x
komprimiert gespeichert werden können
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 265 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
Dokumentenhistorie
Version Datum Autor(en) Anmerkung
0.1 22.10.2013 K.Stranacher Erstversion
0.2 11.11.2013 K.Stranacher Abschnitt 2
0.3 15.11.2013 K.Stranacher Abschnitt 3
1.0 21.11.2013 K.Stranacher Update Abschnitt 3, Abschnitt 4,
Finalisierung
Zusammenfassung 28Referenzen
[CAdES] ETSI, Electronic Signatures and Infrastructures (ESI); CMS Advanced
Electronic Signatures (CAdES), TS 101 733, V 1.8.1
[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.12-20 19.01.2000.
[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, 19.05.2010.
[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, 25.02.2011.
[GML] Open Geospatial Consortium Inc., Geography Markup Language (GML)
– Extended schemas and encoding rules, Version: 3.3.0, 2012-02-07
[KML] Open Geospatial Consortium Inc., KML, Version: 2.2.0, 2008-04-14
[PAdES] ETSI, Electronic Signatures and Infrastructures (ESI); PDF Advanced
Electronic Signature Profiles; Part 3: PAdES Enhanced - PAdES-BES and
PAdES-EPES Profiles, TS 102 778-3, V 1.2.1
[PDF] ISO, Document management - Portable document format - Part 1: PDF
1.7, ISO 32000-1:2008
[RFC2315] B. Kaliski, RFC 2315, PKCS #7: Cryptographic Message Syntax,
Version 1.5, http://tools.ietf.org/html/rfc2315
[RFC4180] Y. Shafranovich, RFC 4180, Common Format and MIME Type for Comma-
Separated Values (CSV) Files, http://tools.ietf.org/html/rfc4180
[RFC5652] R. Housley, RFC 5652, Cryptographic Message Syntax (CMS),
http://tools.ietf.org/html/rfc5652
[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. 124-131.
[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, 16.08.2011
[XAdES] ETSI, Electronic Signatures and Infrastructures (ESI); XML Advanced
Electronic Signatures (XAdES), TS 101 903, V 1.4.1
[XML] Bray et al., Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C
Recommendation, 26 November 2008.
Zusammenfassung 29[XMLDSIG] W3C Empfehlung, XML Signature Syntax and Processing (Second Edition),
2008, http://www.w3.org/TR/xmldsig-core/
[ZIP] PKWARE Inc., ZIP File Format Specification, Version: 6.2.0, 04.26.2004
Zusammenfassung 30Sie können auch lesen
