# An Improved Blockchain-Based Authentication Protocol for IoT Network Management

Authors: Mostafa Yavari; Masoumeh Safkhani; Saru Kumari; Sachin Kumar; Chien-Ming Chen
Journal: Security and Communication Networks
 (2020)

---

## Abstract

Communication security between IoT devices is a major concern in this area, and the blockchain has raised hopes that this concern will be addressed. In the blockchain concept, the majority or even all network nodes check the validity and accuracy of exchanged data before accepting and recording them, whether this data is related to financial transactions or measurements of a sensor or an authentication message. In evaluating the validity of an exchanged data, nodes must reach a consensus in order to perform a special action, in which case the opportunity to enter and record transactions and unreliable interactions with the system is significantly reduced. Recently, in order to share and access management of IoT devices information with distributed attitude a new authentication protocol based on blockchain is proposed and it is claimed that this protocol satisfies user privacy preserving and security. However, in this paper, we show that this protocol has security vulnerabilities against secret disclosure, replay, traceability, andToken reuse attacks with the success probability of 1 and constant complexity of also 1. We also proposed an improved blockchain-based authentication protocol (IBCbAP) that has security properties such as secure access management and anonymity. We implemented IBCbAP using JavaScript programming language and Ethereum local blockchain. We also proved IBCbAP’s security both informally and formally through the Scyther tool. Our comparisons showed that IBCbAP could provide suitable security along with reasonable cost.


---

## Body

## 1. Introduction

With the advent of Internet of Things (IoT) technologies, a large number of intelligent devices have been developed and integrated into daily life [1–5]. By increasing number of devices and users, current architecture and the communication protocols (centralized system) cannot give enough response to system requirements such as authentication, authorization, and access management. Although security and privacy are important issues in communication, various solutions have been proposed for security and privacy in Internet of Things (IoT) networks [6–12]. One of the important solutions is use of distributed networks instead of centralized or decentralized networks [13–20]. A new and powerful distributed system is blockchain [21] which for the first time proposed by Satoshi Nakamoto. Blockchain is a technology comprising few old concepts, such as the ledger and the consensus (the agreement of members of a group on an issue). This technology combines these concepts with the help of a peer-to-peer network to access a distributed database with privacy preserving and security properties. Blockchain has many security features such as integrity, distribution, and tamper-proofing. In a blockchain network, all network members take part in the verification process of information which takes part in the alternative role of the trusted third party (TTP) on the system. It is very difficult to manipulate information because of public surveillance of information. Public surveillance is done by a method called consensus that means 51% of network members need to collaborate to unauthorized changes in the information. Distributing the role of the TTP among network members has also reduced the likelihood of distributed denial of service (DDoS) attacks. As a result, system security is ensured. In contrast, the processing amount and system messages sent to the members of each node in the network are very high. Also, because of the transparency of all information, privacy preserving becomes difficult and new solutions are needed and these solutions should not impede the consensus process. Another problem is its low scalability because of the fixed and unchangeable data and setting. Therefore, the cost of changing some parts of the blockchain network is much more than building a new network. As a result, the cost of upgrading the system is very high.In this regard, Cha et al. in [22] have presented an authentication scheme for the IoT using blockchain, claiming that their protocol has made it possible for users to access and manage IoT device information with privacy. In fact, they claimed that their protocol was able to establish user privacy and trust in IoT applications. In this paper, we show that the protocol designed by Cha et al. has drawbacks that make their design vulnerable to various attacks such as secret disclosure, traceability, replay, and reuse of Token attacks, which leads to loss of privacy and trust. Security analysis of the Cha et al.’s protocol before use prevents a lot of possible damage. It also makes designers aware of such errors in protocol design and avoid repeating them in their designs. In this paper, we also offer suggestions for troubleshooting this protocol. Using these suggestions, we provide an improved version of the protocol in terms of security and cost, which is called IBCbAP.


### 1.1. Main Contribution

The contributions of the paper are as follows:(1)
Presenting security weaknesses of Cha et al. blockchain-based authentication and secure management of privacy preferences scheme.(2)
Addressing security pitfalls of Cha et al.’s scheme and proposing a new improved one called IBCbAP.(3)
Formal and informal security analysis of IBCbAP. Formal proofing is done using the Scyther tool.(4)
Implementation of IBCbAP through JavaScript language and Ethereum local blockchain and considering its functionality and correctness.


### 1.2. Paper Organization

We organize the rest of the paper as follows. In Section2, we will look at related works on the blending of two technologies of blockchain and IoT and also provide some explanations on their security requirements and existing issues. We review the Cha et al.’s blockchain-based authentication protocol and describe its security pitfalls in Sections 3 and 4, respectively. In Section 5, we propose a new improved protocol called IBCbAP and describe its security and functionality features. We analyze the security and functionality of IBCbAP in Sections 6 and 7, respectively. In Section 8, we compare the proposed protocol in terms of the type of blockchain used, the implementation platform, and security features with other related authentication schemes in this area, and at last Section 9 concludes the paper with concluding remarks and suggestions for future works.


## 1.1. Main Contribution

The contributions of the paper are as follows:(1)
Presenting security weaknesses of Cha et al. blockchain-based authentication and secure management of privacy preferences scheme.(2)
Addressing security pitfalls of Cha et al.’s scheme and proposing a new improved one called IBCbAP.(3)
Formal and informal security analysis of IBCbAP. Formal proofing is done using the Scyther tool.(4)
Implementation of IBCbAP through JavaScript language and Ethereum local blockchain and considering its functionality and correctness.


## 1.2. Paper Organization

We organize the rest of the paper as follows. In Section2, we will look at related works on the blending of two technologies of blockchain and IoT and also provide some explanations on their security requirements and existing issues. We review the Cha et al.’s blockchain-based authentication protocol and describe its security pitfalls in Sections 3 and 4, respectively. In Section 5, we propose a new improved protocol called IBCbAP and describe its security and functionality features. We analyze the security and functionality of IBCbAP in Sections 6 and 7, respectively. In Section 8, we compare the proposed protocol in terms of the type of blockchain used, the implementation platform, and security features with other related authentication schemes in this area, and at last Section 9 concludes the paper with concluding remarks and suggestions for future works.


## 2. Related Works and Preliminaries

This section addresses the important security requirements for access control systems in the IoT networks and briefly presents a few related works. Since we used the blockchain to store critical information securely in our proposed protocol, the definition of blockchain technology and how it works are also explained in this section. Also, we briefly explain the smart contract and its usage in our proposed protocol. Finally, we will talk about how the blockchain was used in the related works.


### 2.1. Blockchain

Blockchain was proposed in 2008 by Satoshi Nakamoto [21]. Blockchain includes blocks where blocks are interconnected like a chain. Each block contains information such as block number, the hash of the previous block, a nonce, and transaction information. By storing the hash of the previous block in each block, the chain will be formed. This chain is called the ledger. Figure 1 shows a simple example of the blockchain ledger. Each node in the network has its ledger. Blockchain uses consensus mechanisms [23, 24] to verify the transaction and update the entire ledger. At the time of adding a new transaction in the ledger, all nodes in the network will check the correctness of the information and, after approving, will add the new transaction to their ledger. Each user subscribes to the network by registering a pair of public and private keys on the network. This is done by recording a transaction. Each user’s keys are stored in their wallet. Miners created the blocks. Miners are nodes in the network, tasked with generating and approving blocks to the blockchain. To generate a block, the corresponding node solves a difficult problem, and the one who solves the problem sooner registers its block in the blockchain. Changing an approved block in the ledger is costly and difficult. There are two types of blockchain: public and private. In a public blockchain, anyone can participate in the block generation and consensus process, but in a private blockchain, only preapproved nodes can do this operation. Bitcoin [21] and Ethereum [25] are examples of the public type, and Hyperledger [26] is an example of the private type blockchain.Figure 1
Chain of blocks in the blockchain technology [21].


### 2.2. Smart Contract

Smart contracts are executable codes and memories, which are stored as transactions in the blockchain. Smart contracts are executed by miners with a fixed cost. By knowing the transaction address, it is possible to call the smart contract for the network members. Because blockchain is irremovable, smart contracts can provide a great deal of confidence. One of the famous blockchains, which is a smart contract provider, is Ethereum [25]. In the Ethereum network, any member can create a smart contract and share it with anyone. In this paper, we use the testRPC [27] to implement the blockchain network. This library creates a local Ethereum blockchain network.


### 2.3. Related Work

In the following, we introduce several related kinds of research which have tried to use blockchain’s security features, such as distribution, integrity, and tamper-proof properties to create security and privacy in communications protocols. The first blockchain is provided by Bitcoin [21], which stores financial transactions about coins. In Bitcoin, if the transactions change, it can store identity information and access policies. Ouaddah et al. designed a system to maintain privacy and security in a distributed manner, which is their main idea [28]. A problem with Ouaddah et al.’s design is the high computational cost for network members. Novo [29], by decreasing of distribution, has attempted the computations to fit the resources of the devices. Novo separated the blockchain network from the general network and communicates with the devices using management hubs. This solution boosts performance and reduces distribution. Compared to Ouaddah et al.’s design, it boosts computational power to devices and increases the probability of distributed denial of service (DDoS) attacks. In Novo’s protocol, miners cannot be a member of the network just cooperating to the blockchain network. The high computational load results from the block generation process. Using the lighter block generation process, we can efficiently use the blockchain network in the Internet of Things (IoT). Dorri et al. proposed a method for the block generation process and consensus, which is based on the limitation of the number of blocks generated per unit time per node [30]. Dorri et al. have claimed that the proposed method is scalable and provides a proportional computational burden to network members. In their scheme, miners are members of the network and their number and membership are changed based on few parameters. Dorri et al. used smart homes network scenario. The interior management of each home is done by a central point inside the house, and it is described in [31]. Lin et al. by using blockchain, ABS (Attribute-Based Signature), and MRE (Multi-Receiver Encryption) have proposed a system for managing industrial devices and data collection [32]. In fact, Lin et al.’s protocol is presented for the development of industry V.4 by blockchain. The structure of Lin et al.’s protocol has five entities, including terminals, blockchain, cloud, industrial network, and physical resources. In this scheme, commands are stored by the terminals at blockchain. The cloud and industrial network monitor the blockchain and find the commands and then perform the operations. Lin et al. have used distributed reductions to adapt their protocol to IoT conditions.Hammi et al. have proposed a system to authenticate and authorize IoT devices that also meet security requirements such as confidentiality and integrity. They based the main idea behind their scheme on the use of blockchain security benefits and the segmentation of system components into unique areas. In these areas, known as bubbles, all members are allowed to communicate with their bubble members and identify other bubble members as attackers. ECDLP (Elliptic Curve Discrete Logarithm Problem) based cryptography is used by Hammi et al. This system has appeared in highly practical results, and the authors emphasized that they have achieved very satisfactory results. Xie et al. in [33] used the blockchain to improve security and privacy on the Internet of Vehicles (IoV) and transportation systems using 5G-VANET [34]. In Xie et al.’s scheme, all RSU (Road Side Unit-5G-Station–Vehicle) members are connected and controlled by a central SDN (Software Defined Network) controller. The number of messages sent by any vehicle and the message authorization status are stored in the blockchain. In this scheme, transactions are unchangeable and the vehicles cannot deny sending. As a result, as the error coefficient of a vehicle increases, the miners define more restrictions on the transmission of the vehicle transaction, which will increase system’s security. In fact, in their scheme vehicles with data encryption protect privacy. Huang et al. have introduced a system for controlling access to device resources according to device policies in [35]. The overall structure of Huang et al.’s scheme is very similar to the overall structure of Cha et al.’s scheme. Huang et al. used DAG (Directed Acyclic Graph)-based blockchains [36]. DAG-based blockchains are suitable for IoT applications because of their lightness and high speed. Also, Huang et al. have proposed a consensus method. In their proposed consensus method, the nodes have a credit value which comprises two variables: node activity and node honesty. The difficulty of the problem solved in block generation is inversely related to the credit value. The speed of storing a device’s transactions depends on its credit value. By reducing the credit value of a malicious device, the cost and time of attack increase. Yao et al. introduced a lightweight blockchain-based authentication system in [37]. Yao et al. specifically recommends this system for using in distributed vehicular fog servers. Yao et al. have enabled one-time authentication to access the services. They used the blockchain to store authentication history and reauthentication is selected by the devices. Sidorov et al. have proposed a blockchain-based supply chain system in [38]. They have used RFID tags to track products and also have used blockchain as a trusted third party. Sidorov et al. have claimed that they created a high level of privacy and security. The used blockchain type in the Sidorov et al.’s system is private and messages are encrypted only using rotation operation, XOR (Exclusive OR) operation, and HW (Hamming Weight) function. Dwivedi et al. have provided a blockchain-based healthcare system in [39]. The need for privacy preserving and distribution in healthcare systems is justifiable reasons for using blockchain in this plan. Dwivedi et al.’s scheme has used cloud and smart contracts, which are used to store patient data and analyze data according to the instructions of the healthcare provider. They used blockchain to secure the information in the cloud and keep track of changes. In Dwivedi et al.’s scheme, the patient sends information to the smart contract by wearing and using IoT devices and the smart contract decides according to the healthcare provider orders and notifies the relevant doctor.As seen in this section, many attempts have been made to integrate blockchain technology with the IoT. All of these efforts lead to the growth and maturity of blockchain use in the Internet of Things [40–43]. An example is Cha et al.’s scheme [22], in which the authentication of IoT devices is done through blockchain. In this paper, we show that Cha et al.’s designed structure has its drawbacks and we offer solutions to address them.


## 2.1. Blockchain

Blockchain was proposed in 2008 by Satoshi Nakamoto [21]. Blockchain includes blocks where blocks are interconnected like a chain. Each block contains information such as block number, the hash of the previous block, a nonce, and transaction information. By storing the hash of the previous block in each block, the chain will be formed. This chain is called the ledger. Figure 1 shows a simple example of the blockchain ledger. Each node in the network has its ledger. Blockchain uses consensus mechanisms [23, 24] to verify the transaction and update the entire ledger. At the time of adding a new transaction in the ledger, all nodes in the network will check the correctness of the information and, after approving, will add the new transaction to their ledger. Each user subscribes to the network by registering a pair of public and private keys on the network. This is done by recording a transaction. Each user’s keys are stored in their wallet. Miners created the blocks. Miners are nodes in the network, tasked with generating and approving blocks to the blockchain. To generate a block, the corresponding node solves a difficult problem, and the one who solves the problem sooner registers its block in the blockchain. Changing an approved block in the ledger is costly and difficult. There are two types of blockchain: public and private. In a public blockchain, anyone can participate in the block generation and consensus process, but in a private blockchain, only preapproved nodes can do this operation. Bitcoin [21] and Ethereum [25] are examples of the public type, and Hyperledger [26] is an example of the private type blockchain.Figure 1
Chain of blocks in the blockchain technology [21].


## 2.2. Smart Contract

Smart contracts are executable codes and memories, which are stored as transactions in the blockchain. Smart contracts are executed by miners with a fixed cost. By knowing the transaction address, it is possible to call the smart contract for the network members. Because blockchain is irremovable, smart contracts can provide a great deal of confidence. One of the famous blockchains, which is a smart contract provider, is Ethereum [25]. In the Ethereum network, any member can create a smart contract and share it with anyone. In this paper, we use the testRPC [27] to implement the blockchain network. This library creates a local Ethereum blockchain network.


## 2.3. Related Work

In the following, we introduce several related kinds of research which have tried to use blockchain’s security features, such as distribution, integrity, and tamper-proof properties to create security and privacy in communications protocols. The first blockchain is provided by Bitcoin [21], which stores financial transactions about coins. In Bitcoin, if the transactions change, it can store identity information and access policies. Ouaddah et al. designed a system to maintain privacy and security in a distributed manner, which is their main idea [28]. A problem with Ouaddah et al.’s design is the high computational cost for network members. Novo [29], by decreasing of distribution, has attempted the computations to fit the resources of the devices. Novo separated the blockchain network from the general network and communicates with the devices using management hubs. This solution boosts performance and reduces distribution. Compared to Ouaddah et al.’s design, it boosts computational power to devices and increases the probability of distributed denial of service (DDoS) attacks. In Novo’s protocol, miners cannot be a member of the network just cooperating to the blockchain network. The high computational load results from the block generation process. Using the lighter block generation process, we can efficiently use the blockchain network in the Internet of Things (IoT). Dorri et al. proposed a method for the block generation process and consensus, which is based on the limitation of the number of blocks generated per unit time per node [30]. Dorri et al. have claimed that the proposed method is scalable and provides a proportional computational burden to network members. In their scheme, miners are members of the network and their number and membership are changed based on few parameters. Dorri et al. used smart homes network scenario. The interior management of each home is done by a central point inside the house, and it is described in [31]. Lin et al. by using blockchain, ABS (Attribute-Based Signature), and MRE (Multi-Receiver Encryption) have proposed a system for managing industrial devices and data collection [32]. In fact, Lin et al.’s protocol is presented for the development of industry V.4 by blockchain. The structure of Lin et al.’s protocol has five entities, including terminals, blockchain, cloud, industrial network, and physical resources. In this scheme, commands are stored by the terminals at blockchain. The cloud and industrial network monitor the blockchain and find the commands and then perform the operations. Lin et al. have used distributed reductions to adapt their protocol to IoT conditions.Hammi et al. have proposed a system to authenticate and authorize IoT devices that also meet security requirements such as confidentiality and integrity. They based the main idea behind their scheme on the use of blockchain security benefits and the segmentation of system components into unique areas. In these areas, known as bubbles, all members are allowed to communicate with their bubble members and identify other bubble members as attackers. ECDLP (Elliptic Curve Discrete Logarithm Problem) based cryptography is used by Hammi et al. This system has appeared in highly practical results, and the authors emphasized that they have achieved very satisfactory results. Xie et al. in [33] used the blockchain to improve security and privacy on the Internet of Vehicles (IoV) and transportation systems using 5G-VANET [34]. In Xie et al.’s scheme, all RSU (Road Side Unit-5G-Station–Vehicle) members are connected and controlled by a central SDN (Software Defined Network) controller. The number of messages sent by any vehicle and the message authorization status are stored in the blockchain. In this scheme, transactions are unchangeable and the vehicles cannot deny sending. As a result, as the error coefficient of a vehicle increases, the miners define more restrictions on the transmission of the vehicle transaction, which will increase system’s security. In fact, in their scheme vehicles with data encryption protect privacy. Huang et al. have introduced a system for controlling access to device resources according to device policies in [35]. The overall structure of Huang et al.’s scheme is very similar to the overall structure of Cha et al.’s scheme. Huang et al. used DAG (Directed Acyclic Graph)-based blockchains [36]. DAG-based blockchains are suitable for IoT applications because of their lightness and high speed. Also, Huang et al. have proposed a consensus method. In their proposed consensus method, the nodes have a credit value which comprises two variables: node activity and node honesty. The difficulty of the problem solved in block generation is inversely related to the credit value. The speed of storing a device’s transactions depends on its credit value. By reducing the credit value of a malicious device, the cost and time of attack increase. Yao et al. introduced a lightweight blockchain-based authentication system in [37]. Yao et al. specifically recommends this system for using in distributed vehicular fog servers. Yao et al. have enabled one-time authentication to access the services. They used the blockchain to store authentication history and reauthentication is selected by the devices. Sidorov et al. have proposed a blockchain-based supply chain system in [38]. They have used RFID tags to track products and also have used blockchain as a trusted third party. Sidorov et al. have claimed that they created a high level of privacy and security. The used blockchain type in the Sidorov et al.’s system is private and messages are encrypted only using rotation operation, XOR (Exclusive OR) operation, and HW (Hamming Weight) function. Dwivedi et al. have provided a blockchain-based healthcare system in [39]. The need for privacy preserving and distribution in healthcare systems is justifiable reasons for using blockchain in this plan. Dwivedi et al.’s scheme has used cloud and smart contracts, which are used to store patient data and analyze data according to the instructions of the healthcare provider. They used blockchain to secure the information in the cloud and keep track of changes. In Dwivedi et al.’s scheme, the patient sends information to the smart contract by wearing and using IoT devices and the smart contract decides according to the healthcare provider orders and notifies the relevant doctor.As seen in this section, many attempts have been made to integrate blockchain technology with the IoT. All of these efforts lead to the growth and maturity of blockchain use in the Internet of Things [40–43]. An example is Cha et al.’s scheme [22], in which the authentication of IoT devices is done through blockchain. In this paper, we show that Cha et al.’s designed structure has its drawbacks and we offer solutions to address them.


## 3. Cha et al.’s Blockchain-Based Protocol

In this section, we explain Cha et al.’s blockchain-based protocol [22] and its security analysis including secret disclosure, replay, traceability, and reuse Token attacks.


### 3.1. Cha et al.’s Protocol

Recently, in [22], Cha et al. proposed a new authentication protocol based on blockchain for share and access management of IoT device information as a distributed attitude. In this protocol, there are three main entities called device, user, and blockchain connected gateway (BCG). Devices are the nodes in the network that share information or resources with conditions called Device policy, and other users, device, or people who want to use the information and resources of the devices. BCG is an intermediary between the device and the user. These gateways assess users’ eligibility (permissions and authentication) to use the information and resources of the devices according to policies.We use the scenario described in [22] to explain communication and process sequencing. In this scenario, each user joins the blockchain network and registers its public and private key pair. The BCGs and administrator of devices deploy their smart contract in the blockchain network. Authentication processes and access policies management are done by smart contracts. In this scenario, each device is connected to a BCG. This connection is a logical connection and saved in the device and in the BCG smart contracts. When a device connects to a BCG, it can be said that access to device information is done by this BCG.As shown in Figure2, the user first finds the BCG smart contract address and then accesses the list of subset devices. To use any device, the user must declare their agreement with the device’s privacy policies. This agreement is stored in the blockchain network so that the BCG can be used at the time of request for access to device information by the user.Figure 2
Overview of Cha et al.’s blockchain-based authentication protocol.


#### 3.1.1. Smart Contracts

Here, we explain the implicit smart contract and their obligations in Cha et al.’s authentication protocol. Interactions between the device and the BCG (logical communication), control of device information and privacy policies and BCG management are all done through smart contracts. As shown in Figure3, the communication between the devices and the BCG is recorded in the blockchain and is done through it. We can say the blockchain plays the role of a trusted third party (TTP). Therefore, there is no possibility of manipulating or violating information for the protocol’s parties.Figure 3
Device binding communications in Cha et al.’s blockchain-based authentication protocol.


#### 3.1.2. Cha et al.’s Proposed Signature

The signature used in [22] is based on ECDLP (Elliptic Curve Discrete Logarithm Problem) and has six steps including SETUP, SET-PARTIAL-PRIVATE-KEY, SET-SECRET-VALUE, SET-PUBLIC-KEY, SIGN, and VERIFY. These steps by using notations represented in Table 1 will be briefly discussed in the following subsections and also are shown in Figure 4.Table 1
Summary of notations used in this paper.
NotationDescriptionqPrime orderG1,G2Cyclic groups with the same prime orderqeBilinear pairing mapG1∗G1⟶G2PGenerator ofG1sMaster private keyPKBCGBCG public key, i.e.,s.PH,H1Hash functionsH2,H3IDiUserUi’s identitySKdbcgShared key between the device and the BCGmMessageEK.Symmetric encryption functionPjDevice policyPPjConsent of thePj policyTijTimestampsKUiPjNiGenerated key between BCG and userUiPKiUser’s public keyru,rd,rbRandom numbers generated by user, device, and BCG, respectivelyTIDijTransaction address added to blockchain because of acceptance policyPj by Ui userNiRandom numbersSKubcgShared key between the user and the BCGriRandom numbers‖ConcatenationFigure 4
Cha et al.’s proposed signature.(1) Setup. In the first step, according to the secret value of k, the BCG selects two groups of G1 and G2 with the same q prime order. The relationship between G1 and G2 is e:G1∗G1⟶G2, where P is the generator of G1. G1 has bilinear pairing attribute, so the following relationship exists:(1)∀m,n∈Zq∗,∀S,P∈G1:emS,nP=eS,Pmn.The BCG selects its private and public key pair ass∈Zq∗ and PKBCG=s.P, respectively. Also BCG chooses three hash functions with definitions H1:0,1∗×G1⟶Zq∗, H2:0,1∗×G1×G1⟶Zq∗ and H3:0,1∗×G1×G1×G1⟶Zq∗, and ultimately the values of G1,G2,q,e,P,PKBCG,H1,H2,H3,eP,P are published by the BCG.(2) Set-Partial-Private-Key. In this step, the BCG calculates Ri, hi, si, and σi1 values as below:(2)Ri=ri·P,hi=H1IDi,Ri,PKBCG,si=ri+hi·smodq,σi1=si−1·P.In the above calculations, a random numberri∈Zq∗ is used which is generated using public parameters, master private key, and the user Ui’s identity IDi. After that, BCG sends Ri,σi1 to the user; the user once receives the messages immediately checks eσi1,Ri+hi.PKBCG==?eP,P, where hi=H1IDi,Ri,PKBCG.(3) Set-Secret-Value. In this step, the user selects a random number as his private key. This key is notated with xi∈Zq∗ .(4) Set-Public-Key. In this step, the user using his secret key, i.e., xi, generates his public key as PKi=xi.P.(5) Sign. At the beginning of this step, the user calculates the amount of ki=H2IDi,PKi,Ri,PKBCG,m, where m is the message to be signed, and calculates σi2=ki.si+xi−1.P. At the end, the user sends m,Ri,σi2 to the verifier.(6) Verify. In this step, the verifier computes the value of hi as H1IDi,Ri,PKBCG using the values of PKi and received m,Ri,σi2. After that, the verifier calculates ki as H2IDi,PKi,Ri,PKBCG,m and verifies the correctness of signature by checking whether eσi2,ki.Ri+hi.PKBCG+PKi==?eP,P. If the condition is fulfilled, the signer is authentic.


#### 3.1.3. Device Binding

The user sends a consent of the device policiesPPj to the BCG. Each BCG has a root key. The user’s public key PKi is also specified. The BCG initially generates a random number (nonce Ni) and then, using this value, the public key of the user, BCG root key, and a hash function H, generates a key KUiPjNi. The combination of user consent, policy Pj, and timestamp Tij are encrypted with the generated key and then stored in the blockchain. The BCG sends the transaction IDTIDij and the generated key to the user because the user is sure of its accuracy. In future communications, stored information is the basis for licensing access to the device. Figure 5 illustrates the device binding of Cha et al.’s protocol.Figure 5
Cha et al.’s protocol: device binding phase.


#### 3.1.4. Access to the Device

Figure6 illustrates how the user is accessing the device. The implications of Figure 6 will be discussed in the following.(i)
The user generates a signature for the access request messagePPj using si=ri+hi.s, Ri=ri.P, hi=H1IDi,Ri,PKBCG, xi, PKi, PPj, Kij=H2IDi,PKi,Ri,PKBCG,PPj as σij=kij.si+xi−1 and sends PPj,Ri,σij to the BCG.Once the BCG receives the message, it checks the authenticity of the signature by checking whethereσij,kij.Ri+hi.PKBCG+PKi==?eP,P or not. If so, the BCG generates a random value rij∈Zq∗ and then calculates Rij=rij.P, lij=H1IDi,Rij,σij,PKBCG, sij=rij+lij, σBCG=sij−1.P and at last the BCG sends Rij,σBCG to the user in response.After receivingRij,σBCG from the BCG, the user verifies the validity of the received values by computing lij=H1IDi,Rij,σij,PKBCG and checking whether eσBCG,Rij+lij.PKBCG==?eP,P or not. If the accuracy of the received information is verified, the access Token is calculated as below:(3)Token=PPj,Ri,σij,Rij,σBCG.Figure 6
Cha et al.’s protocol: access to device phase.Finally, the user may use the device by sendingToken to the device. Access permission depends on the result of verifying the validity of the received Token by the device.


## 3.1. Cha et al.’s Protocol

Recently, in [22], Cha et al. proposed a new authentication protocol based on blockchain for share and access management of IoT device information as a distributed attitude. In this protocol, there are three main entities called device, user, and blockchain connected gateway (BCG). Devices are the nodes in the network that share information or resources with conditions called Device policy, and other users, device, or people who want to use the information and resources of the devices. BCG is an intermediary between the device and the user. These gateways assess users’ eligibility (permissions and authentication) to use the information and resources of the devices according to policies.We use the scenario described in [22] to explain communication and process sequencing. In this scenario, each user joins the blockchain network and registers its public and private key pair. The BCGs and administrator of devices deploy their smart contract in the blockchain network. Authentication processes and access policies management are done by smart contracts. In this scenario, each device is connected to a BCG. This connection is a logical connection and saved in the device and in the BCG smart contracts. When a device connects to a BCG, it can be said that access to device information is done by this BCG.As shown in Figure2, the user first finds the BCG smart contract address and then accesses the list of subset devices. To use any device, the user must declare their agreement with the device’s privacy policies. This agreement is stored in the blockchain network so that the BCG can be used at the time of request for access to device information by the user.Figure 2
Overview of Cha et al.’s blockchain-based authentication protocol.


### 3.1.1. Smart Contracts

Here, we explain the implicit smart contract and their obligations in Cha et al.’s authentication protocol. Interactions between the device and the BCG (logical communication), control of device information and privacy policies and BCG management are all done through smart contracts. As shown in Figure3, the communication between the devices and the BCG is recorded in the blockchain and is done through it. We can say the blockchain plays the role of a trusted third party (TTP). Therefore, there is no possibility of manipulating or violating information for the protocol’s parties.Figure 3
Device binding communications in Cha et al.’s blockchain-based authentication protocol.


### 3.1.2. Cha et al.’s Proposed Signature

The signature used in [22] is based on ECDLP (Elliptic Curve Discrete Logarithm Problem) and has six steps including SETUP, SET-PARTIAL-PRIVATE-KEY, SET-SECRET-VALUE, SET-PUBLIC-KEY, SIGN, and VERIFY. These steps by using notations represented in Table 1 will be briefly discussed in the following subsections and also are shown in Figure 4.Table 1
Summary of notations used in this paper.
NotationDescriptionqPrime orderG1,G2Cyclic groups with the same prime orderqeBilinear pairing mapG1∗G1⟶G2PGenerator ofG1sMaster private keyPKBCGBCG public key, i.e.,s.PH,H1Hash functionsH2,H3IDiUserUi’s identitySKdbcgShared key between the device and the BCGmMessageEK.Symmetric encryption functionPjDevice policyPPjConsent of thePj policyTijTimestampsKUiPjNiGenerated key between BCG and userUiPKiUser’s public keyru,rd,rbRandom numbers generated by user, device, and BCG, respectivelyTIDijTransaction address added to blockchain because of acceptance policyPj by Ui userNiRandom numbersSKubcgShared key between the user and the BCGriRandom numbers‖ConcatenationFigure 4
Cha et al.’s proposed signature.(1) Setup. In the first step, according to the secret value of k, the BCG selects two groups of G1 and G2 with the same q prime order. The relationship between G1 and G2 is e:G1∗G1⟶G2, where P is the generator of G1. G1 has bilinear pairing attribute, so the following relationship exists:(1)∀m,n∈Zq∗,∀S,P∈G1:emS,nP=eS,Pmn.The BCG selects its private and public key pair ass∈Zq∗ and PKBCG=s.P, respectively. Also BCG chooses three hash functions with definitions H1:0,1∗×G1⟶Zq∗, H2:0,1∗×G1×G1⟶Zq∗ and H3:0,1∗×G1×G1×G1⟶Zq∗, and ultimately the values of G1,G2,q,e,P,PKBCG,H1,H2,H3,eP,P are published by the BCG.(2) Set-Partial-Private-Key. In this step, the BCG calculates Ri, hi, si, and σi1 values as below:(2)Ri=ri·P,hi=H1IDi,Ri,PKBCG,si=ri+hi·smodq,σi1=si−1·P.In the above calculations, a random numberri∈Zq∗ is used which is generated using public parameters, master private key, and the user Ui’s identity IDi. After that, BCG sends Ri,σi1 to the user; the user once receives the messages immediately checks eσi1,Ri+hi.PKBCG==?eP,P, where hi=H1IDi,Ri,PKBCG.(3) Set-Secret-Value. In this step, the user selects a random number as his private key. This key is notated with xi∈Zq∗ .(4) Set-Public-Key. In this step, the user using his secret key, i.e., xi, generates his public key as PKi=xi.P.(5) Sign. At the beginning of this step, the user calculates the amount of ki=H2IDi,PKi,Ri,PKBCG,m, where m is the message to be signed, and calculates σi2=ki.si+xi−1.P. At the end, the user sends m,Ri,σi2 to the verifier.(6) Verify. In this step, the verifier computes the value of hi as H1IDi,Ri,PKBCG using the values of PKi and received m,Ri,σi2. After that, the verifier calculates ki as H2IDi,PKi,Ri,PKBCG,m and verifies the correctness of signature by checking whether eσi2,ki.Ri+hi.PKBCG+PKi==?eP,P. If the condition is fulfilled, the signer is authentic.


### 3.1.3. Device Binding

The user sends a consent of the device policiesPPj to the BCG. Each BCG has a root key. The user’s public key PKi is also specified. The BCG initially generates a random number (nonce Ni) and then, using this value, the public key of the user, BCG root key, and a hash function H, generates a key KUiPjNi. The combination of user consent, policy Pj, and timestamp Tij are encrypted with the generated key and then stored in the blockchain. The BCG sends the transaction IDTIDij and the generated key to the user because the user is sure of its accuracy. In future communications, stored information is the basis for licensing access to the device. Figure 5 illustrates the device binding of Cha et al.’s protocol.Figure 5
Cha et al.’s protocol: device binding phase.


### 3.1.4. Access to the Device

Figure6 illustrates how the user is accessing the device. The implications of Figure 6 will be discussed in the following.(i)
The user generates a signature for the access request messagePPj using si=ri+hi.s, Ri=ri.P, hi=H1IDi,Ri,PKBCG, xi, PKi, PPj, Kij=H2IDi,PKi,Ri,PKBCG,PPj as σij=kij.si+xi−1 and sends PPj,Ri,σij to the BCG.Once the BCG receives the message, it checks the authenticity of the signature by checking whethereσij,kij.Ri+hi.PKBCG+PKi==?eP,P or not. If so, the BCG generates a random value rij∈Zq∗ and then calculates Rij=rij.P, lij=H1IDi,Rij,σij,PKBCG, sij=rij+lij, σBCG=sij−1.P and at last the BCG sends Rij,σBCG to the user in response.After receivingRij,σBCG from the BCG, the user verifies the validity of the received values by computing lij=H1IDi,Rij,σij,PKBCG and checking whether eσBCG,Rij+lij.PKBCG==?eP,P or not. If the accuracy of the received information is verified, the access Token is calculated as below:(3)Token=PPj,Ri,σij,Rij,σBCG.Figure 6
Cha et al.’s protocol: access to device phase.Finally, the user may use the device by sendingToken to the device. Access permission depends on the result of verifying the validity of the received Token by the device.


## 3.1.1. Smart Contracts

Here, we explain the implicit smart contract and their obligations in Cha et al.’s authentication protocol. Interactions between the device and the BCG (logical communication), control of device information and privacy policies and BCG management are all done through smart contracts. As shown in Figure3, the communication between the devices and the BCG is recorded in the blockchain and is done through it. We can say the blockchain plays the role of a trusted third party (TTP). Therefore, there is no possibility of manipulating or violating information for the protocol’s parties.Figure 3
Device binding communications in Cha et al.’s blockchain-based authentication protocol.


## 3.1.2. Cha et al.’s Proposed Signature

The signature used in [22] is based on ECDLP (Elliptic Curve Discrete Logarithm Problem) and has six steps including SETUP, SET-PARTIAL-PRIVATE-KEY, SET-SECRET-VALUE, SET-PUBLIC-KEY, SIGN, and VERIFY. These steps by using notations represented in Table 1 will be briefly discussed in the following subsections and also are shown in Figure 4.Table 1
Summary of notations used in this paper.
NotationDescriptionqPrime orderG1,G2Cyclic groups with the same prime orderqeBilinear pairing mapG1∗G1⟶G2PGenerator ofG1sMaster private keyPKBCGBCG public key, i.e.,s.PH,H1Hash functionsH2,H3IDiUserUi’s identitySKdbcgShared key between the device and the BCGmMessageEK.Symmetric encryption functionPjDevice policyPPjConsent of thePj policyTijTimestampsKUiPjNiGenerated key between BCG and userUiPKiUser’s public keyru,rd,rbRandom numbers generated by user, device, and BCG, respectivelyTIDijTransaction address added to blockchain because of acceptance policyPj by Ui userNiRandom numbersSKubcgShared key between the user and the BCGriRandom numbers‖ConcatenationFigure 4
Cha et al.’s proposed signature.(1) Setup. In the first step, according to the secret value of k, the BCG selects two groups of G1 and G2 with the same q prime order. The relationship between G1 and G2 is e:G1∗G1⟶G2, where P is the generator of G1. G1 has bilinear pairing attribute, so the following relationship exists:(1)∀m,n∈Zq∗,∀S,P∈G1:emS,nP=eS,Pmn.The BCG selects its private and public key pair ass∈Zq∗ and PKBCG=s.P, respectively. Also BCG chooses three hash functions with definitions H1:0,1∗×G1⟶Zq∗, H2:0,1∗×G1×G1⟶Zq∗ and H3:0,1∗×G1×G1×G1⟶Zq∗, and ultimately the values of G1,G2,q,e,P,PKBCG,H1,H2,H3,eP,P are published by the BCG.(2) Set-Partial-Private-Key. In this step, the BCG calculates Ri, hi, si, and σi1 values as below:(2)Ri=ri·P,hi=H1IDi,Ri,PKBCG,si=ri+hi·smodq,σi1=si−1·P.In the above calculations, a random numberri∈Zq∗ is used which is generated using public parameters, master private key, and the user Ui’s identity IDi. After that, BCG sends Ri,σi1 to the user; the user once receives the messages immediately checks eσi1,Ri+hi.PKBCG==?eP,P, where hi=H1IDi,Ri,PKBCG.(3) Set-Secret-Value. In this step, the user selects a random number as his private key. This key is notated with xi∈Zq∗ .(4) Set-Public-Key. In this step, the user using his secret key, i.e., xi, generates his public key as PKi=xi.P.(5) Sign. At the beginning of this step, the user calculates the amount of ki=H2IDi,PKi,Ri,PKBCG,m, where m is the message to be signed, and calculates σi2=ki.si+xi−1.P. At the end, the user sends m,Ri,σi2 to the verifier.(6) Verify. In this step, the verifier computes the value of hi as H1IDi,Ri,PKBCG using the values of PKi and received m,Ri,σi2. After that, the verifier calculates ki as H2IDi,PKi,Ri,PKBCG,m and verifies the correctness of signature by checking whether eσi2,ki.Ri+hi.PKBCG+PKi==?eP,P. If the condition is fulfilled, the signer is authentic.


## 3.1.3. Device Binding

The user sends a consent of the device policiesPPj to the BCG. Each BCG has a root key. The user’s public key PKi is also specified. The BCG initially generates a random number (nonce Ni) and then, using this value, the public key of the user, BCG root key, and a hash function H, generates a key KUiPjNi. The combination of user consent, policy Pj, and timestamp Tij are encrypted with the generated key and then stored in the blockchain. The BCG sends the transaction IDTIDij and the generated key to the user because the user is sure of its accuracy. In future communications, stored information is the basis for licensing access to the device. Figure 5 illustrates the device binding of Cha et al.’s protocol.Figure 5
Cha et al.’s protocol: device binding phase.


## 3.1.4. Access to the Device

Figure6 illustrates how the user is accessing the device. The implications of Figure 6 will be discussed in the following.(i)
The user generates a signature for the access request messagePPj using si=ri+hi.s, Ri=ri.P, hi=H1IDi,Ri,PKBCG, xi, PKi, PPj, Kij=H2IDi,PKi,Ri,PKBCG,PPj as σij=kij.si+xi−1 and sends PPj,Ri,σij to the BCG.Once the BCG receives the message, it checks the authenticity of the signature by checking whethereσij,kij.Ri+hi.PKBCG+PKi==?eP,P or not. If so, the BCG generates a random value rij∈Zq∗ and then calculates Rij=rij.P, lij=H1IDi,Rij,σij,PKBCG, sij=rij+lij, σBCG=sij−1.P and at last the BCG sends Rij,σBCG to the user in response.After receivingRij,σBCG from the BCG, the user verifies the validity of the received values by computing lij=H1IDi,Rij,σij,PKBCG and checking whether eσBCG,Rij+lij.PKBCG==?eP,P or not. If the accuracy of the received information is verified, the access Token is calculated as below:(3)Token=PPj,Ri,σij,Rij,σBCG.Figure 6
Cha et al.’s protocol: access to device phase.Finally, the user may use the device by sendingToken to the device. Access permission depends on the result of verifying the validity of the received Token by the device.


## 4. Security Analysis of Cha et al.’s Blockchain-Based Authentication Protocol

In this section, we will investigate Cha et al.’s protocol’s security. This analysis includes the presentation of security attacks. We have applied four attacks on Cha et al.’s protocol comprising secret disclosure, replay, traceability, and reuseToken attacks. This section describes how the attacks are performed, their success probability and complexity, and a solution to prevent the occurrence of the attacks. We base the proposed protocol on these solutions.


### 4.1. The Adversary Model

Here, we used the common adversary model [44–48] in which the adversary can fully control and eavesdrop the public communication channel. So, he/she can eavesdrop, replay, modify, and delete any message or fabricate a new message.


### 4.2. Secret Disclosure Attack

According to (3), the Token is generated by the values of the sent messages. Since Cha et al. do not consider the channel secure, the attacker can eavesdrop the transferred messages through the channel. As a result, generating Token by the attacker is only possible through the eavesdropping of the channel, resulting in threats to the device’s resources and security. For this attack, the attacker proceeds as below:(1)
The attacker eavesdrops transferred messages for one run of the access to device phase of Cha et al.’s protocol(2)
UsingPPj,Ri, σij, Rij, and σBCG which eavesdropped in access to device phase of Cha et al.’s protocol, the attacker can calculate Token as PPj,Rj,σij,σBCG(3)
Using calculatedToken in the previous step, the attacker can access and use the intended IoT deviceThe success probability of the attack is 1 and its complexity is one run of the protocol. We will fix this weakness in our proposed protocol, i.e., IBCbAP. To solve this problem, we do signature using HMAC (Hash-Based Message Authentication Code) function and ECDLP (Elliptic Curve Discrete Logarithm Problem) encryption. Their details will be explained inSection 5.2.


### 4.3. Replay Attack

Because of the absence of new random values in each session, messages from each session are not different from other sessions, so a message is acceptable in all sessions. The attacker can gain BCG approval by sending messages sniffed in previous sessions and impersonating the user. The steps of this attack are as follows:(1)
The attacker eavesdrops one session and storesPPj,Ri,σij message as N′(2)
The attacker starts a new session with BCG by sendingN′ to the BCG(3)
BCG checks correctness ofN′ and because of the mentioned weakness in Cha et al.’s protocol, BCG confirms the authenticity of the information(4)
BCG sendsRij,σBCG to the attacker(5)
The attacker accesses the device.This attack is possible with the success probability of one and complexity of only one run of protocol’s eavesdropping.


### 4.4. Traceability Attack

Because of the absence of nonces or timestamp in Cha et al.’s protocol’s transferred messages, all of them are static, so it is possible for the attacker to trace the protocol parties using the content of the transferred messages. For this attack, it is enough for the attacker to proceed as below:(1)
The attacker eavesdrops one run of protocol and stores the transferred messages(2)
The attacker getsRi related to Ui user, notated Ri′(3)
After that, if the attacker sniffs the protocol messages and compares theRi with Ri′, he/she can determine whether the message is for the Ui user or not, so recognizing the userThe attacker can detect a user, with the probability of 1 and the complexity of eavesdropping one run of the protocol. This attack is possible because in Cha et al.’s protocol, theRi=ri.P is calculated only once and does not change in each session. By adding random nonces or timestamp to messages which are generated by all protocol parties, messages sent in each session are different, and the possibility of tracing users is vanishing.


### 4.5. Reuse Token Attack

Cha et al. in [22] did not explain their method for verifying the Token (in (3)) by the device. Also, despite the existing parameters in the protocol messages, the device cannot ensure that the Token has not duplicated and is correct. In other words, the user or attacker by receiving a Token can use the device’s resources unlimitedly, and the BCG or device cannot detect this situation. This is because no fresh variable (such as random numbers or timestamps) is used in the Token and the device has no role in creating the Token. So, by getting a Token, the attacker and a malicious user can use the Token repeatedly and any members of the network do not figure out. This issue causes the abuse of device resources and violates the claim made by Cha et al. to manage privacy policies. We will solve this problem by using random numbers in each Token separately which are generated by all members who take part in the network. In the next section, we will address all of abovementioned vulnerabilities which lead to proposing an improved version of Cha et al.’s blockchain-based authentication protocol called IBCbAP. We also will conduct formal security analysis and informal security analysis of IBCbAP. Formal proof will be done using the Scyther tool. To show the functionality of IBCbAP, we will implement it by JavaScript language and the Ethereum local blockchain network.


## 4.1. The Adversary Model

Here, we used the common adversary model [44–48] in which the adversary can fully control and eavesdrop the public communication channel. So, he/she can eavesdrop, replay, modify, and delete any message or fabricate a new message.


## 4.2. Secret Disclosure Attack

According to (3), the Token is generated by the values of the sent messages. Since Cha et al. do not consider the channel secure, the attacker can eavesdrop the transferred messages through the channel. As a result, generating Token by the attacker is only possible through the eavesdropping of the channel, resulting in threats to the device’s resources and security. For this attack, the attacker proceeds as below:(1)
The attacker eavesdrops transferred messages for one run of the access to device phase of Cha et al.’s protocol(2)
UsingPPj,Ri, σij, Rij, and σBCG which eavesdropped in access to device phase of Cha et al.’s protocol, the attacker can calculate Token as PPj,Rj,σij,σBCG(3)
Using calculatedToken in the previous step, the attacker can access and use the intended IoT deviceThe success probability of the attack is 1 and its complexity is one run of the protocol. We will fix this weakness in our proposed protocol, i.e., IBCbAP. To solve this problem, we do signature using HMAC (Hash-Based Message Authentication Code) function and ECDLP (Elliptic Curve Discrete Logarithm Problem) encryption. Their details will be explained inSection 5.2.


## 4.3. Replay Attack

Because of the absence of new random values in each session, messages from each session are not different from other sessions, so a message is acceptable in all sessions. The attacker can gain BCG approval by sending messages sniffed in previous sessions and impersonating the user. The steps of this attack are as follows:(1)
The attacker eavesdrops one session and storesPPj,Ri,σij message as N′(2)
The attacker starts a new session with BCG by sendingN′ to the BCG(3)
BCG checks correctness ofN′ and because of the mentioned weakness in Cha et al.’s protocol, BCG confirms the authenticity of the information(4)
BCG sendsRij,σBCG to the attacker(5)
The attacker accesses the device.This attack is possible with the success probability of one and complexity of only one run of protocol’s eavesdropping.


## 4.4. Traceability Attack

Because of the absence of nonces or timestamp in Cha et al.’s protocol’s transferred messages, all of them are static, so it is possible for the attacker to trace the protocol parties using the content of the transferred messages. For this attack, it is enough for the attacker to proceed as below:(1)
The attacker eavesdrops one run of protocol and stores the transferred messages(2)
The attacker getsRi related to Ui user, notated Ri′(3)
After that, if the attacker sniffs the protocol messages and compares theRi with Ri′, he/she can determine whether the message is for the Ui user or not, so recognizing the userThe attacker can detect a user, with the probability of 1 and the complexity of eavesdropping one run of the protocol. This attack is possible because in Cha et al.’s protocol, theRi=ri.P is calculated only once and does not change in each session. By adding random nonces or timestamp to messages which are generated by all protocol parties, messages sent in each session are different, and the possibility of tracing users is vanishing.


## 4.5. Reuse Token Attack

Cha et al. in [22] did not explain their method for verifying the Token (in (3)) by the device. Also, despite the existing parameters in the protocol messages, the device cannot ensure that the Token has not duplicated and is correct. In other words, the user or attacker by receiving a Token can use the device’s resources unlimitedly, and the BCG or device cannot detect this situation. This is because no fresh variable (such as random numbers or timestamps) is used in the Token and the device has no role in creating the Token. So, by getting a Token, the attacker and a malicious user can use the Token repeatedly and any members of the network do not figure out. This issue causes the abuse of device resources and violates the claim made by Cha et al. to manage privacy policies. We will solve this problem by using random numbers in each Token separately which are generated by all members who take part in the network. In the next section, we will address all of abovementioned vulnerabilities which lead to proposing an improved version of Cha et al.’s blockchain-based authentication protocol called IBCbAP. We also will conduct formal security analysis and informal security analysis of IBCbAP. Formal proof will be done using the Scyther tool. To show the functionality of IBCbAP, we will implement it by JavaScript language and the Ethereum local blockchain network.


## 5. IBCbAP: The Improved Protocol

Here, we improve Cha et al.’s protocol’s weaknesses by using the HMAC function instead of Cha et al.’s proposed signature. We named the proposed protocol IBCbAP (Improved Blockchain-based Authentication Protocol). According to [49], the speed and memory consumption in an ECDLP (Elliptic Curve Discrete Logarithm Problem) encryption are less than RSA. Therefore, we use the ECDLP encryption method. We do the initial setting and selection of constant values just like Cha et al.’s protocol. As shown in Figures 7 and 8, respectively, the steps of IBCbAP are as below.(i)
Confirm access policy phase: In this phase, the user, after finding device policy by associated BCG, sends its consent to device policies to the BCG. Also, the BCG generates aSKubcga secret key and shares with the user. In this phase, the used channel is secure.(ii)
Create accessToken phase: In this phase, the BCG creates a Token for the user for using the device. Token is generated by the user, the device, and the BCG participants securely. The key used in this phase is generated in the Confirm access policy phase in which the used channel is secure.Figure 7
IBCbAP: Confirm access policy phase.Figure 8
IBCbAP: Create accessToken phase.


### 5.1. Confirm Access Policy

In the first step, the user needs to find the device access policiesPj and agree to them. To accept the device policy, he/she sends a message PPj to the BCG according to the policy. The BCG generates a nonce Ni upon which it receives PPj. The shared key between the device and the BCG SKubcg is created using the equation below:(4)SKubcg=HIDiNiSKBCG.This key is used in subsequent messages whereH is a hash function, and SKBCG is a secret value associated with the BCG. The Pj, PPj, and a timestamp T are encrypted using the generated key and stored as a transaction in the blockchain. The transaction address TIDij along with the SKubcg is sent to the user through the secure channel. It is worth noting that the channel between the BCG and the user is secure.


### 5.2. Create Access Token

The user accesses the device through the following steps:(i)
The user producesPPj=ESKubcgTIDij‖ru, where TIDij, ru, and SKubcg are the transaction number associated with accepting device policies, a random number, and a shared secret key between himself and the BCG, respectively. The user sends PPj,ru to the device.(ii)
The device once receives the message, generates a random numberrd, and computes Msig=HMACrurdPPj,SKdbcg and sends Msig,rd,ru,PPj to the BCG.(iii)
Upon receipt of the message, the BCG generates a signatureMsig′=HMACrurdPPj,SKdbcg and compares it with the received signature Msig. The continuation of the protocol is related to the satisfying Msig′=Msig condition. BCG decrypts the PPj and ensures the user’s claim using the blockchain network. In the next step, the BCG generates another random number rb and the value of Msig′′=HMACrbruTIDij,SKubcg. And finally, it sends Msig′′,rb to the user.(iv)
Once the user received theMsig′′,rb message, it verifies the authority of the BCG. This is accomplished by checking whether Msig′′==?HMACrbruTIDij,SKubcg or not. The device already knows the value of ru , TIDij, and SKubcg. The continuation of the protocol is conditional upon the generated signature of the user and the signature from the BCG. In the following, the user generates a signed message as Nsig=HMACrb,SKubcg and sends it to the BCG.(v)
The BCG checks whetherNsig=?Nsig′, where Nsig′=HMACrb,SKubcg. If so, it creates access Token and computes ESKubcgToken‖ru and sends it to the user. Also, it computes ESKdbcgToken‖rd and sends it to the device.When the user receives the messageESKubcgToken‖ru and decrypts it with the key SKubcg, if obtained ru is equal to its one, the user trusts the received Token. The same is true for the device.


## 5.1. Confirm Access Policy

In the first step, the user needs to find the device access policiesPj and agree to them. To accept the device policy, he/she sends a message PPj to the BCG according to the policy. The BCG generates a nonce Ni upon which it receives PPj. The shared key between the device and the BCG SKubcg is created using the equation below:(4)SKubcg=HIDiNiSKBCG.This key is used in subsequent messages whereH is a hash function, and SKBCG is a secret value associated with the BCG. The Pj, PPj, and a timestamp T are encrypted using the generated key and stored as a transaction in the blockchain. The transaction address TIDij along with the SKubcg is sent to the user through the secure channel. It is worth noting that the channel between the BCG and the user is secure.


## 5.2. Create Access Token

The user accesses the device through the following steps:(i)
The user producesPPj=ESKubcgTIDij‖ru, where TIDij, ru, and SKubcg are the transaction number associated with accepting device policies, a random number, and a shared secret key between himself and the BCG, respectively. The user sends PPj,ru to the device.(ii)
The device once receives the message, generates a random numberrd, and computes Msig=HMACrurdPPj,SKdbcg and sends Msig,rd,ru,PPj to the BCG.(iii)
Upon receipt of the message, the BCG generates a signatureMsig′=HMACrurdPPj,SKdbcg and compares it with the received signature Msig. The continuation of the protocol is related to the satisfying Msig′=Msig condition. BCG decrypts the PPj and ensures the user’s claim using the blockchain network. In the next step, the BCG generates another random number rb and the value of Msig′′=HMACrbruTIDij,SKubcg. And finally, it sends Msig′′,rb to the user.(iv)
Once the user received theMsig′′,rb message, it verifies the authority of the BCG. This is accomplished by checking whether Msig′′==?HMACrbruTIDij,SKubcg or not. The device already knows the value of ru , TIDij, and SKubcg. The continuation of the protocol is conditional upon the generated signature of the user and the signature from the BCG. In the following, the user generates a signed message as Nsig=HMACrb,SKubcg and sends it to the BCG.(v)
The BCG checks whetherNsig=?Nsig′, where Nsig′=HMACrb,SKubcg. If so, it creates access Token and computes ESKubcgToken‖ru and sends it to the user. Also, it computes ESKdbcgToken‖rd and sends it to the device.When the user receives the messageESKubcgToken‖ru and decrypts it with the key SKubcg, if obtained ru is equal to its one, the user trusts the received Token. The same is true for the device.


## 6. IBCbAP Security Analysis

In this section, we consider the security of IBCbAP informally and also formally. We perform the formal security checking using the Scyther tool [50].


### 6.1. Informal Security Analysis

Here, we informally prove that the improved protocol can resist against different attacks. Informal analysis is based on the knowledge and creativity of the analyst.


#### 6.1.1. Resistance to DDoS Attack

Because of using blockchain, the architecture of the system moves toward distribution architecture. The distribution of a system reduces the probability of the DDoS attack. However, because of the lack of participation of IoT devices in the blockchain network and IoT devices connected to the blockchain network by BCG, the distribution of the system decreases. IoT devices cannot directly participate in blockchain network, because many resources are needed for this purpose. Due to the use of blockchain as the trusted third party (TTP) and the distribution of IoT devices between different BCGs, the possibility of a DDoS attack on the system is reduced. Also, since keys are not changed at each session and the existence of different keys per user for each device, the possibility of changing values and system desynchronization is eliminated.


#### 6.1.2. Resistance to Replay Attack

Since, in the proposed protocol, all members of the network participate in the Create accessToken phase, the possibility of the replay attack is eliminated. Existence of shared secret values SKubcg,SKdbcg between protocol parties and use of freshly random values ru,rd,rb by protocol parties lead each session’s messages to be different from previous sessions messages; as a result, the possibility of the replay attack vanishes.


#### 6.1.3. Resistance to Secret Disclosure Attack

Important messages sent between the user and the BCG are encrypted by a shared key, such asToken which is encrypted as ESKubcgToken‖ru. We also encrypt important messages sent between the device and the BCG, such as Token, using a shared secret value, i.e., ESKdbcgToken‖rd. Due to the encryption of messages in the session, important information remains confidential. Also, the existence of shared secret values allows the protocol members to generate the message authentication code such as Msig and Nsig, so they can authenticate each other and avoid sending the data to an unauthorized party.


#### 6.1.4. Resistance to Traceability Attack

As mentioned before, because of the involvement of random numbers in all transferred messages and changing these random numbers in each session, the attacker cannot find any fixed value. As a result, the attacker is not capable of tracing protocol’s parties using protocol’s transferred messages. Also, it is not possible for the attacker to reveal any data in the current session, by eavesdropping the previous transferred messages because of the lack of correlation between messages sent in each session.


#### 6.1.5. Unlinkability of Device

In the proposed protocol, we issue a separate key for each device. Each user is required to process, accept policies phase, and create an accessToken phase to use each device independently. We can say that the user uses a separate Token for each device, so with the disclosure of a Token, other devices are not threatened.


### 6.2. Formal Security Analysis

We have used the Scyther tool to check out the formal security of our proposed bockchain-based authentication protocol. The Scyther is created with Python [51] language and works according to security claims. Claim events are used in role specifications to model intended security properties [52]. There are several predefined claim types in the Scyther tool which are represented in Table 2.Table 2
Claim events which defined in the Scyther tool.
ClaimDescriptionSecretThere is no unauthorized access to the parameters transmitted in the protocol. For example,claimInitiator,Secret,n means that the value of n remains confidential in the sense of initiator, and the third party has not been able to access it.AliveclaimR,alive,R′ means that R′ is always on the line and is linked to R. In fact, the presence and survival of R′ are requested by R.WeakagreeIt ensures that the receiver has received message at the time that was sent by the sender. There is no agreement on the data transmitted.NiagreeclaimR,Niagree,R′ claims that the agreed values between the receiver and the transmitter will remain unchanged.NisynchclaimR,Nisynch,R′ claims that each message sent by the sender R corresponds to receiving the message by the receiver, and all the steps are executed correctly and without interruption.We have used Nisynch, Niagree, and Secret claims. The Nisynch claim checks desynchronization possibility. Niagree claim considers that an agreement will not commit to the changed values between the parties and the Secret claim states that the amount referred to it is secret. IBCbAP written in the Scyther language, i.e., security protocol description language (spdl) with three roles, i.e., user, device, and blockchain connected gateway, and security claims along with the output of the Scyther tool for its security verification are shown in Figures9 and 10, respectively.Figure 9
Scyther implementation of IBCbAP in the spdl.Figure 10
IBCbAP’s security analysis result, by the Scyther tool.As you can see in Figure10, the Scyther tool could not find an attack for IBCbAP. Therefore, IBCbAP provides a good level of security.


## 6.1. Informal Security Analysis

Here, we informally prove that the improved protocol can resist against different attacks. Informal analysis is based on the knowledge and creativity of the analyst.


### 6.1.1. Resistance to DDoS Attack

Because of using blockchain, the architecture of the system moves toward distribution architecture. The distribution of a system reduces the probability of the DDoS attack. However, because of the lack of participation of IoT devices in the blockchain network and IoT devices connected to the blockchain network by BCG, the distribution of the system decreases. IoT devices cannot directly participate in blockchain network, because many resources are needed for this purpose. Due to the use of blockchain as the trusted third party (TTP) and the distribution of IoT devices between different BCGs, the possibility of a DDoS attack on the system is reduced. Also, since keys are not changed at each session and the existence of different keys per user for each device, the possibility of changing values and system desynchronization is eliminated.


### 6.1.2. Resistance to Replay Attack

Since, in the proposed protocol, all members of the network participate in the Create accessToken phase, the possibility of the replay attack is eliminated. Existence of shared secret values SKubcg,SKdbcg between protocol parties and use of freshly random values ru,rd,rb by protocol parties lead each session’s messages to be different from previous sessions messages; as a result, the possibility of the replay attack vanishes.


### 6.1.3. Resistance to Secret Disclosure Attack

Important messages sent between the user and the BCG are encrypted by a shared key, such asToken which is encrypted as ESKubcgToken‖ru. We also encrypt important messages sent between the device and the BCG, such as Token, using a shared secret value, i.e., ESKdbcgToken‖rd. Due to the encryption of messages in the session, important information remains confidential. Also, the existence of shared secret values allows the protocol members to generate the message authentication code such as Msig and Nsig, so they can authenticate each other and avoid sending the data to an unauthorized party.


### 6.1.4. Resistance to Traceability Attack

As mentioned before, because of the involvement of random numbers in all transferred messages and changing these random numbers in each session, the attacker cannot find any fixed value. As a result, the attacker is not capable of tracing protocol’s parties using protocol’s transferred messages. Also, it is not possible for the attacker to reveal any data in the current session, by eavesdropping the previous transferred messages because of the lack of correlation between messages sent in each session.


### 6.1.5. Unlinkability of Device

In the proposed protocol, we issue a separate key for each device. Each user is required to process, accept policies phase, and create an accessToken phase to use each device independently. We can say that the user uses a separate Token for each device, so with the disclosure of a Token, other devices are not threatened.


## 6.1.1. Resistance to DDoS Attack

Because of using blockchain, the architecture of the system moves toward distribution architecture. The distribution of a system reduces the probability of the DDoS attack. However, because of the lack of participation of IoT devices in the blockchain network and IoT devices connected to the blockchain network by BCG, the distribution of the system decreases. IoT devices cannot directly participate in blockchain network, because many resources are needed for this purpose. Due to the use of blockchain as the trusted third party (TTP) and the distribution of IoT devices between different BCGs, the possibility of a DDoS attack on the system is reduced. Also, since keys are not changed at each session and the existence of different keys per user for each device, the possibility of changing values and system desynchronization is eliminated.


## 6.1.2. Resistance to Replay Attack

Since, in the proposed protocol, all members of the network participate in the Create accessToken phase, the possibility of the replay attack is eliminated. Existence of shared secret values SKubcg,SKdbcg between protocol parties and use of freshly random values ru,rd,rb by protocol parties lead each session’s messages to be different from previous sessions messages; as a result, the possibility of the replay attack vanishes.


## 6.1.3. Resistance to Secret Disclosure Attack

Important messages sent between the user and the BCG are encrypted by a shared key, such asToken which is encrypted as ESKubcgToken‖ru. We also encrypt important messages sent between the device and the BCG, such as Token, using a shared secret value, i.e., ESKdbcgToken‖rd. Due to the encryption of messages in the session, important information remains confidential. Also, the existence of shared secret values allows the protocol members to generate the message authentication code such as Msig and Nsig, so they can authenticate each other and avoid sending the data to an unauthorized party.


## 6.1.4. Resistance to Traceability Attack

As mentioned before, because of the involvement of random numbers in all transferred messages and changing these random numbers in each session, the attacker cannot find any fixed value. As a result, the attacker is not capable of tracing protocol’s parties using protocol’s transferred messages. Also, it is not possible for the attacker to reveal any data in the current session, by eavesdropping the previous transferred messages because of the lack of correlation between messages sent in each session.


## 6.1.5. Unlinkability of Device

In the proposed protocol, we issue a separate key for each device. Each user is required to process, accept policies phase, and create an accessToken phase to use each device independently. We can say that the user uses a separate Token for each device, so with the disclosure of a Token, other devices are not threatened.


## 6.2. Formal Security Analysis

We have used the Scyther tool to check out the formal security of our proposed bockchain-based authentication protocol. The Scyther is created with Python [51] language and works according to security claims. Claim events are used in role specifications to model intended security properties [52]. There are several predefined claim types in the Scyther tool which are represented in Table 2.Table 2
Claim events which defined in the Scyther tool.
ClaimDescriptionSecretThere is no unauthorized access to the parameters transmitted in the protocol. For example,claimInitiator,Secret,n means that the value of n remains confidential in the sense of initiator, and the third party has not been able to access it.AliveclaimR,alive,R′ means that R′ is always on the line and is linked to R. In fact, the presence and survival of R′ are requested by R.WeakagreeIt ensures that the receiver has received message at the time that was sent by the sender. There is no agreement on the data transmitted.NiagreeclaimR,Niagree,R′ claims that the agreed values between the receiver and the transmitter will remain unchanged.NisynchclaimR,Nisynch,R′ claims that each message sent by the sender R corresponds to receiving the message by the receiver, and all the steps are executed correctly and without interruption.We have used Nisynch, Niagree, and Secret claims. The Nisynch claim checks desynchronization possibility. Niagree claim considers that an agreement will not commit to the changed values between the parties and the Secret claim states that the amount referred to it is secret. IBCbAP written in the Scyther language, i.e., security protocol description language (spdl) with three roles, i.e., user, device, and blockchain connected gateway, and security claims along with the output of the Scyther tool for its security verification are shown in Figures9 and 10, respectively.Figure 9
Scyther implementation of IBCbAP in the spdl.Figure 10
IBCbAP’s security analysis result, by the Scyther tool.As you can see in Figure10, the Scyther tool could not find an attack for IBCbAP. Therefore, IBCbAP provides a good level of security.


## 7. IBCbAP Implementation

We have implemented IBCbAP to test the functionality and the feasibility of implementation with existing technologies. We have used JavaScript in the form of Nodejs [53] technology to simulate the proposed protocol. The reason for this choice is WEB3.js [54] library to contact blockchain. This library uses the RPC (Remote Procedure Call) protocol to interact with blockchain nodes. The system used in this simulation includes features such as 4 GB RAM, 1 TB HDD, and Core i7 2.47 GHz CPU.


### 7.1. Confirm Access Policy

The implemented architecture has four participants (user, BCG, device, and blockchain network). User to usePj device sends the PPj to the BCG and then receives the shared key between itself and BCG SKubcg through a secure channel. How to generate SKubcg is explained in Section 5.2. The user uses this key in the create access Token phase. At the Confirm access policy phase, the channel is secure. We run this phase 10 times and took 1363 milliseconds. Most of the time spent in this phase is due to storing the user information in the blockchain. A view of connecting to the device and confirming the device steps are shown in Figures 11 and 12, respectively.Figure 11
The graphical user interface of implemented IBCbAP: Connect to device.Figure 12
The graphical user interface of implemented IBCbAP: Accept device by the user.


### 7.2. Create AccessToken

Figure8 shows the Create access Token phase. At this phase, the user starts the process of issuing the access Token by sending ru and PPj to the device. According to what was mentioned in Section 5.2, the device starts the Token creation process when the user receives the message. Finally, BCG creates a Token and sends it as ESKubcgToken‖ru to the user and as ESKdbcgToken‖rd to the device. We performed this phase 10 times and have a total time of 1200 milliseconds. The major time consumed at this phase is related to encryption operations. Figure 13 shows the graphical user interface indicating successful receipt of the Token from BCG.Figure 13
The graphical user interface of implemented IBCbAP: successful receipt of theToken from BCG.


### 7.3. Ethereum Network

To implement the blockchain network, we have used the testRPC [27] library. This library creates a local blockchain network. Figure 14 illustrates the launch of this library. The testRPC default creates 10 accounts when building a local blockchain. We use one of these accounts. We used Remix tool to deploy the initial smart contract of the BCG, and Solidity language wrote the smart contract (see Figure 15). It is worth noting that the smart contract used is simplified and is suitable for implementing Confirm access policy and Create access Token phase. We used the Crypto [55] library and the sha256 algorithm to generate HMAC. We used the ecccrypto [56] library to perform ECC encryption. Also, we used the Express [57] framework to build the server for each protocol party. It should be noted that we set up the servers for each protocol party and blockchain network on a single system on separate ports. As a result, each phase is short. So, here we have shown it is possible to implement the proposed protocol with existing technologies and facilities. It is worth noting that we achieve measured times with only one device, one user, and one port.Figure 14
Creation of Ethereum local network by launching testRPC library.Figure 15
Creating smart contract in IBCbAP.


## 7.1. Confirm Access Policy

The implemented architecture has four participants (user, BCG, device, and blockchain network). User to usePj device sends the PPj to the BCG and then receives the shared key between itself and BCG SKubcg through a secure channel. How to generate SKubcg is explained in Section 5.2. The user uses this key in the create access Token phase. At the Confirm access policy phase, the channel is secure. We run this phase 10 times and took 1363 milliseconds. Most of the time spent in this phase is due to storing the user information in the blockchain. A view of connecting to the device and confirming the device steps are shown in Figures 11 and 12, respectively.Figure 11
The graphical user interface of implemented IBCbAP: Connect to device.Figure 12
The graphical user interface of implemented IBCbAP: Accept device by the user.


## 7.2. Create AccessToken

Figure8 shows the Create access Token phase. At this phase, the user starts the process of issuing the access Token by sending ru and PPj to the device. According to what was mentioned in Section 5.2, the device starts the Token creation process when the user receives the message. Finally, BCG creates a Token and sends it as ESKubcgToken‖ru to the user and as ESKdbcgToken‖rd to the device. We performed this phase 10 times and have a total time of 1200 milliseconds. The major time consumed at this phase is related to encryption operations. Figure 13 shows the graphical user interface indicating successful receipt of the Token from BCG.Figure 13
The graphical user interface of implemented IBCbAP: successful receipt of theToken from BCG.


## 7.3. Ethereum Network

To implement the blockchain network, we have used the testRPC [27] library. This library creates a local blockchain network. Figure 14 illustrates the launch of this library. The testRPC default creates 10 accounts when building a local blockchain. We use one of these accounts. We used Remix tool to deploy the initial smart contract of the BCG, and Solidity language wrote the smart contract (see Figure 15). It is worth noting that the smart contract used is simplified and is suitable for implementing Confirm access policy and Create access Token phase. We used the Crypto [55] library and the sha256 algorithm to generate HMAC. We used the ecccrypto [56] library to perform ECC encryption. Also, we used the Express [57] framework to build the server for each protocol party. It should be noted that we set up the servers for each protocol party and blockchain network on a single system on separate ports. As a result, each phase is short. So, here we have shown it is possible to implement the proposed protocol with existing technologies and facilities. It is worth noting that we achieve measured times with only one device, one user, and one port.Figure 14
Creation of Ethereum local network by launching testRPC library.Figure 15
Creating smart contract in IBCbAP.


## 8. Comparison

In this section, we compare our proposed protocol with its predecessor, i.e., Cha et al.’s protocol as well as other related schemes. As can be seen in Table3, our proposed protocol has complete security compared to other protocols. Since the type of blockchain used and the specifications of the system are very different in different designs, we only got the time in our system and it was not possible to compare time with other designs. The time of our proposed protocol for Create access Token and Confirm access policy phases is 1200 and 1363 milliseconds, respectively.Table 3
Comparison between IBCbAP and related protocols.
Replay attack resistanceSecret disclosure attack resistanceBlockchain typeConsensus mechanismImplementationIBCbAP√√PublicProof of stackJavaScript, RPC protocol[22]××PublicProof of stackJava, RPC protocol[28]√√PublicProof of workBerkeley DB version 4.8., bitcoind regtest[29]√√Not specifiedNot specifiedDocker [58] and truffle [59][32]√√PrivateBayesian faultJUICE [60][61]√√PublicProof of workC++


## 9. Conclusion

Nowadays, blockchain and Internet of Things (IoT) technologies are bonding. The blockchain first attracted attention as part of a wave of crypto currencies, especially Bitcoin, which challenged the normal course of financial transactions. But it was not the blockchain financial transactions that caught the attention of IoT activists, but rather the data exchanges. Blockchain is essentially an antihacking, distributed, and event logging mechanism that appears to be very useful for solving key issues related to networks where connected devices automatically interact with each other, i.e., IoT. Because of the importance of security in IoT, many schemes have been proposed in this subject. In this paper, we examined Cha et al.’s blockchain-based authentication protocol. We illustrated the weaknesses of Cha et al.’‘s protocol by applying secret disclosure, replay, traceability, and reuseToken attacks with a success probability of one and complexity of one run of protocol. To address Cha et al.’s protocol’s security vulnerabilities, we also proposed an improved protocol called IBCbAP and proved its security in an informal way and also in formal way by the Scyther tool. Finally, we implemented IBCbAP using the JavaScript programming language and the Ethereum local blockchain network. We investigated the feasibility of implementing IBCbAP and measured the timing of some processes. The comparisons show that IBCbAP compared to its predecessor, i.e., Cha et al.’s protocol, is completely secure and the cost and time of its implementation are reasonable. One of the most important issues in the IoT network is the transfer of ownership. In future works, we plan to work on the design of blockchain-based ownership transfer protocols which enables the transfer of ownership in a distributed and secure manner.



---

*Source: 8836214-2020-10-28.xml*