Roadmap Fortgeschrittene Signaturen

Transkript

1 Roadmap Roadmap Fortgeschrittene Signaturen Version 1.0.1, Klaus Stranacher Arne Tauber Zusammenfassung: Das vorliegende Dokument stellt eine Roadmap zur Umsetzung der im Kommissionbeschluss 2011/130/EU definierten Referenzformate für (fortgeschrittene) Signaturen im österreichischen E- Government dar. Diese Roadmap umfasst sowohl einen Planung hinsichtlich einer zeitlichen Umsetzung als auch einen Überblick über die betroffenen Komponenten und die diesbezüglich notwendigen Migrationsschritte. 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 Überblick Roadmap Einleitung Roadmap Betroffene Komponenten Security-Layer Spezifikation BKU Hersteller MOCCA MOA-SS PDF-AS (PAdES) PAdES Signaturprüfung Anwendungsintegration... 9 Abbildungsverzeichnis Abbildung 2.1 Roadmap... 5 Abbildung 3.1 Abhängigkeiten Einleitung 2

3 1 Einleitung Am 25. Februar 2011 wurden Mindestanforderungen für die grenzüberschreitende Verarbeitung von Dokumenten im Kontext der EU Dienstleistungsrichtlinie [EURO06] seitens der Europäischen Kommission beschlossen. Diese Mindestanforderungen sind im Kommissionsbeschluss 2011/130/EU [EURO11] festgelegt und definieren Referenzformate für (fortgeschrittene) elektronische Signaturen um eine grenzüberschreitende Verarbeitung von elektronischen Signaturen wesentlich zu vereinfachen. Um die Interoperabilität im europäischen Umfeld zu erhöhen ist es sinnvoll nicht nur Validierungsservices für das proprietäre österreichische PDF-AS-Format bzw. XML- Signaturformate von Bürgerkartenumgebungen und dem Serversignaturmodul MOA-SS bereitzustellen, sondern vielmehr die Spezifikationen von österreichischen Signaturerstellungsgeräten bzw. Signaturerstellungssoftware konform mit den Anforderungen für fortgeschrittene Signaturen aus dem Kommissionsbeschluss zu gestalten. Sinnvollerweise sollen daher diese Referenzformate und deren wichtigste Neuerungen auch in der österreichischen Signaturlandschaft Einzug halten. Ziel dieses Dokuments ist es daher die betroffenen Komponenten des österreichischen e- Governments zu identifizieren und eine Roadmap für die Migration der bestehenden Signaturformate zu fortgeschrittenen Signaturen sowohl in Spezifikationen als auch in der entsprechenden Signatursoftware zu definieren. Der Rest dieses Dokuments ist wie folgt aufgebaut: Abschnitt 2 gibt einen Überblick über die einzelnen Tasks der Roadmap, insbesondere hinsichtlich der zeitlichen Umsetzung. Abschnitt 3 befasst sich mit den jeweils betroffenen Komponenten. Für jede Komponente beinhaltet er den aktuellen Status bzgl. fortgeschrittener Signaturen, zeigt Abhängigkeiten zu anderen Komponenten und definiert ein entsprechendes Migrationsszenario. Des Weiteren werden betroffene Applikationen gelistet, sowie TODOs definiert und allfällige weitere Punkte aufgeführt, die es zu beachten gilt. Einleitung 3

4 2 Überblick Roadmap 2.1 Einleitung Der Kommissionsbeschluss 2011/130/EU definiert folgende Signaturformate: 1. Fortgeschrittene XML Signaturen: XAdES-BES/EPES in der Version Fortgeschrittene CMS Signaturen: CAdES-BES/EPES in der Version Fortgeschrittene PDF Signaturen: PAdES-BES/EPES in der Version Derzeit werden in der österreichischen Signaturlandschaft in Bezug auf Security-Layer, MOA Module und PDF-AS keine der genannten Signaturformate angewendet. Die bestehenden Signaturformate sollen mittelfristig durch die Formate des Kommissionsbeschlusses ersetzt werden. Dies erfordert einige Spezifikationsupdates sowie Aktualisierungen von Signatursoftware, die in dieser Roadmap beleuchtet werden sollen. Neben neuen Signaturformaten soll auch die Verwendung von stärkeren Hash- Algorithmen forciert werden. Der Trend geht aus Sicherheitsgründen weg vom derzeit bekanntesten SHA-1 Hash-Algorithmus in Richtung der SHA-2 Familie (SHA-184, SHA-256 bzw. SHA-512). Bürgerkartenumgebungen und MOA-SP unterstützen diese Algorithmen bereits. Nun soll MOA-SS folgen. Stapelsignaturen sind derzeit nur in MOA-SS implementiert. Eine Erstellung von Stapelsignaturen mit Bürgerkartenumgebungen ist aufgrund der fehlenden Funktionalität in der Security-Layer-Schnittstelle nicht möglich. Diese Lücke soll nunmehr ebenfalls behoben werden. Überblick Roadmap 4

5 2.2 Roadmap Abbildung 2.1 Roadmap Abbildung 2.1 veranschaulicht die Roadmap für fortgeschrittene Signaturen zeitlich aufgeschlüsselt nach einzelnen Tasks. Dies sind wie folgt: 1.1 Aktualisierung Security-Layer-Spezifikation 1.2 AG-II Abstimmung SL-Spezifikation 2.1 Abstimmung SL-Spezifikation mit BKU-Hersteller 2.2 BKU Integration fortg. Signaturen und Stapelsignaturen 3.1 CAdES-Integration MOCCA 3.2 Integration Stapelsignaturen in MOCCA 4.1 Integration fortg. Signaturen und starke Hash-Algorithmen in MOA-SS 5.1 Umsetzung PAdES-Bibliothek 5.2 Umsetzung PDF-AS Update Signaturprüftool für PAdES-Signaturen 6.2 Update Signaturprüftool der RTR 7.1 Testen BKUs, MOA-SS bzw. PDF-AS 4.0 in Pilotapplikationen 7.2 Schrittweiser Rollout in produktiv-anwendungen Überblick Roadmap 5

6 3 Betroffene Komponenten Dieser Abschnitt beschreibt die von der Roadmap betroffenen Komponenten näher und zeigt deren Abhängigkeiten auf (siehe auch Abbildung 3.1 am Ende des Abschnitts). 3.1 Security-Layer-Spezifikation Die Aktualisierung der Security-Layer-Spezifikation ist erforderlich, damit sowohl XML- als auch CMS-Signaturen, welche mittels Bürgerkarte erstellt werden, standardmäßig den Referenzformaten für fortgeschrittene Signaturen entsprechen. Die Aktualisierung ist dabei in folgende Tasks unterteilt: Task 1.1 Aktualisierung Security-Layer-Spezifikation Task 1.2 AG-II Abstimmung SL-Spezifikation Innerhalb von Task 1.1 wird eine Aktualisierung der Security-Layer-Spezifikation durchgeführt, da die derzeitig spezifizierten XML- und CMS Signaturen nicht den Formaten für fortgeschrittene Signaturen gemäß der EU-Richtlinie 2011/130/EU entsprechen. Es wird daher eine Aktualisierung zumindest auf die Formate XAdES Version 1.4 und CAdES 1.8 durchgeführt. Nach Möglichkeit wird sich die Spezifikation an neuere Versionen dieser Standards halten, sofern eine entsprechende Abwärtskompatibilität gegeben ist. Des Weiteren soll eine Möglichkeit zur Erzeugung von Stapelsignaturen spezifiziert werden. Hierzu wurde bereits 2006 von EGIZ ein Projekt 1 durchgeführt, in welchem die Security-Layer-Spezifikation entsprechend erweitert wurde. Das Projekt soll nun wieder aufgegriffen und auf Praxistauglichkeit in der tatsächlichen Umsetzung getestet werden. Die Funktion der Stapelsignaturen soll als optional spezifiziert werden. Es ist somit Herstellern von Bürgerkartenumgebungen überlassen, ob sie diese implementieren. Im Zuge der Aktualisierung der Security-Layer- Spezifikation sollen BKU-Hersteller bereits aktiv involviert werden (siehe Abschnitt 3.2). Task 1.2 umfasst schließlich die Abstimmung und Konsolidierung der aktualisierten Security-Layer-Spezifikation im Rahmen der AG-II mit Anwendungsbetreibern. 3.2 BKU-Hersteller Da BKU-Herstellern von Security-Layer-Spezifikationsupdates direkt betroffen sind, sind dahingehend folgende zwei Tasks definiert: 1 Betroffene Komponenten 6

7 Task 2.1 Abstimmung SL-Spezifikation mit BKU-Hersteller Task 2.2 BKU-Integration fortg. Signaturen und Stapelsignaturen Task 2.1 umfasst die bereits angesprochene Miteinbeziehung der BKU-Hersteller während der Spezifikations-Updatephase. Dies ist wichtig, damit die Hersteller, insbesondere für die Handy-Signatur, sich frühzeitig auf die Umsetzung der neuen Spezifikationen vorbereiten können. Task 2.2 umfasst schließlich die Integration der aktualisierten Security-Layer-Spezifikation in am Markt befindliche Bürgerkartenumgebungen. Dies umfasst die Integration der Signaturformate XAdES 1.4 und CAdES 1.8 als auch die optionale Umsetzung von Stapelsignaturen. 3.3 MOCCA Hinsichtlich fortgeschrittener Signaturen ist in MOCCA bereits XAdES 1.4 (optional) vorhanden. XAdES 1.4 wird kurzfristig nicht standardmäßig für MOCCA aktiviert. Wenngleich MOA-SP dieses Signaturformat prüfen kann, bestehen weitere Abhängigkeiten in proprietären Umsetzungen und Nutzungen der Security-Layer- Schnittstelle. Dies betrifft auch andere BKU-Hersteller. Eine Umstellung auf XAdES 1.4 ist daher mit Vorsicht zu genießen und sollte wohlüberlegt und koordiniert erfolgen. Für die weitere Integration fortgeschrittener Signaturen sind folgende zwei Tasks definiert: Task 3.1 CAdES-Integration MOCCA Task 3.2 Integration Stapelsignaturen in MOCCA Task 3.1 umfasst die Integration von CAdES 1.8 entsprechend der Aktualisierung der Security-Layer-Spezifikation. CAdES ist eine Voraussetzung für PAdES und wird somit prioritär und parallel zum Update der Security-Layer-Spezifikation umgesetzt. Die CAdES-Umsetzung soll auf Praxistauglichkeit getestet werden und BKU-Hersteller sollen von Erfahrungswerten bzw. der Implementierung in MOCCA profitieren. Der Task 3.2 Stapelsignaturen hat keine hohe Priorität und wird daher zu einem späteren Zeitpunkt umgesetzt. 3.4 MOA-SS Innerhalb der MOA-Module können von MOA-SP bereits alle geforderten Signaturformate geprüft werden. Nun sollen auch bei der Signaturerstellung mittels MOA-SS die entsprechenden fortgeschrittenen Signaturen erzeugt werden können. Zur Umsetzung wurde folgender Task definiert: Betroffene Komponenten 7

8 Task 4.1 Integration fortg. Signaturen und starke Hash-Algorithmen in MOA-SS Innerhalb von Task 4.1 wird die Möglichkeit geschaffen, XAdES 1.4 und CAdES 1.8 kompatible Signaturen zu erzeugen. Hierzu ist es nötig die XML-Schnittstelle zu erweitern, da MOA-SS bisher keine CMS- bzw. CAdES-Signaturen unterstützt. Lediglich deren Verifikation wird mit MOA-SP unterstützt. Sinnvollerweise wird auch diese Erweiterung der Schnittstelle stark an die Spezifikation des Security-Layers angelehnt sein (wodurch sich eine Abhängigkeit zur Aktualisierung der Spezifikation des Security-Layers ergibt). Analog zu BKUs muss auch die Einführung von XAdES 1.4 in MOA-SS mit Bedacht erfolgen. Hier könnte man eine dual-stack-strategie andenken, d.h. dass zunächst standardmäßig weiterhin XML-Signaturen in der bisherigen Form erzeugt werden, XAdES 1.4 aber optional aktiviert werden kann. Sobald alle Applikationen XAdES 1.4 verarbeiten können, kann in weiteren MOA-SS Releases XAdES 1.4 als default- Signaturformat verwendet werden. Des Weiteren werden auch die unterstützen Hash-Algorithmen bei der Signaturerstellung erweitert. So wird die Möglichkeit geschaffen, Signaturen mit neueren Hash-Algorithmen der SHA-2 Familie zu erzeugen. Auch diese Funktionalität wird zunächst in einer dual-stack Variante angeboten, und SHA-2 erst zu einem späteren Zeitpunkt als default-hash-algorithmus gesetzt. 3.5 PDF-AS (PAdES) Das bisher in Österreich genutzte proprietäre PDF-Signaturformate PDF-AS soll mittelfristig durch fortgeschrittene PDF-Signaturen auf Basis von PAdES abgelöst werden. Für diese Migration wurden folgende Tasks definiert: Task 5.1 Umsetzung PAdES-Bibliothek Task 5.2 Umsetzung PDF-AS 4.0 In Task 5.1 wird eine Nachfolgeversion des derzeitigen PDF-AS Signaturformats spezifiziert und umgesetzt. Dieser Task beinhaltet den reinen PAdES Signaturteil auf Basis von CAdES-Signaturen, die über die Security-Layer-Schnittstelle, MOA-SS oder anderen Signaturgeräten (Software-Keys) erstellt werden können. Die PAdES-Umsetzung kann daher parallel zur CAdES-Integration in den einzelnen Signaturgeräten erfolgen. Task 5.2 umfasst die konkrete Umsetzung einer PDF-AS Nachfolgerversion. Diese Version soll auf der in Task 5.1 entwickelten PAdES-Bibliothek beruhen und die gewohnten Funktionalitäten wie die Positionierung und Darstellung eines Signaturblocks beibehalten. Weiters soll auch die einheitliche Visualisierung an die PAdES Rahmenbedingungen angepasst werden und es soll neben PDF/A auch PDF/UA für barrierefreie Inhalte berücksichtigt werden. Zusätzlich wird auch ein Wrapper Betroffene Komponenten 8

9 umgesetzt, der eine Abwärtskompatibilität zu PDF-AS 3.x sicherstellt und damit einen nahtlosen Übergang zu PDF-AS 4.0 garantiert. 3.6 PAdES Signaturprüfung Mit der Umsetzung von PAdES in PDF-AS 4.0 wird auch eine Aktualisierung des Signaturprüftools notwendig. Dies betrifft in erster Linie Signaturen auf Basis elliptischer Kurven (ECC). Diese werden erst mit dem zukünftigen Standard PDF 2.0 spezifiziert werden. Es ist zum aktuellen Zeitpunkt noch nicht klar, wie PAdES-ECC-Signaturen identifiziert werden. Die Unterstützung für PAdES Signaturprüfung am Signaturprüftool erfolgt in folgenden zwei Tasks: Task 6.1 Update Signaturprüftool für PAdES-Signaturen Task 6.2 Update Signaturprüftool der RTR In Task 6.1 erfolgt das Update des Signaturprüftools um auch PAdES-Signaturen prüfen zu können. Dieses Update basiert auf der Funktionalität der PAdES-Bibliothek und kann somit bereits vor Umsetzung von PDF-AS 4.0 integriert werden. Die Prüfbarkeit von älteren PDF-AS-Signaturformaten bleibt selbstverständlich weiterhin gewahrt. Task 6.2 umfasst anschließend die Integration in das Signaturprüftool der RTR. 3.7 Anwendungsintegration Das Ziel der Anwendungsintegration ist ein erfolgreiches Rollout der aktualisierten Komponenten. Sie ist daher in folgende Tasks unterteilt: Task 7.1 Testen BKUs, MOA-SS bzw. PDF-AS 4.0 in Pilotapplikationen Task 7.2 Schrittweiser Rollout in produktiv-anwendungen In Task 7.1 werden sämtliche aktualisierte Komponenten (BKUs, MOA-SS und PDF-AS 4.0) mit Hilfe von Pilotapplikationen (bspw. Testportale EGIZ/Bund/Länder, etc.) eingehend getestet. Die Pilotphase ist in Abbildung 2.1 nur kurz dargestellt, verläuft aber parallel zum Rollout in produktiv-anwendungen weiter. Währen der Pilotphase werden alle Anwendungsbetreiber dahingehend informiert, dass eine neue Version von XAdES- Signaturen verwendet werden kann bzw. soll und dass CAdES- und PAdES-Signaturen nun zur Verfügung stehen. Alle Anwendungsbetreiber werden ermuntert, diese Signaturformate kurz- bis mittelfristig in ihre Anwendung zu integrieren bzw. die Machbarkeit diser Integration zu testen. Diese Informationskampagne soll durch gezielte Vorträge bzw. Workshops zu den neuen Signaturformaten bzw. Software unterstützt werden. Betroffene Komponenten 9

10 Die PAdES-Migration wird sich hier vermutlich wesentlich einfacher gestalten, da die Signaturprüfung derzeit (fast) ausschließlich über die (zentralen) Signaturprüfservices im Internet durchgeführt werden kann. Die XAdES 1.4-Migration ist hier wesentlich komplizierter, da BKU-Signaturen neben MOA-ID oft direkt über die Security-Layer- Schnittstelle in Anwendungen integriert und darüber verarbeitet bzw. geprüft werden. Hier gilt es noch eine entsprechende Einschätzung der betroffenen Applikationen bzw. der Auswirkungen auf diese zu erheben bevor XAdES 1.4 zum Standardsignaturformat für BKUs erhoben werden kann. Task 7.2 umfasst schließlich das schrittweise Rollout in den produktiv-anwendungen (E- Recht, Amtssignatur-Dienste, etc.). Hier ist vermutlich mit entsprechender Unterstützungsleistung zu rechnen. Abbildung 3.1 Abhängigkeiten Betroffene Komponenten 10

11 Dokumentenhistorie Version Datum Autor(en) Anmerkung Klaus Stranacher Initiale Version Arne Tauber Update Abschnitt Klaus Stranacher Update Abschnitt Arne Tauber Taskdetails, Abhängigkeiten, Auswirkungen Tobias Kellner Überarbeitet Betroffene Komponenten 11

12 Referenzen [EURO06] Richtlinie 2006/123/EG des Europäischen Parlaments und des Rates vom 12. Dezember 2006 über Dienstleistungen im Binnenmarkt. [EURO11] Beschluss der Europäischen Kommission, Mindestanforderungen für die grenzüberschreitende Verarbeitung von Dokumenten, die gemäß der Richtlinie 2006/123/EG des Europäischen Parlaments und des Rates über Dienstleistungen im Binnenmarkt von zuständigen Behörden elektronisch signiert worden sind, Bekannt gegeben unter Aktenzeichen K(2011) 1081, 2011/130/EU, 25. Februar Betroffene Komponenten 12