Blockchain-Based Data Access Control and Key Agreement System in IoT Environment

Abstract

Recently, with the increasing application of the Internet of Things (IoT), various IoT environments such as smart factories, smart homes, and smart grids are being generated. In the IoT environment, a lot of data are generated in real time, and the generated IoT data can be used as source data for various services such as artificial intelligence, remote medical care, and finance, and can also be used for purposes such as electricity bill generation. Therefore, data access control is required to grant access rights to various data users in the IoT environment who need such IoT data. In addition, IoT data contain sensitive information such as personal information, so privacy protection is also essential. Ciphertext-policy attribute-based encryption (CP-ABE) technology has been utilized to address these requirements. Furthermore, system structures applying blockchains with CP-ABE are being studied to prevent bottlenecks and single failures of cloud servers, as well as to support data auditing. However, these systems do not stipulate authentication and key agreement to ensure the security of the data transmission process and data outsourcing. Accordingly, we propose a data access control and key agreement scheme using CP-ABE to ensure data security in a blockchain-based system. In addition, we propose a system that can provide data nonrepudiation, data accountability, and data verification functions by utilizing blockchains. Both formal and informal security verifications are performed to demonstrate the security of the proposed system. We also compare the security, functional aspects, and computational and communication costs of previous systems. Furthermore, we perform cryptographic calculations to analyze the system in practical terms. As a result, our proposed protocol is safer against attacks such as guessing attacks and tracing attacks than other protocols, and can provide mutual authentication and key agreement functions. In addition, the proposed protocol is more efficient than other protocols, so it can be applied to practical IoT environments.

1. Introduction

As IoT devices are deployed in various environments such as houses, farms, factories, and grids, the development and spread of smart cities such as smart homes, smart factories, and smart grids continues. As the amount of data generated and collected by IoT devices increases exponentially, it is predicted that the total amount of data generated annually by 2024 will reach 149 ZB [1]. IoT data are used as source data for services related to finance, medical care, artificial intelligence, and electricity bills.

Data access control technology that can provide IoT data to data users (e.g., managers of smart grids and financial institutions) in an appropriate service environment is required to utilize IoT data as source data for various services. To efficiently utilize IoT data and provide them to data users, the gateway collects IoT data, outsources them to a cloud server, and manages the data through the cloud [2,3]. However, the generated IoT data contain sensitive information such as user personal information, so privacy cannot be guaranteed if the data are indiscriminately viewed by institutions using the data. Moreover, data outsourcing also creates security and privacy concerns because it separates data ownership and data management [4]. Therefore, access control for the data users is necessary to protect personal information and provide only data that meet the attributes of the data user that will use the data. To this end, data access control technology using attribute-based encryption (ABE) [5] has recently attracted attention as a promising technology.

In the case of ciphertext-policy ABE (CP-ABE) [6], each original datum is encrypted in relation to the access control structure set in advance by the encryptor. Data users can only decrypt the ciphertext if the set of attributes he or she uses satisfies the ciphertext access structure. IoT data producers need to be able to provide their data only to organizations that want them through the gateway to ensure privacy. Therefore, since the access structure for IoT data must be determined, using CP-ABE is suitable for the IoT environment.

Additionally, if the cloud server manages the computation and communication of most systems, including outsourced data and access control, it is vulnerable to a single point of failure and data management due to centralization issues [7]. In order to solve this problem, research on the decentralization of cloud servers using blockchains has recently been conducted [8,9]. On the other hand, since IoT data are transmitted and received through open channels, malicious attackers can steal the data to perform attacks such as invasions of privacy, data exfiltration, and data abuse. Therefore, to solve these problems, it is necessary to study the application of ABE and blockchain for data privacy provision and access control. In addition, in order to securely store and provide data, gateways, cloud servers, and data users need to verify that they are valid entities through key agreement.

Therefore, in this paper, we suggest a security system that provides authentication while providing access control. We analyze the trends and problems of systems for secure access control and management of data generated in the IoT environment, and present the direction of blockchain-based access control and key agreement to solve these problems.

The main motivations and contributions of this study based on the problems and challenges mentioned above are as follows:

• Unlike existing IoT data access control systems using blockchains, the proposed system guarantees data protection through mutual authentication and key agreement. The detailed method is as follows: The proposed system provides mutual authentication based on bilinear pairing and secure key agreement based on the DBDH assumption. In addition, it provides secure data outsourcing and data access control based on CP-ABE by using the session key generated through key agreement.
• The gateway and the cloud server generate a session key through key agreement and mutual authentication, and the gateway can safely outsource data through the session key. Gateways can also prove data validation through self-signing when uploading data. Data users can request data to the cloud server and verify the received data through the gateway’s signature. Thus, the system can provide data accountability.
• Since the proposed system utilizes a public permissioned blockchain, only data users, gateways, and cloud servers registered with the TA (trusted authority) can use the blockchain as a participant. By auditing the blockchain through data users, nonrepudiation of data can be avoided.
• Detailed formal security validation utilizing the widely accepted “AVISPA Software Verification Tool” [10], “indistinguishability game against selective chosen plaintext attack (IND-CPA)”, and “informal (nonmathematical) security analysis” shows that the suggested system guarantees safety against multiple potential attacks on smart city environments utilizing IoT.
• Testbed experiments with cryptographic primitives in a laptop environment were performed using the popular “Multiprecision Integer and Rational Arithmetic Cryptographic Library (MIRACL)” [11].

The remainder of this paper is organized as follows: Section 2 reviews papers on data access control using CP-ABE and blockchain in IoT environments. Section 3 outlines the proposed system model, blockchain, access structure, bilinear pairing, DBDH assumption, and adversary model. Section 4 describes our proposed data access control system. Section 5 describes the results of formal security validation using AVISPA and IND-CPA, and Section 6 describes the results of informal security analysis. We analyze the efficiency and security features of the protocol in Section 7. Finally, Section 8 concludes the paper.

2. Related Works

Numerous studies on data access control using CP-ABE have been proposed; its application to the IoT environment has also been proposed. In 2007, Ling and Newport [12] proposed a CP-ABE method that can be applied to both positive and negative attributes using an AND gate access structure. They proposed a structure that has been proven to be secure with plaintext selected under the decisional bilinear Diffie–Hellman (DBDH) assumption. Lewko and Waters [13] suggested a CP-ABE method based on multiauthority, and argued that their system does not require collaboration between rapid institutions. However, in the initialization phase, all agencies must set key parameters, so their structure is impractical for large-scale systems.

In order to efficiently store and manage data, systems in which data are outsourced to a cloud server and controlled have been also proposed [14,15,16,17,18]. Yeh et al. [14] proposed a system that can collect patient information from IoT devices and use it for smart healthcare. For data integrity in their system, data are pre-encrypted before uploading to cloud servers, giving patients access control to data. Miao et al. [15] proposed a CP-ABE-based data access control and keyword search system structure in a cloud-enabled mobile crowdsourcing environment. Liu et al. [16] proposed an e-healthcare record system that uploads and shares health data collected from wearable IoT devices to a cloud server and protects the personal information of patients based on CP-ABE. Ding et al. [17] proposed a structure that can ensure data security in IoT systems by using a pairing-free-based CP-ABE in IoT systems. Lu et al. [18] proposed a secure data sharing system in cloud computing that ensures data privacy protection in resource-constrained mobile terminals. However, since these studies are data access control systems based on cloud servers, a centralization problem may occur, which may cause a single-point-of-failure problem.

Therefore, CP-ABE systems have been proposed for access control of IoT data based on blockchains to solve this centralization problem [19,20,21,22,23,24]. In 2018, Zhang et al. [19] proposed a user-controlled data sharing system with privacy protection using fine-grained access control based on a blockchain and CP-ABE. In 2019, Ding et al. [20] also proposed an ABE access control system for IoT. Blockchain technology was used to record the distribution of properties to prevent single-point errors and data tampering. They demonstrated that authentication can ensure strict access control, but there is no algorithm or protocol for this in their system. Guo et al. [21] suggested a multiauthority blockchain-based ABE protocol for telemedicine systems. Unfortunately, Son et al. [25] figured out that Guo et al.’s protocol [21] is not suitable for real-world environments as patients must maintain their own attribute keys. Yang et al. [22] proposed an EHR sharing system utilizing cloud computing based on ABE and blockchains. In 2021, Wei et al. [23] designed an ABE algorithm for multiauthority scenarios with resource-constrained IoT devices in mind, thereby shifting data management to a blockchain instead of a central server. Qin et al. [24] also proposed a blockchain-based CP-ABE system using cloud computing with consideration to the resource limitations of IoT devices. However, the authentication they proposed [19,20,21,22,23,24] is authentication for data, not mutual authentication between entities participating in communication. For secure communication, the session key must be calculated by performing mutual authentication and key agreement.

Blockchain-based CP-ABE access control systems have been proposed in various smart environments using IoT devices. However, most studies do not provide mutual authentication, key agreement, data access control, validation and accountability at the same time. Therefore, we propose a structure that guarantees a secure data outsourcing process through mutual authentication and key agreement and provides data access control using CP-ABE technology. In addition, our proposed structure proposes an access control system that provides functions of data nonrepudiation, data accountability, and data validation based on a blockchain.

3. System Models and Preliminary Work

We present the proposed system model for IoT data access control considering data users in the different IoT environments. We describe blockchain characteristics, ABE, and the adversary model used in our system.

Table 1. Notations (author’s own processing).

Notations & Abbreviations	Meanings
IoT	Internet of Things
ABE	Attribute-based encryption
CP-ABE	Ciphertext-policy ABE
DBDH	Decisional bilinear Diffie-Hellman
$D{U}_i$, $DUI{D}_i$, $DUP{W}_i$	ith data user
	and his/her identity and password, respectively
$G{W}_j$, $GI{D}_i$	jth gateway and its identity, respectively
$CS$, $I{D}_{cs}$	Cloud server and its identity, respectively
$HDUI{D}_i,PGI{D}_j,PI{D}_{cs}$	The hidden identity of data user,
	gateway, and cloud server, respectively
$TA$	Trusted authority
$R_{cs}$, $r_i$, $r_j$, $k_{TA}$	The secret key of $CS$, $D{U}_i$, $G{W}_j$, and $TA$, respectively
$P{K}_{cs}$, $P{K}_i$, $P{K}_j$, $P{K}_{TA}$	The public key of $CS$, $D{U}_i$, $G{W}_j$, and $TA$, respectively
$ATTR{I}_i$	The attribute of $D{U}_i$
$att{r}_i$	The attribute private key of $D{U}_i$
$\mathcal{T}$, $\tau$	Access tree and root of tree
$SK$	The session key established among $G{W}_j$ and $CS$
K	The data decryption key
$h_1,h_2$	Hash function and map-to-point hash function
$\left|\right|$	Data concatenation operator
⊕	Bitwise exclusive-or operator

is an explanation of abbreviations and symbols used in this paper.

3.1. System Model

Our proposed data access control system model is described in Figure 1. The proposed system model consists of the following four entities:

• Cloud Server (CS): A set of CSs forms a “CS network”, where a distributed ledger is maintained for block additions. CSs are honest but curious entities. Moreover, the CS receives the IoT data and provides the data to the data user when the user’s attribute value matches. In addition, the CS uploads data such as data attributes, signature values, and public keys to the blockchain to solve the centralization problem.
• Gateway (GW): Gateways are distributed in various smart environments that make up the smart city. The gateway collects IoT data from each environment and uploads them to a cloud server with attribute-based encryption appropriate for each attribute.
• Data User (DU): Data user refers to a person who charges fees using IoT data or provides services such as artificial intelligence, finance, and medical care using IoT data. The data user requests an attribute key from the TA. After that, the TA can request data matching the attribute from the cloud server, and can obtain the original data by decrypting the received data through the attribute key.
• Trusted Authority (TA): All data users, gateways, and cloud servers must register with a fully trusted $TA$.
• Blockchain: In the proposed system model, the blockchain is composed of a public permissioned blockchain. To solve the problem of centralization of CSs, the blockchain stores the storage address of data stored in the CS, the public key of each component, hash, data access tree, etc., on behalf of the CS. The “practical Byzantine fault tolerance (PBFT) consensus algorithm” [26] has been applied for adding blocks to existing blockchains, verifying blocks, and voting-based consensus algorithms. Data users audit the blockchain ledger. All blockchain members can read the ledger, but only data users and cloud servers can upload transitions to the blockchain. When the DU requests information from the CS, the CS checks whether the access tree of the requested information and the attributes of the DU match through the blockchain. If the attributes match the access tree, the CS passes the encrypted data to the DU.

In the setup phase, $TA$ generates and publishes parameters necessary for the system and tree. During the registration phase, $DU$s, $GW$s, and $CS$ are registered with $TA$ through closed channels. Through the attribute key generation phase, $DU$ can ask $TA$ for a key that matches his attribute, and use the acquired attribute key to decrypt the encrypted data. In the authentication phase, $GW$ and $CS$ perform authentication and key agreement for data upload. In the data upload phase, $GW$ uploads data to the cloud server through the agreed session key. Simultaneously, $GW$ uploads the signature as a verification value to verify its own data and the upload time to the blockchain. In addition, $CS$ uploads the attribute tree value of the data and the record address value where the data are stored to the blockchain. In the data request and provide phase, $DU$ requests data from $CS$, and $CS$ verifies the $DU$’s request message, checks the attribute value of $DU$ through the blockchain, and transmits the corresponding data to $DU$. $DU$ downloads the verification value from the blockchain for the transmitted data, verifies that they are valid data, and can decrypt the data with its own attribute key.

3.2. Blockchain

A blockchain is a distributed data storage system that can solve the single-point-of-failure problem that can occur by being concentrated in the cloud server. The decentralized nature of blockchains can provide nonrepudiation of data, accountability, and transparency. In addition, the timestamp recorded on the blockchain allows blockchain participants to know the transaction generation time [27]. In general, four types of blockchain platforms are defined:

• Public permissionless blockchain: A public permissionless blockchain provides a ’low trust’ environment where anyone can run nodes and participate in the network. A public permissionless blockchain can be accessed by anyone, and any node can participate in the consensus protocol. Moreover, anyone can read the entire ledger of transactions.
• Public permissioned blockchain: Public permissioned blockchains have rules that determine who can participate in the verification process and launch nodes. They are commonly used by public institutions such as government agencies, businesses, or educational institutions. Whitelisted nodes can participate in the consensus mechanism. Owners create validator nodes that define governance rules for the blockchain, including those who can create new nodes or write to the blockchain. However, read access can be used by anyone who makes the blockchain publicly accessible.
• Private permissionless blockchain: A private permissionless blockchain has no restrictions on who can participate in the consensus mechanism. However, unlike public permissionless convex chains, there are restrictions on who can read and write content on the blockchain.
• Private permissioned blockchain: These blockchains are controlled by a unique group of one or several owners who determine the participants in the consensus mechanism. Only selected user groups can read or write to these blockchains. If public verification of records is not required, consider private permissioned blockchains.

In this paper, only cloud servers and data users of smart cities can write to the blockchain. Therefore, in this paper, a public permission-type blockchain is adopted, and the consensus algorithm uses PBFT.

3.3. Access Structure

According to [6], we use the following access tree as an access structure.

Assuming that $\mathcal{T}$ is an access tree, $\mathcal{T}$ includes $(v,nu{m}_v,threshol{d}_v,par\left(v\right),ind\left(v\right))$, where v is a node of $\mathcal{T}$, $threshol{d}_v$ is threshold value of v, $nu{m}_v$ is the number of children nodes of v, $ind\left(v\right)$ is unique index of v, and $par\left(v\right)$ is a parent node of v. Assuming v is an internal node, v is the threshold gate denoted by $AND$ and $OR$. $AND$ and $OR$ gates are defined as follows: when $0<threshol{d}_v\le nu{m}_v$, it is an $AND$ gate if $threshol{d}_v=nu{m}_v$ and an $OR$ gate if $threshol{d}_v=1$.

Moreover, in the case where v is a leaf node, it is described as the attributes $threshol{d}_v=1$. To fit $\mathcal{T}$ with attribute set $att\left(v\right)$, $att\left(v\right)$ have to match the threshold gate at root node $\tau$ of $\mathcal{T}$. Here, $att\left(v\right)$ is defined only if v is a leaf node and represents an attribute related to leaf node v in the tree. In the first case, $\tau$ is an attribute and its key satisfies the access tree $att\left(v\right)$. In the following case, if $\tau$ is a threshold gate whose child node is an attribute, the access tree is satisfied when $att\left(v\right)$ holds the threshold gate of $\tau$. In other cases, such as where $\tau$ is a threshold gate and the child nodes are also threshold gates, the method in the second case can be applied recursively to solve it.

3.4. Bilinear Pairing

Let $G_1$ and $G_2$ be recursive groups with large prime q, and let them be addition and multiplication groups, respectively. Then, a map that satisfies the following conditions can be applied to the bilinear map $e:G_1\times G_1\in G_2$.

• Efficiency: For all $P,Q\in G_1$, $e(P,Q)$ are able to be computed in polynomial time.
• Bilinearity: For all $P,Q\in G_1$, and for all $x,y\in Z_p^{\ast }$, $e(xP,yQ)$ is $e{(P,Q)}^{xy}$.
• Nondegeneracy: Existing $P,Q\in G_1$, then $e(P,Q)\ne 1_{G_1}$, where $1_{G_1}$ is the identifying element of $G_1$.

3.5. Decisional Bilinear Diffie–Hellman (DBDH) Assumption

Let $G_1$ be a group of order q; P be a generator of $G_1$; and $a,b,c,z\in Z_q$ be chosen randomly. The DBDH assumption [28] is that it is difficult for a probabilistic polynomial time adversary $\mathcal{A}$ to distinguish $(P^a,P^b,P^c,e{(P,P)}^{abc})$ from $(P^a,P^b,P^c,e{(P,P)}^z)$. The advantage $\epsilon$ of $\mathcal{A}$ is defined as follows:

$$\begin{array}{c}\hfill |Pr[\mathcal{A}(P^a,P^b,P^c,e{(P,P)}^{abc})=1]-Pr[\mathcal{A}(P^a,P^b,P^c,e{(P,P)}^z)=1]|\ge \epsilon \end{array}$$

(1)

If there is no $\mathcal{A}$ can decide whether $e{(P,P)}^z=e{(P,P)}^{abc}$, that is deciding whether $z=abc$ or $z\in Z_q$, with a non-negligible advantage, the DBDH assumption holds.

3.6. Adversary Model

We adopt the widely accepted “Dolev–Yao (DY) threat model” [29] for cryptographic analysis of protocol security. A malicious adversary could, according to the assumptions of the DY model, intercept messages sent over public channels. Attackers can also modify, insert, delete, or eavesdrop on hijacked messages.

• An adversary takes full control of transmitted messages sent over an open wireless channel and learns from the messages. The attacker can then modify, remove, or insert a legitimate message.
• In polynomial time, an adversary is able to only guess one value, because guessing more than one value at a time is “computationally infeasible”, for example, guessing an ID and password at the same time.
• An adversary can steal or obtain a valid smart card. The adversary can perform a power analysis attack [30,31] on a smart card to steal sensitive information stored on the smart card.

In addition, this paper adopts the assumption of the “CK adversary model” [32], which is a more powerful attack model considering the actual environment. The CK attack model is considered the de facto standard for modeling key exchange protocols. Therefore, in the CK model, for the session key agreed upon between the communicating parties to be secure, the key exchange protocol must minimize the impact of persistent (long-term) or temporary (short-term) secret leaks.

4. Proposed Data Access Control System for IoT Environments

In this section, we propose a method of access control for IoT data, which overcomes the limitations and security pitfalls of previous access control methods. In addition, the proposed protocol guarantees stronger security through authentication in the existing access control method.

4.1. Setup Phase

TA generates public parameters for use in the system’s attribute-based encryption and blockchain. The following steps are followed:

Step SP1: $TA$ generates $G_1$ and $G_2$ in the same order q, where $G_1$ is an additive cyclic group and $G_2$ is a multiplicative cyclic group. Then, $TA$ generates a bilinear map $e:G_1\times G_1$. $TA$ chooses the secret keys $k_{TA}$ and $\zeta$ in $Z_q^{\ast }$, and chooses $P\in G_1$, where P is a generator. Moreover, $TA$ chooses the hash functions $h_1:{\{0,1\}}^{\ast }\to Z_q$ and $h_2:{\{0,1\}}^{\ast }\to G_1$.

Step SP2: $TA$ computes the public key $P{K}_{TA}=k_{TA}\ast P$, a factor of an attribute key $F=\frac{P}{k_{TA}}$ and a factor for decryption $e{(P,P)}^{\zeta }$. Then, $TA$ publishes ($G_1,G_2,q,e,P,P{K}_{TA},F,e{(P,P)}^{\zeta },$$h_1,h_2$).

4.2. Registration Phase

For key agreement and authentication, $GW$, of the IoT environment, $CS$ and $DU$ have to register at $TA$. This phase runs through a secure channel.

4.2.1. Cloud Server Registration Phase

This phase is also executed over the secure channel:

Step CSR1: A cloud server $CS$ picks its identity $I{D}_{cs}$ and generates a random number $c_{cs}$. $CS$ computes $PI{D}_{cs}=I{D}_{cs}\oplus c_{cs}$. Then, $CS$ sends $\langle PI{D}_{cs},$$c_{cs}\rangle$ to the trusted authority $TA$ through a closed channel.

Step CSR2: After that, $TA$ stores $PI{D}_{cs}$ in a its secure database. $TA$ computes $R_{cs}=h(k_{ta}\left|\right|c_{cs})$ as $CS$’s private key. After that, $TA$ sends $\langle R_{cs}\rangle$ to $CS$ over a secure channel.

Step CSR3: $CS$ computes the public key $P{K}_{cs}=P\ast R_{cs}$.

4.2.2. Data User Registration Phase

When a new data user $D{U}_i$ registers with $TA$, the following steps are followed:

Step UR1: $D{U}_i$ chooses unique identity and password $DUI{D}_i$ and $DUP{W}_i$. $D{U}_i$ generates random nonces $I{U}_i$ and $a_i$, where they are in $Z_q^{\ast }$. Then, $D{U}_i$ computes $HDUI{D}_i=h_1(DUI{D}_i\left|\right|I{U}_i)$ and $HDUP{W}_i=h_1(DUI{D}_i\left|\right|I{U}_i\left|\right|DUP{W}_i)$. After that, $D{U}_i$ sends $HDUI{D}_i$, $HDUP{W}_i\oplus a_i$ to $TA$ via closed channels.

Step UR2: After $TA$ receives the request message, $TA$ computes $TI{D}_i=(HDUI{D}_i\ast k_{TA})\ast P{K}_{TA}$ and $A_i=TI{D}_i\oplus (HDUP{W}_i\oplus a_i)$. $TA$ stores $HDUI{D}_i$ with $TI{D}_i$ in a its secure memory and stores $A_i$ in a smart card $SC$. Then, $TA$ issues $SC$ to $D{U}_i$. At the same time, $TA$ sends $\langle h_1\left(TI{D}_i\right),HDUI{D}_i\rangle$ to $CS$ via closed channels.

Step UR3: After receiving $SC$, $D{U}_i$ computes $Z_i=h_1(DUI{D}_i\left|\right|DUP{W}_i)\oplus I{U}_i$, $B_i=A_i\oplus a_i=TI{D}_i\oplus HDUP{W}_i$, $C_i=h_1(TI{D}_i\left|\right|HDUP{W}_i)$, and $D_i=r_i\oplus HDUP{W}_i$. Then, $D{U}_i$ stores $Z_i$, $B_i$, $C_i$ and $D_i$ into $SC$ and computes a public key as $P{K}_i=r_i\ast P$.

Step UR4: After receiving message, $CS$ computes $MC{S}_i=h_1(HMI{D}_i\left|\right|R_{cs})$ and stores $MC{S}_i$ in its secure database. $CS$ also stores $h_1\left(TI{D}_i\right)$ with $HDUI{D}_i$.

4.2.3. Gateway Registration Phase

In this phase, the following steps are performed in the closed channel:

Step GWR1: A gateway $G{W}_j$ chooses identity $GI{D}_j$ and generates a random nonce $b_j$. $GW$ computes $PGI{D}_j=GI{D}_j\oplus b_j$. Then, $GW$ generates a public key $P{K}_j=r_j\ast P$ and sends $\langle PGI{D}_j\rangle$ to the trusted authority $TA$ via closed channels.

Step GWR2: After that, $TA$ computes $TGI{D}_j=(h_1\left(PGI{D}_j\right)\ast k_{TA})\ast P{K}_{TA}$ and stores $PGI{D}_j$ with $TGI{D}_j$ in a its secure database. Then, $TA$ sends $TGI{D}_j$ to $G{W}_j$ over a secure channel. At the same time, $TA$ sends $\langle h_1\left(PGI{D}_j\right),TGI{D}_j\rangle$ through secure channels.

Step GWR3: $CS$ computes $GC{S}_j=h_1(h_1(PGI{D}_j\left|\right|R_{cs}\left)\right)$ and stores $GC{S}_j$ in its secure database. $CS$ also stores $TGI{D}_j$ with $h_1\left(PGI{D}_j\right)$.

4.3. Attribute Key Generation Phase

In this phase, the data user with attributes $ATTR{I}_i$ requests the attribute key from the $TA$ and provides the corresponding key.

Step AKG1: $DU$ chooses his/her attributes $ATTR{I}_i$ and sends it to $TA$ to request the attribute key.

Step AKG2: After that, $TA$ generates random nonces $r{a}_i,r{b}_i\in Z_q^{\ast }$. In addition, $TA$ computes $A{t}_i=F(\zeta +r{a}_i)$ for all $s\in ATTR{I}_i$, and also computes $A{t}_{i_s}=r{a}_{i}P+r{b}_{i}H\left(s\right)$ and $A{t}_{i_s}^{{}^{\prime }}=r{b}_{i}P$. Then, $TA$ computes attribute keys $att{r}_i=(A{t}_i,A{t}_{i_s},A{t}_{i_s}^{{}^{\prime }}$). Finally, $TA$ sends attribute keys $att{r}_i$ to $D{U}_i$.

Step AKG3: After receiving attribute keys, $D{U}_i$ uploads the transaction $T{x}_i=$$(P{K}_i,ATTR{I}_i)$ to the blockchain.

4.4. Authentication and Key Agreement Phase

For uploading the IoT data to the cloud server, $G{W}_j$ and $CS$ authenticate each other. They authenticate each other to secure mutual trust, and later, by establishing the session key $SK$, $G{W}_j$ and $CS$ can configure a secure communication channel. The detailed steps involved in this step are shown below and are summarized in Figure 2.

Step AK1:$G{W}_j$ generates a random number ${\beta }_i$ and timestamp $T_1$, and computes $E_i=({\beta }_i\ast r_j)\ast P$, $AUT{H}_j=({\beta }_i\ast r_j)\ast P{K}_{cs}$, $F_i=h_1\left(PGI{D}_j\right)\oplus AUT{H}_j$, $M{C}_{jc}=$$h_1(AUT{H}_j$$\left|\right|h_1\left(PGI{D}_j\right)\left|\right|T_1)$, and $TAUT{H}_j=TGI{D}_j\ast M{C}_{jc}$. Then, $GW$ sends a request message $\langle E_i,$$F_i,$$P{K}_j$, $TAUH{T}_j$, $T_1\rangle$ to $CS$ over an insecure channel.

Step AK2: After receiving the message, $CS$ retrieves $h_1\left(PGI{D}_j\right)$ using $TGI{D}_j$ and verifies $h_1(h_1\left(PGI{D}_j\right)\left|\right|R_{cs})\stackrel{?}{=}GC{S}_j$. If it corrects, $CS$ computes $AUT{H}_j=E_i\ast R_{cs}$, $h_1(h_1\left(PGI{D}_j\right)\left|\right|{\beta }_i)=F_i\oplus AUT{H}_j$, and $M{C}_{jc}=h_2(AUT{H}_j\left|\right|h_1\left(PGI{D}_j\right)\left|\right|T_1)$. After that, $CS$ checks $e(TAUT{H}_j,P)\stackrel{?}{=}e((h_1\left(PGI{D}_j\right)\ast M_{jc})\ast P{K}_{TA},P{K}_{TA})$. If they are the same, $G{W}_j$ is authenticated. After that, $CS$ generates a $n_{cs}$ and timestamp $T_2$. In addition, $CS$ computes $P_{cg}=(n_{cs}\ast R_{cs})\ast P$, $V_{cg}=(n_{cs}\ast R_{cs})\ast P{K}_j$, and $CS$ also computes $G_i=V_{cg}\oplus n_{cs}$, $SK=h_1(n_{cs}\left|\right|h_1(h_1\left(PGI{D}_j\right)\left|\right|{\beta }_i\left)\right)$ as a session key, and $M_{cg}=h_1(h_1\left(PGI{D}_j\right)\left|\right|V_{cg}\left|\right|T_2)$. Then, $CS$ sends a response message $\langle P_{cg},G_i,M_{cg},T_2\rangle$ to $G{W}_j$ through public channels.

Step AK3: After that, $G{W}_j$ checks the validity of $|T_2^{\prime }-T_2^{″}|<\mathsf{\Delta }T$. If it is valid, $G{W}_j$ computes $V_{cg}=P_{cg}\ast r_j$ and $n_{cs}=G_i\oplus V_{cg}$. Then, $G{W}_j$ checks $M_{cg}\stackrel{?}{=}{h}_1(h_1\left(PGI{D}_j\right)\left|\right|V_{cg}\left|\right|T_2)$. If it holds, $G{W}_j$ considers $CS$ as authentic and computes the session key shared with $CS$ as $SK=h_1(n_{cs}\left|\right|h_1(h_1\left(PGI{D}_j\right)\left|\right|{\beta }_i\left)\right)$.

Finally, $G{W}_j$ and $CS$ complete mutual authentication to generate the same session key $SK$ for IoT data upload.

4.5. Data Upload Phase

$G{W}_j$ uploads IoT data through the session key agreed with $CS$. At this time, $G{W}_j$ encrypts data through CP-ABE and uploads them to $CS$ so that only $D{U}_i$ with appropriate attributes can access data sharing. In addition, $G{W}_j$ generates the signature value for data verification of $D{U}_i$. $CS$ stores encrypted data and uploads $G{W}_j$’s signature value, public key, attribute tree, and stored server address value to the blockchain. Detailed steps related to this phase are provided below.

Step DU1: $G{W}_j$ chooses an access tree $\mathcal{T}$ and root of tree $\tau$. Then, $G{W}_j$ generates a timestamp $T{S}_j$ and selects a random polynomial $q_{\tau }\left(x\right)$ with degree $d_{\tau }=v_{\tau }-1$. $G{W}_j$ generates a random number $x_j=q_{\tau }\left(0\right)$ for a leaf node x of $\mathcal{T}$. Thereafter, $G{W}_j$ computes $c_{j1}=DAT{A}_j\ast e{(P,P)}^{{\zeta }_{x_j}}$, $c_{j2}=P{K}_{TA}\ast s_j$.

For other leaf nodes $le$ of $\mathcal{T}$, $G{W}_j$ chooses a random point $d_{le}$ of polynomial $q_{le}\left(x\right)$. Then, $G{W}_j$ calculates $C_{le}=P\ast q_n\left(0\right)$ and $C_{le}^{\prime }=h_2\left(attr\left(le\right)\right)\ast q_{le}\left(0\right)$ for all leaf nodes $le$ of $\mathcal{T}$. The ciphertext consists of ${\delta }_j=(\mathcal{T},c_{j1},c_{j2},C_{le},C_{le}^{{}^{\prime }})$. $G{W}_j$ also computes the signature of data as follows. $GW$ computes $s_j=h_1(PGI{D}_j\left|\right|r_j\left|\right|DAT{A}_j)$, $S_j=s_j\ast P$, and $Si{g}_j=s_j+h_1(P{K}_j\left|\right|{\delta }_j)\ast r_j$ as the signature. Finally, $G{W}_j$ sends $\langle {(S_j,Si{g}_j,{\delta }_j,T{S}_j)}_{SK},h_1(P{K}_j\left|\right|{\delta }_j\left|\right|T{S}_j)\rangle$ to $CS$ through a open channel.

Step DU2: After that, $CS$ decrypts $(Si{g}_j,{\delta }_j,T{S}_j)$ using the session key and checks $h_1(P{K}_j\left|\right|{\delta }_j\left|\right|T{S}_j)$. If these values are equal, $CS$ stores ${\delta }_j$ in its database and sets $ADD{R}_j$ to the record address. At the end, $CS$ uploads the transaction $T{x}_j=$$(S_j,Si{g}_j,P{K}_j,\mathcal{T},h_1({\delta }_j\left|\right|P{K}_j),$$ADD{R}_j)$ to the blockchain.

4.6. Data Request and Provide Phase

Step DRP1: $D{U}_i$ inserts the smartcard $SC$ and inputs $DUI{D}_i$ and $DUP{W}_i$. Then, $SC$ computes $I{U}_i^{{}^{\prime }}=Z_i\oplus h_1(DUI{D}_i\left|\right|DUP{W}_i)$, $HDUP{W}_i^{{}^{\prime }}=h_1(DUI{D}_i\left|\right|I{U}_i^{{}^{\prime }}\left|\right|DUP{W}_i)$, and $TI{D}_i^{{}^{\prime }}=B_i\oplus HDUP{W}_i^{{}^{\prime }}$. $SC$ checks $C_i^{{}^{\prime }}\stackrel{?}{=}{h}_1(TI{D}_i^{{}^{\prime }}\left|\right|HDUP{W}_i^{{}^{\prime }})$. If it is valid, $D{U}_i$ generates random nonce $r_{du}$ and timestamp $T{S}_i$, and computes $r_i=D_i\oplus HDUP{W}_i^{{}^{\prime }}$, $M{C}_{ic}=h_1(AUT{H}_i\left|\right|h_1(DUI{D}_i\left|\right|I{U}_i^{{}^{\prime }}\left)\right||T{S}_i)$, $AI{D}_i=TI{D}_i\ast M{C}_{ic}$. After that, $D{U}_i$ obtains the transaction $(Si{g}_j,P{K}_j,\mathcal{T},h_1({\delta }_j\left|\right|P{K}_j),ADD{R}_j)$. $D{U}_i$ computes $M_1=(P{K}_i\left|\right|ADD{R}_j\left|\right|r_{du}\left|\right|T{S}_i)+r_i\ast P{K}_{cs}$ and sends the data request message $\langle h_1\left(TI{D}_i\right)$$AI{D}_i$, $P{K}_i$, $T{S}_i$, $M_1\rangle$.

Step DRP2: After receiving the message, $CS$ retrieves $HDUI{D}_i$ using $h_1\left(TI{D}_i\right)$ and verifies $h_1(HDUI{D}_i^{{}^{\prime }}\left|\right|R_{cs})\stackrel{?}{=}MC{S}_i$. If it holds, $CS$ computes $AUT{H}_i=P{K}_i\ast R_{cs}$ and $M{C}_{ic}=h_1(AUT{H}_i\left|\right|HDUI{D}_i\left|\right|T{S}_i)$. Then, $CS$ checks $e(AI{D}_i,P)\stackrel{?}{=}e((HDUI{D}_i\ast M{C}_{ic})\ast P{K}_{TA}),P{K}_{TA})$. If this equality holds, $CS$ obtains $(P{K}_i,ATTR{I}_i)$ from the blockchain. Then, $CS$ computes $(P{K}_i\left|\right|ADD{R}_j\left|\right|r_{du}\left|\right|T{S}_i)=M_1-R_{cs}\ast P{K}_i$ and confirms that $ATTR{I}_i$ satisfies tree of ${\delta }_j$. If it is met, $CS$ calculates $M_2=({\delta }_j\left|\right|T_{cs})+R_{cs}\ast P{K}_i$. Then, $CS$ sends the message $\langle M_2$$AI{D}_i$, $T{S}_{cs}\rangle$.

Step DRP3: After receiving the message, $D{U}_i$ computes $({\delta }_j\left|\right|T{S}_{cs})=M_2-r_i\ast P{K}_{cs}$. Then, $D{U}_i$ checks $h_1({\delta }_j\left|\right|P{K}_j{)}^{\ast }\stackrel{?}{=}{h}_1({\delta }_j\left|\right|P{K}_j)$ acquired on the blockchain. Depending on the type of root node, data decryption proceeds as follows.

• Case 1: If $\tau$ is a leaf node, $D{U}_i$ calculates $e(A_{t_i},C_{le})$ and $e(A_{t_i}^{{}^{\prime }},C_{le}^{{}^{\prime }})$. Then, $D{U}_i$ computes $A{t}_{i_s},C_{le}$ and $A{t}_{i_s}^{{}^{\prime }},C_{le}^{{}^{\prime }}$. Then, $D{U}_i$ computes $\frac{e(A{t}_{i_s},C_{le})}{e(A{t}_{i_s}^{{}^{\prime }},C_{le}^{{}^{\prime }})}=e{(P,P)}^{r{a}_i{q}_{\tau }\left(0\right)}=K$ for data decryption. Thereafter, $D{U}_i$ can decrypt as follows:

  $$\begin{array}{cc}\hfill \frac{c_{j1}}{e(c_{j2},A{t}_i)/K}& =\frac{DAT{A}_j\ast e{(P,P)}^{\zeta x_i}}{e(x_{i}P{K}_{TA},F(\zeta +r_{ai}))/K}\hfill \\ & =\frac{DAT{A}_j\ast e{(P,P)}^{\zeta x_i}}{e{(P,P)}^{x_i(\zeta +r_{ai})}/K}=DAT{A}_j\hfill \end{array}$$
• Case 2: We assume that root node $\tau$ is a threshold gate and child nodes are attributes. Before we describe the decryption computation, we define the symbols $c_{\tau }$ and ${\mathsf{\Delta }}_{ind\left(le\right),c_{\tau }}\left(x\right)$. $c_{\tau }$ is a set of child nodes of the root node, and ${\mathsf{\Delta }}_{ind\left(le\right),c_{\tau }}\left(x\right)$ is Lagrange coefficient, where ${\mathsf{\Delta }}_{ind\left(le\right),c_{\tau }}\left(x\right)={\mathsf{\Pi }}_{o\in c_{\tau },ind\left(o\right)\ne ind\left(le\right)}$$\frac{x-ind\left(o\right)}{ind\left(le\right)-ind\left(o\right)}$.
  $D{U}_i$ computes $\frac{e(A{t}_{i_s},C_{le})}{e(A{t}_{i_s}^{{}^{\prime }},C_{le}^{{}^{\prime }})}=e{(P,P)}^{r{a}_i{q}_{\tau }\left(0\right)}=K_{le}$ for all leaf nodes $le$. After that, $D{U}_i$ computes decrypt key:

  $$\begin{array}{cc}\hfill \prod _{le}{K}_{le}^{{▵}_{ind\left(le\right),c_{\tau }\left(0\right)}}& =\prod _{le}{\left(e{(P,P)}^{r{a}_i{q}_{le}\left(0\right)}\right)}^{{▵}_{ind\left(le\right),c_{\tau }\left(0\right)}}\hfill \\ & =\prod _{le}{\left(e{(P,P)}^{r{a}_i{q}_{\tau }(ind\left(le\right)}\right)}^{{▵}_{ind\left(le\right),c_{\tau }\left(0\right)}}\hfill \\ & =e{(P,P)}^{r{a}_i{q}_{\tau }\left(0\right)}=K\hfill \end{array}$$
  Then, $D{U}_i$ can decrypt the IoT data.

4.7. Data Validation Phase

If the data users want to verify that the gateway information is correct, data verification can be performed during this phase. This data validation ensures that the gateway is accountable for its own data and that the data user can obtain the reliability of the data. A detailed description of this phase is provided bellow:

Step DVP:$D{U}_i$ obtains $S_j$, $Si{g}_j$, $P{K}_j$, and $h_1({\delta }_j\left|\right|P{K}_j)$ from the transaction related to the data. $D{U}_i$ computes $Si{g}_j\ast P=s_j\ast P+h_1(P{K}_j\left|\right|{\delta }_j)\ast r_j\ast P=S_j+h_1(P{K}_j\left|\right|{\delta }_j)\ast P{K}_j$. Then, $D{U}_i$ checks $S_j=Si{g}_j-h_1(P{K}_j\left|\right|{\delta }_j)\ast P{K}_j$. If it is valid, $D{U}_i$ can be considered as data validation completed.

4.8. Block Formation and Addition Phase

In the key generation phase and data upload phase, $D{U}_i$ and $CS$ create a transaction and upload it to the blockchain. We describe it in detail in terms of $CS$ in this section, and the block construction and addition of $D{U}_i$ is similar. The “practical Byzantine fault tolerance (PBFT) consensus algorithm” [26] has been applied for adding blocks to existing blockchains, verifying blocks, and voting-based consensus algorithms. The block structure is depicted in Figure 3, and the entire algorithm of block addition is given in Algorithm 1.

Algorithm 1 PBFT Consensus for Block Addition in Blockchain by Cloud Server

1: Input: Block $(Bloc{k}_m$ as shown in Figure 3, transactions pool $\left(T{x}_{p}ol\right)$, transactions threshold $(T{x}_{thresh=t}$, number of $CS$ nodes: $n_{cs}$, minimal approval $(Mi{n}_{approve}=2\ast (n_{cs}-1)/3+1)$   2: Output: Commitment for block addition ($CMP$)   3: Assume that a cloud server node ($C{S}_l$) is elected as a leader   4: $C{S}_l$ picks a fresh timestamp and creates a block $Bloc{k}_m$ with $T{x}_{pool}$   5: $C{S}_l$ sets $CMP=NULL$ and sends $Bloc{k}_m$ to follower cloud server nodes ($C{S}_k$$(k\ne l|k=1,2,\dots ,n_{cs})$) for voting request   6: for each follower $C{S}_j$ do   7:    if (($T{x}_j=valid$) and ($MR=valid$) and ($ECDSA.si{g}_{Tx}=valid$) and ($CBHash=valid$)) then   8:      Set $CMP=CMP+1$   9:    end if  10: end for  11: if ($CMP\ge Mi{n}_{approve}$) then  12:    Add $Bloc{k}_m$ to the blockchain  13:    Broadcast commitment message to $CS$  14: end if

4.8.1. Block Formation Phase

At the data upload phase of our system, the data generated by $G{W}_j$ are uploaded to $CS$ using $SK$ agreed between $G{W}_j$ and $CS$ at the authentication and key agreement phase. $CS$ safely gathers t counts of data, filters that information, and then generates t counts of transactions $T{x}_j=$$(S_j,Si{g}_j,P{K}_j,\mathcal{T},h_1({\delta }_j\left|\right|P{K}_j),ADD{R}_j)$, for $j=$ 1, 2,…, t, to contribute to the transactions pool. To describe this in detail in terms of the data upload phase, $CS$ computes the Merkle tree root ($MR$) for transactions $T{x}_j$ and calculates “elliptic curve digital signature” for transactions $T{x}_j$ as $ECDSA.si{g}_{Tx}=ECDSA.si{g}_{gen}\left(T{x}_{msg}\right)$, where $T{x}_{msg}=h_1(T{x}_1\left|\right|T{x}_2\left|\right|\dots \left|\right|T{x}_j\left|\right|P{K}_{cs}\left|\right|MR)$.

4.8.2. Block Addition Phase

After block formation phase, the $MR$ for the transaction existing in the block is verified. In addition, $CS$ conducts a voting-based PBFT consensus algorithm. The $CS$ nodes $C{S}_l|l=1,2,\dots ,n_{cs}$ ($n_{cs}$ represent the number of peers in $CS$) form a distributed P2P network. Here, each $CS$ node is considered a peer node that is responsible for adding blocks. After the $CS$ peer node receives the $Bloc{k}_m$, peer node verifies it with the existing transaction pool. When all transactions in $Bloc{k}_m$ are confirmed by the transaction pool, the peer puts a valid vote into the commit message pool. $CS$ constantly checks the commit message pool and checks when the minimum approval $\left(Mi{n}_{approve}\right)$ for block additions on the blockchain is reached; where $Mi{n}_{approve}=2\ast (n_{cs}-1)/3+1$, the new block $Bloc{k}_m$ will be added to the blockchain.

5. Formal Security Validation: AVISPA Simulation Study and IND-CPA

In this section, we utilize the “AVISPA simulation tool” [10] and IND-CPA to verify the security of the proposed system.

5.1. AVISPA Simulation

We use the “AVISPA Simulation Tool” [10] in this section to validate our proposed system security against man-in-the-middle and replay attacks.

In AVISPA, there are four backends: “tree automata based on automatic approximations for analysis of security protocols (TA4SP)”, the “SAT-based model checker (SATMC)”, the “on-the-fly-mode-checker (OFMC)” and the “constraint-logic-based attack Searcher” (CL-AtSe)”. Among these, the SATMC and TA4SP backends can not aid the “bitwise exclusive OR (XOR)”. However, since our system has an XOR operation, two backends are not suitable for analysis. Therefore, we adopt two backends, OFMC and CL-AtSe, which support XOR operation, and use them for analysis. In the proposed system, “High-Level Protocol Specification Language (HLPSL)”, a language supported by AVISPA, is used to implement the basic roles of $CS$ and $G{W}_j$. Figure 4 shows the HLPSL implementation of the role user.

At transition 1, $GW$ sends the request message $\{PGI{D}_j$} to $TA$ using $SND$ operation and $SKgwta$, which means the secure channel. The declaration $secret\left(\right\{B{j}^{{}^{\prime }},$$Rj\},sp3,\{GW\left\}\right)$ means that the random nonce $B_j$ and secret key $R_j$ are only known to $GW$.

At transition 2, $GW$ receives the $TGI{D}_j$ from $TA$. In login and authentication phase, $GW$ sends the message $\{E_i,F_i,TGI{D}_j,P{K}_j,TAUT{H}_j,T_1\}$ to $CS$ through insecure channel. The declaration $witness(GW,CS,gw\_cs\_bei,Be{i}^{\prime })$ means that $GW$ generates a random nonce ${\beta }_i$ for $CS$.

At transition 3, $GW$ receives the message $\{P_{cg},G_i,M_{cg},T_2\}$ from $CS$. The declaration $request(CS,GW,cs\_gw\_ncs,$$Nc{s}^{\prime })$ specifies that $CS$ request to the $GW$ for checking the value of $n_{cs}$.

HLPSL of cloud server is implemented similarly to gateway’s HLPSL. In addition, it implements “composite roles and goals for sessions and environment” of the proposed system through HLPSL. AVISPA used in this section is a security validation simulation based on the DY model [30]. Figure 5 gives the analysis results performed on the CL-ATse and OFMC backends. The figure clearly shows that the proposed system can be resistant to “replay and man-in-the-middle attacks”.

5.2. IND-CPA Security

We prove the confidentiality property of our system with the game of IND-CPA. In our scheme, the game is defined as follows.

• Init. The adversary $\mathcal{A}$ gives a challenge access structure ${\mathcal{T}}^{\ast }$.
• Setup. The simulator $\mathcal{X}$ executes Setup phase and sends the public parameters to the adversary $\mathcal{A}$.
• Phase 1. $\mathcal{A}$ queries multiple private keys corresponding to $q_1$ different sets of attributes $(ATTR{I}_1,\dots ,ATTR{I}_{q_1})$ where $ATTR{I}_i\notin {\mathcal{T}}^{\ast }$.
• Challenge. $\mathcal{A}$ submits two plaintext $DAT{A}_0$ and $DAT{A}_1$, where $|DAT{A}_0|=|DAT{A}_1|$ to the simulator $\mathcal{X}$ with ${\mathcal{T}}^{\ast }$. $\mathcal{X}$ flips the coin $b\in \{0,1\}$, encrypts $DAT{A}_b$ under ${\mathcal{T}}^{\ast }$, and sends the ciphertext $C{T}^{\ast }$ to $\mathcal{A}$.
• Phase 2. $\mathcal{A}$ repeats Phase 1 with the attribute sets $(ATTR{I}_{q_1+1},\dots ,ATTR{I}_q)$ where $ATTR{I}_i\notin {\mathcal{T}}^{\ast }$.
• Guess. $\mathcal{A}$ outputs a guess $b^{\prime }$ of b to the simulator $\mathcal{X}$. If $b^{\prime }=b$, $\mathcal{A}$ wins the game.

The adversary $\mathcal{A}$’s advantage $\epsilon$ in this game is defined as $\epsilon =|Pr[b^{\prime }=b]-\frac{1}{2}|$. If $\mathcal{A}$ in probabilistic polynomial time can be played with a non-negligible advantage $\epsilon$, then we prove that the problem of the DBDH assumption can be solved with $\epsilon /2$.

Proof. 

Assume that the adversary $\mathcal{A}$ wants to take advantage of $\epsilon$ to subvert the system. We build a $\mathcal{X}$ simulator to play the DBDH game with a $\epsilon /2$ advantage. We proceed through the simulation process as follows. The $\mathcal{B}$ challenger randomly picks $a,b,c,z\in Z_q$ and generator $P\in G_1$. $\mathcal{B}$ flips a coin to obtain a random value $\mu \in \{0,1\}$. If $\mu =1$, $Z=e{(P,P)}^z$, which means $(P^a,P^b,P^c,e{(P,P)}^z)$. Otherwise, $Z=e{(P,P)}^{abc}$ means $(P^a,P^b,P^c,e{(P,P)}^{abc})$. After that, $\mathcal{B}$ transmits the results to $\mathcal{X}$.

Init. The simulator $\mathcal{X}$ runs $\mathcal{A}$ to create access structure ${\mathcal{T}}^{\ast }$ that $\mathcal{A}$ hopes to attack. Then, $\mathcal{A}$ transmits it to $\mathcal{X}$.

Setup. $\mathcal{X}$ computes public parameters $\{P{K}_{TA}=k_{TA}\ast P,F=\frac{P}{k_{TA}},e{(P,P)}^{\zeta }\}$, where $\zeta =ab$. Then, $\mathcal{X}$ sends them to $\mathcal{A}$.

Phase 1. $\mathcal{A}$ requests multiple private keys $(att{r}_{i1},\dots ,att{r}_{i{q}_1})$ corresponding to $q_1$ different sets of attributes $(ATTR{I}_1,\dots ,ATTR{I}_{q_1})$ where $ATTR{I}_i\notin {\mathcal{T}}^{\ast }$. The simulator $\mathcal{X}$ generates random nonces $r{a}_i,r{b}_i\in Z_q^{\ast }$. $\mathcal{X}$ computes $A{t}_i=F(\zeta +r{a}_i)$ for all $s\in ATTR{I}_i$, $A{T}_{i_s}=r{a}_{i}P+r{b}_{i}H\left(s\right)$, $A{t}_{i_s}^{{}^{\prime }}=r{b}_{i}P$, $att{r}_i=(A{t}_i,A{t}_{i_s},A{t}_{i_s}^{{}^{\prime }})$. Then, $\mathcal{X}$ sends $att{r}_i$ to $\mathcal{A}$.

Challenge. $\mathcal{A}$ submits ${\mathcal{T}}^{\ast }$ to the $\mathcal{X}$ simulator with plain text $DAT{A}_0$ and $DAT{A}_1$ of equal length. $\mathcal{X}$ randomly tosses a coin to obtain $b\in \{0,1\}$. If $\mu =0$, then $Z=e{(P,P)}^{abc}$. In this case, we let $x_j=c$, then $e{(P,P)}^{abc}=e{(P,P)}^{\zeta x_j}$ and $c_{j1}=DAT{A}_b\ast e{(P,P)}^{abc}$. Otherwise, if $\mu =1$, then $Z=e{(P,P)}^z$ and $c_{j1}=DAT{A}_b\ast e{(P,P)}^z$. $\mathcal{X}$ computes $c_{j2}=P{K}_{TA}\ast s_j$. Then, $\mathcal{X}$ chooses a random point $d_{l_e}$ of polynomial $q_{le}\left(x\right)$ and computes $C_{le}=P\ast q_n\left(0\right)$, $C_{le}^{\prime }=h_2\left(attr\left(le\right)\right)\ast q_{le}\left(0\right)$ for all leaf nodes $le$ of $\mathcal{T}$. Then, $\mathcal{X}$ sends ${\delta }_j=(c_{j1},c_{j2},C_{le},C_{le}^{\prime })$ to $\mathcal{A}$.

Phase 2. The adversary $\mathcal{A}$ repeats Phase 1 to obtain the private keys that are associated with attribute sets $\forall ATTR{I}_i{|}_{q_1+1\le i\le q}$ and $ATTR{I}_i\notin {\mathcal{T}}^{\ast }$.

Guess. $\mathcal{A}$ guesses $b^{\prime }$ of b. If $b\ne b^{\prime }$, $\mathcal{X}$ gives a result 1, otherwise, it gives a result 0. If $\mathcal{X}$ gives a result 0, then $Z=e{(P,P)}^{abc}$. $\mathcal{A}$ can obtain practical ciphertext ${\delta }_j$. The advantage in this case is $\epsilon$, so we obtain $Pr[b^{\prime }=b|Z=e{(P,P)}^{abc}]=\frac{1}{2}+\epsilon$. When $\mathcal{X}$ gives a result 0, it means $Z=e{(P,P)}^z$. $\mathcal{A}$ obtains the wrong ciphertext, and does not have the advantage of guessing the correct $b^{\prime }$, so it is able to obtain $Pr[b\ne b|Z=e{(P,P)}^z]=\frac{1}{2}$. Therefore, the probability $Pr$ of a successful game is

$$\begin{array}{cc}\hfill Pr& =\frac{1}{2}Pr[\mathcal{A}(P,P^a,P^b,P^c,e{(P,P)}^{abc})=1]\hfill \\ \hfill & +\frac{1}{2}Pr[\mathcal{A}(P,P^a,P^b,P^c,e{(P,P)}^z)=1]-\frac{1}{2}\hfill \\ \hfill & =\frac{1}{2}Pr[b^{\prime }=b|Z={(P,P)}^{abc}]\hfill \\ \hfill & +\frac{1}{2}Pr[b^{\prime }\ne b|Z=e{(P,P)}^z]-\frac{1}{2}\hfill \\ \hfill & =\frac{1}{2}\times (\frac{1}{2}+\epsilon )+\frac{1}{2}\times \frac{1}{2}-\frac{1}{2}\hfill \\ \hfill & =\frac{\epsilon }{2}\hfill \end{array}$$

(2)

Therefore, our scheme ensures IND-CPA security.

□

6. Informal Security Analysis

We provide an nonmathematical (informal) security analysis of whether the proposed system can provide various security features and safety against possible attacks.

6.1. Correctness of Data Decryption Key

If the leaf node $le$ is a root node $\tau$, we check the correctness of the decryption key as follows:

$$\begin{array}{cc}\hfill \frac{e(A{t}_{i_s},C_{le})}{e(A{t}_{i_s^{{}^{\prime }}},C_{le}^{{}^{\prime }})}& =\frac{e(r{a}_{i}P+r{b}_i{h}_2\left(attr\left(\tau \right)\right),q_{\tau }\left(0\right)P)}{e(r{b}_{i}P,h_2\left(attr\left(\tau \right)\right)q_{\tau }\left(0\right))}\hfill \\ & =\frac{e(r{a}_{i}P,q_{\tau }\left(0\right)P)e(r{b}_i{h}_2\left(attr\left(\tau \right)\right),q_{\tau }\left(0\right)P)}{e(r{b}_{i}P,h_2\left(attr\left(\tau \right)\right)q_{\tau }\left(0\right))}\hfill \\ & =\frac{e{(P,P)}^{r{a}_i{q}_{\tau }\left(0\right)}e{(h_2\left(attr\left(\tau \right)\right),P)}^{r{b}_i{q}_{\tau }\left(0\right)}}{e{(P,h_2\left(attr\left(\tau \right)\right))}^{r{b}_i{q}_{\tau }\left(0\right)}}\hfill \\ & =e{(P,P)}^{r{a}_i{q}_{\tau }\left(0\right)}=K\hfill \end{array}$$

6.2. Guessing Attacks

The malicious adversary $\mathcal{A}$ cannot guess the data user’s $DUI{D}_i$ and $DUP{W}_i$ in the proposed system. $\mathcal{A}$ obtains the credentials $\{Z_i,B_i,C_i,D_i\}$ stored on the smart card. However, since $\{Z_i,B_i,C_i\}$ is encrypted with random numbers $I{U}_i$ and $a_i$, $\mathcal{A}$ cannot obtain sensitive information. Furthermore, these values are protected via “a one-way collision-free hash function $h(·)$”. In addition, $D_i$ is masked by the unknown parameter $HDUP{W}_i$ and secret key $r_i$. As a result, our proposed system can resist guessing attacks.

6.3. Tracing Attacks and Provides Anonymity

The adversary $\mathcal{A}$ is trying to obtain the real IDs of $D{U}_i$ and $G{W}_j$ to perform a tracking attack. In our system, the user’s real identity $DUI{D}_i$ is hidden by $HDUI{D}_i$ masked with a random number $I{U}_i$. In addition, the $D{U}_i$ sends the message through the public channel using the temporary ID $TI{D}_i$ received from $TA$ via an insecure channel. Moreover, $G{W}_j$ hides its real ID $GI{D}_j$ as $PGI{D}_j$. $G{W}_j$ sends a message through the public channel with the temporary ID $TGI{D}_j$ obtained from $TA$. So, $\mathcal{A}$ cannot know original IDs $DUI{D}_i$ and $GI{D}_j$. This demonstrates that our system provides anonymity and can resist tracing attacks.

6.4. Impersonation Attacks

$\mathcal{A}$ may attempt to impersonate each entity by calculating legitimate messages to obtain information. In our system, messages sent over public channels are encrypted using random numbers ${\beta }_i$, $n_{cs}$, $x_i$, and $r_{du}$ and secret values $r_j$ and $R_{cs}$. Moreover, in the data upload phase, the message is encrypted by the session key $SK$. $\mathcal{A}$ tries to take out these values, but this cannot be carried out. In addition, each of the entities check $e(TAUT{H}_j,P)\stackrel{?}{=}e((h_1\left(PGI{D}_j\right)\ast M_{jc})\ast P{K}_{TA},P{K}_{TA})$, $M_{cg}\stackrel{?}{=}{h}_1(h_1\left(PGI{D}_j\right)\left|\right|V_{cg}\left|\right|T_2)$, and $e(AI{D}_i,P)\stackrel{?}{=}e((HMI{D}_i\ast M{C}_{ic})\ast P{K}_{TA}),P{K}_{TA})$. Therefore, the proposed system can provide protection against impersonation attacks.

6.5. Ephemeral Secret Leakage Attacks

In the authentication and key agreement phase, $G{W}_j$ and $CS$ establish the session key $SK=h_1(n_{cs}\left|\right|h_1(h_1\left(PGI{D}_j\right)\left|\right|{\beta }_i\left)\right)=h_1(n_{cs}\left|\right|h_1(h_1(GI{D}_j\oplus b_j)\left|\right|{\beta }_i\left)\right)$ in our system. The $SK$ depends on “ephemeral secrets $n_{cs}$ and ${\beta }_i$” and long-term secret $b_j$. Even if the attacker “short-term secret $n_{cs}$ and ${\beta }_i$” is compromised for $\mathcal{A}$, guessing $SK$ without long-term secret $b_j$ is “a computationally difficult problem.” Likewise, even if “long-term secret $b_j$” is compromised to $\mathcal{A}$, deriving $SK$ is also “computationally difficult. except for short-term secrets. Since $SK$ between the gateway and the cloud server is distinct and unique, leaking $SK$ from a session to $\mathcal{A}$ is “computationally infeasible” as it applies both short-term and long-term secrets without having to compute another session key in another session. Therefore, the proposed system prevents ephemeral secret leakage attacks.

6.6. Mutual Authentication and Key Agreement

At our system, $GW$ and $CS$ use the $TAUT{H}_j$ and $M_{cg}$ values to authenticate each other by verifying the message. Every transmitted message is changed with a random number and current timestamps. $GW$ and $CS$ authenticate each other through an authentication and key agreement phase and compute the same session key $SK$ only if the authentication is complete. Therefore, our system provides key agreement through mutual authentication.

6.7. Data Access Control, Validation and Accountability

The proposed system can provide access control to IoT data of $G{W}_j$. $G{W}_j$ establishes an access tree for IoT data and uses it to encrypt data and upload them to $CS$. Then, only $D{U}_i$ with the appropriate set of attributes in the IoT data’s access tree is able to request data from $CS$ and decrypt them with the attribute key. In addition, $G{W}_j$ uploads the signature value of its own data to the transaction on the blockchain. $D{U}_i$ can confirm that the data are uploaded by $G{W}_j$ through the signature value of the transaction, which means that $G{W}_j$ guarantees accountability for its own data when uploading. Thus, the system can provide data access control, validation, and accountability.

7. Efficiency Features and Security Analysis

The proposed system is compared with existing competitive data access control systems in the smart city area, such as smart health and smart homes [18,24]. The compared schemes are all schemes using attribute-based encryption. We compare different data access control schemes with each other in terms of communication and communication costs, function, and security features.

7.1. Testbed Experiment Using MIRACL

In this section, we apply MIRACL to show an an environment for practical perspective experiments. The MIRACL testbed experiment shows the computation costs of the proposed system. We performed a testbed experiment with cryptographic primitives using the popular “MIRACL” [11] in a laptop environment. Here are the detailed performance details of the laptops we used: “Ubuntu 18.04.4 LTS with memory 8 GiB, processor: Intel Core i7-4790 @ 3.60 GHz × 4, CPU Architecture: 64-bit”. The experiments were run 100 times to determine the time to run “bilinear pairing operation $\left(T_{pair}\right)$”, “ECC signature operation $\left(T_{sig}\right)$, “ECC scalar point multiplication $\left(T_{mul}\right)$”, “ECC point addition $\left(T_{add}\right)$”, “modular exponentiation operation $\left(T_{exp}\right)$”, “map-to-point-hash-function $\left(T_{mtp}\right)$”, “encryption function $\left(T_{enc}\right)$”, “decryption function $\left(T_{dec}\right)$”, and “one-way-hash-function $\left(T_h\right)$”. Thereafter, the average execution time in milliseconds for these functions or operations over 100 run was recorded: 6.587 ms, 0.546 ms, 2.547 ms, 0.013 ms, 0.164 ms, 7.564 ms, 0.001 ms, 0.001 ms, and 0.003 ms, respectively.

7.2. Security and Function Feature Comparison

This section presents the results of comparison of the proposed system with related existing approaches in terms of security and functionality.

Table 2. Security and function properties comparison (Author’s own processing).

Security and Function Properties	Lu et al. [18]	Qin et al. [24]	Proposed
$S{F}_1$	x	-	o
$S{F}_2$	x	-	o
$S{F}_3$	o	o	o
$S{F}_4$	x	o	o
$S{F}_5$	-	-	o
$S{F}_6$	-	-	o
$S{F}_7$	x	x	o
$S{F}_8$	o	o	o
$S{F}_9$	x	x	o

o: provide the security property x: does not provide the security property -: does not consider $S{F}_1$: Guessing attack $S{F}_2$: Anonymity and tracing attacks $S{F}_3$: Replay and man-in-the-middle attacks $S{F}_4$: Impersonation attack $S{F}_5$: ESL attack $S{F}_6$: Session key disclosure attack $S{F}_7$: Mutual authentication and key agreement $S{F}_8$: Data validation $S{F}_9$: Data accountability.

presents the results of the comparison. Previous studies do not provide data accountability, nor do they provide the functions of mutual authentication and key agreement, whereas the proposed method meets all essential security and functional requirements for data access control in a smart city environment.

7.3. Computation Cost Comparison Analysis

Computational costs are compared, taking into account the data upload and data request and provide phases, and follow the testbed experiment results reported in Section 7.1.

We use the average time required on the platform for the data owner/gateway/IoT device, cloud server, and data user costs, respectively.

Table 3. Computation costs comparison (Author’s own processing).

System	Data Owner/Gateway	Cloud Server	Data User	Total Costs
Lu et al. [18]	$(1+n)T_{mul}+2T_{exp}+T_h$	$T_h+T_{sig}+\left(n\right)T_{exp}$	$T_{pair}+2T_{mul}$	110.307 ms
	$\approx 15.613$ ms	$+(3+n)T_{mul}+\left(2n\right)T_{pair}\approx 83.013$ ms	$\approx 11.681$ ms
Qin et al. [24]	$5T_{mul}+9T_{exp}+T_{add}+4T_h$	$(8+6n)T_{mul}+6T_{pair}$	$T_{exp}+2T_{mul}$	156.802 ms
	$\approx 14.236$ ms	$\approx 137.308$ ms	$\approx 5.258$ ms
Proposed	$(4+2n)T_{mul}+\left(n\right)T_{mtp}+2T_h+T_{pair}$	$3T_h+2T_{mul}+2T_{add}+T_{pair}$	$5T_{mul}+\left(n\right)T_{pair}+\left(n\right)T_{exp}$	138.305 ms
	$+T_{add}+T_{enc}\approx 80.081$ ms	$\approx 11.716$ ms	$+6T_h\approx 46.508$ ms

n: number of attribute (assuming that n = 5).

shows the comparison results of the computation costs. In Table 3, n means the number of attributes. We assumed that n is 5 to obtain the total computation costs. It can be observed that the total computational costs of our system are slightly higher than those of the other systems. The proposed system uses traditional CP-ABE, which has proven safety rather than efficiency. Moreover, as shown in Table 2, the proposed system can provide mutual authentication, key agreement, and data accountability that other systems cannot provide, and it is safe against attacks from various security aspects.

7.4. Communication Cost Comparison Analysis

For comparison analysis of the communication costs during the data upload and data request and provide phases between the proposed system and other systems, the l column matrix, encryption data, hash function output value (using SHA-256), public key, identity, ECC value, chain code, index, and timestamp are taken as $32l$ bits, 256 bits, 256 bits, 256 bits, 160 bits, 256 bits, 256 bits, 256 bits, and 32 bits, respectively.

Table 4. Communication costs comparison (Author’s own processing).

System	Number of Messages	Number of Bits
Lu et al. [18]	3	$32l$ + 1952
Qin et al. [24]	3	2208
Proposed	3	2112

indicates that our system requires communication costs of 2112 bits to exchange three messages for data upload and data download. On the other hand, the schemes of Lu et al. [18] and Qin et al. [24] require communication costs of $32l$+ 1952 bits for three messages and 2208 bits for three messages.

8. Conclusions

In this paper, we proposed an access control system for IoT data in various IoT environments based on CP-ABE and blockchains. Existing systems do not provide mutual authentication and key agreement for secure communication. However, the proposed system guarantees secure communication through these two properties. In addition, the proposed system can provide data validation and accountability to data users. To verify the safety of our system, formal and unofficial security analysis was performed, and the proposed system was compared and analyzed with existing systems in terms of security and functionality. Through the analysis results, it was found that the proposed system is safe against guessing, tracing, ESL, and session key disclosure attacks, unlike existing systems. In addition, our protocol can be said to be an efficient protocol because it has a computation cost similar to or lower than that of existing systems and a lower communication cost than existing systems.

In the future, we plan to design a more efficient access control system. In this paper, we used the traditional CP-ABE, but we need to design an efficient ABE for a more efficient system design. In traditional CP-ABE, when the number of users or the number of attributes increase, the number of pairing operations increases. This will increase the computational cost of the system, which will make it impossible to provide real-time services to users in the IoT environment. In order to solve this problem, there is a need to study a new method of access control in the future. If we develop an efficient access control method even if the number of users and attributes increases, we will be able to design an access control system that is more suitable for the IoT environment.