Ergebnisse der Fernsignatur-Umfrage 2023

Da die erste Version von ETSI TS 119 432 („Protokolle für die entfernte Erstellung digitaler Signaturen“) mittlerweile fast fünf Jahre her ist, haben sich die Experten von ETSI ESI , OASIS DSS-X , Cloud Signature Consortium (CSC) und go .eIDAS  zusammengeschlossen, um eine kurze Umfrage durchzuführen, die darauf abzielte, bestehende Implementierungen von ETSI TS 119 432 zu identifizieren und einen Überblick über bestehende Fernsignaturdienste zu geben.

Beachten Sie, dass diese Dienste eine entscheidende Rolle bei der praktischen Umsetzung des bevorstehenden Artikel 6a (4) (ec) eIDAS2 spielen können, der vorsieht, dass die Europäischen Identitätsbrieftaschen („European Digital Identity Wallets“, EUDIW) die Möglichkeit bieten sollen, qualifizierte elektronische Signaturen für die private Nutzung kostenlos zu erstellen.

Remote Signature Architecture

Diese Umfrage wurde im letzten Quartal 2023 durchgeführt und von den 30 unten aufgeführten Organisationen beantwortet, von denen fast alle Fernsignaturdienste anbieten.

Die wichtigsten Ergebnisse der Umfrage lassen sich wie folgt zusammenfassen:

  • 17 % (5) der Fernsignaturdienste sind konform zu ETSI TS 119 432 v1.2.1 , während 13 % (4) sich für die Implementierung der Variante auf Basis der CSC-API entschieden haben und 3 % (1) auf der OASIS-API basieren.
  • 60 % (18) der Fernsignaturdienste stellen eine API bereit, die der ETSI-API ähnelt , während 47 % (14) auf der CSC-API basieren, 7 % (2) auf der OASIS-API basieren und 7 % (2) eine andere API Beachten Sie, dass mehrere Befragte, die die CSC-Variante unterstützen, angegeben haben, dass sie Version 1.0.4.0 oder sogar 2. 0.0.2 dieser Spezifikation unterstützen, während ETSI 119 432 v1.2.1 auf Version 1.0.3.0 der CSC-API-Spezifikation verweist und somit möglicherweise entsprechend aktualisiert werden sollte.
  • 3 % (1) Fernsignaturdienstanbieter plant, die ETSI-API in naher Zukunft zu unterstützen und
  • 20 % (6) planen überhaupt nicht, eine standardisierte API zu unterstützen.

Ergebnisse der Fernsignatur-Umfrage

Während fast alle Teilnehmer der Umfrage es vorziehen, Preisinformationen vertraulich zu behandeln, wurden dennoch einige Zahlen genannt: Ein Befragter gab einen Preis von 120 € pro Jahr für qualifizierte elektronische Signaturen und 400 € für fortgeschrittene elektronische Siegel an. Ein anderer Befragter erwähnte eine monatliche Gebühr von 200 € für den Zugriff auf die Fernsignaturschnittstelle. Ein weiterer Befragter nannte eine Spanne von 0 bis 0,50 € pro fortgeschrittener elektronischer Signatur und 0 bis 2,50 € pro qualifizierter elektronischer Signatur. Indikative Kosten zur Identifizierung betragen 2,50 € bei eID, 7,50 € bei VideoIdent und 3,50 € bei AutoIdent. Nur ein Befragter stellte eine Preisliste für Fernsignaturdienste bereit, die auf Transaktionsgebühren und einer Mindestanzahl von Transaktionen basiert, wobei diese Preisgestaltung jedoch nur in ausgewählten EU-Mitgliedstaaten gilt.

Wir danken folgenden Organisationen für die Teilnahme an der Umfrage:

eIDAS-Signer gestartet

Das EU-finanzierte Projekt mGov4EU verfolgte einen bürgerzentrierten Ansatz, um sichere und datenschutzfreundliche mobile Verwaltungsdienste in ganz Europa zu ermöglichen. Zu den Projektergebnissen gehört der neuartige eIDAS-Signer Dienst (https://Signer.eID.AS ), der es ermöglicht, elektronische Identifizierungsmittel (eID), wie z.B. den deutschen Personalausweis oder die ID Austria, für die Erstellung fortgeschrittener oder qualifizierter elektronischer Signaturen in einer mobilen Umgebung zu verwenden.

Derzeit gibt es in Europa 32 (prä) notifizierte eID-Systeme. Darüber hinaus gibt es derzeit 260 Qualifizierte Vertrauensdiensteanbieter (Qualified Trust Service Provider, QTSP), von denen 189 qualifizierte Zertifikate für Zwecke der elektronischen Signatur ausstellen. Vor diesem Hintergrund hat das mGov4EU-Projekt führende europäische Experten aus Verwaltung, Wirtschaft und Wissenschaft aus Österreich, Belgien, Estland, Deutschland und Spanien zusammengebracht, um die Service-Infrastruktur der nächsten Generation für Europa zu entwerfen und auf dieser Basis innovative Dienste zu entwickeln.

Hierbei wird insbesondere die Lücke zwischen dem „eID“-Teil und dem „AS“-Teil (Vertrauensdienste) der eIDAS-Verordnung geschlossen, um vertrauenswürdige, mobile und bürgerzentrierte elektronische Geschäfts- und Verwaltungsprozesse in ganz Europa zu ermöglichen.

mGov4EU bridges the gap between eID and AS

Ein wichtiges Ergebnis des mGov4EU-Projekts ist der neuartige und von der offenen eIDAS-Community gestaltete eIDAS-Signer-Dienst, der unter https://Signer.eID.AS verfügbar ist und es ermöglicht, nach geeigneten elektronischen Identifizierungsprozessen mit einem Smartphone fortgeschrittene oder qualifizierte elektronische Signaturen in einem mobilen Umfeld zu erstellen.

Welcome to the eIDAS community - Simply sign with your eID!

Der eIDAS-Signer-Dienst wurde gemeinsam mit einer Vielzahl von Expertinnen und Experten aus der offenen eIDAS-Community konzipiert, die sich rund um den gemeinnützigen go.eIDAS e.V. versammelt. Er wurde von der ecsec GmbH entwickelt und wird von ihr in einem zertifizierten Rechenzentrum betrieben, um eine einfach zu bedienende und KMU-gerechte Alternative zu bereits bestehenden, aber rein kommerziell orientierten Angeboten bereitzustellen, die typischerweise von multinationalen Unternehmen angeboten werden.

Während der eIDAS-Signer-Dienst derzeit nur die ID Austria und den deutschen Personalausweis unterstützt, so ist es wie unten dargestellt ein offensichtliches Ziel die anderen notifizierten eID-Systeme und weitere QTSPs zu unterstützen.

Map with notified eID-Systems

Wenden Sie sich gern an die offene eIDAS-Community, um Unterstützung zu erhalten oder Verbesserungsvorschläge, Anregungen sowie Prioritäten für die Weiterentwicklung vorzuschlagen.

Wir sind sehr dankbar dafür, dass die eIDAS-Signer-Lösung auf Komponenten und Diensten aufbauen kann, die im Rahmen von Forschungsprojekten entwickelt wurden, die von der Europäischen Kommission (FutureTrust und mGov4EU) oder dem Bundesministerium für Wirtschaft und Klimaschutz (SkIDentity und TEAM-X) unterstützt wurden.

Das Triple ist komplett: Der Personalausweis ist ab sofort kostenlos in Nextcloud, WordPress und TYPO3 zur starken Authentisierung nutzbar!

Die starke Authentisierung mittels des Personalausweises für alle TYPO3-Anwendungen komplettiert das im Auftrag des Bundesamtes für Sicherheit in der Informationstechnik (BSI) von der ecsec GmbH realisierte Triple der eID-Logins für Nextcloud, WordPress und TYPO3. Damit sind nun in den letzten Wochen gleich drei eID-Login Services für in Deutschland besonders populäre Webanwendungen entwickelt und unter einer Open Source Lizenz veröffentlicht worden. In Verbindung mit dem für das Projekt gebührenfrei bereitgestellten SkIDentity-Dienst kann der Personalausweis mit Online-Ausweisfunktion nun in diesen Webanwendungen zur starken Authentisierung genutzt werden.

BU: Der Personalausweis ist ab sofort kostenlos in Nextcloud, WordPress und TYPO3 zur starken Authentisierung nutzbar!

Starke Authentisierung mit Personalausweis erreicht breite Öffentlichkeit

Der auf dem höchstmöglichen Sicherheitsniveau („hoch“) gemäß der eIDAS-Verordnung notifizierte Personalausweis mit Online-Ausweisfunktion kann von allen Bürgerinnen und Bürgern zur elektronischen Identifizierung (eID) und zur starken pseudonymen Authentisierung im Netz genutzt werden. Bislang wurde dieser vor allem in spezialisierten Anwendungen im Bereich E-Government eingesetzt. Durch die von der ecsec GmbH im Auftrag des BSI entwickelten eID-Login Services ist es nun leicht möglich, den Personalausweis mit Online-Ausweisfunktion in den populären Webanwendungen Nextcloud, WordPress und TYPO3 zur starken Authentisierung zu nutzen. Dabei wird mit der frühzeitigen und standardmäßigen Berücksichtigung relevanter Sicherheitsaspekte nach dem Prinzip „Security by Design“ und der Veröffentlichung der verschiedenen „eID-Login“ Erweiterungen als Open Source ein Höchstmaß an Vertrauenswürdigkeit erreicht.

„eID-Login“ App für Nextcloud

Nextcloud ist die branchenführende Open-Source Cloud-Lösung für on-premise Datenverarbeitung und -kommunikation. Die Plattform vereint universellen Datenzugriff über mobile und stationäre Web-Schnittstellen mit innovativen, sicheren Kommunikations- und Kollaborationsfunktionen, wie z.B. Dokumentenbearbeitung in Echtzeit, Chat und Videoanrufe – und das alles unter direkter Kontrolle der eigenen IT-Abteilung sowie integrierbar in bestehende Infrastrukturen. Mit seiner einfachen und schnellen Bereitstellung, der modularen Architektur und dem Fokus auf Sicherheit und effiziente Zusammenarbeit, ermöglicht Nextcloud modernen Unternehmen, ihre vorhandenen Datei- und Dokumentenspeicher innerhalb und außerhalb der Grenzen ihres Unternehmens zu optimieren. Durch die von der ecsec GmbH im Auftrag des Bundesamtes für Sicherheit in der Informationstechnik (BSI) entwickelte „eID-Login“ App für Nextcloud ist es nun möglich, den Personalausweis mit Online-Ausweisfunktion in dieser beliebten Cloud-Lösung zur starken Authentisierung zu nutzen. „Es ist großartig, dass Nextcloud die erste Mainstream-Plattform ist, die den Personalausweis mit Online-Ausweisfunktion zur starken Authentifizierung und Identifizierung unterstützt“, ergänzt Frank Karlitschek, Gründer und Geschäftsführer der Nextcloud GmbH. „Wir freuen uns auf viele Nutzer dieser innovativen Authentisierungstechnologie.“

„eID-Login“ Plugin für WordPress

WordPress war ursprünglich eine Software für Weblogs und hat sich inzwischen zu einem vollwertigen, auf PHP und MySQL aufgebauten, Content Management System (CMS) zur Erstellung und Pflege von Webseiten entwickelt. Ein großer Prozentsatz aller deutschen Webseiten ist auf Basis des frei verfügbaren und marktführenden WordPress CMS umgesetzt. Vor diesem Hintergrund hat die ecsec GmbH im Auftrag des Bundesamtes für Sicherheit in der Informationstechnik (BSI) ein „eID-Login“ Plugin für WordPress entwickelt, mit dem der Personalausweis mit Online-Ausweisfunktion ab sofort in WordPress zur starken Authentisierung genutzt werden kann. „Damit kann die elektronische Identität bei rund 40 % aller Webauftritte sofort aktiviert und eingesetzt werden“, erklärt Dr. Detlef Hühnlein, Geschäftsführer der ecsec GmbH.

„eID-Login“ Extension für TYPO3

TYPO3 ist ein kostenloses und flexibel einsetzbares Open Source CMS, das zur professionellen Webseitenerstellung sehr gut geeignet ist. Beispielsweise setzen die Hälfte aller DAX-Konzerne und rund ein Viertel aller deutschen Städte auf TYPO3. Damit der Personalausweis in TYPO3 zur starken Authentisierung von Frontend-Nutzern eingesetzt werden kann, wurde die ecsec GmbH vom BSI beauftragt, eine entsprechende „eID-Login“ Extension für TYPO3 zu entwickeln. „Es ist großartig, dass der Personalausweis mit Online-Ausweisfunktion nun auch in TYPO3 zur starken Authentifizierung genutzt werden kann“, ergänzt Tina Hühnlein, Geschäftsführerin der ecsec GmbH.

Kooperation von BSI und ecsec GmbH ermöglicht kostenlose https://eID.Services

Damit der Personalausweis sofort und kostenlos zur starken Authentisierung in Nextcloud, WordPress und TYPO3 genutzt werden kann, wird im Rahmen des gemeinsamen Projektes außerdem der mehrfach international ausgezeichnete SkIDentity-Dienst zur starken Authentisierung ohne Gebühren bereitgestellt. Neben dem kostenlosen Authentisierungsdienst bieten die eID-Experten der ecsec GmbH außerdem weitere Unterstützungsleistungen für Hosting-Anbieter und Anwendungsentwickler (siehe https://eID.Services) an, so dass die „eID-Login“-Funktionalität zukünftig auch leicht in andere Open Source Anwendungen integriert werden kann.

mGov4EU mobilisiert das europäische eGovernment

Durch die praktische Implementierung der seit Juli 2016 vollständig anwendbaren „eIDAS-Verordnung“ hat die Europäische Union in den letzten Jahren große Fortschritte gemacht, den grenzüberschreitenden Online-Identifizierungsprozess für Bürgerinnen und Bürger erfolgreich zu vereinfachen. Außerdem ist im Dezember 2020 ein erster Teil der „Single Digital Gateway (SDG)“ Verordnung zur Einrichtung eines einheitlichen digitalen Zugangstores zur Verwaltung in der EU in Kraft getreten. Schließlich existiert ein ungebrochener Trend hin zur mobilen und selbstbestimmten Nutzung von Verwaltungsdienstleistungen: Bürgerinnen und Bürger erwarten heute, dass eGovernment-Dienste jederzeit bequem per Smartphone nutzbar sind. Vor diesem Hintergrund ist kürzlich das von der Europäischen Union im Rahmen des Forschungs- und Innovationsprogramms Horizon 2020 geförderte mGov4EU („Mobile Cross-Border Government Services for Europe“, https://mGov4.EU) Projekt gestartet, um mobile grenzüberschreitende Verwaltungsdienste in Europa zu ermöglichen. Das Projekt ist offen für weitere Pilotpartner und lädt herzlich zur Mitwirkung ein.

Das mGov4EU-Projekt versammelt führende europäische Experten aus dem Bereich Verwaltung, Wirtschaft und Wissenschaft aus Österreich, Belgien, Estland, Deutschland und Spanien, um sichere und datenschutzfreundliche mobile eGovernment-Dienste in ganz Europa zu ermöglichen. mGov4EU stellt die Bürgerin und den Bürger in den Mittelpunkt der Betrachtungen und wird ihnen neue, sichere und die Privatsphäre schützende Optionen zur Verwaltung ihrer Identität und ihrer persönlichen Daten bieten – ganz gleich, ob sie oder der eGovernment-Dienst sich im Heimatland oder in einem anderen EU-Mitgliedsstaat befinden.

mGov4EU kombiniert eIDAS mit Single Digital Gateway in benutzerzentrierter Weise

Den regulatorischen Rahmen dieses Projektes bilden die Verordnung (EU) 2018/1724 über die Einrichtung eines einheitlichen digitalen Zugangstors (Single Digital Gateway Regulation – SDGR) zur grenzüberschreitenden Bereitstellung von Diensten, zusammen mit der eIDAS-Verordnung (EU) Nr. 910/2014 für grenzüberschreitende elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt. Das mGov4EU-Projekt stellt die Anforderungen selbstbestimmter und mobiler Bürgerinnen und Bürger in das Zentrum der Betrachtungen und integriert das existierende eIDAS-Ökosystem in das neue einheitlichen Zugangstor zu einem benutzerfreundlichen Gesamtsystem.

mGov4EU im Überblick

Abbildung 1: Das mGov4EU-System auf einen Blick

Im mGov4EU-Projekt sollen die bereits existierenden und neu entstehenden Möglichkeiten der eIDAS- und SDG-Verordnung genutzt und die Prinzipien „once-only“, „digital-by-default“ und „mobile-first“ praktisch umgesetzt werden. Nach einer benutzerfreundlichen mobilen Identifizierung und einer expliziten Freigabe durch den Nutzer kann auf bereits verfügbare Daten zugegriffen werden, damit soweit wie möglich auf das bisweilen umständliche Ausfüllen komplexer Formulare verzichtet werden kann. Durch die konsequente Nutzung der in modernen Smartphones verfügbaren Technologien werden die in mGov4EU anvisierten Lösungen nicht nur den höchsten Sicherheits- und Datenschutzanforderungen genüge tun, sondern auch eine ausgezeichnete Benutzerfreundlichkeit bieten. Hierbei zielt das mGov4EU-Projekt darauf ab, grundlegende Bausteine für sichere und mobil nutzbare eGovernment-Dienste bereitzustellen, die in ganz Europa und darüber hinaus genutzt werden können. Diese Bausteine sollen in ausgewählten Pilotanwendungen im Bereich elektronischer Wahlen, der „smarten Mobilität“ und nicht zuletzt der mobilen Signatur erprobt und danach einer breiteren Nutzergruppe zur Verfügung gestellt werden. Ausgehend von den mGov4EU-Entwicklungen kann auf diese Weise eine vertrauenswürdige Föderation von kollaborativen eGovernment-Plattformen entstehen, die die gemeinsame Bereitstellung und Wiederverwendung von verfügbaren und einfach zu nutzenden öffentlichen Diensten erleichtert.

Das mGov4EU-Projekt wird von einem interdisziplinären Expertenteam durchgeführt

Das Projekt mGov4EU wird vollständig durch das EU-Forschungs- und Innovationsprogramm Horizon 2020 mit einem Budget von 3,9 Millionen Euro gefördert. Für das mGov4EU-Projekt haben sich hochkarätige, international erfahrene, interdisziplinäre Experten aus Verwaltung, Wirtschaft und Wissenschaft zusammengefunden. Neben der TECHNIKON Forschungs- und Planungsgesellschaft mbH als Koordinator arbeiten das Zentrum für sichere Informationstechnologie – Austria (A-SIT zusammen mit der A-SIT Plus GmbH), die Donau-Universität Krems, die ecsec GmbH, die Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V., der go.eIDAS e.V., die Technische Universität Graz, Scytl, TIMELEX und die Universität Tartu an diesem Projekt.

Während der dreijährigen Projektlaufzeit werden mehrere mGov4EU-Pilotanwendungen entworfen und implementiert, um die bereitgestellten Lösungsbausteine und Infrastrukturdienste zu validieren. Unter den Pilotanwendungen finden sich z.B. elektronische Wahlen, „smarte Mobilität“ auf Basis von subventionierten Taxifahrten und die mobile Signatur. Interessierte Behörden in ganz Europa sind herzlich eingeladen, sich mit dem mGov4EU-Projekt in Verbindung zu setzen, um an diesen Pilotanwendungen teilzunehmen oder die innovativen Technologien frühzeitig selbst in eigenen Anwendungen zu nutzen.

Deploy with GAIA-X – Auf dem Weg zur digitalen Souveränität per Knopfdruck

Digitale Souveränität beschreibt die Fähigkeit, die digitale Transformation in Bezug auf Hardware, Software, Diensten und Kompetenzen selbstbestimmt zu gestalten. Gemeinsame Standards, modulare Architekturen und der Einsatz von Open Source im öffentlichen Sektor gelten als zentrale Säulen für die digitale Souveränität und Interoperabilität, und GAIA-X wird voraussichtlich einen wichtigen Beitrag zur praktischen Umsetzung der digitalen Souveränität in Europa leisten.

Vor diesem Hintergrund haben sich führende Europäische Cloud-Experten von Cloud & Heat, Charité / deNBI, D3TN, ecsec, IONOS, publicplan, Red Hat / IBM, Scheer und Trusted Cloud zusammengeschlossen, um die Machbarkeit des Deployments von zusammengesetzten Open Source Anwendungen, wie zum Beispiel Nextcloud mit der kürzlich vorgestellten eID-Login App, über die Orchestrator-Engine Krake in geeignete Cloud-Umgebungen, wie durch entsprechende Benutzeranforderungen und den Selbstbeschreibungen der Anbieter bestimmt, zu demonstrieren. Die Anwendung von eIDAS-konformen Identitätsmanagement-Diensten, wie diese durch SkIDentity bereitgestellt werden, gewährleistet zudem das geforderte hohe Sicherheitsniveau, die Einhaltung der einschlägigen rechtlichen Rahmenbedingungen und die einfache Anwendung in ganz Europa.

Der vorgestellte Prototyp „Deploy with GAIA-X“ bildet den Ausgangspunkt für die Implementierung des geplanten deutschen öffentlichen Code-Verzeichnisses „Ort für öffentlichen Code”, das die digitale Souveränität auf allen Ebenen des deutschen öffentlichen Sektors fördern soll – von der kommunalen Ebene über die Bundesländer bis hin zur Bundesebene.

Neue APIs für das eIDAS-Ökosystem

Detlef Hühnlein, Ulrike Korte, Andreas Kühne, Andrea Röck


OASIS und ETSI schaffen Programmierschnittstellen für die Erstellung, Validierung und langfristige Bewahrung von Signaturen, Siegeln, Zeitstempeln und Beweisdaten und bilden somit die Grundlage für die Entwicklung einer umfassenden „eIDAS-API“.

Mit der seit Juli 2016 vollständig anwendbaren „eIDAS-Verordnung“ haben sich zahlreiche neue Möglichkeiten zur vertrauenswürdigen Digitalisierung von Geschäftsprozessen in Wirtschaft und Verwaltung eröffnet. Damit diese Chancen auch praktisch genutzt werden können, haben die Standardisierungskomitees OASIS DSS-X und ETSI ESI kürzlich entsprechende Standards für die Erstellung, Validierung und langfristige Bewahrung von Signaturen, Siegeln, Zeitstempeln und Beweisdaten entwickelt. Der vorliegende Beitrag liefert einen kompakten Überblick über die neu geschaffenen Programmierschnittstellen (Application Programming Interface, API) und liefert einen Ausblick auf zukünftige Entwicklungen.

Einleitung

Die „Verordnung (EU) Nr. 910/2014 des Europäischen Parlaments und des Rates vom 23. Juli 2014 über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt und zur Aufhebung der Richtlinie 1999/93/EG“, die gemeinhin als „eIDAS-Verordnung” bekannt ist, verspricht das Vertrauen und die Effizienz von elektronischen Transaktionen in Europa zu steigern. Mit ihr wurde das bisherige Europäische Rahmenwerk für elektronische Signaturen und Zeitstempel um zahlreiche neue Vertrauensdienste und Aspekte der elektronischen Identifizierung erweitert. Neben der im Erwägungsgrund (52) erwähnten Fernsignatur, wurden in den Artikeln 33, 34 und 40 insbesondere auch Dienste zur Validierung und langfristigen Bewahrung von Signaturen und Siegeln eingeführt. Um die praktische Nutzung dieser neuen Vertrauensdienste in einer interoperablen Weise zu ermöglichen und somit ein solides Fundament für ein prosperierendes und langfristig tragfähiges „eIDAS-Ökosystem“ zu schaffen, haben die für elektronische Signaturtechnologien zuständigen Standardisierungskomitees bei OASIS (Digital Signature Services eXtended, DSS-X) und ETSI (Electronic Signatures and Infrastructures, ESI) nun entsprechende Standards für Programmierschnittstellen (Application Programming Interface, API) zur Erstellung, Validierung und langfristige Bewahrung von Signaturen, Siegeln, Zeitstempeln und Beweisdaten vorgelegt. Der vorliegende Artikel vermittelt einen groben Überblick über die neu geschaffenen Programmierschnittstellen und und geht darüber hinaus kurz auf mögliche zukünftige Entwicklungen ein.

Die neuen API-Standards

Überblick

Wie in Abbildung 1 angedeutet, stellen die neuen API-Standards Programmierschnittstellen für die wichtigen Dienste im eIDAS-Ökosystem bereit. Hierbei können über den Signatur- und Siegelerstellungsdienst (SigS) entsprechende Signaturen und Siegel erstellt, über den Validierungsdienst (ValS) geprüft und schließlich mit dem Bewahrungsdienst (PresS) langfristig beweiskräftig aufbewahrt werden. Dazu nutzen die Anwendungssysteme die bei ETSI ESI und OASIS DSS-X entwickelten Webservice-basierten Programmierschnittstellen. Während die Schnittstellen für die Erstellung (ETSI TS 119 432) und Validierung von elektronischen Signaturen und Siegeln (ETSI TS 119 442) auf der neuen Version 2.0 des OASIS DSS-X Core aufsetzen und diesen profilieren bzw. für JSON und die Erstellung auch auf den Vorarbeiten des von Adobe geführten „Cloud Signature Consortium“, werden für die Schnittstelle zum Bewahrungsdienst (ETSI TS 119 512) nur die grundlegenden Schemadateien von OASIS („Base“) importiert und es wird eine entsprechende Erweiterung vorgenommen. Neben den im Folgenden näher betrachteten technischen Schnittstellenspezifikationen wurden mit ETSI TS 119 431 (Teil 1 und Teil 2), ETSI TS 119 441 und ETSI TS 119 511 entsprechende Sicherheitsanforderungen spezifiziert, die die Grundlage für die Konformitätsprüfung von (qualifizierten) Vertrauensdiensten gemäß der eIDAS-Verordnung bilden.

 

Ein Bild, das Screenshot enthält.

Automatisch generierte Beschreibung

Abbildung 1: Die neuen Signatur-APIs im Überblick

 

OASIS DSS-X Core 2.0

Im Rahmen eines auf Signaturdienste spezialisierten „Technical Committee“ (TC) wurde bei der internationalen Standardisierungsorganisation OASIS bereits im Jahre 2007 eine Kernspezifikation („Core“) standardisiert, die die Basisfunktionalität für die Erstellung (SignRequest / -Response) und Validierung (VerifyRequest / -Response) von CMS- und XMLDSig-konformen Signaturen festlegt. Aufgrund der großen Bandbreite von Anforderungen aus den verschiedenen Einsatzbereichen von Signaturen und Zeitstempeln wurde die Kernspezifikation um eine Reihe von sog. Profilen („Profile“) erweitert, z.B. für den Einsatz für Code Signing, Entity Seals oder für die Verarbeitung von XAdES- und CAdES-konformen Artefakten. In den Folgejahren wurden weitere Profile entwickelt, z.B. für detaillierte Signaturprüfberichte und zur Signaturerstellung mit nicht in der Serverinstanz lokalisierten Signaturerstellungseinheiten.

Aufbauend auf diesen Vorarbeiten wurden im OASIS Digital Signature Services eXtended (DSS-X) TC mit der Version 2.0 des Core die Herausforderungen einer neuen API-Landschaft adressiert und die Semantik der Schnittstelle von der konkreten Umsetzung in eine bestimmte Syntax separiert. Neben der von Version 1 geerbten XML-Syntax wird nun auch das in modernen Webanwendungen oftmals eingesetzte JSON unterstützt und weitere Syntaxen könnten bei Bedarf zusätzlich definiert werden. Denkbar wäre hier beispielsweise eine ASN.1-Syntax, um mit den „Packed Encoding Rules“ (PER) ein besonders kompaktes Format für mobile und eingebettete Anwendungen im „Internet der Dinge“ zu ermöglichen. Um eine möglichst große Sichtbarkeit und gute Akzeptanz des Standards sicherzustellen, hat das DSS-X TC in Zusammenarbeit mit dem OASIS-Infrastruktur-Team begonnen, die Schnittstelle auf der Kollaborationsplattform „SwaggerHub“ bereitzustellen. Dazu wird das JSON-Schema um eine Reihe von Meta-Informationen erweitert, um der OpenAPI-Spezifikation zu entsprechen.

Durch die jüngst bei ETSI und aktuell bei OASIS entstehenden Profile können die spezifischen Eigenschaften der AdES-Signaturformate in Verbindung mit lokalen und entfernten eIDAS-konformen Signaturerstellungseinheiten über die DSS-X-Schnittstelle genutzt werden. Durch die zusätzlichen Attribute der Signaturen (z.B. die eingebetteten Zertifikatstatusinformationen, Zeitstempel oder Evidence Records) wird eine breite Anwendbarkeit dieser Formatfamilie ermöglicht. Seit der initialen Standardisierung werden die zugehörigen Schnittstellenerweiterungen für die Formate XAdES und CAdES durch das AdES-Profil definiert. Im Rahmen der Version 2.0 wird aktuell das AdES-Profil dahingehend erweitert, dass die zwischenzeitlichen Weiterentwicklungen der AdES-Formate berücksichtigt werden. Insbesondere wird auch das auf der PDF-Spezifikation basierende PAdES-Format gemäß ETSI EN 319 142-1 unterstützt, mit dem mehrfache Signaturen in einem Workflow und die visuelle Repräsentation einer elektronischen Signatur in einem PDF-Dokument realisiert werden können.

Für den Einsatz im eIDAS-Umfeld erweist sich die Unterstützung von sog. „Policies“ durch die DSS-X-Spezifikation als wertvoll. Damit kann der Aufrufer eine für die gewünschte Aktion erforderliche „Policy“ an den Dienst übermitteln. Die angesprochene Serverinstanz entscheidet, ob sie dem geforderten Qualitätsniveau gerecht werden kann oder ob die Anfrage abgewiesen werden muss. Wird die Anforderung bearbeitet, so kann in der Antwortstruktur die angewandte „Policy“ an den Aufrufer übertragen werden. So wird sichergestellt, dass ein Konsens über das mindestens anzuwendende Qualitätsniveau erreicht wurde.

ETSI TS 119 432

ETSI TS 119 432 basiert auf Version 2.0 des OASIS DSS-X Core bzw. für JSON auch auf den Vorarbeiten des von Adobe geführten „Cloud Signature Consortium“ und spezifiziert Schnittstellen für die mit der eIDAS-Verordnung ermöglichten Fernsignatur. Hierbei wird im Einklang mit dem bei CEN erarbeiteten Standard CEN EN 419 241 (Teil 1 und Teil 2) zwischen der „Serversignaturanwendung“ („Server Signing Application“, SSA) und der „Signaturerstellungsanwendung“ („Signature Creation Application“, SCA) unterschieden, die jeweils entsprechende Webservice-Schnittstellen anbieten. Während die SSA ein HSM-basiertes „Unterschriftsaktivierungsmodul“ („Signature Activation Module“, SAM) enthält, das nach einer starken Authentisierung des Unterzeichners im „Signaturaktivierungsprotokoll“ („Signature Activation Protocol“, SAP) unter Verwendung der „Unterzeichner-Interaktionskomponente“ („Signer Interaction Component“) die Erstellung der rohen digitalen Signatur in einem „Low-Level-Format“ (z.B. RSA gemäß PKCS#1 oder ECDSA) auslöst, sorgt die SCA für die Bildung des erweiterten AdES-Signaturformats gemäß ETSI EN 319 122 (CAdES), ETSI EN 319 132 (XAdES) oder ETSI EN 319 142 (PAdES).

 

Abbildung 2: Fernsignatursystem gemäß ETSI TS 119 432

 

ETSI TS 119 442

ETSI TS 119 442 definiert drei verschiedene Programmierschnittstellen, jeweils eine für Dienste, die Signaturvalidierung („Validation“ per VerifyRequest / VerifyResponse), Signaturerweiterung („Augmentation“ per AugmentRequest / AugmentResponse), oder beides kombiniert anbieten. Die erste Version dieses Dokuments behandelt die Validierung und Erweiterung von AdES-Signaturen, welche den aktuellen ETSI-Standards, wie z. B. ETSI EN 319 122 (CAdES), ETSI EN 319 132 (XAdES) und ETSI EN 319 142 (PAdES) bzw. den vorausgegangenen AdES-Spezifikationen entsprechen. Bezüglich der AdES-Spezifikationen sind hier insbesondere die im Durchführungsbeschluss (EU) 2015/1506 erwähnten „Baseline Profiles“ ETSI TS 103 171, ETSI TS 103 172 und ETSI TS 103 173 bzw. die diesen Dokumenten zu Grunde liegenden AdES-Spezifikationen ETSI TS 101 733, ETSI TS 102 778 und ETSI TS 101 903 relevant.

Zukünftige Versionen dieses Dokuments könnten zum Beispiel auch die Validierung von Zeitstempeln, Evidence Records oder von Signaturen in ASiC-Containern behandeln.

ETSI TS 119 442 basiert so weit wie möglich auf Version 2.0 des OASIS DSS-X Core. Zum Zeitpunkt der Finalisierung von ETSI TS 119 442 war die endgültige Version des neuen OASIS DSS-X Core noch nicht veröffentlicht, so dass bei der Entwicklung des ETSI TS 119 442 letztlich auf eine Entwurfsversion des OASIS-Dokumentes aufgebaut werden musste. In Fällen, in denen der Funktionsumfang des OASIS-Drafts nicht ausreichend schien, um die gewünschte Funktionalität der Programmierschnittstelle zu bieten, wurden neue Elemente definiert.

Ähnlich wie in Version 2.0 des OASIS DSS-X Core wird jedes Element der Programmierschnittstelle zuerst allgemein beschrieben, bevor entsprechende Syntaxen für XML und JSON beschrieben werden.

Die definierte Validierungsschnittstelle erlaubt es, zusätzlich zur Signatur, statt dem signierten Dokument nur den Hash des entsprechen Dokumentes zu senden. Diese Funktionalität kann sehr nützlich sein, falls das signierte Dokument entweder sehr groß ist oder falls es aus Datenschutz- oder Geheimhaltungsgründen vermieden werden soll, dass es vollständig zum Validierungsdienst gesendet wird. Da im Fall einer Signaturerweiterung möglicherweise ein neuer Hash des signierten Dokuments berechnet werden muss, ist diese Option bei der Signaturerweiterung nicht vorgesehen.

Falls mehr als eine Signatur in einem Dokument enthalten ist, erlaubt es die Programmierschnittstellen nur einen Teil dieser Signaturen für die Validierung und/oder Erweiterung auszuwählen. Außerdem kann bei einem Aufruf spezifiziert werden, wie viele Details in der Antwort zurückgeliefert werden sollen. Dies kann von einer sehr einfachen Antwort bis zu einem umfassenden und signierten Signaturprüfbericht gemäß ETSI TS 119 102-2 reichen, wie er zur Erfüllung der Anforderungen aus Artikel 33 Absatz 1 (b) der eIDAS-Verordnung benötigt wird.

ETSI TS 119 512

Als Grundlage für die Entwicklung der technischen Spezifikationen im Bereich der Bewahrungsdienste wurde in ETSI ESI zunächst in einer Vorstudie ein Spezialbericht (“Special Report”) ETSI SR 019 510 erarbeitet. Auf dieser Basis erfolgte sodann die Entwicklung des eigentlichen Protokollstandards ETSI TS 119 512  und der zugehörigen Sicherheitsanforderungen („Policy and Security Requirements “) ETSI TS 119 511.

Wie in Abbildung 3 dargestellt, stellt ein Bewahrungsdienst gemäß ETSI TS 119 512 eine „Preservation-API“ bereit, die z.B. dazu genutzt wird, die zur langfristigen Aufbewahrung vorgesehenen Datenobjekte („Preservation Objects“) an einen Bewahrungsdienst zu senden. Ein Bewahrungsdienst kann wiederum externe Zeitstempeldienste („Time-Stamping Authority“) gemäß ETSI EN 319 422, Signatur- und Siegel-Erstellungsdienste (SigS) oder Validierungsdienste (ValS) nutzen, um Sperrinformationen abzurufen und um digitale Signaturen prüfen zu lassen. Alternativ kann der Bewahrungsdienst selbst die notwendigen Zertifikate zusammentragen und Zertifikatsstatusinformationen beim zuständigen Zertifikatsstatusdienst („Certificate Status Authority“) einholen.

Dabei gibt es drei Hauptvarianten für Bewahrungsdienste, abhängig von der Frage, ob sie (a) mit einem Langzeitspeicher („with long-term storage“, WST), (b) mit einem temporären Speicher („with a temporary storage“, WTS) oder (c) ohne Speicher („without storage“, WOS) betrieben werden. Im WST-Fall kann der Bewahrungsdienst einen internen Speicher oder einen externen Speicher unter seiner Kontrolle für die Bewahrung nutzen. Ein solcher Bewahrungsdienst mit Speicher funktioniert insgesamt sehr ähnlich, wie eine „TR-ESOR-Middleware“ gemäß der BSI-Richtlinie TR-03125, in der aktuell auch die „Preservation-API“ gemäß ETSI TS 119 512 integriert wird.

 

Abbildung 3: System mit Bewahrungsdienst

 

Die bei ETSI entwickelten Bewahrungsstandards ETSI TS 119 511 und ETSI TS 119 512 erlauben es, unterschiedliche Strategien für die Bewahrung („Preservation Schemes“) zu definieren und mit so genannten Bewahrungsprofilen („Preservation Profiles“) umzusetzen.

Die Bewahrungsprofile können wiederum die folgenden Bewahrungsziele verfolgen:

  • PDS („Preservation of digital signatures”) – zum Beweis der Existenz und zur Bewahrung des Status digitaler Signaturen,
  • PGD („Preservation of general data”) – zum Beweis der Existenz beliebiger Daten, die entweder signiert oder nicht signiert sein können, und
  • AUG („Augmentation“) – für die Erweiterung von Beweisdaten, die von einem anderen Bewahrungsdienst erzeugt wurden, um eine langfristig beweiskräftige Bewahrung zu ermöglichen.

Die in ETSI TS 119 512 spezifizierten Bewahrungsstrategien nutzen entweder Evidence Records gemäß RFC 4998 bzw. RFC 6283, die für CAdES und XAdES vorgesehenen Archivzeitstempel oder die für PAdES vorgesehenen Dokumentenzeitstempel.

Abhängig vom Speichermodell (WST, WTS, WOS) müssen (M) bzw. können (K) die verschiedenen Operationen, wie in der folgenden Tabelle dargestellt, von einem Bewahrungsdienst gemäß ETSI TS 119 512 umgesetzt werden:

 

Operation

Speichermodell

Beschreibung der Funktion

 

WST

WTS

WOS

 

Retrieve
Info

M

M

M

Liefert Informationen über die vom Bewahrungsdienst unterstützten Profile

PreservePO

M

M

M

Übergabe von Datenobjekten (“Preservation Object”, PO)

RetrievePO

M

M

/

Abruf von Datenobjekten (Nutz- und Beweisdaten)

DeletePO

M

/

/

Löschen von Datenobjekten

UpdatePOC

K[1]

/

/

Erweiterung eines Aufbewahrungscontainers um eine neue Version

Retrieve
Trace

K

K

K

Abruf von Protokolldaten

Validate
Evidence

K

K

K

Validierung von Beweisdaten

Search

K

K

/

Suche nach einem bestimmten
Datenobjekt

Tabelle 1: Operationen der Preservation-API



Ähnlich wie bei den anderen API-Spezifikationen wurde auch in ETSI TS 119 512 zunächst die Semantik einer Operation definiert, bevor die konkrete Syntax für XML und JSON spezifiziert wurde.

Auf dem Weg zur „eIDAS-API“ und zur Interoperabilität für das eIDAS-Ökosystem

Ausgehend von den bislang von OASIS und ETSI vorgelegten Programmierschnittstellen ist es nur noch ein vergleichsweise kleiner Schritt hin zu einer umfassenden „eIDAS-API“, über die alle Dienste des eIDAS-Ökosystems über gängige, Webservice-basierte Mechanismen auf Basis von XML/SOAP oder JSON/REST angesprochen werden können.

Hierfür muss lediglich ein für die jeweiligen Technologieausprägungen geeigneter Authentisierungs- und Autorisierungsmechanismus ergänzt werden. Während bei SOAP der Einsatz von Web Service Security Mechanismen naheliegend ist, bietet sich bei REST der Einsatz von OAuth gemäß RFC 6749 bzw. allgemeiner der Einsatz von HTTP/1.1 basierten Authentisierungsmechanismen gemäß RFC 7235 an.

Eine solche „eIDAS-API“ wird sinnvoller Weise nicht nur die hier beschriebenen Funktionen zur Erstellung, Validierung  und Bewahrung von Signaturen, Siegeln und Zeitstempeln  umfassen, sondern auch die anderen Dienste des eIDAS-Ökosystems in geeigneter Weise integrieren. Dies umfasst nicht nur die elektronische Identifizierung und die auf dieser Basis sehr effizient mögliche Ausstellung von (qualifizierten) Zertifikaten, sondern beispielsweise auch die vertrauenswürdige Übermittlung und Zustellung elektronischer Dokumente und Einschreiben. Um die nahtlose und gleichzeitige Nutzung von Chipkarten- und HSM-basierten Signaturerstellungseinheiten zu ermöglichen, empfiehlt sich der Einsatz des kürzlich vorgeschlagenen und aktuell in OASIS DSS-X standardisierten „Local and Remote Signature Profile“, bei dem lokale und entfernte Signaturerstellungseinheiten über weitgehend identische Schnittstellen angesprochen werden können. Erste Schritte zur praktischen Umsetzung der geplanten „eIDAS-API“ wurden kürzlich mit dem Start des FutureTrust-Pilotportals und der Einsetzung der go.eIDAS-Arbeitsgruppe „API-Interoperabilität“ unternommen. Schließen Sie sich uns dort an, um den Traum von einem interoperablen eIDAS-Ökosystem Wirklichkeit werden zu lassen!


[1] Die Funktion setzt voraus, dass das verwendete Containerformat die Versionierung grundsätzlich unterstützt.

Willkommen in der Zukunft des Vertrauens

Noch bevor die Verordnung (EU) Nr. 910/2014 über elektronische Identifizierung (eID) und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt (eIDAS) am 1. Juli 2016 in vollem Umfang in Kraft getreten ist, hatte sich ein gesamteuropäisches Expertenteam unter der Leitung der Ruhr-Universität Bochum und der ecsec GmbH im EU-finanzierten FutureTrust Projekt zusammengefunden, um die Bereitstellung und Nutzung elektronischer Identifizierungs- (eID) und Vertrauensdienste (Trust Services) zu erleichtern. In mehr als drei Jahren intensiver Forschungs- und Entwicklungsarbeit sind im FutureTrust-Projekt zahlreiche bemerkenswerte Innovationen entstanden, die nun einer breiten Öffentlichkeit zugänglich gemacht und im vorliegenden Blogbeitrag im Überblick vorgestellt werden.

Überblick über die FutureTrust Systemarchitektur

Überblick über die FutureTrust Systemarchitektur

Wie in der obigen Abbildung dargestellt, adressiert das FutureTrust Projekt große Teile des eIDAS-Ökosystems und integriert verschiedene FutureTrust Services und FutureTrust Pilotanwendungen sowie die „Globale Vertrauensliste“ (Global Trust List), die Informationen über Anbieter von Vertrauensdiensten in den europäischen Mitgliedstaaten und darüber hinaus liefert.

Es gibt die folgenden wesentlichen FutureTrust Services

  • den gesamteuropäischen eID-Broker (eID-Broker, eID),
  • den Signatur- und Siegelerstellungsdienst (Signature Generation & Sealing Service, SigS),
  • den Validierungsdienst (Validation Service ValS),
  • den Bewahrungsdienst (Preservation Service PresS),

und die folgenden FutureTrust Pilotanwendungen

  • ein portugiesischer Dienst für elektronische SEPA-eMandate (eMandate),
  • ein österreichischer Dienst für elektronische Rechnungen (eInvoice),
  • ein georgischer Dienst für elektronische Apostillen (eApostille) und
  • das deutsche eIDAS-Portal, mit dem nach einer eID-basierten Identifizierung Zertifikate ausgestellt werden können.

Hintergrund, Motivation und Probleme – sowie Lösungen von FutureTrust!

Wie in der Abbildung unten dargestellt, gibt es derzeit[1] rund 200 Vertrauensdiensteanbieter (QTSP) in Europa, die qualifizierte Zertifikate für elektronische Signaturen ausstellen sowie etwa 100 Anbieter von qualifizierten Zeitstempeln.

Es gibt derzeit  rund 200 Vertrauensdiensteanbieter (QTSP) in Europa, die qualifizierte Zertifikate für elektronische Signaturen ausstellen sowie etwa 100 Anbieter von qualifizierten Zeitstempeln

Damit ist das „eIDAS-Ökosystem“ hinsichtlich dieser grundlegenden Vertrauensdienste, die bereits vor dem Inkrafttreten der eIDAS-Verordnung existierten, sehr gut entwickelt. In ähnlicher Weise gibt es inzwischen in Europa eine beachtliche Zahl von Anbietern für qualifizierte Zertifikate zur Ausstellung elektronischer Siegel (93) bzw. Webseiten-Authentifizierung (41), so dass die Marktentwicklung hier auf einem guten Weg zu sein scheint. Auf der anderen Seite gibt es bislang nur sehr wenige Anbieter von qualifizierten Validierungs- (13), Bewahrungs- (10 bzw. 11) oder Einschreiben-Zustelldiensten (15) und die – gerade in Verbindung mit der Fernsignatur – sehr vielversprechende Option zur Ausstellung von qualifizierten Zertifikaten auf Basis einer geeigneten elektronischen Identifizierung (Art. 24 (1) (b) eIDAS-Verordnung) scheint bislang noch nicht praktisch umgesetzt und am Markt verfügbar zu sein.

In Erwartung dieser absehbaren Entwicklung hat das FutureTrust Projekt auf den Erfahrungen und Vorarbeiten aus einschlägigen Vorprojekten (wie z.B. STORK, STORK 2.0, FutureID, e-SENS, SD-DSS, Open eCard, OpenPEPPOL und SkIDentity) aufgebaut, um so die bestehenden Lücken durch Adressieren der folgenden Probleme (P1-P6) so weit wie möglich zu schließen und maßgeschneiderte Lösungen (->) anzubieten:

  • Kein Open Source Validierungsdienst -> der FutureTrust Validierungsdienst (ValS)
  • Kein standardisierter Bewahrungsdienst -> der FutureTrust Bewahrungsdienst (PresS)
  • Keine eID-basierte Zertifikatsausstellung -> das eIDAS-Portal der deutschen Universitäten
  • Kein universeller Signaturerstellungsdienst -> der FutureTrust Signatur- und Siegelerstellungsdienst (SigS)
  • Grenzüberschreitende und außereuropäische Transaktionen sind eine Herausforderung -> der gesamteuropäische eID-Broker
  • Grundlegender Forschungsbedarf im Bereich Sicherheit, Vertrauen und Vertrauenswürdigkeit

P1. Kein Open Source Validierungsdienst -> der FutureTrust Validierungsdienst (ValS)

Viele derzeit verfügbare Komponenten zur Prüfung elektronischer Signaturen und Siegel sind

  • auf bestimmte Dokument- und Signaturformate eingeschränkt (beispielsweise unterstützt der kostenfrei verfügbare Adobe Reader nur die Prüfung von elektronischen Signaturen und Siegeln im PAdES-Format gemäß ETSI EN 319 142),
  • leicht angreifbar und/oder
  • proprietäre Komponenten, deren Quellen nicht öffentlich verfügbar sind,

so dass die Vertrauenswürdigkeit eines Prüfungsergebnisses nur sehr schwer eingeschätzt werden kann.

Außerdem, wie in der Abbildung oben dargestellt, gibt es bislang in Europa nur sehr wenige qualifizierte Validierungsdienste für qualifizierte elektronische Signaturen oder Siegel. 

Vor diesem Hintergrund hat das FutureTrust-Projekt, einen umfassenden Validierungsdienst (ValS) entwickelt, der fortgeschrittene elektronische Signaturen und Siegel (AdES) sowie zugehörige Signaturobjekte, wie z.B. X.509 Zertifikate oder Evidence Records, auf Basis konfigurierbarer Signaturprüfungsrichtlinien („Signature Validation Policies“) unterstützt und das Validierungsergebnis in einem maschinenlesbaren XML- oder JSON-basierten Validierungsbericht zurückgibt (vgl. ETSI TS 119 102-2 und OASIS DSS v1.0 Comprehensive Multi-Signature Verification Report Profile).

Format

Standard

Beschreibung

CAdES

ETSI EN 319 122

ASN.1-basierte Signatur auf Basis der „Cryptographic Message Syntax

XAdES

ETSI EN 319 132

XML-basierte Signatur auf Basis der „XML Digital Signature

PAdES

ETSI EN 319 142

in PDF-Dokument eingebettete CAdES-Signatur

JWS

RFC 7515

JSON-basierte Signatur für Webanwendungen, zukünftig ebenso JAdES

X.509

X.509

Ermöglicht die Überprüfung des Status und der Vertrauenswürdigkeit eines X.509-Zertifikats (siehe auch RFC 5280) anhand einer geeigneten Vertrauensliste.

ERS

RFC 4998

Evidence Records, die es ermöglichen, effiziente Nachweise der Existenz bestimmter Daten zu einem bestimmten Zeitpunkt zu erbringen.

Weitere Details zum FutureTrust Validation Service (ValS), der in Kürze als Open Source zur Verfügung gestellt wird, werden in einem kommenden Blogbeitrag veröffentlicht.

P2. Kein standardisierter Bewahrungsdienst -> der FutureTrust Bewahrungsdienst (PresS)

Die wohlbekannte Tatsache, dass signierte Objekte ihren Beweiswert verlieren, wenn kryptographische Algorithmen schwach werden, stellt Anwendungen, die die Aufrechterhaltung der Integrität und Authentizität signierter Daten über lange Zeiträume – oder sogar für die Ewigkeit – erfordern, vor sehr große Herausforderungen. Während die technische Richtlinie BSI TR-03125 (TR-ESOR) bereits vor FutureTrust erste spezifische Komponenten für den Beweiswerterhalt spezifiziert hat, sind die entsprechenden ETSI-Standards für Bewahrungsdienste (vgl. beispielsweise ETSI TS 119 511 und ETSI TS 119 512) eben erst fertig gestellt worden.

Vor diesem Hintergrund waren ausgewählte Experten des FutureTrust Teams aktiv an der einschlägigen Standardisierungsarbeit in OASIS DSS-X und ETSI ESI beteiligt, so dass das FutureTrust Projekt in der Lage war, eine vertrauenswürdige Referenzimplementierung des Europäischen Standards für Bewahrungsdienste zu schaffen.

Weitere Details zum FutureTrust Bewahrungsdienst (PresS) werden in einem kommenden Blogbeitrag veröffentlicht.

P3. Keine eID-basierte Zertifikatsausstellung -> das eIDAS-Portal der deutschen Universitäten

Vor der Ausstellung eines qualifizierten Zertifikats an eine natürliche oder juristische Person, müssen gemäß Art. 24 der eIDAS-Verordnung die Identität und gegebenenfalls spezifische Attribute des Zertifikatsinhabers überprüft werden. Darüber hinaus existieren auch ähnliche Anforderungen an die Ausstellung von nicht qualifizierten Zertifikaten, die innerhalb der Public-Key-Infrastruktur des Deutsches Forschungsnetzes (DFN-PKI) ausgegeben werden. Diese Infrastruktur, die nach ETSI EN 319 411-1 auditiert ist, kann für verschiedene Zwecke – d.h. neben der elektronischen Signatur auch zur E-Mail-Verschlüsselung, Authentifizierung und für die Absicherung von Webseiten – genutzt werden. Neben der persönlichen Identifizierung vor Ort (Art. 24 (1) a)), erlaubt die eIDAS-Verordnung auch die Identifizierung per eID (Art. 24 (1) b)), per qualifizierter Signatur bzw. per qualifiziertem Siegel (Art. 24 (1) c)) oder über sonstige, national anerkannte, Identifizierungsmethoden mit gleichwertiger Sicherheit (Art. 24 (1) d)). Während die wachsende Zahl der notifizierten eID-Systeme und die Verfügbarkeit des gesamteuropäischen eID-Brokers die Verwendung von eID-Mitteln für die Identitätsprüfung bei der Zertifikatsregistrierung nahe legen, scheint diese Option in der Praxis noch nicht verfügbar zu sein. Vor diesem Hintergrund hat das FutureTrust- Projekt ein intelligentes eID-basiertes System zur Zertifikatsregistrierung entwickelt, das es ermöglicht, hochschulspezifische Zugangsdaten mit eID-basierter Identitätsverifizierung zu kombinieren, um am Ende einen vollständig elektronischen Prozess zur Zertifikatsverwaltung innerhalb der DFN-PKI zu erhalten.

Weitere Details zu diesem neuartigen System zur Zertifikatsverwaltung, das als „eIDAS-Portal“ der an FutureTrust teilnehmenden deutschen Universitäten bezeichnet wird, werden in einem kommenden Blogbeitrag behandelt.

P4. Kein universeller Signaturerstellungsdienst -> der FutureTrust Signatur- und Siegelerstellungsdienst (SigS)

Auch wenn Zertifikate bereits ausgestellt sind, heißt dies noch lange nicht, dass man sie leicht zur Erstellung von Signaturen oder Siegeln in Webanwendungen nutzen kann. Einen universellen Dienst, mit dem man beliebige Chipkarten- oder Fernsignatur-basierte Zertifikate unterschiedlicher Anbieter nutzen könnte, gibt es bislang scheinbar nicht. Durch das von LuxTrust S.A. in Zusammenarbeit mit dem FutureTrust-Partner ecsec GmbH entwickelte ChipGateway-Protokoll und die Erweiterung und Anpassung des Protokolls und der Architektur zur Unterstützung der Besonderheiten des deutschen Personalausweises sowie der jüngst bei OASIS DSS-X und ETSI ESI entwickelten Signaturstandards, sind hier wichtige Grundlagen für den im FutureTrust-Projekt anvisierten universellen Signaturerstellungsdienst geschaffen worden.

Weitere Details zum der FutureTrust Signatur- und Siegelerstellungsdienst (SigS) sowie den dazugehörigen Standards von OASIS und ETSI werden in einem kommenden Blogbeitrag behandelt.

P5. Grenzüberschreitende und außereuropäische Transaktionen sind eine Herausforderung -> der gesamteuropäische eID-Broker

Kapitel II der eIDAS-Verordnung, das sich mit eID-Systemen befasst, zielt auf die Schaffung eines standardisierten einheitlichen Interoperabilitätsrahmen mit klar definierten Prozessen, Sicherheitsstufen, Mindestanforderungen und Schnittstellen ab, beabsichtigt aber nicht, die jeweiligen nationalen eID-Systeme zu vereinheitlichen. Dabei können die EU-Mitgliedstaaten ihr nationales eID-System notifizieren, so dass die entsprechenden eID-Mittel europaweit auf einem bestimmten Sicherheitsniveau anerkannt werden, nachdem eine sorgfältige Prüfung („Peer Review“) durchgeführt wurde und das förmliche Notifizierungsverfahren mit einer Veröffentlichung im Amtsblatt der Europäischen Union abgeschlossen wurde (siehe beispielsweise 2019/C 150/06). Für die technische Umsetzung des eID-Rahmenwerks sind so genannte „eIDAS-Knoten“ vorgesehen, die bei grenzüberschreitenden Prozessen zwischen den Anwendungs- und Authentifizierungsdiensten vermitteln. Bisher sind die vorgesehenen „eIDAS-Knoten“ noch nicht vollständig im Produktivbetrieb und das „eIDAS-Netzwerk“ auf EU-Mitgliedsstaaten und Länder des Europäischen Wirtschaftsraums beschränkt. Vor diesem Hintergrund, hat das FutureTrust-Projekt – aufbauend auf einschlägige Vorarbeiten aus FutureID und SkIDentity – einen intelligenten gesamteuropäischen eID-Broker entwickelt, der durch die europäischen Patente EP2439900 und EP2919145 geschützt ist, eine Vielzahl von Standards sowie notifizierte Identifizierungsmittel aus Deutschland, Estland, Luxemburg, Belgien und Portugal unterstützt. Die entsprechenden Details werden in einem zukünftigen Blog-Beitrag erläutert.

Während die grenzüberschreitende Identifizierung innerhalb Europas schon nicht ganz einfach ist, kommen bei der elektronischen Abwicklung von Transaktionen mit außereuropäischen Partnern weitere Herausforderungen hinzu, die auf datenschutzrechtliche Besonderheiten bei der Übermittlung personenbezogener Daten an Drittländer (vgl. DSGVO, Kapitel 5) oder bislang fehlende internationale Abkommen zur gegenseitigen Anerkennung von Vertrauensdiensten gemäß Artikel 14 der eIDAS-Verordnung zurückzuführen sind. Leider gibt es keine zur eIDAS-Verordnung vergleichbare globale Gesetzgebung, so dass im FutureTrust-Projekt entsprechende Grundlagenforschung im Bereich rechtlicher, organisatorischer und technischer Aspekte durchgeführt werden musste, die sich in entsprechenden Publikationen und dem Prototyp einer „Globalen Vertrauensliste“ (gTSL) widerspiegelt. Die gTSL ist eine Open-Source-Komponente für die vertrauenswürdige Verwaltung von Trusted Lists nach ETSI TS 119 612, die mit den anderen FutureTrust Diensten oder als eigenständiger Dienst bereitgestellt werden kann und die Gegenstand eines zukünftigen Blog-Beitrags sein wird.

P6. Grundlegender Forschungsbedarf im Bereich Sicherheit, Vertrauen und Vertrauenswürdigkeit

Die fortlaufende Sicherheitsforschung fördert regelmäßig Sicherheitsprobleme und Schwachstellen zu Tage und hinsichtlich der zentralen Begriffe „Vertrauen“ und „Vertrauenswürdigkeit“ scheint es bislang nicht einmal fundierte und allgemein akzeptierte Definitionen zu geben, ganz zu schweigen von global akzeptierten abgestuften Sicherheitsmindestanforderungen. Deshalb war es notwendig, diese grundlegenden Aspekte von „Vertrauen“ und „Vertrauenswürdigkeit“ im Rahmen des FutureTrust-Projektes wissenschaftlich zu erörtern und zu analysieren, bevor formale Modelle entwickelt werden konnten, die umfassende Vertrauensmodelle beschreiben, die letztendlich die Grundlage für den objektiven Vergleich der Vertrauenswürdigkeit verschiedener Identifizierungs- und Vertrauensdienste bildeten.

Zusammenfassung, Würdigung und Ausblick

Der vorliegende Blog-Beitrag gibt einen kompakten Überblick über die wichtigsten Probleme, die im Rahmen des FutureTrust Projekts, das am 1. Juni 2016 begann und von der Europäischen Kommission im Rahmen des EU-Rahmenprogramms für Forschung und Innovation (Horizont 2020) unter der Fördervereinbarung Nr. 700542 gefördert wurde, addressiert und gelöst wurden.

Wie oben erläutert, wurden im FutureTrust-Projekt nicht nur wichtige Grundlagen im Bereich von Sicherheit, Vertrauen und Vertrauenswürdigkeit erforscht, sondern es wurde auch der Standardisierungsprozess in zentralen Bereichen aktiv begleitet und es wurden zahlreiche Dienste entwickelt, die den Einsatz von eID und elektronischer Signaturtechnologie in realen Anwendungen erleichtern, indem sie die oben beschriebenen Probleme angegangen sind.

Die praktische Anwendbarkeit der Konzepte und Softwarekomponenten wurde in mehreren Pilotanwendungen demonstriert, wie z.B. einem portugiesischen Dienst für elektronische SEPA-eMandate, einem österreichischen Dienst für elektronische Rechnungen (eInvoice), einem georgischen Dienst für elektronische Apostillen (eApostille) und nicht zuletzt dem deutschen eIDAS-Portal, das die Ausstellung von Zertifikaten nach einer eID-basierten Identifizierung ermöglicht.

Die FutureTrust Dienste und die FutureTrust Anwendungen werden nun Schritt für Schritt der breiten Öffentlichkeit zur Verfügung gestellt und Interessenten werden ermutigt, sich mit den FutureTrust Experten in Verbindung zu setzen, um über maßgeschneiderte Lösungen für individuelle Bedürfnisse zu sprechen.

 

[1] Vergleicht man die aktuellen Zahlen (Juli 2019) mit den Zahlen eines aktuellen deutschen Artikels, der in der DuD 2019/04 erschienen ist, so zeigt sich, dass die Zahl der qualifizierten Vertrauensdiensteanbieter leicht wächst.

 

 

 

Besichtigung des „eIDAS-Ökosystems”

Die „Verordnung (EU) Nr. 910/2014 des Europäischen Parlaments und des Rates vom 23. Juli 2014 über elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im Binnenmarkt und zur Aufhebung der Richtlinie 1999/93/EG”, die gemeinhin als „eIDAS-Verordnung” bekannt ist, verspricht das Vertrauen und die Effizienz von elektronischen Transaktionen in Europa zu steigern. In diesem Blogeintrag wollen wir ins Gedächtnis zurückrufen, worum es in der eIDAS-Verordnung geht, und wir möchten Sie herzlich einladen, mit uns zu einem „virtuellen Aussichtspunkt” hinaufzusteigen, von dem aus die wesentlichen Teile und Dienste des „eIDAS-Ökosystems“ und ihr Zusammenspiel erkennbar werden, so dass Sie die existierenden Vertrauensdienste in einer interaktiven eIDAS-Landkarte erkunden und das generelle Potential  und Ihre individuellen Vorteile  durch diese EU-Verordnung erkennen können.

Das „eIDAS-Ökosystem” auf einem Blick

Wie in der Abbildung gezeigt, umfasst das „eIDAS-Ökosystem” insbesondere den „Benutzer”, der einen „eIDAS-basierten Transaktionsdienst” nutzt. Dieser Transaktionsdienst greift wiederum auf eine Reihe von weiteren „eIDAS-Diensten” zu, deren Vertrauenswürdigkeit durch das „eIDAS Vertrauenssystem” sichergestellt wird.

Das „eIDAS Vertrauenssystem”, welches auf Grund der ausgefeilten, darin zusammenwirkenden Mechanismen eine gesonderte Behandlung in einem zukünftigen Blogeintrag verdient, stellt die vertrauenswürdige Basis für das „eIDAS-Ökosystem” bereit, die durch eine sorgfältig ausgewählte Kombination von Maßnahmen wie Akkreditierung, Konformitätsbewertung, Überwachung und Vorfallsbehandlung erreicht wird.

Während auch das Reich der „eIDAS-basierten Transaktionsdienste” facettenreich genug ist, um besser in zukünftigen Blogeinträgen behandelt zu werden, sollen die „eIDAS-Dienste“ im Folgenden kurz vorgestellt und näher erläutert werden, da sie das funktionale Herz des „eIDAS-Ökosystems“ bilden.

Die „eIDAS-Dienste” umfassen den „Identifizierungsdienst” (eID-Service) gemäß Kapitel II der eIDAS-Verordung und verschiedene „Vertrauensdienste“ (Trust Services) gemäß Artikel 3 (16) und Kapitel III der eIDAS-Verordnung. Diese umfasst insbesondere

Identifizierungsdienst (eID-Service)

Der „Identifizierungsdienst“ (eID-Service) ermöglicht die sichere Identifizierung und Authentifizierung von Benutzern und juristischen Personen. Hierbei können die gemäß
Artikel 9 notifizierten Identifizierungssysteme sowie weitere geeignete Mittel zur Identifizierung und Authentifizierung genutzt werden. Für die Bewertung des Sicherheitsniveaus eines Identifizierungssystems bzw. Identifizierungsmittels sind in Artikel 8 der eIDAS-Verordnung die Stufen „niedrig“, „substanziell“ und „hoch“ definiert und detaillierte Anforderungen finden sich im zugehörigen Durchführungsrechtsakt DVO (EU) 2015/1502. Notifizierte Identifizierungssysteme, die zumindest die Stufe „substanziell“ erreichen, werden gemäß Artikel 6 der eIDAS-Verordnung von den EU-Mitgliedsstaaten bei grenzüberschreitenden Transaktionen gegenseitig anerkannt.

Zertifizierungsdienst (Certification Authority, CA)

Ein „Zertifizierungsdienst” (Certification Authority, CA) erzeugt elektronische Zertifikate und stellt diese für Benutzer und andere Entitäten (Zertifikatsinhaber, Subject) aus. Dies kann entweder direkt oder vermittelt über einen entsprechenden Dienst, wie z.B. dem „eIDAS-basierten Transaktionsdienst“ oder dem „Signatur- und Siegelerstellungsdienst“ (SigS) erfolgen. In diesem Fall interagiert der Dienst mit dem CA-System und bestimmt zusammen mit dem „Identifizierungsdienst” die Identität des Zertifikatsinhabers, indem die entsprechenden Identitätsattribute geprüft und bestätigt werden, die schließlich mit dem öffentlichen Schlüssel des Zertifikatsinhabers kombiniert und zur Erstellung des Zertifikates vom „Zertifizierungsdienst“ signiert werden.

Zeitstempeldienst (Time Stamping Authority, TSA)

Die Möglichkeit die Existenz bestimmter Daten zu einem bestimmten Zeitpunkt beweisen zu können, ist eine Anforderung, die bei vielen elektronischen Transaktionen (z.B. für elektronische Signaturen, bei der Verwaltung elektronischer Rechte, bei elektronischen Verträgen oder für beweiskräftige Aufzeichnungen) benötigt wird. Zu diesem Zweck erhält ein „Zeitstempeldienst“ (Time Stamping Authority, TSA) die mit einem Zeitstempel zu versehenden Daten, oder einen Hashwert davon, und liefert einen Zeitstempel zurück, der neben dem Hashwert der Daten eine zuverlässige Zeitangabe umfasst und mit einer Signatur des Zeitstempeldienstes versehenen ist.

Signatur- und Siegelerstellungsdienst (Signature Generation & Sealing Service SigS)

Der „Signatur- und Siegelerstellungsdienst” (Signature Generation & Sealing Service, SigS) ermöglicht die Erzeugung von (qualifizierten) elektronischen Signaturen gemäß Abschnitt 4 und (qualifizierten) elektronischen Siegeln gemäß Abschnitt 5 der eIDAS-Verordnung in technischen Formaten, wie z.B. CAdES, XAdES und PAdES.

Validierungsdienst (Validation Service, ValS)

Die (qualifizierten) elektronischen Signaturen und Siegel, die mit dem oben erläuterten SigS erzeugt werden, können mit dem „Validierungsdienst“ (Validation Service, ValS) geprüft werden. Hierzu nutzt der ValS die in den Vertrauenslisten gemäß Artikel 22, bzw. dem Durchführungsbeschluss DFB (EU) 2015/1506 und ETSI TS 119 162(v2.1.1), enthaltenen Zertifikate als Vertrauensanker und führt eine Signaturprüfung gemäß EN 319 102-1 in Verbindung mit einer geeigneten Signaturprüfungspolitik (Signature Validation Policy) durch.

Bewahrungsdienst (Preservation Service, PresS)

Die langfristige Aufbewahrung signierter Dokumente macht eine Form der Aufbewahrung notwendig, die die Lesbarkeit und den Erhalt der Beweiskraft der Dokumente und Signaturen unabhängig vom Speichermedium sicherstellt. Um die rechtliche Gültigkeit und die Beweiskraft elektronischer Signaturen und Siegel langfristig zu erhalten, müssen geeignete Bewahrungstechniken eingesetzt werden, wie sie in ETSI SR 019 510 beschrieben sind. Die Aufbewahrungstechniken, die von einem „Bewahrungsdienst“ (Preservation Service, PresS) gemäß Artikel 34 der eIDAS-Verordnung umgesetzt werden müssen, können sich auf Evidence Records gemäß RFC 4998 oder RFC 6283 oder die kontinuierliche Konservierung von Signaturen mit Archivzeitstempeln gemäß CAdES oder XAdES stützen.

Zustelldienst (Electronic Delivery Service, EDS)

In der papierbasierten Welt kann durch den Versand eines Briefs als Einschreiben sicher erkannt werden, dass ein Brief wirklich den Empfänger erreicht hat. Diese Dienstleistung wird durch die Postdienstleister angeboten. In diesem Fall schreibt der Absender seine Nachricht auf ein Stück Papier und steckt dieses in einen abgeschlossenen Umschlag, auf dem die Adresse des Empfängers vermerkt ist und verschickt diesen schließlich mit der Post. Die Zurechenbarkeit, die Vertraulichkeit und die Unversehrtheit des Briefs wird weitgehend durch den Absender sichergestellt, während der Postdienstleister vor allem die Gewähr für die Verfügbarkeit und die korrekte Zustellung der Sendung übernimmt.

Gemäß Artikel 44 der eIDAS-Verordnung müssen „qualifizierte Dienste für die Zustellung elektronischer Einschreiben […] folgende Anforderungen erfüllen:

  1. Sie werden von einem oder mehreren qualifizierten Vertrauensdiensteanbietern erbracht.
  2. Sie stellen die Identifizierung des Absenders mit einem hohen Maß an Vertrauenswürdigkeit sicher.
  3. Sie stellen die Identifizierung des Empfängers vor der Zustellung der Daten sicher.
  4. Das Absenden und Empfangen der Daten ist durch eine fortgeschrittene elektronische Signatur oder ein fortgeschrittenes elektronisches Siegel eines qualifizierten Vertrauensdiensteanbieters auf eine Weise gesichert, die die Möglichkeit einer unbemerkten Veränderung der Daten ausschließt.
  5. Jede Veränderung der Daten, die zum Absenden oder Empfangen der Daten nötig ist, wird dem Absender und dem Empfänger der Daten deutlich angezeigt.
  6. Das Datum und die Zeit des Absendens, Empfangens oder einer Änderung der Daten werden durch einen qualifizierten elektronischen Zeitstempel

Vor dem Hintergrund dieser Anforderungen ist es offensichtlich, dass ein „Zustelldienst“ (Electronic Delivery Service, EDS) eine Vielzahl weiterer eIDAS-Dienste umfasst bzw. nutzen muss. Dies umfasst z.B. den „Identifizierungsdienst“, den „Signatur- und Siegelerstellungsdienst“ (SigS), den „Validierungsdienst“ (ValS), den „Zeitstempeldienst“ (TSA) und muss die vom „Zertifizierungsdienst“ (CA) bereitgestellten Zertifikatstatusinformationen auswerten.

Entdecken Sie das Potenzial von eIDAS mit der interaktiven eIDAS-Landkarte

Der EDS ist ein schönes Beispiel dafür, dass verschiedene grundlegende „eIDAS-Dienste“ zu einem umfassenderen „eIDAS-Dienst“ bzw. einem „eIDAS-basierten Transaktionsdienst“ für anwendungsspezifische Anforderungen zusammengefasst werden können. Ein zentraler Aspekt der eIDAS-Verordnung ist, dass durch sie die regulatorischen Anforderungen für elektronische Identifizierungsdienste und Vertrauensdienste europaweit harmonisiert werden und auch der rechtliche Effekt von notifizierten Identifizierungssystemen (siehe Artikel 6), elektronischen Signaturen (siehe Artikel 25), elektronischen Siegeln (siehe Artikel 35), Zeitstempeln (siehe Artikel 41), elektronischen Zustelldiensten (siehe Artikel 43) und nicht zuletzt elektronischen Dokumenten (siehe Artikel 46) nun europaweit einheitlich geregelt ist.

Deshalb können Anbieter und Nutzer von Vertrauens- und Transaktionsdiensten aus der großen Anzahl qualifizierter Vertrauensdiensteanbieter, die derzeit im Europäischen Markt aktiv sind, auswählen und diese über die heute bereitgestellte interaktive eIDAS-Landkarte leicht erkunden. Diese Landkarte bietet jeweils einen tagesaktuellen Überblick über die am Europäischen Markt agierenden Vertrauensdiensteanbieter und ihre derzeit angebotenen Vertrauensdienste.

Der individuelle Nutzen der eIDAS-Verordnung – Was bringt mir eIDAS?

Welche spezifischen Vorteile und welchen Nutzen die eIDAS-Verordnung für Sie genau bereithält, hängt von Ihrer spezifischen Rolle im „eIDAS-Ökosystem“ ab. Der Vorteil für Anbieter von „eIDAS-Diensten“ ist, dass diese nun ihre Dienste in ganz Europa anbieten und verkaufen können, was neue und sehr interessante Vermarktungsmöglichkeiten beinhaltet. Der Vorteil für Benutzer ist, dass diese nun aus einer Vielzahl von angebotenen Vertrauensdiensten mit wohldefinierter Vertrauenswürdigkeit wählen können und die mit der Nutzung dieser Dienste verbundenen Rechtsfolgen klar definiert sind. Der möglicherweise größte mit der eIDAS-Verordnung einhergehende Vorteil existiert jedoch für „eIDAS-basierte Transaktionsdienste“, die Gegenstand eines zukünftig erscheinenden Blogeintrags sein werden.

Danksagung

Wir erkennen dankbar an, dass dieser Blogeintrag auf Inhalten aufbaut, die im FutureTrust-Projekt erarbeitet wurden, das unter dem Förderkennzeichen No. 700542 Fördermittel aus dem Forschungs- und Innovationsprogramm „Horizont 2020“ der Europäischen Union erhalten hat.

Ist Ihr Identitätsmanagement schon fit für die Datenschutz-Grundverordnung?

„Daten sind das Öl des 21. Jahrhunderts.“ – so oder so ähnlich fällt diese Aussage häufig, sobald es um Themen wie Big Data oder Spionage geht. Tatsächlich beruht mittlerweile das Geschäftsmodell von vielen Unternehmen auf dem Sammeln oder Analysieren von Nutzerdaten oder -verhalten. Dabei spielen nicht nur offensichtliche Akteure, wie z. B. soziale Netzwerke und Suchmaschinen, deren Ziel es ist, möglichst scharfe Profile ihrer einzelnen Nutzer zu erzeugen, eine wichtige Rolle, sondern auch die großen Werbenetzwerke, die ihrerseits diese und eigene Profile dafür nutzen, um möglichst treffsicher personalisierte Werbung an die jeweiligen Nutzer auszuliefern.

Umso wichtiger war es, dass mit der Datenschutz-Grundverordnung (DSGVO) europaweit harmonisierte Rahmenbedingungen für den Datenschutz entstanden sind, um für alle Bürgerinnen und Bürger in Europa ein angemessenes Datenschutzniveau zu gewährleisten. Die DSGVO ist seit dem 24. Mai 2016 in Kraft und wird ab dem 25. Mai 2018 (also in ziemlich genau einem Jahr), auch für die zuständigen Aufsichtsbehörden, anwendbar sein. Auf Grundlage der DSGVO, und mit einem Auge auf die ePrivacy-Verordnung („Verordnung über Privatsphäre und elektronische Kommunikation“), die zeitgleich mit der DSGVO im Mai 2018 wirksam werden soll, werden derzeit die nationalen Datenschutzgesetze, wie z. B. das Bundesdatenschutzgesetz durch das „Datenschutz-Anpassungs- und -Umsetzungsgesetz EU“ (DSAnpUG-EU), überarbeitet.

Insbesondere muss sich jeder Datenverarbeiter bewusst sein, dass Artikel 5 („Grundsätze für die Verarbeitung personenbezogener Daten“) eine explizite Rechenschaftspflicht enthält, durch die der für die Datenverarbeitung Verantwortliche die korrekte Einhaltung der Anforderungen der DSGVO bei Bedarf gegenüber den Aufsichtsbehörden nachweisen können muss.

Dieser Nachweis muss z. B. für die in Artikel 6 (Rechtmäßigkeit der Verarbeitung) festgelegten Bedingungen erbracht werden. Die zentrale Bedingung ist hierbei, dass die betroffene Person explizit in die Verarbeitung ihrer Daten für einen oder mehrere bestimmte Zwecke eingewilligt hat. Für Unternehmen, die mit personenbezogenen Daten arbeiten heißt dies also, dass bereits bei der allerersten Interaktion mit einem neuen Nutzer oder Kunden darauf zu achten ist, dass die Einwilligung in die Verarbeitung der Daten auf eine Weise geschieht, die DSGVO-konform ist. Artikel 7 (Bedingungen für die Einwilligung) gibt hierfür strengere Vorgaben vor, als sie bisher in der Regel üblich waren. Unternehmen werden hierdurch wohl noch mehr als vorher auf eine beweiskräftige Dokumentation der Einwilligung und die Möglichkeit eine erteilte Einwilligung zu widerrufen achten müssen; denn ist die Einwilligung unwirksam, und die Verarbeitung der Daten Betroffener damit unzulässig, können schnell empfindliche Bußgelder drohen.

Artikel 83 (Allgemeine Bedingungen für die Verhängung von Geldbußen) legt hier die Höhe der zu verhängenden Bußgelder fest, die schnell empfindliche Höhen erreichen können. Selbst bei geringeren Verstößen, wenn z. B. keine geeigneten Sicherheitsmaßnahmen nach dem Stand der Technik implementiert wurden, drohen Geldstrafen von bis zu 10 Mio. Euro bzw. im Fall eines Unternehmens bis zu 2 % des weltweiten Jahresumsatzes. Bei Verstößen gegen die zentralen Grundsätze der Verordnung (insbesondere Artikel 5, 6, 7 und 9) oder gegen die Betroffenenrechte (Artikel 12 bis 22) erhöht sich die Höhe der Geldbuße auf bis zu 20 Mio. Euro bzw. bei Unternehmen auf 4 % des weltweiten Jahresumsatzes.

Ein zentrales Recht für Betroffene wird in Artikel 17 („Recht auf Vergessenwerden“) festgeschrieben. Dieses Recht war bereits vor einer Weile nach einem Gerichtsurteil des EuGH in aller Munde und wurde, vor allem mit Blick auf das Internet und insbesondere Suchmaschinen, kontrovers diskutiert. Die DSGVO garantiert dieses Recht nun Betroffenen ausführlich mit einem eigenen Artikel; in der alten EU-Datenschutzrichtlinie war dieses Recht noch nicht mehr als ein Teil einer Aufzählung. Dienstanbieter werden nun sehr genau darauf achten müssen, die Vorgaben der DSGVO einzuhalten, da sonst die oben erwähnten empfindlichen Geldbußen von bis zu 4 % des weltweiten Jahresumsatzes drohen.

Eine weitere Herausforderung für Dienstanbieter ist das Recht der Betroffenen auf Datenübertragbarkeit (Artikel 20). Dieser Artikel schreibt hierbei vor, dass Dienstanbieter und Datenverarbeiter zukünftig jedem Betroffenen die Möglichkeit bieten müssen, innerhalb eines angemessenen Zeitraums, die vom Betroffenen selbst oder durch dessen unmittelbares Handeln erzeugten Daten diesen in einem maschinenlesbaren Format zur Verfügung zu stellen. Naheliegend erscheint hier der Export der Betroffenendaten aus den Datenbanken des Anbieters mit einem maschinenlesbaren Format wie XML oder JSON.

Insbesondere bei historisch gewachsenen Anwendungslandschaften ist die Integration der verschiedenen Applikationen, Datenbestände und Identitäten eines Benutzers vor dem Hintergrund von Artikel 17 und 20 der DSGVO eine Herausforderung, die nicht ohne Unterstützung von entsprechenden Experten auf diesem Gebiet angegangen werden sollte.

Artikel 25 stellt eine wichtige Errungenschaft der neuen DSGVO dar: Das Prinzip „Privacy by Design and Default“ (im Deutschen etwas sperrig als „Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen“ bezeichnet). Durch Etablierung dieses Prinzips als eines der zentralen Punkte der Verordnung soll einerseits erreicht werden, dass die zum Schutz der personenbezogenen Daten umgesetzten Maßnahmen sowohl dem Stand der Technik (der in Artikel 32 zusätzlich näher definiert wird) entsprechen, aber eben auch, dass die realisierten und in der Praxis angewandten Maßnahmen stets dem Schutzbedarf der Daten angemessen sind. Der Schutzbedarf richtet sich hier ausschließlich nach dem Risiko, das dem Betroffenen durch die Verarbeitung der Daten entsteht. Für den Datenverarbeiter bedeutet dies, dass er (verglichen mit der Bewertung des Risikos im Rahmen des klassischen Informationssicherheitsmanagement (ISMS)) die Perspektive wechseln muss. Die einfache Übernahme der bereits für das eigene ISMS durchgeführten Risikoanalyse könnte hier also zu kurz greifen.

Was „Privacy by Design and Default“ im Bereich des Identitätsmanagements bedeutet, kann gut am Beispiel des innovativen und datenschutzfreundlichen SkIDentity-Dienstes erläutert werden: Denn SkIDentity unterstützt das Management von digitalen Identitäten durch Einführung eines datenschutzfreundlichen Single Sign-On für Unternehmen und Behörden. Durch die Nutzung modernster Technologien können sich Benutzer so genannte Cloud Identitäten (CloudIDs) aus ihren Identitätstoken (wie z. B. dem deutschen Personalausweis und anderen Ausweiskarten) oder sonstigen Identitätsquellen erstellen. Über seine CloudID behält ein Benutzer jederzeit die volle Kontrolle über seine Identitätsdaten, da die CloudIDs nicht zentral auf einem Server gespeichert werden, sondern dezentral bei jedem Benutzer auf dem Endgerät seiner Wahl. Dabei kann ein Benutzer, die auf seinem PC erstellte CloudID problemlos auf weitere Endgeräte übertragen (beispielsweise sein Mobiltelefon) und diese so auch mobil nutzen. Durch die dezentrale Speicherung der CloudIDs liegt außerdem die Löschung und Sperrung der jeweiligen CloudID komplett in der Hand des Nutzers. Das Risiko des Identitätsdiebstahls durch erfolgreiche Angriffe auf eine zentrale Infrastruktur wird hierdurch signifikant reduziert.

Dabei wurden bei SkIDentity von der ersten Idee bis zum heutigen Tag die Grundsätze Privacy by Default und Privacy by Design nicht nur beachtet, sondern als wesentliche Designkritierien und Kernthemen des Dienstes gesehen. Damit wurde bereits vor Entstehung und Veröffentlichung der DSGVO einer der wichtigsten Aspekte der Verordnung in SkIDentity gelebt und umgesetzt.

Belohnt wurde diese Herangehensweise nicht nur durch verschiedene internationale Auszeichnungen, sondern sie spiegelt sich auch ganz besonders in den erfolgreich durchgeführten Zertifizierungsverfahren nach dem Trusted Cloud Datenschutz Profil und nach ISO 27001 auf Basis von IT-Grundschutz wider, durch die wiederum die Erfüllung der Anforderungen gemäß Artikel 25 und Artikel 32, insbesondere auch im Fall der Auftragsdatenverarbeitung gemäß Artikel 28, nachgewiesen werden kann.

Schutz nach dem Stand der Technik (Artikel 32) ist ein vielfältig auslegbarer Begriff, bei dem insbesondere die existierenden internationalen Standards und einschlägigen Regularien und Empfehlungen des Bundesamtes für Sicherheit in der Informationstechnik (BSI) zu berücksichtigen sind. Durch tiefe Kenntnisse der einschlägigen internationalen Standards und die aktive Erstellung und Pflege verschiedener Technischer Richtlinien im Auftrag des BSI, ist die ecsec GmbH ihr kompetenter Ansprechpartner zu Fragen nach dem aktuellen Stand der Technik und einer effizienten Umsetzung von wirksamen Sicherheitslösungen. Für das Login bei Cloud- und Webanwendungen empfiehlt das BSI in seinem „Cloud Computing Eckpunktepapier“ sowie im „Anforderungskatalog Cloud Computing (C5)“ beispielsweise den Einsatz von starken und auf mindestens zwei Faktoren basierenden Authentifizierungsmechanismen.

Galaktisches Lob für den elektronischen Personalausweis

Zur Erörterung des Entwurfs eines „Gesetzes zur Förderung des elektronischen Identitätsnachweises“ (BT-Drs. 18/11279) fand am Montag, 24. April 2017 eine offenbar weithin beachtete¹ Anhörung des Innenausschusses des Deutschen Bundestages statt. Wer an diesem denkwürdigen Tag nicht vor Ort in Berlin sein konnte, kann sich den Livemitschnitt der Expertenanhörung in der  Mediathek des Bundestages ansehen. Für diejenigen, die sich nicht die komplette Sitzung zu Gemüte führen möchten, haben wir den möglicherweise interessantesten Ausschnitt hier bereitgestellt:

Dr. Constanze Kurz, die Sprecherin des Chaos Computer Clubs, führt zum elektronischen Personalausweis folgendes aus:

„Das Grundkonzept technischer Art ist zwar komplex und sicherlich schwer zu verstehen für den normalen Bürger der jetzt diesen aktivierten Chip kriegt, aber natürlich sehr durchdacht und ‘ne gute Lösung.“

Wir haben es immer gewusst! Dem ist eigentlich nichts hinzuzufügen. Es sei dahingestellt, ob die eID-Funktion des Personalausweises nach diesem wohl größtmöglichen, mindestens aber galaktischen² Lob überhaupt noch eine gesetzliche Förderung braucht.

¹ Siehe z.B. ZEIT, Focus, NETZPOLITIK, Berliner Zeitung, Frankfurter Rundschau, Heise, Kommune21, eGovernment-Computing, Computer Base

² Wie in der FAQ erläutert, ist der Chaos Computer Club „eine galaktische Gemeinschaft von Lebewesen, unabhängig von Alter, Geschlecht und Abstammung sowie gesellschaftlicher Stellung.“