Privacy ABCs: Now Ready for Your Wallets!

The paper deals with privacy-enhanced electronic access control technologies, in particular cryptographic schemes that allow verification of users' personal attributes without their identification, so-called anonymous attribute-based credential schemes (ABCs). We present the last bit necessary for making ABCs practical for large-scale applications that are using smart cards as users' devices for storing credentials: a novel cryptographic scheme that combines fast credential verification protocols with efficient offline revocation protocols. Using proven building blocks, namely weak Boneh-Boyen (wBB) signatures, keyed-verification credentials and $k$-times anonymous proofs, we construct a practical scheme for proving personal attributes anonymously, unlinkably, untraceably and, most importantly, with the verifier-local revocation (VLR) functionality that is running on standard existing smart cards. To prove the practicality of the design, we implemented all the proposed protocols using an off-the-shelf card, benchmarked the proving protocol, compared to existing solutions and put all the source codes on the GitHub as an open source. The cryptographic design and our implementation are efficient enough to be immediately used for the privacy enhancement of existing large-scale applications, such as electronic ID cards (e-IDs), public transportation cards, apps for citizen tracing during pandemic situations or secure authentication of IoT devices.


I. INTRODUCTION
Using anonymous attribute-based credentials (ABCs), users can prove their personal attributes (such as age, citizenship, ticket ownership, negative SARS-CoV-2 test) without revealing their identity. Furthermore, advanced privacy-enhancing features are provided by ABC schemes, such as unlinkability, untraceability or selective attribute disclosure.
While the ABC schemes are known for a long time since the publication of [1]- [3], their implementation on constrained offline devices was a hard problem for a long time due to high computational complexity. In particular, the implementations of core protocols on smart cards were impractical until very recently [4]- [7]. Implementations with efficient large-scale revocation are still completely missing on smart cards and only available on online and computationally strong user devices, which usually do not include IoT devices, which have only very limited memory and computational resources.
In this paper, we finally present a scheme that holds all privacy-enhancing features, is provably secure, provides efficient revocation even in applications with millions of users and yet it is implemented and benchmarked on a standard smart card. Since we consider smart cards the most convenient devices for storing and proving personal attributes due to their security, durability and portability, we believe that the results presented in this paper will contribute to the practical deployment of ABC technologies in applications such as eID cards, e-ticketing, mass transportation or privacy-enhanced people tracing and smart quarantine.

A. State of the Art
There are several implementations of ABC schemes on programmable smart cards available, such as [4], [5], [7], [8]. However, these implementations lack revocation, which is the crucial feature for removing misbehaving or invalid users from the system. Revocation was the topic of many papers [9]- [14], but none of them proposed practical protocols that can be used in large-scale applications with smart cards due to the following issues: use of unsupported operations (e.g., bilinear pairing on constrained user's device), need for periodic updates of a smart card content, need for online communication, loss of unlinkability, only user-driven revocation or missing security proofs. Lueks et al. [15] proposed a revocation scheme with low computational cost based on the Vuller's and Alpar's (VA's) Idemix implementation [4] that is part of the IRMA Project. The disadvantages are limited unlinkability within one epoch and need for revocation list re-computation for each verifier, which is impractical. The scheme was further extended by Verheul [16] to avoid the disadvantages but requires bilinear pairings, that are currently unsupported by smart cards. Efficient revocation scheme for smart-cards was proposed by Camenisch et al. in [6]. However, the integration of the revocation protocols with any ABC scheme is not described, nor implemented yet. Recently, Camenisch et al. [7] present Keyed-Verification Anonymous attribute-based Credentials (KVAC) based on algebraic MAC and Boneh-Boyen signatures. The solution is designed directly for smart cards. However, the scheme lacks revocation completely.

B. Our Contribution
ABC schemes without practical revocation are useless for electronic service providers, as they essentially need mechanisms for the identification and revocation of misbehaving users. However, the cryptographic protocols for proving personal attributes and for the revocation of invalid users have been handled rather separately so far. While there exist schemes that allow efficient proving of attributes using smart cards (e.g., [7]) and there are generic schemes for ABC revocation (e.g., [6]), there is also a lack of results showing at least the basic principles of their combination. Due to the high complexity of proving and revocation protocols, it is a non-trivial task to design mechanisms for their integration, to combine these protocols together and keep the computational complexity within the limits of existing smart cards. Therefore, the first contribution of this paper is the full cryptographic specification of a novel scheme that combines efficient attribute proving protocols with revocation protocols.
Although there exist theoretical specifications of some partial ABC solutions, the practical implementations are currently only very few [4], [5]. That is caused by the complexity of the development on the smart card platforms. The lack of computational and memory resources, very limited cryptographic support, awkward debugging and missing arithmetic operations (such as operations on elliptic curves, bilinear pairings, etc.) result in the absence of even prototypical implementations of ABCs that could be used by service providers for their testing and integration into practical systems. To improve this situation, we provide the full open-source implementation 1 of all protocols of our revocable ABC scheme that is fully functional on off-the-shelf smartcard with a standard operating system. This is the second major contribution of the paper.
Finally, due to the use of advanced cryptographic primitives in ABC protocols and due to very limited resources of smart cards, the existing partial implementations are often very inefficient. It is not uncommon that some protocols take over 10 seconds [17], [18], which is useless in real applications such as public transportation, loyalty cards or ticketing. As a third major contribution, we present benchmarks of our protocols on real devices which prove the efficiency our cryptographic design and implementation and give estimates of expected running times to future adopters of the ABC technology.

A. Preliminaries
The symbol ":" means "such that", the symbol "||" means concatenation and |x| is the bitlength of x. The symbol H denotes a secure hash function. We write a ← $ A when a is sampled uniformly at random from A. Let e denote a bilinear map

B. Protocol Description
The communication pattern depicted in Fig. 1 employs the following entities: • Revocation Authority (RA): assigns and issues a unique revocation handler (private attribute m r ) to each user using the Issue algorithm. Thanks to this attribute, the revocation authority can revoke users. • Issuer (I): is responsible for issuing attributes (personal attributes m i , such as gender, nationality, age or negative SARS-CoV-2 test) to a user aggregated in a cryptographic 1 GitHub link: https://github.com/rcasanovama/rkvac-protocol-multos credential cred using the Issue algorithm. The credential is digitally signed by the issuer's secret key sk I . • User (U): gets the credential cred which includes issued attributes from the issuer and anonymously proves the possession of attributes to the verifier using the Show algorithm. Furthermore, the user has to compute a onetime per-session pseudonym C which is linked to the credential cred via the revocation handler m r and prove that this one-time pseudonym is not revoked. • Verifier (V): verifies the possession of required attributes and the revocation status of the revocation handler using the Verify algorithm and Verifier's secret key sk V and RA's public key pk RA .
The algorithms and protocols are specified in the next section, including their input and output parameters: : the algorithm inputs the security parameter κ and generates the public system parameters (which are implicit inputs of all other algorithms), namely a bilinear group with parameters params I = (q, G 1 , G 2 , G T , g 1 , g 2 , e) satisfying |q| = κ. Next, the private keys where n is the number of all attributes in the credential, are generated and securely distributed to issuer and verifier. In our implementation, we use a bilinear group generated by the MCL [19] library, namely we use the BN-254 curve. The SetupI algorithm is run by the issuer.
(1 κ , ver max ): the algorithm inputs the security parameter κ and the parameter ver max setting the maximum number of unlinkable sessions per user within one epoch. First, the RA computes its keypair as ). Second, the algorithm sets integers (k, j) : ver max = k j . In our implementation, we set j = 2, k = 10, i.e. 100 pseudonyms per epoch (e.g., a day). Furthermore, the algorithm chooses random integers (α 1 , . . . , α j ) ← $ Z q and computes h z = g αz 1 for all z from 1 to j. Finally, the RA generates an empty revocation list RL and an empty list of revocation handlers RH. The algorithm outputs keys (sk RA , pk RA ) and parameters params RA = (k, j, (h 1 , . . . , h j ), (α 1 , . . . , α j )). The SetupRA algorithm is run by the revocation authority, pk RA and params RA are securely distributed to other entities. algorithm outputs signature on all user attributes σ (i.e., cryptographic credential), the revocation handler m r , the (signed) randomizers and updates the list of revocation handlers RH. The algorithm consists of two sub-algorithms: IssueRA and IssueI. The IssueRA algorithm is run first and after that it is followed by the IssueI algorithm. α z e z , where e z and α z are secret user's parameters (stored on a secure device such as a smart card) and the revocation handler m r . The user then randomizes its credential and computes a proof of knowledge of all its attributes inside the credential. Furthermore, the user proves that the one-time pseudonym C and signatureσ are constructed using the same handler m r . Finally, the verifier verifies the proof π and checks whether the one-time pseudonym C is not placed on the revocation list RL.
• RL ←Revoke(RH, RL, sk RA , π, C): the algorithm inputs the RA's private list of revocation handlers RH, the public revocation list RL, the RA's private key and the communication transcript π, C received from the verifier. The algorithm outputs updated revocation list RL . The Revoke algorithm is typically run between the verifier and the revocation authority. The RA is able to reconstruct all pseudonyms of all users for every epoch by computing where i = α 1 e I + α 2 e II is computed for all possible combinations of α j and e k (i.e. in case of j = 2, k = 10, it is 100 combinations) and m r , which are taken from the list of revocation handlers RH. By comparing the C received from the verifier with all reconstructed pseudonyms of all users, the RA is able to identify the owner of the pseudonym (since RA stores the link between the revocation handler m r and the identity of the user in RH) and put all his one-time pseudonyms on the updated revocation list RL for the next epoch.

III. SECURITY ANALYSIS
Our scheme is composed of two crucial components: the keyed-verification credential scheme [7] and the scalable revocation scheme [6]. In the next sections, we outline the security model and the results of formal analysis. More details, including the formal security models and formal security proofs, can be found in our aforementioned papers on these building blocks.

A. Keyed-Verification Credentials
We follow the security model defined by Chase et al. [21], thus requiring (informally): • Correctness: honest users are almost always accepted, • Unforgeability: dishonest users are almost always rejected, • Anonymity: protocol transcripts are indistinguishable from simulations, • Key-Parameter Consistency: there is a unique private key to every public key/parameter.
The keyed-verification credential scheme has been proven secure in the random oracle model in [7] under the n-SCDHI assumption (defined below).
SCDHI is (t, )-hard if no t-time adversary has advantage at least .

B. Scalable Revocation Scheme
We use the security model defined in [6] with following requirements (informally): • Revocation Completeness: unrevoked users will almost always pass the revocation check. • Revocation Soundness: revoked users will almost always be rejected by the revocation check. • Revocation Privacy: protocols will not release any private data during proving the possession of an unrevoked revocation handler. The revocation scheme has been proven secure in the random oracle model in [6] under the l-DBDHI assumption [22] (defined below).
Definition 2 (l-Decisional Bilinear Diffie-Hellman Inversion Problem (DBDHI)): Input the tuple (g, g x , . . . , g x q ). Distinguish e(g, g) 1/x from random γ in G with advantage: -hard if no t-time adversary has advantage at least .

IV. IMPLEMENTATION RESULTS
We provide the proof-of-concept implementation of our scheme in order to benchmark and compare it with the existing schemes. The scheme implementation consists of the smart card side (i.e. entity representing the user) and the terminal side (i.e. entity representing the issuer/verifier and the revocation authority). Both implementations are available on the GitHub public repository: Link Anonymized. In case of the smart card application, only standard MultOS API and free public development environment (Eclipse IDE for C/C++ Developers, SmartDeck 3.0.1, MUtil 2.8) were used. We used standard off-the-shelf programmable smart cards, namely MultOS ML4 contact smart cards (MCU SC23Z018, 1.75 kB RAM, 252 kB ROM, 18 kB EEPROM, OS Mul-tOSv4.3.1), which support only T=0 transmission protocol. The MultOS platform was selected due to its wide support of modular arithmetic and elliptic curve operations (ECC scalar multiplication and ECC addition), see [23] for more details. For the terminal application, OpenSSL [24], MCL [19] and GMP [25] libraries were used. The GMP library achieved the best performance results from all tested libraries which supports bilinear pairing operations, see [26] for more details. Figure 3 depicts the comparison between our implementation (blue and red) and the original keyed-verification scheme lacking revocation [7] (black and white) for different numbers of attributes stored and disclosed. The figure shows the times for maximum n−1 disclosed attributes, where n is the number of stored attributes on the card since the revocation handler (the attribute m r ) is always present but never disclosed. The Show and Verify algorithms of both schemes were implemented using a pairing-friendly BN-254 curve generated by the MCL library. We stress that the original keyedverification implementation had to be extended to support BN-254 curve since it supported only the NIST P-192 curve. The algorithm time (in red) shows the time necessary to compute all operations on the card. The overhead time (in blue) includes the additional time for APDU transmission and MultOS processing. Results are the arithmetic means of 10 measurements in milliseconds.
Independently of the number of attributes used, our scheme requires always only ca. 1.3 s to generate the ownership proof with all but revocation attributes disclosed. The total time of around 2.08 s is necessary for the proof generation including communication (2.01 s) and computations on a terminal (0.07 s on Raspberry Pi 4 Model B, ARM Cortex-A72, 4 GB RAM, Raspberry Pi OS 4.19 32b). The complexity of the scheme increases with the number of undisclosed attributes, each undisclosed attribute increases the Show time by ca. 100 ms. Our implementation is limited to 10 attributes per user, but the available memory resources (approx. 1.75 KB RAM and 7.5 KB usable EEPROM) would allow storing up to 50 attributes on a card.

V. CONCLUSION
We focused on the practical aspects of ABC technologies and presented an integrated scheme that holds all privacypreserving features, provides efficient revocation and is based on provably secure building blocks. The scheme has been implemented on a standard smart card, benchmarked and the source is openly available on GitHub. To the best of our knowledge, we present the first implementation of a revocable anonymous credential scheme on a standard smart-card that achieves practical running times. Next, we plan to further optimize the Show protocol, keep searching for faster cards and start the real-world pilot deployment.