Delegatable Attribute-Based Anonymous Credentials from Dynamically Malleable Signatures

Abstract

We introduce the notion of delegatable attribute-based anonymous credentials (DAAC). Such systems offer fine-grained anonymous access control and they give the credential holder the ability to issue more restricted credentials to other users. In our model, credentials are parameterized with attributes that (1) express what the credential holder himself has been certified and (2) define which attributes he may issue to others. Furthermore, we present a practical construction of DAAC. For this construction, we deviate from the usual approach of embedding a certificate chain in the credential. Instead, we introduce a novel approach for which we identify a new primitive we call dynamically malleable signatures (DMS) as the main ingredient. This primitive may be of independent interest. We also give a first instantiation of DMS with efficient protocols.

This work was partially supported by the German Research Foundation (DFG) within the Collaborative Research Center “On-The-Fly Computing”(SFB 901).

1 Introduction

In this paper, we construct delegatable attribute-based anonymous credentials (DAAC) that offer fine-grained anonymous access control for many typical scenarios. For example, consider a company with the usual hierarchical organization structure. We want the company owner to be able to grant appropriate access rights to department managers. For this, he issues each of them a credential with certain attributes encoding what rights the department manager has. The department managers, in turn, should be able to grant appropriate subsets of their rights to their staff by delegating a (weaker) version of their credential to them. Then a staff member may want to grant access rights to her interns, etc.

This scenario could be trivially realized using certificate chains (similar to the ones used in TLS): the company owner signs the public key of a department manager alongside some string that encodes which attributes the manager has and which ones he may delegate to his staff. Then the department manager can extend the chain by signing a staff member’s public key, and so on.

However, our goal is to enable anonymity for authentication: An authorized user requesting access to a resource should be indistinguishable from all other users who have access to it. Still, the verifier, who is executing the authentication checks, should be assured that only authorized users can pass them. Overall, we have the following requirements:

• R1. The verifier must not learn the sequence of delegations a user’s credential went through.

• R2. The verifier must only learn as much as necessary about the attributes of the authenticating user or of any users involved in the delegation.

• R3. A user must not be able to grant other users more rights/attributes than he is allowed to.

• R4. A user should not be able to pass the authentication checks without being given an appropriate credential.

• R5. Users shall remain anonymous while delegating and receiving a credential.

Most previous constructions of delegatable credentials [1, 4, 14] fulfill R1, R3, R4 and R5. However, in those constructions the attributes of all users in the chain are presented in plain to the verifier. This violates R2. A more recent scheme [6] supports R1, R3, R4 and R2. However, in their construction, credential holders see all attributes of the users in the delegation chain. This violates R5. In this paper, we introduce the first construction of practical delegatable attribute-based anonymous credentials that supports all five requirements.

Our Model of Delegatable Attribute-Based Anonymous Credentials. In DAAC, users have a single secret key and can derive an arbitrary number of unlinkable public keys (usually called pseudonyms). Users can issue credentials to other users (also anonymously, if desired). A credential is parameterized with a delegation flag $d\in \{0,1\}$, which determines whether or not the credential is delegatable, and an attribute vector $(A_1,\dots ,A_n)\in (\mathbb {A}\cup \{\star \})^n$ for some set $\mathbb {A}$ (e.g., $\mathbb {A}= \mathbb {Z}_p$). Each $A_i$ in the attribute vector either takes on a concrete value from $\mathbb {A}$, or the special value $\star$, which can be interpreted as a placeholder that can be replaced with an arbitrary $\mathbb {A}$-value.

We define the $covers$ relation on attribute vectors that will determine what attributes the user can delegate and show. A vector $(A_1,\dots ,A_n)$ covers another vector $(A_1',\dots ,A_n')$ (we write $\vec {A}\succeq \vec {A}'$) if and only if $(A_i \ne \star ) \Rightarrow (A_i' = A_i)$ for all i. This means that the placeholder $\star$ can be replaced with any concrete $\mathbb {A}$ value (or $\star$ again), whereas concrete values from $\mathbb {A}$ cannot be changed.

Given a credential with delegation flag $d = 1$ and attribute-vector $\vec {A}$, a user is able to issue a credential with any delegation flag $d^*\in \{0,1\}$ and any attributes $\vec {A}^*$ as long as $\vec {A}\succeq \vec {A}^*$. A credential with delegation flag $d=0$ cannot be delegated any further. When showing a credential for an access policy $\phi$ (e.g., a Boolean formula over statements like “$A_2 = 13$”), the user proves that his attributes cover some concrete $\vec {A}'\in \mathbb {A}^n$ for which $\phi (\vec {A}') = 1$. Note that it is natural that whatever users can delegate, they can also show.

In the simplest case, each attribute $A_i$ may just encode a Boolean access right and users can delegate subsets of their access rights. In the concrete instantiation based on Construction 11 in our paper, you can encode arbitrary elements of $\mathbb {A}= \mathbb {Z}_p$ (e.g., short strings) into credentials, hence our scheme can realize more elaborate authentication scenarios. As a small example for this, the state of California may issue San Francisco a delegatable credential like $\vec {A} = (\star ,\star ,\texttt {San Francisco})$. This allows the city to delegate credentials with attributes $\vec {A}^* = (\texttt {John}, \texttt {Doe}, \texttt {San Francisco})$ to its citizens, but prohibits issuing credentials encoding other cities.

When authenticating with a credential, the only information revealed to the verifier is the root of the delegation chain (e.g., the company owner or the state), a pseudonym of the authenticating user, and the fact that the credential’s attributes fulfill some predicate.

Idea of Our Construction. We deviate from the usual way of constructing delegatable credentials and instead follow a novel approach. We identify a new primitive we call dynamically malleable signatures (DMS) as the main ingredient. DMS are similar to usual malleable signatures, but the set of allowed transformations is specific to each signature and can be incrementally restricted over time (“dynamic” refers to the fact that the set of allowed transformations is not static but can be changed “at runtime” for each signature). More specifically, the $\mathrm {Sign}$ algorithm takes some vector of messages $(m_1,\dots ,m_n)$ and an index set $I\subseteq \{1,\dots ,n\}$ as input and produces a signature $\sigma$ and a malleability key $mk$. The index set I determines which of the positions in the vector are malleable, i.e. given $\sigma$ and $mk$, anyone can derive a signature $\sigma '$ on any message $(m_1',\dots ,m_n')$ as long as $m_i' = m_i$ for all $i\notin I$. This process also yields a malleability key $mk '$ for $\sigma '$, which can be restricted to allow further modification of $\sigma '$ only on some (smaller) index set $I'\subseteq I$. In Sect. 5, we give an efficient construction of DMS with supporting protocols. Our construction is based on the Pointcheval-Sanders signature scheme [17] and it can be proven secure in the generic group model.

Using any secure DMS scheme with an efficient protocol to derive a signature on a committed value, we generically implement a DAAC as follows: With some details omitted, a credential for a user with secret $usk$ and attributes $\vec {A} = (15,7,\star , \star )$ is a dynamically malleable signature on $usk$ and $\vec {A}$. For each $\star$ in $\vec {A}$, we instead sign 0. More formally, in this example we would sign $(m_1,\dots ,m_5) := ( usk ,15,7,0,0)$ and allow the receiver to use malleability on the first index (to change $usk$ when delegating) and the last two indices (to model the $\star$), i.e. $I = \{1,4,5\}$. Unforgeability of the signature scheme then guarantees that this user cannot produce a credential whose first two attributes are not 15 and 7 (cf. requirement R3). If he wants to delegate attributes $\vec {A}' = (15,7,13,\star )$ to another user with secret key $usk '$, the two parties engage in a protocol to derive a signature on $( usk ', 15, 7, 13, 0)$ such that only the first and the last message can be changed further, i.e. $I' = \{1,5\}\subset I$. Note that the issuer’s $usk$ or his exact attributes are not part of the derived credential, immediately implying R1. Our delegation protocol will also ensure R5. To mark the credential non-delegatable ($d=0$), the delegator can remove the first index from the index set, which precludes the receiver from changing the signature to any other secret key $usk ''\ne usk '$. Showing the credential to a verifier follows standard procedure [15], i.e. the user runs a zero-knowledge protocol to prove knowledge of a signature on his user secret and on attributes fulfilling some policy (and that his user secret is consistent with his pseudonym). The zero-knowledge property ensures requirement R2 while the proof of knowledge property and the unforgeability of the signature scheme ensures R4.

Related Work on Delegatable Credentials. Chase and Lysyanskaya introduced the first anonymous delegatable credential system [8], which extended the idea of anonymous credentials [9] to enable delegation. Later, Belenkiy et al. published an elegant construction of delegatable credentials [4] and introduced formal security requirements. In their paper, delegatable credentials are defined through levels. Any user can publish a pseudonym $pk _\mathrm {root}$ and issue a level $L = 1$ credential to another user. Then, a level L credential can be used to derive a level $L+1$ credential for another user. When showing a credential, the verifier learns the root pseudonym $pk _\mathrm {root}$ of the credential, the prover’s pseudonym $pk _L$, and the credential’s level L.

The construction of [4] allows users to attach public attributes to a credential when delegating, meaning that a level L credential is parameterized with L attribute descriptions $(A_1,\dots ,A_L)\in (\{0,1\}^*)^L$, where the issuer of the level $\ell \le L$ credential chooses $A_\ell$. However, they do not describe a way to hide the attributes of any user in the delegation chain, which weakens anonymity considerably (cf. our requirement R2). Furthermore, there are no restrictions on the attribute strings a delegator can add when delegating a credential (cf. requirement R3). Hence the burden of verifying plausibility of delegated attributes lies with the verifier.

If we instantiate our generic construction of DAAC with our concrete DMS scheme (Sect. 5), a credential with n attributes consists of at most $n+3$ group elements. In particular, the credential size is independent of the delegation chain length. Using standard variants of Schnorr’s protocol, showing the credential can be done very efficiently compared to [4], whose credentials are Groth-Sahai proofs with size linear in the chain length. As a trade-off, we reach this level of efficiency mainly by (1) not encoding the delegation chain into credentials (which also precludes the feature of tracing the sequence of credential owners using a trapdoor), and (2) leveraging a new ad-hoc algebraic assumption for the construction of our concrete DMS scheme (there are delegatable credentials that are secure under standard assumptions, e.g., DLIN [7]).

Most other constructions [1, 7, 14] also follow roughly the same techniques as [4], i.e. using malleable proof systems (like Groth-Sahai) as a building block, improving upon and generalizing the original idea. However, there do not seem to be any constructions that improve upon their handling of (public) attributes.

More recently, Camenisch et al. published a delegatable credential system [6]. Their construction is very efficient and practical. They achieve this by allowing credential holders to see all attributes on all levels in plain, i.e. not offering anonymity for delegators. In many contexts, this is not a problem. However, consider the example of a distributed car sharing scenario where the car owner is issued a credential for his car. In a car-sharing fashion, he can delegate his access rights to any other person. In this scenario, the car owner has no reason to reveal his identity. Our construction shows that one does not have to sacrifice support for such scenarios to achieve practicality: Namely, our scheme’s efficiency is comparable to [6] while offering anonymity for delegators (R5).

Related Work on Malleable Signatures. Malleable signature schemes allow anyone to transform a signature on a message m to be valid for a different message $m'$ for a well-defined set $\mathcal {T}$ of allowed transformations on m (e.g., [7]).

In contrast, our notion of DMS allows signers to choose transformation sets $\mathcal {T}_\sigma$ on a per-signature basis, which can be further restricted to some subset $\mathcal {T}_{\sigma '}$ when transforming $\sigma$ to $\sigma '$.

The general idea for DMS is similar to homomorphic signatures like [2, 3, 5, 13]. In these constructions (mostly designed for network coding), a signer effectively signs a vector space by signing its base vectors with a homomorphic signature scheme. This allows computing signatures on any vector in the vector space. Like DMS, homomorphic signature schemes allow to derive signatures on related messages. However, the main feature of DMS is that one can derive signatures that are more restricted than the original. Furthermore, one cannot combine two restricted signatures to produce a signature on a message not covered by either of them.

2 Basics and Notation

For a random variable X, $[X]:=\{x\mid \Pr [X=x] > 0\}$ is the support of X. With $X\leftarrow S$, we denote that X is chosen uniformly at random from the set S. If X and Y are identically distributed random variables, we write $X \approx Y$. With $X\leftarrow A(y)$ we denote that X is generated by running the probabilistic algorithm A on input y. The notation $\Pr [X_1\leftarrow S, X_2\leftarrow A(y,X_1); \phi (X_1,X_2)]$ denotes the probability that the predicate $\phi (X_1,X_2)$ holds in the probability space described by $X_1,X_2$. For a prime number p, $\mathbb {Z}_p$ is the field of order p and $\mathbb {Z}_p^* = \mathbb {Z}_p{\setminus }\{0\}$.

Definition 1

Let A, B be probabilistic interactive algorithms that halt on every input. We write $y_A \leftarrow A(x_A)\leftrightarrow B(x_B) \rightarrow y_B$ to denote that A on input $x_A$ interacts with B on input $x_B$; then A outputs $y_A$ and B outputs $y_B$. Furthermore, we define $\mathrm {output}_A[A(x_A)\leftrightarrow B(x_B)]$ to be the random variable taking on $y_A$, i.e. the output of A after interacting with B.    $\diamond$

Definition 2

(Protocols and signatures of knowledge). The expression $ZKAK [(w);(x,w)\in \varPsi ]$ denotes a zero-knowledge argument of knowledge for the relation $\varPsi$. $NIZK [(w);(x,w)\in \varPsi ](m)$ denotes a signature of knowledge on message m for the relation $\varPsi$.    $\diamond$

Zero-knowledge arguments of knowledge can be implemented, for example, using Damgård’s technique [12] on Schnorr-like $\Sigma$ protocols. Signatures of knowledge can be implemented, for example, using the Fiat-Shamir heuristic.

3 Delegatable Attribute-Based Anonymous Credentials

In this section, we define DAAC. Each credential is parameterized with a vector $\vec {A} = (A_1,\dots ,A_n) \in (\mathbb {A}\cup \{\star \})^n$, a delegation flag d, and the root authority’s pseudonym $pk _\mathrm {root}$.

To define what a user may do with his credential, we need the relation “covers”. An attribute vector $\vec {A} = (A_1,\dots ,A_n)\in (\mathbb {A}\cup \{\star \})^n$ covers another attribute vector $\vec {A}' = (A_1',\dots ,A_n')\in (\mathbb {A}\cup \{\star \})^n$ if $(A_i\ne \star ) \Rightarrow (A_i' = A_i)$ for all $1\le i\le n$. In this case we write $\vec {A}\succeq \vec {A}'$. Furthermore, we say that an attribute vector $\vec {A} \in (\mathbb {A}\cup \{\star \})^n$ covers a predicate $\phi :\mathbb {A}^n \rightarrow \{0,1\}$ if it covers some vector without $\star$ fulfilling $\phi$, i.e. $\exists \vec {A}' \in \mathbb {A}^n:\ \vec {A}\succeq \vec {A}'\ \wedge \ \phi (\vec {A}') = 1$. We write $\vec {A}\succeq \phi$.

Let $cred$ be a credential with attributes $\vec {A}$, delegation flag d, and root authority’s pseudonym $pk _\mathrm {root}$ (we say that $cred$ is rooted at $pk _\mathrm {root}$). With $cred$, the user can do the following: (1) Prove possession of a $pk _\mathrm {root}$-rooted credential that covers some predicate $\phi$, and (2) if $d = 1$, he can issue a derived credential still rooted at $pk _\mathrm {root}$ with attributes $\vec {A}' \in (\mathbb {A}\cup \{\star \})^n$ iff $\vec {A}\succeq \vec {A}'$.

3.1 Formal Definition

Definition 3

A DAAC system consists of the following ppt algorithms:  

${\mathrm {Setup}(1^\lambda )\rightarrow ( pp , osk )}$ :

generates public parameters $pp$ and an opening key $osk$. We assume an attribute universe $\mathbb {A}$ be to be encoded in $pp$.

${\mathrm {KeyGen}( pp )\rightarrow ( usk , id )}$ :

generates a user secret $usk$ and an identity $id$.

${\mathrm {FormNym}( pp , usk , 1^n)\rightarrow ( pk , sk )}$ :

generates a pseudonym $pk$ and a pseudonym secret $sk$ such that credentials rooted at $pk$ support n attributes.

${\mathrm {Open}( pp , osk , pk )} = id$ :

is a deterministic algorithm that extracts an identity $id$ from the pseudonym $pk$.

${\mathrm {CreateCred}( pp , pk , sk )\rightarrow cred }$ :

creates a root credential, i.e. a delegatable credential with attributes $(\star ,\dots ,\star )$ and delegation flag $d=1$, rooted at $pk$.

${\mathrm {DelegIssue}( pp , pk _\mathrm {root}, usk , cred , \vec {A}^*, d^*, pk ^*)}$ :

  ${\leftrightarrow \mathrm {DelegRcv}( pp , pk _\mathrm {root}, \vec {A}^*, d^*, pk ^*, sk ^*, usk ^*)\rightarrow cred ^*}$ is an interactive protocol with common input the root’s pseudonym $pk _\mathrm {root}$, the receiver’s pseudonym $pk ^*$, the attributes to be issued $\vec {A}^*$, and the delegation flag $d^*\in \{0,1\}$. Additionally, the issuer gets his user secret $usk$ as private input, as well as his credential $cred$. Finally, the receiver gets his pseudonym secret $sk ^*$ and user secret $usk ^*$ as private input. After the protocol, the receiver side outputs a credential $cred ^*$ or the failure symbol $\perp$.

${\mathrm {ShowProve}( pp , pk _\mathrm {root}, pk , \phi , sk , usk , cred )\leftrightarrow \mathrm {ShowVrfy}( pp , pk _\mathrm {root}, pk , \phi ) \rightarrow b}$ :

is an interactive protocol with common input the root’s pseudonym $pk _\mathrm {root}$, the prover’s pseudonym $pk$, and a statement over attributes $\phi :\mathbb {A}^n\rightarrow \{0,1\}$. The prover gets his pseudonym secret $sk$, his user secret $usk$, and his credential $cred$ as private input. The verifier outputs a bit b.

 

Furthermore, we require three helper predicates that enable simpler correctness and security definitions: $\mathrm {CheckPseud}( pp , pk , sk , usk )$, $\mathrm {CheckShow}( pp , pk _\mathrm {root}, pk , \phi , sk , usk , cred )$, and $\mathrm {CheckDeleg}( pp , pk _\mathrm {root}, usk , cred , \vec {A}^*)$.

For correctness, we require that

• All pseudonyms $( pk , sk )$ generated by $\mathrm {FormNym}( pp , usk ,1^n)$ pass the check $\mathrm {CheckPseud}$. We call $( pk , sk )$ that pass $\mathrm {CheckPseud}$ valid.

• For all $( usk , id )\in [\mathrm {KeyGen}( pp )]$ and valid $( pk , sk )$: $\mathrm {Open}( pp , osk , pk ) = id$.

• $\mathrm {ShowVrfy}\leftrightarrow \mathrm {ShowProve}$ succeeds if its input passes $\mathrm {CheckShow}$ and also $\mathrm {CheckPseud}$.

• In $\mathrm {DelegIssue}\leftrightarrow \mathrm {DelegRcv}$, if the protocols’ inputs pass $\mathrm {CheckDeleg}$ for the issuer’s credential and $\mathrm {CheckPseud}$ for the receiver’s pseudonym, then $\mathrm {DelegRcv}$ does not output the error symbol $\perp$.

• Any output of $\mathrm {DelegRcv}( pp , pk _\mathrm {root}, \vec {A}^*, d^*, pk ^*, sk ^*, usk ^*)$ is either $\perp$ or a credential $cred ^*$ that passes $\mathrm {CheckShow}( pp , pk _\mathrm {root}, pk ', \phi , sk ', usk ^*, cred ^*)$ for all $\vec {A}^*\succeq \phi$. If $d^* = 1$, it also passes $\mathrm {CheckDeleg}( pp , pk _\mathrm {root}, usk ^*, cred ^*, \vec {A}')$ for all $\vec {A}^*\succeq \vec {A}'$.

• Root credentials $cred \in [\mathrm {CreateCred}( pp , pk _\mathrm {root}, sk _\mathrm {root})]$ are universal, i.e. if $( pk , sk )$ are valid, then $\mathrm {CheckShow}( pp , pk _\mathrm {root}, pk , \phi , sk , usk , cred ) = 1$ for all satisfiable $\phi$. Furthermore, $\mathrm {CheckDeleg}( pp , pk _\mathrm {root}, usk , cred , \vec {A}^*) = 1$ for all $\vec {A}^*\in (\mathbb {A}\cup \{\star \})^n$.    $\diamond$

A more formal version of correctness can be found in the full version of this paper.

The system is set up using $\mathrm {Setup}$, and the special opener secret $osk$ is given to a trusted authority. Any user can join the system by simply calling $\mathrm {KeyGen}$ to generate their own user secret $usk$ and identity $id$. With the user secret, one can generate any number of pseudonyms $pk$ using $\mathrm {FormNym}$. A user can declare himself a credential-issuing authority by publishing one of his pseudonyms $pk _\mathrm {root}$ and creating a root credential with $\mathrm {CreateCred}$ which allows him to delegate arbitrary credentials rooted at $pk _\mathrm {root}$. To delegate a credential, the delegator runs $\mathrm {DelegIssue}$ while the receiver runs $\mathrm {DelegRcv}$. To show a credential, a user runs $\mathrm {ShowProve}$ while the verifier runs $\mathrm {ShowVrfy}$. In case of abuse, the opener secret $osk$ can be used to extract the identity of a user from one of his pseudonyms.

Note the omission of a registration mechanism that prevents users from repeatedly generating ephemeral identities to circumvent persecution by the opener. A registration mechanism can be generically constructed from the credential system itself. We explain this in Sect. 3.2.

For security, we expect anonymity (users cannot be traced when showing, delegating, or receiving credentials) and soundness (users cannot impersonate other users or show credentials they have not been issued).

Definition 4

(Anonymity). A DAAC system $\varPi$ has anonymity if there is an ppt algorithm $( pp , osk , td )\leftarrow \mathfrak {S}^{ pp }(1^\lambda )$ whose output is such that $( pp , osk )$ is distributed exactly like $\mathrm {Setup}(1^\lambda )$. Furthermore, there are ppt simulators $\mathfrak {S}_\mathrm {ShowProve}$,$\mathfrak {S}_\mathrm {DelegIssue}$,$\mathfrak {S}_\mathrm {DelegRcv}$ such that no (unrestricted) $\mathcal {A}$ can distinguish between interacting

• with $\mathrm {ShowProve}( pp , pk _\mathrm {root}, pk , \phi , sk , usk , cred )$ or with $\mathfrak {S}_\mathrm {ShowProve}( td , pk _\mathrm {root}, pk , \phi )$

• with $\mathrm {DelegIssue}( pp , pk _\mathrm {root}, usk , cred , \vec {A}^*, d^*, pk ^*)$ or $\mathfrak {S}_\mathrm {DelegIssue}( td , pk _\mathrm {root}, \vec {A}^*, d^*, pk ^*, usk _\mathrm {alt}, cred _\mathrm {alt})$ for any $usk _\mathrm {alt}, cred _\mathrm {alt}$ that pass the $\mathrm {CheckDeleg}( pp , pk _\mathrm {root}, usk _\mathrm {alt}, cred _\mathrm {alt}, \vec {A}^*)$ check.

• with $\mathrm {DelegRcv}( pp , pk _\mathrm {root}, \vec {A}^*, d^*, pk ^*, sk ^*, usk ^*)$ or $\mathfrak {S}_\mathrm {DelegRcv}( td , pk _\mathrm {root}, \vec {A}^*, d^*, pk ^*)$.

Furthermore, for all ppt $\mathcal {A}$ there is a negligible function $negl$ s.t. for all $\lambda \in \mathbb {N}$,

$$\begin{aligned}&\Pr [( pp , osk , td )\leftarrow \mathfrak {S}^{ pp }(1^\lambda ), ( usk _0, id _0),( usk _1, id _1)\leftarrow \mathrm {KeyGen}( pp ), b\leftarrow \{0,1\}, \\&b' \leftarrow \mathcal {A}^{\mathcal {O}_\mathrm {FormNym}(\cdot ), \mathcal {O}_\mathrm {Open}(\cdot )}(1^\lambda , pp , td , usk _0, id _0, usk _1, id _1); b=b']\le 1/2+ negl (\lambda ) \end{aligned}$$

where $\mathcal {O}_\mathrm {FormNym}(1^n)$ returns pseudonyms of $usk _b$, it runs $( pk , sk )\leftarrow \mathrm {FormNym}( pp , usk _b, 1^n)$ and returns $pk$. $\mathcal {O}_\mathrm {Open}( pk )$ returns $\perp$ if $pk$ was previously output by $\mathcal {O}_\mathrm {FormNym}(\cdot )$, otherwise returns $\mathrm {Open}( pp , osk , pk )$.    $\diamond$

A more formally rigorous definition can be found in the full version of this paper. Our simulators get as input the simulation trapdoor $td$ and the common public input of the simulated protocol. In addition, $\mathfrak {S}_\mathrm {DelegIssue}$ gets any $usk _\mathrm {alt}, cred _\mathrm {alt}$ (which can be completely uncorrelated to the actual delegator’s $usk , cred$) as input to help with the simulation. The experiment in the last part of the definition models a situation where the ppt algorithm $\mathcal {A}$ knows all secrets except the opener’s $osk$. He interacts with one of two possible honest users (who generated their $usk$ honestly) and may request additional pseudonyms from that unknown user. Additionally, $\mathcal {A}$ may use $usk _0, usk _1$ to create any situation it wants for the two users. We allow $\mathcal {A}$ to query $\mathrm {FormNym}$ and $\mathrm {Open}$ oracles (with the usual constraints) to try to learn information about the unknown user from his pseudonyms. All other actions that $\mathcal {A}$ may want to make the unknown user do (issue credentials, etc.), can be perfectly simulated by $\mathcal {A}$ without knowledge of b. For this, we supply $\mathcal {A}$ with the simulation trapdoor $td$.

Definition 5

(Soundness). In the soundness experiment $\mathrm {Exp}^{\mathrm {soundness}}_{\varPi ,\mathcal {A}}(\lambda )$, the challenger plays the role of an arbitrary number of honest users. The adversary may internally set up any number of corrupted users.

The experiment begins with handing $pp , osk$ to the adversary $\mathcal {A}$. We allow $\mathcal {A}$ to make honest users run $\mathrm {FormNym}$ and $\mathrm {CreateCred}$, and to interact with honest users running $\mathrm {DelegIssue}$, $\mathrm {DelegRcv}$, or $\mathrm {ShowProve}$. Furthermore, $\mathcal {A}$ can make honest users delegate credentials among themselves.

Eventually, $\mathcal {A}$ outputs a challenge $( pk _\mathrm {root}, pk ,\phi )$. The experiment runs the protocol $\mathrm {ShowVrfy}( pp , pk _\mathrm {root}, pk ,\phi )$ interacting with $\mathcal {A}$. The experiment outputs 1 if $\mathrm {ShowVrfy}$ accepts and one of the following is true:

• The user or root issuer’s identity cannot be traced: $\mathrm {Open}( pp , osk , pk ) = \perp$ or $\mathrm {Open}( pp , osk , pk _\mathrm {root}) = \perp$.

• $\mathcal {A}$ was able to impersonate some honest user: $\mathrm {Open}( pp , osk , pk ) = id '$ for some honest user’s identity $id '$.

• $\mathcal {A}$ was able to show a credential he did not receive: $\mathrm {Open}( pp , osk , pk _\mathrm {root}) = id '$ for some honest user’s $id '$ and $\mathcal {A}$ never queried to receive a credential $cred ^*$ on a pseudonym $pk ^*$ such that: (1) $cred ^*$ is rooted at $pk _\mathrm {root}$, (2) $cred ^*$ has attributes $\vec {A}^*\succeq \phi$, and (3) $cred ^*$ is marked delegatable or $\mathrm {Open}( pp , osk , pk ) = \mathrm {Open}( pp , osk , pk ^*)$.

A DAAC system $\varPi$ is sound if for all ppt adversaries $\mathcal {A}$ there exists a negligible function $negl$ with $\Pr [\mathrm {Exp}^{\mathrm {soundness}}_{\varPi ,\mathcal {A}}(\lambda ) = 1] \le negl (\lambda )$ for all $\lambda \in \mathbb {N}$.    $\diamond$

The complete experiment can be found in the full version of this paper.

The adversary’s win conditions imply that a credential with delegation flag $d=0$ can only be shown with a pseudonym that opens to the same identity as the pseudonym used when receiving the credential. Note that even if $d=0$, it is always possible for a credential holder A to reveal his credential and his user secret $usk _A$ to another user B (who can then show the credential somewhere and gain access). However, users are discouraged from doing this because after revealing $usk _A$ to B, B can perform (malicious) activities, which the opener will then trace back to A. Hence A bears the risk of being made responsible for B’s actions. For more details of how we propose applications use the security guarantees of Definition 5 to enforce accountability, we refer to Sect. 3.2.

3.2 How to Deploy Delegatable Attribute-Based Anonymous Credential Systems in Practice

In the following, we describe an example how an application would utilize DAAC in practice. The system should be set up by a trusted authority (TA). The TA runs $( pp , osk )\leftarrow \mathrm {Setup}(1^\lambda )$, $( usk _\text {TA}, id _\text {TA})\leftarrow \mathrm {KeyGen}( pp )$, $( pk _\text {TA}, sk _\text {TA})\leftarrow \mathrm {FormNym}( pp , usk _\text {TA},1^0)$. He then publishes $pp$ and $pk _\text {TA}$.

In order to join the system, a user generates $( usk , id )\leftarrow \mathrm {KeyGen}( pp )$. He then approaches the TA to register in the system. For this, he sends one of his pseudonyms $pk$ to the TA and uses some mechanism to authenticate with his real identity (e.g., physically showing a passport). The TA computes the user’s $id$ using $\mathrm {Open}( pp , osk , pk )$ and stores $id$ alongside the user’s real identity information. Then the TA uses the user’s $pk$ to issue a non-delegatable ($d=0$) “master” credential $cred _\text {master}$.

Whenever the user introduces a new pseudonym $pk '$ to some verifier, he first shows the master credential by running $\mathrm {ShowProve}( pp , pk _\text {TA}, pk ',\phi , sk ', usk , cred _\text {master})$ with the verifier. This ensures that the user indeed registered with the TA and hence the TA will be able to trace his pseudonyms to his real identity. If at some point the user breaks some rule within the application, the verifier can approach the TA with $pk '$, which the TA can trace to the user’s identity by computing $\mathrm {Open}( pp , osk , pk ')$. This is because the soundness property (Definition 5) ensures that the non-delegatable credential $cred _\text {master}$, which was issued to $pk$, can be successfully shown only for $pk '$ where $\mathrm {Open}( pp , osk , pk ') = \mathrm {Open}( pp , osk , pk )$.

Of course, you may also want to ensure that users cannot be falsely accused by verifiers for (malicious) actions they never committed. The application can enforce this by logging relevant actions and making a user certify each log entry by issuing a credential to the verifier whose attributes encode the log entry. This credential (rooted at the user’s pseudonym $pk '$) can be used by the verifier to prove to the TA that $pk '$ indeed executed the logged action. Honest users cannot be falsely accused anymore because the soundness property (Definition 5) prohibits forging/showing a credential rooted at a pseudonym that traces to an honest user. The user’s privacy when issuing the credential to the verifier is still guaranteed because the anonymity property (Definition 4) guarantees anonymity not only for the receiver of a credential, but also for the issuer. Note that the TA may still lie about the identity that $\mathrm {Open}( pp , osk , pk ')$ outputs. This can be prevented with standard techniques, e.g., by making the TA prove non-interactively that the claimed identity is indeed output by $\mathrm {Open}$.

4 Dynamically Malleable Signatures with Efficient Protocols

For our construction of DAAC, we introduce dynamically malleable signatures (DMS) as a building block. As explained in the introduction, a DMS is a malleable signature where the set of allowed transformations on the signed message can be incrementally restricted. We first define DMS, then define related protocols that are used in our DAAC construction.

4.1 Definition

A DMS is accompanied by a malleability key $mk$ and parameterized with an index set I. We describe malleability through a relation $\equiv _I$, which depends on I. Namely, using $mk$, a message $\vec {m}$ can be changed into a message $\vec {m}'$ iff $\vec {m} \equiv _I \vec {m}'$. We remark that our definitions (syntax and security) for DMS apply to arbitrary equivalence relations $\equiv _I$ and arbitrary index sets I satisfying $I'\subseteq I \Rightarrow \equiv _{I'}\subseteq \equiv _{I}$, i.e. restricting I restricts the malleability relation. However, in this paper, we are going to use the following concrete relation $\equiv _I$.

Definition 6

Let $I\subseteq \{1,\dots ,n\}$ be an index set. We define $\equiv _I$ by

$$ (m_1,\dots ,m_n) \equiv _I (m_1',\dots ,m_n')\ \Leftrightarrow \forall i\notin I:\ m_i = m_i'. $$

   $\diamond$

This means that malleability of DMS is restricted so that exactly the messages at indices present in I can be modified. A DMS is called dynamically malleable because given any signature $\sigma$ and malleability key $mk$ with index set I, one can efficiently compute $\sigma ', mk '$ with index set $I'\subseteq I$. We now formally define DMS.

Definition 7

(Dynamically malleable signatures). A DMS scheme consists of the following (probabilistic) polynomial-time algorithms:  

${\mathrm {Setup}(1^\lambda )\rightarrow pp }$ :

for security parameter $\lambda$ outputs public parameters $pp$. We assume that the message space M can be inferred from $pp$ and that $| pp |\ge \lambda$.

${\mathrm {KeyGen}( pp , 1^n)\rightarrow ( pk , sk )}$ :

for $n\in \mathbb {N}$ outputs a key pair $( pk , sk )$.

${\mathrm {Sign}( pp , sk , \vec {m}, I)\rightarrow (\sigma , mk )}$ :

for a message vector $\vec {m} \in M^n$ and an index set I outputs a signature $\sigma$ and a malleability key $mk$.

${\mathrm {Transform}( pp ,\vec {m}, \vec {m}', \sigma , mk , I')\rightarrow (\sigma ', mk ')}$ :

on input a signature $\sigma$ on $\vec {m}$ outputs a signature $\sigma '$ and a malleability key $mk '$ for $\vec {m}',I'$.

${\mathrm {Vrfy}( pp , pk , \vec {m}, \sigma ) = b}$ :

is a deterministic algorithm that outputs a bit.

${\mathrm {VrfyMk}( pp , pk , \vec {m}, \sigma , mk , I) = b}$ :

is a deterministic algorithm that outputs a bit.

 

A DMS scheme is correct if for all $\lambda ,n\in \mathbb {N}$, all $pp \in [\mathrm {Setup}(1^\lambda )]$, all $( pk , sk )\in [\mathrm {KeyGen}( pp , 1^n)]$, all $\vec {m}\in M^n$ and index sets $I\subseteq \{1,\dots ,n\}$:

• $\Pr [(\sigma , mk )\leftarrow \mathrm {Sign}( pp , sk , \vec {m}, I); \mathrm {Vrfy}( pp , pk ,\vec {m}, \sigma ) = \mathrm {VrfyMk}( pp , pk ,\vec {m},\sigma , mk , I) = 1] = 1$ (signatures and malleability keys from $\mathrm {Sign}$ are accepted by the verification algorithms)

• $\Pr [(\sigma ', mk ')\leftarrow \mathrm {Transform}(\vec {m}, \vec {m}', \sigma , mk , I'); \mathrm {Vrfy}( pp , pk ,\vec {m}', \sigma ') = \mathrm {VrfyMk}( pp , pk ,\vec {m}',\sigma ', mk ', I') = 1] = 1$ for all $\vec {m}'\equiv _I \vec {m}$, $I'\subseteq I$, and all $(\sigma , mk )$ with $\mathrm {VrfyMk}( pp , pk ,\vec {m},\sigma , mk , I) = 1$. (signatures and malleability keys derived from $\mathrm {Transform}$ are accepted by the verification algorithms).    $\diamond$

Note that our definition implies that any signature/malleability key created with $\mathrm {Transform}$ can again be input to $\mathrm {Transform}$ to further change the message or weaken the malleability key. Also note that we model both $\mathrm {Vrfy}$ and $\mathrm {VrfyMk}$ as the former may be more efficient.

We now define security for DMS. We expect (1) derivation privacy: signatures derived with $mk$ are indistinguishable from signatures freshly created with $sk$ and (2) unforgeability: an adversary cannot produce a signature that cannot be legally derived from oracle-queried signatures. For derivation privacy, we demand perfect derivation privacy for simplicity.

Definition 8

(Perfect derivation privacy). A DMS scheme $\mathcal {S}$ is perfectly derivation private if for all $\lambda ,n\in \mathbb {N}$, all $pp \in [\mathrm {Setup}(1^\lambda )]$, all $pk ,\sigma , mk$, all $\vec {m}, \vec {m}'\in M^n$, and all index sets $I,I'$ with $\vec {m}'\equiv _I \vec {m}$, $I'\subseteq I$, and $\mathrm {VrfyMk}( pp , pk ,\vec {m},\sigma , mk , I) = 1$, it holds that (1) $\exists sk$ with $( pk , sk )\in [\mathrm {KeyGen}( pp ,1^n)]$, and (2) for all $sk$ such that $( pk , sk )\in [\mathrm {KeyGen}( pp , 1^n)]$, $\mathrm {Transform}(\vec {m}, \vec {m}', \sigma , mk , I')\approx \mathrm {Sign}( pp , sk , \vec {m}', I')$    $\diamond$

The first item (that for each $pk$ accepted by $\mathrm {VrfyMk}$, there exists a corresponding $sk$) is a somewhat technical requirement. Without this requirement, it may happen that someone receives valid $\sigma , mk$ from an untrusted source for a public key $pk$ for which there exists no corresponding $sk$. In this case the premise $( pk , sk )\in [\mathrm {KeyGen}( pp , 1^n)]$ of the second item does not apply and hence any signatures $\sigma '$ derived from $\sigma , mk$ would be allowed to be easily traced back to $\sigma$.

For the second property, unforgeability, we simply weaken the standard EUF-CMA definition for digital signatures such that signatures that can be legally derived using $\mathrm {Transform}$ are not considered forgeries anymore. Note that for simplicity, we only define unforgeability for perfectly derivation private schemes.

Definition 9

(Unforgeability). Consider the experiment $\mathtt {SigForge}_{\varPi ,\mathcal {A}}(\lambda , n)$ for a DMS scheme $\varPi$ and an adversary $\mathcal {A}$:

• $pp \leftarrow \mathrm {Setup}(1^\lambda )$, $( pk , sk )\leftarrow \mathrm {KeyGen}( pp , 1^n)$. $\mathcal {A}$ is given $pp , pk$ and oracle access to $\mathrm {Sign}( pp , sk , \cdot , \cdot )$.

• Eventually $\mathcal {A}$ outputs $\vec {m}^*,\sigma ^*$. The experiment outputs 1 iff $\mathrm {Vrfy}( pp , pk ,\vec {m}^*,\sigma ^*) = 1$ and $\mathcal {A}$ never made a query $\mathrm {Sign}( pp , sk , \vec {m}', I')$ where $\vec {m}^* \equiv _{I'} \vec {m}'$.

A perfectly derivation private DMS scheme $\varPi$ is unforgeable if for all polynomials p and all ppt $\mathcal {A}$ there is a negligible function $negl$ such that for all $\lambda \in \mathbb {N}$ and $n\le p(\lambda )$, $\Pr [\mathtt {SigForge}_{\varPi ,\mathcal {A}}(1^\lambda , 1^n) = 1] \le negl (\lambda )$.    $\diamond$

For perfectly derivation private schemes, the output of $\mathrm {Transform}$ is distributed the same as the output of $\mathrm {Sign}$. Hence there is no need to give $\mathcal {A}$ explicit access to a $\mathrm {Transform}$ oracle. Furthermore, note that the definition can be fulfilled by schemes where a signature $\sigma$ can be modified even without a corresponding malleability key $mk$. Consequently, the distinction between $\sigma$ and $mk$ is somewhat arbitrary – one may just as well merge $mk$ into $\sigma$. However, note that $mk$ is not required as input to $\mathrm {Vrfy}$; hence we keep the distinction for the sake of intuition and potential efficiency gains.

4.2 Deriving a Signature on a Committed Message

For our construction of DAAC, we will require a protocol for deriving a signature on a hidden committed message. The setting for the protocol is the following: The issuer holds a signature $\sigma$ on a message $\vec {m} = (m_1,\dots ,m_n)$ and corresponding malleability key $mk$ for index set I. For $i\in I$ and $I^*\subseteq I$ and a message $m^*$, the receiver wants to obtain the output of $\mathrm {Transform}( pp ,\vec {m},(m_1,\dots ,m_{i-1},m^*, m_{i+1},\dots ,m_n), \sigma , mk ,I^*)$ without revealing his $m^*$. For this, the receiver commits to $m^*$, then both parties engage in a protocol to jointly compute $\mathrm {Transform}$.

Definition 10

(Deriving a signature on a committed value). A scheme for deriving a signature on a committed value consists of two ppt algorithms and two interacting algorithms:  

$\mathrm {BlindInit}(\sigma , mk , \vec {m}, i)\rightarrow (K,k)$ :

on input a signature $\sigma$ on $\vec {m}$, an index i, and a corresponding malleability key $mk$, outputs a key K for the commitment scheme and some secret information k.

$\mathrm {Commit}(K,m^*,r)\rightarrow C$ :

takes as input a key K, a message $m^*$ and some randomness r, and outputs a commitment C.

$\mathrm {BlindIssue}(\sigma , mk , \vec {m}, i, I^*, k, C)$ :

on input a signature $\sigma$ on $\vec {m}$, an index set $I^*$, a malleability key $mk$, a commitment C, an index i, and the secret k, interacts with $\mathrm {BlindRcv}$.

$\mathrm {BlindRcv}(m^*, i, I^*, K, C, r)\rightarrow (\sigma ^*, mk ^* )$ :

on input a message $m^*$, an index i, an index set $I^*$, a commitment C for key K and its randomness r, interacts with $\mathrm {BlindIssue}$ and outputs a signature $\sigma ^*$ and a malleability key $mk ^*$.

 

The public parameters $pp$ and the public key under which the issuer’s signature is valid are considered implicit input to all the algorithms above.

Such a protocol is correct if for all $m^*\in M$, all $\sigma , mk$ valid on $\vec {m}$ with index set I, all $i\in I$, and all $I^*\subseteq I$, the result $(\sigma ^*, mk ^*)$ of $\mathrm {BlindRcv}(m^*, i, I^*, K, C, r) \leftrightarrow \mathrm {BlindIssue}(\sigma , mk , \vec {m}, i, I^*, k)$, where $C = \mathrm {Commit}(K,m^*, r)$, is a valid signature (and malleability key) on $(m_1,\dots ,m_{i-1},m^*, m_{i+1},\dots ,m_n)$.    $\diamond$

In this scenario, the issuer would use $\mathrm {BlindInit}$ to create a commitment key K. He then sends K to the receiver, who uses it to commit to his message $m^*$. Then both parties engage in the $\mathrm {BlindIssue}\leftrightarrow \mathrm {BlindRcv}$ protocol, which yields the signature and malleability key for the receiver.

In our credential system construction, we are going to make the receiver prove something about the message $m^*$ that he committed to. For this reason, the commitment process is made explicit in this definition as opposed to hiding it in the implementation details of the $\mathrm {BlindRcv}\leftrightarrow \mathrm {BlindIssue}$ protocol.

For the security of such a protocol, we require security for the receiver and for the issuer. Security for the receiver requires that (1) the commitment scheme is perfectly hiding, and (2) runs of $\mathrm {BlindRcv}$ for two distinct committed messages are perfectly indistinguishable for the issuer. Security for the issuer requires that (1) the distribution of the commitment key K is independent of the issuer’s concrete $\sigma , mk$ and $\vec {m}$, and (2) the receiver only learns a single signature. We detail these requirements formally in the full version of this paper.

5 Construction of Dynamically Malleable Signatures Based on Pointcheval-Sanders Signatures

Our construction is an extension of Pointcheval-Sanders signatures [17].

The $\mathrm {Setup},\mathrm {KeyGen},\mathrm {Vrfy}$ algorithms below are exactly the same as in the original Pointcheval-Sanders signature scheme, as are the signatures produced by $\mathrm {Sign}$. We extend the $\mathrm {Sign}$ algorithm to output a malleability key and we add the $\mathrm {VrfyMk}$ and $\mathrm {Transform}$ algorithms. The main observation for our construction is that a signature $(h,h^{x+\sum y_i m_i})$ on $(m_1,\dots ,m_n)$ can be made malleable at position i by adding $h^{y_i}$ to the malleability key.

Construction 11

(DMS scheme).  

$\mathrm {Setup}(1^\lambda )$ :

generates a bilinear group $\mathbb {G}= (\mathbb {G}_1,\mathbb {G}_2,\mathbb {G}_{\mathrm {T}}, e, p)$ of prime order $p\ge 2^\lambda$. It outputs $pp = \mathbb {G}$. The message space is $M = \mathbb {Z}_p$.

$\mathrm {KeyGen}( pp , 1^n)$ :

chooses random generator $\tilde{g}\leftarrow \mathbb {G}_2$. It then chooses random $x,y_1,\dots ,y_n\leftarrow \mathbb {Z}_p$. The secret key is $sk = (x,y_1,\dots ,y_n)$ and the public key is $pk = (\tilde{g}, \tilde{g}^x, \tilde{g}^{y_1},\dots , \tilde{g}^{y_n})$. It outputs $( pk , sk )$.

$\mathrm {Sign}( pp , sk , m_1,\dots ,m_n, I)$ :

chooses $h\leftarrow \mathbb {G}_1{\setminus }\{1\}$. It then computes $\sigma = (h, h^{x+\sum _i y_i m_i})$ and $mk = (h^{y_i})_{i\in I}$. It outputs $(\sigma , mk )$.

$\mathrm {Vrfy}( pp , pk , \vec {m}, \sigma )$ :

parses $\sigma$ as $(h,\sigma _2)$, $pk$ as $(\tilde{g}, \tilde{g}^x, \tilde{g}^{y_1},\dots , \tilde{g}^{y_n})$, and returns 1 iff $h\ne 1$ and $e(h, \tilde{g}^x\cdot \prod _{i=1}^n (\tilde{g}^{y_i})^{m_i}) = e(\sigma _2, \tilde{g})$.

$\mathrm {VrfyMk}( pp , pk , \vec {m}, \sigma , mk , I)$ :

checks $\mathrm {Vrfy}( pp , pk , \vec {m}, \sigma ) \overset{!}{=} 1$ and outputs 0 if the check does not pass. It parses $\sigma$ as $(h,\sigma _2)$ and $mk$ as $(h_i)_{i\in I}$. Then it returns 1 iff $e(h_i, \tilde{g}) = e(h, \tilde{g}^{y_i})$ for all $i\in I$.

$\mathrm {Transform}(\vec {m}, \vec {m}', \sigma , mk , I')$ :

parses $\sigma$ as $(h, h^{x+\sum _i y_i m_i})$ and $mk$ as $(h^{y_i})_{i\in I}$¹. It aborts if $\mathrm {VrfyMk}( pp , pk ,\vec {m},\sigma , mk , I) \ne 1$ or $I'\not \subseteq I$ or $\vec {m}\not \equiv _I \vec {m}'$. Otherwise it chooses $r\leftarrow \mathbb {Z}_p^*$ and computes

$$\sigma ' = (h^r, (h^{x+\sum _i y_i m_i}\cdot \prod _{i\in I} (h^{y_i})^{m_i'-m_i})^r)\text { and } mk ' = ((h^{y_i})^r)_{i\in I'}.$$

It outputs $(\sigma ', mk ')$.    $\diamond$

 

One can easily check that our scheme fulfills the correctness requirements (Definition 7). Furthermore, $\mathrm {Transform}$ clearly produces signatures with the same distribution as $\mathrm {Sign}$ since $h^r$ is uniformly distributed over $\mathbb {G}_1{\setminus }\{1\}$ and the second signature component as well as $mk$ are uniquely determined by that choice. Consequently, the scheme is perfectly derivation private (Definition 8). The scheme can be proven unforgeable in the generic group model.

Theorem 12

(Unforgeability). Construction 11 is unforgeable in the generic group model for type-3 bilinear groups.

The proof is straight-forward and very similar to other generic group model proofs (e.g., [17]). It can be found in the full version of this paper.

As noted above, for our construction of DAAC, we need an efficient protocol for deriving a signature on a committed value (cf. Definition 10). A protocol for signing a committed value for the original signature scheme was given in [17]. Our protocol is similar, with some changes to account for transforming an existing signature instead of creating new one, and to account for privacy of the issuer (which was not a requirement before). The commitment scheme we use is essentially Pedersen’s commitment [16], but we derive the commitment key from the issuer’s signature.

Construction 13

(Deriving a signature on a committed value).  

$\mathrm {BlindInit}(\sigma , mk , \vec {m}, i)$ :

parses $\sigma$ as $(h, \sigma _2)\in (\mathbb {G}_1{\setminus }\{1\})\times \mathbb {G}_1$ and $mk = (h^{y_j})_{j\in I}$. It chooses $k\leftarrow \mathbb {Z}_p^*$. It sets $K = ((h^{y_i})^k, h^k)$ and outputs (K, k).

$\mathrm {Commit}(K,m,r)$ :

parses K as $(h^{y_ik}, h^k) \in \mathbb {G}_1\times (\mathbb {G}_1{\setminus }\{1\})$ and interprets r as an element of $\mathbb {Z}_p$. It outputs the commitment $C = (h^{y_ik})^m\cdot (h^k)^r$.

$\mathrm {BlindRcv}(m^*, i, I^*, K, C, r)\leftrightarrow \mathrm {BlindIssue}(\sigma , mk , \vec {m}, i, I^*, k, C)$ :

works as follows: $\mathrm {BlindIssue}$ parses $\sigma$ as $(h, \sigma _2)$ and $mk$ as $(h^{y_i})_{i\in I}$, chooses a random $u\leftarrow \mathbb {Z}_p^*$ and computes $(\sigma _1', \sigma _2') = (h^{ku}, (\sigma _2^k\cdot (h^{y_i})^{-km_i} \cdot C)^u)$. It sends $(\sigma _1',\sigma _2')$ together with $mk ' = ((h^{y_j})^{ku})_{j\in I^*}$ to the receiver. $\mathrm {BlindRcv}$ then unblinds $(\sigma _1', \sigma _2')$ as $\sigma ^* = (\sigma _1^*, \sigma _2^*) = (\sigma _1', \sigma _2'\cdot (\sigma _1')^{-r})$. $\mathrm {BlindRcv}$ outputs $(\sigma ^*, mk ')$.    $\diamond$

 

The proof of security for this construction is straight-forward and can be found in the full version of this paper.

6 Constructing Delegatable Attribute-Based Anonymous Credentials from Dynamically Malleable Signatures with Efficient Protocols

We now construct DAAC from a DMS scheme with efficient protocols. The general construction idea is similar to the generic construction of (attribute-based) credential systems without delegation [15], but using DMS instead of standard signatures essentially allows adding the delegation feature. We define the following notation:

Definition 14

Let $\mathcal {H}$ be a hash function. For $\vec {A}\in (\mathbb {A}\cup \{\star \})^n$, $d\in \{0,1\}$, $usk$, and $pk _\mathrm {root}$, we define

• $\vec {m}^{(\vec {A}, usk , pk _\mathrm {root})} := (m_1,\dots ,m_n, usk , \mathcal {H}( pk _\mathrm {root}))$, where $m_i = A_i$ if $m_i \in \mathbb {A}$, and $m_i = 0$ if $A_i = \star$ (where $0\in M$ denotes some constant).

• $I^{(d, \vec {A})} := \{i \mid A_i = \star \vee (i=n+1\wedge d=1) \} \subseteq \{1,\dots ,n+2\}$    $\diamond$

We will also use the special case $\vec {m}^{(\vec {A}, 0, pk _\mathrm {root})}$, which is the same as above but with the user secret set to the constant $0\in M$. In our construction, the predicates $\mathrm {CheckPseud}$, $\mathrm {CheckShow}$, and $\mathrm {CheckDeleg}$ from Definition 3 can be evaluated in polynomial time and we are going to use them in the algorithm descriptions.

With some details omitted, our construction is going to work as follows: A credential for user $usk$ rooted at $pk _\mathrm {root}$ with attribute vector $\vec {A}$ and delegation flag d will be a dynamically malleable signature on $\vec {m}^{(\vec {A}, usk , pk _\mathrm {root})}$ with index set $I^{(d, \vec {A})}$. To delegate a credential, the issuer needs to derive a signature on the receiver’s $usk$ without being given $usk$ itself. For this, we use a protocol for deriving a signature on a committed value (cf. Definition 10). Showing the credential consists of the user proving possession of $usk$ and a signature with attributes fulfilling some predicate $\phi$, such that $usk$ is both within his pseudonym and the signature. The identity of a user with key $usk$ will be $id = f( usk )$ for some one-way function f. Then, following standard techniques, a user’s pseudonym is an encryption c of $id$. For issuing credentials, each pseudonym also contains a signature scheme key $pk _\mathcal {S}$ and a signature of knowledge binding the encryption c and $pk _\mathcal {S}$ together.

Construction 15

(Generic construction of delegatable attribute-based anonymous credentials). Let $\mathcal {S}= (\mathrm {Setup}_\mathcal {S}, \mathrm {KeyGen}_\mathcal {S},\mathrm {Sign}_\mathcal {S},\mathrm {Transform}_\mathcal {S},\mathrm {Vrfy}_\mathcal {S})$ be a DMS scheme with $(\mathrm {BlindInit}_\mathcal {S}, \mathrm {BlindIssue}_\mathcal {S}, \mathrm {BlindRcv}_\mathcal {S}, \mathrm {Commit}_\mathcal {S})$ for deriving a signature on a committed value. Let $\mathcal {E}= (\mathrm {Setup}_\mathcal {E}, \mathrm {KeyGen}_\mathcal {E},\mathrm {Encrypt}_\mathcal {E},\mathrm {Decrypt}_\mathcal {E})$ be a public-key encryption scheme. Let $\mathcal {OW}= (\mathrm {Setup}_\mathcal {OW}, \mathrm {GenFnct}_\mathcal {OW})$ be a one-way function scheme. Let $\mathcal {H}$ be a (collision-resistant) hash function (usage hidden within the $\vec {m}^{(\dots )}$ notation, cf. Definition 14).

We require that $\mathrm {Setup}_\mathcal {S}= \mathrm {Setup}_\mathcal {E}= \mathrm {Setup}_\mathcal {OW}=: \mathrm {Setup}$. We denote the (finite) message spaces of $\mathcal {S}$ and $\mathcal {E}$ as $M_\mathcal {S}$ and $M_\mathcal {E}$, respectively (they may depend on the output of $\mathrm {Setup}$) and require that functions $f\in [\mathrm {GenFnct}_\mathcal {OW}( pp )]$ bijectively map between the message spaces for the signature and encryption scheme, i.e. $f:M_\mathcal {S}\rightarrow M_\mathcal {E}$. Furthermore, the hash function must hash to $M_\mathcal {S}$, i.e. $\mathcal {H}:\{0,1\}^*\rightarrow M_\mathcal {S}$. The scheme consists of the following algorithms:  

$\mathrm {Setup}(1^\lambda )$ :

runs $pp _{\mathcal {S},\mathcal {E},\mathcal {OW}}\leftarrow \mathrm {Setup}(1^\lambda )$, $( pk _\mathcal {E}, sk _\mathcal {E})\leftarrow \mathrm {KeyGen}_\mathcal {E}( pp _{\mathcal {S},\mathcal {E},\mathcal {OW}})$, and $f\leftarrow \mathrm {GenFnct}_\mathcal {OW}( pp _{\mathcal {S},\mathcal {E},\mathcal {OW}})$. It outputs $pp = ( pp _{\mathcal {S},\mathcal {E},\mathcal {OW}}, pk _\mathcal {E}, f)$ and the opening key $osk = sk _\mathcal {E}$. The attribute universe $\mathbb {A}$ is $M_\mathcal {S}$.

$\mathrm {KeyGen}( pp )$ :

chooses $usk \leftarrow M_\mathcal {S}$ and sets $id = f( usk )$. It returns $( usk , id )$.

$\mathrm {FormNym}( pp , usk , 1^n)$ :

generates keys $( pk _\mathcal {S}, sk _\mathcal {S}) \leftarrow \mathrm {KeyGen}_\mathcal {S}( pp _{\mathcal {S},\mathcal {E},\mathcal {OW}}, 1^{n+2})$. It encrypts $usk$ as $c = \mathrm {Encrypt}_\mathcal {E}( pk _\mathcal {E}, f( usk );r')$ using fresh randomness $r'$. It then creates a signature of knowledge on $pk _\mathcal {S}$ and c proving that it can open c: $\gamma = NIZK [( usk ,r'); c = \mathrm {Encrypt}_\mathcal {E}( pk _\mathcal {E}, f( usk );r')]( pk _\mathcal {S},c)$. The pseudonym is $pk = ( pk _\mathcal {S}, c, \gamma )$ and the secret is $sk = ( sk _\mathcal {S}, r', usk )$. It outputs $( pk , sk )$.

$\mathrm {Open}( pp , osk , pk )$ :

parses $pk$ as $( pk _\mathcal {S}, c, \gamma )$, checks $\gamma$ (outputs $\perp$ and aborts if the check fails), then it runs and outputs $\mathrm {Decrypt}_\mathcal {E}( sk _\mathcal {E}, c)$.

$\mathrm {CreateCred}( pp , pk , sk )$ :

runs $(\sigma , mk )\leftarrow \mathrm {Sign}_\mathcal {S}( sk _\mathcal {S}, \vec {m}^{((\star ,\dots ,\star ), usk , pk )}, I^{(1,(\star ,\dots ,\star ))})$. It outputs $cred = (\sigma , mk , (\star ,\dots ,\star ), d = 1)$

$\mathrm {DelegIssue}( pp , pk _\mathrm {root}, usk , cred , \vec {A}^*, d^*, pk ^*) \leftrightarrow$ :

$\mathrm {DelegRcv}( pp , pk _\mathrm {root}, \vec {A}^*, d^*, pk ^*,$ $sk ^*, usk ^*)$ works as follows:

1.:

The issuer checks $\mathrm {CheckDeleg}( pp , pk _\mathrm {root}, usk , cred , \vec {A}^*) \overset{!}{=} 1$ and parses $cred$ as $(\sigma , mk , \vec {A}, d)$.

2.:

The receiver checks $\mathrm {CheckPseud}( pp , pk ^*, sk ^*, usk ^*) \overset{!}{=} 1$.

3.:

The issuer prepares an anonymized delegatable credential by running $(\sigma ', mk ')\leftarrow \mathrm {Transform}( pp ,\vec {m}^{(\vec {A}, usk , pk _\mathrm {root})}, \vec {m}^{(\vec {A}^*, 0, pk _\mathrm {root})}, \sigma , mk , I^{(1,\vec {A}^*)})$.

4.:

If $d^* = 1$, the issuer simply hands $(\sigma ', mk ')$ to the receiver. Then the receiver changes the signature to his user secret by running $(\sigma ^*, mk ^*)\leftarrow \mathrm {Transform}( pp ,\vec {m}^{(\vec {A}^*,0, pk _\mathrm {root})}, \vec {m}^{(\vec {A}^*, usk ^*, pk _\mathrm {root})}, \sigma ', mk ', I^{(d^*,\vec {A}^*)})$

5.:

If $d^* = 0$, we write $pk _\mathrm {root}= ( pk _{\mathcal {S}, \text {root}}, c_\text {root},\gamma _\text {root})$. Then

(a):

the issuer runs $(K,k)\leftarrow \mathrm {BlindInit}_\mathcal {S}(\sigma ', mk ', \vec {m}^{(\vec {A}^*, 0, pk _\mathrm {root})}, n+1)$, sends K to the receiver.

(b):

the receiver computes $C\leftarrow \mathrm {Commit}_\mathcal {S}(K, usk ^*, r)$ for some random r, sends C to the issuer, and then runs a zero knowledge argument of knowledge with the issuer, proving he can open the commitment and his pseudonym $pk ^* = ( pk _\mathcal {S}^*, c^*,\gamma ^*)$ to his user secret (using $r'$ and $usk ^*$ from $sk ^* = ( sk _\mathcal {S}^*, r', usk ^*)$):

$$\begin{aligned} ZKAK [( usk ^*, r, r');&C = \mathrm {Commit}_\mathcal {S}(K, usk ^*, r) \\&\wedge c^* = \mathrm {Encrypt}_\mathcal {E}( pk _\mathcal {E}, f( usk ^*); r') ] \end{aligned}$$

(c):

if the $ZKAK$ protocol accepts, then the issuer runs the protocol $\mathrm {BlindIssue}_\mathcal {S}(\sigma ', mk ', \vec {m}^{(\vec {A}^*,0, pk _\mathrm {root})}, n+1, I^{(d^*, \vec {A}^*)}, k, C)$, while the receiver runs $(\sigma ^*, mk ^*)\leftarrow \mathrm {BlindRcv}_\mathcal {S}( usk ^*, n+1, I^{(d^*, \vec {A}^*)}, K, C, r))$.

6.:

The receiver checks $\mathrm {VrfyMk}_\mathcal {S}( pk _{\mathcal {S}, \text {root}}, \vec {m}^{(\vec {A}^*, usk ^*, pk _\mathrm {root})}, \sigma ^*, mk ^*, I^{(d^*, \vec {A}^*)}) \overset{!}{=} 1$. If the check fails, it outputs $\perp$, otherwise it outputs $cred ^* := (\sigma ^*, mk ^*,\vec {A}^*, d^*)$.

$\mathrm {ShowVrfy}( pp , pk _\mathrm {root}, pk , \phi )\leftrightarrow \mathrm {ShowProve}( pp , pk _\mathrm {root}, pk , \phi , sk , usk , cred )$ :

: Parse $pk _\mathrm {root}= ( pk _{\mathcal {S}, \text {root}}, \cdot , \cdot )$, $pk = (\cdot , c, \cdot )$ and $sk = ( sk _\mathcal {S}, r', usk )$.

1.:

The prover checks $\mathrm {CheckShow}( pp , pk _\mathrm {root}, pk , \phi , sk , usk , cred ) \overset{!}{=} 1$.

2.:

The prover parses $cred = (\sigma , mk , \vec {A}, d)$ and computes some $\vec {A}' \in \mathbb {A}^n$ with $\vec {A}'\preceq \vec {A}$ and $\phi (\vec {A}') = 1$.²

3.:

Prover runs $(\sigma ', mk ')\leftarrow \mathrm {Transform}( pp ,\vec {m}^{(\vec {A}, usk , pk _\mathrm {root})}, \vec {m}^{(\vec {A}', usk , pk _\mathrm {root})}, \sigma , mk , I)$ with $I = \emptyset$.

4.:

The prover runs the following black-box zero-knowledge argument of knowledge protocol with the verifier:

$$\begin{aligned} ZKAK [( usk , r', \sigma ', \vec {A}');&\mathrm {Vrfy}_\mathcal {S}( pk _{\mathcal {S}, \text {root}}, \vec {m}^{(\vec {A}', usk , pk _{\mathcal {S}, \text {root}})}, \sigma ') = 1\\&\wedge \phi (\vec {A}') = 1 \wedge c = \mathrm {Encrypt}_\mathcal {E}( pk _\mathcal {E}, f( usk ); r') ] \end{aligned}$$

 

The checker predicates required by Definition 3 are as follows. We denote them as algorithms because in our case the predicates are polynomial-time computable.  

$\mathrm {CheckPseud}( pp , pk , sk , usk )$ :

outputs 1 if and only if $pk = ( pk _\mathcal {S}, c, \gamma )$ and $sk = ( sk _\mathcal {S}, r', usk )$ such that $c = \mathrm {Encrypt}_\mathcal {E}( pk _\mathcal {E}, f( usk );r')$ and $\gamma$ is valid signature of knowledge for $NIZK [( usk ,r'); c = \mathrm {Encrypt}_\mathcal {E}( pk _\mathcal {E}, f( usk );r')]( pk _\mathcal {S},c)$.

$\mathrm {CheckShow}( pp , pk _\mathrm {root}, pk , \phi , sk , usk , cred )$ :

outputs 1 iff $\mathrm {CheckPseud}( pp , pk , sk , usk ) = 1$, and $pk _\mathrm {root}= ( pk _{\mathcal {S}, \text {root}}, c_\text {root}, \gamma _\text {root})$, $cred = (\sigma , mk , \vec {A}, d)$ such that $\vec {A}\succeq \phi$, $\mathrm {VrfyMk}_\mathcal {S}( pk _{\mathcal {S}, \text {root}}, \vec {m}^{(\vec {A}, usk , pk _\mathrm {root})}, \sigma , mk , I^{(d, \vec {A})}) = 1$, and $\gamma _\text {root}$ is a valid signature of knowledge $NIZK [( usk _\text {root}, r_\text {root}); c_\text {root} = \mathrm {Encrypt}_\mathcal {E}( pk _\mathcal {E}, f( usk _\text {root}); r_\text {root})]( pk _{\mathcal {S},\text {root}}, c_\text {root})$

$\mathrm {CheckDeleg}( pp , pk _\mathrm {root}, usk , cred , \vec {A}^*)$ :

outputs 1 if and only if $pk _\mathrm {root}= ( pk _{\mathcal {S}, \text {root}}, c_\text {root}, \gamma _\text {root})$, and $cred = (\sigma , mk , \vec {A}, d)$ such that $\gamma _\text {root}$ is a valid signature of knowledge with respect to $NIZK [( usk _\text {root}, r_\text {root}); c_\text {root} = \mathrm {Encrypt}_\mathcal {E}( pk _\mathcal {E}, f( usk _\text {root});r_\text {root})]( pk _{\mathcal {S},\text {root}},c_\text {root})$, and $d = 1$, $\vec {A} \succeq \vec {A}^*$, and $\mathrm {VrfyMk}_\mathcal {S}( pk _{\mathcal {S}, \text {root}}, \vec {m}^{(\vec {A}, usk , pk _\mathrm {root})}, \sigma , mk , I^{(d, \vec {A})}) = 1$    $\diamond$

 

Note that parameters for the argument of knowledge, signature of knowledge, and the hash function $\mathcal {H}$ also need to be part of the public parameters $pp$, but we abstract from the details here.

One can instantiate this construction in a type-3 bilinear group setting, i.e. $\mathrm {Setup}$ generates a bilinear group $\mathbb {G}= (\mathbb {G}_1,\mathbb {G}_2,\mathbb {G}_{\mathrm {T}}, e, p)$ of prime order p. You can use the DMS scheme and its protocol from Sect. 5 for $\mathcal {S}$, and Cramer-Shoup encryption [11] in $\mathbb {G}_1$ for $\mathcal {E}$. Then $M_\mathcal {S}= \mathbb {Z}_p$ and $M_\mathcal {E}= \mathbb {G}_1$, so the bijective one-way function $\mathcal {OW}$ can simply be $x\mapsto g^x$. In this setting, the statements in the zero-knowledge arguments of knowledge fall into the prove knowledge of exponents category. Hence they can be easily constructed from Schnorr-like $\Sigma$ protocols together with Damgård’s technique [12] (using Pedersen’s commitment) to make it concurrent black-box zero-knowledge. To enable arbitrary Boolean formulas for policies $\phi$, one can combine the $\Sigma$ protocol with proofs of partial knowledge [10]. For the signatures of knowledge, you can use Schnorr-like protocols with the Fiat-Shamir heuristic.

Theorem 16

(Security of the generic construction). If $\mathcal {E}$ is correct and CCA-secure, $\mathcal {S}$ is correct (Definition 7), unforgeable (Definition 9) and perfectly derivation private (Definition 8) with secure protocol for deriving a signature on a committed value, $\mathcal {OW}$ is a secure one-way function scheme, and $\mathcal {H}$ is a collision-resistant hash function, then Construction 15 is correct (Definition 3), anonymous (Definition 4), and sound (Definition 5).

A sketch of the proof can be found in the full version of this paper.