A Secure and Computable Blockchain-Based Data Sharing Scheme in IoT System

Abstract

The internet of things (IoT) devices are expected to collect vast amounts of data that support different kinds of applications such as health monitor, smart home, and traffic management. However, its characteristics such as resource-constrained nature, dynamicity, and large-scale growth bring challenges to secure IoT data sharing. Nowadays, blockchain-based ciphertext-policy attribute-based encryption (CP-ABE) was proposed to realize secure IoT data sharing. In blockchain-based CP-ABE data sharing schemes, the data are encrypted and stored in the cloud. Once users want to process the data, they should download and then decrypt the ciphertext in the client-end, and after processing the data, users encrypt and upload the ciphertext onto the cloud. This outweighs the advantage of using cloud computing resources. Fully homomorphic encryption (FHE) and homomorphic signature technology may be adopted to realize ciphertext computation and for correctness checking of ciphertext computation results. In this paper, we propose a secure and computable IoT data sharing system to ensure users enjoying the computation convenience of the cloud-end. Specifically, the proposed system integrates CP-ABE and FHE to realize secure IoT data sharing and ciphertext computation. In addition, we generated homomorphic signatures of ciphertexts to enable users to check the correctness of the ciphertext computation results. Moreover, to supervise the cloud, providing the honest IoT data access control, storage, and computing services for users, we recorded the access policy of the data, the hash of the data, the signature of the ciphertext, and the homomorphic signature of the ciphertext on the blockchain. The performance evaluation and security analysis show the proposed scheme is practical and secure.

1. Introduction

The internet of things (IoT) is one of the most promising technologies in recent years. It is a distributed system equipped with IoT devices, such as sensors and actuators. According to the forecast, more than 8.4 billion connected IoT devices joined the network in 2017, and will reach 20.4 billion by 2020 [1]. IoT devices are expected to collect and exchange vast amounts of data, which can be useful for different stakeholders. Many challenges arise when organizing the IoT data sharing, because the resource-constrained IoT devices cannot process the data securely and efficiently.

Currently, the cloud-edge-collaborative (CEC) framework is widely used in IoT data processing [2]. In the framework, edge servers act as intermediaries between IoT devices and the cloud and allow IoT devices to share data with low latency, while the cloud with unlimited storage capability stores the IoT data [3]. However, sharing IoT data in CEC suffers from the risk of data tampering, data leakage, and ungranted access. Hence, secure data sharing in CEC is capturing increasing attention. The simplest and most direct approach to solve these problems is to encrypt the IoT data with other users’ public keys. However, this is inefficient and cannot support fine-grained access control for IoT data sharing [4,5,6,7,8,9].

Ciphertext-policy attribute-based encryption (CP-ABE) [10,11,12] is a public-key encryption technology for fine-grained access control and data sharing. In CP-ABE schemes, the private key of users is associated with their own attributes, and the data owner specifies the access policy for the ciphertext. A user could decrypt the ciphertext, only when his/her attributes of private key satisfy the access policy of the ciphertext. There are many data sharing approaches based on CP-ABE, these schemes upload access policy and encrypted data onto the cloud, thus the cloud is the single-server that grants users access to data. However, the cloud may tamper with the encrypted data or deny granted users from accessing data. Therefore, blockchain-based CP-ABE schemes are proposed. These schemes store the access policy in the blockchain [13,14], and due to the blockchain’s openness characteristics, users can verify whether their attributes are satisfied with the ciphertext’s access policy independently. Thus, the cloud cannot deny authorized users access to the data.

The blockchain-based CP-ABE scheme ensures the security of IoT data sharing. However, when users process the data, they should download and decrypt the ciphertext, and then process the data at the client-end, which wastes cloud computing resources. The fully homomorphic encryption (FHE) is known as a mechanism for computing encrypted data without decrypting it. For example, Alice encrypts the plaintexts $p_1, p_2,\cdots ,p_n$ with FHE and uploads her ciphertexts $c_1, c_2,\cdots ,c_n$ onto the cloud. When Alice wants to compute $f\left(p_1, p_2,\cdots ,p_n\right)$, she only needs to send the computation function $f$ to the cloud. Once the cloud receives $f$, it calculates $c = eval\left(f,c_1, c_2,\cdots ,c_n\right)$ and returns c to Alice. Finally, Alice decrypts c with her private key to get $f\left(p_1, p_2,\cdots ,p_n\right)$. In a homomorphic encryption scheme, ciphertexts are stored on and calculated by the cloud. As a third party, the cloud server is not fully trusted because it may return incorrect ciphertext, $c_i$, or ciphertext calculation result, c, to users.

Homomorphic signature schemes are designed to verify the correctness of outsourcing computation to address the problem [15] mentioned above. However, the homomorphic signature is a kind of data or information, and it also faces the risk of information tampering.

To get better use advantages of FHE and homomorphic signature, we also record the hash of IoT data and the homomorphic signature of the ciphertext on the blockchain. The openness and non-tampering characteristics of blockchain enable it to act as a supervisor to confirm whether the cloud is storing and calculating ciphertext correctly.

To sum up, we extend the blockchain-based CP-ABE scheme to realize ciphertext computation by combining FHE and CP-ABE algorithms. In our proposed system, the blockchain-based CP-ABE scheme enjoys the computation convenience of the cloud server. To avoid the cloud tampering with the ciphertexts and providing incorrect ciphertext calculation results, we generated the homomorphic signatures of ciphertexts and uploaded the hash of the data and the homomorphic signature of the ciphertext onto the blockchain. Our contributions are as follows:

(1)

We construct a computable IoT data sharing system based on FHE and CP-ABE. In the system, we extended the blockchain-based CP-ABE IoT data sharing scheme to realize ciphertext computable by reconstructing its encryption algorithm and decryption algorithm based on FHE.

(2)

Moreover, we use the homomorphic signature algorithm to sign the ciphertext, realizing the computation result verifiable. Thus, the cloud cannot return the incorrect ciphertext calculation results for users.

(3)

Finally, we upload the access policy of data, the hash of data, the signature of ciphertext, and the homomorphic signature of ciphertext onto the blockchain. Due to the openness characteristics of the blockchain, users can get the access policy of IoT data to verify whether they are the authorized ones to access the data. Thus, the cloud cannot deny authorized users’ access requests. In addition, the non-tampering characteristics of blockchain guarantee that users get the integrity hash, signature of IoT data, and homomorphic signature of ciphertext to verify the correctness of the ciphertext and ciphertext computation result returned from the cloud.

The remainder of this paper is organized as follows: The background and related works are introduced in Section 2. Section 3 introduces the proposed scheme, security assumptions, and security goals. The design detail of the proposed scheme is described in Section 4. Section 5 and Section 6 describe the security and evaluation of our scheme. Finally, Section 7 gives the conclusion of this paper.

2. Background and Related Work

2.1. Blockchain

Blockchain technology got introduced as a decentralized cryptocurrency, such as Bitcoin [16]. Nowadays, the blockchain is more used as the underlying technology to provide decentralized, distributed anti-destruction, traceability, and tamper-resistant services, than as a decentralized electronic currency trading system.

Blockchain can be divided into two types: permissioned blockchain and permissionless blockchains [17]. In the permissionless blockchain network, anyone can join, quit, and obtain data at any time, and every participant is anonymous. While the permissioned blockchain needs identity authentication before users joining the blockchain network and provides a secure way for a group of entities that have a common goal, to communicate with each other. Common blockchain platforms include Bitcoin [16], Ethereum [18], EOS [19], and Hyperledger Fabric [20].

2.2. Fully Homomorphic Encryption

The fully homomorphic encryption (FHE) scheme supports arbitrary function computation on encrypted data without decrypting it. This technology enables the cloud to process the ciphertext directly, which allows users to enjoy the convenience of shared resources while ensuring the confidentiality of the data [21,22].

An FHE scheme consists of four parts: KeyGen, Encrypt, Decrypt, and Evaluate. Consider the messages $m_1,\cdots ,m_t$, which are encrypted to the ciphertext $c_1,\cdots ,c_t$, where $c_i = Encrypt\left(m_i\right)$, $i = 1,\cdots ,t$. Given a computable function, $f$, anyone could compute the ciphertext $c = Evaluate\left(f, c_1,\cdots ,c_t\right)$ that decrypts to $f\left(m_1,\cdots ,m_t\right)$.

• Ciphertext Flatten

The flatten technique modifies vectors that keep ciphertext bounded to realize leveled FHE.

Let x, y $\in$ $Z_q^k$ be two vectors whose dimension is k, and set $l = \lfloor lo{g}_{2}q\rfloor +1$, $N=k·l$.

-

$BitDecomp\left(x\right)$ is a vector $\left(x_{1,0}, \cdots , x_{1,l-1}, \cdots , x_{k,0}, \cdots ,x_{k,l-1}\right)$, where $x_{i,j}$ is the $j$-th bit in ${x_i}^{\prime }s$. binary representation.

-

$BitDecom{p}^{-1}\left(x\right)$ = $\left(\sum 2^j·x_{1,j},\cdots ,\sum 2^j·x_{k,j}\right)$.

-

$Flatten\left(x\right)$ = $BitDecomp\left(BitDecom{p}^{-1}\left(x\right)\right)$.

-

$Powersof2\left(y\right)$ = ($y_1, 2y_1 \cdots , 2^{l-1}{y}_1, \cdots , y_k, 2y_k\cdots , 2^{l-1}{y}_k$).

So that the following equalities to hold,

$<BitDecomp\left(x\right),Powersof2\left(y\right)>$ = $<x,y>$

For any $N$ dimension vector $x^{\prime }$,

$<x^{\prime },Powersof2\left(y\right)>$ = $<BitDecom{p}^{-1}\left(x^{\prime }\right), y>$ = $<Flatten\left(x^{\prime }\right),Powersof2\left(y\right)>$ hold.

2.3. Ciphertext-Policy Attribute-Based Encryption

Ciphertext-policy attribute-based encryption (CP-ABE) is a type of public-key encryption and has been widely applied and employed in cloud storage systems [14,23]. In CP-ABE schemes, a user’s secret key is associated with the attributes, and ciphertext is associated with the access policy. Thus, a user can decrypt a ciphertext only if the attributes of his/her secret key match the access policies of the ciphertext. Therefore, data owners can define access policies to achieve fine-grained data sharing [24,25]. Thus, how to construct the access policy structure is the core of the CP-ABE scheme.

• Bilinear Mapping

Suppose $G_0$ and $G_T$ are two cyclic groups whose order p is prime, and the generator of $G_0$ is g. A bilinear map $e : G_0\times G_0\to G_T$ should satisfy the following properties:

(1)

Bilinear: For $\forall x,y \in Z_p^{\ast }$, $e\left(g^x,g^y\right)=e{\left(g,g\right)}^{xy}$.

(2)

Non-degeneracy: There exists $g_1,g_2\in G_0$, such that e($g_1,g_2$)$\ne$1.

(3)

Computability: For $\forall g_1,g_2\in G_0$, e($g_1,g_2$) could be computed easily.

• Linear secret sharing scheme

In the proposed system, we use a linear secret sharing scheme (LSSS) to define the access policy structure of the ciphertext. An LSSS scheme $\mathsf{\Pi }$ over $Z_q$ with a set of parties, P is linear, if:

(1)

Each party shares a secret number that forms a secret vector over $Z_q$.

(2)

There exists matrix $M$ for $\mathsf{\Pi }$ with $n$ columns and $l$ rows. For $\forall i=1,\cdots ,l$, the M’s $i$th row is defined as a function $\rho \left(i\right)$. Let a vector ${\mathit{v}}^T=\left(s,y_2,\cdots ,y_n\right)\in Z_q^n$, where s is a shared secret, and each $y_i \left(i=2,\cdots ,n\right)$ is randomly chosen. Thus, ${\lambda }_i={(M\mathit{v})}_i$, $i=1,\cdots ,l$, is the shared secret of s for $\mathsf{\Pi }$. There exists $w_i\in Z_q$, where $i\in I\subset \left\{1,2,\cdots ,l\right\}$ to make $\sum _{i\in I}{w}_i{\lambda }_i=s$ holds.

2.4. Homomorphic Signature Schemes

Homomorphic signature schemes are designed to verify the correctness of outsourcing computation to address pollution attacks [15]. The cost of the computation and communication of homomorphic signature is independent of the amount of data input by the verifier, and the time complexity of the algorithm within the O(1). A homomorphic signature scheme is a polynomial-time algorithm [26] and can be described as follows:

• Setup (${\mathbf{1}}^{\lambda }, \mathit{N}$)$\to${sk, pk}. Suppose $\lambda$ is a security parameter and $N>0$ is an integer. The algorithm output a key pair {$sk, pk$}, where $sk$ is a secret key and $pk$ is the corresponding public key.
• HSign (sk, m) $\to \mathit{\sigma }$. The algorithm generates a signature $\sigma$ for the message m, computed with the secret key $sk$.
• Eval (pk, $\mathit{f}$, $\overrightarrow{\mathit{\sigma }}$) $\to {\mathit{\sigma }}^{\prime }$. The algorithm takes a public key, $pk;$ a computable function, $f;$ and a signature tuple, $\overrightarrow{\sigma },$ as input. Then it outputs a signature, ${\sigma }^{\prime },$ which is a result of the function, $f,$ over the signature tuple, $\overrightarrow{\sigma }$.
• Vrf (pk,${\mathit{m}}^{\prime }$, ${\mathit{\sigma }}^{\prime }$) $\to \mathbf{0}/\mathbf{1}$. The algorithm takes a public key, $pk$; a signature, ${\sigma }^{\prime };$ and a message, $m^{\prime },$ which is the result of the function, $f,$ over the message tuple, $\overrightarrow{m},$ as input. It outputs 1, if ${\sigma }^{\prime }$ is valid for the message, $m^{\prime };$ otherwise it outputs 0.

2.5. Related Works

There are many cryptographic techniques proposed to solve the security problem in IoT applications, Saračević et al. designed a data encryption technique and key exchange model for a smart city [27,28]. To provide secure IoT data sharing, Mollah et al. [3] proposed a secure IoT data-sharing scheme based on the CEC framework that utilizes public key encryption and symmetric encryption, but the scheme supposes that the edge servers must share their data-search secret keys to retrieve the requested data for users, which causes communication overheads in practice. To address the above problem, Tao et al. [1] proposed a new CEC scheme that allows users to generate keyword search trapdoors based on the keywords and private key. However, they all assumed that the cloud server cloud does not tamper with users’ data.

While Fan et al. [13] proposed a secure and verifiable data sharing scheme to realize data sharing in VSNs. They upload the data’s access policy onto a blockchain, realizing the self-certification of users, data confidentiality, and cloud attack resistance. Wang et al. [14] proposed a framework that combines Ethereum and ABE to realize fine-grained access control of the data in IPFS. Through the decentralization, verifiability, and immutability properties of blockchain, these schemes ensure the integrity of the data stored on the server. Although ABE technology enables data owners to define the data access policy and ensure data security, the computing resource of the cloud is not utilized. It should be highlighted to provide verifiable data outsourcing computation without compromising data privacy.

Nowadays, cloud data computation privacy has become a focus of research [4,29]. FHE is one of the important technologies to ensure cloud data computing security, ciphertext retrieval, etc. The first FHE scheme was proposed by Gentry [30,31] in 2009. After Gentry’s proposition, there were several notable works on FHE over integers [32,33]. Some other works focused on improving the FHE scheme’s performance [34,35]. López-Alt et al. [36] implemented FHE on multi-party computation. Micciancio [37] and Boneh et al. [38] proposed the FHE is an important solution in the cloud computing area.

The FHE scheme ensures the privacy of data outsourcing computation, but it cannot verify the correctness of the ciphertext calculation results. In 2002, Johnson et al. [39] introduced a definition for homomorphic signatures. After that, many homomorphic signature schemes were proposed that improved efficiency, security, and privacy [40,41] of homomorphic signatures. To allow multi-private key signatures to do the homomorphic evaluation, Zhang et al. [42] added the homomorphic property to the aggregate signature schemes.

3. The Proposed System

3.1. System Architecture

The system consists of the following entities: an attribute authority (AA), IoT devices, edge servers, a cloud server, blockchain, and users.

AA is responsible for generating decryption keys as well as to evaluate keys for users. Additionally, the AA generates a public key for each IoT device.

IoT devices are data collectors that define the access policy of the data.

Edge servers are responsible for encrypting the IoT data and sending the ciphertext to the cloud. In addition, edge servers verify the correctness of the ciphertext stored on the cloud server (actually, edge servers verify the signatures signed by the cloud). All edge servers jointly maintain the blockchain. They run smart contact (described in Section 4.3.) to record the valid IoT data information on the blockchain. Moreover, during the ciphertext computation stage, edge servers run Pre-compute (described in Section 4.2) and Final-compute (described in Section 4.2.) to process the ciphertexts.

The cloud server stores the encrypted IoT data and computes ciphertexts for users. Moreover, it signs the ciphertexts via a signature algorithm (such as ECDSA) and a homomorphic signature algorithm separately.

The blockchain records the hash of the data, the cloud server’s signatures, and the access policy of the data.

Users are data and computation requesters.

As shown in Figure 1, the description of the step numbers are as follows:

• IoT devices send the collected data, their public key, and the access policy to the nearby edge server via a secure channel.
• The edge server encrypts the IoT data and sends the ciphertexts to the cloud server. Concretely, the edge server selects a secret message and then uses the attribute-based encryption scheme with the access policy as input to encrypt the trapdoor, r. Then, the edge server uses fully homomorphic encryption to encrypt the data with the trapdoor, r. Finally, the edge server sends the ciphertexts, c and c’, to the cloud server.
• The cloud server signs the hash of ciphertext, c, via a traditional signature algorithm and signs the hash of ciphertext, c’, via a homomorphic signature algorithm. Then, the cloud server returns the signatures to the edge server.
• The edge server verifies the signatures and records the valid signatures, the hash of data, and the access policies of the data on the blockchain.
• A user sends the access request or computation request to the cloud.
• The cloud server retrieves the ciphertext or computes the ciphertexts, then sends the ciphertext or ciphertext computation result to the user.
• The user decrypts the ciphertext and downloads the data from the blockchain. Then, the user verifies the validity of the data via the hash of the data or computation result via the homomorphic signatures.

3.2. Security Assumption

To ensure our system is secure, we make the security assumptions as follows:

Assumption 1. Edge servers may be compromised. Thus, an edge server may become a Byzantine node. Hence, we assume that the number of Byzantine nodes does not exceed one-third of the number of edge servers.

Assumption 2. We assume that IoT devices are not capable of encrypting data and calculating the hash value. Thus, we assume the IoT devices trust their nearby edge servers and send their data and access policies through a secure channel. In addition, we assume that users are capable of decrypting and computing the hash value.

Assumption 3. We assume that the cloud server is not fully trusted, which means it will provide services honestly but may tamper with the ciphertext. The AA is fully trusted. Users are dishonest to obtain ungranted access to data.

3.3. Security Goals

3.3.1. Cloud Attack Resistance

The proposed system should guarantee the cloud server could not deny the granted users access to the data.

3.3.2. Data Confidentiality and Integrity

The proposed system should ensure that only the granted users whose attributes of the secret key satisfy the access policy of the ciphertext could be able to decrypt and compute the ciphertext. In addition, the proposed system should guarantee the integrity of the ciphertext stored on the cloud.

3.3.3. Computation Privacy and Verifiability

To take advantage of the powerful computing capability of the cloud, the system should ensure the privacy of data during the computation process. Moreover, the computation result should be verifiable.

4. System Design

4.1. Construction

In this section, we introduce the processing of building a secure IoT data sharing system that supports ciphertexts computation. Concretely, as shown in Figure 2, the AA generates global parameters to set up the system by running Global Setup. Then AA generates data encryption keys for IoT devices by running IoT Devices Registration and generates decryption keys and evaluate keys based on the attributes of users by running Users Registration. To realize secure IoT data sharing and realize computable ciphertexts, edge devices share a random trapdoor under the IoT data access policy by encrypting the trapdoor via the PolicyEnc algorithm. Thus, only users whose attributes meet the access policy can obtain the trapdoor. Then, edge devices use the trapdoor to encrypt IoT data via the PlaintextEnc algorithm, which realizes data security and supports the ciphertext computation. We store the ciphertexts of IoT data, generated by edge devices, on the cloud. To confirm the reception and storage of the corresponding ciphertext correctly, the cloud server runs Cloud Signature to calculate the ordinary signature and homomorphic signature of the ciphertexts separately. Then, the cloud server sends the signatures to the edge server. The edge server runs Blockchain Record to record the IoT data information via invoking smart contract (described in Section 4.3) after verifying that the signatures are valid and the ciphertexts have not been tampered with. When users want to obtain IoT data, they send an access request to the cloud server by running Users Retrieve. The cloud server determines whether to return the corresponding ciphertexts via evaluating whether the attributes of the users meet the access policy of the IoT data. After obtaining the ciphertexts, users decrypt the trapdoor with their attribute private keys by running the PolicyDec algorithm and then running the PlaintextDec algorithm to get the IoT data by inputting the trapdoor. Finally, the user verifies the plaintext by comparing the data information downloaded from the blockchain via running Verify Data.

• Global Setup($\lambda , L$) $\to \left\{msk, pp\right\}$: The AA chooses $k=k\left(\lambda , L\right)$ as the security parameter, $G_0$, $G_1$ are cyclic groups whose order are prime p, g is a generator of $G_0$,$e:G_0\times G_0\to G_1$ is a bilinear map, and $H: {\left\{0,1\right\}}^{\ast }\to G_0$ is a hash function. Then AA choose two random numbers $\alpha ,\beta \in Z_p$, and computes $mpk=\left(G_0,H,g,h=g^{\beta },e{\left(g,g\right)}^{\alpha }\right)$, $msk=\left(\beta ,g^{\alpha }\right)$. In addition, the AA takes a lattice dimension $n=n\left(\lambda , L\right)$, an error distribution $\chi = \chi \left(\lambda ,L\right)$, and an integer q as input. Then, AA sets $m = O\left(n\log q\right)$, $N=\left(n-1\right)\left(\left|\log q+1\right|\right)$, $\mathit{t}\leftarrow Z_q^n$ and constructs a uniform distribution matrix $E_r\in {\left(0,1\right)}^{N\times N}$. Finally, AA outputs the global parameter $pp=\left(mpk, n, q, m, \mathit{t}, E_r\right)$.
• IoT Devices Registration(pp)$\to$ pubKey: AA generates encryption public key for IoT devices. Specifically, $B\leftarrow Z_q^{m\times n}$ is a matrix, and $e\leftarrow {\chi }^m$ is a vector, AA computes the vector $b=Bt+e$, where $t\in Z_q^n$, and let $A = (b | B)$, then it outputs pubKey = (mpk, $E_r$, A).
• Users Registration(pp, msk, attrs) $\to${evalKey, prvKey}: In this algorithm, AA generates evaluate keys and decryption keys for users. Upon receiving the attributes, $attrs\in string$, of a user, the AA chooses two random numbers $r,r_{attr}\in Z_p$, and then generates the attribute key $ABE.sk=(D=g^{\frac{\alpha +r}{\beta }},\forall attr\in attrs:D_{attr}=g^{r}H{\left(attr\right)}^{r_{attr}},D_{attr}^{\prime }=g^{r_{attr}})$. After that, the AA choose $s\leftarrow \left(1,-t_1,\cdots ,-t_n\right)\in Z_q^{n+1}$, where $t_i\in \mathit{t}$, and computes $\mathit{v}=Powerof2\left(\mathit{s}\right)$. Finally, the AA outputs the evaluate key as evalKey = (ABE.sk, $E_r$) and the decryption key as prvKey = (ABE.sk, $\mathit{v}$, $E_r$).
• Encrypt (pp, pubKey, policy, d)$\to${$C_t,C_d$}: Once an edge server receives the access policy of data, the public key of IoT device, and the data. The edge server encryptions a trapdoor, which is used for encrypting the IoT data, under the policy of IoT data.
  PolicyEnc(pp, policy)$\to C_t$: During the policy encryption phase, the edge server chooses a random trapdoor $m_r\in G_1$, an encryption exponent $s\in Z_p$, and a vector $\mathit{w}=\left(s,a_2,\cdots ,a_n\right)\in Z_p^n$. Let policy = (M, $\rho$), the edge server computes ${\lambda }_i=\mathit{w}·M_i$, for $i$= 1 to $l$ ($l$ is the number of the matrix M’s rows and $M_i$ is the M’s $i$th row), and outputs $C_t=(C_{m_r}=m_{r}e{\left(g,g\right)}^{\alpha s}, C_s=h^s, \forall i\in \left[1,l\right], C_i=g^{{\lambda }_i},C_i^{\prime }=H{\left(att{r}_i\right)}^{{\lambda }_i})$.
• PlaintextEnc (pp, pubKey, d)$\to C_d$: During the data encryption phase, the edge server chooses a unique distribution matrix, $R\in {\left\{0,1\right\}}^{N\times m}$, and computes $C_d=Flatten\left(d{I}_N+BitDecomp\left(R·A\right)+m_r{E}_r\right)\in Z_q^{N\times N}$.

Finally, the edge server sends {$C_t,C_d$} to the cloud server.

• Cloud Signature{$C_t,C_d$} $\to$ $\{Sig{n}_{csk}\left(H(C_t\right)),HSig{n}_{hcsk}\left(C_d\right)$}: On receiving the {$C_t,C_d$} from an edge server, the cloud stores the ciphertexts on the cloud. Then, the cloud signs the hash of the ciphertext, $C_t,$ via a signature algorithm with its secret key, csk, that is, $Sig{n}_{csk}\left(H\left(C_t\right)\right)$, and signs the ciphertext, $C_d,$ via a homomorphic signature algorithm with its homomorphic secret key, hcsk, that is, $HSig{n}_{hcsk}\left(C_d\right)$. Finally, the cloud returns the signatures to the edge server.
• Blockchain Record ($Sig{n}_{csk}\left(H(C_t\right)),HSig{n}_{hcsk}\left(C_d\right)$): On receiving $Sig{n}_{csk}\left(H(C_t\right)),HSig{n}_{hcsk}\left(C_d\right)$ from the cloud, the edge server first verifies the signatures. If the signatures are invalid and the ciphertexts have been tampered with, the edge server sends error information to the cloud. Otherwise, the edge server constructs a transaction = {$H\left(d\right),Sig{n}_{csk}\left(H(C_t\right)),HSig{n}_{hcsk}\left(C_d\right)$, (M, $\rho$)}. Then the edge server signs the transaction’s hash with its secret key, edev, that is, $Sig{n}_{edev}\left(H\left(transaction\right)\right)$. Finally, the edge server packages the transaction and the signature and then broadcasts them in the edge server network.
• Users Retrieve: Users send the data requests to the cloud. The cloud decides whether to return the ciphertext ($C_t,C_d$) to users by evaluating whether the attributes of users meet the access policy of the IoT data.
• Decrypt(pp, prvKey,$C_t,C_d$): This algorithm consists of PolicyDec and PlaintextDec and is run by users.

  (1)

  PolicyDec(pp, prvKey,$C_t$)$\to m_r$: When users receive the ciphertext, it means there exist $k_i\in Z_p, i\in I$ satisfying $\sum _{i\in I}{k}_i{\lambda }_i=\left\{s\right\}$. Thus, users calculate Formula (1).

  $$\begin{array}{c}{C_t}_{\prime }={\prod }_{i\in I}\frac{e{\left(D_{attr},C_i\right)}^{w_i}}{e\left({D_{attr}}^{\prime },{C_i}^{\prime }\right)}\\ ={\prod }_{i\in I}\frac{e{(g_{r}H{(attr)}^{r_{attr}},g^{{\lambda }_i})}^{k_i}}{e(g^{r_{attr}},H{\left({attr}_i\right)}^{{\lambda }_i})} = e{(g,g)}^{rs}\end{array}$$

  (1)

  Then, users obtain $m_r$. by calculating Formula (2).

  $$\frac{C_t}{\frac{e\left(C_s,D\right)}{C_t^{\prime }}}= \frac{m_{r}e{\left(g,g\right)}^{\alpha s}}{\frac{e\left(h^s,g^{\frac{\alpha +r}{\beta }}\right)}{e{\left(g,g\right)}^{rs}}} = m_r$$

  (2)

  (2)

  PlaintextDec (pp, prvKey,$C_d$) $\to d$: Users compute $C_d^{\prime }=C_d-Flatten\left(m_r{E}_r\right)$, and $\mathit{x}=C_d^{\prime }\mathit{v}=dv+RA\mathit{s}=d\mathit{v}+R\mathit{e}$. Then users process vector $\mathit{x}$ as: $bi{t}_i=\min \left(x_i, q-x_i\right)$. Finally, users get the plaintext by computing d + = $bi{t}_i{2}^{l-1-i}$, where $i=\left\{l-2,\cdots ,0\right\}$.

• Verify Data($d$) → 0/1: When a user gets the plaintext of the data, d, he computes d’s hash value. Then the user verifies whether the hash value is equal to the H(d) stored on the blockchain. If they are not equal, the user outputs 0. Otherwise, the user outputs 1.

4.2. Ciphertext Calculation

In some cases, users want to process the data stored on the cloud. Therefore, we add ciphertext computation (i.e., Pre-Compute, Compute, and Final-Compute) and Computation Correct Verify processes to the system.

As shown in Figure 3, users could outsource their computing to the cloud as follows:

• Pre-Compute(pp, f, ($C_{t_1}, C_{d_1}$),$\cdots ,$($C_{t_n},C_{d_n}$), $evalKe{y}_1, \cdots ,evalKe{y}_n$)$\to$ {$C_{d_1}^{\prime },\dots ,C_{d_n}^{\prime }$}: Once the edge server receives a user’s computation request, it downloads the ciphertexts from the cloud. Then it calls the PolicyDec algorithm to decrypt the ciphertexts to get $d_{r_i}$($i=1,\cdots$,n). Finally, the edge server computes $C_{d_i}^{\prime }= C_{d_i}-Flatten\left(m_{r_i}{E}_r\right)$, ($i=1,\cdots$,n) and sends $f$, $C_{d_i}^{\prime }$ $i=1,\cdots ,n$ to the cloud server.
• Compute(f, $C_{d_1}^{\prime }$,$\cdots$,$C_{d_n}^{\prime }$) $\to C_{\prime }$: Once the cloud server receives the $f$ and $C_{d_i}^{\prime }$ $i=1,\cdots ,n$, it computes $C^{\prime }=f\left(C_{d_1,}^{\prime }{C}_{d_2,\cdots ,}^{\prime }{C}_{d_n}^{\prime }\right)$ and returns $C_{\prime }$ to the edge server.
• Final-Compute($C^{\prime }$)$\to$ $C_d^{\prime }$: On receiving $C^{\prime }$, the edge server selects a random r and calls PolicyEnc(pp, policy)$\to C_t^{\prime }$ to encrypt the trapdoor, r. Then the edge server computes $C_d^{\prime }= C^{\prime }-Flatten\left(r{E}_r\right)$ and returns $\left\{C_t^{\prime }, C_d^{\prime }\right\}$ to the user.
• Computation Correct Verify(hcpk, policy, f, $\left\{C_t^{\prime }, C_d^{\prime }\right\}$): On receiving $\left\{C_t^{\prime }, C_d^{\prime }\right\}$, the user downloads homomorphic signatures from blockchain and computes Eval(hcpk, f, $hsig{n}_{hcsk}$($C_{d_1}$),$\cdots$, $hsig{n}_{hcsk}$($C_{d_n}$)) $\to$ $\left\{\sigma \right\}$, and then verifies whether Vrf(hcpk, $C_d^{\prime }$, $\sigma$) = 1 holds. If the signature is invalid, the user sends error information to the edge server and cloud server. Otherwise, the user decrypts the ciphertext to obtain the calculated plaintext, $d = f\left(d_1,d_2,\cdots ,d_n\right)$.

4.3. Smart Contract

In our scheme, the blockchain acts as a trusted party to record the data information, which consists of the hash of data, the signature of the ciphertext signed by the cloud, and the access policy of the data. Users could supervise the cloud server to return the correct ciphertexts and the correct ciphertext calculation results based on the data information.

Edge servers use the smart contract to upload the data information. Specifically, after verifying the signature and the homomorphic signature signed by the cloud (described in Section 4.1. Blockchain Record), the edge server uploads IoT data information onto the blockchain via invoking uploadDataInfo described in Algorithm 1.

Algorithm 1. UploadDataInfo

Input: DataInfo $\% \mathrm{DataInfo} = \left\{H\right(mm), Sig{n}_{csk}\left(H(C_t\right)),HSig{n}_{hcsk}\left(C_m\right)$, (M, $\rho$)} Output: bool if msg.sender is not the nearby edge then return false else dataList[address] = DataInfo; return true end

In addition, during the verification phase (described in Section 4.1. Verify Data and Section 4.2. Computation Correct Verify) users get the IoT data information via invoking getDataInfo described in Algorithm 2.

Algorithm 2. GetDataInfo

Input: address Output: DataInfo return dataList[address] = DataInfo; end

5. Security Analysis

This section presents security analyses of the proposed system in both formal and informal ways.

5.1. Formal Security Analysis

Theorem 1.

Assume that the digital signature, $Sign,$and the homomorphic signature,$HSign,$are unforgeable under chosen message attacks, and the hash function,$H,$is second pre-image resistant, and the blockchain can resist tampering attacks. Then the proposed system is secure for static cloud adversaries.

Adversary Model: Let $\mathcal{A}$ be a cloud adversary, we assume $\mathcal{A}$ to have (1) capability to decide whether to return the ciphertexts to users; (2) ful control over the ciphertext of IoT data. Thus $\mathcal{A}$ may launch attacks such as denying authorized users to access IoT data, data forgery, and data tampering.

Lemma 1.

It is not possible for$\mathcal{A}$to record illegal signatures of ciphertexts on the blockchain and change the blockchain data as long as he/she corrupted no more than 1/3 of blockchain nodes or controls not more than 50% of the total computation power.

Proof. 

Before the information of IoT data is uploaded to the blockchain, the cloud signs the ciphertexts via digital signature and homomorphic signature. The edge server verifies the signatures and only records the valid IoT data information on the blockchain. Thus $\mathcal{A}$ cannot record illegal $Sig{n}_{csk}\left(H(C_t\right)),HSig{n}_{hcsk}\left(C_d\right)$ on the blockchain by forging wrong signatures. Furthermore, the blockchain consists of blocks connected by the hash of the former block. To change the blockchain data, $\mathcal{A}$ needs to successfully corrupt more than 1/3 of blockchain nodes (based on the PBFT consensus algorithm) or have more than 50% of the total computational power of the network (based on the POW consensus algorithm). □

Lemma 2.

It is not possible for$\mathcal{A}$to return incorrect ciphertext and incorrect ciphertext calculation results to requesters (or users), named R.

Definition 1.

Consider that the cloud returns a ciphertext, ($C_t,C_d$to R. R runs Dec(pp, prvKey,$C_t,C_d$) (described in Section 4.1.) and gets the plaintext, d. Then R gets the data information {H(d),$Sig{n}_{csk}\left(H(C_t\right)),HSig{n}_{hcsk}\left(C_d\right)$, (M, $\rho$)} via invoking getDataInfo (described in Algorithm 2). Finally, R checks the signatures$Sig{n}_{csk}\left(H(C_t\right))$ and $HSig{n}_{hcsk}\left(C_d\right)$ and computes the hash of plaintext, d, denoted by H′(d), and then compares H′(d) with H(d). If the signature is valid and H′(d) is equal to H(d), R regards ($C_t,C_d$) as the correct ciphertext.

Definition 2.

Consider that the cloud returns a calculated ciphertext result, ($C_t^{\prime },C_d^{\prime }$), where$C_d^{\prime }= C^{\prime }-Flatten\left(r{E}_r\right)$and$C^{\prime }=f\left(C_{d_1,}^{\prime }{C}_{d_2,\cdots ,}^{\prime }{C}_{d_n}^{\prime }\right)$to R. Then R gets the data information {H($d_i$), $Sig{n}_{csk}\left(H(C_{t_i}\right)),HSig{n}_{hcsk}\left(C_{d_i}\right)$, (M, $\rho$)}$\left(i = 1,2,..,n\right)$ via invoking getDataInfo (described in Algorithm 2). Finally, R computes Eval(hcpk, f, $hsig{n}_{hcsk}$($C_{d_1}$),$\cdots$, $hsig{n}_{hcsk}$($C_{d_n}$)) $\to$ $\left\{\sigma \right\}$, and then verifies whether Vrf(hcpk, $C_d^{\prime }$, $\sigma$) = 1 holds. If the equation holds, R regards ($C_t^{\prime },C_d^{\prime }$) as the correct ciphertext computation result.

Proof. 

If $\mathcal{A}$ wants to return an incorrect ciphertext, ($C_t,C_d$), or an incorrect ciphertext computation result, ($C_t^{\prime },C_d^{\prime }$), to R. $\mathcal{A}$ needs to tamper the hash, H(d), and forge signatures $Sig{n}_{csk}\left(H(C_t\right)),HSig{n}_{hcsk}\left(C_d\right)$ recorded on the blockchain. As shown in Lemma 1, it is not possible for $\mathcal{A}$ to record illegal IoT information on the blockchain. □

Theorem 2.

The proposed system cannot deny the authorized users’ access requests and can protect the privacy of IoT data from being disclosed to unauthorized users.

Proof. 

The proposed system algorithm encrypts the IoT data under the access policy of the IoT data, and generates the users’ private key, which is associated with users’ attributes. Thus, a user could decrypt the ciphertext, only when the attributes of his/her private key satisfy the access policy of the ciphertext. (1) Suppose a cloud adversary, $\mathcal{A},$ refuses to return ciphertext to authorized users. Users can propose an objection and get the corresponding access policy in the blockchain to prove the illegal behavior of $\mathcal{A}$. Thus, $\mathcal{A}$ cannot deny authorized users’ access requests. (2) Suppose a cloud adversary, $\mathcal{A},$ returns ciphertexts to unauthorized users. Because the attributes of users do not satisfy the access policy of the ciphertexts, users cannot decrypt the ciphertext. Thus, our system can protect the privacy of IoT data from being disclosed to unauthorized users. □

5.2. Informal Security Analysis

We will informally explain how the system achieves the security goals described in Section 3.3.

(1)

Cloud attack resistance: We have assumed that the cloud server may tamper with data and deny granted users access to data. In our scheme, we upload the data’s access policy onto the blockchain. The user can determine whether his/her attributes are satisfied with the access policies of the ciphertext. Therefore, the cloud server cannot deny the granted user access to the IoT data.

(1)

Data confidentiality: In our system, we use FHE to encrypt the data and the trapdoor, $m_r,$ to make data computable. Then we use ABE to encrypt the trapdoor, thus only the users whose attributes satisfy the access policies of the ciphertext could get the trapdoor. Therefore, our scheme satisfies the data confidentiality.

(3)

Data integrity: We also upload the data’s hash onto the blockchain. When users obtain data from the cloud server, they can execute Verify Data (described in Section 4.1) to ensure the integrity of the IoT data. Therefore, the cloud server cannot tamper with the data in our scheme.

(4)

Computation privacy: The computation privacy of our scheme is based on FHE, which allows arbitrary computation on the encrypted data without decrypting it. The cloud computes the ciphertext for users with an evaluate key that satisfies the access policies who could not get any information of data due to the security of FHE. Therefore, our scheme could ensure the privacy of the data during the processing.

(5)

Computation verifiability: The cloud uses a homomorphic signature algorithm to sign the encrypted data, so users can verify whether the ciphertext computation result is correct by verifying the homomorphic signature.

To show the advantage of our system, we compared the proposed system with the existing IoT data protection system in terms of the following features. “Privacy” represents the protection of IoT data against unauthorized access, “fine-grained access control” means each data item has its own access control policy, “integrity” refers to the accuracy and consistency of data over its lifecycle, “ciphertext calculation” is the ability to compute the ciphertext, and “trustworthiness” represents that the required data and calculation results can be verified by the user.

Table 1. Comparison between our system with other data protection system in the internet of things (IoT).

Feature	Our System	Manzoor’s System [43]	DING’s System [1]	Fan’s System [13]	Truong’s System [44]
privacy	√	√	×	√	×
fine-grained access control	√	×	√	√	×
integrity	√	√	√	√	√
ciphertext calculation	√	√	×	√	×
trustworthiness	√	×	√	√	×

illustrates that our system not only owns the functionalities of ciphertext calculation but also provides privacy, fine-grained access control, integrity, and trustworthiness of the IoT data.

6. Performance Evaluation

In this section, we implemented and evaluated the performance of the proposed scheme. The performance evaluation was broken into two parts. The time cost for processing the cryptographic schemes is studied in the first part. The blockchain efficiency is studied in the second part.

6.1. System Settting

The efficiency of the scheme mainly depends on the blockchain platform, computing platform, and performance of the cryptographic scheme. For instance, in this paper, we use the Hyperledger Fabric (HLF) as the blockchain platform, since HLF is a platform for permissioned distributed ledger solutions, underpinned by a modular architecture delivering high degrees of confidentiality, resiliency, flexibility, and scalability. In addition, we use a popular cryptography library Pairing-Based Cryptography (PBC) [45], which implements pairing-based cryptosystems (described in Section 2.3.). Thus, we can realize CP-ABE by choosing an elliptic curve group. Moreover, based on the public HElib [46], which implements various forms of homomorphic encryption with many optimizations to make homomorphic evaluation run faster, we implement the FHE algorithm.

Specifically,

Table 2. Configuration of system parameters.

	Edge Server	Cloud Server
CPU	Intel® Core™ i3-2130 M 3.40 GHz	Intel® Core™ i5-7300 U 2.60 2.71 GHz
RAM	4G	8G
OS	Ubuntu 18.04 LST	Ubuntu 18.04 LST

shows the hardware and software environments, and we used HLF v1.2 to initialize a permissioned blockchain in the edge server which was configured cpabe-0.11 [47], while we configured could server with HElib to implement the homomorphic calculation.

6.2. Proccessing Time of Cryptogrphic Shceme

6.2.1. ABE Overhead

We evaluate the ABE performance on a personal computer based on PBC library (version 0.5.14). Specifically, we use a 160-bit elliptic curve group based on the supersingular curve $y^2=x^3+x$ over a 512-bit finite field. We consider a user with a different number of attributes to generate ABE.sk. Figure 4a shows the time for AA to generate attribute keys is approximately 0.021–0.104 s. Figure 4b,c shows the time for edge servers’ encryption and users’ decryption in our scheme.

6.2.2. FHE Overhead

We evaluate the FHE performance on a personal computer based on HElib, which is a software library that implements BGV [48]. Specifically, we choose different security parameters, $\lambda =\left\{80, 256\right\};$ plaintext spaces, $P=\left\{2, 2^{40}\right\};$ and evaluation function levels, $L=\left\{16, 200\right\}$.

Table 3. Time cost for fully homomorphic encryption (FHE, s).

Parameters	Key Generation ${\mathit{T}}_{\mathit{F}\mathit{H}\mathit{E}.\mathit{k}\mathit{G}\mathit{e}\mathit{n}}$	Encryption ${\mathit{T}}_{\mathit{F}\mathit{H}\mathit{E}.\mathit{E}\mathit{n}\mathit{c}}$	Addition ${\mathit{T}}_{\mathit{F}\mathit{H}\mathit{E}.\mathit{A}\mathit{d}\mathit{d}}$	Multiplication ${\mathit{T}}_{\mathit{F}\mathit{H}\mathit{E}.\mathit{M}\mathit{u}\mathit{l}}$	$\mathbf{Decryption} {\mathit{T}}_{\mathit{F}\mathit{H}\mathit{E}.\mathit{D}\mathit{e}\mathit{c}}$
$\lambda$= 80, P = 2, L = 16	0.11635	0.01420	0.00010	0.00836	0.00089
$\lambda$= 80, P = 2, L = 200	0.48225	0.07500	0.00208	0.09007	0.01485
$\lambda$= 80, P =$2^{40}$, L = 16	0.64053	0.01865	0.00019	0.00901	0.00091
$\lambda$= 80, P =$2^{40}$, L = 200	5.6135	0.07280	0.09280	0.01470	0.00218
$\lambda$= 256, P = 2, L = 16	0.57431	0.02903	0.00021	0.02106	0.00219
$\lambda$= 256, P = 2, L = 200	20.2508	0.18132	0.00453	0.21242	0.03752
$\lambda$= 256, P =$2^{40}$, L = 16	2.08672	0.03180	0.00021	0.02188	0.00219
$\lambda$= 256, P =$2^{40}$, L = 200	38.4297	0.19377	0.00470	0.22477	0.03795

shows the measured values (average of 100 runs) of the key generation time, encryption time, ciphertext addition calculation time (two ciphertext addition), ciphertext multiplication calculation time (two ciphertext multiplication), and decryption time.

6.2.3. Homomorphic Signature Overhead

We suggest using Wang’s scheme [49] to test the efficiency of the homomorphic signature. The signing cost of running one-time signature is 1psf. The psf denotes the computation cost of running the PFS algorithm.

6.3. Smart Contract

We use HLF v1.2 to realize the designed smart contract (chaincode) described in Algorithms 1 and 2 and build a five-node PC test environment. Specifically, one PC acts as the orderer node with a Kafka/Zoomkeeper, and only one channel was established. We use the default endorsement policy of HLF and fixed the complexity of the transaction’s payload field as 1000 bytes. Inspired by [50], we study the latency and throughput of each smart contract for different block sizes and various transaction arrival rates.

Table 4. Block size (#tansactions) and transaction arrival rate.

Parameters	Values
Block size	10, 30, 50
Transaction arrival rate	25, 50, 75, 100

shows the block sizes and transaction arrival rates used in our tests.

After deploying the smart contract (chaincode) on the blockchain, we simulated different transaction arrival rates by triggering smart contracts different times per second and conducted 1000 s of experiments.

Figure 5 shows uploadDataInfo average latency (i.e., time taken from uploadDataInfo trigging to DataInfo committed to the blockchain ledger) and throughput (i.e., the rate at which DataInfo are committed to the blockchain) for different parameters referred to in Table 4.

Figure 6 shows getDataInfo’s average latency (i.e., time taken from getDataInfo trigging to DataInfo being returned to users) and throughput (i.e., rate of getting DataInfo from the blockchain) for different parameters referred to in Table 4.

6.4. System Performance

To show the utility of our system, we evaluate the communication and computation costs of each phase of the system.

Table 5. Communication and computation cost(s) of IoT data sharing.

Phase	Communication Cost	Computation Cost
Global Setup	$G_1$ + 4|$G_0$| + |n($\mathsf{\lambda }$,L)| + (n + 1)|$Z_q$| + $N^2$	$T_{\mathit{FHE}.\mathit{kGen}}$
IoT Device Registration	$G_1$ + 4|$G_0$| + $N^2$ + $\left(m+\mathit{mn}\right)$|$Z_q$| + m.|$\mathsf{\chi }$|	$T_{\mathit{ABE}.\mathit{PkGen}}$
Users Registration	$\left(2n+1\right)\left|G_0\right|$ + (n + 1)$2^{\left|\log q+1\right|}$ +${ N}^2$	${nT}_{\mathit{ABE}.\mathit{SkGen}}$
Enypt	$G_1$ + 3|$G_0$| +${ N}^2$	${{\displaystyle N}T}_{\mathit{ABE}.E{\displaystyle NC}}$ + $T_{\mathit{FHE}.E{\displaystyle NC}}$
Cloud Signature	$\left|\mathsf{\lambda }\right|$ + $m\log q$ + n	$T_{{\displaystyle \mathit{SIGN}}}$ + $T_{H{\displaystyle \mathit{SIGN}}}$
Blockchain Record	|H| + $\left(l+1\right)\times n$ |$Z_q$ |	$T_{{\displaystyle \mathit{VERIFY}}}$ + $T_{H{\displaystyle \mathit{VERIFY}}}$ + $T_{{\displaystyle \mathit{HASH}}}$ + uploadDataInfo
Users Retrieve	$G_1$ + 3|$G_0$| +${ N}^2$	0
Deypt	0	${\displaystyle N}{T}_{\mathit{ABE}.D{\displaystyle EC}}+T_{\mathit{FHE}.\mathit{Dec}}$
Verify Data	|H| +$\left(l+1\right)\times n$|$Z_q$|	getDataInfo + $T_{{\displaystyle \mathit{HASH}}}$

Note that n is the number of attributes, |H| is the length of a hash function, uploadDataInfo and getDataInfo are smart contract algorithms.

shows the cost of the IoT data sharing process described in Section 4.1.

Table 6. Communication and computation cost(s) of IoT data computation.

Phase	Communication Cost	Computation Cost
Pre-Compute	$n{G}_1$ +$3n$|$G_0$| + $n{N}^2$	${{\displaystyle n}T}_{\mathit{Flatten}}$
Compute	|f| +$n{2}^{\left|\log q+1\right|}$	$n_{\mathit{add}}.T_{\mathit{FHE}.\mathit{Add}}$ + $n_{\mathit{mul}}.T_{\mathit{FHE}.\mathit{Mul}}$
Final-Compute	$G_1$ + 3|$G_0$| + $N^2$	$T_{\mathit{ABE}.\mathit{Enc}}$ +${ T}_{\mathit{Flatten}}$
Computation Correct Verify	$n\left|H\right|$ + $\left(l+1\right)\times n^2$|$Z_q$|	O(1) or O(1) + $T_{\mathit{ABE}.D{\displaystyle \mathit{EC}}}$ + $T_{\mathit{FHE}.D{\displaystyle \mathit{EC}}}$

Note that n is the number of ciphertexts, $n_{\mathit{add}}$ is the number of addition operation in f, $n_{\mathit{mul}}$ is the number of multiplication operation in f, $T_{\mathit{Flatten}}$ is the time costs of Flatten computation.

shows the cost of the IoT data computation process described in Section 4.1.

6.5. System Limitation

Since the homomorphic signature scheme does not support the verification of arbitrary computation, our system can only verify the ciphertexts calculated on the polynomial function, $f$. In addition, our system needs multiple times of interact and ciphertext pre-process between edge servers and cloud server. It is not suitable for application scenarios with real-time requirements.

7. Conclusions

In this article, we proposed a computable and secure IoT data sharing scheme, which is based on blockchain, ABE, FHE, and homomorphic encryption. In the scheme, we use FHE to encrypt the data, realizing secure data computation. Then we used ABE to realize fine-granted IoT data sharing. In addition, we upload the data’s access policy onto the blockchain, which allows any user to verify whether their attributes satisfied the access policy at any time. To ensure the correctness of the ciphertext computation, we used a homomorphic signature algorithm to sign ciphertexts. The security analysis proved that the proposed scheme is secure, and the performance evaluation experiments show that the scheme is practical.

Our solution can be deployed in IoT architectures that require trusted storage and computation. For example, in the smart hospital scenario, the data collected by medical equipment can be encrypted by PCs and stored in the cloud server. The corresponding access-control policies can be formulated by patients. Doctors can access and process the data according to their authorities and outsource complex data calculation requests to the cloud.

In future research, we are looking for alternatives to homomorphic signatures to verify ciphertext calculation results. Moreover, we will reduce the number of interactions between the cloud server and the edge server in the ciphertext calculation process.