An Improved Blockchain-Based Authentication Protocol for IoT Network Management

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, and Token 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.


Introduction
With the advent of Internet of ings (IoT) technologies, a large number of intelligent devices have been developed and integrated into daily life [1][2][3][4][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 ings (IoT) networks [6][7][8][9][10][11][12]. One of the important solutions is use of distributed networks instead of centralized or decentralized networks [13][14][15][16][17][18][19][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). is 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. erefore, 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.

Main Contribution.
e contributions of the paper are as follows: 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.

Paper Organization.
We organize the rest of the paper as follows. In Section 2, 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 blockchainbased 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.

Related Works and Preliminaries
is 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.

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.
is 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. is 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. ere 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.

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.
is library creates a local Ethereum blockchain network.

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 tamperproof properties to create security and privacy in communications protocols. e 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. is 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. e 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 ings (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. e 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]. Hammi et al. have proposed a system to authenticate and authorize IoT devices that also meet security requirements such as confidentiality and integrity. ey 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. is 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. e 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]. e 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. e difficulty of the problem solved in block generation is inversely related to the credit value. e 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. ey 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]. ey 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. e 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]. e need for privacy preserving and distribution in healthcare systems is justifiable reasons for using blockchain in this plan. Dwivedi Figure 1: Chain of blocks in the blockchain technology [21].
Security and Communication Networks data and analyze data according to the instructions of the healthcare provider. ey 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 ings [40][41][42][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.

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.

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. ese 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. e 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. is 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 Figure 2, 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. is 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.

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 Figure 3, 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). erefore, there is no possibility of manipulating or violating information for the protocol's parties.

Cha et al.'s Proposed Signature.
e 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. ese steps by using notations represented in Table 1 will be briefly discussed in the following subsections and also are shown in Figure 4.
(1) Setup. In the first step, according to the secret value of k, the BCG selects two groups of G 1 and G 2 with the same q prime order.
e relationship between G 1 and G 2 is e: where P is the generator of G 1 . G 1 has bilinear pairing attribute, so the following relationship exists: e BCG selects its private and public key pair as s ∈ Z * q and PK BCG � s.P, respectively. Also BCG chooses three hash functions with definitions and ultimately the values of G 1 , G 2 , q, e, P, PK BCG , H 1 , H 2 , H 3 , e(P, P) are published by the BCG.
(2) Set-Partial-Private-Key. In this step, the BCG calculates R i , h i , s i , and σ i 1 values as below: (2) In the above calculations, a random number r i ∈ Z * q is used which is generated using public parameters, master private key, and the user U i 's identity ID i . After that, BCG sends (R i , σ i 1 ) to the user; the user once receives the messages immediately checks e(σ i 1 (3) Set-Secret-Value. In this step, the user selects a random number as his private key. is key is notated with x i ∈ Z * q .
(4) Set-Public-Key. In this step, the user using his secret key, i.e., x i , generates his public key as PK i � x i .P.
(5) Sign. At the beginning of this step, the user calculates the amount of k i � H 2 (ID i , PK i , R i , PK BCG , m), where m is the message to be signed, and calculates σ i 2 � (k i .s i + x i ) − 1 .P. At the end, the user sends (m, R i , σ i 2 ) to the verifier.
(6) Verify. In this step, the verifier computes the value of h i as H 1 (ID i , R i , PK BCG ) using the values of PK i and received (m, R i , σ i 2 ). After that, the verifier calculates k i as and verifies the correctness of signature by checking whether e(σ i 2 , k i .(R i + h i .PK BCG )+ PK i )�� ? e(P, P). If the condition is fulfilled, the signer is authentic.

Device
Binding. e user sends a consent of the device policies (PP j ) to the BCG. Each BCG has a root key. e user's public key (PK i ) is also specified. e BCG initially generates a random number (nonce N i ) and then, using this value, the public key of the user, BCG root key, and a hash function (H), generates a key (K ). e combination of user consent, policy (P j ), and timestamp (T ij ) are encrypted with the generated key and then stored in the blockchain. e BCG sends the transaction ID (TID ij ) and the generated key to the user because the user is sure of its accuracy. In future communications, stored information is the basis for 1. e administrator or owner of the device records the identification information, device policy, and device smart contract as a transaction on the blockchain network and receives the transaction address. is address is used to communicate and interact with the BCG.
2. e administrator sends the smart contract address to the BCG administrator to establish a logical connection. Tracking this request is done through a BCG and device smart contract.
3. e function of establishing a logical connection between the device and the port (bindDevice) is called. is call is made according to the device's address.
5. Request confirmation of logical information is sent to the device administrator. 6.A er verifying the device manager, the process result is announced to the BCG smart contract and BCG administrator. 4. e gateway stores the user's approval in blockchain and uses it for further communications.
5. e user sends an access request to device information to the gateway. e gateway starts the authentication and authorization process.
6. e user sends a request to the device and transfers information.
1. Smart contracts are implemented and encapsulated within the blockchain network.
1. e user asks the gateway smart contract address. 3.1.4. Access to the Device. Figure 6 illustrates how the user is accessing the device. e implications of Figure 6 will be discussed in the following.
(i) e user generates a signature for the access request message (PP j ) using Once the BCG receives the message, it checks the authenticity of the signature by checking whether e(σ ij , k ij .(R i + h i .PK BCG ) + PK i )�� ? e(P, P) or not. If so, the BCG generates a random value (r ij ∈ Z * q ) and then calculates R ij � r ij .P, l ij � H 1 (ID i , R ij , σ ij , PK BCG ), s ij � r ij + l ij , σ BCG � s −1 ij .P and at last the BCG sends (R ij , σ BCG ) to the user in response. After receiving (R ij , σ BCG ) from the BCG, the user verifies the validity of the received values by computing l ij � H 1 (ID i , R ij , σ ij , PK BCG ) and checking whether e(σ BCG , R ij + l ij .PK BCG )�� ? e(P, P) or not. If the accuracy of the received information is verified, the access Token is calculated as below: (1) BCG publishes if e (σ i1 , K i . (R i + h i .PK BCG ) + PK i ) ≠ e (P, P): (3) Generate x i as secret key (4) PK i = x i .P as public key if e (σ i1 , R i + h i .PK BCG ) ≠ e (P, P): Blockchain connceted gateway (BCG) s, PK BCG G 1 , G 2 , q, e, P, PK BCG , H 1 , H 2 , H 3 , e (P, P)

Security Analysis of Cha et al.'s Blockchain-Based Authentication Protocol
In this section, we will investigate Cha et al.'s protocol's security. is analysis includes the presentation of security attacks. We have applied four attacks on Cha et al.'s protocol comprising secret disclosure, replay, traceability, and reuse Token attacks. is 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.

e Adversary Model.
Here, we used the common adversary model [44][45][46][47][48] Generate r ij s ij = r ij + r ij .s Security and Communication Networks e 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. eir details will be explained in Section 5.2.  (1) e attacker eavesdrops one run of protocol and stores the transferred messages (2) e attacker gets R i related to U i user, notated R i ′ (3) After that, if the attacker sniffs the protocol messages and compares the R i with R i ′ , he/she can determine whether the message is for the U i user or not, so recognizing the user e attacker can detect a user, with the probability of 1 and the complexity of eavesdropping one run of the protocol. is attack is possible because in Cha et al.'s protocol, the R i � r i .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. [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. is 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. is 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.

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. erefore, 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 a SK ubcga secret key and shares with the user. In this phase, the used channel is secure. (ii) Create access Token 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. e key used in this phase is generated in the Confirm access policy phase in which the used channel is secure.

Confirm Access Policy.
In the first step, the user needs to find the device access policies (P j ) and agree to them. To accept the device policy, he/she sends a message (PP j ) to the BCG according to the policy. e BCG generates a nonce (N i ) upon which it receives PP j . e shared key between the device and the BCG (SK ubcg ) is created using the equation below: is key is used in subsequent messages where H is a hash function, and SK BCG is a secret value associated with the BCG. e P j , PP j , and a timestamp (T) are encrypted using the generated key and stored as a transaction in the blockchain. e transaction address (TID ij ) along with the (SK ubcg ) is sent to the user through the secure channel. It is worth noting that the channel between the BCG and the user is secure.

Create Access Token.
e user accesses the device through the following steps: TID ij , r u , and SK ubcg are the transaction number associated with accepting device policies, a random number, and a shared secret key between himself and the BCG, respectively. e user sends (PP j , r u ) to the device. is is accomplished by checking whether M ′ ′ sig �� ? HMAC(r b ‖r u ‖TID ij , SK ubcg ) or not. e device already knows the value of r u , TID ij , and SK ubcg . e 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 N sig � HMAC(r b , SK ubcg ) and sends it to the BCG.
Invoke (6) Send TID ij to User with generated secret key (SK ubcg ) between BCG and User (7) SK ubcg , TID ij    When the user receives the message E SK ubcg (Token � � � �tr u ) and decrypts it with the key SK ubcg , if obtained r u is equal to its one, the user trusts the received Token. e same is true for the device.

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].

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.

Resistance to DDoS Attack.
Because of using blockchain, the architecture of the system moves toward distribution architecture. e 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. 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.

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 access Token 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.

Formal Security Analysis.
We have used the Scyther tool to check out the formal security of our proposed bockchainbased authentication protocol. e 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]. ere are several predefined claim types in the Scyther tool which are represented in Table 2.
We have used Nisynch, Niagree, and Secret claims. e 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 Figures 9 and 10, respectively.
As you can see in Figure 10, the Scyther tool could not find an attack for IBCbAP. erefore, IBCbAP provides a good level of security.

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. e reason for this choice is WEB3.js [54] library to contact blockchain. is library uses the RPC (Remote Procedure Call) protocol to interact with blockchain nodes. e system used in this simulation includes features such as 4 GB RAM, 1 TB HDD, and Core i7 2.47 GHz CPU.

Confirm Access Policy.
e implemented architecture has four participants (user, BCG, device, and blockchain network). User to use P j device sends the PP j to the BCG and then receives the shared key between itself and BCG (SK ubcg ) through a secure channel. How to generate SK ubcg is explained in Section 5.2. e 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 8 shows the Create access Token phase. At this phase, the user starts the process of issuing the access Token by sending r u and PP j 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 E SK ubcg (Token � � � �tr u ) to the user and as E SK dbcg (Token � � � �tr d ) to the device. We performed this phase 10 times and have a total time of 1200 milliseconds. e 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.

Ethereum Network.
To implement the blockchain network, we have used the testRPC [27] library. is library creates a local blockchain network. Figure 14 illustrates the launch of this library. e testRPC default creates 10

Claim Description
Secret ere is no unauthorized access to the parameters transmitted in the protocol. For example, claim(Initiator, 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.
Alive claim(R, 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.

Weakagree
It ensures that the receiver has received message at the time that was sent by the sender. ere is no agreement on the data transmitted. Niagree claim(R, Niagree, R′) claims that the agreed values between the receiver and the transmitter will remain unchanged.
Nisynch claim(R, 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.      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.

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 Table 3, 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. e time of our proposed protocol for Create access Token and Confirm access policy phases is 1200 and 1363 milliseconds, respectively.

Conclusion
Nowadays, blockchain and Internet of ings (IoT) technologies are bonding. e 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 reuse Token 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. e 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.

Data Availability
No data were used to support this study.