Abstract
We revisit the SM2 protocol, which is widely used in Chinese commercial applications and by Chinese government agencies. Although it is by now standard practice for protocol designers to provide security proofs in widely accepted security models in order to assure protocol implementers of their security properties, the SM2 protocol does not have a proof of security. In this paper, we prove the security of the SM2 protocol in the widely accepted indistinguishability-based Bellare-Rogaway model under the elliptic curve discrete logarithm problem (ECDLP) assumption. We also present a simplified and more efficient version of the SM2 protocol with an accompanying security proof.
1. Introduction
Due to the potential of elliptic curve cryptography (ECC) to offer similar security to established public-key cryptosystems at reduced key sizes, it has become a subject of research focus. For example, we observe an emerging trend in the use of identity-based (ID-based) cryptography, such as ID-based key agreement protocols using pairings. The latter include ID-based authenticated key agreement (ID-AKA) protocol. ID-AKA protocols (as well as other key establishment protocols such as [1–4]) allow a shared secret key to be established between two or more parties for subsequent cryptographic use. The first two-party ID-AKA protocol was proposed by Shamir, which is based on Weil Pairing [5]. Shamir’s protocol requires a trusted key generation center (KGC). Challenges associated with KGC are well documented, and Alriyami and Paterson proposed the first certificateless two-party authenticated key agreement (CTAKA) protocol that does not require a KGC [6]. Since then, a number of CTAKA protocols have been proposed in the literature [7–9]. Most of these CTAKA protocols are, however, based on bilinear pairings. The latter is expensive, especially in comparison to RSA algorithm [10, 11].
A number of recently published certificateless ECC-based AKA protocols that do not require the use of pairings have been proposed. For example, in 2007, Zhu et al. proposed a pairing-free ID-AKA protocol [12]. However, the combination of a pairing-free ID-based signature scheme with the Diffie-Hellman key exchange in the proposed protocol results in larger computation complexity and message size. In addition, the protocol and the ECC-based pairing-free ID-AKA protocol of Cao et al. [13] require three rounds of message exchanges. Another later protocol of Cao et al. reduces the minimum message exchange rounds to two and the protocol was proven secure in the Bellare-Rogaway model [10]. He et al. also independently proposed a two-round certificateless ID-AKA protocol without the use of pairings [14] and a three-round certificateless ID-AKA protocol without the use of pairings [2], respectively.
In 2011, the Chinese government published an ECC-based key exchange protocol, SM2 [15]. According to the official report from the Chinese Government State Cryptography Administration and various media releases, SM2 protocol is mandatory in various cryptographic applications used by Chinese government agencies from 1st July, 2011 [16–18]. A 2005 survey by Boyd and Choo revealed that the purported security of several published ID-based protocols is based on heurstic security arguments. A number of protocols were also found to be proven secure in a restricted model. This study highlighted the need for more rigorously tested identity-based protocols [19]. Surprisingly, we observed that despite the wide usage of the SM2 protocol among Chinese commercial applications/electronics, it does not have a security proof.
A protocol’s goal is defined as the properties that the protocol aims to achieve. As Boyd and Mathuria suggested, any attack on a protocol is only valid if it violates some property that the protocol was intended to achieve [20]. Without identifying at an early stage the properties and/or goals that a protocol offers, one can debate the validity of attacks against a published protocol since it may not be clear whether the protocol is not intended to provide assurances against the properties being exploited [21]. This reinforced the importance of having a security proof for protocols, particularly those that are widely used by government agencies and in the private sector.
Our contributions in this paper are two-fold.(1)We prove the SM2 protocol secure in the widely accepted indistinguishability-based model of Bellare and Rogaway under the ECDLP assumption.(2)We propose a simplified version of SM2 protocol that is more efficient, and prove it secure in the Bellare-Rogaway model under the ECDLP assumption.
In the next section, we will briefly review the model that we work in. We revisit the SM2 protocol and prove it secure in Section 3. Section 4 describes our simplified SM2 protocol and its proof of security. Finally, the last section concludes the paper.
2. Overview of the Bellare-Rogaway Model
In the Bellare-Rogaway model [22, 23], the adversary (denoted by ) controls the communication channel by interacting with a set of oracles. is defined to be the th instantiation of a protocol participant, in a specific protocol run and is the other protocol participant, with whom wishes to establish a secret key. The predefined oracle queries are described informally as follows.(i)The Send query allows to send a message to another protocol participant at will. In other words,(a), upon receiving the query, will compute what the protocol specification demands. The response message and/or decision will then be sent to ,(b)if has either accepted with some session key or terminated, this will be made known to .(ii)The Reveal query allows to expose a previously accepted session key. In other words, , upon receiving this query and if it has accepted and holds some session key, will send this session key back to .(iii)The Corrupt query allows to learn the complete internal state of . This models the real world scenario of a corrupted insider.(iv)The Test query is the only oracle query that does not correspond to any of ’s abilities. If has accepted with some session key and is being asked a Test query; then depending on a randomly chosen bit , is given either the actual session key or a session key drawn randomly from the session key distribution.
Definition 1 (Definition of Partnership). Let us denote and as two oracles in the protocol run. These two oracles are considered partners if and only if(i)both and have accepted the same session key,(ii)only and (i.e., no other oracle) have accepted with the same session ID (i.e., SID, which is defined to be the concatenation of the message flows) and agreed on the same set of principals (i.e., the initiator and the responder of the protocol).
Definition 2 (Definition of Freshness). Oracle holds a fresh session key at the end of execution, if and only if all the following conditions are satisfied: (i) has accepted with, or without, a partner oracle ,(ii) and (if such a partner oracle exists) has/have not been sent a Reveal query,(iii)both and (if such a partner exists) has/have not been sent a Corrupt query.
The definition of security depends on the notions of partnership as outlined in Definition 1 and freshness as outlined in Definition 2 and is defined using the game and played between and a collection of oracles for players and instances . runs the game simulation , whose setting is as follows.(i)Send, Reveal, and Corrupt oracle queries are sent by in any order at will.(ii) chooses a fresh session on which to be tested by sending a Test query to the fresh oracle associated with the test session at some point during . This chosen test session must be fresh (in the sense of Definition 2). Depending on a randomly chosen bit , is given either the actual session key or a session key drawn randomly from the session key distribution.(iii) continues making any Send, Reveal, and Corrupt oracle queries of its choice.(iv) will eventually terminate and outputs its guess of the value of , denoted as .
We measure ’s success in in terms of ’s advantage in distinguishing whether receives the real key or a random value (i.e., whether ).
Let be a security parameter. Then, the advantage function of is denoted by, where
Definition 3 (Definition of Security). A protocol is secure in the Bellare-Rogaway model if both the following requirements are satisfied. (1)Two oracles accept the same key when the protocol is run in the absence of a malicious adversary.(2)For all probabilistic, polynomial-time (PPT) adversaries, is negligible.
3. A Provably-Secure SM2 Key Exchange Protocol
3.1. SM2 Key Exchange Protocol
The notations used in SM2 protocol (Table 1) are as follows:(i), : two SM2 protocol participants with identities and respectively,(ii), : , : the parameters of the elliptic curve on where elliptic function is ,(iii): the prime field includes elements,(iv): the set of all points on the elliptic curve defined over ,(v): the base point of elliptic curve, order of is prime number that ,(vi): cofactor, , is the order of ,(vii): the space of number that ,(viii): long-term private and public key pair,(ix): session key,(x): identification of client,(xi): hash value of identification, the length of is bits,(xii): one-way hash function,(xiii): temporary private and public key pair,(xiv) and : the bit length of the key and , respectively,(xv): the one-way key derivation hash function whose output length is ,(xvi): concatenation of two strings and ,(xvii): there is no message or the value is not known.
randomly selects and computes , prior to sending to . will also randomly select and compute , before sending to . The public parameters are . And and are hash values of the identification of and , respectively, where and . To establish a session key with client ,(1)client will now run the protocol as follows:(a)randomly selects ,(b)computes and where ,(c)computes ,(d)sends to client ;(2)upon receiving the message from client , will perform the following:(a)randomly selects ,(b)computes , , , and ,(c)(optional for key confirmation) computes ,(d)Sends to client (optional for key confirmation, will also send to );(3)upon receiving the messages, (and ), from , client will perform the following:(a)computes , and ,(b)(optional for key confirmation) computes ,(c)verifies , and if it returns true then is assured that actually has possession of the session key, otherwise, terminates the protocol run and outputs ,(i)(optional for key confirmation, computes ),(ii)Sends to client ;(4)(optional for key confirmation) upon receiving the message () from client , client will perform the following: (a)computes ,(b)verifies whether ,(c)if the verification returns wrong, then client terminates the protocol run and outputs ,(d)otherwise, client is assured that actually has possession of the session key;(5)session key established is ,(6)SID is or in the case where key confirmation is required.
3.2. Security Proof
The security of the protocol—see Theorem 5—is based on the ECDLP assumption (see Definition 4) in the random oracle model.
Definition 4 (ECDLP Assumption). The ECDLP problem is defined as follows: If we can solve the discrete logarithm problem (DLP) [26], then we can also (immediately) solve the ECDLP problem.
Theorem 5. SM2 protocol is secure in the sense of Definition 3 when the underlying hash and key derivation schemes are modelled as random oracles and the elliptic curve discrete logarithm problem (ECDLP) assumption is satisfied in .
The soundness requirement is trivial to verify. We will now concentrate on proving the indistinguishability requirement.
In the usual tradition of reductionist proofs, we assume that there exists an adversary against the protocol (i.e., has a nonnegligible advantage, , where is the security parameter), and we then construct a solver that makes use of to solve the problem. In other words, will simulate the view of by answering all Send, Reveal, Corrupt, and Test queries of . will start by randomly selecting two users, and , and a session number, , as the test session. will also manage two random oracles, and , in order to answer ’s queries. More specifically when the oracle is queried, will check whether the tuple is already in the -list and output the stored response. Otherwise, will respond with the appropriate output, , and adds the tuple to the -list. will answer queries in the same manner.(i)Send queries: for any well-formed Send queries from , can trivially answer with the right output as the protocol specification demands. Specifically, answers the query as follows.(a)If = initiator and = responder, then the will output the message .(b)Consider the case that = initiator, = responder, and message .(1)If has rejected the message , then will respond with . Otherwise, will verify whether is the right format or not. (2)If verifies correctly, then will output messages to . Otherwise, will abort the simulation and output .(c)Assume = initiator, = responder, and messages .(1)If has rejected the messages , then will respond with . Otherwise, will verify whether is the right format or not. (2)If verifies correctly, then will output messages to . Otherwise, will abort the simulation and output .(ii)Reveal queries: if or , then will abort the simulation and fail. Otherwise this query can be answered with the right session key as long as has accepted and neither nor its partner has been corrupted. However, such a session will be rendered unfresh.(iii)Corrupt queries: this query can be easily answered as per the protocol specifications, unless or . In the latter scenario, will abort the simulation and fail.(iv)Test queries: if , then will abort the simulation and fail. Otherwise, will check whether has accepted and that the session is fresh. If so, will be given either the actual session key or a session key drawn randomly from the session key distribution, depending on the randomly chosen bit .
For to distinguish whether the value returned is the actual session key or a session key drawn randomly from the session key distribution, has to determine the correct values of or to compute the session key (since , and , ). For this to happen,(i) has to guess the long-term private key and short-term private key in order to compute and hence, the session key . If is able to successfully guess and via and , then would be able to use to solve the problem. Let and denote ’s advantage in computing the correct values of and , respectively, and denotes the event that can successfully guess the session key using the computed values of and . So we have (ii) has to guess the correct value of . Similar to the above, we let and denote ’s advantage in computing the correct value of and , respectively, and denotes the event that can successfully guess the session key using the computed values of and . So we have There is, therefore, a negligible advantage of distinguishing whether the value returned is the actual session key or a session key drawn randomly from the session key distribution. Let and denote the number of Test queries asked and the event that can correctly distinguish the session key, respectively. We now have
Since , , , , , , and , , we have and . Therefore,
This concludes the proof for Theorem 5.
4. A Provably-Secure Simplified SM2 Key Exchange Protocol
In this section, we propose a more efficient version of the SM2 protocol—see Table 2—and prove its security in the Bellare-Rogaway model.
4.1. Protocol Description
randomly selects and computes long-term public key and . It then sends and to . also randomly selects and computes and , prior to sending and to . are system parameters. To establish a session key with ,(1) will now run the protocol as follows:(a)randomly selects ,(b)computes and ,(c)sends to ;(2)upon receiving from , will perform the following:(a)randomly selects ,(b)computes , , , and ,(c)(optional for key confirmation) computes ,(d)sends to (optionally for key confirmation, will also send to );(3)upon receiving (and , optionally for key confirmation) from , will perform the following:(a)computes and , ,(b)(optional for key confirmation) compute ,(c)verifies that , and if it returns true, then is assured that actually has possession of the session key, otherwise, terminates the protocol run and outputs ,(i)(optional for key confirmation) computes ,(ii)Send to client ;(4)(optional for key confirmation) upon receiving , will perform the following:(a)computes ,(b)verifies whether ,(c)if the verification returns wrong, then client terminates the protocol run and outputs . If it returns true, then is assured that actually has possession of the session key. Otherwise, terminates the protocol run and outputs ; session key established is , SID is or in the case where key confirmation is required.
4.2. Security Proof
Theorem 6. The simplified SM2 protocol (Table 2) is secure in the sense of Definition 3 when the underlying hash and key derivation schemes are modelled as random oracles and the ECDLP assumption is satisfied in .
The proof process is similar to that of Section 3.2.(i)Send queries: for any well-formed Send queries from , can trivially answer with the right output as the protocol specification demands. Specifically, answers the query as follows.(a)If = initiator and = responder, then the will output the message, , to the query.(b)Consider the case that = initiator, = responder, and messages .(1)If has rejected the message , then will respond with . Otherwise, will verify whether is the right format or not.(2)If verifies correctly, then will output messages to . Otherwise, will abort the simulation and output .(c)Assume = initiator, = responder, and messages .(1)If has rejected the messages , then will respond with . Otherwise, will verify whether is the right format or not.(2)If verifies correctly, then will output messages to . Otherwise, will abort the simulation and output .
Simulations for the Reveal, Corrupt, and Test follow that of Section 3.2.
For to distinguish whether the value returned is the actual session key or a session key drawn randomly from the session key distribution (i.e., whether or ), has to determine the correct values of or (since , and , ). For this to happen, has to obtain the correct value of in order to compute and consequently, the session key . For to obtain , has to be able to compute from since .
Let denote ’s advantage in computing from , and we have
Let denote ’s advantage in computing from , and we have
Let denote the event that is able to distinguish whether the value returned is the actual session key or a session key drawn randomly from the session key distribution. We then have
Since, , , , , , and , , we have − and . It follows that .
This concludes the proof for Theorem 6.
5. Conclusion
Key exchange protocols are the cornerstone of any secure communication. By proving the widely used Chinese Government SM2 protocol secure in the Bellare-Rogaway model under the ECDLP assumption, we hope that this provides a strong assurance to protocol implementers that the protocol is behaving as desired. In addition, we presented a more efficient version of the SM2 protocol with a proof of security in the Bellare-Rogaway model under the ECDLP assumption.
A comparison with six existing pairing-free protocols reveals that the computational load of our simplified SM2 protocol is no more than that of the six and the SM2 protocols, yet provides both implicit key confirmation ( is assured that can compute the session key) and explicit key confirmation ( is assured that has actually computed the session key)—see Table 3. In Table 3, , , , and denote addition, multiplication, exponentiation, and hash operations, respectively.
Conflict of Interests
As the authors of the paper, we do not have a direct financial relation with any institution or organization mentioned in our paper that might lead to a conflict of interests for any of the authors.