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.