See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/339168393

Enabling Attribute Revocation for Fine-Grained Access Control in

Blockchain-IoT Systems

Article  in  IEEE Transactions on Engineering Management · February 2020

DOI: 10.1109/TEM.2020.2966643

CITATIONS

0READS

76

9 authors, including:

Some of the authors of this publication are also working on these related projects:

5G Heterogeneous Networks: QoS Perspective View project

base-station View project

Guangsheng Yu

University of Technology Sydney

7 PUBLICATIONS   11 CITATIONS   

SEE PROFILE

Xuan Zha

University of Technology Sydney

13 PUBLICATIONS   64 CITATIONS   

SEE PROFILE

Xu Wang

University of Technology Sydney

17 PUBLICATIONS   89 CITATIONS   

SEE PROFILE

Wei Ni

The Commonwealth Scientific and Industrial Research Organisation

234 PUBLICATIONS   1,527 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Xu Wang on 14 February 2020.

The user has requested enhancement of the downloaded file.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT 1

Enabling Attribute Revocation for Fine-GrainedAccess Control in Blockchain-IoT Systems

Guangsheng Yu , Xuan Zha , Xu Wang , Wei Ni , Senior Member, IEEE, Kan Yu , Ping Yu,J. Andrew Zhang , Senior Member, IEEE, Ren Ping Liu , Senior Member, IEEE, and Y. Jay Guo , Fellow, IEEE

Abstract—The attribute-based encryption (ABE) has drawn alot of attention for fine-grained access control in blockchains,especially in blockchain-enabled tampering-resistant Internet-of-Things (IoT) systems. However, its adoption has been severelyhindered by the incompatibility between the immutability of typicalblockchains and the attribute updates/revocations of ABE. In thisarticle, we propose a new blockchain-based IoT system, which iscompatible with the ABE technique, and fine-grained access controlis implemented with the attribute update enabled by integratingChameleon Hash algorithms into the blockchains. We design andimplement a new verification scheme over a multilayer blockchainarchitecture to guarantee the tamper resistance against maliciousand abusive tampering. The system can provide an update-orientedaccess control, where historical on-chain data can only be accessibleto new members and inaccessible to the revoked members. This isdistinctively different from existing solutions, which are threatenedby data leakage toward the revoked members. We also provideanalysis and simulations showing that our system outperformsother solutions in terms of overhead, searching complexity, security,and compatibility.

Manuscript received June 30, 2019; revised November 13, 2019, December5, 2019, and December 26, 2019; accepted January 6, 2020. This work wassupported in part by funding from Food Agility CRC Ltd., funded under theCommonwealth Government CRC Program and in part by UCOT Australia PtyLtd. Review of this manuscript was arranged by Department Editor K.-K. Choo.(Corresponding author: Guangsheng Yu.)

G. Yu is with the Global Big Data Technologies Centre, University ofTechnology Sydney, Ultimo, NSW 2007, Australia (e-mail: guangsheng.yu@uts.edu.au).

X. Zha is with the Security Research Institute, China Academy of Informationand Communications Technology, Beijing 100191, China (e-mail: zhaxuan@caict.ac.cn).

X. Wang is with the School of Cyberspace Security, Beijing University ofPosts and Telecommunications, Beijing 100876, China, and also with the GlobalBig Data Technologies Centre, University of Technology Sydney, Ultimo, NSW2007, Australia (e-mail: Xu.Wang-1@uts.edu.au).

W. Ni is with the CSIRO, Sydney, ACT 2601, Australia (e-mail: wei.ni@data61.csiro.au).

K. Yu is with the Department of Computer Science and InformationTechnology, La Trobe University, Bendigo, VIC 3552, Australia (e-mail:k.yu@latrobe.edu.au).

P. Yu is with the State Key Laboratory of Networking and Switching Tech-nology, Beijing University of Posts and Telecommunications, Beijing 100876,China, and also with the Global Big Data Technologies Centre, Universityof Technology Sydney, Ultimo, NSW 2007, Australia (e-mail: Ping.Yu-2@student.uts.edu.au).

J. A. Zhang, R. P. Liu, and Y. J. Guo are with the Global Big Data Technolo-gies Centre, University of Technology Sydney, Ultimo, NSW 2007, Australia(e-mail: andrew.zhang@uts.edu.au; renping.liu@uts.edu.au; jay.guo@uts.edu.au).

Color versions of one or more of the figures in this article are available onlineat https://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TEM.2020.2966643

Index Terms—Access control, attribute-based encryption (ABE),blockchain, Chameleon Hash (CH) algorithm, Internet of Things(IoT).

I. INTRODUCTION

THE Internet of Things (IoT) technology is reshaping man-ufacturing and industrial processes [1]. Massive data from

smart machines can reduce cost, benefit production, and assist inderiving accurate business decisions and have attracted increas-ing attention. The massive data need to be accessible by specificgroups of users among many different entities. Fine-grainedaccess control is important, especially with the fast developmentof the IoT and the increasing number of devices and users [2], [3].Existing solutions tend to rely on the cloud service to maintaindata storage for access control services [4]. However, there existthe following critical issues.

1) Amazon Cloud Service, Microsoft Azure, and Alicloudsuffered from the service outage from 2017 to 2019, lead-ing to the huge losses of data service for customers [5]–[7].

2) The public cloud, the private cloud, and the hybrid cloudhardly tolerate the Byzantine Failure [8]. The ByzantineFailure takes malicious nodes into account, which is themost complicated failure mode in a distributed system [9].

3) The cloud services lack trustworthy tamper resistance fordata storage and access control [10].

As a consequence, the IoT security could be severely com-promised. Reliable and trustworthy IoT data services with fine-grained access control have yet to be available among businessentities and users.

The blockchain technology, originating from cryptocurrency,has been recently employed in the IoT as the root of trustfor authorization management [11], policy management [12],and data security [13]. In a blockchain, all participants canverify and certify data by following a common consensus pro-tocol to provide decentralized, reliable, and tamper-resistantservices [14]. There have been a number of attempts to imple-ment data access control on the traditional blockchains, wheredata are publicly stored, e.g., Bitcoin and Ethereum [15], [16].Cryptographic technologies, e.g., homomorphic encryption andzero-knowledge-proof [17], [18], have been adopted. However,these technologies can suffer from prohibitive overhead forIoT devices [19]. This prevents fine-grained access control inblockchain-based IoT systems. Meanwhile, Hyperledger Fab-ric [20] implements a traditional access control by using trans-action encryption and key management. However, the size of

0018-9391 © 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See https://www.ieee.org/publications/rights/index.html for more information.

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

2 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT

encrypted conversation keys grows linearly with the number ofusers. The overhead would still be very high in blockchain forfine-grained access control.

The attribute-based encryption (ABE) technologies have thepotential to achieve fine-grained access control, where a cipher-text can only be decrypted when the attributes of a user match apredefined set of rules [21], [22]. In [22], the conversation keysof encrypted transaction data are protected with ABE by thetransaction senders (i.e., data owners). Any outdated ciphertextneeds to be updated and overwritten with an updated versionwhen the attributes are revoked. However, the immutability ofblockchain prevents the update of attributes and the dynamicgroup membership of ABE. The existing solution tends to storethe updated ciphertext of ABE by smart contracts [23]. A riskof a direct data leakage to revoked members arises. Adequatedesigns of ABE-based blockchain access control have yet to beproperly addressed.

In this article, we propose a novel multilayer blockchain-IoTdata service system, which enables secure attribute updatesin an ABE-based fine-grained access control mechanism forblockchains. We develop a redactable key chain along with astandard data chain to secure and control the access to the datachain. Empowered by redactable hash functions, the redactablekey chain allows the access policies of ABE to be updated by keychain miners. The data chain can be any existing blockchain withany scalable structure and preserves the immutability of the IoTdata. Collectively, these crytographic primitives address the in-herent incompatibility between the immutability of blockchainsand the indispensable need of updating attributes to managethe access to blockchains. To the best of our knowledge, theproposed blockchain-IoT data service system is the first of itskind to enable the attribute updates and provide effective accesscontrol in the presence of the updates. The system is compatiblewith the major types of cryptographic primitives and consensusalgorithms in blockchains.

The key contributions of this article are shown as follows.1) We identify the incompatibility between the immutability

of blockchain and the update of attributes in ABE, and theresultant potential risk of direct data leakage to revokedmembers. The incompatibility hinders the adoptions ofABE in blockchain-based IoT systems.

2) We design a new multilayer blockchain structure consist-ing of a data chain and key chains, in order to decoupledata storage and access control management. ABE is usedfor fine-grained access control in the proposed key chains.

3) We propose to integrate the Chameleon Hash (CH) algo-rithm in the blockchain structure along with a new ver-ification scheme to support the tamper-resistant attributeupdate of ABE in the proposed key chains. As a result, thesystem allows trusted policy update in ABE, while stillpreserving the tamper resistance of blockchains.

The analysis and simulation results show that our proposedmechanism is able to outperform existing solutions in terms ofoverhead, searching complexity, and security. Our mechanismalso provides excellent compatibility with major types of con-sensus protocols, cross-chain protocols, and crypto algorithms(ABE and CH).

The rest of this article is organized as follows. InSection II, the related works are surveyed. Section III presentsthe proposed blockchain system. Section IV presents the mul-tilayer blockchain design, as well as the design of redactablekey chain with a new verification scheme. In Section V, weconduct comprehensive system analysis and simulation. Finally,Section VI concludes this article.

II. RELATED WORK

Recently, several access control mechanisms have beenproposed for IoT networks based on cloud services [24]–[26].Therein, the ABE technology has attracted much attention incloud computing to provide fine-grained access control [27]–[29]. For example, Roy et al. [27] apply ABE over multiplecloud servers, and Fedrecheski et al. [28] provide a distributedand scalable structure for an ABE-based IoT network. TheABE allows users to asynchronously decrypt a ciphertext whenthe users’ attributes match the prespecified access rules ofthe ciphertext with no need for IoT devices staying online allthe time [30]. ABE schemes can be divided into key-policyattribute-based encryption (KP-ABE) [31] and ciphertext-policyattribute-based encryption (CP-ABE). In KP-ABE schemes,a ciphertext is associated with a set of attributes, and users’secret keys are based on an access policy. CP-ABE schemesuse access policies to encrypt data, and users’ secret keys aregenerated over a set of attributes. However, only relying oncloud services may lead to a loss of reliability and traceabilityof data [5]–[7]. Thus, blockchain-based access control becomesincreasingly attractive.

In [10] and [11], it is shown that blockchains allow themanager or gateway of each domain network to be part ofthe consensus process in a blockchain-based key managementcloud. This can ensure the service of key management anddistribution for users in a transparent manner. Nevertheless,such access control mechanisms are incapable of providing fine-grained access control in the presence of a device, or even systembreakdown, caused by a burst of encryption request messagesat the IoT devices. To address this issue, there have been studieson blockchain-based ABE schemes [21]–[23]. For example,in [22], an ABE scheme is employed in a blockchain-based IoTsystem to encrypt sensory data into transactions. However, asrevealed in [21], few existing blockchain-based ABE schemescan support a practical mechanism for attribute update and thuscan hardly be adopted in dynamic IoT applications. One ofthose providing a vague discussion about attribute update is [23](the technological detail is not given), where the smart contractis used to support attribute updates in a blockchain-based ABEsystem. The scheme in [23] can potentially allow the data tobe directly exposed to members with revoked attributes. Thisis because the history of smart contract is recorded along withthe past blocks, and the revoked members can directly accessoutdated versions of the ciphertext associated with their outdatedABE private keys. A potential remedy to this issue is to introducea redactable blockchain by using CH algorithms [32], [33]. Ourproposed system achieves a better performance than that of [23]in terms of overhead, searching complexity, and security.

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

YU et al.: ENABLING ATTRIBUTE REVOCATION FOR FINE-GRAINED ACCESS CONTROL IN BLOCKCHAIN-IOT SYSTEMS 3

TABLE INOTATION DEFINITION

III. PRELIMINARY

A. Attribute-Based Encryption

ABE provides access control to data based on a set of rulesassociated with data and attributes of a data user (DU). In gen-eral, an ABE scheme consists of the following five algorithms.Table I summarizes the notations used in the rest of this article.

ABE_Setup (1k) → (MK): This algorithm sets up ABE. Ittakes as input a security parameter 1k and outputs a masterkey MK.

ABE_KeyGen (MK, r) → (ABESK,i, ABEPK): This al-gorithm generates attribute-based keys. It takes as input themaster key MK and a random number r and outputs a pair ofABE keys. Each pair of ABE key includes a private parameterset, ABESK,i, and a public parameter set, ABEPK . Note thatABESK,i is identity based, which indicates that each member iassigned with the same attribute has its own unique ABESK,i.

ABE_Encrypt (PT ,A, ABEα,PK) → (CT ): This algo-rithm encrypts data according to the assigned access policy. Ittakes as input a message to encrypt PT , an access policy A, anda set of public parameters ABEα,PK of attribute α and outputsCT , which is the ciphertext of PT .

ABE_Decrypt (CT ,A, ABEα,SK) → (PT ): This algo-rithm decrypts data if the attribute-related parameters satisfythe access policy. It takes as input a message to decrypt CT ,an access policy A, and a set of private parameters ABEα,SK

by each member in attribute α and outputs PT , which is theplaintext of CT .

ABE_Update (MK,α,CT , ABEα,SK , r′) →(CT ,′ ABE ′

α,SK): This algorithm updates the CT and the correspondingABEα,SK to a new version, i.e., CT ′ and ABE ′

α,SK ,respectively, to meet the update of attribute members. It takes asinput the master key MK, an attribute α, the outdated CT , theoutdated ABEα,SK , and a new random number r′ and outputsthe updated CT ′ and ABE ′

α,SK .

B. CH Algorithm

A generic CH algorithm involves a trapdoor (private key) toallow one to quickly identify an arbitrary hash collision withinthe domain of this algorithm. It consists of the following threealgorithms.

CH_KeyGen (λ, ParaCH) → (SKCH , PKCH): This algo-rithm generates CH keys, given security parameters. It takes asinput a security parameter λ and a system parameter ParaCH

and outputs a private (trapdoor) key SKCH and a public (hash)key PKCH .

CH_Hash (M,PKCH , r) → (CH): This algorithm gener-ates the CH value for a message. It takes as input a messageto hash M , a private key PKCH , and a random number r andoutputs a CH value CH .

CH_Update (M,M,′ r, SKCH) → (r′): This algorithm up-dates CH-related parameters to guarantee that the original CHvalue remains valid after the message update. It takes as inputa message before the update M , the message after the updateM ′, the CH random number r before the update, and the

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

4 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT

Fig. 1. Overview of the proposed system. The bottom-half-side shows the architecture of the network layer, where the hierarchical topology of facilities isspecifically described, upon which blockchains being run among these facilities charged with different roles are described in the top-half-side. The table regardingthe allocation of roles describes the relationship between the considered facilities and roles.

corresponding private key SKCH and outputs an updated CHrandom number r′. The CH associated with the updated CH ran-dom number and the updated message is identical to the originalCH value before an update, i.e., CH_Hash (M,′ PKCH , r′) =CH_Hash (M,PKCH , r).

IV. MULTILAYER BLOCKCHAIN-IOT SYSTEM WITH

REDACTABLE KEY CHAIN

This article proposes a novel multilayer blockchain-IoT dataservice system, where secure attribute updates are enabledin an ABE-based fine-grained access control mechanism forblockchains. We develop a redactable key chain to providesecure access to another standard data chain. The redactable keychain enables the tamper-resistant attribute updates of ABE viaa new verification scheme conducted by the key chain miners.As a result, a secure fine-grained access control mechanism forblockchain-IoT systems can be achieved.

A. System Overview

The proposed system uses blockchain to provide IoT datastorage and data sharing services, where a CP-ABE scheme isintegrated to enable fine-grained access control. The proposedsystem consists of the following four roles.

1) Trusted authority (TA): The TA assigns and managesattributes for the entities in the system. The accessibilityof an entity to a particular piece of data depends onthe attributes of the entity, as well as the access controlpolicy of the data. The TA can be a standalone entity or amultiauthority group of which each member manages a setof attributes for robustness and scalability. In this article,we consider the TA as a single entity.

2) Data publisher (DP): The DPs, such as IoT devices, pro-duce, packetize, and upload data to blockchain in the formof transactions. The DPs also specify the access policyfor each new published message, so that only the DUswith attributes satisfying the access policy can access themessage.

3) DU: The DUs access the blockchain to retrieve data.Their attributes may change over time, and only the TA

can update DUs’ attributes and attribute-related privateinformation.

4) Miners: A Miner is responsible for mining data into theblockchain and providing tamper resistance, as typicallydone in any existing blockchain systems. A new responsi-bility of the Miners is to conduct a new verification schemeto avoid abusing the CH updating function during theconsensus process, as will be described in Section IV-C1.In the rest of this article, Miners refer to those running,managing, and storing the key chains. They are powerfulservers typically located in either the cloud or private datacenters.

Fig. 1 shows the network construction of a hierarchical IoTsystem, where these roles can be decoupled from the physicaldevices and one device may take multiple roles. For example,servers providing different services (e.g., Web servers, IoTservers, and blockchain RPC servers) can take the role of DP orDU. The table at the right-bottom corner of Fig. 1 provides themapping between network elements in the network architectureand the roles in the (key) blockchains. As a result, every networkelement assigned with one or multiple roles is connected via thenetwork. Each of the roles can participate in the data exchangeof blockchains, i.e., uploading or fetching data from the DataChain or Key Chains.

An IoT device serves as a DP/DU (primarily DP) in the pro-posed protocol. It only uses its own conversation keySKP /PKP

associated with message P , ABE public key ABEPK , andprivate key ABESK associated with each of its attributes toencrypt its data before uploading the data to the blockchains(or to decrypt its data after downloading the data from theblockchains). Based on field-programmable gate array (FPGA)and system-on-chip boards such as AVNETs Zedboards orsingle-board computers (SBCs) such as Raspberry Pi, many cur-rent IoT devices are reasonably powerful to carry out encryptionoperations. These are the IoT devices considered in this article.On the other hand, ABEPK and ABESK are generated by theTA and maintained/stored in one of the key chains. The IoTdevices only retrieve the keys from the key chain and are notinvolved in running, managing, or storing any of the blockchains(including the key chains and the data chain) due to limitedmemory and communication resources of the devices.

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

YU et al.: ENABLING ATTRIBUTE REVOCATION FOR FINE-GRAINED ACCESS CONTROL IN BLOCKCHAIN-IOT SYSTEMS 5

Fig. 2. Process of encrypting and publishing a new message is shown on the left-hand side. The right-hand side shows the process of decrypting and retrieving anew published message. A DP and DUs implement the Interchain Protocol to deal with the data encryption/decryption between the Data Chain and Key Chain.

B. Proposed Multilayer Blockchain System

We propose a multilayer blockchain-based data ledger servicesystem consisting of two types of blockchains: Data Chainfor immutable confidential data service and Key Chain for keymanagement, as shown in Fig. 2.

Data Chain: A Data Chain can be any existing permis-sionless or permissioned blockchains used for recording data,e.g., Ethereum [16], with the following scalability-enhancingtechniques:

1) existing scalable consensus algorithms or data structures,e.g., ByzCoin [34] and directed acyclic graph [35], that canhelp reduce the communication overhead of the proposedsystem to at most O(n), where n is the network size;

2) existing scale-out techniques that can partition a network(including the proposed network) into shards from theperspective of data storage, communication bandwidth,and computation, to achieve horizontal scalability (shard-ing) to accommodate huge amounts of data, e.g., Om-niLedger [36].

By using these techniques, the total capacity and throughputof a scalable Data Chain can be expected to support the hugedata of IoT systems. A DP encrypts its data with conversationkeys before publishing encrypted data in the form of transactionsin the Data Chain.

Key Chain: A Key Chain stores the ciphertext of the con-versation keys, i.e., CT , for key management. The Key Chain ispermissioned and has a unique TA to manage the key generationand distribution of the ABE scheme. Here, the conversation keys,used to encrypt data in the Data Chain, are encrypted by the ABEalgorithm by the DP, before the DP publishes the encrypted datain the Data Chain. Every Key Chain is redactable along witha new verification scheme conducted by the Miners on the KeyChain to guarantee the tamper resistance. Thus, the attributeupdates of ABE can be enabled.

Interchain Protocol: This protocol is implemented for dataexchange among a Data Chain and Key Chains.1 Any partic-ipants acting as clients on both Data Chain and Key Chains

1A major type of cross-chain protocol [37] can be rather implemented tobridge the communication among Data Chain and Key Chain instead of makingDPs send the transactions to each blockchain by themselves. Remark that oursystem is a generic one and independent of the cross-chain protocols.

operate the new the Interchain Protocol. The protocol includesthe following subprotocols.

1) Encryption and publishing a new message P : A DPencrypts PKA,P to CT = ABEA(PKA,P ), by usingABEα,PK , where an attribute α satisfies an attributepolicy {A}. This CT is uploaded to a Key Chain as atransaction, ti,j (jth transaction of the block with heighti). After that, the DP encrypts the message P into CTby using the corresponding SKA,P . As such, the indexesto ti,j , i.e., i and j, are uploaded along with CT ona Data Chain for the cross-reference in the Decryptionsubprotocol. The details are provided in Section IV-D1.

2) Decryption and retrieving a new message P : A DUassigned with the attribute α satisfying {A} intends toretrieve the message P , and the DU identifies the blockcontaining the related CT and the indexes, i and j on theData Chain. The DU then searches for the correspondingti,j on the Key Chain. Next, the DU can retrieve thePKA,P by decrypting the CT with its own ABEα,SK .As such, the DU can decrypt CT on the Data Chain withPKA,P . The details are provided in Section IV-D2.

3) Attribute updates by updating blocks on a Key Chain:The nonrevoked (this means the DUs that are reservedafter the corresponding attribute changes) and new DUsassigned with the attribute α satisfying {A} update theoutdated ABEα,SK . Meanwhile, the miners of the KeyChain update the outdated CT . The revoked DUs cannotdirectly retrieve PKA,P from the Key Chain, while thenonrevoked and new DUs can access any CT assignedwith the attribute policy {A}. The details are provided inSection IV-D3.

The proposed system can have a Data Chain and multiple KeyChains to support different and independent access policies tothe Data Chain, as shown in Fig. 1. The Data Chain ensures thedata integrity and transparency among multiple communities,and all communities can contribute to maintaining the DataChain. The multiple Key Chains allow each community to man-age their own private keys independently, using their own KeyChain to meet different requirements. Attributes are managedindependently from other Key Chains. This is useful because twoKey Chains, for example, may be managed by two communitiesthat have similar business requirements. This implies that thesetwo communities may use identical attributes expected to be

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

6 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT

mutually privacy reserved on their own Key Chain, thus leadingto the design of a cluster of Key Chains for flexible managementof the IoT.

The Data Chain and Key Chains collaborate to provide thefollowing properties.

1) Fine-grained access control: An ABE scheme integratedwith the proposed multilayer blockchain system guar-antees the secured fine-grained access control. Take theaccess control of a message M as an example. M isencrypted by a conversation key before stored in the DataChain. The conversation key is a prerequisite to accessM . Only the DUs satisfying the access policy of theconversation key can retrieve the key which is stored inthe Key Chains and encrypted by the ABE algorithm.

2) Revocable attribute of ABE: The editability of a KeyChain enables the support of attribute revocability of ABEin the Key Chain. All related conversation keys remainunchanged, while the corresponding ciphertext stored inthe Key Chain is updated if an attribute of a member isrevoked. Only DUs with attributes satisfying the attributepolicy are able to decrypt the conversation keys and, inturn, the data. As a result, the Data Chain is unaffected bythe attributes update, while the Key Chains adopt CH torun as redactable blockchains to embrace the addition andrevocation of attributes. The design of the redactable KeyChains and the details of attribute updates will be givenin Sections IV-C and IV-D3, respectively.

3) Antitampering: The tamper resistance of both the DataChain and Key Chains is inherited from the blockchain.In the case with the member update supported, the DataChain is unaffected, as discussed earlier. The Key Chaincan also guarantee the tamper resistance by conductinga new verification scheme with the editability of the CHalgorithm, as will be given in Section IV-C1. Thus, thesecure update of attributes of ABE can be ensured on theKey Chain.

C. New Design of Redactable Key Chain

As mentioned in Section IV-B, the key to achieving the revoca-ble attributes of ABE and antitampering is the key managementin the design of Key Chains. In this section, the design of a singleredactable Key Chain is presented for illustration conveniences,such as the block structure, and the new verification scheme toensure the tamper resistance of the Key Chain.

1) Block Structure: Different from the existing blockchainsuch as Bitcoin, our Key Chain is designed to be a redactableblockchain to address the conflict between the immunity ofblockchains and attribute updates of an ABE scheme. We pro-pose to use a CH algorithm, instead of traditional collision-freehash algorithms, to hash the data field of the blocks. The CHallows one to easily find an arbitrary hash collision regard-ing a specific hash value with a trapdoor, i.e., CHSK [38],and has been used for removing sensitive information fromblockchains [39]. The CH can preserve the editability of the KeyChain, while allowing the Key Chain to be updated in responseto additions and revocations of members and attributes. Here,(CHSK , CHPK) is short for (CHSK,P , CHPK,P ).

Fig. 3. Block structure of a block in a Key Chain that stores redactablemessages.

Each predefined Miner is assigned with a CHSK , as given by

PKMiner,P = ABE_Decrypt(CT ,Miner, ABEMiner,SK)(1a)

CHSK = DPKMiner,P(ESKMiner,P

(CHSK)) (1b)

where CT = ABEMiner(PKMiner,P ) on the Key Chain. Eachblock has a data field containing the CT and a random numberin the block body. Any Miner that holds CHSK is able to editthe data field of the blocks, while the CH value of the transactionremains unchanged. In this way, the chained structure of the KeyChain is maintained. Only a node of the Key Chain possessingCHSK can edit blocks. As shown on Fig. 3, each block of a KeyChain has a block header and a block body. Take Block-h, i.e.,the block at height-h, for an example. The block header containsthe following four key fields. The first two fields, c(h), i.e., theConsensus Info of the consensus algorithm, and Hp(h), i.e.,Parent Hash accounting for the linked structure, are inheritedfrom the traditional blockchain structure. n(h) and MPT (h)are new in the Key Chain for security consideration to monitorand prevent any unauthorized blockchain updates.

Body Hash n(h): This field can be regarded as the hash valueof the block body, i.e., the right-hand side of Fig. 3, exceptfor the message itself and the corresponding random number.That is,

n(h) = Hash(G(h, 1), G(h, 2), G(h, 3), . . .) (2)

where n(h) remains unchanged given that G(·) is unchanged,even in the presence of an update of the data field and the relatedrandom number. G(·) is the CH value of the transaction. Anoptional field containing all other information related to thetransactions, such as event logs or receipts defined in Ethereum-like blockchain, can also be included in the Body Hash [16].

Updating Log MPT (h): It denotes the state of the hash ofevery single random number in each transaction of the blockbody, i.e., v(i, j), all through the LOOP process defined inTable I, i.e.,

⊔hi

⊔j(ti,j) on Block-h (the latest state). This

describes a process that:1) any jth transaction starting from the first to the last of a

Block-i is traversed;2) on top of 1), any Block-i starting from the first to Block-h

is traversed.

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

YU et al.: ENABLING ATTRIBUTE REVOCATION FOR FINE-GRAINED ACCESS CONTROL IN BLOCKCHAIN-IOT SYSTEMS 7

Fig. 4. Scheme of MPT (h) delivers reliable verification for every editingconducted at block height-h, by maintaining an additional MPT dedicated forthe logs.

The immutability of MPT (h) is a clear indicator of theeffectiveness of the proposed verification scheme in terms ofoverhead and search complexity, as shown in Section IV-C2 andthe simulation result in Section V-A. MPT (h) can prevent amalicious Miner from conducting a false update, which can bean outdated content intentionally preserved without breakingthe linked structure because of the property of the CH algorithm(the users cannot distinguish any change of ciphertext by justlooking at the unchanged G(·)). Otherwise, the revoked DUsfrom an attribute α can directly access the outdated CT withtheir outdatedABEα,SK and retrieve the conversation keyPK.

There is no restriction on the data structure of MPT (h);nevertheless, it contains the following rule formulated in (3):

mapping[i][j] =⇒ Hash(v(i, j)) (3)

which indicates that a hash value of a specific v(i, j) should betraceable given the unique block height i and the transactionindex j of Block-i, when the verification scheme of MPT (h)is conducted, as shown in Fig. 4. Here, storing the state ofHash(v(i, j)) prevents the outdated v(i, j) from being directlyexposed to revoked members on the Key Chain.

The following structures are provided as possible options forMPT (h):

1) a variable stored in a smart contract through which the stateroot of the world state, in the format of a Merkle PatriciaTree (MPT) used in Ethereum, can notify the world stateof the hash of every single random number [16];

2) a new dedicated MPT in addition to the world state MPT;3) an engraved transaction in the block body that is im-

mutable and engraved inside Block-h and all blocksbeyond.

In the case where the world state MPT or the new dedicatedMPT is used, the values stored in the leaves of the tree constitutethe values of their parents and ancestors, i.e., up to the value ofthe state root. The proposed verification scheme can be achieveddue to the fact that any updates at an individual leaf, i.e., the valueof Hash(v(i, j)), would change the value of the state root storedin the block header (see more details of the MPT in [16]).

As shown on the right-hand side of Fig. 3, the block bodycontains several redactable transactions, which store encrypted

conversation keys.2 A redactable transaction has the followingfields. Here, a transaction ti,j , i.e., the jth transaction in the bodyof Block-i, is taken for an example.

1) ABE Encrypted Keym(i, j): This field stores the latest en-crypted conversation key ABEA(PK). Each transactiononly records one encrypted conversation key. This field isnot required when calculating n(i) of the block header.

2) Random Number v(i, j): This field stores the latest ran-dom number used for calculating the CH value based onm(i, j). This field is also not used when calculating n(i)in the block header.

3) The CH ValueG(i, j): It is the CH value of the transaction.This field remains unchanged as it is involved in thecalculation of n(i) in the block header.

Here, m(i, j) and v(i, j) can be jointly edited withoutchanging their CH value G(i, j), by following the algorithmCH_Update defined in Section III-B. For example, we assumem(i, j) in the transaction (m(i, j), v(i, j), G(i, j)) changes tom′(i, j), CH_Update outputs v′(i, j), which satisfies

CH_Hash (m′(i, j), v′(i, j))

= CH_Hash (m(i, j), v(i, j))

= G(i, j). (4)

The design in (4) contributes to the efficient and secureeditability of the Key Chain. On the one hand, the design savescomputation overhead by keeping only a single edited blockvalid in the presence of a change of m(i, j) and v(i, j). Thisis because G(i, j) is the only field in the block body that istaken to validate the Key Chain. This allows G(i, j) not to bechanged even with the update ofm(i, j) and v(i, j), leading to anunchangedn(h) in the block header. In other words, a valid blockwith an immutable block header can still be validated, as long asm(i, j) and v(i, j) are edited based on the algorithm CH_Updateto satisfy the property of G(i, j), as shown in (4). On the otherhand, such editability does not breach the tamper resistance ofthe Key Chain. One reason is that the editability of the block bodyis secured by CHSK (trapdoors), which are an indispensableinput to CH_Update. Another reason is that all fields in the blockheader of the Key Chain are immutable to provide high tamperresistance. Specifically, c(h) and Hp(h) jointly guarantee thatthe blockchain is robust to block tampering. MPT (h) protectsthe historical path of redactable transaction updating and pre-vents malicious Miners from exposing the outdated version ofABEA(PK) by an intentional false update.

2) Block Generation and Verification: With the transactionand block form defined above, the DPs of the permissioned KeyChain generate and broadcast transactions in the Key Chain. Incontrast, the Miners reach consensus on generating blocks basedon a collection of pending transactions.

Block verification is required when mining blocks and retriev-ing blocks from the Miners. Block-h in a Key Chain is valid ifand only if the following three conditions are all satisfied.

2In the case that the data structure of the engraved transaction is chosen forMPT (h), the immutable engraved transactions used for recording the updatehistory are contained in the block body.

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

8 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT

Verify (MPT (h), ti,j): This function implements a verifi-cation mechanism, where an additional pointer links to thepast block headers in addition to Hp(h). Here, Hp(h) denotesthe hash of the parent block header, which provides a pointerlinking to the past generation. In contrast, MPT (h) providesa pointer linking to an arbitrary ancestor block headers. Basedon MPT (h), the latest state of Hash(v(i, j)), provided in (3),is matched with the hash value of the random number con-tained in ti,j , as stated at the bottom in Fig. 4. As long asCT = ABEA(PK), the Key Chain is updated and edited (thefirst redactable transaction turning to black color and gettingupdated from the outdated version, m(97, 1) to the latest ver-sion, m′(97, 1), as shown in the top left corner of Fig. 4), itsrelated random number v(97, 1) is also updated to the latestversion, v′(97, 1), while G(97, 1), denoting the CH value of thefirst redactable transaction in Block-97, remains unchanged, asdescribed in (4). This also contributes to an unchanged n(97, 1),as shown in the block header on the right-hand side of Fig. 4.

Verify (hp(h)) and Verify (c(h)): These functions verify thelinked structure via hp(h) and the consensus requirement viac(h), respectively. They are standard to existing blockchainsystems [15], [16].

In general, the Miners owning the CHSK on a KeyChain can update the transaction ti,j containing m(i, j) andv(i, j) and append a new Block-h, where Hash(v(i, j)) canbe traceable via MPT (h). This can ensure the update of

CT = ABEA(PK) without corrupting the linked struc-ture. Note that m(i, j), i.e., the data field of ti,j , denotesABEAm

{PKAm,Pn}, where Am denotes the mth access pol-

icy and Pn denotes the nth message. MPT (h) records thestate of the hash of v(i, j) on Block-h associated with eachindividual update of (ABEAM

{PKAM ,PN})Am,Pn

A0,P0, i.e., all

ABEAM{PKAM ,PN

} from A0 to Am with messages from P0

to Pn.

D. New Design of Interchain Protocol

This section elaborates on the design of our proposed Inter-chain Protocol. Three subprotocols are discussed separately inSections IV-D1–IV-D3. Algorithm 1 presents the whole processof data sharing in our system regarding the encryption andpublishing a new message conducted by a DP, and the decryptionand retrieving the new message conducted by entitled DUs. Fur-thermore, Algorithm 2 describes the process of the encryptionand decryption used in Algorithms 1 and 3. Algorithm 3 presentsthe complete process of updating an attribute (both adding andrevoking) by updating blocks on a Key Chain.

1) Protocol of Message Encryption and Publication: Westart with the Encryption subprotocol of the Interchain Protocol,with details in the following (referring to lines 4 and 5 ofAlgorithm 1 and steps (1)–(3) of Fig. 2 on the left-hand side,denoted as Fig. 2-L),

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

YU et al.: ENABLING ATTRIBUTE REVOCATION FOR FINE-GRAINED ACCESS CONTROL IN BLOCKCHAIN-IOT SYSTEMS 9

Step 1. Initialization by TA: The unique TA of a Key Chaintakes responsibility for initializing the system, as shown in line1 of Algorithm 1 and step (1) of Fig. 2-L.

1) User register and attribute initialization: Entities registerat the TA, after which the TA allocates attributes for eachentity as a DU.

2) ABE initialization: The TA generates ABE parametersfor each attribute α with the Algorithm ABE_KeyGen, asdefined in Section III-A.

3) CH function initialization: The TA generates the parame-ters of a chosen CH algorithm according to CH_KeyGen,as defined in Section III-B.

4) Key distribution: The TA distributes the private ABE pa-rametersABEα,SK in a secure channel to the correspond-ing DUs. Recall that ABEα,SK is identity-based, i.e.,each member of α has its own unique ABEα,SK . In themeantime, the TA broadcasts the public ABE parametersABEα,PK , ∀α to the network, as shown in line 2 ofAlgorithm 1.

Step 2. Publish data by DP: ESKMiner,P (CHSK) assignedto the DUs owning an attribute Miner � {Miner} (attributeMiner satisfies the access policy {Miner}) is published on theData Chain by the DP, prior to publishing a new message. Thus,only the Miners of the Key Chain are entitled to the update pro-cess. Every new message is assigned with such a pair of CH keypair (CHSK , CHPK) regarding a chosen CH algorithm, whereESKMiner,P (CHSK) is stored in the Data Chain and CHPK ispublicly broadcast, and ABEMiner(PKMiner,P ) is stored in theKey Chain. Then, a DP publishing a new message PT is subject

to the following procedures to generate two transactions: one inthe Data Chain and the other in the Key Chain [see Steps (2)and (3) of Fig. 2-L].

1) Define access policy: The DP defines the access policy,{A}, to its data PT , i.e., PT is only accessible to the DUswhose attributes satisfy the access policy {A}.

2) Generate conversation key: The DP generates3 a pairof conversation keys (SKA,P , PKA,P ),4 for the accesspolicy {A} DP also generates a pair of conversation key(SKMiner,P , PKMiner,P ) to publish the CH private keyCHSK based on the {Miner} (see line 3 of Algorithm 1).Here, (SK,PK) is short for (SKA,P , PKA,P ) in the restof this article for simplicity.

3) Encrypt conversation key: The DP uses the ABE algorithmABE_Encrypt to encrypt the conversation (public) keyPK to CT = ABEA(PK). Here, ABEA(PK) denotesthe ABE ciphertext ofPK with its access policy {A}. Thecorresponding attribute scheme is shown on the bottomleft of Fig. 2-L, where an attribute User ⊂ α, User � Aexists.

4) Generate transaction for conversation key: The DP gen-erates and uploads a transaction to the Key Chain (see

3The key generation depends on the data encryption algorithm, which ischosen according to specific applications and beyond the scope of this article.

4In fact, the conversation keys, (SKAP , PKA,P ), can be a symmetric or anasymmetric key pair, depending on the chosen encryption algorithm. To simplifythe illustration, we only discuss the case of asymmetric encryption algorithmand conversation keys in the rest of this article. In the case of symmetric keys,the encryption key SKA,P and the decryption key PKA,P are identical, i.e.,SKA,P = PKA,P .

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

10 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT

line 1 of Algorithm 2). Here, the transaction containsCT = ABEA(PK), and the corresponding CH value andrandom number. This transaction is denoted as ti,j afterthe successful mining of the transaction on the Key Chain.

5) Encrypt data: The DP encrypts PT to the ciphertextCT by using the conversation (private) key SK, andthen, CT = ESK(PT ). Here, E denotes the encryptionoperation of the chosen encryption algorithm.

6) Generate transaction for data: The DP generates a trans-action based on the encrypted message CT and uploadsto the Data Chain. This transaction, tP , contains theindexes i and j of ti,j to its encrypted conversation keyABEA{PK}, i.e., the jth transaction of Block-i on theKey Chain, where ABEA{PK} is stored, in order toidentify the location of CT in the Key Chain. As such,a private message can be successfully published aftermining in the Data Chain.

2) Protocol of Message Decryption and Retrieval: We pro-ceed with the Decryption subprotocol of the Interchain Protocol.

This subprotocol only contains one step: Access to Data byDUs. In the case that a DU/Miner is to obtain the message PTin the transaction tP , two procedures take place to retrieve thedecryption key PK by decrypting the CT in a Key Chain (also

see lines 6 and 7 of Algorithm 1 and steps (1)–(3) of the right-hand side of Fig. 2, denoted as Fig. 2-R).

1) Retrieve conversation key from key chain: As mentionedin steps 2-(2)–2-(6) in Section IV-D1, tP of the DataChain stores the index to its encrypted conversation keyin the Key Chain. The DU first retrieves the indexes iand j from transaction tP and then obtains the latestABEA{PK} in ti,j from the Key Chain. If the attributesof the DUs satisfy the access policy {A}, e.g., Users inFig. 2-R, the DUs can retrieve the conversation keyPK bydecrypting ABEA{PK} with the corresponding privatekey ABEUser,SK . Here, the decryption algorithm refersto ABE_Decrypt (also see line 9 of Algorithm 2).

2) Retrieve data from data chain: By using the conversationkey PK and the encrypted message CT in transaction tP ,the DU can decrypt CT to PT = DPK(CT ), referringline 10 of Algorithm 2. Herein, D is the decrypt algorithm,corresponding to the encrypting algorithm E.

3) Protocol of Attribute Updates on a Key Chain: This sec-tion describes the Attribute Updates in the Interchain Protocol.In the case that new members are to be registered in attributeα, or current members are to be revoked from α, the DataChain remains stable, while the Key Chain updates those blocks

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

YU et al.: ENABLING ATTRIBUTE REVOCATION FOR FINE-GRAINED ACCESS CONTROL IN BLOCKCHAIN-IOT SYSTEMS 11

Fig. 5. Process of an attribute update is shown. Only the nonrevoked DU and new DUs obtain the updated ABE private key, so that they can access to all relateddata across the Data Chain. In contrast, the revoked DU can only access to the history with the outdated ABE private key and updated ciphertext edited by theminers.

which store encrypted conversation keys assigned with accesspolicy {A} satisfied by α, i.e., ABEA(PK), α � A. The detailof updating in a Key Chain is shown as follows.

Step 1. Update the ciphertext in the key chain: The TAruns ABE_Update and sends entities the corresponding updatedattribute parameters in any secure and encrypted channel (seeDefine of Algorithm 1, lines 1 and 2 of Algorithm 3, and steps(1a) and (1b) of Fig. 5). After that, each Miner calculates theupdated CT for any of its conversation keys PK, whose accesspolicy {A} can be satisfied by α. Here, the CT s before andafter the update are denoted as ABEA(PK) and ABE′

A(PK),respectively.

Step 2. Update transactions in the key chain: In lines 5 and 6 ofAlgorithm 3, with the aid of the CHSK , each Miner overwritesCT via the given indexes i and j with the updated CTUpdate

(also see step (2) of Fig. 5). Then, by including the updatedMPT (h) in each of the new pending Block-h, with the lateststate of the hash of the updated random number related toCTUpdate, a consensus process runs to complete appendingBlock-h to the Key Chain (see lines 7–11 of Algorithm 3and step (3) of Fig. 5). Note that a practical byzantine faulttolerance (PBFT) (or a PBFT-like) consensus algorithm [40]with a lower-bounded number of faulty nodes N ≥ 3f + 1is usually considered in a permissioned blockchain, where Ndenotes the number of Miners and f denotes the number of faultyMiners. The proposed verification scheme is applied during thisprocess to ensure the consistency among the Miners to preventa malicious Miner from conducting a false update to expose anoutdated version of the message.

When a DP publishes a new message with a newPK assignedto attribute α after the revocation (refer to steps (4) and (5)of Fig. 5), it can be found in lines 11–14 of Algorithm 3 thatonly the nonrevoked DUs with attribute α and the new DUs canconduct the decryption process to any messages on the DataChain assigned to attribute α by their own updated ABE′

α,SK .Recall that ABE′

α,SK is identity based. On the other hand, therevoked members fail to conduct the following after this updateevent (update-oriented):

1) retrieve the new PK, e.g., PKA,P2in the absence of its

corresponding new ABEα,SK ;

2) directly retrieve the past PK before the revocationfrom an updated ABE′

A{PKA,P } via its own outdatedABEα,SK .

This is because the revoked members of attribute α do nothave the updated ABEα,SK regarding the CT Update after an up-date happens. Meanwhile, the revoked members cannot directlyaccess the outdated CT from the past blocks of the Key Chain, asCT has been overwritten without breaking the linked structureby using the CH algorithm. In contrast, the nonrevoked DUs andnew DUs of α have the latest updated ABE ′

α,SK . This indicatesthat they can decrypt any CT Updates in the past and any futurenew CT s, where their attribute α � {A}.

V. ANALYSIS AND EVALUATION

In this section, we present the system analysis and simulationin terms of energy, scalability, compatibility, and security.

A. System Analysis

1) Energy Overhead: We consider the IoT devices are typi-cally FPGA (e.g., AVNETs Zedboards) or SBCs (e.g., RaspberryPi), which can be the DU or DP in the analysis regarding theenergy overhead. Such IoT devices are considered to be able tohandle the following behaviors, as illustrated in Fig. 1, includingthe following:

1) conducting the cryptographic operations for conversa-tion keys and ABE cryptographic operations (encryp-tion/decryption);

2) signing transactions by themselves when publishing newmessages;

3) exchanging network packets with the higher layer devices(e.g., the edge network or the core network).

Any other devices that are incapable of delivering and han-dling the above behaviors are considered to be the data collectors(e.g., sending sensor data to SBCs). It is pointed out that theproposed system is suitable for typical IoT systems with suchIoT devices for the following two reasons.

First, it is not the responsibility for IoT devices to maintainthe chains, as illustrated in the table on the right-hand side ofFig. 1. Rather, it is the sufficiently powerful machines (cloud

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

12 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT

TABLE IICOMPUTATION OVERHEAD AND PERFORMANCE COMPARISON BETWEEN DIFFERENT TYPES OF RASPBERRY PI WITH A SECURITY LEVEL OF 80 BITS

UNDER 30 ATTRIBUTES

*The data are sourced from [44] based on the pipelining scheme [45].**The data are sourced from [46] and [47].†ten and tde denote the execution time for encryption and decryption, respectively. tAES,en and tAES,de are considered to be equal. tAES,keygen

can be negligible because of the pipelining [45]. tAES,keygen can also be negligible as it is the TA’s responsibility. The last column shows theperformance of 4B with a 128-bit security level under 30 attributes; C = 10 000 mAh, V = 3.3 V and 5 V. We focus on the cryptographicoperations. The typical AES scheme proposed in [43] with pipelining is used to encrypt (and protect the confidentiality of) conversationkeys. We consider the widely accepted CP-ABE scheme [30] which is part of AndrABEn, an open source ABE library particularlyoptimized for Android/smartphone/IoT operating systems. The ABE library has been adopted in many existing studies, e.g., [42], [44].

servers or local data centers) that are in charge. The CH-orientedoverhead of the update process is conducted by the miners of KeyChains, while the miners also tend to be located in cloud or localdata centers. As such, IoT devices only deal with the overheadof running the cryptographic operations and transmitting theciphertext.

Second, a cluster of Key Chains is designed to provide dif-ferentiated access control of the data chain for different orga-nizations and communities, so that the overlapped attributesin different contexts (different Key Chains) can be properlymanaged. This enables IoT devices to be usually involved inonly a single Key Chain and the Data Chain, so that the totalcommunication and computation overhead on IoT devices canbe regarded as the overhead between the Data Chain and a singleKey Chain.

Upon the considered communication and computation over-head that excludes the blockchain maintenance for IoT devicesrunning across the Data Chain and the related Key Chain, wepresent the following energy analysis.

a) Computation overhead and performance: Our pro-posed system can be suited to IoT systems in terms of thecomputation overhead and performance. We take RaspberryPi for an example, because of its popularity as an SBC. Tobe specific, the computation overhead mainly includes 1) theen/decryption of the (a)symmetric encryption algorithm and 2)the en/decryption of the ABE algorithm.

A DP publishing a message needs to conduct the encryptionprocess, while the decryption process accounts for the com-putation overhead that a DU needs to incur. We utilize themetrics proposed in [41], execution time (denoted as t, andmeasured in s. We also define the number of the completeprocess flows under the given condition (T ) to evaluate theenergy efficiency/consumption, as given by

T =3.6× CV

η

where C denotes the battery capacity measured in mAh, Vdenotes the working voltage of the tested Raspberry Pi measuredin volts, and η refers to the proposed metrics in [41], i.e., theenergy consumption for a single execution measured in Joules.

It can be concluded from Table II that even the most energy-consuming type of Raspberry Pi, i.e., 1B, can execute the encryp-tion operation around 18 800 times and the decryption operation30 000 times with a 10 000-mAh battery, in the context of an80-bit security level. The most energy-efficient type, Zero, andthe most powerful 4B can both execute the encryption opera-tion around 60 000–70 000 times and the decryption operationaround 90 000–100 000 times with the same battery life. Incontrast, the optimized CPU performance of 4B can potentiallyimprove tABE,en to around 10 s and tABE,de to around 9 s witha security level of 128 bits under 30 attributes, respectively. Insuch a context with a stronger security level, Raspberry Pi 4B

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

YU et al.: ENABLING ATTRIBUTE REVOCATION FOR FINE-GRAINED ACCESS CONTROL IN BLOCKCHAIN-IOT SYSTEMS 13

can still execute the encryption operation around 6000 timesand the decryption operation around 6700 times. As a result, 4Bcan even be used in scenarios with a fixed power supply, e.g.,CCTV cameras or solar-based devices, so that higher compu-tation performance (compared to 1B and Zero) can guaranteea stronger security level, at the cost of a slightly higher energyconsumption.

b) Communication overhead and performance: Our sys-tem is also suited for IoT systems in terms of communicationoverhead and performance (with Wi-Fi, or even more energy-saving protocols, where messages can be chunked into pieces,e.g., LoRa, NBIoT, and Zigbee). As a DP, an IoT device uploadsthe ciphertext of messages and ciphertext of the conversationkey (i.e., CT and CT , respectively) to the Data Chain andKey Chain. The DP (playing the role of DU) also downloadsthe CT and CT from the Data Chain and related Key Chain,respectively.

Transmitting CT : As block ciphers, the size of CT is nearlyequal to that of PT . A 1-MB message is considered in thecomputation analysis, which has been proved acceptable basedon the result [44, Tables III–VIII].

Transmitting CT : According to [48], the communicationoverhead of transmitting CT is 50, 96, and 140 kB, for 80-, 112-,and 128-bit security level, respectively. The overhead consistsof 1) transmitting CT and 2) receiving the updating factorof SK (or ABE ′

α,SK in some ABE algorithms) from the TAwhenever an attribute is updated. The latter happens infrequentlyin practice so that we can focus on the former, which are 25, 48,and 70 kB, as the two aspects of the overhead share the overheadon a 50–50 basis [47, Fig. 5]. Thus, Wi-Fi satisfies such overheadbased on the normal LAN throughput of Raspberry Pi [46]. It isnoteworthy that the energy consumption of Wi-Fi is about 10%more than the case where all communication modules are turnedOFF [49].

2) Scalability and Compatibility: Because of the editabilityof our proposed system, this analysis focuses on the scalabilityof a Key Chain with the redactable data structure, as well asthe compatibility of our system integrated with a cloud-basedsystem. We develop a Python-based testbed which is based ona popular (4.7k stars) Python-based open source platform5 andthe Charm Crypto native libraries.6 The testbed allows us to runmultiple entities on a single machine. We can simulate multiplenodes with different roles (i.e., the TA and miners typically lo-cated in clouds/data centers, and the DPs/DUs typically runningon IoT devices) on a single 2017 iMac with 10.13.3 macOSHigh Sierra, a processor of 2.3-GHz Intel Core i5 and 16-GB2133-MHz DDR4 memory.

a) Scalability: We conduct a comparison among our threeproposed data structures of MPT (h) [see description be-low (3)], and the state-of-the-art design developed in [23] re-garding the overhead and searching complexity of H , K, andR, where the notations are described as follows.

1) H (blocks): the Block Height, starting from a block wherea given CT being inserted or updated to the latest block;

5https://github.com/dvf/blockchain6https://github.com/JHUISI/charm

Fig. 6. Comparison among our three proposed structures and the structureproposed in [23] regarding the storage overhead with respect to H , where R =K = 1000.

2) K (inserts/blocks): the Insert Rate, the average rate forDUs to insert CT s in a Key Chain;

3) R (updates/blocks): the Update Rate, the average rate ofattribute updates being applied in a Key Chain.

Recall that the data structures discussed in this articlecorrespond to the world state and smart contract used inEthereum [16]. In the segment figures, the blue curves denotethe structure of engraving transaction; the red curves denote thatof storing Hash(v(i, j)) in a smart contract as a pure variablein the existing world state MPT; the green curves denote thatof storing Hash(v(i, j)) as a new dedicated MPT in addition tothe MPT world state; the gray curves denote that of storing CTin a smart contract as a pure variable in the existing world stateMPT, vaguely discussed in [23].7 For the red and gray curves,there exist the unrelated addresses of normal accounts and smartcontracts in the same Key Chain, the number of which is denotedas C. C has an apparent impact on the searching complexity.

Overhead: It is shown in Fig. 6 that in the case ofK � R withthe growth of H , the green, red, and gray curves have a lineargrowth rate. The green grows more slowly than the red and gray,with an increasing gap between the green and red curves. Theblue curve grows the most quickly with an intersection pointto the gray curve at around H = 60, which is at quite an earlystage. In the case where a large value of H is expected to appearin a Key Chain, the blue curve has a superior growth rate, whilethe growth rate of the green curve is the lowest.

In Figs. 7 and 8, we conduct a controlled experiment thatthe values of K and R are set to be the independent variablesrespectively with a certain H = 10 000, in order to investigatethe correlations between K and the growth rate, and between Rand the growth rate. We also choose two different values of Rin Fig. 7 and K in Fig. 8 to evaluate the side effect of one toanother.

It is shown in Fig. 7(a) that the blue curve, which starts with thelargest storage space, has the smallest growth rate asK increases

7We can assume that CT is directly stored as a variable in smart contractsrather than storing Hash(v(i, j)), as the overwriting or purge of the on-chain-stored outdated CT by the latest updated version is not discussed in [23]. Thisimplies that [23] has no new verification scheme for the update process.

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

14 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT

Fig. 7. Comparison among our three proposed structures and that of [23]regarding the overhead with respect to a constant H = 10 000 and an upperbound of K in two different values of R. (a) K ∈ [0, 3000], R = 1. (b) K ∈[0, 300 000], R = 1000.

from 0 to 3000 inserts/block with R = 1 updates/block. Thiscan be found at the intersections, where K � 2500, as shownin the subfigure in the bottom-right corner of Fig. 7(a). Thered curve has the largest growth rate as K increases. For alarge value of R = 1000 within the range of K from 0 to300 000 in Fig. 7(b), the blue curve has a superior growth rate.The gray curve intersects the red curve right after K � 2000and increasingly approaches the green curve asK increases. Thegrowth rate of the green curve remains the lowest throughout therange. It can be concluded that K has a strong impact on the redcurve and a negligible impact on the blue curve among all thesestructures. Nevertheless, the blue curve is strongly impacted by alarge R, while the green curve performs the best among all thesestructures throughout the range of K regardless of the valueof R.

It is shown in Fig. 8(a) that the blue curve has a superiorgrowth rate among these structures, the gray curve performs thesecond to the worst, and the green curve has the lowest growthrate. As shown in Fig. 7, K has a much stronger effect on thegray, red and, green curves than the blue curve. As such, for asmall value of K = 1 where R ∈ [0, 200], it can be concludedthat the blue curve is incapable of the storage for a Key Chain.If a large K is set, e.g., K = 100 000, shown in Fig. 8(b), theblue curve performs the best when R ≤ 40. As R increases, the

Fig. 8. Comparison among our three proposed structures and that of [23]regarding the overhead with respect to a constant H = 10 000 and an upperbound of R in two different values of K. (a) R ∈ [0, 200], K = 1. (b) R ∈[0, 200], K = 100 000.

blue curve grows sharply, while the green curve increases slowlywith the lowest growth rate. It can be concluded that R has thestrongest effect on the blue curve and the weakest effect on thegreen curve.

The green curve is the most appropriate data structure imple-mented in the scheme of an attribute update, if the settings ofthe Key Chain that might happen in a realistic environment aretaken into account, as shown in the following:

1) K is much likely greater than R;2) both values of K and R are likely within the range

of (0, 10 000) due to the throughput restriction8 of thecommonly used consensus algorithm in a Key Chain, i.e.,PBFT.

Therefore, it is unrealistic to set a sufficiently large value ofK to support better performance of the blue curve among allthese structures. On the other hand, the green curve has the moststable and smallest growth rate with respect to both R and K.It is expected to be the most appropriate structure to update theattribute in a Key Chain.

Searching complexity: As Engraving Transaction has asearching complexity of at least O(HR), which is significantlygreater than the other three, which are only in a logarithmic order,

8The throughput (transactions per second) is limited in the case where theByzantine tolerance needs to be satisfied [50].

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

YU et al.: ENABLING ATTRIBUTE REVOCATION FOR FINE-GRAINED ACCESS CONTROL IN BLOCKCHAIN-IOT SYSTEMS 15

Fig. 9. Comparison among our proposed structures and that of [23] re-garding the searching complexity with respect to H , where R = K = 1000,C = 1000 000.

we only compare Smart Contract with Hash of Random (the redcurve in Figs. 6–8), Smart Contract with CT (the gray curvein Figs. 6–8), and MPT of Hash of Random (the green curve inFigs. 6–8). Also because an inner MPT used in a smart contract isimplemented in both Smart Contract with Hash of Random andSmart Contract with CT, which doubles the depth of the MPT,Smart Contract with Hash of Random and Smart Contract withCT have the same searching complexity, i.e.,O(log(HK + C)),as shown by the blue curve in Fig. 9. On the other hand, MPT ofHash of Random has a searching complexity ofO(log(HK)), asshown by the red curve in Fig. 9. It can be concluded that the redcurve has a smaller growth rate than the blue curve, according toFig. 9. As the value ofC increases and asymptotically stabilizes,the performance of the blue curve converges to that of the redcurve.

Therefore, it is the most appropriate to introduce a new dedi-cated MPT for storing Hash(v(i, j)) in a practical implementa-tion of the Key Chain based on both the overhead and searchingcomplexity (MPT of Hash of Random, the green curve in Figs. 6–8 and the red curve in Fig. 9). In contrast, if the unchangedstructure of block headers is preferable, e.g., Ethereum, for back-ward compatibility with the existing blockchain, Hash(v(i, j))can be stored in the existing the world state MPT as a purevariable (Smart Contract with Hash of Random, the red curvein Figs. 6–8, and the blue curve in Fig. 9). Also, EngravingTransaction (the blue curve in Figs. 6–8) can be used in a testingenvironment, where the complexity is not the focus because ofits simple implementation.

b) Compatibility: It is worth noting that our proposed sys-tem is a general decentralized framework and is generic to all theconsensus protocols, cross-chain protocols, and cryptographicalgorithms. Although we do not encourage completely relyingon cloud services due to risks on the reliability, traceability, andtransparency, the proposed structure and protocols complementto cloud services, rather than a competitor. In our scenario,blockchain is considered to be a decentralized data structure,while part of the nodes storing a copy of data running on thecloud servers can be a better option. As such, either faulty cloudservers or attacks on cloud servers cannot have strong impactson our proposed blockchain system.

B. Security Analysis

This analysis focuses on the security of our entire multilayerblockchain system. The TA is supposed to have the highestsecurity level and the immunity to cyber and physical attacks,as is typically assumed in ABE systems (this assumption stillholds for multiauthorities as the trust is only alleviated for asingle authority, while the wholeness must be still trusted [51]).

1) Attack Model: External and internal adversaries target tobreak the confidentiality and integrity of the data recorded inblockchains. Here, the external adversaries are nodes which canonly obtain the public information, such as the ciphertext of amessage CT in the Data Chain and/or the public key of anattribute α, i.e., ABEα,PK . The internal adversaries can becategorized into following two types:

1) the nodes that used to be legitimate and now are revokedin regards to a specific attribute, and have not had theirABESK updated;

2) the nodes that have been assigned with a specific attributeMiner (Key Chain).

In an update process, the internal adversaries can conducta false update to compromise the integrity (or in other words,tamper-resistance) of the redactable Key Chains with legal iden-tities and valid keys, i.e., ABESK . The proposed architectureis expected to be secure against the two types of adversaries interms of the confidentiality of the published messages in the DataChain and the integrity of the updated ciphertext CTUpdate inthe Key Chains.

2) Confidentiality: We consider that an external or internaladversary targets to obtain the encrypted message CT stored inthe Data Chain, which must not be accessible to the adversary,i.e., the adversary does not own any attribute α satisfying theaccess policy {A} of CT . In the proposed system, the orig-inal message P is encrypted to CT and stored in the DataChain, while the decryption key PKA,P is encrypted by anABE algorithm to be CT = ABEA(PKA,P ), as described inSection IV-B.

For an external adversary whose attributeα has never satisfiedthe access policy {A} before, the adversary cannot decryptCT = ABEA(PKA,P ) to obtainPKA,P , as can be guaranteedby the security of the ABE algorithm. Therefore, the externaladversary does not have the decryption key PKA,P and cannotextract the message P , as guaranteed by the security of the(a)symmetric encryption algorithm.

For an internal adversary, whose attribute β has once satisfiedthe access policy {A}, the attribute β and the encrypted conver-sation key CT are updated. As a result, the revoked adversarywithout the correspondingly updated version of ABEβ,SK can-not decrypt CT to obtain the decryption key PKA,P (see therevocation design in Section IV-D3). As a result, the internaladversary cannot obtain the message P , as it is unaware of thedecrypted key PKA,P .

3) Integrity/Antitampering: The integrity can be guaranteedas long as the lower bounds of faulty tolerance of consensusprotocols (e.g., 33% for PBFT [40] or 50% for proof ofwork [15]) are all satisfied among the Data Chain and KeyChains. The history of updates is immutable and verified duringthe consensus. Because of the synchronization among the

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

16 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT

miners [40] in a permissioned blockchain, where a PBFT (orPBFT-like) consensus is implemented, an internal adversarywith an attribute Miner conducting a false update (it is possibledue to identical CH values) and providing an outdated version ofblocks to any DUs would fail to synchronize with other honestMiners and would be detected by the system, as discussed in Sec-tion IV-C2. Therefore, by means of punishment for the internaladversaries found conducting a false-update attack, the integrityand tamper resistance of blockchains can still be ensured in ourproposed system. In addition, the updated ciphertext, CT Update,is attached with the signature of the leader of the current con-sensus round. As a result, there is no need for the DPs to remainonline, and the man-in-the-middle attack can be prevented.

VI. CONCLUSION

In this article, we proposed a new blockchain system withfine-grained access control for IoT applications, where the mem-bership and attributes of individuals, i.e., data owner, user, andminer, can be updated securely in antitamper blockchains by in-tegrating CH algorithms in a new multilayer chain architecture.The system addressed direct data leakage caused by revokedmembers and maintained good compatibility with major consen-sus protocols, cross-chain protocols, and encryption algorithms.The system can be further optimized by having multiple TAs ina decentralized manner to guarantee the superior security levelof the TA. Our system analysis and simulation showed that theproposed system can outperform existing solutions in terms ofoverhead and complexity.

By utilizing the proposed system, a secure, manageable, anddecentralized data access control, which enables large-scale andhigh-precision data management, can be readily deployed in anIoT network. The access control can, for the first time, stoprevoked users or miners from accessing not only the futuredata but the past data in a blockchain, thereby substantiallyimproving the manageability without compromising the tamperresistance of the blockchain. This allows flexible and secureblockchain-based IoT services and management to be adoptedby regional/global IoT leagues. Our analysis provided manage-rial guidelines for risk assessment, cost evaluation, and energyand storage requirements, so that appropriate technical solutionscan be designed to meet specific business requirements.

REFERENCES

[1] K. R. Choo, S. Gritzalis, and J. H. Park, “Cryptographic solutions for in-dustrial Internet-of-things: Research challenges and opportunities,” IEEETrans. Ind. Inform., vol. 14, no. 8, pp. 3567–3569, Aug. 2018.

[2] K. L. Lueth, “State of the IoT 2018: Number of IoT devices now at 7B—Market accelerating,” 2018. [Online]. Available: https://iot-analytics.com/state-of-the-iot-update-q1-q2-2018-number-of- iot-devices-now-7b/

[3] I. Ali, S. Sabir, and Z. Ullah, “Internet of things security, device au-thentication and access control: A review,” 2019. [Online]. Available:http://arxiv.org/abs/1901.07309

[4] Flexera, “Cloud computing trends: 2019 state of the cloud survey,” 2019.[Online]. Available: https://blogs.flexera.com/cloud/cloud-industry-insights/cloud-computing -trends-2019-state-of-the-cloud-survey/

[5] AWS, “Summary of the Amazon S3 service disruption in the NorthernVirginia (US-EAST-1) region,” 2017. [Online]. Available: https://aws.amazon.com/message/41926/

[6] S. Moss, “Microsoft Azure suffers outage after cooling issue,” 2018.2018. [Online]. Available: https://https://www.datacenterdynamics.com/news/microsoft-azure-suffers -outage-after-cooling-issue/

[7] F. Yingwei, “Alibaba cloud reports IO hang error in north china,”2019. [Online]. Available: https://equalocean.com/technology/20190303-alibaba-cloud-reports-io-han g-error-in-north-china

[8] R. Jhawar and V. Piuri, “Fault tolerance management in IAAS clouds,”in Proc. IEEE 1st AESS Eur. Conf. Satell. Telecommun., Oct. 2012,pp. 1–6.

[9] L. Lamport, R. Shostak, and M. Pease, “The byzantine generals problem,”ACM Trans. Program. Lang. Syst., vol. 4, no. 3, pp. 382–401, Jul. 1982.

[10] M. Ma, G. Shi, and F. Li, “Privacy-oriented blockchain-based distributedkey management architecture for hierarchical access control in the IoTscenario,” IEEE Access, vol. 7, pp. 34045–34059, 2019.

[11] A. Ouaddah, A. A. Elkalam, and A. A. Ouahman, “Towards a novelprivacy-preserving access control model based on blockchain technologyin IoT,” in Europe and MENA Cooperation Advances in Informationand Communication Technologies. New York, NY, USA: Springer, 2017,pp. 523–533.

[12] O. Novo, “Blockchain meets IoT: An architecture for scalable accessmanagement in IoT,” IEEE Internet Things J., vol. 5, no. 2, pp. 1184–1195,Apr. 2018.

[13] R. Li, T. Song, B. Mei, H. Li, X. Cheng, and L. Sun, “Blockchain forlarge-scale Internet of things data storage and protection,” IEEE Trans.Services Comput., vol. 12, no. 5, pp. 762–771, Sep./Oct. 2019.

[14] X. Wang et al., “Survey on blockchain for Internet of things,” Comput.Commun., vol. 136, pp. 10–29, 2019.

[15] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.[Online]. Available: http://bitcoin.org/bitcoin.pdf

[16] G. Wood et al., “Ethereum: A secure decentralised generalised transactionledger,” Ethereum Project Yellow Paper, vol. 151, pp. 1–32, 2014.

[17] Q. Lin, H. Yan, Z. Huang, W. Chen, J. Shen, and Y. Tang, “An ID-basedlinearly homomorphic signature scheme and its application in blockchain,”IEEE Access, vol. 6, pp. 20632–20640, 2018.

[18] I. Miers, C. Garman, M. Green, and A. D. Rubin, “Zerocoin: Anonymousdistributed e-cash from bitcoin,” in Proc. IEEE Symp. Secur. Privacy,May 2013, pp. 397–411.

[19] D. Yang, J. Gavigan, and Z. Wilcox-OHearn, “Survey of confidentialityand privacy preserving technologies for blockchains,” r3/Zcash Company,New York, NY, USA, Res. Rep., Nov. 14, 2016.

[20] IBM, “Transaction confidentiality,” 2016. [Online]. Available: https://openblockchain.readthedocs.io/en/latest

[21] S. Wang, Y. Zhang, and Y. Zhang, “A blockchain-based framework for datasharing with fine-grained access control in decentralized storage systems,”IEEE Access, vol. 6, pp. 38437–38450, 2018.

[22] Y. Rahulamathavan, R. C.-W. Phan, M. Rajarajan, S. Misra, and A. Kon-doz, “Privacy-preserving blockchain based IoT ecosystem using attribute-based encryption,” in Proc. IEEE Int. Conf. Adv. Netw. Telecommun. Syst.,Dec. 2017, pp. 1–6.

[23] Z. C. Q. Wen, Y. Guo, and D. Wu, “A blockchain-based data sharingscheme in the supply chain by IIoT,” in Proc. Int. Conf. Ind. Cyber-Phys.Syst., 2019, pp. 683–688.

[24] B. Anggorojati, P. N. Mahalle, N. R. Prasad, and R. Prasad, “Capability-based access control delegation model on the federated IoT network,” inProc. 15th Int. Symp. Wireless Pers. Multimedia Commun., Sep. 2012,pp. 604–608.

[25] L. Yeh, P. Chiang, Y. Tsai, and J. Huang, “Cloud-based fine-grained healthinformation access control framework for lightweight IoT devices withdynamic auditing and attribute revocation,” IEEE Trans. Cloud Comput.,vol. 6, no. 2, pp. 532–544, Apr. 2018.

[26] Y. Chen, W. Sun, N. Zhang, Q. Zheng, W. Lou, and Y. T. Hou, “Towardsefficient fine-grained access control and trustworthy data processing forremote monitoring services in IoT,” IEEE Trans. Inf. Forensics Secur.,vol. 14, no. 7, pp. 1830–1842, Jul. 2019.

[27] S. Roy, A. K. Das, S. Chatterjee, N. Kumar, S. Chattopadhyay, and J. J. P. C.Rodrigues, “Provably secure fine-grained data access control over multiplecloud servers in mobile cloud computing based healthcare applications,”IEEE Trans. Ind. Inform., vol. 15, no. 1, pp. 457–468, Jan. 2019.

[28] G. Fedrecheski, L. C. C. De Biase, P. C. Calcina-Ccori, and M. K. Zuffo,“Attribute-based access control for the swarm with distributed policymanagement,” IEEE Trans. Consum. Electron., vol. 65, no. 1, pp. 90–98,Feb. 2019.

[29] R. Li, H. Asaeda, and J. Li, “A distributed publisher-driven secure datasharing scheme for information-centric IoT,” IEEE Internet Things J.,vol. 4, no. 3, pp. 791–803, Jun. 2017.

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

YU et al.: ENABLING ATTRIBUTE REVOCATION FOR FINE-GRAINED ACCESS CONTROL IN BLOCKCHAIN-IOT SYSTEMS 17

[30] J. Bethencourt, A. Sahai, and B. Waters, “Ciphertext-policy attribute-basedencryption,” in Proc. IEEE Symp. Secur. Privacy, May 2007, pp. 321–334.

[31] J. Lai, R. H. Deng, and Y. Li, “Fully secure cipertext-policy hidingCP-ABE,” in Proc. 7th Int. Conf. Inf. Secur. Pract. Experience, 2011,pp. 24–39.

[32] G. Ateniese and B. de Medeiros, “On the key exposure problem inChameleon hashes,” in Security in Communication Networks, C. Blundoand S. Cimato, Eds. Berlin, Germany: Springer, 2005, pp. 165–179.

[33] S. Hohenberger and B. Waters, “Realizing hash-and-sign signatures understandard assumptions,” in Proc. Annu. Int. Conf. Theory Appl. Crypto-graphic Techn., 2009, pp. 333–350.

[34] E. K. Kogias et al., “Enhancing bitcoin security and performance withstrong consistency via collective signing,” in Proc. 25th USENIX Secur.Symp., Austin, TX, USA, 2016, pp. 279–296.

[35] S. Popov, “The tangle,” IoTA Found., Berlin, Germany, Tech. Rep., Version1.3, 2016, p. 131.

[36] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford,“OmniLedger: A secure, scale-out, decentralized ledger via sharding,” inProc. IEEE Symp. Secur. Privacy, May 2018, pp. 583–598.

[37] V. Buterin, “Chain interoperability,” r3, New York, NY, USA, Res. Rep.,Sep. 9, 2016.

[38] J. Camenisch, D. Derler, S. Krenn, H.C. Pöhls, K. Samelin, and D.Slamanig, “Chameleon-hashes with ephemeral trapdoors,” in Proc. Int.Workshop Public-Key Cryptography, 2017, pp. 152–182.

[39] G. Ateniese, B. Magri, D. Venturi, and E. Andrade, “Redactableblockchain—or—rewriting history in bitcoin and friends,” in Proc. IEEEEur. Symp. Secur. Privacy, Apr. 2017, pp. 111–126.

[40] M. Castro and B. Liskov, “Practical byzantine fault tolerance,” in Proc.3rd USENIX Symp. Oper. Syst. Des. Implementation, Berkeley, CA, USA,Feb. 1999, pp. 173–186.

[41] M. Ambrosin et al., “On the feasibility of attribute-based encryptionon Internet of things devices,” IEEE Micro, vol. 36, no. 6, pp. 25–35,Nov./Dec. 2016.

[42] J. Daemen and V. Rijmen, AES Proposal: Rijndael, 1999.[43] M. Ambrosin, M. Conti, and T. Dargahi, “On the feasibility of attribute-

based encryption on smartphone devices,” in Proc. Workshop IoT Chal-lenges Mobile Ind. Syst., 2015, pp. 49–54.

[44] P. Singh and K. Deshpande, “Performance evaluation of cryptographicciphers on IoT devices,” 2018. [Online]. Available: http://arxiv.org/abs/1812.02220

[45] T. Subashri et al., “Pipelining architecture of AES encryption and keygeneration with search based memory,” in Recent Trends in NetworkSecurity and Applications. Berlin, Germany: Springer, 2010, pp. 224–231.

[46] R. Zwetsloot, “Raspberry Pi 4 specs and benchmarks.” [On-line]. Available: https://magpi.raspberrypi.org/articles/raspberry-pi-4-specs-benchmarks, Accessed on: Oct. 1, 2019.

[47] Alex, “How much power does the Pi4B use? Power measurements.”[Online]. Available: https://www.raspberrypi-spy.co.uk/2018/11/raspberry-pi-power-consumptio n-data, Accessed on: Oct. 1, 2019.

[48] X. Wang, J. Zhang, E. M. Schooler, and M. Ion, “Performance evaluationof attribute-based encryption: Toward data privacy in the IoT,” in Proc.IEEE Int. Conf. Commun., Jun. 2014, pp. 725–730.

[49] MATT, “Raspberry Pi power consumption data.” [Online]. Avail-able: https://raspi.tv/2019/how-much-power-does-the-pi4b-use-power-measuremen ts, Accessed on: Oct. 1, 2019.

[50] D. Mingxiao, M. Xiaofeng, Z. Zhe, W. Xiangwei, and C. Qijun, “A reviewon consensus algorithm of blockchain,” in Proc. IEEE Int. Conf. Syst.,Man, Cybern., Oct. 2017, pp. 2567–2572.

[51] M. Chase, “Multi-authority attribute based encryption,” in Theory of Cryp-tography, S. P. Vadhan, Ed. Berlin, Germany: Springer, 2007, pp. 515–534.

Guangsheng Yu received the B.Sc. degree intelecommunication network engineering and M.Sc.degree in computer network from the University ofNew South Wales, Sydney, NSW, Australia, in 2011and 2015, respectively. He is currently working to-ward the Ph.D. degree in computer engineering andsecurity with the Faculty of Engineering and Informa-tion Technology, University of Technology, Sydney.

His current research interests include blockchainconsensus algorithms, scaling blockchains, privacy inblockchains, and Internet of Things application withblockchains.

Xuan Zha received the dual Ph.D. degree in cybersecurity from the School of Cyberspace Security,Beijing University of Posts and Telecommunications,Beijing, China, and the Faculty of Engineering andInformation Technology, University of TechnologySydney, Ultimo, NSW, Australia, in 2019.

She is currently an Engineer with the ChinaAcademy of Information and Communications Tech-nology, Beijing. Her current research interests in-clude wireless network security, Markov theory,blockchain, and vehicular ad hoc networks.

Xu Wang received the B.E. degree from the BeijingInformation Science and Technology University, Bei-jing, China, in 2010, and the Ph.D. degree from theBeijing University of Posts and Telecommunications,Beijing, in 2019, both in computer science.

His current research interests include blockchain,cyber security, complex networks, social networks,and network dynamics.

Wei Ni (Senior Member, IEEE) received the B.E.and Ph.D. degrees in electronic engineering fromFudan University, Shanghai, China, in 2000 and 2005,respectively.

He is currently a Team Leader with CSIRO, Syd-ney, NSW, Australia, and an Adjunct Professor withthe University of Technology Sydney, Ultimo, NSW.He was a Postdoctoral Research Fellow with Shang-hai Jiao Tong University from 2005 to 2008, theDeputy Project Manager with the Bell Labs R&ICenter, Alcatel/Alcatel-Lucent from 2005 to 2008,

and a Senior Researcher with Devices Research and Development, Nokia, from2008 to 2009. His research interests include stochastic optimization, gametheory, graph theory, and their applications to network and security.

Kan Yu received the B.Eng. degree in communicationengineering from the Beijing University of Posts andTelecommunications, Beijing, China, in 2005, theM.Eng. degree in communication engineering fromthe Chalmers University of Technology, Gothenburg,Sweden, in 2010, and the Ph.D. degree in computerscience from Malardalen University, Västerås, Swe-den, in 2014.

He was a Visiting Scholar with the University ofSydney in 2015. He worked with the Huawei BeijingResearch Centre and Huawei Australia in 2007 and

2016, respectively. He is currently a Lecturer in Internet of Things (IoT) with LaTrobe University, Bendigo, VIC, Australia. His current research interests includeapplying blockchain to IoT, industrial IoT, smart cities, and smart agriculture.

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

18 IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT

Ping Yu is working toward the dual Ph.D. degree incyber security from the Network Security ResearchCentre, Beijing University of Posts and Telecommu-nications, Beijing, China, and the Global Big DataTechnologies Centre, Faculty of Engineering andInformation Technology, University of TechnologySydney, Ultimo, NSW, Australia.

Her research interests include information security,cryptography, and network security.

J. Andrew Zhang (Senior Member, IEEE) receivedthe B.Sc. degree from Xi’an Jiaotong University,Xi’an, China, in 1996, the M.Sc. degree from theNanjing University of Posts and Telecommunica-tions, Nanjing, China, in 1999, and the Ph.D. degreefrom the Australian National University, Canberra,ACT, Australia, in 2004, all in telecommunicationengineering.

He is currently an Associate Professor with theSchool of Electrical and Data Engineering, Universityof Technology Sydney, Ultimo, NSW, Australia. He

has authored or coauthored more than 150 papers in leading internationalJournals and conference proceedings and has received five best paper awardsfor his work. His research interests include signal processing for wirelesscommunications and sensing and autonomous vehicular networks.

Ren Ping Liu (Senior Member, IEEE) received hisB.E. degree in telecommunication engineering andM.E. degree in computer engineering from the Bei-jing University of Posts and Telecommunications,China, and the Ph.D. degree in electrical and com-puter engineering from the University of Newcastle,Australia, in 1985, 1988, and 1996, respectively.

He is a Professor with the School of Computing andCommunications, University of Technology Sydney,Ultimo, NSW, Australia, where he leads the NetworkSecurity Laboratory. Prior to that, he was a Principal

Scientist with CSIRO, Sydney, NSW, where he led wireless networking researchactivities. He specializes in protocol design and modeling and has deliverednetworking solutions to a number of government agencies and industry cus-tomers. He has authored or coauthored more than 100 research publicationsand has supervised more than 30 Ph.D. students. His research interests includeMarkov analysis and quality-of-service scheduling in wireless local area net-works, vehicular ad hoc networks, Internet of Things, long-term evolution, 5G,software-defined networking, and network security.

Prof. Liu was the recipient of the Australian Engineering Innovation Awardand the CSIRO Chairman medal.

Y. Jay Guo (Fellow, IEEE) received the bachelor’sand master’s degrees in electromagnetic field andmicrowave from Xidian University, Xi’an, China, in1982 and 1984, respectively, and the Ph.D. degree inantennas and electromagnetic scattering from Xi’anJiaotong University, Xi’an, China, in 1987.

He is currently a Distinguished Professor in Facultyof Engineering and Information Technology and thefounding Director of the Global Big Data Technolo-gies Centre, University of Technology Sydney, Ul-timo, NSW, Australia. He has authored or coauthored

more than 350 research papers and holds 24 patents in antennas and wirelesssystems. His research interests include antennas, millimeter-wave and terahertzcommunication and sensing systems, and big data.

Prof. Guo is a Fellow of the Australian Academy of Engineering and Tech-nology and the Institution of Engineering and Technology and a member of theCollege of Experts of the Australian Research Council.

Authorized licensed use limited to: University of Technology Sydney. Downloaded on February 14,2020 at 05:13:44 UTC from IEEE Xplore. Restrictions apply. View publication statsView publication stats