Dokumentation Strategiekonformität

Transkript

1 Telefon: ++43 (316) Fax: ++43 (316) Inffeldgasse 16a / 8010 Graz / Austria Dokumentation Strategiekonformität Version 1.0, 30. Juli 2008 DI Klaus Stranacher klaus.stranacher@egiz.gv.at Zusammenfassung: Im Bereich der elektronischen Dokumente hat Microsoft ein neues Dokumentenformat namens XPS entwickelt. XPS steht für XML Paper Specification und ist ein Format zur Beschreibung und Darstellung von Seiten eines Dokuments. In diesem Dokument wird die Spezifikation von XPS dahingehend untersucht, ob dieses Format im Teilaspekt elektronische Signatur im E-Government geeignet ist. Dabei ist zu berücksichtigen ob XPS für die qualifizierte Signatur bzw. die Darstellbarkeit oder Rückführbarkeit einer Amtssignatur geeignet ist. Inhaltsverzeichnis: Abbildungsverzeichnis... 3 Revision History Einleitung XPS Gesetzliche Bestimmungen Signaturgesetz ( 2) Signaturverordnung SigV ( 4) E-Government Gesetz E-GovG ( 19 und 20) Problematik dynamischer oder verdeckter Elemente XPS Einleitung Logischer Layer Physikalischer Layer 9 4 Signaturen mit XPS Einleitung Digitale Signatur Parts Signatur Verifikation 13 5 Analyse des Formats Signaturverordnung Eignung als Amtssignatur Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

2 5.2 Beispiele Beispiel Beispiel 2 (Signatur) Beispiel 3 (Signatur) Beispiel 4 (Signatur) Beispiel 5 (Fontsubstituition) Schlussbemerkung Referenzen

3 Abbildungsverzeichnis Abbildung 3-1: Logischer Layer... 9 Abbildung 3-2: Physikalischer Layer Abbildung 3-3: Zusamenhang physikalischer und logischer Layer Abbildung 4-1: Digitale Signatur Abbildung 4-2: Zusamenhang physikalischer und logischer Layer bei einer digitalen Signatur Abbildung 4-3: Signatur Verifikation Abbildung 5-1: XPS-Viewer

4 Revision History Version Datum Autor(en) Klaus Stranacher Finaler Entwurf Herbert Leitold Kommentare Klaus Stranacher Überarbeitungen 4

5 1 Einleitung 1.1 XPS Diese Studie behandelt das Dokumentenformat XPS. In diesem Dokument wird dabei die Spezifikation von XPS dahingehend untersucht, ob dieses Format im Teilaspekt elektronische Signatur im E-Government geeignet ist. Dabei ist zu berücksichtigen ob XPS für die qualifizierte Signatur bzw. die Darstellbarkeit oder Rückführbarkeit einer Amtssignatur geeignet ist. 1.2 Gesetzliche Bestimmungen Für diese Studie sind folgende Gesetze bzw. Verordnungen relevant: Signaturgesetz [SigG] Signaturverordnung [SigV] E-Government Gesetz [E-GovG] Diese Gesetze und Verordnungen wurden zu Beginn des Jahres 2008 einer Novelle unterzogen. Nachfolgend werden die für die Studie wichtigsten Gesetzestexte wiedergegeben Signaturgesetz ( 2) 2. Im Sinne dieses Bundesgesetzes bedeuten 1. [ ] 2. Signator: eine Person oder eine sonstige rechtsfähige Einrichtung, der Signaturerstellungsdaten und Signaturprüfdaten zugeordnet sind und die im eigenen oder fremden Namen eine elektronische Signatur erstellt; 3. fortgeschrittene elektronische Signatur: eine elektronische Signatur, die a) ausschließlich dem Signator zugeordnet ist, b) die Identifizierung des Signators ermöglicht, c) mit Mitteln erstellt wird, die der Signator unter seiner alleinigen Kontrolle halten kann, sowie d) mit den Daten, auf die sie sich bezieht, so verknüpft ist, dass jede nachträgliche Veränderung der Daten festgestellt werden kann; 3a. qualifizierte elektronische Signatur: eine fortgeschrittene elektronische Signatur, die auf einem qualifizierten Zertifikat beruht und von einer sicheren Signaturerstellungseinheit erstellt wird; Signaturverordnung SigV ( 4) Technische Sicherheitserfordernisse für die Systemumgebung der Signaturerstellungseinheit bei qualifizierten Signaturen 4. (1) Die Spezifikation eines Formats für zu signierende Daten muss allgemein verfügbar sein und sicherstellen, dass die signierten Daten sowohl bei der Signaturerstellung als auch bei der Signaturprüfung zweifelsfrei und mit gleichem Ergebnis darstellbar sind. Können in einem Format dynamische Änderungen codiert werden, so dürfen jene Elemente, die dynamische Änderungen hervorrufen können, nicht verwendet werden. (2) [ ] E-Government Gesetz E-GovG ( 19 und 20) Amtssignatur 19. 5

6 (1) Die Amtssignatur ist eine fortgeschrittene elektronische Signatur im Sinne des Signaturgesetzes, deren Besonderheit durch ein entsprechendes Attribut im Signaturzertifikat ausgewiesen wird. (2) Die Amtssignatur dient der erleichterten Erkennbarkeit der Herkunft eines Dokuments von einem Auftraggeber des öffentlichen Bereichs. Sie darf daher ausschließlich von diesen unter den näheren Bedingungen des Abs. 3 bei der elektronischen Unterzeichnung und bei der Ausfertigung der von ihnen erzeugten Dokumente verwendet werden. (3) Die Amtssignatur ist im Dokument durch eine Bildmarke, die der Auftraggeber des öffentlichen Bereichs im Internet als die seine gesichert veröffentlicht hat, sowie durch einen Hinweis im Dokument, dass dieses amtssigniert wurde, darzustellen. Die Informationen zur Prüfung der elektronischen Signatur sind vom Auftraggeber des öffentlichen Bereichs bereitzustellen. Beweiskraft von Ausdrucken 20. Ein auf Papier ausgedrucktes elektronisches Dokument einer Behörde hat die Beweiskraft einer öffentlichen Urkunde ( 292 der Zivilprozessordnung ZPO, RGBl. Nr. 113/1895), wenn das elektronische Dokument mit einer Amtssignatur versehen wurde. Die Amtssignatur muss durch Rückführung des Dokuments aus der ausgedruckten in die elektronische Form prüfbar oder das Dokument muss durch andere Vorkehrungen der Behörde verifizierbar sein. Das Dokument hat einen Hinweis auf die Fundstelle im Internet, wo das Verfahren der Rückführung des Ausdrucks in das elektronische Dokument und die anwendbaren Prüfmechanismen enthalten sind, oder einen Hinweis auf das Verfahren der Verifizierung zu enthalten. 6

7 2 Problematik dynamischer oder verdeckter Elemente Die Problematik dynamischer oder verdeckter Elemente wurde bereits in einer vorangegangenen Studie ausführlich behandelt (siehe [PDFA]). Aus diesem Grunde werden hier nur die wichtigsten Punkte nochmals angeführt. Laut Signaturverordnung ist sicherzustellen dass die signierten Daten sowohl bei der Signaturerstellung als auch bei der Signaturprüfung zweifelsfrei und mit gleichem Ergebnis darstellbar sind.. Aufgrund der folgenden angeführten Punkte kann nun im Allgemeinen zwischen Signaturzeitpunkt und Betrachtungszeitpunkt eine unterschiedliche Darstellung der Daten erfolgen: Dokumentenformat: Diese Probleme sind auf das jeweilige Dokumentenformat zurückzuführen. Man unterscheidet dabei zwischen folgenden Problemfaktoren: o Dynamische Elemente (Javascript): Hierbei besteht die Problematik darin, dass durch die Verwendung dynamischer Elemente eine Kontext- bzw. Zeitabhängigkeit entsteht. Dies ist beispielsweise dann der Fall, wenn ein Dokument einen Javascript-Code enthält, der datumsabhängig einen anderen Text ausgibt. o Verdeckter/unsichtbarer Inhalt (Transparenz): Die Problematik in diesem Fall ist, dass durch die Verwendung transparenter Grafiken, Effekte auftreten können, die nicht erwünscht sind. Dies ist beispielsweise der Fall, wenn ein Viewer die Transparenz nicht richtig erkennt. Systemintegrität: Die Ursache der Manipulation liegt nicht am Dokumentenformat, sondern ist viel mehr im System zu suchen. Zu Systemintegrität zählen vor allem externe Referenzen. o Externe Referenzen: Hierbei sind Verweise vom jeweiligen Dokument auf externe Daten, wie Bilder oder Fonts, angesprochen. Die Problematik dabei ist, dass diese externen Daten durch andere ersetzt werden können. So kann beispielsweise bei einer Fontsubstituition ein Font durch einen anderen ersetzt und somit der Inhalt des Textes verändert werden. 7

8 3 XPS 3.1 Einleitung XPS steht für XML Paper Specification und wurde von Microsoft entwickelt. Erstmals an die Öffentlichkeit gebracht wurde dieses Format im April 2005, damals noch unter dem Namen Next Generation Print Path (Codename Metro). Veröffentlicht wurde XPS anschließend via Windows Vista bzw. für die Version 3 des.net-frameworks für Windows XP. XPS stellt dabei eine offene Spezifikation dar, die unter [XPSSpec] abgerufen werden kann. Bei XPS handelt es sich um eine XML-basierte Seitenbeschreibungssprache. Aufgrund der Geräte- und Auflösungs-Unabhängigkeit sowie vieler weiterer Eigenschaften, wird XPS oft auch als Konkurrenzprodukt zu Adobes PDF angesehen. Dabei benutzt XPS ein fixiertes Seitenlayout, d.h. unabhängig vom Ausgabemedium (XPS Viewer 1 oder als Ausdruck) ist das völlig idente Dokument zu sehen. Der Betrachter sieht also das Dokument exakt so, wie es vom jeweiligen Autor beabsichtig wurde. Eine XPS Datei stellt dabei einen ZIP-Container (=Package) entsprechend der Open Packaging Convention (OPC) dar. Diese Convention legt ein Dateiformat fest, das es ermöglicht XML und nicht-xml Daten gemeinsam innerhalb einer Datei zu speichern. Spezifiziert ist OPC dabei in Teil 2 des Ecma Office Open XML Standards [ECMA376]. In Folge verweist diese Studie auf die im Container (Package) enthaltenen Dateien. Im folgenden Abschnitt werden das Prinzip und die Grundzüge von XPS näher erläutert. 3.2 Logischer Layer Ein Package besteht aus mehreren Komponenten. Diese Komponenten werden als Parts bezeichnet. Weiters hat jedes Package sowohl eine logische als auch eine physikalische Organisation. Man spricht hierbei von einem logischen bzw. physikalischen Layer. Dabei wird die logische Organisation durch die verschiedenen Parts beschrieben. An der Spitze des logischen Layers steht die FixedDocumentSequence. Sie enthält ein oder mehrere Dokumente, die im FixedDocumentSequence Part angegeben sind. Ein Dokument wird dabei als FixedDocument bezeichnet. Ein FixedDocument referenziert nun weiters sämtliche darin enthaltene Seiten, so genannte FixedPages. Jede dieser FixedPages enthält wiederum die jeweiligen Text-Markups und das Layout der Seite. Weiters enthält sie auch Referenzen auf Bilder, Fonts und allfällige andere Resourcen. Abbildung 3-1 zeigt ein Beispiel eines XPS-Dokumentes. An der Spitze befindet sich eine FixedDocumentSequence, die zwei FixedDocuments referenziert. Diese referenzieren wiederum jeweils zwei FixedPages. FixedPage#1 und FixedPage#2 enthalten dabei jeweils Referenzen auf zwei unterschiedliche Fonts und Bilder. Im Gegensatz dazu enthalten FixedPage#3 und FixedPage#4 jeweils Referenzen auf die gleichen Bilder bzw. den gleichen Font. Es können also Resourcen gemeinsam genützt werden. 1 XPS-Viewer (Internet Explorer oder XPS Viewer EP) ist bei Windows Vista bereits integriert. Für Windows XP muss die Version 3 des.net-frameworks installiert werden. 8

9 FixedDocumentSequence FixedDocument #1 FixedDocument #2 FixedPage #1 FixedPage #2 FixedPage #3 FixedPage #4 Font Font Font Bild Bild Bild Bild Abbildung 3-1: Logischer Layer 3.3 Physikalischer Layer Der physikalische Layer eines XPS Dokumentes besteht aus den Ordnern und Dateien des jeweiligen Packages. Die einfachste Möglichkeit sich den physikalischen Inhalt eines Packages anzusehen besteht darin, die XPS-Datei zu entpacken und sich anschließend die entsprechende Ordner- und Dateistruktur anzusehen. Abbildung 3-2 zeigt dabei die physikalische Organisation eines XPS Beispiel Dokumentes (siehe auch 5.2.1). Die logische Organisation ist aus diesem Bild nicht zu erkennen. Den Zusammenhang zwischen logischem und physikalischem Layer zeigt Abbildung 3-3. An der Spitze steht wiederum die FixedDocumentSequence, die in der Datei FixedDocumentSequence.fdseq angegeben ist. Sie referenziert ein FixedDocument. Des Weiteren sind über ein Relationship 2 auch zwei Metadaten ein Thumbnail und ein Printticket angegeben. Das Relationship ist in der Datei.rels bzw. FixedDocumentSequence.fdseq.rels festgelegt. Beide Metadaten sind dabei in der XPS Spezifikation wie folgt festgelegt: Thumbnail: Ein Thumbnail beinhaltet ein Bild, das den Inhalt einer Seite oder des gesamten Packages repräsentiert. PrintTicket: Ein PrintTicket beinhaltet Einstellungen, die für den Druck des Dokumentes benötigt werden. Die Referenz auf das FixedDocument sieht nun folgendermaßen aus: <FixedDocumentSequence xmlns=" <DocumentReference Source="/Documents/1/FixedDocument.fdoc"/> </FixedDocumentSequence> Daraus ist ersichtlich, dass das FixedDocument in der Datei FixedDocument.fdoc zu finden ist. Das FixedDocument referenziert wiederum eine FixedPage (das Dokument enthält nur eine Seite). Diese Referenz ist wie folgt angegeben: 2 Ein Relationship stellt eine logische Verbindung zwischen zwei Objekten her. 9

10 <FixedDocument xmlns=" <PageContent Source="/Documents/1/Pages/1.fpage"/> </FixedDocument> Das dazugehörige PrintTicket wird über ein Relationship in der Datei FixedDocument.fdoc.rels angeben. Abbildung 3-2: Physikalischer Layer Die Datei 1.fpage (= die FixedPage) enthält nun die entsprechenden Text- und Bild-XML- Markups in denen die jeweiligen Daten angegeben sind, um den Inhalt der Seite genau zu bestimmen. Der Inhalt dieser Datei sieht exemplarisch wie folgt aus: <FixedPage Width="793.76" Height=" " xmlns=" xml:lang="und"> <Glyphs Fill="#ff000000" FontUri="/Documents/1/Resources/Fonts/F7297B13-A1E A- 8A32FE5C981C.odttf" FontRenderingEmSize=" " StyleSimulations="None" OriginX="94.4" OriginY="108.8" Indices="39;68;86,38;3;76;86,40;87;3;72;76,27;81;3;55;72;91,51;87 ;3;76;81;3;55;76;80,79;72;86,37;3;49;72;90;3,24;53;82,51;80;68;81,49;17;3" UnicodeString="Das ist ein Text in Times New Roman. "/>... </FixedPage> Hierbei werden über die obigen Attribute folgende Inhalte angegeben: Layoutinformationen Fontinformationen Textinformationen 10

11 Abschließend enthält das FixedPage-Relationship (Datei: 1.fpage.rels) noch einen Verweis auf ein PrintTicket. Logischer Layer Physikalischer Layer FixedDocumentSequence Datei: FixedDocumentSequence.fdseq Ort: / Referenziert von: _rels/.rels Thumbnail Datei: Page1_Thumbnail.JPG Ort: /Documents/1/Metadata Referenziert von: _rels/.rels PrintTicket Datei: Job_PT.xml Ort: /Metadata Referenziert von: _rels/fixeddocumentsequence.fdseq.rels FixedDocument 1 Datei: FixedDocument.fdoc Ort: /Documents/1 Referenziert von: /FixedDocumentSequence.fdseq PrintTicket Datei: Job_PT.xml Ort: /Metadata Referenziert von: /Documents/1/rels/FixedDocument.fdoc.rels FixedPage 1 Datei: 1.fpage Ort: /Documents/1/Pages Referenziert von: /Documents/1/FixedDocument.fdoc Image Datei: 1.jpg Ort: /Documents/1/Resources/Images Referenziert von: /Documents/1/Pages/1.fpage Font Datei: 86AFEEB3-D92A-4734-B3C4-55BA odttf Ort: /Documents/1/Resources/Fonts Referenziert von: /Documents/1/Pages/1.fpage Font Datei: F7297B13-A1E A-8A32FE5C981C.odttf Ort: /Documents/1/Resources/Fonts Referenziert von: /Documents/1/Pages/1.fpage PrintTicket Datei: Page1_PT.xml Ort: /Documents/1/Metadata Referenziert von: /Documents/1/Pages/_rels/1.fpage.rels Abbildung 3-3: Zusamenhang physikalischer und logischer Layer 11

12 4 Signaturen mit XPS 4.1 Einleitung XPS sieht auch die Möglichkeit vor, digitale Signaturen auf ein XPS-Dokument aufzubringen. Somit ist es möglich die Integrität eines Dokumentes zu überprüfen. Grundsätzlich werden Signaturen entsprechend der XMLDSIG-Spezifikation [XMLDSIG] erzeugt und überprüft. Es wurden dabei einige Modifikationen vorgenommen. Diese Änderungen betreffen aber nur Teile der XMLDSIG-Spezifikation, an deren Stelle der any-namespace erlaubt ist. Die entstehenden Signaturen sind daher allenfalls XMLDSIG-konforme Signaturen, weshalb diese Modifikationen hier nicht weiter betrachtet werden. Im Folgenden wird kurz auf den Signaturmechanismus von XPS eingegangen. 4.2 Digitale Signatur Parts Eine XPS Signatur besteht im Allgemeinen aus folgenden drei Parts: Digitale Signatur Origin Part Digitale Signatur XML Signature Part Digitale Signatur Certificate Part Der Origin Part ist sozusagen der Startpunkt für alle Signaturen die sich im Package befinden. Er referenziert über Relationships die XML Signature Parts, die die XML Signature Markups enthalten. Diese Markups enthalten die entsprechende XMLDSIG-Signatur und referenzieren über URIs die signierten Parts. Des Weiteren muss das Zertifikat mit dem die Signatur erzeugt wurde mitangegeben werden. Dies kann einerseits über eine Relationship erfolgen, oder das Zertifikat wird direkt im Signature Markup mitgegeben. Siehe hierzu auch Abbildung 4-1. Digital Signature Origin Part Digital Signature XML Signature Part Digital Signature XML Signature Part X.509 Zertifikat X.509 Zertifikat Signed Part Signed Part Signed Part Signed Part Signed Part Signed Part Relationship URI Abbildung 4-1: Digitale Signatur 12

13 Abbildung 4-2 zeigt wiederum den Zusammenhang zwischen logischem und physikalischem Layer bei einem signierten Dokument (siehe auch 5.2.2). Um den Überblick zu bewahren werden nur jene Parts betrachtet, die für die Signatur notwendig sind. Der Digital Signature Origin Part dient als Startpunkt für die Signatur und befindet sich in der Datei origin.psdsor. Er wird via _rels/.rels referenziert. Der Origin Part verweist nun via Relationship auf den XML Signature Part, der die eigentliche Signatur enthält. Dieser referenziert zum einen via URIs sämtliche signierte Parts und zum anderen referenziert er über ein Relationship das verwendete Zertifikat. Logischer Layer Physikalischer Layer Digital Signature Origin Part Datei: origin.psdsor Ort: /package/services/digital-signature Referenziert von: _rels/.rels Digital Signature XML Signature Part Datei: f3cdaf441b674981a6e934f3f77bb602.psdsxs Ort: /package/services/digital-signature/xml-signature Referenziert von: /package/services/digital-signature/_rels/origin.psdsor.rels Digitale Signatur Zertifikat Part Datei: 0083FB8CB0D102.cer Ort: /package/services/digital-signature/certificate Referenziert von: /package/services/digital-signature/\xml-signature/_rels/ f3cdaf441b674981a6e934f3f77bb602.psdsxs.rels Signierter Part 1... Signierter Part n Datei: FixedDocumentSequence.fdseq Ort: / Referenziert von: /package/services/digital-signature/xml-signature/ f3cdaf441b674981a6e934f3f77bb602.psdsxs Datei:.rels Ort: /_rels Referenziert von: /package/services/digital-signature/xml-signature/ f3cdaf441b674981a6e934f3f77bb602.psdsxs... Abbildung 4-2: Zusamenhang physikalischer und logischer Layer bei einer digitalen Signatur 4.3 Signatur Verifikation Die Prüfung einer Signatur folgt einem einfachen Schema (siehe Abbildung 4-3). In einem ersten Schritt werden die Signaturregeln überprüft wie sie in der XPS Spezifikation beschrieben sind. Ist dies nicht der Fall, so erhält man eine nicht konforme Signatur. Wurden die Signaturregeln eingehalten so wird in einem nächsten Schritt die Signatur selbst überprüft. Die Prüfung erfolgt dabei gemäß der XPS-Spezifikation 3. Im Falle einer negativen Signaturprüfung erhält man eine gebrochene Signatur. Fällt die Prüfung positiv aus, wird anschließend das Zertifikat überprüft. Wird beispielsweise keine gültige Zertifikatskette gefunden, so wird die Signatur als fragwürdig bezeichnet. Eine gültige Signatur erhält man nur wenn auch die Zertifikatsprüfung positiv ausfällt. 3 Hierbei ist anzumerken, dass eine Prüfung grundsätzlich auch mit MOA-SP möglich ist, es müssen dazu nur die entsprechenden Supplements angegeben werden und MOA-SP muss die passenden Transformationen unterstützen. 13

14 Abbildung 4-3: Signatur Verifikation 14

15 5 Analyse des Formats Im Folgenden wird das XPS-Format hinsichtlich der eindeutigen Darstellung und Rückführbarkeit analysiert Signaturverordnung Erste wichtige Forderung der SigV ist die Eindeutigkeit der Darstellung. Aus der XPS- Spezifikation geht dabei hervor, dass eine Eindeutigkeit der Darstellung gegeben ist. Des Weiteren erlaubt XPS keine dynamischen Elemente, womit eine weitere Forderung der SigV erfüllt ist. Abschließend ist anzumerken, dass XPS-Signaturen XMLDSIG konform sind. Mittels XPS können also qualifizierte elektronische Signaturen im Sinne des österreichischen E-Government erzeugt werden Eignung als Amtssignatur Für die Eignung von XPS als Amtssignatur, wurde die Spezifikation hinsichtlich der Rückführbarkeit untersucht. Hierbei wurde festgestellt, dass eine Rückführbarkeit grundsätzlich gegeben ist. Es müssen jedoch bestimmte Vorkehrung getroffen werden um eine Rückführbarkeit vom Ausdruck zu erhalten. So wird es nötig sein ein bestimmtes XPS- Dokument vorzudefinieren, in dem anschließend nur noch der Text eingefügt werden muss. Für die Rückführung müssen dann diese Texte in ein entsprechendes Service eingegeben werden. 5.2 Beispiele Im Folgenden werden einige Beispiel angeführt, die das Verhalten des XPS-Viewers 4 darstellen. Sämtliche Beispiele sind dabei in der beiliegenden Datei examples.zip zu finden Beispiel 1 Dieses Beispiel enthält ein XPS-Dokument mit einer Seite, die Text und ein Bild beinhaltet. Der XPS-Viewer zeigt es wie erwartet (eben mit Text und Bild) richtig an. Dieses Dokument dient lediglich als Ausgangspunkt für sämtliche weiteren Beispiele Beispiel 2 (Signatur) Wie Beispiel 1 nur wurde das gesamte Dokument signiert. Der Viewer zeigt es wie erwartet inklusive der Signatur an. Automatisch startet auch eine Signaturprüfung, die die Signatur als gültig erkennt. Die Gültigkeitsprüfung bezieht sich beim untersuchten XPS-Viewer jedoch auf den Prüfzeitpunkt, nicht den Signaturzeitpunkt Beispiel 3 (Signatur) Wie Beispiel 2, nur wurde eine weitere Textzeile (nach der Signatur) hinzugefügt. Da dies eine Veränderung des Dokumentes ist, meldet der XPS-Viewer erwartungsgemäß, dass der Inhalt des signierten Dokumentes verändert wurde und die Signatur daher ungültig ist Beispiel 4 (Signatur) Wie Beispiel 2 nur wurde eine weitere FixedPage (nach der Signatur) eingefügt. Man erwartet in einem solchen Fall, dass die Signatur natürlich ungültig wird. Der XPS-Viewer zeigt hier aber ein unerwartetes Verhalten. Der Viewer zeigt zunächst ein Dokument ohne Signatur an. Es können jedoch trotzdem Signaturdetails angesehen werden. Wie in 4 Untersucht wurde Microsoft XPS-Viewer unter Vista. 15

16 Abbildung 5-1 ersichtlich enthalten die Details jedoch keine weiteren Daten, insbesondere nicht den Hinweis darauf, dass die Signatur ungültig ist. Abbildung 5-1: XPS-Viewer Beispiel 5 (Fontsubstituition) Dieses Beispiel enthält ein XPS-Dokument bei dem ein Font durch einen anderen substituiert wurde. Hierbei wurde der Arial-Text aus Beispiel 2 durch einen anderen Font ersetzt. Da bei XPS-Dateien die Fonts aber direkt eingebunden sind, wird bei der Signaturprüfung erkannt, dass es sich um eine andere Schriftart handelt. Aus diesem Grunde zeigt auch der XPS- Viewer die Signatur dieses Dokumentes als ungültig an. Ähnliche Beispiele lassen sich beispielsweise auch für Grafiken oder Bilder konstruieren. Da XPS aber keine externen Referenzen erlaubt, ist damit einen Manipulation durch Substituition nicht möglich. 16

17 6 Schlussbemerkung In dieser Studie wurde eruiert, dass XPS keinerlei Schwierigkeiten mit den im Kapitel 2 angeführten Problemen bei dynamischen und verdeckten Elementen hat. Sowohl externe Elemente als auch Transparenz bereiten für XPS keinerlei Probleme. Dadurch, dass in XPS keine dynamischen Elemente vorkommen können, gibt es hierbei auch keinerlei Probleme. Die Studie hat weiters ergeben, dass mit XPS qualifizierte elektronische Signaturen erstellt werden können. Auch eine Rückführbarkeit in die elektronische Form ist grundsätzlich gegeben. Für den Einsatz von XPS im österreichischen E-Government ist daher grundsätzlich zu sagen, dass XPS geeignet ist. Beim aktuellen On-Board Tool XPS-Viewer ergaben sich bei der Signaturprüfung noch unerwartete Ergebnisse, etwa dass sich die Gültigkeitsprüfung auf den Prüfzeitpunkt bezieht, nicht auf den Signaturzeitpunkt. 17

18 Referenzen [E-GovG] [ECMA376] Bundesgesetz über Regelungen zur Erleichterung des elektronischen Verkehrs mit öffentlichen Stellen. BGBl. I Nr. 10/2004 zuletzt geändert durch BGBl. I Nr. 7/2008 Standard ECMA-376, Office Open XML File Formats, Dezember 2006, [PDFA] Edgar Neuherz, Studie zu sicheren Signaturen mit PDF/A, 30. Juli 2007 [SigG] [SigV] [XMLDSIG] [XPSSpec] Bundesgesetz über elektronische Signaturen (Signaturgesetz - SigG), BGBl. I Nr. 190/1999 zuletzt geändert durch BGBl. I Nr. 8/2008 Verordnung des Bundeskanzlers über elektronische Signaturen (Signaturverordnung 2008 SigV 2008). StF: BGBl. II Nr. 3/2008 W3C Recommendation, XML Signature Syntax and Processing (Second Edition), 10 Juni 2008, XML Paper Specification, 24. October 2006, 18