Hindawi

Security and Communication Networks

Volume 2020, Article ID 8836214, 16 pages
https://doi.org/10.1155/2020/8836214

Research Article
An Improved Blockchain-Based Authentication Protocol for IoT
Network Management

Mostafa Yavari ,1 Masoumeh Safkhani ,1 Saru Kumari ,2 Sachin Kumar ,3

and Chien-Ming Chen 4
1
Computer Engineering Department, Shahid Rajaee Teacher Training University, Tehran, Iran
2
Department of Mathematics, Chaudhary Charan Singh University, Meerut 250004, India
3
Department of Computer Science and Engineering, Ajay Kumar Garg Engineering College, Ghaziabad 201009, India
4
Shandong University of Science and Technology, Qingdao, Shandong, China

Correspondence should be addressed to Chien-Ming Chen; [email protected]

Received 19 July 2020; Revised 19 September 2020; Accepted 5 October 2020; Published 28 October 2020

Academic Editor: Debiao He

Copyright © 2020 Mostafa Yavari et al. This is an open access article distributed under the Creative Commons Attribution License,
which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

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.

1. Introduction powerful distributed system is blockchain [21] which for the

first time proposed by Satoshi Nakamoto. Blockchain is a
With the advent of Internet of Things (IoT) technologies, a technology comprising few old concepts, such as the ledger
large number of intelligent devices have been developed and and the consensus (the agreement of members of a group on
integrated into daily life [1–5]. By increasing number of an issue). This technology combines these concepts with the
devices and users, current architecture and the communi- help of a peer-to-peer network to access a distributed da-
cation protocols (centralized system) cannot give enough tabase with privacy preserving and security properties.
response to system requirements such as authentication, Blockchain has many security features such as integrity,
authorization, and access management. Although security distribution, and tamper-proofing. In a blockchain network,
and privacy are important issues in communication, various all network members take part in the verification process of
solutions have been proposed for security and privacy in information which takes part in the alternative role of the
Internet of Things (IoT) networks [6–12]. One of the im- trusted third party (TTP) on the system. It is very difficult to
portant solutions is use of distributed networks instead of manipulate information because of public surveillance of
centralized or decentralized networks [13–20]. A new and information. Public surveillance is done by a method called
2 Security and Communication Networks

consensus that means 51% of network members need to respectively. In Section 8, we compare the proposed protocol
collaborate to unauthorized changes in the information. in terms of the type of blockchain used, the implementation
Distributing the role of the TTP among network members platform, and security features with other related authen-
has also reduced the likelihood of distributed denial of tication schemes in this area, and at last Section 9 concludes
service (DDoS) attacks. As a result, system security is en- the paper with concluding remarks and suggestions for
sured. In contrast, the processing amount and system future works.
messages sent to the members of each node in the network
are very high. Also, because of the transparency of all in- 2. Related Works and Preliminaries
formation, privacy preserving becomes difficult and new
solutions are needed and these solutions should not impede This section addresses the important security requirements
the consensus process. Another problem is its low scalability for access control systems in the IoT networks and briefly
because of the fixed and unchangeable data and setting. presents a few related works. Since we used the blockchain to
Therefore, the cost of changing some parts of the blockchain store critical information securely in our proposed protocol,
network is much more than building a new network. As a the definition of blockchain technology and how it works are
result, the cost of upgrading the system is very high. also explained in this section. Also, we briefly explain the
In this regard, Cha et al. in [22] have presented an smart contract and its usage in our proposed protocol. Fi-
authentication scheme for the IoT using blockchain, nally, we will talk about how the blockchain was used in the
claiming that their protocol has made it possible for users to related works.
access and manage IoT device information with privacy. In
fact, they claimed that their protocol was able to establish
2.1. Blockchain. Blockchain was proposed in 2008 by Satoshi
user privacy and trust in IoT applications. In this paper, we
Nakamoto [21]. Blockchain includes blocks where blocks are
show that the protocol designed by Cha et al. has drawbacks
interconnected like a chain. Each block contains information
that make their design vulnerable to various attacks such as
such as block number, the hash of the previous block, a
secret disclosure, traceability, replay, and reuse of Token
nonce, and transaction information. By storing the hash of
attacks, which leads to loss of privacy and trust. Security
the previous block in each block, the chain will be formed.
analysis of the Cha et al.’s protocol before use prevents a lot
This chain is called the ledger. Figure 1 shows a simple
of possible damage. It also makes designers aware of such
example of the blockchain ledger. Each node in the network
errors in protocol design and avoid repeating them in their
has its ledger. Blockchain uses consensus mechanisms
designs. In this paper, we also offer suggestions for trou-
[23, 24] to verify the transaction and update the entire
bleshooting this protocol. Using these suggestions, we
ledger. At the time of adding a new transaction in the ledger,
provide an improved version of the protocol in terms of
all nodes in the network will check the correctness of the
security and cost, which is called IBCbAP.
information and, after approving, will add the new trans-
action to their ledger. Each user subscribes to the network by
1.1. Main Contribution. The contributions of the paper are registering a pair of public and private keys on the network.
as follows: This is done by recording a transaction. Each user’s keys are
stored in their wallet. Miners created the blocks. Miners are
(1) Presenting security weaknesses of Cha et al. block- nodes in the network, tasked with generating and approving
chain-based authentication and secure management blocks to the blockchain. To generate a block, the corre-
of privacy preferences scheme. sponding node solves a difficult problem, and the one who
(2) Addressing security pitfalls of Cha et al.’s scheme solves the problem sooner registers its block in the block-
and proposing a new improved one called IBCbAP. chain. Changing an approved block in the ledger is costly
and difficult. There are two types of blockchain: public and
(3) Formal and informal security analysis of IBCbAP.
private. In a public blockchain, anyone can participate in the
Formal proofing is done using the Scyther tool.
block generation and consensus process, but in a private
(4) Implementation of IBCbAP through JavaScript blockchain, only preapproved nodes can do this operation.
language and Ethereum local blockchain and con- Bitcoin [21] and Ethereum [25] are examples of the public
sidering its functionality and correctness. type, and Hyperledger [26] is an example of the private type
blockchain.
1.2. Paper Organization. We organize the rest of the paper as
follows. In Section 2, we will look at related works on the 2.2. Smart Contract. Smart contracts are executable codes
blending of two technologies of blockchain and IoT and also and memories, which are stored as transactions in the
provide some explanations on their security requirements blockchain. Smart contracts are executed by miners with a
and existing issues. We review the Cha et al.’s blockchain- fixed cost. By knowing the transaction address, it is possible
based authentication protocol and describe its security to call the smart contract for the network members. Because
pitfalls in Sections 3 and 4, respectively. In Section 5, we blockchain is irremovable, smart contracts can provide a
propose a new improved protocol called IBCbAP and de- great deal of confidence. One of the famous blockchains,
scribe its security and functionality features. We analyze the which is a smart contract provider, is Ethereum [25]. In the
security and functionality of IBCbAP in Sections 6 and 7, Ethereum network, any member can create a smart contract
Security and Communication Networks 3

Block N-1 Block N Block N + 1 operations. Lin et al. have used distributed reductions to
Hash of N-2th block Hash of N-1th block Hash of Nth block adapt their protocol to IoT conditions.
Hammi et al. have proposed a system to authenticate and
Transactions Transactions Transactions authorize IoT devices that also meet security requirements
such as confidentiality and integrity. They based the main idea
Hash of the block Hash of the block Hash of the block behind their scheme on the use of blockchain security benefits
and the segmentation of system components into unique
Figure 1: Chain of blocks in the blockchain technology [21].
areas. In these areas, known as bubbles, all members are
allowed to communicate with their bubble members and
and share it with anyone. In this paper, we use the testRPC identify other bubble members as attackers. ECDLP (Elliptic
[27] to implement the blockchain network. This library Curve Discrete Logarithm Problem) based cryptography is
creates a local Ethereum blockchain network. 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
2.3. Related Work. In the following, we introduce several blockchain to improve security and privacy on the Internet of
related kinds of research which have tried to use blockchain’s Vehicles (IoV) and transportation systems using 5G-VANET
security features, such as distribution, integrity, and tamper- [34]. In Xie et al.’s scheme, all RSU (Road Side Unit-5G-
proof properties to create security and privacy in commu- Station–Vehicle) members are connected and controlled by a
nications protocols. The first blockchain is provided by central SDN (Software Defined Network) controller. The
Bitcoin [21], which stores financial transactions about coins. number of messages sent by any vehicle and the message
In Bitcoin, if the transactions change, it can store identity authorization status are stored in the blockchain. In this
information and access policies. Ouaddah et al. designed a scheme, transactions are unchangeable and the vehicles
system to maintain privacy and security in a distributed cannot deny sending. As a result, as the error coefficient of a
manner, which is their main idea [28]. A problem with vehicle increases, the miners define more restrictions on the
Ouaddah et al.’s design is the high computational cost for transmission of the vehicle transaction, which will increase
network members. Novo [29], by decreasing of distribution, system’s security. In fact, in their scheme vehicles with data
has attempted the computations to fit the resources of the encryption protect privacy. Huang et al. have introduced a
devices. Novo separated the blockchain network from the system for controlling access to device resources according to
general network and communicates with the devices using device policies in [35]. The overall structure of Huang et al.’s
management hubs. This solution boosts performance and scheme is very similar to the overall structure of Cha et al.’s
reduces distribution. Compared to Ouaddah et al.’s design, it scheme. Huang et al. used DAG (Directed Acyclic Graph)-
boosts computational power to devices and increases the based blockchains [36]. DAG-based blockchains are suitable
probability of distributed denial of service (DDoS) attacks. for IoT applications because of their lightness and high speed.
In Novo’s protocol, miners cannot be a member of the Also, Huang et al. have proposed a consensus method. In their
network just cooperating to the blockchain network. The proposed consensus method, the nodes have a credit value
high computational load results from the block generation which comprises two variables: node activity and node
process. Using the lighter block generation process, we can honesty. The difficulty of the problem solved in block gen-
efficiently use the blockchain network in the Internet of eration is inversely related to the credit value. The speed of
Things (IoT). Dorri et al. proposed a method for the block storing a device’s transactions depends on its credit value. By
generation process and consensus, which is based on the reducing the credit value of a malicious device, the cost and
limitation of the number of blocks generated per unit time time of attack increase. Yao et al. introduced a lightweight
per node [30]. Dorri et al. have claimed that the proposed blockchain-based authentication system in [37]. Yao et al.
method is scalable and provides a proportional computa- specifically recommends this system for using in distributed
tional burden to network members. In their scheme, miners vehicular fog servers. Yao et al. have enabled one-time au-
are members of the network and their number and mem- thentication to access the services. They used the blockchain
bership are changed based on few parameters. Dorri et al. to store authentication history and reauthentication is se-
used smart homes network scenario. The interior man- lected by the devices. Sidorov et al. have proposed a block-
agement of each home is done by a central point inside the chain-based supply chain system in [38]. They have used
house, and it is described in [31]. Lin et al. by using RFID tags to track products and also have used blockchain as
blockchain, ABS (Attribute-Based Signature), and MRE a trusted third party. Sidorov et al. have claimed that they
(Multi-Receiver Encryption) have proposed a system for created a high level of privacy and security. The used
managing industrial devices and data collection [32]. In fact, blockchain type in the Sidorov et al.’s system is private and
Lin et al.’s protocol is presented for the development of messages are encrypted only using rotation operation, XOR
industry V.4 by blockchain. The structure of Lin et al.’s (Exclusive OR) operation, and HW (Hamming Weight)
protocol has five entities, including terminals, blockchain, function. Dwivedi et al. have provided a blockchain-based
cloud, industrial network, and physical resources. In this healthcare system in [39]. The need for privacy preserving and
scheme, commands are stored by the terminals at block- distribution in healthcare systems is justifiable reasons for
chain. The cloud and industrial network monitor the using blockchain in this plan. Dwivedi et al.’s scheme has used
blockchain and find the commands and then perform the cloud and smart contracts, which are used to store patient
4 Security and Communication Networks

data and analyze data according to the instructions of the the devices and the BCG is recorded in the blockchain and is
healthcare provider. They used blockchain to secure the in- done through it. We can say the blockchain plays the role of a
formation in the cloud and keep track of changes. In Dwivedi trusted third party (TTP). Therefore, there is no possibility of
et al.’s scheme, the patient sends information to the smart manipulating or violating information for the protocol’s parties.
contract by wearing and using IoT devices and the smart
contract decides according to the healthcare provider orders
and notifies the relevant doctor. 3.1.2. Cha et al.’s Proposed Signature. The signature used in
As seen in this section, many attempts have been made to [22] is based on ECDLP (Elliptic Curve Discrete Logarithm
integrate blockchain technology with the IoT. All of these efforts Problem) and has six steps including SETUP, SET-PARTIAL-
lead to the growth and maturity of blockchain use in the In- PRIVATE-KEY, SET-SECRET-VALUE, SET-PUBLIC-KEY,
ternet of Things [40–43]. An example is Cha et al.’s scheme [22], SIGN, and VERIFY. These steps by using notations represented
in which the authentication of IoT devices is done through in Table 1 will be briefly discussed in the following subsections
blockchain. In this paper, we show that Cha et al.’s designed and also are shown in Figure 4.
structure has its drawbacks and we offer solutions to address
them. (1) Setup. In the first step, according to the secret value of k, the
BCG selects two groups of G1 and G2 with the same q prime
3. Cha et al.’s Blockchain-Based Protocol order. The relationship between G1 and G2 is
e: G1∗ G1 ⟶ G2 , where P is the generator of G1 . G1 has
In this section, we explain Cha et al.’s blockchain-based bilinear pairing attribute, so the following relationship exists:
protocol [22] and its security analysis including secret
∀m, n ∈ Zq∗, ∀S, P ∈ G1 : e(mS, nP) � e(S, P)mn . (1)
disclosure, replay, traceability, and reuse Token attacks.
The BCG selects its private and public key pair as
3.1. Cha et al.’s Protocol. Recently, in [22], Cha et al. proposed s ∈ Zq∗ and PKBCG � s.P, respectively. Also BCG chooses
a new authentication protocol based on blockchain for share three hash functions with definitions
and access management of IoT device information as a dis- H1 : {0, 1}∗ × G1 ⟶ Zq∗ , H2 : {0, 1}∗ × G1 × G1 ⟶ Zq∗
tributed attitude. In this protocol, there are three main entities and H3 : {0, 1}∗ × G1 × G1 × G1 ⟶ Zq∗ , and ultimately the
called device, user, and blockchain connected gateway (BCG). values of G1 , G2 , q, e, P, PKBCG , H1 , H2 , H3 , e(P, P) are
Devices are the nodes in the network that share information or published by the BCG.
resources with conditions called Device policy, and other users,
device, or people who want to use the information and re- (2) Set-Partial-Private-Key. In this step, the BCG calculates
sources of the devices. BCG is an intermediary between the Ri , hi , si , and σ i1 values as below:
device and the user. These gateways assess users’ eligibility Ri � ri · P,
(permissions and authentication) to use the information and
resources of the devices according to policies. hi � H1 IDi , Ri , PKBCG 􏼁,
(2)
We use the scenario described in [22] to explain com- si � ri + hi · s mod q,
munication and process sequencing. In this scenario, each
user joins the blockchain network and registers its public σ i1 � s−1
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 ∈ Zq∗ is
Authentication processes and access policies management used which is generated using public parameters, master
are done by smart contracts. In this scenario, each device is private key, and the user Ui ’s identity IDi . After that, BCG
connected to a BCG. This connection is a logical connection sends (Ri , σ i1 ) to the user; the user once receives the mes-
?
and saved in the device and in the BCG smart contracts. sages immediately checks e(σ i1 , Ri + hi .PKBCG )�� e(P, P),
When a device connects to a BCG, it can be said that access where hi � H1 (IDi , Ri , PKBCG ).
to device information is done by this BCG.
As shown in Figure 2, the user first finds the BCG smart (3) Set-Secret-Value. In this step, the user selects a random
contract address and then accesses the list of subset devices. number as his private key. This key is notated with xi ∈ Zq∗ .
To use any device, the user must declare their agreement
with the device’s privacy policies. This agreement is stored in (4) Set-Public-Key. In this step, the user using his secret key,
the blockchain network so that the BCG can be used at the i.e., xi , generates his public key as PKi � xi .P.
time of request for access to device information by the user.
(5) Sign. At the beginning of this step, the user calculates the
amount of ki � H2 (IDi , PKi , Ri , PKBCG , m), where m is the
3.1.1. Smart Contracts. Here, we explain the implicit smart message to be signed, and calculates σ i2 � (ki .si + xi )− 1 .P. At
contract and their obligations in Cha et al.’s authentication the end, the user sends (m, Ri , σ i2 ) to the verifier.
protocol. Interactions between the device and the BCG (logical
communication), control of device information and privacy (6) Verify. In this step, the verifier computes the value of hi as
policies and BCG management are all done through smart H1 (IDi , Ri , PKBCG ) using the values of PKi and received
contracts. As shown in Figure 3, the communication between (m, Ri , σ i2 ). After that, the verifier calculates ki as
Security and Communication Networks 5

1. Smart contracts are

implemented and encapsulated
within the blockchain network.

2. Fetches device list and privacy User

policies by invoking gateway 6. The user sends a request to the
smart contract. device and transfers information.
Blockchain network

3. The user agrees to

the privacy policies
of the device. 5. The user sends an
access request to device
information to the
gateway. The gateway
4. The gateway stores the user's 1. The user asks IoT device
starts the authentication
approval in blockchain and the gateway
and authorization
uses it for further smart contract
process.
communications. address.

Blockchain connected
gateway (BCG)
Figure 2: Overview of Cha et al.’s blockchain-based authentication protocol.

Blockchain network

4. Logical authentication
function (bindRequest) is
called.

Device BCG
smart smart
5. Request confirmation of logical 3. The function of
contract contract
information is sent to the device establishing a logical
administrator. connection between
6.After verifying the device the device and the
manager, the process result is port (bindDevice) is
announced to the BCG smart called. This call is
contract and BCG made according to the
1. The administrator or owner of the device administrator. device’s address.
records the identification information,
device policy, and device smart contract as
a transaction on the blockchain network and
receives the transaction address. This address is used
to communicate and interact with the BCG.
2.The administrator sends the smart contract address to the BCG administrator to BCG administrator
establish a logical connection. Tracking this request is done through a BCG and device
Device smart contract.
administrator

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

H2 (IDi , PKi , Ri , PKBCG , m) and verifies the correctness of generates a random number (nonce Ni ) and then, using this
signature by checking whether e(σ i2 , ki .(Ri + hi .PKBCG )+ value, the public key of the user, BCG root key, and a hash
? N
PKi )�� e(P, P). If the condition is fulfilled, the signer is function (H), generates a key (KUii ). The combination of
authentic. Pj

user consent, policy (Pj ), and timestamp (Tij ) are encrypted

with the generated key and then stored in the blockchain.
3.1.3. Device Binding. The user sends a consent of the device The BCG sends the transaction ID (TIDij ) and the generated
policies (PPj ) to the BCG. Each BCG has a root key. The key to the user because the user is sure of its accuracy. In
user’s public key (PKi ) is also specified. The BCG initially future communications, stored information is the basis for
6 Security and Communication Networks

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 G1
s Master private key
PKBCG BCG public key, i.e., (s.P)
H, H1
Hash functions
H2 , H3
IDi User Ui ’s identity
SKdbcg Shared key between the device and the BCG
m Message
EK (.) Symmetric encryption function
Pj Device policy
PPj Consent of the Pj policy
Tij Timestamps
N
KUii Generated key between BCG and user Ui
P
PKi j User’s public key
ru , rd , rb Random numbers generated by user, device, and BCG, respectively
TIDij Transaction address added to blockchain because of acceptance policy Pj by Ui user
Ni Random numbers
SKubcg Shared key between the user and the BCG
ri Random numbers
‖ Concatenation

Blockchain connceted gateway (BCG) User (Ui)

s, PKBCG IDi, PKBCG
(1) BCG publishes
G1, G2, q, e, P, PKBCG, H1, H2, H3, e (P, P)
hi = H2 (IDi, Ri, PKBCG)
(2) Ri = ri.P,
(Ri, σi1) if e (σi1, Ri + hi.PKBCG) ≠ e (P, P):
hi = ri + hi.s mod q
σi = ri + hi.s mod q (3) Generate xi as secret key
σi1 = s–1
i .P (4) PKi = xi.P as public key
hi = H1 (IDi, Ri, PKBCG) and (m, Ri, σi2, PKi) ki = H2 (IDi, PKi, Ri, PKBCG, m) and
ki = H2 (IDi, PKi, Ri, PKBCG, m) (5) σi2 = (ki.si + xi)–1.P
(6) if e (σi1, Ki. (Ri + hi.PKBCG) + PKi) ≠ e (P, P):
break;

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

licensing access to the device. Figure 5 illustrates the device so, the BCG generates a random value (rij ∈ Zq∗ ) and
binding of Cha et al.’s protocol. then calculates Rij � rij .P, lij � H1 (IDi , Rij , σ ij ,
PKBCG ), sij � rij + lij , σ BCG � s−1ij .P and at last the
BCG sends (Rij , σ BCG ) to the user in response.
3.1.4. Access to the Device. Figure 6 illustrates how the user is
accessing the device. The implications of Figure 6 will be After receiving (Rij , σ BCG ) from the BCG, the user
discussed in the following. verifies the validity of the received values by com-
puting lij � H1 (IDi , Rij , σ ij , PKBCG ) and checking
(i) The user generates a signature for the access request ?
message (PPj ) using si � ri + hi .s, Ri � ri .P, hi � whether e(σ BCG , Rij + lij .PKBCG )�� e(P, P) or not. If
H1 (IDi , Ri , PKBCG ), xi , PKi , PPj , Kij � H2 (IDi , PKi , the accuracy of the received information is verified,
Ri , PKBCG , PPj ) as σ ij � (ki j.si + xi )− 1 and sends the access Token is calculated as below:
(PPj , Ri , σ ij ) to the BCG.
Once the BCG receives the message, it checks the
authenticity of the signature by checking whether Token � 􏼐PPj , Ri , σ ij , Rij , σ BCG 􏼑. (3)
?
e(σ ij , kij .(Ri + hi .PKBCG ) + PKi )�� e(P, P) or not. If
Security and Communication Networks 7

User (Ui) BCG Smart contract

Blockchain network
IDi, PKBCG, Ri s, PKBCG, K for the gateway

(1) PPj on privacy

(2) Generate a nonce Ni
policy PPj
N
KU i = H (K || Ni || PKi)
i PJ

EM = EUiNi H (PPj || Pj || Tij) (3) Store EM

PJ Add transaction in
blockchainand return
(4) TIDij
transaction ID (TIDij)
N (5) Invoke Log (TIDij)
(6) KUii , TIDij
PJ function in smart contract Invoke

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

User (Ui) BCG

Device Dk
IDi, PKBCG, Ri s, PKBCG, K
(1) kij = H2 (IDi, PKi, Ri, PKBCG, PPj)
σij = (kij.si + xi)–1.P (2) (PPj, Ri, σij)
(3) hi = H1 (IDi, Ri, PKBCG)
kij = H2 (IDi, PKi, Ri, PKBCG, PPj)
kij = (kij.si + xi)–1.P
if e (σi1, Ri + hi.PKBCG) ≠ e (P, P):
break;
Generate rij
(4) (Rij, σBCG) Rij = rij.P,
(5) lij = H1 (IDi, Rij, σij, PKBCG) lij = H1 (IDi, Rij, σij, PKBCG)
if e (σBCG, Rij. + lij.PKBCG) ≠ e (P, P): sij = rij + rij.s
break; σBCG = sij–1.P
(6) Token
Token = (PPj, Ri, σij, Rij.σBCG)
(7) Verify σij and σBCG
(8) Success/failure

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

Finally, the user may use the device by sending Token to So, he/she can eavesdrop, replay, modify, and delete any
the device. Access permission depends on the result of message or fabricate a new message.
verifying the validity of the received Token by the device.

4. Security Analysis of Cha et al.’s Blockchain- 4.2. Secret Disclosure Attack. According to (3), the Token is
generated by the values of the sent messages. Since Cha et al.
Based Authentication Protocol do not consider the channel secure, the attacker can
In this section, we will investigate Cha et al.’s protocol’s eavesdrop the transferred messages through the channel. As
security. This analysis includes the presentation of se- a result, generating Token by the attacker is only possible
curity attacks. We have applied four attacks on Cha et al.’s through the eavesdropping of the channel, resulting in
protocol comprising secret disclosure, replay, traceability, threats to the device’s resources and security. For this attack,
and reuse Token attacks. This section describes how the the attacker proceeds as below:
attacks are performed, their success probability and (1) The attacker eavesdrops transferred messages for one
complexity, and a solution to prevent the occurrence of run of the access to device phase of Cha et al.’s
the attacks. We base the proposed protocol on these protocol
solutions.
(2) Using PPj , Ri , σ ij , Rij , and σ BCG which eavesdropped
in access to device phase of Cha et al.’s protocol, the
4.1. The Adversary Model. Here, we used the common ad- attacker can calculate Token as (PPj , Rj , σ ij , σ BCG )
versary model [44–48] in which the adversary can fully (3) Using calculated Token in the previous step, the
control and eavesdrop the public communication channel. attacker can access and use the intended IoT device
8 Security and Communication Networks

The success probability of the attack is 1 and its com- unlimitedly, and the BCG or device cannot detect this sit-
plexity is one run of the protocol. We will fix this weakness in uation. This is because no fresh variable (such as random
our proposed protocol, i.e., IBCbAP. To solve this problem, numbers or timestamps) is used in the Token and the device
we do signature using HMAC (Hash-Based Message Au- has no role in creating the Token. So, by getting a Token, the
thentication Code) function and ECDLP (Elliptic Curve attacker and a malicious user can use the Token repeatedly
Discrete Logarithm Problem) encryption. Their details will and any members of the network do not figure out. This issue
be explained in Section 5.2. 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
4.3. Replay Attack. Because of the absence of new random
separately which are generated by all members who take part
values in each session, messages from each session are not
in the network. In the next section, we will address all of
different from other sessions, so a message is acceptable in all
abovementioned vulnerabilities which lead to proposing an
sessions. The attacker can gain BCG approval by sending
improved version of Cha et al.’s blockchain-based authen-
messages sniffed in previous sessions and impersonating the
tication protocol called IBCbAP. We also will conduct
user. The steps of this attack are as follows:
formal security analysis and informal security analysis of
(1) The attacker eavesdrops one session and stores IBCbAP. Formal proof will be done using the Scyther tool.
(PPj , Ri , σ ij ) message as N′ To show the functionality of IBCbAP, we will implement it
(2) The attacker starts a new session with BCG by by JavaScript language and the Ethereum local blockchain
sending N′ to the BCG network.
(3) BCG checks correctness of N′ and because of the
mentioned weakness in Cha et al.’s protocol, BCG
5. IBCbAP: The Improved Protocol
confirms the authenticity of the information Here, we improve Cha et al.’s protocol’s weaknesses by using
(4) BCG sends (Rij , σ BCG ) to the attacker the HMAC function instead of Cha et al.’s proposed sig-
(5) The attacker accesses the device. nature. We named the proposed protocol IBCbAP (Im-
proved Blockchain-based Authentication Protocol).
This attack is possible with the success probability of one According to [49], the speed and memory consumption in
and complexity of only one run of protocol’s eavesdropping. an ECDLP (Elliptic Curve Discrete Logarithm Problem)
encryption are less than RSA. Therefore, we use the ECDLP
4.4. Traceability Attack. Because of the absence of nonces or encryption method. We do the initial setting and selection of
timestamp in Cha et al.’s protocol’s transferred messages, all constant values just like Cha et al.’s protocol. As shown in
of them are static, so it is possible for the attacker to trace the Figures 7 and 8, respectively, the steps of IBCbAP are as
protocol parties using the content of the transferred mes- below.
sages. For this attack, it is enough for the attacker to proceed (i) Confirm access policy phase: In this phase, the user,
as below: after finding device policy by associated BCG, sends
(1) The attacker eavesdrops one run of protocol and its consent to device policies to the BCG. Also, the
stores the transferred messages BCG generates a SKubcga secret key and shares with
the user. In this phase, the used channel is secure.
(2) The attacker gets Ri related to Ui user, notated R′i
(ii) Create access Token phase: In this phase, the BCG
(3) After that, if the attacker sniffs the protocol messages
creates a Token for the user for using the device.
and compares the Ri with R′i, he/she can determine
Token is generated by the user, the device, and the
whether the message is for the Ui user or not, so
BCG participants securely. The key used in this phase
recognizing the user
is generated in the Confirm access policy phase in
The attacker can detect a user, with the probability of 1 which the used channel is secure.
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 5.1. Confirm Access Policy. In the first step, the user needs to
each session. By adding random nonces or timestamp to find the device access policies (Pj ) and agree to them. To
messages which are generated by all protocol parties, accept the device policy, he/she sends a message (PPj ) to the
messages sent in each session are different, and the possi- BCG according to the policy. The BCG generates a nonce
bility of tracing users is vanishing. (Ni ) upon which it receives PPj . The shared key between the
device and the BCG (SKubcg ) is created using the equation
below:
4.5. Reuse Token Attack. Cha et al. in [22] did not explain �� ��
their method for verifying the Token (in (3)) by the device. SKubcg � H􏼐IDi ��Ni ��SKBCG 􏼑. (4)
Also, despite the existing parameters in the protocol mes-
sages, the device cannot ensure that the Token has not This key is used in subsequent messages where H is a hash
duplicated and is correct. In other words, the user or attacker function, and SKBCG is a secret value associated with the BCG.
by receiving a Token can use the device’s resources The Pj , PPj , and a timestamp (T) are encrypted using the
Security and Communication Networks 9

User (Ui) BCG Smart contract

Blcokchain network
IDi, SKubcg SKubcg, SKBCG, SKdbcg for the gateway
(1) Request for acceptance
of Pj policy (PPj) (2) Generate a nonce Ni
SKubcg = H (IDi || Ni || SKBCG)
T = Timestamp
(7) Store EM
EM = ESKubcg (PPj || Pj || T) Add transaction in
(4) TIDij blockchain and return
(5) Invoke Log (TIDij) transaction ID (TIDij)
function in gatway
smart contract Invoke
(6) Send TIDij to User with
generated secret key (SKubcg)
(7) SKubcg, TIDij between BCG and User

Figure 7: IBCbAP: Confirm access policy phase.

Device Dk User (Ui) BCG

SKubcg IDi, SKubcg SKubcg, SKBCG, SKdbcg
(1) Generate random number ru
(2) PPj, ru
(3) Generate random number rd PPj = SKubcg (TIDij||ru)
(5) M′sig = HMAC (ru||rd||PPj, SKdbcg)
Msig = HMAC (ru||rd||PPj, SKdbcg) (4) (Msig, rd, ru, PPj)
if (Msig ≠ M′sig ): break;
Find PPj and verify it according to
blockchain transaction (the
(6) rb, M″sig connection with blockchain is
(7) done through RPC protocol)
″ ≠ HMAC (rb||ru||TIDij, SKubcg):
Msig
break; (8) Nsig Msig = HMAC (rb||ru||TIDij, SKubcg)
Nsig = HMAC (rb, SKubcg) (9) N′sig = HMAC (rb, SKubcg)
(10) ESK (Token||ru) if (Nsig ≠ M′sig): break;
(12) Verify ESK (Token||ru) ubcg
dbcg
(11) ESK (Token||rd) Generate access Token
dbcg

Figure 8: IBCbAP: Create access Token phase.

generated key and stored as a transaction in the blockchain. satisfying Msig′ � Msig condition. BCG decrypts the
The transaction address (TIDij ) along with the (SKubcg ) is PPj and ensures the user’s claim using the block-
sent to the user through the secure channel. It is worth noting chain network. In the next step, the BCG generates
that the channel between the BCG and the user is secure. another random number (rb ) and the value of
M′′sig � HMAC(rb ‖ru ‖TIDij , SKubcg ). And finally, it
sends (M′′sig , rb ) to the user.
5.2. Create Access Token. The user accesses the device (iv) Once the user received the (M′′sig , rb ) message, it
through the following steps: verifies the authority of the BCG. This is ac-
��
(i) The user produces PPj � ESKubcg (TIDij ���tru ), where complished
?
by checking whether
TIDij , ru , and SKubcg are the transaction number M′′sig �� HMAC(rb ‖ru ‖TIDij , SKubcg ) or not. The
associated with accepting device policies, a random device already knows the value of ru , TIDij , and
number, and a shared secret key between himself SKubcg . The continuation of the protocol is
and the BCG, respectively. The user sends (PPj , ru ) conditional upon the generated signature of the
to the device. user and the signature from the BCG. In the
following, the user generates a signed message as
(ii) The device once receives the message, generates a
Nsig � HMAC(rb , SKubcg ) and sends it to the
random number (rd ), and computes
BCG.
Msig � HMAC(ru ‖rd ‖PPj , SKdbcg ) and sends ?
(Msig , rd , ru , PPj ) to the BCG. (v) The BCG checks whether Nsig � Nsig ′ , where
′ � HMAC(rb , SKubcg ). If so, it � creates access
Nsig
(iii) Upon receipt of the message, the BCG generates a �
′ � HMAC(ru ‖rd ‖PPj , SKdbcg )) and Token and computes ESKubcg (Token��tru ) and sends
��
signature (Msig
it to the user. Also, it computes ESKdbcg (Token��trd )
compares it with the received signature (Msig ). The
and sends it to the device.
continuation of the protocol is related to the
10 Security and Communication Networks

��
When the user receives the message ESKubcg (Token��tru ) 6.1.4. Resistance to Traceability Attack. As mentioned be-
and decrypts it with the key SKubcg , if obtained ru is equal to fore, because of the involvement of random numbers in all
its one, the user trusts the received Token. The same is true transferred messages and changing these random numbers
for the device. 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
6. IBCbAP Security Analysis for the attacker to reveal any data in the current session, by
In this section, we consider the security of IBCbAP infor- eavesdropping the previous transferred messages because of
mally and also formally. We perform the formal security the lack of correlation between messages sent in each
checking using the Scyther tool [50]. session.

6.1.5. Unlinkability of Device. In the proposed protocol, we

6.1. Informal Security Analysis. Here, we informally prove
issue a separate key for each device. Each user is required to
that the improved protocol can resist against different at-
process, accept policies phase, and create an access Token
tacks. Informal analysis is based on the knowledge and
phase to use each device independently. We can say that the
creativity of the analyst.
user uses a separate Token for each device, so with the
disclosure of a Token, other devices are not threatened.
6.1.1. Resistance to DDoS Attack. Because of using block-
chain, the architecture of the system moves toward distri- 6.2. Formal Security Analysis. We have used the Scyther tool
bution architecture. The distribution of a system reduces the to check out the formal security of our proposed bockchain-
probability of the DDoS attack. However, because of the lack based authentication protocol. The Scyther is created with
of participation of IoT devices in the blockchain network Python [51] language and works according to security
and IoT devices connected to the blockchain network by claims. Claim events are used in role specifications to model
BCG, the distribution of the system decreases. IoT devices intended security properties [52]. There are several pre-
cannot directly participate in blockchain network, because defined claim types in the Scyther tool which are represented
many resources are needed for this purpose. Due to the use in Table 2.
of blockchain as the trusted third party (TTP) and the We have used Nisynch, Niagree, and Secret claims. The
distribution of IoT devices between different BCGs, the Nisynch claim checks desynchronization possibility. Niagree
possibility of a DDoS attack on the system is reduced. Also, claim considers that an agreement will not commit to the
since keys are not changed at each session and the existence changed values between the parties and the Secret claim
of different keys per user for each device, the possibility of states that the amount referred to it is secret. IBCbAP written
changing values and system desynchronization is in the Scyther language, i.e., security protocol description
eliminated. 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
6.1.2. Resistance to Replay Attack. Since, in the proposed are shown in Figures 9 and 10, respectively.
protocol, all members of the network participate in the As you can see in Figure 10, the Scyther tool could not
Create access Token phase, the possibility of the replay find an attack for IBCbAP. Therefore, IBCbAP provides a
attack is eliminated. Existence of shared secret values good level of security.
(SKubcg , SKdbcg ) between protocol parties and use of freshly
random values (ru , rd , rb ) by protocol parties lead each
session’s messages to be different from previous sessions
7. IBCbAP Implementation
messages; as a result, the possibility of the replay attack We have implemented IBCbAP to test the functionality and
vanishes. 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
6.1.3. Resistance to Secret Disclosure Attack. Important choice is WEB3.js [54] library to contact blockchain. This
messages sent between the user and the BCG are encrypted library uses the RPC (Remote Procedure Call) protocol to
by a shared �key, such as Token which is encrypted as interact with blockchain nodes. The system used in this
�
ESKubcg (Token��tru ). We also encrypt important messages simulation includes features such as 4 GB RAM, 1 TB HDD,
sent between the device and the BCG, such �� as Token, using a and Core i7 2.47 GHz CPU.
shared secret value, i.e., ESKdbcg (Token��trd ). Due to the
encryption of messages in the session, important informa-
tion remains confidential. Also, the existence of shared secret 7.1. Confirm Access Policy. The implemented architecture
values allows the protocol members to generate the message has four participants (user, BCG, device, and blockchain
authentication code such as Msig and Nsig , so they can network). User to use Pj device sends the PPj to the BCG
authenticate each other and avoid sending the data to an and then receives the shared key between itself and BCG
unauthorized party. (SKubcg ) through a secure channel. How to generate SKubcg is
Security and Communication Networks 11

Table 2: Claim events which defined in the Scyther tool.

Claim Description
There is no unauthorized access to the parameters transmitted in the protocol. For example, claim(Initiator, Secret, n) means
Secret
that the value of n remains confidential in the sense of initiator, and the third party has not been able to access it.
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
Alive
by R.
It ensures that the receiver has received message at the time that was sent by the sender. There is no agreement on the data
Weakagree
transmitted.
Niagree claim(R, Niagree, R′ ) claims that the agreed values between the receiver and the transmitter will remain unchanged.
claim(R, Nisynch, R′ ) claims that each message sent by the sender (R) corresponds to receiving the message by the receiver,
Nisynch
and all the steps are executed correctly and without interruption.

usertype sessionkey; claim_u2(user,Nisynch); var tid;

usertype integer; claim_u3(user,Niagree); fresh rb,rb′: Nonce;
} var pp,nsig,msig;
protocol bcggateway(device,user,bcg) role device macro msig″={rb,ru,tid}k(device,bcg);
{ {
hashfunction h; var ru,rb′: Nonce; recv_2(device,bcg, msig,rd,ru,pp );
role user var token: sessionkey; match({rd,ru,pp}k(device,bcg),msig);
{ var pp;
fresh ru : Nonce; fresh rd: Nonce; send_3(bcg,user,rb,msig″);
macro tid= h(ru); macro msig = {ru,rd,pp}k(device,bcg); recv_4(user, bcg,nsig );
var token: sessionkey; match(nsig,{rb}k(user,bcg));
var msig″; recv_1(user,device, pp,ru ); send_5(bcg ,device,{token,rd}k(device,bcg));
var rb,rb′ :Nonce; send_2(device,bcg, msig,rd,ru,pp); send_6(bcg,user,{token,ru}k(user,bcg));
macro pp={ru,tid}k(user,bcg); recv_5(bcg ,device,{token,rb′}k(device,bcg));
macro nsig={rb}k(user,bcg); claim_b1(bcg,Secret,token);
claim_d1(device,Secret,token); claim_b2(bcg,Nisynch);
send_1(user,device, pp,ru); claim_d2(device,Nisynch); claim_b3(bcg,Niagree);
recv_3(bcg,user,rb,msig″); claim_d3(device,Niagree); }
match(msig″,{rb,ru,tid}k(user,bcg)); } }
send_4(user, bcg, nsig); role bcg
recv_6(bcg,user,{token,rb′}k(user,bcg)); {
fresh token: sessionkey;
claim_u1(user,Secret,token); var rd,ru: Nonce;

Figure 9: Scyther implementation of IBCbAP in the spdl.

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.

7.2. Create Access Token. Figure 8 shows the Create access

Token phase. At this phase, the user starts the process of
issuing the access Token by sending ru and PPj to the device.
According to what was mentioned in Section 5.2, the device
starts the Token creation process when the user receives the
message. Finally,
�� BCG creates a Token and sends �� it as
ESKubcg (Token��tru ) to the user and as ESKdbcg (Token��trd ) to
the device. We performed this phase 10 times and have a
total time of 1200 milliseconds. The major time consumed at
this phase is related to encryption operations. Figure 13
shows the graphical user interface indicating successful
Figure 10: IBCbAP’s security analysis result, by the Scyther tool. receipt of the Token from BCG.

explained in Section 5.2. The user uses this key in the create 7.3. Ethereum Network. To implement the blockchain net-
access Token phase. At the Confirm access policy phase, the work, we have used the testRPC [27] library. This library
channel is secure. We run this phase 10 times and took 1363 creates a local blockchain network. Figure 14 illustrates the
milliseconds. Most of the time spent in this phase is due to launch of this library. The testRPC default creates 10
12 Security and Communication Networks

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.
Security and Communication Networks 13

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 Secret disclosure attack Blockchain Consensus
Implementation
resistance resistance type mechanism
IBCbAP √ √ Public Proof of stack JavaScript, RPC protocol
[22] × × Public Proof of stack Java, RPC protocol
Berkeley DB version 4.8., bitcoind
[28] √ √ Public Proof of work
regtest
[29] √ √ Not specified Not specified Docker [58] and truffle [59]
[32] √ √ Private Bayesian fault JUICE [60]
[61] √ √ Public Proof of work C++

accounts when building a local blockchain. We use one of smart contract (see Figure 15). It is worth noting that the
these accounts. We used Remix tool to deploy the initial smart contract used is simplified and is suitable for
smart contract of the BCG, and Solidity language wrote the implementing Confirm access policy and Create access
14 Security and Communication Networks

Token phase. We used the Crypto [55] library and the Data Availability
sha256 algorithm to generate HMAC. We used the ecccrypto
[56] library to perform ECC encryption. Also, we used the No data were used to support this study.
Express [57] framework to build the server for each protocol
party. It should be noted that we set up the servers for each Conflicts of Interest
protocol party and blockchain network on a single system on
separate ports. As a result, each phase is short. So, here we The authors declare that there are no conflicts of interest
have shown it is possible to implement the proposed pro- regarding the publication of this paper.
tocol with existing technologies and facilities. It is worth
noting that we achieve measured times with only one device, References
one user, and one port.
[1] E. K. Wang, J. Yu, C.-M. Chen, S. Kumari, and J. J. Rodrigues,
“Data augmentation for internet of things dialog system,”
8. Comparison Mobile Networks and Applications, pp. 1–14, 2020.
[2] C.-M. Chen, B. Xiang, Y. Liu, and K.-H. Wang, “A secure
In this section, we compare our proposed protocol with its authentication protocol for internet of vehicles,” IEEE Access,
predecessor, i.e., Cha et al.’s protocol as well as other related vol. 7, pp. 12 047–12 057, 2019.
schemes. As can be seen in Table 3, our proposed protocol [3] K.-H. Wang, C.-M. Chen, W. Fang, and T.-Y. Wu, “On the
has complete security compared to other protocols. Since the security of a new ultra-lightweight authentication protocol in
type of blockchain used and the specifications of the system iot environment for rfid tags,” The Journal of Supercomputing,
are very different in different designs, we only got the time in vol. 74, no. 1, pp. 65–70, 2018.
our system and it was not possible to compare time with [4] S. Qu, L. Zhao, and Z. Xiong, “Cross-layer congestion control
of wireless sensor networks based on fuzzy sliding mode
other designs. The time of our proposed protocol for Create
control,” Neural Computing and Applications, vol. 32, no. 17,
access Token and Confirm access policy phases is 1200 and pp. 13505–13520, 2020.
1363 milliseconds, respectively. [5] C.-M. Chen, Y. Huang, K.-H. Wang, S. Kumari, and
M.-E. Wu, “A secure authenticated and key exchange scheme
9. Conclusion for fog computing,” Enterprise Information Systems, pp. 1–16,
2020.
Nowadays, blockchain and Internet of Things (IoT) tech- [6] C.-T. Li, C.-C. Lee, and C.-Y. Weng, “An extended chaotic
nologies are bonding. The blockchain first attracted atten- maps based user authentication and privacy preserving
tion as part of a wave of crypto currencies, especially Bitcoin, scheme against dos attacks in pervasive and ubiquitous
which challenged the normal course of financial transac- computing environments,” Nonlinear Dynamics, vol. 74,
tions. But it was not the blockchain financial transactions no. 4, pp. 1133–1143, 2013.
[7] C.-C. Lee, M.-S. Hwang, and I.-E. Liao, “Security enhance-
that caught the attention of IoT activists, but rather the data
ment on a new authentication scheme with anonymity for
exchanges. Blockchain is essentially an antihacking, dis- wireless environments,” IEEE Transactions on Industrial
tributed, and event logging mechanism that appears to be Electronics, vol. 53, no. 5, pp. 1683–1687, 2006.
very useful for solving key issues related to networks where [8] C.-T. Li, C.-Y. Weng, and C.-C. Lee, “A secure rfid tag au-
connected devices automatically interact with each other, thentication protocol with privacy preserving in telecare
i.e., IoT. Because of the importance of security in IoT, many medicine information system,” Journal of Medical Systems,
schemes have been proposed in this subject. In this paper, we vol. 39, no. 8, p. 77, 2015.
examined Cha et al.’s blockchain-based authentication [9] S. K. Dwivedi, R. Amin, and S. Vollala, “Blockchain based
protocol. We illustrated the weaknesses of Cha et al.’‘s secured information sharing protocol in supply chain man-
protocol by applying secret disclosure, replay, traceability, agement system with key distribution mechanism,” Journal of
Information Security and Applications, vol. 54, p. 102554,
and reuse Token attacks with a success probability of one
2020.
and complexity of one run of protocol. To address Cha [10] S. K. Dwivedi, R. Amin, S. Vollala, and R. Chaudhry,
et al.’s protocol’s security vulnerabilities, we also proposed “Blockchain-based secured event-information sharing pro-
an improved protocol called IBCbAP and proved its security tocol in internet of vehicles for smart cities,” Computers &
in an informal way and also in formal way by the Scyther Electrical Engineering, vol. 86, p. 106719, 2020.
tool. Finally, we implemented IBCbAP using the JavaScript [11] A. Irshad, M. Usman, S. A. Chaudhry, H. Naqvi, and
programming language and the Ethereum local blockchain M. Shafiq, “A provably secure and efficient authenticated key
network. We investigated the feasibility of implementing agreement scheme for energy internet based vehicle-to-grid
IBCbAP and measured the timing of some processes. The technology framework,” IEEE Transactions on Industry Ap-
comparisons show that IBCbAP compared to its prede- plications, vol. 56, no. 4, pp. 4425–4435, 2020.
cessor, i.e., Cha et al.’s protocol, is completely secure and the [12] K. Mahmood, J. Arshad, S. A. Chaudhry, and S. Kumari, “An
enhanced anonymous identity-based key agreement protocol
cost and time of its implementation are reasonable. One of
for smart grid advanced metering infrastructure,” Interna-
the most important issues in the IoT network is the transfer tional Journal of Communication Systems, vol. 32, no. 16,
of ownership. In future works, we plan to work on the design p. e4137, 2019.
of blockchain-based ownership transfer protocols which [13] P. K. Sharma, N. Kumar, and J. H. Park, “Blockchain tech-
enables the transfer of ownership in a distributed and secure nology toward Green IoT: opportunities and challenges,”
manner. IEEE Network, vol. 34, no. 4, pp. 263–269, 2020.
Security and Communication Networks 15

[14] V. Dedeoglu, R. Jurdak, A. Dorri et al., “Blockchain tech- [33] L. Xie, Y. Ding, H. Yang, and X. Wang, “Blockchain-based
nologies for IoT,” in Advanced Applications of Blockchain secure and trustworthy internet of things in SDN-enabled 5g-
Technology, pp. 55–89, Springer, Berlin, Germany, 2020. VANETs,” IEEE Access, vol. 7, pp. 56 656–56 666, 2019.
[15] S. Shamshad, K. Minahil, K. Mahmood, and C.-M. Chen, “A [34] S. A. A. Shah, E. Ahmed, M. Imran, and S. Zeadally, “5G for
secure blockchain-based e-health records storage and sharing vehicular communications,” IEEE Communications Maga-
scheme,” Journal of Information Security and Applications, zine, vol. 56, no. 1, pp. 111–117, 2018.
vol. 55, p. 102590, 2020. [35] J. Huang, L. Kong, G. Chen, M.-Y. Wu, X. Liu, and P. Zeng,
[16] B. C. Florea and D. D. Taralunga, “Blockchain IoT for smart “Towards secure industrial IoT: blockchain system with
electric vehicles battery management,” Sustainability, vol. 12, credit-based consensus mechanism,” IEEE Transactions on
no. 10, p. 3984, 2020. Industrial Informatics, vol. 15, no. 6, pp. 3680–3689, 2019.
[17] G. Yu, X. Zha, X. Wang et al., “Enabling attribute revocation [36] S. Popov, “The Tangle,” Cit. on, p. 131, 2016.
for fine-grained access control in blockchain-IoT systems,” [37] Y. Yao, X. Chang, J. Misic, V. B. Misic, and L. Li, “BLA:
IEEE Transactions on Engineering Management, vol. 67, no. 4, blockchain-assisted lightweight Anonymous authentication
pp. 1213–1230, 2020. for distributed vehicular fog services,” IEEE Internet of Things
[18] P. P. Ray, D. Dash, K. Salah, and N. Kumar, “Blockchain for Journal, vol. 6, no. 2, pp. 3775–3784, 2019.
IoT-based healthcare: background, consensus, platforms, and [38] M. Sidorov, M. T. Ong, R. V. Sridharan, J. Nakamura,
use cases,” IEEE Systems Journal, 2020. R. Ohmura, and J. H. Khor, “Ultralightweight mutual au-
[19] G. Rathee, M. Balasaraswathi, K. P. Chandran, S. D. Gupta, thentication RFID protocol for blockchain enabled supply
and C. Boopathi, “A secure IoT sensors communication in chains,” IEEE Access, vol. 7, pp. 7273–7285, 2019.
industry 4.0 using blockchain technology,” Journal of Ambient [39] A. Dwivedi, G. Srivastava, S. Dhar, and R. Singh, “A
Intelligence and Humanized Computing, 2020. decentralized privacy-preserving healthcare blockchain for
[20] S. Gupta, V. Malhotra, and S. N. Singh, “Securing IoT-driven IoT,” Sensors, vol. 19, no. 2, p. 326, 2019.
remote healthcare data through blockchain,” in Advances in [40] E. K. Wang, C.-M. Chen, D. Zhao, W. H. Ip, and K. L. Yung,
Data and Information Sciences, pp. 47–56, Springer, Berlin, “A dynamic trust model in internet of things,” Soft Com-
Germany, 2020. puting, vol. 24, no. 8, pp. 5773–5782, 2020.
[21] S. Nakamoto, Bitcoin: A Peer-To-Peer Electronic Cash System, [41] H. Xiong, Y. Wu, C. Jin, and S. Kumari, “Efficient and privacy-
2008, https://bitcoin.org/en/bitcoin-paper. preserving authentication protocol for heterogeneous systems
[22] S.-C. Cha, J.-F. Chen, C. Su, and K.-H. Yeh, “A blockchain in IIOT,” IEEE Internet of Things Journal, 2020.
connected gateway for BLE-based devices in the internet of [42] H. Zhu, X. Wang, C.-M. Chen, and S. Kumari, “Two novel
things,” IEEE Access, vol. 6, pp. 24 639–724 649, 2018. semi-quantum-reflection protocols applied in connected
[23] E. K. Wang, R. Sun, C.-M. Chen, Z. Liang, S. Kumari, and
vehicle systems with blockchain,” Computers & Electrical
M. K. Khan, “Proof of X-repute blockchain consensus pro-
Engineering, vol. 86, p. 106714, 2020.
tocol for IoT systems,” Computers & Security, vol. 95,
[43] J.-H. Hsiao, R. Tso, C.-M. Chen, and M.-E. Wu, “Decen-
p. 101871, 2020.
tralized e-voting systems based on the blockchain technol-
[24] E. K. Wang, Z. Liang, C.-M. Chen, S. Kumari, and M. K. Khan,
ogy,” in Advances in Computer Science and Ubiquitous
“PoRX: a reputation incentive scheme for blockchain con-
Computing, pp. 305–309, Springer, Berlin, Germany, 2017.
sensus of IIoT,” Future Generation Computer Systems,
[44] S. Hussain and S. A. Chaudhry, “Comments on “biometrics-
vol. 102, pp. 140–151, 2020.
based privacy-preserving user authentication scheme for
[25] V. Buterin, “Ethereum White Paper,” GitHub Repository, pp.
cloud-based industrial internet of things deployment,” IEEE
22–23, 2013.
[26] Hyperledger, “Open Source Blockchain Technologies,” Internet of Things Journal, vol. 6, no. 6, pp. 10 936–10 940,
https://www.hyperledger.org/, 2020. 2019.
[27] TestRPC, “Library,” https://www.npmjs.com/package/ [45] K. Mansoor, A. Ghani, S. Chaudhry, S. Shamshirband,
ethereumjs-testrpc/, 2020. S. Ghayyur, and A. Mosavi, “Securing IoT-based RFID sys-
[28] A. Ouaddah, A. Abou Elkalam, and A. Ait Ouahman, tems: a robust authentication protocol using symmetric
“Fairaccess: a new blockchain-based access control framework cryptography,” Sensors, vol. 19, no. 21, p. 4752, 2019.
for the internet of things,” Security and Communication [46] A. Ghani, K. Mansoor, S. Mehmood, S. A. Chaudhry,
Networks, vol. 9, no. 18, pp. 5943–5964, 2016. A. U. Rahman, and M. Najmus Saqib, “Security and key
[29] O. Novo, “Blockchain meets IoT: an architecture for scalable management in IoT-based wireless sensor networks: an au-
access management in IoT,” IEEE Internet of Things Journal, thentication protocol using symmetric key,” International
vol. 5, no. 2, pp. 1184–1195, 2018. Journal of Communication Systems, vol. 32, no. 16, p. e4139,
[30] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, “LSB: a 2019.
lightweight scalable blockchain for IoT security and privacy,” [47] C.-M. Chen, K.-H. Wang, K.-H. Yeh, B. Xiang, and T.-Y. Wu,
2017, https://arxiv.org/abs/1712.02969v1. “Attacks and solutions on a three-party password-based
[31] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, authenticated key exchange protocol for wireless communi-
“Blockchain for IoT security and privacy: the case study of a cations,” Journal of Ambient Intelligence and Humanized
smart home,” in Proceedings of the 2017 IEEE International Computing, vol. 10, no. 8, pp. 3133–3142, 2019.
Conference on Pervasive Computing and Communications [48] K.-H. Wang, C.-M. Chen, W. Fang, and T.-Y. Wu, “A secure
Workshops (PerCom workshops), pp. 618–623, IEEE, Kona, authentication scheme for internet of things,” Pervasive and
HI, USA, March 2017. Mobile Computing, vol. 42, pp. 15–26, 2017.
[32] C. Lin, D. He, X. Huang, K.-K. R. Choo, and A. V. Vasilakos, [49] D. Mahto, D. A. Khan, and D. K. Yadav, “Security analysis of
“BSeIn: a blockchain-based secure mutual authentication with elliptic curve cryptography and RSA,” in Proceedings of the
fine-grained access control system for industry 4.0,” Journal of World Congress on Engineering, pp. 419–422, London, UK,
Network and Computer Applications, vol. 116, pp. 42–52, 2018. July 2016.
16 Security and Communication Networks

[50] Scyther, “Tool,” https://people.cispa.io/cas.cremers/scyther,

2020.
[51] Python, “Programming Language,” https://www.python.org/:
2020.
[52] C. J. F. Cremers, “The Scyther tool: verification, falsification,
and analysis of security protocols,” in Computer Aided Ver-
ification, pp. 414–418, Springer Berlin Heidelberg, Berlin,
Germany, 2008.
[53] N..js, “Nodejs,” https://nodejs.org/, 2020.
[54] WEB3.js, https://web3js.readthedocs.io/en/1.0/, 2020.
[55] Crypto, “L,” https://nodejs.org/api/crypto.html/, 2020.
[56] Ecccrypto, “Library,” https://www.npmjs.com/package/
eccrypto/, 2020.
[57] Express, “Framework,” https://expressjs.com/, 2020.
[58] Docker, “Get Started with Docker,” https://www.docker.com/,
2020.
[59] G. N. D’andrea, “Truffle—simple development framework for
ethereum,” https://libraries.io/npm/truffle/2.1.1, 2020.
[60] 2020 JUICE, https://www.juzhen.io/.
[61] 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.