# Real-World Identification for an Extensible and Privacy-Preserving Mobile eID

Michael Hölzl, Michael Roland, René Mayrhofer

► To cite this version:

Michael Hölzl, Michael Roland, René Mayrhofer. Real-World Identification for an Extensible and Privacy-Preserving Mobile eID. Marit Hansen; Eleni Kosta; Igor Nai-Fovino; Simone Fischer-Hübner. Privacy and Identity Management. The Smart Revolution: 12th IFIP WG 9.2, 9.5, 9.6/11.7, 11.6/SIG 9.2.2 International Summer School, Ispra, Italy, September 4-8, 2017, Revised Selected Papers, AICT-526, Springer International Publishing, pp.354-370, 2018, IFIP Advances in Information and Communication Technology, 978-3-319-92924-8. 10.1007/978-3-319-92925-5_24. hal-01883623

HAL Id: hal-01883623

https://inria.hal.science/hal-01883623

Submitted on 28 Sep 2018

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
Real-world Identification for an Extensible
and Privacy-preserving Mobile eID

Michael Hölzl¹, Michael Roland², and René Mayrhofer¹

¹ Insitute of Networks and Security, JKU Linz, Austria,
hoelzl@ins.jku.at, mayrhofer@ins.jku.at

² University of Applied Sciences Upper Austria, Hagenberg, Austria
michael.roland@fh-hagenberg.at

**Abstract.** There is a broad range of existing electronic identity (eID) systems which provide methods to sign documents or authenticate to online services (e.g. governmental eIDs, FIDO). However, these solutions mainly focus on the validation of an identity to a web page. That is, they often miss proper techniques to use them as regular ID cards to digitally authenticate an eID holder to another physical person in the real world. We propose a mobile eID which provides such a functionality and enables extensibility for its use with numerous different public and private services (e.g. for loyalty programs, public transport tickets, student cards), while protecting the privacy of the eID holder. In this paper, we present a general architecture and efficient protocols for such a privacy-preserving mobile eID that allows identity validation in a similar fashion as regular ID cards and makes carrying around various physical cards unnecessary.

# 1 Introduction

Many governments already provide their citizens with an electronic identity (eID) infrastructure to handle administrative tasks like doing taxes or applying for subsidies (cf. survey of European governmental eIDs by Lehman et al. [16]). However, they lack appropriate methods to allow eID holders to use the eID in a privacy-preserving manner. In our terms, such a privacy-preserving eID gives the prover (i.e. the eID holder) the capability to only reveal and prove the validity of certain attributes to a verifier. For example, an eID holder wants to prove to the bouncier at a disco that she is above 18 years old without revealing the name or even the actual date of birth. Furthermore, a privacy-preserving eID should also not leak any usage behavior to the verifier (e.g. how often does a specific eID holder enter the disco).

There are existing solutions for such a privacy-preserving eID, where the most recent ones are based on attribute-based credentials (ABCs) [7, 8]. ABCs allow eID holders to prove a subset of their personal data attributes (e.g. age, name, citizenship) without revealing the full set. They have already been actively used for pilot studies in the ABC4Trust project [4,21] and have been implemented on smart cards [3, 11, 23]. Alpár and Jacobs [2] discuss the difficulties of such ABC systems (which applies to smart card-based identity systems in general):
- Controlling attribute access for verifiers requires either additional technical restrictions (i.e. let each verifier get a signed list of readable attributes from the identity manager), legal restrictions (i.e. in order to read attributes, verifiers must have valid contracts), or additional monitoring on the card.

- Verifying that the person presenting the smart card is the actual eID holder requires additional communication channels (e.g. picture on the card).

- The usage of PIN protection for smart cards ensures confidentiality, user consent and authentication, but adds additional complexity (e.g. the PIN may have to be entered in every verification on the card reader of the verifier).

One possible solution to these issues of smart card-based eIDs is the usage of a mobile eID. Although existing ABC technologies could already be ported to run on mobile platforms (e.g. Jensen's smart phone feasibility study of ABC4Trust [15]), there are additional challenges which have to be considered: (i) Mobile devices can easily be stolen and an adversary could attempt to take over the identity. (ii) The mobile device can run out of battery or (iii) has no online connectivity.

We envision a privacy-preserving mobile eID which addresses these challenges and allows eID holders to use it in a similar fashion as regular ID cards to prove their identity (we refer to this as *real-world identification*). Verification of an identity should even work with a turned-off prover device and in an offline setting, while the integrity of the eID should be protected with additional tamper resistant hardware. And finally, the mobile eID should be usable for multiple public or private services. We refer to these services as *domains* and use a loyalty program in a shop as an example use case throughout this paper (other examples would be public transport tickets, student cards, etc.) In this paper we describe the general architecture of such a mobile eID scheme and propose protocols to enroll to numerous domains and verify data attributes in an efficient way. The architecture allows to provide proofs of single eID attributes in a privacy-preserving manner and builds upon state-of-the-art technologies in that field.

## 2 Related Work

A specification for eIDs that has recently become famous is provided by the FIDO Alliance [9]. This consortium aims to improve the usability of user authentication on the internet by reducing the reliance on passwords. With one specification for biometric authentication and one for two-factor authentication, they provide schemes for secure identity verification to any online service.

Concerning governmental eIDs, the survey by Lehman et al. [16] about eIDs in the European Union shows that current systems do not provide sufficient privacy-preserving verification methods. Only the Austrian and German eID cards support notable features protecting the privacy of the user (i.e. generation of pseudonyms, selective attribute disclosure).

Nyman et al. [18] define a governmental and privacy-preserving eID architecture that is based on the use of so-called Trusted Platform Modules (TPM). They build upon version 2.0 of the TPM specification and evaluate its feasibility as an identity token on PC as well as mobile platforms. Similar to our concept,
their system relies on additional tamper resistance hardware in computing devices. The mobile eID solution by Otterbein et al. in [19] also involves additional tamper resistant hardware. Their scheme uses a trusted execution environment on Android devices to enter secret information of the user and get access to the content of this additional hardware.

ABCs [5–7] build the basis for another field of research in the area of privacy-preserving eID schemes. In an ABC scheme, a credential is referred to as a cryptographic container for multiple attributes. An attribute, on the other hand, is a property about a person that some trusted authority attested. Most important technologies in that field are Identity Mixer (Idemix) [14], developed by IBM Research, and Microsoft’s U-Prove system [20]. In addition, the ABC4Trust project defines a common, unified architecture that uses multiple ABC protocols for a privacy-preserving verification on any platform [4,21]. The benefit of ABCs is that besides ensuring authenticity and integrity of eID attributes, it also provides some privacy guarantees for credential owners. That is, it allows the eID holder to prove certain predicates of an attribute without revealing the actual content. Moreover, each verification of a single eID appears unrelated and can therefore not be linked by a verifier. In other related work, it has already been proven that ABCs can also be implemented on smart cards [3, 11, 23].

## 3 Threat Model

We consider two general types of adversaries in a privacy-preserving eID: (i) A malicious prover trying to forge or steal an identity. This would allow an attacker to adapt single data attributes for an attack (e.g. modify the age or place of residence), impersonate someone else, or even result in digital identity theft (e.g. take over mail and bank accounts). (ii) Malicious verifiers who try to compromise the privacy of an eID holder. We assume that this adversary has the capability to eavesdrop on all eID verification processes and attempts to:

- Misuse data. As information is processed digitally, users cannot be sure that the data they transmit to a verifier is adequately protected, only used for the claimed purpose (of identification), and not stored or passed on to other parties. Hence, in order to protect their privacy it is important that as little information as necessary is given to potentially malicious verifiers.

- Tracing identities. An adversary could use the digital information provided by the eID to trace activities of an eID holder. For example, the disco bouncers or the public transport system could track all identification processes and therefore trace all activities of a single user.

- Linking pseudonyms. A system that provides pseudonymity shall not allow verifiers to link single pseudonyms to each other. For example, a shop, where the user is enrolled in a loyalty program, should not be able to derive, link, or determine other pseudonyms of the user.
## 4 Extensible and Privacy-preserving Mobile eID

We propose a privacy-preserving mobile eID that has the flexibility to be used as a regular identification document and for the use by numerous services. More specifically, besides protecting the privacy of the user, this eID provides:

- Real-world identification. The mobile eID can be used as a replacement for regular ID cards and can be used for identification and verification of attributes (e.g. age of the eID holder).

- Extensibility. The eID can also be used for numerous different services with the possibility to derive pseudonyms. A service provider can therefore easily and rapidly establish their own e.g. loyalty program on top of our eID system.

- Capable for offline and turned-off devices. The prover mobile device does not need to be powered on in order to verify the identity of the eID holder and no constant online connectivity to a central server shall be required.

### 4.1 Stakeholders

Figure 1 depicts the proposed eID architecture consisting of four stakeholders:

- The *eID issuer* is the central authority that controls the enrollment of new eIDs and provides an interface to acquire the public system parameters for eID verification (e.g. governmental authority in a nationwide eID).

- The *prover* is the actual owner of the eID and consists of a mobile device equipped with a secure element (SE). Communication to the SE can be done directly over near field communication (NFC) or through the eID management application (eID-MA) on the mobile device.

- The *domain manager* is responsible for controlling the enrollment of a prover to a specific *domain* (i.e. a service). A domain may have additional attributes associated to an eID or require a pseudonym for the prover.

- The *verifier* can be anyone who wants to verify attributes of the eID holder (e.g. disco bouncers). They can also be domain members (referred to as *domain verifier*) and read domain-specific attributes (e.g. loyalty card membership).

### 4.2 Building Blocks

Our architecture combines several techniques. That is, we make use of secure elements for the protection of sensitive data and use ABCs to verify the eID in a privacy-preserving manner as well as authenticate an additional secure channel:

**Secure Elements (SE)** Our architecture assumes the existence of a trustworthy SE on the prover's device. An SE is usually shipped as an embedded integrated circuit in mobile devices together with NFC [17] (e.g. as a SIM card) and brings two main security advantages: (i) it protects against unauthorized access as well as tampering, and (ii) small applications (applets) can be executed directly on the card in the trusted execution environment. Another advantage of SEs is
<figure><img src="image_2.png" /><figcaption>Fig. 1: General architecture of the proposed mobile and extensible eID system.</figcaption></figure>

that they can be powered by the NFC field when the prover device is turned off (provided that the NFC controller in the prover device supports this feature).

In our eID scenario, the SE shall protect the identities of the eID holders as well as their attributes. All computations that require these data need to be performed within the SE. However, the constrained execution performance and memory on the SE have strong implications on the protocols and architectural design of the eID system (see performance evaluation in [12]). Our proposed architecture acknowledges these requirements and can be executed within this secure but constrained environment in reasonable time. That is, we assume that a user is not willing to wait for more than 2 seconds to finish a task.

**Attribute-based Credentials (ABCs)** In our proposed architecture, we use ABCs for attesting the validity of the eID in a privacy-friendly way. We assume the following properties of ABC: (i) With a selective disclosure mechanism, the holder of the credential can reveal any subset of attributes and provide a validity proof of them (i.e. they have been attested by the trusted authority); (ii) Ownership of a credential can be proven without revealing the attributes itself; (iii) Verification of credentials are unlinkable to verifier and issuer.

In order to protect against replay attacks, the selective disclosure mechanism allows the verifier to send a random challenge. The prover responds to this with a non-interactive-zero-knowledge (NIZK) proof, which is also a signature of this challenge. Using this mechanism, we establish an authenticated secure channel as described in [1], and therefore introduce a simple notation for selective disclosure:

$$ \pi = SD(\mathcal{A}, ch), \qquad (1) $$

where $\mathcal{A}$ is the subset of disclosed attributes from a credential and $ch$ is the random challenge.
The downside of ABCs is the higher complexity of issuing attributes and
creating proofs. Although they have been successfully deployed on smart cards
(i.e. execution on SE also possible) [3, 11], they are still considerably slower than
ordinary signature schemes and can become the bottleneck in a privacy-preserving
eID system. For example, Vullers and Alpár report the results of a RSA-based
1024 bit smart card implementation of the Idemix technology in [23]. Disclosing
and creating a proof for only one credential (with 4 attributes) takes already
1 second on the used MULTOS cards (incl. overhead). They also indicate that
increasing the security level to a 2048 bit modulus would more than double the
computation time. Furthermore, we assume that a regular transaction requires
more than 4 attributes and that a user is not willing to wait for more than 2
seconds for the identification. Hence, for our use cases, the performance of an eID
system solely based on ABCs is not sufficient. We therefore propose a system that
only requires a single selective disclosure operation in any verification process.

## 4.3 Extensibility and Privacy-preserving Mechanisms

A central component of our architecture is the potential usage of the eID for
numerous services (e.g. loyalty card program). With simplicity as a major goal,
it should thereby be easy for service providers to integrate with our system and
for eID holders to control the data attributes that can be read by verifiers. We
define three main mechanisms for that purpose:

**Profiles** In order to give the user control over the data, we introduce the concept of profiles to the mobile eID architecture. A profile defines data attributes which are accessible for a specific purpose or a group of verifiers. For example, an age verification profile where only the date of birth and the portrait picture are accessible (for the disco bouncers use case). The management application (eID-MA) running on the mobile device of the prover maintains these profiles and stores them on the SE. It is also possible to associate one profile with a domain in a trust-on-first-use (TOFU) database. This enables the user to remember data attributes that can be retrieved by specific domain verifiers.

**Trust-on-First-Use (TOFU)** Each SE of an eID holder possesses a TOFU database with information about enrolled domains. The basic idea is that the trust relationship between an eID holder and a domain manager is established at the first encounter. The eID holder then stores the public key of this domain in the TOFU database and only trusts verifications for that domain where the verifier can proof the possession of the private key or demonstrate a certificate signed with this private key. An entry in the database consists of the identifier (i.e. public key) of the domain $D_{id}$ and a profile, which defines the attributes a domain verifier can query. In addition, there might be additional attributes stored for that specific domain (e.g. validity of loyalty program membership). As a positive result of this mechanism, it is relatively simple for domain managers to integrate with our eID scheme. That is, they do not require additional, and potentially complex, authorization by a central administration.
**Domain Pseudonyms** An eID holder that enrolls to a number of domains has unlinkable pseudonyms for each of them. They are derived from the identity of the eID holder as well as the identifier of the domain manager and can be used for domain-specific identification (e.g. for bonus point system in loyalty programs). We use a mechanism that does not require additional space on the SE. It also provides the capability for multiple devices of an eID holder to derive the same pseudonym for a specific domain.

# 5 Protocols

The protocols in our scheme use profiles for easy attribute selection and build upon ABCs to validate the eID as well as authenticate an additional secure channel. This secure channel is used to efficiently transfer the data attributes of the profile to the verifier. In addition, we introduce a simple mechanism to derive domain pseudonyms, which do not require additional space on the SE, and a TOFU database to store domain-specific profiles and attributes on the prover device (i.e. the SE). The notation of the protocol is listed in Table 1.

## 5.1 Setup

During setup, every involved party receives the public system parameters of the used ABC system as well as the elliptic curve parameters. Every domain manager creates a public/private key pair ($d_{sk}, D_{id} := d_{sk} \cdot G$), where the public key $D_{id}$ also serves as the domain identifier, and defines a list $la_d$, which specifies the attributes they want to access from a user. Each verifier generates a key-pair ($v_{sk}, V_{pk} := v_{sk} \cdot G$) and the TOFU databases of each SE are empty.

<table><caption>Table 1: Notation used in this paper.</caption><tr><td>id<sub>u</sub></td><td>Secret identifier of the user.</td></tr><tr><td>da<sub>u</sub></td><td>Data attributes of the user.</td></tr><tr><td>C<sub>u</sub></td><td>ABC key credential of user u for eID validation.</td></tr><tr><td>N<sub>u,d</sub>, n<sub>u,d</sub></td><td>Derived domain pseudonym and the corresponding secret key.</td></tr><tr><td>G</td><td>Elliptic curve generator point.</td></tr><tr><td>D<sub>id</sub>, d<sub>sk</sub></td><td>Public/private key-pair of domain manager d.</td></tr><tr><td>la<sub>d</sub></td><td>List of attribute identifiers which a domain d wants to access.</td></tr><tr><td>V<sub>pk</sub>, v<sub>sk</sub></td><td>Public/private key-pair of verifier v.</td></tr><tr><td>ca<sub>v,d</sub></td><td>Certificate of domain verifier v.</td></tr><tr><td>H(m)</td><td>One-way hash function over message m.</td></tr><tr><td>Enc(K, m)</td><td>Symmetric encryption of message m using key K.</td></tr><tr><td>Sign(sk, m)</td><td>Signature creation over message m with private key sk.</td></tr><tr><td>SD(A, ch)</td><td>Create a NIZK proof of an attribute-set A in a given ABC, while using the random challenge ch.</td></tr></table>
## 5.2 Prover Enrollment

There are two types of enrollment: eID and domain enrollment. The enrollment of the eID can only be done once for every SE while the domain enrollment is only limited to the available storage space for the TOFU database on the SE.

**eID Enrollment** During the initial eID enrollment, the SE of the prover and the eID issuer communicate in a secure channel using GlobalPlatform card management [10]. The eID-MA acts as a proxy between them. The process is initiated by the eID holder and presumably involves an additional out-of-band identity verification (the detailed steps of this enrollment are out-of-scope of this paper). We assume that during this process the SE acquires the secret identifier $id_u$ and the data attributes of the eID holder $da_u$. The SE also acquires an ABC key credential $C_u$ from the issuer, which is used to validate the eID and authenticate an additional secure channel with the method described by Alpár and Hoepmann in [1].

**Domain Enrollment and Pseudonym Derivation** An example scenario for this enrollment would be an eID holder who would like to join a loyalty card system. This enrollment process is performed by the manager of a domain, the prover's mobile device and the SE. The eID-MA running on the prover's mobile device acts as a proxy between domain manager and SE. In contrast to the eID enrollment, domain enrollment does not require GlobalPlatform card management. Hence, user approval is sufficient (e.g. through entering a PIN/password that is verified on the SE) to add domains to the provers' SE.

The protocol steps of the domain enrollment consists of establishing an authenticated and privacy-friendly secure channel with ABCs (based on the scheme in [1]). This secure channel is then used to efficiently transfer eID data attributes directly between the SE of the prover and the domain manager. Additionally, during this process the domain manager and the SE authenticate the pseudonym of the user and the domain public key, respectively:

1. The process is initiated by the eID-MA, for example, when the user taps an NFC tag in the shop with a loyalty program. In this first step, the eID-MA sends the enrollment request to the domain manager.

2. The domain manager creates a new ephemeral key-pair $(a, A := a \cdot G)$ as well as a signature $\sigma_{i,d}$ over the public part $A$ as well as $la_d$:

$$ \sigma_{i,d} = \text{Sign}(d_{sk}, H(A \parallel la_d)) \qquad (2) $$

The manager sends $(\sigma_{i,d}, A, D_{id}, la_d)$ to the eID-MA.

3. The eID-MA asks the user to confirm the enrollment and the attribute disclosure of $la_d$. If the user rejects, the enrollment aborts. Otherwise, he has to authenticate himself with a previously defined PIN/password and the enrollment message is forwarded to the SE. Note that the user may only confirm a subset of the attributes in $la_d$. The SE conceals the remaining attributes from the domain.
4. On successful authentication, the SE proceeds and verifies the signature $\sigma_{i,d}$ with the received domain public key $D_{id}$. Furthermore, the SE checks in the TOFU database if an entry with the domain public key $D_{id}$ already exists. If the signature is invalid or an entry exists, the SE sends an error message to eID-MA and aborts. Otherwise, it derives a pseudonym $N_{u,d}$ for that domain:

$$n_{u,d} = H(id_u || D_{id}) \qquad (3)$$

$$N_{u,d} = n_{u,d} \cdot G \qquad (4)$$

Note that the pseudonym does not have to be stored on the SE (i.e. no additional space required) and can be easily derived in each verification (see Section 5.4). Also multiple devices of a user will derive the same pseudonym for a domain (i.e. all SEs receive the same $id_u$ during eID enrollment).

For the next step, the SE creates a new ephemeral key-pair ($b, B := b \cdot G$) and a NIZK proof over $A, B$, and $N_{u,d}$, using the ABC key credential $C_u$. Furthermore, the signatures $\sigma_{i,N}$ and $\sigma_{i,B}$ verify the knowledge of the secret-key $n_{u,d}$ and ephemeral key $b$, respectively:

$$\pi_i = \mathrm{SD}(C_u, H(A || B || N_{u,d})) \qquad (5)$$

$$\sigma_{i,n} = \mathrm{Sign}(n_{u,d}, H(A || \pi_i)) \qquad (6)$$

$$\sigma_{i,b} = \mathrm{Sign}(b, H(A || \sigma_{i,n})) \qquad (7)$$

The SE sends $(N_{u,d}, B, \pi_i, \sigma_{i,n}, \sigma_{i,b})$ to the domain manager.

5. With the NIZK proof $\pi_i$, the ephemeral public key $A$, and the received pseudonym $N_{u,d}$, the domain manager verifies the eID validity. The signature verification ensures the validity of the pseudonym and the ephemeral key. If any verification fails, the manager aborts. Otherwise, she creates a signature $\sigma_{i,A}$ to verify the ephemeral key and computes the session key $K_i$ with

$$\sigma_{i,a} = \mathrm{Sign}(a, H(B || N_{u,d})) \qquad (8)$$

$$K_i = H(a \cdot B), \qquad (9)$$

and outputs $(\sigma_{i,a})$ to the SE.

6. If the signature $\sigma_{i,a}$ is valid, the SE also computes the session key $K_i$:

$$K_i = H(b \cdot A) \qquad (10)$$

7. The SE and the domain manager use the session key $K_i$ for an authenticated secure channel and to exchange data attributes now. The domain manager can only request attributes which have been confirmed by the user. Additionally, the SE adds a new entry to the TOFU database, with the domain identifier $D_{id}$ and the accepted attributes of the attribute identifier list $la_d$ (i.e. as the profile for that domain). The domain manager might also send additional attributes (e.g. loyalty card validity period), which are also stored on the SE and linked to the TOFU entry.

8. The domain manager stores the pseudonym and the data attributes.
## 5.3 Profile Selection

Prior to the verification, the user selects a currently active profile within the eID-MA. This profile is then stored on the SE as the default profile and is also active if the mobile device of the prover is turned-off. An example of such a profile would be the birthday verification profile where only the birthday attribute is accessible for verifiers.

In the case where the verifier belongs to a domain, the profile will be automatically selected from the TOFU database after a successful membership verification of the verifier. This is part of the verification protocol.

## 5.4 Verification

Verification of the eID is done between verifier and prover over NFC. On the prover mobile device the communication is either transferred through the management application to the SE (using NFC host-card emulation) or directly with the SE (if the device is turned-off). Both communication paths use the same protocol steps described in this section. However, the host-card emulation enables the management application to display additional information of the verifier to the user (e.g. domain name, id, etc.)

The verifier can be any user who downloaded and installed the verifier application or can be a specific verifier of a domain. In the latter case, we assume the existence of a certificate $ca_{v,d}$, which is essentially a signature of the long-term public key $V_{pk}$ with the secret key of the domain manager $d_{sk}$.

The protocol steps are similar to the domain enrollment protocol and mainly consist of establishing an authenticated secure-channel between the SE of the prover and the verifier. This channel is based on ABCs to validate the eID and allows an efficient data attribute exchange:

1. The process is initiated by the verifier, for example, when the phones of verifier and prover are tapped together and communication over NFC is established. The verifier creates a new ephemeral key-pair $(c, C := c \cdot G)$ and sends $(D_{id}, ca_{v,d}, V_{pk}, C)$ to the SE. If the verifier is not part of a domain, the domain public key $D_{id}$ and the certificate $ca_{v,d}$ are omitted.

2. The SE also chooses a new ephemeral key-pair $(b, B := b \cdot G)$, creates a NIZK proof over $B$ as well as $C$ and creates a signature using the new secret key:

$$ \pi_i = \mathrm{SD}(C_u, \mathrm{H}(C \parallel B)) \qquad (11) $$

$$ \sigma_{i,b} = \mathrm{Sign}(b, \mathrm{H}(C \parallel \pi_i)) \qquad (12) $$

The SE sends $(B, \pi_i, \sigma_{i,b})$ to the verifier.

3. The verifier proves the validity of the eID using the NIZK proof $\pi_i$ and checks the signature $\sigma_{i,b}$ to ensure the validity of the ephemeral key. If any verification fails, the verifier aborts; otherwise proceeds by creating a signature using its own ephemeral key $c$ and the long-term secret key $v_{sk}$:

$$ \sigma_{i,v} = \mathrm{Sign}(v_{sk}, \mathrm{H}(B \parallel C)) \qquad (13) $$

$$ \sigma_{i,c} = \mathrm{Sign}(c, \mathrm{H}(\sigma_{i,v})) \qquad (14) $$
The verifier sends $(\sigma_{i,v}, \sigma_{i,c})$ to the SE and computes the session key $K_i$:

$$K_i = H(c \cdot B) \qquad (15)$$

4. If any signature $(\sigma_{i,v}, \sigma_{i,c})$ is not correct, the SE cancels the process. Otherwise, the SE computes the session key $K_i$:

$$K_i = H(b \cdot C) \qquad (16)$$

The SE also chooses the profile that defines the allowed attribute disclosure now. There are two cases:

(a) The verifier is member of a domain and sent $ca_{v,d}$ and $D_{id}$: the SE checks in the TOFU database if the domain public key $D_{id}$ is already known. If the domain is not in the database or if the certificate $ca_{v,d}$ does not properly validate the verifier key $V_{pk}$, the process is aborted. If the check is successful, the profile from the TOFU database is chosen.

(b) The verifier is not member of a domain: the default profile is chosen.

5. The SE and the verifier use the session key $K_i$ for the attribute exchange in an authenticated secure channel now. During this process, the verifier may request different attributes and based on the chosen profile, the SE decides if the attributes are disclosed or not.

6. If the verifier is a valid member of a domain, she may also request the domain pseudonym $N_{u,d}$. The derivation of it is the same as described in Equations 3-4. However, as the proposed system should not allow single verifiers to trace the activities of the prover, the pseudonym is not directly revealed to the verifier. That is, we assume that not all domain verifiers can be trusted and only the domain manager shall verify the prover's pseudonym. For that purpose, the SE generates a random value $r$, encrypts the pseudonym following the elliptic curve integrated encryption scheme [22] (ECIES), and signs the message with the secret key of the pseudonym:

$$K_N = H(r \cdot D_{id}) \qquad (17)$$

$$\gamma_N = \text{Enc}(K_N, N_{u,d}) \qquad (18)$$

$$\sigma_N = \text{Sign}(n_{u,d}, H(\gamma_N)) \qquad (19)$$

The SE outputs $(\gamma_N, \sigma_N, R := r \cdot G)$ to the domain verifier. As the message is encrypted with the public key of the domain manager, the domain verifier cannot acquire the pseudonym $N_{u,d}$. Hence, a single verifier can validate the eID and get domain-specific attributes but by default cannot link and trace the verifications. Even if domain verification of the same eID is requested multiple times, a domain verifier cannot link these verifications due to the randomness of $r$. Only the manager can decrypt that message, verify the signature and perform appropriate actions on that pseudonym (e.g. add bonus points to the loyalty program account). Note that disclosed attributes may still make verifications linkable to verifiers (see analysis in the next section).
# 6 Security & Privacy Analysis

Following up on our threat model, the proposed scheme prevents against:

- Forging identities. The security of our scheme relies on the security of the used ABC scheme as well as on the usage of an SE as a tamper-resistant storage for the credential and the identifier $id_u$. For that purpose, the SE on the provers' mobile device has a special security compartment (referred to as *security domain* [10]) that is under the control of a trusted eID issuer. Hence, a malicious prover cannot modify or forge sensitive data (i.e. identity, ABC, data attributes, etc.) without breaking the security of the SE. This is state-of-the-art technology for protecting sensitive information (e.g. SIM/bank cards) and also protects the integrity of the eID in cases where the mobile device gets stolen or malicious software is able to exploit the operating system of the prover device.

A malicious prover could also try to establish a secure channel to the verifier and send invalid data attributes. Without the knowledge of an ABC key credential $C_u$, the malicious prover cannot authenticate the ephemeral public keys in Step 4 of the domain enrollment protocol or in Step 2 of the verification protocol. Hence, without breaking the security of the SE or the used ABC scheme, it is infeasible for an attacker to forge an authenticated secure channel to the verifier and send invalid data attributes.

- Misuse data. The profiles as well as the TOFU database on the SE prevent uncontrolled attribute disclosure. The user stays in control of which data is sent to which verifier.

- Tracing identities. ABCs are designed to enable credential holders to attest the existence of certain signed attributes, without revealing the attribute itself. We make use of this mechanism to attest the validity of the eID without revealing any information about the eID holder. Hence, under the assumption that the used ABC mechanism protects against identity tracing, our proposed architecture is also secure against it.

Note that the disclosed attributes may still make verifications of a user linkable and enable identity tracing. Additional privacy-preserving mechanisms, such as the attribute queries proposed in [13], could reduce the amount of revealed information in this case and further protect the privacy of the eID holders.

- Linking pseudonyms. Our pseudonym derivation relies on the usage of a secure one-way hash function. That is, a hash function that is resistant against preimage, second preimage and collision attacks. Under this assumption, we argue that it is not feasible to link or deanonymize the pseudonyms of the prover without knowledge of the random and secret identifier $id_u$.

# 7 Evaluation

In the evaluation we use a 256-bit hash function, 256-bit elliptic curves (EC) for the creation of ECDSA signatures and 128-bit AES encryption. We will focus on the extensibility of the proposed architecture in terms of computation time as well as the required storage space on the SE.
## 7.1 Required Storage Space

Persistent and volatile memory are highly limited on an SE and therefore a limiting factor for smart card-based eID schemes. Hence, we briefly outline the required storage space of our architecture:

**eID** The SE of the prover has to store the identifier $id_u$ (we assume a size of 128 byte), the ABC key credential $C_u$ (size depends on the specific ABC implementation and the required security level), and the data attributes of the eID holder $da_u$.

**TOFU database** Each enrolled domain adds one entry to the TOFU database, consisting of the domain public key $D_{id}$ (33 bytes if point compression is supported, 65 bytes otherwise) and a profile that describes the accessible attributes for verifiers of that domain (we assume 4 bytes to control the disclosure of up to 32 attributes). There might also be additional attributes stored for each domain, hence, the exact size depends on the domain and cannot be estimated. Nevertheless, with an overhead of 37 bytes (or 69 bytes without point compression) for each domain, we argue that our proposed system is very space efficient and allows the use of many services at the same time.

## 7.2 Computation Time

We implemented the involved steps of the domain enrollment and verification protocol and measured the computation time on a NFC SIM card and a Yubikey NEO (also a smart card based computing device), both with JavaCard version 3.0.1. The measurements for the NFC SIM where done on an OPPO N1 Mini with Android 4.3 using the Open Mobile API and the Yubikey NEO measurements where done with a Thinkpad T440s over the USB interface. Note that an evaluation of the used ABC functionalities in our scheme is out of scope of this paper and not included in the computational analysis (an evaluation of ABCs on smart cards can be found in [23]).

As the transfer speed between SE and other devices highly depends on the interface [12], we omit the transfer time in this evaluation. For that purpose, we send the required data in a preceding command, store it in temporary memory on the SE, and then execute and measure the actual command.

**Domain Enrollment** The measurement of the domain enrollment protocol (see Section 5.2) comprises of the following commands:

- Step 4 involves one signature verification, the pseudonym derivation (one hash and an elliptic curve (EC) point multiplication), generation of a new ephemeral key-pair and two signature creations.

- Step 6 involves one signature verification and the creation of the shared secret key (one EC point multiplication and a hash)
<table><caption>Table 2: Median computation time of the domain enrollment on the SE.</caption><thead><tr><th></th><th>NFC SIM</th><th>Yubikey NEO</th></tr></thead><tbody><tr><td>Step 4</td><td>1432 ± 3 ms</td><td>672 ± 1 ms</td></tr><tr><td>Step 6</td><td>620 ± 5 ms</td><td>349 ± 1 ms</td></tr></tbody></table>

<table><caption>Table 3: Median computation time of the verification protocol on the SE.</caption><thead><tr><th></th><th>NFC SIM</th><th>Yubikey NEO</th></tr></thead><tbody><tr><td>Step 2</td><td>432 ± 13 ms</td><td>163 ± 0 ms</td></tr><tr><td>Step 4</td><td>970 ± 5 ms</td><td>153 ± 1 ms</td></tr><tr><td>Step 6</td><td>1048 ± 7 ms</td><td>437 ± 1 ms</td></tr></tbody></table>

Table 2 lists the median results of 25 measurements performed on the two test cards. Overall, the steps involving the SE took 2053 ms for the NFC SIM and 1021 ms for the Yubikey NEO.

**Verification** The evaluation of the verification protocol comprises of:

- Step 2 involves the generation of a new ephemeral key-pair and the creation of one signature.

- Step 4 involves two signature verifications and the creation of the shared secret key (one EC point multiplication and a hash)

- Step 6 is executed for domain verifiers and involves the creation of a public/private key-pair, a domain pseudonym derivation (one hash and an elliptic curve point multiplication), one AES encryption with a newly created secret key (one EC point multiplication and a hash) and a signature creation.

Table 3 lists the median computation time of 25 measurements on the test cards. Establishing the secure channel (Step 2 and 4) took overall 1402 ms on the NFC SIM and 315.5 ms on the Yubikey NEO. The derivation and encryption of the domain pseudonym (Step 6) took 1048 ms and 437 ms, respectively.

## 7.3 Discussion

Based on these results, we argue that our proposed architecture and the protocols are efficient for the user and can be performed on a computationally restricted device in reasonable time (below 2 seconds). Especially the verification protocol, where two people (e.g. disco bouncer and the guest) are directly interacting with each other, should not exceed this limit. The evaluation shows that the channel establishment on the SE is below this time limit with some time left for the selective disclosure protocol and the data transfer (further communication to the SE uses symmetric encryption and is therefore rather efficient). Only the enrollment on the NFC SIM took more than 2 seconds. However, this protocol does not require direct human interaction and can be performed in the background.

Compared to other systems that use ABCs (e.g. the ABC4Trust project) for a privacy-preserving verification, our system has the downside that we do not provide a cryptographic proof for every transferred eID attribute. However, we argue that creating proofs for different attributes within multiple credentials becomes very slow in ABC systems and many use cases do not require these
security guarantees. For example, a loyalty card program might not require
such strong assurances and a simpler approach (which requires less storage
and computation on the smart card) is sufficient. In addition, our scheme also
benefits from a simple mechanism for service providers to integrate with the eID
architecture (no authorization by central administration required).

One limitation of our proposed scheme is the requirement of an SE on the
prover side as well as NFC on both involved devices. Due to the heterogeneous
landscape of the mobile device market, it is therefore not provided that our
proposed scheme can be deployed on every device.

8 Conclusion

In this paper we proposed an architecture and protocols for a privacy-preserving
and extensible mobile eID system for real-world identification. The scheme com-
bines attribute-based credentials with additional mechanisms (TOFU, profiles,
privacy-preserving secure channel) to be implemented on computationally con-
strained hardware (NFC secure elements) in an efficient way (only one selective
disclosure operation required). We evaluated the proposed architecture and proto-
cols in terms of computation time as well as storage space and demonstrate that
it can be executed in reasonable time on a computationally constrained device,
such as smart cards. In future work, we will further analyze the security of our
proposed scheme as well as evaluate the computation time on the verifier mobile
device. Another part of future work will be to investigate possible solutions for
an efficient and privacy-preserving revocation in our mobile eID system.

Acknowledgments

This work has been carried out within the scope of *u'smile*, the Josef Ressel Center for User-Friendly Secure Mobile Environments, funded by the Christian Doppler Gesellschaft, A1 Telekom Austria AG, Drei-Banken-EDV GmbH, LG Nexera Business Solutions AG, NXP Semiconductors Austria GmbH, and Österreichische Staatsdruckerei GmbH.

References

1. G. Alpár and J.-H. Hoepman. A Secure Channel for Attribute-based Credentials: [Short Paper]. In *Proceedings of the 2013 ACM Workshop on Digital Identity Management*, DIM '13, pages 13–18. ACM, 2013.

2. G. Alpár and B. Jacobs. Credential design in attribute-based identity management. In *Bridging distances in technology and regulation, 3rd TIL Ting Perspectives Conference*, pages 189–204, Apr. 2013.

3. P. Bichsel, J. Camenisch, T. Groß, and V. Shoup. Anonymous Credentials on a Standard Java Card. In *Proceedings of the 16th ACM Conference on Computer and Communications Security*, CCS '09, pages 600–610. ACM, 2009.
4. P. Bichsel and others. An Architecture for Privacy-ABCs. In *Attribute-based Credentials for Trust*, pages 11–78. Springer, 2015.

5. R. Bjones, I. Krontiris, P. Paillier, and K. Rannenberg. Integrating Anonymous Credentials with eIDs for Privacy-Respecting Online Authentication. In *Privacy Technologies and Policy*, Lecture Notes in Computer Science, pages 111–124. Springer, Berlin, Heidelberg, Oct. 2012.

6. J. Camenisch, A. Lehmann, and G. Neven. Electronic identities need private credentials. *IEEE Security & Privacy*, 10(1):80–83, 2012.

7. J. Camenisch and A. Lysyanskaya. An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation. In *Advances in Cryptology – EUROCRYPT 2001*. Springer Berlin Heidelberg, May 2001.

8. J. Camenisch and A. Lysyanskaya. A signature scheme with efficient protocols. In *International Conference on Security in Communication Networks*, pages 268–289. Springer Berlin Heidelberg, 2002.

9. FIDO Alliance. FIDO UAF Protocol Specification v1.1, Feb. 2017. Implementation Draft.

10. GlobalPlatform. Card Specification v2.3, Oct. 2015. Public Release.

11. J. Hajny and L. Malina. Unlinkable Attribute-Based Credentials with Practical Revocation on Smart-Cards. In *Smart Card Research and Advanced Applications*, pages 62–76. Springer Berlin Heidelberg, Nov. 2012.

12. M. Hölzl, R. Mayrhofer, and M. Roland. Requirements for an Open Ecosystem for Embedded Tamper Resistant Hardware on Mobile Devices. In *Proceedings of International Conference on Advances in Mobile Computing & Multimedia*, MoMM ’13, pages 249–252. ACM, 2013.

13. M. Hölzl, M. Roland, and R. Mayrhofer. Real-World Identification: Towards a Privacy-Aware Mobile eID for Physical and Offline Verification. In *Proceedings of the 14th International Conference on Advances in Mobile Computing and Multimedia*, MoMM ’16, pages 280–283. ACM, 2016.

14. IBM Research. Specification of the Identity Mixer Cryptographic Library v2.3.0, Apr. 2010. Research Report.

15. J. L. Jensen. Smartphone feasibility analysis. Deliverable D4.4, May 2014.

16. A. Lehmann et al. Survey and Analysis of Existing eID and Credential Systems. FutureID Deliverable D32.1, Apr. 2013.

17. G. Madlmayr, J. Langer, C. Kantner, and J. Scharinger. NFC Devices: Security and Privacy. In *Third International Conference on Availability, Reliability and Security (ARES’08)*, pages 642–647. IEEE, 2008.

18. T. Nyman, J.-E. Ekberg, and N. Asokan. Citizen electronic identities using TPM 2.0. In *Proceedings of the 4th International Workshop on Trustworthy Embedded Devices*, pages 37–48. ACM, 2014.

19. F. Otterbein, T. Ohlendorf, and M. Margraf. Mobile Authentication with German eID. *Extended Abstract for Presentation at the 11th Int. IFIP Summer School on Privacy and Identity Management*, 2016.

20. C. Paquin. U-prove technology overview v1.1, Apr. 2013. Technical Report, Microsoft Corporation Draft Revision.

21. K. Rannenberg, J. Camenisch, and A. Sabouri, editors. *Attribute-based Credentials for Trust - Identity in the Information Society*. Springer, 2015.

22. V. Shoup. A proposal for an ISO standard for public key encryption (version 2.1). IACR E-Print Archive 112, 2001.

23. P. Vullers and G. Alpár. Efficient Selective Disclosure on Smart Cards Using Idemix. In *Policies and Research in Identity Management (IDMAN)*, pages 53–67. Springer Berlin Heidelberg, Apr. 2013.