Hierarchical Blockchain-Based Multi-Chaincode Access Control for Securing IoT Systems

Abstract

The rapid growth of the Internet of Things (IoT) and its attributes of constrained devices and a distributed environment make it difficult to manage such a huge and growing network of devices on a global scale. Existing traditional access-control systems provide security and management to the IoT system. However, these mechanisms are based on central authority management, which introduces issues such as a single point of failure, low scalability, and a lack of privacy. In order to address these problems, many researchers have proposed using blockchain technology to achieve decentralized access control. However, such models are still faced with problems such as a lack of scalability and high computational complexity. In this paper, we propose a light-weight hierarchical blockchain-based multi-chaincode access control to protect the security and privacy of IoT systems. A clustering concept with BC managers enables the extended scalability of the proposed system. The architecture of the proposed solution contains three main components: an Edge Blockchain Manager (EBCM), which is responsible for authenticating and authorizing constrained devices locally; an Aggregated Edge Blockchain Manager (AEBCM), which contains various EBCMs to control different clusters and manage ABAC policies, and a Cloud Consortium Blockchain Manager (CCBCM), which ensures that only authorized users access the resources. In our solution, smart contracts are used to self-enforce decentralized AC policies. We implement a proof of concept for our proposed system using the permissioned Hyperledger Fabric. The simulation results and the security analysis show the efficiency and effectiveness of the proposed solution.

1. Introduction

The Internet of Things (IoT) is experiencing exponential growth with the increase of the number of digital objects connected through the Internet. The number of interconnected IoT devices is expected to reach 20.4 billion in 2022 [1]. IoT devices collect data from their surrounding environments and can share these data with various entities. Therefore, it is necessary to obtain an access-control mechanism that can filter users who can access the shared data of the IoT and determine what data is allowed to be accessed. Classical access-control mechanisms include Mandatory Access Control (MAC) [2], Discretionary Access Control (DAC) [3], and Role-Based Access Control (RBAC) [4]. In the MAC-based systems, access control is based on policies established through centralized management. This model uses security labels or restrictions to ensure the accessibility of sensitive data. DAC-based access control implements access rights in accordance with their identity or user groups. This model is created based on relations between users and objects, allowing users to provide their right of access to any other user. Within the RBAC model, access control is built according to the roles that are associated with permissions. This model assigns roles to subjects according to their tasks within the organization. The RBAC model supports many-to-many relationships between users and roles. These traditional access controls can provide security to IoT systems, but they are based on centralized management, which have some challenges—such as a single point of failure, an inability to be scaled, and privacy issues. In addition, IoT systems are under different management entities, and some other IoT scenarios may have mobility. Generally, IoT are constrained devices; therefore, classical access controls cannot give a reasonable access control to IoT environments. This paper presents a secure hierarchical blockchain-based access control for IoT systems. This solution consists of three layers: The first layer features the Edge Blockchain Managers (EBCMs), which includes IoT devices; this layer manages and authenticates any transactions from the restricted devices. Second, the AEBCM layer includes Aggregated Edge Blockchain Manager (AEBCM) nodes, which guarantee device communication with different sub-device clusters and manage ABAC policy. Finally, the Cloud Consortium Blockchain Manager (CCBCM) includes CCBCM nodes, which are represented as cloud storage and act as access controls to verify any transaction from the external requesters (users).

Access control in IoT systems needs to meet the following requirements [5]: decentralization, where the access control should deal with the large-scale and distributed nature of IoT systems; dynamicity, where the access-control scheme should be able to adapt to flexible attributes such as time and location; granularity, where the IoT needs a fine-grained access-control scheme to achieve high dynamicity and accuracy.

Therefore, blockchain technology provides a solution where the access-control policies are built upon it, and the access-control policies are self-enforced by the smart contracts. Furthermore, decentralized access control based on blockchain overcomes the issues of the traditional access control, such as having a single point of failure. In addition, the main issues in blockchain-based schemes are mining process latency in order to validate blocks in the network, such with as Bitcoin and Ethereum, which have a high computation cost. IoT devices, however, are power- and storage-restricted, there are lack-of-scalability and privacy issues when all network members can participate for block validation, and they can analyze transactions. We propose a Hierarchal Blockchain structure solution that provides security and reduces transaction latency and network overhead, while each cluster of IoT devices are managed and authenticated by EBCM, and this clustering technique enhances network scalability. Moreover, the nature of blockchain, like immutability, permits tracing a transactions’ records in a P2P blockchain network, and this feature makes it impossible to compromise these records.

The main contributions of our proposed system are:

• We propose a multi-layer blockchain-based solution for protecting the privacy and security of IoT systems and enhancing system scalability. The solution achieves a light-weight security mechanism by adopting a local private blockchain to meet the IoT requirements;
• Multiple-chaincode-based access control is used to guarantee secure communication with different entities without Trusting Third Parties (TTP);
• We evaluate our solution by conducting a prototype implementation. The results show that our system is more effective and efficient in terms of transaction latency and throughput; we also perform a security analysis of the proposed solution along with other current studies in the literature.

The remainder of this paper is structured as follows. Section 2 presents a literature sources review. Section 3 presents the proposed architecture, the main parts of the system, and a use case. Section 4 presents the simulation analysis and results. Section 5 concludes the paper.

2. Literature Sources Review

This section discusses the technologies that used our proposed solution as a background study and related works based on blockchain solutions for IoT systems.

2.1. Background

In this section, we provide an overview of blockchain, Hyperledger Fabric, and blockchain-based access controls.

2.1.1. Blockchain

Blockchain is a kind of distributed ledger that contains a group of blocks, where each block is linked to the preceding block by referring to the hash value as a chain to ensure data integrity [6]. In order to add a new block, the blockchain must be validated by miners on the P2P network. Blockchain can be categorized [7] as permissionless (public) or permissioned (private), according to authentication and access-control models. In a public blockchain, every user can join the blockchain network and participate in the consensus process to validate transactions as well as to submit a transaction. This type of blockchain suffers from high computation requirements due to a large number of participants in the network and the type of consensus algorithm used, such as Proof of Work (PoW) algorithms, which have computational complexity. However, public blockchains have some limitations, such as a lack of scalability and high computational overheads; therefore, they are not suitable for IoT scenarios. Private blockchains are the inverse of public blockchains. They are permissioned networks, and every peer joining the P2P network should be authenticated by the organization. Private blockchain members are known; therefore, the mining processes are controlled by a particular organization or by selected network participants. In addition, private blockchains use P2P notifications to publish blocks and do not require tokens or fees to handle transactions, as do public blockchains. Moreover, private blockchains have high efficiency and low computational overhead, so they are more applicable to the constrained devices. Blockchain technology plays a significant [8] role in the security of IoT systems because of its distributed and tamper-proof nature. The main characteristics [9] of blockchain technologies are summarized below:

• Decentralization: The nature of the decentralization of the blockchain empowers all the network participants to participate in the approving process of the transactions, in contrast to the centralized systems in which the transaction processes are approved by a single administrator;
• Security: Blockchain technology is immutable, and the records cannot be modified until approved by the majority of the blockchain network members;
• Traceability: Each participant in a blockchain network has the same transactions recorded in the ledger; therefore, it can be audited easily. A timestamp is assigned to each transaction to ensure its traceability;
• Trust: Blockchain network participants rely on the P2P network to interact with each other, rather than relying on third parties to secure transactions.

These are some of the strong points of blockchain technology; additionally, the features of security, decentralization, and immutability, as well as the self-executing nature of blockchain technology makes it a supreme component for becoming a solution for IoT systems.

2.1.2. Hyperledger Fabric

Hyperledger Fabric [10] is a permissioned blockchain platform that provides a modular architecture to enable plug-in features in various components, such as membership services and consensuses. This platform supports chaincode (smart contract), which is used to develop business logic along with blockchain transaction functions. Chaincode can be developed by using different programming languages such as Go and Java. We discuss, briefly, the main parts of Hyperledger Fabric below:

• Peers and clients: Peers are the nodes that make up the Hyperledger Fabric network and host the chaincode and ledger. There are two types of peers: endorsing peers are responsible for identifying and endorsing transactions by checking which node generated them before submitting them to a committing peer. The committing peer is responsible for validating transactions and committing them to the ledger. A client is an entity that can interact with the peers in order to submit transactions. In general, clients are applications created by a Software Development Kit (SDK) or a Command Line Interface (CLI);
• Endorsement policies: Hyperledger Fabric uses endorsement policies that define how many organizations would need to validate transactions to accept other members of the network to store a copy on their ledger. Logic expressions are used to formulate endorsement policies, such as AND (‘Org1.p1’, ‘Org2.p2’), which means that any transaction must be endorsed by both Org1.p1 and Org2.p2;
• Chaincode: The smart contract of the Hyperledger Fabric platform is called a chaincode. It can be defined as a set of programs written in languages such as Go or Java and which controls transactions in the blockchain. We utilize the terms “chaincodes” and “smart contracts” interchangeably. The chaincode allows for interactions with the transactional parties according to the terms and rules defined in the smart contract;
• Channels: In order to achieve data confidentiality and privacy, this platform uses channels that provide an isolated communication scheme to the various organizations of the blockchain network. Furthermore, organizations can join various blockchain networks through multiple channels;
• Ordering Service (Orderer): This is a group of nodes that are responsible for packaging the transactions into blocks and distributing them to the P2P network. In order to commit blocks in the local ledger of each peer, it must be verified by the peers;
• Certificate Authorities (CA): This issues certificates to the network members, such as the nodes and administrators. The certificates are used to identify the components of a particular organization and to sign a transaction. Hyperledger Fabric may contain various organizations, and each organization has many members. Thus, the certificate mapping for members of the organization can be reached through the Membership Service Provider (MSP).

In addition, the Hyperledger Fabric uses dockers to isolate each program application from others, and physical resources that provide it with more security.

2.1.3. Blockchain-Based Access Control

Access control is a security mechanism that protects a resource by filtering who can access it and how it can be accessed, such as giving a specific permission (e.g., read-only). Blockchain-based access-control systems eliminate the dependence on a single administrator to manage access-control policies within IoT systems. This mechanism can store the policies of the access control in the ledger of the blockchain through a smart contract, which enables it to execute automatically to provide access permission or to deny access requests from users. Blockchain technology provides the framework with features such as decentralization, a trustworthy and tamper-proof database to ensure data integrity, and authenticity, verified by the majority of blockchain network members.

In our solution, we use the Attribute-Based Access Control (ABAC) model to define access-control policies by using smart contracts across the blockchain network to execute policies automatically. ABAC [11] is a dynamic and fine-grained access-control approach that adds the contextual information and attributes of subjects and objects to the access-control policies. ABAC manages access to the resource through the evaluation of user request attributes and environmental attributes. Attributes may be defined as the characteristics of a set of entities, such as subjects (users), objects (resources), environments, and permissions.

2.2. Related Work

With the fast-growing nature of IoT devices, a decentralized access-control mechanism has attracted researchers in recent years. Blockchain technology offers many features, such as decentralization and a tamper-proof ledger, to obtain efficient access control in IoT systems.

Ouaddah et al. [12] proposed decentralized access control for IoT frameworks. In order to authorize users in this system, a token, which is defined as a digital signature that allows users to access a target resource based on their address, would be used. This framework uses the blockchain as a database that maintains the access-control policies as a pair (object, subject). In fact, this system offers more advantages to IoT systems, as a result of the application of a blockchain that enforces access-control policies rather than relying on trusted third parties. However, this framework suffers from latency due to continued communication with the owner of the resource to make a new request or cancel a token.

Xue et al. [13] presented an access-control system based on a private blockchain for smart home frameworks. There are three entities in the scheme: the administrator, who manages access-control policies and smart devices and authenticates users; visitors, who are the requesters of the resource and who can access requested data when they receive a token from the administrator; and smart devices, which are data collectors from their surrounding environments in smart homes. In addition, this model keeps all records in the private blockchain to prevent data tampering, so it improves the security and data integrity of smart home devices. However, this model did not use smart contracts to self-enforce access-control policies.

Xu et al. [14] proposed capability access control based on blockchain technology for IoT systems. Their framework includes a domain coordinator, responsible for managing and enforcing policies locally in order to manage their resources, while the cloud manages policies globally. In order for a user to access a resource, a capability token would be generated by the domain coordinator after receiving the user’s request and would be stored on the smart contract as a new token. Services would be provided to the user based on the token extracted from the blockchain by the cloud. Furthermore, this system provides a light-weight and fine-grained decentralized access-control framework for IoT systems. Nevertheless, it has latency in the mining process because of the utilized Ethereum platform.

Novo [15] introduced a distributed blockchain-based access control for IoT systems. The proposed solution includes managers, an agent node, and management hub entities. Managers are able to connect with the smart contract and set the access-control policies in the framework. The agent node is responsible for controlling and deploying the smart contract into the system. Despite the fact that IoT devices are not members of the blockchain, the management hub can request access on behalf of the restricted devices from the blockchain network. In addition, the smart contract will permit the transactions that fulfill the required conditions in the system, and constrained devices will be either granted or denied access based on the results from the smart contract. Although this solution may scale because of the distribution of queries in management hubs, it will have an issue if the manager that controls the smart contract becomes a malicious user.

Huang et al. [16] proposed a decentralized security mechanism based on blockchain for trustworthy IoT data transfers. In this solution, they used three different smart contracts in the management layer. An access contract gives access permission to the IoT data and is based on the CapBAC model. A communication contract is responsible for keeping all transactions among the requester, service provider, and IoT data for traceability, while the responsibility of the auto-exchange contract is to provide the requesters with permission rights to the data after being authorized.

Ali et al. [17] introduced a blockchain-based access-control mechanism for IoT systems. In this context, they used the blockchain and an Inter-Planetary File System (IPFS) to achieve a decentralized access-control mechanism. The consortium network verifies the user’s transactions to prevent unauthorized access to the resource, while the sidechain is responsible for keeping the event logs created by the constrained devices. Although this model protects data privacy, this framework can face latency and create forks in the blockchain due to the use of PoW and Tendermint works alongside Proof of Stake (PoS) consensus mechanisms.

Jo et al. [18] proposed a secure blockchain-based data exchange in the health monitoring systems of the structure. This model has two networks: an edge network, which contains nodes that keep participants’ public keys and access-control policies, and a core network, which verifies newly generated blocks using PoW consensus and self-executing decisions generated by smart contracts. However, this solution has latency issues due to the PoW consensus mechanism for mining the blocks.

Zhang et al. [19] introduced smart contract-based access control for IoT systems. This framework consists of three different contracts: multiple Access-Control Contracts (ACCs), which are responsible for validating both static and dynamic access permissions of the subject; a Judge Contract (JC), which is responsible for judging the misbehaving activities of the subjects; and the Register Contract (RC), which is used to record the system entities as a subject or object. Although this solution achieves reliability, authentication, and authorization by self-executing access-control policies through smart contracts, it suffers from latency issues due to the Ethereum platform, and no stress tests were carried out to evaluate its feasibility.

Dukkipati et al. [20] presented an attribute access control on the blockchain for IoT frameworks. In this system, the policies are stored in an external database while the URL links of the policies are stored in the blockchain. The smart contract verifies the user’s policy and whether it meets the requirements to permit access to the resource. However, this framework is vulnerable to policy-manipulation attacks due to storage policies in external database systems.

Dorri et al. [21,22] presented blockchain-based access control in smart home systems; this solution has three tiers, namely, cloud storage, smart home devices, and an overlay network. Each smart home has a miner, which is a powerful machine able to maintain access-control policies stored in a local private blockchain in order to control access requests from inside or outside of the home. In this context, the concept of a PoW mechanism is eliminated, and all IoT devices within the home are centrally controlled by the miner. As a result, the elimination of the proof-of-work mechanism makes it possible to manipulate the access-control policies.

Maesa et al. [23] proposed an ABAC access model based on Bitcoin. Within this framework, policies can be published to allow access to a resource, and users can transfer access rights to each other. Moreover, the benefit of this solution is that access rights and policies are openly visible to users, and this prevents any party from denying the granted access rights. Although this solution reduces the complexity of blockchain space due to storage policies in an external database, it does not benefit from blockchain technology as a tamper-resistant and available system, and policies are not automatically enforceable because of the lack of a smart contract.

Cruz et al. [24] developed a solution that integrates Role-Based Access Control (RBAC) with blockchain. This framework uses a challenge–response protocol to verify and authenticate users based on their ownership roles. In addition, using a smart contract with RBAC grants trans-organizational access control so users can access a resource from one organization to another depending on their roles. However, this solution is suitable only for smaller organizations.

Albreiki et al. [25] presented a CapBAC access scheme with blockchain to control access to IoT resources. As part of this, they used trusted oracles to interconnect the blockchain network with users and an IoT resource host to ensure secure data access. Nevertheless, this solution was not fully implemented, and the researchers did not conduct a stress test to consider its feasibility.

Uddin et al. [26] introduced a multi-layered underwater IoT monitoring framework that contains three-layers; a perception layer (underwater IoT), an edge layer, and a cloud layer. This solution manages and organizes the sensors in clusters; the Bloom filter is used to track network members (i.e., nodes) by the cluster head. The second layer contains gateways to integrate sensors with the blockchain to solve problems of scalability, transaction preparation, and the routing of data to miners. Finally, the cloud layer has a blockchain that verifies transactions and stores them in the ledger.

An Ethereum-distributed application was indrotuced by [27] to use and control the vehicle’s data by the users. They used IPFS and Ethereum blockchain to protect the vehicle’s data and share it among users through a smart contract with their keys. However, it does not elaborate on user authentication mechanisms.

Fusion Chain [28] is designed to support IoT devices. This solution uses IPFS to overcome blockchain storage problems and uses the PBFT consensus mechanism for block validation. Moreover, it used Public-Key Encryption (PKI) to protect the resource of IoT devices. However, growing the IoT system necessitates a scalable system.

P2B-Trace [29] is designed to protect the privacy of the contact-tracing framework. The authors used blockchain architecture to store authenticated data and they utilized a zero-knowledge proximity verification scheme to provide privacy preservation in the system.

Ali et al. [30] proposed a healthcare framework based on blockchain. They developed a security algorithm for protecting the security and privacy of the system. In addition, a ring signature was used for encrypting and decrypting the data to provide more security. Nevertheless, it lacks fine-grained AC.

VFChain [31] is a blockchain-based federated learning system that provides verifiability audibility. The authors used blockchain to collect models and store verifiable proofs, while the authentication model is used to ensure the committee’s security and improve the efficiency of searching for verifiable proofs.

Joshi et al. [32] designed a data transmission based on blockchain for vehicular networks. The authors used a Rainfall Optimization Algorithm with Blockchain (ROAC-B) technique to ensure privacy for data transmission in the system, but a consensus mechanism is needed to achieve trustworthiness.

Wu et al. [33] introduced the Verifiable Query Layer (VQL) with the cloud to ensure that data queries for blockchain systems are effective and verifiable. This layer collects blockchain data and reorganizes it efficiently in databases. They used a cryptographic fingerprint to prevent the middleware from storing modified data. The miners will verify the fingerprints of the database and then commit them to the blockchain ledger.

3. Proposed Hierarchical Blockchain Architecture-Based Access Control for IoT Systems

The proposed framework is based on hierarchical blockchain-based access control for IoT systems. The proposed solution, as shown in Figure 1, includes multiple layers. First, it contains Edge Blockchain Managers (EBCMs), which include the IoT devices and sub-device clusters. Each cluster of devices is powered with EBCM, which controls all sending and receiving transactions of constrained devices. Second, the AEBCM layer includes Aggregated Edge Blockchain Manager (AEBCM) nodes, which guarantee device communication with different sub-device clusters and manage ABAC policy. Finally, the Cloud Consortium Blockchain Manager (CCBCM) includes CCBCM nodes representing cloud storage and acts as an access control to verify any transaction from the external requesters.

The IoT systems face some challenges such as a lack of privacy, a single point of failure, and the unfeasibility of fine-grained access control over data sharing and continuously growing devices, which require a scalable system. Blockchain technology provides some features, such as decentralization and immutability, to overcome these issues. However, public blockchains such as Bitcoin [6] and Ethereum [34] have cryptocurrencies and high computational consensus mechanisms, such as Proof of Work (PoW) and Proof of Stake (PoS) mechanisms. In addition, any participant can join the public blockchain network and participate in the validation process, which leads to high processing overheads. Therefore, these blockchain platforms are not suitable for IoT systems. In our proposed system, we use a hierarchical permissioned blockchain to protect the security and privacy of IoT systems and provide high throughput, less transaction latency, and good scalability to fulfill the constrained device’s requirements. The main parts of our proposed system are provided in the following sections.

3.1. Main Parts of The System

3.1.1. Edge Blockchain Manager (EBCM)

IoT devices are grouped into sub-device clusters, and each sub-device cluster is controlled by an EBCM as a cluster head. Separating responsibilities in different clusters reduces network overhead, clustering, and cluster head selection performed by using a density-based algorithm [35]. The constrained devices are registered locally and assigned public and private keys to sign their transaction to associate with EBCM. The EBCM authenticates and authorizes IoT devices locally within each sub-device cluster. EBCM maintains keys of sub-device clusters; thus, any transactions from the unauthorized device are dropped by the EBCM. The security and the privacy of each sub-device cluster are maintained by the EBCM, which acts as the sub-device cluster manager. In our system, the responsibilities are separated into different layers to reduce system overhead, overcome privacy issues of the blockchain contents, such as public visibility, and to obtain great scalability. The EBCM is responsible for maintaining the following tasks: authenticating and authorizing devices, securing intra-device cluster communication, creating logs of IoT data that come from authorized devices, and updating the local BC ledger as well as updating the upper-layer BC. The EBCM nodes store any data received from authorized devices that encrypted them using their keys. In addition, the EBCM nodes merge the sub-device clusters into the AEBCM network; therefore, each EBCM node is a powerful machine with large storage space. In our solution, we address the interaction of IoTs with EBCM, while the nature of IoT devices and their distribution network are, by nature, power- and storage-limited. Consequently, a blockchain that has highly computational mining mechanisms, such as PoW consensus, is not suitable for IoT systems; therefore, a light-weight security technique should be applied. In our framework, we used a local private blockchain in each sub-device cluster that enables transaction execution.

3.1.2. Aggregated Edge Blockchain Manager (AEBCM)

In this layer, all EBCMs are connected to form a P2P AEBCMs network, running on a private BC. BC managers enable interactions with different levels through a distributed consensus mechanism. With the various IoT devices across multiple sub-device clusters generating data and exchanging information among them, we need to obtain a single manager that can control all of the devices. The chaincode of private BC, in this layer, has stored the public keys of all authorized devices and their sub-device cluster’s ID. Therefore, the AEBCM authorizes requesters from various sub-device clusters to share data among them. The AEBCMs are responsible for maintaining the following responsibilities: providing secure data exchanges between devices within different sub-device clusters, keeping all authorized credential keys to verify them and, moreover, managing the ABAC policy model in the system. In order to achieve a consensus mechanism in AEBCM, we used the Practical Byzantine Fault Tolerance (PBFT) consensus mechanism due to its high processing transactions with low latency. The PBFT algorithm works with permissioned networks so that all nodes in the network must know each other; therefore, selected nodes in the P2P verify transactions to create blocks in the AEBCM. After the block transaction is validated and created, the AEBCM updates the ledger; then, other peers store the shared ledger when the validation stage is completed. Figure 2 illustrates the deployment architecture of the proposed solution.

3.1.3. Cloud Consortium Blockchain Manager (CCBCM)

This layer consists of distributed aggregated edge nodes to form a consortium cloud network that works as an access-control manager. The CCBCM is responsible for authenticating and authorizing external requesters (users) to access IoT data within a specified sub-device cluster. In addition, the CCBCM will retrieve the corresponding requester’s ABAC policy from the AEBCM to complete the authorization processes. Our solution framework implements blockchain technology that improves data integrity, security, and privacy. Blockchain provides peer-to-peer communication for the various entities of consortium cloud BC managers, and it gives secure communication among them through cryptographical credentials such as certificates and private and public keys. In addition, chaincode-based access control enables the authorization of different entities of this layer to perform secure communication without trusting third parties. Figure 3 indicates the procedure for executing the proposed system and provides further details on each framework component.

3.2. Use Case: Smart Vehicle

Based on a smart vehicle scenario, our proposed solution can be equipped with various IoT devices, such as GPS receivers, radar, smartphones, and cameras, which generate data and communicate with each other to share it. The proposed solution protects the security and privacy of smart vehicles through authentication and authorization to prevent unauthorized access to the resources.

3.2.1. Storing and Accessing IoT Data

The sub-device clusters include smart vehicles with IoT objects that generate IoT data to store in the system; each sub-device cluster is controlled by an EBCM node as a cluster head, which is a powerful machine. A private and public key is assigned to each IoT device of the smart vehicle to communicate with the EBCM, while all device keys are stored in the EBCM node by the smart vehicle’s owner. The EBCM is responsible for authenticating and authorizing each device associated with an EBCM to store or access data. Any vehicle or IoT device in the same cluster network that needs to store or access data in local private blockchain will send, store, and access transactions. The transaction format will be as Equations (1) and (2), respectively.

$${\text{Tr}}_{\text{store}}=\text{Tr-ID}, \text{D-ID}, \text{Per, sig(request, R.prv)},$$

(1)

where Tr-ID is the transaction identifier and D-ID is the device identifier; a sign is the signing process of the message(request). At the same time, R.prv is the private key of the device used to encrypt its data, Per is the permission action, and sig(request, R.prv) is the requester’s digital signature, which is used to verify it.

$${\mathrm{T}\mathrm{r}}_{\mathrm{a}\mathrm{c}\mathrm{c}}=\text{Tr-ID}, \text{Req-ID, D-ID, Per, sign(request, R.prv)}$$

(2)

where Tr_acc is an access transaction, Tr-ID is the identifier of the transaction, Req-ID and D-ID are the requester and resource(device) identifications, respectively, and Per is the permission action. The EBCM verifies the transaction by comparing the hash with the computed hash; therefore, any transaction from an unauthorized IoT device or modified data will be blocked by an EBCM. Figure 4 shows the signing and verification processes by the users and BC managers.

EBCMs are responsible for storing smart vehicles with their IoT data and securing all communications among constrained devices, while an AEBCM provides secure data exchange with various devices within different sub-device clusters. For example, if a device needs to access another device with a different sub-device cluster, it will send a transaction, as shown in Equation (3):

$${\mathrm{T}\mathrm{r}}_{\mathrm{a}\mathrm{c}\mathrm{c}}=\text{Tr-ID}, \text{Req-ID, Cl-ID, D-ID, Per, sign(request, R.prv)}.$$

(3)

The EBCM maintains the credential keys of authorized IoT objects locally; thus, this process blocks any attack from unauthorized devices into the EBCM nodes. Once the IoT data are received by the EBCM node, it verifies and stores transactions into local BC and forwards them to the upper layers for updating. To access IoT data within the sub-device cluster, each device sends an access request to the EBCM, which validates and grants access; if the device in the sub-cluster needs to access another sub-cluster’s device, then the EBCM forwards the access request to the AEBCM to verify it and grant a response to the requester. The details of EBCM validation processes are shown in Algorithm 1.

On the other hand, if the external requester (user) needs to access the data of the vehicle, the requester sends an access request by signing with their private key. The requester’s public key and their access rights are stored in the BC managers. At this point, the CCBCM authenticates the requester by comparing the hash file with the computed hash file, as shown in Figure 4; if it is authenticated successfully, the CCBCM retrieves the ABAC policy corresponding to the requester to authorize it. If the access request is authenticated and authorized successfully, the CCBCM returns a response to the user; the CCBCM validation processes are presented in Algorithm 2.

Algorithm 1 EBCM

Require: AccessRequest, Signature

Ensure: Store/Resource, Denied

1: Let AccessRequest = R.pub, Cl-ID, D-ID 2: for each AccessRequest in CCBCM, AEBCM, EBCM do 3:     Requester submits AccessRequest with his Signature to EBCM 4:     EBCM verifies Requester based on his AccessRequest and Signature 5:     if Requester is an authenticated Requester then 6:         if AccessRequest type is store then 7:            EBCM checks AccessRequest 8:            EBCM stores it and updates AEBCM 9:         end if 10:         if AccessRequest type is access then 11:            EBCM checks AccessRequest 12:            EBCM returns response 13:         else 14:            EBCM forwards AccessRequest to AEBCM 15:            AEBCM check AccessRequest 16:            AEBCM return response to requester 17:         end if 18:     else 19:         Denied 20:     end if 21: end for

Algorithm 2 CCBCM

Require: AccessRequest, Signature

Ensure: Resource, Access-denied

1: Let AccessRequest = R.pub, Cl-ID, D-ID 2: for each AccessRequest in CCBCM, AEBCM, EBCM do 3:     User submits AccessRequest with his Signature to CCBCM 4:     CCBCM authenticates user based on his AccessRequest and Signature 5:     if user is an authenticated user then 6:         CCBCM forwards AccessRequest to AEBCM 7:         AEBCM verifies AccessRequest 8:         AEBCM assigns AccessRequest with ABAC policy 9:         AEBCM return assigned ABAC policy to CCBCM 10:         CCBCM authorize AccessRequest based on ABAC policy. 11:         CCBCM return response to user. 12:     else 13:         Access-denied 14:     end if 15: end for

3.2.2. Smart Contract and Transaction Processing

The term “smart contract” [36] was first proposed by Nick Szabo. It is defined as a set of protocols and promises that enable contracts to be executed to build secure relationships on networks. Smart contracts have contractual clauses that execute automatically when the required information is met. The benefits of smart contracts for blockchain systems are to provide trustworthy and efficient policy self-execution. We used different smart contracts in the various layers of the proposed system. For example, the chaincode of edge BC layers store IoT devices’ information and their access-control rules, such as device IDs, cluster IDs, timestamps, and their access rights. In addition, transaction operations such as access-control rules are defined in the chaincode as functions. This chaincode stores IoT transactions in the ledger of the local private blockchain. It also provides Application Binary Interfaces (ABIs) for interacting with the blockchain for managing resources such as updating or querying the ledger. In addition, ABAC policy management is defined in an aggregated edge BC layer. Finally, the chaincode in consortium BC is responsible for verifying whether external requesters (users) meet the required conditions to execute their transactions.

3.2.3. Attribute-Based AC Model

The ABAC model is a type of access-control mechanism that operates under access policies and attributes. The ABAC [11] model is based on the attributes of the subject(user), object(resource), environments, and permissions. This model enables updating the policies based on the state situation to add or remove some attributes of the ABAC entities. In addition, it can handle control of a massive number of subjects and objects regardless of specifying each entity’s relationship to another. The ABAC policy can be defined as a combination of various attributes of the user (subject), resource (object), permission, and environment. For example, a subject attribute describes the user attributes such as requester ID, role, and its membership in the system, while the object attributes define the resource (object) attributes such as device ID, cluster ID, and MAC address. In addition, environmental attributes contain the time that describes the start and end time to access a specific resource; thus, the user’s access right should be revoked after access time ends. Finally, the permission attribute describes actions such as “allow”, which enables users to access the resource, and “deny”, which rejects the performance of any transactions.

4. Simulation Analysis and Results

4.1. Development Environment

We performed the simulations on an Ubuntu Linux 20.4 LTS with Intel(R) Core(TM) i710510U CPU @ 1.80GHz, 2.30 GHz, and 8 GB RAM. We used Hyperledger Fabric (v1.4.4) as the permissioned blockchain platform. Hyperledger Fabric is an open-source system developed by the Linux Foundation. In addition, we used the docker engine (v19.03.8, build afacb8b7f0) to give the runtime for dockers and docker-compose (1.25.0) to provide containerized and docker image configuration in the virtual system. Node (v10.24.0) was utilized for developing clients. We used the Golang language to develop our smart contracts, so we installed version go1.16.2. In our proposed system, we can invoke smart contract functions by using clients developed by the node (SDK). The Hyperledger Fabric network was initialized and deployed to create certificates and secret keys for participants by using cryptogenic tools. The certificates and secret keys were stored on the client’s wallet. Clients can reach out to peer nodes to invoke or query a transaction after execution. Finally, the peer nodes updated the ledger after being validated by consensus mechanisms.

4.2. Performance Evaluation

We evaluated the performance of the proposed framework by utilizing Hyperledger Caliper [37], which is an open-source blockchain-performance benchmarking tool that allows users to configure and test various blockchain systems and obtain results of the performance testing. Hyperledger performance [38] is reached through testing throughput and latency. Therefore, we calculated performance metrics, such as transaction latency and throughput within our proposed system, to conduct a performance analysis. Additionally, in this simulation environment, we used two performance metrics, namely, latency and throughput. Read latency is the time it takes to provide replies when the read request is submitted, as described in Equation (4). The read throughput is a measurement of the number of read operations performed in a defined time period, and it is expressed as Reads Per Second (RPS), as shown in Equation (5), where R_lat is the read latency, T_res is the time when a response is received and T_sub is the submit time of the transaction.

$$\mathrm{Read} \mathrm{latency} {\mathrm{R}}_{\mathrm{l}\mathrm{a}\mathrm{t}}={\mathrm{T}}_{\mathrm{r}\mathrm{e}\mathrm{s}}-{\mathrm{T}}_{\mathrm{s}\mathrm{u}\mathrm{b}}$$

(4)

$$\mathrm{Read} \mathrm{throughput} {\mathrm{R}}_{\mathrm{t}\mathrm{h}}={\mathrm{R}}_{\mathrm{t}\mathrm{o}\mathrm{t}}/{\mathrm{T}}_{\mathrm{t}\mathrm{o}\mathrm{t}}$$

(5)

where R_th is the read throughput, R_tot is the total read operations, and T_tot is the total time in seconds. In our system, we assess the processing ability of transactions by invoking and querying the chaincodes. In addition, Transaction Latency is a network-wide view of how long it takes for the effect of a transaction to be available across the network, as illustrated in Equation (6). The transaction throughput is defined as the rate that the validated transactions are committed by the blockchain network in a defined period of time. It is stated as Transactions Per Second (TPS) in the blockchain network size, as shown in Equation (7), whereas Tr_lat is the Transaction Latency, T_con stands for confirmation time, and N_tr is the network threshold.

$$\mathrm{Transaction} \mathrm{latency} {\mathrm{T}\mathrm{r}}_{\mathrm{l}\mathrm{a}\mathrm{t}}=({\mathrm{T}}_{\mathrm{c}\mathrm{o}\mathrm{n}}\ast {\mathrm{T}}_{\mathrm{t}\mathrm{r}})-{\mathrm{T}}_{\mathrm{s}\mathrm{u}\mathrm{b}}$$

(6)

$$\mathrm{Transaction} \mathrm{throughput} {\mathrm{T}\mathrm{r}}_{\mathrm{t}\mathrm{h}}={\mathrm{T}\mathrm{r}}_{\mathrm{c}\mathrm{o}\mathrm{m}}/{\mathrm{T}}_{\mathrm{t}\mathrm{o}\mathrm{t}}\ast {\mathrm{N}}_{\mathrm{c}\mathrm{o}\mathrm{m}}$$

(7)

where Tr_th is the transaction throughput, Tr_com is the total transactions that are committed, T_tot is the total time in seconds, and N_com is the number of committed nodes.

4.2.1. Performance Analysis Based on Send Rates

In this experiment, different send rates were used to test the throughput and latency of the proposed solution. In our experimental test, we did ten rounds of each method of invoke and query transactions with various send rates, from 25 tps to 150 tps, to monitor the effect of send rates on the network latency and throughput. To minimize the possibility of errors, several rounds of tests were performed.

In Figure 5, the evaluation results of the invoke transaction in the chaincode show that the throughput increases as the send rate increases until it reaches the limit point, which is 100 tps. After the limit point, when the sending rate is increased, then the rate of the throughput growth is significantly reduced. However, the query transaction in the chaincode indicates that the throughput increases linearly as the send rate increases; this means that the query transaction only performs read jobs on the blockchain ledger, while invoking the transaction method updates the ledger, which needs additional computing tasks such as verification and validation before committing it.

Figure 6 shows that the latency of the query method in chaincode is good since it maintains a high throughput, whereas the latency of the invoked transaction method increases linearly as the sending rate increases. However, because of the limited environment, we simulated our system with 100 tps, which affects transaction latency. However, if our solution is deployed into the real-world system as the production environment, then the limit point is greater than 2000 tps; this will have a clear effect on the latency performance, as both throughput and latency are inversely proportional.

4.2.2. Performance Analysis Based on User Groups

In this study, three groups of 2000, 4000, and 6000 users were used. The time taken by the proposed solution to complete a transaction will count as the maximum, minimum, and average time. Figure 7 describes the minimum, average, and maximum transaction latency of the invoke-execution method with user groups of 2000, 4000, and 6000 users. For the 2000-user group, the minimum latency is 107 ms, the averaging time is 269 ms, while the maximum latency is 461 ms. For the 4000-user group, the minimum latency is 116 ms, the average latency is 295 ms, and the maximum latency time is 490 ms. Finally, for the 6000-user group, the minimum latency is 156, the average latency time is 327 ms, and the maximum latency time is 532 ms. The graph shows a small change in latency time with growing users, but it does not greatly affect system performance.

Figure 8 shows a bar chart representing three different user groups. It shows the latency of the execution query method. The minimum, average, and maximum latency time for the 2000-user group is 10 ms, 39 ms, and 94 ms, respectively. For the 4000-user group, the minimum latency is 10 ms, averaging time is 37 ms, and the maximum latency time is 96 ms. Lastly, the minimum, average, and maximum latency time of the 6000-user group is 10 ms, 36 ms, and 86 ms, respectively.

Figure 7 and Figure 8 show the response time of storing and querying the resources of the chaincode. The chart shows that the invoked transactions have a higher latency than the query transactions because the invoking methods need endorsement policy verification by the peers of the blockchain network.

4.3. Comparative and Significance Analysis

In this section, we present the comparison of existing work to our proposed system by conducting a critical review of the related work. Our proposed system uses smart contract-based access control to self-execute policy without Trusting Third Parties (TTP), and it does not require cryptocurrency to perform transactions. In contrast, most existing systems are based on permissionless blockchain, which allows everyone to join the P2P network and participate in the mining process. These systems use token-based access control to overcome the lack of confidentiality, and this technique causes high transaction latency and more power consumption due to the costly mining process, and also it is fueling the execution of the smart contracts. In addition, to protect policies of AC from manipulations, we used on-chain policy management that benefits from blockchain technology’s features like immutability and integrity. In contrast, storing policies on external servers can cause policy manipulation and untrustworthiness of the access control. Our proposed solution uses a local private blockchain to provide privacy protection for each cluster and also uses hashing function to provide data integrity. The proposed framework uses a lightweight consensus mechanism to avoid high computational mining processes like the PoW, which is not suitable for constrained devices.

Table 1. Comparison of some blockchain-based access-control schemes with the proposed framework.

References	Auto-Policy Enforcement	On-Chain Policy Management	Security	Fee-less	Privacy Protection	Trustworthy (without TTP)	Scalability
Maesa et al. [23]	No	No	Yes	No	No	Yes	No
Novo [15]	Yes	Yes	Yes	No	Yes	Yes	Yes
Ouaddah et al. [12]	No	Yes	Yes	No	Yes	Yes	No
Dukkipati et al. [20]	Yes	No	Yes	Yes	Yes	No	No
Uddin et al. [26]	No	Yes	Yes	No	Yes	Yes	Yes
Ali et al. [17]	Yes	Yes	Yes	No	Yes	Yes	Yes
Dorri [22]	No	Yes	Yes	Yes	Yes	Yes	Yes
Proposed system	Yes	Yes	Yes	Yes	Yes	Yes	Yes

shows a comparison table of existing related work with our proposed solution; the comparison is done in terms of auto-policy enforcement, on-chain policy management, security, fee-less, privacy protection, trustworthy, and scalability.

In addition, we show the efficiency of the proposed solution by conducting a performance evaluation with other references, as shown in Figure 9. The total overhead processing time includes the latency time of the submission, validation, and verification of a new transaction in the P2P blockchain network. In this viewpoint, the processing time shows the performance of the proposed solution. Our proposed framework is compared to Dorri [22] and Bitcoin-PoW [22]. For performance, we used the same environmental simulation parameters with the platforms in Dorri [22] and Bitcoin-PoW [22]. In the simulation, we ran a 50-peer network in 60 s, and 960 transactions were executed within the time interval. In addition, the block sizes ranged from 10 to 60, as depicted in the performance chart. As shown in Figure 9, the proposed solution achieves better performance while reducing the processing time of overhead costs for block validation compared to other references.

4.4. Security Analysis

We provide a security and privacy analysis of the proposed framework. The major security requirements for any system are Confidentiality, Integrity, and Availability (CIA) [39]:

• Confidentiality means only authorized users are allowed to access a resource. In our framework, communication between subjects and objects is protected by public key encryption;
• A system with integrity protects the data against modification by unauthorized users. In our architecture, the system inherits the tamper-proof feature from blockchain technology. Consequently, all transactions in the system persist and cannot be modified by an unauthorized entity. The hash function guarantees data integrity, and each blockchain’s blocks include the hash value of the preceding block. Therefore, any change in data integrity through the verification process is easily detectable;
• Availability ensures that the data or service is made available for authenticated entities. In our system, every identity is approved and verified. In addition, our framework prevents any identity from exhibiting malicious behavior by dropping their transaction, because our system is based on the permissioned blockchain, which means that all members of the network are known. Furthermore, the blockchain replication feature ensures availability while each node of the blockchain has kept a copy of the ledger and is synchronized by replication.

In addition, some attacks, such as Denial of Service (DoS) and Distributed Denial of Service (DDoS) are discussed here. In classical access controls, transaction validation is dependent on central management, which has some limitations, including a single point of failure and a performance bottleneck if targeted by malicious attacks such as DOS and DDoS attacks. Our proposed solution can mitigate DoS and DDoS attacks. For example, if an attacker compromises a user and sends an access request for a resource to the P2P blockchain network, users are authenticated before authorization; therefore, each transaction is verified by comparing the requester’s public key with the key stored in the system, so that the system can easily detect and drop malicious transactions.

5. Conclusions

The key challenges of traditional access control for IoT systems are a single point of failure, a lack of confidentiality, and poor adaptation for large IoT devices. In this paper, we presented an effective solution to protect the security and privacy of IoT systems. Our solution is based on a multi-layered blockchain to enhance security and scalability and to reduce overhead processing and transaction latency. We used various BC managers, such as EBCM, AEBCM, and CCBCM, to secure the IoT system through authentication and authorization. To securely store or access data, devices are authenticated via EBCM within the cluster, making our solution sufficiently resistant to vulnerability attacks to obtain unauthorized access. The proposed solution was deployed on the Hyperledger Fabric. In addition, a multi-chaincode was used to self-enforce policies and to achieve decentralized AC policies. Hyperledger Caliper was used to measure the performance of the proposed solution in terms of various metrics, such as throughput and transaction latency. The performance evaluation results demonstrated a steady level, allowing the transaction to be executed efficiently. The solution’s framework is currently based on software simulations as a proof of concept. In the future, we will deploy our solution on a real-world system. In addition, we will use machine learning algorithms that scan data for different models in order to form certain general data rules that reduce the latency of the data collection and improve the performance of blockchain networks by overcoming network congestion.