Abstract
In this paper, we propose a certificateless noninteractive key exchange protocol. No message exchange is required in the protocol, and this feature will facilitate the applications where the communication overhead matters, for example, the communications between the satellites and the earth. The public key certificate is removed as well as the key escrow problem using the certificateless public key cryptosystem. The security of the protocol rests on the bilinear Diffie–Hellman problem, and it could be proved in the random oracle model. Compared with previous protocols, the new protocol reduces the running time by at least 33.0%.
1. Introduction
Noninteractive key exchange (NIKE) protocols enable two users to establish a shared key without any interactions. In a NIKE, every user puts up his public key in a public directory, and two users can set up a shared key with the other’s public key and his own private key [1]. The earliest example of NIKE is Diffie–Hellman key exchange proposed in the seminal paper of [2]. In the protocol, Alice and Bob share a common group of order with generator . Alice’s public key is of the form , and Bob’s public key is of the form . Then, Alice and Bob can establish a shared key without any communications. NIKE is very useful to secure the communications where the communication delay matters, for example, the communications in the wireless networks where two terminals are far away from each other. Another example is the communication between the satellite and the earth. The distance between the satellite and the earth will increase the running time of a security protocol dramatically, and a NIKE protocol will reduce the protocol delay to the minimum because no interaction is needed between the earth and the satellite [3]. With NIKE protocols, two participants can establish a key and sends encrypted message to its peer right away [4, 5].
Similar to NIKE protocols, public key encryption can also realize noninteractive communications. However, there are differences between the two. In a public key encryption system, anyone who wants to send the receiver Alice an encrypted message, only needs to know Alice’s public key and the system parameters. In a NIKE system, both parties should be enrolled in the system and have their private keys in order to establish a shared key. Furthermore, the encryption algorithm in a public key system is much slower than the encryption algorithm in a NIKE system because the latter could use the symmetric encryption algorithm once the shared key is set up.
In this paper, we propose a noninteractive key exchange protocol based on certificateless public key cryptosystem. The security of the protocol is based on the bilinear Diffie–Hellman problem. Our contributions are mainly as follows:(1)A noninteractive key agreement protocol is proposed based on the certificateless public key cryptosystem.(2)The security model of NIKE protocols in the setting of certificateless public key cryptosystem is studied.(3)The security of the proposed protocol is proved formally using the security model of NIKE protocols.(4)The computation efficiency of the proposed protocol is improved compared with the available NIKE protocols.
The remaining part of this paper is organized as follows: Section 2 provides a research on the related work of NIKE protocols; Section 3 introduces the preliminaries, security definition, and security model; in Section 4, we introduce our scheme; Section 5 gives the security proof of our scheme. Section 6 gives the performance comparison; and Section 7 concludes the paper.
2. Related Works
According to the cryptosystems underlined, available NIKE protocols can be divided into three categories, i.e., certificate-based ones, identity-based ones, and certificateless ones. Certificate-based NIKE protocols employ the traditional certificate-based cryptography. Diffie–Hellman’s noninteractive key exchange scheme falls into this category. In 2006, a certificate-based NIKE protocol was proposed using an elliptic curve [6], and a PKI-based security model was given. Later, Cash et al. proposed a stronger security model for NIKE, and a NIKE protocol using the twin Diffie–Hellman problem was also proposed [7]. In 2013, Freire et al. provided different security models for NIKE and studied the relationship between different security models. They also gave two NIKE constructions with provable security [8]. Hesse et al. proposed a NIKE with tight security reduction in [9].
In 1991, Maurer and Yacobi proposed an identity-based NIKE protocol based on a one-way trapdoor function [10]. However, it was pointed out that Maurer and Yacobi’s scheme was weak in security [11]. Later, Maurer and Yacobi improved their protocol [12], but the scheme was still proven insecure [13]. In 2000, Sakai et al. [14] proposed an ID-based NIKE protocol by introducing the bilinear pairings, but there were no formal security proofs. Dupont and Enge extended Sakai et al.’s scheme to a more general case and provided a security model for ID-based NIKE [15]. Paterson and Sirinivasan studied the relationship between ID-based NIKE and ID-based encryption and proposed an ID-NIKE scheme [16] and a security model stronger than Dupont and Enge’s model. An improved ID-NIKE with forward secrecy is proposed in [17].
To remove the inborn issue of key escrow with ID-based cryptosystem, Al-Riyami and Paterson proposed the certificateless cryptography [18]. In certificateless cryptography, a user’s private key is generated both by the key generation center (KGC) and the user. Since, in the private key, there is a portion which is unknown to KGC, certificateless cryptography removes the key escrow problem. Compared with ID-based cryptosystem, certificateless cryptosystem maintains the former’s strength of lightweight public key management while achieves an improved level of security. Even the security authority is unable to know the secret established. In 2014, Sang et al. proposed a certificateless NIKE (CL-NIKE) protocol [19]. Later, Fu and Liu proposed another CL-NIKE protocol [20]. However, neither of the two protocols provided integrated security proof.
3. Preliminaries and Security Models
3.1. Preliminaries
Let be an additive group of order , where is a large prime, and be a multiplicative group of the same order. Let be an arbitrary generator of ; then, a bilinear pairing is a map satisfying the following properties:(1)Bilinearity: given and , we have .(2)Nondegeneracy: given a generator of , then is a generator of .(3)Computability: is efficiently computable for all .
The following problem is assumed intractable in polynomial time [18]: bilinear Diffie–Hellman problem (BDHP): given for unknown , compute .
3.2. Security Definition
In this section, we present the definition of CL-NIKE. A CL-NIKE scheme is defined by the following six algorithms:(1)Setup: this algorithm is run by the KGC once at the beginning to set up a certificateless key agreement system. It takes security parameter and returns system parameters and the master key of KGC master-key. are publicly authentically available, but the master-key is known only to the KGC.(2)Partial-private-key-extract: the algorithm generates the partial private key for system users. It is run by the KGC. It takes , master key, an entity ’s identifier , and outputs ’s partial private key . KGC sends to via a secret channel.(3)Set-secret-value: the algorithm is run by an entity . The algorithm returns ’s secret value .(4)Set-private-key: the algorithm is run by . It takes and and returns ’s private key .(5)Set-public-key: the algorithm is run by . It takes and and returns ’s public key .(6)Shared-key: on input , ’s identifier and private key , and entity ’s identifier and public key , this algorithm outputs a shared key between and .
3.3. Security Model
CK model [21] and eCK model [22] are the most widely used security models for authenticated key exchange (KE) protocols. However, they are not suitable for noninteractive key exchange protocols because CK model and eCK model provide security analysis to ephemeral secrets [23] but no ephemeral secrets are used in NIKE protocols. Therefore, a NIKE protocol needs its own security model.
Bernstein [6] and Cash et al. [7] first proposed the security models for NIKE protocols, respectively. Later, Dupont and Enge [15] and Paterson and Srinivasan [16] extended the security models in [6, 7] from the certificate-based cryptosystem to the ID-based cryptosystem. Paterson’s security model is stronger than Dupont’s security model because Paterson’s model considers the security against the known session key attack by allowing the reveal query in the security model. Our security model follows Paterson’s model in [16]. Furthermore, we extend Paterson’s security model from ID-based cryptosystem to certificateless cryptosystem. Our security model considers the particular public/private key setting in the certificateless public key cryptosystem, and the case where an attacker replaces the legal user’s public key, and the case where the malicious KGC wants to break the shared key.
Now we define our security model of CL-NIKE protocols.
There are two types of adversaries to a CL-NIKE protocol, i.e., type I adversary and type II adversary . Type I adversary simulates the ordinary attacker who is not able to get a user’s partial private key but is able to replace a legal user’s public key. is able to do this because there is no public key certificate in a CL-NIKE. Type II adversary simulates the malicious KGC who owns the system master key and hence knows every user’s partial private key but cannot replace the legal user’s public key because that is easily detected and could destroy KGC’s reputation. Consider two games, game I and game II between a challenger and and , respectively. The security of a CL-NIKE protocol is defined via the two games: Game I: the game is between and . Setup phase: in this phase, given security parameter , challenger obtains the system parameters and master key. gives to while keeps the master key secretly. Query phase: in this phase, the adversary can carry out the following queries in any order, and will answer the queries.(1)Partial private key extraction: chooses an entity with identifier and queries user ’s partial private key. runs the Partial-Private-Key-Extract to generate the partial private key and returns it to .(2)Secret value extraction: after receiving the query, runs the Set-Secret-Value algorithm and returns to .(3)Private key extraction: will call Partial-Private-Key-Extract and Set-Secret-Value in this query to obtain and , and then, runs Set-Private-Key on and to generate the private key .(4)Public key request: first runs Set-Secret-Value and keeps for itself. Then, runs Set-Public-Key to generate ’s public key and returns it to .(5)Public key replacement: will replace the public key of an entity with any value of its choice.(6)Shared key revealing: suppose the query is on and , obtains and , then runs Shared Key to obtain the between and and returns it to . Test phase: given a pair of identities and , obtains as above. Then, selects at random and returns when and when . is the length of the shared key. Finally, outputs its guess , and will win the game if . ’s advantage in the game is We say the CL-NIKE scheme is secure against if is negligible. Game II: the game is between and . Setup phase: in this phase, given security parameter , challenger obtains the system parameters and master key. gives both and master key to . Query phase: since has master key, it can compute the partial private key of any user. Then, in this phase, does not make the partial private key extraction query. Also, since is not allowed to replace the user’s public key, it does not make the public key replacement query. In game II, makes the queries and answers as follows:(1)Secret value extraction: on receiving the query on , runs the Set-Secret-Value and returns to .(2)Private key extraction: if user ’s partial private key has not been computed, first computes ’s partial private key using master key, then it calls the Set-Secret-Value to obtain . At last, runs the Set-Private-Key to obtain user ’s private key and returns it to .(3)Public key request: on receiving this query, first runs Set-Secret-Value to obtain and then it runs Set-Public-Key to obtain the public key and returns it to .(4)Shared key revealing: suppose this query is made on and . runs corresponding algorithms to obtain the and , and then, it computes by running the SharedKey and returns to . Test phase: given a pair of identities and , obtains as above. Then, selects at random and returns when and when . is the length of the shared key.
Finally, outputs its guess , and will win the game if . ’s advantage in the game is
We say the CL-NIKE scheme is secure against if is negligible.
A CL-NIKE scheme is secure if it is secure both against and .
4. Protocol Description
In this section, we propose a new CL-NIKE protocol. The new protocol includes six algorithms, as described in Section 3.2, and each algorithm is as follows:(i)Setup: given system security parameter , KGC does the following:(1)Outputs satisfying the definitions in Section 3.1.(2)Chooses an arbitrary generator of .(3)Selects the master key at random and computes the system public key .(4)Selects two hash functions and .(5)Publishes as system parameters and keeps secretly.(i)Partial-Private-Key-Extract: given a user ’s identifier , KGC computes and . is ’s partial private key. KGC returns to via a secure channel.(iii)Set-Secret-Value: selects at random and sets as his secret value.(iv)Set-Private-Key: ’s private key is .(v)Set-Public-Key: computes and and his public key is .(vi)SharedKey: to set up a shared key with , first verifies whether ’s public key is of the correct form, i.e., verifies if the equation holds. If the verification is correct, computes the shared secrets:
The shared key is
To compute the shared key, first verifies ’s public key by checking if the equation holds. If the verification is correct, computes the shared secrets:
The shared key is
The correctness of the protocol could be guaranteed because
The procedure of the SharedKey algorithm is illustrated in Figure 1.
5. Security Proof
In this section, we prove the security of our protocol in the random oracle model based on the security model in Section 3. We have the following theorem:
Theorem 1. If BDH problem is hard, our CL-NIKE protocol is secure in the random oracle model.
The theorem can be proven via Lemma 1 and Lemma 2.
Lemma 1. If there exists a type I adversary which wins game I against our CL-NIKE protocol, then BDH problem can be solved with nonnegligible probability in the random oracle model.
Proof. Suppose a challenger is given an instance of and is tasked to compute . If there is a type I adversary which wins the game I against the proposed protocol, then can solve the BDH problem by controlling the queries with .
In the setup phase, chooses the system parameters , and sets the system public key with the master-key unknown to .
In the query phase, hash functions and are modeled as random oracles. Without generality, we suppose that there are users in the system, and chooses and in the test phase. We also suppose is allowed to ask queries. During this phase, answers every query as follows:(1) query: ’s query is of the form . maintains an -list with each entry of the form . On receiving ’s query, first searches -list whether there is an entry indexed by . If there is, returns to . If there is not, the following holds:(a)If , inserts in the list and returns to .(b)If , inserts in the list and returns to .(c)If , chooses at random , returns to , and inserts to the -list.(2) query: ’s query is of the form . maintains an -list with each entry the form . On receiving ’s query, first searches -list whether there is an entry indexed by . If there is an item indexed by , returns the corresponding to . Or else chooses at random , returns to , and inserts to -list.(3)Partial private key extraction: maintains a -list of user’s keys. -list is of the form . are ’s private key, and are ’s public key. If , it means that ’s public key has not been replaced. If , it means that ’s public key has been replaced, and the corresponding is the replaced ones. On receiving ’s query on , checks -list; if there is an entry indexed by and , returns the corresponding . If no entry indexed by or , does the following:(a)If , checks -list with for . If there is no entry indexed by in -list, first makes query. Then, computes . If no entry is indexed by in -list, inserts to it; if there is an entry indexed by but in -list, only inserts . Finally, returns to .(b)If , aborts the game.(4)Secret value extraction: on receiving such a query on , checks the -list. If there is an item indexed by and , returns to . If there is not an item indexed by or , runs the Set-Secret-Value algorithm to obtain . If there is not an entry indexed by , adds in the -list. If there is an entry indexed by but , only adds to the entry. Finally, returns to .(5)Private key extraction: the query is on . If , aborts the game. Otherwise, checks the -list. If there is an item indexed by , , and , returns to . If there is not such an item or if there is an item indexed by , but at least one value of and equals , according to the value needed, runs Set-Secret-Value to obtain and queries the partial private key extraction oracle to obtain . If there is no item indexed by , adds to the -list. If there is an item indexed by , but in the item is incomplete, adds the missed value(s) to the item. Finally, returns to .(6)Public key request: on receiving such a query on , checks the -list. If there is an item indexed by and , returns . If there is not an item indexed by , runs the Set-Secret-Value to obtain , computes , and then adds to the -list. If there is an item indexed by , but , first checks if . If , runs the Set-Secret-Value algorithm to obtain , computes , and adds , , to the item. If , computes , inserts , in the item. Finally, returns to .(7)Public key replacement: without generality, we assume that the query is of the form , where . On receiving such a query, sets the entry indexed by as in the -list.(8)Shared key revealing: ’ query is on . aborts the game if . Otherwise, queries ’s private key and ’s public key, computes the shared key according to the protocol description, and returns to .In the test phase, ’s query is on . If , aborts the game. Else, chooses uniformly and returns it to .
If makes the correct guess, then he must have queried oracle. searches the list for the entry . Suppose ’s public key has been replaced with , then we have thatso .
Suppose ’s probability of success is , then ’s probability of success is at least .
Lemma 2. Suppose and are random oracles. If a type II adversary can win the game II against the proposed CL-NIKE protocol, then the BDH problem can be solved with nonnegligible probability.
Proof. Suppose there is a challenger who is given an instance of and is tasked to compute . If there is a type II adversary , then can solve the BDH problem by controlling the queries with .
In the setup phase, chooses the system parameters and the master key and computes the system public key . gives the system parameters as well as the master key to .
In the query phase, hash functions and are modeled as random oracles. Without generality, we suppose that there are users in the system, and chooses and to ask the test query. We also suppose is allowed to ask queries. The ways that answers ’s queries are as follows:(1) query: ’s query is of the form . maintains an -list with each entry of the form . On receiving ’s query, first searches -list. If there is an item indexed with , returns the corresponding to . If there is not such an item, the following holds:(a)If , inserts in the list and returns .(b)If , chooses uniformly , returns , and inserts to the -list.(2) query: ’s query is of the form . maintains an -list with each entry the form . On receiving ’s query, first searches -list. If there is an item indexed with , then returns the corresponding . Else, chooses , returns to , and inserts to -list.(3)Secret value extraction: maintains a -list of the form . On receiving ’s query on , first checks whether there is an entry indexed by in the -list. If there is, returns . Otherwise, runs the Set-Secret-Value algorithm to obtain , adds to the -list, and returns to . We note here that it is impossible that there is an item indexed by but because is known by and the entry must be generated by asking .(4)Private key extraction: ’s private key extraction query is on . If , aborts the game. Else searches the -list, if there is an item indexed by , and , , and returns . If there is not an item indexed by , runs the Set-Secret-Value to get and computes using , then inserts to the -list. If there is an item indexed by , but is missing, computes using and adds to the -list. Finally, returns to .(5)Public key request: on receiving such a query on , checks the -list. If there is an entry listed by and , returns . Otherwise, does the following:(a)If and there is not an item indexed by , runs the Set-Secret-Value to obtain and computes and , then adds to the list. If and there is an entry indexed by , then the entry must be generated when queries ’s private key. obtains from the entry, computes and , and adds to the entry.(b)If , sets and computes . Then, adds to the list.(c)If , sets and computes . Then, adds to the list. Finally, returns to .(6)Shared key revealing: ’ query is on . If , then aborts the game. Else, queries ’s private key and ’s public key, computes the shared key according to the protocol description, and returns to .In the test phase, chooses as query. If , aborts the game. Else, chooses uniformly and returns it to .
If makes the correct guess, then he must have queried oracle. searches the list for the entry . We have that , and then, can output .
Suppose ’s probability of success is , then ’s probability of success is at least .
We also note here that, in a CL-NIKE protocol, a participant has the private key or long-term secret of the form , where is ’s secret number, and is ’s partial private key. A CL-NIKE protocol allows the leakage of or .
In the above security proof, the security against a leaked is modeled by game I, which allows an attacker to obtain via the public key replacement query. The security against a leaked is modeled by game II, which gives the attacker the master key or the partial private key of every participant in the system.
A CL-NIKE protocol does not allow the leakage of both and or the private key. This is very different from authenticated KE protocols because authenticated KE protocols use ephemeral keys [24, 25], and the security of the shared key could be guaranteed by the ephemeral keys even if both participants’ private keys are lost. In order to realize the noninteractive key establishment, there is no ephemeral keys used in NIKE protocols; thus, the leakage of private keys is not allowed in NIKE protocols. However, compared with certificate-based NIKE protocols [7] or identity-based NIKE protocols [15, 16], our CL-NIKE protocol allows the leakage of part of the private key, and this results in the improved security.
6. Performance Analysis
In this section, we compare our protocol with Sang et al.’s protocol [19] and Fu and Liu’s protocol [20] in terms of computation complexity and running time.
The computation complexity is compared in terms of complex operations including pairing, scalar multiplication, and hash to point. We neglect operations including ordinary hash functions, point addition, and integer computations because the running time of these operations is trivial compared with those complex operations. We compare how many complex operations are employed in every protocol. In the comparison, stands for a pairing operation, stands for a scalar multiplication, and stands for a map to point hash. To evaluate the running time of a protocol, we first implement the complex cryptographic operations and then add up to get the overall running time.
We implement the complex operations with Miracle Version 7.0 [26]. We use the Tate pairing defined over supersingular elliptic curve with embedding degree 2. is a 160-bit Solinas prime and a 512-bit prime satisfying . The evaluation is carried out in a PC with Intel Core i7-6700 CPU at 2.8 GHZ and 8.0 GB memory. The operation system is Windows 10. The operation time of every complex operation is listed in Table 1.
The comparison results are given in Table 2. From the comparison, we can see that our protocol reduces the running time by limiting the pairing operation times. Compared with Sang et al.’s protocol, the running time is reduced by 34.75%; compared with Fu-Liu’s protocol, the running time is reduced by 33.00%.
7. Conclusion
In this paper, we propose a certificateless noninteractive key exchange protocol. The protocol requires no interaction; thus, the communication delay is minimized. Moreover, the computation efficiency is improved because the pairing operation times are reduced. Compared with existing CL-NIKE protocols, our protocol improves the computation efficiency by at least 33.00%. The security of the protocol is based on the bilinear Diffie–Hellman problem and could be proved in the random oracle model.
Data Availability
The data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
The authors would like to thank the National Defense Pre-Research Plan for the 13-th Five Years Project (no. 90407180012), National Science Foundation of China (no. 61771361), and Scientific Plan Project of Shaanxi Province (no. 2020JQ-319) for funding.