A study of Block chain role of technological integration system in supply chain 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 ﬁnancial 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 signiﬁcantly 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 satisﬁes 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.

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 communi- cation 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 im- portant 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 ﬁrst 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 da- tabase with privacy preserving and security properties. Blockchain has many security features such as integrity, distribution, and tamper-prooﬁng. In a blockchain network, all network members take part in the veriﬁcation process of information which takes part in the alternative role of the trusted third party (TTP) on the system. It is very diﬃcult 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 en- sured. 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 in- formation, privacy preserving becomes diﬃcult and new solutions are needed and these solutions should not impede the consensus process. Another problem is its low scalability because of the ﬁxed 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 oﬀer suggestions for trou- bleshooting 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. The contributions of the paper are as follows:
1. Presenting security weaknesses of Cha et al. block- chain-based authentication and secure management of privacy preferences scheme.
1. Addressing security pitfalls of Cha et al.’s scheme and proposing a new improved one called IBCbAP.
1. Formal and informal security analysis of IBCbAP. Formal prooﬁng is done using the Scyther tool.
1. Implementation of IBCbAP through JavaScript language and Ethereum local blockchain and con- sidering 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 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 de- scribe 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 authen- tication 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 brieﬂy presents a few related works. Since we used the blockchain to store critical information securely in our proposed protocol, the deﬁnition of blockchain technology and how it works are also explained in this section. Also, we brieﬂy explain the smart contract and its usage in our proposed protocol. Fi- nally, 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. 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 trans- action 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 corre- sponding node solves a diﬃcult problem, and the one who solves the problem sooner registers its block in the block- chain. Changing an approved block in the ledger is costly and diﬃcult. 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.

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 ﬁxed 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 conﬁdence. 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

Block N-1 Block N Hash of N-1th block Transactions Hash of the block Block N + 1 Hash of Nth block Transactions Hash of the block Hash of N-2th block Transactions Hash of the block

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 conﬁdentiality and integrity. They based the main idea behind their scheme on the use of blockchain security beneﬁts

Figure 1: Chain of blocks in the blockchain technology [21].

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.

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 commu- nications protocols. The ﬁrst blockchain is provided by Bitcoin [21], which stores ﬁnancial 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 ﬁt 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 eﬃciently 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 computa- tional burden to network members. In their scheme, miners are members of the network and their number and mem- bership are changed based on few parameters. Dorri et al. used smart homes network scenario. The interior man- agement 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 ﬁve entities, including terminals, blockchain, cloud, industrial network, and physical resources. In this scheme, commands are stored by the terminals at block- chain. The cloud and industrial network monitor the blockchain and ﬁnd the commands and then perform the

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 Deﬁned 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 coeﬃcient of a vehicle increases, the miners deﬁne 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 diﬃculty of the problem solved in block gen- eration 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. speciﬁcally recommends this system for using in distributed vehicular fog servers. Yao et al. have enabled one-time au- thentication to access the services. They used the blockchain to store authentication history and reauthentication is se- lected by the devices. Sidorov et al. have proposed a block- chain-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 justiﬁable 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 in- formation 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 notiﬁes the relevant doctor.

As seen in this section, many attempts have been made to integrate blockchain technology with the IoT. All of these eﬀorts lead to the growth and maturity of blockchain use in the In- ternet 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 oﬀer 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.

Cha et al.’s Protocol. Recently, in [22], Cha et al. proposed

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.

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 brieﬂy discussed in the following subsections and also are shown in Figure 4.

Setup. In the ﬁrst 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: G ^∗ G1 ⟶ G2, where P is the generator of G1. G1 has bilinear pairing attribute, so the following relationship exists:

∀m, n ∈ Z ^∗, ∀S, P ∈ G₁: e(mS, nP) � e(S, P)mn. (1)

The BCG selects its private and public key pair as

s ∈ Z ^∗ and PK_BCG � s.P, respectively. Also BCG chooses

a new authentication protocol based on blockchain for share

three hash functions with deﬁnitions

{ } × × ×

and access management of IoT device information as a dis-

H1: {0, 1}∗ × G1 ⟶ Z ^∗ , H2: {0, 1}∗ × G1 × G1 ⟶ Z ^∗

tributed 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 re- sources 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

and H3: 0, 1 ^∗ G1 G1 G1 ⟶ Z ^∗ , and ultimately the values of G1, G2, q, e, P, PK_BCG, H1, H2, H3, e P, P are published by the BCG.

( )

Set-Partial-Private-Key. In this step, the BCG calculates

Ri, hi, si, and σ_i1 values as below:

(

Ri � ri · P,

resources of the devices according to policies.

We use the scenario described in [22] to explain com-

hi � H1 ID_i, Ri, PK_BCG ,

si � ri + hi · s mod q,

(2)

munication and process sequencing. In this scenario, each user joins the blockchain network and registers its public

σ_i1 � s⁻i · P.

and private key pair. The BCGs and administrator of devices deploy their smart contract in the blockchain network.

In the above calculations, a random number ri ∈ Z ^∗ is used which is generated using public parameters, master private key, and the user Ui’s identity ID_i. After that, BCG sends (Ri, σ_i1 ) to the user; the user once receives the mes-

to device information is done by this BCG.

As shown in Figure 2, the user ﬁrst ﬁnds 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.

3.1.1. Smart Contracts. Here, we explain the implicit smart

Set-Secret-Value. In this step, the user selects a random number as his private key. This key is notated with 𝑥i ∈ Z ^∗ .

Set-Public-Key. In this step, the user using his secret key, i.e., 𝑥i, generates his public key as PK_i � 𝑥i.P.

Sign. At the beginning of this step, the user calculates the amount of ki � H2(ID_i, PK_i, Ri, PK_BCG, m), where m is the

message to be signed, and calculates σ_i � (ki.si + 𝑥i)− 1.P. At

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 end, the user sends (m, Ri, σ_i2 ) to the veriﬁer.

Verify. In this step, the veriﬁer computes the value of hi as H1(ID_i, Ri, PK_BCG) using the values of PK_i and received (m, Ri, σ_i2 ). After that, the veriﬁer calculates ki as

Smart contracts are implemented and encapsulated within the blockchain network.

Blockchain network

Fetches device list and privacy policies by invoking gateway

smart contract.

The user agrees to the privacy policies

of the device.

User

6. The user sends a request to the device and transfers information.

The user sends an access request to device

information to the

4. The gateway stores the user’s approval in blockchain and

uses it for further communications.

The user asks the gateway

smart contract address.

gateway. The gateway starts the authentication and authorization process.

IoT device

Blockchain connected gateway (BCG)

Figure 2: Overview of Cha et al.’s blockchain-based authentication protocol.

Blockchain network

Logical authentication function (bindRequest) is

called.

ction of a logical between and the evice) is s call is ing to the ddress. BCG administrator

Device BCG

Request conﬁrmation of logical information is sent to the device

administrator.

smart contract

The fun establishing connection

6.After verifying the device manager, the process result is announced to the BCG smart contract and BCG

the device port (bindD called. Thi made accord

Device administrator

The administrator or owner of the device records the identiﬁcation information, device policy, and device smart contract as

a transaction on the blockchain network and

administrator.

device’s a

receives the transaction address. This address is used to communicate and interact with the BCG.

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

Figure 3: Device binding communications in Cha et al.’s blockchain-based authentication protocol.

H2(ID_i, PK_i, Ri, PK_BCG, m) and veriﬁes the correctness of signature by checking whether e(σ_i2 , ki.(Ri + hi.PK_BCG)+ PK )�� e(P, P). If the condition is fulﬁlled, the signer is

generates a random number (nonce Ni) and then, using this value, the public key of the user, BCG root key, and a hash

UiP

function (H), generates a key (K ). The combination of

authentic.

user consent, policy ( )

( )

Pj , and timestamp

Tij

( ) are encrypted

Device Binding. The user sends a consent of the device policies (PP_j) to the BCG. Each BCG has a root key. The user’s public key (PK_i) is also speciﬁed. The BCG initially

Table 1: Summary of notations used in this paper.

Notation Description

q Prime order

G1, G2 Cyclic groups with the same prime order q

e Bilinear pairing map G1 ∗ G1 ⟶ G2

P Generator of G₁

s Master private key

PK_BCG BCG public key, i.e., (s.P)

H, H1 Hash functions

H2, H3

ID_i User Ui’s identity

SK_dbcg Shared key between the device and the BCG

m Message

( )

EK . Symmetric encryption function

Pj Device policy

PP_j Consent of the Pj policy

Tij Timestamps

KNi

UiPj

Generated key between BCG and user Ui

PK_i User’s public key

ru, rd, rb Random numbers generated by user, device, and BCG, respectively

TID_ij Transaction address added to blockchain because of acceptance policy Pj by Ui user

Ni Random numbers

SK_ubcg Shared key between the user and the BCG

ri Random numbers

‖ Concatenation

Blockchain connceted gateway (BCG) s, PK_BCG	(R_i, σ_i₁) (m, R_i, σ_i₂, PK_i)	User (U_i) ID_i, PK_BCG
BCG publishes G₁, G₂, q, e, P, PK_BCG, H₁, H₂, H₃, e (P, P) R_i = r_i.P, h_i = r_i + h_i.s mod q σ_i = r_i + h_i.s mod q σ_i₁ = s–1.P i h_i = H₁ (ID_i, R_i, PK_BCG) and k_i = H₂ (ID_i, PK_i, R_i, PK_BCG, m) (6) if e (σ_i₁, K_i. (R_i + h_i.PK_BCG) + PK_i) ≠ e (P, P): break;	(R_i, σ_i₁) (m, R_i, σ_i₂, PK_i)	h_i = H₂ (ID_i, R_i, PK_BCG) if e (σ_i₁, R_i + h_i.PK_BCG) ≠ e (P, P): Generate x_i as secret keyPK_i = x_i.P as public key k_i = H₂ (ID_i, PK_i, R_i, PK_BCG, m) and σ_i₂ = (k_i.s_i + x_i)–1.P

Figure 4: Cha et al.’s proposed signature.

licensing access to the device. Figure 5 illustrates the device binding of Cha et al.’s protocol.

Access to the Device. Figure 6 illustrates how the user is accessing the device. The implications of Figure 6 will be discussed in the following.
- The user generates a signature for the access request

so, the BCG generates a random value (rij ∈ Z ^∗ ) and then calculates Rij � rij.P, lij � H1(ID_i, Rij, σ_ij, PK_BCG), sij � rij + lij, σ_BCG � s⁻¹.P and at last the BCG sends (Rij, σ_BCG) to the user in response.

( )

ij ij

After receiving Rij, σ_BCG from the BCG, the user veriﬁes the validity of the received values by com- puting lij � H1(ID_i, Rij, σ_ij, PK_BCG) and checking

message (PP ) using s � r + h .s, R � r .P, h �

whether e(σ_BCG, R + l .PK_BCG)�^?� e(P, P) or not. If

H1(ID_i, Ri, PK_BCG), 𝑥i, PK_i, PP_j, Kij �− H2(ID_i, PK_i,

the accuracy of the received information is veriﬁed,

Ri, PK_BCG, PP_j) as σ_ij � (kij.si+ 𝑥i) (PP_j, Ri, σ_ij) to the BCG.

¹ and sends

the access Token is calculated as below:

BCG

e(σ

, k

.(R + h .PK

) + PK )�� e(P, P) or not. If

Once the BCG receives the message, it checks the

Token � PP , R ,

User (U_i)	(1) PP_j on privacy policy PP_j (6) K^Ni , TID UiP ij J	BCG s, PK_BCG, K	Store EM TID_ij Invoke	Blockchain network	Smart contract for the gateway
ID_i, PK_BCG, R_i
		(2) Generate a nonce N_i K^Ni = H (K \|\| N \|\| PK ) UiP i i J EM = E_UNi H (PP_j \|\| P_j \|\| T_ij) iPJ (5) Invoke Log (TID_ij) function in smart contract		Add transaction in blockchainand return transaction ID (TID_ij)

Figure 5: Cha et al.’s protocol: device binding phase.

Device D_k	(6) Token (8) Success/failure	User (U_i) ID_i, PK_BCG, R_i	(2) (PP_j, R_i, σ_ij) (4) (R_ij, σ_BCG)	BCG s, PK_BCG, K
(7) Verify σ_ij and σ_BCG	(6) Token (8) Success/failure	(1) k_ij = H₂ (ID_i, PK_i, R_i, PK_BCG, PP_j) σ_ij = (k_ij.s_i + x_i)–1.P (5) l_ij = H₁ (ID_i, R_ij, σ_ij, PK_BCG) if e (σ_BCG, R_ij. + l_ij.PK_BCG) ≠ e (P, P): break; Token = (PP_j, R_i, σ_ij, R_ij.σ_BCG)	(2) (PP_j, R_i, σ_ij) (4) (R_ij, σ_BCG)	(3) h_i = H₁ (ID_i, R_i, PK_BCG) k_ij = H₂ (ID_i, PK_i, R_i, PK_BCG, PP_j) k_ij = (k_ij.s_i + x_i)–1.P if e (σ_i₁, R_i + h_i.PK_BCG) ≠ e (P, P): break; Generate r_ij R_ij = r_ij.P, l_ij = H₁ (ID_i, R_ij, σ_ij, PK_BCG) s_ij = r_ij + r_ij.s σBCG = s –1.P ij

Figure 6: Cha et al.’s protocol: access to device phase.

Finally, the user may use the device by sending Token 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 se- curity attacks. We have applied four attacks on Cha et al.’s protocol comprising secret disclosure, replay, traceability, and reuse Token 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.

The Adversary Model. Here, we used the common ad- versary 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.

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:
- The attacker eavesdrops transferred messages for one run of the access to device phase of Cha et al.’s protocol
- Using PP_j, Ri, σ_ij, Rij, and σ_BCG which eavesdropped in access to device phase of Cha et al.’s protocol, the attacker can calculate Token as (PP_j, Rj, σ_ij, σ_BCG)
- Using calculated Token in the previous step, the attacker can access and use the intended IoT device

The success probability of the attack is 1 and its com- plexity is one run of the protocol. We will ﬁx this weakness in our proposed protocol, i.e., IBCbAP. To solve this problem, we do signature using HMAC (Hash-Based Message Au- thentication Code) function and ECDLP (Elliptic Curve Discrete Logarithm Problem) encryption. Their details will be explained in Section 5.2.

Replay Attack. Because of the absence of new random values in each session, messages from each session are not diﬀerent from other sessions, so a message is acceptable in all sessions. The attacker can gain BCG approval by sending messages sniﬀed in previous sessions and impersonating the user. The steps of this attack are as follows:
- The attacker eavesdrops one session and stores

(PP_j, Ri, σ_ij) message as N′

The attacker starts a new session with BCG by sending N′ to the BCG
- BCG checks correctness of N′ and because of the mentioned weakness in Cha et al.’s protocol, BCG conﬁrms the authenticity of the information
- BCG sends (Rij, σ_BCG) to the attacker
- 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.

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 mes- sages. For this attack, it is enough for the attacker to proceed as below:
- The attacker eavesdrops one run of protocol and stores the transferred messages
- The attacker gets Ri related to Ui user, notated R′i
- After that, if the attacker sniﬀs the protocol messages and compares the Ri with R′i, he/she can determine whether the message is for the Ui user or not, so recognizing the user

�

The attacker can detect a user, with the probability of 1 and the complexity of eavesdropping one run of the pro- tocol. This attack is possible because in Cha et al.’s protocol, the Ri 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 diﬀerent, and the possi- bility of tracing users is vanishing.

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 mes- sages, 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 sit- uation. 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 ﬁgure 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 authen- tication 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 sig- nature. We named the proposed protocol IBCbAP (Im- proved 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.

Conﬁrm access policy phase: In this phase, the user, after ﬁnding 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.
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. The key used in this phase is generated in the Conﬁrm access policy phase in which the used channel is secure.

( )

Conﬁrm Access Policy. In the ﬁrst step, the user needs to ﬁnd the device access policies Pj and agree to them. To accept the device policy, he/she sends a message PP_j to the

( )

BCG according to the policy. The BCG generates a nonce Ni upon which it receives PP_j. The shared key between the device and the BCG SK_ubcg is created using the equation

� �

below:

SK_ubcg � H ID_i Ni SK_BCG . (4)

This key is used in subsequent messages where H is a hash function, and SK_BCG is a secret value associated with the BCG. The Pj, PP_j, and a timestamp (T) are encrypted using the

Figure 7: IBCbAP: Conﬁrm access policy phase.

Device D_k SKubcg	(2) PP_j_, r_u (4) (M_sig, r_d, r_u, PP_j)	User (U_i) IDi, SKubcg	(6) r_b, M″_sig : (8) N_sig E_SKubcg (Token\|\|r_u)E_SKdbcg (Token\|\|r_d)	BCG SKubcg, SKBCG, SKdbcg
(3) Generate random number r_d M_sig = HMAC (r_u\|\|r_d\|\|PP_j_, SK_dbcg)	(2) PP_j_, r_u (4) (M_sig, r_d, r_u, PP_j)	(1) Generate random number r_u PP_j = SK_ubcg (TID_ij\|\|r_u) (7) M_s″_ig ≠ HMAC (r_b\|\|r_u\|\|TID_ij, SK_ubcg) break; N_sig = HMAC (r_b, SK_ubcg) (12) Verify E_SKdbcg (Token\|\|r_u)		(5) M_s′_ig = HMAC (r_u\|\|r_d\|\|PP_j, SK_dbcg) if (M_sig ≠ M′_sig ): break; Find PP_j and verify it according to blockchain transaction (the connection with blockchain is done through RPC protocol) M_sig = HMAC (r_b\|\|r_u\|\|TID_ij, SK_ubcg) (9) N_s′_ig = HMAC (r_b, SK_ubcg) if (N_sig ≠ M_s′_ig): break; Generate access Token

Figure 8: IBCbAP: Create access Token phase.

( ) ( )

generated key and stored as a transaction in the blockchain. The 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.

satisfying Ms′ig Msig condition. BCG decrypts the PP_j and ensures the user’s claim using the block- chain network. In the next step, the BCG generates another random number (rb) and the value of

�

′′

sig

� HMAC(rb‖ru‖TID_ij, SK_ubcg). And ﬁnally, it

Create Access Token. The user accesses the device through the following steps:

sends (Msig, rb) to the user.

sig

Once the user received the (M^′′

, rb) message, it

ubcg

TID

, r , and SK

are the transaction number

The user produces PP_j � ESK (TID_ij�tru), where

veriﬁes the authority of the BCG. This is ac-

complished by checking whether

associated with accepting device policies, a random

( )

number, and a shared secret key between himself and the BCG, respectively. The user sends PP_j, ru to the device.

( � ( ‖ ‖ ))

it to the user. Also, it computes E_SKdbcg(Token�tr_d)

The device once receives the message, generates a random number (rd), and computes Msig � HMAC(ru‖rd‖PP_j, SK_dbcg) and sends (M , r , r , PP ) to the BCG.

device already knows the value of ru , TID_ij, and

� ( )

sig

SK_ubcg. 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 HMAC rb, SK_ubcg and sends it to the BCG.

Token and computes E_SKubcg(Token�tr_u) and s��ends

(v) The BCG checks whether Nsig�^? Ns′ig, where

signature Ms′ig HMAC ru rd PP_j, SK_dbcg and compares it with the received signature Msig . The continuation of the protocol is related to the

sig d u j

N′ � HMAC(r , SK ). If so, it �creates access

sig b ubcg �

When the user receives the message ESK Token tru and decrypts it with the key SK_ubcg, 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 infor- mally 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 diﬀerent at- tacks. Informal analysis is based on the knowledge and creativity of the analyst.

Resistance to DDoS Attack. Because of using block- chain, the architecture of the system moves toward distri- bution 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 diﬀerent 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 diﬀerent keys per user for each device, the possibility of changing values and system desynchronization is eliminated.

( )

Resistance to Replay Attack. Since, in the proposed protocol, all members of the network participate in the Create access Token phase, the possibility of the replay attack is eliminated. Existence of shared secret values SK_ubcg, SK_dbcg between protocol parties and use of freshly random values ru, rd, rb by protocol parties lead each

session’s messages to be diﬀerent from previous sessions

messages; as a result, the possibility of the replay attack vanishes.

Resistance to Secret Disclosure Attack. Important messages sent between the user and the BCG are encrypted

Resistance to Traceability Attack. As mentioned be- fore, because of the involvement of random numbers in all transferred messages and changing these random numbers in each session, the attacker cannot ﬁnd any ﬁxed 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 bockchain- based authentication protocol. The Scyther is created with Python [51] language and works according to security claims. Claim events are used in role speciﬁcations to model intended security properties [52]. There are several pre- deﬁned claim types in the Scyther tool which are represented in Table 2.

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 veriﬁcation are shown in Figures 9 and 10, respectively.

As you can see in Figure 10, the Scyther tool could not ﬁnd 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] tech- nology 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

ESKubcg

(Token�tr_u). We also encrypt important messages

interact with blockchain nodes. The system used in this simulation includes features such as 4 GB RAM, 1 TB HDD,

sent between the device and the BCG, suc��h as Token, using a

( � )dbcg

shared secret value, i.e., ESK Token trd . Due to the encryption of messages in the session, important informa- tion remains conﬁdential. 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.

and Core i7 2.47 GHz CPU.

Conﬁrm Access Policy. The implemented architecture has four participants (user, BCG, device, and blockchain network). User to use Pj 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

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.

Figure 13: The graphical user interface of implemented IBCbAP: successful receipt of the Token from BCG.

Figure 14: Creation of Ethereum local network by launching testRPC library.

Figure 15: Creating smart contract in IBCbAP.

Table 3: Comparison between IBCbAP and related protocols.

Replay attack resistance

Secret disclosure attack resistance

Blockchain type

Consensus mechanism

Implementation

IBCbAP √ √ Public Proof of stack JavaScript, RPC protocol

[22] × × Public Proof of stack Java, RPC protocol

regtest

[28] √ √ Public Proof of work Berkeley DB version 4.8., bitcoind

[29]	√	√	Not speciﬁed	Not speciﬁed	Docker [58] and truﬄe [59]
[32]	√	√	Private	Bayesian fault	JUICE [60]
[61]	√	√	Public	Proof of work	C++

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 simpliﬁed and is suitable for implementing Conﬁrm 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 pro- tocol with existing technologies and facilities. It is worth noting that we achieve measured times with only one device, one user, and one port.

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 Table 3, our proposed protocol has complete security compared to other protocols. Since the type of blockchain used and the speciﬁcations of the system are very diﬀerent in diﬀerent 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 Conﬁrm access policy phases is 1200 and 1363 milliseconds, respectively.

9. Conclusion

Nowadays, blockchain and Internet of Things (IoT) tech- nologies are bonding. The blockchain ﬁrst attracted atten- tion as part of a wave of crypto currencies, especially Bitcoin, which challenged the normal course of ﬁnancial transac- tions. But it was not the blockchain ﬁnancial transactions that caught the attention of IoT activists, but rather the data exchanges. Blockchain is essentially an antihacking, dis- tributed, 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. The comparisons show that IBCbAP compared to its prede- cessor, 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.

Conflicts of Interest

The authors declare that there are no conﬂicts of interest regarding the publication of this paper.

References

E. K. Wang, J. Yu, C.-M. Chen, S. Kumari, and J. J. Rodrigues, “Data augmentation for internet of things dialog system,” Mobile Networks and Applications, pp. 1–14, 2020.
C.-M. Chen, B. Xiang, Y. Liu, and K.-H. Wang, “A secure authentication protocol for internet of vehicles,” IEEE Access, vol. 7, pp. 12 047–12 057, 2019.
K.-H. Wang, C.-M. Chen, W. Fang, and T.-Y. Wu, “On the security of a new ultra-lightweight authentication protocol in iot environment for rﬁd tags,” The Journal of Supercomputing, vol. 74, no. 1, pp. 65–70, 2018.
S. Qu, L. Zhao, and Z. Xiong, “Cross-layer congestion control of wireless sensor networks based on fuzzy sliding mode control,” Neural Computing and Applications, vol. 32, no. 17, pp. 13505–13520, 2020.
C.-M. Chen, Y. Huang, K.-H. Wang, S. Kumari, and M.-E. Wu, “A secure authenticated and key exchange scheme for fog computing,” Enterprise Information Systems, pp. 1–16, 2020.
C.-T. Li, C.-C. Lee, and C.-Y. Weng, “An extended chaotic maps based user authentication and privacy preserving scheme against dos attacks in pervasive and ubiquitous computing environments,” Nonlinear Dynamics, vol. 74, no. 4, pp. 1133–1143, 2013.
C.-C. Lee, M.-S. Hwang, and I.-E. Liao, “Security enhance- ment on a new authentication scheme with anonymity for wireless environments,” IEEE Transactions on Industrial Electronics, vol. 53, no. 5, pp. 1683–1687, 2006.
C.-T. Li, C.-Y. Weng, and C.-C. Lee, “A secure rﬁd tag au- thentication protocol with privacy preserving in telecare medicine information system,” Journal of Medical Systems, vol. 39, no. 8, p. 77, 2015.
S. K. Dwivedi, R. Amin, and S. Vollala, “Blockchain based secured information sharing protocol in supply chain man- agement system with key distribution mechanism,” Journal of Information Security and Applications, vol. 54, p. 102554, 2020.
S. K. Dwivedi, R. Amin, S. Vollala, and R. Chaudhry, “Blockchain-based secured event-information sharing pro- tocol in internet of vehicles for smart cities,” Computers & Electrical Engineering, vol. 86, p. 106719, 2020.
A. Irshad, M. Usman, S. A. Chaudhry, H. Naqvi, and

M. Shaﬁq, “A provably secure and eﬃcient authenticated key agreement scheme for energy internet based vehicle-to-grid technology framework,” IEEE Transactions on Industry Ap- plications, vol. 56, no. 4, pp. 4425–4435, 2020.

K. Mahmood, J. Arshad, S. A. Chaudhry, and S. Kumari, “An enhanced anonymous identity-based key agreement protocol for smart grid advanced metering infrastructure,” Interna- tional Journal of Communication Systems, vol. 32, no. 16, p. e4137, 2019.
P. K. Sharma, N. Kumar, and J. H. Park, “Blockchain tech- nology toward Green IoT: opportunities and challenges,” IEEE Network, vol. 34, no. 4, pp. 263–269, 2020.

V. Dedeoglu, R. Jurdak, A. Dorri et al., “Blockchain tech- nologies for IoT,” in Advanced Applications of Blockchain Technology, pp. 55–89, Springer, Berlin, Germany, 2020.
S. Shamshad, K. Minahil, K. Mahmood, and C.-M. Chen, “A secure blockchain-based e-health records storage and sharing scheme,” Journal of Information Security and Applications, vol. 55, p. 102590, 2020.
B. C. Florea and D. D. Taralunga, “Blockchain IoT for smart electric vehicles battery management,” Sustainability, vol. 12, no. 10, p. 3984, 2020.
G. Yu, X. Zha, X. Wang et al., “Enabling attribute revocation for ﬁne-grained access control in blockchain-IoT systems,” IEEE Transactions on Engineering Management, vol. 67, no. 4, pp. 1213–1230, 2020.
P. P. Ray, D. Dash, K. Salah, and N. Kumar, “Blockchain for IoT-based healthcare: background, consensus, platforms, and use cases,” IEEE Systems Journal, 2020.
G. Rathee, M. Balasaraswathi, K. P. Chandran, S. D. Gupta, and C. Boopathi, “A secure IoT sensors communication in industry 4.0 using blockchain technology,” Journal of Ambient Intelligence and Humanized Computing, 2020.
S. Gupta, V. Malhotra, and S. N. Singh, “Securing IoT-driven remote healthcare data through blockchain,” in Advances in Data and Information Sciences, pp. 47–56, Springer, Berlin, Germany, 2020.
S. Nakamoto, Bitcoin: A Peer-To-Peer Electronic Cash System, 2008, https://bitcoin.org/en/bitcoin-paper.
S.-C. Cha, J.-F. Chen, C. Su, and K.-H. Yeh, “A blockchain connected gateway for BLE-based devices in the internet of things,” IEEE Access, vol. 6, pp. 24 639–724 649, 2018.
E. K. Wang, R. Sun, C.-M. Chen, Z. Liang, S. Kumari, and

M. K. Khan, “Proof of X-repute blockchain consensus pro- tocol for IoT systems,” Computers & Security, vol. 95, p. 101871, 2020.

E. K. Wang, Z. Liang, C.-M. Chen, S. Kumari, and M. K. Khan, “PoRX: a reputation incentive scheme for blockchain con- sensus of IIoT,” Future Generation Computer Systems, vol. 102, pp. 140–151, 2020.
V. Buterin, “Ethereum White Paper,” GitHub Repository, pp. 22–23, 2013.
Hyperledger, “Open Source Blockchain Technologies,” https://www.hyperledger.org/, 2020.
TestRPC, “Library,” https://www.npmjs.com/package/ ethereumjs-testrpc/, 2020.
A. Ouaddah, A. Abou Elkalam, and A. Ait Ouahman, “Fairaccess: a new blockchain-based access control framework for the internet of things,” Security and Communication Networks, vol. 9, no. 18, pp. 5943–5964, 2016.
O. Novo, “Blockchain meets IoT: an architecture for scalable access management in IoT,” IEEE Internet of Things Journal, vol. 5, no. 2, pp. 1184–1195, 2018.
A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, “LSB: a lightweight scalable blockchain for IoT security and privacy,” 2017, https://arxiv.org/abs/1712.02969v1.
A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, “Blockchain for IoT security and privacy: the case study of a smart home,” in Proceedings of the 2017 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom workshops), pp. 618–623, IEEE, Kona, HI, USA, March 2017.
C. Lin, D. He, X. Huang, K.-K. R. Choo, and A. V. Vasilakos, “BSeIn: a blockchain-based secure mutual authentication with ﬁne-grained access control system for industry 4.0,” Journal of Network and Computer Applications, vol. 116, pp. 42–52, 2018.

L. Xie, Y. Ding, H. Yang, and X. Wang, “Blockchain-based secure and trustworthy internet of things in SDN-enabled 5g- VANETs,” IEEE Access, vol. 7, pp. 56 656–56 666, 2019.
S. A. A. Shah, E. Ahmed, M. Imran, and S. Zeadally, “5G for vehicular communications,” IEEE Communications Maga- zine, vol. 56, no. 1, pp. 111–117, 2018.
J. Huang, L. Kong, G. Chen, M.-Y. Wu, X. Liu, and P. Zeng, “Towards secure industrial IoT: blockchain system with credit-based consensus mechanism,” IEEE Transactions on Industrial Informatics, vol. 15, no. 6, pp. 3680–3689, 2019.
S. Popov, “The Tangle,” Cit. on, p. 131, 2016.
Y. Yao, X. Chang, J. Misic, V. B. Misic, and L. Li, “BLA: blockchain-assisted lightweight Anonymous authentication for distributed vehicular fog services,” IEEE Internet of Things Journal, vol. 6, no. 2, pp. 3775–3784, 2019.
M. Sidorov, M. T. Ong, R. V. Sridharan, J. Nakamura,

R. Ohmura, and J. H. Khor, “Ultralightweight mutual au- thentication RFID protocol for blockchain enabled supply chains,” IEEE Access, vol. 7, pp. 7273–7285, 2019.

A. Dwivedi, G. Srivastava, S. Dhar, and R. Singh, “A decentralized privacy-preserving healthcare blockchain for IoT,” Sensors, vol. 19, no. 2, p. 326, 2019.
E. K. Wang, C.-M. Chen, D. Zhao, W. H. Ip, and K. L. Yung, “A dynamic trust model in internet of things,” Soft Com- puting, vol. 24, no. 8, pp. 5773–5782, 2020.
H. Xiong, Y. Wu, C. Jin, and S. Kumari, “Eﬃcient and privacy- preserving authentication protocol for heterogeneous systems in IIOT,” IEEE Internet of Things Journal, 2020.
H. Zhu, X. Wang, C.-M. Chen, and S. Kumari, “Two novel semi-quantum-reﬂection protocols applied in connected vehicle systems with blockchain,” Computers & Electrical Engineering, vol. 86, p. 106714, 2020.
J.-H. Hsiao, R. Tso, C.-M. Chen, and M.-E. Wu, “Decen- tralized e-voting systems based on the blockchain technol- ogy,” in Advances in Computer Science and Ubiquitous Computing, pp. 305–309, Springer, Berlin, Germany, 2017.
S. Hussain and S. A. Chaudhry, “Comments on “biometrics- based privacy-preserving user authentication scheme for cloud-based industrial internet of things deployment,” IEEE Internet of Things Journal, vol. 6, no. 6, pp. 10 936–10 940, 2019.
K. Mansoor, A. Ghani, S. Chaudhry, S. Shamshirband,

S. Ghayyur, and A. Mosavi, “Securing IoT-based RFID sys- tems: a robust authentication protocol using symmetric cryptography,” Sensors, vol. 19, no. 21, p. 4752, 2019.

A. Ghani, K. Mansoor, S. Mehmood, S. A. Chaudhry,

A. U. Rahman, and M. Najmus Saqib, “Security and key management in IoT-based wireless sensor networks: an au- thentication protocol using symmetric key,” International Journal of Communication Systems, vol. 32, no. 16, p. e4139, 2019.

C.-M. Chen, K.-H. Wang, K.-H. Yeh, B. Xiang, and T.-Y. Wu,

“Attacks and solutions on a three-party password-based authenticated key exchange protocol for wireless communi- cations,” Journal of Ambient Intelligence and Humanized Computing, vol. 10, no. 8, pp. 3133–3142, 2019.

K.-H. Wang, C.-M. Chen, W. Fang, and T.-Y. Wu, “A secure authentication scheme for internet of things,” Pervasive and Mobile Computing, vol. 42, pp. 15–26, 2017.
D. Mahto, D. A. Khan, and D. K. Yadav, “Security analysis of elliptic curve cryptography and RSA,” in Proceedings of the World Congress on Engineering, pp. 419–422, London, UK, July 2016.

Scyther, “Tool,” https://people.cispa.io/cas.cremers/scyther, 2020.
Python, “Programming Language,” https://www.python.org/: 2020.
C. J. F. Cremers, “The Scyther tool: veriﬁcation, falsiﬁcation, and analysis of security protocols,” in Computer Aided Ver- iﬁcation, pp. 414–418, Springer Berlin Heidelberg, Berlin, Germany, 2008.
N..js, “Nodejs,” https://nodejs.org/, 2020.
WEB3.js, https://web3js.readthedocs.io/en/1.0/, 2020.
Crypto, “L,” https://nodejs.org/api/crypto.html/, 2020.
Ecccrypto, “Library,” https://www.npmjs.com/package/ eccrypto/, 2020.
Express, “Framework,” https://expressjs.com/, 2020.
Docker, “Get Started with Docker,” https://www.docker.com/, 2020.
G. N. D’andrea, “Truﬄe—simple development framework for ethereum,” https://libraries.io/npm/truﬄe/2.1.1, 2020.
2020 JUICE, https://www.juzhen.io/.
M. T. Hammi, B. Hammi, P. Bellot, and A. Serhrouchni, “Bubbles of trust: a decentralized blockchain-based authen- tication system for IoT,” Computers & Security, vol. 78, pp. 126–142, 2018.