Analysis and comparison of identi cation and ...Master Thesis Analysis and comparison of identi cation and authentication systems under the eIDAS regulation Author: Floris Roelofs

Master Thesis

Analysis and comparison of identificationand authentication systems under the

eIDAS regulation

Author:Floris RoelofsS1029871Supervisor:Prof. Dr. Eric VerheulSecond evaluator:Prof. Dr. Bart Jacobs

Institute for Computing and Infor-mation Sciences, Radboud University,Toernooiveld 212, 6525 EC Nijmegen,NL

October 13, 2019

CONTENTS

Contents

1 Introduction 31.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Methods 52.1 Criteria pre-analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Description of systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Selection of criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 Comparisons and insights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Context 73.1 eIDAS - electronic IDentification Authentication and trust Services . . . . . . . . . . 7

3.1.1 European law . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.2 Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.1.3 Notification and assurance levels . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.1 Federated versus non-federated authentication . . . . . . . . . . . . . . . . . 93.2.2 Supporting standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 PKI - Public Key Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Description of systems 114.1 Belgium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.1 Belgian eID Scheme FAS / eCards . . . . . . . . . . . . . . . . . . . . . . . . 114.1.2 Itsme R© . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Germany . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2.1 German eID based on Extended Access Control . . . . . . . . . . . . . . . . . 13

4.3 Luxembourg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3.1 Luxembourg national identity card (eID card) . . . . . . . . . . . . . . . . . . 154.3.2 Luxtrust - alternative methods . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4 Estonia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4.1 Estonian eID Scheme: ID card / RP Card / Digi-ID / e Residency Digi-ID /

Diplomatic Identity Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4.2 Mobiil-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5 Spain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.5.1 Documento Nacional de Identidad electronico (DNIe) . . . . . . . . . . . . . 204.5.2 Cl@ve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6 Italy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.6.1 SPID - Public System of Digital Identity . . . . . . . . . . . . . . . . . . . . . 224.6.2 Italian eID based on National ID card (CIE) . . . . . . . . . . . . . . . . . . 24

4.7 Croatia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.7.1 National Identification and Authentication System (NIAS) . . . . . . . . . . 254.7.2 NIAS - alternative authentication means . . . . . . . . . . . . . . . . . . . . . 26

4.8 The Netherlands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.8.1 DigiD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.8.2 DigiD Hoog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Criteria for comparison 305.1 Usability - service provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.1.1 Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.1.2 Usage with private service providers . . . . . . . . . . . . . . . . . . . . . . . 30

5.2 Usability - user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1

CONTENTS

5.2.1 Authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2.2 Single-sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2.3 Availability of other qualified trust services . . . . . . . . . . . . . . . . . . . 315.2.4 Accessing past authentication information . . . . . . . . . . . . . . . . . . . . 31

5.3 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.3.1 Privacy hotspots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.3.2 Pseudonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4.1 Security of Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.4.2 Vulnerability to ‘Man in the browser’ attacks . . . . . . . . . . . . . . . . . . 33

6 Comparison 346.1 Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2 Usage with private service providers . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3 Authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.4 Single-sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.5 Availability of other trust services . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.6 Accessing past authentication information . . . . . . . . . . . . . . . . . . . . . . . . 406.7 Privacy hotspots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.8 Pseudonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.9 Security of communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.10 Vulnerability to ‘Man in the browser’ attacks . . . . . . . . . . . . . . . . . . . . . . 44

7 Insights 457.1 Chapter outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2 Insights per criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2.1 Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2.2 Usage with private service providers . . . . . . . . . . . . . . . . . . . . . . . 457.2.3 Authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2.4 Single-sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2.5 Availability of other trust services . . . . . . . . . . . . . . . . . . . . . . . . 467.2.6 Accessing past authentication information . . . . . . . . . . . . . . . . . . . . 467.2.7 Privacy hotspots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.2.8 Pseudonyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.2.9 Security of communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.2.10 Vulnerability to ‘Man in the browser’ attacks . . . . . . . . . . . . . . . . . . 47

8 Discussion & Conclusion 488.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.3 Further research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

2

1. INTRODUCTION

1 Introduction

1.1 Background

Throughout Europe governments are in the process of making themselves digitally available totheir citizens. In 2014 the European Union passed Regulation 910/2014, also known as the eIDASregulation, which set the goal for all digital governmental services to be interoperable and usable bycitizens of other member states. In order to achieve this, the Union has requested the member statesto create their systems individually, and created a framework that will link all these systems. Thishas resulted in some vastly different methods of creating such systems, which has created hurdlesin the way of reaching interoperability, such as differing levels of security required for using thesystems.

An example of such an aspect that the varying implementations differ in, which causes difficultiesin the interoperability of the systems, is whether the system is federated or direct. Federated beingthat there is a usually centralised system which handles the identification and authentication, anddirect meaning that there is no such party between the user and the organisation to which they areidentifying. The reason for choosing a direct system is that there is no single actor that can knowabout all the authentication actions of a user. If one entity were to handle all authentications foreverything from contact with a municipality to handling medical information, this entity could havecontrol over an extremely privacy-sensitive data set, if no other measures against this are in place.For this reason some European countries, such as Germany, have chosen for a direct authenticationmodel. On the other hand, a federated system is much simpler to use for service providers, as theydo not need to worry about the authentication and all overhead that comes with it. Belgium isamong states that have chosen for a federated model. Of course, even among countries that havemade the same choice, federated or direct, there can still be vast differences in structure.

1.2 Goal

This will be an exploratory research into the many differences between the implementations ofthe identification and authentication systems of various European member states. Based on thesedifferences a comparison of the systems will be made, and the reasons that led to these differenceswill be discussed. The focus will be on three aspects of the systems; privacy of the user, securityof the system and usability for both citizens and the service providers, what these aspects entailregarding this research will be described in chapter five. The results of this comparison and theanalysis of the differences will lead to possible recommendations for future implementations andimprovements to identification and authentication systems.

1.3 Scope

Throughout the Union countries are in various states of production of their systems. Once a memberstate has finished developing their system they can ask the Union to review the system and assessit on quality and security requirements laid out by the eIDAS regulation. Once a system has beenreviewed and deemed acceptable the Union is ‘notified’ of the system, meaning other member statesneed to ensure their government services are available through that system within twelve months.The systems are reviewed and accepted through a peer review process performed by other memberstates, coordinated by what is called the ‘Cooperation Network’.

For this review we will be focused on systems that allow at least citizen to government authentication,systems that are only meant for businesses to government or citizen to business authentication willbe deemed out of scope. Included in the research will be all systems from countries that havecompleted notification of at least one system at the start of this research, on February 1st 2019 [13].This will include all notified and non-notified systems of member states, as long as the member state

3

1. INTRODUCTION

had at least one system notified on the cut-off date. Non-notified systems from the selected statesare included as well, as the non-notified systems can be a key part of the user experience for theauthentication process in those member states. As this research is performed by a Dutch student ata Dutch university, the Dutch system will also be included for ease of access and for the possibility tomake recommendations for the Dutch system. The Netherlands is currently still in the developmentstage for a citizen to government authentication system that will match the requirements laid outby eIDAS, so the system that will be used for the comparison is the current, non eIDAS notified,‘DigiD’ system. The full list of included member states is as follows:

• Germany

• Estonia

• Spain

• Croatia

• Belgium

• Luxembourg

• Italy

• The Netherlands

1.4 Research questions

With the goal and the scope laid out, the following three research questions have been formulated,as well as two sub-questions to further specify the answers expected to the third research ques-tion.

1. Which characteristics or criteria can be identified as key differences to the identification andauthentication systems of the various member states?

2. How do the selected systems and member states rate and compare according to the definedcriteria?

3. What recommendations can be made for existing and future identification and authenticationsystems based on these discoveries?

(a) What recommendations can be made for the upcoming Dutch system?

(b) What recommendations can be made for identification and authentication systems undereIDAS in general?

4

2. METHODS

2 Methods

2.1 Criteria pre-analysis

In order to get an idea of what qualities identification and authentication systems are being judgedon, a selection of requirements was made from EU implementing regulation 2015/1502 [16], whichholds the requirements which all notified systems under eIDAS should adhere to. Alongside re-quirements from regulation 2015/1502, requirements from a document intended for parties applyingto produce a private alternative authentication system for The Netherlands, defined by the DutchMinistry of the Interior [11] were also taken into account.

Among the two extensive lists all requirements pertaining to the privacy, security and usability of thevarious implementations were selected. From this subset, requirements that provide little room forinterpretation were discarded, as these are expected to be implemented well in all implementations.The resulting list was used as guidance while describing the various systems, and while selecting thecriteria the systems are compared on.

2.2 Description of systems

The systems are described based on the available documentation provided to the eIDAS CooperationNetwork, as well as provided by the government and/or responsible authorities through other meanssuch as support documentation for users and/or service providers, GitHub pages if those werepublicly available, and more. Aside from official documentation, if certain information was hard tofind from official sources, tutorial and help videos made by users of the system were also used togather certain information regarding the user experience. Being a Dutch citizen the possibility isavailable to use the Dutch system itself, so information on this system was also gathered throughusing and observing the system from a user perspective. The Estonian government will provideforeigners at request an e-citizenship, one of the six means notified under the Estonian system, thise-citizenship has been successfully requested and used to observe the Estonian system from a userperspective.

These various sources were used to define six key aspects of the systems, starting off with generalinformation on the system such as its status under eIDAS, responsible authorities and requiredtools. The general information is then followed by some information on the Encryption and PKItechnology used in the system, and the authentication process users of the system must follow. Adescription of the software tools that are included with the system is made, including informationon the party that produced it. Information is provided on the authentication model of the system,whether authentication is directly between the user and the service provider or with an identityprovider in the chain. Finally other relevant details to the privacy, security, and usability of thesystem are described, if any. These are usually details that are unique to the system.

2.3 Selection of criteria

Based on the descriptions of the systems, and using the pre-analysis as a guideline, criteria forcomparison were formed. Differences noticed between two systems were checked among all systems,and standout features in systems were taken as handholds. The resulting criteria were divided intothe categories privacy, security and usability. Some criteria could be argued to fit in more than onecategory, in this case this was either highlighted in the description of the criteria, or this resulted ina similar criterion in the other category.

5

2. METHODS

2.4 Comparisons and insights

By referring back to the descriptions of systems all criteria were checked and compiled for each systemand visualised in a set of tables. Where necessary additional explanations and clarifications are givenwith the table, in case the nuances of a systems implementation could not easily be summarised inthe table. During the compilation of criteria some inconsistencies in the completeness of descriptionswere found and corrected. In the insights chapter trends and other notable discoveries related tothe criteria are discussed.

6

3. CONTEXT

3 Context

3.1 eIDAS - electronic IDentification Authentication and trust Services

3.1.1 European law

In 2014 the European Commission published regulation 910/2014. This regulation, commonly calledthe eIDAS regulation, aims to “enhance trust in electronic transactions in the internal market byproviding a common foundation for secure electronic interaction between citizens, businesses andpublic authorities” [14].

Together with implementing regulations 1501/2015 and 1502/2015, these regulations have laid aframework that will enable citizens throughout the Union to authenticate to and communicate witheGovernment services of member states while using an identification service of their own memberstate. For this purpose regulation 1501/2015 lays down technical and operational requirements forthe interoperability framework [15], and regulation 1502/2015 lays down the technical specificationsand procedures required for the national eID systems that are to be used in the interoperabilityframework [16].

3.1.2 Interoperability

How this is being achieved, is by setting a standard for communication between member states’various identification and authentication tools. This includes standards for the types of personal datathe systems must be able to handle and communicate, called the minimum dataset. This minimumdataset is defined in article 11 of regulation 1501/2015, and includes the following attributes, as wellas some additional attributes, shown in italic.

• Current family name

• Current first name

• Date of birth

• Unique identifier

• first and family name at birth

• place of birth

• current address

• gender

In practice the system is structured around a set of nodes set up by every country. If a citizenfrom member state A wishes to identify to the eGovernment of member state B, instead of usingthe identification system of member state B, this system instead hands off to the “eIDAS Node” forcountry A. The citizen then authenticates to the authentication system from his home state, and ifthis succeeds the minimum dataset for the citizen is passed to the system in member state B throughthe eIDAS node.

When the system is fully functional, all member states should have such a node up and running, andconnected to the eGovernment services of all the member states participating in the system.

3.1.3 Notification and assurance levels

In order to ensure the authenticity of the connections to eGovernment portals, the national au-thentication means of the countries that wish to participate in the system have to meet a set of

7

3. CONTEXT

requirements and specifications. These specifications and requirements are laid out in implementingregulations 2015/1501 [15] and 2015/1502 [16].

When a member state believes their authentication means are up to the required standard, andwish for it to become a part of the system, they must request notification of the system withthe European Commission. When this occurs, an entity overseeing the eIDAS network, called thecooperation network, must test and analyse the system to check whether the requirements are met[22]. This cooperation network is a cooperation of the member states of the European Union, staffedwith representatives from every member state. From these member states, a small subgroup will beselected which will be tasked with a peer-review of the system to be notified.

When a member state requests notifications, it also states its assurance level. The assurance level canbe either low, substantial or high, with each level adding an extra set of demands and requirementsthat are set for the system. The peer-review will check the system according to the requirements setfor the selected assurance level. EGovernment services that are connected to the eIDAS network canset a minimum level of assurance they require, to protect their own system. This allows a memberstate to set lower demands for services that are less critical or have less privacy concerns, whereascritical systems or those that handle especially sensitive information can be assured of a high levelof security. This will block services from being used by citizens if they are authenticating using anauthentication system with an insufficient assurance level.

When the peer review is completed, and it has deemed that the requirements for the requestedassurance level are met, the Cooperation network will review the documents and procedures, anddecide whether to publish the notification in the Official Journal of the European Union. After thenotification is published, member states have 12 months to start allowing the use of the notifiedauthentication means to their eGovernment services [14].

3.2 Authentication

According to the Oxford dictionary of English [1], authentication is ‘The action or process of verifyingthe identity of a user or process’. This research is mainly focused on the authentication of users andindividuals. The eIDAS regulation defines authentication as follows: “...an electronic process thatenables the electronic identification of a natural or legal person, or the origin and integrity of data inelectronic form to be confirmed” [14]. In this definition, the term ‘electronic identification’ is used,which is defined as “...the process of using person identification data in electronic form uniquelyrepresenting either a natural or legal person, or a natural person representing a legal person”.

Authentication usually follows after identification, and happens in one of three ways, or a multitudeof those. The first way is by providing some information only the authentic user could know, usuallythis is a secret password or personal identification number (PIN). The second way is by provingpossession of something only the authentic user possesses, this could be anything as long as thepossession is unique to the user, and the party that is being identified to is aware of the exactpossession. Examples of such possessions are smart cards and cellphones. The third way is byshowing something that is unique to the user itself, this can be done by identifying yourself inperson or by recording and providing something that is unique to the user, such as a biometricslike a fingerprint or iris scan. Together these three ways are referred to as authentication factors,and are named knowing, having and being. Generally an authentication is seen as more trustworthyor reliable if more factors were used in the process, for this reason systems that are notified underassurance level substantial or high under the eIDAS regulation require at least two authenticationfactors, whereas under assurance level low only one factor is required [16].

When a persons wishes to use services provided on the internet, often they will need to authenticateto the service provider. Most commonly this occurs using the ‘something you know’ authenticationfactor, when the user visits the service provider for the first time they are asked to register a passwordor PIN, and with every subsequent visit they are asked to provide the same password or PIN inorder to prove they are the same person that registered.

8

3. CONTEXT

3.2.1 Federated versus non-federated authentication

Services that require users to be authenticated have the choice of either handling authenticationthemselves, or relying on a federated authentication mechanism. Under eIDAS the member stateshave to develop an authentication mechanism, and the choice for either federated or non-federatedhas to be made as well. As both methods have their upsides and downsides, both have been employedby differing member states under eIDAS. Federated authentication mechanisms are generally easierto use for the relying service providers, as they hand off the responsibility for the authenticationto the central authority in the federation. The downside however is that all information regardingauthentication to government services within that country will typically pass through that federation,this can create a privacy hot-spot, causing major privacy and security concerns [39].

By making service providers handle the authentication process themselves this possible hot-spot willbe mitigated, but the service providers will gain the additional task of managing and maintainingtheir own authentication system and surrounding infrastructure, such as a helpdesk.

In a federated system the entity known as the identity provider handles account management, usuallystores information about accounts and handles authentications. When a user wishes to authenticateto a service provider, the service provider refers the user to the identity provider, where the user canauthenticate using the account he has with the identity provider. After successful authenticationthe identity provider sends confirmation of this to the service provider, and provides the accountinformation the service provider requires.

3.2.2 Supporting standards

Sharing or federating an authentication service has been common on the internet well before the eI-DAS regulation. This has resulted in a variety of technologies and standards to support in setting upsuch a system. Notable technologies among those are SAML or Secure Assertion Markup Language,and OpenID Connect. SAML and OpenID Connect provide standardised message formats for com-municating about authentication, allowing identity providers to share authentication informationwith service providers, including the personal information, also called attributes, of authenticatedusers. SAML is also embedded in the eIDAS infrastructure, as it is used for the communication witheIDAS nodes [23]. SAML is an open standard, managed by the OASIS consortium and currentlyon version 2.0 [55]. OpenID connect is not directly a part of the eIDAS infrastructure, but somemember states are using it as a tool for their own authentication systems.

3.3 PKI - Public Key Infrastructure

Aside from establishing a standard for authentication, the eIDAS regulation also aims to supportuse and interoperability of various “Trust services”. These trust services include digital signatures,digital timestamps, electronic seals, electronic delivery services and website authentication. Articles21 and up of the eIDAS regulation establish the legal effect and value of these trust services. Forinstance, article 25 of the eIDAS regulation demands that an electronic signature holds the samelegal effect as a handwritten signature [14]. The regulation makes no mention of what exactly anelectronic signature is, or how it should be implemented, aside from demanding they be unique,identifying, can be under the sole control of the user, and is non-repudiable. The same applies tothe other trust services described by eIDAS, there are requirements to their functioning, but not totheir implementation. The preface of the regulation shortly refers to the technology that is currentlywidely used for such trust services; Public Key Infrastructure (PKI).

Public Key Infrastructure is a system that associates individuals with cryptographic certificates.These certificates can be used to cryptographically sign data, proving to the receiver of the datathat it was signed by the owner of the associated certificate. To be sure of the ownership of a

9

3. CONTEXT

certificate, Public Key Infrastructure relies on a chain of trust. Certificates are provided to end-users by certificate authorities (CA), who have signed the end-user certificates with their own CAcertificate. This signature by the CA indicates that they stand for the validity of the certificate.Often these CA’s have also been authorised to hand out certificates by a CA higher in the chain.The highest CA in such a chain is called a root certificate authority. As there is no authority abovethe root CA to attest to the trustworthiness of their certificate, they hold a very fragile position,and should be subject to very high security standards.

PKI is currently widely used for technologies such as smart access cards, encrypted e-mail usingPGP, and encrypted communication on the internet using SSL/TLS. Most authentication schemesof European Union member states that are being or have been adapted to the eIDAS regulation alsomake use of PKI.

10

4. DESCRIPTION OF SYSTEMS

4 Description of systems

4.1 Belgium

4.1.1 Belgian eID Scheme FAS / eCards

The Belgian eID system, officially titled “Belgian eID Scheme FAS / eCards” was officially notifiedin December of 2018, and assigned the assurance level ‘High’ [61]. The system is based around apair of public key certificates, which are stored on a chip on the users national identity card. Thesystem is fully managed and maintained by the Belgian Government, and currently it can only beused to authenticate with government services. Use of the system by a citizen requires ownershipof an ID card, an electronic card-reader and the installation of software that is required for readingthe card and communicating with the authentication service. Aside from owning the ID card, theuser also needs to request the activation of the certificates stored on the card, this is optional andcan be done when requesting a new card or any time thereafter.

Encryption and PKI information The certificates used by the system are X.509 certificates,a set of two X.509 certificates are stored on every Belgian eID card. The certificates include onefor authentication and one for signing. Communication with the eID card occurs using PKCS #11(Public Key Cryptography Standard #11). The card itself is compliant to the ISO 7816 standardfor smart cards [32]. ‘FOD BOSA BG DT’, the Belgian bureau for digital transformation, acts asthe root certificate authority.

Authentication process Authentication within the system starts with the user navigating to theservice they wish to use with their webbrowser. When the user presses the log-in button to initiatethe authentication process, they are forwarded to a general log-in portal that will be the same for allconnected services. There the user selects his preferred authentication method, the system describedhere being one of the options. After the eID method is selected, the log-in portal requests the userto connect a card-reader and input their eID. The user then has to select the correct certificatefrom their eID and enter the corresponding PIN, after which the authentication will be completedand the user will be forwarded back to the service provider they were authenticating to. As thisrequires both the physical card (possession) and a PIN (knowing), there are two factors required toauthenticate.

Software tools The software aiding users in using the Belgian eID means consists of two parts, the‘CSAM’ login portal that help users initiate the authentication process, and the middleware, simplynamed ‘eID middleware’ or ‘eID software’, which handles the authentication process. CSAM iscreated and maintained by a cooperation of six Belgian governmental entities, including the bureaufor digital transformation ‘FOD BOSA BG DT’ and the ministry of the interior. CSAM provides asingle authentication interface for all government services, unifying the process and making it easierfor users to recognise imposter websites. As CSAM handles the authentication for all governmentservices, and because CSAM employs Single-Sign-On authentication, once a user has authenticatedto CSAM he will be able to access all connected services, without having to authenticate to each oneindividually. Aside from facilitating authentication using the national eID means, this portal is alsoused for the alternative Belgian eID system Itsme, and authentication using access codes obtainedthrough other means. A user can request a physical token to generate access codes, or choose toreceive them through other channels such as a mobile app, SMS or physical mail. These access codesare deemed less secure and the use of these options can only be activated after identifying using themore secure eID option. The various access options are divided into several levels of security, andservices that are being identified to can require a minimal level of security, preventing users fromaccessing their service if insufficient means are used.

The software that handles communication with the eID card and the certificates stored within it isan open source solution created and maintained by the Belgian bureau for digital transformationFOD BOSA BG DT. The software allows users to check the certificates on their eID, and when a

11


user selects the eID authentication method in the CSAM portal, it hands the process over to thesoftware. The authentication process follows a challenge-response protocol in which the authentica-tion certificate on the eID is used to sign the response. After the CSAM portal accepts the response,the authentication process is completed.

Federation As in this system the identity management is not handled by a service provider but acentral identity provider, the system is seen as federated. In case the eID is used for identifying withthe FAS, the FAS acts as the sole identity provider, but the system also allows for other entitiesto serve as an identity provider [33]. Belgian law has set a list of requirements to which identityproviders must adhere if they wish to be an identity provider for government services. Services thatbelieve they meet these demands can request recognition, and if this succeeds the service can becoupled to the FAS and it will show up as an option in the CSAM login portal for governmentservices. Currently there is only one service that has completed this process, Itsme by BelgianMobile ID, Itsme will be discussed in depth in the following section.

When a service is coupled, the service will act as an identity provider for the FAS, which will inturn be acting as an identity provider for the service providers the users choose to use. This systemof delegated identity providers makes the identity chain more complicated, which could be causefor security and privacy concerns. The specification for the coupling between the FAS and thethird party identity services is publicly available, and is based on OAuth 2.0 and OpenID Connect[31].

Other relevant details In case a user has lost his ID or had it stolen, a phone number is available24 hours a day that can be called to request a block of the certificates on the ID, to prevent misuseof the card. As only a single authentication action is required to authenticate to every connectedservice, the system is open to a man-in-the-browser attack, in which malware can make transactionsto a service without the user being aware.

After a user has authenticated with their eID, other authentication means can also be tied to theusers’ identity. These can be used as a second authentication factor in place of the eID from then on,but only with service providers that allow the lower level of assurance these means provide. Optionsinclude a mobile application, a hardware token and OTP received via SMS [18]. Some serviceproviders allow even single factor authentication through relying on username and password.

4.1.2 Itsme R©

Itsme is a privately owned alternative authentication system available to anyone that owns a BelgianeID or a Belgian bank account. The system is based around a mobile application, which has usersaffirm their identity using a PIN. Authentication with the app checks whether it is still running fromthe phone it was originally installed on, whether the SIM has changed, and asks the user for theirPIN. The system is managed and maintained by Belgian Mobile ID, a consortium of Belgian banksand cellular network providers. In order to start using the Itsme system the user needs to install themobile application, and prove their identity either by using the signing functionality provided bythe Belgian national eID scheme or by proving their identity at an office of their bank. The schemeis currently in the pre-notification stage.

Encryption and PKI information At the time of writing the Itsme application is closed sourceand there is no technical documentation regarding its functioning publicly available. Regarding thesecurity and integrity check, Itsme states that the application confirms the PIN, SIM card and thephysical device it is running on. The organisation states that they are in ongoing “cat and mousegame” to prevent users circumventing this security by using cellphones that provide ‘root access’ totheir owner, indicating that they are having some trouble with ensuring the authenticity of theirusers [8].

Authentication process The authentication process using Itsme varies depending on the servicethe user is authenticating to. In the case of authenticating to a government service, the process starts

12


off identically to the process described for the Belgian eID Scheme FAS / eCards described above.When attempting to authenticate to a government service, the user is forwarded to the CSAM portal.When the user selects his preferred authentication method, they select the Itsme method instead ofthe eID method. When the method is selected the user is forwarded to an Itsme portal where theuser is asked to identify by providing their cellphone number, after which the authentication processwill continue in the app, where the user provides their PIN. The application will show informationon which service the user is authenticating to. When a user uses Itsme to authenticate to a privateservice provider, the name of the private service provider will be listed. But when authenticating toa government service, Itsme cannot be specific and will tell the user he/she is authenticating to “Theonline government services”. This is because Itsme does not know which government service theuser is authenticating to, and is actually authenticating to all of them due to single-sign-on featureof the government authentication portal CSAM. As the process requires both physical possession ofthe phone and knowledge of the PIN, there are two factors required to authenticate. When the userhas successfully authenticated, the personal information required by the service provider is sent tothem by the Itsme network [9].

When identifying to a private company, such as one of the banks part of the Belgian Mobile IDcooperation, the authentication is similar, but instead of using the CSAM portal the various partic-ipating companies have their own log-in interface, and use their own Itsme implementation insteadof a centralised Itsme portal.

Other relevant details In case a user loses their phone or has it stolen, a malicious user shouldnot be able to use it without the correct PIN. The legitimate owner is also able to block their Itsmeaccount through a phone helpdesk or an online form. To block an account through the online form,the only information that is needed is the phone number and birth location of the owner. Thedataset that identifies the user is stored in the Itsme network and sent to the service providers fromthere, no personal data is stored on the users phone [9]. Logs regarding use of the system by theuser will be stored for up to ten years. The Belgian Mobile ID organisation is certified under ISO27001 [38].

4.2 Germany

4.2.1 German eID based on Extended Access Control

The German eID system, officially titled “German eID based on Extended Access Control” wasofficially notified in September 2017, and assigned the assurance level ‘High’ [61]. The system isbased on a stack of authentication mechanisms, which ensures that only parties that are authorised bythe German government are able to use the system. The data that users can provide to these partiesis stored on a chip in their national identity card. Use of the system by a citizen requires an identitycard which has been activated, a computer with compatible software installed and a cardreader.The cardreader can be either a dedicated device or a smartphone with NFC functionality. Bydesign there is no entity or service overseeing the authentication between the user and the serviceprovider, the users prove their identity directly to the service provider. The authenticity of theinformation provided by users is ensured by the use of public key encryption and signing usingcertificates managed by the German Federal office for Information Management (BSI) [30]. On theother side, certificates are also used to ensure the authenticity of service providers. This mechanismis also used to ensure only authorised service providers can read the eID, as well as restrict accessto certain information stored on the eID, so that service providers can only access the informationthey are authorised to access. The authentication process using this system relies on two factors,with the eID card being something you own, and a PIN being something you know. Most servicesproviders that use the system are government entities, but private entities can also request accessto the system.

Encryption and PKI information For the encryption used by the system, a method has beendeveloped especially for this purpose by the BSI. This method, as the name of the German eID system

13


implies, is based on the Extended Access Control standard. Extended Access control was developedas a security measure to protect biometric data in machine readable travel documents, also by theBSI. EAC relies on a public key infrastructure to ensure the authenticity of both communicatingparties. This process of mutual authentication ensures that only authorised parties with the rightcertificates can request information from the eID, just like how the fingerprint data on a machinereadable travel document can only be accessed using an authorised terminal. The variation on EACused for the eID system is called the General Authentication Procedure and consists of three phases[30].

The firsts phase serves to confirm the user knows the correct PIN for the used eID, for this purposethe PACE protocol is used. Phase two is the mutual authentication phase, this phase uses certificatesand challenge-response mechanisms to prove the authenticity of the service provider and the eIDin three steps. In step one the service provider signs a challenge sent by the eID with a certificateonly available to authorised service providers, this proves the service providers authenticity and itsauthority to access the eID. In step two the eID sends its certificate so that the service providercan confirm its authenticity and encrypt future communications to the user using the certificate’spublic key. In step three the authenticity of the users eID, as well as the possession of the privatekey, are verified using the chip authentication v2 protocol. This protocol also establishes a securetwo-way communication tunnel, using TLS. Then in phase three the access provider can access thedata on the eID according to their specified access rights, which is used to check the validity andrevocation status of the eID [30]. The BSI acts as the root certificate authority for all certificatesused in this process, although different root certificates are used to differentiate between the serviceprovider certificates and the eID certificates.

Authentication process On first use of the system, the user has to activate their ID card withthe use of a ‘Transport PIN’, which was sent to the user through the post. This process requiresthe user to set their own six digit PIN. When a user starts the authentication process with a serviceprovider, the user is asked to open their authentication software. In the software, the user can seewhat information is being requested, and by whom. As the service providers need to be licensedto use the system, this license can also be seen, indicating which personal information the serviceprovider can request and for what purposes they may do this. From this point the user can eitherdeny or accept the request. If the user accepts the information request, they must scan their eIDand provide their PIN, after which the authentication process will be completed and the informationwill be sent to the service provider [34].

The eID can be scanned with either a dedicated cardreader connected to the computer, or witha connected smartphone with NFC functionality. To use a smartphone an application is required,which also needs to be manually linked with the software on the computer that is being used toaccess the service provider, the smartphone also needs to be connected with the same local networkas the computer. When the app and software are coupled, the smartphone can open the connectionwith the press of a button, after which the smartphone can be used like any cardreader.

Software tools The software users require for the authentication process is not directly providedby the German government. The choice was made to not make a single software solution and forceusers to use this, instead a specification is provided, and anyone may make software that can beused for the authentication process. The government does provide a certification process for suchsoftware, and recommends only using certified solutions [30]. Currently, there is only one certifiedsolution, called ‘AusweisApp 2’.

14


AusweisApp 2 is made by the company Governikus Gmbh, which is owned by the local governmentof the German city Bremen. The application is available for Windows and Mac OSX, and also hascompanion mobile applications for iOS and Android. The desktop software can be used for theauthentication process, has a directory of all coupled service providers, an option to see previousauthentications and can be used to change the PIN of the users eID. The companion smartphone appsprovide the same functionality, including functionality to completely authenticate on the smartphone,as well as functionality to use the smartphone as a cardreader for the desktop application [35][36].

Federation In this system the choice was made to implement it without a federation, meaningall identification and authentication communication occurs directly between the citizen and theservice provider. This means all service providers are tasked with maintaining the functionality intheir online service, and the tasks that come with it such as support and certificate maintenance.This overhead has proved to be a limiting factor into adoption by service providers. In order toalleviate this problem, the German government has started allowing service providers to outsourcethe authentication, effectively turning the system into an optional hybrid of federated and directauthentication [28].

Other relevant details Every German eID can provide a pseudonym that can be used to identifyto some service providers, instead of the personal identification data on the card. The pseudonymis cryptographically generated by the eID card and will be unique for every service provider[64].As the pseudonym is bound to the eID and not to the user, when a user receives a new eID theirpseudonyms will also change, with the German eID expiring every 10 years. When used in theeIDAS system, the pseudonym will be unique to each member state, and will be supplied with theminimum dataset [30]. In order to prevent service providers being able to track and monitor theauthentication behaviour of users, the certificates on the eID are also not unique or bound to the useror even the eID card. In practice this means many citizens will share identical certificates.

In case an eID is stolen or the owner loses it, the user can call an emergency phone number to have itdisabled. Using this phonenumber to block the eID also requires knowledge of a “blocking number”that was supplied during the enrolment of the eID. If the user no longer possesses this number therevocation can also be requested at a local government office.

4.3 Luxembourg

4.3.1 Luxembourg national identity card (eID card)

The Luxembourgish eID system, officially titled “Luxembourg national identity card (eID card)”was officially notified in November 2018, and assigned the assurance level ‘High’ [61]. The systemis based around a pair of public key certificates, which are stored on a chip on the users nationalidentity card, which can be read using Near-Field-Communications (NFC) technology. The systemis co-operatively run by both the government of Luxembourg and a public limited company called“LuxTrust”. LuxTrust handles most interactions regarding the authentication system and the publickey infrastructure, whereas the government handles the processes regarding the issuance of theeID cards and the certificates they contain. The government of Luxembourg is one of the keyshareholders for LuxTrust, as well as the Luxembourg national bank and a set of other private andsemi-governmental entities. In order to use the system, a user needs to possess a Luxembourgishidentity document, for which activation of the certificates has been requested, as well as an electroniccard-reader and installed software required for the authentication process.

Encryption and PKI information The exact workings of the encryption and PKI behind theLuxembourg national identity card is kept confidential. According to the peer review report, thecommunication between the identity server and the eID card follows a proprietary version of theChipGateway Protocol [65]. The ChipGateway protocol is an open standard under OASIS, the

15


standard itself is based on the specification for the eID client provided for the German eID imple-mentation and was co-developed by Luxtrust [24].

Authentication process On first use of the eID card, the user must set a 6 to 8 characterslong PIN, which will be required to authenticate from then on. The user must also provide animage on first use of the system, this image will be used as a ‘secret image’ and will be shown tothe user every time they enter their PIN. The authentication process itself starts when the userstarts the authentication process with the service they wish to use, usually on their website. Whenchoosing to authenticate on a website that uses LuxTrust, the user will be forwarded to the LuxTrustauthentication portal. At the LuxTrust authentication portal the user is prompted to select whichauthentication tool they wish to use, among which the eID is one option. The other tools are outof the scope for this section and will be discussed in the section ‘Luxtrust - alternative methods’.When the eID is selected, the middleware for the authentication is opened, which prompts the userto scan their eID with a connected electronic card-reader, if it is not already placed on the scanner.After the eID is identified, the user is prompted to confirm they are using the correct certificate forthe authentication and to enter their PIN. This PIN prompt will also show the users’ secret image,if the secret image does not appear or is different from the one they selected the user should notenter their PIN and cancel their authentication. After the PIN is entered the authentication will becompleted and the user will be sent back to the service provider they were authenticating to.

Software tools Use of the Luxembourgish eID means requires installation of a software packagethat includes two applications, Gemalto Classic Client Toolbox for Luxembourg and LuxTrust Mid-dleware. Gemalto Classic Client Toolbox is a general tool for reading and managing certificates andother information stored on smartcards, the tool can be used to check card contents and changethe PIN. The included version is specific for the Luxembourg eID, but the difference between thisversion and the standard version is not immediately visible. The software is created by Gemalto,who also produce the eID card for Luxembourg. LuxTrust Middleware provides the communicationbetween the authentication server and the users’ eID, and provides the user interface when the userhas to select their certificate and enter their PIN. The software is closed-source and produced byLuxTrust. After installation, unless the user changes this behaviour, the software will be active atall times. This applies to the Gemalto Classic Client Toolbox and LuxTrust Middleware.

Other relevant details Not every service provider that is connected to LuxTrust allows authenti-cation using the eID, some require other means provided by LuxTrust [42]. This not only applies toprivate service provider but also to some governmental service providers.

Recently LuxTrust added the described ‘secret image’ feature, LuxTrust states this was added inorder to comply with new legislation [43]. As the feature was recently added it is not in thedocumentation provided to the cooperation network and has not been reviewed by other memberstates.

Luxembourg does not provide functionality to sign documents or use other eIDAS qualified trustservices, the user documentation and help website however does provide guides on how to use theeID and other LuxTrust means to sign documents using commonly used text editing software [44].LuxTrust also provides services to businesses as a provider of qualified trust services, includingelectronic signatures, timestamping, sealing and SSL certificates, but not regularly to users of theLuxembourg national identity card.

4.3.2 Luxtrust - alternative methods

Aside from using the eID as a means of authentication, the Luxembourgish authentication serviceLuxTrust also provides access to Luxembourgish services using the following other means:

• Smartcard

• Signing Stick

16


• Hardware token

• LuxTrust Scan

• LuxTrust Mobile

Although the means are all provided by LuxTrust, they can not all be used for authentication withevery service, some service providers have opted out of allowing certain means [42]. LuxTrust hasshown no intention of having these means notified under eIDAS. Regarding the functionality of thedevices, they can be divided in three groups, the functionality and other details will be explainedper group. All of these devices are used as a ‘having’ authentication factor.

All LuxTrust authentication means share the same initial steps to start the process, these steps areas follows:

1. The user uses their browser to visit a service providers’ website

2. The user chooses to log-in, upon clicking the button they are forwarded to the LuxTrustauthentication portal.

3. The LuxTrust authentication portal shows the means that can be used to access the visitedservice provider, the user must click the one they wish to use.

4. After clicking the correct authentication method the means specific authentication process isinitiated.

The means specific steps will be described in the following sections, aside from the steps for the eIDmeans as this was explained in its own section.

Hardware token The hardware token is a small physical device with a button and a screen. Whenthe button is pressed the screen will show a One-Time-Password for use with authenticating. Tostart using a token a user must buy it from LuxTrust and pair it with his account, LuxTrust willpair it with a trusted certificate managed by them.

After the authentication process is initiated as above, the user is asked to provide their LuxTrustusername and password. After the username and password are entered correctly, the user is askedfor a One-Time-Password, to be generated by the token. The screen asking for the OTP will alsoshow the users’ secret image, an image the user has shared with LuxTrust previously, the user mustconfirm the image matches the image they shared previously or abort the authentication process.To generate the OTP the user must press the button on his token and then copy it from its screen.After successful entry of the OTP the authentication is complete and the user will be forwardedback to the service provider they were accessing.

LuxTrust Scan & LuxTrust Mobile LuxTrust Scan and LuxTrust Mobile provide OTP in amanner quite different from the token, the method is the same for these two methods. LuxTrustScan and the LuxTrust mobile app rely on reading a QR coded provided during the authenticationprocess, and will generate an OTP based on the data in the QR code. LuxTrust Scan is a dedicateddevice featuring a camera and a touchscreen that can do no more than read QR codes and generateOTPs. LuxTrust Mobile is a mobile application for iOS and Android that provides the exact samefunctionality.

After the authentication process is initiated as above, the user is asked to provide their LuxTrustusername and password. After the username and password are entered correctly, the user is asked fora One-Time-Password and shown the QR code needed to generate it. The user must then scan theQR code with their Scan device or Mobile application, and enter the OTP the device will generate.After successful entry of the OTP the authentication is complete and the user will be forwardedback to the service provider they were accessing.

Smartcard & Signing stick The smartcard and signing stick are qualified electronic signaturecreation devices that function similarly to the eID. The main difference between the smartcardand the signing stick is that they are not under the direct responsibility of the Luxembourgish

17


government. There is also a difference in the way the devices are connected, where the eID can beread using NFC technology, the smartcard requires a different kind of cardreader that makes contactwith contactpoints on the chip. The signing stick does not require a reader at all and can simplybe inserted into an available USB port. The software used and the authentication process usingthese two devices are entirely identical to that of the Luxembourgish eID, described in a previoussection.

4.4 Estonia

4.4.1 Estonian eID Scheme: ID card / RP Card / Digi-ID / e Residency Digi-ID /Diplomatic Identity Card

The Estonian eID systems; ID Card, RP card, Digi-ID, e-Residency Digi-ID and Diplomatic Identitycard were officially notified in November of 2018, and assigned the assurance level ‘High’ [61]. Dueto the similarity of the functioning of these systems they will be described as if they were a singlesystem from here on. In the documentation provided to the eIDAS Cooperation network a sixthsystem “Mobiil ID” is also included with these systems, but as the functionality of that system issignificantly different it will be discussed in a separate subsection.

The Estonian eID system is based around a pair of public key certificates which are stored onthe chip of the various cards of the system. The system is fully managed and maintained by theEstonian government, with some tasks being outsourced to the private company Idemia. The systemcan be used to authenticate to both eGovernment services and private service providers includingbanks, hospitals, universities and many more. Use of the system by a citizen requires ownership ofone of the various cards, such as an ID card or an e-Residency Digi-ID, an electronic card-readerand the installation of software that is required for reading the card and communicating with theauthentication service [58].

Encryption and PKI information The system relies on two user bound X.509 certificates forthe authentication and signing, one for each purpose. Communication with the certificates onthe card occurs using PKCS #11, and the authentication process follows the SSL/TLS protocol.The card itself is compliant to the ISO 7816 standard for smart cards. The Estonian governmenthas contracted the private company ‘SK ID Solutions AS’ to act as the root certificate authority[56].

Authentication process The start of the authentication process requires the user to insert his IDcard or other relevant card into a card reader, and the card reader into his computer. Then whenthe user browses to a service provider and chooses to authenticate, the browser will ask the user toselect a certificate for the authentication. After the certificate choice is confirmed, the user is askedto enter their pin for the selected certificate. Upon correctly entering the PIN, the authenticationcompletes and the user is able to access the service provider.

Software tools The Estonian government provides a suite of software tools for use with the system.Core to the suite is the DigiDoc4 software, which acts as the management tool for the ID cards andprovides signing and encrypting functionality. Paired with DigiDoc4 comes a tool that providesfunctionality for another eIDAS trust service, timestamping with TeRa Client. These two tools areavailable for Windows, Mac OSX and Linux. The final member or members of the suite are thebrowser extensions that allow use of the signing functionality within the browser, these extensionsare available for Internet Explorer, Edge, Mozilla Firefox and Google Chrome.

DigiDoc4 was created by the Public company Aktors on behalf of the Estonian Information SystemsAuthority, the software is open source and published under a Lesser GNU General Public Licence[27]. The system allows users to check their certificates, set the PIN individually for both certificatesand set the PUK code. Aside from these management functions, the software can sign documents,and check the signature information of signed documents, encrypt and decrypt documents. The

18


signing functionality packages the document to be signed in a standard ASiC-e container for signeddocuments, the DigiDoc4 client can also be used to check the signature information. The encryptionfunctionality requires the user to select one or more recipients, after the encryption only theserecipients will be able to decrypt the document using their personal certificates.

Federation Authentication using this system uses direct communication between the service providerand the citizen and their identification document, there is no federation handling the authenticationfor the service providers. Due to this, single-sign-on is not an option and users are required toauthenticate separately to each service provider they wish to use.

Other relevant details The system also functions when using an ID-card issued by neighbouringcountries Finland and Latvia. The ID-card keeps track of how many authentication actions havebeen taken with the card, helping users detect possible malicious use of the card. The system hasa very low implementation effort for service providers that wish to allow authentication using thesystem, as the required functionality is present in widely used web server software such as Apache,IIS and NGINX [25]. In 2017 a flaw was found in the method by which the keys for certificates in theEstonian identity cards were generated, this flaw meant that the private keys of certificates could becalculated from the public key in a feasible amount of time. Worldwide an estimated 1 billion chipswere affected, among them around 800,000 used in the described Estonian eID cards. The Estoniangovernment required everyone with an affected identity document to renew their certificates, whichcould be done from home. Certificates that were not renewed would be revoked a few months later.The Estonian government states there are no recorded cases of identity theft due to this incident[26]. In the wake of this event Estonia opted not to renew their contract with Gemalto, whowere producing the identity documents before this incident, and switched to the French companyIdemia.

4.4.2 Mobiil-ID

The Estonian government also provides an optional cellphone based authentication mechanism,called Mobiil-ID. The same entities of the Estonian government that are responsible for the card-based systems are responsible for Mobiil-ID [59], and like the card-based systems Mobiil-ID is alsonotified under eIDAS with the assurance level high [61]. The system is similar to these card-basedsystems, but instead of storing the certificates on an identification document they are stored on aSIM card. This SIM card acts as the second “possession” factor instead of the ID. In order to use thesystem a citizen must request a supported SIM card from their cellular provider, and then activatethe certificates on the card using their ID or equivalent card. Use of the card is similar to that ofthe other Estonian systems, but instead of inserting the eID into a card reader and providing theirPIN on the same computer as is being used for accessing the service provider, a mobile phone isused for reading the card and entering the PIN [60]. One added security feature that is providedin this system but not when using one of the card-based Estonian systems, is that Mobiil-ID willprovide information as to what service provider the citizen is authenticating to. Before entering theirPIN, the user is also shown a randomly generated control number on both the website of the serviceprovider and on the cellphone, the user must make sure these match. This is another measure tohelp the user detect possible malicious behaviour.

The authentication process also has a key difference with the card-based systems on the back-end.The authentication process is no longer handled by the service provider, but instead handled by anAPI that only provides confirmation to the service provider. This step seems to be taken becausea separate connection needs to be made with the SIM of the user. This has effectively turned thissystem into an identity and authentication federation.

19


4.5 Spain

4.5.1 Documento Nacional de Identidad electronico (DNIe)

The Spanish eID system, officially titled “Documento Nacional de Identidad electronico (DNIe)”,was officially notified in November of 2018, and assigned the assurance level ‘High’ [61]. The systemis based around a pair of public key certificates, which are stored on a chip on the users nationalidentity card. The system is managed and controlled by the the General Secretariat of DigitalAdministration in the Ministry of Finance and Public Function, and the information on the identitycard is provided and validated by the national police [53]. The system can be used to authenticateto government services, and to electronically sign documents. Use of the system by a citizen requiresownership of an ID card, an electronic card-reader and the installation of software that is requiredfor reading the card and communicating with the authentication service [19]. The cardreader canbe either a dedicated device or an NFC enabled Android smartphone. Aside from owning the IDcard, the certificates on the card must also be active in order to use the system, the certificates canbe disabled at the request of the user, are automatically revoked when the card expires, and whenthe certificates themselves expire. The certificates will expire 60 months after enrolment, so mostusers will need to reactivate their certificates once in the lifetime of their eID [19].

Encryption and PKI information The system uses a similar certificate set-up as member statesmentioned previously, with the eID containing different certificates for two purposes, authenticationand signing. The national police acts as the root certificate authority. The function, storage andmany other functions of the eID are compliant to various relevant international standards, such as,ISO 7816 and ISO 14443, PKCS #15 for the file system on the card, establishment of a securecommunication channel according to the EN 419212-1:2014 standard, which achieves mutual au-thentication, and a combination of RSA, AES, DES and SHA256 for the various cryptographicalcomponents [53].

Authentication process The authentication process starts with the user choosing to authenticatewith DNI on a supported website. In order to start the process, the user must already have connecteda card-reader and have placed his card in it. When the DNI method is selected, immediately a pop-up will appear asking which of the certificates on the card the user wishes to use. After selectingthe correct certificate, the user is prompted for his/her PIN, and after the PIN is correctly enteredthe authentication process is complete. With the authentication requiring something the user knows(an 8 to 16 digit PIN) and something the user possesses (the eID) the authentication requires twofactors.

Software tools The system does not include a software package that provides a user interface forthe authentication or the management of their certificates. The only necessary software is a driverthat allows the cardreader to read the eID. All user interaction is provided by existing certificatehandling functionality in the operating system and web browser the user chooses to use. The driversare available for Windows, Mac OSX and Linux. The choice of browser that the user can use withthe system is limited to Google Chrome, Mozilla Firefox and Internet Explorer.

If choosing to use an Android smartphone as the cardreader instead of a dedicated device, installationof software called DNIeRemote is required on both the smartphone and on the computer. Afterinstallation the software can connect either through USB or Wi-Fi. The software only provides onefunctionality, and that is reading the eID, in this case the smartphone is also used for entering thePIN [20].

To sign documents using the eID, the Spanish government also provides a software solution. Thissolution is called AutoFirm@ or AutoFirma. Autofirma is an open source tool that is providedand maintained by the Centre for Technology Transfer and Innovation [10], which is overseen by theMinistry for Territorial Administrations. The tool allows users to select a compatible document, suchas a PDF file, select a location to show the signature in the document and then select the certificateto use for the signature and enter the required PIN. After following these steps the document will be

20


signed and can be to sent to a government service that requires it, or any other relevant party.

Federation Authentication using the DNI uses direct communication between the service providerand the citizen and his/her eID, there is no federation handling the authentication in-between. Dueto this, single-sign-on is not an option and users are required to authenticate separately to eachservice provider they wish to use.

Other relevant details Certain management tasks such as refreshing the certificates or changingthe PIN can not be done from home, but must be done at certain offices of the local governmentor at a “DNI Update Point” [19]. The Spanish eID cards were affected by the same vulnerabilityas described with the Estonian system, this led to the Spanish government revoking the certificatesfrom 17 million cards [26] [45].

4.5.2 Cl@ve

Cl@ve or Clave, is an alternative authentication system available for use with digital governmentservices in Spain [2]. Use of the system requires the user to first register using the aforementionedDNI authentication method, as well as a mobile phone-number, which will be used to send codesto use as a second authentication factor. It is also possible to register for Clave at a registrationoffice, or online with an invitation letter, these methods however are seen as a less secure and willprovide access to fewer services. Clave, just like DNI, is managed and controlled by the the GeneralSecretariat of Digital Administration in the Ministry of Finance and Public Function. Spain hasshown no sign it intends to notify the Clave service.

Encryption and PKI information This system relies on the DNI system and in-person identifi-cation to authenticate newly registered users. After registration the system functions as any otherusername and password authentication service, so there are no additional communication steps withphysical tokens or PKI systems.

Authentication process There are three ways Clave allows users to authenticate, authenticationusing only a password, using only a one-time-password sent via SMS or a mobile application, orusing a password and a verification code sent via SMS [12].

The one-time-password method is only available to users that have not used DNI to register with thesystem, and only for certain services that require a lower level of security. When one has enrolled forthis method and wishes to use it to authenticate online is simple. To start the authentication process,the user selects authentication with Cl@ve PIN. The user is then prompted to fill in the number oftheir DNI, or if they do not possess this, their tax identification number (NIE). Together with thisnumber the user selects whether they wish to receive their one-time-password through the app orthrough SMS. If the user selected receiving through the mobile application, the user then receives twocodes, an identifier and a password. When these codes are successfully entered the authenticationis complete. If the user selected receiving through SMS, the user is then asked to enter eitherthe identification number and expiry date of their DNI, or the identification number and ‘supportnumber’ of their NIE. The one-time-password will be sent to the phone-number linked to thatidentity. If the user successfully enters the one-time-password within ten minutes the identificationwill be complete.

The authentication method using only a password is quite straightforward, it functions just likeany other username/password system, with the username being either the unique identifier of theusers DNI or their NIE. The two factor password and verification code option is an extensionof this method, and it is set as the minimum security standard for some services, meaning theaforementioned Clave authentication methods will not be available. With the two factor option,after successfully entering the identification number and password, the user is sent a verificationcode through SMS, and after entering this the authentication is complete.

Federation Clave identifies itself as a federated authentication management system [12], steppingin as a central identity provider between various governmental service providers and the citizens

21


using these systems. In this role the Clave system is also integrated with the eIDAS framework,handling authentication information from European citizens wishing to authenticate using theirnational authentication means [3].

Part of the system makes it so users only need to sign in once if they wish to use multiple services thatare part of the federation, also known as single-sign-on. Although this is positive for the usabilityof the system, this opens the systems and its users to attacks on multiple services when signing onto a single website so it is not positive for the security of these systems.

4.6 Italy

4.6.1 SPID - Public System of Digital Identity

The Italian eID system, officially titled “SPID - Public System of Digital Identity”, was officiallynotified in September of 2018, and assigned the assurance levels ‘Low’, ‘Substantial’ and ‘High’ [61].The system provides multiple authentication methods, which allow access to services at differentassurance levels, this includes one method at assurance level low, two methods on assurance levelsubstantial and one method at assurance level high. The Agency for Digital Italy is responsible forthe eID scheme. The system provides access to over 700 service providers, both public and private.Depending on the method used, some tools are required to use the system, multiple methods requireusing a either mobile phone or a time-based security token, and the high assurance method requireseither a hardware token, a smartcard and cardreader or some other device or service holding atrusted certificate [6]. Use of the system also requires signing up with one of the SPID providers,currently there are nine possible identity providers to choose from, which are recognised as separateeID means under eIDAS [61]. These are the following companies;

• Aruba PEC SpA

• Namirial SpA

• InfoCert SpA

• In.Te.S.A. SpA

• Poste Italiane SpA

• Register.it SpA

• Sielte SpA

• Telecom Italia Trust Technologies S.r.l.

• Lepida SpA

Encryption and PKI information The SPID allows use of multiple differing methods of au-thentication, only one method makes use of certificates and PKI, aside from setting up the HTTPSconnection with the users web browser, which occurs with all methods. SPIDs most secure authen-tication option relies on a pair of X.509 certificate, which can be stored on a variety of devices suchas smart cards and hardware security modules. The knowledge and possession of the private key ofthe certificates is tested using TLS client authentication.

Authentication process The SPID recognises three levels of security in their methods of authen-ticating. The user does not decide which level of security to use while logging in, the only optionis always the minimum security level required for the selected service provider. On level one is asimple username and password system, to use this on a supported service provider a user must selectthe option to enter using SPID, and then select the identity provider the user wishes to use. Uponthe selection the user will be forwarded to the authentication system of the selected provider, wherethey will be prompted for their username and password. When those are entered correctly, the userwill be informed of which data will be sent to the service provider, and is asked to confirm this to

22


complete the authentication and be sent back to the service provider’s website. Security level onein SPID corresponds to assurance level low in eIDAS.

Security level two includes two similar methods, relying on a username, password and one-time-password (OTP) from the user. The difference between the two methods is that in one the OTP issent via SMS, while in the other it is generated in a mobile application. The start of the process is thesame for both methods, as well as for the level 1 method. The user navigates to a service provider,selects the option to enter with SPID, and selects his preferred identity provider. The user will beforwarded to the authentication system of the selected provider, where they will be prompted fortheir username and password. After this is completed, the user is prompted for their current OTP,which has either been sent to them by SMS, or they must generate from their mobile application,accessing the mobile application requires a PIN. When the OTP is entered correctly, the user will beinformed of which data will be sent to the service provider, and is asked to confirm this to completethe authentication and be sent back to the service provider’s website. The documentation for thesystem provided to the Cooperation Network also describes a system where the OTP is sent througha phonecall, but none of the Identity Providers have implemented this. Security level two in SPIDcorresponds to assurance level substantial in eIDAS.

Security level three includes a variety of methods that depend on username, password and a trustedcertificate. These methods can use trusted certificates stored in various ways, service providers sellphysical tokens containing a certificate that can be used, but the certificate stored on a users eIDor on their health insurance card can also be used, and there is support for certificates stored ona managed hardware-security-module. The authentication process is similar to the processes onsecurity level one and two, but after the username and password are successfully entered the useris prompted to select their certificate, which they have loaded in the manner relevant to the devicethey are using to store it, and enter the corresponding PIN. Security level three in SPID correspondsto assurance level high in eIDAS.

Software tools SPID supports a multitude of identity providers, and has defined requirements formobile applications on Android, Apple iOS and Windows Phone. This combination of factors hasresulted in a variety of mobile applications that can be seen as part of the system, as every provideruses their own proprietary application. From the nine identity providers, four have created apps fortheir users to generate OTPs, while the other five only provide OTP’s via SMS. The four providersthat have constructed mobile applications for their users have all opted to provide them for Androidand Apple iOS, there is currently no identity provider offering a Windows Phone application. Thefunctioning of the security mechanism and the OTP generation is defined by the Agency for DigitalItaly [6]. The OTP generation is time based and is generated from a seed that is shared with theuser’s device through SMS at first time setup.

Federation As mentioned before, SPID runs a federated model where the user can choose from nineseparate identity providers, and can also choose to use more than one identity provider. Communica-tion between the user, the service provider and the identity provider occurs according to the SAML2.0 standard, using the ‘Web Browser SSO’ profile, in which all communication passes through theuser and the authentication process is initiated from the service provider’s platform [5]. Becomingsuch an identity provider is controlled by the Agency for Digital Italy and requires the company toadhere to a list of requirements and be certified for ISO 27001 and ISO 9001, the implementationof these requirements and certificates are checked during an accreditation by the Agency for DigitalItaly when an identity provider becomes part of the system, and conformity is checked again everytwo years [6]. After an identity provider is accepted into the federation, it will also need to passthe requirements related to the eIDAS regulation in order to be notified and provide authenticationservices across the Italian border.

Other relevant details Security level one allows for Single-Sign-On functionality, meaning thatafter a successful authentication on security level one, the user will no longer need to authenticateto other service providers which require only security level one for the following thirty minutes.In contrast to other described systems, identity proofing for enrolment in this system is possible

23


through online video chat. This was seen as something that could not be permitted in a systemwith a ‘High’ assurance level by the peer reviewers of the eIDAS cooperation network, to which theresponsible parties stated that they would remove the possibility. It is currently still possible withsome service providers, including one that provides the highest level of security [7].

Another aspect the peer reviewers were troubled by with the SPID system was the possibility to usean authentication method relying on OTP sent through SMS at the assurance level high. Due to thelow security of mobile networks, the trust in such networks and methods relying on them has fallen.In the United States of America for instance the National Institute of Standards and technologyhas defined methods relying on public switched telephone networks (PSTN) to be ‘restricted’, andthat any entity should take extra care when relying on it, citing its vulnerability to “device swap,SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authentication secret.” [37]. As is reflected in the authentication methods section of thisdescription, this feedback was implemented and the SMS based authentication method was relegatedto the assurance level substantial.

4.6.2 Italian eID based on National ID card (CIE)

The Italian eID system, officially titled “Italian eID based on National ID card (CIE)”, was officiallynotified in September of 2019, and assigned the assurance level ‘High’ [61]. The system is basedaround the national identity card, which stores certificates for authentication, and can communicateusing Near-Field-Communication (NFC) technology. Unlike most other eID based systems, thesystem does not provide electronic signature functionality. The system is managed and maintainedby the Italian ministry of the interior, with some tasks such as enrolment being handled by themunicipalities and the State Mint and Polygraphic Institute [46]. Use of the system by a citizenrequires ownership of a newly available eID card, an NFC card-reader or NFC supported phone,and the installation of the computer software or mobile application. The scheme can be usedto authenticate to both governmental and private service providers [48]. The first time a citizenuses their card they need to activate it, this is done by entering their full eight digit PIN. Anyauthentication attempts after this only require the last four digits of the PIN.

Encryption and PKI information The certificates used by the system are X.509 certificates usingthe SHA256 and RSA encryption algorithms [47], of which the Italian eID holds one. Communicationwith the eID occurs using PKCS #11. The card itself is compliant to the ISO 7816 standard forsmart cards. The Italian ministry of the interior acts as the root certificate authority [49].

Authentication process The authentication process on a Windows or Mac OSX computer issimilar to most other ID document based authentication systems. The process starts with the userplacing their ID on their connected NFC reader and navigating to the service provider they wish toauthenticate to. There they select the option to identify with CIE, upon this selection the user isforwarded to the CIE authentication webpage. On this page the users web-browser will ask them toselect the right certificate, users can recognise their certificate as its name includes their tax payerID. After selecting the correct certificate the user is prompted for the last four digits of their pin,and when this is successfully entered and accepted the authentication is complete and the user willbe sent back to the website of the service provider [51].

When using an Android phone to communicate with a service provider the process is quite similar.After selecting the option to authenticate using CIE on the service providers website, the ‘Cie-ID’app will automatically open. The app will show the logo of the service the user is authenticating toand ask the user to input their PIN. After inputting the PIN the user is asked to hold their ID bytheir phone so the NFC connection can be made with the card. If the PIN is correct for the ID cardthe authentication will be completed and the user will be sent back to the website of the serviceprovider [50].

Software tools Two software tools are part of the CIE authenticaton system, the desktop softwarefor Windows and OSX, and the mobile application for Android.

24


The desktop systems are open source projects managed by the Agency for Digital Italy, the softwareprovides functionality to activate the card, change the pin and unblock a card that had the wrongPIN entered three times. The software includes a tutorial as well. When authenticating the softwareis not required, the system uses standard functionality in the supported web-browsers and operatingsystems for the menus where the user selects their certificate and enters their PIN. Installation andpreparation of the software for use is straightforward in most cases, with one exception. When auser wishes to use the software in combination with the Mozilla Firefox web-browser, the user needsto navigate to advanced options within Firefox and change the PKCS #11 module to the one thatcomes with the middleware. Aside from this the user also needs to pre-select the CIE certificatethey wish to use for authenticating. The steps required to change and set these options are welldocumented for the user [51].

The mobile application ‘Cie-ID’ is made under co-operation by the State Mint and Polygraphicinstitute and Fondazione Bruno Kessler, a research foundation founded by the Trento provincialgovernment. The mobile application is only available for Android and not for iPhone because oflimitations to the NFC communication set by Apple. The application provides the same functionalityas the desktop middleware. To authenticate with the app, the user must be using the GoogleChrome browser to navigate to the service provider they wish to use, other browsers are currentlynot supported [50].

Federation The CIE runs on a federated system where the Italian ministry of interior acts as thesole identity provider. The federation communicates according to the ‘SAML 2.0 Web Browser SSOProfile’ standard [48]. This standard puts the user at the centre of all communication, there is nodirect traffic between the service provider and the identity provider. The ministry of the interior,acting as the identity provider, logs all authentication attempts [48].

Other relevant details Currently SPID, the other Italian identification and authentication provider,is seen as the main identity provider. For this reason only a handful of services support authen-tication using the CIE, in contrast to the over 700 services supporting SPID. The documentationfor service providers includes functionality to show users which data exactly will be shared with theservice providers before they finish authenticating, but this does not seem to be implemented at thistime.

4.7 Croatia

4.7.1 National Identification and Authentication System (NIAS)

The Croatian eID system, officially titled “National Identification and Authentication System (NIAS)”was officially notified in November of 2018, and assigned the assurance level ‘High’ [61]. The systemis based around a pair of public key certificates, which are stored on a chip on the users nationalidentity card. The system is fully managed and maintained by the Croatian government, specificallythe Agency for Commercial Activities and Production (AKD), which falls under the Croatian min-istry of the interior. The system can only be used to authenticate to government services [69]. For acitizen to use the system requires possession of an eID, a compatible cardreader and the installationof certain middleware on a computer. The system also provides access through a variety of othermethods and identity providers, but these are separate from the eID system and will be discussedin another section. The system relies on two-factor authentication, using something you have (eID)and something you know (PIN).

Encryption and PKI Croatia has not made many technical details publicly available about thefunctioning of their system. What is known is that NIAS communicates according to a SAMLstandard, and that the system is certified according to the extensive requirements of the CommonCriteria version 3.1 [52].

Authentication process The authentication process using this system can start when a user visitsone of the supported government websites using a supported web-browser. On the website, the user

25


can click the log-in button, which will take them to the NIAS authentication portal, where they canselect the credentials they wish to use to authenticate. Among this list, the first option is to log-inusing the national eID, which the user should select after connecting their eID with a cardreader.Upon selecting the eID method, the user will be prompted by their browser to select the correctcertificate, and then input the PIN set for that certificate. The user should choose for the certificatethat is stored on their eID, when this is done and the PIN is entered correctly the authenticationwill be completed and the user will be forwarded back to the government website.

Software tools Users of NIAS have access to a set of tools that are either required or can supporttheir authentication capability. First is the middleware, which facilitates the communication withthe eID during the authentication process and is available for Windows, Linux and Mac OSX.The middleware is provided by AKD and closed source. The middleware comes paired with somemanagement software called AKD eID Client. AKD eID Client provides functionality to activatethe certificates on an eID, view basic card information, view certificates, change the PIN, unlock aPIN and change the PUK [4].

Aside from these software tools the user also interacts with the system through two online portals.Primarily this is done through the NIAS authentication portal. When a user initiates the authenti-cation with a service provider that relies on NIAS, the user is forwarded to a webpage run by NIAS,on this page the user can select which authentication means they wish to use and the authenticationwill continue from there. Aside from showing the authentication means this page will also showwhich level of assurance the various means provide, with these levels being based on the definitionsprovided by STORK [68]. The page will only show authentication means which provide a sufficientlevel of security for the service provider from which the authentication was started.

Finally there is an extra portal that can be used by citizens to manage their account with NIAS. Thistool, ‘mojID’ or myID in English is an online portal that allows users to see what authenticationshave been made with their various authentication means. Aside from this the portal also providessome functionality to change contact information or cancel an account.

Federation In this authentication system NIAS is acting as an identity provider for various gov-ernment services, which allows using the eID to authenticate to a limited selection of the serviceproviders that rely on NIAS as their authentication provider.

Aside from using the eID as a means of authentication with NIAS, NIAS also allows using othermeans of authentication, and even integrates other identity providers. More detail on this will beprovided in the section ‘NIAS - alternative authentication means’.

NIAS features Single-Sign-On, but only for low security service providers, which excludes cross-border authentication.

4.7.2 NIAS - alternative authentication means

As previously mentioned, the Croatian National Identification and Authentication Service supportsa wide variety of authentication means. This includes other means provided by AKD, such ascertificates and OTP tokens, but also companies coupling their existing account system to act as anidentity provider to the NIAS [68]. Currently there are 23 options for authentication within NIAS,with roughly half of them being controlled by governmental or semi-governmental agencies and theother half by private companies, mostly banks and a single telecommunications provider. None ofthese other means have been notified under eIDAS, nor are they currently in the process.

The authentication process for these various systems all starts off as described with the CroatianeID in the section above, but when one of the 22 other methods is selected a pop-up appears inwhich the authentication process specific to the selected method will occur. After this is completedthe NIAS will receive confirmation that the authentication was successful from the identity providerand the user will be forwarded to the service provider they were authenticating to.

26


The technical details of the authentication will vary per method, but the communication betweenthe NIAS and the identity provider will occur according to a SAML standard.

4.8 The Netherlands

4.8.1 DigiD

The Dutch governmental authentication system, officially titled “DigiD” has not been pre-notifiedand thus is not assigned an assurance level at this time. The system currently supports a variety ofauthentication methods based around either account and password system with an optional OTP,or authentication within a mobile application for Android and iOS. The system is managed andmaintained by Logius, a subsidiary of the Dutch Ministry of the Interior and Kingdom Relations.The system can be used to authenticate to government services and a select set of private companiesincluding health insurers and pension funds. The system allows one factor authentication basedon something you know (password) and two factor authentication based on something you know(password or PIN) and something you have (mobile phone). The one factor method is referredto as ‘DigiD basis’, whereas the two factor methods are referred to as ‘DigiD midden’, the mobileapplication based ‘DigiD midden’ method can also be used for a higher level of security referred toas ‘DigiD substantieel’, referring to the eIDAS assurance level ‘substantial’ [41].

Encryption and PKI Authentication with DigiD follows the SAML 2.0 standard and commu-nication between service provider and identity provider is encrypted with two way SSL [40]. Theonly information provided by DigiD to the service providers is the users personal identification num-ber (BSN) and the level at which they authenticated, the service providers keep the users data intheir own databases or acquire it elsewhere. The current implementation of DigiD does not rely oncertificates under control of the user.

Authentication process All three authentication methods start off with the same steps; a userbrowses to a service provider and chooses to authenticate, if the service only serves natural personsthe user will be forwarded to the DigiD login portal. If the service also serves businesses the userwill have to choose between authenticating with DigiD or eHerkenning, a Dutch identity providerfor businesses. When the user selects DigiD they will be forwarded to the DigiD login portal. Thefirst choice the user has to make in this portal is the authentication method, if the service providerallows it the choice to use an accountname and password is available, the other options will be tolog in with an accountname, password and OTP, or using the DigiD application.

When the user chooses the accountname and password option, ‘DigiD basis’, the user will beprompted for their accountname and password. If these are entered correctly the authenticationis completed and the user is forwarded to the service provider.

When the user chooses the SMS code option, one of the two ‘DigiD midden’ options, the user willsimilarly be prompted for their accountname and password. When these are entered correctly theuser will be sent an OTP by SMS, this SMS will also contain the name of the service provider theuser is authenticating to. After the OTP is correctly entered the authentication is completed andthe user is forwarded to the service provider.

When the user chooses the mobile application option the user will be asked to enter a ‘koppelcode’ orcoupling code, a new koppelcode can be requested in the DigiD app. After entering the koppelcodethe portal will show a QR code, to be scanned by the DigiD app, when this code is scanned theapplication will show which service provider the user is authenticating to and ask to confirm this.After this confirmation the user must enter their PIN in the mobile application. After the PINis entered in the mobile application the authentication is complete and the users webbrowser willbe forwarded back to the service provider. If the user initiates this authentication method on thesame mobile device that holds the mobile application, the steps for entering the koppelcode will beskipped.

27


The mobile application based method can also be raised to the higher security level of ‘DigiDsubstantieel’, this can be done by using the application to scan the users’ ID, passport, or driverslicense. Doing this once will enable ‘DigiD substantieel’ authentications for all future authenticationswith that installation of the application.

Software tools There are two tools provided to the users’ of DigiD; the aforementioned DigiD mobileapplication, and the online portal Mijn DigiD. The DigiD application is provided by the ministry ofthe interior, is available for iOS and Android, and provides limited functionality. Primarily it can beused for the authentication process described above, aside from this it also contains a rudimentarysupport page for troubleshooting problems with DigiD. If the device it is installed on has NFCfunctionality, the device also contains functionality to scan an identity document, and use this tofurther verify the identity of the owner and enable the ability to authenticate on the level ‘DigiDsubstantieel’.

The second tool, Mijn DigiD is a management portal for the users’ DigiD account. The tool is in theform of an online portal where users can manage their DigiD account. The functionality providedby the portal includes the following:

• Change contact information

• Change password

• Enable/Disable SMS authentication

• Manage connected DigiD mobile applications

• Enable/Disable authenticating with only username and password

• Delete DigiD account

• View account action history

Federation Currently DigiD functions on a straightforward federated model in which DigiD actsas the sole identity provider for the system.

4.8.2 DigiD Hoog

The Dutch government is currently working on a higher security authentication method within DigiDcalled ‘DigiD hoog’, the authentication method is currently not available, but some informationregarding its functionality is. The system will be based around the Dutch identity card and drivinglicense, which will contain a card application holding the users credentials in an encrypted form.The card application is based on the German eID. Dutch driving licenses with the required chipand application have started being circulated in 2018 [57]. The Dutch government intends to notifyDigiD hoog under the eIDAS regulation, and is aiming for the assurance level high [63].

Encryption and PKI The system is set to use a method of encryption and communication thatshould prevent the occurrence of a privacy hotspot 1 in a federated model. This method of encryption,polymorphic encryption and pseudonymisation [67] or PEP, relies on multiple cryptographic stepsin which the user provides their personal information to the identity provider in an encrypted form,and the identity provider manipulates the ciphertext in a way that it can only be decrypted with thekey belonging to a specific service provider. As the identity provider can only adapt the ciphertextto be decrypted by a service provider, the identity provider at no point has access to the identity ofthe user. To prevent the identity provider from identifying a user based on repeated access attempts,the ciphertexts the users eID’ provides to the identity provider are randomised each time.

Federation When ‘DigiD hoog’ becomes available, the Dutch government also intends to restructurethe federation model for authenticating to government services. In the current form DigiD is a

1an actor or system in an authentication process that handles a large amount of privacy sensitive data

28


centralised federation in which there is only one identity provider, but with DigiD hoog the systemis to open up to allow authentication through private identity providers as well [62].

Other relevant details Aside from providing personal information, DigiD Hoog will also includepseudonym functionality, in which users prove they are a Dutch citizen in possession of an eID,but only provide a pseudonym unique to the service provider instead of their personal information[66]. This pseudonym is based on the users’ BSN, although the BSN can not be calculated from thepseudonym.

29

5. CRITERIA FOR COMPARISON

5 Criteria for comparison

5.1 Usability - service provider

5.1.1 Federation

An identification and authentication system being federated can have various positive and negativeeffects on the system. As was discussed prior in chapter three, one of the positives is in the amountof implementation effort and other overhead required for the relying parties. If a service providercan use a federated authentication system versus a direct system, many tasks outside of the serviceproviders core business are outsourced. This lets service providers focus on their core business,instead of having to manage an authentication system and all the overhead that comes with it.

5.1.2 Usage with private service providers

Some countries have chosen to allow private companies to use the notified eID means as theiridentity provider. The ability to use the eID means for a larger amount of services motivatescitizens to use it more and thus supports the adoption of the system, while also providing users withsecure authentication methods for these services. Aside from the usability improvements for theuser, allowing usage with private service providers can help spread the costs of the authenticationproblem across relying parties, possibly lowering the costs for individual service providers.

5.2 Usability - user

5.2.1 Authentication methods

Among the authentication systems that were described, a large selection of available authenticationmethods were observed. Many relying on using a computer and a card-reader, some on a computerand a smartphone, and others. Letting users choose a method they trust and are comfortable with isbeneficial to the user experience, so this criterion will index which options are available with whichsystems.

5.2.2 Single-sign-on

Some federated identification and authentication systems provide single-sign-on functionality. Thismeans that once the user has authenticated with the identity provider, they will not have to au-thenticate again until this authentication has expired, even when using different service providers.This makes the process easier and less tedious for users, but also has some downsides regardingsecurity. One downside is that this system is less restrictive to man in the browser attacks, themalware no longer needs to fool the user into signing into a different service provider, as they arealready authenticating to all service providers simultaneously. Man-in-the-browser attacks and theirrelation to single-sign-on will be discussed further with the ‘Vulnerability to man in the browserattacks’ criterion.

Some also question if single-sign-on should be allowed under eIDAS for systems that are notifiedwith the assurance levels substantial or high. Substantial and high require the use of at least twoauthentication factors, but when using single-sign-on, after the first authentication, the followingauthentications occur based on the existence of a ‘cookie’. One could argue that the checking of thiscookie is an authentication process relying on a single factor.

30


5.2.3 Availability of other qualified trust services

Aside from setting a framework for international authentication within the European Union, theeIDAS regulation has also laid legal grounds for a set of other electronic trust services, namelyqualified electronic signatures, qualified timestamps, electronic seals, registered delivery services andwebsite authentication. The demands to and implications of these services are laid out in chapterthree of the eIDAS regulation [14]. Some member states have provided the tools for use of some ofthese services with the software provided for the authentication system. As the following chapter willshow, this was limited to electronic signatures, electronic timestamps and electronic seals. Includingthese tools provides citizens with a method to learn about and use these trust services, helping themprotect their security when using these trust services for their communication and transactions. Thiscriterion will be focused on the inclusion of signing certificates on the national eID, as well as theavailability of software for and/or documentation on- using the certificate for qualified trust services.All countries within the scope have one or more registered ‘trust service provider’, but these areusually focused on serving businesses.

5.2.4 Accessing past authentication information

To detect misuse of users’ identity and maintain trust in an authentication system, various memberstates have implemented options that allow users to view past authentications made with theirauthentication means. Such functionality ideally informs the user on when an authentication wasmade including a time and date, as well as to which service provider. This will help users take timelymeasures if their identity has been misused, or be certain that it was not misused when they are indoubt.

Getting full information on the use of authentication means in your name can be increasingly complexin member states with multiple identity providers or even multiple means. If a malicious actormanages to enroll for a means of authentication using someone else’s identity, without the victimknowing, the victim can not be expected to check the authentication history of this means. Ideallythis is solved by providing a facility where citizens can check which means are registered under theirname. But as such extraneous facilities fall out of the scope of this research, their existence with therelevant member states Belgium, Estonia, Spain and Italy were not extensively researched. Althoughduring the regular investigation of these member states’ systems no documentation on such a systemwas found. The future implementation of The Netherlands DigiD Hoog which will include multipleidentity providers will provide such a facility [62].

5.3 Privacy

5.3.1 Privacy hotspots

Beside the aforementioned effects on usability, an identification and authentication system beingfederated can also have great effects on the privacy of the system. To reiterate what was mentionedin the context chapter, a federated identity provider takes over the identification and authenticationtasks for service providers, thereby improving the usability for these service providers. A problemwith such a system however is that all identification and authentication traffic for these serviceproviders will pass through a single identity provider. This could cause a hotspot of privacy sensitivedata in a single place, which becomes even more sensitive and valuable due to the aggregation ofinformation, while also introducing a single point of failure.

A federated identity system does not have a privacy hotspot by definition. To prevent a privacyhotspot in a federated system there are two options. The first option is to make the identity providerblind to what service provider the user is authenticating to. In this case the federation does knowwhich users are authenticating and when, but not to which service provider, which greatly reduces

31


the sensitivity of the information the federation has access to. The second option is to make theidentity provider blind to what users are authenticating. In this case the federation does know whatservice providers are being authenticated to, but does not know the identity of the users that areauthenticating. With this option the federation does not hold identifiable personal information atall, completely mitigating the privacy hotspot.

5.3.2 Pseudonyms

With the enforcement of the General Data Protection Regulation beginning in 2018, the demandsand requirements for the handling of sensitive personal information have greatly increased. Article32 of the GDPR demands that organisations ‘implement appropriate measures’ to ensure the securityof personal information, and the first example of a measure to achieve this mentioned in the GDPRis pseudonymisation [17]. With the amount and types of data that are handled by governmentservices and the corresponding identity providers, possibly including ‘special categories of personalinformation’, the use of pseudonymisation in such systems seems warranted.

The use of pseudonymisation in such systems would allow users to access a service provider with-out providing their actual personal information. This provides users with extra Privacy towardsthat service provider, and makes it harder if not impossible to couple data from different serviceproviders.

5.4 Security

5.4.1 Security of Communication

To ensure the security of the communication article 2.3.1 of EU implementing regulation 1502 re-quires identification and authentication mechanisms to include security measures to prevent “guess-ing, eavesdropping, replay or manipulation of communication” [16]. In the analysis of the varioussystems various measures were found to increase the security of communication. One measure takenin those systems is to use PKI to encrypt traffic using the trusted certificate of the service- or iden-tity provider. This measure will aid to prevent guessing, eavesdropping, replay and manipulation ofcommunication.

Phishing is a form of attack that can not easily be prevented with such measures however. ‘Phishingis the fraudulent attempt to obtain sensitive information such as usernames, passwords and creditcard details by disguising oneself as a trustworthy entity in an electronic communication [70]. Forexample, a malicious actor sets up the website mygovernnent.nl, made to look exactly like thegovernment website mygovernment.nl. The malicious actor will then convince citizens to log inthrough his website, having them believe they are accessing the real government website. Any userthat does not notice this discrepancy will enter their credentials believing they are communicatingwith a legitimate actor, but they are actually sending their credentials to a malicious actor who canthen assume their identity.

To protect against phishing, what must be achieved is that the user can be sure that the partythey are communicating with are who they say they are. In federated systems this is achieved byusing a unified authentication portal, users are taught how to recognise this portal and not to entertheir information anywhere else. In direct systems users will have to authenticate on many differentwebsites, which will make it harder for users to recognise false websites which are set-up to gatherusers’ credentials.

Direct systems must achieve this surety through other means, and that is by limiting the partiesthat can use the authentication system. In such a system, during the authentication process, theeID and the service provider mutually exchange certificates. The user of course provides theirs toprove their identity, and the service provider provides their certificate to prove they are authorised

32


to use the system and to possibly allow the user to confirm themselves they are engaging with theintended service provider. This process is commonly called mutual authentication, and the effect isthat, just like with a federation, users can be sure that they are communicating with a party thathas been vetted and whitelisted by a managing authority.

5.4.2 Vulnerability to ‘Man in the browser’ attacks

A man in the browser attack is a variation of a man in the middle attack that uses the browser ofthe user as the attack vector, thereby circumventing encryption and other defences occurring whendata is being transmitted [21]. In the context of identification and authentication for eGovernment,man in the browser can be an important threat, as the authentication systems often provide ac-cess to more than one service. This brings the possibility for malware to make it appear like theuser is authenticating to a certain service, while actually authenticating to another, and using thisauthentication for illicit transactions or acquiring personal information.

The requirements to authentication systems under eIDAS laid out in implementing regulation 1502of the European Union [16] for systems notified at assurance level substantial or higher demandimplementation of measures to protect against attackers with a moderate attack potential. Theextension to these requirements by the Dutch government, used in the pre-analysis of this research,define man-in-the-browser attacks as an example of an attack with moderate potential [11].

Figure 1: Confirmationof authentication in theItsme app

There are multiple possible design decisions that can be taken thatwill help users recognise or prevent a Man in the browser attack, orinstead make it harder to recognise or prevent such an attack. Onesuch design decision that makes it harder for users to detect a man inthe browser attack is the availability of single-sign-on functionality.If one authentication will immediately provide access to all serviceproviders to the user, it will also do this for malware, meaning it nolonger has to trick the user into accessing a different service providerthan they were intending to access.

A precaution that can be taken to help users recognise and preventa successful man in the browser attack, is to have the user check andconfirm the action they are taking through a second channel. Usuallythe second authentication factor is used for this. For instance, anSMS with an authentication code will not only contain the code, butalso state for which service provider the code is being used. Thiscould also be done within an app or on the screen of a card-scannerif this is available. This precaution can not be taken in conjunctionwith single-sign-on, as then the authentication will always be forevery service provider.

A third design option that could help users detect a man-in-the-browser attack after the fact is the previously discussed functionalityto see and review historical authentications.

33

6. COMPARISON

6 Comparison

This chapter will contain various tables, each showing how the various systems perform on thecriteria listed in chapter five. The tables will contain the systems and member states in the orderthey were described in chapter four. For clarity, the following table will show which systems belongto which member states, the order will be the same in each table.

System name Member state

Belgian eID Belgium

Itsme Belgium

German eID Germany

Luxembourg eID

/ LuxTrust

Luxembourg

Estonian eID /

Mobiil-ID

Estonia

Spanish eID Spain

Cl@ve Spain

SPID Italy

Italian eID Italy

NIAS Croatia

DigiD The Netherlands

DigiD Hoog The Netherlands

34

6. COMPARISON

6.1 Federation

Federated or direct

Belgian eID Federated

Itsme Federated

German eID Direct*

Luxembourg eID

/ LuxTrust

Federated

Estonian eID Direct

Mobiil-ID Federated

Spanish eID Direct

Cl@ve Federated

SPID Federated

Italian eID Federated

NIAS

Including Croatian eID

Federated

DigiD Federated

DigiD Hoog Federated

The German eID is based on direct authentication in its original design. But changes to the systemhave allowed service providers to outsource the handling of the authentication process to othercompanies, essentially making a part of the system run on a decentralised federated model.

35

6. COMPARISON

6.2 Usage with private service providers

Open to private service providers

Belgian eID No

Itsme Yes

German eID Yes

Luxembourg eID

/ LuxTrust

Yes

Estonian eID /

Mobiil-ID

Yes

Spanish eID No

Cl@ve No

SPID Yes

Italian eID Yes

NIAS No

DigiD Yes

DigiD Hoog Yes

36

6. COMPARISON

6.3 Authentication methods

Computer and

cardreader

Computer and

smartphone

Computer

and SMS

Computer and

OTP device

Computer

only

Smartphone

app only

Belgian eID Yes Yes* Yes* Yes* Yes* No

Itsme No Yes* No No No Yes*

German eID Yes Yes No No No Yes

Luxembourg eID

/ LuxTrust

Yes Yes* Yes* Yes* No Yes*

Estonian eID /

Mobiil-ID

Yes Yes No No No Yes

Spanish eID Yes Yes No No No No

Cl@ve No No No No Yes* No

SPID Yes Yes Yes Yes Yes Yes

Italian eID Yes No No No No Yes

NIAS Yes Yes* Yes* Yes* Yes* Yes*

DigiD No Yes* Yes* No Yes* No

In the table above, the column Computer and smartphone refers to methods where either thesmartphone is used as a cardreader for the computer, or used to generate an OTP or other form ofaccess code.

All methods marked with ‘*’ are methods that are currently not notified and thus not usable forcross-border authentication.

37

6. COMPARISON

6.4 Single-sign-on

Single-Sign-On

Belgian eID Yes

Itsme Yes*

German eID No

Luxembourg eID

/ LuxTrust

No

Estonian eID /

Mobiil-ID

No

Spanish eID No

Cl@ve Yes

SPID Yes*

Italian eID No

NIAS


Yes*

DigiD Yes*

DigiD Hoog No

Itsme does not have Single-Sign-On by design, but due to the sequential identity provider structureof the system, it does have Single-Sign-On when connecting to Belgian government services.

SPID, NIAS and DigiD limit Single-Sign-On to service providers that require a low level of assur-ance/security.

38

6. COMPARISON

6.5 Availability of other trust services

Document Signing Document sealing Timestamping

Belgian eID Yes No No

Itsme No No No

German eID No No No

Luxembourg eID

/ LuxTrust

Yes No No

Estonian eID /

Mobiil-ID

Yes Yes Yes

Spanish eID Yes No No

Cl@ve No No No

SPID No No No

Italian eID No No No

NIAS No No No

DigiD No No No

Germany is currently in the process of creating a tool to provide document signing to users of theireID, the required certificates are already present in the German eID [29].

39

6. COMPARISON

6.6 Accessing past authentication information

Functionality

available

Belgian eID No

Itsme Yes

German eID No*

Luxembourg eID

/ LuxTrust

No

Estonian eID /

Mobiil-ID

Yes*

Spanish eID No

Cl@ve No

SPID No*

Italian eID No

NIAS Yes

DigiD Yes

DigiD Hoog Yes

The German software for authenticating with the eID does provide functionality to save and reviewpast authentications, but as these transactions are stored locally in the software it is of no use if theidentity theft was committed on a different computer. Aside from this the option can easily be turnedoff within the software, so it does not provide any certainty in detecting malicious transactions.

The Estonian system has a limited method of informing the user of past authentications, as it doesnot provide a list, but instead keeps a counter. Every time a users eID is used to authenticatethe counter increases, and the user should notice if the counter has increased too much betweenuses.

The Italian SPID system consists of a variety of identity providers with differing implementations,and this functionality is not consistently implemented by all of these service providers.

40

6. COMPARISON

6.7 Privacy hotspots

Privacy Hotspot Hotspot location

Belgian eID Yes Belgian eID FAS

Itsme Yes Belgian eID FAS

German eID No*

Luxembourg eID

/ LuxTrust

Yes LuxTrust

Estonian eID

and variants

No

Mobiil-ID Yes Mobiil-ID API

Spanish eID No

Cl@ve Yes Cl@ve

SPID Yes* Various identity providers

Italian eID Yes Italian eID

NIAS Yes NIAS

DigiD Yes DigiD

DigiD Hoog No

Belgian eID runs on a federated model without mitigation for a privacy hotspot. Itsme serves as asecondary identity provider to the Belgian eID system, so although Itsme does not have a privacyhotspot by design, all authentications to government services using Itsme pass through the BelgianeID FAS so are still subject to that same privacy hotspot.

The German eID does not have privacy hotspots in its original design, due to being based on direct,non-federated authentication. But changes to the system have allowed service providers to outsourcethe handling of the authentication process to other companies, essentially creating decentralisedfederated identity providers and thus possible privacy hotspots in the system.

The Luxembourg eID system runs on a federated model without mitigation for a privacy hotspot.

The Estonian card-based systems are based on direct, non-federated authentication and thus haveno privacy hotspot. The Estonian Mobiil-ID system, in contrast to the Estonian card-based systems,runs on a federated model without mitigation for a privacy hotspot.

The Spanish eID system is based on direct, non-federated authentication and thus has no privacyhotspot. The Spanish Cl@ve systems runs on a federated model without mitigation for a privacyhotspot.

The Italian SPID system has a decentralised federation model that allows users to use more thanone authentication provider simultaneously. If a user chooses to do this it alleviates some of theconcerns for the privacy hotspot, as their authentication data can not be combined easily. But eachidentity provider the user regularly uses still accumulates privacy sensitive data.

41

6. COMPARISON

The Italian eID, Croatian NIAS and Dutch DigiD in its current form run on a federated modelwithout mitigation for a privacy hotspot.

The future DigiD Hoog system will run on a decentralised federational model, in which the identityproviders will be blind to the identity of the user, thus mitigating a privacy hotspot.

6.8 Pseudonyms

Pseudonyms

Belgian eID No

Itsme No

German eID Yes

Luxembourg eID

/ LuxTrust

No

Estonian eID /

Mobiil-ID

No

Spanish eID No

Cl@ve No

SPID No

Italian eID No

NIAS


No

DigiD No

DigiD Hoog Yes

42

6. COMPARISON

6.9 Security of communication

Encrypted communication Receiving party surety

Belgian eID Yes Yes

Itsme Yes Yes

German eID Yes Yes

Luxembourg eID

/ LuxTrust

Yes Yes

Estonian eID

and variants

Yes No

Mobiil-ID Yes Yes

Spanish eID Yes Yes

Cl@ve Yes Yes

SPID Yes Yes

Italian eID Yes Yes

NIAS


Yes Yes

DigiD Yes Yes

DigiD Hoog Yes Yes

As federations have an active relationship with their relying parties, they are expected to preventmalicious actors from using their platform. The direct identification and authentication systems; theGerman eID, the Estonian card based systems and the Spanish eID, have to rely on other means toensure to their users the service providers do not misrepresent themselves. The German and SpanisheID have achieved this through mutual authentication. The Estonian system on the other hand, isentirely open to service providers, and thus can not rely on this measure, which results in it beingthe only system to fail this criterion.

43

6. COMPARISON

6.10 Vulnerability to ‘Man in the browser’ attacks

Measures taken SSO Service provider confirmation

Belgian eID Yes No

Itsme Yes* No*

German eID No Yes

Luxembourg eID

/ LuxTrust

No No

Estonian eID /

Mobiil-ID

No Only in Mobiil-ID

Spanish eID No No

Cl@ve Yes No

SPID No* Yes

Italian eID No Only with mobile application

NIAS


No* No

DigiD No* Yes

DigiD Hoog No Yes

Itsme does not provide single-sign-on by default, and does inform the user of which service theyare authenticating to or which action they are approving. However, as the governmental service-providers Itsme works with use the Belgian eID Scheme FAS / eCards as an intermediary betweenthem and Itsme, a single authentication action will still be an effective single-sign-on for thoseservices in particular. Thus there is no effective countermeasure to a man in the browser attackwhen authenticating with Itsme to governmental service providers.

SPID, NIAS and DigiD do allow Single-Sign-On, but only with service providers that require a lowassurance or security level. NIAS fully excludes cross-border authentications from using Single-Sign-On.

44

7. INSIGHTS

7 Insights

7.1 Chapter outline

This chapter will discuss the various insights that can be taken from the descriptions of the countriesand the comparisons that were made between them.

7.2 Insights per criterion

7.2.1 Federation

Within the scope of this research there seems to be a greater preference for federated authenticationmodels than for direct authentication. Germany’s change to a hybrid system shows that a directsystem might cause too much overhead for service providers, Estonia has circumvented this by relyingon simpler and already widely available technology, and Spain has limited itself to governmentalservice providers only and has a secondary authentication system.

7.2.2 Usage with private service providers

Most countries have made their authentication system available to private service providers as well asgovernmental ones. There is however still a distinction to be made among those countries, regardingthe strictness of allowing service providers to become a part of the system. Italy’s SPID and Estonia’ssystems stand out as especially open, being integrated with many private service providers. On theother end of the spectrum are The Netherlands and Germany, as their systems seem to be usablewith a much more limited set of non-governmental service providers.

7.2.3 Authentication methods

The comparison of available authentication methods shows a positive image across the board, withevery member state offering authentication methods for desktop and mobile. There is some variationin countries offering alternative One-Time-Password methods, but with some systems being strictlyeID based this is understandable.

Looking at this criterion from a security perspective, it is notable that four systems are offeringauthentication methods relying on OTP sent through SMS. As discussed in the description of theItalian SPID system, this method is seen as quite vulnerable to attacks, so it is recommendednot to use it for systems relying on a high standard of security [37]. Among these four systems,only the SPID system has the method notified for cross-border authentication, at assurance levelsubstantial.

7.2.4 Single-sign-on

Member states seem to be split on enabling single-sign-on with their authentication systems, withhalf of the member states within scope having one or more systems featuring it and the otherhalf having it disabled. The most notable however is Belgium, which not only has SSO on bothsystems, but is also the only system to not restrict SSO to low assurance service providers. Asmentioned earlier, it is questionable if allowing SSO with service providers requiring intermediateor high assurance level should be allowed under eIDAS, as authentications after the first sign onare only based on the existence and validity of a ‘cookie’, which can be interpreted as single factorauthentication.

45

7. INSIGHTS

7.2.5 Availability of other trust services

This criterion shows that the other trust services have fallen behind quite a bit compared to theauthentication systems. Only four member states have provided tools to their citizens to help themmake use of such trust services, with Spain, Luxembourg and Belgium remaining limited to documentsigning, and Estonia including document signing, document sealing and timestamping. The tablemight mislead you to thinking that at least Estonia has provided tools for all trust services, but asno member state has provided the tools for registered delivery services and website authenticationthese were omitted from the table.

7.2.6 Accessing past authentication information

Reviewing past authentications seems to be somewhat of an overlooked feature among authenticationsystems. Many systems do not include the feature, and those that do often make little note of it intheir documentation. In case a users identity is stolen, it can however be of great help to find outwhat has been done with it by the perpetrator, and revert any changes if possible.

Taking into account article 15 of the General Data Protection Regulation [17], which grants allEuropean citizens the right to access personal information concerning them, in combination withrequirement 2.4.4 from implementing regulation 1502 [16] which requires member states to store andretain authentication information for purposes of auditing and investigation of security breaches, onewould expect that more authentication systems would have such a system in place. But it seemsthat citizens wishing to review their authentication data will have to follow a more difficult processto obtain the information with most systems.

7.2.7 Privacy hotspots

Multiple countries and systems seem to be dealing with privacy hotspots and have taken little to nomeasures to prevent this. A select group of member states have set up direct authentication systemswhich have prevented the problem, of which at least Germany has stated it is one of their reasonsfor doing so. The Netherlands’ future DigiD hoog system is the only system taking a different pathto preventing the occurrence of a privacy hotspot, which is by using polymorphic encryption andpseudonymisation. This PEP system ensures identity providers only receive and pass on encrypteduser information, making it blind to the users’ identity.

7.2.8 Pseudonyms

Currently only one member state within the scope of this research seems to have noticed the demandsof the GDPR and it’s privacy by design demands and taken them into account in their authenticationsystem, which is Germany and their eID system. The future Dutch system will follow suit when itbecomes available, and outside of the scope of this research other member states are also thinkingof pseudonymisation, as it is also implemented in the Austrian eID system [54].

7.2.9 Security of communication

As should be expected due to the legal foundation of eIDAS, all systems adhere to the minimumsecurity standard of encrypting communicaton, although it might not be fair to credit the eIDASregulation for this, as systems that are not notified also manage this. The second part of thiscriterion checks whether systems can provide surety to their users that only legitimate parties canmake use of the system, which is key in preventing replay attacks. Most countries have achievedthis due to being based on a federated system, in which relying parties are in an active relationshipwith and can be vetted by the managing authority. Among the systems that are based upon direct

46

7. INSIGHTS

communication, the Spanish and German eID systems rely on mutual authentication to ensure onlycertified parties can make use of the system. Which leaves only Estonia, which has made no obviousmeasures to ensure only legitimate parties can make use of the authentication system.

7.2.10 Vulnerability to ‘Man in the browser’ attacks

The Netherlands and Germany stand out in this section as the only two member states to consistentlyhave implemented both preventative measures in their authentication systems. The Belgian systemand the Spanish non-notified Cl@ve system stand out in the opposite way, featuring Single-Sign-Onwithout having the user confirm what service provider they are communicating with, leaving theirusers vulnerable to a man in the browser attack.

47

8. DISCUSSION & CONCLUSION

8 Discussion & Conclusion

8.1 Conclusions

Goal of this research was to discover differences between the various identification and authenti-cation systems of European Union member states, and make recommendations for the upcomingDutch system and other future identification and authentication systems, if notable discoveries weremade.

The research has resulted in detailed descriptions of eleven identification and authentication systemsfrom eight member states, and compared them across ten criteria. These ten criteria can be taken asthe answer to the first research question; ‘Which characteristics or criteria can be identifiedas key differences to the identification systems of the various member states?’.

The descriptions show that the systems among member states show many similarities, indicatingthat member states look to one another for inspiration and assistance while designing their systems.Although this might not be immediately visible from the selected criteria, as those were selectedbased on differences in the systems, criteria that showed no notable differences among systems werediscarded. Countries that were early in completing their systems, such as Germany and Estonia,have made notable impact on the design choices of other member states. Nonetheless differenceswere found, most notably, but not limited to, the ten selected criteria.

The second research question, ‘How do the selected systems and member states rate andcompare according to the defined criteria?’, has resulted in the comparisons and insightsdescribed in chapter six and seven of this paper.

Which leaves research question three, ‘What recommendations can be made for existingand future identification and authentication systems based on these discoveries?’, andits two sub-questions focusing on the Dutch system and authentication systems under eIDAs ingeneral.

As for the future Dutch system, based on the information that is already available, this systemwas also included in comparisons where possible. In the comparisons the upcoming system, DigiDHoog, fared well. The system achieved a perfect score within the privacy criteria, as well as withthe security criteria. Due to the unfinished nature of the system and thus incomplete information,it was left out the comparisons of two criteria in the usability category, but scored almost perfectlyin the other four as well. The only gap in its usability score was with the single-sign-on criterion,but as the system intends to notify at assurance level high this feature will be left out for securityreasons.

One of the categories in which DigiD Hoog was left out, is one which warrants a recommendation forDigiD and other existing and future authentication systems under eIDAS. The criteria that saw someof the worst performance among all member states was the inclusion of other eIDAS trust services.From the eight included member states, only four provide tools for making use of the eIDAS trustservices, three of which only for a single selected service. The eIDAS regulation has laid a legalfoundation for digital trust services in order to improve and simplify the online transaction process.But most citizens have no knowledge how to make use of such digital services. The governmentsof member states could assist their citizens by helping them make use of these trust services byproviding useful software, documentation and qualified certificates.

A recommendation for other future and current authentication systems is in the option for usersto inspect their past authentications. The comparison shows six out of the eleven authenticationsystems do not have this feature, even though it can be a useful tool for users that have fallen victimto identity theft. The Estonian system has shown such a feature does not need to be complex nordoes it require centralised tracking of authentication attempts. Although the implementations infederated systems can provide the full functionality, and thus the full benefit to the user.

48

8. DISCUSSION & CONCLUSION

The final recommendation stems from the criterion which was least implemented among the authen-tication systems within the scope of this research. This criterion is the availability of pseudonymi-sation. Pseudonymisation can be a key feature in helping citizens protect their privacy, and for thisreason it is seen as a key aspect to the privacy by design aspects of the General Data Protection Reg-ulation. But only one system within this research, the German eID system, currently provides thefunctionality to the users, with the DigiD hoog system being listed as a future second system.

8.2 Limitations

The greatest limitation that was faced in this research is the availability of information. Betweenmember states and systems within member states there are large discrepancies to how much andhow easily documentation and other information is available. In some cases this was caused bysystems being entirely closed source, in other cases it was a lack of documentation easily availableto the public. Notable systems in this regard were on the one hand the German system, which isextremely well documented with lots of documentation provided by the BSI. On the other hand wasLuxembourg, which opted to not provide any technical documentation, and keep all documentationit provided to the eIDAS cooperation network confidential. If more information was available acrossall systems this could have provided more grounds for comparison, resulting in more comparisoncriteria, especially in the categories privacy and security.

Basing a comparison of user experience strictly on documentation is also somewhat limited, ideallythe research should have had access to all systems and the ability to perform user experience testingwith real users, allowing for use of more rigorous methods. Such methods would have helped createa more detailed comparison of the user experience and usability of the systems.

8.3 Further research

Regarding the previously mentioned limitation regarding the availability of information, repetitionof this research with the cooperation of the member states and the various actors that managethe systems could be warranted, in order to create more detailed descriptions and more extensivecomparisons.

Once all member states have notified systems a repetition of this research with a more complete scoperegarding the member states could also be warranted, to reach a complete overview and comparisonof all identification and authentication systems under eIDAS.

As this was an exploratory research, more in depth research regarding the privacy, security andusability of the systems could be performed. Although I would recommend separating the categoriesinto different research, as there is plenty to discuss regarding all three topics. As mentioned inlimitations, usability could go more in-depth by obtaining access to all the systems and performingfull usability reviews. Privacy and Security could both benefit by full co-operation from the managingparties in order to get a complete view on the workings of the systems.

Finally, something that was noticed during this research but fell out of scope. Among countries withmore than one means of authentication, such as Italy or Belgium, there seems to be no straightfor-ward way to check which means have already been registered to your name in any of them. Thiswould mean that if someone’s identity would be stolen successfully and used to register with one ofthe means the citizen is not already using, there would be no simple way of finding this out. Futureresearch could take a broader scope of the authentication experience in a member state, and findout if this is possible in any member states, and what the implications of not having this optionwould be.

49

REFERENCES

References

[1] Authentication in The Oxford Dictionary of English, 2015.https://www.lexico.com/en/definition/authentication.

[2] Administracion Electronica. Cl@ve Identificacion, 2019.https://administracionelectronica.gob.es/ctt/clave.

[3] Administracion Electronica. European system of recognition of electronic identities - eIDAS,2019.https://administracionelectronica.gob.es/pae_Home/pae_Estrategias/pae_

Identidad_y_firmaelectronica/Nodo-eIDAS.html?idioma=en.

[4] Agencija za komercijalnu djelatnost proizvodno, usluzno i trgovacko. Akd eid middleware - eidclient korisnicke upute, 2018.https://www.id.hr/datastore/filestore/12/Upute-za-koristenje-softverskog-paketa_

1.pdf.

[5] Agenzia per l’Italia Digitale. Spid - general info, 2017.https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Italy+-+SPID.

[6] Agenzia per l’Italia Digitale. Spid - general loa mapping, 2017.https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Italy+-+SPID.

[7] Agenzia per l’Italia Digitale. Request spid, 2019.https://www.spid.gov.it/richiedi-spid?lang=en-001.

[8] Belgian Mobile ID. Itsme on the intigriti bugbounty platform, 2018.https://www.intigriti.com/public/project/itsme/itsme.

[9] Belgian Mobile ID NV/SA. Itsme - privacy policy 04/03/2019, 2019.https://www.itsme.be/legal/app-privacy-policy.

[10] Centre for Technology Transfer and Innovation. Cliente afirma, 2017.https://github.com/ctt-gob-es/clienteafirma.

[11] Centrum voor Facilitaire Dienstverlening. Marktconsultatie eid: privaat inlogmiddel of –mid-delen, 2017.https://www.cartaidentita.interno.gov.it/il-microprocessore/.

[12] Cl@ve. Get to know Cl@ve, 2014.https://clave.gob.es/clave_Home/en/clave.html.

[13] Connecting Europe Facility. Country overview - pre-notified and notified eid schemes undereidas, 2019.https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+

pre-notified+and+notified+eID+schemes+under+eIDAS.

[14] Council of the European Union. Council regulation (EU) no 910/2014 on electronic identifica-tion and trust services for electronic transactions in the internal market, 2014.https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.

01.0073.01.ENG.

[15] Council of the European Union. Council regulation (EU) no 1501/2015 on the interoperabilityframework pursuant to article 12(8) of regulation (eu) no 910/2014 of the european parliamentand of the council on electronic identification and trust services for electronic transactions inthe internal market, 2015.https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL_2015_235_R_0001.

50

https://www.lexico.com/en/definition/authentication

https://administracionelectronica.gob.es/ctt/clave

https://administracionelectronica.gob.es/pae_Home/pae_Estrategias/pae_Identidad_y_firmaelectronica/Nodo-eIDAS.html?idioma=en

https://administracionelectronica.gob.es/pae_Home/pae_Estrategias/pae_Identidad_y_firmaelectronica/Nodo-eIDAS.html?idioma=en

https://www.id.hr/datastore/filestore/12/Upute-za-koristenje-softverskog-paketa_1.pdf

https://www.id.hr/datastore/filestore/12/Upute-za-koristenje-softverskog-paketa_1.pdf

https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Italy+-+SPID

https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Italy+-+SPID

https://www.spid.gov.it/richiedi-spid?lang=en-001

https://www.intigriti.com/public/project/itsme/itsme

https://www.itsme.be/legal/app-privacy-policy

https://github.com/ctt-gob-es/clienteafirma

https://www.cartaidentita.interno.gov.it/il-microprocessore/

https://clave.gob.es/clave_Home/en/clave.html

https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+pre-notified+and+notified+eID+schemes+under+eIDAS

https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Overview+of+pre-notified+and+notified+eID+schemes+under+eIDAS

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL_2015_235_R_0001

REFERENCES

[16] Council of the European Union. Council regulation (EU) no 1502/2015 on setting out minimumtechnical specifications and procedures for assurance levels for electronic identification meanspursuant to article 8(3) of regulation (eu) no 910/2014 of the european parliament and of thecouncil on electronic identification and trust services for electronic transactions in the internalmarket, 2015.https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL_2015_235_R_0002.

[17] Council of the European Union. Council regulation (EU) no 679/2016 on the protection ofnatural persons with regard to the processing of personal data and on the free movement ofsuch data, 2016.https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679.

[18] CSAM. Wat zijn digitale sleutels?, 2019.https://iamapps.belgium.be/sma/generalinfo?view=digitalKeys.

[19] Direccion General de la Policıa. Dni electronico.https://www.dnielectronico.es/PortalDNIe/PRF1_Cons02.action?pag=REF_100&id_

menu=1.

[20] Direccion General de la Policıa. Manual de usuario dnieremote v1.2.25, 2019.https://www.dnielectronico.es/PDFs/DNIeRemote_user_manual_v1_2_25.pdf.

[21] T. Dougan and K. Curran. Man in the browser attacks. International Journal of AmbientComputing and Intelligence (IJACI), 4(1):29–39, 2012.

[22] M. Eichholtzer. Cooperation network resources, 2018.https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Cooperation+Network+

Resources.

[23] eIDAS Cooperation Network. eIDAS technical specification version 1.1, 2016.https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL2018/eIDAS+Profile.

[24] Escec Gmbh and Luxtrust S.A. Chipgateway protocol, 2017.https://www.oasis-open.org/committees/download.php/60049/

ChipGateway-Specification-OASIS.pdf.

[25] Estonian Information System Authority. Electronic identity (eid) application guide: where,why, how., 2014.https://eid.eesti.ee/index.php/Authenticating_in_web_applications#

Implementing_authentication_with_an_ID_card.

[26] Estonian Information System Authority. Roca vulnerability and eid: Lessons learned, 2018.https://www.ria.ee/sites/default/files/content-editors/kuberturve/

roca-vulnerability-and-eid-lessons-learned.pdf.

[27] Estonian Information System Authority. Digidoc4 client, 2019.https://github.com/open-eid/DigiDoc4-Client/wiki.

[28] Federal Ministry of the Interior, Building and Community. eid service, 2019.https://www.personalausweisportal.de/EN/Business/Technology/eID-service/

eID-service_node.html.

[29] Federal Ministry of the Interior, Building and Community. Remote signatures with the onlineid function, 2019.https://www.personalausweisportal.de/EN/Business/eidas_compliant_remote_

signature/eidas_compliant_remote_signature_node.html.

51

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL_2015_235_R_0002

https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679

https://iamapps.belgium.be/sma/generalinfo?view=digitalKeys

https://www.dnielectronico.es/PortalDNIe/PRF1_Cons02.action?pag=REF_100&id_menu=1

https://www.dnielectronico.es/PortalDNIe/PRF1_Cons02.action?pag=REF_100&id_menu=1

https://www.dnielectronico.es/PDFs/DNIeRemote_user_manual_v1_2_25.pdf

https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Cooperation+Network+Resources

https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Cooperation+Network+Resources

https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL2018/eIDAS+Profile

https://www.oasis-open.org/committees/download.php/60049/ChipGateway-Specification-OASIS.pdf

https://www.oasis-open.org/committees/download.php/60049/ChipGateway-Specification-OASIS.pdf

https://eid.eesti.ee/index.php/Authenticating_in_web_applications#Implementing_authentication_with_an_ID_card

https://eid.eesti.ee/index.php/Authenticating_in_web_applications#Implementing_authentication_with_an_ID_card

https://www.ria.ee/sites/default/files/content-editors/kuberturve/roca-vulnerability-and-eid-lessons-learned.pdf

https://www.ria.ee/sites/default/files/content-editors/kuberturve/roca-vulnerability-and-eid-lessons-learned.pdf

https://github.com/open-eid/DigiDoc4-Client/wiki

https://www.personalausweisportal.de/EN/Business/Technology/eID-service/eID-service_node.html

https://www.personalausweisportal.de/EN/Business/Technology/eID-service/eID-service_node.html

https://www.personalausweisportal.de/EN/Business/eidas_compliant_remote_signature/eidas_compliant_remote_signature_node.html

https://www.personalausweisportal.de/EN/Business/eidas_compliant_remote_signature/eidas_compliant_remote_signature_node.html

REFERENCES

[30] Federal office for Information Security. German eid based on extended access control v2.Technical report, 2017.https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/EIDAS/German_eID_

Whitepaper.pdf?__blob=publicationFile&v=7.

[31] Federal Public Service Policy and Support DG Digital Transformation. Technical specificationshandbook related to the royal decree of recognition of partner’s electronic identification services,2017.https://bosa.belgium.be/en/publications.

[32] Federal Public Service Policy and Support DG Digital Transformation. Developing for thebelgian eid, 2019.https://github.com/Fedict/eid-mw/wiki/Development.

[33] Federale overheidsdienst beleid en ondersteuning. Koninklijk besluit tot vaststelling van devoorwaarden, de procedure en de gevolgen van de erkenning van diensten voor elektronischeidentificatie voor overheidstoepassingen, 2017.http://www.ejustice.just.fgov.be/cgi_loi/change_lg.pl?language=nl&la=N&table_

name=wet&cn=2017102211.

[34] Governikus. Online ausweisen - ein beispiel, 2017.https://www.youtube.com/watch?v=fzbUZmHaZp4.

[35] Governikus. Android-smartphone als kartenlesegerat einsetzen, 2018.https://www.youtube.com/watch?v=PWF1kEwfQ0Y.

[36] Governikus. Online-ausweisfunktion mit nfc mobil nutzen (iphone/ios), 2019.https://www.youtube.com/watch?v=qArkIGs0cFM.

[37] P. A. Grassi, M. E. Garcia, and J. L. Fenton. NIST Special Publication 800-63-3 Digital IdentityGuidelines. National Institute of Standards and Technology, 2017.https://doi.org/10.6028/NIST.SP.800-63-3.

[38] INTERNATIONAL CERTIFICATION TRUST SERVICES. Itsme - iso/iec 27001:2013certificate, 2017.https://www.itsme.be/files/Certi-Trust-ISO-27001-Certificate-Belgian-Mobile-ID-R1.

pdf.

[39] B. Jacobs. Open brief aan: dhr. R.W. Knops, 2019.https://privacybydesign.foundation/pdf/stas-bzk-aug-19.pdf.

[40] Logius. Koppelvlakspecificatie digid saml, 2016.https://www.logius.nl/sites/default/files/public/bestanden/diensten/DigiD/

Koppelvlakspecificatie-SAML-DigiD.pdf.

[41] Logius. Digid: Hoe werkt het, 2019.https://www.logius.nl/diensten/digid/hoe-werkt-het.

[42] LuxTrust. Available applications, 2019.https://www.luxtrust.lu/en/simple/207.

[43] LuxTrust. The secret image, 2019.https://www.luxtrust.lu/en/article/1443.

[44] LuxTrust. User guides, 2019.https://www.luxtrust.lu/en/simple/565.

[45] D. Meyer. Id card security: Spain is facing chaos over chip crypto flaws, 2017.https://www.zdnet.com/article/id-card-security-spain-is-facing-chaos-over-chip-crypto-flaws/.

52

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/EIDAS/German_eID_Whitepaper.pdf?__blob=publicationFile&v=7

https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/EIDAS/German_eID_Whitepaper.pdf?__blob=publicationFile&v=7

https://bosa.belgium.be/en/publications

https://github.com/Fedict/eid-mw/wiki/Development

http://www.ejustice.just.fgov.be/cgi_loi/change_lg.pl?language=nl&la=N&table_name=wet&cn=2017102211

http://www.ejustice.just.fgov.be/cgi_loi/change_lg.pl?language=nl&la=N&table_name=wet&cn=2017102211

https://www.youtube.com/watch?v=fzbUZmHaZp4

https://www.youtube.com/watch?v=PWF1kEwfQ0Y

https://www.youtube.com/watch?v=qArkIGs0cFM

https://doi.org/10.6028/NIST.SP.800-63-3

https://www.itsme.be/files/Certi-Trust-ISO-27001-Certificate-Belgian-Mobile-ID-R1.pdf

https://www.itsme.be/files/Certi-Trust-ISO-27001-Certificate-Belgian-Mobile-ID-R1.pdf

https://privacybydesign.foundation/pdf/stas-bzk-aug-19.pdf

https://www.logius.nl/sites/default/files/public/bestanden/diensten/DigiD/Koppelvlakspecificatie-SAML-DigiD.pdf

https://www.logius.nl/sites/default/files/public/bestanden/diensten/DigiD/Koppelvlakspecificatie-SAML-DigiD.pdf

https://www.logius.nl/diensten/digid/hoe-werkt-het

https://www.luxtrust.lu/en/simple/207

https://www.luxtrust.lu/en/article/1443

https://www.luxtrust.lu/en/simple/565

https://www.zdnet.com/article/id-card-security-spain-is-facing-chaos-over-chip-crypto-flaws/

REFERENCES

[46] Ministero Dell’Interno. Decreto 23 dicembre 2015, 2015.https://www.gazzettaufficiale.it/do/atto/serie_generale/caricaPdf?cdimg=

15A0980900100010110001&dgu=2015-12-30&art.dataPubblicazioneGazzetta=

2015-12-30&art.codiceRedazionale=15A09809&art.num=1&art.tiposerie=SG.

[47] Ministero Dell’Interno. Specifiche tecniche della carta d’identita elettronica 3.0, 2015.https://idserver.servizicie.interno.gov.it/idp/tutorial_android_chrome.jsp.

[48] Ministero Dell’Interno. Accesso ai servizi in rete mediante la cie 3.0, 2019.https://www.cartaidentita.interno.gov.it/CIE3.0-ManualeSP.pdf.

[49] Ministero Dell’Interno. Carta di identita elettronica - il microprocessore, 2019.https://www.cartaidentita.interno.gov.it/il-microprocessore/.

[50] Ministero Dell’Interno. Come usare cie id su smartphone android, 2019.https://idserver.servizicie.interno.gov.it/idp/tutorial_android_chrome.jsp.

[51] Ministero Dell’Interno. Manuale d’uso del middleware cie 1.3, 2019.https://www.cartaidentita.interno.gov.it/wp-content/uploads/2018/10/CIE3.

0-Manuale_duso_del_middleware_CIE.pdf.

[52] Ministry of Public Administration. Overview of the croatian eid scheme, 2018.https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Croatia.

[53] P. Munoz de Mora. Notification form for electronic identity scheme under article 9(5) ofregulation (eu) no 910/2014, 2015.https://ec.europa.eu/cefdigital/wiki/download/attachments/62885675/

Notificacion%20DNIe_2015_1984_EN%20%286%29.pdf?version=1&modificationDate=

1531759567445&api=v2.

[54] I. Naumann and G. Hogben. Privacy features of european eid card specifications. NetworkSecurity, 2008(8):9–13, 2008.

[55] OASIS SAML Technical committee. SAML wiki, 2019.https://wiki.oasis-open.org/security/FrontPage.

[56] Police and Border Guard Board. Certificate Policy for identity card, digital identity card,residence permit card and diplomatic identity card, 2018.https://www.id.ee/public/CP_ESTEID_01.10.2018_version1.0.pdfn.

[57] RDW. Rijbewijsmodel 2014, 2019.https://www.rdw.nl/particulier/voertuigen/auto/het-rijbewijs/

over-het-rijbewijs/rijbewijsmodel-2014.

[58] Republic of Estonia Police and Border Guard. Estonian eid scheme: Id-card, 2018.https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Estonia.

[59] Republic of Estonia Police and Border Guard. Estonian eid scheme: Mobiil-id, 2018.https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Estonia.

[60] Republic of Estonia Police and Border Guard. Using mobiil-id, 2019.https://www.id.ee/index.php?id=36884.

[61] The European Union. Electronic identification schemes notified pursuant to article 9(1) ofregulation (eu) no 910/2014 of the european parliament and of the council on electronicidentification and trust services for electronic transactions in the internal market. OfficialJournal of the European Union, 2019.https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.C_.2019.309.01.

0009.01.ENG&toc=OJ:C:2019:309:FULL.

53

https://www.gazzettaufficiale.it/do/atto/serie_generale/caricaPdf?cdimg=15A0980900100010110001&dgu=2015-12-30&art.dataPubblicazioneGazzetta=2015-12-30&art.codiceRedazionale=15A09809&art.num=1&art.tiposerie=SG



https://idserver.servizicie.interno.gov.it/idp/tutorial_android_chrome.jsp

https://www.cartaidentita.interno.gov.it/CIE3.0-ManualeSP.pdf

https://www.cartaidentita.interno.gov.it/il-microprocessore/

https://idserver.servizicie.interno.gov.it/idp/tutorial_android_chrome.jsp

https://www.cartaidentita.interno.gov.it/wp-content/uploads/2018/10/CIE3.0-Manuale_duso_del_middleware_CIE.pdf

https://www.cartaidentita.interno.gov.it/wp-content/uploads/2018/10/CIE3.0-Manuale_duso_del_middleware_CIE.pdf

https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Croatia

https://ec.europa.eu/cefdigital/wiki/download/attachments/62885675/Notificacion%20DNIe_2015_1984_EN%20%286%29.pdf?version=1&modificationDate=1531759567445&api=v2



https://wiki.oasis-open.org/security/FrontPage

https://www.id.ee/public/CP_ESTEID_01.10.2018_version1.0.pdfn

https://www.rdw.nl/particulier/voertuigen/auto/het-rijbewijs/over-het-rijbewijs/rijbewijsmodel-2014

https://www.rdw.nl/particulier/voertuigen/auto/het-rijbewijs/over-het-rijbewijs/rijbewijsmodel-2014

https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Estonia

https://ec.europa.eu/cefdigital/wiki/display/EIDCOMMUNITY/Estonia

https://www.id.ee/index.php?id=36884

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.C_.2019.309.01.0009.01.ENG&toc=OJ:C:2019:309:FULL

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.C_.2019.309.01.0009.01.ENG&toc=OJ:C:2019:309:FULL

REFERENCES

[62] M. van Binnenlandse Zaken en Koninkrijksrelaties. Uniforme set van eisen, 2016.https://www.rijksoverheid.nl/documenten/rapporten/2016/12/15/

uniforme-set-van-eisen.

[63] M. van Binnenlandse Zaken en Koninkrijksrelaties. Rijks ICT-dashboard: DigiD Substantieelen Hoog/voorheen Publiek middel, 2019.https://www.rijksictdashboard.nl/projecten/332198.

[64] F. van Krevel. Peer review report – german eid, 2017.https://ec.europa.eu/cefdigital/wiki/download/attachments/48762401/

Peer%20review%20report%20German%20eID%20-%2016062017.pdf?version=1&

modificationDate=1499172190851&api=v2.

[65] F. van Krevel and T. Arik. Peer review report – Luxembourg eID scheme, 2018.https://ec.europa.eu/cefdigital/wiki/download/attachments/62885755/Final%20LU%

20Peer%20Review%20Report%20v1.0.pdf?version=1&modificationDate=1531760306409&

api=v2.

[66] E. Verheul. The polymorphic eidas token. Keesing Journal of Documents Identity, 2017.

[67] E. Verheul and B. Jacobs. Polymorphic encryption and pseudonymisation in identity manage-ment and medical research. 2017.

[68] Vlada Republike Hrvatske. Lista prihvacenih vjerodaj, 2019.https://gov.hr/e-gradjani/lista-prihvacenih-vjerodajnica/1667.

[69] Vlada Republike Hrvatske. Za institucije u projektu, 2019.https://gov.hr/e-gradjani/za-institucije-u-projektu/1552.

[70] Wikipedia contributors. Phishing — Wikipedia, the free encyclopedia, 2019.https://en.wikipedia.org/wiki/Phishing.

54

https://www.rijksoverheid.nl/documenten/rapporten/2016/12/15/uniforme-set-van-eisen

https://www.rijksoverheid.nl/documenten/rapporten/2016/12/15/uniforme-set-van-eisen

https://www.rijksictdashboard.nl/projecten/332198

https://ec.europa.eu/cefdigital/wiki/download/attachments/48762401/Peer%20review%20report%20German%20eID%20-%2016062017.pdf?version=1&modificationDate=1499172190851&api=v2



https://ec.europa.eu/cefdigital/wiki/download/attachments/62885755/Final%20LU%20Peer%20Review%20Report%20v1.0.pdf?version=1&modificationDate=1531760306409&api=v2



https://gov.hr/e-gradjani/lista-prihvacenih-vjerodajnica/1667

https://gov.hr/e-gradjani/za-institucije-u-projektu/1552

https://en.wikipedia.org/wiki/Phishing