Results of the Remote Signature Survey 2023

Cloud, CSC, eID, eIDAS, eSeal, eSignature, ETSI, go.eIDAS, OASIS

As it is by now almost five years ago that the first version of ETSI TS 119 432 (“Protocols for remote digital signature creation”) was published, the experts from ETSI ESI, OASIS DSS-X, Cloud Signature Consortium (CSC) and go.eIDAS have joined forces in order to set up a short survey, which aimed at identifying existing implementations of ETSI TS 119 432 and providing an overview of existing Remote Signature services.

Note, that these services may play a crucial role within the practical implementation of the forthcoming Art. 6a (4) (ec) eIDAS2, which stipulates that the European Digitial Identity Wallet (EUDIW) shall offer the ability to create qualified electronic signatures free of charge for non-professional purposes.

Remote Signature Survey 2023

This survey has been carried out in the last quarter of 2023 and was answered by 30 organisations listed below, among almost all provide Remote Signature services.

The main results of the survey may be summarised as follows:

  • 17 % (5) of the Remote Signature Services are compliant to ETSI TS 119 432 v1.2.1, whereas 13 % (4) have chosen to implement the variant based on the CSC-API and 3 % (1) is based on the OASIS-API.
  • 60 % (18) of the Remote Signature Services provide an API, which is similar to the ETSI-API, whereas 47 % (14) are based on the CSC-API, 7 % (2) are based on the OASIS-API and 7% (2) are based on some other API. Note, that several respondents, which support the CSC-variant, have indicated that they are supporting version 0.4.0 or even 2.0.0.2 of this specification, while ETSI 119 432 v1.2.1 is refering to version 1.0.3.0 of the CSC-API-specification and hence ETSI TS 119 432 may need to be updated accordingly.
  • 3 % (1) of the Remote Signature Service providers plan to support the ETSI-API in the near future and
  • 20 % (6) do not plan to support a standardised API at all.

Remote Signature Survey Result

While almost all participants in the survey prefer to keep pricing information confidential, there were some figures provided: One respondent indicated a price of 120 € per year for qualified electronic signatures and 400 € for advanced electronic seals. Another respondent mentioned a monthly fee of 200 € for accessing the remote signature interface. Yet another respondent mentioned a range from 0 to 0,50 € per advanced electronic signature and 0 to 2,50 € per qualified electronic signature. Sample costs for identification have been provided for 2,50 € with eID, 7,50 € with VideoIdent and 3,50 € with AutoIdent. Only one respondent shared a price list for remote signature services, which is based on transaction fees and a minimum number of transactions, but this pricing is only valid in selected EU Member States.

We thank the following organisations for participating in the survey:

eIDAS-Signer launched

Digital Sovereignty, eID, eIDAS, eSeal, eSignature, go.eIDAS, mGov4EU

The EU-funded mGov4EU project follows a citizen-centric approach to enable secure and privacy-friendly mobile government services across Europe. Among the project results is the novel eIDAS-Signer service (https://Signer.eID.AS), which allows to use electronic identification (eID) means, such as the German eID or ID Austria, for the creation of advanced or qualified electronic signatures in a mobile environment.

There are currently 32 (pre-) notified eID-Schemes in Europe. Furthermore there are currently 260 Qualified Trust Service Providers (QTSPs), among which 189 issue qualified certificates for electronic signature purposes. Against this background the mGov4EU project has assembled leading European experts from government, business and science located in Austria, Belgium, Estonia, Germany, and Spain in order to design the next generation service infrastructure for Europe and develop innovative services on this basis.

This especially bridges the gap between the “eID” part and the “AS” (trust services) part of the eIDAS regulation in order to enable trustworthy, mobile and citizen-centric electronic business and cross-border government processes all over Europe.

mGov4EU bridges the gap between eID and AS for mobile citizen

An important result of the mGov4EU project is the novel and community-driven eIDAS-Signer service, which is available at https://Signer.eID.AS and allows to create advanced or qualified electronic signatures after suitable electronic identification processes in a mobile environment.

Welcome to the eIDAS-Signer

The eIDAS-Signer service has been co-designed with a variety of experts within the open eIDAS community, assembled around the non-profit go.eIDAS e.V., and has been developed and is operated by ecsec GmbH in a certified environment to provide an easy to use and SME-suitable alternative to already existing, but purely commercially oriented offerings, which are typically provided by multi-national enterprises.

While the eIDAS-Signer service currently only supports ID Austria and the German eID, it is an obvious goal to support the other notified eID-Schemes and more QTSPs as depicted below.

Please feel free to reach out to the open eIDAS community to get support, suggest improvements or new features as well as priorities for further development.

We gratefully acknowledge that the eIDAS-Signer builds upon components and services, which have been developed within research projects supported by the European Commission (FutureTrust and mGov4EU) and the German Ministry of Economic Affairs and Climate Action (SkIDentity and TEAM-X).

The triple is completed: The German ID card can now be used in Nextcloud, WordPress and TYPO3 for strong authentication free of charge!

BSI, Cloud, eID, eIDAS, eIDASin Action, Nextcloud, SkIDentity, TYPO3, WordPress

The strong authentication by means of the German ID card for all TYPO3 applications completes the triple of eID logins for Nextcloud, WordPress and TYPO3 realised by ecsec GmbH on behalf of the Federal Office for Information Security (BSI). In the last few weeks, three eID Login Services for web applications that are particularly popular have been developed and published under an Open Source license. In connection with the SkIDentity service, the German eID card can now be used free of charge in all these web applications for strong authentication.

Underline: The German ID card can now be used in Nextcloud, WordPress and TYPO3 for strong authentication free of charge!

Strong Authentication with German eID Card reaches public

The German eID Card (“Personalausweis”) with online ID function, which has been notified at the highest possible level of assurance (“high”) in accordance with the eIDAS-Regulation, can be used by all citizens for electronic identification (eID) and for strong pseudonymous authentication on the Internet. Until now, this has been used in a range of special applications mostly in the government sector. With the eID Login Services developed by ecsec GmbH on behalf of the BSI, it is now possible to use the German eID Card with online ID function in the popular web applications Nextcloud, WordPress und TYPO3 for strong authentication.

The early and consequent consideration of relevant security aspects according to the „Security by Design“ principle and the publication of the “eID-Login” extensions as Open Source ensure that a very high level of trustworthiness is achieved

„eID-Login“ App for Nextcloud

Nextcloud offers the industry-leading Open Source Cloud Solution for on-premises data processing and communication. The platform combines universal data access via mobile and desktop web interfaces with innovative, secure communication and collaboration functions such as document processing in real time, chat and video calls – and all of this under the direct control of IT and can be integrated into existing infrastructures. With its easy and fast deployment, modular architecture and focus on security and efficient collaboration, Nextcloud enables modern companies to optimize their existing file storage facilities inside and outside the boundaries of their company. Based on the “eID-Login” App for Nextcloud developed by ecsec GmbH on behalf of the BSI, it is now possible to use the German ID card with online ID function in this popular cloud solution for strong authentication. “It is great to see Nextcloud as the first mainstream platform with support for the German eID Card for strong authentication and identification,” adds Frank Karlitschek, founder and managing director of Nextcloud GmbH. “We look forward to many users of this innovative authentication technology.”

„eID-Login“ Plugin for WordPress

WordPress was originally a software for weblogs and has now developed into a full-fledged Content Management System (CMS) based on PHP and MySQL for creating and maintaining websites. A large percentage of all German websites are implemented on the basis of the freely available and market-leading WordPress Content Management System (CMS). Against this background, ecsec GmbH developed on behalf of the BSI an „eID-Login“ Plugin for WordPress, with which the German eID card with online ID can now be used for strong authentication. “This means that the electronic identity can be activated and used immediately in around 40% of all German websites,” explains Dr. Detlef Hühnlein Managing Director of ecsec GmbH.

„eID-Login“ Extension for TYPO3

TYPO3 is a free and flexible Open Source Content Management System that is very well suited for professional website creation. About half of the German DAX companies and about a quarter of all German cities have set up their websites with TYPO3. In order to use the German ID card for strong authentication of frontend users in TYPO3, ecsec GmbH has developed an “eID-Login” extension for TYPO3 on behalf of the BSI. “It is great that the German eID card with online ID function can now also be used in TYPO3 for strong authentication”, adds Tina Hühnlein Managing Director of ecsec GmbH.

Cooperation between BSI and ecsec GmbH enables free https://eID.Services

So that the German eID Card can be used immediately and free of charge for strong authentication in Nextcloud, WordPress and TYPO3 the SkIDentity service, which has won multiple international awards, is also provided for strong authentication free of charge as part of the joint project. In addition to the free authentication service, the eID experts at ecsec GmbH also offer additional support services for hosting providers and application developers (see https://eID.Services) so that the “eID-Login” functionality can easily be integrated and used in other Open Source applications as well.

 

mGov4EU mobilises European eGovernment

mGov4EU

With the practical implementation of the “eIDAS regulation”, which has been fully applicable since July 2016, the European Union has made great strides in recent years in successfully simplifying the cross-border online identification process for citizens. In addition, in December 2020 a first part of the “Single Digital Gateway (SDG)” regulation for the establishment of a uniform digital access gate for administration in the EU came into force. After all, there is an unbroken trend towards the mobile and self-determined use of administrative services: Today, citizens expect eGovernment services to always be conveniently usable via smartphone. Against this background, the mGov4EU (“Mobile Cross-Border Government Services for Europe”, https://mGov4.EU) project, funded by the European Union as part of the Horizon 2020 research and innovation program, has recently started to enable mobile cross-border administrative services in Europe. The project is open to further pilot partners and cordially invites you to participate.

The mGov4EU project assembles leading European experts from government, business and science located in Austria, Belgium, Estonia, Germany, and Spain, to enable secure and privacy-friendly mobile government services across Europe. mGov4EU will put the citizen at the center of the considerations and offer them new, secure and privacy-protecting options for managing their identity and personal data – regardless of whether they or the eGovernment service are located in the home country or in another EU Member State.

mGov4EU combines eIDAS with a single digital gateway in a user-centric way

The regulatory framework for this project is provided by Regulation (EU) 2018/1724 on the establishment of a Single Digital Gateway Regulation (SDGR) for the cross-border provision of services together with the eIDAS Regulation (EU) No. 910/2014 for cross-border electronic identification and trust services for electronic transactions in the internal market. The mGov4EU project puts the requirements of self-sovereign and mobile citizens at the center of the considerations and integrates the existing eIDAS ecosystem with the new Single Digital Gateway to create a user-friendly overall system.

The mGov4EU-System at a glance

Figure 1: The mGov4EU-System at a glance

Within the mGov4EU project the existing and emerging possibilities of the eIDAS and SDG regulation will be used and the principles of “once-only”, “digital-by-default” and “mobile-first” will be implemented in practice. After a user-friendly mobile identification and explicit approval by the user, it will be possible to access data that is already available, so that the time-consuming filling out of complex forms can be dispensed with, as far as possible. Through the consistent use of the technologies available in modern smartphones, the solutions targeted in mGov4EU are not only expected to meet the highest security and data protection requirements, but also offer an excellent user-friendliness. The mGov4EU project aims at providing basic building blocks for secure and mobile eGovernment services that can be used throughout Europe and beyond. These modules will be tested in selected pilot applications in the field of electronic voting, smart mobility and, last but not least, mobile signature, before they will be made available to a broader group of users. In this way, based on the mGov4EU developments, a trustworthy federation of collaborative eGovernment platforms can emerge, which facilitates the joint provision and reuse of available and easy-to-use public services.

The mGov4EU project is carried out by an interdisciplinary team of experts

The mGov4EU project is fully funded by the EU research and innovation program Horizon 2020 with a budget of 3.9 million Euro. The mGov4EU project assembles top-class, internationally experienced, interdisciplinary experts from administration, business and science. In addition to the TECHNIKON Forschungs- und Planungsgesellschaft mbH as coordinator, the Center for Secure Information Technology Austria (A-SIT together with A-SIT Plus GmbH), Danube University Krems, ecsec GmbH, the Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V., go.eIDAS Association, Graz University of Technology, Scytl Election Technologies, TIMELEX and the University of Tartu work on this project.

During the three-year project period, several mGov4EU pilot applications will be designed and implemented in order to validate the solution modules and infrastructure services provided. The pilot applications include electronic voting, smart mobility based on subsidised taxi rides and mobile signature. Interested authorities across Europe are cordially invited to contact the mGov4EU project in order to participate in these pilot applications or to use the innovative technologies in their own applications at an early stage.

Deploy with GAIA-X – Towards Digital Sovereignty at a push of a button

Cloud, Digital Sovereignty, GAIA-X, SkIDentity

Digital sovereignty describes the ability to shape the digital transformation in a self-determined manner with regard to hardware, software, services, and skills. Common standards, modular architectures and the use of Open Source in the public sector are considered to be central pillars for digital sovereignty and interoperability and GAIA-X is expected to provide a major contribution for the practical implementation of digital sovereignty in Europe.

Against this background leading European cloud experts from Cloud & Heat, Charité / deNBI, D3TN, ecsec, IONOS, publicplan, Red Hat / IBM, Scheer and Trusted Cloud have joined forces to demonstrate the feasibility of deploying composite Open Source applications, such as Nextcloud with the recently presented eID-Login App, via the orchestrator engine Krake to suitable cloud environments as determined by matching user requirements with provider Self-Description files. The application of eIDAS-compliant identity management services provided by SkIDentity ensure the required high level of trust, legal compliance and easy application across Europe.

The presented “Deploy with GAIA-X” prototype will be the starting point for the implementation of the German public code repository “Ort für öffentlichen Code”, which is envisioned to foster digital sovereignty in all levels of the German public sector – from the local government level via the federal states to the federal level.

 

New APIs for the eIDAS-Ecosystem

eIDAS

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

OASIS and ETSI have developed Application Programming Interfaces (API) for the generation, validation and long-term preservation of signatures, seals, time-stamps and evidence records, which provide the foundation for the development of a comprehensive “eIDAS-API”.

The eIDAS-Regulation, which has been fully applicable since July 2016, opened numerous new possibilities for the trustworthy digitalization of business processes in industry and administration. To put these opportunities into practice, the standardisation committees OASIS DSS-X and ETSI ESI have developed standards for the generation, validation, and long-term preservation of signatures, seals, time-stamps and evidence records. This blog post provides a compact overview of the recently created APIs and provides an outlook on possible future developments.

Introduction

Regulation (EU) No 910/2014 of the European Parliament and the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC, which is commonly known as the “eIDAS Regulation”, aims at increasing the trust and efficiency of electronic transactions in Europe. This regulation has added numerous new trust services and aspects of electronic identification (eID) to the existing European framework for electronic signatures and time-stamps. In addition to the remote signature mentioned in recital (52), services for the validation and long-term preservation of signatures and seals have been included in Articles 33, 34 and 40 of the eIDAS-Regulation. In order to facilitate the practical use of these new trust services in an interoperable way and to provide a solid foundation for a prosperous and sustainable eIDAS-Ecosystem, the standardization committees responsible for electronic signature technologies at OASIS (Digital Signature Services eXtended, DSS-X) and ETSI (Electronic Signatures and Infrastructures, ESI) have recently adopted API-standards for for the creation, validation, and long-term preservation of signatures, seals, timestamps and evidence records.

This post provides a compact overview of the recently standardised programming interfaces and outlines possible future developments.

The new API standards Overview

As depicted in the figure below, the new API-standards provide programming interfaces for key services within the eIDAS-Ecosystem. Signatures and seals can be created via the Signature Generation & Sealing Service (SigS), verified via the Validation Service (ValS) and finally preserved for long periods of time with the Preservation Service (PresS). The application systems use the web service-based APIs developed by ETSI ESI and OASIS DSS-X. While the interfaces for the creation (ETSI TS 119 432) and validation of electronic signatures and seals (ETSI TS 119 442) are based upon the new version 2.0 des OASIS DSS-X Core, only the basic schema files created by OASIS (“Base” and “Metadata”) have been imported and extended for the definition of the interface of the Preservation Service (ETSI TS 119 512). In addition to the technical interface specifications considered in more detailed below, ETSI TS 119 431 (part 1 and part 2), ETSI TS 119 441 and ETSI TS 119 511 specify corresponding policy and security requirements, which form the basis for the conformity assessment of related (qualified) trust services in accordance with the eIDAS-Regulation.

 

Figure 1: The new signature APIs at a glance

 

OASIS DSS-X Core 2.0

As part of a Technical Committee (TC), specialising in “signature services”, a “Core” specification was created by the international standardization organization OASIS in 2007. This standard defines the basic functionality for the creation (SignRequest /-Response) and validation (VerifyRequest /-Response) of CMS- and XMLDSig-compliant signatures. Due to the wide range of requirements from the various application areas of signatures and time-stamps, the core specification has been extended by a series of so-called “profiles”, e.g. for use with code signing, entity seals or processing XAdES- and CAdES-compliant artifacts. In the following years further profiles were developed, e.g. for detailed signature verification reports and for signature creation devices not located within the server instance.

Based on this previous work, the challenges of a new “API-Ecosystem” were addressed in the OASIS Digital Signature Services eXtended (DSS-X) TC with version 2.0 of the Core, which also seperates the semantics of the interface from the concrete implementation using a specific syntax. In addition to the XML syntax adopted from version 1, JSON, which is often used in modern web applications, is now also supported. Additional syntaxes could be defined, if required. For example, an ASN.1 based syntax would be conceivable to enable a particularly compact format for mobile and embedded applications with the “Packed Encoding Rules” (PER). To ensure the highest possible visibility and acceptance of the standard, the DSS-X Technical Committee, in collaboration with the OASIS Infrastructure team, has started to provide the interface on the „SwaggerHub“ collaboration platform. For this purpose, the JSON schema is extended by a series of meta-information to comply with the OpenAPI specification.

The profiles, recently created by ETSI and currently at OASIS, enable the specific characteristics of the AdES signature formats in combination with local and remote eIDAS-compliant signature createn devices via the DSS-X interface. The additional attributes of the signatures (e.g., the embedded certificate status information, time-stamps or evidence records) allow a wide applicability of this format. Since the initial standardisation, the associated interface extensions for the XAdES and CAdES formats are defined by the “AdES-Profile”. As part of version 2.0, the AdES-Profile is currently updated to support the latest developments related to the AdES formats. In particular, the PAdES format based on the PDF specification is also supported in accordance with ETSI EN 319 142-1. With this PAdES format multiple signatures in a workflow and the visual representation of an electronic signature in a PDF document can be realised.

For use within the eIDAS environment, the support of so-called “policies” by the DSS-X specification proves to be valuable. This allows the caller to submit a “policy” to the service, required for the desired action. The addressed server instance decides whether it can meet the required quality level or whether the request must be rejected. If the request is processed, the applied “policy” can be transferred to the caller within the response structure. This ensures that a consensus has been reached on the minimum quality level to be applied.

ETSI TS 119 432

ETSI TS 119 432 based on version 2.0 of the OASIS DSS-X Core or in case of JSON also on the preparatory work of the Adobe-led “Cloud Signature Consortium” specifies interfaces for the remote signatures enabled by the eIDAS-Regulation. Here, in accordance with the standard EN 419 241 (part 1 and part 2) developed by CEN, a differentiation is made between the “Server Signing Application” (SSA) and the “Signature Creation Application” (SCA), each offering corresponding web service interfaces. The SSA contains an HSM-based “Signature Activation Module” (SAM) that triggers, after strong authentication of the signer in the “Signature Activation Protocol” (SAP) using the “Signer Interaction Component”, the creation of a raw digital signature in a low-level format, such as RSA according to PKCS # 1 or ECDSA for example. On the other hand, SCA ensures the preparation of the extended AdES signature format according to ETSI EN 319 122 (CAdES), ETSI EN 319 132 (XAdES) or ETSI EN 319 142 (PAdES).

 

Figure 2: Remote signing system according to ETSI TS 119 432

 

ETSI TS 119 442

ETSI TS 119 442 defines three different programming interfaces, one for each type of service offering signature validation (validation via VerifyRequest / VerifyResponse), signature augmentation (augmentation via AugmentRequest / AugmentResponse), or offering both services combined. The first version of this document deals with the validation and enhancement of AdES signatures that comply with the current ETSI standards, such as: ETSI EN 319 122 (CAdES), ETSI EN 319 132 (XAdES) and ETSI EN 319 142 (PAdES) and the previous AdES specifications. Especially relevant are in particular the “Baseline Profiles” ETSI TS 103 171, ETSI TS 103 172 and ETSI TS 103 173 mentioned in the “Commission Implementing Decision” (EU) 2015/1506 and the underlying AdES specifications ETSI TS 101 733, ETSI TS 102 778 and ETSI TS 101 903.

Future versions of this document may also cover the validation of time-stamps, evidence records, or signatures in ASiC containers.

ETSI TS 119 442 is based as much as possible on version 2.0 of the OASIS DSS-X Core. At the time of the finalisation of ETSI TS 119 442, the final version of the new OASIS DSS-X Core had not yet been published and therefore ETSI TS 119 442 needed to be based upon a draft version of the OASIS document. In cases where the depth of the OASIS draft did not seem sufficient to provide the desired functionality of the programming interface, new elements were defined.

Similar to version 2.0 of the OASIS DSS-X Core, each element of the programming interface is first described generally before characterising corresponding syntaxes for XML and JSON.

The defined validation interface allows, in addition to the signature, to send only the hash of the corresponding document instead of the signed document. This functionality can be very useful if the signed document is either very large, or if it must be avoided to send it completely to the Validation Service because of privacy or confidentiality reasons. Since a signature augmentation may require a new hash of the signed document, this option is not provided for the signature augmentation protocol.

If a document contains more than one signature, the APIs allow to select a specific subset of these signatures for validation and / or extension. In addition, it can also be specified in a request how many details should be returned in the response. This can range from a very simple response up to a comprehensive and signed signature valication report according to ETSI TS 119 102-2, as required in Article 33 (1) lit. b) of the eIDAS-Regulation.

ETSI TS 119 512

As a basis for the development of the technical specifications in the field of preservation services, a special report ETSI SR 019 510 was first created in ETSI ESI. On this basis, the development of the actual protocol standard ETSI TS 119 512 and the associated “Policy and Security Requirements” ETSI TS 119 511 took place.

As shown in the figure below, a Preservation Service according to ETSI TS 119 512 provides a “Preservation API”. This API may for example be used to send the preservation objects, intended for long-term preservation to the Preservation Service. A Preservation Service may on the other hand use external Time Stamping Authorities in accordance with ETSI EN 319 422, Signing & Sealing Services (SigS) or Validation Services (ValS) in order to obtain missing certificates and certificate revocation information necessary for signature validation. Alternatively, the Preservation Service may itself compile the necessary certificates and obtain certificate status information from the appropriate Certificate Status Authority.

There are three main types of Preservation Services, depending on the question whether they are operating: (a) “with a long-term storage” (WST), (b) “with a temporary storage” (WTS) or (c) “without storage” (WOS). In case of WST, the Preservation Service may use an internal or external storage under its control. Such a Preservation Service with storage is very similar to a “TR-ESOR-Middleware” according to the BSI Guideline TR-03125. The “Preservation-API” according to ETSI TS 119 512 is currently being integrated into the “TR-ESOR-Middleware”.

 

Figure 3: System with Preservation Service

 

The preservation standards ETSI TS 119 511 and ETSI TS 119 512 developed by ETSI allow to use different Preservation Schemes, which can be implemented in so-called Preservation Profiles.

The Preservation Profiles may on the other hand pursue the following objectives:

  • PDS (“Preservation of digital signatures”) – as proof of existence and for the preservation of the status of the digital signatures,
  • PGD (“Preservation of general data”) – as proof of the existence of general data that may either be signed or unsigned, and
  • AUG (“Augmentation”) – for the preservation of the conclusiveness of evidence, which has been produced by another preservation service, over long periods of time.

The preservation strategies specified in ETSI TS 119 512 use either Evidence Records according to RFC 4998 or RFC 6283, the Archive Time Stamps specified for CAdES and XAdES or the Document Time-Stamps specified for PAdES.

Depending on the storage model (WST, WTS, WOS), the various operations must (M) or may optionally (O) be converted by a Preservation Service according to ETSI TS 119 512, as shown below:

 

Operation Speichermodell Beschreibung der Funktion
WST WTS WOS
Retrieve
Info		 M M M Provides information about the profiles supported by the preservation service
PreservePO M M M Transfer of data objects (“preservation object”, PO)
RetrievePO M M / Retrieval of data objects (reference and evidence data)
DeletePO M / / Delete data objects
UpdatePOC O[1] / / Extension of a storage container by a new version
Retrieve
Trace		 O O O Retrieval of log data
Validate
Evidence		 O O O Validation of evidence data
Search O O / Search for a specific data object

Table: Operations of the Preservation-API

 

Similar to the other API specifications, ETSI TS 119 512 first specifies the general semantics of an operation, before it specifies the concrete syntax for XML and JSON.

Towards the “eIDAS-API” and interoperability for the eIDAS-Ecosystem

Based on the programming interfaces developed by OASIS and ETSI, it is only a comparatively small step towards a comprehensive “eIDAS-API”, by which all services of the eIDAS-Ecosystem can be addressed via common, web service interface based on XML / SOAP or JSON / REST. For this purpose, only an appropriate authentication and authorization mechanism must be provided for the respective technology characteristics. While mechanisms based on Web Service Security are the obvious choice for SOAP, the use of OAuth according to RFC 6749 or, more generally, the use of HTTP/1.1 based authentication mechanisms according RFC 7235 is a natural choice for REST.

The “eIDAS-API” may not only include the functions described here for the generation, validation and preservation of signatures, seals, time-stamps and evidence records, but may also integrate the other services of the eIDAS-Ecosystem in an appropriate way. This may not only include the electronic identification (eID) and the efficient enrolment for (qualified) certificates based on this, but also the trustworthy transmission and registered electronic delivery of documents and emails, for example. In order to enable the seamless and simultaneous use of smartcards and HSM-based signature creation devices, one may use the “Local and Remote Signature Profile”, which has recently been outlined and which is currently standardised in OASIS DSS-X. First steps towards the practical implementation of the envisioned “eIDAS-API” have recently been taken with the launch of the FutureTrust pilots portal and the constitution of the go.eIDAS Working Group “API-Interoperability”. Join us there to make the dream of an interoperable eIDAS-Ecosystem come true!

[1] This function assumes that the used container format supports versioning.

Welcome to the Future of Trust

eIDAS, FutureTrust

Even before the Regulation (EU) No. 910/2014 on electronic identification (eID) and trusted services for electronic transactions in the internal market (eIDAS) became fully applicable on 1st of July 2016, a pan-European team of experts led by the Ruhr University Bochum and ecsec GmbH had joined forces in the EU-funded FutureTrust project to facilitate the provision and use of eID and trust services. In more than three years of intensive research and development, the FutureTrust project has produced numerous remarkable innovations, which are now being made available to the general public and outlined in the present blog post.

 

Overview of the FutureTrust System Architecture

Overview of the FutureTrust System Architecture

As shown in the above figure, the FutureTrust project addresses large parts of the eIDAS-Ecosystem and integrates various FutureTrust Services and FutureTrust Pilot Applications as well as the “Global Trust List”, which provides information related to trust service providers across the European Member States and beyond.

There are the following basic FutureTrust Service

  • Pan-European eID-Broker (eID-Broker, eID),
  • Signature Generation & Sealing Service (SigS),
  • Validation Service (ValS),
  • Preservation Service (PresS),

and the following FutureTrust Pilot Applications

  • a Portuguese service for electronic SEPA eMandates (eMandate),
  • an Austrian service for electronic invoices (eInvoice),
  • a Georgian service for electronic Apostilles (eApostille) and
  • the German eIDAS-Portal, which allows to enrol for certificates after an eID-based identification.

Background, Motivation and Problems – as well as solutions provided by FutureTrust!

As shown in the figure below, there are currently[1] around 200 Qualified Trust Service Providers (QTSP) in Europe issuing qualified certificates for electronic signatures, as well as around 100 providers of qualified time stamps.

 

Trust Service Providers

Hence, the eIDAS-Ecosystem is, with respect to these basic trust services, which already existed before the eIDAS-Regulation entered into force, fairly well developed. Similarly, there also exist a significant number of European providers of qualified certificates for issuing electronic seals (93) or website authentication (41). The development of the market seems to be on the right track here. On the other hand, there are very few providers of qualified validation (13), preservation (10 or 11) or electronic registered delivery service (15) so far. Furthermore the very promising option for issuing qualified certificates based on electronic identification (see Art. 24 (1) (b) of the eIDAS-Regulation) – especially in combination with remote signatures – does not yet seem to be practically implemented and available in the market.

Expecting this foreseeable development, the FutureTrust project has built upon experiences and previous work from pertinent projects (e.g. STORK, STORK 2.0, FutureID, e-SENS, SD-DSS, Open eCard, OpenPEPPOL and SkIDentity) in order to close the existing gaps as far as possible by adressing the following problems (P1-P6) and provide tailormade solutions (->):

  • No Open Source Validation Service -> The FutureTrust Validation Service (ValS)
  • No standardised Preservation Service -> The FutureTrust Preservation Service (PresS)
  • No eID-based certificate enrolment -> The eIDAS-Portal of the German Universities
  • No universal signature and seal creation service -> The FutureTrust Signature Generation & Sealing Service (SigS)
  • Cross-border and non-European transactions are challenging -> The pan-European eID-Broker
  • Demand for fundamental research in the area of security, trust and reliability

P1. No Open Source Validation Service -> The FutureTrust Validation Service (ValS)

Many currently available components for validating electronic signatures and seals are

  • limited to specific document and signature formats (e.g. the freely available Adobe Reader only supports the validation of electronic signatures and seals in the PAdES format according to ETSI EN 319 142),
  • have been shown to be vulnerable and / or
  • are proprietary components, for which the sources are not publicly available

and hence the trustworthiness of a specific validation result is very difficult to assess.

Furthermore, as shown in the figure above, there are currently very few qualified validation service for qualified electronic signatures or seals available in Europe.

Against this background, the FutureTrust project has developed a comprehensive Validation Service (ValS), which supports advanced electronic signatures and seals (AdES) as well as related signature objects including X.509 certificates or Evidence Records based on configurable “Signature Validation Policies” and returns the validation result in a machine-readable XML or JSON based validation report (cf. ETSI TS 119 102-2 and OASIS DSS v1.0 Comprehensive Multi-Signature Verification Report Profile).

Format

Standard

Description

CAdES

ETSI EN 319 122

ASN.1-based digital signature based on the “Cryptographic Message Syntax“

XAdES

ETSI EN 319 132

XML-based digital signature based on the “XML Digital signature“

PAdES

ETSI EN 319 142

PDF document with embedded CAdES signature

JWS

RFC 7515

JSON-based digital signature for web applications, in the future also JAdES

X.509

X.509

Allows to check the status and trustworthiness of an X.509 certificate (see also RFC 5280) based on a suitable Trusted List.

ERS

RFC 4998

Evidence Records, which allow to produce efficient proofs of existence.

More details with respect to the FutureTrust Validation Service (ValS), which will soon be provided as Open Source, will be provided in a forthcoming blog post.

P2. No standardised Preservation Service -> The FutureTrust Preservation Service (PresS)

The well-known fact that signed objects lose their evidential value, if cryptographic algorithms become weak, induces major challenges for applications, which require maintaining the integrity and authenticity of signed data for long periods of time – or even for eternity. While the Technical Guideline BSI TR-03125 (TR-ESOR) had specified components for the preservation of evidence before the advent of FutureTrust, the corresponding ETSI standards for preservation services, such as ETSI TS 119 511 and ETSI TS 119 512 only appeared recently.

Against this background, selected experts from the FutureTrust team have been actively involved in the preservation-related standardisation work within OASIS DSS-X and ETSI ESI such that FutureTrust project has been able to provide a reference implementation of selected preservation schemes from the new preservation standards.

More details with respect to the FutureTrust Preservation Service (PresS) will be provided in a forthcoming blog post.

P3. No eID-based certificate enrolment -> The eIDAS-Portal of the German Universities

Before a qualified trust service provider can issue a qualified certificate to a natural or legal person, it is obliged (see Art. 24 (1) of the eIDAS-Regulation) to verify the identity and, if applicable, any specific attributes of the certificate subject. Furthermore, there are similar requirements for non-qualified certificates, which are issued within the Public-Key Infrastructure of the German Research Network (Deutsches Forschungsnetz, DFN-PKI), which is audited against ETSI EN 319 411-1, and which can be used for electronic signatures, email encryption, authentication or website authentication. In addition to the classical way to perform the identity verification while the subject is physically present (Art. 24 (1) a)), the eIDAS-Regulation also allows to perform the identification remotely using appropriate electronic identification (eID) means (Art. 24 (1) b)), by using qualified signatures or seals (Art. 24 (1) c)) or other identification methods recognised at national level (Art. 24 (1) d)), if they provide equivalent assurance. While the growing number of notified eID schemes and the availability of the pan-European eID-Broker infrastructures strongly suggest to use eID means for the identity verification during certificate enrolment, this option does not seem to be available in practice yet. Against this background, the FutureTrust project has designed and implemented a smart eID-based system for certificate enrolment, which allows to combine University-specific credentials with eID-based identity verification in order to end up with a completely electronic process for certificate enrolment within the DFN-PKI.

More details with respect to this novel certificate enrolment system, which is referred to as the “eIDAS-Portal” of the German Universities, which are participating in FutureTrust, will be subject of a forthcoming blog post.

P4. No universal signature creation service -> The FutureTrust Signature Generation & Sealing Service (SigS)

Even if certificates are already issued, this does not mean that these certificates can easily be used to create signatures or seals in web applications. A universal service for using arbitrary smart card- or remote signature-based certificates of different providers does not seem to exist so far. Through the development of the ChipGateway-protocol by ecsec GmbH and LuxTrust S.A. and the extension and adaptation of the protocol and architecture to support the special features of the German eID card, as well as the latest standards developed by OASIS DSS-X and ETSI ESI, the FutureTrust project has provided a solid corner stone for the envisioned universal signature creation service.

More details with respect to the FutureTrust Signature Generation & Sealing Service (SigS) as well as the related standards produced by OASIS and ETSI will subject of a forthcoming blog post.

P5. Cross-border and non-European transactions are challenging -> The pan-European eID-Broker

Chapter II of the eIDAS-Regulation, which deals with eID systems, aims at creating a standardised interoperability framework with well-defined processes, security levels, minimum requirements and interfaces, but does not intend to harmonise the respective national eID systems. In doing so, the EU Member States can notify their national eID scheme, such that the corresponding eID means will be recognised across Europe for a certain level of assurance, after a careful assessment (“peer review”) has been conducted and the formal notification procedure has concluded with a publication in the Official Journal of the European Union (see 2019/C 150/06 for example). For the technical implementation of the eID interoperability framework, so-called „eIDAS-Nodes“ are provided, which take care about cross-border processes between the application services and the identification services. So far, the envisioned „eIDAS-Nodes“ are not completely available in production yet and the focus of the “eIDAS-Cooperation Network” is limited to EU Member States and countries in the European Economic Area.

Against this background, the FutureTrust project has built upon previous work from pertinent projects, such as FutureID and SkIDentity in order to develop a smart pan-European eID-Broker, which is protected by the European patents EP2439900 and EP2919145, supports a plenty of standards as well as notified eID means from Germany, Estonia, Luxembourg, Belgium and Portugal and is subject of a forthcoming blog post.

While cross-border identification within Europe is often not easy in practice, the electronic processing of transactions with non-European partners poses additional challenges related to data protection specifics in case of transferring personal data to third countries (cf. GDPR, chapter 5) and missing international agreements for mutual recognition of trust services according to Article 14 of the eIDAS-Regulation. Unfortunately, there is no global legislation comparable to the eIDAS-Regulation, which made it necessary in FutureTrust to conduct fundamental research in the area of legal, organisational and technical aspects, which are reflected in relevant academic publications and the prototype of a “Global Trust List” (gTSL). The gTSL is an Open Source component for the trusted management of trust lists according to ETSI TS 119 612, which can be deployed with the other FutureTrust services or as standalone service and which will be subject of a forthcoming blog post.

P6. Fundamental research demand in the area of security, trust and trustworthiness

Conducting security research regularly points out new security problems and vulnerabilities, and with respect to the central concepts of “Trust” and “Trustworthiness”, there does not even seem to be well-founded and generally accepted definitions – not to talk about globally accepted graded minimum requirements. Therefore, it was necessary to scientifically discuss and analyse these fundamental aspects of „Trust“ and „Trustworthiness“ within the FutureTrust project, before formal models were developed, which describe comprehensive “Trust Models”, which finally formed the basis for the objective comparison of trustworthiness of various identification and trust services.

Summary, Acknowledgement and Outlook

The present blog post provided a compact overview of the main problems addressed and solved within the FutureTrust project, which started on 1st of June 2016 and has received funding by the European Commission within the EU Framework Programme for Research and Innovation (Horizon 2020) under the Grant Agreement No. 700542.

As explained throughout this article, the FutureTrust project has conducted fundamental research with respect to the foundations of trust and trustworthiness, has actively supported the standardization process in relevant areas, and has developed numerous services, which ease the use of eID and electronic signature technology in real world applications by addressing the problems outlined above.

The practical applicability of the concepts and software components has been demonstrated in several pilot applications, such as a Portuguese service for electronic SEPA eMandates, an Austrian service for electronic invoices (eInvoice), a Georgian service for electronic Apostilles (eApostille) and last but not least the German eIDAS-Portal, which allows to enrol for certificates after an eID-based identification.

The FutureTrust Services and the FutureTrust Applications are now being made available to the general public step by step and interested parties are encouraged to get in touch with the FutureTrust experts to talk about tailormade solutions and individual needs.

[1] Comparing the current figures (July 2019) with the figures from a recent German article, which has appeared in DuD 2019/04, shows that the number of qualified trust service providers is slightly growing.

 

Sightseeing the “eIDAS-Ecosystem”

eIDAS

The “Regulation (EU) No. 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the internal market and repealing Directive 1999/93/EC”, which is commonly known as the “eIDAS Regulation”, is expected to boost trust and efficiency for electronic transactions across Europe and beyond. In this post, we briefly recall what the eIDAS-Regulation is about, invite you to follow us and climb up to a “virtual viewpoint” from which the major parts and services of the “eIDAS-Ecosystem” and their interrelationship become visible, so that you can explore the currently available trust services using the interactive eIDAS-Map and see the overall potential and your individual benefits introduced by this regulation.

The “eIDAS-Ecosystem” at a glance

As shown in the figure, the “eIDAS-Ecosystem” is populated by “Users”, which use some kind of “eIDAS-based Transaction Services”. These Transaction Services in turn may use a variety of “eIDAS Services”, for which the trust is maintained by the “eIDAS Trust System”.

The “eIDAS Trust System”, which deserves a specific treatment in a forthcoming post because of its sophisticated structure, provides the trustworthy foundation for the entire “eIDAS-Ecosystem” by an appropriate combination of measures including accreditation, conformity assessment, supervision and incident handling.

While the realm of “eIDAS-based Transaction Services” is also sufficiently rich to be subject of additional posts, we will introduce and explain the set of “eIDAS Services” in the following, as these services provide the functional core of the “eIDAS-Ecosystem”.

The “eIDAS Services” comprise the “eID-Service” for electronic identification regulated by Chapter II and a variety of “Trust Services” according to Article 3 (16) and regulated by Chapter III of the eIDAS-Regulation. These services in particular comprise

  • the “Signature Generation & Sealing Service” (SigS),
  • the “Validation Service” (ValS),
  • the “Preservation Service” (PresS),
  • the “Electronic Delivery Service” (EDS) and the already widely implemented classical trust services, such as
  • the “Time Stamp Authority” (TSA) and last but not least
  • the “Certification Authority” (CA).

eID-Service

The “eID-Service” provides services for the secure electronic identification and authentication of Users and legal persons. The employed means and services for electronic identification and authentication comprise electronic identification schemes, which have been notified according to Article 9 as well as other schemes. As specified in Article 8 of the eIDAS-Regulation and the related implementing act CIR (EU) 2015/1502, the trustworthiness of an electronic identification scheme and the identification means deployed within, is reflected in its level of assurance. The specified assurance levels range from “low” over “substantial” to “high”. Notified eID schemes which provide at least a substantial level of assurance will be mutually recognized in cross-border transactions according to Article 6 of the eIDAS-Regulation.

Certification Authority (CA)

A Certification Authority (CA) generates electronic certificates and issues them to Users or other entities, commonly called the Subject of a certificate. This may happen directly, via the “eIDAS-based Transaction Service” or the “Signature & Seal Generation Service” (SigS). The SigS interacts with the CA-system, performs an appropriate identification of the Subject and validates the provided identity attributes, which are combined with a public key and are signed by the CA to create the certificate.

Time Stamping Authority (TSA)

Proving the existence of a given set of digital data at a given time is a fundamental requirement in many electronic transactions, which involve electronic signatures, aspects of digital rights management, electronic contracts or require accountability for example. For this purpose, a Time Stamping Authority (TSA) receives the data, which need to be time stamped, or a hash thereof, and returns a time stamp token, which is signed by the TSA.

Signature Generation & Sealing Service (SigS)

The Signature Generation & Sealing Service (SigS) allows to generate (qualified) electronic signatures according to Section 4 and (qualified) electronic seals according to Section 5 of the eIDAS-Regulation in technical formats such as CAdES, XAdES and PAdES for example.

Validation Service (ValS)

The (qualified) electronic signatures and seals generated with the SigS above can be validated with the Validation Service (ValS). The ValS uses the certificates contained in the Trusted Lists according to Article 22 of the eIDAS-Regulation, the corresponding implementing act CID (EU) 2015/1506 and ETSI TS 119 162(v2.1.1) as trust anchors and performs a signature validation according to EN 319 102-1 using an appropriate validation policy.

Preservation Service (PresS)

The long term retention of signed documents requires a form of safekeeping that ensures the legibility and conclusiveness regardless of the storage medium. In order to ensure the legal validity of electronic signatures and electronic seals over long periods of time one needs to apply appropriate preservation techniques as outlined in ETSI SR 019 510.

The preservation techniques realised by a Preservation Service (PresS) according to Article 34 may involve Evidence Records according to RFC 4998 or RFC 6283 or the continuous augmentation of signatures using archive time stamps according to CAdES or XAdES for example.

Electronic Delivery Service (EDS)

In a paper-based world, the only way to know that a letter indeed has reached the addressee is to send it by registered mail. This is a service offered by the mail service providers. The sender writes down his/her statements on a sheet and puts it into a closed envelope, which is marked with the coordinates of the addressee and sends it by mail. The accountability, confidentiality and integrity of the letter are primarily assured by the author, while the mail service providers primarily warrant availability and correct delivery.

According to Article 44 of the eIDAS-Regulation “qualified electronic registered delivery services shall meet the following requirements:

  • they are provided by one or more qualified trust service provider(s);
  • they ensure with a high level of confidence the identification of the sender;
  • they ensure the identification of the addressee before the delivery of the data;
  • the sending and receiving of data is secured by an advanced electronic signature or an advanced electronic seal of a qualified trust service provider in such a manner as to preclude the possibility of the data being changed undetectably;
  • any change of the data needed for the purpose of sending or receiving the data is clearly indicated to the sender and addressee of the data;
  • the date and time of sending, receiving and any change of data are indicated by a qualified electronic time stamp.”

Given these requirements it is obvious that the EDS needs to utilise a variety of other eIDAS Services such as the eID-Service, the SigS, the TSA, the ValS and the certificate status information provided by the CA.

Exploring the overall potential of eIDAS using the interactive eIDAS-Map

The EDS is a nice example that several basic “eIDAS Services” may be combined to form more comprehensive “eIDAS Services” or “eIDAS-based Transaction Services”, which address application-specific needs. A key aspect of the eIDAS-Regulation is that it harmonises the requirements for electronic identification and trust services across Europe and defines the EU-wide legal effect of notified electronic identification means (cf. Article 6), electronic signatures (cf. Article 25), electronic seals (cf. Article 35), time stamps (cf. Article 41), electronic delivery services (cf. Article 43) and last but not least electronic documents (cf. Article 46).

This means that providers and consumers of services may choose among the large number of qualified trust service providers, which are currently active in the European market as exposed by the interactive eIDAS-TSP-Map released today. This map provides an up-to-date overview of the currently existing trust service providers and trust services across Europe.

The individual benefits of the eIDAS-Regulation – What’s in for you?

What kind of benefits the eIDAS-Regulation provides for you depends on your specific role within the “eIDAS-Ecosystem”. The benefit for providers of “eIDAS Services” is that they now can provide and sell their services across Europe, which gives rise to interesting new market opportunities. The benefit for Users is that they may now use a variety of trust services, with well-defined trustworthiness and legal effect. The probably biggest potential benefit of the eIDAS-Regulation however exists for the emerging “eIDAS-based Transaction Services”, which will be subject of a forthcoming post.

Acknowledgement

We gratefully acknowledge that this post is based on contents developed in the FutureTrust project, which has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No. 700542.

Is your Identity Management ready for the General Data Protection Regulation?

Data Protection

“Data is the oil of the 21st century.” – is a common phrase when topics like Big Data or espionage are discussed. And indeed, the business model of many companies is now based on collecting and analysing user data or behaviour. Not only obvious actors like social networks and search engines, whose goal it is to create exact profiles of their individual users, but also large advertising networks are involved. Those networks use the aggregated profiles on top of their own to deliver – as accurately as possible – personalized advertising to the respective users.

It was thus all the more important to harmonize the general framework for data protection with the General Data Protection Regulation (GDPR) across Europe, in order to ensure an adequate level of data protection for all European citizens. The GDPR has been in force since 24 May 2016 and will be enforceable by the relevant supervisory authorities beginning 25 May 2018 (i.e. in about one year). On the basis of the GDPR, and with an eye on the ePrivacy regulation (“Regulation on Privacy and Electronic Communication”), which is to be effective with the GDPR in May 2018, national data protection laws, such as the German “Bundesdatenschutzgesetz”, are revised with respect to the GDPR.

In particular, each data processor must be aware that Article 5 (“Principles relating to processing of personal data”) contains explicit accountability, which forces the data controller to be able to prove compliance with the requirements of the GDPR, if necessary, to the supervisory authorities.

Such proof shall, for example, be provided for the conditions laid down in Article 6 (Lawfulness of processing). The central condition here is that the data subject has explicitly agreed to the processing of his or her data for one or more specific purposes. For companies that work with personal data, this means that at the moment of the very first interaction with a new user or customer, it must be ensured that consent to the processing of the data is requested in a manner that complies with the GDPR. Article 7 (Conditions for consent) specifies stricter requirements for consent than those common in current national data protection laws. As a result, companies will probably have to pay more attention than before to a vigorous documentation of the consent and the possibility to revoke a given consent; if the consent is ineffective, and thus the processing of the data of those affected turns out to be inadmissible, heavy fines might quickly be a consequence.

Article 83 (General conditions for imposing administrative fines) defines the amount of fines to be imposed which can reach painful heights quickly. Even with minor violations, if for example no appropriate security measures according to the technological state of the art are implemented, impending fines of up to EUR 10 million, or (for companies) up to 2% of the worldwide annual turnover are possible. In the case of infringements of the central principles of the regulation (in particular Articles 5, 6, 7 and 9) or of the rights of the data subject (Articles 12 to 22), the amount of the fine can be increased to up to EUR 20 million or in the case of companies to up to 4% of the worldwide annual turnover.

A central right for those affected is laid down in Article 17 (“Right to be forgotten”). After a decision of the European Court of Justice, this right was a divisive point in discussions for some time, especially concerning search engines in particular and the internet as a whole. The GDPR guarantees this right in detail in its own article; whereas in the old EU Data Protection Directive, this law was merely part of an enumeration of several with several other rights. Service providers will now have to pay close attention to the requirements of the GDPR, as otherwise the above-mentioned sensitive fines of up to 4% of the worldwide annual turnover can be enforced.

Another challenge for service providers is the right of data subjects to data portability (Article 20). This article stipulates that service providers and data processors must be able to offer each data subject the opportunity to export the aggregated data in a machine-readable format within a reasonable period of time. This right only includes data that was provided by the data subject or generated by her direct actions. An obvious approach for the export of the affected data from the databases of the provider would be to use XML or JSON as machine readable data format.

Especially in historically grown application environments integrating different applications, databases and identities of a user in the context of Article 17 and 20 of the GDRP is a challenge that should not be addressed without support from appropriate experts in this field.

Article 25 is an important achievement of the new GDPR: the principle “Data protection by design and default”. Establishing this principle as one of the central points of the Regulation ensures on the one hand that the measures implemented to protect personal data are state of the art (defined additionally detailed in Article 32, but also on the other hand that the applied measures are proportionate to the level of assurance required to adequately protect the data. The protection need is solely determined by the risk posed to the data subject by processing relevant personal data. For the data processor, this means that he has to change the perspective when conducting a data protection specific risk analysis (compared the classical information security management (ISMS) approach). Therefore the mere reuse of the risk analysis that has already been done for an ISMS might not be sufficient in the context of the GDPR.

What “Data protection by design and default” means in the area of identity management can be explained by the example of the innovative SkIDentity service: SkIDentity supports the management of digital identities through the introduction of a privacy friendly single sign-on for enterprises and authorities. By leveraging state-of-the-art technologies, users can create Cloud Identities (CloudIDs) from their identity tokens (such as national identity cards) or other identity sources. Through its CloudID, a user always retains full control of her identity data, as the CloudIDs are not stored centrally on a server, but in a decentral manner on a device of the user’s choice. A user can easily transfer a CloudID created on PC to other devices (for example a mobile phone) and thus also use it in a mobile environment. Due to the decentralized storage of the CloudIDs, the deletion and blocking of each CloudID is completely in the hands of the user and the risk of identity theft through successful attacks on a central infrastructure is significantly reduced.

Within SkIDentity, the principles of Privacy by Default and Privacy by Design have not only been taken into consideration, but have also been seen as essential design criteria and core themes of the service. Thus, Article 25, which is undoubtedly among the most important aspects of the new regulation, was already lived and implemented in SkIDentity even before the creation and publication of the GDPR.

This approach has not only been acknowledged with a number of international awards, but is also in particular reflected in the successful certification procedures based on the “Trusted Cloud Data Protection Profile” and ISO 27001 based on IT baseline protection (of the German Federal Office for Information Security, Bundesamt für Sicherheit in der Informationstechnik, BSI), which in turn complies with the requirements of Article 25 and 32, especially in the case of order data processing pursuant to Article 28.

State-of-the-art protection (Article 32) is a widely interpreted concept, in particular taking account of the existing international standards and regulation for example from the BSI. Through deep knowledge of the relevant international standards and the active creation and maintenance of various technical guidelines on behalf of the BSI, ecsec GmbH is your competent partner for questions about the current state of the art and efficient implementation of effective security solutions. For a secure login to Cloud and Web applications, the BSI published the recommendations “Security Recommendations for Cloud Computing Providers” and “Cloud Computing Compliance Controls Catalogue (C5)”, which recommend the use of strong authentication mechanisms with at least two factors.

Galactic praise for the German electronic Identity Card (“Personalausweis”)

eID

In order to discuss the draft of a “Law for the Promotion of Electronic Identification” (BT-Drs. 18/11279) on Monday, April 24, 2017, an apparently widely perceived¹ hearing of the Committee for Internal affairs of the German parliament (“Bundestag”) took place. Everybody who was not able to be in Berlin on this memorable day, can see the recording of the expert hearing in the media library of the Bundestag. For those who do not wish to view the entire meeting, we have provided the most interesting section here:

Dr. Constanze Kurz, the spokeswoman of the Chaos Computer Club explains the following about the German electronic ID card:

“The basic concept of its technical nature is complex and certainly difficult to understand for the ordinary citizen who now gets this activated chip, but of course very well designed and a good solution.”

We always knew it! There is nothing more to say. It is an open question whether the eID function of the ID card still needs legal support after this most likely largest possible galactic² praise.

¹ As explained in the FAQ, the Chaos Computer Club „is a galactic community of creatures, regardless of age, gender and descent, as well as social status“.

² See e.g. ZEIT, Focus, NETZPOLITIK, Berliner Zeitung, Frankfurter Rundschau, Heise, Kommune21, eGovernment-Computing, Computer Base