DAKEs: Decentralized Authenticated Key Exchange Protocols via Blockchain for Smart City

Authenticated key exchange (AKE) is a classic problem in cryptography, where two participants want to exchange their secret keys without being guessed feasibly. Recently, there has been renewed interest in this problem in the smart city since millions of devices and servers in this environment may involve the problem. New challenges are raised at the same time. One of the greatest challenges is how to facilitate communication between participants. Traditionally, a trusted third party (TTP) is needed to provide a trusted way to exchange keys. However, devices in the smart city environment are usually distributed and trustless. A central trusted mechanism is not suitable for many applications in it. The second challenge is that the requirements in the applications of the smart city are diverse. Finally, a practical AKE protocol should be e ﬃ cient and easy to integrate. To address these challenges, we provide a fully decentralized AKE protocol framework called DAKEs. To the best of our knowledge, DAKEs enjoy the most comprehensive security properties to ful ﬁ l diverse requirements. The decentralization of DAKEs is captured by using the blockchain while avoiding the availability problem of other similar blockchain-based schemes. Our test is conducted in a real-world test network of Ethereum. The result shows that DAKEs are e ﬃ cient and at a low cost.


Introduction
As a classic cryptography problem, authenticated key exchange (AKE) is prescribed for sharing secret keys over insecure channel [1] and providing a way to authenticate the identity of the participants. Recently, there has been renewed interest in this topic as the concept of "Smart City" goes viral [2]. "Smart City" introduces a large number of participants (devices and servers, etc.) sharing data with each other. AKE protocol as a basic cryptography protocol can be used to secure the system for authentication, access control and data confidentiality, etc. Moreover, participants in a smart city are usually distributed and mutual untrusted. The trust and consensus for a digital economy activity in a smart city need to be more transparent. Thus, new challenges are raised in designing an AKE protocol fitting for a smart city.
One of the greatest challenges is how to facilitate communication between participants in a trustless environment. Traditionally, the two participants in an AKE protocol should build their communication under the assistance of a trusted third party (TTP). The TTP plays a role to manage the digital identities of the participants who have no prior relationship [3]. The trust and consensus are based on a central party. However, in a trustless and transparent environment like a smart city, a distributed trust paradigm is essential for a wide range of applications. In 2015, Patrick McCorry et al. [4] presented an AKE protocol via Bitcoin [5]. As an early study to realize AKE without any TTP, the paper showed us the potential power of blockchain technology. Thereafter, many researchers tried to explore blockchain as a facility of decentralized trust in a smart city. In 2020, Yavari et al. [6] proposed a blockchainbased authentication protocol for secure communication between IoT equipment. In 2022, privacy-preserving problem has become an important component in secure communication [7] [8].
Meanwhile, the capacity and availability limitation in blockchain technology becomes a primary concern, especially in Bitcoin-alike systems [9]. A long time might be taken to wait for accepting a transaction in these systems. Yifei Hu et al. [10] provided a way to construct a specialized blockchain for building AKE protocols. Apparently, this is too expensive for constructing a basic protocol. Perhaps, a more practical way to design an authenticated key exchange protocol is to program on the blockchain instead of constructing transactions directly. Ethereum smart contract [11] provides such an approach. Indeed, there have been thousands of decentralized applications built via the Ethereum smart contracts. Recently, Robert Muth et al. [12] proposed a Diffie-Hellman Key Exchange with Smart Contracts. But the security requirements in the applications of the smart city can be diverse. And the demands for AKE protocols in different scenarios may be distinct. A considerate AKE protocol should take all the security properties into account. The smartDHX in [12] only fulfills a static security property. Chen et al. [13] provided the first post-quantum blockchain construction for securing a smart city. However, they only design the theoretical protocol but supply no real deployment.
To address these essential problems, we present DAKEs, a decentralized authenticated key exchange protocol framework via Ethereum smart contract. Specifically, our contributions are summarized as follows: (i) We have proposed a blockchain-based decentralized authenticated key exchange protocol design framework and implemented five protocols with different security properties. The proposed framework called DAKEs provides a practical method to design fully decentralized authenticated key exchange protocols which avoid the problem of availability when using the Bitcoin-alike blockchains (ii) To the best of our knowledge, the implemented protocols are the first work to take most key security properties in AKE into account. Not only DAKEs is fully decentralized, but also can be used in various applications which may have different security requirements (iii) We conduct experiments in a live testnet of the Ethereum blockchain. The experiment shows that the protocols in DAKEs are effective and low-cost. We also gave a comprehensive comparison of the protocols, and anyone who wants to use a decentralized authenticated key exchange protocol can choose a suitable protocol in DAKEs according to his/her requirements The rest of this paper is arranged as follows. In Section 2, we introduce the necessary preliminary knowledge. In Section 3, we give system model and the detail design of our framework. In Section 5, we provide the implementation of our protocol based on the testnet of the Ethereum blockchain. Finally, in Section 6, we draw a brief conclusion.

Preliminaries
2.1. Authenticated Key Exchange (AKE). Key exchange (KE) may happen when two participants want to build a secure channel to communicate with each other. To build a secure channel, they could use a common secret key and encrypt all the messages. Here comes the problem: How to exchange the secret key over an insecure channel? Moreover, the two participants should know the identity of the counterparty at the end of a key exchange protocol. We call this kind of protocol as authenticated key exchange (AKE) protocols [14].
Formally, suppose there are two users O and C who want to exchange a secret key called a session key, a secure AKE protocol should at least fulfil two requirements: Firstly, providing a way for the originator O to generate a random session key effectively and the key can only be known to the counterparty C eventually. Secondly, following the protocol, both O and C will know which person they are exchanging the session key with at the end of the protocol.

Threat
Model. In our protocols, the certificates of the users and public security parameters are written on the blockchain. Firstly, we assume that there is an adversary who can eavesdrop on the data transferred between the two participants since the data on a public blockchain can be analyzed by anyone. The data on the blockchain is tamper-proof and traceable due to the feature of blockchain technology. However, we shall assume the adversary can delay or block the transactions since the adversary may be a powerful node of the blockchain and participate in the consensus. Under these assumptions, we then give the potential threats as follows: (1) Man-in-the-Middle Attack [15]. In this type of attack, the adversary is able to recover a session key by blocking the message transferred between the two participants. To make this clear, we illustrate an insecure protocol as an example. Suppose a user O as the originator of the protocol want to exchange a session key with a user C as the counterparty of the protocol. In step one, O sends a random number r and his/her certificate Cert O to C. In step two, C query the certificate of O and verify its validity. Then, C sign on the data δ ≔ Sig C ðr, id O Þ and encrypt the session key data c ≔ Enc C ðk, id C Þ by C's public key. Eventually, C sends ðδ, c, Cert C Þ to O.
To attack this, the adversary R as a middle man can block the message which C send to O in step two and replace c with c′ ≔ Enc C ðk′, id R Þ. At the end of the protocol, O will get a session key k ′ , which is generated by the adversary (2) Replay Attack [16]. In this type of attack, the adversary attacks the protocol by re-using the old information. Similarly, we give an insecure protocol example here.  [17]. In this type of attack, the adversary tries to mislead the participants into thinking they are talking to the expected counterparty. However, they are talking to the adversary indeed. Again, we give an insecure protocol example. In step one, O sends r, Cert O to C. In step two, C sends c ≔ Enc C ðk, id C Þ, δ ≔ Sig C ðr, cÞ, Cert C to O. The adversary can attack this protocol like this. First, the adversary blocks the message which O sends to C in step one and sends r, Cert R to C. Then, the adversary will get c, δ, Cert C from C. And he then delivers c, δ, Cer t C to O. Finally, O will deem that C is his/her counterpart while C is talking to another originator R (4) Chosen ciphertext attack [18]. An encryption scheme will usually be used in an AKE protocol.
There is a kind of attack on encryption schemes called chosen ciphertext attack (CCA). In a CCA, the adversary is supposed to be able to choose some ciphertexts to ask for the corresponding decryptions. But there is a restriction that the adversary cannot ask for the plaintexts of any ciphertexts. If an encryption scheme used in an AKE protocol cannot resist CCA, it may suffer a number of potential threats. For instance, suppose a stream cipher is used in an AKE protocol. Firstly, the adversary gets a ciphertext c which is encrypted by a unknown string m and a secret key k, c = m ⊕ GðkÞ. Then, the adversary can construct a ciphertext c ′ = c ⊕ Δ, where Δ can be an arbitrary string. c ′ can be taken as a legal ciphertext because the decryptor will decrypt it as c ′ ⊕ GðkÞ and c′ ⊕ GðkÞ = m ⊕ GðkÞ ⊕ Δ ⊕ GðkÞ = m ⊕ Δ. Now assume the length of k is n-bit, m = kkid C and Δ ≔ 0 n kðid C ⊕ id R Þ. The adversary can easily construct an encryption c ′ = kkid R from c = kkid C 2.3. Security Properties. In the part of the threat model, we have already hinted at some of the properties we want for a secure AKE protocol. Let us try to make these just a bit more precise in this part. First of all, we suppose in an AKE protocol; the keys for authenticating an identity of a participant may be used for a long time. For example, a public key for a certificate Cert and its corresponding secret key may be used quite the long term; we call this kind of key a long-term key. Contrarily, the session key exchanged by the participants may be used for just a short time. And we call this kind of key the short-term key. The security properties of an AKE protocol can be distinct. And we give a comprehensive consideration of these security properties in our protocols. One can choose a proper security level for his own application. In general, there are six security properties [19] overall as follows: (i) Static secrecy. This is the weakest security property where we assume that an honest participant's long-term secret key can never be compromised by the adversary. However, we assume that the adversary can query a session key from an instance of an AKE protocol except the one he/she tries to compromise. For a new instance, the session key k of an AKE protocol should be indistinguishable from a random key in the view of the adversary. Then, we say the protocol has a static secrecy property (ii) Perfect forward secrecy. This is a stronger security notation than static secrecy where we assume an honest participant's long-term secret key can be compromised by the adversary. However, before the participant's long-term key is compromised, the session keys generated in the previous instances remain secret and cannot be distinguished from a random key.
Although the protocol is no longer safe after the adversary gets a long-term key, this security property can limit the damage to the time after that (iii) Explicit authenticity. This is a security property where the two participants O and C should be sure that they are talking to the other one when sharing the session key k. It means that they can know the identity of the counterparty explicitly (iv) Implicit authenticity. It is a weaker security notation than explicit authenticity and sometimes may be enough for some applications. Suppose there are two participants O and C. At the end of the protocol, the originator O can make sure that the counterparty C was online following the protocol and hold the same session key with him/her, whereas C cannot get the same guarantee. He/she cannot be sure about whether there is a counterparty holding the same session key. Moreover, he/she also has no idea whether the counterpart was online. But if he/she can make sure that if someone gets the same session key, then that must be O (v) Identity protection. This is a security property where the privacy of the participants can be protected under the AKE protocol. The adversary cannot get any useful information about the identities (vi) Deniability. This security property means both the two participants cannot provide valid evidence to a third party to prove that the other one has exchanged the key with him/her in the protocol. This could be useful in some applications. For example, when a mobile device O gets a shared session key from a base station C with an AKE protocol, O might not want to be known that he/she was nearby the station at that time. Deniability of an AKE protocol makes sure that no matter what evidence gathered by C cannot be convincing. For example, with the protocol, the evidence can be generated on C ′ s own without exchanging with O 3 Wireless Communications and Mobile Computing 2.4. ElGamal Encryption. In this part, we introduce the encryption scheme used in our protocols. ElGamal encryption [20] is a probabilistic encryption scheme first proposed by ElGamal et al. ElGamal encryption consists of several components: a cyclic group G of prime order q with generator g ∈ G, the key generator, the encryption algorithm, and the decryption algorithm.
(i) Key generator. The key pairs are computed as follows: Randomly choose x, where sk = x ∈ ℤ q . Then compute pk = h = g x (ii) Encryption algorithm. Given pk = h ∈ G and m ∈ M, the algorithm encrypts the message m as follows: Randomly choose y, where y ∈ ℤ q . Compute s = h y , c 1 = g y , and c 2 = m · s. Finally, the ciphertext is ðc 1 , c 2 Þ (iii) Decryption algorithm. Given sk = x ∈ ℤ q and ðc 1 , c 2 Þ , the algorithm decrypts the ciphertext as follows: In this part, we introduce the digital signature scheme used in our protocols. Actually, the digital signature algorithm (DSA) is a variant of ElGamal signature schemes. DSA is also a digital signature standard proposed by the National Institute of Standards and Technology (NIST) [21]. Following the standard, we describe a DSA digital signature as follows: (i) Parameters. There are a group of domain parameters used by a DSA as follows: A prime modulus p has a bit length of L, where 2 L−1 < p < 2 L ; a prime divisor q has a bit length of N, where qjp − 1 and 2 N−1 < q < 2 N ; a multiplicative group GFðpÞ; a subgroup SubGðqÞ in GFðpÞ with a order of q; a generator g of SubGðqÞ, where 1 < g < p; a randomly choosed private key x, where x ∈ ℤ q ; the corresponding public key y, where y = g x ; and a randomly chosen number k, where k is unique to each message and k ∈ ℤ q . The choices for the pair L and N follow the standard (ii) Signature generation. Given private key x and message m, the algorithm generates the signature for m as follows: r = ðg k mod pÞ mod q; z = lmðmin ðN, o utlenÞ, HashðmÞÞ; s = ðk −1 ðz + xrÞÞ mod q. Output the signature ðr, sÞ. Here, lm means the leftmost min ðN, outlenÞ bits of the hash output, where outl en is the bit length of the hash function output block (iii) Signature verification. Given a triplet ðm′, r′, s′Þ, the algorithm verifies the signature as follows: Check that 0 < r ′ < q and 0 < s ′ < q; w = ðs ′ −1 mod qÞ; z = lmð min ðN, outlenÞ, Hashðm ′ ÞÞ; u 1 = ðzwÞ mod q; u 2 = ððr ′ ÞwÞ mod q; and v = ððg u 1 y u 2 Þ mod pÞ mod q. If v = r′, then the signature is verified

DAKEs: The Framework
3.1. Overview. As is shown in Figure 1, we give a decentralized framework for designing authenticated key exchange protocols. In this framework, we have implemented five protocols with different properties. These protocols are DAKE1 to DAKE5. There are two kinds of users in this framework, namely, the originator who starts a protocol at the beginning and the counterparty who communicates with the originator. Thus, O denotes the originator and C denotes the counterparty. The originator O is on the left side of the figure, while the counterparty C is on the right side. The direction of each line with an arrow represents the direction of the data flow. For example, the first line of DAKE1 represents that a random number r is sent from the originator O into the blockchain. And then a group of information r, pk o , id o is by the counterparty C from the blockchain. Before giving the details of each protocol, we will explain the whole design of the framework and the basic notations as follows: (i) Random number. r represents a random number generated under the domain parameters (ii) Public key. pk with a subscript denotes the public key of a user. For example, pk o denotes the originator's public key. Especially, pk R denotes a random public key generated by the user. Since we used the ElGamal encryption and DSS in our framework, the authenticated public key of the originator and the counterparty can also be denoted as the g α and g β separately. Other notations like g ν , g μ , g γ , and g σ are the exponential computation in the ElGamal encryption and DSS. We will give more explanation when describing the specific protocol (iii) Identity. id with a subscript denotes the public key of a user. For example, id o denotes the originator's identity (i) Encryption algorithm. Enc with a subscript denotes an asymmetric encryption algorithm with a public key. For example, Enc o ðmÞ denotes encrypting the message m using the originator's public key. Enc pk R ðmÞ encrypts the message m using the randomly generated public key. E with a subscript denotes a symmetric encryption algorithm using a symmetric secret key. For example, E k ðmÞ denotes encrypting the message m using a symmetry secret key k (iv) Digital signature algorithm. Sig with a subscript denotes a signature algorithm generated by a user. For example, Sig o ðmÞ denotes generating a signature on the message m using the originator's secret key. And the notation δ represents a signature (v) Others. k is the session key shared between O and C. H is a hash function In this framework, we have implemented three smart contracts for the users in the protocols to interact with the blockchain. In the initialization stage, all users 4 Wireless Communications and Mobile Computing submit their identification documents (e.g., passport or drivers license) and their public key for the system. They agree on the security parameters ðG, g, p, q, N, LÞ mentioned in Sections 2.4 and 2.5. Therefore, at the beginning of each protocol, there have been ðIDs, PKs, ParamsÞ on the blockchain where IDs denotes the identities of the users, PKs denotes the public keys, and Params denotes ðG, g, p, q, N, LÞ 3.2. Protocol Design. After the initialization, we can start to design the protocols. Note that when we say send the message to the blockchain "explicitly," anyone in the system can find out the identity of the message receiver. When we say send the message to the blockchain "implicitly," any others cannot get the identity of the message receiver. We will explain how to realize this in the Section 3.3. In this part, we focus the process of the protocols.  Here, the encryption Enc O ðk, id C Þ is used to bind the identity id C and the session key k to the ciphertext c. To avoid a misbinding attack, the encryption algorithm should be able to resist the chosen ciphertext attack (CCA). We use the ElGamal encryption scheme (see Section 2.4) to encapsulate the session key. Let G be a cyclic group, q be the prime order of G, g is a generator of G, IDSpace be the user identity space, and H be a hash function H : G 3 × IDS ⟶ K. Then, we get the implementation of the key exchange protocol DAKE1 as follows: (1) O chooses a random number r, where r ∈ R. Then, he/she sends r to the blockchain explicitly (2) C gets the r, pk O , id O from the blockchain, where p k O = g α and α denotes the secret key of O and then signs on ðr, pk C , id O Þ, namely, δ = Sig C ðr, pk C , id O Þ and sends δ to the blockchain explicitly. At this time, C terminates. He/she gets the session key by com- Similarly, we encapsulate the key by a mechanism corresponding to the ElGamal encryption scheme. Then, we get the implementation of the key exchange protocol DAKE2 as follows: (1) O generates a random public key u = g γ ; signs on u and gets δ 1 = Sig O ðuÞ; and then sends ðu, δ 1 Þ to the blockchain explicitly (2) C gets the u, δ 1 , pk O , id O from the blockchain, verifies the validity of δ 1 , and then generates the signatures δ 2 = Sig C ðu, v = g σ , id O Þ. At last, he/she sends it to the blockchain explicitly. At this time, C gets the session key k by computing k = Hðu, v, u σ , id C Þ (3) O gets the δ 2 , pk C , id C from the blockchain. Then, he/she verifies the validity of δ 2 . If it is valid, O gets the session key k by computing k = Hðu, v, v γ , id C Þ In DAKE3, yhe detailed description of the third protocol is as follows: (1) O uses a key generator algorithm to generate a new random key par ðpk R , sk R Þ and sends pk R to the blockchain implicitly (2) C generates a random session key k and two other random keys k 1 , k 2 for the symmetric encryption E; encrypts ðk, k 1 , k 2 Þ and gets c = E pk R ðk, k 1 , k 2 Þ; signs on ð1, pk R , cÞ and gets δ 1 = Sig C ð1, pk R , cÞ; encrypts ðδ 1 , id C Þ and gets c 1 = E k 1 ðδ 1 , id C Þ; and at last, sends ðc, c 1 Þ to the blockchain implicitly (3) O gets the c, c 1 from the blockchain, decrypts c using the key sk R , and gets k, k 1 , k 2 . Then, O decrypts c 1 using k 1 and gets δ 1 , id C . Then, O gets pk C corresponding to id C from the blockchain and verifies the validity of δ 1 . If it is valid, O computes δ 2 = Si g O ð2, pk R , cÞ, c 2 = E k 2 ðδ 2 , id O Þ and sends c 2 to the blockchain implicitly (4) C decrypts c 2 using the key k 2 and gets δ 2 and id O ; C gets pk O corresponding to id O from the blockchain and verifies the validity of δ 2 As we did for protocols DAKE1 and DAKE2, we can implement protocol AKE3 using ElGamal encryption as follows: (1) O generates a random public key u = g γ and sends u to the blockchain implicitly 6 Wireless Communications and Mobile Computing (2) C gets the u from the blockchain and generates v = g σ . C computes ðk, k 1 , k 2 Þ = Hðg γ , g σ , g γσ Þ, δ 1 = Si g C ð1, u, vÞ, and c 1 = E k 1 ðδ 1 , id C Þ and sends v, c 1 to the blockchain implicitly In DAKE4, the detailed description of the forth protocol is as follows: (1) O generates a random public key g μ and sends it to the blockchain explicitly (2) C gets the g μ , pk O = g α , id O from the blockchain and generates g ν . C computes ðk, k 1 , where g β is C's public key, and sends g ν , k 1 to the blockchain explicitly (3) O gets the g ν , k 1 , pk C = g β , id C from the blockchain and computes ðk, k 1 , k 2 Þ = Hððg β g ν Þ α+μ , ðg ν Þ μ , g α , g μ , g β , g ν , id O , id C Þ; then, O compares its computed value of k 1 to the value it received from the blockchain; if these match, O sends k 2 to the blockchain explicitly (4) C gets k 2 from the blockchain and compares its computed value of k 2 to it In DAKE5, the detailed description of the fifth protocol is as follows: (1) O generates random public keys g σ and g μ ; O computes α′ = α + σ, where g α is O's initial public key on the blockchain. Then, O sends g α ′ , g μ to the blockchain implicitly (2) C gets the g α ′ , g μ from the blockchain and generates ðg τ , g ν Þ; C computes β ′ = β + τ where g β is C's initial public key on the blockchain. Then, C computes ðk, k 1 , k 2 Þ = Hððg α′ g μ Þ ðβ ′ +νÞ , g μν , g α′ , g μ , g β′ , g ν Þ and c 1 ⟵ R E k 1 ðτ, id C Þ and sends g β ′ , g ν , c 1 to the blockchain implicitly (3) O gets the g β ′ , g ν , c 1 from the blockchain and computes ðk, k 1 , k 2 Þ = Hððg β ′ g ν Þ ðα ′ +μÞ , g νμ , g α ′ , g μ , g β ′ , g ν Þ, c 2 ⟵ R E k 2 ðσ, id O Þ. O decrypts c 1 using the key k 1 and gets ðτ, id C Þ. Then, O gets pk C corresponding to id C from the blockchain and verifies g β · g τ = g β ′ ; if it is valid, O sends c 2 to the blockchain implicitly (4) C gets the c 2 from the blockchain decrypts it using the key k 2 ; C obtains ðσ, id O Þ and then gets the corresponding pk O from the blockchain. C verifies g α · g σ = g α ′ 3.3. Smart Contracts. We have given three smart contracts noted as contracts 1, 2, and 3. All the protocols should use the contracts to interact with the blockchain. Specifically, contract 1 provides a way to send the message to the blockchain "explicitly" for DAKE1, DAKE2, and DAKE4. Contract 2 provides a way to send the message to the blockchain "implicitly" for DAEK3. Contract 3 provides a way to send the message to the blockchain "implicitly" for DAEK5. Here, "explicitly" means that anyone in the system can find out the identity of the message receiver, while "implicitly" means that any others cannot get the identity of the message receiver. Now, let us see how to achieve this. As is shown in Table 1, the three smart contracts have common parts in their user data structures. For a user in the system, there is a public key "PK," an identity string "ID," an Ethereum account address "user," and a "timestamp" which is used to indicate whether the public key is expired. These public parameters are set up in the initialization stage and cannot be modified later. The data type "mapping(address ⇒ string)" makes contract 1 different from the other two contracts. We have implemented "set" and "get" interfaces in these contracts separately. For simplicity, we use the pseudocode shown in Algorithms 2 and 3 to give the overall design. An originator can set a communicate message for his/her counterparty by using Algorithm 2. And the counterparty can read the message set by his/her originator by using Algorithm 3.
For contract 1, the inputs of Algorithm 2 are ðiO, iC, r, v ersionÞ, where iO, iC are the public account addresses of the originator and the counterparty separately. r is the data to be exchanged, for example, a random number in DAKE1. Lines 1 to 4 will be executed for contract 1. In Algorithm 3, lines 1 to 4 will be executed for contracts 1 and line 2 to make sure that only the designated counterparty can read the message. Since the data on the blockchain is thought to be public, everyone will find out the identity of the counterparty in the contract 1. Therefore, we say that contract 1 provides a way to send the message to the blockchain "explicitly." Contrarily, for contracts 2 and 3, Algorithm 2 does not designate the account address of the counterparty. The difference between 2 and 3 is that 3 has two other message to record in the blockchain, namely, token1 and token2. c, tok en1, and tonken2 represent the data to be exchanged. For example, in DAKE5 for O, token1 is g α ′ , token2 is g μ , and c is c 2 . And for C, token1 is g β ′ , token2 is g ν , and c is c 1 . This will make sense when we take a look at the detail of the protocols. And since we set the message without pointing out the counterparty address, we say that they provide a way 7 Wireless Communications and Mobile Computing to send the message to the blockchain "implicitly" in contracts 2 and 3.

Soundness and Security Property Analysis
Soundness. The soundness of each protocol is proven if the originator O and the counterparty C obtain an identical session key k at the end of the protocol. In this sense, the soundness of DAKE3, DAKE4, and DAKE5 are quite straight since O and C use the same input of a hash function to compute their session keys. In the implementation of DAKE1, O will get a session key k = Hðpk O , pk C , pk C α , id C Þ, and C will get k = Hðpk O , pk C , pk O β , id C Þ. Since pk C α = g β α = g αβ = pk O β , O and C will hold an identical session key at last. In the implementation of DAKE2, O will get a session key k = Hðu, v, v γ , id C Þ, and C will get k = Hðu, v, u σ , id C Þ. Since v γ = g σγ = g γσ = u σ , O and C will hold an identical session key at last.

Security
Property. Now, we can compare their security properties shown in Table 2 with the other decentralized protocols. SmartDHX [12] only has a security property of Static secrecy since it is actually a Diffie-Hellman key exchange based on blockchain. Apparently, it should assume an honest participant's long-term secret key can never be compromised by the adversary. Besides, smartDHX does not provide any way for the participants to authenticate the identity of their counterparties. Thus, it cannot obtain other security properties.
In Bitcoin-based AKE [4], the authors provide two protocols over Bitcoin. One of them called Diffie-Hellman-over-Bitcoin is a non-interactive protocol without perfect forward secrecy, while another one called YAK-over-Bitcoin is an interactive protocol with perfect forward secrecy. Bitcoinbased AKE uses a Schnorr zero knowledge proof algorithm to provide identity protection and authenticity. However, the deniability is not taken into account.
Protocol DAKE1 only provides static secrecy and implicit authenticity since we are assuming that the long-term keys (initial public key pairs) are never compromised. When O finishes the protocol, he can be confident that C was online since C must have signed the message containing O's random number. However, when C finishes the protocol, he has no such guarantee. Protocol DAKE2 provides perfect forward secrecy since a new key pair for the encryption scheme is generated with each run of the protocol. And user long-term keys are used only for signing, not encrypting. So the adversary cannot    To see the performance of our protocols, we provide the tests on a live network. Rinkeby is the live network we chose. It is a testnet of Ethereum based on proof of authority (PoA) [22]. We used a PC with the OS of Ubuntu Desktop 18.04 64× as a client PC to run the tests. The CPU of this computer is dual-core with intel(R) Core(TM) i7-10510 U CPU @ 1.80GHz 2.30GHz on each. The memory is 4G.

Efficiency Analysis.
In order to give a comprehensive estimation for our authenticated key exchange framework, we first gave the overall performance of each protocol and then provide the test results of the originator and counterparty separately. The reason is that in some applications, the computation and network capability are quite different for the users of the key exchange protocols. For instance, in a payment application, the bank as a server has a more large capability than the clients of the application. In this kind of application, the detailed analysis can help you to choose a proper protocol in our framework. The originator as a client can get a similar efficiency as we showed in the test, while the counterparty as a server may obtain a more efficient performance since he/she can increase his/her computation and network resource.
As is shown in Figure 2, the overall performance of each protocol is quite stable when the size of the security parameters increases from 1024 bits to 3072 bits. According to Table 2, the security properties of the protocols from DAKE1 to DAKE5 increase one by one. Intuitively, a protocol should cost more exchange time for obtaining more properties as well. However, we can find out that there is an exception where protocol DAKE2 has a better performance than DAKE3 in general. To figure out this, we then listed the number of interactions with Ethereum blockchain for each protocol. As shown in Table 3, the letter "q" represents an operation to query data from the blockchain, and the letter "t" means sending a transaction to the blockchain to write data on it. Thus, the "t" operation will take more time than the "q" operation.
Although protocol DAKE3 has an extra cryptographic encryption function than protocol DAKE2, it needs fewer transactions. Besides, we can infer that the time to perform a cryptographic function locally is quite less than to execute a transaction on the blockchain.
Furthermore, when we see the time for the originator and the counterparty separately, we find out that more than one protocol having fewer security properties can obtain quite better performance for one of the participants. The results are given in Figures 3 and 4. Except for the protocol DAKE5, all protocols have obviously distinct costs between the originator and the counterparty. Thus, when the users of the application play different roles and have distinct computation resources, one can choose a more proper protocol according to the performance of the originator and the counterparty. Table 3 can also be used to explain this result.

Gas Cost Analysis.
Like the efficiency analysis, we first gave the overall gas cost of each protocol and then provide the gas cost for the originator and counterparty separately. The gas cost includes deploying a smart contract on the Ethereum blockchain and sending transactions to it. Note that it is costless to query data from the blockchain, namely, the "q" operation is gas-free.
As is shown in Table 4, the gas costs for deployment in protocols DAKE1, DAKE2, and DAKE4 are equal since they use the same smart contract. When the size of the security parameters increases for each protocol, the gas cost for exchange will go higher. It is easy to understand, for a large parameter size means a longer string to exchange. Then, we can take a look at different protocols with identical parameter   10 Wireless Communications and Mobile Computing sizes. We can find out the two highest gas cost protocols are DAKE3 and DAKE5. To figure out this, we can review the protocols in Section 3. The difference between these two protocols with others is that they both need an encryption function which makes their exchange data get larger than others. As is shown in Table 5, the gas cost for the originator and the counterparty of the same protocol in DAKE3, DAKE4, and DAKE5 are equal. Note that the situation in gas cost seems a slice different from that in the efficiency analysis where most protocols have obviously distinct time costs between the originator and the counterparty. It is because both the computation and blockchain network capability will affect the efficiency and the time for completing the protocol may be a little fluctuated. However, the gas cost for executing a transaction is only related to the size of the transaction and is quite stable.

Conclusion
In this paper, we propose a novel decentralized authenticated key exchange framework via blockchain. In this framework, we implement five protocols with different security properties. To the best of our knowledge, our framework is the first one to take different kinds of security properties into account and construct a decentralized authenticated key exchange protocol framework which can be used in different applications in the smart city. To resist the potential threat, we combine the CCA-secure ElGamal encryption algorithm and the digital signature algorithm (DSA) in some of the protocols. Compared with other decentralized key exchange protocols, our protocols enjoy more security properties and get rid of the problem caused by the availability of Bitcoin-like blockchain. Finally, we conduct our test cases in the live testnet of Ethereum and give a comprehensive analysis. The results can help someone who wants to use the proposed framework to choose which protocol is suitable for his application.
Since the decentralization of the proposed protocol framework is based on the blockchain technology, a natural progression of this work is to improve the framework as the blockchain technology evolves. For example, an improved blockchain technology [23] [24] may provide specialized features for IoT to design a more efficient protocol. A further study could assess the compatibility of the protocols in the applications of the smart city. More information about the compatibility of the protocols in the applications of the smart city would help us to establish a greater degree of availability on the protocols.

Data Availability
No data were used to support this study.

Conflicts of Interest
The authors declare that they have no conflicts of interest.