Hierarchical Attribute-Based Signatures: Short Keys and Optimal Signature Length

Abstract

With Attribute-based Signatures (ABS) users can simultaneously sign messages and prove compliance of their attributes, issued by designated attribute authorities, with some verification policy. Neither signer’s identity nor possessed attributes are leaked during the verification process, making ABS schemes a handy tool for applications requiring privacy-preserving authentication. Earlier ABS schemes lacked support for hierarchical delegation of attributes (across tiers of attribute authorities down to the signers), a distinct property that has made traditional PKIs more scalable and widely adoptable.

This changed recently with the introduction of Hierarchical ABS (HABS) schemes, where support for attribute delegation was proposed in combination with stronger privacy guarantees for the delegation paths (path anonymity) and new accountability mechanisms allowing a dedicated tracing authority to identify these paths (path traceability) and the signer, along with delegated attributes, if needed. Yet, current HABS construction is generic with inefficient delegation process resulting in sub-optimal signature lengths of order $O(k^{2}|\varPsi |)$ where $\varPsi$ is the policy size and k the height of the hierarchy.

This paper proposes a direct HABS construction in bilinear groups that significantly improves on these bounds and satisfies the original security and privacy requirements. At the core of our HABS scheme is a new delegation process based on the length-reducing homomorphic trapdoor commitments to group elements for which we introduce a new delegation technique allowing step-wise commitments to additional elements without changing the length of the original commitment and its opening. While also being of independent interest, this technique results in shorter HABS keys and achieves the signature-length growth of $O(k|\varPsi |)$ which is optimal due to the path-traceability requirement.

1 Introduction

Attribute-based Signatures, first introduced in [30] and [31], provide privacy-preserving mechanisms for authenticating messages. An ABS signature assures the verifier that the signer owns a set of attributes that satisfy the signing policy without leaking their identity, nor the set of attributes used. Traditional ABS schemes considered two security properties, user privacy and unforgeability. Informally, a user is anonymous if an ABS signature does not leak their identity, nor the set of attributes used to satisfy the signing policy, while unforgeability requires that a signer cannot produce a signature conforming to a policy for which he does not own a set of suitable attributes. Later constructions [14, 16, 20] offered more advanced functionality with an additional property of traceability which holds signers accountable by allowing a dedicated tracing authority to identity them if required.

The vast majority of existing ABS schemes [5, 13, 14, 16, 20, 32, 33, 35] are non-interactive, in the standard model and is based on bilinear maps and Groth-Sahai proofs [21], with the exception of [23], which uses RSA setting and the random oracle model, and the recent schemes in [15, 38] which rely on lattices. Interactive ABS schemes, e.g. [27], where policies must be chosen by verifiers ahead of the signing phase have also been proposed. In general, signing polices can have varying levels of flexibility and range from threshold policies [30], to monotone boolean predicates [14, 20], and generalised circuits [35]. Typically, more restrictive policies allow for more efficient constructions. Policy-based Signatures (PBS) [5] can be viewed as a generalisation of ABS schemes, albeit their security is currently proven in a single-user setting without addressing stronger non-frameability requirement of more recent ABS schemes [12, 14, 20].

Hierarchical Attribute-Based Signature and Their Limitations. Hierarchical Attribute-based Signatures (HABS), recently introduced in [12], extend traditional ABS schemes by permitting controlled delegation of attributes from a root authority (RA) over possibly multiple intermediate authorities (IAs) down to the users. In this way HABS aims to close the gap between ABS and traditional PKIs where hierarchical delegation can be achieved at low cost. In HABS, IAs can delegate attributes to any authority in the scheme and users can acquire attributes from any authority in the hierarchy that is authorised to issue them. In addition to strong non-frameability property in a multi-user setting, the authors extend traditional ABS privacy guarantees to protect not only the identity of the signer but also the identities of all intermediate authorities in the delegation path, as part of their new path-anonymity property. Traditional traceability property of ABS schemes has also been extended to hold not only signers but also intermediate authorities accountable for their actions, through the new notion of path-traceability where a dedicated tracing authority can reveal the entire delegation path, along with delegated attributes.

We observe that the HABS scheme in [12] is generic, based on standard cryptographic primitives, i.e., public key encryption, one-time signature, tag-based signature, and non-interactive zero-knowledge proofs. Its delegation process is handled using a tag-based signature (TBS) where an authority at level i produces a TBS signature, using attribute as a tag, on the public key of authority j together with all public keys appearing previously in the delegation path. As part of its HABS signature the signer proves knowledge of each TBS at every delegation of each attribute that is required to satisfy the policy. Clearly this delegation process is highly inefficient. Not only does an additional signature need to be verified per delegation (and per attribute), the size of the signature grows linearly in the distance from the root authority. Thus, per attribute, verification of the delegation path is of order $O(k^{2})$.

Other Related Work. Attribute-based signatures can be seen as a generalisation of group [11] and ring [34] signatures, in which case identities are viewed as attributes and policies can only contain disjunction over them. The notion of hierarchical delegation in these, more restricted, primitives have been explored in [37] and [29] respectively. Attribute delegation has been widely investigated in anonymous credentials [9, 10]. Maji et al. [31] give discussion that ACs are a more powerful primitive than ABS but with efficiency drawbacks, as attribute acquisition typically requires expensive zero-knowledge proofs. Note that in HABS intermediate authorities may know each other, and so as discussed in [12], there is no need to hide their identities from each other during the delegation phase, which in turn helps to omit costly proofs and make this phase more efficient than in the case of ACs. Regardless, we note that ACs with hierarchical delegation have been proposed [4]. Further, a homomorphic ABS scheme [25] has been used to construct non-delegatable anonymous credentials. In this setting, a signer obtains attributes directly from the (multiple) root authorities where combining attributes from different issuers requires an online collaboration. Anonymous Proxy Signatures [17] also allow for verification of anonymous delegation paths back to a root authority. However, tasks that are delegated, when viewed as attributes, remain in the clear and are required for verification of the proxy signature. Homomorphic Signatures [38] have been claimed to be equivalent to Attribute-based Signatures, however this equality has been shown to hold in the weaker security setting that only considers a solitary user. In which, it is impossible to capture the notion of collusion and non-frameability. Finally, we note functional signatures [3, 8] also allow for delegation of signing rights. Here, however, keys are dependent on the function f and can only sign on messages that fall within the range. For an attribute-based scheme, this would require keys for each possible combination of attributes a user obtains.

Contribution. We address the suboptimal efficiency of the so-far only (generic) HABS construction [12] and propose a scheme with a completely new delegation mechanism which no longer relies on the consecutive issue of tag-based signatures from higher-level to lower-level authorities on the delegation path. The main novelty in our approach is a smart use of the length-reducing homomorphic trapdoor commitment scheme to multiple group elements from [21] which we extend with delegation capabilities. At a high level, at each delegation the issuing intermediate authority amends the current trapdoor opening such that the existing commitment incorporates the public key of the next-level authority or user to whom the attribute is delegated. With this new delegation mechanism we are able to significantly reduce the lengths of HABS keys and achieve the optimal growth of $O(k|\varPsi |)$ for the length of HABS signatures, depending on the length k of the delegation path and size $|\varPsi |$ of the signing policy. In particular, verifying delegation of an attribute along the path takes O(k) steps (as opposed to $O(k^2)$ in [12]). We use the original security model from [12] to show that our construction satisfies the required properties of path anonymity, path traceability, and non-frameability, in the standard model under standard assumptions in bilinear groups and an additional assumption which we justify using the generic group model [36]. Our efficiency improvement claims over [12] are reinforced in a detailed comparison between the two schemes.

2 HABS Model: Entities and Definitions

We start with the description of entities within the HABS ecosystem.

Attribute Authorities. The set of Attribute Authorities (AA) comprises the Root Authority (RA) and Intermediate Authorities (IAs). All AAs can delegate attributes to lower-level IAs and users. The RA is at the top of the hierarchy and upon setup, defines the universe of attributes $\mathbb {A}$. With its key pair ($ask_{0},apk_{0}$), the RA can delegate a subset of attributes to IAs which hold their own key pairs ($ask_{i},apk_{i}$), $i > 0$. IAs can further delegate/issue attributes to any end user (aka. signer). In this way a dynamically expandable HABS hierarchy can be established.

Users. Users join the scheme by creating their own key pair (usk, upk), and are issued attributes by possibly multiple AAs.

By $\varPsi$ we denote a predicate for some signing policy. A policy-conforming user can use usk to create a HABS signature, provided their issued set of attributes A satisfies the policy, i.e. $\varPsi (A')=1$ for some $A' \subseteq A$. Users are unable to delegate attributes further and thus can be viewed as the lowest tier of the hierarchy. To account for this, when an attribute is delegated to a user a dedicated symbol $\star$ will be used in addition to upk to mark the end of the delegation path.

Warrants. An IA or user, upon joining the HABS scheme, receives a warrant warr that consists of all their delegated attributes $a \in \mathbb {A}$ and a list of all AAs in each of the delegation paths. Warrants can be updated at any time, i.e. if the owner is issued a new attribute, by appending a new entry with the list of authorities on the delegation path. We use the notation |warr| to denote the size of the warrant, i.e. the number of attributes stored in the warrant warr, and we use |warr[a]| to denote the length of the delegation path of the attribute $a \in \mathbb {A}$. Upon signing, the user submits a reduced warrant for an attribute set $A' \subseteq A$ that satisfies $\varPsi (A')=1$.

Tracing Authority. The tracing authority (TA) is independent of the hierarchy. Upon receiving a valid HABS signature, it can identify the signer and all authorities on the delegation paths for attributes that the signer used to satisfy the signing policy. The tracing authority can output a publicly verifiable proof $\hat{\pi }$ that the path was identified correctly. The existence of such tracing authority improves the accountability of signers and IAs from possible misbehaviour.

Definition 1

(Hierarchical ABS Scheme [12]). A scheme $\mathrm{\mathtt{HABS}}:= (\mathtt {Setup},\mathtt {KGen},\mathtt {AttIssue}, \mathtt {Sign},\mathtt {Verify}, \mathtt {Trace},\mathtt {Judge})$ consists of the following seven processes:

• $\mathtt {Setup}(1^\lambda$) is the initialisation process where based on some security parameter $\lambda \in \mathbb {N}$, the public parameters pp of the scheme are defined, and the root and tracing authority independently generate their own key pair, i.e. RA’s $(ask_{0}, apk_{0})$ and TA’s $(tsk, tpk)$. In addition, RA defines the universe $\mathbb {A}$ of attributes, and a label $\star$ for users. We stress that due to dynamic hierarchy, the system can be initialised by publishing (pp, $apk_{0}, tpk)$ with $\mathbb {A}$ and $\star$ contained in pp.

• $\mathtt {KGen}(\text {pp})$ is a key generation algorithm executed independently by intermediate authorities and users. Each entity generates its own key pair, i.e., $(ask_{i},apk_{i})$ for $i>0$ or $(usk, upk)$.

• $\mathtt {AttIssue}$ $(ask_{i}, {\mathbf{warr }}_{i}, A, \{apk_{j}\vert upk_j\})$ is an algorithm that is used to delegate attributes to an authority with $apk_{j}$ or issue them to the user with $upk$. On input of an authority’s secret key $ask_{i}$, $i \in \mathbb {N}_{0}$, its warrant ${\mathbf{warr }}_{i}$, a subset of attributes A from ${\mathbf{warr }}_{i}$, and the public key of the entity to which attributes are delegated or issued, it outputs a new warrant for that entity.

• $\mathtt {Sign}$ $((usk, {\mathbf{warr }}), \mathrm{\mathrm{m}}, \varPsi )$ is the signing algorithm. On input of the signer’s $usk$ and (possibly reduced) warr, a message $\mathrm{m}$ and a predicate $\varPsi$ it outputs a signature $\sigma$.

• $\mathtt {Verify}$ $(apk_{0}, (\mathrm{\mathrm{m}}, \varPsi , \sigma ))$ is a deterministic algorithm that outputs 1 if a candidate signature $\sigma$  on a message m is valid with respect to the predicate $\varPsi$ and 0 otherwise.

• $\mathtt {Trace}$ $(tsk, apk_{0}, (\mathrm{m}, \varPsi , \sigma ))$ is an algorithm executed by the TA on input of its private key $tsk$ and outputs either a triple $(upk, {\mathbf{warr }}, \hat{\pi })$ if the tracing is successful or $\bot$ to indicate its failure. Note that ${\mathbf{warr }}$ contains attributes and delegation paths that were used by the signer.

• $\mathtt {Judge}$ $(tpk, apk_{0}, (\mathrm{\mathrm{m}}, \varPsi , \sigma ),\ (upk, {\mathbf{warr }}, \hat{\pi }))$ is a deterministic algorithm that checks a candidate triple $(upk, {\mathbf{warr }}, \hat{\pi })$ from the tracing algorithm and outputs 1 if the triple is valid and 0 otherwise.

A HABS scheme must have the correctness property ensuring that any signature $\sigma$ generated based on an honestly issued warrant will verify and trace correctly. The output ($upk,{\mathbf{warr }},\hat{\pi }$) of the tracing algorithm on such signatures will be accepted by the public judging algorithm with overwhelming probability.

2.1 Security Properties

Our security definitions resemble the requirements of path anonymity, path traceability, and non-frameability from [12]. We recall the associated game-based definitions assuming probabilistic polynomial time (PPT) adversaries interacting with HABS entities through the following set of oracles (Fig. 1):

• $O_{\text {Reg}}{:}$ $\mathcal {A}$ registers new IAs and users through this registration oracle, for which a key pair will be generated and added to List. The public key is given to the adversary. Initially, the entity is considered honest, and so the public key is also added to the list HU.

• $O_{\text {Corr}}{:}$ This oracle allows $\mathcal {A}$ to corrupt registered users or IAs. Upon input of a public key, the corresponding private key is given as output if it exists in List. The public key is removed from HU so the oracle keeps track of corrupt entities.

• $O_{\text {Att}}{:}$ $\mathcal {A}$ uses this oracle to ask an attribute authority to delegate attributes to either an IA or to the user. In particular, the adversary has control over which attributes are issued and the oracle outputs a warrant warr if both parties are registered, otherwise it outputs $\bot$.

• $O_{\text {Sig}}{:}$ $\mathcal {A}$ can ask for a HABS signature from a registered user. The adversary provides the warrant (and implicitly the attributes used), signing policy, message and the public key of the signer. If the attribute set satisfies the policy, and the public key is contained in HU then the signature will be given to $\mathcal {A}$, otherwise $\bot$ is returned.

• $O_{\text {Tr}}{:}$ s $\mathcal {A}$ can ask the TA trace a HABS signature (provided by the adversary) to the output is returned. The TA does verification checks on the signature and upon failure, will return $\bot$.

Fig. 1.

Oracles used in the HABS security experiments.

Path Anonymity. This property extends the anonymity guarantees of traditional ABS schemes and hides not only the identity of the signer but also the identities of all intermediate authorities on delegation paths for attributes included into the signer’s warrant. Path anonymity, as defined in Fig. 2, also ensures that signatures produced by the same signer remain unlinkable. The corresponding experiment requires the adversary to distinguish which warrant and private key were used in the generation of the challenge HABS signature $\sigma _b$. In the first phase, $\mathcal {A}_1$ generates a hierarchy of authorities and users, utilising the RA’s secret key $ask_{0}$. If the warrants created by $\mathcal {A}_1$ are of the same size, a challenge HABS signature $\sigma _{\textit{b}}$ is produced on the randomly chosen user-warrant pair. In the second phase, with access to the tracing oracle, the adversary $\mathcal {A}_2$ must be able to guess the challenge bit b.

Definition 2

(Path Anonymity [12]). A HABS scheme offers path anonymity if no PPT adversary adv can distinguish between ${{\mathrm{\mathbf{Exp}}}}_{HABS, \mathcal {A}}^{\mathrm{pa-0}}$ and ${{\mathrm{\mathbf{Exp}}}}_{HABS, \mathcal {A}}^{\mathrm{pa-1}}$ defined in Fig. 2, i.e., the following advantage is negligible in $\lambda$:

$${{\mathbf{\mathrm{Adv}}}}^{\mathrm{pa}}_{HABS,\mathcal {A}}(\lambda ) = |{\mathrm{Pr}[{{\mathbf{\mathrm{Exp}}}}_{HABS, \mathcal {A}}^{\mathrm{pa-0}} (\lambda ) = 1] - |\mathrm{Pr}[{{\mathrm{\mathbf{Exp}}}_{HABS, \mathcal {A}}^{\mathrm{pa-1}} (\lambda ) = 1}}]|. $$

Fig. 2.

Path-anonymity experiment

Non-frameability. This property, formalised in Fig. 3, captures the notion of unforgeability, i.e., that no PPT adversary can create a HABS signature without having an honestly issued warrant that satisfies the policy, and in particular, they cannot create one on behalf of an user for which the secret key is not known. The adversary wins if either he produces a valid HABS signature, or is able to perform delegation for at least one attribute on behalf of any honest authority anywhere in the delegation path.

Definition 3

(Non-Frameability [12]). A HABS scheme is non-frameable, if no PPT adversary $\mathcal {A}$ can win the experiment ${\mathrm{\mathbf{Exp}}}_{\mathrm{\mathtt{HABS}}, \mathcal {A}}^{\mathrm{nf}}$ defined in Fig. 3, i.e., the following advantage is negligible in $\lambda$:

$$ {\mathrm{\mathbf{Adv}}}^{\mathrm{nf}}_{HABS,\mathcal {A}}(\lambda ) = | \mathrm{Pr}[{\mathrm{\mathbf{Exp}}}_{HABS, \mathcal {A}}^{\mathrm{nf}}({\lambda })=1]|. $$

Fig. 3.

Non-frameability experiment

Fig. 4.

Path-traceability experiment

Path Traceability. This property, formalised in Fig. 4, ensures that any valid HABS signature can be traced (by the tracing authority) to the signer and the set of authorities that were involved in the issue of attributes used to produce the signature. The adversary is required to output either a HABS signature that verifies but cannot be traced, or one in which the tracing algorithm outputs a warrant for which at least one IA or the user is unknown to the experiment, i.e., were not previously registered in List. The attribute-issuing oracle checks that both entities are registered to prevent the trivial attack where adversary asks the oracle to delegate to an unregistered entity.

Definition 4

(Path Traceability [12]). A HABS scheme offers path traceability if no PPT adversary $\mathcal {A}$ can win the experiment ${\mathrm{\mathbf{Exp}}}_{\mathrm{\mathtt{HABS}}, \mathcal {A}}^{\mathrm{tr}}$ defined in Fig. 4, i.e., the following advantage is negligible in $\lambda$:

$$ {\mathrm{\mathbf{Adv}}}^\mathrm{tr}_{HABS,\mathcal {A} }(\lambda ) = |\mathrm{Pr}[{\mathrm{\mathbf{Exp}}}_{HABS, \mathcal {A}}^{\mathrm{tr}}({\lambda })=1]|. $$

3 Our Short HABS Construction

We start with the description of the underlying hardness assumptions and building blocks.

3.1 Underlying Hardness Assumptions

In addition to widely used hardness assumptions in the asymmetric bilinear group setting generated by $\mathcal {BG}(1^{\lambda })$, namely q-Srong Diffie-Hellman (q-SDH) [7], Symmetric eXternal Diffie-Hellman (SXDH) [1] and Simultaneous Decision LINear (SDLIN) [26] assumptions, which we do not recall here, our scheme requires the following interactive assumption, which we prove to hold in the generic group model [24, 36]. We equip the adversary with an oracle $\mathcal {O}_{X_0,Y_0}$ and assume that it is hard to produce group elements that satisfy the verification equations for an input that has not been queried to the oracle. We note that on input of (X, Y), the oracle can compute each component without knowledge the discrete logarithm of X or Y as it has access to $r,s,t_1,t_2.$

Assumption 1

Let $pp:=(p,\mathbb {G}_1,\mathbb {G}_2,\mathbb {G}_T,e,g_1,g_2) \leftarrow \mathcal {BG}(1^{\lambda })$. The adversary $\mathcal {A}$ has access to the oracle $\mathcal {O}_{X_0,Y_0}(\cdot ,\cdot )$ which on input (X, Y) returns $(A,B,T_1,T_2, T_3,T_4):=(h_2^{x_0t_1}h_5^{x_0t_2}h_2^{xt_1}h_5^{yt_1},h_5^{y_0t_1}h_4^{y_0t_2}h_5^{xt_2}h_4^{yt_2},f_1^{t_1},f_2^{t_2},g_2^{t_1},g_2^{t_2})$ for $t_1,t_2 \leftarrow \mathbb {Z}^{*}_p$. We assume that for all p.p.t. adversaries $\mathcal {A}$, the following probability is negligible in $\lambda$.

$$ \begin{array}{l} {Adv}^{\mathtt {Assump 1}}_{\mathcal {A}}(\lambda ) := \\ \text {Pr}\left[ \begin{array}{l} x_0,y_0,r,s \leftarrow \mathbb {Z}^{*}_p; h_1:=g_1^{s},h_2:=g_1^{s^{2}},h_3:=g_1^{r}, h_4:=g_1^{r^{2}}, h_5:=g_1^{rs} \\ f_1:=g_2^{s},f_2:=g_2^{r}, X_0:=h_1^{x_0}; Y_0:=h_3^{y_0}; \\ (\hat{A},\hat{B},\hat{T}_1,\hat{T}_2,\hat{T}_3,\hat{T}_4, \hat{X}, \hat{Y}) \leftarrow \mathcal {A}^{\mathcal {O}_{X_0,Y_0}}(pp, X_0, Y_0, h_1,h_2,h_3,h_4,h_5, f_1,f_2): \\ e(\hat{A},g_2) = e(X_0,\hat{T}_1\hat{T}_2)e(\hat{X}\hat{Y},\hat{T}_1)\ \wedge \ e(\hat{B},g_2) = e(Y_0,\hat{T}_1\hat{T}_2)e(\hat{X}\hat{Y},\hat{T}_2) \\ \ \wedge \ e(g_1,\hat{T}_1\hat{T}_2) = e(h_1,\hat{T}_3)e(h_3,\hat{T}_4) \quad \mathrm{where }\ (\hat{X},\hat{Y})\ \mathrm{was\ not\ queried. } \end{array} \right] \end{array} $$

Theorem 1

Let $\mathcal {A}$ denote an adversary in the generic group model against Assumption 1. $\mathcal {A}$ has access to oracles for which he makes $q_G$ group queries, $q_P$ pairing queries, and $q_O$ oracle queries. The probability $\epsilon$ of $\mathcal {A}$ winning the game for Assumption 1 is bounded by $\epsilon \le 5(q_G+q_P+6q_O+11)^2/p$, where p is the prime order of the generic groups.

Proof

See full version [19].

3.2 Cryptographic Building Blocks

The following building blocks will be used in our HABS construction.

Tag-Based Encryption. A $\mathtt {TBE}$ scheme has the same algorithms as a traditional public key encryption scheme, except that its encryption and decryption procedures take an extra tag t as input. A correctly formed $\mathtt {TBE}$ ciphertext C will fail to decrypt if the tag used as input to the decryption algorithm is different from the one used upon encryption. We adopt the $\mathtt {TBE}$ scheme from [26] which relies on the SDLIN assumption. It offers selective-tag witness-indistinguishable chosen-ciphertext (st-IND-CCA) security, where an adversary is unable to distinguish between two ciphertexts under the same tag t of their choosing. Kiltz [28] showed that a st-IND-CCA $\mathtt {TBE}$ scheme combined with a strongly unforgeable one-time signature, where the one-time verification key is used as the tag, gives rise to an IND-CCA2 secure PKE. Our scheme uses this approach.

One-Time Signature. For the $\mathtt {OTS}$, we use the strongly unforgeable BBS one-time signature scheme from [7]. It consist of three algorithms (KeyGen, Sig, Ver) with a verification key in $\mathbb {G}^{2} \times \mathbb {Z}_p^{*}$ and the corresponding signing key in $\mathbb {Z}_p^{*2}$.

Groth-Sahai Proofs. We use the Groth-Sahai proof system [22] to construct the required non-interactive zero-knowledge proofs $\mathtt {NIZK}_{.}$ A GS proof, which consists of five algorithms $(\texttt {Setup}, \texttt {Prove}, \texttt {Verify}, \texttt {SimSetup},\texttt {SimProve})$, allows proving relations involving multi-linear, quadratic, and pairing-based equations. We use GS proofs in the asymmetric bilinear group setting with Type-3 curves [18], i.e., where there is no computable isomorphism between $\mathbb {G}_1$ and $\mathbb {G}_2$, in which case their security is based on the SXDH assumption [7].

Homomorphic Trapdoor Commitments to Group Elements. The key to our short HABS scheme is the length-reducing homomorphic trapdoor commitment scheme by Groth [21], adopted in our new delegation mechanism. With the HTC scheme, defined by four algorithms $(\texttt {Setup},\texttt {KeyGen},\texttt {Commit}, \texttt {Trapdoor})$, one can use the trapdoor key tk to open a constant-length commitment (c, d) to arbitrary group elements with respect to a commitment key. We observe that due to its construction this $\mathtt {HTC}$ scheme has an interesting property that allows a commitment to group elements step-wise, i.e. an opening $(a_i,b_i)$ to elements $g_1,\ldots ,g_i$ can be transformed into an opening $(a_{i+1},b_{i+1})$ for an extended set of elements $g_1,\ldots ,g_{i+1}$ without knowledge of the secret commitment key, i.e., without jeopardising the binding property for the already committed group elements. In our HABS scheme such step-wise extension of an initial commitment (c, d) produced by the root authority allows intermediate authorities, upon delegation, to embed public keys of next-level authorities or users, along with the delegated attribute, by providing appropriate modification to the opening of (c, d), that is without changing its value nor increasing its length. Proving ownership of a delegated attribute amounts to presenting an opening (a, b) for the commitment (c, d) to the attribute and the list of public keys of authorities on the delegation path, i.e., $apk_{0},\ldots ,$upk$,\star$. In our scheme we use the asymmetric variant of Groth’s $\mathtt {HTC}$ scheme with security based on the XDLIN assumption [1].

3.3 Specification of Our HABS Scheme

We start with a high-level intuition behind our HABS construction and provide detailed specification in Figs. 5, 6, and 7.

High-Level Overview. As part of the setup process public parameters pp of the scheme are generated. They include the security parameter $\lambda$, the description of bilinear groups $(\mathbb {G}_1,\mathbb {G}_2, \mathbb {G}_T)$, the trapdoor key tk for the $\mathtt {HTC}$ scheme, the initial ‘dummy’ $\mathtt {HTC}$ commitment (c, d) with an opening ($a_0,b_0$), and the description of the attribute universe $\mathbb {A}$. The independent tracing authority TA generates the $\mathtt {TBE}$ key-pair ($tsk$, $tpk$):=$((\eta _1,\eta _2),(V_1,V_2,V_3,V_4))$ with $tpk$ included into pp. For simplicity we describe the setup phase as a single process involving computations performed by the RA and TA. We stress, however, that generation of $h_1,...,h_5,f_1,f_2$ must be trusted in that no entity knows the corresponding exponents.

Fig. 5.

Setup algorithm of our HABS construction.

In our scheme, all attribute authorities and users generate their own private/public key pairs ($ask_{i}$, $apk_{i}$) and (usk, upk) respectively, of the form $\{(x,y),(X,Y,Z,\hat{Z})\}$. While only X and Y are used in the verification of attribute delegation which we prove in the signature, the components ($Z,\hat{Z}$) are used in the issuing phase. To ensure an authority creates a delegation that opens to (X, Y), we insist that the validity of a public key is checked prior to delegation. This is done by evaluating $e(XY,h_1)=e(Z,g_2)$ and $e(XY,h_3)=e(\hat{Z},g_2)$. IAs and users obtain attributes from existing authorities at a higher level in the hierarchy. Ownership of a valid key-pair $(ask_{i},apk_{i})$ allows authorities to delegate attributes further down the hierarchy and to the users, by manipulating the opening of the initial commitment (c, d).

With the trapdoor key tk an authority can create an opening ($a_i,b_i$) for (c, d) to the path that includes delegate’s public key e.g. $apk_{j}$. Rather than opening directly, the issuer first creates randomisation tokens $T_1,T_2,T_3,T_4 \in \mathbb {G}_2$ and opens to these instead. It then uses $T_1$ and $T_2$ as one-time commitment keys to open to $apk_{j}$ and the delegated attribute att, that is hashed into the message space using $g^{\mathcal {H}_1(att)}$. The randomisation tokens $T_1$ and $T_2$ are used to prevent forgeries (where the adversary combines multiple openings and in doing so, forges an opening to a new public key) whereas $T_3$ and $T_4$ are used to verify the well-formedness of $T_1$ and $T_2$, by evaluating $e(g_1,T_1T_2)=e(h_1,T_4)e(h_3,T_3)$. The issuing authority updates the (possibly empty) warrant with opening ($a_i,b_i$), his public key $apk_{i}$ and the randomisation tokens $(T_1,T_2,T_3,T_4)$. As tk is part of public parameters, any IA in the hierarchy is able to perform the delegation procedure, where it receives $(a_{i-1},b_{i-1})$ from its issue and generates $(a_i,b_i)$ for the next delegation. When delegating to users, an issuing IA will open (c, d) to a designated element $\star \in \mathbb {G}$, in addition to the user’s public key upk and the attribute att. A warrant contains the trapdoor opening and a list of all public keys of AAs that appear in the delegation path for any issued attribute.

Fig. 6.

Key generation and issue of attributes in our HABS construction.

Upon signing, the user first generates an $\mathtt {OTS}$ key-pair $(otssk,otsvk):=\{(k_1,k_2),(K_1,K_2,\kappa )\}$ and an opening to $\mathcal {H}_3(otsvk)$ by modifying the opening $(a_0,b_0)$ using his public key upk and the trapdoor key tk. The reduced warr along with upk are encrypted in a $\mathtt {TBE}$ ciphertext under the TA’s public key $tpk$ and tag $\mathcal {H}_3(otsvk)$. The signing policy $\varPsi$ is modelled as a monotone span program, with labelling function $\rho$ that maps rows from S to the attribute set $\mathbb {A}$. The signer proves that this set satisfies $\varPsi$ by computing a vector $\mathbf z$ such that $\mathbf {zS}=[1,0,...,0]$, where any non-zero entry z$_i$ implies $\rho (i) \in {\mathbf{warr }}$. A $\mathtt {NIZK}_{\ }$proof $\pi$ is then computed using Groth-Sahai framework with witness ($upk,{\mathbf{warr }},\mathbf {z},\tilde{r},\tilde{s}$) for the following relation:

Fig. 7.

Sign, Verify, Trace and Judge algorithms of our HABS construction.

The message m and policy $\varPsi$ are then bound to this proof and ciphertext by hashing $\mathcal {H}_2(\pi ,\text {C},\varPsi ,m)$, before an $\mathtt {OTS}$ signature $\sigma _o$ is produced with otssk. The resulting signature is verified with respect to the public parameters of the scheme, and the RA’s public key $apk_{0}$ by verifying the $\mathtt {OTS}$ signature and the $\mathtt {NIZK}_{\ }$proof.

As part of the tracing procedure, executed by TA with knowledge of tsk, the ciphertext C is decrypted to obtain the warrant warr, signer’s public key upk, and the opening (a, b). A publicly verifiable $\mathtt {NIZK}_{}$ proof $\hat{\pi }$ is created with witness $tsk$ for the statement ($otsvk$, C, $tpk$, ($apk_{0}$, warr)) and relation:

We give a detailed construction for the Groth-Sahai proofs $\mathtt {NIZK}_{1}$ and $\mathtt {NIZK}_{2}$ in Appendix D.

3.4 Security Analysis

In this section we prove that our construction meets HABS security properties of path anonymity, non-frameability and path traceability.

Lemma 1

The HABS construction from Figs. 5, 6 and 7 offers path anonymity, if SXDH, SDLIN and q-SDH hold in $\mathcal {G}$.

Proof

We follow a game-based approach and show that the advantage of the PPT adversary $\mathcal {A}$ in the path-anonymity experiment for the $\mathrm{\mathtt{HABS}}$ construction from Figs. 5, 6 and 7, is bounded by the advantages of the constructed adversaries for the underlying primitives. We assume that adversary $\mathcal {A}$ asks n user registration queries and the probability for sampling one of these users is 1/n.

Game $G_{0}$ : This game is defined to the be the experiment in Fig. 2, where the 2-stage adversary $\mathcal {A} =(\mathcal {A}_1,\mathcal {A} _2)$ is required to distinguish between the HABS signatures $\sigma _0 = (\sigma _{o}^0,\text {C}_0, \pi _0, otsvk_0)$ and $\sigma _1 = (\sigma _{o}^{1},\text {C}_1,\pi _1,otsvk_1)$.

Game $G_1$: We define the game $G_{1}$ as $G_{0}$ where the check “$\mathcal {A}_{2}$ did not query $O_\text {Tr}(m, \varPsi , \sigma _{b})$” is enforced by the $O_\text {Tr}$ oracle available to $\mathcal {A}_2$, which aborts the game if this is the case. The probability from $G_0$ to $G_1$ is preserved.

Game $G_2$: The game $G_2$ is obtained from $G_1$ where, on the output of $O_\text {Tr}$, we replace the $\mathtt {NIZK}_{2}$ proof $\hat{\pi }$ with $\hat{\pi }'$ from the simulator $\mathtt {NIZK}_{2}.\mathtt {SimProve}$. We also replace $\mathtt {Setup}$ by $\texttt {SimSetup}$ for $\mathtt {NIZK}_{2}$. This prevents the case where $\mathcal {A}$ may “extract” $tsk$ from $\mathtt {NIZK}_{2}$ proofs. Thus, for all future $O_\text {Tr}$ oracle calls we use the simulated $\mathtt {NIZK}_{2}$ proof. The probability that $\mathcal {A}$ can distinguish between these two games is bounded by the advantage of the zero-knowledge adversary $\mathcal {B}_{nizk2}$ for $\mathtt {NIZK}_{2}$. For our instantiation of GS proofs, this is reduced to the SXDH assumption [22].

Game $G_3$: Let $G_3$ be the game obtained from $G_2$ where we replace the proof $\pi _b$ from the challenge signature $\sigma _b = (\sigma _{o,b},C_b,\pi _b,otsvk_b)$ with the simulated proof $\pi '_b$ by calling $\mathtt {NIZK}_{1}.\texttt {Sim}$ on $(\text {C}_b, otsvk_b, tpk, apk_{0}, \varPsi )$. Additionally, we replace $\mathtt {NIZK}_{1}.\mathtt {Setup}$ by $\mathtt {NIZK}_{1}.\texttt {SimSetup}$. The probability that $\mathcal {A}$ can distinguish between games $G_2$ and $G_3$ is bounded by the advantage of the zero-knowledge adversary $\mathcal {B}_{nizk1}$ for $\mathtt {NIZK}_{1}$ proof. Similarly, this property is implied by SXDH.

Game $G_4$: Game $G_4$ only differs from game $G_3$ in that we abort if $\mathcal {A}_2$ queries $O_\text {Tr}(m,\varPsi ,(\sigma _{o},\text {C}_{b}, \pi , otsvk_{b}))$. The adversary $\mathcal {A}$ is only able to distinguish between these games if it can produce a valid $\mathtt {OTS}$ signature $\sigma _o$ for the message $(C_b,\pi ,m,\varPsi )$ and public key $otsvk_{b}$, without knowledge of the secret key $otssk_{b}$. Thus, the capabilities of the adversary $\mathcal {A}$ to distinguish between these two games is bounded by the advantage of the adversary $\mathcal {B}_{ots}$ against the strong unforgeability of the $\mathtt {OTS}$ scheme, which is reduced to the q-SDH assumption [7].

Game $G_5$: Game $G_5$ is defined to be $G_4$, except we additionally do a check for any queries $\mathcal {A}_2$ makes do not contain the challenge ciphertext, that is $O_\text {Tr}( m,\varPsi ,(\sigma _{o},\text {C}_{b}, \pi , otsvk))$. If so the game is aborted. The output of $O_\text {Tr}$ is for $G_4$ and $G_5$ is the same, as the oracle returns $\bot$ if the tag $otsvk_b$ for $\text {C}$ is different from $otsvk$ received as input. Hence, the probability is preserved.

Game $G_6$: The game $G_6$ is the same as $G_5$, except that we move the $\mathtt {OTS}$ key generation from the signature generation phase into the setup of the experiment. Note that only one key pair needs to be created in this game since the adversary only sees the challenge signature. This step is necessary to utilise the st-IND-CCA property of the $\mathtt {TBE}$ scheme. The probability is unchanged from game $G_5$ to $G_6$.

Game $G_7$: Let $G_7$ be the game obtained from $G_6$ where the $\mathtt {TBE}$ ciphertext $\text {C}_b$ from the challenge signature $\sigma _b = (\sigma _{o}^b,C_b,\pi '_b, otsvk_b)$ is replaced with the $\text {C}_0$. The adversary $\mathcal {A}$ is unable to query a ciphertext $C'\ne \text {C}_b$ for the same tag $\mathcal {H}_3(otsvk)$ as a result of game $G_4$. Further, any query to the oracle for a tag $t' \ne \mathcal {H}_3(otsvk)$ will also fail as decryption of $\text {C}_b$ is dependent on the correct tag. Thus, the ability of the adversary $\mathcal {A}_2$ to distinguish between the ciphertexts $C_0$ and $C_b$ is bounded by the advantage of the st-IND-CCA adversary $\mathcal {B}_{ind}$. For out instantiation, this property of $\mathtt {TBE}$ is implied by SDLIN [26].

The experiment $G_7$ provides $\mathcal {A}$ with the same challenge signature independent of b that $\mathcal {A}$ is asked to guess. Additionally, due to the zero-knowledge property of $\mathtt {NIZK}_{2}$ used in $G_1$, $\mathcal {A}$ does not have access to $tsk$. Therefore, the probability that the adversary wins game $G_7$ is 1/2 and hence the advantage of $\mathcal {A}$ to win this experiment is 0. $\square$

Lemma 2

The HABS construction from Figs. 5, 6 and 7 is non-frameable, if $\mathcal {H}_1,\mathcal {H}_2$ and $\mathcal {H}_3$ are second-preimage resistant hash functions, and q-SDH, SXDH and Assumption 1 hold in $\mathcal {G}$.

Proof

We begin by first splitting the non-frameability experiment from Fig. 3 into two experiments based on the winning condition of the adversary $\mathcal {A}$. The first $\mathbf{Exp }_1$, defined in Fig. 8, captures the probability of the adversary $\mathcal {A}$ to create a forged HABS signature. The second experiment $\mathbf{Exp }_2$ is the same as $\mathbf{Exp }_1$ except that the event “$j \in HU \ \wedge \ \mathcal {A} \text{ did } \text{ not } \text{ query } O_\text {Sig}((usk_j, {\mathbf{warr }}), \varPsi , \mathrm{m})$” is replaced with

We capture the probability of winning the non-frameability experiment by the probability that $\mathcal {A}$ wins either $\mathbf{Exp }_1$ or $\mathbf{Exp }_2$.

Fig. 8.

Experiment $\mathbf{Exp }_1$

We first bound the advantage of the adversary for the experiment $\mathbf{Exp }_1$. Intuitively, we consider the output of the adversary and argue that each component must coincide with a call to the signing oracle. The forgery is denoted by $(upk',{\mathbf{warr }}',$ $m',\varPsi '), (\sigma '_{o},\text {C}',\pi ',otsvk')$. We take each element of the tuple $(upk_j, {\mathbf{warr }},$ $m,\varPsi )$ and try to reason about its relation with their prime counterpart.

Given n calls to the registration oracle, we model the probability the adversary can guess which oracle constructs the keys for a particular user uniformly, i.e. is equal to 1/n.

Game $G_{0}$. This game is defined as $\mathbf{Exp }_1$ where the query restriction “$\mathcal {A}$ did not query $O_\text {Sig}((usk_j,$ ${\mathbf{warr }}), m,\varPsi )$” in instead enforced by a membership check $(upk_u,{\mathbf{warr }},m,\varPsi ) \notin SigL$ for the list SigL. We also introduce the list SigLO that stores the input and output of the $O_\text {Sig}$ oracle. Both lists are initialised empty at the beginning of the experiment, and are updated with the inputs, and additionally, the outputs of the $O_\text {Sig}$ oracle, respectively. The probability is preserved between $\mathbf{Exp }_1$ and $G_0$.

Game $G_{1}$. This game is defined exactly as $G_0$ with the exception of an additional check that the opening (a, b) for (c, d) contains the path $e(X_i,g^{\mathcal {H}_3(otsvk)})$ and $e(Y_i,g^{\mathcal {H}_3(otsvk)})$, respectively. The success probability of a soundness adversary for $\mathtt {NIZK}_{1}$ bounds the distinguishability of $G_1$ from $G_0$. That is, $\mathcal {A}$ can only distinguish between these two games if it is able to generate a valid $\mathtt {NIZK}_{1}$ proof for a false statement, namely that (a, b) does not open to $g^{\mathcal {H}_3(otsvk)}$. Soundness for our instantiation of $\mathtt {NIZK}_{1}$ is implied by the SXDH assumption [22].

Game $G_2$. The game $G_2$ is obtained from $G_1$ by adding the condition $(upk_j,\star ,\star ,\star ) \notin SigL$. The adversary in $G_2$ managed to create a valid opening (a, b) for $upk_u$ to $g^{\mathcal {H}_3(otsvk)}$, without having access to the user’s secret key $usk_j$ (since $j \in HU$). The capabilities of $\mathcal {A}$ in this experiment are upper-bounded by the advantage of an adversary against Assumption 1 and the second-preimage property of $\mathcal {H}_3$.

Game $G_3$. Game $G_3$ is defined to be Game $G_1$, but where $\mathcal {A}$ made at least one signing query that contains user $upk_j$. Therefore, there exists $((upk_j,{\mathbf{warr }}',m',\varPsi '),(\sigma '_{o},\text {C}',\pi ',otsvk')) \in SigL$ with $({\mathbf{warr }},m,\varPsi ) \ne ({\mathbf{warr }}',m',\varPsi ')$ as $(upk_j,{\mathbf{warr }},m,\varPsi ) \notin SigL$ but $(upk_j,{\mathbf{warr }}',m',\varPsi ') \in SigL$. The probability is preserved between $G_1$ and $G_3$.

Game $G_4$. We define $G_4$ as the game $G_3$ where $otsvk\ne otsvk'$. In this case, the adversary $\mathcal {A}$ is able to provide a forged opening to $g^{\mathcal {H}(otsvk')}$ without knowledge of $usk_j$. This is similar to the method of computing the bound for $G_2$, except that now $\mathcal {A}$ asks signature queries for upk. It is also bounded by an adversary against Assumption 1.

Game $G_5$. We define game $G_5$ as the game $G_3$ where $(m,\varPsi ) \ne (m',\varPsi ')$. At this point, we have $otsvk= otsvk'$ and upk = $upk_j$ for some j. Thus, if $\mathcal {A}$ can distinguish between $G_5$ and $G_3$ then it is able to provide a forgery for the $\mathtt {OTS}$ scheme by signing a message that contains $(m',\varPsi ')$ without knowledge of $otssk$, or break the second preimage property of $\mathcal {H}_2$.

Game $G_6$. We define game $G_6$ as the game $G_5$ where $(m,\varPsi ) = (m',\varPsi ')$. Because of the $({\mathbf{warr }},m,\varPsi ) \ne ({\mathbf{warr }}',m',\varPsi ')$ restriction, we have ${\mathbf{warr }}' \ne {\mathbf{warr }}$. The correctness property of the encryption scheme $\mathtt {TBE}$ that builds $\text {C}'$ now implies $\text {C}\ne \text {C}'$ under the tag $t=\mathcal {H}_3(otsvk)$. The probability that the adversary can distinguish between $G_6$ and $G_5$ is upper-bounded by an adversary $\mathcal {B}_{cor}'$ against the correctness of $\mathtt {TBE}$, which is implied by the SDLIN assumption [26].

Game $G_7$. Let $G_7$ is the same as $G_6$ but with $\text {C}\ne \text {C}'$. Assuming second-preimage resistance of $\mathcal {H}_2$, the adversary $\mathcal {A}$ managed to create a forged $\mathtt {OTS}$ signature without knowledge of $otssk$. Therefore, the probability of success for adversary $\mathcal {A}$ in this game is bounded by the advantage of an $\mathtt {OTS}$-forger $\mathcal {B}'_{ots}$. The q-SDH assumption implies the BBS signature is strongly unforgeable [7].

From the sequence of games $G_0,\ldots , G_7$, it follows that the probability of $\mathbf{Exp }_1$ is bounded by the unforgeability of $\mathtt {OTS}$, zero-knowledge of $\mathtt {NIZK}_{1}$, correctness of $\mathtt {TBE}$, and computational hardness of Assumption 1.

The experiment $\mathbf{Exp }_2$ captures the case where the adversary $\mathcal {A}$ is able to provide a forged delegation for an honest authority $apk_i$ and some attribute att. In this case, $\mathcal {A}$ is bounded by the hardness of Assumption 1 and the second preimage property of $\mathcal {H}_1$.

Lemma 3

The HABS construction from Figs. 5, 6 and 7 offers path traceability, if SXDH, SDLIN and Assumption 1 hold in $\mathcal {G}$.

Proof

See full version [19].

Theorem 2

The HABS scheme in Figs. 5, 6 and 7 offers path-anonymity, non-frameability and path-traceability if $\mathcal {H}_1$, $\mathcal {H}_2$ and $\mathcal {H}_3$ are second-preimage resistant hash functions and SXDH, SDLIN, q-SDH and Assumption 1 hold in $\mathcal {G}$.

Proof

The result follows from Lemmas 1, 2 and 3. $\square$

4 Efficiency Comparison

We first compare the warrant sizes for our scheme and [12]. For a single attribute, an authority at level 1 (with respect to the root authority at level 0) has a warrant size of 6 group elements (of the form $\mathbb {G}_1^2 \times \mathbb {G}_2^4$). Further delegation to level 2 adds a further 6 elements in $\mathbb {G}_1^2 \times \mathbb {G}_2^4$. A delegation from the root authority contains the opening (a, b) (as part of the 6 elements) which is updated by subsequent delegations, however the warrant must now also contain the issuers public key $(X_i,Y_i)$ in $\mathbb {G}_1^2$. This generalises, and for a user at level k, the size of the warrant is 6k for a single attribute. Likewise, if we extend the number of attributes in the warrant to |A|, each of which has a delegation path of length k, then the warrant has 6k|A| group elements.

In contrast, for a single attribute issued to a level-1 entity, the warrant in [12] contains $7\lceil \frac{12+2m}{m-2}\rceil$ group elements, where m is the size of the message space used in the TBS instantiation. A level-2 delegation increases this to $7\lceil \frac{24+4m}{m-2}\rceil \,+\,2m\,+\,12$ elements, and this generalises for a single attribute that is issued to a level k entity to $7\lceil \frac{k(12+2m)}{m-2}\rceil +(k-1)(2m+12)$ elements. Similarly, a warrant that contains |A| attributes adds a linear factor of |A| to this term. To give a concrete comparison, a user with 3 attributes at level 4 of the hierarchy would have a warrant containing 72 group elements in our scheme, as opposed to 208 elements for an optimal choice of m (i.e., $m=10$) in the scheme from [12]. Since m would be chosen in advance during the setup phase, the warrant would unlikely reach its optimal bound and for any suboptimal choice of m, the warrant grows linearly in this parameter.

Next, in Table 1 we compare the sizes of public keys (of users and authorities) and the lengths of signatures generated by our scheme and [12]. By $\beta$ we denote the size of the span program representing the policy $\varPsi$. As before k is the maximum length of a delegation path, $|\varPsi |$ is the number of attributes needed to satisfy the signing policy, and m is the size of the message space for the TBS scheme used in [12].

Table 1. Comparison of key and signature sizes.

In addition to being more efficient and shorter than [12], our scheme, in fact, produces HABS signatures of optimal length, from the asymptotic point of view. The need to provide path traceability, where the TA must be able to reveal the entire delegation path along with delegated attributes from a valid HABS signature implies the $O(k|\varPsi |)$ growth of its length. This means that in order to reduce this bound path-tracability property would need to be relaxed.

Finally, our scheme brings a few other efficiency improvements. The use of Type-3 pairings results in fewer group elements and the possibility to achieve the same level security for a smaller choice of the prime p [18], which would give rise to smaller groups and faster operations than in the symmetric setting. In addition, we can adopt batch verification techniques available for Groth-Sahai proofs [6] to speed up the computations.

5 Conclusion

We proposed a direct construction of Hierarchical Attribute-based Signatures (HABS) with a new delegation process based on length-reducing homomorphic trapdoor commitments. Our HABS scheme significantly reduces the lengths of warrants, public keys and signatures in comparison to the so-far only known (generic) HABS construction. Moreover, due to the need to support the path-traceability requirement, our HABS scheme achieves optimal signature length growth of $O(k|\varPsi |)$ for delegations paths of size k and signing policies of size $|\varPsi |$. Our technique of step-wise embedding of new group elements into the homomorphic trapdoor commitment can be considered to be of independent interest, e.g., it could add support for delegation to other privacy-preserving signature schemes that rely on homomorphic trapdoor commitments, e.g. [2].