Research Article  Open Access
Xuefei Cao, Lanjun Dang, Yingzi Luan, Wei You, "A Certificateless Noninteractive Key Exchange Protocol with Provable Security", Security and Communication Networks, vol. 2020, Article ID 8862476, 8 pages, 2020. https://doi.org/10.1155/2020/8862476
A Certificateless Noninteractive Key Exchange Protocol with Provable Security
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., certificatebased ones, identitybased ones, and certificateless ones. Certificatebased NIKE protocols employ the traditional certificatebased cryptography. Diffie–Hellman’s noninteractive key exchange scheme falls into this category. In 2006, a certificatebased NIKE protocol was proposed using an elliptic curve [6], and a PKIbased 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 identitybased NIKE protocol based on a oneway 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 IDbased 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 IDbased NIKE [15]. Paterson and Sirinivasan studied the relationship between IDbased NIKE and IDbased encryption and proposed an IDNIKE scheme [16] and a security model stronger than Dupont and Enge’s model. An improved IDNIKE with forward secrecy is proposed in [17].
To remove the inborn issue of key escrow with IDbased cryptosystem, AlRiyami 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 IDbased 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 (CLNIKE) protocol [19]. Later, Fu and Liu proposed another CLNIKE 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 CLNIKE. A CLNIKE 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 masterkey. are publicly authentically available, but the masterkey is known only to the KGC.(2)Partialprivatekeyextract: 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)Setsecretvalue: the algorithm is run by an entity . The algorithm returns ’s secret value .(4)Setprivatekey: the algorithm is run by . It takes and and returns ’s private key .(5)Setpublickey: the algorithm is run by . It takes and and returns ’s public key .(6)Sharedkey: 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 certificatebased cryptosystem to the IDbased 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 IDbased 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 CLNIKE protocols.
There are two types of adversaries to a CLNIKE 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 CLNIKE. 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 CLNIKE 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 PartialPrivateKeyExtract to generate the partial private key and returns it to .(2)Secret value extraction: after receiving the query, runs the SetSecretValue algorithm and returns to .(3)Private key extraction: will call PartialPrivateKeyExtract and SetSecretValue in this query to obtain and , and then, runs SetPrivateKey on and to generate the private key .(4)Public key request: first runs SetSecretValue and keeps for itself. Then, runs SetPublicKey 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 CLNIKE 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 SetSecretValue 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 SetSecretValue to obtain . At last, runs the SetPrivateKey to obtain user ’s private key and returns it to .(3)Public key request: on receiving this query, first runs SetSecretValue to obtain and then it runs SetPublicKey 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 CLNIKE scheme is secure against if is negligible.
A CLNIKE scheme is secure if it is secure both against and .
4. Protocol Description
In this section, we propose a new CLNIKE 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)PartialPrivateKeyExtract: given a user ’s identifier , KGC computes and . is ’s partial private key. KGC returns to via a secure channel.(iii)SetSecretValue: selects at random and sets as his secret value.(iv)SetPrivateKey: ’s private key is .(v)SetPublicKey: 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 CLNIKE 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 CLNIKE 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 masterkey 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 SetSecretValue 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 SetSecretValue 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 SetSecretValue to obtain , computes , and then adds to the list. If there is an item indexed by , but , first checks if . If , runs the SetSecretValue 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 CLNIKE 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 SetSecretValue 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 SetSecretValue 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 SetSecretValue 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 CLNIKE protocol, a participant has the private key or longterm secret of the form , where is ’s secret number, and is ’s partial private key. A CLNIKE 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 CLNIKE 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 certificatebased NIKE protocols [7] or identitybased NIKE protocols [15, 16], our CLNIKE 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 160bit Solinas prime and a 512bit prime satisfying . The evaluation is carried out in a PC with Intel Core i76700 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 FuLiu’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 CLNIKE 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 PreResearch Plan for the 13th Five Years Project (no. 90407180012), National Science Foundation of China (no. 61771361), and Scientific Plan Project of Shaanxi Province (no. 2020JQ319) for funding.
References
 E. S. V. Freire, J. Hesse, and D. Hofheinz, “Universally composable noninteractive key exchange,” Lecture Notes in Computer Science, Springer, Berlin, Germany, 2014. View at: Publisher Site  Google Scholar
 W. Diffie and M. Hellman, “New directions in cryptography,” IEEE Transactions on Information Theory, vol. 22, no. 6, pp. 644–654, 1976. View at: Publisher Site  Google Scholar
 R. Du, Z. Zhou, and H. Milan, “Noninteractive key exchange protocol for space dtn,” Computer Engineering, vol. 42, no. 4, pp. 137–142, 2016. View at: Google Scholar
 M. Qi and J. Chen, “An enhanced authentication with key agreement scheme for satellite communication systems,” International Journal of Satellite Communications and Networking, vol. 36, no. 3, pp. 296–304, 2018. View at: Publisher Site  Google Scholar
 Y. Wei, F. Wei, and C. Ma, “Certificateless noninteractive key exchange protocol without pairings,” in Proceedings of the International Conference on Security and Cryptography, pp. 31–42, Pune, India, October 2014. View at: Google Scholar
 D. J. Bernstein, “Curve25519: new diffiehellman speed records,” Public Key CryptographyPKC 2006, Springer, Berlin, Germany, 2006. View at: Publisher Site  Google Scholar
 D. Cash, E. Kiltz, and V. Shoup, “The twin diffiehellman problem and applications,” Journal of Cryptology, vol. 22, no. 4, pp. 470–504, 2009. View at: Publisher Site  Google Scholar
 E. S. V. Freire, D. Hofheinz, E. Kiltz, and K. G. Paterson, “Noninteractive key exchange,” PublicKey CryptographyPKC 2013, Springer, Berlin, Germany, 2013. View at: Publisher Site  Google Scholar
 J. Hesse, D. Hofheinz, and L. Kohl, “On tightly secure noninteractive key exchange,” Lecture Notes in Computer Science, Springer, Berlin, Germany, 2018. View at: Publisher Site  Google Scholar
 U. Maurer and Y. Yacobi, “Noninteractive publickey cryptography,” in Proceedings of the Eurocrypt, pp. 498–507, Brighton, UK, April 1991. View at: Google Scholar
 C. H. Lim and P. J. Lee, “Modified MaurerYacobi’s scheme and its applications,” Advances in CryptologyAUSCRYPT’92, Springer, Berlin, Germany, 1993. View at: Publisher Site  Google Scholar
 U. M. Maurer and Y. Yacobi, “A noninteractive publickey distribution system,” Designs, Codes and Cryptography/jtl>, vol. 9, no. 3, pp. 305–316, 1996. View at: Publisher Site  Google Scholar
 U. Maurer and K. Dennis, “A note on the weakness of the maureryacobi squaring method,” Tech. Rep., TU Darmstadt, Darmstadt, Germany, 1999, Tech. Rep. TI 15/99. View at: Google Scholar
 R. Sakai, K. Ohgishi, and M. Kasahara, “Cryptosystems based on pairing,” The 2000 Symposisum on Cryptography and Information Security, Springer, Berlin, Germany, 2000. View at: Google Scholar
 R. Dupont and A. Enge, “Provably secure noninteractive key distribution based on pairings,” Discrete Applied Mathematics, vol. 154, no. 2, pp. 270–276, 2006. View at: Publisher Site  Google Scholar
 K. G. Paterson and S. Srinivasan, “On the relations between noninteractive key distribution, identitybased encryption and trapdoor discrete log groups,” Designs, Codes and Cryptography, vol. 52, no. 2, pp. 219–241, 2009. View at: Publisher Site  Google Scholar
 R. Steinwandt and A. Suárez Corona, “Identitybased noninteractive key distribution with forward security,” Designs, Codes and Cryptography, vol. 64, no. 12, pp. 195–208, 2012. View at: Publisher Site  Google Scholar
 S. S. AlRiyami and K. G. Paterson, “Certificateless public key cryptography,” Advances in CryptologyASIACRYPT 2003, Springer, Berlin, Germany, 2003. View at: Publisher Site  Google Scholar
 Y. Sang, L. Zhang, L. You, and Z. Li, “Two noninteractive key agreement protocols under certificateless scenarios,” International Journal of Advancements in Computing Technology, vol. 4, no. 6, pp. 331–337, 2012. View at: Publisher Site  Google Scholar
 X. Fu and X. Liu, “A noninteractive key agreement protocol under certificateless scenarios,” Journal of Cryptologic Research, vol. 1, no. 4, pp. 334–340, 2014. View at: Google Scholar
 R. Canetti and H. Crawczyk, “Analysis of key exchange protocols and their usage in building secure channels,” in Advances in CryptologyEurocrypt 2001, LNCS 2045, pp. 453–474, SpringerVerlag, Berlin, Germany, 2001. View at: Google Scholar
 B. LaMaechia, K. Lauter, and A. Mitya, “Stronger security of authenticated key exchange,” in Proceedings of Provsec 2007, pp. 1–16, SpringerVerlag, Wollongong, Australia, October 2007. View at: Google Scholar
 D. AbbasinezhadMood and M. Nikooghadam, “An anonymous eccbased selfcertified key distribution scheme for the smart grid,” IEEE Transactions on Industrial Electronics, vol. 65, no. 10, pp. 7996–8004, 2018. View at: Publisher Site  Google Scholar
 D. AbbasinezhadMood, A. OstadSharif, M. Nikooghadam, and S. M. Mazinani, “A secure and efficient key establishment scheme for communications of smart meters and service providers in smart grid,” IEEE Transactions on Industrial Informatics, vol. 16, no. 3, pp. 1495–1502, 2020. View at: Publisher Site  Google Scholar
 D. AbbasinezhadMood, A. OstadSharif, S. M. Mazinani, and M. Nikooghadam, “Provablysecure escrowless chebyshev chaotic mapbased key agreement protocol for vehicle to grid connections with privacy protection,” IEEE Transactions on Industrial Informatics, 2020. View at: Publisher Site  Google Scholar
 Miracl Library, 2015, https://www.miracl.com/.
Copyright
Copyright © 2020 Xuefei Cao et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.