Creating an AAS scheme requires three stages. The first stage is finding a secure group signature scheme that will prove that the signer is a member of the group in a fully anonymous and traceable matter. The second stage is proving possession of attributes and that is using the tree in Section 5.2. The third stage is to prove that the signer of the group signature scheme is a signer satisfying the attributes. In this section we demonstrate stage three. We show how to use the group signature algorithms in Section 4.2.1 and the attribute tree structure in Section 5.2 to create the AAS
algorithms in Section 5.4.1. We should highlight the fact that an attribute tree as defined in Section 5.2 requires bilinear maps. To guarantee FAP security (Section 5.2), the bilinear map e : G1× G2→ G3 should be chosen over groups of prime order where
the BDH (See Definition 2.2.9) is hard. In order to convert the elements of the group signature, which can be of any key space, into elements in the mathematical groups G1
and G2 we use hash functions. The hash function chosen should be collision resistant.
The algorithms of the AAS scheme are constructed as follows: • GCS.Setup : The central authority follows the steps below:
1. Run SGS.Setup to produce the system parameters Spub, and Spri.
2. Choose a hash function H1 : {0, 1}∗ → G1 and H2 : {0, 1}∗ → G2.
3. Output (Spri, Spub, H1, H2), where Spri is kept private to the central au-
thority and the rest can be accessed by anyone.
• GCS.M.KeyGen: The central authority creates the public key base w, n private key bases bsk[i] and registration keys Ai as follows:
1. Run SGS.KeyGen algorithm to get n private keys, bsk[i].
2. Let the private key base of the AAS be bsk[i]. Let the registration key, Ai = H1(bsk[i]).
3. The central authority saves H2(bsk[i]) in a database which we will refer to
as T used for tracing purposes.
• GCS.A.KeyGenpub: The attribute authority chooses for attribute j, a master
key tj ∈R Z∗p in order to create the attribute public key, bpkj = H2(Spub)tj. To
guarantee honesty of attribute authority in generating the key, this algorithm is replaced with the protocol APK as explained in Section 5.4.6.
• GCS.A.KeyGenpri : An attribute private key for user i will be Ti,j = A 1/tj
i .
The private key the member will use to sign with is gsk = hbsk[i], Ti,1, ..., Ti,ji
where j is the number of attributes he owns. As done in Section 5.4.6, this al- gorithm is replaced with the protocol ASK. The protocol in this case is different from the one in Section 5.4.6 and we will explain it later in this section.
• GCS.SignVerify : This stage is a Sign/Verify protocol (this corresponds to the V erif ign algorithm in Section 5.4) that runs between verifier V and member Ui
as follows:
1. V chooses a Γ and collects all public key bases it needs ¯B = (bpk1, ..., bpkκ).
6.2. The General Construction 6. General Construction
(D1, ..., Dκ) = T Create(Γ, α, B) as shown in Section 5.2 and sends the val-
ues together with Γ to Ui.
2. Uiin this stage runs the AAS signature algorithm by first calculating GSσ =
SGS.Sign(M, bsk[i], Spub). Ui picks β ∈RZ∗pand calculates ¯T = {CT1, CT2,
..., CTτ} where CTj = Ti,jβ. These values enable Ui to run the algorithm
T V erif y(D, =i, ¯T ) = Froot as done in Section 5.2. Ui assigns td = Aβi.
Ui calculates T K = GS.Sign(Froot, bsk[i], Spub) and L = e(td, H2(bsk[i])).
The signature is σ = (GSσ, T K, Froot, td, L) and is sent to the verifier.
3. V in this stage runs the AAS verification algorithm. V starts with verify- ing GS.σ using the algorithm GS.V erif y. He can verify the attributes by checking Froot1/α = e(td, w). V verifies the signature on Froot whether it is
valid or not. If all three hold then output accept signature otherwise reject it.
We shall point out that L and T K are meant for tracing a signature as shown later. The element T K will be used as a proof that verifier V used a random element α on the signature. This kind of proof will be useful in the opening algorithm.
• GCS.Open : First step is to verify the signature σ. Note that verifier can not manipulate α because it is inbuilt in Froot which the signer agreed on by signing
it in T K. Second step is to run the GS.Open on GS.σ that will identify the member. Finally, check whether L = e(td, H2(bsk[i])) of the user where H2(bsk[i])
is retrieved from T .
Simple Conversion Method: The purpose behind adding the hash functions H1, H2
and the element L in the construction above is to convert any private key and public key to generators that belong to groups G1, and G2. This enables using the bilinear
maps and reserves the possibility of tracing to a user. In case the private key and/or the public key are already generators then there is no need to add all these elements (See example in Section 5.4). We can assume that our hash function Hb(g) = gsomething,
where b ∈ {1, 2} and g ∈ Gb.
Attribute Private Key Protocol (ASK): Earlier we described the procedure of obtaining attribute private keys as the algorithm A.KeyGenpri(Ai, j). This can be
replaced with a protocol that runs as follows:
1. The attribute authority may want to verify some information about the member before giving him an attribute.
2. The member Ui and the attribute authority AAj run the protocol
V erif ign(Ui(gsk, M ), AAj(M, ¯B)).
3. From the V erif ign protocol AAjobtains the signature σ = (GSσ, T K, Froot, td, L).
4. AAj can verify the signature and if it is valid AAj sends td1/tj back.
5. Ui can calculate his attribute private key Ti,j = (td1/tj)1/β.
6. Ui verifies Ti,j is correct by checking e(Ti,j, bpkj) = e(Ai, w).
Note that the attribute authority does not know the attribute private key of the user since it does not know β. This protocol and the APK protocol (explained in Sec- tion 5.4.6) will guarantee honesty in the generation of the attribute keys. The following section will prove full anonymity and traceability of the scheme.