Recovering Lost Device-Bound Credentials

Abstract

Anonymous credential systems allow users to authenticate in a secure and private fashion. To protect credentials from theft as well as from being shared among multiple users, credentials can be bound to physical devices such as smart cards or tablets. However, device-bound credentials cannot be exported and backed up for the case that the device breaks down or is stolen. Restoring the credentials one by one and re-enabling the legitimate owner to use them may require significant efforts from the user. We present a mechanism that allows users to store some partial backup information of their credentials that will allow them to restore them through a single interaction with a device registration authority, while security and privacy are maintained. We therefore define anonymous credentials with backup and provide a generic construction that can be built on top of many existing credential systems.

This work was supported by the European Community through the Seventh Framework Programme (FP7) under grant agreement number 318424 (FutureID) and by project S40012/K1102 at Wrocław University of Technology.

1 Introduction

Digital credentials are used to certify a set of attributes for a user (i.e., birth date, sex, clearances, access rights, or qualifications), similar to traditional paper-based credentials such as identity cards or driving licenses. However, their electronic nature makes them easy to duplicate and share. This is particularly problematic when users have an incentive to share their credentials, e.g., when they give access to payed subscription services such as music or video streaming. The problem becomes even worse when anonymous credentials are used, since a service provider cannot determine whether two presentations (i.e., authentications) were performed using the same or different credentials.

Service providers therefore often protect credentials by “binding” them to an uncloneable hardware device that can perform authentications, but from which the credentials are not easily extracted. The main idea is that physical access to the device is required to be able to present the credential. A high-security way of doing so is by embedding the credentials on tamperproof smart cards or secure elements; while for lower-security use cases, storing the credentials in obfuscated form on the user’s phone or tablet PC may suffice.

Unfortunately, both those techniques do not allow users to make backups of their credentials in order to recover if the device breaks down, or is lost or stolen. Instead, they will have to re-issue all the credentials and possibly also revoke the old ones. However, a single device may store many such credentials and replacing all of them is often costly and impracticable since it might require off-line authentication steps such as appearing in person at an office, receiving a letter by paper mail, or answering secondary security questions. Although efficient backup mechanisms for credentials—and in particular, anonymous credentials—seem essential, no such construction has been proposed so far in the literature.

Our Contributions. In this paper, we describe a scheme for efficient backup and restoration of device-bound credentials. Rather than binding the credentials to the device directly, we propose binding credentials to the user, while devices are registered to users as well. To perform a correct authentication, the user must prove that the credential is bound to the same user to which the device is registered. Credentials can then be exported and backed up in the traditional way, while a device registration authority prevents credential sharing and theft by ensuring that users can only register a limited number of devices and cannot register devices in other users’ names.

We consider very strong security features for users as well as service providers. We assume that users store their backups on untrusted media that could fall into the wrong hands of malicious users, or even of malicious device manufacturers. In spite of having access to the backup and being able to register new devices to any user, the attacker should not be able to impersonate the user. We do so by requiring the user to keep a strong secret in an offline vault, e.g., on a piece of paper stored in a safe place. To maintain an acceptable level of usability, however, the vault secret is solely needed for device registration but not for everyday use.

We first give a high level description of an anonymous credential system with backup ($\mathsf{BPABC}$) in Sect. 2, where we also define the syntax of $\mathsf{BPABC}$ and give an overview of the related security requirements. Besides the basic functionalities and backup, our framework covers advanced issuance (i.e., attributes can be carried over into new credentials without revealing them to the issuer), scope-exclusive pseudonyms (i.e., pseudonyms that are linkable for a fixed scope string, but unlinkable across scopes), revocation, and equality predicates (i.e., users can prove equality of hidden attributes, potentially across multiple credentials). In Sect. 3 we give a high-level description of the generic construction of a $\mathsf{BPABC}$  scheme together with a sketch of its security proof.

Related Work. Anonymous credentials were originally envisioned by Chaum [Cha81, Cha85], and subsequently a large number of schemes have been proposed, e.g., [BL13, BCC+09, CH02, CL01, CL02, CL04, Bra99, PZ13, CMZ14, GGM14]. Various formalizations of basic credential schemes have been proposed in the literature, typically only considering a limited set of features, e.g., Camenisch and Lysyanskaya [CL01] or Garman et al. [GGM14]. Recently, Camenisch et al. [CKL+14] presented the so far most holistic definitional framework for attribute-based credential systems, covering the same features as our framework, except that theirs was limited to software credentials only and thus there was no need for backup. Following their approach of a unified definitional framework, we extend their syntax, definitions, and generic construction to additionally support device-bound credentials.

2 Device-Bound Credentials with Backup

A privacy-enhancing attribute-based credential system ($\mathsf{PABC}$) consists of users ${\mathcal {U}}$ that can request credentials on their attributes from issuers, ${\mathcal I}$, and verifiers, ${\mathcal V}$, to whom users can present (i.e., prove possession of) an arbitrary set of their credentials. Additionally, in a $\mathsf{PABC}$ system with backup ($\mathsf{BPABC}$), device manufacturers $\mathcal {DM}$ generate hardware tokens, and device credential issuers $\mathcal {DI}$ can issue device credentials that can only be used if the device is physically present. The idea is that software credentials certify the users’ attributes, whereas device credentials only guarantee that a user has physical access to a valid device. Then, upon presentation, the user shows that he possesses a valid device, and an arbitrary set of software credentials that also belong to the same user.

When joining the system, every user computes a user secret key $\textit{usk}$, which is used to bind credentials to the user and allows him to derive unique pseudonyms for different scopes, where a scope may be an arbitrary bit string. Pseudonyms are linkable if computed twice for the same scope, but are completely unlinkable across scopes. Furthermore, a user computes a vault user secret/public key pair $(\textit{vusk},\textit{vupk})$. Upon presentation, the user needs to know $\textit{vupk}$, whereas the vault user secret key $\textit{vusk}$ can be stored in a secure vault (e.g., it could be written on paper and stored in a safe), and is only needed to “authenticate” the user every time he obtains a new device or in order to restore a lost device.

Note here that any method to legitimately re-obtaining credentials (anonymous or not) requires some secret data to be stored outside the used hardware tokens, e.g., on paper or an offline data stick. This is, because otherwise the honest owner of a credential could not prove legitimate ownership of a credential once the adversary got access to his device, as the adversary would know exactly the same information and could thus perfectly imitate the user. In traditional settings, this data may be the correct response to a security question for a given service. For a backup mechanism to be practical, it is important that the amount of secret data, as well as the number of modifications and look-ups of this data are kept small. In our construction, the secret data consists of only a single long-term signing key, independent of the number of credentials, and needs to only be accessed when setting up a new device.

In Fig. 1 we describe the main steps of $\mathsf{BPABC}$. Every user may possess several devices, and store an arbitrary set of his software credentials on any of these devices. Users can obtain software credentials from issuers as in a traditional credential system using

$\mathsf{Issue}$, i.e., no device is required to obtain a credential. However, we assume that presenting credentials to verifiers using

$\mathsf{Present}$ always requires possession of a device.¹ Furthermore, certain credentials may be bound to specific devices, i.e., they only can be used with this specific device, by binding it to a device binding identifier $\textit{dbid}$ that is unique for every device.

Fig. 1.

All steps of a $\mathsf{BPABC}$ system are user-centric, and no two actions taken by the user can be linked unintentionally.

The device manufacturer first generates a device containing a certificate of genuineness using the algorithm

$\mathsf{Produce}$. When buying a device, the user first has to activate it in interaction with the manufacturer by running the protocol

$\mathsf{Activate}$, at the end of which the device contains an initial device credential. Now, the user has two possibilities to personalize his device. If the user wants to register a new device, he runs

$\mathsf{Register}$ in interaction with the device credential issuer. If, on the other hand, the user wants to restore a lost device, he runs

$\mathsf{Restore}$ with $\mathcal {DI}$. In both cases, the user uses his vault secret key $\textit{vusk}$ for this personalization; in the latter case, he further uses some backup token that was computed prior to losing the device. Restoring a device can be seen as a special way of registering a device: while for a plain registration, the device receives a fresh $\textit{dbid}$, restoring allows the user to register the new device with the $\textit{dbid}$ of the lost device. Doing so allows the user to use all his software credentials (including those that were bound to the lost device) with the new device. However, the security requirements of the system guarantee that no user can abuse this restoring procedure to clone or duplicate devices, i.e., it is ensured that at any point in time at most one device with a certain $\textit{dbid}$ is valid in the system.

We chose a multi-step approach for personalizing the device to ensure maximum security to all involved parties, and to model reality more accurately. For instance, requiring to first activate the device with the manufacturer gives him the chance to deny this activation, e.g., if the vendor reported the given device to be stolen. However, as no personal information is involved in the $\mathsf{Activate}$ protocol on the user side, the manufacturer does not learn any information about the user, but only that a given device is now activated. Splitting the activation and personalization steps allows us to distinguish the device credential issuer (e.g., a public authority) and the manufacturer (e.g., a smart card producer).

2.1 Syntax of Anonymous Credentials with Backup

In the following we formally specify the syntax and interfaces of an anonymous credential system with backup ($\mathsf{BPABC}$). We kept the syntax as close as possible to that of $\mathsf{PABC}$ schemes without backup [CKL+14].

We denote algorithms by sans serif font, e.g., $\mathsf{A}, \mathsf{B}$. Drawing s uniformly at random from a set $\mathcal {S}$ is denoted by . Similarly, denotes that a is the output of a randomized algorithm $\mathsf{A}$. For a two party protocol $(\mathsf{A},\mathsf{B})$, we write to denote that $\mathsf{A}$ obtained output $out _\mathsf{A}$ on input $in _\mathsf{A}$ (accordingly for $\mathsf{B}$). For sets $\mathcal {P}\subseteq \mathcal {S}$, we write $\mathcal {P}^c$ for the complement of $\mathcal {P}$, i.e., $\mathcal {P}^c=\mathcal {S}\setminus \mathcal {P}$. We write $(x_i)_{i=1}^n$ to denote the vector $(x_1,\dots ,x_n)$. Finally, for $n\in \mathbb {N}$, we write $[n]:=\{1,\dots ,n\}$.

A $\mathsf{BPABC}$ scheme consists of a specification of an attribute space $\mathcal {AS}\subseteq \pm \{0,1\}^\ell$, algorithms $\mathsf{SPGen}$, $\mathsf{UKGen}$, $\mathsf{VKGen}$, $\mathsf{IKGen}$, $\mathsf{DMKGen}$, $\mathsf{Produce}$, $\mathsf{ITGen}$, $\mathsf{ITVf}$, $\mathsf{Present}$, $\mathsf{Verify}$, $\mathsf{Revoke}$, $\mathsf{BTGen}$, and protocols $\langle {{\mathcal U}}.{\mathsf{Issue}},{{\mathcal I}}.{\mathsf{Issue}}\rangle$, $\langle {\mathcal U}.\mathsf{Register},$ $\mathcal {DI}.\mathsf{Register}\rangle$, $\langle {\mathcal U}.\mathsf{Restore},\mathcal {DI}.\mathsf{Restore}\rangle$, $\langle {\mathcal U}.\mathsf{Activate},\mathcal {DM}.\mathsf{Activate}\rangle$ defined as:

• On input $1^\kappa$, this system parameter generation algorithm generates system parameters $\textit{spar}$.

• On input system parameters $\textit{spar}$, the user key generation algorithm outputs a user secret key $\textit{usk}$.

• On input system parameters $\textit{spar}$, the vault user key generation algorithm outputs a vault user secret/public key pair.

• On input $\textit{spar}$, the (device) issuer key generation algorithm outputs a public/private issuer key pair and some initial public revocation information, $\textit{RI}$. Formally, our construction does not require to distinguish software and device credential issuers. However, to ease presentation, we will write $(\textit{disk}, \textit{dipk},\textit{RI}_\mathcal {DI})$ whenever an issuer is currently in the role of a device credential issuer.

• On input $\textit{spar}$, the device manufacturer key generation algorithm outputs a public/secret manufacturer key pair.

• On input a secret manufacturer key $\textit{dmsk}$, the device production algorithm outputs a genuineness certificate.

• In this interactive device activation protocol, the user takes inputs $(\textit{dmpk},\mathtt{cert})$, whereas the device manufacturer takes input $\textit{dmsk}$. At the end of the protocol, the user obtains a device secret key $\textit{dsk}$, a device binding identifier $\textit{dbid}$ and the initial device credential $\textit{dcred}_{init}$.

• In this device registration protocol, the user takes inputs $(\textit{dipk},\textit{dmpk},\textit{vusk},\textit{vupk},\textit{dsk},\textit{dbid},\textit{dcred}_{init},\textit{drh})$, while the device credential issuer takes inputs $(\textit{disk},\textit{dmpk},\textit{RI}_\mathcal {DI},\textit{drh})$, where the inputs and outputs are defined as before. Moreover, $\textit{drh}$ is the revocation handle for the new device. As the result of this protocol, the user obtains the device credential $\textit{dcred}$, while the issuer receives an updated revocation information $\textit{RI}'_\mathcal {DI}$.

• To issue a software credential, a user needs to generate an issuance token that defines the attributes of the credentials to be issued, where (some of) the attributes and the secret key can be hidden from the issuer and can be blindly “carried over” from credentials that the user already possesses (so that the issuer is guaranteed that hidden attributes were vouched for by another issuer). Taking inputs $\big (\textit{usk}, \textit{scope}_{\mathcal U}, \textit{rh},\left( \textit{ipk}_i, \textit{RI}_i, \textit{cred}_i, (a_{i,j})_{j=1}^{n_i}, R_i\right) _{i=1}^{k+1}, E, \textit{M}, \textit{vupk},\textit{dbid}\, \big )$, the issuance token generation algorithm outputs a user pseudonym $\textit{nym}$ and a public/secret issuance token $(\textit{pit},\textit{sit})$. The inputs are defined as follows:

  • $\textit{usk}$ is the user’s secret key;

  • $\textit{scope}_{\mathcal U}$ is the scope of the generated user pseudonym $\textit{nym}$, where $\textit{scope}=\varepsilon$ if no pseudonym is to be generated (in which case $\textit{nym}=\varepsilon$);

  • $\textit{rh}$ is the revocation handle for $\textit{cred}_{k+1}$ (e.g., chosen by the issuer before);

  • $(\textit{ipk}_i,\textit{RI}_i)_{i=1}^k$ are the issuers’ public keys and current revocation information for $(\textit{cred}_i)_{i=1}^k$; $(\textit{ipk}_{k+1},\textit{RI}_{k+1})$ correspond to the issuer of the new credential;

  • $(\textit{cred}_i)_{i=1}^{k}$ are credentials owned by the user and involved in this issuance and $\textit{cred}_{k+1} = \varepsilon$ is a placeholder for the new credential to be issued;

  • $R_i \subseteq [n_i]$ is the set of attribute indices for which the value is revealed;

  • for $i \in [k]$, $(a_{i,j})_{j=1}^{n_i}$ is the list of attribute values certified in $\textit{cred}_i$; $(a_{k+1,j})_{j \in R_{k+1}}$ are the attributes of $\textit{cred}_{k+1}$ that are revealed to the issuer;

  • $(a_{k+1,j})_{j \not \in R_{k+1}}$ are the attributes of $\textit{cred}_{k+1}$ that remain hidden;

  • $((k+1,j),(i',j')) \in E$ means that the jth attribute of the new credential will have the same value as the $j'$th attribute of the $i'$th credential;

  • $\textit{M}\in \{0,1\}^*$ is a message to which the issuance token is to be bound;

  • $\textit{vupk}$ is the user’s vault public key;

  • $\textit{dbid}$ is the device’s binding identifier which can be set to $\varepsilon$ if the new credential should not be device bound.

• On inputs $\big (\textit{nym},\textit{pit}, \textit{scope}_{\mathcal U}, \textit{rh}, \left( \textit{ipk}_i, \textit{RI}_i, (a_{i,j})_{j \in R_i}\right) _{i=1}^{k+1}, E, \textit{M}\big )$, this issuance token verification algorithm outputs whether to accept or to reject the issuance token. For $j=1,\dots ,k$ all inputs are as before, but for $k+1$ they are for the new credential to be issued based on $\textit{pit}$.

• In the interactive issuance protocol, the user takes input $\textit{sit}$, whereas the issuer takes inputs $(\textit{isk}, \textit{pit}, \textit{RI})$, where $\textit{pit}$ has been verified by the issuer before. At the end of the protocol, the user obtains a credential $\textit{cred}$ as an output, while the issuer receives an updated revocation information $\textit{RI}'$.

• On input $\big (\textit{usk}, \textit{scope}_{\mathcal U}, \big ( \textit{ipk}_i, \textit{RI}_i, \textit{cred}_i, (a_{i,j})_{j=1}^{n_i}$, $R_i\big )_{i=1}^{k}, E, \textit{M}, \textit{dsk}, \textit{scope}_{\mathcal D}, \big (\textit{dipk},\textit{RI}_\mathcal {DI}, \textit{dcred}\big ), \mathcal {BD}, \textit{vupk}\big )$, the presentation algorithm outputs a presentation token $\textit{pt}$, a user pseudonym $\textit{nym}$, and a device pseudonym $\textit{dnym}$. Most of the inputs are as before, but:

  • $E\subseteq \left\{ (i,j) : i\in [k], j\in [n_i]\right\}$, where $((i,j), (i',j')) \in E$ means that the presentation token proves that $a_{i,j} = a_{i',j'}$ without revealing the actual attribute values. That is, E enables one to prove equality predicates;

  • $\textit{M}$ is a message to which the presentation is bound. This might, e.g., be a nonce chosen by ${\mathcal V}$ to prevent replay attacks, where ${\mathcal V}$ uses a presentation token to impersonate a user towards another verifier;

  • $\textit{dsk}$ is the user’s device secret key stored in the secure element of the device;

  • $\textit{scope}_{\mathcal D}$ is the scope of the generated device pseudonym $\textit{dnym}$;

  • $\textit{dipk}$ and $\textit{RI}_\mathcal {DI}$ are the public key and current revocation information of the issuer of the device credential $\textit{dcred}$;

  • $\mathcal {BD}\subseteq [k]$ is a set of indices specifying which credentials are device-bound;

  • $\textit{vupk}$ is the user’s vault public key;

• The presentation verification algorithm takes $\big (\textit{pt}, \textit{nym}, \textit{scope}_{\mathcal U},( \textit{ipk}_i, \textit{RI}_i, (a_{i,j})_{j \in R_i})_{i=1}^{k}, E, \textit{M}, \textit{dnym}, \textit{scope}_{\mathcal D}, \textit{dipk}, \textit{RI}_\mathcal {DI}, \mathcal {BD}\big )$ defined as before as inputs, and outputs whether to accept or to reject a presentation token. For notational convenience, we assume that a term like $(a_{i,j})_{j \in R_i}$ implicitly also describes the set $R_i$.

• The revocation algorithm takes as inputs $(\textit{isk}, \textit{RI}, \textit{rh})$, where $\textit{isk}$ is the issuer’s secret key, $\textit{RI}$ is the current revocation information, and $\textit{rh}$ is the revocation handle to be revoked. It outputs an updated revocation information $\textit{RI}'$.

• The backup token generation algorithm takes as input $\big (\textit{dsk}, \textit{vupk},\textit{dipk}, \textit{RI}_\mathcal {DI}, \textit{dcred}, \textit{dbid}\big )$, where all the values are as before. It outputs a device pseudonym $\textit{dnym}$ and a public/secret backup token $(\textit{pbt},\textit{sbt}$), which will allow the user to carry over the current $\textit{dbid}$ into a new device upon restoring. In theory, the entire backup token may be stored in a public cloud, as no adversary would be able to use it to get a new device credential re-issued. However, as $\textit{sbt}$ may contain personally identifying information, it is recommended to store $\textit{sbt}$ privately or only in an encrypted form.

• In the device restoring protocol, the user takes as input $(\textit{sbt},\textit{dipk},\textit{dmpk},\textit{vusk},\textit{dsk},\textit{dcred}_{init},\textit{drh})$, whereas the device issuer takes as input $(\textit{dnym},\textit{pbt},\textit{disk},\textit{dmpk},\textit{RI}_\mathcal {DI},\textit{drh})$. At the end of the protocol, the user outputs a fresh device credential $\textit{dcred}$, while the issuer receives an updated revocation information $\textit{RI}'_\mathcal {DI}$.

2.2 Security Definitions (Informal)

We now next describe the security properties of an attribute-based credential system with backup. Our definitions extend that of Camenisch et al. [CKL+14], who gave a comprehensive formal definitional framework for traditional credential schemes. As our system involves more types of parties and offers more interfaces, the formal definitions are quite complex, thus we only sketch the intuition here and refer to the full version for the formal definitions.

Oracles. In our definitions, the adversary is granted access to three oracles: a device manufacturer oracle $\mathcal {O}^\mathtt{producer}$, an issuer oracle $\mathcal {O}^\mathtt{issuer}$, and a user oracle $\mathcal {O}^\mathtt{user}$, allowing the adversary to interact with honest device manufacturers, issuers, and users, respectively. While most of the interfaces of the oracles are natural, $\mathcal {O}^\mathtt{user}$ has additional interfaces that allow the adversary to “steal” a device with a specific set of credentials from an honest user. Furthermore, the adversary is given interfaces to use such a device. His available options depend on the assumed security guarantees of the devices. We explicitly distinguish the following three types of devices, but our definitions are flexible enough to be easily adopted for other settings as well. First, if the devices are assumed to have secure memory and are protected by strong PINs, then the adversary essentially cannot profit from the stolen device at all. Second, if the memory is assumed to be secure but no strong PINs are used, then the adversary can use (i.e., backup, present, etc.) the stolen device and the credentials on them, but he does not learn the precise values of the user secret key or the credentials. Finally, if no assumption on the device are made, the adversary learns all the information stored on the device, including the user secret key and the credentials.

We believe that parameterizing our security definitions by the assumed security of the devices is useful to realistically model a broad range of real world scenarios, as, for instance, the security guarantees of eID cards, smart phones, or public transport tickets might drastically differ in practice. Clearly, making no assumptions on the devices results in the strongest definitions; however, as the computational capacity of embedded devices is often limited, our approach of considering additional properties is essential to obtain practical protocols.

Completeness. If all parties behave honestly, all protocols can be run successfully. In particular, honest users interacting with an honest counterpart can always activate, register, and restore devices, as well as obtain and present credentials.

Unforgeability. We define unforgeability as a game between an adversary and the $\mathcal {O}^\mathtt{producer}$, $\mathcal {O}^\mathtt{issuer}$, $\mathcal {O}^\mathtt{user}$ oracles. The adversary can produce new devices, obtain and revoke credentials from honest issuers, instruct honest users to obtain credentials on inputs of his choice, request presentation tokens and receive backup tokens for given device credentials. Moreover, as mentioned above, he can “steal” devices and receive the device credential together with the software credentials and secret keys. At the end of the game the adversary outputs a number of presentation tokens and pseudonyms and wins if at least one of the presentation tokens is a forgery, or an issuance token successfully submitted to the honest issuer oracle was a forgery. A token is a forgery if it is inconsistent with the world the adversary interacts with using oracles $\mathcal {O}^\mathtt{producer}$, $\mathcal {O}^\mathtt{issuer}$, and $\mathcal {O}^\mathtt{user}$. Informally, being consistent here means that for each token returned by the adversary, all software credentials are bound to the same use secret key, the pseudonym $\textit{nym}$ is sound for the given scope $\textit{scope}_{\mathcal U}$, values of revealed attributes are correct, the equality relation E is satisfied, all credentials presented in the token are either bound to the same device binding identifier $\textit{dbid}$ or to $\varepsilon$ and bound to the same vault public key. Moreover, presentation tokens must have been created using a valid device credential (issued for a genuine device using restore or register), the device pseudonym $\textit{dnym}$ is sound for the given scope $\textit{scope}_{\mathcal D}$ and the device credential must be signed such that the signature is verifiable with the vault public key.

Privacy. Similar to Camenisch et al. [CKL+14], we define privacy via a simulation based approach. We consider a set of honest users and let the adversary control all other parties in the system (device manufacturers, issuers, and verifiers). It should be computational infeasible for the adversary to distinguish whether he is communicating with the real set of honest users, or with a simulator, $\mathsf{S}$, that only has access to the public information of the respective protocol (e.g., revealed attributes, scopes, public keys). For this, we define a filter $\mathcal F$ that has the same interfaces as the user oracle $\mathcal {O}^\mathtt{user}$, but sanitizes the inputs beforeforwarding them to the $\mathsf{S}$. For instance, unlinkability of presentation is ensured by not forwarding the credential identifiers $\textit{cid}$ (that the adversary gives to $\mathcal {O}^\mathtt{user}$) to $\mathsf{S}$. Furthermore, the filter performs comprehensive book keeping to exclude trivial distinguishing attacks that would result from requesting presentation tokens from invalid credentials which would be answered by the $\mathsf{S}$ but not by $\mathcal {O}^\mathtt{user}$.

3 A Generic Construction and Its Security

One possible way to realize recoverable device-bound credentials would be to choose a unique “recovery secret” a for each device-bound credential and embed its image through a one-way function $\mathsf{f}(a)$ as an additional attribute in the credential. This attribute is not revealed during presentation, but to backup a credential $\textit{cred}$, he stores a presentation token $\textit{pt}$ revealing $\mathsf{f}(a)$ on insecure backup media, and stores a in a secure offline vault. To restore $\textit{cred}$ upon loss, the user sends $\textit{pt}$ and a to the issuer, who checks if $\textit{pt}$ and $\mathsf{f}(a)$ are correct, and then participates in an advanced issuance protocol that allows the user to blindly carry over all attributes from $\textit{cred}$ into a new credential that will be bound to freshly chosen recovery secret $a'$.²

One drawback of this construction is that a malicious device issuer getting access to a user’s device carrying some software credentials could simply re-issue himself a new device credential, as he would then just omit the proof of knowledge for a. The device issuer could then use the user’s software credentials with the new device, and the user would have no option to revoke the malicious device credential as it would contain a fresh revocation handle.

This problem could be mitigated by encrypting credentials before loading them onto the device. The decryption key could be stored inside the secure element of the device, and the credentials would only be decrypted in this secure environment. So a malicious device issuer finding a user’s device would not learn the user’s software credentials and thus could not impersonate him. However, reality shows that virtually any tamperproof device can be broken by a sufficiently powerful adversary. In this case a user could again be impersonated.

One solution to this problem is to let the verifier not only check that the user owns a valid device credential, but also that the user “accepted” this credential. On a very high level, this can be done by letting the user sign his device credential, and embed the verification key of this signature into all his credentials as an attribute. Then, at presentation, the user shows that he owns a device credential and a signature thereon, and that the public verification key is also contained in all the other credentials. As a malicious device issuer may never learn the signing key of this user (as it is stored in a secure vault), he may not impersonate the user with a fresh device credential any more, as this would require forging a signature on this credential.

A bit more precisely, each user computes a signature key pair $(\textit{vusk},\textit{vupk})$ and stores $\textit{vusk}$ in a bank vault as his vault user secret key, and only needs to access $\textit{vusk}$ when (re-)obtaining device credentials. After buying and activating a device, the user requests a device credential $\textit{dcred}$, that certifies the validity of the device and a unique device binding identifier $\textit{dbid}$. The device credential $\textit{dcred}$ is bound to $\textit{vupk}$. All software credentials also get bound to $\textit{vupk}$, and optionally to $\textit{dbid}$ if the credential is to be bound to a specific device; if no $\textit{dbid}$ is given, the credential can be used with any device. Upon loss of a device, the user now only needs to get $\textit{dcred}$ re-issued, but all the software credentials can be left unchanged. To ensure that only the legitimate user can re-obtain and later prove possession of a device credential, we let the user sign the (unique) revocation handle $\textit{rh}$ of $\textit{dcred}$ using $\textit{vusk}$. Upon presentation, the user now not only shows that he possesses a device credential, but also that he knows a signature under $\textit{vupk}$ on $\textit{rh}$. This signature protects against malicious credential issuers, which cannot create such proof of signature knowledge on a non-revoked token $\textit{rh}$. Unfortunately, binding the credentials to $\textit{vupk}$ by adding it as an attribute does not work here generically, as this would require that the attribute space of the credential scheme subsumes the key (message) space of the signature scheme. Furthermore, standard signatures would require the verifier to learn the signature verification key $\textit{vupk}$, which must not be revealed to maintain unlinkability. Therefore, upon device registration, the user commits to $\textit{vupk}$ and lets the issuer additionally sign this commitment. Using commuting signatures [Fuc11] additionally allows us to perform the required proofs with only publishing a commitment to $\textit{vupk}$, but not $\textit{vupk}$ itself, therefore achieving the required privacy goals.

What is left, is to bind this signature to the specific credential. To do so, the issuer, instead of only signing the vault public key, signs a combination of $\textit{vupk}$ and the revocation handle, $\textit{rh}$, for the credential issued. Thus, once the credential gets revoked, the signature of the issuer becomes useless. Since revocation handles do not necessarily belong to the message (key) space of commuting signatures, we sign the value $\phi (\textit{rh})$ instead of signing the actual revocation handle $\textit{rh}$, for some appropriate mapping function $\phi$. Finally, we also use a proof system that allows to verify that commitments to $\textit{rh}$ and $\phi (\textit{rh})$ are consistent.

3.1 Building Blocks

In the following, we briefly recap the non-standard building blocks required for the generic construction presented in this section.

Privacy-Enhancing Attribute-Based Credentials. Because of space limitations and to avoid redundancy, we refrain from giving formal definitions for $\mathsf{PABC}$ systems, but refer to Camenisch et al. [CKL+14].

Informally, anonymous credentials (without backup) have the same interfaces as introduced in Sect. 2.1, except for all the backup-related parts. That is, they consist of the following algorithms and protocols: $\mathsf{SPGen}, \mathsf{UKGen}, \mathsf{IKGen}, \mathsf{ITGen}, \mathsf{ITVf},\langle {{\mathcal U}}.{\mathsf{Issue}}; {{\mathcal I}}.{\mathsf{Issue}}\rangle , \mathsf{Present}, \mathsf{Verify}, \mathsf{Revoke}$. The input/output behavior and the required security properties are again similar to Sects. 2.1 and 2.2, respectively.

Commuting Signatures and Verifiable Encryption. On a high level, commuting signatures combine digital signatures, encryption, and proof systems, such that one can commit to (any subset of) signature verification key, message, and signature, and still be able to prove that the three values are a valid key/message/signature tuple. In the following we give a slightly simplified version of the interfaces introduced by Fuchsbauer [Fuc11].

• $\mathsf{SPGen}_\mathsf{CS}$ . On input global system parameters $\textit{spar}_\mathtt{g}$, this system parameter generation algorithms outputs signature parameters $\textit{spar}_\mathsf{CS}$. These system parameters are input to all algorithms in the following, but we will sometimes omit this for notational convenience.

• $\mathsf{KeyGen}_\mathsf{CS}$ . On input $\textit{spar}_\mathsf{CS}$, this key generation algorithm outputs a signature key pair $(\textit{sk},\textit{pk})$.

• $\mathsf{Com}_\mathsf{CS}$ . On input a message m in the signature or the key space, this commitment algorithm outputs a commitment ${\textit{c}s}_\mathcal {M}$ and opening information ${\textit{o}cs}_\mathcal {M}$.

• $\mathsf{Com_{\mathcal {M}}}$ . On input a message m from the message space, this commitment algorithm extends $\mathsf{Com}_\mathsf{CS}$ by, among others, proofs of consistency. Note that the key space is consistent with the message space and therefore one can also use this algorithm to commit to verification keys.

• $\mathsf{DCom}_\mathsf{CS}$ . On input a commitment ${\textit{c}s}_\mathcal {M}$ and opening ${\textit{o}cs}_\mathcal {M}$, this decommitment algorithm outputs the committed message m.

• $\mathsf{CombCom}_\mathsf{CS}$ . On input two commitment/opening pairs $({\textit{c}s}_1,{\textit{o}cs}_1),({\textit{c}s}_2,{\textit{o}cs}_2)$ to $m_1,m_2$ in the message or key space, this commitment combining algorithm outputs a commitment/opening pair $({\textit{c}s}_3,{\textit{o}cs}_3)$ of type $\mathsf{Com_{\mathcal {M}}}$ to $m_1 \otimes m_2$.

• $\mathsf{VerCombCom}_\mathsf{CS}$ . On input three commitments ${\textit{c}s}_i$, $i=1,2,3$, this combined commitment verification algorithm outputs 1, if and only if ${\textit{c}s}_3$ is the output of $\mathsf{CombCom}_\mathsf{CS}$ on input ${\textit{c}s}_1,{\textit{c}s}_2$.

• $\mathsf{SigCom}_\mathsf{CS}$ . On input a secret key $\textit{sk}$ and a commitment ${\textit{c}s}_\mathcal {M}$, this commitment signing algorithm outputs a signature $\sigma$, a commitment/opening pair $({\textit{c}s}_\sigma ,{\textit{o}cs}_\sigma )$ to $\sigma$, and a proof $\pi _\sigma$ of the validity of the signature.

• $\mathsf{Verify}_\mathsf{CS}$ . On input a public key $\textit{pk}$, a message m, a signature $\sigma$ (or commitments to (some of) these values), and a proof $\pi$, this verification algorithm outputs $\mathsf{accept}$ if and only if $\pi$ is a valid proof that $\sigma$ is a signature on m for the public key $\textit{pk}$.

• $\mathsf{AdPrC}$ . On input $\textit{pk}$, ${\textit{c}s}_\mathcal {M}$, $({\textit{c}s}_\sigma ,{\textit{o}cs}_\sigma )$, and $\pi$ such that $\mathsf{Verify}_\mathsf{CS}(\textit{pk},{\textit{c}s}_\mathcal {M}, \sigma ,\pi )=\mathsf{accept}$ (where $\sigma$ is obtained using $\mathsf{DCom}_\mathsf{CS}$), this committing proof adaption algorithm outputs a proof $\pi '$ such that $\mathsf{Verify}_\mathsf{CS}(\textit{pk},{\textit{c}s}_\mathcal {M},{\textit{c}s}_\sigma ,\pi ')=\mathsf{accept}$; to decommit in a proof, $\mathsf{AdPrDC}$ works the other way round (i.e., adapts $\pi$ such that it verifies for $\sigma$ and not for ${\textit{c}s}_\sigma$).

• $\mathsf{AdPrC_{\mathcal {M}}}$ . On input $\textit{pk}$, $({\textit{c}s}_\mathcal {M},{\textit{o}cs}_\mathcal {M})$, ${\textit{c}s}_\sigma$, and $\pi$ such that $\mathsf{Verify}_\mathsf{CS}(\textit{pk},m,{\textit{c}s}_\sigma ,\pi )=\mathsf{accept}$, this committing proof adaption algorithm outputs $\pi '$ such that $\mathsf{Verify}_\mathsf{CS}(\textit{pk},{\textit{c}s}_\mathcal {M},{\textit{c}s}_\sigma ,\pi ')=\mathsf{accept}$; again, $\mathsf{AdPrDC_{\mathcal {M}}}$ works the other way round,

• $\mathsf{AdPrC_{\mathcal {K}}}$ . On input $({\textit{c}s}_\textit{pk},{\textit{o}cs}_\textit{pk})$, ${\textit{c}s}_\mathcal {M}$, ${\textit{c}s}_\sigma$, and $\pi$ such that $\mathsf{Verify}_\mathsf{CS}(\textit{pk},{\textit{c}s}_\mathcal {M},{\textit{c}s}_\sigma ,\pi )=\mathsf{accept}$, the committing proof adaption algorithm outputs $\pi '$ such that $\mathsf{Verify}_\mathsf{CS}({\textit{c}s}_\textit{pk},{\textit{c}s}_\mathcal {M},{\textit{c}s}_\sigma ,\pi ')=\mathsf{accept}$; $\mathsf{AdPrDC_{\mathcal {K}}}({\textit{c}s}_\textit{pk},{\textit{c}s}_\mathcal {M},{\textit{c}s}_\sigma ,\pi )$ works the other way round.

We require that $(\mathsf{Com}_\mathsf{CS},\mathsf{DCom}_\mathsf{CS})$ is a secure extractable commitment scheme. We also require strong unforgeability (under chosen message attack), i.e., the adversary cannot output a new pair message/signature $(m,\sigma )$. Moreover, all the proofs must be simulatable using an appropriate trapdoor, for details we refer to Fuchsbauer [Fuc11].

In addition to the above algorithms, Fig. 2 specifies the algorithm $\mathsf{RandSign}$ that we will use in our construction. The procedure takes as input a commuting signature for which the signature is given as commitment and adapts it to a commuting signature for which the signature, the message and optionally the public key are given as commitments (the commitment to signature is re-randomized), such that the inputs ${\textit{c}s}_\sigma$ and $\pi _\sigma$ cannot be linked to ${\textit{c}s}'_\sigma$ and $\pi '_\sigma$.

Fig. 2.

$\mathsf{RandSign}((\textit{pk},{\textit{c}s}_\textit{pk},{\textit{o}cs}_\textit{pk}),({\textit{c}s}_\mathcal {M},{\textit{o}cs}_\mathcal {M}),(\sigma ,{\textit{c}s}_\sigma ,{\textit{o}cs}_\sigma ,\pi _\sigma ))$

3.2 The Construction

In the following we show how to build a $\mathsf{BPABC}$ system from a $\mathsf{PABC}$ system and a commuting signature scheme ($\mathsf{Com_{\mathcal {M}}},\dots$). In the construction, let $\mathsf{H}_\mathcal {AS}: \{0,1\}^* \rightarrow \mathcal {AS}$ and $\mathsf{H}_\mathcal {MS}: \{0,1\}^* \rightarrow \mathcal {MS}$ be collision-resistant hash functions, where $\mathcal {AS}$ is the attribute space of the $\mathsf{PABC}$ system, and $\mathcal {MS}$ is the message space of presentation tokens used in the $\mathsf{PABC}$ system. Let ($\mathsf{Com}_\mathtt{c},\dots$) be a standard commitment scheme. Furthermore, let $\phi$ be a homomorphism from the message space of $\mathsf{Com}_\mathtt{c}$ to the message space of $\mathsf{Com_{\mathcal {M}}}$, that additionally has the property that $\phi (m_1) \otimes \phi (m_2) = \phi (m_1 \oplus m_2)$, where $m_1,m_2, m_1 \oplus m_2$ are in the message space of $\mathsf{Com}_\mathtt{c}$. Finally, let $(\mathsf{Prove_\phi },\mathsf{Verify_\phi })$ be a zero-knowledge proof system for statements:

$$\mathsf{ZKP}\left[ (\alpha ): c_1 = \mathsf{Com_{\mathcal {M}}}(\phi (\alpha )) ~\wedge ~ c_2 = \mathsf{Com}_\mathtt{c}(\alpha )\right] .$$

Below we give a simplified generic construction of our $\mathsf{BPABC}$ scheme, based on the $\mathsf{PABC}$ credential scheme [CKL+14] and commuting signatures. The complete construction is given in the full version and actually does not build upon $\mathsf{PABC}$’s, but rather extends the generic $\mathsf{PABC}$-construction, as we require access to the commitment values produced and consumed by the building blocks of the $\mathsf{PABC}$ scheme. In the description below, we assume, for the sake of simplicity, that we can extract the commitments from $\mathsf{PABC}$ presentation and issuance tokens, which allows us to focus on the extensions needed to obtain the $\mathsf{BPABC}$.

Setup and Key Generation

$\underline{\mathsf{SPGen}}$: The system parameters $\textit{spar}$ consist of the parameters $\textit{spar}_\mathsf{PABC}$ of the $\mathsf{PABC}$ system, $\textit{spar}_\mathsf{CS}$ of the commuting signature scheme, and two attributes $\{ \mathsf{initial}, \mathsf{activated}\} \in \mathcal {AS}$. These parameters in particular specify all required domains, e.g., of revocation handles, etc.

$\underline{\mathsf{UKGen}}$: As in $\mathsf{PABC}$, i.e., compute the user key as .

$\underline{\mathsf{VKGen}}$: Compute the vault keys as , e.g., being keys for the commuting signature scheme.

$\underline{\mathsf{IKGen}}$: The issuer key consists of an issuer’s key for the $\mathsf{PABC}$ system and a key for the commuting signature scheme. For device credential issuers the key also comprises two scopes and list to keep track of used pseudonyms:

• Compute .

• Compute .

• Set $\textit{ipk}= (\textit{ipk}_\mathsf{PABC},\textit{ipk}_\mathsf{CS})$, $\textit{isk}= (\textit{isk}_\mathsf{PABC},\textit{isk}_\mathsf{CS},\textit{ipk})$, and $\textit{RI}= \textit{RI}_\mathsf{PABC}$.

• For device credential issuers further generate two scopes (for backup pseudonyms and for registration pseudonyms) and an empty list $\mathcal {L}_\textit{dnym}$ to store used pseudonyms. Set $\textit{dipk}= (\textit{ipk}, \textit{scope}_{bup}, \textit{scope}_{reg})$, $\textit{disk}= \textit{isk}$, and $\textit{RI}_\mathcal {DI}= (\textit{RI}, \mathcal {L}_\textit{dnym})$.

$\underline{\mathsf{DMKGen}}$: The device manufacturer’s key consists of an issuer’s key for the $\mathsf{PABC}$ system, a scope for activation pseudonyms and an empty list $\mathcal {L}_{\mathtt{cert}}$ to store used pseudonyms:

• Compute .

• Generate empty list .

• Set $\textit{dmpk}= (\textit{dmpk}_\mathsf{PABC},\textit{RI}_\mathsf{PABC},\mathcal {L}_{\mathtt{cert}},\textit{scope}_{act})$, and the secret key to $\textit{dmsk}= (\textit{dmsk}_\mathsf{PABC},\textit{dmpk}_\mathsf{PABC})$.

$\underline{\mathsf{Produce}}$: Generate an initial device secret key $\textit{dsk}_{\mathtt{cert}}$ and issue a device credential under $\textit{dmsk}$.

• Compute device secret key .

• Choose a random revocation handle $\textit{drh}$.

• Issue (locally) a $\mathsf{PABC}$ credential $\textit{cred}_{\mathtt{cert}}$ for the attribute $\mathsf{initial}$, device key $\textit{dsk}_\mathtt{cert}$ and revocation handle $\textit{drh}$ under the device manufacturer’s issuance key $\textit{dmsk}_\mathsf{PABC}$.

• Set $\mathtt{cert}= (\textit{cred}_{\mathtt{cert}},\textit{dsk}_{\mathtt{cert}})$.

Device Activation and Registration

$\underline{\mathsf{Activate}}$: To activate a device, the user runs a protocol with the device manufacturer where ${\mathcal U}$ derives a new device secret key $\textit{dsk}$ as $\textit{dsk}= \textit{dsk}' \oplus \textit{dsk}_{\mathtt{cert}}$ for a randomly chosen $\textit{dsk}'$. The user also obtains a credential on $\textit{dsk}$ from $\mathcal {DM}$. Thereby, $\mathcal {DM}$ can verify that $\textit{dsk}$ is correctly derived from a previously certified $\textit{dsk}_\mathtt{cert}$ but does not learn the new device key. A simplified version of the activation protocol is depicted in Fig. 3. For the sake of simplicity, we therein omit the openings from the in- and outputs of the commitment algorithms.

Fig. 3.

Device activation

$\underline{\mathsf{Register}}$: To register a device with a device credential issuer $\mathcal {DI}$, the user (assisted by his device) runs a protocol with $\mathcal {DI}$. Therein, ${\mathcal U}$ shows that he has an activation credential $\textit{dcred}_{init}$ from $\mathcal {DM}$ on some (secret) device key $\textit{dsk}$ and identifier $\textit{dbid}$. The device credential issuer then blindly carries over $\textit{dsk}, \textit{dbid}$ into a new credential that also includes a revocation handle $\textit{drh}$. In addition, $\mathcal {DI}$ also signs a commitment on a combination of $\textit{drh}$ and the user’s vault public key $\textit{vupk}$, and the user signs a commitment of $\phi (\textit{drh})$, both using the commuting signature scheme. The registration information then consists of the credential and both signatures. The simplified registration protocol is given in Fig. 4. For simplicity, we again omit the openings from the in- and outputs of the commitment algorithms.

Fig. 4.

Device registration

Credential Issuance and Presentation

$\underline{\mathsf{ITGen}}$: This algorithm produces an issuance token for input $(\textit{usk}, \textit{scope}_{\mathcal U}, \textit{rh},( \textit{ipk}_i, \textit{RI}_i, \textit{cred}_i, (a_{i,j})_{j=1}^{n_i}, R_i)_{i=1}^{k+1}, E, \textit{M}, \textit{vupk},\textit{dbid}_{\mathcal D}\, )$ and combines an $\mathsf{PABC}$ issuance token with a commuting signature as follows:

• 1. Compute $\mathsf{PABC}$ issuance token. First, the input to $\mathsf{ITGen}_\mathsf{PABC}$ needs to be prepared such that is also captures the device-binding property, i.e., the relation E gets extended to express which credentials are device-bound, and that they are all bound to the same device. More precisely, given k credentials $\textit{cred}_i = (\textit{cred}'_i, \textit{dbid}_i, \textit{rh}_i, (\sigma _{{\mathcal I},i},{\textit{c}s}_{\sigma ,i},{\textit{o}cs}_{\sigma ,i}, \pi _{\sigma ,i}))$, one first verifies whether all device-bound credentials with $\textit{dbid}_i \ne \varepsilon$ contain the same device identifier $\textit{dbid}^*$. We denote $\mathcal {BD}$ for the set of all device-bound credentials. If at least one credential is device-bound, then the new credential should be also device-bound as well, i.e., verify that $\textit{dbid}_{\mathcal D}= \textit{dbid}^*$ and set $\textit{dbid}_{k+1} = \textit{dbid}_{\mathcal D}$. Abort with output $\bot$ if any of the checks fails. Update the relation expression to $E' = E \cup \{( (i,n_i+1),(j,n_j+1)): i,j \in \mathcal {BD}\cup \{k+1\} \}$ and use $E'$ to obtain the $\mathsf{PABC}$ issuance token. That is, we run $\mathsf{ITGen}_\mathsf{PABC} (\textit{usk},\textit{scope}_{\mathcal U},\textit{rh},( \textit{ipk}_i, \textit{RI}_i, \textit{cred}'_i, ((a_{i,j})_{j=1}^{n_i},\textit{dbid}_i), R_i)_{i=1}^{k+1}, E', \textit{M})$ receiving $(\textit{nym}',\textit{pit}',\textit{sit}')$.

• 2. Adapt and randomize the Issuer’s signatures $\sigma _{{\mathcal I},i}$ . The second part is based on the commuting signatures the user has obtained for all credentials $\textit{cred}_i$. The issuer’s signatures $\sigma _{{\mathcal I},i} = (\sigma _{i},{\textit{c}s}_{\sigma ,i},{\textit{o}cs}_{\sigma ,i}, \pi _{\sigma ,i})$ originally signed $\phi (\textit{rh}_i) \otimes \textit{vupk}$. We now adapt them to be signatures on fresh commitments of the same messages: we first compute $\mathsf{CS}$ commitments ${\textit{c}s}_{\textit{rh},i}$ (with openings ${\textit{o}cs}_{\textit{rh},i})$ for the individual revocation handles $\phi (\textit{rh}_{i})$ of all credentials. Then, we compute a $\mathsf{CS}$ commitment ${\textit{c}s}_\textit{vupk}$ (with opening ${\textit{o}cs}_\textit{vupk}$) for the user’s vault public key $\textit{vupk}$ and combine ${\textit{c}s}_\textit{vupk}$ with each ${\textit{c}s}_{\textit{rh},i}$ via $\mathsf{CombCom}_\mathsf{CS}$ to obtain commitments ${\textit{c}s}_{\mathcal {M},i}$ for messages $\phi (\textit{rh}_i) \otimes \textit{vupk}$. We then adopt and re-randomize the issuer’s signatures using $\mathsf{RandSign}$, which adapts the committed signatures to be signatures on the freshly computed commitments ${\textit{c}s}_{\mathcal {M},i}$. We denote the randomized and adapted signatures as $({\textit{c}s}'_{\sigma ,i},\pi '_ {\sigma ,i})$.

• 3. Combine both parts. Finally, we have to bind the $\mathsf{PABC}$ and the commuting signature part together. This is done by proving that the revocation handles committed in ${\textit{c}s}_{\textit{rh},i}$ are the same revocation handles to which the $\mathsf{PABC}$-issuance token commits as $(c_{\textit{rh},i},o_{\textit{rh},i})$ (which we extract from $\textit{pit}'$). For each $\textit{rh}_i$ we therefore compute . We set $\textit{pit}= (\textit{pit}',\mathcal {BD},{\textit{c}s}_\textit{vupk},({\textit{c}s}_{\mathcal {M},i}, {\textit{c}s}_{\textit{rh},i},\pi ^{\phi }_{\textit{rh},i},{\textit{c}s}'_{\sigma ,i},\pi '_{\sigma ,i})_{i=1}^k)$, $\textit{sit}= (\textit{sit}', \textit{dbid}_{\mathcal D}, {\textit{c}s}_\textit{vupk}, {\textit{o}cs}_\textit{vupk})$ and $\textit{nym}= \textit{nym}'$.

$\underline{\mathsf{ITVf}}$: Verify the $\mathsf{PABC}$ issuance token $\textit{pit}'$, proofs $\pi ^{\phi }_{\textit{rh},i}$, that $({\textit{c}s}'_{\sigma ,i},\pi '_{\sigma ,i})$ are valid issuer signatures on ${\textit{c}s}_{\mathcal {M},i}$, and that $\mathsf{VerCombCom}_\mathsf{CS}({\textit{c}s}_{\textit{rh}_i}, {\textit{c}s}_\textit{vupk}, {\textit{c}s}_{\mathcal {M},i}) = 1$ for $i=1, \dots , k$. Output $\mathsf{reject}$ if any of the check fails, and $\mathsf{accept}$ otherwise.

$\underline{\mathsf{Issue}}$: Issuance of a software credential (possibly bound to a device if $\textit{dbid}_{\mathcal D}\ne \varepsilon$) consists of a $\mathsf{PABC}$ issuance protocol, and a commuting signature generated by the issuer as depicted in Fig. 5.

Fig. 5.

Credential issuance

$\underline{\mathsf{Present}}$: A presentation token for $(\textit{usk}, \textit{scope}_{\mathcal U}, ( \textit{ipk}_i, \textit{RI}_i, \textit{cred}_i, (a_{i,j})_{j=1}^{n_i}, R_i)_{i=1}^{k}, E, \textit{M}, \textit{dsk}, \textit{scope}_{\mathcal D}, (\textit{dipk},\textit{RI}_\mathcal {DI}, \textit{dcred}), \mathcal {BD}, \textit{vupk})$ consists of two $\mathsf{PABC}$ presentation tokens (one for the software credentials, and one for the device credential) and randomized commuting signatures:

• 1. Compute $\mathsf{PABC}$ presentation token $\textit{pt}'$ for the software credentials. Parse each credential as $\textit{cred}_i = (\textit{cred}'_i, \textit{dbid}_i, \textit{rh}_i, \sigma _{{\mathcal I},i})$. Adapt the relation E to include the device-binding relations, i.e., use the indices in set $\mathcal {BD}$ to compute $E' = E \cup \{( (i,n_i+1),(j,n_j+1)): i,j \in \mathcal {BD}\}$. Compute $(\textit{nym},\textit{pt}')$ for all software credentials $\textit{cred}_1,\ldots ,\textit{cred}_k$ by running $\mathsf{Present}_\mathsf{PABC} (\textit{usk}, \textit{scope}_{\mathcal U}, ( \textit{ipk}_i, \textit{RI}_i,\textit{cred}_i',((a_{i,j})_{j=1}^{n_i},\textit{dbid}_i), R_i)_{i=1}^{k}, E', \textit{M})$.

• 2. Compute $\mathsf{PABC}$ presentation token $\textit{pt}''$ for the device credential. If $\textit{dcred}\ne \varepsilon$, parse $\textit{dcred}= (\textit{dcred}',\textit{drh},\sigma _{\mathcal {DI}},\sigma _{\mathcal U})$, and compute presentation token $(\textit{dnym},\textit{pt}'')$ as $\mathsf{Present}_\mathsf{PABC} ( \textit{dsk}, \textit{scope}_{\mathcal D}, ( \textit{ipk}_\mathcal {DI},\textit{RI}_\mathcal {DI},\textit{dcred}', (\textit{dbid}_{\mathcal D}) ), \emptyset , \textit{M})$. If $\textit{dcred}= \varepsilon$ abort with output $\bot$.

• 3. Bind $\textit{pt}'$ and $\textit{pt}''$ together. Extract $(c_{\textit{dbid},{\mathcal D}}, o_{\textit{dbid}, {\mathcal D}})$ from $\textit{pt}''$ and, for some $i\in \mathcal {BD}$, $(c_{\textit{dbid},i}, o_{\textit{dbid}, i})$ from $\textit{pt}'$. Prove that both commit to the same value in $\pi _\textit{dbid}$.

• 4. Adapt and randomize the Issuer’s signatures $\sigma _{{\mathcal I},i}$ and $\sigma _{\mathcal {DI}}$ . Similarly as in the $\mathsf{ITGen}$ algorithm we adapt the issuer’s signatures $\sigma _{{\mathcal I},i} = (\sigma _{i},{\textit{c}s}_{\sigma ,i},{\textit{o}cs}_{\sigma ,i}, \pi _{\sigma ,i})$ on $\phi (\textit{rh}_i) \otimes \textit{vupk}$ to be signatures on fresh commitments of the same messages. To this end, we first compute $\mathsf{CS}$ commitments ${\textit{c}s}_{\textit{rh},i}$ (with openings ${\textit{o}cs}_{\textit{rh},i})$ for the individual revocation handles $\phi (\textit{rh}_{i})$ for all $i= 1,\ldots , k, {\mathcal D}$. Then, we compute a $\mathsf{CS}$ commitment ${\textit{c}s}_\textit{vupk}$ (with opening ${\textit{o}cs}_\textit{vupk}$) for the user’s vault public key $\textit{vupk}$ and combine ${\textit{c}s}_\textit{vupk}$ with each ${\textit{c}s}_{\textit{rh},i}$ via $\mathsf{CombCom}_\mathsf{CS}$ to obtain commitments ${\textit{c}s}_{\mathcal {M},i}$ for messages $\phi (\textit{rh}_i) \otimes \textit{vupk}$. We then adopt and re-randomize the issuer’s signatures using $\mathsf{RandSign}$, which adapts the committed signatures to be signatures on the freshly computed commitments ${\textit{c}s}_{\mathcal {M},i}$. We denote the randomized and adapted signatures for all $i= 1,\ldots , k, {\mathcal D}$ as $({\textit{c}s}'_{\sigma ,i},\pi '_{\sigma ,i})$, where $({\textit{c}s}'_{\sigma ,{\mathcal D}},\pi '_{\sigma ,{\mathcal D}})$ stands for the adapted signature of the device credential issuer.

• 5. Adapt and randomize the User’s signature $\sigma _{{\mathcal U}}$ (contained in $\textit{dcred}$). In a similar vein, we adapt the user’s signature $\sigma _{{\mathcal U}} = (\sigma ,{\textit{c}s}_{\sigma ,{\mathcal U}},{\textit{o}cs}_{\sigma ,{\mathcal U}}, \pi _{\sigma ,{\mathcal U}})$ on the revocation handle of the device credential $\phi (\textit{drh})$ using procedure $\mathsf{RandSign}$. However, here we also adapt the proof using a commitment to $\textit{vupk}$. Note that this ensures that the final signature proof is not only for a committed signature on a committed message, but that also the public key is given as a commitment. This is required here, as the user’s public key would serve as a unique identifier otherwise. We denote the randomized user signature on message ${\textit{c}s}_{\textit{rh},{\mathcal D}}$ and under key ${\textit{c}s}_\textit{vupk}$ (computed in the step above) as $({\textit{c}s}'_{\sigma ,{\mathcal U}},\pi '_{\sigma ,{\mathcal U}})$.

• 6. Bind the $\mathsf{PABC}$ part and $\mathsf{CS}$ part together. This is again similar to the $\mathsf{ITGen}$ algorithm: we bind both parts together by extracting the commitments for all revocation handles from the $\mathsf{PABC}$ tokens and proving that they contain the same values as the $\mathsf{CS}$ commitments used in the commuting signatures part. That is, for all $i= 1,\ldots , k$ we extract $(c_{\textit{rh},i},o_{\textit{rh},i})$ from $\textit{pt}'$ and $(c_{\textit{rh},{\mathcal D}},o_{\textit{rh},{\mathcal D}})$ from $\textit{pt}''$ and compute . Finally, we compose the presentation token as $\textit{pt}= ((\textit{pt}', \textit{pt}'', \pi _\textit{dbid},{\textit{c}s}_\textit{vupk}, ({\textit{c}s}_{\mathcal {M},i}, {\textit{c}s}_{\textit{rh},i},\pi ^{\phi }_{\textit{rh},i},{\textit{c}s}'_{\sigma ,i},\pi '_{\sigma ,i})_{i=1}^{k, {\mathcal D}}, {\textit{c}s}'_{\sigma ,{\mathcal U}},\pi '_{\sigma ,{\mathcal U}}), \textit{nym}, \textit{dnym})$.

$\underline{\mathsf{Verify}}$: Verify both presentation tokens $(\textit{nym},\textit{pt}')$, $(\textit{dnym}, \textit{pt}'')$, proofs $\pi _\textit{dbid}$, $\pi ^{\phi }_{\textit{rh},i}$ and that all ${\textit{c}s}_{\mathcal {M},i}$ are valid combinations of commitments ${\textit{c}s}_{\textit{rh},i}$ and ${\textit{c}s}_\textit{vupk}$ (for $i= 1,\ldots , k, {\mathcal D}$). Moreover, verify the credential issuer’s signatures under ${\textit{c}s}_{\mathcal {M},i}$ and the user’s signature under ${\textit{c}s}_{\textit{rh},{\mathcal D}}$ and for key ${\textit{c}s}_\textit{vupk}$. Output $\mathsf{reject}$ if any of the checks fails, and $\mathsf{accept}$ otherwise.

$\underline{\mathsf{Revoke}}$: On input $(\textit{isk}, \textit{RI}, \textit{rh})$ parse $\textit{isk}$ as $(\textit{isk}_\mathsf{PABC},\textit{isk}_\mathsf{CS},\textit{ipk})$ and run the $\mathsf{PABC}$ revocation algorithm $\mathsf{Revoke}_\mathsf{PABC} (\textit{isk}_\mathsf{PABC},\textit{RI}_\mathsf{PABC},\textit{rh})$.

Backup and Restore

$\underline{\mathsf{BTGen}}$: Upon input $(\textit{dsk}, \textit{vupk},\textit{dipk}, \textit{RI}_\mathcal {DI}, \textit{dcred}, \textit{dbid}_{\mathcal D})$ parse $\textit{dcred}= (\textit{dcred}',\textit{drh},\sigma _{\mathcal {DI}},\sigma _{\mathcal U})$ and compute the presentation token $(\textit{dnym},\textit{pt}) \leftarrow \mathsf{Present}_\mathsf{PABC} ( \textit{dsk}, \textit{scope}_{bup}, ( \textit{ipk}_\mathcal {DI},\textit{RI}_\mathcal {DI},\textit{dcred}', (\textit{dbid}_{\mathcal D}) ), \emptyset , \textit{M})$ for the device credential. Extract the commitment and opening $(c_\textit{dbid}, o_\textit{dbid})$ to the device identifier $\textit{dbid}_{\mathcal D}$ and commitment and opening $(c_\textit{drh}, o_\textit{drh})$ to the device revocation handle. Set the public part to $\textit{pbt}= (\textit{pt}, \textit{drh}, o_\textit{drh})$, $\textit{sbt}=(\textit{dbid},c_\textit{dbid},o_\textit{dbid})$ and output $(\textit{dnym},\textit{pbt},\textit{sbt})$.

$\underline{\mathsf{Restore}}$: The restore procedure is initiated by the user when he obtained his new (and activated) device including a new device key $\textit{dsk}'$ and activation credential $\textit{dcred}_{init}'$. The user then runs the restore protocol with the device credential issuer $\mathcal {DI}$ where he obtains a new device credential $\textit{cred}'$ that contains the device identifier $\textit{dbid}$ from the backup token. The simplified protocol is given in Fig. 6.

Fig. 6.

Restore protocol

Theorem 1

(Informal). The $\mathsf{BPABC}$-system constructed above is unforgeable for all types of devices, if the underlying $\mathsf{PABC}$- and the $\mathsf{CS}$-schemes are unforgeable and $\mathsf{Prove_\phi }$ is extractable and sound. It is further private for devices with secure memory without PINs, if the $\mathsf{PABC}$-scheme is private, $\mathsf{Prove_\phi }$ is zero-knowledge, and the $\mathsf{CS}$ scheme can be simulated given commitments to messages or/and verification keys.

3.3 Intuition Underlying the Security Proofs

Due to space limitations, we only give the intuition of our security proofs.

Privacy. Our generic construction can be shown to be private, if one assumes secure memory without strong PINs, cf. Sect. 2.2. Note that without assuming secure memory, the adversary could in particular learn the user’s secret key from which it could (deterministically) derive pseudonyms for arbitrary scopes, and could thus easily link arbitrary presentations to the user; achieving privacy with insecure memory would therefore require to update $\textit{usk}$ upon re-issuance if scope-exclusive pseudonyms are required.

To prove the above statement we essentially need to show that the commuting signature part, the $\mathsf{PABC}$ scheme and the $\mathsf{Prove_\phi }$ prove system can be simulated. As our privacy definitions extend those given by Camenisch et al. [CKL+14], it can be shown that the parts related to the classic $\mathsf{PABC}$ system used in our construction can be simulated using their simulator. Simulating the $\mathsf{Prove_\phi }$ system that is used to bind revocation handles in $\mathsf{PABC}$ and $\mathsf{CS}$ commitments can be done by the zero-knowledge property of the used proof system. Finally we have to show that commuting signatures can be simulated. First note that in all used commuting signatures, the messages and the signatures are given as commitments. Moreover, the verification keys for those commuting signatures are either the publicly known keys of issuers or the users vault public key given also as commitment. Therefore, we can use the results from [Fuc11], that there exists a simulator, that given commitments to messages and verification keys can compute commitments to signatures and valid proofs of correctness.

Unforgeability. Our generic construction satisfies the unforgeability property for all types of devices. This means that there exists no forgery among the issuance and presentation tokens returned by the adversary in the unforgeability game.

First note that credentials in our generic construction are classic $\mathsf{PABC}$ system credentials with an additional commuting signature under $\phi (\textit{rh}) \otimes \textit{vupk}$. From the unforgeability property of the $\mathsf{PABC}$ system, it follows that all presentation or issuance tokens returned by the adversary satisfy that all software credentials are bound to the same user secret key, the pseudonym $\textit{nym}$ is sound for the given $\textit{scope}_{\mathcal U}$, the revealed attribute values are correct, the equality relation E for blinded attributes is satisfied, the committed device binding identifier are the same in all presented credentials (this is also ensured by the E relation) except the ones that are given opening information to $\varepsilon$, and the device pseudonym $\textit{dnym}$ is sound for the given $\textit{scope}_{\mathcal U}$. Moreover, from the binding property of the $\mathsf{CS}$ commitments scheme and the soundness property of the proof system $\mathsf{Prove_\phi }$ we have that the adversary cannot return presentation or issuance tokens that present credentials bound to different vault public keys. The initial credential and scope specific pseudonyms for static scopes ensure that the adversary cannot create tokens for devices that are restored from a backup token twice and restored or register without activation. Finally, the unforgeability of commuting signatures and the soundness property of $\mathsf{Prove_\phi }$ ensure that the adversary cannot create presentation tokens for software credentials with a device the device credential of which was revoked.

3.4 Instantiation

Due to space restrictions, we omit a full instantiation of our generic construction here. Similar to Camenisch et al. [CKL+14], it can be instantiated using Pedersen commitments [Ped91, DF02], CL-signatures [CL02], a variant of the Nakanishi et al. revocation scheme [NFHF09], and the pseudonym scheme used in the IBM identity mixer [IBM10]. The new parts of the construction based on commuting signatures can be instantiated using the scheme proposed by Fuchsbauer [Fuc11], and the proof system $\mathsf{Prove_\phi }$ can be obtained using standard techniques.