Abstract
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 efficient 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 fulfil 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 efficient and at a low cost.
1. 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 blockchain-based 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.
2. 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 and 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 to generate a random session key effectively and the key can only be known to the counterparty eventually. Secondly, following the protocol, both and will know which person they are exchanging the session key with at the end of the protocol.
2.2. 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 as the originator of the protocol want to exchange a session key with a user as the counterparty of the protocol. In step one, sends a random number and his/her certificate to . In step two, query the certificate of and verify its validity. Then, sign on the data and encrypt the session key data by ’s public key. Eventually, sends to . To attack this, the adversary as a middle man can block the message which send to in step two and replace with . At the end of the protocol, will get a session key , 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. In step one, only sends his/her certificate to without the random number . In step two, sends to . Then, the adversary can use a replay attack like this. First, the adversary collect the message between and , and record . Later, the adversary starts a new exchange with and sends recorded before. Suppose a stream cypher is used later to encrypt the message with the shared key . The adversary then gets two ciphertexts from which encrypts two different messages and . Let encrypt and in the stream cipher. The adversary who gets and can compute . Redundancy in English text makes the adversary able to recover the two messages(3)Identity misbinding attack [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, sends to . In step two, sends to . The adversary can attack this protocol like this. First, the adversary blocks the message which sends to in step one and sends to . Then, the adversary will get from . And he then delivers to . Finally, will deem that is his/her counterpart while is talking to another originator (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 which is encrypted by a unknown string and a secret key , . Then, the adversary can construct a ciphertext , where can be an arbitrary string. can be taken as a legal ciphertext because the decryptor will decrypt it as and . Now assume the length of is -bit, and . The adversary can easily construct an encryption from
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 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 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 and should be sure that they are talking to the other one when sharing the session key . 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 and . At the end of the protocol, the originator can make sure that the counterparty was online following the protocol and hold the same session key with him/her, whereas 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 (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 gets a shared session key from a base station with an AKE protocol, 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 cannot be convincing. For example, with the protocol, the evidence can be generated on own without exchanging with
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 of prime order with generator , the key generator, the encryption algorithm, and the decryption algorithm. (i)Key generator. The key pairs are computed as follows: Randomly choose , where . Then compute (ii)Encryption algorithm. Given and , the algorithm encrypts the message as follows: Randomly choose , where . Compute , , and . Finally, the ciphertext is (iii)Decryption algorithm. Given and , the algorithm decrypts the ciphertext as follows: Compute and
2.5. Digital Signature Algorithm (DSA)
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 has a bit length of , where ; a prime divisor has a bit length of , where and ; a multiplicative group ; a subgroup in with a order of ; a generator of , where ; a randomly choosed private key , where ; the corresponding public key , where ; and a randomly chosen number , where is unique to each message and . The choices for the pair and follow the standard(ii)Signature generation. Given private key and message , the algorithm generates the signature for as follows: ; ; . Output the signature . Here, means the leftmost bits of the hash output, where is the bit length of the hash function output block(iii)Signature verification. Given a triplet , the algorithm verifies the signature as follows: Check that and ; ; ; ; ; and . If , then the signature is verified
3. 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, denotes the originator and denotes the counterparty. The originator is on the left side of the figure, while the counterparty 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 is sent from the originator into the blockchain. And then a group of information is by the counterparty 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. represents a random number generated under the domain parameters(ii)Public key. with a subscript denotes the public key of a user. For example, denotes the originator’s public key. Especially, 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 and separately. Other notations like are the exponential computation in the ElGamal encryption and DSS. We will give more explanation when describing the specific protocol(iii)Identity. with a subscript denotes the public key of a user. For example, denotes the originator’s identity(i)Encryption algorithm. with a subscript denotes an asymmetric encryption algorithm with a public key. For example, denotes encrypting the message using the originator’s public key. encrypts the message using the randomly generated public key. with a subscript denotes a symmetric encryption algorithm using a symmetric secret key. For example, denotes encrypting the message using a symmetry secret key (iv)Digital signature algorithm. with a subscript denotes a signature algorithm generated by a user. For example, denotes generating a signature on the message using the originator’s secret key. And the notation represents a signature(v)Others. is the session key shared between and . 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 submit their identification documents (e.g., passport or drivers license) and their public key for the system. They agree on the security parameters mentioned in Sections 2.4 and 2.5. Therefore, at the beginning of each protocol, there have been on the blockchain where denotes the identities of the users, denotes the public keys, and denotes
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.
In DAKE1, the detailed description of the first protocol is as follows: (1) chooses a random number , where . Then, he/she sends to the blockchain explicitly(2) gets the from the blockchain; chooses a random session key , where ; encrypts using public key, namely ; signs on , namely, ; and sends to the blockchain explicitly. At this time, terminates. He/she gets the session key and his/her counterparty identity (3) gets the from the blockchain and then verifies the validity of using public key. If is a valid signature on the message , decrypts the ciphertext . If the decryption is successful, will gets the session key and his/her counterparty identity id
Here, the encryption is used to bind the identity and the session key to the ciphertext . 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 be a cyclic group, be the prime order of , is a generator of , be the user identity space, and be a hash function . Then, we get the implementation of the key exchange protocol DAKE1 as follows: (1) chooses a random number , where . Then, he/she sends to the blockchain explicitly(2) gets the from the blockchain, where and denotes the secret key of and then signs on , namely, and sends to the blockchain explicitly. At this time, terminates. He/she gets the session key by computing (3) gets the from the blockchain, where and denotes the secret key of . Then, verifies that is a valid signature; if not, aborts; otherwise, terminates and gets the session key by computing
In DAKE2, the detailed description of the second protocol is as follows: (1) uses a key generator algorithm to generate a new random key par . Then he/she signs on and gets . At last, he sends to the blockchain explicitly(2) gets the from the blockchain and verifies the validity of . If it is valid, randomly choose a session key , where . Then, he/she encrypts using the public key and gets . Then, he/she signs on and gets . At last, he/she sends to the blockchain explicitly(3) gets the from the blockchain and then verifies the validity of . If it is valid, decrypts the ciphertext . If the decryption is successful, will get the session key and the counterparty identity id
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) generates a random public key ; signs on and gets ; and then sends to the blockchain explicitly(2) gets the from the blockchain, verifies the validity of and then generates the signatures . At last, he/she sends it to the blockchain explicitly. At this time, gets the session key by computing (3) gets the from the blockchain. Then, he/she verifies the validity of . If it is valid, gets the session key by computing
In DAKE3, yhe detailed description of the third protocol is as follows: (1) uses a key generator algorithm to generate a new random key par and sends to the blockchain implicitly(2) generates a random session key and two other random keys for the symmetric encryption ; encrypts and gets ; signs on and gets ; encrypts and gets ; and at last, sends to the blockchain implicitly(3) gets the from the blockchain, decrypts using the key and gets . Then, decrypts using and gets . Then, gets corresponding to from the blockchain and verifies the validity of . If it is valid, computes , and sends to the blockchain implicitly(4) decrypts using the key and gets and ; gets corresponding to from the blockchain and verifies the validity of
As we did for protocols DAKE1 and DAKE2, we can implement protocol AKE3 using ElGamal encryption as follows: (1) generates a random public key and sends to the blockchain implicitly(2) gets the from the blockchain and generates . computes , , and and sends to the blockchain implicitly(3) gets the from the blockchain and computes . decrypts using the key and gets . Then, gets from the blockchain and verifies the validity of . If it is valid, computes , and sends to the blockchain(4) decrypts using the key and gets and ; gets corresponding to from the blockchain and verifies the validity of
In DAKE4, the detailed description of the forth protocol is as follows: (1) generates a random public key and sends it to the blockchain explicitly(2) gets the from the blockchain and generates . computes , where is ’s public key, and sends to the blockchain explicitly(3) gets the from the blockchain and computes ; then, compares its computed value of to the value it received from the blockchain; if these match, sends to the blockchain explicitly(4) gets from the blockchain and compares its computed value of to it
In DAKE5, the detailed description of the fifth protocol is as follows: (1) generates random public keys and ; computes , where is ’s initial public key on the blockchain. Then, sends to the blockchain implicitly(2) gets the from the blockchain and generates ; computes where is ’s initial public key on the blockchain. Then, computes and and sends to the blockchain implicitly(3) gets the from the blockchain and computes , . decrypts using the key and gets . Then, gets corresponding to from the blockchain and verifies ; if it is valid, sends to the blockchain implicitly(4) gets the from the blockchain decrypts it using the key ; obtains and then gets the corresponding from the blockchain. verifies
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 pseudo-code 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 , where are the public account addresses of the originator and the counterparty separately. 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, and . and represent the data to be exchanged. For example, in DAKE5 for , is , is and is . And for , is , is and is . 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 to send the message to the blockchain “implicitly” in contracts 2 and 3.
| ||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||
4. Soundness and Security Property Analysis
4.1. Soundness
The soundness of each protocol is proven if the originator and the counterparty obtain an identical session key at the end of the protocol. In this sense, the soundness of DAKE3, DAKE4, and DAKE5 are quite straight since and use the same input of a hash function to compute their session keys. In the implementation of DAKE1, will get a session key and will get . Since , and will hold an identical session key at last. In the implementation of DAKE2, will get a session key and will get . Since , and will hold an identical session key at last.
4.2. 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. Bitcoin-based 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 finishes the protocol, he can be confident that was online since must have signed the message containing ’s random number. However, when 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 decrypt any messages by compromising the signing key. DAKE3 provides identity protection and explicit authenticity. If the adversary is not one of the participants, he/she cannot learn the identities of both the participants since they are encrypted in the communication. Although each participant will eventually learn the identity of the other, can withhold his/her identity until confirming the identity of . Thus, we say that DAKE3 has the explicit authenticity property. Note that we do not consider that DAKE3 provides deniability, since and have signed on the message. Even though all messages are encrypted, one of the participants can still collect all the data to prove the existence of another one. Since both the participants sign nothing, DAKE4 provides deniability. DAKE5 has an extra property of Deniability. DAKE4 sends in the clear, while in DAKE5, sends for blinding the value. And the exponent along with are encrypted. can verify the blinding value and use a symmetric method.
5. Implementation and Performance Evaluation
5.1. Implementation
In our implementation, we use smart contracts written in solidity to store and query the public data in the blockchain. The other functions are implemented as Web APIs written in JavaScript. There are several JavaScript open libraries we used. “ethers.js” is used to interact with the Ethereum blockchain. To provide the necessary cryptographic functions, we also imported two other libraries “Crypto.js” and “jsbn.js.” Our test environment is built by a professional tool called HardHat. You can compile, deploy, test, and debug your Ethereum software with HardHat. We run our test cases in Hardhat local network and Rinkeby test network. Once we’re ready to share the decentralized services with other people, what we may want to do is deploy it to a live network. 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.
5.2. 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.
5.3. 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 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.
6. 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.
Acknowledgments
This research was partially supported by the National Key Research and Development Program of China (Grant No. 2019YFE0118700) and Science and Technology Project of China Southern Power Grid Corporation (Grant No. 080036KK52190007).