A Blockchain-Based and SGX-Enabled Access Control Framework for IoT

Abstract

With the rapid development of physical networks, tens of billions of Internet of Things (IoT) devices have been deployed worldwide. Access control is essential in the IoT system, which manages user access to vital IoT data. However, access control for the IoT is mainly based on centralized trusted servers, which face problems such as a single point of failure and data leakage. To tackle these challenges, we propose an access control framework for the IoT by combining blockchain and Intel software guard extension (SGX) technology. A blockchain validates both IoT devices and edge servers added to the network. The access control contract is deployed on the blockchain, which can manage attribute-based access control policies in a fine-grained manner and make access control decisions flexibly. SGX technology is introduced into the edge computing server to realize the confidentiality of data processing. Finally, we implemented the prototype of the framework on Quorum and conducted extensive experiments and theoretical analyses on the performance of the blockchain. The results of the experimental tests and theoretical analyses show that our framework has more advantages in computing costs and on-chain storage costs.

1. Introduction

With the rapid development of modern information technology, the Internet of Things (IoT) technology has brought significant digital changes to all levels of society. It is profoundly changing the traditional industrial form and human production and lifestyle. The Internet of Things is widely used in sensor networks, healthcare systems, smart cities, transportation, smart industries, communication systems, and manufacturing [1]. Statista [2] states that the number of Internet of Things connected devices worldwide will be 19.1 billion by 2025. Additionally, forecasts suggest that by 2030 approximately 29.4 billion of these IoT devices will be in use worldwide, creating a massive web of interconnected devices spanning everything from smartphones to kitchen appliances. IoT significant data statistics [3] show that, with increased adoption, devices will generate exponentially more data globally in the following years. The numbers will reach 73.1 ZB by 2025, which equals 422% of the 2019 output when 17.3 ZB of data was produced. The increase in IoT devices will inevitably generate user data.

Such colossal data computing overhead is unacceptable for computing-resource constrained IoT devices. Suppose users access many IoT devices simultaneously in a short time. In that case, a large amount of data will be uploaded to the cloud data center server, inevitably leading to network delay. Therefore, to alleviate the pressure on data center servers, the Internet of Things architecture introduces edge computing [4] close to the data source as an extension of the cloud computing center to alleviate network and storage pressure on the cloud data center. Edge computing (EC) uses the edge zone close to the data source to provide network services and computing power closer to the client, which should improve data processing efficiency and reduce service response delay.

However, edge computing in the Internet of Things architecture will face huge data security problems. The data collected and processed by the edge server is closely related to user privacy, and the security of data is related to the immediate interests of users. The first problem is how to prevent malicious edge nodes from illegally obtaining sensitive data of users. In 2020, Amazon’s IoT devices, including the Ring doorbell and Home security camera, were exposed to hacker intrusion [5], resulting in the disclosure of dozens of people’s privacy. The attacker intercepted the username and password through the unencrypted HTTP protocol of the local user network, thus gaining access to the IoT devices. The second problem is that the security protection of edge nodes is weaker than that of cloud computing centers, which puts user data in edge nodes at risk of malicious tampering [6], which is unacceptable for data related to medical care. According to the data of Cynerio in its 2022 report [7] on the security status of Internet of Things devices in health care, 53% of hospital networked medical devices and other IoT devices have known severe vulnerabilities. In addition, one-third of the bedside healthcare IoT devices on which patients rely most for optimal health outcomes have identified severe risks. If attacked, these vulnerabilities may affect service availability, data confidentiality, or patient security with potentially life-threatening consequences for patient care.

As malicious users often abuse rules to gain unauthorized access to IoT devices, there is an urgent need for a credible IoT access control framework to prevent such behavior. The public have gradually learned about blockchain technology with the rise of non-fungible tokens (NFT) and the encrypted digital currency industry in recent years. Blockchain [8] is a distributed storage technology. A trust relationship can be established in a decentralized network environment through a peer-to-peer (P2P) network, consensus mechanism, and encryption algorithm, ensuring the integrity of data on the chain and providing a new access control solution. Trusted computing technology, represented by intel software guard extensions (SGX) technology [9], can execute applications in an isolated environment using secure hardware. It provides a new way to solve the problem of malicious disclosure or tampering with user privacy data through untrusted edge nodes. Intel SGX technology provides hardware-level memory isolation and remote security attestation, allowing applications to open a trusted execution area, known as an enclave in memory. Malicious software, privileged software, and even the operating system on the same platform cannot be accessed without authorization, thus preventing data leakage and malicious tampering within the enclave.

To solve the issues of malicious access and tampering of private user data resources in the mentioned IoT environment, we propose an improved fine-grained access control framework for the Internet of Things based on blockchain and SGX technology, which has three main innovations:

• The performance of the existing public blockchain cannot meet the massive terminal nodes of the Internet of Things; to solve this issue, we designed a blockchain framework of the permissioned blockchain on Quorum, based on the Ethereum protocol, to break the practical bottleneck. The framework saved the valuable storage space of the blockchain by distributing attribute signatures for clients off the chain. Specifically, it dramatically improves data-carrying capacity and transmission efficiency.
• We have designed an attribute-based access control contract to manage the access control strategy of IoT data resources in a fine-grained manner. It can effectively complete the process of client access verification on the blockchain. At the same time, the on-chain access control policy can be updated dynamically. We use a set of attributes to describe the client’s identity and grant it access through an off-chain attribute signature distribution mechanism. Therefore, our control access framework decouples access policy on the blockchain from client identity, which is more flexible than previous work [10,11].
• In data processing and the transmission of edge nodes, we use the Enclave security zone provided by Intel SGX as a trusted execution environment to process sensitive data. We use the remote attestation mechanism provided by Intel SGX to build a secure communication channel from the edge server to the client to ensure the credibility of data in the remote processing process and the security of the transmission process.
• We implemented a prototype of the proposed framework on Quorum. We conducted many experiments and compared them with previous work. Finally, we demonstrated the superiority of the proposed scheme with excellent performance data.

The rest of this article is organized as follows. Section 2 introduces the related technologies of blockchain, SGX, and access control. In Section 3, we discuss the related work of predecessors. In Section 4, we first introduce the system architecture of the proposed framework and then present our scheme in detail from two aspects of the access control process and the trusted data processing process. We completed the experimental verification in Section 5 and compared it with similar work to show the superiority of our scheme. Section 6 discusses the advantages and limitations of the framework. Finally, in Section 7, we summarize the framework of this article and discuss the direction of future research.

2. Related Technologies

2.1. Quorum and Smart Contract

Satoshi Nakamoto first proposed blockchain technology in his article [8] published in 2008. It is a decentralized, distributed data ledger linked by digital blocks in chronological order. Inspired by bitcoin, Buterin put forward the concept of Ethereum [12] in 2013, which is widely known as blockchain 2.0. The most prominent feature of Ethereum is that it adds support for smart contracts. Ethereum is popular as it establishes a Turing complete platform that allows developers to write arbitrary smart contracts and decentralized applications (DApps).

Quorum [13] is a branch of the Go language implementation version of Ethereum, developed by JPMorgan Chase Company, which reuses and extends some features of Ethereum. Quorum is an enterprise blockchain platform and a permissioned chain supporting privacy transactions. It supports confidentiality and privacy of transactions as well as PBFT consensus algorithms. Quorum is suitable for application scenarios that require high-speed transactions and high throughput to handle private transactions.

In an ideal state, the smart contract can be regarded as a Turing machine, a piece of program code that can be automatically executed according to the preset rules. Smart contracts can be developed and programmed in high-level languages such as Solidity, Serpent, Vyper, etc. Smart contracts for Ethereum are often written in Solidity. The compilation, interpretation, and execution of smart contracts are completed through the 256-bit Ethereum virtual machine (EVM) [14] installed on each Ethereum node. The EVM compiles the contract into byte code and deploys it in the blockchain. A successfully deployed smart contract is treated as an account, and the contract is executed similarly to a user sending a transaction to the account. All Ethereum nodes can execute deployed smart contracts through EVM. When the trigger conditions of the contract are met, predefined code logic can be independently executed. The execution results cannot be changed in the chain after validation by other nodes.

2.2. Intel SGX

In 2013, the Intel corporation published three papers [9,15,16] on processor security in SGX technology, introducing the design framework, technical route, and security features of SGX. SGX is an extension of the Intel Architecture (IA) to enhance software security by allowing an application code to be executed in a secure operating environment called an enclave. The SGX technology has two main mechanisms: isolated execution [15] and SGX attestation [16].

2.2.1. Isolated Execution

The isolation execution mechanism of SGX technology is shown in Figure 1. An enclave is similar to a protected memory container, which stores the code, data, and important data related to the application. These contents are encrypted and stored in the memory during operation. Programs not hosted in the enclave are not allowed to access the enclave’s memory area, including privileged programs such as virtual machine monitors, BIOS, and operating systems. The operating system has an enclave page cache (EPC) [17] memory space that can hold enclave and SGX data structures.

2.2.2. SGX Attestation

SGX attestation is a process used to prove that an application has been correctly instantiated on the enclave platform. There are two ways to do this. One way is local attestation, that is, attestation between two different enclaves on the same platform; and the other is remote attestation, that is, attestation between two enclaves on various platforms.

In Figure 2, enclave B must prove its identity to other enclaves on the platform for local attestation. In this case, Enclave B requires the hardware to generate a credential, also known as a REPORT. The REPORT contains the following data: the identity of Enclave B, the attributes related to Enclave B, the reliability of the hardware trusted computing base (TCB), the additional information that the Enclave B authenticator wants to deliver to the target Enclave A, and the message authentication code (MAC) tag. When the target REPORT structure is generated, Enclave B will request the REPORT identity and will pass the report to the final target Enclave A. The target Enclave A will then verify Enclave B, and will request attestation to determine whether it is on the same platform.

The remote attestation mechanism is an extension of the local attestation mechanism, but local attestation uses symmetric keys, while remote attestation uses asymmetric keys. In remote attestation, because the key to the processor needs to be accessed during the attestation process, the quoting enclave is used. In Figure 3, supposea remote attestation process where the authenticator, Enclave C, authenticates Enclave D. First, Enclave D needs to generate the REPORT hardware credentials, and the MAC is generated using the quoting enclave (Q) reporting key. Then package the above and additional information to Q. The quoting enclave can verify whether Enclave D works on this platform through the above content. Suppose Enclave D is determined to be on the same platform as itself. In that case, Q will pack the received content into a reference structure QUOTE, sign the QUOTE, and send it to Enclave C. Enclave C first verifies the correctness of the signature. It then uses QUOTE to conduct remote attestation after verification.

2.3. Access Control

Access control [18] is a security protection technology that aims to prevent unauthorized users from accessing resources with limited operation permissions. It also prevents authorized users from performing operations that are not within the scope of authorization. System administrators use access control to control user access to network resources, such as servers, directories, and files. The basic concepts involved in access control include subject, object, and operation. A subject is a user requesting access to a resource to act. The object refers to the resources the subject requests to access, including files, applications, servers, APIs, etc. The operation refers to the action that the subject wants to perform on the object. Typical operations include read, write, execute, modify, copy, and delete.

Role-based access control (RBAC) [19] is control through access to roles. By becoming a member of the appropriate role, the subject obtains the rights of its role and associates its access rights with the role. Attribute-based access control (ABAC) [20] generates policy decisions according to subject and object attributes, operation, and environment to control the access of objects to resources. Object-based access control (OBAC), from the point of view of the managed object, directly associates the subject’s access rights with the controlled object and regulates the object’s access by defining the access control list (ACL) of the object.

3. Related Work

In recent years, because many IoT devices are connected to the internet, a large amount of data are uploaded to the data center in a short time, resulting in inevitable network delays. Edge computing provides a solution to solve the problem of high latency in the mass data transmission of Internet of Things devices. Yang et al. [21] put forward a trusted edge computing framework suitable for the power of the Internet of Things, aimed at real-time and security-functional requirements of the power of the Internet of Things system. Li et al. [22] proposed an adaptive transmission architecture for the industrial Internet of Things scenario. This architecture combined software defined networks (SDN) and edge computing (EC) technologies to design an optimal routing algorithm for data streams. Their scheme improved the network performance of data exchange between intelligent industrial devices. The limited device capacity of the Internet of Things also affects service performance. Chen et al. [23] proposed an energy-saving dynamic unloading algorithm. They combined their algorithm with mobile edge computing to reduce the energy consumed during the transmission and processing of computing tasks. The above work applies edge computing to specific IoT scenarios and puts forward optimized solutions to meet the performance requirements of processing increasing IoT device data. All of the schemes above are based on the notion that edge nodes are trusted. However, edge nodes will face attacks and threats from all sides in today’s complex and changeable network space. When edge servers are not trusted, private user data may be leaked.

Data access control is the key to ensuring the data security of the Internet of Things. Due to the data security requirements of the Internet of Things, some researchers have optimized and adjusted the traditional access control framework [24,25,26]. Xu et al. [24] proposed an access control framework suitable for lightweight and resource-limited devices for the Internet of Medical Things scenario. It combined attribute-based encryption, cloud computing, and edge computing technologies to reduce data communication overhead and network delay. Alkhresheh et al. [25] proposed an attribute-based dynamic access control framework in the IoT to improve the adaptability of access policies to the active IoT environment. However, all the above work is based on centralized authorization to realize authorized access, that is, authorization through the central server. This authorization process lacks transparency, and there are problems with user data security and a single point of failure.

In recent years, the advantages of blockchain technology, such as decentralization, immutability, transparency, and consensus, have attracted the attention of many researchers. At present, the era of blockchain 2.0 is the era of smart contract development and application, represented by Ethereum. It claims that blockchain technology can be applied to all aspects of society, from the financial field, to establishing trust relationships between individuals, and realizing data sharing without the intervention of centralized third-party organizations. As an emerging technology with great potential, blockchain technology provides a programmable application development environment for smart contracts. Most existing blockchain applications are programmed using smart contracts. Many studies have applied blockchain technology to traditional services to ensure that the service process is implemented correctly according to agreed specifications under transparent and open conditions. Mahmood et al. [27] proposed a security model that uses federated learning and supports blockchain. This model utilizes Ethereum’s incentive mechanism and the proof-of-work (PoW) consensus algorithm to promote cooperation between decentralized nodes. Han et al. [28] implemented a framework for searchable encryption on Ethereum. This framework manipulated the access control and searchable encryption process through smart contracts, significantly reducing the communication overhead. Barenji et al. [29] proposed a blockchain resource and asset sharing platform based on hyperledger fabric and edge computing. Moreover, they implemented the proof-of-delivery (PoD) mechanism based on smart contracts, which proved the feasibility of the scheme through experiments.

Therefore, in recent years, some scholars have turned to studying the decentralized access control framework in the Internet of Things. Most studies [10,11,30,31,32,33,34] combined blockchain technology with access control. Ouaddah et al. [30] proposed a decentralized authorization management framework called FairAccess, which introduced the token concept. They specified the output address of the transaction and stored the access rights on the blockchain in the form of a bitcoin script. However, Bitcoin’s PoW consensus algorithm will lead to highly inefficient transaction throughput, which does not apply to the IoT system. Ding et al. [31], Alansari et al. [32], and Damiano et al. [33] combined blockchain with attribute-based access control technology (ABAC). Moreover, they used blockchain to record attribute information but did not consider the diversity of resources in the IoT. Li et al. [34] proposed a double-layer blockchain IoT access control framework on Ethereum and Fisco. They used the linear secret sharing scheme to achieve a fine-grained access strategy. Still, the increase in the number of attributes will lead to a large amount of gas overhead on the blockchain. Therefore, the scalability of the framework proposed by this study will be severely limited. Zhang et al. [10] designed an ACL-based access control framework for the IoT based on the smart contract of Ethereum, in which each subject and object are assigned corresponding ACLs to achieve access control. However, in large-scale IoT, the storage overhead on the chain will increase linearly with the number of clients, and the scalability will be greatly limited. Yutaka et al. [11] designed ABAC’s access control framework based on the smart contract of Ethereum. They used multiple contracts to store, manage, and make decisions regarding the attributes and policy information of subjects and objects. When receiving an access request, the contract retrieved related subject and object attributes and policy information. Then contract executed the access decision and output the decision result. As the client’s attributes also need to be stored in the blockchain, this also causes the problem of high on-chain storage overhead in large-scale networks.

The storage space in the blockchain is valuable. Therefore, in most studies combining blockchain with access control, the blockchain is mainly used to record some metadata, and the original data are stored under the chain. The security of users is primarily ensured by traditional encryption technology. However, performing complex encryption and decryption operations on the blockchain will take up a lot of valuable computing resources.

In recent years, Intel SGX hardware technology has attracted the attention of researchers because of its security and high efficiency. Park et al. [35] proposed a key management framework combined with SGX in the Internet of Things environment, ensuring key management security for data access control. Gao et al. [36] introduced SGX technology into edge computing for the access control scenario of the Internet of Medical Things resources. Their scheme ran the data analysis process in the enclave to ensure the confidentiality of the data analysis process. Ayoade et al. [37] combined SGX technology to achieve data security processing in the IoT Middleware system. The system supported users in implementing data access policy control in the enclave. Moreover, their scheme ensured that computations of even untrusted systems were performed through a remote-proof mechanism.

For the above work related to IoT access control, we summarized the characteristics of some representative studies in

Table 1. Comparison of Internet of Things access control schemes.

Schemes	Basic Framework	Enable Blockchain	Enable SGX	Decision Maker
Xu [24]	ABAC	NO	NO	Edge Server
Zhang [10]	ACL	YES (Ethereum)	NO	Smart contract
Yutaka [11]	ABAC	YES (Ethereum)	NO	Smart contract
Gao [36]	ACL	YES (Hyperledger Fabric)	YES	Edge Server
Ours	ABAC	YES(Quorum)	YES	Smart contract

.

In this article, using attribute-based access control, blockchain, and SGX technologies, we propose an extensible and fine-grained access control framework for trusted Internet of Things. Specifically, on the one hand, we have designed an attribute-based access control contract on Quorum, a permissioned chain of Ethereum, which can perform a fine-grained access control process on the chain. Moreover, the access policies on the chain can be updated as needed. On the other hand, SGX technology makes up for the lack of security in the computing process of edge nodes. It handles the original data safely and credibly in an isolated environment, thus ensuring the confidentiality and security of the original data.

4. Design and Implementation

4.1. System Framework

As shown in Figure 4, the IoT access control framework proposed in this paper mainly includes six components: Quorum blockchain, IoT device, inter-planetary file system (IPFS) storage layer, trusted edge computing layer, data owner, and client.

Quorum blockchain: As a foundation for the rest of the framework, the blockchain alliance network consists of edge nodes, IoT device nodes, and clients. Data owners deploy smart contracts on blockchain networks. The contract can register the identity of IoT devices, store data index addresses, metadata, and access policies, and make decisions about client access requests.

IoT device: As the data source of this framework, IoT devices are composed of IoT devices in different scenarios, including smart medical devices (such as thermometers, sphygmomanometers, etc.), smart home devices (such as mobile phones, televisions, etc.), and smart industrial devices (such as cameras, cars, etc.). They are responsible for real-time sensing, collecting, and processing the perceived object information of the surrounding environment, encrypting the information, and forwarding the data to the IoT gateway through different protocols.

IPFS storage layer: The IPFS storage layer provides an IPFS storage service for IoT device data. IPFS is a point-to-point storage file system with a distributed network structure. When the data file is stored in the IPFS system, IPFS will return the unique corresponding hash index. By adopting the IPFS distributed storage scheme, IoT user data can be obtained from nearby nodes, which saves bandwidth resources and can effectively resist the downtime of central servers in the real world.

Trusted edge computing layer: This layer provides trusted data processing services. The edge computing servers in this framework have enabled the trusted computing service of Intel SGX, which ensures the confidentiality and integrity of the original data in the access process and protects the privacy of the data owner. Moreover, the edge computing server safely returns the data to the client through the constructed secure communication channel.

Data owner ($DO$): The $DO$ is the owner of the accessed resource object, which exists in the form of an edge server. As the owner of all IoT devices in the current edge cluster, it has the right to call the data resources of the IoT devices to which it belongs.

Client: The client is the interactive front-end for data access by data users, bound to the client’s identity. If the client’s attributes meet the access policy corresponding to the target data, the smart contract will authorize the client’s access. The requested data is safely returned to the client after being processed by the SGX-enabled edge server.

Professionals typically use unified modeling language (UML) to model system architectures. UML deployment diagrams are generally applied to physical structure modeling and functional to physical components mapping. Górski [38] proposed a 1 + 5 architecture view model for designing blockchain and internet technology (IT) system integration solutions. They mainly described an integration flow diagram that extended the UML activity diagram. Inspired by their work, we use the UML deployment diagram to represent physical nodes and the allocation of components in this framework, as shown in Figure 5.

Table 2. Stereotypes for nodes, services, and protocols.

Name	Extended UML Element
$\langle \langle IoTDeviceNode\rangle \rangle$	Node
$\langle \langle IoTGatewayNode\rangle \rangle$	Node
$\langle \langle IPFSNode\rangle \rangle$	Node
$\langle \langle ClientNode\rangle \rangle$	Node
$\langle \langle SGXServerNode\rangle \rangle$	Node
$\langle \langle dataCollectionService\rangle \rangle$	Artifact
$\langle \langle dataUploadService\rangle \rangle$	Artifact
$\langle \langle \mathit{distributedStorageService}\rangle \rangle$	Artifact
$\langle \langle blockchainService\rangle \rangle$	Artifact
$\langle \langle trustedComputingService\rangle \rangle$	Artifact
$\langle \langle Wi-Fi/RJ45/\dots \rangle \rangle$	Generic Connection
$\langle \langle IPFS\rangle \rangle$	Generic Connection
$\langle \langle P2P\rangle \rangle$	Generic Connection
$\langle \langle HTTPS\rangle \rangle$	Generic Connection

summarizes the stereotypes of nodes, services, and protocols in the UML deployment diagram.

4.2. Access Control of IoT Based on Blockchain

Before the detailed description is given, we first introduce some relevant symbol meanings in

Table 3. Notations.

Notation	Description
$DO$	The data owner
$D{O}_{Addr}$	Data owner’s account address
$C$	The client
$C_{Addr}$	Client’s account address
$D$	The IoT device
$D_{Addr}$	IoT device’s account address
$C_{Att}$	Attributes of the client
$AP$	Access policy
$Si{g}_{DO}\left(data\right)$	Sign data with the data owner’s public key
$Token$	A label bound to the client deregister
$Dat{a}_{ID}$	The ID of IoT data
$K_{DO}$	Encryption key of the data owner
$K_C$	Encryption key of the client
$K_{DH}$	DH shared secret key between enclaves
$P_{dataprocess}$	Data process program

.

4.2.1. Initialization of Blockchain

In this framework, we use Quorum to deploy a blockchain network. The nodes of the Quorum network include edge servers, IoT devices, and clients. As a blockchain application, Quorum is installed on the above nodes. Its functions include blockchain network communication, key pair generation, transaction management, and the creation and operation of smart contracts. Quorum’s account address is generated by $Keccak-256$ hash using the $pk$ of keypair ($pk,sk)$ When the Quorum network is created, the $DO\prime s$ account is initialized to the network administrator’s role. All $DOs$ are jointly responsible for maintaining the permission of nodes in the whole network, such as approving new nodes (including IoT nodes and client nodes) to join the alliance chain network. This permissioned mechanism is more secure, targeted, and controllable than the public chain.

First, when a new IoT device node needs to be added to the framework, it needs to be approved by the $DO$ before it can connect to the blockchain network and then create the corresponding account. The IoT device’s public key uniquely identifies the device account. We use smart contracts to define the data structure of the IoT device account, the storage address index, metadata, and data access policy for the data. The specific data structure is shown in Figure 6.

4.2.2. Attribute-Based Access Control Contract

This section will introduce the detailed process of using smart contracts to implement the access control framework.

• Initialization of the Contract

The $DO$ first creates an access control contract, as shown in Algorithm 1, and deploys the contract to the blockchain by sending the transaction. During the deployment phase of the contract, we define a set of state variables, including the $DO\prime s$ address, the mapping between $DataID$ and $AP$, and the mapping between $C_{Addr}$ and $C_{Att}$ and $Token$. We store the values of these variables persistently in the blockchain. We also define an event interface to record the results of access decisions in history. In the deployment phase of the contract, the constructor function is used to initialize the contract status, and the variable owner is initialized to the account address of the $DO$, which sends the contract deployment.

Algorithm 1. Initialization of the Contract
1:	address$owner$
2:	enum$Result${$Unregistered$, $Unsigned$, $Unpermitted$, $Permitted$}
3:	mapping($Dat{a}_{ID }$=> $Policy$) $policy\_all$
4:	event ResultEvent($address$, $DataID$, $Result$)
5:	mapping($address$ => $token$) $clientToken$
6:	function Constructor():            ▷only invoked once by $DO$
7:	$owner$ = $msg.sender$
8:	end function

• Management of Access Policy

After the contract deployment, the $DO$ first encrypts and uploads the original data collected by IoT devices to IPFS, and returns the address index of the data to IPFS. As shown in Algorithm 2, the $DO$ can send transactions to invoke the $\mathit{AddDataPol}$, $\mathit{DelDataPol}$, and $\mathit{QueryData}$ methods of the contract, which correspond to the addition, deletion, and query of on-chain access policies. The $\mathit{onlyOwner}$ modifier function ensures that data resources can only be added and removed by the $DO$.

Algorithm 2. Management of Access Policy
Input:	$\mathit{I}\mathit{D}$: the target data’ID $\mathit{H}\mathit{a}\mathit{s}\mathit{h}$: IPFS address index $\mathit{P}$:the access policy
1:	function AddDataPol($\mathit{I}\mathit{D}$, $\mathit{H}\mathit{a}\mathit{s}\mathit{h}$, $\mathit{P}$) $onlyOwner$:   ▷only invoked by $DO$
2:	policy_all[$\mathit{I}\mathit{D}$] = ($\mathit{H}\mathit{a}\mathit{s}\mathit{h}$, $\mathsf{P}$)
3:	end function
4:	function DelDataPol($\mathit{I}\mathit{D}$) $onlyOwner$          ▷only invoked by $DO$
5:	$delete$ $policy\_all\left[\mathit{I}\mathit{D}\right]$
6:	end function
7:	function QueryData($\mathit{I}\mathit{D}$)                ▷only invoked by $ES$
8:	$require$($msg.sender$==$ES$)
9:	return $policy\_all \left[\mathit{I}\mathit{D}\right].metadata$
10:	end function

$\mathit{AddDataPol}$: In the actual Internet of Things scenario, data is generated anytime, anywhere. Therefore, the $DO$ takes the $DataID$, IPFS address index, and access policy as the input to add the target data and corresponding access policy dynamically. It is important to note that to avoid storing the plaintext information of the data access policy on the blockchain, we have one-way hashed the key fields in the access policy.

$\mathit{DelDataPol}$: The $DO$ takes the number of $DataID$ corresponding to the data on the chain as the input and calls the contract keyword $delete$ to release the data stored in the contract. After the function is called, $DataID\prime s$ corresponding access policy in the blockchain will be cleared.

$\mathit{QueryData}$: The edge server inputs $DataID$ to query the IPFS address index corresponding to the target data and downloads the data locally. The edge server then completes the trusted processing of the data in the data processing stage.

• Assignment of Client Permission

First, the data owner $DO$ defines a set of attributes according to the system role. When client $C$ is added to the framework, the $DO$ will define its set of attributes $C_{Att}$ according to its permissions and will then sign the message $\left(C_{Addr}\left|\left|C_{Att}\right|\right|Token\right)$ with the private key. The $DO$ then sends a message containing $\left(C_{Att}, Token, Si{g}_{DO}\left(C_{Addr}\left|\left|C_{Att}\right|\right|Token\right)\right)$ to the offline client $C$, where $C_{Addr }$is the blockchain account address of the client $C$, and $C_{Att }$is the attribute of the client $C$. In addition, the contract initializes the token of each newly added client with $1$, persistently saves the mapping value $clientToken$, records the token value of each client address, and uses it in the phases of client deregistration and recovery.

• Access Control

To request access to the specified data, client $C$ calls the $\mathit{AccessControl}$ function of the contract, and the input is $\left(Dat{a}_{ID}, C_{Att}, Si{g}_{DO}\left(C_{Addr}\left|\left|C_{Att}\right|\right|Token\right)\right)$. The access control process of the smart contract is shown in Algorithm 3:

Algorithm 3. Assignment of Client Permission
Input:	$\mathit{I}\mathit{D}$: the target data’ID $\mathit{A}$: the $Client\prime s$ attribute set $\mathit{Sign}$: a message signed by $DO$
1:	function AccessControl($\mathit{I}\mathit{D}$, $\mathit{A}$, $\mathit{Sign}$):       ▷only invoked by $Client$
2:	$require$($msg.sender$==$Client$)
3:	if $clientToken\left[msg.sender\right]$! = 1:
4:	$emit$ ResultEvent($\mathit{I}\mathit{D}$, $msg.sender$, $“Unregistered”$)
5:	elif SignVerify($\mathit{A}$, $\mathit{Sign}$) == $false$:
6:	$emit$ ResultEvent($\mathit{I}\mathit{D}$, $msg.sender$, $“Unsigned”$)
7:	elif PolicyVerify($\mathit{I}\mathit{D}$, $\mathit{A}$) == $false$:
8:	$emit$ ResultEvent($\mathit{I}\mathit{D}$, $msg.sender$, $“Unpermitted”$)
9:	else:
10:	$emit$ ResultEvent($\mathit{I}\mathit{D}$, $msg.sender$,$“Permitted”$,$permit time$)
11:	end if
12	end function
13:	function SignVerify($\mathit{A}$, $\mathit{Sign}$):             ▷only invoked internally
14:	msgHash =$keccak256\left(msg.sender\left|\left|\mathit{A}\right|\right|1\right)$
15:	if $ecrecover\left(msgHash,\mathit{Sign}\right)$ == $owner$:
16:	return $true$
17:	else
18:	return $false$
19:	end if
20:	end function
21:	function PolicyVerify($\mathit{I}\mathit{D}$, $\mathit{A}$):             ▷only invoked internally
22:	$\mathit{P}$ = $policy\_all\left[\mathit{I}\mathit{D}\right].policy$
23:	if $\mathit{P}$ is satisfied by $\mathit{A}$:
24:	return $ture$
25:	else
26:	return $false$
27:	end if
28:	end function

$\mathit{TokenVerify}$: The smart contract first checks the token value corresponding to the client address. Only when the token value is $1$ will the access request continue to authenticate. Otherwise, an$“Unregistered”$ event will be triggered.

$\mathit{SignVerify}$: The function takes the client attribute set $C_{Att }$and the signed message $Si{g}_{DO}\left(C_{Addr}\left|\left|C_{Att}\right|\right|Token\right)$ in the access request message as inputs to verify whether the signature matches the $DO\prime s$ address $D{O}_{Addr}$. If the signature authentication succeeds, it indicates that client $C\prime s$ attribute set $C_{Att}$ and $Token$ are valid, and the attribute verification continues. Otherwise, an $“Unsigned”$ event will be emitted. Specifically, Quorum provides a reliable signature verification mechanism in smart contracts, ensuring the authenticity of key pairs and data used for the signature. The ecrecover function in the contract is used to obtain the address associated with the public key from the signed message.

$\mathit{PolicyVerify}$: This function takes the data identifier $Dat{a}_{ID}$, and the client attribute set $C_{Att}$ in the access request message as inputs and verifies whether the client attribute set $C_{Att}$ meets the access policy $P$ related to $Dat{a}_{ID}$. If satisfied, the contract will trigger a $“Permitted”$ event. Otherwise, it will trigger an $“Unpermitted”$ event. When the blockchain node catches the $“Permitted”$ event, client $C$ has been granted access to the data related to $Dat{a}_{ID}$ within the specified time interval. When the access times out, a $“Timeout”$ event will be triggered, and the client needs to re-initiate the access request when it catches this event.

• Deregistration and Recovery of Client

As shown in Algorithm 4, toderegister client $C$, the $DO$sends a transaction to call the $\mathit{DeregisterClient}$ function in the contract, taking the client’s account address $C_{Addr}$ as input. The token value associated with $C$ will be updated to $Token+1$. It will make it impossible for a signed message previously sent by the $DO$ to pass access control signature verification. After the client $C$ deregisters, the $DO$ can resend the signature message by updating the client’s token to recover the corresponding permissions of client $C$.

Algorithm 4. Deregistration of Client
Input:	$\mathit{Addr}$: the $Client\prime s$ account address
1:	function DeregisterClient($\mathit{Addr}$) $onlyOwner$:   ▷only invoked by $DO$
2:	$clientToken\left[\mathit{Addr}\right]$++
3:	end function

4.3. Trusted Processing of IoT Data Based on SGX-Enabled Edge Computing

In this framework, we combine SGX-enabled edge computing services and blockchain to achieve trusted processing of IoT data. As shown in Figure 7, the data owner of IoT is the $DO$, the data requester is the client $C$, and the edge computing server is $ES$. We assume that the $DO$ and $C$ have established a secure communication channel within the enclave through remote attestation.

We use a UML sequence diagram to represent the IoT data access and processing flow based on SGX edge computing, as shown in Figure 8. The trusted data processing flow based on SGX is as follows.

Step 1: The $DO$ encrypts the raw data of the IoT device using its key $K_{DO}$, then uploads the encrypted data to IPFS to obtain the data index $ID$.

Step 2: The $DO$ calls the smart contract to store the access policy corresponding to the $Dat{a}_{ID}$ on the blockchain.

Step 3: The $DO$ assigns access permissions to registered clients.

Step 4: The client $C$ invokes the $\mathit{AccessControl}$ function of the smart contract to request access to specified data.

Step 5: The smart contract makes access decisions according to the access control process described in the previous section.

Step 6: When the access decision is passed, the $“Permitted”$ event will be triggered and broadcast in the blockchain network.

Step 7: When the blockchain program of $ES$ catches the $“Permitted”$ event, $ES$ will download the corresponding encrypted data from IPFS.

Step 8: When the $DO$ catches the $“Permitted”$ event, it will encrypt its key $K_{DO}$ with $K_{DH}$, get the ciphertext $C{T}_{DO}$, and send it to the enclave of the edge node.

Step 9: When the client catches the “permitted” event, it will encrypt its key $K_C$ with $K_{DH}$ to obtain the ciphertext $C{T}_C$. The client sends the required data type and $C{T}_C$ to the enclave of the edge node.

Step 10: $ES$ uses $K_{DH}$ to recover $K_{DO}$ as the input for data decryption to obtain the plaintext of IoT data.

Step 11: $ES$ uses $P_{dataprocess }$to process the IoT plaintext data and takes the decrypted IoT data and the data type specified by the client as input parameters.

Step 12: The data processing results are generated when the data processing is complete. The result is encrypted by $K_C$ and returned to the client $C$.

In the process of data decryption, data processing, and data encryption by SGX, $ES$ keeps the IoT data in the enclave, ensuring the confidentiality and integrity of user data. The data processing program can also verify the correctness of the process through the SGX.

5. Performance Evaluation

To verify the feasibility and effectiveness of this scheme, we set up an experimental environment to simulate the process of deploying access policies to the blockchain through smart contracts and calling contracts to obtain data access authorization. We then tested the gas overhead and communication delay of the blockchain. We also tested the data processing performance of the edge server before and after SGX was enabled. The hardware environment of the experiment is as follows. The $DO$ and client $C$ are instantiated on a notebook with an Intel Core I7-11800H CPU at 2.30GHz and 16GB RAM, running on the Windows 10 system. The SGX-enabled $ES$ runs on a server with an Intel Xeon e3-1280 v6 CPU at 3.90GHz and 32GB RAM, running on Ubuntu18.04 (64b). The software environment is as follows. $ES$ data processing program uses SGX SDK 2.9 written. The Quorum version is v22.4.2, and the installed version of IPFS is v0.4.19. The smart contract is written in Solidity (V 0.4.22), debugged and compiled, and deployed with Truffle and Ganache’s tools. Using the JavaScript web3.js library, we implemented the signature mechanism of the chain, mainly by calling the transaction signature algorithm ECDSA-SecP256K. In the experiment, we used Boolean expressions composed of attributes to describe the data access strategy. In this case, the access policy can only be satisfied when the attribute set $C_{Att}$ of the client $C$ makes the attribute expression true.

5.1. Performance of Access Control Contract

In Quorum, gas is the basic unit used to measure the computing resources consumed by each transaction, such as the deployment and invocation of smart contracts. As Quorum is a coin-free blockchain, its gas is not anchored to any cryptocurrency. The more complex the computational steps required for Quorum to execute a transaction are, the more gas will be consumed. We used Solidity to write contracts to realize the whole access control process. At the same time, we selected the related common indicators and set the number of attributes involved to four. We compared our scheme with other work [10,11] in detail in terms of the gas cost of the main operations. The data comparison is shown in

Table 4. Comparison of gas costs for main operations.

Scheme	Deploying Contracts	Adding Attributes	Adding a Policy	Access Control	Total
[10]	1,706,290	-	128,777	75,771	1,910,838
[11]	1,301,972	308,109	363,964	264,635	2,238,680
ours	871,268	-	163,284	42,764	1,077,316

. We only need to deploy one contract in our scheme, so the gas cost of deploying the contract is the lowest, and the subsequent gas cost is used to call the calculation operation of the contract interface. The gas cost of adding access policies and verifying access is mainly determined by the complexity of access policies and the number of attributes. The schemes of Zhang et al. [10] and Yutaka et al. [11] have relatively complex data information interactions between attributes and policies of different contracts, resulting in more gas overhead in the access control process than our scheme.

Furthermore, we recorded the comparison of the gas cost of calling $\mathit{AddDataPol}$, $\mathit{DelDataPol}$, $\mathit{AccessControl}$, and $\mathit{QueryData}$ operations in the access control contract when the scheme in this paper involves different quantity attributes, as shown in Figure 9.

As the number of attributes increases, the calculation and storage overhead of blockchain contract execution will increase, so the gas cost of these four operations will also increase correspondingly. In the experimental results, the gas overhead of $\mathit{AddDataPol}$ is significantly higher than that of $\mathit{DelDataPol}$. Storing new data on the blockchain will lead to excessive resource usage while deleting data will free up storage space on the blockchain and return the appropriate gas. Unqualified tokens or invalid signature and attribute sets will end early in the access control function. If the client passes all the verification stages, it can finally trigger the $“Permitted”$ event, where the gas cost of token verification and signature verification is fixed, and the total gas cost of access request processing is mainly determined by the attribute verification process. As attribute verification requires Boolean operations on the attributes involved, the more attributes means the more computing resources used, and the higher the gas cost. In most attribute-based access control scenarios in the internet of things, 10 attributes can meet the needs of the scenario. When the access policy contains 10 attributes, the access control cost is only 79,172 gas, which is still less than the gas cost of adding the access policy, proving that the proposed scheme is very efficient and friendly to the client access control process in this case.

Regarding communication delay, we recorded an average of 10 contract test results, as shown in

Table 5. Comparison of communication delay for main operations.

Scheme	Deploying Contracts	Access Control
[10]	≈1 min	≈30 s
[11]	≈80 s	≈36 s
Ours	≈33 s	≈2 s

. The access control contract is deployed on the Quorum blockchain. As Quorum is a permissioned chain that supports high concurrency and low latency, the time-consuming nature of the contract-deployed transactions being packaged into the blockchain by miners is mainly related to external factors, such as the network status of nodes or the computing power of nodes. In the 10 repeated experimental tests, the average deployment time of the contract was 30 $s$, which was approximately 1/2 faster than the work of Zhang et al. [10]. In the contract’s access control interface test, the average execution time of our scheme was within 2 $s$, which had a significant advantage over the work of [10,11] in terms of time efficiency. This is because, in their studies [10,11], the information interaction between different contracts on attributes and policies is relatively complex.

The authors of [10] need to specify the ACL for each client on the chain, and the authors of [11] need to record the attributes of each client on the blockchain. Therefore, the on-chain storage cost is directly proportional to the number of clients. As the number of clients increase, the on-chain storage cost increases linearly. However, in our scheme, the attributes of clients are distributed off the chain by the $DO$ signature, and the number of clients will not affect the storage overhead of the blockchain, which significantly saves the valuable on-chain storage space.

Table 6. Comparison of the relationship between on-chain storage overhead and the number of clients $n$.

Scheme	On-Chain Storage Overhead
[10]	$O\left(n\right)$
[11]	$O\left(n\right)$
ours	$O\left(1\right)$

records the relationship between the on-chain storage overhead and the number of clients $n$.

5.2. Performance of Trusted Data Processing Based on SGX

We assume that the $ES$ has captured the $“Permitted”$ event triggered by the client and downloaded the corresponding data set from IPFS. First, we developed two programs with the same data processing capabilities on the server, one on an SGX-enabled server and the other on a non-SGX-enabled server. We used data sets of different sizes to test the data processing time in the two environments and executed the data processing process 10 times for each data set. Finally, we took the average test time as the experimental result. We conducted experiments in the two environments to compare the difference in data processing performance before and after the SGX function was enabled. Figure 10 compares data processing results before and after the SGX function was enabled on the server. Generally, the data processing time in both environments increases with the data set size. Data processing times of the same size with SGX enabled are always higher than without SGX enabled. When the data set is small, the data processing time of the two cases is the same. The time difference between the two cases gradually increases with the size of the processed data set. Mainly, when the data set is 90,000 pieces of data, the time difference between them is 1.31 $s$, which is still an acceptable range in most cases.

6. Discussion and Limitations

In this article, we combine blockchain, SGX, and IPFS technologies to propose an IoT access control framework. Our discussion on the scheme of this article is as follows:

(1)

Auditability

Traditional Internet of Things access control is performed by centralized cloud center servers, leading to a lack of transparency in the process. In our proposed framework, blockchain enables all participants (DOs, clients, edge servers, IoT devices) to monitor contract events continuously and verify access control results. In addition, blockchain can record all process events, including transaction initiation, processing, contract call process, authorization, and other events. In this way, all illegal and unauthorized operations can be traced. Therefore, the proposed framework guarantees auditability.

(2)

Flexibility

In our framework, access policies and clients are separated. The client is described by a set of attributes instead of being described by a unique identity. IoT data is bound with attribute-based access policies. When a new client node joins, its access rights are granted by distributing attribute signatures of the chain, so it is unnecessary to store the client-related permission information on the blockchain. Therefore, increasing the number of clients will not lead to an increase in blockchain storage costs. Thus, the flexibility of the proposed framework is greatly enhanced.

(3)

Authenticity

The nodes involved in this framework, including IoT devices, edge servers, and clients, need to be approved by the DO in the blockchain first to obtain identity information. Secondly, the client’s address is included in the attribute signature signed by the DO. When the client calls the smart contract, the smart contract can verify its identity from the transaction information by using the $\mathit{SignVerify}$ method of the $\mathit{AccessControl}$ function. The node’s identity will also be remotely authenticated when registering in the edge server’s enclave. Therefore, the proposed framework guarantees authenticity.

(4)

IoT Data Confidentiality

After IoT data is generated, it is encrypted by the DO’s symmetric key and uploaded to the IPFS. The edge server downloads the encrypted data from the IPFS. Without an encryption key, a malicious attacker cannot access sensitive information in the data. The key for encrypting IoT data is encrypted with the shared key obtained by the enclave through key exchange protocol, ensuring that only the enclave in the edge server and the DO can decrypt the IoT data. The decryption, processing, and re-encryption of IoT data are all performed in the edge server’s enclave, guaranteed by the remote attestation mechanism provided by SGX. In summary, in data transmission and trusted processing, the proposed framework ensures the confidentiality of IoT data through encryption algorithms and Intel’s SGX technology.

However, we also note that there are some limitations to the proposed scheme. Firstly, it should be highlighted that our experimental results were obtained in a laboratory environment, not in a real IoT scenario. Therefore, we have not considered all the potential limitations in our research. Currently, the continuous delivery and deployment of blockchain-distributed software is widely and rapidly developing, and there have been many excellent works [39,40]. Tran et al. [39] proposed a novel framework for the automated deployment and evaluation of blockchain applications. The framework is driven by blockchain network architecture specifications that support heterogeneous multi-channel networks and describe high-level design decisions (e.g., network topology, protocol selection). Górski [40] proposed a solution for continuously delivering blockchain applications to different deployment environments. They implemented two continuous delivery pipelines using a Jenkins automated server. The first pipeline prepares the business application, while the second pipeline generates the complete node deployment package. In terms of software delivery and deployment, in our proposed scheme, blockchain software Quorum is designed and deployed in edge server nodes, user client nodes, and IoT device nodes. However, in different IoT scenarios, the computing resources of IoT nodes are various, affecting whether IoT nodes are deployed as blockchain full nodes or lightweight nodes. Moreover, the blockchain platform selected in this scheme is the permissioned blockchain Quorum, which supports the design of multi-channel heterogeneous scenarios. Still, it needs further adjusted and adapted according to specific business requirements. Therefore, the scheme of this article still needs further in-depth study in terms of continuous delivery and deployment combined with specific IoT scenarios (such as the Internet of Medical Things).

7. Conclusions

This article proposes an IoT access control framework based on blockchain and SGX. We designed an attribute-based access control contract based on blockchain. We deployed it on the Quorum blockchain to achieve flexible management of access policies and fine-grained access control in IoT systems. In addition, our scheme distributes attribute information to clients in the form of signatures, stores it offline, and realizes the signature check mechanism on the blockchain, saving valuable storage space on the chain. Meanwhile, combined with SGX technology, we designed the trusted processing flow of IoT data in edge servers, eliminating the possibility of malicious servers accessing data illegally. Finally, we conducted extensive experiments on Quorum blockchain and SGX-enabled servers. Through testing and analysis of comparative experiments, the performance of our framework is more advantageous in terms of gas overhead, deployment time, and storage overhead on the chain. The experimental results proved the feasibility and rationality of the proposed framework.

In future work, we plan to deploy the framework proposed in this article in factual IoT scenarios (such as the Internet of Medical Things). We will try to use privacy protection technologies such as zero-knowledge proof and homomorphic encryption to protect the privacy of user identities and IoT data. And we will explore the solution of continuous delivery and deployment of our framework in combination with the slockchain-as-a-service (BaaS) platform.