Received 24 January 2023, accepted 24 February 2023, date of publication 2 March 2023, date of current version 8 March 2023.

Digital Object Identifier 10.1109/ACCESS.2023.3251651

Blockchain Regulated Verifiable and Automatic

Key Refreshment Mechanism for IoT
RAAJ ANAND MISHRA1 , (Student Member, IEEE), ANSHUMAN KALLA 2 , (Senior Member, IEEE),
AN BRAEKEN 3 , (Member, IEEE), AND MADHUSANKA LIYANAGE 4 , (Senior Member, IEEE)
1 DellTechnologies, Bengaluru 560071, India
2 Chhotubhai Gopalbhai Patel Institute of Technology (CGPIT), Uka Tarsadia University (UTU), Bardoli 394620, India
3 IndustrialEngineering Department (INDI), Vrije Universiteit Brussel, 1050 Brussel, Belgium
4 School of Computer Science, University College Dublin, Dublin 4, D04 V1W8 Ireland

Corresponding author: Madhusanka Liyanage ([email protected])

This work was supported in part by the European Union in CONFIDENTIAL 6G Project under Grant 101096435, and in part by the
Science Foundation Ireland under CONNECT Phase 2 Projects under Grant 13/RC/2077_P2.

ABSTRACT Internet of Things (IoT) has proved its applicability in numerous domains, such as healthcare,
agriculture, automobile, industrial production, logistics, and supply chain management. Looking at the
current trend, we expect a massive proliferation of such IoT devices all around us. However, one of the issues
with the widespread use of IoT is the increasing complexity of the underlying architecture, which leads to
difficulty in ensuring security compliance. Key refreshment, one of the critical aspects of key management,
requires a regular update of the key used to provide strong security. However, in most cases, keys are not
updated. If they are updated, the update logs (e.g., time of last key update) are not available for all entities
to verify and establish trust in the system. Moreover, the rules for key refreshment are also not defined
transparently. In this direction, the present work proposes a blockchain-regulated, secure, verifiable, and
automatic key refreshment mechanism for IoT systems. The proposed mechanism enables users to verify the
freshness of the security keys (being used), thereby relying on the data from IoT devices and establishing trust
in an IoT system. The proposed mechanism is driven by blockchain technology and smart contract. As proof
of concept, we have implemented the proposed solution using Ethereum and Hyperledger Fabric blockchains.
Cost, scalability, and security (formal and informal) analyses have been carried out for performance analysis.
The results show the economic viability and strong security of the proposed mechanism.

INDEX TERMS Internet of Things (IoT), Industrial Internet of Things (IIoT), blockchain, smart contracts,
security, authentication, Ethereum.

I. INTRODUCTION The network server’s job is to aggregate the required info

The Internet of Things (IoT) paradigm has significantly con- from deployed sensors and send it to different requesting
tributed to the improved landscape of the digital world around applications. Each of these applications’ users must ensure
us. It has proved its applicability in various domains such that the network operator offers sufficient security for com-
as healthcare, agriculture, automobile, industrial production, munication with the underlying devices [1].
logistics, and supply chain management. Following the trend, However, when it comes to key refreshment, it is well
one can find many instances where different applications known that many network operators never (or rarely)
use the same Internet of Things (IoT) devices concurrently. refresh the session key due to a lack of maintenance or
For example, an environmental sensor device can be used the non-existence of any auditing mechanism. LoRaWAN
simultaneously for applications focusing on smart agricul- defines the network architecture for long-range LoRa com-
ture, air pollution study, or transport and logistics planning. munication technology and recommends two methods for
periodically updating session keys. One is after a certain
The associate editor coordinating the review of this manuscript and period, and another is when a counter reaches a predefined
approving it for publication was Byung-Seo Kim . value [2]. An advanced alternative has been proposed in [3],

This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/
21758 VOLUME 11, 2023
R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

also called the Key Updating Scheme (KUS). In the KUS, Blockchain is a decentralized peer-to-peer (P2P) network
there are two types of triggers to update the session keys; of nodes where all the participating nodes locally store a copy
event-driven and time-driven. For an event-driven trigger, of a distributed ledger. This ledger is cryptographically sealed
a key update process is initiated each time an unusual behav- and is updated in append-only mode after establishing the
ior is detected. In comparison, a time-driven trigger advocates consensus among the majority of the nodes. These proper-
the key refreshment after a specific time or when a counter ties, such as a decentralized P2P network, distributed ledger,
reaches a value or after a randomly determined period. cryptographic techniques, and consensus-based append-only
Another important issue with the key refreshment proce- updates, make the BC an important choice for storing key
dure is that its rules are implicitly defined, which means they refreshment updates. Furthermore, smart contracts running
are not transparent. Neither the application providers nor the on top of the blockchain are self-executable codes that pro-
end-users have any control. Both rely entirely on the network vide autonomous execution, which enables enforcing auto-
server for the key management process and assume that the matic key updates.
security of the communication is intact. Although a lot of The paper is organized as follows. Section II presents
attention has been given to the key management among the related work. In Section III, several preliminaries are dis-
communication parties, to the best of our knowledge, there is cussed. Section IV provides details on the proposed system.
currently no solution available that addresses transparency or Implementation and experimental results are explained in
verification features from the viewpoint of end-users [1]. Section V, while the security evaluation is outlined in Section
Thus, some of the questions we focus on in the current VI. Conclusions and suggestions for future work are given in
work are: How can all the entities (in particular users) of an Section VII.
IoT ecosystem know which key refreshment mechanism is
used (and its rules)? Can the key updates be automatically II. RELATED WORK
rolled out strictly as per the predefined key refreshment mech- There are many blockchain-based solutions for key manage-
anism? How to enable (decentralized) verification of the past ment proposed in the literature. This section describes the
key updates carried out so far? most relevant and recent proposals.
To answer these questions, the following are the contribu- There are proposals dedicated to particular use-case and
tions made by this paper: application domains. For instance, in [4], a blockchain-based
distributed key management scheme for heterogeneous Fly-
• Propose a blockchain and smart contract-based verifi- ing Ad hoc Networks (FANET) is presented. The scheme
able key refreshment mechanism that securely and auto- allows UAVs to update their public/private key pairs, migrate
matically enforces the key updates between the network between clusters, and securely revoke malicious drones.
server and IoT devices. In [5], a blockchain-based distributed multicast key man-
• Leverage smart contract for transparently and immutably agement approach is discussed to enable secure communi-
defining the rules for the key refreshment. cations in a smart grid. Authors in [6] proposed a secure
• Keep the key refreshment scheme computationally light blockchain-based key management and power-efficient rout-
for the resource-constrained IoT devices. ing for content-centric decentralized Vehicular Named Data
• Implement and analyze the proposed mechanism using Networking (VNDN). In [7], an access control system relying
both public and private blockchains, and compare the on a blockchain is proposed to enable traceability and revo-
performance with a non-blockchain solution (which cability for IIoT and to allow secure data sharing for smart
does not allow transparent verification). factories. In each of these proposals, key management relied
• Evaluate the cost and security (both from a protocol on public-key-based mechanisms.
viewpoint and from a blockchain-related viewpoint) of In [8], blockchain-based smart contracts are proposed
the proposed mechanism. to deal with certificate-related operations. Moreover, the
lightweight Elliptic Curve Qu Vanstone (ECQV) certificates
The proposed mechanism offers three distinct advantages. are included to allow resource-constrained IoT devices to
First, the application server can offer its users protection participate in the process.
against potential security leaks, for instance, making it impos- A novel blockchain-based decentralized key management
sible to derive the previous session keys in case one of the protocol for device-to-device communication is presented
session keys is retrieved, which is called perfect forward in [9]. Here, key management relies on symmetric key-based
secrecy. Second, since blockchain immutably keeps track mechanisms in which network members are distributed into
of all the key updates that have happened ever thus the logical sets. A device shares a distinct pairwise key with each
proposed mechanism provides provenance and verifiability. member of its set and a pairwise set key with the members of
Third, because all the rules of enforced key refreshment are each set.
immutably encoded in a smart contract, all the participating In [10], a permissioned blockchain solves the problem that
and allowed entities can transparently view them. All these the root key is unchanged throughout the device’s life in the
benefits help offer public verifiability, which builds trust for LoRaWAN key management. The key update process relies
the applications’ users (and developers). on the Elliptic Curve Diffie-Hellman (ECDH).

VOLUME 11, 2023 21759

 R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

TABLE 1. Comparison of our work with other pertinent works.

A blockchain-based solution, called PERMANENT, has the system architecture and the corresponding security
been proposed in [11] to deal with publicly verifiable remote requirements.
attestation for IoT. Here, the blockchain stores all the previ-
ous attestation results of the devices and ensures that each
A. BLOCKCHAIN AND SMART CONTRACTS
interacting device can obtain the corresponding attestation
Blockchain, the most popular type of Distributed Ledger
result to verify the trustworthiness of the operating system
Technology (DLT), is implemented as a decentralized Peer-
and application software.
to-Peer (P2P) network of nodes. Together, these nodes are
Table 1 summarises all the existing related works discussed
responsible for maintaining and updating a cryptographically
above and distinguishes our work from those. The primary
secure and distributed digital ledger. The underlying data
goal of this paper is to provide a decentralized, transpar-
structure used for building the distributed ledger is a logically
ent, automatic, and verifiable mechanism for enforced key
linked chain of blocks. Every block contains a set of legiti-
refreshment. Our paper presents the first approach in which
mate transactions and is time-stamped and cryptographically
a smart contract is developed dealing explicitly with the
sealed. As the new blocks are created with time, every new
enforced key refreshment. Moreover, most of the related
block is logically linked with the most recent block in the
works on key management via blockchain technology rely
ledger using a cryptographic (hash-based) chain [15].
on public-key cryptography, which is heavy on computation
Smart contracts are self-executable and self-enforceable
for the often constrained devices in the field. In addition,
codes that run on top of the blockchain. Unlike paper-based
many of the proposed works do not have a corresponding
traditional contracts, smart contracts encode all the terms
blockchain-based implementation and only offer simulation
and conditions of agreements between participating entities.
to provide performance results. As can be seen from Table 1,
Thanks to the programming capability, smart contracts can
our paper clearly distinguishes from the rest of the literature
be designed with pre-defined conditions, enabling automatic
in its unique scenario of key refreshment management in a
execution when these conditions are met in the future. Thus,
decentralized manner, using symmetric key cryptography and
when deployed on top of the blockchain, smart contracts offer
providing an effective implementation.
code immutability, transparency, autonomy, and trust within
Moreover, we here also explicitly show the difference
the system [16].
between the two blockchains by implementing our security
Two fundamental types of blockchains are public and
solution and demonstrate the significant impact of choice on
private blockchains. Public blockchains such as Ethereum
the performance. Note that for choosing a proper blockchain
have no restriction for entities willing to join the blockchain
for a particular use-case, several papers also already described
network and participate in the block mining process. Thus,
the difference in a theoretical [12], [13] and empirical
such blockchains are open, and anyone can perform read
way [14] between the Hyperledger Fabric and Ethereum
and write operations on the distributed ledger. Whereas in
blockchains.
private blockchains, for example, Hyperledger Fabric, only
the vetted participants can join the network and operate
III. PRELIMINARIES on the ledger. Hence, a private blockchain forms a closed
We start with a short description of the blockchain and system. Because only a limited number of known entities
cryptographic operations background. Next, we discuss participate in a private blockchain, neither a computationally

21760 VOLUME 11, 2023

R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

intensive block-mining process nor an incentive mecha- blockchain network in our setup. Each connected entity has a
nism is required. Thus, the throughput scalability of private pair of public and private keys, which ensures authenticity,
blockchains is much higher than public blockchains. authorization, and non-repudiation. For enforcing the key
updates, a smart contract with the rules of key refreshment
B. CRYPTOGRAPHIC OPERATIONS
and validation logic is deployed on the blockchain network
by the network server.
There are two main types of cryptographic operations: sym-
metric key and public key-based operations. Public key-based
D. SECURITY REQUIREMENTS
operations typically require a factor of 100-1000 more com-
The system expects the presence of both passive and active
putational time [17] and thus also energy compared to the
attackers during the entire process. This implies an attack
symmetric key-based operations. Moreover, it is explained
can attempt to eavesdrop, change, delete, or insert messages
in [18] that the main advantage of public-key cryptography is
on the communication channels between the device and net-
in protecting against a semi-trusted third party, which might
work server and the network server and blockchain server.
be interested in impersonating or reading the communication
So the first requirement is that system should withstand such
for its purposes or, in the worst case, hack the system.
attackers.
For the communication between the network server and
Next, since the objective of the proposed scheme is to
servers running the blockchain service, regular Transport
provide public verifiability that leads to provable trust, the
Layer Security (TLS) relying on public-key cryptography
underlying devices should execute regular time frame key
such as Elliptic Curve Cryptography (ECC) is used since we
updates even if the network server tends to cheat. Thus,
assume that both types of servers are equipped with sufficient
the second requirement is to handle a semi-trusted network
resources.
server. To achieve this, as discussed in the next section, the
We will develop a dedicated authentication and key agree-
devices share some secret information, which the devices can
ment protocol between the IoT devices and network server,
only know, and not the network server.
which is linked to the blockchain service to enable public
Furthermore, classical security features such as mutual
verifiability of the process. Here, since the objective is to min-
authentication, integrity, and confidentiality are required for
imize the impact of the proposed blockchain-based service on
the underlying authentication and key agreement between the
the constrained IoT devices, thus public-key-based operations
network server and the IoT device. In addition, it is also essen-
are not an option.
tial to guarantee perfect forward secrecy. Finally, we have to
Instead, we will use lightweight cryptographic opera-
ensure that the proposed protocol is secure against leakage
tions, including the exclusive or (XOR) operation ⊕ and a
of temporary session-specific data like random values and
secure hash operation H , which is a function that produces
session keys at one of the two entities involved in the protocol.
a fixed-length output value for an arbitrary length input.
A hash operation is said to be secure if it can resist collision, IV. PROPOSED SECURITY MECHANISMS
pre-image, and second pre-image attacks. To offer 128-bit We distinguish five main phases which are: (i) Initialization
security, the output value should be at least 256 bits. SHA2 of devices, (ii) registration of devices and application servers
and SHA3 are the current standard hash functions, offering on the blockchain, (iii) execution of the key update procedure
sufficient protection. between the network server and a device, (iv) evaluation of
the key update process on the blockchain once the required
C. SYSTEM ARCHITECTURE input is sent by the network server, and (v) an optional
The system architecture layout is shown in Figure 1. synchronization phase when the network server and a device
It includes four different types of entities: IoT devices, go out of sync.
a network server, application servers, and a blockchain plat- Figure 2 shows the schematic view of the communication
form. IoT devices communicate with the network server flow in the key update scheme for timeslot s, where s = n −
leveraging long-range technology LoRA. More precisely, the 1, n − 2, . . . , 1.
battery-operated IoT devices send the measured data to the
network server via gateways pre-registered with the network A. INITIALIZATION OF DEVICE
server. Depending on the different applications rolled out, the The owner of the device i selects a random 256-bit value
network server forwards the received data to one or multiple Hi0 and derives a hash chain for it: Hi1 = H (Hi0 ), Hi2 =
application servers. H (Hi1 ), . . . , Hin = H (Hin−1 ). These values are stored in the
A shared key between the device and the network server tamper-proof part of the IoT device’s memory and will be
is required in order to establish a new common shared key released one by one from back to front (i.e., from Hin to
and session key between the device and the application server. Hi1 ). The parameter n corresponds with the number of key
Consequently, the application servers completely rely on the refreshments possible to be performed by the device without
network server for the key management. So as per the status a manual interception for key updates. Note that there are
quo, they have no control over key management. The net- several tricks to save storage space in the device’s memory,
work server and the registered devices are connected to the like, for instance, storing only each t-th outcome in the hash

VOLUME 11, 2023 21761

 R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

FIGURE 1. The architecture of the proposed system.

FIGURE 2. Illustration of the different steps in the key update process between device, network server and blockchain service.

chain at the cost of some additional computational effort. The chain Hin , together with its identity IDi with the network
choice of the hash chain length n and corresponding imple- operator.
mentation technique depends on the application’s security
needs and the available resources at the device.
Before putting the device in the field, two common B. BLOCKCHAIN REGISTRATION
shared secret keys Sn1 , Sn2 with the network server are 1) REGISTRATION OF DEVICES
agreed by using a secure channel (e.g., pre-installation) To register the device in the system and to make the network
and stored on the device and the network server. In addi- operator responsible for its management and the communica-
tion, the device i also shares the last value of the key tion with the network server, the network operator sends the

21762 VOLUME 11, 2023

R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

message M = {IDi , Hin , TSn , 1TS} to the blockchain. This The key K = Ss−11 ⊕ S 2 ⊕ SK
s−1 s−1 is now used to encrypt the
message should be cryptographically signed (e.g. Schnorr previous value of the hash chain stored in the device His−1 ,
signature scheme) by the network operator to guarantee together with H (His−2 , TSs+ ). Note that this last part is used
authenticity and integrity. Here, TSn denotes the time at which to verify the device’s time stamp, which is possible in the next
the device is registered, and 1TS is the maximum time key update phase.
allowed between two key updates. As a consequence, the device i sends the following message
In addition, a smart contract is made in which the network M2 to the network server.
operator receives a reminder for key refreshment at a time
interval 1TS − ϵ with ϵ the time needed to perform the key M2 = {TSs+ , Ss2 ⊕ Ss−1
+
, EK (His−1 , H (His−2 , TSs+ ))}
update procedure with the device. If the network operator can-
not deliver the previous value of the hash chain of the device The network server can now retrieve Ss−1 +
from the second
to the blockchain, the different application servers, which part of the message M2 . It first validates TSs+ , next computes
are subscribed for the device, will receive a warning (see 1 , S 2 , SK
in a similar way Ss−1 s−1 s−1 in order to find K . Then,
registration of application servers). The successful update of using this value of K, the network server decrypts the last part
the device is also logged on the blockchain. of the message M2 , being EK (His−1 , H (His−2 , TSs+ ). It then
computes H (His−1 ) (from decrypted His−1 ) and checks if this
2) REGISTRATION OF APPLICATION SERVERS value is equal to the value His available on the blockchain.
The application developers that are interested in data coming If so, it sends a confirmation message M3 to the device
from a certain device i first contact the responsible network
operator. The network operator refers to the device’s address M3 = {H (His−1 , Ss−1
∗
, Ss−1
+
)}
on the blockchain, which allows the application developer to
verify the device’s health by checking if the device respects The network server definitely erases the value {Ss1 } from its
the planned regular key updates. Next, the application devel- memory and stores now the values {Ss−1 1 , S 2 }. Note that the
s−1
oper subscribes with the network operator and shares its 2
value {Ss } is kept to deal with the issue of desynchronization.
public key {PKj }i . The network operator then updates the Further, the last part of the decrypted message M2 needs to be
information on the blockchain by including this public key, communicated to the blockchain in the next phase (discussed
which is later used to send warnings via the smart contract to in the next subsection IV-D). Here, additional remarks like
the application developers if the devices have not undergone desynchronization errors (by means of a predefined coding
the required key updates. mechanism) can also be included.
If the message M3 arrives at the device and is correctly
C. KEY UPDATE BETWEEN NETWORK SERVER AND verified, the values {Ss1 , Ss2 } are erased from the memory of
DEVICE the device and replaced by {Ss−1 1 , S 2 }. If M is incorrect or
s−1 3
In this process, three messages are exchanged. First, the M3 does not arrive in a reasonable time frame, the process is
network server sends M1 to the device i aborted and needs to be repeated.
M1 = {IDi , TSs∗ , Ss1 ⊕ Ss−1
∗
, H (Ss−1
∗
, TSs∗ )}
∗ D. KEY UPDATE BETWEEN NETWORK SERVER AND
with s ≤ n in decreasing order. Here, Ss−1 is a randomly
∗ BLOCKCHAIN
generated value by the network server. TSs is the timestamp
If the verification of M2 by the network server is positive, the
at the network server.
network server sends to the blockchain the message M4 =
Upon the arrival of this message, the device first checks
{TSs+ , His−1 , H (His−2 , TSs+ )}. The miners can then also verify
the validity of TSs∗ if it fits in the s to (s − 1)-th interval. If so,
∗ , using its previous session key S 1 . Next, the validity of TSs+ , together with the correctness of His−1 .
device i derives Ss−1 s
∗ The actual validity of the time slot from the previous update
the correctness of the computed Ss−1 is verified by recom-
∗ , TS ∗ ) and comparing it with the received hash request containing H (His−1 , TSs+1 +
) can be checked using the
puting H (Ss−1 s s−1
value from the network server. Denote the time stamp at the received Hi . If both verifications are correct, the transac-
side of the device by TSs+ . tion is agreed upon.
+
Then the device also randomly generates Ss−1 and com-
2 +
putes Ss ⊕ Ss−1 . Next, updates are derived for the long term E. DESYNCHRONIZATION
key materials Ss1 , Ss2 . Desynchronization happens in case M3 was not successfully
received by the device and the server has already updated its
1
Ss−1 = H (Ss1 , Ss−1
∗
, Ss−1
+
, TSs∗ , TSs+ ) old values {Ss1 , Ss2 } to new values {Ss−1
1 , S 2 }. However, the
s−1
2
Ss−1 = H (Ss2 , Ss−1
+
, Ss−1
∗
, TSs+ , TSs∗ ) server always keeps the previous value Ss2 to be still able to
proceed with the process. In this case, the same protocol as
The session key SK , to be used in the current session, is then
before is used, but with Ss2 = Ss1 . Note that this process has
defined by
a cost in protection against session temporary data leakage
SKs−1 = H (Ss1 ⊕ Ss2 , Ss−1
1 2
⊕ Ss−1 ) attacks.

VOLUME 11, 2023 21763

 R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

V. IMPLEMENTATION AND EXPERIMENT RESULTS and thus there is no public verifiability and the trust com-
A. OVERVIEW OF EXPERIMENTAL SET-UP pletely relies on the auditing entity. MongoDB as a database
To provide a proof of concept of the proposed blockchain- is used to store and manage the session keys, to which this
regulated key refreshment scheme, we use an experimental auditing entity has access in a secure way via standard secu-
set-up with three types of entities. These are IoT devices, the rity mechanisms.
network server, and the blockchain platform for key manage- We now discuss the specifications of the implementation
ment services. To evaluate the performance comparison of the aspects of the two blockchain-based systems and the non-
proposed system, three different implementations of the key blockchain-based system.
management service have been done. The first implemen-
tation is carried out using the Ethereum blockchain, which 1) ETHEREUM-BASED SETUP
is a public permissionless blockchain. The second imple- In the Ethereum-based experimental setup, a smart con-
mentation is performed using Hyperledger Fabric which is tract named NetworkServerContract is implemented. It is
a private permissioned type blockchain. The two implemen- assumed that the network server administrator deploys the
tations are compared with the third non-blockchain-based smart contract. Hence during the deployment, the adminis-
implementation. Two RESTful server-based applications are trator’s Ethereum address is set as the contract’s owner. It is
developed using NodeJS [19]; one for the IoT device, and also assumed that the IoT devices have their independent
the other for the network server. The IoT device is connected Ethereum addresses, which are used as the device IDs. Only
to the network server through a socket connection using the owner can store, update and manage the session keys
Socket.IO [20]. The APIs of both the servers have been of the IoT devices. The smart contract also has a register
developed using ExpressJS [21] and serve basic function- function which an IoT device can call with the device details
alities such as the creation of session keys for a particular such as the key update interval, the number of updates remain-
IoT device and registration of an IoT device. The entire key ing based on the hash-chain, and recent hash-chain value.
updating process starts when an IoT device, with a valid The registration happens successfully only if the device with
session key with the network server, sends a request for reg- its Ethereum address has a valid session key present on the
istration. On successful registration, a package called toad- Blockchain. Once the registration is done, a registered event
scheduler [22] is used to schedule automated key updates for is emitted from the smart contract, which the network server
the particular IoT device. The key updating process requires application listens to in real-time. On receiving the event, the
a couple of lightweight cryptographic operations, which are application schedules an automatic key update time with the
implemented using packages such as aes256 [23], object- interval specified by the IoT device. During the key update
hash [24], randomstring [25], buffer-xor [26], and @the- process, the IoT device and the network server communicate
QRL/hashchains [27]. The experimental setup for the three through a secure socket channel. On the successful generation
different implementations is shown in Figure 3. of the key, the network server updates the session key on the
In the Ethereum blockchain-based scenario, a local Ethereum blockchain along with updated device details such
blockchain is deployed on the system using Ganache and as remaining updates and the recent hash chain value.
a smart contract is developed and deployed over it, which
provides functionalities such as storing and updating ses- 2) HYPERLEDGER FABRIC BASED SETUP
sion keys, registering IoT Devices, and recording the key The Hyperledger Fabric-based setup works almost similarly
update history. To interact with the deployed Smart Contract, to the Ethereum-based setup. The key difference is that the
Web3JS [28] is used. functionalities of the smart contract (i.e., NetworkServer-
For the Hyperledger Fabric-based scenario, we have used Contract) in the Ethereum-based setup are facilitated by
the fabric tools provided by Hyperledger Foundation [29] chaincode (named NetworkServerChaincode) deployed on
to set up a test network along with a certificate authority the Hyperledger Fabric test network in this setup. The NodeJS
in the local system. For the development of the chaincode, SDK for Fabric helps set up wallets for both the network
which provides similar functionalities as the Ethereum Smart server and the IoT device, which are then used to sign any
Contract does, we have used the NodeJS-based chaincode-api transaction calls made to the chaincode. For the simplicity of
[30] to do so and deploy it on the test network. The chaincode the prototype, the network consists of one orderer node and
interactions are then done from the NodeJS applications of two peer nodes.
the IoT Device and the Network Server using the Fabric
Client SDK (Software Development Kit) for Node.js [31]. 3) NON-BLOCKCHAIN IMPLEMENTATION
To compare the performance of the proposed blockchain- In the Non-Blockchain based scenario, MongoDB is used
based mechanism with the non-blockchain system, we use to store the session keys and the IoT device details. The
an experimental set-up which uses MongoDB as shown in network server application can store a new session key for an
figure 3. For the Non-Blockchain based scenario, exactly the IoT device to be registered directly on MongoDB, when the
same steps are performed as in the protocol of Figure 2, device requests for registration with the device details (such
except that there is no communication with a blockchain. as the device id, key update interval, number of remaining
We here assume the existence of an external auditing entity updates and recent hash-chain values) are sent. The key is
21764 VOLUME 11, 2023
R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

FIGURE 3. Implementation setup of proposed solution.

fetched from MongoDB, and if it is valid, the device gets TABLE 2. Deployment Cost of NetworkServerContract.
successfully registered, and the data of the new device is
added to MongoDB. The application running on the network
server in real-time listens to the event of a new device creation
on MongoDB. When it receives the event, an automatic key
update task is scheduled by the network server application, new blocks. The senders of all the transactions which get
which will update the session key of the IoT device based confirmed with the mining of a new block, pay this reward
on the interval it has specified. The Key update process is in terms of gas which is converted into Ether. The conversion
the same as the Blockchain-based system, the IoT device, is based on the current gas price value (i.e., the value of
and the network server communicates via a socket channel 1 gas in terms of Ether). The more the value of gas for a
to update the session key. Once the process is complete, the transaction send to the blockchain, the higher is the priority
network server stores the updated key and the device details, given by the miners, and thus the execution will be faster.
such as remaining updates and the recent hash-chain value on For the experiment, we have set the gas price as 1 GWEI as it
MongoDB. is the moderate rate used for transactions. For the calculation
of the cost, the gas required by the NetworkServerContract
B. EXPERIMENT RESULTS for deployment as well as for various functionalities is calcu-
lated by using the remix tool.1 The cost for the deployment
The performance of all three experimental setups is evaluated.
of the NetworkServerContract is shown in Table 2.
First, the cost is calculated incurred by the Ethereum-based
There are two types of costs associated with the Ethereum
system. As the Hyperledger Fabric framework uses the SOLO
blockchain, one is the transaction cost which is a fixed fee
consensus protocol, there is no cost associated with it. Next,
paid to Ethereum for a transaction along with the additional
the scalability of the three systems is compared.
cost if any data is sent with the transaction. The other cost
is the execution cost, which is the cost of any operation
1) COST COMPUTATION FOR ETHEREUM-BASED SETUP performed on the smart contract for a given transaction.
To validate and confirm new transactions, a new block is to Any transaction which writes or sends data to the Ethereum
be mined. To do so, miners perform intensive computations blockchain incurs some cost but reading data does not cost
which require resources such as energy, storage, and high-end anything. Thus, the costs are calculated for three different
processing infrastructure. In return, miners in the Ethereum
blockchain are rewarded in units called Ether for mining 1 http://remix.ethereum.org/

VOLUME 11, 2023 21765

 R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

TABLE 3. Cost of some smart contract functions.

FIGURE 5. Throughput evaluation for various rate controllers in

Hyperledger fabric.

up to 9915 milliseconds for 600 devices. The time in the

blockchain-based system is high as it involves two smart con-
tract calls, and due to the proof of work consensus algorithm.
As we increase the number of transactions sent by multiple
FIGURE 4. Key update time for the implemented systems. IoT devices, the transactions get accumulated and processed
sequentially in batches of the maximum transactions stored
operations: (i) storing or updating session keys for a device, in a single block, thus increasing the time. The difference
(ii) registering a new device, and (iii) updating device details. in time between the Ethereum and the non-blockchain-based
Table 3 shows the computed costs. system is high, but this is prevented by using the Hyperledger
Fabric-based system as it uses the Solo consensus algorithm
2) SCALABILITY EVALUATION instead of the Proof of Work consensus algorithm. The time
The comparison of performance for the three different sys- taken by the Hyperledger Fabric-based system for the key
tems is made by performing the scalability test, which con- updation process is 5304 milliseconds for 600 devices and
sists of calculating the average time taken for the update thus more in line with the Non-blockchain-based method.
session key process simultaneously for a large number of IoT Thus, the Hyperledger Fabric-based system is highly scalable
devices. In the case of the two Blockchain-based systems, compared to the Ethereum-based system, and there is no cost
we have assumed that the session key update process involves incurred for the chaincode interactions.
two smart contract calls; one to update the session key on To further analyze the scalability of the Hyperledger Fab-
Blockchain and a second to update the device details on the ric system, the Hyperledger Caliper [32] benchmark tool
Blockchain. Especially, the latter takes the most amount of has been used to generate the throughput of transactions
time in the entire process. Hence, we have calculated the for different rate controllers. The rate controllers are used
average time taken for a large number of devices (up to to simulate the pattern of incoming requests to the hyper-
600) by taking the average time of the sum of both smart ledger network. The caliper tool is configured to simulate
contract calls. In the case of the non-blockchain-based sys- five worker nodes to process the various requests. Four
tem, we have simulated multiple devices through a script different types of rate controllers have been used for this
and have used the devices to perform the key update process experiment: fixed load, fixed-rate, linear rate, and composite
simultaneously. The average time taken for the key update rate. Figure 5 shows the throughput per second for up to
is calculated for the different number of devices (up to 600) 600 requests using the various rate controllers. The fixed load
from the time taken by each device. rate controller has been configured to send the maximum
Figure 4 shows the comparison of results for the three number of transactions available for each iteration hence
different systems. In the case of the non-blockchain system, the throughput increases with the increase of the number of
the time taken by the least number of devices which is requests sent to the network. The linear rate controller is
50, is 63 milliseconds, and as we increase the number of configured to linearly increase the number of transactions
devices, it goes up to a maximum of 579 milliseconds for being sent to the network from 10 to the maximum number of
600 devices. The time for the update process is less as it available requests for each iteration. The throughput averages
involves less CPU-intensive operations and no network calls around 40 transactions per second. Similarly, the fixed rate
as the database runs locally. For the Ethereum-based system, controller is configured to send 10 requests per second and
the time taken by 50 devices is 902 milliseconds and goes the throughput averages out to around 10 transactions per

21766 VOLUME 11, 2023

R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

second. To model and simulate complex network behavior, A. SECURITY OF THE AUTHENTICATION AND KEY
the composite rate controller is used which allows the con- AGREEMENT UPDATE PROTOCOL—INFORMAL ANALYSIS
figuration of multiple simple rate controllers in a single As discussed in Section III-D., we have to ensure that the
iteration. The controller switches between the simpler rate proposed protocol provides the typically required crypto-
controllers automatically according to the specified weights graphic features, taking into account the presence of active
for each of them. The weights increase the frequency of usage and passive attackers.
of a given rate controller over others. For this experiment,
the composite rate controller has two fixed-rate controllers • Mutual authentication: For each of the sent messages
configured inside of it to send requests to the network at a (M1 , M2 , M3 ), the corresponding receiver can uniquely
rate of 10 and the maximum number of requests available determine the sender’s authenticity. This follows from
in the iteration with weights 1 and 2 associated with them the fact that parts of the messages are protected by key
respectively. The fluctuations in the graph for the composite material, which is assumed to be in possession of the
rate indicate the switching of the two fixed-rate controllers expected communication party and can be verified by
randomly. The results obtained from the benchmarking tool hash functions. In addition, both the network server and
do not generate any failed transactions for the different rate- device contribute to the construction of the updated key
controlled transactions. The throughput for fixed load shows material as both generate a random value.
that the system scales based on the increase in requests and • Integrity: The essential parts of the messages are
the scalability can be further increased if needed by adding included in a hash function, enabling the verification of
more worker nodes to the network. its integrity.
Accordingly, the composite rate controller enables the con- • Confidentiality: Only the entity in possession of either
figuration of multiple ‘‘simpler’’ rate controllers in a single the pre-shared key material (Sn1 , Sn2 , Hin ) or the later
round, promoting the reusability of existing rate controller derived key material (Ss1 , Ss2 , His , s < n) can retrieve the
implementations. The composite rate controller will auto- required data to construct the session key K .
matically switch between the given controllers according to • Perfect forward secrecy: This is guaranteed by the fact
the specified weights (see the configuration details after the that the key material (Ss1 , Ss2 ) is updated after each run of
example). the protocol, and the previous values are erased from the
memory. Moreover, these updated values are constructed
C. LIMITATIONS OF THE IMPLEMENTATION through a hash operation on different parameters that
For the Ethereum-based setup, one major limitation is scal- cannot be revealed based on the data sent over the chan-
ability. As more devices join the network, the amount of nel. Also the session keys are built employing a hash
data that needs to be processed and stored on the blockchain function on values that cannot be revealed based on only
increases, which can lead to a slower transaction rate. Addi- knowledge of the stored key material (Ss1 , Ss2 ).
tionally, using a proof-of-work (PoW) consensus algorithm in • Protection of data: Protection against leakage of
Ethereum can lead to high energy consumption, which is not session-specific data is obtained thanks to the usage of
ideal for IoT devices with limited power resources. Another two independent keys Ss1 , Ss2 . As long as both are not
limitation is the lack of privacy, as all transactions on the known, it is not possible to derive additional information
Ethereum (public permissionless) blockchain are visible to enabling the construction of the updated values or the
anyone on the network. session key. Note that no protection against this type of
For the Hyperledger Fabric-based setup, one of the lim- attack is obtained in the desynchronization phase.
itations is the complexity of configuring and managing the • Attack resistance: Protection against man-in-the-middle
system. Also, using a permissioned blockchain involves using and impersonation attacks are obtained as mutual
trusted authority to manage access to the network which authentication, integrity, and confidentiality are ensured
limits the network’s decentralization. in the protocol.
As for future scope, there is a lot of potential for using • Prevention of replay attack: Protection against replay
blockchain technology to secure and decentralize IoT net- attacks is guaranteed thanks to the usage of timestamps,
works. One area of research is developing more efficient whose authenticity is verified by including them in the
consensus algorithms that reduce energy consumption and different hash operations.
improve scalability. Another area is exploring the use of
hybrid blockchain solutions that combine the benefits of Finally, the scheme’s main goal, providing public verifiability
permissioned and permissionless blockchains to create more to external parties, is obtained thanks to the usage of a hash
flexible and secure networks. chain defined in the device. Each hash value in the hash
chain is gradually released from front to back as discussed in
VI. SECURITY EVALUATION section IV. The corresponding timestamps at which the key
This section discusses the security first from a protocol update process at the device’s side is taken is also protected by
point of view, and next go deeper into the security from the means of a hash on the second last received hash chain value.
Blockchain perspective. It should be additionally mentioned that the verification for

VOLUME 11, 2023 21767

 R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

this can only happen during the next period, i.e., the next Local sets of D:
release of the value of the hash chain. Poss(D) = {(Ss1 , Ss2 , Ss+1
2 , (H 0 , . . . , H s )}
i i
Bel(D) = (#Ss , #Ss , #Ss+1
1 2 2 }

BL =
B. SECURITY OF THE AUTHENTICATION AND KEY
D1: Receive M1
AGREEMENT UPDATE PROTOCOL—FORMAL ANALYSIS ∗ and check hash
D2: Compute Ss−1
In order to formally prove the protection against mutual D3: Generate nonce Ss−1 +
authentication, integrity, and confidentiality of the blockchain-
D4: Compute Ss−1 , Ss−1 , SKs−1 , K
1 2
based key refreshment protocol, the non-monotonic logic-
D5: Send M2 to NS
based verification RUBIN logic [33] is used. This method
D6: Receive M3
is applied in a multitude of papers and has the advan-
D7: Check M3
tage that it is closely related to the actual implemen- 2 }, Store{S 1 , S 2 }
D8: Erase {Ss1 , Ss+1 s−1 s−1
tation of the protocol. The evaluation is performed
based on the evolution of a global set, local sets, and
Local sets of BS:
actions.
Poss(BS) = {His }
The global setting is public and consists of four dif-
Bel(BS) = {#His }
ferent sets, which include information available in the
BL =
protocol. First, the principal set P = {D, NS, BS}
BS1: Receive M4
defines the participants in the protocol. Second, the rule
BS2: Verify validity of received His−1 and TS
set contains the inference rules for deriving new state-
ments from existing ones [33]. Third, the secret set S
For the verification of the protocol, we start with running the
defines the secrets at a given moment in time. To start,
actions NS1-NS3 of the BL of NS. This results in an update
S = {Ss1 , Ss2 , Ss+1
2 , (H 0 , . . . , H s−1 , H s )}. Finally, the three
i i i of the global sets (S, Obs) and the local sets (Poss,Bel) of NS.
observer sets include all participants who know the secrets
S = {Ss1 , Ss2 , Ss+1
2 , (H 0 , . . . , H s−1 , H s , S ∗ )}.
i i i s−1
contained in S. Here, the following observer sets are distin- ∗
Obs(Ss−1 ) = {NS}
guished:
Poss(NS) = {(Ss1 , Ss2 , Ss+1
2 , H s, S ∗ }
Obs(Hi0 , . . . , His−1 ) = {D} i s−1
Bel(NS) = (#Ss , #Ss , #Ss+1
1 2 2 , #S ∗ }
Obs(His ) = {D, NS, BS} s−1
Obs(Ss1 , Ss2 , Ss+1
2 ) = {D, NS}
Next, the actions D1-D5 are executed by the device. As a
result, the following sets are
The local sets contain a possession set, belief set, and
updated:
behavior list, and are different for each participant. The pos-
S = {Ss1 , Ss2 , Ss+1
2 , (H 0 , . . . , H s ), S ∗ , S + , S 1 , S 2 ,
i i s−1 s−1 s−1 s−1
session set Poss(P) includes all secrets known for that partic-
SKs−1 , K )}.
ular participant P. The belief set Bel(P) contains all beliefs ∗ , S + , S 1 , S 2 , SK
Obs(Ss−1 s−1 s−1 s−1 s−1 , K ) = {D}
held by a participant P, e.g. with respect to key freshness
(denoted by #), and possession of secrets by other involved Poss(D) = {(Ss , Ss , Ss+1 , (Hi , . . . , His ), Ss−1
1 2 2 0 ∗ , S+ , S1 ,
s−1 s−1
2 , SK
participants. The behavior list BL is basically defined by the Ss−1 s−1 , K }
∗ , #S + , #S 1 , #S 2 , #SK
different actions executed by the participants. Bel(D) = (#Ss−1 s−1 s−1 s−1 s−1 , K }
As the communication begins with NS, we start with the
definition of the local sets of NS, followed by the device D Upon receiving M2, the network server performs actions
and the blockchain server BS. NS4-NS10, which also result in the achievement of the
Local sets of NS: remaining actions of the device D6-D8 and the BS actions
Poss(NS) = {(Ss1 , Ss2 , Ss+1
2 , H s} BS1-BS2. Consequently, the global sets are updated as fol-
i
Bel(NS) = (#Ss , #Ss , #Ss+1
1 2 2 } lows: S = {(Hi0 , . . . , His−1 , Ss−1
1 , S 2 , S 2 , K )}
s−1 s
BL = Obs(Hi , . . . , Hi ) = {D}
0 s−2

NS1: Generate nonce Ss−1 ∗ Obs(His−1 ) = {D, NS, BS}

1 , S 2 , S 2 ) = {D, NS}
NS2: Compute Ss ⊕ Ss−1 , H (Ss−1
1 ∗ ∗ , TS ∗ )
s
Obs(Ss−1 s−1 s
NS3: Send M1 to D
NS4: Receive M2 The local sets of each of the participants are changed
1 , S 2 , S 2 , H s−1 , K }
NS5: Compute Ss−1 +
, Ss−1
1 , S 2 , SK
s−1 s−1 , K into Poss(NS) = {(Ss−1 s−1 s i
1 , #S 2 #K }
Bel(NS) = (#Ss−1
NS6: Derive (Hi , . . . , His−1 ), H (His−2 , TSs+ ) by decryption
0
s−1
1 , S 2 , S 2 , (H 0 , . . . , H s−1 )}
NS7: Check validity of His Poss(D) = {(Ss−1 s−1 s i i
NS8: Send M3 to D Bel(D) = (#Ss−1 , #Ss−1
1 2 #K }

NS9: Erase {Ss1 , Ss+12 }, Store{S 1 , S 2 }

s−1 s−1 Poss(BS) = {His−1 }
NS10: Send M4 to BS Bel(BS) = {#His−1 }

21768 VOLUME 11, 2023

R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

TABLE 4. Security analysis of NetworkServerContract using various tools. the most important attacks. As a result, the end-user can
now verify the trustworthiness of the applications, which base
their decisions on measurements of IoT devices.
In future work, we will focus more on the AI-based tech-
niques to integrate with the smart contract allowing the iden-
tification of required events needed to cause key refreshment.
In addition, it will also be interesting to combine our proposed
system with an access control system to enable data sharing
between IoT devices and applications. Another interesting
area to investigate is looking at a public key alternative for the
update protocol in order to benchmark the differences with
respect to storage cost, computation, and communication
cost. In our protocol, due to the usage of a hash chain, there is
Therefore, we can conclude the following statements related high storage cost for the IoT device, but the communication
to confidentiality, integrity and mutual authentication. and computation costs are very low.
• The material Ss−11 , S 2 , S 2 to derive new keys for the
s−1 s
next session are fresh and are only known by the legiti- REFERENCES
mate participants’ NS and D. [1] E. Aras, G. S. Ramachandran, P. Lawrence, and D. Hughes, ‘‘Exploring
• The key material used in this session was fresh and the security vulnerabilities of LoRa,’’ in Proc. 3rd IEEE Int. Conf. Cybern.
(CYBCONF), Jun. 2017, pp. 1–6.
resulted in key material K, which is only known by the [2] H. Noura, T. Hatoum, O. Salman, J.-P. Yaacoub, and A. Chehab,
legitimate participants’ NS and D. ‘‘LoRaWAN security survey: Issues, threats and possible mitigation tech-
s−1
• Thanks to the possession of Hi by D and His by niques,’’ Internet Things, vol. 12, Dec. 2020, Art. no. 100303.
[3] X. Chen, M. Lech, and L. Wang, ‘‘A complete key management scheme
NS and BS, the authenticity of D is uniquely verified for LoRaWAN v1.1,’’ Sensors, vol. 21, no. 9, p. 2962, Apr. 2021.
because of the strength of the hash function. [4] Y. Tan, J. Liu, and N. Kato, ‘‘Blockchain-based key management for
heterogeneous flying ad hoc network,’’ IEEE Trans. Ind. Informat., vol. 17,
C. SECURITY ANALYSIS OF SMART CONTRACT AND no. 11, pp. 7629–7638, Nov. 2021.
[5] M. Baza, M. M. Fouda, M. Nabil, A. T. Eldien, H. Mansour, and
BLOCKCHAIN-BASED SYSTEM M. Mahmoud, ‘‘Blockchain-based distributed key management approach
Blockchain-based key refreshment mechanism provides tailored for smart grid,’’ in Combating Security Challenges in the Age of
Big Data. Cham, Switzerland: Springer, 2020, pp. 237–263.
strong authentication and non-repudiation thanks to its under-
[6] H. Liu, R. Zhu, J. Wang, and W. Xu, ‘‘Blockchain-based key management
lying cryptographic mechanisms such as public-key cryp- and green routing scheme for vehicular named data networking,’’ Secur.
tography, hashing, and digital signature. In the case of a Commun. Netw., vol. 2021, pp. 1–13, Jul. 2021.
non-blockchain-based system due to the centralized database, [7] K. Yu, L. Tan, M. Aloqaily, H. Yang, and Y. Jararweh, ‘‘Blockchain-
enhanced data sharing with traceable and direct revocation in IIoT,’’ IEEE
important requirements such as availability, verifiability, and Trans. Ind. Informat., vol. 17, no. 11, pp. 7669–7678, Nov. 2021.
access control are challenging. The use of smart contracts in [8] T. Hewa, A. Bracken, M. Ylianttila, and M. Liyanage, ‘‘Blockchain-based
conjunction with blockchain provides transparency and tight automated certificate revocation for 5G IoT,’’ in Proc. IEEE Int. Conf.
Commun. (ICC), Jun. 2020, pp. 1–7.
access control. Nevertheless, any loophole in smart control [9] M. A. Kandi, D. E. Kouicem, H. Lakhlef, A. Bouabdallah, and Y. Challal,
can be a source of a security breach. Thus, to ensure the ‘‘A blockchain-based key management protocol for secure device-to-
security of the blockchain-based system the developed smart device communication in the Internet of Things,’’ in Proc. IEEE 19th Int.
Conf. Trust, Secur. Privacy Comput. Commun. (TrustCom), Dec. 2020,
contact is tested for vulnerabilities such as indirect execution pp. 1868–1873.
of unknown code, reentrancy, interface/naming issues and [10] M. Tan, D. Sun, and X. Li, ‘‘A secure and efficient blockchain-based key
incorrectly handled exceptions. As shown in table 4 various management scheme for LoRaWAN,’’ in Proc. IEEE Wireless Commun.
Netw. Conf. (WCNC), Mar. 2021, pp. 1–7.
tools are used to check the presence of such kinds of vulnera- [11] S. F. J. J. Ankergård, E. Dushku, and N. Dragoni, ‘‘PERMANENT:
bilities. The results manifest the security strength of the smart Publicly verifiable remote attestation for Internet of Things through
contract. blockchain,’’ in Proc. 14th Int. Symp. Found. Pract. Secur. Cham, Switzer-
land: Springer, 2021, pp. 218–234.
[12] A. H. Mohammed, A. A. Abdulateef, and I. A. Abdulateef, ‘‘Hyperledger,
VII. CONCLUSION Ethereum and blockchain technology: A short overview,’’ in Proc. 3rd Int.
In this paper, we have proposed a distributed ledger-based Congr. Hum.-Comput. Interact., Optim. Robotic Appl. (HORA), Jun. 2021,
pp. 1–6.
solution to enforce key refreshment of the IoT devices in
[13] W. Melo, L. S. dos Santos, L. M. Bento, P. Nascimento, and C. A. Ruviaro,
a publicly verifiable way on regular time frames. We have ‘‘Using blockchains to protect critical infrastructures: A comparison
implemented the solution on both Ethereum and Hyperledger between ethereum and hyperledger fabric,’’ Int. J. Secur. Netw., vol. 17,
no. 2, p. 77, 2022.
fabric-based systems. We show that Hyperledger offers a
[14] M. Dabbagh, M. Kakavand, M. Tahir, and A. Amphawan, ‘‘Performance
highly scalable approach enabling the update process of analysis of blockchain platforms: Empirical evaluation of hyperledger
500 devices in less than 4.5s. A corresponding dedicated key fabric and Ethereum,’’ in Proc. IEEE 2nd Int. Conf. Artif. Intell. Eng.
update protocol between the device and network server is Technol. (IICAIET), Sep. 2020, pp. 1–6.
[15] T. Hewa, M. Ylianttila, and M. Liyanage, ‘‘Survey on blockchain based
also proposed enabling mutual authentication, integrity, con- smart contracts: Applications, opportunities and challenges,’’ J. Netw.
fidentiality, perfect forward secrecy, and protection against Comput. Appl., vol. 177, Mar. 2021, Art. no. 102857.

VOLUME 11, 2023 21769

 R. A. Mishra et al.: Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

[16] T. M. Hewa, Y. Hu, M. Liyanage, S. S. Kanhare, and M. Ylianttila, ANSHUMAN KALLA (Senior Member, IEEE)
‘‘Survey on blockchain-based smart contracts: Technical aspects and future received the Bachelor of Engineering degree
research,’’ IEEE Access, vol. 9, pp. 87643–87662, 2021. from Government Engineering College Bikaner in
[17] S. Patonico, ‘‘Study and analysis of security features for Internet of Things 2004, the Master of Science degree in telecom-
devices in a ONE-M2M based network,’’ Ph.D. thesis, Dept. Ind. Eng. munications and wireless networking from ISEP,
(INDI), Vrije Universiteit Brussel, Brussels, Belgium, 20201. Paris, France, in 2008, the master’s degree from
[18] A. Braeken, ‘‘Public key versus symmetric key cryptography in client— the University of Nice Sophia Antipolis, France,
Server authentication protocols,’’ Int. J. Inf. Secur., vol. 21, no. 1, in 2011, and the Ph.D. degree in 2017. He has
pp. 103–114, 2021.
more than 12 years of teaching and research expe-
[19] Node.Js. Accessed: Sep. 29, 2021. [Online]. Available: https://
rience. He was a Postdoctoral Visiting Researcher
nodejs.org/en/
with the Center for Wireless Communications (CWC), University of Oulu,
[20] Socket.IO. Accessed: Sep. 29, 2021. [Online]. Available: https://socket.
io/ Finland. He is a Professor with the Department of Computer Engineering,
[21] Expressjs. Accessed: Sep. 29, 2021. [Online]. Available: Chhotubhai Gopalbhai Patel Institute of Technology (CGPIT), Uka Tarsadia
https://expressjs.com/ University (UTU), India. He was a recipient of master’s scholarships for
[22] Toad-Scheduler. Accessed: Sep. 29, 2021. [Online]. Available: pursuing both the master’s programs. He has published articles in reputed
https://github.com/kibertoad/toad-scheduler international journals, such as Elsevier (JII, IPM, JNCA, COMNET, and
[23] Aes256. Accessed: Sep. 29, 2021. [Online]. Available: https://github.com/ ICT Express), IEEE Consumer Electronics Magazine, IEEE OPEN JOURNAL
ricmoo/aes-js OF THE COMMUNICATIONS SOCIETY (OJ-COMS), IEEE Computer, and IEEE
[24] Object-Hash. Accessed: Sep. 29, 2021. [Online]. Available: ENGINEERING MANAGEMENT REVIEW (EMR). His research interests include
https://github.com/puleos/object-hash blockchain, 5G, 6G, the IoT, information-centric networking, software-
[25] Randomstring. Accessed: Sep. 29, 2021. [Online]. Available: defined networking, and next generation networks.
https://github.com/klughammer/node-randomstring
[26] Buffer-Xor. Accessed: Sep. 29, 2021. [Online]. Available: https://github.
com/crypto-browserify/buffer-xor AN BRAEKEN (Member, IEEE) received the
[27] Theqrl/Hashchains. Accessed: Sep. 29, 2021. [Online]. Available:
M.Sc. degree in mathematics from the University
https://github.com/theqrl/hashchains
of Gent, in 2002, and the Ph.D. degree in engineer-
[28] Web3js. Accessed: Sep. 29, 2021. [Online]. Available:
ing sciences from the Research Group Computer
https://web3js.readthedocs.io/en/v1.5.2/
[29] Fabric Tools. Accessed: Nov. 20, 2021. [Online]. Available: Security and Industrial Cryptography (COSIC),
https://hyperledger-fabric.readthedocs.io/en/release-2.2/test_network. KU Leuven, in 2006. She was a Professor with
html the Industrial Sciences Department, Erasmushoge
[30] Fabric Chaincode API. Accessed: Nov. 20, 2021. [Online]. Available: School Brussel, in 2007. Since 2013, she has been
https://github.com/hyperledger/fabric-chaincode-node/ with Vrije Universiteit Brussel, where she is cur-
[31] Fabric Client SDK. Accessed: Nov. 20, 2021. [Online]. Available: rently a full-time Professor with the Industrial
https://github.com/hyperledger/fabric-sdk-node/ Engineering Department (INDI). She is the coauthor of more than 120 publi-
[32] Hyperledger Caliper. Accessed: Jun. 25, 2022. [Online]. Available: cations. Her current interests include security and privacy protocols for IoT,
https://hyperledger.github.io/caliper/ cloud and fog, blockchain, and 5G security. She is a member of the program
[33] A. D. Rubin and P. Honeyman, ‘‘Nonmonotonic cryptographic protocols,’’ committee for numerous conferences and workshops and the Editorial Board
in Proc. Comput. Secur. Found. Workshop VII, 1994, pp. 100–116. of Security and Communications Magazine. Since 2015, she has been an
expert reviewer for several EU calls. She has cooperated and coordinated
more than 12 national and international projects.

MADHUSANKA LIYANAGE (Senior Member,

IEEE) received the D.Tech. degree in communi-
cation engineering from the University of Oulu,
Oulu, Finland, in 2016. He is an Assistant Profes-
RAAJ ANAND MISHRA (Student Member, sor/Ad Astra Fellow and the Director of Graduate
IEEE) received the B.Tech. degree from the Research with the School of Computer Science,
Department of Computer and Communication University College Dublin, Ireland. He is also an
Engineering, School of Computing and Informa- Adjunct Professor with the University of Oulu,
tion Technology, Manipal University, Jaipur, India, the University of Ruhuna, Sri Lanka, and the Uni-
in 2020. He has experience in fullstack soft- versity of Sri Jayawardhanepura, Sri Lanka. His
ware and blockchain-based decentralized applica- research interests include 5G/6G, blockchain, network security, artificial
tion (DApp) development. He is the Product Lead intelligence (AI), explainable AI, federated learning (FL), network slicing,
at Dell Technologies, Bengaluru, India. He has the Internet of Things (IoT), and multi-access edge computing (MEC).
worked on two blockchain-based projects and has He was a recipient of the prestigious Marie Skłodowska-Curie Actions
published papers at IEEE CCNC 2020, IEEE 5G World Forum 2020, Individual Fellowship and the Government of Ireland Postdoctoral Fellow-
Information Processing and Management 58(3), and IEEE TRANSACTIONS ON ship, from 2018 to 2020. In 2020, he received the ‘‘2020 IEEE ComSoc
NETWORK AND SERVICE MANAGEMENT PP(99). He has conducted four work- Outstanding Young Researcher’’ Award from IEEE ComSoc EMEA. In
shops: ‘‘Blockchain for Cyber-Physical Systems and IoT’’ at ANTS 2019, 2021 and 2022, he was ranked among the world’s top 2% scientists (2020
‘‘Blockchain Technology, Its Technical Challenges and Role of Formal and 2021) in the list prepared by Elsevier BV, Stanford University, USA.
Methods’’ at ETCI 2021, ‘‘Emerging Applications of Blockchain Technolo- He was awarded the Irish Research Council (IRC) Research Ally Prize as
gies in India’’ at ISPDA 2022, and the STTP on Fullstack Dapp Develop- part of the IRC Researcher of the Year 2021 Awards for the positive impact
ment at the Chhotubhai Gopalbhai Patel Institute of Technology (CGPIT), he has made as a Supervisor. In 2022, he received the ‘‘2022 Tom Brazil
Tarsadia University. His research interests include blockchain, decentralized Excellence in Research Award’’ by SFI CONNECT Center.
applications, micro frontends, and network security.

21770 VOLUME 11, 2023