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

. 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 diﬀerent 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 eﬃcient 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.


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 bouncer 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.

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][6][7] build the basis for another field of research in the area of privacypreserving 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].

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 bouncer 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.

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.

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 bouncer).They can also be domain members (referred to as domain verifier ) and read domain-specific attributes (e.g.loyalty card membership).

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  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 then 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: where 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.

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 bouncer 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.

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.

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 • 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 • G) and the TOFU databases of each SE are empty.H (m) One-way hash function over message m.Enc (K , m) Symmetric encryption of message m using key K .Sign (sk , m) Signature creation over message m with private key sk .SD (A, ch) Create a NIZK proof of an attribute-set A in a given ABC, while using the random challenge ch.

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 • G) as well as a signature σ i,d over the public part A as well as la d : The manager sends (σ 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 σ 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: 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 • G) and a NIZK proof over A, B , and N u,d , using the ABC key credential C u .Furthermore, the signatures σ i,N and σ i,B verify the knowledge of the secret-key n u,d and ephemeral key b, respectively: The SE sends (N u,d , B , π i , σ i,n , σ i,b ) to the domain manager.5.With the NIZK proof π 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 σ i,A to verify the ephemeral key and computes the session key K i with and outputs (σ i,a ) to the SE. 6.If the signature σ i,a is valid, the SE also computes the session key K i : 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.

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.

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: The SE sends (B , π i , σ i,b ) to the verifier.3. The verifier proves the validity of the eID using the NIZK proof π i and checks the signature σ 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 : The verifier sends (σ i,v , σ i,c ) to the SE and computes the session key K i : 4. If any signature (σ i,v , σ i,c ) is not correct, the SE cancels the process.Otherwise, the SE computes the session key K i : 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: The SE outputs (γ N , σ N , R := r • 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).

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-ofthe-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 .

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.

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.

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)   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.

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.

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 combines attribute-based credentials with additional mechanisms (TOFU, profiles, privacy-preserving secure channel) to be implemented on computationally constrained hardware (NFC secure elements) in an efficient way (only one selective disclosure operation required).We evaluated the proposed architecture and protocols 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.

Fig. 1 :
Fig. 1: General architecture of the proposed mobile and extensible eID system.

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 • 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 • G), creates a NIZK proof over B as well as C and creates a signature using the new secret key:

Table 1 :
Notation used in this paper.id u Secret identifier of the user.dau Data attributes of the user.Cu ABC key credential of user u for eID validation.N u,d , n u,d Derived domain pseudonym and the corresponding secret key.G Elliptic curve generator point.D id , d sk Public/private key-pair of domain manager d. la d List of attribute identifiers which a domain d wants to access.V pk , v sk Public/private key-pair of verifier v. ca v,d Certificate of domain verifier v.

Table 2 :
Median computation time of the domain enrollment on the SE.

Table 3 :
Median computation time of the verification protocol on the SE.

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.

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.