Digital identities and AmDL

There are many systems that provide users with an electronic identity (eID) to sign documents or authenticate to online services (e.g. governmental eIDs, OpenID). However, current solutions lack in providing proper techniques to use them as regular ID cards that digitally authenticate their holders to another physical person in the real world. Within this work package we proposed techniques and protocols for such a privacy-preserving mobile eID that also fulfills requirements for governmental identities with high security demands (such as driver's licenses or passports) and can be used in the private domain (e.g. as loyalty cards).

Architecture for an extensible and privacy-preserving mobile eID

A main goal was to design an architecture and efficient protocols for a privacy-preserving mobile eID that allows identity validation in a similar fashion as regular ID cards. An example use case would be an eID holder who wants to prove to a disco bouncer that she is above 18 years old without revealing her name or even her actual date of birth (we refer to this property as real-world identification). In addition, a main requirement for the design of our scheme was the possibility to extend the eID to numerous domains. Such a domain could be any public or private service (e.g. loyalty card programs, public transport tickets, student cards). We analyzed the requirements for such a privacy-preserving mobile eID and presented a basic scheme that would allow such a real-world identification. We further extended this scheme with additional mechanisms and protocols that support the extensibility requirement. Our proposed architecture thereby aims for simplicity for service providers and users. Hence, it should be easy for service providers to make use of our mobile eID system and for eID holders to control their data.

We analyzed our basic scheme and argue that our proposed architecture and the protocols are efficient for the user and can be performed on a computationally restricted device (such as a smart card) in reasonable time. That is, we assume that a user is not willing to wait for more then 2 seconds to finish a task. 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 secure element is below this time limit with some time left for the selective disclosure protocol and the data transfer. Only the enrollment, when tested on a secure element (NFC UICC), took more than 2 seconds. However, this enrollment does not require direct human interaction and can, therefore, be performed in the background.

Besides the design of this extensible mobile eID architecture, we also considered the circumstance that including an eID in the – already pervasive – smartphones transforms them into a single point of failure: loss, theft, or malfunction would prevent their users even from identifying themselves e.g. during travel. Therefore, secure backup of such identity data is essential, and the obvious solution is to store encrypted backups on cloud services. Unfortunately, users will be highly unlikely to remember a cryptographically strong password in the – typically rare but then crucial – case of recovering their eID onto a new device. Hence, we proposed a combination of recently popular Password-Protected Secret Sharing (PPSS) schemes with a Fuzzy Extractor to allow users to recover the key required for decrypting their backup from multiple key shares and a biometric identifier. In practice, this allows relying on only partially trusted cloud servers for the backup with key parts either carried with the user (e.g. as a printed QRcode) or shared with trusted friends, and biometric authentication (e.g. by fingerprint) on the new smartphone during the recovery phase.

Privacy-preserving eID revocation

Providing a revocation mechanism that preserves privacy is often the bottleneck for the scalability of a privacy-preserving eID scheme. In order to bridge this gap between practicability and privacy, we designed and implemented a new scalable and efficient scheme that preserves privacy of the user beyond revocation and is suitable to be executed for smart cards. We make use of a simple, but effective, generation of revocation tokens which provides anonymity in the whole population as well as unlinkability and backward unlinkability. A proof of validity of these tokens is done with a new method which we refer to as disposable dynamic accumulators, a variant of the dynamic accumulator. Applying a protocol that splits the computation of this accumulator between two entities, allows its execution on computationally restricted prover devices, such as smart cards. By using Bloom filters we keep the revocation list small and the revocation check efficient (can be performed in constant time). The false positive rate through the usage of these probabilistic data structures (i.e. Bloom filters) is addressed with additional mitigation techniques. Finally, we evaluate our scheme for populations with multiple hundred thousands of revoked eIDs and show that it stays efficient for mobile devices and smart cards.

Austrian mobile Driving License (AmDL)

(c) profile conf.

(b) enrolled domains

(a) driving license

Part of this work package is the implementation of the concepts from our research into a prototype for a first Austrian mobile Driving License (AmDL) that also respects the privacy of the license holder. The goal was to present actual use cases for the proposed Therefore, we implemented Android prototypes for the prover (i.e. the license holder) as well as for the verifier. We make uses of our proposed protocols and our new revocation mechanism to establish a secure channel between prover and verifier. The verifier then uses this secure channel to query attributes, as well as a signature over these attributes, from the AmDL. The prototype for the prover also implements a first version of our concept of domain profiles. This gives the license holder the possibility to control the attributes, which certain domains are allowed to query from the AmDL.

(a) bouncer

(b) postal

(c) vend. machine

(d) police officer

To demonstrate the broad range of use cases, we also implemented multiple variants of the verifier, which differ in the attributes that they can retrieve and verify. An example for such a privacy-preserving attribute verification is a disco bouncer that should only get a proof that the guest is above 18 years old, without revealing the name or even the actual date of birth. Another example is a verification of the address within a postal office or a vending machine (e.g. cigarette vending machine) that verifies the age of the license holder. Only in a scenario where an actual police officer wants to verify the legitimacy of the driving license, the complete set of attributes of the driving license is accessible.

Our prototype targets Android devices and uses a combination of NFC and Wi-Fi technology to transfer data between verifier and prover. As the usability was a main requirement of our scheme, we designed this interaction to be as simple as possible. Hence, our prototype only requires the verifier and the prover to hold their mobile devices together (i.e. the back side of the devices) for around two seconds. Everything else will happen automatically in the background and does not involve any other user interaction. In essence, we use Wi-Fi for fast exchange of data and NFC to initiate communication security and to transfer the information required to establish the Wi-Fi channel for further communication. We therefore evaluated the compatibility between different Android devices and measured the communication speed of NFC and Wi-Fi, including NFC to Wi-Fi handover. This evaluation also identified some incompatibility of Wi-Fi communication between current devices.

In order to have full interoperability between currently existing mobile devices, we also analyzed the possibility to establish communication between Android and iOS. As Apple implements its own Wi-Fi Direct like protocol, called MultiPeerDiscovery, it is incompatible with the Wi-Fi Direct implementation of Android (the Apple implementation uses a combination of Wi-Fi, Bluetooth Classic and Bluetooth Low Energy). The result of this evaluation shows, that for a connection between Android and iOS devices, initial information has to be shared using a QR code. Additionally, we show that there is documentation available for iOS that describes how an iOS device (without Wi-Fi Direct support) could connect to an Android device that has Wi-Fi Direct support via a legacy mode.