Blockchain Regulated Verifiable and Automatic Key Refreshment Mechanism for IoT

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.


I. INTRODUCTION
The Internet of Things (IoT) paradigm has significantly contributed to the improved landscape of the digital world around us. It has proved its applicability in various domains such as healthcare, agriculture, automobile, industrial production, logistics, and supply chain management. Following the trend, one can find many instances where different applications use the same Internet of Things (IoT) devices concurrently. For example, an environmental sensor device can be used simultaneously for applications focusing on smart agriculture, air pollution study, or transport and logistics planning.
The associate editor coordinating the review of this manuscript and approving it for publication was Byung-Seo Kim .
The network server's job is to aggregate the required info from deployed sensors and send it to different requesting applications. Each of these applications' users must ensure that the network operator offers sufficient security for communication with the underlying devices [1].
However, when it comes to key refreshment, it is well known that many network operators never (or rarely) refresh the session key due to a lack of maintenance or the non-existence of any auditing mechanism. LoRaWAN defines the network architecture for long-range LoRa communication technology and recommends two methods for periodically updating session keys. One is after a certain period, and another is when a counter reaches a predefined value [2]. An advanced alternative has been proposed in [3], also called the Key Updating Scheme (KUS). In the KUS, there are two types of triggers to update the session keys; event-driven and time-driven. For an event-driven trigger, a key update process is initiated each time an unusual behavior is detected. In comparison, a time-driven trigger advocates the key refreshment after a specific time or when a counter reaches a value or after a randomly determined period.
Another important issue with the key refreshment procedure is that its rules are implicitly defined, which means they are not transparent. Neither the application providers nor the end-users have any control. Both rely entirely on the network server for the key management process and assume that the security of the communication is intact. Although a lot of attention has been given to the key management among the communication parties, to the best of our knowledge, there is currently no solution available that addresses transparency or verification features from the viewpoint of end-users [1].
Thus, some of the questions we focus on in the current work are: How can all the entities (in particular users) of an IoT ecosystem know which key refreshment mechanism is used (and its rules)? Can the key updates be automatically rolled out strictly as per the predefined key refreshment mechanism? How to enable (decentralized) verification of the past key updates carried out so far?
To answer these questions, the following are the contributions made by this paper: • Propose a blockchain and smart contract-based verifiable key refreshment mechanism that securely and automatically enforces the key updates between the network server and IoT devices.
• Leverage smart contract for transparently and immutably defining the rules for the key refreshment.
• Keep the key refreshment scheme computationally light for the resource-constrained IoT devices.
• Implement and analyze the proposed mechanism using both public and private blockchains, and compare the performance with a non-blockchain solution (which does not allow transparent verification).
• Evaluate the cost and security (both from a protocol viewpoint and from a blockchain-related viewpoint) of the proposed mechanism.
The proposed mechanism offers three distinct advantages. First, the application server can offer its users protection against potential security leaks, for instance, making it impossible to derive the previous session keys in case one of the session keys is retrieved, which is called perfect forward secrecy. Second, since blockchain immutably keeps track of all the key updates that have happened ever thus the proposed mechanism provides provenance and verifiability. Third, because all the rules of enforced key refreshment are immutably encoded in a smart contract, all the participating and allowed entities can transparently view them. All these benefits help offer public verifiability, which builds trust for the applications' users (and developers).
Blockchain is a decentralized peer-to-peer (P2P) network of nodes where all the participating nodes locally store a copy of a distributed ledger. This ledger is cryptographically sealed and is updated in append-only mode after establishing the consensus among the majority of the nodes. These properties, such as a decentralized P2P network, distributed ledger, cryptographic techniques, and consensus-based append-only updates, make the BC an important choice for storing key refreshment updates. Furthermore, smart contracts running on top of the blockchain are self-executable codes that provide autonomous execution, which enables enforcing automatic key updates.
The paper is organized as follows. Section II presents related work. In Section III, several preliminaries are discussed. Section IV provides details on the proposed system. Implementation and experimental results are explained in Section V, while the security evaluation is outlined in Section VI. Conclusions and suggestions for future work are given in Section VII.

II. RELATED WORK
There are many blockchain-based solutions for key management proposed in the literature. This section describes the most relevant and recent proposals.
There are proposals dedicated to particular use-case and application domains. For instance, in [4], a blockchain-based distributed key management scheme for heterogeneous Flying Ad hoc Networks (FANET) is presented. The scheme allows UAVs to update their public/private key pairs, migrate between clusters, and securely revoke malicious drones. In [5], a blockchain-based distributed multicast key management approach is discussed to enable secure communications in a smart grid. Authors in [6] proposed a secure blockchain-based key management and power-efficient routing for content-centric decentralized Vehicular Named Data Networking (VNDN). In [7], an access control system relying on a blockchain is proposed to enable traceability and revocability for IIoT and to allow secure data sharing for smart factories. In each of these proposals, key management relied on public-key-based mechanisms.
In [8], blockchain-based smart contracts are proposed to deal with certificate-related operations. Moreover, the lightweight Elliptic Curve Qu Vanstone (ECQV) certificates are included to allow resource-constrained IoT devices to participate in the process.
A novel blockchain-based decentralized key management protocol for device-to-device communication is presented in [9]. Here, key management relies on symmetric key-based mechanisms in which network members are distributed into logical sets. A device shares a distinct pairwise key with each member of its set and a pairwise set key with the members of each set.
In [10], a permissioned blockchain solves the problem that the root key is unchanged throughout the device's life in the LoRaWAN key management. The key update process relies on the Elliptic Curve Diffie-Hellman (ECDH). A blockchain-based solution, called PERMANENT, has been proposed in [11] to deal with publicly verifiable remote attestation for IoT. Here, the blockchain stores all the previous attestation results of the devices and ensures that each interacting device can obtain the corresponding attestation result to verify the trustworthiness of the operating system and application software. Table 1 summarises all the existing related works discussed above and distinguishes our work from those. The primary goal of this paper is to provide a decentralized, transparent, automatic, and verifiable mechanism for enforced key refreshment. Our paper presents the first approach in which a smart contract is developed dealing explicitly with the enforced key refreshment. Moreover, most of the related works on key management via blockchain technology rely on public-key cryptography, which is heavy on computation for the often constrained devices in the field. In addition, many of the proposed works do not have a corresponding blockchain-based implementation and only offer simulation to provide performance results. As can be seen from Table 1, our paper clearly distinguishes from the rest of the literature in its unique scenario of key refreshment management in a decentralized manner, using symmetric key cryptography and providing an effective implementation.
Moreover, we here also explicitly show the difference between the two blockchains by implementing our security solution and demonstrate the significant impact of choice on the performance. Note that for choosing a proper blockchain for a particular use-case, several papers also already described the difference in a theoretical [12], [13] and empirical way [14] between the Hyperledger Fabric and Ethereum blockchains.

III. PRELIMINARIES
We start with a short description of the blockchain and cryptographic operations background. Next, we discuss the system architecture and the corresponding security requirements.

A. BLOCKCHAIN AND SMART CONTRACTS
Blockchain, the most popular type of Distributed Ledger Technology (DLT), is implemented as a decentralized Peerto-Peer (P2P) network of nodes. Together, these nodes are responsible for maintaining and updating a cryptographically secure and distributed digital ledger. The underlying data structure used for building the distributed ledger is a logically linked chain of blocks. Every block contains a set of legitimate transactions and is time-stamped and cryptographically sealed. As the new blocks are created with time, every new block is logically linked with the most recent block in the ledger using a cryptographic (hash-based) chain [15].
Smart contracts are self-executable and self-enforceable codes that run on top of the blockchain. Unlike paper-based traditional contracts, smart contracts encode all the terms and conditions of agreements between participating entities. Thanks to the programming capability, smart contracts can be designed with pre-defined conditions, enabling automatic execution when these conditions are met in the future. Thus, when deployed on top of the blockchain, smart contracts offer code immutability, transparency, autonomy, and trust within the system [16].
Two fundamental types of blockchains are public and private blockchains. Public blockchains such as Ethereum have no restriction for entities willing to join the blockchain network and participate in the block mining process. Thus, such blockchains are open, and anyone can perform read and write operations on the distributed ledger. Whereas in private blockchains, for example, Hyperledger Fabric, only the vetted participants can join the network and operate on the ledger. Hence, a private blockchain forms a closed system. Because only a limited number of known entities participate in a private blockchain, neither a computationally intensive block-mining process nor an incentive mechanism is required. Thus, the throughput scalability of private blockchains is much higher than public blockchains.

B. CRYPTOGRAPHIC OPERATIONS
There are two main types of cryptographic operations: symmetric key and public key-based operations. Public key-based operations typically require a factor of 100-1000 more computational time [17] and thus also energy compared to the symmetric key-based operations. Moreover, it is explained in [18] that the main advantage of public-key cryptography is in protecting against a semi-trusted third party, which might be interested in impersonating or reading the communication for its purposes or, in the worst case, hack the system.
For the communication between the network server and servers running the blockchain service, regular Transport Layer Security (TLS) relying on public-key cryptography such as Elliptic Curve Cryptography (ECC) is used since we assume that both types of servers are equipped with sufficient resources.
We will develop a dedicated authentication and key agreement protocol between the IoT devices and network server, which is linked to the blockchain service to enable public verifiability of the process. Here, since the objective is to minimize the impact of the proposed blockchain-based service on the constrained IoT devices, thus public-key-based operations are not an option.
Instead, we will use lightweight cryptographic operations, including the exclusive or (XOR) operation ⊕ and a secure hash operation H , which is a function that produces a fixed-length output value for an arbitrary length input. A hash operation is said to be secure if it can resist collision, pre-image, and second pre-image attacks. To offer 128-bit security, the output value should be at least 256 bits. SHA2 and SHA3 are the current standard hash functions, offering sufficient protection.

C. SYSTEM ARCHITECTURE
The system architecture layout is shown in Figure 1. It includes four different types of entities: IoT devices, a network server, application servers, and a blockchain platform. IoT devices communicate with the network server leveraging long-range technology LoRA. More precisely, the battery-operated IoT devices send the measured data to the network server via gateways pre-registered with the network server. Depending on the different applications rolled out, the network server forwards the received data to one or multiple application servers.
A shared key between the device and the network server is required in order to establish a new common shared key and session key between the device and the application server. Consequently, the application servers completely rely on the network server for the key management. So as per the status quo, they have no control over key management. The network server and the registered devices are connected to the blockchain network in our setup. Each connected entity has a pair of public and private keys, which ensures authenticity, authorization, and non-repudiation. For enforcing the key updates, a smart contract with the rules of key refreshment and validation logic is deployed on the blockchain network by the network server.

D. SECURITY REQUIREMENTS
The system expects the presence of both passive and active attackers during the entire process. This implies an attack can attempt to eavesdrop, change, delete, or insert messages on the communication channels between the device and network server and the network server and blockchain server. So the first requirement is that system should withstand such attackers.
Next, since the objective of the proposed scheme is to provide public verifiability that leads to provable trust, the underlying devices should execute regular time frame key updates even if the network server tends to cheat. Thus, the second requirement is to handle a semi-trusted network server. To achieve this, as discussed in the next section, the devices share some secret information, which the devices can only know, and not the network server.
Furthermore, classical security features such as mutual authentication, integrity, and confidentiality are required for the underlying authentication and key agreement between the network server and the IoT device. In addition, it is also essential to guarantee perfect forward secrecy. Finally, we have to ensure that the proposed protocol is secure against leakage of temporary session-specific data like random values and session keys at one of the two entities involved in the protocol.

IV. PROPOSED SECURITY MECHANISMS
We distinguish five main phases which are: (i) Initialization of devices, (ii) registration of devices and application servers on the blockchain, (iii) execution of the key update procedure between the network server and a device, (iv) evaluation of the key update process on the blockchain once the required input is sent by the network server, and (v) an optional synchronization phase when the network server and a device go out of sync. Figure 2 shows the schematic view of the communication flow in the key update scheme for timeslot s, where s = n − 1, n − 2, . . . , 1.

A. INITIALIZATION OF DEVICE
The owner of the device i selects a random 256-bit value H 0 i and derives a hash chain for it: . These values are stored in the tamper-proof part of the IoT device's memory and will be released one by one from back to front (i.e., from H n i to H 1 i ). The parameter n corresponds with the number of key refreshments possible to be performed by the device without a manual interception for key updates. Note that there are several tricks to save storage space in the device's memory, like, for instance, storing only each t-th outcome in the hash  chain at the cost of some additional computational effort. The choice of the hash chain length n and corresponding implementation technique depends on the application's security needs and the available resources at the device.
Before putting the device in the field, two common shared secret keys S 1 n , S 2 n with the network server are agreed by using a secure channel (e.g., pre-installation) and stored on the device and the network server. In addition, the device i also shares the last value of the key chain H n i , together with its identity ID i with the network operator.

B. BLOCKCHAIN REGISTRATION 1) REGISTRATION OF DEVICES
To register the device in the system and to make the network operator responsible for its management and the communication with the network server, the network operator sends the message M = {ID i , H n i , TS n , TS} to the blockchain. This message should be cryptographically signed (e.g. Schnorr signature scheme) by the network operator to guarantee authenticity and integrity. Here, TS n denotes the time at which the device is registered, and TS is the maximum time allowed between two key updates.
In addition, a smart contract is made in which the network operator receives a reminder for key refreshment at a time interval TS − ϵ with ϵ the time needed to perform the key update procedure with the device. If the network operator cannot deliver the previous value of the hash chain of the device to the blockchain, the different application servers, which are subscribed for the device, will receive a warning (see registration of application servers). The successful update of the device is also logged on the blockchain.

2) REGISTRATION OF APPLICATION SERVERS
The application developers that are interested in data coming from a certain device i first contact the responsible network operator. The network operator refers to the device's address on the blockchain, which allows the application developer to verify the device's health by checking if the device respects the planned regular key updates. Next, the application developer subscribes with the network operator and shares its public key {PK j } i . The network operator then updates the information on the blockchain by including this public key, which is later used to send warnings via the smart contract to the application developers if the devices have not undergone the required key updates.

C. KEY UPDATE BETWEEN NETWORK SERVER AND DEVICE
In this process, three messages are exchanged. First, the network server sends M 1 to the device i Here, S * s−1 is a randomly generated value by the network server. TS * s is the timestamp at the network server.
Upon the arrival of this message, the device first checks the validity of TS * s if it fits in the s to (s − 1)-th interval. If so, device i derives S * s−1 , using its previous session key S 1 s . Next, the correctness of the computed S * s−1 is verified by recomputing H (S * s−1 , TS * s ) and comparing it with the received hash value from the network server. Denote the time stamp at the side of the device by TS + s . Then the device also randomly generates S + s−1 and computes S 2 s ⊕ S + s−1 . Next, updates are derived for the long term key materials S 1 s , S 2 s .
The session key SK , to be used in the current session, is then defined by The , TS + s ). Note that this last part is used to verify the device's time stamp, which is possible in the next key update phase.
As a consequence, the device i sends the following message M 2 to the network server.   However, the server always keeps the previous value S 2 s to be still able to proceed with the process. In this case, the same protocol as before is used, but with S 2 s = S 1 s . Note that this process has a cost in protection against session temporary data leakage attacks. VOLUME 11, 2023

A. OVERVIEW OF EXPERIMENTAL SET-UP
To provide a proof of concept of the proposed blockchainregulated key refreshment scheme, we use an experimental set-up with three types of entities. These are IoT devices, the network server, and the blockchain platform for key management services. To evaluate the performance comparison of the proposed system, three different implementations of the key management service have been done. The first implementation is carried out using the Ethereum blockchain, which is a public permissionless blockchain. The second implementation is performed using Hyperledger Fabric which is a private permissioned type blockchain. The two implementations are compared with the third non-blockchain-based implementation. Two RESTful server-based applications are developed using NodeJS [19]; one for the IoT device, and the other for the network server. The IoT device is connected to the network server through a socket connection using Socket.IO [20]. The APIs of both the servers have been developed using ExpressJS [21] and serve basic functionalities such as the creation of session keys for a particular IoT device and registration of an IoT device. The entire key updating process starts when an IoT device, with a valid session key with the network server, sends a request for registration. On successful registration, a package called toadscheduler [22] is used to schedule automated key updates for the particular IoT device. The key updating process requires a couple of lightweight cryptographic operations, which are implemented using packages such as aes256 [23], objecthash [24], randomstring [25], buffer-xor [26], and @the-QRL/hashchains [27]. The experimental setup for the three different implementations is shown in Figure 3.
In the Ethereum blockchain-based scenario, a local blockchain is deployed on the system using Ganache and a smart contract is developed and deployed over it, which provides functionalities such as storing and updating session keys, registering IoT Devices, and recording the key update history. To interact with the deployed Smart Contract, Web3JS [28] is used.
For the Hyperledger Fabric-based scenario, we have used the fabric tools provided by Hyperledger Foundation [29] to set up a test network along with a certificate authority in the local system. For the development of the chaincode, which provides similar functionalities as the Ethereum Smart Contract does, we have used the NodeJS-based chaincode-api [30] to do so and deploy it on the test network. The chaincode interactions are then done from the NodeJS applications of the IoT Device and the Network Server using the Fabric Client SDK (Software Development Kit) for Node.js [31].
To compare the performance of the proposed blockchainbased mechanism with the non-blockchain system, we use an experimental set-up which uses MongoDB as shown in figure 3. For the Non-Blockchain based scenario, exactly the same steps are performed as in the protocol of Figure 2, except that there is no communication with a blockchain. We here assume the existence of an external auditing entity and thus there is no public verifiability and the trust completely relies on the auditing entity. MongoDB as a database is used to store and manage the session keys, to which this auditing entity has access in a secure way via standard security mechanisms.
We now discuss the specifications of the implementation aspects of the two blockchain-based systems and the nonblockchain-based system.

1) ETHEREUM-BASED SETUP
In the Ethereum-based experimental setup, a smart contract named NetworkServerContract is implemented. It is assumed that the network server administrator deploys the smart contract. Hence during the deployment, the administrator's Ethereum address is set as the contract's owner. It is also assumed that the IoT devices have their independent Ethereum addresses, which are used as the device IDs. Only the owner can store, update and manage the session keys of the IoT devices. The smart contract also has a register function which an IoT device can call with the device details such as the key update interval, the number of updates remaining based on the hash-chain, and recent hash-chain value. The registration happens successfully only if the device with its Ethereum address has a valid session key present on the Blockchain. Once the registration is done, a registered event is emitted from the smart contract, which the network server application listens to in real-time. On receiving the event, the application schedules an automatic key update time with the interval specified by the IoT device. During the key update process, the IoT device and the network server communicate through a secure socket channel. On the successful generation of the key, the network server updates the session key on the Ethereum blockchain along with updated device details such as remaining updates and the recent hash chain value.

2) HYPERLEDGER FABRIC BASED SETUP
The Hyperledger Fabric-based setup works almost similarly to the Ethereum-based setup. The key difference is that the functionalities of the smart contract (i.e., NetworkServer-Contract) in the Ethereum-based setup are facilitated by chaincode (named NetworkServerChaincode) deployed on the Hyperledger Fabric test network in this setup. The NodeJS SDK for Fabric helps set up wallets for both the network server and the IoT device, which are then used to sign any transaction calls made to the chaincode. For the simplicity of the prototype, the network consists of one orderer node and two peer nodes.

3) NON-BLOCKCHAIN IMPLEMENTATION
In the Non-Blockchain based scenario, MongoDB is used to store the session keys and the IoT device details. The network server application can store a new session key for an IoT device to be registered directly on MongoDB, when the device requests for registration with the device details (such as the device id, key update interval, number of remaining updates and recent hash-chain values) are sent. The key is fetched from MongoDB, and if it is valid, the device gets 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, which will update the session key of the IoT device based on the interval it has specified. The Key update process is the same as the Blockchain-based system, the IoT device, and the network server communicates via a socket channel to update the session key. Once the process is complete, the network server stores the updated key and the device details, such as remaining updates and the recent hash-chain value on MongoDB.

B. EXPERIMENT RESULTS
The performance of all three experimental setups is evaluated. First, the cost is calculated incurred by the Ethereum-based system. As the Hyperledger Fabric framework uses the SOLO consensus protocol, there is no cost associated with it. Next, the scalability of the three systems is compared.

1) COST COMPUTATION FOR ETHEREUM-BASED SETUP
To validate and confirm new transactions, a new block is to be mined. To do so, miners perform intensive computations which require resources such as energy, storage, and high-end processing infrastructure. In return, miners in the Ethereum blockchain are rewarded in units called Ether for mining new blocks. The senders of all the transactions which get confirmed with the mining of a new block, pay this reward in terms of gas which is converted into Ether. The conversion is based on the current gas price value (i.e., the value of 1 gas in terms of Ether). The more the value of gas for a transaction send to the blockchain, the higher is the priority given by the miners, and thus the execution will be faster. For the experiment, we have set the gas price as 1 GWEI as it is the moderate rate used for transactions. For the calculation of the cost, the gas required by the NetworkServerContract for deployment as well as for various functionalities is calculated by using the remix tool. 1 The cost for the deployment of the NetworkServerContract is shown in Table 2.
There are two types of costs associated with the Ethereum blockchain, one is the transaction cost which is a fixed fee paid to Ethereum for a transaction along with the additional cost if any data is sent with the transaction. The other cost is the execution cost, which is the cost of any operation performed on the smart contract for a given transaction. Any transaction which writes or sends data to the Ethereum blockchain incurs some cost but reading data does not cost anything. Thus, the costs are calculated for three different  operations: (i) storing or updating session keys for a device, (ii) registering a new device, and (iii) updating device details. Table 3 shows the computed costs.

2) SCALABILITY EVALUATION
The comparison of performance for the three different systems is made by performing the scalability test, which consists of calculating the average time taken for the update session key process simultaneously for a large number of IoT devices. In the case of the two Blockchain-based systems, we have assumed that the session key update process involves two smart contract calls; one to update the session key on Blockchain and a second to update the device details on the Blockchain. Especially, the latter takes the most amount of time in the entire process. Hence, we have calculated the average time taken for a large number of devices (up to 600) by taking the average time of the sum of both smart contract calls. In the case of the non-blockchain-based system, we have simulated multiple devices through a script and have used the devices to perform the key update process simultaneously. The average time taken for the key update is calculated for the different number of devices (up to 600) from the time taken by each device. Figure 4 shows the comparison of results for the three different systems. In the case of the non-blockchain system, the time taken by the least number of devices which is 50, is 63 milliseconds, and as we increase the number of devices, it goes up to a maximum of 579 milliseconds for 600 devices. The time for the update process is less as it involves less CPU-intensive operations and no network calls as the database runs locally. For the Ethereum-based system, the time taken by 50 devices is 902 milliseconds and goes up to 9915 milliseconds for 600 devices. The time in the blockchain-based system is high as it involves two smart contract calls, and due to the proof of work consensus algorithm. As we increase the number of transactions sent by multiple IoT devices, the transactions get accumulated and processed sequentially in batches of the maximum transactions stored in a single block, thus increasing the time. The difference in time between the Ethereum and the non-blockchain-based system is high, but this is prevented by using the Hyperledger Fabric-based system as it uses the Solo consensus algorithm instead of the Proof of Work consensus algorithm. The time taken by the Hyperledger Fabric-based system for the key updation process is 5304 milliseconds for 600 devices and thus more in line with the Non-blockchain-based method. Thus, the Hyperledger Fabric-based system is highly scalable compared to the Ethereum-based system, and there is no cost incurred for the chaincode interactions.
To further analyze the scalability of the Hyperledger Fabric system, the Hyperledger Caliper [32] benchmark tool has been used to generate the throughput of transactions for different rate controllers. The rate controllers are used to simulate the pattern of incoming requests to the hyperledger network. The caliper tool is configured to simulate five worker nodes to process the various requests. Four different types of rate controllers have been used for this experiment: fixed load, fixed-rate, linear rate, and composite rate. Figure 5 shows the throughput per second for up to 600 requests using the various rate controllers. The fixed load rate controller has been configured to send the maximum number of transactions available for each iteration hence the throughput increases with the increase of the number of requests sent to the network. The linear rate controller is configured to linearly increase the number of transactions being sent to the network from 10 to the maximum number of available requests for each iteration. The throughput averages around 40 transactions per second. Similarly, the fixed rate controller is configured to send 10 requests per second and the throughput averages out to around 10 transactions per second. To model and simulate complex network behavior, the composite rate controller is used which allows the configuration of multiple simple rate controllers in a single iteration. The controller switches between the simpler rate controllers automatically according to the specified weights for each of them. The weights increase the frequency of usage of a given rate controller over others. For this experiment, the composite rate controller has two fixed-rate controllers configured inside of it to send requests to the network at a rate of 10 and the maximum number of requests available in the iteration with weights 1 and 2 associated with them respectively. The fluctuations in the graph for the composite rate indicate the switching of the two fixed-rate controllers randomly. The results obtained from the benchmarking tool do not generate any failed transactions for the different ratecontrolled transactions. The throughput for fixed load shows that the system scales based on the increase in requests and the scalability can be further increased if needed by adding more worker nodes to the network.
Accordingly, the composite rate controller enables the configuration of multiple ''simpler'' rate controllers in a single round, promoting the reusability of existing rate controller implementations. The composite rate controller will automatically switch between the given controllers according to the specified weights (see the configuration details after the example).

C. LIMITATIONS OF THE IMPLEMENTATION
For the Ethereum-based setup, one major limitation is scalability. As more devices join the network, the amount of data that needs to be processed and stored on the blockchain increases, which can lead to a slower transaction rate. Additionally, using a proof-of-work (PoW) consensus algorithm in Ethereum can lead to high energy consumption, which is not ideal for IoT devices with limited power resources. Another limitation is the lack of privacy, as all transactions on the Ethereum (public permissionless) blockchain are visible to anyone on the network.
For the Hyperledger Fabric-based setup, one of the limitations is the complexity of configuring and managing the system. Also, using a permissioned blockchain involves using trusted authority to manage access to the network which limits the network's decentralization.
As for future scope, there is a lot of potential for using blockchain technology to secure and decentralize IoT networks. One area of research is developing more efficient consensus algorithms that reduce energy consumption and improve scalability. Another area is exploring the use of hybrid blockchain solutions that combine the benefits of permissioned and permissionless blockchains to create more flexible and secure networks.

VI. SECURITY EVALUATION
This section discusses the security first from a protocol point of view, and next go deeper into the security from the Blockchain perspective.

A. SECURITY OF THE AUTHENTICATION AND KEY AGREEMENT UPDATE PROTOCOL-INFORMAL ANALYSIS
As discussed in Section III-D., we have to ensure that the proposed protocol provides the typically required cryptographic features, taking into account the presence of active and passive attackers.
• Mutual authentication: For each of the sent messages (M 1 , M 2 , M 3 ), the corresponding receiver can uniquely determine the sender's authenticity. This follows from the fact that parts of the messages are protected by key material, which is assumed to be in possession of the expected communication party and can be verified by hash functions. In addition, both the network server and device contribute to the construction of the updated key material as both generate a random value.
• Integrity: The essential parts of the messages are included in a hash function, enabling the verification of its integrity.
• Confidentiality: Only the entity in possession of either the pre-shared key material (S 1 n , S 2 n , H n i ) or the later derived key material (S 1 s , S 2 s , H s i , s < n) can retrieve the required data to construct the session key K .
• Perfect forward secrecy: This is guaranteed by the fact that the key material (S 1 s , S 2 s ) is updated after each run of the protocol, and the previous values are erased from the memory. Moreover, these updated values are constructed through a hash operation on different parameters that cannot be revealed based on the data sent over the channel. Also the session keys are built employing a hash function on values that cannot be revealed based on only knowledge of the stored key material (S 1 s , S 2 s ). • Protection of data: Protection against leakage of session-specific data is obtained thanks to the usage of two independent keys S 1 s , S 2 s . As long as both are not known, it is not possible to derive additional information enabling the construction of the updated values or the session key. Note that no protection against this type of attack is obtained in the desynchronization phase.
• Attack resistance: Protection against man-in-the-middle and impersonation attacks are obtained as mutual authentication, integrity, and confidentiality are ensured in the protocol.
• Prevention of replay attack: Protection against replay attacks is guaranteed thanks to the usage of timestamps, whose authenticity is verified by including them in the different hash operations.
Finally, the scheme's main goal, providing public verifiability to external parties, is obtained thanks to the usage of a hash chain defined in the device. Each hash value in the hash chain is gradually released from front to back as discussed in section IV. The corresponding timestamps at which the key update process at the device's side is taken is also protected by means of a hash on the second last received hash chain value. It should be additionally mentioned that the verification for VOLUME 11, 2023 this can only happen during the next period, i.e., the next release of the value of the hash chain.

B. SECURITY OF THE AUTHENTICATION AND KEY AGREEMENT UPDATE PROTOCOL-FORMAL ANALYSIS
In order to formally prove the protection against mutual authentication, integrity, and confidentiality of the blockchainbased key refreshment protocol, the non-monotonic logicbased verification RUBIN logic [33] is used. This method is applied in a multitude of papers and has the advantage that it is closely related to the actual implementation of the protocol. The evaluation is performed based on the evolution of a global set, local sets, and actions. The global setting is public and consists of four different sets, which include information available in the protocol. First, the principal set P = {D, NS, BS} defines the participants in the protocol. Second, the rule set contains the inference rules for deriving new statements from existing ones [33]. Third, the secret set S defines the secrets at a given moment in time. To start, Finally, the three observer sets include all participants who know the secrets contained in S. Here, the following observer sets are distinguished: The local sets contain a possession set, belief set, and behavior list, and are different for each participant. The possession set Poss(P) includes all secrets known for that particular participant P. The belief set Bel(P) contains all beliefs held by a participant P, e.g. with respect to key freshness (denoted by #), and possession of secrets by other involved participants. The behavior list BL is basically defined by the different actions executed by the participants.
As the communication begins with NS, we start with the definition of the local sets of NS, followed by the device D and the blockchain server BS. Local sets of NS:

and TS
For the verification of the protocol, we start with running the actions NS1-NS3 of the BL of NS. This results in an update of the global sets (S, Obs) and the local sets (Poss,Bel) of NS.  Therefore, we can conclude the following statements related to confidentiality, integrity and mutual authentication.
• The material S 1 s−1 , S 2 s−1 , S 2 s to derive new keys for the next session are fresh and are only known by the legitimate participants' NS and D.
• The key material used in this session was fresh and resulted in key material K, which is only known by the legitimate participants' NS and D.
• Thanks to the possession of H s−1 i by D and H s i by NS and BS, the authenticity of D is uniquely verified because of the strength of the hash function.

C. SECURITY ANALYSIS OF SMART CONTRACT AND BLOCKCHAIN-BASED SYSTEM
Blockchain-based key refreshment mechanism provides strong authentication and non-repudiation thanks to its underlying cryptographic mechanisms such as public-key cryptography, hashing, and digital signature. In the case of a non-blockchain-based system due to the centralized database, important requirements such as availability, verifiability, and access control are challenging. The use of smart contracts in conjunction with blockchain provides transparency and tight access control. Nevertheless, any loophole in smart control can be a source of a security breach. Thus, to ensure the security of the blockchain-based system the developed smart contact is tested for vulnerabilities such as indirect execution of unknown code, reentrancy, interface/naming issues and incorrectly handled exceptions. As shown in table 4 various tools are used to check the presence of such kinds of vulnerabilities. The results manifest the security strength of the smart contract.

VII. CONCLUSION
In this paper, we have proposed a distributed ledger-based solution to enforce key refreshment of the IoT devices in a publicly verifiable way on regular time frames. We have implemented the solution on both Ethereum and Hyperledger fabric-based systems. We show that Hyperledger offers a highly scalable approach enabling the update process of 500 devices in less than 4.5s. A corresponding dedicated key update protocol between the device and network server is also proposed enabling mutual authentication, integrity, confidentiality, perfect forward secrecy, and protection against 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 techniques to integrate with the smart contract allowing the identification 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 high storage cost for the IoT device, but the communication and computation costs are very low.