Authentication-Chains: Blockchain-Inspired Lightweight Authentication Protocol for IoT Networks

Abstract

Internet of Things networks (IoT) are becoming very important in industrial, medical, and commercial applications. The security aspect of IoT networks is critical, especially the authentication of the devices in the network. The current security model in IoT networks uses centralized key exchange servers that present a security weak point. IoT networks need decentralized management for network security. Blockchain, with its decentralized model of authentication, can provide a solution for decentralized authentication in IoT networks. However, blockchain authentication models are known to be computationally demanding because they require complex mathematical calculations. In this paper, we present an Authentication-Chains protocol which is a lightweight decentralized protocol for IoT authentication based on blockchain distributed ledger. The proposed protocol arranges the nodes in clusters and creates an authentication blockchain for each cluster. These cluster chains are connected by another blockchain. A new consensus algorithm based on proof of identity authentication is adapted to the limited computational capabilities of IoT devices. The proposed protocol security performance is analyzed using cryptographic protocols verifier software and tested. Additionally, a test bed consisting of a Raspberry Pi network is presented to analyze the performance of the proposed protocol.

1. Introduction

The demand for IoT applications in recent years has increased substantially. IoT applications include commercial, medical, and industrial implementations [1]. In these applications, the security of the IoT network is very important. Specifically, the authentication of the devices in the IoT network [2]. The conventional solution for IoT device authentication depends on key exchange servers. These servers provide services, including creating and distributing keys and certificates in the IoT network [3]. The widely used TLS/DTLS (Transport Layer Security/Datagram Transport Layer Security) protocols provide the security requirements of authentication, confidentiality, and integrity. Authentication is achieved when the server and the client exchange digital certificates during the handshake process. The certificates are issued by a server that is part of the public key infrastructure [4]. The public key infrastructure and digital certificate model have been shown to have multiple security vulnerabilities [5]. Additionally, the centralized nature of the public key infrastructure presents a major challenge in the diverse and distributed IoT network. This presents the issue that IoT networks demand a decentralized method of authentication that can provide the desired level of security and, at the same time, presents a solution for authentication that is lightweight and suitable for the limited processing capabilities of IoT devices [6].

Blockchain technology is being considered a solution for the decentralized security problem in multiple applications [7,8]. Blockchain has a distributed nature that can serve IoT security very effectively [8]. However, blockchain requires a substantial amount of computational resources and bandwidth to achieve the authentication of its participants and their transactions [9]. This means that the application of blockchain for authenticating IoT devices requires more memory, processing, and energy resources than IoT devices can provide.

The high memory and computational demands of blockchain technology are critical challenges for the adoption of blockchain technology in IoT security. A suggested solution is to use edge devices to authenticate the data transaction using smart contracts [10]. However, this presents new points of failure in the network. Additionally, the use of smart contracts for creating tokens is suggested. These solutions would solve the limitation of the IoT devices but, at the same time, would present new shortcomings, including the presence of points of failure in the network and the dependency on existing blockchain applications that are already overcrowded and have large processing demands [11].

To answer the IoT networks’ need for decentralized security and to address blockchain’s high processing requirements that limit its application in IoT, we present an authentication protocol for IoT devices. This protocol is based on concepts presented by blockchain technology to provide device authentication in IoT networks while being decentralized and lightweight. This paper is a significant extension of the concepts and ideas presented in our early work [12]. The following contributions are presented and investigated:

• Presenting multiple levels of blockchains for IoT device authentication, called Authentication-Chains, with more emphasis on integrating authentication chains with the existing IoT network structure.
• Proposing a consensus algorithm that uses an identity-based encryption key pair to verify and validate the devices in the multiple-level blockchains.
• Analysis of security performance of the proposed Authentication-Chains.
• To present a working test bed of Authentication-Chains and to evaluate and compare its performance with existing blockchain technology.

The remainder of this paper is organized as follows. Section 2 presents existing literature that investigates applying lightweight, decentralized solutions for IoT security using blockchain technology that focuses on device authentication in IoT networks. Section 3 presents the protocol structure in detail. In Section 4, the protocol security is analyzed. Section 5 presents the simulation and performance results. Section 6 presents the concluding remarks.

2. Related Work

The use of blockchain technology for securing IoT networks has witnessed great interest in the last few years. Researchers have proposed different security applications for IoT networks for healthcare, sensing, and energy. Several applications adopt the cryptocurrency and smart contracts for IoT applications for network management, such as the work in [13], where the authors explore the application of blockchain for security management without the need for a trusted agent; the work in [14] uses Ethereum blockchain for public key pair management. Additionally, in [15], the authors propose a continuous blockchain authentication scheme based on blockchain for fog layer devices. Control of IoT devices using private blockchains and interconnecting them over public blockchains is introduced in [16], where the authors propose a tiered blockchain structure for IoT device security management. Additionally, the authors of [17] propose a method for preserving and managing the security of IoT devices using blockchain. Access control of IoT devices using blockchain is proposed in different forms that are presented in [18,19,20]. The use of hybrid forms of blockchains is also presented in [21], where private and public blockchains are interconnected to authenticate IoT devices. Other types of consensus and ledgers are also presented, such as using multiple blockchain technologies by combining Ethereum and IOTA applications for authentication [22] and side chains [23].

Moreover, several methods of consensus are present to minimize the blockchain requirements, such as proof of authenticity [24] and access control based on device capability [25]. Other researchers are concerned about the authentication mechanism itself and how the blockchain can be used for key management and have introduced several methods of authentication based on blockchain, such as in [5,26].

Most applications use existing blockchain technology for IoT devices and data authentication by introducing devices that work as a connection point between the IoT devices and the blockchain network. These applications use smart contracts or issue tokens to manage the authentication of IoT devices. On the other hand, some researchers concentrate on financially rewarding the data owners, which may limit the application of blockchain technology in IoT because of the cost of blockchain access.

In our proposed work, we introduce a blockchain authentication mechanism that is designed for IoT device authentication. We present a new way of using blockchain technology in IoT networks in a way that is simple, lightweight, and takes into consideration the specific needs of IoT devices and networks.

3. Protocol Structure

The Authentication-Chains protocol aims to solve the problem of providing a lightweight, scalable, simple decentralized authentication process for IoT networks. The solution is based on the blockchain-decentralized authentication model.

In the proposed protocol, we consider the security of Fog and Edge devices in IoT networks. First, we categorize the devices in clusters based on their type, processing capabilities, and their energy reserve. These clusters are arranged in multiple levels; each level is managed by a small blockchain that uses proof of identity authentication. These small blockchains are connected to create multiple levels of authenticated devices.

The design of the Authentication-Chains authentication process is specifically aimed at the IoT network topology. In IoT networks, it is commonly agreed to arrange the devices based on their function and ability to sense devices that have low power and low capability [2,27]. Their main function is to collect data from the attached sensors [28]. These devices are attached to access points or managing devices that collect the received data from the sensing devices to be stored or processed; usually, these devices are referred to as edge devices. Finally, cloud storage and managing servers are used for data processing and large-scale storage.

In general, as shown in Figure 1, the devices in IoT networks can be categorized based on their processing and bandwidth resources into:

• Cloud Devices: These include large data servers and network management servers. These devices have large processing and data storage capability and have high bandwidth communication channels.
• Edge devices: These include access points and edge data servers. These devices have more processing power than other IoT devices and have larger storage capabilities and larger bandwidths. These devices present a linking point between cloud servers and IoT devices and perform basic tasks of network security management.
• IoT devices: These devices can be divided into two categories.
  • The first category includes the data collection devices that manage the data collection from the sensing devices. The devices in this tire are limited in their storage and processing powers and have limited bandwidth and constrained energy reserves.
  • The second category includes sensing devices that have minimal processing power, very limited connectivity, and very limited energy reserves. In general, these devices are small sensors and actuators that are managed by more capable devices.

3.1. Blockchain Structure

Authentication-Chains protocol works by creating groups of IoT devices that are related by location or function within the IoT network. These devices are assigned to be a member of a cluster that has a small blockchain. The blockchains that are created follow a hierarchical order. That is, devices within a cluster are assigned to be in the lowest level of the blockchain hierarchy; this level is assigned to be level-0 blockchain. Devices with higher computational power are assigned to be cluster heads, and they participate in the cluster blockchain, “level-0 blockchain”, and in a blockchain containing the other cluster heads, “level-1 blockchain”. Edge devices also participate in a cluster, and each device participates in two blockchains, “level-1 blockchain” and “level-2 blockchain”. The resulting interconnected blockchains are shown in Figure 2.

To overcome the complexity and high memory requirements of existing blockchain architecture, Authentication-Chains use a reduced block size by using smaller blocks that store a single transaction called a device authentication request (DAR) in addition to the previous hash and block index value. The block structure is shown in Figure 3. The validation process for the authentication transaction is simplified to reduce the response time of the network. Basically, the validation process depends on two factors. The first is that the device is part of the cluster managed by a certain cluster head, and the second is that the authentication transaction is signed by the requesting device and verified by the other devices within the same cluster. The device validation process and the simplified consensus algorithm are discussed in detail in Section 3.1.

As illustrated in Algorithm 1, we use an asymmetrical RSA key pair generated from the device address. In the blockchain network, the device is identified using its public key. The device sends an authentication request containing its device ID (the device’s public key) and the cluster head device ID (the public key of the device taking the role of cluster head). This request is signed using the device’s private key. The receiving devices in the network within the same cluster verify the signature using the device’s public key. If the request is verified, the authentication request is used to generate a block by hashing the content of the authentication request, the node id, the cluster head id, the index value, and the previous hash.

Algorithm 1: Authentication chains algorithm.

Inputs: device_Address, cluster_head_Address. # Device id is the public key of the RSA key pair created from the device address value. device_Id = Puk_Device(RSA(device_address)) # Cluster head id is the public key of the RSA key pair created from the cluster head address value. ch_Id = Puk_CH(RSA (cluster_head_Address)) # Device authentication request (DAR) is sent to the devices in the related cluster for verification Sign_DAR = ((device_id,ch_Id),PrK_Device)) DAR = (device_id,ch_Id,Sign_DAR) # Device authentication request is sent to all device in related cluster Function send (DAR); # Devices verify the DAR Function verify_DAR(DAR, Puk_Device) If DAR signature is valid, then Function create_Blcok (node_id,ch_id, prv_hash, DAR) Else DAR is invalid DAR rejected. # When a block is created the device in the related cluster verify the block by comparing block hash values from their copy of the block chain. Function validate_Block (new_Block, blockchain) If block is verified, then Block added to blockchain Device added to authentication_Table Else Block is rejected.

The process of creating multiple blockchains for authentication requires that these blockchains are independently created for each cluster of devices at the same time. The cluster blockchains are connected to the upper-level blockchain by the hash field of the first block in each cluster blockchain. The genesis hash value is calculated from the cluster head block of the upper-level blockchain. This approach prevents the presence of imposter blockchains. This method of structuring the blockchains presents hierarchically connected blockchains. The structure is shown in Figure 4. This structure uses one level of blockchain for each cluster. These blocks are seeded and started by providing a genesis hash created by each cluster head in the cluster. Another blockchain is used to authenticate the cluster heads.

The clusters blockchains used for creating authentication process the devices in the network in the following steps:

• For a device in the network, it must first be part of a cluster, as illustrated in Figure 2. The figure shows that each cluster consists of a number of devices that share the same cluster head. The cluster heads are also part of a higher-level cluster, which also has its own cluster head.
• The device sends a device authentication request (DAR) to the devices in the cluster. The devices verify the device’s ID and signature. If the signature is verified, a block is created containing the device’s credentials. The block hash, the device id, and the block index are added to an authentication table.
• The device must provide the device ID and the block hash for any further communication in the network.

The addition of the authentication block hash provides an additional level of security because if the attacker can gain control over the network, he cannot reproduce the same hash value from the blockchain.

3.2. The Consensus Algorithm

The typical application of blockchain consensus methods would increase the bandwidth and processing demand on the network. The commonly used consensus algorithms in blockchain applications include:

• Proof of Work (PoW): In proof of work, the nodes need to compete to solve complex mathematical problems. The node that finds the solution adds a block to the blockchain. The difficulty level is increased with each block added to the blockchain. The PoW consensus algorithm requires high processing power to solve the mathematical problems and demands high memory resources to store the blockchain in each node. The high resource requirement deems PoW unsuitable for IoT applications. The most common applications of PoW include Bitcoin and Ethereum V1.
• Byzantine Fault Tolerance (BFT): This consensus approach requires multiple rounds of consensus among the nodes in the blockchain network. Each node votes to reject or accept the addition of a new block to the blockchain. This approach is mostly used in private networks, and it is only applicable if the number of good nodes is larger than the bad nodes in the network. BFT has lower computational demands compared to PoW, but at the same time, this consensus algorithm has high network bandwidth demand.
• Proof of stake (PoS): This is the consensus algorithm used in the Ethereum V2 network. PoS is basically weighted BFT, where every node has voting power proportional to its stakes in the network. This consensus algorithm is faster and has lower network bandwidth demand; however, the stake share required for adding a new block means that the network control is limited to nodes with higher stakes.

The proposed Authentication-Chains protocol uses a simplified consensus algorithm where each device verifies the signature of a device. Based on this verification, the transaction is authenticated and added to the blockchain. The Authentication-Chains protocol does not have any reward system to reduce the bandwidth and processing required for the consensus process. That means that the devices within the same tier do not have to perform further calculations to adjust their reward values. The consensus algorithm will be further discussed in Section 3 and Section 4.

3.3. The Authentication Table

The main goal of the proposed work is to manage the authentication process in the IoT network in a decentralized way with minimum resource consumption. This means that using a blockchain transaction to register every communication between any two devices in the IoT network would be time-consuming and has a larger processing power requirement and higher memory load. Because of this issue, the proposed work registers the device in the blockchain ledger using DAR. This assigns a specific block with a specific hash value to every device in the IoT network. This value is based on the device’s public key value, which is derived from the device’s IP address in addition to the cluster head public key value.

The authentication table is a way to track these hash values in relation to the devices in the cluster blockchain and the devices in other blockchains in the network.

The authentication table stores the public key values for the devices in addition to the hash values of the blocks from the cluster blockchain related to each device in the cluster. The authentication table is decentralized and is stored in every device in the cluster. This eliminates the need for having a trusted public key-storing server in the network because the attacker cannot replace the block hash values without replacing the whole blockchain. Moreover, if the attacker manages to change the authentication table in a device, the other devices have their own copy of both the blockchain containing the DAR and the authentication table.

The authentication table’s stored values vary depending on the device’s capabilities and the device’s position in the ordered device structure. In this way, the memory overhead required for storing the authentication table is reduced.

For illustration purposes, if the network has three levels of blockchain, level-0 clusters correspond to a level-0 blockchain, and, respectively, level-1 and level-2 clusters correspond to level-1 and level-2 blockchains. As described in previous sections, higher levels contain devices with more available resources.

The devices in level-0 clusters have authentication tables containing the authentication information for that cluster. The cluster head of the level-0 cluster is also a member of a level-1 cluster. By design, this device has more storage capability and is required to store the authentication information from the level-0 cluster and the authentication information from the level-1 cluster.

Refer to Figure 5 for three levels of blockchains. The authentication table stored in devices in level-0 contains only the device id, the cluster head id, the block hash value, and the block index for the devices in the level-0 cluster. The cluster head named CH1 is part of another cluster that is managed by a level-1 blockchain. CH1 stores two parts of the authentication table the information related to level-0 cluster devices and the information for the devices in the level-2 cluster. This information includes the device ID, the cluster head ID, and the hash values from the level-1 blockchain. The devices in the level-3 cluster also store the information related to lower-level clusters, namely level-1 and level-0, in addition to the information related to devices in the level-2 cluster, including the devices ID, the cluster head ID, and the related block hash values and indices from the level-2 blockchain.

3.4. The Initialization Process

The proposed protocol has two main processes: the initialization process and the authentication process.

The initialization process involves the steps taken by the devices that are arranged in the clusters and the creation of the cluster blockchains required to build the authentication table. The process is presented in Figure 6. The initialization of Authentication-Chains blockchains and authentication table works as follows:

• Based on identity-based keys, each node generates a public key pair based on its IP address.
• In Authentication-Chains, there is only one type of transaction called a “Device Authentication Request” (DAR). Each device is allowed to send only one DAR that contains the following (the device public key as an ID, the higher-level device ID that works as the cluster head for the cluster that the device is a part of, and the signature of the transaction).
• The Authentication-Chains are formed from interconnected blockchains based on the following steps. As in Figure 4, starting from the level-2 device, a seeding hash is provided to level-1 devices. This seeding hash is used in the previous hash field in the first block in the level-1 device’s blockchain. In an equivalent way, a seeding hash is provided from the level-1 device to all level-3 devices connected to that device. This results in a tree-like connected blockchain, with each block initialized using data from the upper-level device.
• When a device within a certain group is validated, a new block is added to the related group blockchain. This device ID is added to the authenticated devices table (AuthTable). The table contains information about the group of devices that formed the blockchain within that group.
• The authenticated device table contains the device ID, the cluster head (CH) device ID that is connected to it, and the block hash and block index resulting from validating the authentication request of the device.

The next step after the cluster blockchains and authentication table are created is the authentication process.

3.5. The Authentication Process

After the initial process of adding the device to the authentication table, the device’s interaction with the network can be authenticated using the credentials stored in the authentication table.

To explain the authentication process, as presented in Figure 7, we need to set the following preliminary definitions. The sending device “A” is assumed to be part of a cluster with cluster head ID “CHA”. The receiving device “B” is assumed to be part of a cluster with cluster head ID “CHB”. The device ID is obtained from the public key part of the RSA encryption of the device address and added to the cluster head ID obtained from the public key part of the RSA encryption of the cluster head address. This means that device A is identified by the tuple $A={(puk}_A,{puk}_{CHA})$, similarly device B is identified by the tuple $B={(puk}_B,{puk}_{CHB})$.

The plain text message is M. To send the message, the plain text M is added to the tuple with the transmitting device ID and is encrypted using the receiving device’s public key. The message contains the following parts:

• The sender ID;
• The encrypted plain text;
• The authentication block hash of the sender.

The steps for message exchange are the following:

• For device A to communicate with device B, “A” would send a message containing plain text M amended to it with the sender ID “A” and the receiving device ID “B”. In addition, the block hash validating the sending device is appended to the message.
• The receiver B receives the message and decrypts it. To authenticate the message, it compares the sender ID with the value from the decrypted part; it also compares the sender ID with the authentication hash from the authenticated list values. If the values are verified, the sender is authenticated.
• If the cluster head value does not match or if the block hash value is not matched, the sender is not authenticated, and the message is rejected.

In the following sections, we will discuss the security of the proposed protocol and present an analysis of its performance.

4. Protocol Analysis

The proposed protocol uses the blockchain structure to create an authentication list that is used for authenticating the devices. This process is required for adding new devices to the cluster blockchain. Data transmission does not require further validation using the blockchain. This means that the complex calculations required for data transmission are reduced. At the same time, the devices participating in the network are all verified and validated by the cluster’s blockchains. Moreover, the addition of the cluster head ID ensures that new attackers are not able to interact with the network without completing multiple validation steps. This makes the process of successfully attacking the network very difficult. The following claims evaluate the proposed protocol security performance:

Claim 1: 

The proposed protocol has minimum resource consumption.

Proof: 

The proposed protocol does not require complex calculations for block validation in the blockchain. In addition, the blockchain is needed only for the initial authentication process and it is not required for further transactions. Furthermore, the grouping of IoT devices in clusters and each cluster having its own blockchain reduces processing, memory, and energy requirements usually related to blockchain management. □

Claim 2: 

The proposed protocol needs a shorter time than other blockchain authentication methods.

Proof: 

The proposed protocol has minimal time requirements for the following reasons:

• Using an independent blockchain for each cluster means that the authentication process can be performed simultaneously.
• Using a simpler validation process in the blockchain results in a shorter time for blockchain validation.
• The device authentication process requires the creation of a single block, further authentication is based on the original block hash, and its time is minimal. □

Claim 3: 

The proposed protocol provides decentralized, scalable security for IoT networks.

Proof: 

The protocol can adapt to an increasing number of IoT devices without affecting its performance because the IoT devices are grouped in clusters, with each cluster having its own blockchain. The authentication process depends on values that can be managed and stored, such as asymmetric cryptography. Furthermore, the blockchain structure and validation process are designed specifically for IoT networks. □

In the following section, we will analyze the authentication process and validate the security of the proposed protocol.

4.1. Informal Analysis

In this section, an informal analysis of the proposed authentication method is based on the work of [29,30]. To simplify our work and to make it compatible with predominant internet applications, we are using RSA encryption; other public key-generating algorithms can be used, such as elliptical curve or more powerful lattice encryption. However, RSA is secure enough for demonstration purposes and simple enough to be applied using the available processors of IoT devices.

In the following sections, the device is identified by its Node ID, which is the public key part of the RSA key pair. The RSA key pair is generated from the node’s address. As described in the previous sections, devices from the lower tire are connected to a device from an upper tier. Thus, we have a cluster of devices from a lower tier that are attached to a cluster head from a higher tier.

Each device in the cluster has an identity ${Node}_{ID}=Puk(node address),$ similarly, the cluster head has an identity ${CH}_{ID}=Puk(cluster head address)$.

For a node to join the network, it must have a DAR containing the node ID, cluster head ID, and the signature of this request. The device authentication request has the following form $DAR=({Node}_{ID},{CH}_{ID},Signature)$.

If the ${Node}_{ID}$ and the ${CH}_{ID}$ are valid and the signature is validated, a new block is created and added to the cluster blockchain. The new block hash and index are added to the authentication table in addition to the ${Node}_{ID}$ and the ${CH}_{ID}$. After this process, the node is not required to create any new blocks or transactions for its authentication. That means that blockchain processing requirements are minimal and are required when a new node is attempting to join the network. This ensures that the computing and memory loads are very low.

4.2. User Steps for Verification

The block hash obtained from the initial setup process is used in Authentication-Chains as an added value for message authentication. This hash value has the benefit of being immutable. Moreover, it is known to all the users in the network. In addition, it is specifically obtained for a single node. Furthermore, it is related to the device position in the network by adding the cluster head ID. Because of the above properties, the attacker does not have the ability to recreate the same exact values.

To investigate the Authentication-Chains method of authentication performance, we will analyze a communication scenario and investigate the possibility of an attacker affecting the security communication.

Let us assume a scenario consisting of a sender X and a receiver Y, where X wants to send a message M to Y. It needs to send the tuple $T=(X,EncY(M),Y),$ which contains the sender’s ID X, the encrypted message using Y’s private key, and the receiver’s ID Y. To verify the security of the communication, we must prove that an intruder Z cannot claim to be either X or Y without detection. We will assume that all parties can receive any message from any participant in the network, and every participant in the network can perform the following functions:

• Encryption;
• Decryption;
• Appending;
• Deletion;
• Name Matching.

The communication scenario has the following stages.

The network setup stage:

In a network setup, all the nodes in the network are arranged based on their capabilities, position, and function, as described earlier. Node X creates a key pair based on IBE and transmits its public key to all nodes in the network. Similarly, node Y does the same. Each node performs the initial authentication process and is verified and added to the authentication table by adding the block hash (BHX) and (BHY) and the block indices (BIX and BIY).

Here we have two possibilities. The first is that X and Y have the same cluster head CH which means that the block created for X and Y are in the same blockchain; the second possibility is that X and Y have different cluster heads CHX and CHY, which means that blocks created for X and Y are in different blockchains. These two options would not affect the message authentication process because the two block-hash values are shared in the authentication table.

Similarly, we can also assume that the intruder Z can also join the network by sending an authentication request, and if verified, a new block is created and validated. A hash value is added to the authentication table (BHZ), and a block index is added (BIZ).

Data communication stage:

For the data communication stage, we assume a device X that sends a message M. The receiver is assumed to be a device Y. We also assume the existence of an intruder Z that attempts to intercept the message M.

For X to send a message to Y, the transmission T contains the tuple:

$$T=(X,EncY(M,BHX),Y)$$

Where the message M is appended with the block hash (BHX) and encrypted as usual using the public key of the device Y. The identity of X and Y are also added to the tuple. When device Y receives the transmission T, Y takes the following steps:

• The message is decrypted using Y private key. DecY(EncY(M, BHX)) = (M, BHX).
• Y compares the sending node Id X with the hash value BHX from the Authentication table.
• If the BHX value is matched from the authentication table, the device X block index (BIX) is used to find the authentication block in the blockchain. If the hash of the block with index BIX matches the hash in the message BHX, then the receiver Y authenticates that the sender is X.
• Device Y now sends the message M back to device X with transmission tuple:

$$T=(Y,EncX(M,BHY),X).$$

The receiver X can repeat the previous steps to authenticate the message received from the transmitter Y.

The intruder Z is an outsider from the network. This means that for intruder Z to claim to be the transmitter X, the intruder Z must have the exact value of the blockchain hash related to X, meaning that BHZ = BHX and this case, it is impossible because of the nature of the blockchain ledger. The other case is if Z has already joined the blockchain and has a hash value registered in the authentication table (BHZ) that corresponds to a block with a block index (BIZ). In this case, if Z attempts to intercept the message T and tries to retransmit it as,

$$T\prime =(Z,EncZ(EncY(M,BHX),BHZ),Y).$$

The receiver Y would receive the message and perform the previously described steps to obtain $M\prime =DecZ\left(EncZ\right(EncY(M,BHX),BHZ\left)\right)=EncY(M,BHX),BHZ$.

The receiver Y verifies the message and validates the hash value BHZ and block index BIZ; however, the message is not verified to be received from X. This indicates that Z cannot claim to be X. From the above discussion we can conclude the proposed authentication protocol is secure.

5. Simulation and Performance Analysis

5.1. Simulation Setup

In this section, we present a study of blockchain performance. The proposed Authentication-Blocks protocol presents a novel approach for working with blockchains. This prevents us from using existing simulation environments such as Hyperledger Fabric. To evaluate the performance, Authentication-Blocks were implemented using Python programming language. The protocol was implemented using a network consisting of the devices shown in Figure 8.

The network has two Raspberry Pi Zero level-0 nodes, and for simplicity, we will assign them as “node 0” and “node 1”, the Raspberry Pi 3 B+ as level-1 cluster heads which are assigned as “CH-RPi0” and “CH-RPi1” and the computer with I7 processor as the level-2 cluster head that is assigned “CH-PC”. The Raspberry Pi devices have limited processing capability that simulates devices in IoT networks that have low resources. The specifications of the devices are presented in

Table 1. Device specifications.

Device	OS	Processor	RAM
Raspberry pi zero w	Raspberry Pi OS	ARM11 processor @ 1 GHz	512 MB
Raspberry pi 3 B+	Raspberry Pi OS	Cortex-A53 64-bit SoC @ 1.4 GHz	1 GB
Laptop	Windows 11	Intel i7-10510U CPU @ 1.80 GHz to 2.3 GHz	16 GB

.

The proof of concept works as follows:

• The level-2 cluster head “CH-PC” is announced as the level-2 cluster head and creates the first block of the level-2 blockchain (note that there is only one node in this level, so there is only one block in this blockchain). The cluster heads of level-1 create the level-1 blockchain by using the genesis hash from level-2. The two devices, “CH-RPi0” and “CH-RPi1”, send requests to join the cluster head, and each device works to find the hash value required to join the cluster. When the hash values are found and verified, blocks are added to the level-1 blockchain, and the authentication values are added to the “AuthTable”of the cluster.
• The devices “node0” and “node1” are joined in a cluster with the device “CH-RPi0” as the cluster head.
• The devices “node0” and “node1” use the block related to “CH-RPi0” from the level-1 blockchain as the genesis block to start calculating the hash value required by the level-0 blockchain. When the hash values are found and verified, blocks are added to the level-0 blockchain, and the authentication values are added to the “AuthTable” of the cluster.
• When a device sends a message, the device information is compared to the values stored in the authentication table “AuthTable”. If the device is in the “AuthTable”, the device “node 0” is verified by the authentication table “AuthTable”.

The framework is assessed by repeating the blockchain formation and authentication process. The results are an average of 15 runs. The network delays were, on average, 7 ms, which can be neglected compared to the block creation time. The average time for a single block created in each device type in the network is shown in the first column of

Table 2. Time performance measurements of Authentication-Chains.

Device	Average Single Block Creation Time (sec)	Average Signature Time (sec)	Average Verification Time (sec)	Average Encryption Time (sec)	Average Decryption Time (sec)
Raspberry pi zero w	1.298	2.009426	0.058274	0.077642	3.537678
Raspberry pi 3 B+	0.354	0.53406	0.041908	0.032855	1.151501
Laptop	0.194	0.023046	0.003523	0.002458	0.044644

.

The authentication process performance is evaluated by considering the time required for the signature process and verification process. The measured values are shown in the second column and the third column of Table 2.

The average measured time required for encryption and decryption of data using RSA key pair is shown in the fourth column and fifth columns of Table 2.

For further performance validation, a test of both the proposed consensus protocol and proof of work consensus was conducted using Raspberry Pi 3 B+. The test consisted of creating 15 blocks using each consensus algorithm. The CPU load was recorded using Python’s Process and System Utility Library (psutil). A function that records and saves the CPU load was used to measure the CPU load every 1 ms, and it returns a text file containing measured CPU load values. The test was conducted using the same Raspberry device, and to make sure that the performance was not affected by CPU temperature variation, a cooling time of 30 min was applied between each test. The same applications were run in both tests. After each test, the device was rebooted to make sure that any extra running processes were terminated. The results are shown in

Table 3. CPU load percentage.

Consensus Protocol	CPU Load%
Proposed consensus protocol	39%
Proof of Work consensus protocol	61%

, which shows that using the proposed consensus algorithm has a lower CPU load than PoW consensus.

Most of the works in the literature that apply IoT security based on existing blockchain technology mainly deal with registering IoT devices or users within a transaction that is then added to the blockchain when a new block is added. This approach is used in bitcoin applications. The other approach is using smart contracts to manage IoT devices’ security in the Ethereum blockchain network. Because we are presenting a new structure based on blockchain, for performance analysis, we compare the proposed framework performance to that of Ethereum and Bitcoin because these are the most dominant blockchain networks.

As presented in Table 2, the overall average block creation time for all the devices is 0.699 sec. This time is very small compared to existing blockchain networks such as Bitcoin, which has a 10 min block creation time [31], and Ethereum, which has an average 15 s block creation time [32]. This implies that for a device to be registered in the Bitcoin network, it needs to add a transaction that would require 10 min to be added to the blockchain network. In Ethereum, a device requires an average of 15 s to be added using a transaction or managed using a smart contract.

As we described, the Authentication-Blocks protocol registers a single device per transaction. Each verified device has its own distinctive block in the blockchain with a unique hash value. The hash value is stored in the authentication table, thus eliminating the need for further resources and time-consuming mining. The average time for transaction time is equal to the time required for creating a single block, which is presented in Table 2.

In the Authentication-Blocks structure, the blocks for each cluster are created simultaneously, which helps to reduce the time to add all the devices to the blockchain structure. To illustrate the performance enhancement, we consider a hypothetical IoT network consisting of the number of devices presented in

Table 4. Device types and numbers in a hypothetical IoT network.

Device Type	Number of Devices	Number of Devices in the Cluster
CHL2	5	5
CHL1	20	4
Nodes	80	4

.

If we consider the performance values measured in the network in Figure 8 and presented in Table 2. The time to create a level-2 blockchain depends on the number of devices in the level-2 blockchain $N_{L2}$ and the time to create a block in the level-2 blockchain $T_{L2}$ that equals 0.194 s. Similarly, the time required to create any level-1 blockchain depends on the number of level-1 devices in the level-1 blockchain $N_{L1}$ and the time to create a block in the level-1 blockchain $T_{L1}$. This also applies to level-0 blockchain with any cluster containing $N_{L0}$ devices that need a time $T_{L0}$ to add a block to the level-0 blockchain. The time is presented in

Table 5. Blockchain levels and their respective number of devices in each cluster and the single block creation time.

Blockchain Level	Number of Devices in the Cluster	Single Block Creation Time
Level-2	NL2 = 5	TL2 = 0.194
Level-1	NL1 = 4	TL1 = 0.354
Level-0	NL0 = 4	TL0 = 1.298

.

Because of the clustering structure of the blockchain network, the time required to add a block for the level-2 node $n_{L2}$ is $(n_{L2}+1)T_{L2}$. The time required for a level-1 node $n_{L1}$ to add a block in level-1 is $T_{L2}+(n_{L1}+1)T_{L1}$. For a level-0 node $n_{L0}$ the time required to add a block is $\left(n_{L2}+2\right)T_{L2}+\left(n_{L1}+2\right)T_{L1}+(n_{L0}+1)T_{L1}$. The time to create all the blockchain networks is $\left(N_{L2}+2\right)T_{L2}+\left(N_{L1}+2\right)T_{L1}+(N_{L0}+1)T_{L1}$. For the above example, the total number of devices in our network is 105 devices. For the proposed Authentication-Chains, the time to connect all the devices is equal to 14.002 s. On the other hand, if the proposed consensus algorithm is used to create a single-level blockchain containing the 105 devices, the time required will be $5\times 0.194+20\times 0.354+80\times 1.298=111.89 \sec$.

It can be noted that the proposed structure has reduced the blockchain creation time by presenting a simplified consensus algorithm and by using the multilevel blockchain structure.

For the authentication process using the authentication table and the block hash value, the time required for data transmission is the encryption time $T_{ENC}$, the decryption time $T_{DEC}$ and the time required to calculate the block hash $T_{hash}$ to compare it to the value stored in the authentication table. The network transmission time is negligible. The total time is equal to $T_{ENC}+T_{DEC}+T_{hash}$. The average encryption and decryption times are presented in the fourth and fifth columns of Table 2. From [33], the time required to calculate the hash is 0.016 s. The average time required for data authentication is presented in

Table 6. Average time required for data authentication.

Device	Data Authentication Time TENC + TDEC + Thash
Raspberry Pi zero w	0.077 + 3.537 + 0.016 = 3.63 sec
Raspberry Pi 3 B+	0.0325 + 1.15 + 0.016 = 1.1985 sec
Laptop	0.0024 + 0.044 + 0.016 = 0.0624 sec

.

It can be noted that the addition of the hash value calculation resulted in a small increase in the authentication times. This increase is minimal compared to the time required to authenticate the transmission using an Ethereum smart contract which would require a time of about 15 s [5] for the transaction to be verified in the blockchain network.

5.2. Security Analysis

The security analysis of Authentication-Chains was conducted using Verifpal [34]. Verifpal is a security analysis tool for the formal analysis of security protocols. This tool was used for the analysis of multiple security protocols. We chose to use this tool because it provides comprehensive formal analysis and, at the same time, uses simple, intuitive language to describe the protocol. Figure 9 shows the Verifpal code for the security analysis of the Authentication-Block protocol. The verification code consists of the following elements:

• The attacker definition. The attacker is set as “active” to test every possibility of compromising the protocol.
• Principal X and principal Y are used to define the initial values known and generated by the two communicating devices, such as the node ID, the cluster head ID, and the private and public keys.
• The nodes share their public keys with messages that send the public key from node X to Y and vice versa.
• For X to send a message to Y. Node X generates a message m1. The node generates the message T1 by encrypting the m1 in addition to the block hash ‘BHX’. In Verifpal, this is performed using the function AEAD_ENC. The message is sent to Y where it is decrypted and the block hash BHX and checked.
• For Y to send a message to X, the steps of step 4 are repeated for the message m2, which is encrypted with the hash BHY to give T2.
• The security tests are included in “queries ”. The tests are the authentication of the message T1 transmitted from X to Y, the authentication of message T2 transmitted from Y to X, and the confidentiality of messages m1 and m2.

The formal analysis results are shown in Figure 10. The attacker is set to active, which means that the analysis includes all value permutations that would result in a successful attack. Verifpal concludes that only a ‘nil’ value can be used for a successful attack, which means that the attacker cannot obtain any possible value that would result in a successful attack. This concludes that the attacker cannot succeed in obtaining any value that would compromise the authenticity of the communication between the nodes X and Y. Verifpal indicates that by an “All queries pass ” message.

6. Conclusions

In this paper, we proposed Authentication-Chains, which is a decentralized and lightweight authentication protocol based on blockchain technology. This protocol works by arranging the IoT devices in clusters with multiple levels of blockchains that connect these devices to create an authentication table based on the hash values of the blocks.

The Authentication-Chains protocol implements a fast and lightweight consensus algorithm that uses an identity-based key pair to sign a transaction called an authentication request. If the authentication request is verified, a block containing this single transaction is created. The device verified by this block is added to the authentication table. The authentication process uses the public key pair and the authentication block hash to verify and authenticate the device for data communication.

The Authentication-Chains security performance was analyzed informally and simulated. The analysis has shown that Authentication-Chain is immune to potential attacks. Software security protocol analysis has shown that the protocol is immune to possible attacks.

Authentication-Chains was tested using the Raspberry Pi network. The results have shown that the proposed blockchain structure is faster than existing blockchain technology, and the authentication protocol has a fast response time compared to existing blockchain-based authentication protocols.