Analysis and Comparison of Identification and Authentication

Master Thesis

Analysis and comparison of identiﬁcation and authentication systems under the eIDAS regulation

Author: Floris Roelofs Institute for Computing and Infor- S1029871 mation Sciences, Radboud University, Supervisor: Toernooiveld 212, 6525 EC Nijmegen, Prof. Dr. Eric Verheul NL Second evaluator: Prof. Dr. Bart Jacobs

October 13, 2019

CONTENTS

Contents

1 Introduction 3 1.1 Background...... 3 1.2 Goal...... 3 1.3 Scope...... 3 1.4 Research questions...... 4

2 Methods 5 2.1 Criteria pre-analysis...... 5 2.2 Description of systems...... 5 2.3 Selection of criteria...... 5 2.4 Comparisons and insights...... 6

3 Context 7 3.1 eIDAS - electronic IDentiﬁcation Authentication and trust Services...... 7 3.1.1 European law...... 7 3.1.2 Interoperability...... 7 3.1.3 Notiﬁcation and assurance levels...... 7 3.2 Authentication...... 8 3.2.1 Federated versus non-federated authentication...... 9 3.2.2 Supporting standards...... 9 3.3 PKI - Public Key Infrastructure...... 9

4 Description of systems 11 4.1 Belgium...... 11 4.1.1 Belgian eID Scheme FAS / eCards...... 11 4.1.2 Itsme R ...... 12 4.2 Germany...... 13 4.2.1 German eID based on Extended Access Control...... 13 4.3 Luxembourg...... 15 4.3.1 Luxembourg national identity card (eID card)...... 15 4.3.2 Luxtrust - alternative methods...... 16 4.4 Estonia...... 18 4.4.1 Estonian eID Scheme: ID card / RP Card / Digi-ID / e Residency Digi-ID / Diplomatic Identity Card...... 18 4.4.2 Mobiil-ID...... 19 4.5 Spain...... 20 4.5.1 Documento Nacional de Identidad electr´onico(DNIe)...... 20 4.5.2 Cl@ve...... 21 4.6 Italy...... 22 4.6.1 SPID - Public System of Digital Identity...... 22 4.6.2 Italian eID based on National ID card (CIE)...... 24 4.7 Croatia...... 25 4.7.1 National Identiﬁcation and Authentication System (NIAS)...... 25 4.7.2 NIAS - alternative authentication means...... 26 4.8 The Netherlands...... 27 4.8.1 DigiD...... 27 4.8.2 DigiD Hoog...... 28

5 Criteria for comparison 30 5.1 Usability - service provider...... 30 5.1.1 Federation...... 30 5.1.2 Usage with private service providers...... 30 5.2 Usability - user...... 30

1 CONTENTS

5.2.1 Authentication methods...... 30 5.2.2 Single-sign-on...... 30 5.2.3 Availability of other qualiﬁed trust services...... 31 5.2.4 Accessing past authentication information...... 31 5.3 Privacy...... 31 5.3.1 Privacy hotspots...... 31 5.3.2 Pseudonyms...... 32 5.4 Security...... 32 5.4.1 Security of Communication...... 32 5.4.2 Vulnerability to ‘Man in the browser’ attacks...... 33

6 Comparison 34 6.1 Federation...... 35 6.2 Usage with private service providers...... 36 6.3 Authentication methods...... 37 6.4 Single-sign-on...... 38 6.5 Availability of other trust services...... 39 6.6 Accessing past authentication information...... 40 6.7 Privacy hotspots...... 41 6.8 Pseudonyms...... 42 6.9 Security of communication...... 43 6.10 Vulnerability to ‘Man in the browser’ attacks...... 44

7 Insights 45 7.1 Chapter outline...... 45 7.2 Insights per criterion...... 45 7.2.1 Federation...... 45 7.2.2 Usage with private service providers...... 45 7.2.3 Authentication methods...... 45 7.2.4 Single-sign-on...... 45 7.2.5 Availability of other trust services...... 46 7.2.6 Accessing past authentication information...... 46 7.2.7 Privacy hotspots...... 46 7.2.8 Pseudonyms...... 46 7.2.9 Security of communication...... 46 7.2.10 Vulnerability to ‘Man in the browser’ attacks...... 47

8 Discussion & Conclusion 48 8.1 Conclusions...... 48 8.2 Limitations...... 49 8.3 Further research...... 49

2 1. INTRODUCTION

1 Introduction

1.1 Background

Throughout Europe governments are in the process of making themselves digitally available to their citizens. In 2014 the European Union passed Regulation 910/2014, also known as the eIDAS regulation, which set the goal for all digital governmental services to be interoperable and usable by citizens of other member states. In order to achieve this, the Union has requested the member states to create their systems individually, and created a framework that will link all these systems. This has resulted in some vastly different methods of creating such systems, which has created hurdles in the way of reaching interoperability, such as differing levels of security required for using the systems. An example of such an aspect that the varying implementations differ in, which causes difficulties in the interoperability of the systems, is whether the system is federated or direct. Federated being that there is a usually centralised system which handles the identification and authentication, and direct meaning that there is no such party between the user and the organisation to which they are identifying. The reason for choosing a direct system is that there is no single actor that can know about all the authentication actions of a user. If one entity were to handle all authentications for everything from contact with a municipality to handling medical information, this entity could have control 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 authentication model. On the other hand, a federated system is much simpler to use for service providers, as they do not need to worry about the authentication and all overhead that comes with it. Belgium is among states that have chosen for a federated model. Of course, even among countries that have made 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 of the identification and authentication systems of various European member states. Based on these differences a comparison of the systems will be made, and the reasons that led to these differences will be discussed. The focus will be on three aspects of the systems; privacy of the user, security of the system and usability for both citizens and the service providers, what these aspects entail regarding this research will be described in chapter five. The results of this comparison and the analysis of the differences will lead to possible recommendations for future implementations and improvements to identification and authentication systems.

1.3 Scope

Throughout the Union countries are in various states of production of their systems. Once a member state has finished developing their system they can ask the Union to review the system and assess it on quality and security requirements laid out by the eIDAS regulation. Once a system has been reviewed and deemed acceptable the Union is ‘notified’ of the system, meaning other member states need 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 member states, 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 will be deemed out of scope. Included in the research will be all systems from countries that have completed 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 states are included as well, as the non-notified systems can be a key part of the user experience for the authentication process in those member states. As this research is performed by a Dutch student at a Dutch university, the Dutch system will also be included for ease of access and for the possibility to make recommendations for the Dutch system. The Netherlands is currently still in the development stage for a citizen to government authentication system that will match the requirements laid out by 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 • Belgium • Estonia • Luxembourg • Spain • Italy • Croatia • 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 question. 1. Which characteristics or criteria can be identified as key differences to the identification and authentication systems of the various member states? 2. How do the selected systems and member states rate and compare according to the defined criteria? 3. What recommendations can be made for existing and future identification and authentication systems 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 under eIDAS 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 judged on, a selection of requirements was made from EU implementing regulation 2015/1502 [16], which holds the requirements which all notified systems under eIDAS should adhere to. Alongside requirements from regulation 2015/1502, requirements from a document intended for parties applying to produce a private alternative authentication system for The Netherlands, defined by the Dutch Ministry of the Interior [11] were also taken into account.

Among the two extensive lists all requirements pertaining to the privacy, security and usability of the various implementations were selected. From this subset, requirements that provide little room for interpretation 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 the criteria the systems are compared on.

2.2 Description of systems

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

These various sources were used to deﬁne six key aspects of the systems, starting oﬀ with general information on the system such as its status under eIDAS, responsible authorities and required tools. The general information is then followed by some information on the Encryption and PKI technology used in the system, and the authentication process users of the system must follow. A description of the software tools that are included with the system is made, including information on 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 identity provider in the chain. Finally other relevant details to the privacy, security, and usability of the system 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 for comparison were formed. Diﬀerences noticed between two systems were checked among all systems, and standout features in systems were taken as handholds. The resulting criteria were divided into the categories privacy, security and usability. Some criteria could be argued to ﬁt in more than one category, in this case this was either highlighted in the description of the criteria, or this resulted in a 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 system and visualised in a set of tables. Where necessary additional explanations and clariﬁcations are given with the table, in case the nuances of a systems implementation could not easily be summarised in the table. During the compilation of criteria some inconsistencies in the completeness of descriptions were found and corrected. In the insights chapter trends and other notable discoveries related to the criteria are discussed.

6 3. CONTEXT

3 Context

3.1 eIDAS - electronic IDentiﬁcation Authentication and trust Services

3.1.1 European law

In 2014 the European Commission published regulation 910/2014. This regulation, commonly called the eIDAS regulation, aims to “enhance trust in electronic transactions in the internal market by providing a common foundation for secure electronic interaction between citizens, businesses and public authorities” [14]. Together with implementing regulations 1501/2015 and 1502/2015, these regulations have laid a framework that will enable citizens throughout the Union to authenticate to and communicate with eGovernment services of member states while using an identiﬁcation service of their own member state. For this purpose regulation 1501/2015 lays down technical and operational requirements for the interoperability framework [15], and regulation 1502/2015 lays down the technical speciﬁcations and procedures required for the national eID systems that are to be used in the interoperability framework [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 data the systems must be able to handle and communicate, called the minimum dataset. This minimum dataset is defined in article 11 of regulation 1501/2015, and includes the following attributes, as well as 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 citizen from member state A wishes to identify to the eGovernment of member state B, instead of using the identification system of member state B, this system instead hands off to the “eIDAS Node” for country A. The citizen then authenticates to the authentication system from his home state, and if this succeeds the minimum dataset for the citizen is passed to the system in member state B through the eIDAS node. When the system is fully functional, all member states should have such a node up and running, and connected to the eGovernment services of all the member states participating in the system.

3.1.3 Notiﬁcation and assurance levels

In order to ensure the authenticity of the connections to eGovernment portals, the national authentication 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 implementing regulations 2015/1501 [15] and 2015/1502 [16]. When a member state believes their authentication means are up to the required standard, and wish for it to become a part of the system, they must request notification of the system with the European Commission. When this occurs, an entity overseeing the eIDAS network, called the cooperation 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, staffed with representatives from every member state. From these member states, a small subgroup will be selected 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 can be either low, substantial or high, with each level adding an extra set of demands and requirements that are set for the system. The peer-review will check the system according to the requirements set for the selected assurance level. EGovernment services that are connected to the eIDAS network can set a minimum level of assurance they require, to protect their own system. This allows a member state to set lower demands for services that are less critical or have less privacy concerns, whereas critical systems or those that handle especially sensitive information can be assured of a high level of security. This will block services from being used by citizens if they are authenticating using an authentication system with an insufficient assurance level. When the peer review is completed, and it has deemed that the requirements for the requested assurance level are met, the Cooperation network will review the documents and procedures, and decide whether to publish the notification in the Official Journal of the European Union. After the notification is published, member states have 12 months to start allowing the use of the notified authentication means to their eGovernment services [14].

3.2 Authentication

According to the Oxford dictionary of English [1], authentication is ‘The action or process of verifying the identity of a user or process’. This research is mainly focused on the authentication of users and individuals. The eIDAS regulation defines authentication as follows: “...an electronic process that enables the electronic identification of a natural or legal person, or the origin and integrity of data in electronic 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 uniquely representing 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 multitude of those. The first way is by providing some information only the authentic user could know, usually this is a secret password or personal identification number (PIN). The second way is by proving possession of something only the authentic user possesses, this could be anything as long as the possession is unique to the user, and the party that is being identified to is aware of the exact possession. Examples of such possessions are smart cards and cellphones. The third way is by showing something that is unique to the user itself, this can be done by identifying yourself in person or by recording and providing something that is unique to the user, such as a biometrics like 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 trustworthy or reliable if more factors were used in the process, for this reason systems that are notified under assurance level substantial or high under the eIDAS regulation require at least two authentication factors, 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 authenticate to the service provider. Most commonly this occurs using the ‘something you know’ authentication factor, when the user visits the service provider for the first time they are asked to register a password or PIN, and with every subsequent visit they are asked to provide the same password or PIN in order 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 authentication themselves, or relying on a federated authentication mechanism. Under eIDAS the member states have to develop an authentication mechanism, and the choice for either federated or non-federated has to be made as well. As both methods have their upsides and downsides, both have been employed by differing member states under eIDAS. Federated authentication mechanisms are generally easier to use for the relying service providers, as they hand off the responsibility for the authentication to the central authority in the federation. The downside however is that all information regarding authentication 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 will be mitigated, but the service providers will gain the additional task of managing and maintaining their own authentication system and surrounding infrastructure, such as a helpdesk. In a federated system the entity known as the identity provider handles account management, usually stores information about accounts and handles authentications. When a user wishes to authenticate to a service provider, the service provider refers the user to the identity provider, where the user can authenticate using the account he has with the identity provider. After successful authentication the identity provider sends confirmation of this to the service provider, and provides the account information 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 up such 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 communicating about authentication, allowing identity providers to share authentication information with service providers, including the personal information, also called attributes, of authenticated users. SAML is also embedded in the eIDAS infrastructure, as it is used for the communication with eIDAS nodes [23]. SAML is an open standard, managed by the OASIS consortium and currently on version 2.0 [55]. OpenID connect is not directly a part of the eIDAS infrastructure, but some member 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 support use and interoperability of various “Trust services”. These trust services include digital signatures, digital timestamps, electronic seals, electronic delivery services and website authentication. Articles 21 and up of the eIDAS regulation establish the legal effect and value of these trust services. For instance, article 25 of the eIDAS regulation demands that an electronic signature holds the same legal effect as a handwritten signature [14]. The regulation makes no mention of what exactly an electronic 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 to the other trust services described by eIDAS, there are requirements to their functioning, but not to their implementation. The preface of the regulation shortly refers to the technology that is currently widely 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 data that 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 CA certificate. 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 above the 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 using PGP, and encrypted communication on the internet using SSL/TLS. Most authentication schemes of European Union member states that are being or have been adapted to the eIDAS regulation also make 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 notified in December of 2018, and assigned the assurance level ‘High’ [61]. The system is based around a pair of public key certificates, which are stored on a chip on the users national identity card. The system is fully managed and maintained by the Belgian Government, and currently it can only be used to authenticate with government services. Use of the system by a citizen requires ownership of an ID card, an electronic card-reader and the installation of software that is required for reading the card and communicating with the authentication service. Aside from owning the ID card, the user also needs to request the activation of the certificates stored on the card, this is optional and can 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 one for 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 standard for smart cards [32]. ‘FOD BOSA BG DT’, the Belgian bureau for digital transformation, acts as the root certificate authority. Authentication process Authentication within the system starts with the user navigating to the service they wish to use with their webbrowser. When the user presses the log-in button to initiate the authentication process, they are forwarded to a general log-in portal that will be the same for all connected services. There the user selects his preferred authentication method, the system described here being one of the options. After the eID method is selected, the log-in portal requests the user to connect a card-reader and input their eID. The user then has to select the correct certificate from their eID and enter the corresponding PIN, after which the authentication will be completed and the user will be forwarded back to the service provider they were authenticating to. As this requires both the physical card (possession) and a PIN (knowing), there are two factors required to authenticate. 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, simply named ‘eID middleware’ or ‘eID software’, which handles the authentication process. CSAM is created and maintained by a cooperation of six Belgian governmental entities, including the bureau for digital transformation ‘FOD BOSA BG DT’ and the ministry of the interior. CSAM provides a single authentication interface for all government services, unifying the process and making it easier for users to recognise imposter websites. As CSAM handles the authentication for all government services, and because CSAM employs Single-Sign-On authentication, once a user has authenticated to CSAM he will be able to access all connected services, without having to authenticate to each one individually. Aside from facilitating authentication using the national eID means, this portal is also used for the alternative Belgian eID system Itsme, and authentication using access codes obtained through other means. A user can request a physical token to generate access codes, or choose to receive them through other channels such as a mobile app, SMS or physical mail. These access codes are deemed less secure and the use of these options can only be activated after identifying using the more secure eID option. The various access options are divided into several levels of security, and services that are being identified to can require a minimal level of security, preventing users from accessing their service if insufficient means are used. The software that handles communication with the eID card and the certificates stored within it is an open source solution created and maintained by the Belgian bureau for digital transformation FOD BOSA BG DT. The software allows users to check the certificates on their eID, and when a

11 4. DESCRIPTION OF SYSTEMS user selects the eID authentication method in the CSAM portal, it hands the process over to the software. The authentication process follows a challenge-response protocol in which the authentication 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 a central identity provider, the system is seen as federated. In case the eID is used for identifying with the FAS, the FAS acts as the sole identity provider, but the system also allows for other entities to serve as an identity provider [33]. Belgian law has set a list of requirements to which identity providers must adhere if they wish to be an identity provider for government services. Services that believe they meet these demands can request recognition, and if this succeeds the service can be coupled to the FAS and it will show up as an option in the CSAM login portal for government services. Currently there is only one service that has completed this process, Itsme by Belgian Mobile 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 in turn be acting as an identity provider for the service providers the users choose to use. This system of delegated identity providers makes the identity chain more complicated, which could be cause for security and privacy concerns. The specification for the coupling between the FAS and the third 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 available 24 hours a day that can be called to request a block of the certificates on the ID, to prevent misuse of the card. As only a single authentication action is required to authenticate to every connected service, the system is open to a man-in-the-browser attack, in which malware can make transactions to a service without the user being aware. After a user has authenticated with their eID, other authentication means can also be tied to the users’ 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. Options include a mobile application, a hardware token and OTP received via SMS [18]. Some service providers 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 Belgian eID or a Belgian bank account. The system is based around a mobile application, which has users affirm their identity using a PIN. Authentication with the app checks whether it is still running from the phone it was originally installed on, whether the SIM has changed, and asks the user for their PIN. The system is managed and maintained by Belgian Mobile ID, a consortium of Belgian banks and cellular network providers. In order to start using the Itsme system the user needs to install the mobile application, and prove their identity either by using the signing functionality provided by the Belgian national eID scheme or by proving their identity at an office of their bank. The scheme is currently in the pre-notification stage. Encryption and PKI information At the time of writing the Itsme application is closed source and there is no technical documentation regarding its functioning publicly available. Regarding the security and integrity check, Itsme states that the application confirms the PIN, SIM card and the physical device it is running on. The organisation states that they are in ongoing “cat and mouse game” to prevent users circumventing this security by using cellphones that provide ‘root access’ to their owner, indicating that they are having some trouble with ensuring the authenticity of their users [8]. Authentication process The authentication process using Itsme varies depending on the service the user is authenticating to. In the case of authenticating to a government service, the process starts

12 4. DESCRIPTION OF SYSTEMS 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 of the eID method. When the method is selected the user is forwarded to an Itsme portal where the user is asked to identify by providing their cellphone number, after which the authentication process will continue in the app, where the user provides their PIN. The application will show information on which service the user is authenticating to. When a user uses Itsme to authenticate to a private service provider, the name of the private service provider will be listed. But when authenticating to a government service, Itsme cannot be specific and will tell the user he/she is authenticating to “The online government services”. This is because Itsme does not know which government service the user is authenticating to, and is actually authenticating to all of them due to single-sign-on feature of the government authentication portal CSAM. As the process requires both physical possession of the phone and knowledge of the PIN, there are two factors required to authenticate. When the user has successfully authenticated, the personal information required by the service provider is sent to them by the Itsme network [9]. When identifying to a private company, such as one of the banks part of the Belgian Mobile ID cooperation, the authentication is similar, but instead of using the CSAM portal the various participating companies have their own log-in interface, and use their own Itsme implementation instead of a centralised Itsme portal. Other relevant details In case a user loses their phone or has it stolen, a malicious user should not be able to use it without the correct PIN. The legitimate owner is also able to block their Itsme account 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. The dataset that identifies the user is stored in the Itsme network and sent to the service providers from there, no personal data is stored on the users phone [9]. Logs regarding use of the system by the user will be stored for up to ten years. The Belgian Mobile ID organisation is certified under ISO 27001 [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” was officially notified in September 2017, and assigned the assurance level ‘High’ [61]. The system is based on a stack of authentication mechanisms, which ensures that only parties that are authorised by the German government are able to use the system. The data that users can provide to these parties is stored on a chip in their national identity card. Use of the system by a citizen requires an identity card 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. By design there is no entity or service overseeing the authentication between the user and the service provider, the users prove their identity directly to the service provider. The authenticity of the information provided by users is ensured by the use of public key encryption and signing using certificates managed by the German Federal office for Information Management (BSI) [30]. On the other side, certificates are also used to ensure the authenticity of service providers. This mechanism is also used to ensure only authorised service providers can read the eID, as well as restrict access to certain information stored on the eID, so that service providers can only access the information they 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 services providers that use the system are government entities, but private entities can also request access to the system. Encryption and PKI information For the encryption used by the system, a method has been developed especially for this purpose by the BSI. This method, as the name of the German eID system

13 4. DESCRIPTION OF SYSTEMS implies, is based on the Extended Access Control standard. Extended Access control was developed as a security measure to protect biometric data in machine readable travel documents, also by the BSI. EAC relies on a public key infrastructure to ensure the authenticity of both communicating parties. This process of mutual authentication ensures that only authorised parties with the right certificates can request information from the eID, just like how the fingerprint data on a machine readable travel document can only be accessed using an authorised terminal. The variation on EAC used 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 purpose the PACE protocol is used. Phase two is the mutual authentication phase, this phase uses certificates and challenge-response mechanisms to prove the authenticity of the service provider and the eID in three steps. In step one the service provider signs a challenge sent by the eID with a certificate only available to authorised service providers, this proves the service providers authenticity and its authority to access the eID. In step two the eID sends its certificate so that the service provider can confirm its authenticity and encrypt future communications to the user using the certificate’s public key. In step three the authenticity of the users eID, as well as the possession of the private key, are verified using the chip authentication v2 protocol. This protocol also establishes a secure two-way communication tunnel, using TLS. Then in phase three the access provider can access the data on the eID according to their specified access rights, which is used to check the validity and revocation status of the eID [30]. The BSI acts as the root certificate authority for all certificates used in this process, although different root certificates are used to differentiate between the service provider certificates and the eID certificates. Authentication process On first use of the system, the user has to activate their ID card with the use of a ‘Transport PIN’, which was sent to the user through the post. This process requires the user to set their own six digit PIN. When a user starts the authentication process with a service provider, the user is asked to open their authentication software. In the software, the user can see what information is being requested, and by whom. As the service providers need to be licensed to use the system, this license can also be seen, indicating which personal information the service provider can request and for what purposes they may do this. From this point the user can either deny or accept the request. If the user accepts the information request, they must scan their eID and provide their PIN, after which the authentication process will be completed and the information will be sent to the service provider [34]. The eID can be scanned with either a dedicated cardreader connected to the computer, or with a 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 to access the service provider, the smartphone also needs to be connected with the same local network as the computer. When the app and software are coupled, the smartphone can open the connection with 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 provided by the German government. The choice was made to not make a single software solution and force users to use this, instead a specification is provided, and anyone may make software that can be used for the authentication process. The government does provide a certification process for such software, and recommends only using certified solutions [30]. Currently, there is only one certified solution, called ‘AusweisApp 2’.

14 4. DESCRIPTION OF SYSTEMS

AusweisApp 2 is made by the company Governikus Gmbh, which is owned by the local government of the German city Bremen. The application is available for Windows and Mac OSX, and also has companion mobile applications for iOS and Android. The desktop software can be used for the authentication process, has a directory of all coupled service providers, an option to see previous authentications and can be used to change the PIN of the users eID. The companion smartphone apps provide 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, meaning all identification and authentication communication occurs directly between the citizen and the service provider. This means all service providers are tasked with maintaining the functionality in their 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 to alleviate this problem, the German government has started allowing service providers to outsource the authentication, effectively turning the system into an optional hybrid of federated and direct authentication [28]. Other relevant details Every German eID can provide a pseudonym that can be used to identify to some service providers, instead of the personal identification data on the card. The pseudonym is 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 their pseudonyms will also change, with the German eID expiring every 10 years. When used in the eIDAS system, the pseudonym will be unique to each member state, and will be supplied with the minimum dataset [30]. In order to prevent service providers being able to track and monitor the authentication behaviour of users, the certificates on the eID are also not unique or bound to the user or 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 it disabled. 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 the revocation 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 system is based around a pair of public key certificates, which are stored on a chip on the users national identity card, which can be read using Near-Field-Communications (NFC) technology. The system is 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 public key infrastructure, whereas the government handles the processes regarding the issuance of the eID cards and the certificates they contain. The government of Luxembourg is one of the key shareholders for LuxTrust, as well as the Luxembourg national bank and a set of other private and semi-governmental entities. In order to use the system, a user needs to possess a Luxembourgish identity document, for which activation of the certificates has been requested, as well as an electronic card-reader and installed software required for the authentication process. Encryption and PKI information The exact workings of the encryption and PKI behind the Luxembourg national identity card is kept confidential. According to the peer review report, the communication between the identity server and the eID card follows a proprietary version of the ChipGateway Protocol [65]. The ChipGateway protocol is an open standard under OASIS, the

15 4. DESCRIPTION OF SYSTEMS standard itself is based on the specification for the eID client provided for the German eID implementation and was co-developed by Luxtrust [24]. Authentication process On first use of the eID card, the user must set a 6 to 8 characters long PIN, which will be required to authenticate from then on. The user must also provide an image on first use of the system, this image will be used as a ‘secret image’ and will be shown to the user every time they enter their PIN. The authentication process itself starts when the user starts the authentication process with the service they wish to use, usually on their website. When choosing to authenticate on a website that uses LuxTrust, the user will be forwarded to the LuxTrust authentication portal. At the LuxTrust authentication portal the user is prompted to select which authentication tool they wish to use, among which the eID is one option. The other tools are out of 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 user to 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 for the 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 not enter their PIN and cancel their authentication. After the PIN is entered the authentication will be completed 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 package that 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 and other information stored on smartcards, the tool can be used to check card contents and change the PIN. The included version is specific for the Luxembourg eID, but the difference between this version 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 communication between the authentication server and the users’ eID, and provides the user interface when the user has to select their certificate and enter their PIN. The software is closed-source and produced by LuxTrust. After installation, unless the user changes this behaviour, the software will be active at all 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 authentication using the eID, some require other means provided by LuxTrust [42]. This not only applies to private service provider but also to some governmental service providers. Recently LuxTrust added the described ‘secret image’ feature, LuxTrust states this was added in order to comply with new legislation [43]. As the feature was recently added it is not in the documentation provided to the cooperation network and has not been reviewed by other member states. Luxembourg does not provide functionality to sign documents or use other eIDAS qualified trust services, the user documentation and help website however does provide guides on how to use the eID 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, including electronic signatures, timestamping, sealing and SSL certificates, but not regularly to users of the Luxembourg national identity card.

4.3.2 Luxtrust - alternative methods

Aside from using the eID as a means of authentication, the Luxembourgish authentication service LuxTrust also provides access to Luxembourgish services using the following other means: • Smartcard • Signing Stick

16 4. DESCRIPTION OF SYSTEMS

• Hardware token • LuxTrust Scan • LuxTrust Mobile Although the means are all provided by LuxTrust, they can not all be used for authentication with every service, some service providers have opted out of allowing certain means [42]. LuxTrust has shown no intention of having these means notified under eIDAS. Regarding the functionality of the devices, they can be divided in three groups, the functionality and other details will be explained per 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 are as 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 LuxTrust authentication portal. 3. The LuxTrust authentication portal shows the means that can be used to access the visited service provider, the user must click the one they wish to use. 4. After clicking the correct authentication method the means specific authentication process is initiated. The means specific steps will be described in the following sections, aside from the steps for the eID means as this was explained in its own section. Hardware token The hardware token is a small physical device with a button and a screen. When the button is pressed the screen will show a One-Time-Password for use with authenticating. To start using a token a user must buy it from LuxTrust and pair it with his account, LuxTrust will pair it with a trusted certificate managed by them. After the authentication process is initiated as above, the user is asked to provide their LuxTrust username and password. After the username and password are entered correctly, the user is asked for a One-Time-Password, to be generated by the token. The screen asking for the OTP will also show the users’ secret image, an image the user has shared with LuxTrust previously, the user must confirm 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 forwarded back to the service provider they were accessing. LuxTrust Scan & LuxTrust Mobile LuxTrust Scan and LuxTrust Mobile provide OTP in a manner quite different from the token, the method is the same for these two methods. LuxTrust Scan and the LuxTrust mobile app rely on reading a QR coded provided during the authentication process, and will generate an OTP based on the data in the QR code. LuxTrust Scan is a dedicated device featuring a camera and a touchscreen that can do no more than read QR codes and generate OTPs. LuxTrust Mobile is a mobile application for iOS and Android that provides the exact same functionality. After the authentication process is initiated as above, the user is asked to provide their LuxTrust username and password. After the username and password are entered correctly, the user is asked for a One-Time-Password and shown the QR code needed to generate it. The user must then scan the QR 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 forwarded back to the service provider they were accessing. Smartcard & Signing stick The smartcard and signing stick are qualified electronic signature creation devices that function similarly to the eID. The main difference between the smartcard and the signing stick is that they are not under the direct responsibility of the Luxembourgish

17 4. DESCRIPTION OF SYSTEMS government. There is also a diﬀerence in the way the devices are connected, where the eID can be read using NFC technology, the smartcard requires a diﬀerent kind of cardreader that makes contact with contactpoints on the chip. The signing stick does not require a reader at all and can simply be inserted into an available USB port. The software used and the authentication process using these two devices are entirely identical to that of the Luxembourgish eID, described in a previous section.

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 Identity card were officially notified in November of 2018, and assigned the assurance level ‘High’ [61]. Due to the similarity of the functioning of these systems they will be described as if they were a single system from here on. In the documentation provided to the eIDAS Cooperation network a sixth system “Mobiil ID” is also included with these systems, but as the functionality of that system is significantly 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 on the chip of the various cards of the system. The system is fully managed and maintained by the Estonian government, with some tasks being outsourced to the private company Idemia. The system can be used to authenticate to both eGovernment services and private service providers including banks, hospitals, universities and many more. Use of the system by a citizen requires ownership of one of the various cards, such as an ID card or an e-Residency Digi-ID, an electronic card-reader and the installation of software that is required for reading the card and communicating with the authentication service [58]. Encryption and PKI information The system relies on two user bound X.509 certificates for the authentication and signing, one for each purpose. Communication with the certificates on the 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 government has 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 ID card or other relevant card into a card reader, and the card reader into his computer. Then when the user browses to a service provider and chooses to authenticate, the browser will ask the user to select a certificate for the authentication. After the certificate choice is confirmed, the user is asked to enter their pin for the selected certificate. Upon correctly entering the PIN, the authentication completes 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 and provides signing and encrypting functionality. Paired with DigiDoc4 comes a tool that provides functionality for another eIDAS trust service, timestamping with TeRa Client. These two tools are available for Windows, Mac OSX and Linux. The final member or members of the suite are the browser extensions that allow use of the signing functionality within the browser, these extensions are available for Internet Explorer, Edge, Mozilla Firefox and Google Chrome. DigiDoc4 was created by the Public company Aktors on behalf of the Estonian Information Systems Authority, 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 certificates and 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 4. DESCRIPTION OF SYSTEMS signing functionality packages the document to be signed in a standard ASiC-e container for signed documents, the DigiDoc4 client can also be used to check the signature information. The encryption functionality requires the user to select one or more recipients, after the encryption only these recipients will be able to decrypt the document using their personal certificates. Federation Authentication using this system uses direct communication between the service provider and the citizen and their identification document, there is no federation handling the authentication for the service providers. Due to this, single-sign-on is not an option and users are required to authenticate separately to each service provider they wish to use. Other relevant details The system also functions when using an ID-card issued by neighbouring countries Finland and Latvia. The ID-card keeps track of how many authentication actions have been taken with the card, helping users detect possible malicious use of the card. The system has a very low implementation effort for service providers that wish to allow authentication using the system, 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 the Estonian identity cards were generated, this flaw meant that the private keys of certificates could be calculated from the public key in a feasible amount of time. Worldwide an estimated 1 billion chips were affected, among them around 800,000 used in the described Estonian eID cards. The Estonian government required everyone with an affected identity document to renew their certificates, which could 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, who were producing the identity documents before this incident, and switched to the French company Idemia.

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 also notified under eIDAS with the assurance level high [61]. The system is similar to these card-based systems, but instead of storing the certificates on an identification document they are stored on a SIM card. This SIM card acts as the second “possession” factor instead of the ID. In order to use the system a citizen must request a supported SIM card from their cellular provider, and then activate the certificates on the card using their ID or equivalent card. Use of the card is similar to that of the other Estonian systems, but instead of inserting the eID into a card reader and providing their PIN on the same computer as is being used for accessing the service provider, a mobile phone is used for reading the card and entering the PIN [60]. One added security feature that is provided in this system but not when using one of the card-based Estonian systems, is that Mobiil-ID will provide information as to what service provider the citizen is authenticating to. Before entering their PIN, the user is also shown a randomly generated control number on both the website of the service provider and on the cellphone, the user must make sure these match. This is another measure to help 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 an API that only provides confirmation to the service provider. This step seems to be taken because a separate connection needs to be made with the SIM of the user. This has effectively turned this system into an identity and authentication federation.

19 4. DESCRIPTION OF SYSTEMS

4.5 Spain

4.5.1 Documento Nacional de Identidad electr´onico(DNIe)

The Spanish eID system, officially titled “Documento Nacional de Identidad electrónico(DNIe)”, was officially notified in November of 2018, and assigned the assurance level ‘High’ [61]. The system is based around a pair of public key certificates, which are stored on a chip on the users national identity card. The system is managed and controlled by the the General Secretariat of Digital Administration in the Ministry of Finance and Public Function, and the information on the identity card is provided and validated by the national police [53]. The system can be used to authenticate to government services, and to electronically sign documents. Use of the system by a citizen requires ownership of an ID card, an electronic card-reader and the installation of software that is required for reading the card and communicating with the authentication service [19]. The cardreader can be either a dedicated device or an NFC enabled Android smartphone. Aside from owning the ID card, the certificates on the card must also be active in order to use the system, the certificates can be disabled at the request of the user, are automatically revoked when the card expires, and when the certificates themselves expire. The certificates will expire 60 months after enrolment, so most users 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 states mentioned previously, with the eID containing different certificates for two purposes, authentication and signing. The national police acts as the root certificate authority. The function, storage and many 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 secure communication channel according to the EN 419212-1:2014 standard, which achieves mutual authentication, and a combination of RSA, AES, DES and SHA256 for the various cryptographical components [53]. Authentication process The authentication process starts with the user choosing to authenticate with DNI on a supported website. In order to start the process, the user must already have connected a 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 selecting the correct certificate, the user is prompted for his/her PIN, and after the PIN is correctly entered the 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 two factors. Software tools The system does not include a software package that provides a user interface for the authentication or the management of their certificates. The only necessary software is a driver that allows the cardreader to read the eID. All user interaction is provided by existing certificate handling functionality in the operating system and web browser the user chooses to use. The drivers are available for Windows, Mac OSX and Linux. The choice of browser that the user can use with the 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, installation of software called DNIeRemote is required on both the smartphone and on the computer. After installation the software can connect either through USB or Wi-Fi. The software only provides one functionality, and that is reading the eID, in this case the smartphone is also used for entering the PIN [20]. To sign documents using the eID, the Spanish government also provides a software solution. This solution is called AutoFirm@ or AutoFirma. Autofirma is an open source tool that is provided and maintained by the Centre for Technology Transfer and Innovation [10], which is overseen by the Ministry for Territorial Administrations. The tool allows users to select a compatible document, such as a PDF file, select a location to show the signature in the document and then select the certificate to use for the signature and enter the required PIN. After following these steps the document will be

20 4. DESCRIPTION OF SYSTEMS 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 provider and the citizen and his/her eID, there is no federation handling the authentication in-between. Due to this, single-sign-on is not an option and users are required to authenticate separately to each service provider they wish to use. Other relevant details Certain management tasks such as refreshing the certificates or changing the PIN can not be done from home, but must be done at certain offices of the local government or at a “DNI Update Point” [19]. The Spanish eID cards were affected by the same vulnerability as described with the Estonian system, this led to the Spanish government revoking the certificates from 17 million cards [26][45].

4.5.2 Cl@ve

Cl@ve or Clave, is an alternative authentication system available for use with digital government services in Spain [2]. Use of the system requires the user to first register using the aforementioned DNI authentication method, as well as a mobile phone-number, which will be used to send codes to use as a second authentication factor. It is also possible to register for Clave at a registration office, or online with an invitation letter, these methods however are seen as a less secure and will provide access to fewer services. Clave, just like DNI, is managed and controlled by the the General Secretariat of Digital Administration in the Ministry of Finance and Public Function. Spain has shown no sign it intends to notify the Clave service. Encryption and PKI information This system relies on the DNI system and in-person identification to authenticate newly registered users. After registration the system functions as any other username and password authentication service, so there are no additional communication steps with physical tokens or PKI systems. Authentication process There are three ways Clave allows users to authenticate, authentication using only a password, using only a one-time-password sent via SMS or a mobile application, or using 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 the system, and only for certain services that require a lower level of security. When one has enrolled for this 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 of their DNI, or if they do not possess this, their tax identification number (NIE). Together with this number the user selects whether they wish to receive their one-time-password through the app or through SMS. If the user selected receiving through the mobile application, the user then receives two codes, an identifier and a password. When these codes are successfully entered the authentication is complete. If the user selected receiving through SMS, the user is then asked to enter either the identification number and expiry date of their DNI, or the identification number and ‘support number’ of their NIE. The one-time-password will be sent to the phone-number linked to that identity. If the user successfully enters the one-time-password within ten minutes the identification will be complete. The authentication method using only a password is quite straightforward, it functions just like any other username/password system, with the username being either the unique identifier of the users DNI or their NIE. The two factor password and verification code option is an extension of this method, and it is set as the minimum security standard for some services, meaning the aforementioned 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 verification code through SMS, and after entering this the authentication is complete. Federation Clave identifies itself as a federated authentication management system [12], stepping in as a central identity provider between various governmental service providers and the citizens

21 4. DESCRIPTION OF SYSTEMS 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 their national authentication means [3]. Part of the system makes it so users only need to sign in once if they wish to use multiple services that are part of the federation, also known as single-sign-on. Although this is positive for the usability of the system, this opens the systems and its users to attacks on multiple services when signing on to 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 officially notified 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 different assurance levels, this includes one method at assurance level low, two methods on assurance level substantial and one method at assurance level high. The Agency for Digital Italy is responsible for the 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 require using a either mobile phone or a time-based security token, and the high assurance method requires either a hardware token, a smartcard and cardreader or some other device or service holding a trusted 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 separate eID 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 authentication, only one method makes use of certificates and PKI, aside from setting up the HTTPS connection with the users web browser, which occurs with all methods. SPIDs most secure authentication option relies on a pair of X.509 certificate, which can be stored on a variety of devices such as smart cards and hardware security modules. The knowledge and possession of the private key of the certificates is tested using TLS client authentication. Authentication process The SPID recognises three levels of security in their methods of authenticating. The user does not decide which level of security to use while logging in, the only option is always the minimum security level required for the selected service provider. On level one is a simple username and password system, to use this on a supported service provider a user must select the option to enter using SPID, and then select the identity provider the user wishes to use. Upon the selection the user will be forwarded to the authentication system of the selected provider, where they will be prompted for their username and password. When those are entered correctly, the user will be informed of which data will be sent to the service provider, and is asked to confirm this to

22 4. DESCRIPTION OF SYSTEMS complete the authentication and be sent back to the service provider’s website. Security level one in 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 diﬀerence between the two methods is that in one the OTP is sent via SMS, while in the other it is generated in a mobile application. The start of the process is the same 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 be forwarded to the authentication system of the selected provider, where they will be prompted for their 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 be informed of which data will be sent to the service provider, and is asked to conﬁrm this to complete the authentication and be sent back to the service provider’s website. The documentation for the system provided to the Cooperation Network also describes a system where the OTP is sent through a phonecall, but none of the Identity Providers have implemented this. Security level two in SPID corresponds to assurance level substantial in eIDAS.

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

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

Federation As mentioned before, SPID runs a federated model where the user can choose from nine separate 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 SAML 2.0 standard, using the ‘Web Browser SSO’ profile, in which all communication passes through the user and the authentication process is initiated from the service provider’s platform [5]. Becoming such an identity provider is controlled by the Agency for Digital Italy and requires the company to adhere to a list of requirements and be certified for ISO 27001 and ISO 9001, the implementation of these requirements and certificates are checked during an accreditation by the Agency for Digital Italy when an identity provider becomes part of the system, and conformity is checked again every two years [6]. After an identity provider is accepted into the federation, it will also need to pass the requirements related to the eIDAS regulation in order to be notified and provide authentication services across the Italian border.

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

23 4. DESCRIPTION OF SYSTEMS through online video chat. This was seen as something that could not be permitted in a system with a ‘High’ assurance level by the peer reviewers of the eIDAS cooperation network, to which the responsible parties stated that they would remove the possibility. It is currently still possible with some 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 use an authentication method relying on OTP sent through SMS at the assurance level high. Due to the low 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 technology has deﬁned methods relying on public switched telephone networks (PSTN) to be ‘restricted’, and that 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 reﬂected in the authentication methods section of this description, this feedback was implemented and the SMS based authentication method was relegated to 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 officially notified in September of 2019, and assigned the assurance level ‘High’ [61]. The system is based around the national identity card, which stores certificates for authentication, and can communicate using Near-Field-Communication (NFC) technology. Unlike most other eID based systems, the system does not provide electronic signature functionality. The system is managed and maintained by the Italian ministry of the interior, with some tasks such as enrolment being handled by the municipalities and the State Mint and Polygraphic Institute [46]. Use of the system by a citizen requires 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 used to authenticate to both governmental and private service providers [48]. The first time a citizen uses their card they need to activate it, this is done by entering their full eight digit PIN. Any authentication 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 using the SHA256 and RSA encryption algorithms [47], of which the Italian eID holds one. Communication with the eID occurs using PKCS #11. The card itself is compliant to the ISO 7816 standard for smart 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 is similar to most other ID document based authentication systems. The process starts with the user placing their ID on their connected NFC reader and navigating to the service provider they wish to authenticate to. There they select the option to identify with CIE, upon this selection the user is forwarded to the CIE authentication webpage. On this page the users web-browser will ask them to select the right certificate, users can recognise their certificate as its name includes their tax payer ID. 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 will be 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 to and ask the user to input their PIN. After inputting the PIN the user is asked to hold their ID by their phone so the NFC connection can be made with the card. If the PIN is correct for the ID card the authentication will be completed and the user will be sent back to the website of the service provider [50]. Software tools Two software tools are part of the CIE authenticaton system, the desktop software for Windows and OSX, and the mobile application for Android.

24 4. DESCRIPTION OF SYSTEMS

The desktop systems are open source projects managed by the Agency for Digital Italy, the software provides functionality to activate the card, change the pin and unblock a card that had the wrong PIN entered three times. The software includes a tutorial as well. When authenticating the software is not required, the system uses standard functionality in the supported web-browsers and operating systems for the menus where the user selects their certificate and enters their PIN. Installation and preparation of the software for use is straightforward in most cases, with one exception. When a user wishes to use the software in combination with the Mozilla Firefox web-browser, the user needs to navigate to advanced options within Firefox and change the PKCS #11 module to the one that comes with the middleware. Aside from this the user also needs to pre-select the CIE certificate they wish to use for authenticating. The steps required to change and set these options are well documented for the user [51]. The mobile application ‘Cie-ID’ is made under co-operation by the State Mint and Polygraphic institute and Fondazione Bruno Kessler, a research foundation founded by the Trento provincial government. The mobile application is only available for Android and not for iPhone because of limitations to the NFC communication set by Apple. The application provides the same functionality as the desktop middleware. To authenticate with the app, the user must be using the Google Chrome browser to navigate to the service provider they wish to use, other browsers are currently not supported [50]. Federation The CIE runs on a federated system where the Italian ministry of interior acts as the sole identity provider. The federation communicates according to the ‘SAML 2.0 Web Browser SSO Profile’ standard [48]. This standard puts the user at the centre of all communication, there is no direct 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 authentication using the CIE, in contrast to the over 700 services supporting SPID. The documentation for service providers includes functionality to show users which data exactly will be shared with the service providers before they finish authenticating, but this does not seem to be implemented at this time.

4.7 Croatia

4.7.1 National Identiﬁcation 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 system is based around a pair of public key certificates, which are stored on a chip on the users national identity card. The system is fully managed and maintained by the Croatian government, specifically the Agency for Commercial Activities and Production (AKD), which falls under the Croatian ministry of the interior. The system can only be used to authenticate to government services [69]. For a citizen to use the system requires possession of an eID, a compatible cardreader and the installation of certain middleware on a computer. The system also provides access through a variety of other methods and identity providers, but these are separate from the eID system and will be discussed in 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 the functioning of their system. What is known is that NIAS communicates according to a SAML standard, and that the system is certified according to the extensive requirements of the Common Criteria version 3.1 [52]. Authentication process The authentication process using this system can start when a user visits one of the supported government websites using a supported web-browser. On the website, the user

25 4. DESCRIPTION OF SYSTEMS can click the log-in button, which will take them to the NIAS authentication portal, where they can select the credentials they wish to use to authenticate. Among this list, the first option is to log-in using 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 correct certificate, and then input the PIN set for that certificate. The user should choose for the certificate that is stored on their eID, when this is done and the PIN is entered correctly the authentication will 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 support their authentication capability. First is the middleware, which facilitates the communication with the 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 some management software called AKD eID Client. AKD eID Client provides functionality to activate the certificates on an eID, view basic card information, view certificates, change the PIN, unlock a PIN 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 authentication 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 authentication will continue from there. Aside from showing the authentication means this page will also show which level of assurance the various means provide, with these levels being based on the definitions provided by STORK [68]. The page will only show authentication means which provide a sufficient level 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. This tool, ‘mojID’ or myID in English is an online portal that allows users to see what authentications have been made with their various authentication means. Aside from this the portal also provides some functionality to change contact information or cancel an account. Federation In this authentication system NIAS is acting as an identity provider for various government services, which allows using the eID to authenticate to a limited selection of the service providers that rely on NIAS as their authentication provider. Aside from using the eID as a means of authentication with NIAS, NIAS also allows using other means of authentication, and even integrates other identity providers. More detail on this will be provided 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 supports a wide variety of authentication means. This includes other means provided by AKD, such as certificates and OTP tokens, but also companies coupling their existing account system to act as an identity 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 the other half by private companies, mostly banks and a single telecommunications provider. None of these 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 Croatian eID in the section above, but when one of the 22 other methods is selected a pop-up appears in which the authentication process specific to the selected method will occur. After this is completed the NIAS will receive confirmation that the authentication was successful from the identity provider and the user will be forwarded to the service provider they were authenticating to.

26 4. DESCRIPTION OF SYSTEMS

The technical details of the authentication will vary per method, but the communication between the 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-notified and thus is not assigned an assurance level at this time. The system currently supports a variety of authentication 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 and maintained 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 companies including health insurers and pension funds. The system allows one factor authentication based on 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 referred to as ‘DigiD basis’, whereas the two factor methods are referred to as ‘DigiD midden’, the mobile application based ‘DigiD midden’ method can also be used for a higher level of security referred to as ‘DigiD substantieel’, referring to the eIDAS assurance level ‘substantial’ [41]. Encryption and PKI Authentication with DigiD follows the SAML 2.0 standard and communication between service provider and identity provider is encrypted with two way SSL [40]. The only information provided by DigiD to the service providers is the users personal identification number (BSN) and the level at which they authenticated, the service providers keep the users data in their own databases or acquire it elsewhere. The current implementation of DigiD does not rely on certificates under control of the user. Authentication process All three authentication methods start off with the same steps; a user browses to a service provider and chooses to authenticate, if the service only serves natural persons the user will be forwarded to the DigiD login portal. If the service also serves businesses the user will have to choose between authenticating with DigiD or eHerkenning, a Dutch identity provider for businesses. When the user selects DigiD they will be forwarded to the DigiD login portal. The first choice the user has to make in this portal is the authentication method, if the service provider allows it the choice to use an accountname and password is available, the other options will be to log 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 be prompted for their accountname and password. If these are entered correctly the authentication is 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 will similarly be prompted for their accountname and password. When these are entered correctly the user will be sent an OTP by SMS, this SMS will also contain the name of the service provider the user is authenticating to. After the OTP is correctly entered the authentication is completed and the user is forwarded to the service provider. When the user chooses the mobile application option the user will be asked to enter a ‘koppelcode’ or coupling code, a new koppelcode can be requested in the DigiD app. After entering the koppelcode the portal will show a QR code, to be scanned by the DigiD app, when this code is scanned the application 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 PIN is entered in the mobile application the authentication is complete and the users webbrowser will be forwarded back to the service provider. If the user initiates this authentication method on the same mobile device that holds the mobile application, the steps for entering the koppelcode will be skipped.

27 4. DESCRIPTION OF SYSTEMS

The mobile application based method can also be raised to the higher security level of ‘DigiD substantieel’, this can be done by using the application to scan the users’ ID, passport, or drivers license. Doing this once will enable ‘DigiD substantieel’ authentications for all future authentications with that installation of the application. Software tools There are two tools provided to the users’ of DigiD; the aforementioned DigiD mobile application, and the online portal Mijn DigiD. The DigiD application is provided by the ministry of the interior, is available for iOS and Android, and provides limited functionality. Primarily it can be used for the authentication process described above, aside from this it also contains a rudimentary support page for troubleshooting problems with DigiD. If the device it is installed on has NFC functionality, the device also contains functionality to scan an identity document, and use this to further verify the identity of the owner and enable the ability to authenticate on the level ‘DigiD substantieel’. The second tool, Mijn DigiD is a management portal for the users’ DigiD account. The tool is in the form of an online portal where users can manage their DigiD account. The functionality provided by 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 acts as 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 DigiD called ‘DigiD hoog’, the authentication method is currently not available, but some information regarding its functionality is. The system will be based around the Dutch identity card and driving license, 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 chip and application have started being circulated in 2018 [57]. The Dutch government intends to notify DigiD 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 that should 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 steps in 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 the key belonging to a speciﬁc service provider. As the identity provider can only adapt the ciphertext to be decrypted by a service provider, the identity provider at no point has access to the identity of the 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 restructure the 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 4. DESCRIPTION OF SYSTEMS centralised federation in which there is only one identity provider, but with DigiD hoog the system is 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 include pseudonym 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 the pseudonym.

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 negative effects on the system. As was discussed prior in chapter three, one of the positives is in the amount of implementation effort and other overhead required for the relying parties. If a service provider can use a federated authentication system versus a direct system, many tasks outside of the service providers 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 notiﬁed eID means as their identity provider. The ability to use the eID means for a larger amount of services motivates citizens to use it more and thus supports the adoption of the system, while also providing users with secure authentication methods for these services. Aside from the usability improvements for the user, allowing usage with private service providers can help spread the costs of the authentication problem 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 authentication methods were observed. Many relying on using a computer and a card-reader, some on a computer and a smartphone, and others. Letting users choose a method they trust and are comfortable with is beneﬁcial to the user experience, so this criterion will index which options are available with which systems.

5.2.2 Single-sign-on

Some federated identification and authentication systems provide single-sign-on functionality. This means that once the user has authenticated with the identity provider, they will not have to authenticate 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 regarding security. One downside is that this system is less restrictive to man in the browser attacks, the malware no longer needs to fool the user into signing into a different service provider, as they are already authenticating to all service providers simultaneously. Man-in-the-browser attacks and their relation to single-sign-on will be discussed further with the ‘Vulnerability to man in the browser attacks’ criterion. Some also question if single-sign-on should be allowed under eIDAS for systems that are notified with the assurance levels substantial or high. Substantial and high require the use of at least two authentication factors, but when using single-sign-on, after the first authentication, the following authentications occur based on the existence of a ‘cookie’. One could argue that the checking of this cookie is an authentication process relying on a single factor.

30 5. CRITERIA FOR COMPARISON

5.2.3 Availability of other qualiﬁed trust services

Aside from setting a framework for international authentication within the European Union, the eIDAS regulation has also laid legal grounds for a set of other electronic trust services, namely qualified electronic signatures, qualified timestamps, electronic seals, registered delivery services and website authentication. The demands to and implications of these services are laid out in chapter three of the eIDAS regulation [14]. Some member states have provided the tools for use of some of these services with the software provided for the authentication system. As the following chapter will show, this was limited to electronic signatures, electronic timestamps and electronic seals. Including these tools provides citizens with a method to learn about and use these trust services, helping them protect their security when using these trust services for their communication and transactions. This criterion will be focused on the inclusion of signing certificates on the national eID, as well as the availability 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 are usually 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 member states have implemented options that allow users to view past authentications made with their authentication means. Such functionality ideally informs the user on when an authentication was made including a time and date, as well as to which service provider. This will help users take timely measures if their identity has been misused, or be certain that it was not misused when they are in doubt. Getting full information on the use of authentication means in your name can be increasingly complex in member states with multiple identity providers or even multiple means. If a malicious actor manages to enroll for a means of authentication using someone else’s identity, without the victim knowing, the victim can not be expected to check the authentication history of this means. Ideally this is solved by providing a facility where citizens can check which means are registered under their name. But as such extraneous facilities fall out of the scope of this research, their existence with the relevant member states Belgium, Estonia, Spain and Italy were not extensively researched. Although during the regular investigation of these member states’ systems no documentation on such a system was found. The future implementation of The Netherlands DigiD Hoog which will include multiple identity 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 being federated can also have great effects on the privacy of the system. To reiterate what was mentioned in the context chapter, a federated identity provider takes over the identification and authentication tasks for service providers, thereby improving the usability for these service providers. A problem with such a system however is that all identification and authentication traffic for these service providers will pass through a single identity provider. This could cause a hotspot of privacy sensitive data in a single place, which becomes even more sensitive and valuable due to the aggregation of information, while also introducing a single point of failure. A federated identity system does not have a privacy hotspot by definition. To prevent a privacy hotspot in a federated system there are two options. The first option is to make the identity provider blind to what service provider the user is authenticating to. In this case the federation does know which users are authenticating and when, but not to which service provider, which greatly reduces

31 5. CRITERIA FOR COMPARISON the sensitivity of the information the federation has access to. The second option is to make the identity provider blind to what users are authenticating. In this case the federation does know what service providers are being authenticated to, but does not know the identity of the users that are authenticating. With this option the federation does not hold identiﬁable personal information at all, completely mitigating the privacy hotspot.

5.3.2 Pseudonyms

With the enforcement of the General Data Protection Regulation beginning in 2018, the demands and requirements for the handling of sensitive personal information have greatly increased. Article 32 of the GDPR demands that organisations ‘implement appropriate measures’ to ensure the security of personal information, and the ﬁrst example of a measure to achieve this mentioned in the GDPR is pseudonymisation [17]. With the amount and types of data that are handled by government services and the corresponding identity providers, possibly including ‘special categories of personal information’, the use of pseudonymisation in such systems seems warranted. The use of pseudonymisation in such systems would allow users to access a service provider without providing their actual personal information. This provides users with extra Privacy towards that service provider, and makes it harder if not impossible to couple data from diﬀerent service providers.

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 requires identification and authentication mechanisms to include security measures to prevent “guessing, eavesdropping, replay or manipulation of communication” [16]. In the analysis of the various systems various measures were found to increase the security of communication. One measure taken in those systems is to use PKI to encrypt traffic using the trusted certificate of the service- or identity provider. This measure will aid to prevent guessing, eavesdropping, replay and manipulation of communication. Phishing is a form of attack that can not easily be prevented with such measures however. ‘Phishing is the fraudulent attempt to obtain sensitive information such as usernames, passwords and credit card details by disguising oneself as a trustworthy entity in an electronic communication [70]. For example, a malicious actor sets up the website mygovernnent.nl, made to look exactly like the government website mygovernment.nl. The malicious actor will then convince citizens to log in through his website, having them believe they are accessing the real government website. Any user that does not notice this discrepancy will enter their credentials believing they are communicating with a legitimate actor, but they are actually sending their credentials to a malicious actor who can then assume their identity. To protect against phishing, what must be achieved is that the user can be sure that the party they are communicating with are who they say they are. In federated systems this is achieved by using a unified authentication portal, users are taught how to recognise this portal and not to enter their information anywhere else. In direct systems users will have to authenticate on many different websites, which will make it harder for users to recognise false websites which are set-up to gather users’ credentials. Direct systems must achieve this surety through other means, and that is by limiting the parties that can use the authentication system. In such a system, during the authentication process, the eID and the service provider mutually exchange certificates. The user of course provides theirs to prove their identity, and the service provider provides their certificate to prove they are authorised

32 5. CRITERIA FOR COMPARISON to use the system and to possibly allow the user to conﬁrm themselves they are engaging with the intended service provider. This process is commonly called mutual authentication, and the eﬀect is that, just like with a federation, users can be sure that they are communicating with a party that has 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 of the user as the attack vector, thereby circumventing encryption and other defences occurring when data 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 access to more than one service. This brings the possibility for malware to make it appear like the user is authenticating to a certain service, while actually authenticating to another, and using this authentication for illicit transactions or acquiring personal information. The requirements to authentication systems under eIDAS laid out in implementing regulation 1502 of the European Union [16] for systems notified at assurance level substantial or higher demand implementation of measures to protect against attackers with a moderate attack potential. The extension 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]. There are multiple possible design decisions that can be taken that will help users recognise or prevent a Man in the browser attack, or instead make it harder to recognise or prevent such an attack. One such design decision that makes it harder for users to detect a man in the browser attack is the availability of single-sign-on functionality. If one authentication will immediately provide access to all service providers to the user, it will also do this for malware, meaning it no longer has to trick the user into accessing a different service provider than they were intending to access. A precaution that can be taken to help users recognise and prevent a successful man in the browser attack, is to have the user check and confirm the action they are taking through a second channel. Usually the second authentication factor is used for this. For instance, an SMS with an authentication code will not only contain the code, but also state for which service provider the code is being used. This could also be done within an app or on the screen of a card-scanner if this is available. This precaution can not be taken in conjunction with single-sign-on, as then the authentication will always be for every service provider. A third design option that could help users detect a man-in-the- browser attack after the fact is the previously discussed functionality to see and review historical authentications.

Figure 1: Conﬁrmation of authentication in the Itsme app

33 6. COMPARISON

6 Comparison

This chapter will contain various tables, each showing how the various systems perform on the criteria listed in chapter ﬁve. The tables will contain the systems and member states in the order they were described in chapter four. For clarity, the following table will show which systems belong to 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 Luxembourg / LuxTrust

Estonian eID / Estonia Mobiil-ID

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 Federated / LuxTrust

Estonian eID Direct

Mobiil-ID Federated

Spanish eID Direct

Cl@ve Federated

SPID Federated

Italian eID Federated

NIAS Federated Including Croatian eID

DigiD Federated

DigiD Hoog Federated

The German eID is based on direct authentication in its original design. But changes to the system have allowed service providers to outsource the handling of the authentication process to other companies, 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 Yes / LuxTrust

Estonian eID / Yes Mobiil-ID

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 Computer and Computer Computer and Computer Smartphone

cardreader smartphone and SMS OTP device only 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 Yes Yes* Yes* Yes* No Yes* / LuxTrust

Estonian eID / Yes Yes No No No Yes Mobiil-ID

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 the smartphone is used as a cardreader for the computer, or used to generate an OTP or other form of access code. All methods marked with ‘*’ are methods that are currently not notiﬁed and thus not usable for cross-border authentication.

37 6. COMPARISON

6.4 Single-sign-on

Single-Sign-On

Belgian eID Yes

Itsme Yes*

German eID No

Luxembourg eID No / LuxTrust

Estonian eID / No Mobiil-ID

Spanish eID No

Cl@ve Yes

SPID Yes*

Italian eID No

NIAS Yes* Including Croatian eID

DigiD Yes*

DigiD Hoog No

Itsme does not have Single-Sign-On by design, but due to the sequential identity provider structure of 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 assurance/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 Yes No No / LuxTrust

Estonian eID / Yes Yes Yes Mobiil-ID

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 their eID, the required certiﬁcates 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 No / LuxTrust

Estonian eID / Yes* Mobiil-ID

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 review past authentications, but as these transactions are stored locally in the software it is of no use if the identity theft was committed on a different computer. Aside from this the option can easily be turned off 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 does not provide a list, but instead keeps a counter. Every time a users eID is used to authenticate the counter increases, and the user should notice if the counter has increased too much between uses. 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 Yes LuxTrust / LuxTrust

Estonian eID No and variants

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 a secondary identity provider to the Belgian eID system, so although Itsme does not have a privacy hotspot by design, all authentications to government services using Itsme pass through the Belgian eID 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 outsource the handling of the authentication process to other companies, essentially creating decentralised federated 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 have no 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 privacy hotspot. The Spanish Cl@ve systems runs on a federated model without mitigation for a privacy hotspot. The Italian SPID system has a decentralised federation model that allows users to use more than one authentication provider simultaneously. If a user chooses to do this it alleviates some of the concerns for the privacy hotspot, as their authentication data can not be combined easily. But each identity 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 model without mitigation for a privacy hotspot. The future DigiD Hoog system will run on a decentralised federational model, in which the identity providers 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 No / LuxTrust

Estonian eID / No Mobiil-ID

Spanish eID No

Cl@ve No

SPID No

Italian eID No

NIAS No Including Croatian eID

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 Yes Yes / LuxTrust

Estonian eID Yes No and variants

Mobiil-ID Yes Yes

Spanish eID Yes Yes

Cl@ve Yes Yes

SPID Yes Yes

Italian eID Yes Yes

NIAS Yes Yes Including Croatian eID

DigiD Yes Yes

DigiD Hoog Yes Yes

As federations have an active relationship with their relying parties, they are expected to prevent malicious actors from using their platform. The direct identiﬁcation and authentication systems; the German eID, the Estonian card based systems and the Spanish eID, have to rely on other means to ensure to their users the service providers do not misrepresent themselves. The German and Spanish eID have achieved this through mutual authentication. The Estonian system on the other hand, is entirely open to service providers, and thus can not rely on this measure, which results in it being the only system to fail this criterion.

43 6. COMPARISON

6.10 Vulnerability to ‘Man in the browser’ attacks

Measures taken SSO Service provider conﬁrmation

Belgian eID Yes No

Itsme Yes* No*

German eID No Yes

Luxembourg eID No No / LuxTrust

Estonian eID / No Only in Mobiil-ID Mobiil-ID

Spanish eID No No

Cl@ve Yes No

SPID No* Yes

Italian eID No Only with mobile application

NIAS No* No Including Croatian eID

DigiD No* Yes

DigiD Hoog No Yes

Itsme does not provide single-sign-on by default, and does inform the user of which service they are 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 between them and Itsme, a single authentication action will still be an eﬀective single-sign-on for those services in particular. Thus there is no eﬀective countermeasure to a man in the browser attack when authenticating with Itsme to governmental service providers. SPID, NIAS and DigiD do allow Single-Sign-On, but only with service providers that require a low assurance 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 countries and 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 authentication models than for direct authentication. Germany’s change to a hybrid system shows that a direct system might cause too much overhead for service providers, Estonia has circumvented this by relying on simpler and already widely available technology, and Spain has limited itself to governmental service 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 as governmental ones. There is however still a distinction to be made among those countries, regarding the strictness of allowing service providers to become a part of the system. Italy’s SPID and Estonia’s systems stand out as especially open, being integrated with many private service providers. On the other end of the spectrum are The Netherlands and Germany, as their systems seem to be usable with 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, with every member state offering authentication methods for desktop and mobile. There is some variation in countries offering alternative One-Time-Password methods, but with some systems being strictly eID based this is understandable. Looking at this criterion from a security perspective, it is notable that four systems are offering authentication methods relying on OTP sent through SMS. As discussed in the description of the Italian SPID system, this method is seen as quite vulnerable to attacks, so it is recommended not 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 level substantial.

7.2.4 Single-sign-on

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

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 the authentication systems. Only four member states have provided tools to their citizens to help them make use of such trust services, with Spain, Luxembourg and Belgium remaining limited to document signing, and Estonia including document signing, document sealing and timestamping. The table might mislead you to thinking that at least Estonia has provided tools for all trust services, but as no member state has provided the tools for registered delivery services and website authentication these were omitted from the table.

7.2.6 Accessing past authentication information

Reviewing past authentications seems to be somewhat of an overlooked feature among authentication systems. Many systems do not include the feature, and those that do often make little note of it in their documentation. In case a users identity is stolen, it can however be of great help to ﬁnd out what 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 all European citizens the right to access personal information concerning them, in combination with requirement 2.4.4 from implementing regulation 1502 [16] which requires member states to store and retain authentication information for purposes of auditing and investigation of security breaches, one would expect that more authentication systems would have such a system in place. But it seems that citizens wishing to review their authentication data will have to follow a more diﬃcult process to 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 no measures to prevent this. A select group of member states have set up direct authentication systems which have prevented the problem, of which at least Germany has stated it is one of their reasons for doing so. The Netherlands’ future DigiD hoog system is the only system taking a diﬀerent path to preventing the occurrence of a privacy hotspot, which is by using polymorphic encryption and pseudonymisation. This PEP system ensures identity providers only receive and pass on encrypted user 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 demands of the GDPR and it’s privacy by design demands and taken them into account in their authentication system, which is Germany and their eID system. The future Dutch system will follow suit when it becomes available, and outside of the scope of this research other member states are also thinking of 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 minimum security standard of encrypting communicaton, although it might not be fair to credit the eIDAS regulation for this, as systems that are not notiﬁed also manage this. The second part of this criterion checks whether systems can provide surety to their users that only legitimate parties can make use of the system, which is key in preventing replay attacks. Most countries have achieved this due to being based on a federated system, in which relying parties are in an active relationship with 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 only certiﬁed parties can make use of the system. Which leaves only Estonia, which has made no obvious measures 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 consistently have implemented both preventative measures in their authentication systems. The Belgian system and the Spanish non-notiﬁed Cl@ve system stand out in the opposite way, featuring Single-Sign-On without having the user conﬁrm what service provider they are communicating with, leaving their users 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 authentication systems of European Union member states, and make recommendations for the upcoming Dutch system and other future identification and authentication systems, if notable discoveries were made. The research has resulted in detailed descriptions of eleven identification and authentication systems from eight member states, and compared them across ten criteria. These ten criteria can be taken as the answer to the first research question; ‘Which characteristics or criteria can be identified as key differences to the identification systems of the various member states?’. The descriptions show that the systems among member states show many similarities, indicating that 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 selected based on differences in the systems, criteria that showed no notable differences among systems were discarded. 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 differences were found, most notably, but not limited to, the ten selected criteria. The second research question, ‘How do the selected systems and member states rate and compare according to the defined criteria?’, has resulted in the comparisons and insights described in chapter six and seven of this paper. Which leaves research question three, ‘What recommendations can be made for existing and future identification and authentication systems based on these discoveries?’, and its two sub-questions focusing on the Dutch system and authentication systems under eIDAs in general. As for the future Dutch system, based on the information that is already available, this system was also included in comparisons where possible. In the comparisons the upcoming system, DigiD Hoog, fared well. The system achieved a perfect score within the privacy criteria, as well as with the 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 perfectly in 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 security reasons. One of the categories in which DigiD Hoog was left out, is one which warrants a recommendation for DigiD and other existing and future authentication systems under eIDAS. The criteria that saw some of 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 trust services, three of which only for a single selected service. The eIDAS regulation has laid a legal foundation 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 governments of member states could assist their citizens by helping them make use of these trust services by providing useful software, documentation and qualified certificates. A recommendation for other future and current authentication systems is in the option for users to inspect their past authentications. The comparison shows six out of the eleven authentication systems do not have this feature, even though it can be a useful tool for users that have fallen victim to identity theft. The Estonian system has shown such a feature does not need to be complex nor does it require centralised tracking of authentication attempts. Although the implementations in federated systems can provide the full functionality, and thus the full benefit to the user.

48 8. DISCUSSION & CONCLUSION

The ﬁnal recommendation stems from the criterion which was least implemented among the authentication systems within the scope of this research. This criterion is the availability of pseudonymisation. Pseudonymisation can be a key feature in helping citizens protect their privacy, and for this reason 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 the functionality 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. Between member states and systems within member states there are large discrepancies to how much and how easily documentation and other information is available. In some cases this was caused by systems being entirely closed source, in other cases it was a lack of documentation easily available to the public. Notable systems in this regard were on the one hand the German system, which is extremely well documented with lots of documentation provided by the BSI. On the other hand was Luxembourg, which opted to not provide any technical documentation, and keep all documentation it provided to the eIDAS cooperation network conﬁdential. If more information was available across all systems this could have provided more grounds for comparison, resulting in more comparison criteria, especially in the categories privacy and security. Basing a comparison of user experience strictly on documentation is also somewhat limited, ideally the research should have had access to all systems and the ability to perform user experience testing with real users, allowing for use of more rigorous methods. Such methods would have helped create a 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, repetition of this research with the cooperation of the member states and the various actors that manage the systems could be warranted, in order to create more detailed descriptions and more extensive comparisons. Once all member states have notified systems a repetition of this research with a more complete scope regarding the member states could also be warranted, to reach a complete overview and comparison of all identification and authentication systems under eIDAS. As this was an exploratory research, more in depth research regarding the privacy, security and usability of the systems could be performed. Although I would recommend separating the categories into different research, as there is plenty to discuss regarding all three topics. As mentioned in limitations, usability could go more in-depth by obtaining access to all the systems and performing full usability reviews. Privacy and Security could both benefit by full co-operation from the managing parties 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 with more than one means of authentication, such as Italy or Belgium, there seems to be no straightforward way to check which means have already been registered to your name in any of them. This would mean that if someone’s identity would be stolen successfully and used to register with one of the means the citizen is not already using, there would be no simple way of finding this out. Future research could take a broader scope of the authentication experience in a member state, and find out if this is possible in any member states, and what the implications of not having this option would be.

49 REFERENCES

References

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

[2] AdministraciónElectrónica.Cl@ve Identificación,2019. https://administracionelectronica.gob.es/ctt/clave.

[3] Administraci´onElectr´onica. 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, usluˇznoi trgovaˇcko. Akd eid middleware - eid client korisniˇcke 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 aﬁrma, 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-notiﬁed and notiﬁed eid schemes under eidas, 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 identiﬁca- 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 interoperability framework pursuant to article 12(8) of regulation (eu) no 910/2014 of the european parliament and of the council on electronic identiﬁcation and trust services for electronic transactions in the internal market, 2015. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ%3AJOL_2015_235_R_0001.

50 REFERENCES

[16] Council of the European Union. Council regulation (EU) no 1502/2015 on setting out minimum technical specifications and procedures for assurance levels for electronic identification means pursuant to article 8(3) of regulation (eu) no 910/2014 of the european parliament and of the council on electronic identification and trust services for electronic transactions in the internal market, 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 of natural persons with regard to the processing of personal data and on the free movement of such 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] Direcci´onGeneral de la Polic´ıa.Dni electr´onico. https://www.dnielectronico.es/PortalDNIe/PRF1_Cons02.action?pag=REF_100&id_ menu=1.

[20] Direcci´onGeneral 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 Ambient Computing 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 speciﬁcation 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 online id function, 2019. https://www.personalausweisportal.de/EN/Business/eidas_compliant_remote_ signature/eidas_compliant_remote_signature_node.html.

51 REFERENCES

[30] Federal oﬃce 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 speciﬁcations handbook related to the royal decree of recognition of partner’s electronic identiﬁcation services, 2017. https://bosa.belgium.be/en/publications.

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

[33] Federale overheidsdienst beleid en ondersteuning. Koninklijk besluit tot vaststelling van de voorwaarden, de procedure en de gevolgen van de erkenning van diensten voor elektronische identiﬁcatie 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 kartenleseger¨ateinsetzen, 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 Identity Guidelines. 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:2013 certiﬁcate, 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. Koppelvlakspeciﬁcatie 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 ﬂaws, 2017. https://www.zdnet.com/article/id-card-security-spain-is-facing-chaos-over-chip-crypto-flaws/.

52 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. Speciﬁche tecniche della carta d’identit`aelettronica 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 identit`aelettronica - 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. Mu˜nozde Mora. Notiﬁcation form for electronic identity scheme under article 9(5) of regulation (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 speciﬁcations. Network Security, 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. Certiﬁcate 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) of regulation (eu) no 910/2014 of the european parliament and of the council on electronic identification and trust services for electronic transactions in the internal market. Official Journal 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 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 Substantieel en 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 management and medical research. 2017. [68] Vlada Republike Hrvatske. Lista prihva´cenihvjerodaj, 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.