Previously, in the game models of full anonymity and traceability, we assumed the attribute authority is dishonest by giving Adam the privilege of creating the master keys in the initialization stage of the games. However, in real life, we need the signer to be able to verify that the attribute private keys he obtains are valid and will help in signing. Furthermore, he needs to verify that the attribute public key is accepted by everyone in the system as valid verification keys.. In this section we add two further protocols which will help establish that. We start with defining what we mean by “Honestly Generated Attribute Keys”.
Definition 5.4.9. (Honestly Generated Attribute Public Keys): The public attribute key is “generated honestly” if the attribute authority can not produce it or change it without the knowledge of the central authority.
Definition 5.4.10. (Honestly Generated Attribute Private Keys): The private at- tribute key is “generated honestly” if the member can verify its correctness with an honestly generated public attribute key and the members’ registration key.
To improve our scheme we add two protocols the APK and the ASK. We start with defining these protocols and then we explain how these protocols work with our con- struction in Section 5.4.3. The protocols are defined as follows:
• APK(CA : AAj): This protocol runs between the attribute authority AAj and
the central authority CA. It takes no input since all calculations are done by choosing random elements. At the end of the protocol the central authority should obtain bpkj and the attribute authority should obtain tj.
5.4. Attribute Authentication Scheme 5. Attribute Authentication Schemes
• ASK(AAj(tj) : Ui(gsk)): This protocol runs between the attribute authority
AAj and the user Ui. The inputs are the master key of the attribute tj and the
users private key gsk. At the end of the protocol the attribute authority should have authenticated the user and the user should get Ti,j without revealing the
registration key Ai to AAj.
Attribute Public Key Exchange Protocol (APK): This protocol is between the central authority CA and attribute authority AAj. It authenticates the attribute au-
thority to the central authority. It guarantees that the attribute authorities generate the master key honestly. Therefore we replace the A.KeyGenpub algorithm with a in-
teractive protocol. This protocol is a 6-move key generation protocol adopted from Groth’s work in [70]. The procedure is as follows:
1. AAj picks a random a, b ∈ Z∗p and c ∈ Z∗p. AAj then sends A = wa, B = wb, and
C = wc to CA.
2. CA picks d, e ∈ Z∗p and sends DE = wdCe to AAj
3. AAj picks f ∈ Z∗p and sends it to CA.
4. CA sends e, d to AAj.
5. AAj checks DE = wdCe. If the check passes calculate tj = a + d + f . Then send
z = (d + f )a + b mod p and c to CA.
6. CA checks C = wc and Ad+fB = wz and output bpk
j = Awd+f.
Note that our scheme does not deal with the honesty of the AAj but it guarantees
honesty when generating the master key. We will assume some form of standard au- thentication occurred before the protocol started. Therefore throughout this protocol our CA is agreeing on the master key used by the AAj but without revealing the key.
Attribute Private Key Exchange Protocol (ASK): This protocol is between the attribute authority AAj and a member of the group Ui. The purpose behind the
protocol is to authenticate the member before giving him a private attribute key. Ear- lier we described the procedure for obtaining attribute private keys by explaining the algorithm A.KeyGenpri. This can be replaced with the ASK 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)) where the value of M is not significant to the
protocol and can be any random message.
3. From the V erif ign protocol AAj obtains the signature,
σ = (r,C1,C2,C3,C4,c,sξ,sx,sδ).
4. AAj attempts to verify the signature. If it is valid AAj sends E = C 1/tj
2 and F =
v1/tj back. Note that v is known to AA
j because r is known (See Section 5.4.3).
5. Uicalculates his attribute private key Ti,j = E/Fξ = C 1/tj 2 /vξ/tj = (A 1/tj i vξ/tj)/vξ/tj = A1/tj i .
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 can not calculate it from C2. It also does not know the registration key either
because it is coded in C2.
Protocols ASK and APK ensure that Definition 5.4.9 and 5.4.10 holds.
Claim 5.4.11. The ASK protocol ensures honesty of the attribute private key gener- ation as defined in 5.4.10 and APK protocols ensures honestly of attribute public key generation as defined 5.4.9.
We prove the claim in two steps. Step one is to prove the attribute public key is gen- erated honestly and the second step is proving that attribute private key is generated honestly. To generate the attribute public key we used the APK protocol. This pro- tocol has perfect correctness and assuming the discrete logarithm problem is hard it is possible to black box simulate both the AAj and CA. The reader is referred to [70] for
the full proof.
This leaves us with proving the private attribute key is generated honestly. Creating this key was achieved using the ASK protocol between Ui and AAj. Assuming that
the AAS scheme is fully traceable, and σ obtained in the third step of the protocol (V erif ign) verifies, then the pair (C2, v) must be created honestly. AAj calculates
C1/tj
2 , v1/tj which is impossible to do without the value of tj. In the sixth step of the
protocol Ui verifies that tj used in calculating Ti,j is the same as tj used in calculating
bpkj. Ui can trust that bpkj was created honestly using the APK protocol. Therefore
he can trust that Ti,j is honestly created too.
5.5
Phase III: Dynamic Attribute Based Authentication
Schemes
A Dynamic Attribute based Authentication Scheme (DAAS) is an improved AAS scheme. In our previous design of an AAS scheme the attribute authorities were not