The identity-based cryptosystem (IBC) is a special kind of asymmetrical cryptosystem known as public key system. Public key cryptosystems are frequently applied in areas related to data security such as e-commerce. For further readings on these systems refer to [5, 25, 26]. Traditional public key cryptosystems need public key infrastructures (PKI). In PKI, verification of a public key and its use is performed by two separate algorithms, whereas in an IBC, it is performed by one algorithm. Now, we will take a more detailed look at these issues. To verify validity of a user's public key, a trusted third party (TTP) is needed. The TTP verifies the relation between the public key and the user's identity. This section has a different role in the IBC systems compared with the PKI systems. In the PKI systems, the TTP is a certificate authority (CA). Receiving the user's identity and public key, the CA ensures that the identity is really the user's and whether she/he knows this public key's corresponding private key. This way, the CA identifies the user. If the verification is performed successfully, the CA issues a certificate by its own private key that includes a signature on the user's public key and identity. Everybody, using the CA's public key, can verify each user's certificate. In the IBC system, the TTP is a key generation center (KGC). Receiving the user's identity, the KGC needs only to ensure that the identity is really the user's. If the verification is performed successfully, the KGC produces the user's private key by combining his/her identity and the public key. This characteristic leads to favorable results such as a non-pre-interactive relationship between the two sides of a protocol, encryptor and decryptor. For example, assume that Alice wants to send a secure email to Bob's email address, that is, Bob@iust.ac.ir; to do so, Alice encrypts the message using Bob's public key, that is, his identity Bob@iust.ac.ir and sends it to him. Pay attention to the fact that Alice does not need to find Bob's public key certificate (and this is a characteristic of IBC systems). To decrypt the encrypted email he has received, Bob has to prove his ownership over the email (identity) to the KGC and so be identified by it. If Bob is verified, the KGC will send Bob's private key to him through a secure channel, and so, Bob can decrypt the message. Note that this is exactly against secure email based on PKI, that is, Alice can send Bob the encrypted email even if Bob does not have his private key yet. Also, Alice can choose any of Bob's meaningful information such as his picture, phone number, or postal address as the public key. Moreover, she can introduce any TTP as KGC.
Another shortcoming of IBC systems is the key escrow and also KGC's ability to forge the users' identities. Obviously, KGC knows the user's private key and so can forge their identity; for example, it can sign a message instead of him/her. A similar problem exists in the PKI. A CA can issue a pair of keys and certificates (unreal ones) for the public key. Now, CA can forge the user's identity. Anyway, in the PKI, this problem is solved by adding an extra process. But, this problem is inherent in the IBC, and many researches are being performed to solve it. In 2003, to solve this problem, Al-Riyami and Paterson [1] succeeded in introducing a new method which removed this shortcoming of IBC identified by Boneh and Franklin [5]. In this method, like the previous identity-based methods, there is no need to give certificates, and on the other hand, the KGC cannot threaten the security with key escrowing and forging the users' identities. For more information on these schemes see [2, 4, 10, 34], and for attacks on them, refer to [15]. In this article, we introduce two identity-based identification schemes of the challenge–response type that have the property of zero-knowledge proof. In addition, the second scheme has the batch verification property. It means that when executing a protocol once, the verifier can check more than one identity. Also, these schemes are resistant against key escrow and KGC's impersonating the users. For further readings regarding the concepts of zero-knowledge proof and identification schemes' security, see respectively [18, 19] and [3, 29, 30]. For further readings on certificateless cryptography, see [7, 8, 11, 20, 22, 31, 35-37]. The article goes on with some mathematics and cryptography preliminaries. In section 3, the proposed schemes are introduced. In section 4, computational complexities of the aforementioned schemes are computed. In section 5, we examine security of the mentioned schemes and in section 6, the improvements are considered and finally the conclusion comes at the end.
Here is the paper's list of abbreviations (Table 1).
Table 1. Definitions of mathematical notations.
KGC, key generation center.
Elliptic curve
E
Big prime numbers
p, q
Finite field
F_{r}
Elliptic curve group
E(F_{r})
Order of Elliptic curve group
# E(F_{r})
n-torsion set
E[n]
Hash function
H
Cyclic subgroup of E(F_{r}) with order q
G_{1}
Cyclic subgroup of F_{r}* with order q
G_{2}
Generator point G_{1}
P
Pairing
e
User's identity
ID_{A}
Key Generation Center
KGC
KGC's private key
s
KGC's public key
P_{pub}
KGC's generated private key for user
S_{A}
Point corresponding with user's identities
Q_{A}
Private keys generated by user
a
Public keys generated by user
P_{A,KGC}
Random values produced by user during the protocol
d
Reply signature sent by user to center
Y
Computed by user for sending center
S
2 PRELIMINARIES
Definition 1. Assuming E is defined over F_{r}, when r is an exponent of the prime number p, the set E[n] = {Q ∈ E(F_{r}) | nQ = ∞} is called an n-torsion set.
Definition 2. The elliptic curve E over the field F_{r} with the characteristic p is called super singular curve when this equation holds: E[p] = {∞}.
Theorem 3. Assuming E is defined over the field F_{r}, when r is an exponent of the prime number p; let a¯=r+1−#EFr, then we have
E is super singular if and only if a¯≡0modp and if and only if # E(F_{r}) ≡ 1(mod p).
Assuming E with the equation y^{2} = x^{3} + 1 is defined over F_{r} when r = 2(mod 3), therefore E is super singular. w∈Fr2 is considered as the third root of unity. Because w's order does not divide Fr* order, therefore, w ∉ F_{r}. Now, we consider the isomorphism of ∅:EF−r→E(F−r)xy→(wx,y) and ∅ (∞) = ∞. Note that the order of the points P and ∅ (P) is the same.
Definition 5. Assuming q and p are two prime numbers and q|p^{2} − 1 and assuming G_{1} and G_{2} are two cyclic groups of the order q when G_{2} is a subgroup of Fp2*, the modified Weil pairing is this map e : G_{1} × G_{1} → G_{2} with the following characteristics:
Bilinear: e(aP,bQ) = e(P,Q)^{ab} for all P, Q ∈ G_{1}, a, b ∈ Z_{q};
Non-degenerate: There exists P, Q ∈ G_{1} such that e(P,Q) ≠ 1;
Computable: There is an efficient algorithm to compute e(P,Q) for all P, Q ∈ G_{1}
For example, if e˜:Eq×Eq→G2 is a Weil pairing, then ePP=e˜P,∅P, with ∅ as a map defined previously. For further readings on the mentioned concepts, refer to [14, 18, 21].
3 THE PROPOSED SCHEMES
Every identity-based protocol has three phases of setup, key extract, and the needed algorithm (identification). Our schemes (A, B) also have these three stages, which in this part we elaborate on.
3.1 Scheme A
3.1.1 A.1 Setup phase
In this stage, the KGC chooses the prime number p in a way that p = 2 mod 3 and p = 6q − 1, so that q is also a prime number. Let E be a super singular elliptic curve with the equation y^{2} = x^{3} + 1 over the field F_{p}; now, considering the point P ∈ E(F_{p}) with the order q, suppose G_{1} is the subgroup generated by P and G_{2} is a cyclic subgroup of Fp2* of the order q. Let e : G_{1} × G_{1} → G_{2} as the modified Weil pairing and then the hash function H : {0,1}* → G_{1} is selected. Now, KGC selects the random number s∈Zq* and computes its public key as P_{KGC} = sP. The number S is considered as the KGC's private key. The KGC makes the general values of {G_{1},G_{2},P,P_{KGC},H,e,q,p} available to the users.
3.1.2 A.2 Key extract phase
In this stage, the KGC first computes the values of Q_{A} = H(ID_{A}) and S_{A} = sQ_{A} and then sends the value of S_{A} as the private key of the user with the public identity ID_{A} through a secure channel. To verify this private key, the user controls the relation e(P,S_{A}) = e(P_{KGC},Q_{A}). Going on with this stage, the user selects the random value of a∈Zq* and computes P_{A,KGC} = aP_{KGC} = asP to produce his own private key.
3.1.3 A.3 Identification phase
In this stage, we present our proposed certificateless identification scheme. Now, the center and the user do as follows:
Commitment: The user arbitrarily chooses the value b∈Zq* and computes the point S = bQ_{A} and sends it to the center.
Challenge: The center randomly selects the value d ∈ {1, ⋯,2^{t}} so that 2^{t} < q and sends it to the user.
Response: The user computes the value Y = (b + da)S_{A} and sends the points Y and P_{A,KGC} to the center.
Verification: The center accepts the user's identity if and only if
ePY=ePKGCSePA,KGC,HIDAd(1)
=ePKGCSedPA,KGC,HIDA(2)
As it is clear, the verification relation depends on the user's public identity.
Lemma 6. The previous scheme has the completeness property.
Proof. We prove that an honest verifier is able to verify a legitimate user.
Lemma 7. The previous scheme has the soundness property.
Proof. We show that forging user's identity is equal to knowing (or the ability to compute) user's hidden values. Obviously, anyone having the user's hidden values (private keys) can forge his/her identity. Now, we show its opposite is also true. Assuming the cheater has succeeded in the forgery at least twice; therefore, with the values (Y_{1},d_{1}) and (Y_{2},d_{2}), which are true in the verification relation, he has cheated the verifier. So, using these relations we have
Y1=b+d1aSAY2=b+d2aSA⇒Y2−Y1=d2−d1aSA.
Because q (order of G_{1}) is prime, therefore, gcd(d_{2} − d_{1}, q) = 1 and so (d_{2} − d_{1})^{− 1} mod q exist. So, we have (d_{2} − d_{1})^{− 1}(Y_{2} − Y_{1}) = aS_{A}.
The previous relation shows that forging twice is equal to knowing the user's hidden values (or the ability to compute them). Regarding
It is clear that anybody having the value aS_{A} can forge the user's identity and cheat the verifier.
3.2 Scheme B
In the previous scheme and many identification schemes such as in [9, 12, 13, 17, 23, 24, 27, 28, 33], the user, to have his/her k identity(s) verified by the verifier, has to execute the assumed protocols k times. This increases the expense and decreases the speed of the protocol. To solve this problem, we introduce a protocol which by executing it only once the verifier can check the user's k identity(s). Therefore, many shortcomings of the mentioned schemes can be removed.
3.2.1 B.1, 2 Setup and key extract phases
The setup and key extract stages are like those of the previous scheme only in the key extract stage; the user with the identity set IDA1,⋯,IDAk obtains the private keys corresponding with each identity, that is, SA1=sHIDA1,⋯,SAk=sHIDAk=sQA1,…,sQAk from the KGC. To verify his/her private keys for 1 ≤ i ≤ k, the user checks ePSAi=ePKGCQAi. Before executing the protocol, the user computes Q−A=∑i=1kQAi (the sum of the public keys) and S−A=∑i=1kSAi (the sum of the private keys).
Note 8: To increase speed and decrease computations, the user can make use of this equation ePS¯A=ePKGCQ¯A to verify all his/her private keys at the same time. This way, instead of computing 2k pairings, only two pairings are computed.
3.2.2 B.3 Identification phase
Now, the center and the user do as follows:
Commitment: The user chooses the random number b∈Zq* and computes the point S−=bQ−A and sends it to the center.
Challenge: The center selects the random number d ∈ {1, ⋯,2^{t}} so that 2^{t} < q and sends it to the user.
Response: The user computes Y=b+daS−A and sends the points Y and P_{A,KGC} to the center.
Verification: The center accepts the user's identity if and only if these equations hold.
ePY=ePKGC,S−edPA,KGC,∑i=1kHIDAi(3)
=ePKGC,S¯ePA,KGCQ¯Ad(4)
=ePKGC,S¯∏i=1kePA,KGC,HIDAid(5)
Lemma 9. This scheme has the completeness property.
Proof. We show that an honest verifier (the center) can verify a legitimate user.
Proof. We show that impersonating a user means knowing his/her hidden values (or the ability to compute them). Assuming a person succeeds in forging the user's identity, she/he has successfully executed the protocol at least twice with the values (Y_{1},d_{1}) and (Y_{2},d_{2}), thus, we have
The previous relations show that anybody doing the protocol successfully twice can compute the value aS−A (user's hidden values). It is clear that anybody having the value aS−A can forge the user's identities and cheat the verifier.
4 COMPLEXITY
Note 11: To increase efficiency and decrease the needed computations in the verification stage, we can modify the previous protocols with slight changes in a way that the user does more computations. It will be as follows.
After the challenge stage, when the user receives d, she/he computes the value dP_{A,KGC} and then sends it to the center along with other values in the response stage. Then, the center, in the verification relations, will not need to do d exponentiation. Therefore, in the verification relations instead of relation (1), we will use relation (2), and instead of relations (4) and (5), we will use relation (3).
Here is a brief account of the needed computations for each stage of the previous protocols.
Setup: one scalar multiplication in G_{1}.
Key generation: one scalar multiplication in G_{1}, one hash function.
Key verification: two pairings, one multiplication in G_{2},
Commitment: one scalar multiplication in G_{1}.
Response: one scalar multiplication in G_{1}, one multiplication and one addition in G_{2}.
Verification: In the first protocol, if relation (1) is used, then three pairings, one exponentiation, and one multiplication in G_{2}. If the relation (2) is used, then three pairings and one multiplication in G_{2}.
In the second protocol, if the relation (3) is used, then three pairings, k hash function(s), k − 1 addition(s) in G_{1}, one multiplication, and one exponentiation in G_{2}. If the relation (5) is used, then k + 2 pairing(s), k hash function(s), k multiplication(s), and one exponentiation in G_{2}.
Lemma 12. The verification relation of the user's private key in the key extract stage in both mentioned schemes has the completeness property.
Proof. We show that a legitimate user verifies his/her authentic private key made by the KGC using the relation e(P,S_{A}) = e(P_{KGC},Q_{A}). Thus, for example, in the first scheme, we have
ePSA=eP,sQA=esPQA=ePKGCQA
Now, we show that the verification relation represented in (Note 8) has the completeness property.
Lemma 13. Both schemes introduced in this article have the zero-knowledge proof property.
Proof. We show that any information issued from the user does not lead to revealing his/her hidden values. The user's not-to-be-revealed hidden values (private keys) are the values {a, S_{A}, aS_{A}} for the first scheme and the values a,SA1,⋯,SAk,S−A,aS−A for the second. In case any of the previous values is disclosed (to the verifier), the scheme will not be zero-knowledge proof. The public values available to the verifier are {P,P_{KGC},P_{A,KGC},Y}. The values {S,Q_{A}} in the first scheme and S−Q−A in the second scheme are also available to the verifier. Now, we see that to find the private values using the previous values, the verifier needs to solve the discrete logarithm problem in the elliptic curves group. Now, regarding the relation Y = (b + da)S_{A} in the first scheme and Y=b+daS−A in the second scheme, and also that, the verifier is not aware of the values {S_{A},(b + da)} in the first scheme and S−Ab+da in the second scheme, the verifier cannot extract the hidden values from Y. Therefore, these schemes have the zero-knowledge proof property.
Lemma 14. In both schemes introduced in this paper, the user must not use a fixed value of b; otherwise, the needed values to impersonate him/her will be available to the verifier.
Proof. If the user uses a fixed value of b in the commitment stage, the verifier can find his/her hidden values by sending two sequential values of d and subtracting the user's sent values. For example, in the first scheme, we have
Y1=b+daSAY2=b+d+1aSa⇒Y2−Y1=b+d+1aSA−b+daSA=aSA
Thus, the verifier finds the value aS_{A}, and as a result, the protocol loses its zero-knowledge proof property.
6 ANALYSIS OF THE ACHIEVED IMPROVEMENTS
It is worth noting that to do a brief comparison between these schemes and other existing identification schemes, we have to consider that, according to what was said, the shortcoming of many identification schemes such as in [6, 9, 10, 12, 13, 16] is their basic dependence on the authentic certificate and its infrastructures (PKI). Although, the identity-based schemes such as in [5, 25, 26] have somehow modified this problem, they still have other shortcomings such as key escrow or the key generating center's ability to forge identities. The schemes represented here try to modify these weak points this way: in addition to being identity-based (to solve the certificate problem), in our protocols, the user generates a private key (to solve the problem of their entire reliance on KGC). Because the private key produced by the user is kept only by him/her and without his/her knowledge, nothing can be done. Moreover, in the second protocol, the verifier's ability to verify all identities of the user at the same time makes it more advantageous over the previous schemes. This characteristic increases speed and efficiency and decreases both computations and transmitted values between the two sides of the protocol. Of course, two similar schemes (with batch verification) are introduced in [10, 16], which have some weak points such as dependence on the certificate and not being based on identity. In the schemes proposed here, these shortcomings are also removed. Some comparisons are manifested in Table 3.
Table 3. Efficiency comparison among our proposed schemes and related schemes.
Index of schemes
Type of identification
Batch verification
Identity-based
Secure against key escrow
27-13-12-9-6
Certificate-based
×
_
_
10-16
Certificate-based
√
_
_
17
Identity-based
_
√
_
33-28-24-23
Certificate-based
×
_
_
25
Identity-based
_
√
_
Our scheme A
Certificateless
_
√
√
Our scheme B
Certificateless
√
√
√
7 CONCLUSION
In this paper, we introduce two certificateless identification protocols, which are based on people's public identities such as their email addresses. These protocols are secure against the KGC's impersonation and the key escrow. In addition, the second scheme has the quality to verify all identities of the user in doing the protocol only once. Therefore, our schemes compared with many existing identification schemes have a meaningful supremacy. Moreover, they have the zero-knowledge proof property.