# A Lightweight Fine-Grained Searchable Encryption Scheme in Fog-Based Healthcare IoT Networks

Authors: Hui Li; Tao Jing
Journal: Wireless Communications and Mobile Computing
 (2019)

---

## Abstract

For a smart healthcare system, a cloud based paradigm with numerous user terminals is to support and improve more reliable, convenient, and intelligent services. Considering the resource limitation of terminals and communication overhead in cloud paradigm, we propose a hybrid IoT-Fog-Cloud framework. In this framework, we deploy a geo-distributed fog layer at the edge of networks. The fogs can provide the local storage, sufficient processing power, and appropriate network functions. For the fog-based healthcare system, data confidentiality, access control, and secure searching over ciphertext are the key issues in sensitive data. Furthermore, how to adjust the storage and computing requirements to meet the limited resource is also a great challenge for data management. To address these, we design a lightweight keyword searchable encryption scheme with fine-grained access control for our proposed healthcare related IoT-Fog-Cloud framework. Through our design, the users can achieve a fast and efficient service by delegating a majority part of the workloads and storage requirements to fogs and the cloud without extra privacy leakage. We prove our scheme satisfies the security requirements and demonstrate the excellent efficiency through experimental evaluation.


---

## Body

## 1. Introduction

Since Ashton [1] and Brock [2] firstly proposed the concept of IoT, it has been widely used in real life by combining with technologies in sensor networks, embedded system, object identifications, and wireless networks in order to tag, sense, and control things over the Internet [3–6]. With the ubiquitous nature of IoT, it makes great contribution in improving the equality of medical care by empowering remote monitoring and reducing time cost through implanting sensors or wearing mobile devices. According to the insight from [7], the healthcare system will evovle into a home-centered paradigm in 2030 from the current hospital-centered one. As more sensors are deployed in the healthcare system, the seamless data needs to be stored, processed, and transmitted. This may cause a great challenge to the traditional IoT-cloud infrastructure from the aspects of reliability, immediate response, and security [8]. This calls demand for a “mediator” between IoT devices and cloud server to support geo-distribution, storage, and computing capability, acting as an extension of the cloud, which is officially called fog from the concept of fog computing proposed by Cisco [9].When storing sensitive data like personal health records to cloud servers, the security and privacy of these data are still challenges in the fog computing paradigm [10–12]. To solve this problem, applying access control mechanism is an essential method to protect the sensitive data from unauthorized users. As a new type of IBE proposed by [13], attribute-based encryption (ABE) plays a great role in access control, which is classified into the key-policy attribute-based encryption (KP-ABE) and the ciphertext-policy attribute-based encryption (CP-ABE). KP-ABE associates user’s private keys with the designated policies and tags ciphertexts with attributes, while CP-ABE is related to ciphertexts with the designated policies and identifies the user’s private key with attributes [14, 15]. Obviously, CP-ABE is a better choice to execute access control in our model since it is the user’s ability to designate an access structure and process the encryption operation under the structure.However, most existing ABE schemes are time consuming in the key generation phase and have a large computational load in the decryption phase, which leads to suffering a bad experience for users. Also, how to maintain effective search in the encrypted ciphertext is a great challenge. Searchable encryption especially searchable public encryption is an effective approach to solve the above problem. And it is important to reduce complex operations, e.g., pairing and exponential operations, for users in the searchable public encryption.


### 1.1. Motivation and Contribution

The IoT infrastructure, such as the monitoring devices in a traditional hospital or health management wearable devices in a smart home, continuously synchronizes data to the remote cloud. The massive sensitive data leads to a great challenge to the current healthcare-related IoT-to-cloud system due to the nature of IoT’s limited storage, low power, and poor computability. In this paper, we attempt to solve the problem above as follows:(i)
We propose a fog-supported hybrid infrastructure as shown in Figure1. The distributed fogs are deployed between IoT devices and clouds, providing temporary data storage, data computation and analysis, and network services [16], so as to reduce transmission delay. Also, they help to manage users and attributes under the control of trusted authority.Figure 1
A Fog-based healthcare system.With the proposed infrastructure above, we design a new scheme to implement some specific network functions to meet real world needs. We will show it by exhibiting an example as follows. A person named Wealth rarely cares about his physical condition. One day he knows his friend Bob is suffering from hyperglycemia, and then he wants to learn about it. When he searches “Hyperglycemia" in cloud service providers such as “BodyMedia", “Google Health", “CiscoHealthPresence", or “IBM Bluemix", clouds know that he or someone he knows may get hyperglycemia. Obviously, his personal health privacy is exposed to the clouds. In order to prevent privacy disclosure, we construct indexes for “Hyperglycemia" in the file encryption phase through some secure methods. To search such a keyword, we need to generate the corresponding trapdoors with the help of the fog. Upon receiving the trapdoor, clouds return all the encrypted files associated with the specific “Hyperglycemia" if the trapdoor matches with the index. We can protect Wealth’s searching privacy by this way as follows.Further, we consider Wealth receives all files through searching “Hyperglycemia" by performing our designs. After realizing the importance of keeping healthy, he decides to start his own fitness program to monitor his health indicators such as Glycemic index through wearable sensors. Also, due to the limited storage of his own devices, he has to store his data to the cloud and shares it to some designated ones which have specific attributes. If someone without sufficient attributes attempts to search the keyword, he/she is impossible to generate a valid trapdoor matching with a keyword’s index, not to mention to get Wealth’s sensitive data. We help Wealth to accomplish this goal through the following designs.In summary, Wealth could enjoy an efficient, fast, high-quality, and secure service through adopting our system.The main contributions of this article are exhibited as follows:(i)
We design a keyword searchable encryption scheme in the healthcare related IoT-fog-cloud infrastructure. The proposed scheme ensures a security requirement that both data and keywords are protected from the cloud and the fog, which is very essential to users in the health related environment.(ii)
With the restriction of constrained resource, IoT devices are not capable of doing complicated encryption and decryption process. In order to overcome this issue,we transfer most of heavy computation to the fog and the cloud in our scheme, while only a small part is reserved for users.(iii)
On the basis of ciphertext-policy attribute-based encryption, we design a fine-grained access control framework. A user should obtain his query capability authorization from a trusted authority and the fog through checking his attributes. The messages are encrypted with an access policy such thatonly users with the designated attributes can access them.(iv)
We provide formal security analysis which demonstrates that our scheme issecure under IND-CK-CCA attack and satisfies trapdoor indistinguishability secure. Also we make experiment comparisons with some previous research revealing that our scheme has a good efficiency.The rest of the paper is organized as follows. In Section2, we briefly introduce preliminaries which will be utilized in our paper. Next, in Section 3, we present two adversary models, security requirements and system functions of our lightweight fine-grained searchable encryption (LFSE) system. Our proposed system is described in Section 4. The thorough security analysis of the proposed system appears in Section 5 and the efficiency is analysed in Section 6. We conclude our paper in Section 8.


## 1.1. Motivation and Contribution

The IoT infrastructure, such as the monitoring devices in a traditional hospital or health management wearable devices in a smart home, continuously synchronizes data to the remote cloud. The massive sensitive data leads to a great challenge to the current healthcare-related IoT-to-cloud system due to the nature of IoT’s limited storage, low power, and poor computability. In this paper, we attempt to solve the problem above as follows:(i)
We propose a fog-supported hybrid infrastructure as shown in Figure1. The distributed fogs are deployed between IoT devices and clouds, providing temporary data storage, data computation and analysis, and network services [16], so as to reduce transmission delay. Also, they help to manage users and attributes under the control of trusted authority.Figure 1
A Fog-based healthcare system.With the proposed infrastructure above, we design a new scheme to implement some specific network functions to meet real world needs. We will show it by exhibiting an example as follows. A person named Wealth rarely cares about his physical condition. One day he knows his friend Bob is suffering from hyperglycemia, and then he wants to learn about it. When he searches “Hyperglycemia" in cloud service providers such as “BodyMedia", “Google Health", “CiscoHealthPresence", or “IBM Bluemix", clouds know that he or someone he knows may get hyperglycemia. Obviously, his personal health privacy is exposed to the clouds. In order to prevent privacy disclosure, we construct indexes for “Hyperglycemia" in the file encryption phase through some secure methods. To search such a keyword, we need to generate the corresponding trapdoors with the help of the fog. Upon receiving the trapdoor, clouds return all the encrypted files associated with the specific “Hyperglycemia" if the trapdoor matches with the index. We can protect Wealth’s searching privacy by this way as follows.Further, we consider Wealth receives all files through searching “Hyperglycemia" by performing our designs. After realizing the importance of keeping healthy, he decides to start his own fitness program to monitor his health indicators such as Glycemic index through wearable sensors. Also, due to the limited storage of his own devices, he has to store his data to the cloud and shares it to some designated ones which have specific attributes. If someone without sufficient attributes attempts to search the keyword, he/she is impossible to generate a valid trapdoor matching with a keyword’s index, not to mention to get Wealth’s sensitive data. We help Wealth to accomplish this goal through the following designs.In summary, Wealth could enjoy an efficient, fast, high-quality, and secure service through adopting our system.The main contributions of this article are exhibited as follows:(i)
We design a keyword searchable encryption scheme in the healthcare related IoT-fog-cloud infrastructure. The proposed scheme ensures a security requirement that both data and keywords are protected from the cloud and the fog, which is very essential to users in the health related environment.(ii)
With the restriction of constrained resource, IoT devices are not capable of doing complicated encryption and decryption process. In order to overcome this issue,we transfer most of heavy computation to the fog and the cloud in our scheme, while only a small part is reserved for users.(iii)
On the basis of ciphertext-policy attribute-based encryption, we design a fine-grained access control framework. A user should obtain his query capability authorization from a trusted authority and the fog through checking his attributes. The messages are encrypted with an access policy such thatonly users with the designated attributes can access them.(iv)
We provide formal security analysis which demonstrates that our scheme issecure under IND-CK-CCA attack and satisfies trapdoor indistinguishability secure. Also we make experiment comparisons with some previous research revealing that our scheme has a good efficiency.The rest of the paper is organized as follows. In Section2, we briefly introduce preliminaries which will be utilized in our paper. Next, in Section 3, we present two adversary models, security requirements and system functions of our lightweight fine-grained searchable encryption (LFSE) system. Our proposed system is described in Section 4. The thorough security analysis of the proposed system appears in Section 5 and the efficiency is analysed in Section 6. We conclude our paper in Section 8.


## 2. Preliminaries

In this section we provide a detailed description of some fundamentals of cryptography that will be used throughout this paper.


### 2.1. The Notations

In this section, we first give notation descriptions that will be used throughout this paper. For a prime numberp, we denote the set {1,2,…,p-1} as Zp∗, where multiplication and addition modulo p are defined in the set. We use a←rS to denote that a is uniformly chosen from all elements in S randomly. And let λ be the security parameter of our system.


### 2.2. Bilinear Map

G 1 and G2 are two multiplicative cyclic groups of prime order p. Let g be a generator of G1 and e be a bilinear map, e:G1×G1→G2. The bilinear map e has the following properties:(i)
Bilinear: A mape:G1×G1→G2 is bilinear if e(aP,bQ)=e(P,Q)ab for all P,Q∈G1 and all a,b∈Zp∗.(ii)
Nondegenerate:e(g,g)≠1.(iii)
Computable: There is an efficient algorithm to computee(P,Q) for all P,Q∈G1.


### 2.3. Access Policy

An access policy defines attribute sets that are acquired to get access to private messages.Definition 1 (monotonicity).
LettingAT be attributes universe, then an access policy A⊆2AT means A is a collection of non-empty subsets of AT. We call the access policy A is monotone if ∀Ω1,Ω2⊆AT s.t. (1)Ω1⊆Ω2,Ω1∈A⇒Ω2∈A.According to the monotonicity, an authorized user cannot lose his privileges if he has more attributes than required.


## 2.1. The Notations

In this section, we first give notation descriptions that will be used throughout this paper. For a prime numberp, we denote the set {1,2,…,p-1} as Zp∗, where multiplication and addition modulo p are defined in the set. We use a←rS to denote that a is uniformly chosen from all elements in S randomly. And let λ be the security parameter of our system.


## 2.2. Bilinear Map

G 1 and G2 are two multiplicative cyclic groups of prime order p. Let g be a generator of G1 and e be a bilinear map, e:G1×G1→G2. The bilinear map e has the following properties:(i)
Bilinear: A mape:G1×G1→G2 is bilinear if e(aP,bQ)=e(P,Q)ab for all P,Q∈G1 and all a,b∈Zp∗.(ii)
Nondegenerate:e(g,g)≠1.(iii)
Computable: There is an efficient algorithm to computee(P,Q) for all P,Q∈G1.


## 2.3. Access Policy

An access policy defines attribute sets that are acquired to get access to private messages.Definition 1 (monotonicity).
LettingAT be attributes universe, then an access policy A⊆2AT means A is a collection of non-empty subsets of AT. We call the access policy A is monotone if ∀Ω1,Ω2⊆AT s.t. (1)Ω1⊆Ω2,Ω1∈A⇒Ω2∈A.According to the monotonicity, an authorized user cannot lose his privileges if he has more attributes than required.


## 3. System Model

### 3.1. Architecture of System

The architecture of the proposed fog-based healthcare system is shown in Figure2. It is composed of four parts, i.e., a trusted authority, cloud server providers, fog nodes, and data users (including date owners and other users).Figure 2
System model.Trusted Authority (TA). A trusted authority, such as the national health center or an entity authorized by it, is an important authority for verifying users attributes. It takes charge of generating system parameters for all entities. And it is responsible for issue, revoke, and update attribute private keys for users.Cloud (Short for Cloud Server Providers). The cloud such as Amazon provides data storage, computational resource services, and data analysis. Apart from providing content service above, it also takes charge of the access services from the outside users to the encrypted files. We assume that the public cloud executes the searchable algorithm honestly. The cloud in our system is responsible for performing test algorithm and accomplish a part of decryption task with knowing any information about the user’s keys or attributes.Fog (Short for Fog Nodes). Fog, providing abilities of computing, storage, and mobility, is deployed at edges of networks. Because of the limited computing resources and the restricted capacity of the data owner or user’s facility carried nearby, it is responsible for deploying a half-trusted fog as interface between a user and the cloud server, especially in situations with sensitive medical information. Fog in our system takes charge of managing users within its coverage, revoking users and attributes without having any information about their private keys. Further, it helps controlling users’ query action through generating one part of the trapdoor without knowing the queried keyword.Data Owner. The data owner is an entity who intends to share his files with designated receivers. The receivers’ attributes should satisfy the access policy embedded in the corresponding ciphertext. It is in charge of file encryption with a specific access policy, index generation for all the keywords, and uploading to the cloud.Data User. The data user is the entity who intends to get the encrypted files by sending a query request to cloud servers and the fog. If he has enough attributes satisfying with the required access policy, he is able to download ciphertexts and decrypt them with the help from the cloud. It takes charge of keyword selection to generate trapdoors and then ciphertext decryption.Assumptions. We assume that the cloud and the fog are always online. They have sufficient storage capacity and computing resource. Also we assume that there exists a secure channel between data owner/user and the fog node, e.g., secure Wi-Fi networks.We assume that the cloud and fogs are all “honest but curious" [21]. To be specific, they do not delete or modify user’s data and return the computing results honestly but attempt to access as much private information as possible. All the entities execute our proposed protocol and users try to access data either within or out of their privileges. And it is assumed that the cloud and the fog do not collude with each other.Different from most existing work with only public cloud, it is a novel cloud-fog architecture. In this work, we assume that files and keywords are sensitive and should be protected from both the cloud and the fog. And attributes are semisensitive, which means attributes can only be known by the fog.


### 3.2. Definition of Basic Algorithms

We describe a general definition for our lightweight fine-grained searchable encryption scheme, consisting of several polynomial time algorithms.Setup. This phase containing three subalgorithms is implemented by TA.S y s t e m . S e t u p  ( 1 λ ): Input the security parameter λ; then the algorithm outputs the master key Mk, public key Pk, and other system parameters.F o g . S e t u p  ( P k ): Input the system parameter Pk; then the algorithm outputs the fog’s public and private key pair (PkFk,SkFk) and the corresponding verification key vkj for each attribute in the attribute universe.U s e r . S e t u p  ( P k ): For each user requesting to join the system, TA verifies the user identity and his attributes.KeyGeneration. This phase is executed by TA, which contains two subalgorithms.K e y G e n  ( P k , M k , U s e r i , Ω u i ): Input the system’s keys (Pk,Sk), the user identity, and the user’s attributes; then the algorithm outputs the user’s public and private key (Pkui,Skui). Next, Input the output of private key and user’s attributes Ωui; the algorithm outputs the secret verification key svkj for each attribute attrj∈Ωui,.S e a r c h K e y G e n  ( M k , U s e r i ): Input the system’s master key Mk and user’s identity Useri; then the algorithm returns the search key Si for the user.FogSupport. This phase is executed by the fog and users which is under the management of the fog. Three algorithms are included in this phase.A d d u s e r  ( U s e r i ): Input the public parameter and the user’s identity Useri; then the algorithm outputs a table Tuser for the fog Fk to store users’ information.R e K e y G e n  ( S k u i , s v k j ): Input the user’s private key Skui and the private verification key svkj for atj∈Ωui, then the algorithm outputs a secret key cskui.R e E n c  ( P k u i , v k j ): Input the user’s public key Pkui and the verification key vkj for atj∈Ωui, then the algorithm outputs a ciphertext cvkui.FileEncryption. This phase is performed by the user.E n c  ( F , A , v k j ): Input a file F, an access policy A and the verification key vkj; then the algorithm outputs the ciphertext C embedded with the access policy.IndexGeneration. This phase is implemented by the user through running the algorithm Index.I n d e x  ( W , S i , P k u i ): Input the user’s search key Si and the keyword W; then the algorithm outputs an index IW for the keyword.TrapdoorGeneration. This phase is executed by the fog and the user, including two subalgorithms.T r a p d o o r  ( P k F k , c s k u i ): It is performed by the fog. Input the fog’s public key PkFk and the user’s regenerated key cskui as input; then the algorithm outputs Tf that is a part of the trapdoor T.T r a p d o o r 2  ( W , S i ): This algorithm is executed by the user. Input the user’s search key Si and a keyword W, then the algorithm outputs TW that is the other part of the trapdoor T.Test. This phase is implemented by the cloud server through running Test.T e s t  ( I W , T ): Input the keyword index IW and the trapdoor T; then the algorithm outputs 0 if they do not match; otherwise it outputs 1.FileDecryption. The decryption phase is implemented by the cloud server and the user, consisting two subalgorithms.D e c  ( C , c v k u i ): Input the file’s ciphertext C, the trapdoor T, and the ciphertext of user’s attributes ciphertext cvkui; then the algorithm outputs Cpd that is a part-decrypted version of the ciphertext.D e c 2  ( C p d , S k u i ): Input the user’s private key Skui and the part-decrypted ciphertext Cpd, then the algorithm outputs the file F.


### 3.3. Security Requirements

(1)
Data confidentiality: The cloud and the fog are not allowed to know the encrypted data files. Unauthorized users who have no appropriate attributes matching the policy embedded in the ciphertext should not learn the content of the underlying plaintext. (2)
Keyword privacy: The keywords should be protected from both the cloud and the fog in a secure way, such as by using a oneway hash function. The cloud server is able to perform the test operation over the indexes but leaks no information about keywords to any unauthorized attackers. (3)
Trapdoor privacy: One part of the trapdoor is generated by the data user by using the search key and the secret verification key for his attributes together with the keyword. The other part is generated with the help of the fog using the user’s re-encrypted key. The trapdoor reveals no information about the corresponding keyword or the user’s attributes to the attacker.


### 3.4. Adversary Model

To achieve the security requirements, we design two security models for our scheme. Firstly, we introduce a fundamental assumption in Definition2.Definition 2 (DBDH assumption).
We say that the DBDH assumption holds if no polynomial time algorithm has a nonnegligible advantage in solving the DBDH problem.According to the security parameter, let a groupG1 of prime order p have a generator g. a,b,c←RZp∗ are chosen randomly. The DBDH problem states that the adversary should distinguish e(g,g)abc∈G2 from a random element V∈G2 when given g,ga,gb,gc∈G1.Definition 3.
Our LFSE scheme is trapdoor indistinguishable secure if there is no polynomial time attack can have a nonnegligible advantage in the following game.The security model is defined asGame 1 played between an adversary A and an algorithm B.Game 1 (Trapdoor privacy). Setup: With a security parameter λ, the algorithm B outputs system parameters and generates the public key Pkui, the private key Skui, and the search key Si for the data user.Query phase 1: The adversaryA adaptively makes the following queries.O.Trapdoor1: The adversary A could query any keyword’s one part (Tf0,Tf1,Tf2) of the trapdoor.O.Trapdoor2: The adversary A could query the keyword’s another part (TW1,TW2) of the trapdoor.Challenge phase: The adversaryA sends two keywords W1∗ and W0∗ with equal length. Then B will randomly select x∈{0,1} and construct the trapdoor Tf{Wx∗} for the keyword Wx∗ and send it to the adversary A.Query phase 2: The adversaryA queries the same as phase 1 with the restriction the queried keyword W∉{W0∗,W1∗}.Guess: The adversaryA outputs a guess x′∈{0,1}. If x=x′, A wins the game and the algorithm B outputs 1; otherwise A fails and B outputs 0.Definition 4.
Our LFSE scheme is IND-CKCCA secure if there is no polynomial time attack can have a nonnegligible advantage in the following game.We define the indistinguishable against chosen keyword chosen ciphertext attack in our system. The security model is defined throughGame 2 played between an adversary A and a challenger C as follows.Game 2 (Ciphertext and Keyword privacy).This Initial Phase. The adversary A commits to challenge C.Setup: The challengerC seclets a large security parameter λ and runs the setup algorithm to obtain the system master key and public key (Mk,Pk). C gives Pk to A and keeps Mk.Phase 1: The adversaryA makes the following queries with a polynomial number bound.(i)
O.KeyGen: The oracle contains several key generation oracles executed by the challenger C to generate a series of keys for A.(ii)
O.Trapdoor: The oracle contains two trapdoor generation oracles executed by the challenger C to generate the trapdoor T=(Tf,TW) for A, with the keys generated from the above steps.Challenge: After finishing phase 1, the adversaryA outputs two messages m0∗,m1∗ and two keywords W0∗,W1∗ both with equal length to be challenged. The challenger C flips a coin to choose b1,b2∈{0,1} and then constructs ciphertext for mb1∗ and index for Wb2∗. Finally, the challenger C sends them to the adversary A.Phase 2: The adversaryA adaptively makes queries the same as phase 1, expect the restrictions that W∉{W0∗,W1∗} and the user’s private key cannot be queried.Guess: The adversaryA outputs guesses b1′,b2′∈0,1. If b1′=b1 and b2′=b2, A wins the game.The adversaryA has an advantage of ϵAdvALFSE(λ)=|Pr[b1′=b1,b2′=b2]-1/2| in breaking the DBDH assumption.


### 3.5. System Functions

Considering the performance-related issues, our scheme are designed to achieve the following functions.(1)
Fine-grained access control: A data owner embeds an access policy into each file to be transmitted to the cloud. This guarantees that the data is only accessed by users with appropriate attributes and well prevented from the cloud server.(2)
Authorization: Each data user who is authorized by the trusted attribute authority can be assigned his individual private key. These private keys can be used to search and decrypt files in our system.(3)
Search on keywords: An authorized user can generate a query request for some keywords by using his individual private key. After the cloud server receives the query and performs the “Test” on the encrypted files, the user can obtain the matched files.(4)
Revocability: The trusted authority should be able to revoke an user and attributes. If an authorized user is revoked, the user is no longer able to search and read files in our system. If an attribute of the user is revoked, the user is no longer able to access the files embedded with an access policy containing the attribute.


## 3.1. Architecture of System

The architecture of the proposed fog-based healthcare system is shown in Figure2. It is composed of four parts, i.e., a trusted authority, cloud server providers, fog nodes, and data users (including date owners and other users).Figure 2
System model.Trusted Authority (TA). A trusted authority, such as the national health center or an entity authorized by it, is an important authority for verifying users attributes. It takes charge of generating system parameters for all entities. And it is responsible for issue, revoke, and update attribute private keys for users.Cloud (Short for Cloud Server Providers). The cloud such as Amazon provides data storage, computational resource services, and data analysis. Apart from providing content service above, it also takes charge of the access services from the outside users to the encrypted files. We assume that the public cloud executes the searchable algorithm honestly. The cloud in our system is responsible for performing test algorithm and accomplish a part of decryption task with knowing any information about the user’s keys or attributes.Fog (Short for Fog Nodes). Fog, providing abilities of computing, storage, and mobility, is deployed at edges of networks. Because of the limited computing resources and the restricted capacity of the data owner or user’s facility carried nearby, it is responsible for deploying a half-trusted fog as interface between a user and the cloud server, especially in situations with sensitive medical information. Fog in our system takes charge of managing users within its coverage, revoking users and attributes without having any information about their private keys. Further, it helps controlling users’ query action through generating one part of the trapdoor without knowing the queried keyword.Data Owner. The data owner is an entity who intends to share his files with designated receivers. The receivers’ attributes should satisfy the access policy embedded in the corresponding ciphertext. It is in charge of file encryption with a specific access policy, index generation for all the keywords, and uploading to the cloud.Data User. The data user is the entity who intends to get the encrypted files by sending a query request to cloud servers and the fog. If he has enough attributes satisfying with the required access policy, he is able to download ciphertexts and decrypt them with the help from the cloud. It takes charge of keyword selection to generate trapdoors and then ciphertext decryption.Assumptions. We assume that the cloud and the fog are always online. They have sufficient storage capacity and computing resource. Also we assume that there exists a secure channel between data owner/user and the fog node, e.g., secure Wi-Fi networks.We assume that the cloud and fogs are all “honest but curious" [21]. To be specific, they do not delete or modify user’s data and return the computing results honestly but attempt to access as much private information as possible. All the entities execute our proposed protocol and users try to access data either within or out of their privileges. And it is assumed that the cloud and the fog do not collude with each other.Different from most existing work with only public cloud, it is a novel cloud-fog architecture. In this work, we assume that files and keywords are sensitive and should be protected from both the cloud and the fog. And attributes are semisensitive, which means attributes can only be known by the fog.


## 3.2. Definition of Basic Algorithms

We describe a general definition for our lightweight fine-grained searchable encryption scheme, consisting of several polynomial time algorithms.Setup. This phase containing three subalgorithms is implemented by TA.S y s t e m . S e t u p  ( 1 λ ): Input the security parameter λ; then the algorithm outputs the master key Mk, public key Pk, and other system parameters.F o g . S e t u p  ( P k ): Input the system parameter Pk; then the algorithm outputs the fog’s public and private key pair (PkFk,SkFk) and the corresponding verification key vkj for each attribute in the attribute universe.U s e r . S e t u p  ( P k ): For each user requesting to join the system, TA verifies the user identity and his attributes.KeyGeneration. This phase is executed by TA, which contains two subalgorithms.K e y G e n  ( P k , M k , U s e r i , Ω u i ): Input the system’s keys (Pk,Sk), the user identity, and the user’s attributes; then the algorithm outputs the user’s public and private key (Pkui,Skui). Next, Input the output of private key and user’s attributes Ωui; the algorithm outputs the secret verification key svkj for each attribute attrj∈Ωui,.S e a r c h K e y G e n  ( M k , U s e r i ): Input the system’s master key Mk and user’s identity Useri; then the algorithm returns the search key Si for the user.FogSupport. This phase is executed by the fog and users which is under the management of the fog. Three algorithms are included in this phase.A d d u s e r  ( U s e r i ): Input the public parameter and the user’s identity Useri; then the algorithm outputs a table Tuser for the fog Fk to store users’ information.R e K e y G e n  ( S k u i , s v k j ): Input the user’s private key Skui and the private verification key svkj for atj∈Ωui, then the algorithm outputs a secret key cskui.R e E n c  ( P k u i , v k j ): Input the user’s public key Pkui and the verification key vkj for atj∈Ωui, then the algorithm outputs a ciphertext cvkui.FileEncryption. This phase is performed by the user.E n c  ( F , A , v k j ): Input a file F, an access policy A and the verification key vkj; then the algorithm outputs the ciphertext C embedded with the access policy.IndexGeneration. This phase is implemented by the user through running the algorithm Index.I n d e x  ( W , S i , P k u i ): Input the user’s search key Si and the keyword W; then the algorithm outputs an index IW for the keyword.TrapdoorGeneration. This phase is executed by the fog and the user, including two subalgorithms.T r a p d o o r  ( P k F k , c s k u i ): It is performed by the fog. Input the fog’s public key PkFk and the user’s regenerated key cskui as input; then the algorithm outputs Tf that is a part of the trapdoor T.T r a p d o o r 2  ( W , S i ): This algorithm is executed by the user. Input the user’s search key Si and a keyword W, then the algorithm outputs TW that is the other part of the trapdoor T.Test. This phase is implemented by the cloud server through running Test.T e s t  ( I W , T ): Input the keyword index IW and the trapdoor T; then the algorithm outputs 0 if they do not match; otherwise it outputs 1.FileDecryption. The decryption phase is implemented by the cloud server and the user, consisting two subalgorithms.D e c  ( C , c v k u i ): Input the file’s ciphertext C, the trapdoor T, and the ciphertext of user’s attributes ciphertext cvkui; then the algorithm outputs Cpd that is a part-decrypted version of the ciphertext.D e c 2  ( C p d , S k u i ): Input the user’s private key Skui and the part-decrypted ciphertext Cpd, then the algorithm outputs the file F.


## 3.3. Security Requirements

(1)
Data confidentiality: The cloud and the fog are not allowed to know the encrypted data files. Unauthorized users who have no appropriate attributes matching the policy embedded in the ciphertext should not learn the content of the underlying plaintext. (2)
Keyword privacy: The keywords should be protected from both the cloud and the fog in a secure way, such as by using a oneway hash function. The cloud server is able to perform the test operation over the indexes but leaks no information about keywords to any unauthorized attackers. (3)
Trapdoor privacy: One part of the trapdoor is generated by the data user by using the search key and the secret verification key for his attributes together with the keyword. The other part is generated with the help of the fog using the user’s re-encrypted key. The trapdoor reveals no information about the corresponding keyword or the user’s attributes to the attacker.


## 3.4. Adversary Model

To achieve the security requirements, we design two security models for our scheme. Firstly, we introduce a fundamental assumption in Definition2.Definition 2 (DBDH assumption).
We say that the DBDH assumption holds if no polynomial time algorithm has a nonnegligible advantage in solving the DBDH problem.According to the security parameter, let a groupG1 of prime order p have a generator g. a,b,c←RZp∗ are chosen randomly. The DBDH problem states that the adversary should distinguish e(g,g)abc∈G2 from a random element V∈G2 when given g,ga,gb,gc∈G1.Definition 3.
Our LFSE scheme is trapdoor indistinguishable secure if there is no polynomial time attack can have a nonnegligible advantage in the following game.The security model is defined asGame 1 played between an adversary A and an algorithm B.Game 1 (Trapdoor privacy). Setup: With a security parameter λ, the algorithm B outputs system parameters and generates the public key Pkui, the private key Skui, and the search key Si for the data user.Query phase 1: The adversaryA adaptively makes the following queries.O.Trapdoor1: The adversary A could query any keyword’s one part (Tf0,Tf1,Tf2) of the trapdoor.O.Trapdoor2: The adversary A could query the keyword’s another part (TW1,TW2) of the trapdoor.Challenge phase: The adversaryA sends two keywords W1∗ and W0∗ with equal length. Then B will randomly select x∈{0,1} and construct the trapdoor Tf{Wx∗} for the keyword Wx∗ and send it to the adversary A.Query phase 2: The adversaryA queries the same as phase 1 with the restriction the queried keyword W∉{W0∗,W1∗}.Guess: The adversaryA outputs a guess x′∈{0,1}. If x=x′, A wins the game and the algorithm B outputs 1; otherwise A fails and B outputs 0.Definition 4.
Our LFSE scheme is IND-CKCCA secure if there is no polynomial time attack can have a nonnegligible advantage in the following game.We define the indistinguishable against chosen keyword chosen ciphertext attack in our system. The security model is defined throughGame 2 played between an adversary A and a challenger C as follows.Game 2 (Ciphertext and Keyword privacy).This Initial Phase. The adversary A commits to challenge C.Setup: The challengerC seclets a large security parameter λ and runs the setup algorithm to obtain the system master key and public key (Mk,Pk). C gives Pk to A and keeps Mk.Phase 1: The adversaryA makes the following queries with a polynomial number bound.(i)
O.KeyGen: The oracle contains several key generation oracles executed by the challenger C to generate a series of keys for A.(ii)
O.Trapdoor: The oracle contains two trapdoor generation oracles executed by the challenger C to generate the trapdoor T=(Tf,TW) for A, with the keys generated from the above steps.Challenge: After finishing phase 1, the adversaryA outputs two messages m0∗,m1∗ and two keywords W0∗,W1∗ both with equal length to be challenged. The challenger C flips a coin to choose b1,b2∈{0,1} and then constructs ciphertext for mb1∗ and index for Wb2∗. Finally, the challenger C sends them to the adversary A.Phase 2: The adversaryA adaptively makes queries the same as phase 1, expect the restrictions that W∉{W0∗,W1∗} and the user’s private key cannot be queried.Guess: The adversaryA outputs guesses b1′,b2′∈0,1. If b1′=b1 and b2′=b2, A wins the game.The adversaryA has an advantage of ϵAdvALFSE(λ)=|Pr[b1′=b1,b2′=b2]-1/2| in breaking the DBDH assumption.


## 3.5. System Functions

Considering the performance-related issues, our scheme are designed to achieve the following functions.(1)
Fine-grained access control: A data owner embeds an access policy into each file to be transmitted to the cloud. This guarantees that the data is only accessed by users with appropriate attributes and well prevented from the cloud server.(2)
Authorization: Each data user who is authorized by the trusted attribute authority can be assigned his individual private key. These private keys can be used to search and decrypt files in our system.(3)
Search on keywords: An authorized user can generate a query request for some keywords by using his individual private key. After the cloud server receives the query and performs the “Test” on the encrypted files, the user can obtain the matched files.(4)
Revocability: The trusted authority should be able to revoke an user and attributes. If an authorized user is revoked, the user is no longer able to search and read files in our system. If an attribute of the user is revoked, the user is no longer able to access the files embedded with an access policy containing the attribute.


## 4. LFSE Scheme

### 4.1. Construction of LFSE Scheme

We specify the proposed LFSE scheme in fog-based healthcare system in details. In real world, we consider that all the sensors carried by the owner are continually collecting and reporting data, and the owner decides whether and when data is transmitted to the cloud.(1)
System setup: Letλ be the security parameter, and then TA performs the following steps. Firstly, it chooses two cyclic groups (G,·) and (GT,·) with prime order p and defines a bilinear pairing e:G×G→GT. Let g be a generator of G, g1,g2 and s,υ are randomly chosen from G and Zp∗, respectively. Then, it computes g′=gs, V=e(g,g)υ, and selects two hash functions: H:{0,1}∗→Zp∗, H1:Zp∗×{0,1}∗→Zp∗. Ultimately, TA keeps (s,υ) secret as master key Sk and publishes system parameters Pk={λ,G,GT,e,g,g1,g2,g′,V}. Afterwards, TA will initialize the attribute universe AT={at1,at2,…,atm} and the monotone access structure A. Let A0=(Ω1,Ω2,…,Ωn) be a basis for A, where each Ωi is a minimal authorized attribute set in A.(2)
Setup and key generation for fogs: For each fog, TA generates its public and private keys(PkFogk,SkFogk) by running Fog.Setup. The algorithm picks ςk←rZp∗ randomly and outputs (PkFogk, SkFogk)=(ςk,gςk). The fog maintains the private key sent from TA and initializes a table Tuser to manage all the authorized users within its coverage. Further, to authorize fogs to manage attributes, for each fog Fogk, TA selects a σk←rZp∗ and then computes θj=H1(σk,atj), d1j=gθj, and d2j=Vθj for each attribute atj∈AT and defines vkj=(d1j,d2j) as a verification key. Then TA sends verification keys {vkj}atj∈AT to the corresponding fogs as attributes information. The fogs exchange their users and attributes verification keys information to allow the authorized user to connect to our system when he moves to other fog’s managing area.(3)
Key Generation for the user: Assume that a new userUseri with the attribute list Ωui={{atj},j≤m} requests to join the system. First of all, TA authenticates the user’s identity and his attributes. Then it returns the public and private key (PkUseri,SkUseri)=(gαi,(t0,t1,t2)) to each user, where t0=gυg1αi, t1=gβi, t2=δ, and αi,βi,δ←rZp∗. Simultaneously, TA computes svkj=(PkUseri)θj=gαiθj for each atj∈Ωui and returns it to the user as a secret verification key for each attribute obtained by the user. Once the phase is finished, the fog adds Useri to table Tuser as a new authenticated user’s information.(4)
Search Key Generation: After receiving the public and private keys from TA, the userUseri also needs to make a request to get a private key for searching on keywords. The user picks η←rZp∗ randomly and sends g11/η to TA. Then, TA computes the searching key Si=(g11/η)sg2βiδ and sends Si to the user.(5)
Prepare For Fog Support: Due to the limited processing power and low computing efficiency of the user, we would like to transfer most of the computational load to the fog and cloud without leaking additional information. In our system, the user would delegate the fog to complete a part of auxiliary computation by transferring a converted secret keycskui. The user computes T0=t0t2=gυδg1αiδ, T1=t1t2=gβiδ, and T2j=(svkj)t2=gαiθjδ and then sends cskui=(T0,T1,{T2j}atj∈Ωui)to the fog. With cskui, the fog can help users accomplish a part of computation tasks without knowing the user private key. For facilitating further calculations, the user can compute V1=e(g,g) and V2=e(g1,g′) in advance and stores them. Simultaneously, to ensure the cloud can help users do a part of computation and avoid the cloud from obtaining information from the user’s attributes, the fog selects s′←rZp∗ randomly and computes D1=g1s′, D2j=(d1j)s′=(gθj)s′=gθjs′ and sends cvkui=(D1,{D2j}atj∈Ωui) to the cloud and the secret s′ to the user through a secure channel.(6)
Encrypt: Suppose that the data owner decides his fileF. This file can be searched and acquired by users whose attributes satisfy with an access policy A. Under this assumption, the user can designate different types of data to be accessed by different kind of people. For the monotone access policy A, there exists a basis A0=(Ω1,Ω2,…,Ωn), where each Ωi, a minimal set, is composed of the authorized attributes. To encrypt the file, the user picks sl←rZp∗ for each 1≤l≤n computes(2)Cl=C1l,C2l=F·∏atj∈Ωld2jsl,sls′,The user keeps the ciphertext as C=(A,{Cl}1≤l≤n) embedded with the access policy A.(7)
Index: For a continuous health monitoring system, data are constantly processed and transferred to the cloud from various kind of sensors. In order to get quick access to useful files from the super large data center, we add different keywords to files.We assume the fileF contains a set of keywords W which are extracted from the original health file. For each keyword W∈W, the user picks u←rZp∗ randomly and computes IW=(CW1,CW2,CW3)=((e(g,g)H(W)e(g1,g′))u,gu,g2u). Subsequently, the user sends the ciphertext C together with the index IW to the cloud. Then the cloud stores them.(8)
Trapdoor: Generally speaking, theTrapdoor algorithm is used to generate a trapdoor for a certain keyword by the user who wants to search files containing this keyword. In our system, to help the user reduce the computing burden, we delegate the fog to do a part of the trapdoor generation work without leaking any information about the queried keywords. This design has an advantage in our IoT system: confidentiality of keywords. Specifically, upon receiving the query request from the user Useri, the fog firstly searches the user’s identity in table Tuser. If the fog does not find it in the table which means the user did not join the system, then the fog refuses to generate the part trapdoor for the user and returns a warning message. This process completed by the fog ensures that any external user who is not authenticated cannot search any keyword and guarantees no leakage of any information about keywords or encrypted files. If the fog finds the user in table Tuser, the fog randomly chooses ρ←rZp∗, sends it to the user through a secure channel, and then computes(3)Tf0=T0ρ=t0t2ρ=gυδρg1αiδρ,Tf1=T1ρ=t1t2ρ=gβiδρ,Tf2j=T2jρ=svkjt2ρ=gαiθjδρ.After finishing all the above steps, the fog uploads Tf=(Tf0,Tf1,Tf2j{atj∈Ωui}) to the cloud as a part of the trapdoor. To search files with a keyword W′, the user firstly chooses η←rZp∗ and computes(4)TW1=gHW′Siη=gHW′g1sg2βiδη,TW2=ηρwith his own search key. Then, the user sends the other part of the trapdoor TW=(TW1,TW2) to the cloud. Ultimately, the cloud gets a full trapdoor T=(Tf,TW). In this phase, if the fog has verified one user’s identity and verification keys for his attributes, the fog can perform the trapdoor generation once in a while. This is available as this phase is not related to the queried keyword. As a result, the computing burden for the fog and interaction time for both the user and the fog can be reduced.(9)
Test: Upon receiving the search request for keywordW′ from the fog and the user, the cloud runs Test algorithm for all items which are encrypted indexes for all the keywords by computing(5)eCW2,TW1eCW3,Tf1TW2.The cloud compares the result with CW1, if it equals CW1, the cloud outputs 1, and performs the next step. Otherwise, the cloud outputs 0, returns a warning message, and exits the system.(10)
Decryption: If the algorithmTest cannot find an index for the uploaded trapdoor, the cloud would not run the Dec1 algorithm and returns ⊥. Otherwise, the cloud computes(6)Cpd=eD1,∏atj′∈Ωui′Tf2je∏atj′∈Ωui′D2j,Tf0C2lTW2.Once upon receiving the part-decrypted ciphertext Cpd from the cloud, the user recovers the file F by using his own private key through computing(7)F=C1lCpd1/δt2.Obviously, the user only needs to do an exponential operation in the decryption, which is a great step in improving efficiency.


### 4.2. Consistency

Firstly, we present that the trapdoor matching is valid in our system.(8)eCW2,TW1eCW3,Tf1TW2=egu,gHW′g11/ηsg2βiδηeg2u,gβiδρη/ρ=egu,gHW′·egu,g1s·egu,g2βiδηeg2u,gβiδη=eg,guHW′·eg,g1us·eg,g2uβiδηeg2,guβiδη=eg,guHW′·eg,g1us=eg,guHW′·eg1,g′u. If there exists a keyword W∈W matching with the queried keyword which leads H(W)=H(W′), we can derive the conclusion e(CW2,TW1)/e(CW3,Tf1TW2)=CW1.Then, the file recovery can be maintained as the following two steps. If the test passes, the cloud decrypts all the related files by computing(9)Cpd=eD1,∏atj′∈Ωui′Tf2je∏atj′∈Ωui′D2j,Tf0C2lTW2=eg1s′,∏atj′∈Ωui′gαiθjδρe∏atj′∈Ωui′gθjs′,gυg1αiδρsl/s′η/ρ=eg1s′,gαiδρ∑atj′∈Ωui′egs′∑atj′∈Ωui′θj,gυδρ·egs′∑atj′∈Ωui′θj,g1αiδρsl/s′η/ρ=eg1,gs′αiδρ∑atj′∈Ωui′eg,gs′υδρ∑atj′∈Ωui′θj·eg,g1s′αiδρ∑atj′∈Ωui′θjsl/s′η/ρ=1eg,gυδ∑atj′∈Ωui′θjslη=1eg,gυδslη∑atj′∈Ωui′θj.If the user’s attributesΩui′ satisfy the access policy A, we know there exists a basis A0′=(Ω1′,Ω2′,…,Ωn′) s.t.(10)∀atj∈Ωui′,∃Ωl′s.t.atj∈Ωl′⊆Ωui′, and we have ∑atj′∈Ωui′θj=∑atj′∈Ωl′θj=∑1nθj=∑atj′∈Ωlθj.According to this, the user finally recovers the file by computing(11)F=C1lCpd1/δt2=F·∏atj∈Ωld2jsl1eg,gυδslη∑atj′∈Ωui′θj1/δη=F·eg,gυsl∑atj∈Ωuiθj·1eg,gυsl∑atj′∈Ωui′θj=F.


### 4.3. User Revocation and Attribute Revocation

As mentioned above, the fog is an access interface between the cloud and users. The tableTuser is a certification to verify whether a user is in the system. The revocation of a user can be realized through rejecting the query request. To be specific, once a user submits a revocation request to the trusted authority or the trusted authority decides to revoke a user, the trusted authority deletes all keys and attributes information of the user. Then it sends the user’s revocation information to the fog, and all the information about the user will be deleted in Tuser. As a result, the user cannot update his/her request to the cloud server. Furthermore, once the re-encrypted keys cskui and cvkui are revoked from the fog, the user cannot generate trapdoors for any keywords. Because the fog needs cskui and cvkui to do a part of computation to accomplish the trapdoor generation phase, the loss of cskui and cvkui leads to the user’s failure to search for any files. As a result, such a user is new to the system and the fog will no longer respond to its any request.In our system, we can achieve attribute revocation with the designation ofcskui and cvkui. Once an attribute is revoked, the data owner could keep the data from the group of users who have the revoked attribute. To be specific, upon deciding to revoke an attribute atj, the fog destroys the attribute’s verification key vkj and deletes cskui and cvkui for users containing the attribute, then sends a warning message to these users to update the related cskui and cvkui. Before users updating cskui and cvkui, the fog refuses to generate trapdoor for them, which directly leading to the failure of accessing files in the system. Although it may cause some computational loads and transmission cost, it is acceptable when the extremely sensitive data is concerned.


## 4.1. Construction of LFSE Scheme

We specify the proposed LFSE scheme in fog-based healthcare system in details. In real world, we consider that all the sensors carried by the owner are continually collecting and reporting data, and the owner decides whether and when data is transmitted to the cloud.(1)
System setup: Letλ be the security parameter, and then TA performs the following steps. Firstly, it chooses two cyclic groups (G,·) and (GT,·) with prime order p and defines a bilinear pairing e:G×G→GT. Let g be a generator of G, g1,g2 and s,υ are randomly chosen from G and Zp∗, respectively. Then, it computes g′=gs, V=e(g,g)υ, and selects two hash functions: H:{0,1}∗→Zp∗, H1:Zp∗×{0,1}∗→Zp∗. Ultimately, TA keeps (s,υ) secret as master key Sk and publishes system parameters Pk={λ,G,GT,e,g,g1,g2,g′,V}. Afterwards, TA will initialize the attribute universe AT={at1,at2,…,atm} and the monotone access structure A. Let A0=(Ω1,Ω2,…,Ωn) be a basis for A, where each Ωi is a minimal authorized attribute set in A.(2)
Setup and key generation for fogs: For each fog, TA generates its public and private keys(PkFogk,SkFogk) by running Fog.Setup. The algorithm picks ςk←rZp∗ randomly and outputs (PkFogk, SkFogk)=(ςk,gςk). The fog maintains the private key sent from TA and initializes a table Tuser to manage all the authorized users within its coverage. Further, to authorize fogs to manage attributes, for each fog Fogk, TA selects a σk←rZp∗ and then computes θj=H1(σk,atj), d1j=gθj, and d2j=Vθj for each attribute atj∈AT and defines vkj=(d1j,d2j) as a verification key. Then TA sends verification keys {vkj}atj∈AT to the corresponding fogs as attributes information. The fogs exchange their users and attributes verification keys information to allow the authorized user to connect to our system when he moves to other fog’s managing area.(3)
Key Generation for the user: Assume that a new userUseri with the attribute list Ωui={{atj},j≤m} requests to join the system. First of all, TA authenticates the user’s identity and his attributes. Then it returns the public and private key (PkUseri,SkUseri)=(gαi,(t0,t1,t2)) to each user, where t0=gυg1αi, t1=gβi, t2=δ, and αi,βi,δ←rZp∗. Simultaneously, TA computes svkj=(PkUseri)θj=gαiθj for each atj∈Ωui and returns it to the user as a secret verification key for each attribute obtained by the user. Once the phase is finished, the fog adds Useri to table Tuser as a new authenticated user’s information.(4)
Search Key Generation: After receiving the public and private keys from TA, the userUseri also needs to make a request to get a private key for searching on keywords. The user picks η←rZp∗ randomly and sends g11/η to TA. Then, TA computes the searching key Si=(g11/η)sg2βiδ and sends Si to the user.(5)
Prepare For Fog Support: Due to the limited processing power and low computing efficiency of the user, we would like to transfer most of the computational load to the fog and cloud without leaking additional information. In our system, the user would delegate the fog to complete a part of auxiliary computation by transferring a converted secret keycskui. The user computes T0=t0t2=gυδg1αiδ, T1=t1t2=gβiδ, and T2j=(svkj)t2=gαiθjδ and then sends cskui=(T0,T1,{T2j}atj∈Ωui)to the fog. With cskui, the fog can help users accomplish a part of computation tasks without knowing the user private key. For facilitating further calculations, the user can compute V1=e(g,g) and V2=e(g1,g′) in advance and stores them. Simultaneously, to ensure the cloud can help users do a part of computation and avoid the cloud from obtaining information from the user’s attributes, the fog selects s′←rZp∗ randomly and computes D1=g1s′, D2j=(d1j)s′=(gθj)s′=gθjs′ and sends cvkui=(D1,{D2j}atj∈Ωui) to the cloud and the secret s′ to the user through a secure channel.(6)
Encrypt: Suppose that the data owner decides his fileF. This file can be searched and acquired by users whose attributes satisfy with an access policy A. Under this assumption, the user can designate different types of data to be accessed by different kind of people. For the monotone access policy A, there exists a basis A0=(Ω1,Ω2,…,Ωn), where each Ωi, a minimal set, is composed of the authorized attributes. To encrypt the file, the user picks sl←rZp∗ for each 1≤l≤n computes(2)Cl=C1l,C2l=F·∏atj∈Ωld2jsl,sls′,The user keeps the ciphertext as C=(A,{Cl}1≤l≤n) embedded with the access policy A.(7)
Index: For a continuous health monitoring system, data are constantly processed and transferred to the cloud from various kind of sensors. In order to get quick access to useful files from the super large data center, we add different keywords to files.We assume the fileF contains a set of keywords W which are extracted from the original health file. For each keyword W∈W, the user picks u←rZp∗ randomly and computes IW=(CW1,CW2,CW3)=((e(g,g)H(W)e(g1,g′))u,gu,g2u). Subsequently, the user sends the ciphertext C together with the index IW to the cloud. Then the cloud stores them.(8)
Trapdoor: Generally speaking, theTrapdoor algorithm is used to generate a trapdoor for a certain keyword by the user who wants to search files containing this keyword. In our system, to help the user reduce the computing burden, we delegate the fog to do a part of the trapdoor generation work without leaking any information about the queried keywords. This design has an advantage in our IoT system: confidentiality of keywords. Specifically, upon receiving the query request from the user Useri, the fog firstly searches the user’s identity in table Tuser. If the fog does not find it in the table which means the user did not join the system, then the fog refuses to generate the part trapdoor for the user and returns a warning message. This process completed by the fog ensures that any external user who is not authenticated cannot search any keyword and guarantees no leakage of any information about keywords or encrypted files. If the fog finds the user in table Tuser, the fog randomly chooses ρ←rZp∗, sends it to the user through a secure channel, and then computes(3)Tf0=T0ρ=t0t2ρ=gυδρg1αiδρ,Tf1=T1ρ=t1t2ρ=gβiδρ,Tf2j=T2jρ=svkjt2ρ=gαiθjδρ.After finishing all the above steps, the fog uploads Tf=(Tf0,Tf1,Tf2j{atj∈Ωui}) to the cloud as a part of the trapdoor. To search files with a keyword W′, the user firstly chooses η←rZp∗ and computes(4)TW1=gHW′Siη=gHW′g1sg2βiδη,TW2=ηρwith his own search key. Then, the user sends the other part of the trapdoor TW=(TW1,TW2) to the cloud. Ultimately, the cloud gets a full trapdoor T=(Tf,TW). In this phase, if the fog has verified one user’s identity and verification keys for his attributes, the fog can perform the trapdoor generation once in a while. This is available as this phase is not related to the queried keyword. As a result, the computing burden for the fog and interaction time for both the user and the fog can be reduced.(9)
Test: Upon receiving the search request for keywordW′ from the fog and the user, the cloud runs Test algorithm for all items which are encrypted indexes for all the keywords by computing(5)eCW2,TW1eCW3,Tf1TW2.The cloud compares the result with CW1, if it equals CW1, the cloud outputs 1, and performs the next step. Otherwise, the cloud outputs 0, returns a warning message, and exits the system.(10)
Decryption: If the algorithmTest cannot find an index for the uploaded trapdoor, the cloud would not run the Dec1 algorithm and returns ⊥. Otherwise, the cloud computes(6)Cpd=eD1,∏atj′∈Ωui′Tf2je∏atj′∈Ωui′D2j,Tf0C2lTW2.Once upon receiving the part-decrypted ciphertext Cpd from the cloud, the user recovers the file F by using his own private key through computing(7)F=C1lCpd1/δt2.Obviously, the user only needs to do an exponential operation in the decryption, which is a great step in improving efficiency.


## 4.2. Consistency

Firstly, we present that the trapdoor matching is valid in our system.(8)eCW2,TW1eCW3,Tf1TW2=egu,gHW′g11/ηsg2βiδηeg2u,gβiδρη/ρ=egu,gHW′·egu,g1s·egu,g2βiδηeg2u,gβiδη=eg,guHW′·eg,g1us·eg,g2uβiδηeg2,guβiδη=eg,guHW′·eg,g1us=eg,guHW′·eg1,g′u. If there exists a keyword W∈W matching with the queried keyword which leads H(W)=H(W′), we can derive the conclusion e(CW2,TW1)/e(CW3,Tf1TW2)=CW1.Then, the file recovery can be maintained as the following two steps. If the test passes, the cloud decrypts all the related files by computing(9)Cpd=eD1,∏atj′∈Ωui′Tf2je∏atj′∈Ωui′D2j,Tf0C2lTW2=eg1s′,∏atj′∈Ωui′gαiθjδρe∏atj′∈Ωui′gθjs′,gυg1αiδρsl/s′η/ρ=eg1s′,gαiδρ∑atj′∈Ωui′egs′∑atj′∈Ωui′θj,gυδρ·egs′∑atj′∈Ωui′θj,g1αiδρsl/s′η/ρ=eg1,gs′αiδρ∑atj′∈Ωui′eg,gs′υδρ∑atj′∈Ωui′θj·eg,g1s′αiδρ∑atj′∈Ωui′θjsl/s′η/ρ=1eg,gυδ∑atj′∈Ωui′θjslη=1eg,gυδslη∑atj′∈Ωui′θj.If the user’s attributesΩui′ satisfy the access policy A, we know there exists a basis A0′=(Ω1′,Ω2′,…,Ωn′) s.t.(10)∀atj∈Ωui′,∃Ωl′s.t.atj∈Ωl′⊆Ωui′, and we have ∑atj′∈Ωui′θj=∑atj′∈Ωl′θj=∑1nθj=∑atj′∈Ωlθj.According to this, the user finally recovers the file by computing(11)F=C1lCpd1/δt2=F·∏atj∈Ωld2jsl1eg,gυδslη∑atj′∈Ωui′θj1/δη=F·eg,gυsl∑atj∈Ωuiθj·1eg,gυsl∑atj′∈Ωui′θj=F.


## 4.3. User Revocation and Attribute Revocation

As mentioned above, the fog is an access interface between the cloud and users. The tableTuser is a certification to verify whether a user is in the system. The revocation of a user can be realized through rejecting the query request. To be specific, once a user submits a revocation request to the trusted authority or the trusted authority decides to revoke a user, the trusted authority deletes all keys and attributes information of the user. Then it sends the user’s revocation information to the fog, and all the information about the user will be deleted in Tuser. As a result, the user cannot update his/her request to the cloud server. Furthermore, once the re-encrypted keys cskui and cvkui are revoked from the fog, the user cannot generate trapdoors for any keywords. Because the fog needs cskui and cvkui to do a part of computation to accomplish the trapdoor generation phase, the loss of cskui and cvkui leads to the user’s failure to search for any files. As a result, such a user is new to the system and the fog will no longer respond to its any request.In our system, we can achieve attribute revocation with the designation ofcskui and cvkui. Once an attribute is revoked, the data owner could keep the data from the group of users who have the revoked attribute. To be specific, upon deciding to revoke an attribute atj, the fog destroys the attribute’s verification key vkj and deletes cskui and cvkui for users containing the attribute, then sends a warning message to these users to update the related cskui and cvkui. Before users updating cskui and cvkui, the fog refuses to generate trapdoor for them, which directly leading to the failure of accessing files in the system. Although it may cause some computational loads and transmission cost, it is acceptable when the extremely sensitive data is concerned.


## 5. Security Analysis

Recall that our system is concerned about three security requirements: data confidentiality, keyword privacy, and trapdoor privacy. We present our security analysis for trapdoor privacy by proofing Theorem5, and data confidentiality and keyword privacy are exhibited through Theorem 6,.The security of our scheme is based on the complex assumption in Definition2.Theorem 5 (trapdoor privacy).
Under the assumption of DBDH, the trapdoor generated in our LFSE scheme is indistinguishable against the chosen keyword attack.Proof.
Assume that an malicious adversaryA is able to break the trapdoor security in our LFSE scheme in a polynomial time with the advantage ϵ which is not negligible. Without loss of generality, we construct an algorithm B that plays the following game with A and solves DBDH using the capability of A.(i)
Setup: For a security parameterλ, the algorithm B takes (g,ga,gb,gc,Z) as input, where a,b,c are chosen from Zp∗ by the challenger C and Z is also randomly selected from G. The challenger C picks a coin to denote x∈{0,1}. If x=1, computes Z=gabc. Otherwise, Z is a random element from G. For the user ui, the algorithm randomly chooses s,αi,ν from Zp∗ and g1,g2 from the group G. Then it announces the user’s public and private key as (gαi,(gνgαi,gb,c)) and sets g2=g,η=c. Furthermore, it announces the search key for the user as (g11/η)sg2ab.(ii)
Query Phase 1: The adversaryA issues the following query.O.Query: Upon receiving the query request on keyword W from the adversary A. The algorithm B selects r,ρ,θj randomly from Zp∗ and then it computes Tf0=grbρg1αibρ, Tf1=gabρ, Tf2=gαiθjbρ, TW1=gH(W)((g11/η)sg2ab)η, and TW2=c/ρ, where all the other parameters are randomly chosen in a similar way as in Theorem 5. At last, the algorithm B returns Tf=(Tf0,Tf1,Tf2,TW1,TW2) as the trapdoor for the keyword W′ to A.(iii)
Challenge: The adversaryA selects two keywords W0∗ and W1∗ with equal length which are both queried for the first time. Then the algorithm B flips a coin to choose a random bit of x and computes the trapdoor for the keyword Wx∗ as Tf∗=(Tf0∗,Tf1∗,Tf2∗,TW1∗,TW2∗), where Tf0∗=grbρg1αibρ, Tf1∗=gabρ, Tf2∗=gαiθjbρ, TW1∗=gH(W)g1sZ and TW2∗=c/ρ.(iv)
Query Phase 2: The adversaryA does the same thing continuously for polynomial times as in Query Phase 1, but with the restriction that both W0∗ and W1∗ cannot be queried any more.(v)
Guess Phase: The adversaryA returns a guess x∈0,1′ to B. If x′=x, it means the adversary A wins the game, the algorithm B outputs 1. Otherwise A fails and B outputs 0.(vi)
Analysis: As shown above, we haveTW1=gH(W)((g11/η)sg2ab)η=gH(W)((g11/c)sgab)c=gH(W)g1sgabc. Compared with Tf2∗, we can know Z=gabc clearly. As a result, the adversary A can win the game with the same probability of winning the DBDH assumption. That means AdvB(1λ)DBDH=Pr[x′=x]=ϵ, which is contradictory to the DBDH assumption.
In summary, our scheme satisfies the trapdoor indistinguishable secure under the DBDH assumption.Theorem 6 (Ciphertext privacy and keyword privacy).
The proposed scheme shown in Section4 is IND-CK-CCA secure under the DBDH assumption.Proof.
Suppose there is a polynomial time adversaryA who can break our proposed scheme with a nonnegligible advantage ϵ, then we can build an algorithm to solve the DBDH assumption. It can be described as a game between a challenger C and an adversary A.
Setup: The challengerC receives (G,GT,e,g,gx,gy,gz,Z) from the DBDH assumption, where Z is a randomly chosen element from GT or equals e(g,g)xyz. The challenger C chooses s,υ→Zp∗ and computes g2=gs, V=e(g,g)υ, and also C sets g1=gx,g′=gy. (g,g1,g2,g′,V) are sent to the adversary A as public parameters.
Phase 1: The adversaryA makes the following queries:(i)
O.Fog.KeyGen: The adversary A queries keys for the fog, and the challenger C picks σF,ςF←rZp∗ at random and outputs (PkF, SkF)=(ςF,gςF).(ii)
O.KeyGen: The adversary A queries keys for the user Useri, and the challenger C picks αi,βi,δ←rZp∗ at random and computes (PkUseri,SkUseri)=(gαi,(t0,t1,t2)) to A, where t0=gυg1αi, t1=gβi, and t2=δ. For all the attributes owned by the user, the adversary A also queries the verification keys from O.Fog.KeyGen and secret verification keys from O.KeyGen, then A obtains vkj=(d1j,d2j), and svkj=d3j=gαiθj, where θj=H1(σF,atj), d1j=gθj, and d2j=Vθj are computed by C.(iii)
O.SearchKeyGen: After receiving a commitment g11/η, the adversary A queries the search key, and the challenger C computes Si=(g11/η)sg2βiδ to A.(iv)
O.ReKey: The adversary A queries transformed key for the user, and the challenge C computes T0=t0t2, T1=t1t2, and T2j=(d3j)t2 and sends cskui=(T0,T1,{T2j}atj∈Ωui) to A.(v)
O.Trapdoor: Upon getting a query on the trapdoor for the keyword W, C firstly randomly chooses ρ,η←rZp∗ and computes Tf0=T0ρ,Tf1=T1ρ,Tf2j=T2jρ, TW1=gH(W′)Siη, and TW2=η/ρ to A.
Challenge: The adversaryA gives an access policy A∗, two equal length plaintexts m0∗,m1∗ and two keywords W0∗,W1∗ to C. Then C randomly picks b1∈{0,1} and constructs the ciphertext as ((mb2∗·(∏atj∈Ωl‍d2j)sl,sl/s′),1≤l≤n). Also it constructs the index CW1∗=e(g,gz)H(Wb1∗)·Z,CW2∗=gz,CW3∗=(gz)s. C sends the index IW∗=(CW1∗,CW2∗,CW3∗) for keyword W.
Phase 2:A can ask a polynomially bounded number of queries adaptively again as Phase 1 except the queried keyword W∉{W0∗,W1∗}. C answers A’s queries as in Phase 1.
Guess:A outputs guesses b1′,b2′ of b1,b2. C outputs 0 to guess that Z=e(g,g)xyz if b1′=b1 and b2′=b2; otherwise, it outputs 1 to indicate that it believes Z is a random element.
Analysis: Assume the adversaryA has an advantage ϵ in attacking DBDH assumption and C has an advantage ϵ′ in winning the game. Through the game showed above, we can know ϵ′=ϵ as a obvious result.


## 6. Efficiency Analysis

In this section, we analyse the efficiency of our system from both theoretical and experimental aspects. Table1 illustrates the descriptions of notations we use in the following comparisons.Table 1
Description of parameters.
Parameter Description |S| the size of the user’s attribute set k the amount of attributes associated with the user’s private key |U| the size of the attribute universe t the amount of attributes associated with the ciphertext N the number of files to be encrypted m the number of keywords to be used to generate indexes |G|,|GT| the bit length of the elements belong to the groupG,GT |Zp| the bit length of the elements belong to the groupZp Cp the computational cost of the pairing operationG,GeT Ce,CeT the computational cost of the exponential operation in groupG,GeT


### 6.1. Storage and Transmission Cost Analysis

We compare our scheme with the related schemesVKS [17], LHL [19], SYL [18], and ZSQM [20] over some important features, which are illustrated in Tables 2 and 3. Though many parameters are generated, stored, and transmitted throughout the whole process, we only consider the following parameters that extremely affect the system efficiency:(i)
PK: The size of public keyPK measures how many storage is needed to store public keys of all entities for each user to accomplish his computation. As shown in the second column in Table 2, it increases linearly with |U| in [18, 19], which leads to a great amount storage demand for the user. This indicates it is difficult to adopt new attributes in [18, 19]. Because it cannot meet the demands of frequently updating attributes in rapidly changing IoT networks. Reference [20] is file-centered, so the size of PK is related to the number of all files being encrypted, which also causes a large storage requirement for each user. It is obviously that our scheme and [17] only have a small and constant storage requirement.(ii)
SK: The private keySK is always kept by the user himself, so the size of SK only indicates the secure storage needed to store his private key for each user. The third column reveals that, in [17–20], |SK| increases with the attributes with different efficients k,2k,S,|U|, respectively, where k<2k<S≪|U|. Since the storage of users or devices in IoT networks is limited, it would be desirable if only small and constant storage is needed to store the keys. This expected goal is achieved in our scheme as shown; it is obviously better than the others with only constant storage requirement 2|G|+|Zp|, regardless of the attribute number’ change.(iii)
CT: The size of ciphertextCT measures the transmission cost for the user and the storage cost for the cloud server, because the ciphertext is computed by the user, transmitted to the cloud, and stored in the cloud data center. Reference [18] is concentrated in the user management such as user updating and revoking, and the encryption and decryption processes are not revealed in details, so it is empty in the fourth column. Considering that all the five schemes store an access policy in the ciphertext, we ignore this part in the ciphertext size comparison. CT in our scheme and [19] are both linearly increasing with the number of the attributes associated with the user’s private key k, which is consistent with the situations in real world. Obviously, CT in [17] is much larger than our scheme and [19], owing to |U| is much larger than k, which means it takes much more transmission overhead for the user and more storage requirement for the cloud server. Ciphertext size in [20] is (N+2)|G|+2|GT|, because it is file-centered; all files owned by each user are encrypted at one time; this is not convenient if only a part of files are needed to be updated or modified..(iv)
ID and TD: The size of indexID indicates the transmission overhead for the user and the storage required to store the indexes for retrieving related files for the cloud. The size of trapdoor TD shows the transmission cost for the data user, because the trapdoor is needed to be transmitted to the cloud to accomplish the test and search processes. We do not compute ID and TD for [19] as [19] only concerns about attribute-based encryption and it does not support the function of searching on keywords. For simplicity, we consider generating the index and trapdoor for only one keyword here. We could tell that the scheme in [18] costs most for transmitting both ID and TD between the user and the cloud server. It is shown from the fifth column that [17, 20] have similar ID size with our scheme, which reveals a small and constant storage is required. For the trapdoor size, scheme in [17] is linearly with the user’s attribute number, while scheme in [20] and ours is constant; furthermore, ours requires less transmission overhead than [20].Table 2
Storage and transmission comparisons.
PK SK CT ID TD VSKE [17] 6 | G | + | G T | 2 ( | S | + 1 ) | G | + | Z p | ( | U | + k ) ( | G | + | G T | ) 2 | G | + | G T | ( 2 | S | + 3 ) | G |  SYL [18] 3 | U | | G | + | G T | ( 2 | U | + 1 ) | G | + 2 | Z p | - ( | U | + 1 ) | G | + | G T | + | Z p | ( 2 | U | + 1 ) | G | + 2 | Z p |  LHL [19] ( | U | + 4 ) | G | 2 k | G | + | Z p | ( k + 2 ) | G | + | G T | - -  ZSQM [20] ( N + 4 ) | G | ( | S | + 3 ) | G | + | Z p | ( N + 2 ) | G | + 2 | G T | | G T | 4 | G |  Ours 5 | G | + | G T | 2 | G | + | Z p | 2 k | G T | 2 | G | + | G T | | G | + | Z p |Table 3
Computation cost comparisons.
Keygen Encrypt Index Trapdoor Test Decrypt VSKE [17] ( 2 | S | + 4 ) C e ( 2 m + 1 ) C e ( 2 | S | + 4 ) C e ( 2 | U | + K ) C e + k C p ( 2 | S | + 1 ) C p + | S | C e T C p + C e T  SYL [18] ( 2 | U | + 1 ) C e + 2 C e T - ( | U | + 1 ) C e + C e T ( 2 | U | + 1 ) C e ( | U | + 1 ) C p + C e T -  LHL [19] 2 ( k + 1 ) C e ( k + 2 ) C e + C p - - - ( 2 k + 3 ) C p + C e T  ZSQM [20] 5 C e + N C p ( N + 3 ) C e + C p + C e T C p ( N + 2 ) C e 2 C e + ( k + 1 ) C p ( N k + 1 ) C p + C e  Ours 4 C e k C e T 2 ( C e + C e T ) 2 ( | S | + 1 ) C e 2 C p + C e C eAccording to the above analyses, our scheme has a better performance in the storage and transmission requirement comparing with the other exsiting schemes.


### 6.2. Computational Cost Simulation and Analysis

In this section we present the analysis in terms of the computational cost and comparisons with those related works listed in Table2. Since operations over Zp cost much less computational time than operations over groups and the pairing operation, we just consider the latter two fundamental cryptographic operations. The results are given in Table 3. It is obvious from the table that our scheme has significantly better efficiency than the other schemes.By adopting the pairing-based cryptography (PBC (URL:https://crypto.stanford.edu/pbc)) library, we perform our experiment in C on a computer with Intel(R) Core(TM) i3-3220 CPU @ 3.30 running Ubuntu 16.04.5 with 4.00 GB system memory. This simulation environment is used to performKeygen andTest, which are executed by the trusted authority and the cloud server with a great computational capability. In contrast, the users or devices in our system are mostly with low computational capability, to simulateEncrypt,Index,Trapdoor, andDecrypt performed by them; we execute our experiment on a client machine with Intel Core Duo CPU running Ubuntu MATE 16.04 with 2 GB system memory. To realize the security requirement of 1024-bit, we use the Type A curve, which is denoted as E(Fq):y2=x3+x with parameter q=512 bits, where the order p of both the group G and group GT is 160 bits and |G|=|GT|=1024 bits. For simplicity, we assume that the user only generates index for one keyword in our simulation. The simulation result is exhibited in Figure 3.Figure 3
Comparison of computational cost.
(a)
Time for key generation (b)
Time for encryption (c)
Time for index generation (d)
Time for trapdoor generation (e)
Time for test (f)
Time for decryptionOnce receiving a request from a user to join in the system, TA generates public and private keys for each user with only four exponential operations in our scheme. Clearly from Figure3(a), the computation cost in our scheme is constant and the smallest among all the schemes. As the attribute number increases, the computational cost for key generation in [17–19] all grows; especially in [18] it climbs up to thousands of milliseconds. Cost in [20] is also constant and similar with ours, this is because we assume the encrypted file number N=1 for simplicity in our experiment. While in reality the scheme in [20] is file-centered, the computational cost for key generation grows with the number of encrypted files increases, but in our scheme the cost for key generation is irrelevant with the encrypted file numbers.After receiving the keys from TA, the user encrypts the files with his/her keys before updating them to the cloud server. Reference [18] focuses on attributed-based encryption to manage users; the data encryption and decryption phase are not described in details; therefore it is not considered in our encryption simulation. Reference [20] is not considered in the encryption phase because the scheme encrypts all files of one user at once, while the others encrypt one file at a time. As shown in Figure 3(b), cost for encryption in our scheme and [19] are increasing linearly with the number of attributes grows, due to the file is encrypted associated with the attributes embedded in the access policy. When the attribute number is 50, our scheme needs 109.96 milliseconds and [19] needs 133.758 milliseconds, which is lightly larger than ours. Reference [17] has the lowest computational cost because they use symmetric encryption method to encryption and the cost shown in Figure 3(b) is for access control in encryption phase.Next is about querying on keywords, which involves the three algorithms:Index,Trapdoor, andTest. The computational cost for them is exhibited in Figures 3(c), 3(d), and 3(e), respectively. Because [19] has no capability for searching based on keywords, it is not considered in our comparison for these three phases. References [17, 18] have a obviously large increase in computation burden when the number of the attributes grows. When the attribute number grows up to 100, almost 15000 milliseconds are required to complement these three algorithms to achieve querying on keywords for the two schemes, which causes a long network delay. Our scheme has a similar computational cost with the scheme in [20] proposed to speed up in the industrial IoT network, which has been proved having a good efficiency in fast query.Last, the computational cost for the decryption phase is shown in Figure3(f). The efficiency for the decryption algorithm is very important because one keyword is always associated with a lot of different files. To decrypt all the returned files in a short time in IoT networks is a key issue in recent researches. As shown in Figure 3(f), our scheme satisfies this demand with only less than 13 milliseconds is required, regardless of the increasing of the attribute number. And the scheme in [17] has a lightly bigger cost than ours. In contrast, the other two schemes’ cost grows enormously with the attributes’ number, which causes a super large computational burden because of the large amount of returned files and the user’s limited computation capability.In summary, our proposed scheme enjoys a good efficiency in storage, transmission requirement, and computational cost, which indicates it is suitable for the healthcare related IoT networks.


## 6.1. Storage and Transmission Cost Analysis

We compare our scheme with the related schemesVKS [17], LHL [19], SYL [18], and ZSQM [20] over some important features, which are illustrated in Tables 2 and 3. Though many parameters are generated, stored, and transmitted throughout the whole process, we only consider the following parameters that extremely affect the system efficiency:(i)
PK: The size of public keyPK measures how many storage is needed to store public keys of all entities for each user to accomplish his computation. As shown in the second column in Table 2, it increases linearly with |U| in [18, 19], which leads to a great amount storage demand for the user. This indicates it is difficult to adopt new attributes in [18, 19]. Because it cannot meet the demands of frequently updating attributes in rapidly changing IoT networks. Reference [20] is file-centered, so the size of PK is related to the number of all files being encrypted, which also causes a large storage requirement for each user. It is obviously that our scheme and [17] only have a small and constant storage requirement.(ii)
SK: The private keySK is always kept by the user himself, so the size of SK only indicates the secure storage needed to store his private key for each user. The third column reveals that, in [17–20], |SK| increases with the attributes with different efficients k,2k,S,|U|, respectively, where k<2k<S≪|U|. Since the storage of users or devices in IoT networks is limited, it would be desirable if only small and constant storage is needed to store the keys. This expected goal is achieved in our scheme as shown; it is obviously better than the others with only constant storage requirement 2|G|+|Zp|, regardless of the attribute number’ change.(iii)
CT: The size of ciphertextCT measures the transmission cost for the user and the storage cost for the cloud server, because the ciphertext is computed by the user, transmitted to the cloud, and stored in the cloud data center. Reference [18] is concentrated in the user management such as user updating and revoking, and the encryption and decryption processes are not revealed in details, so it is empty in the fourth column. Considering that all the five schemes store an access policy in the ciphertext, we ignore this part in the ciphertext size comparison. CT in our scheme and [19] are both linearly increasing with the number of the attributes associated with the user’s private key k, which is consistent with the situations in real world. Obviously, CT in [17] is much larger than our scheme and [19], owing to |U| is much larger than k, which means it takes much more transmission overhead for the user and more storage requirement for the cloud server. Ciphertext size in [20] is (N+2)|G|+2|GT|, because it is file-centered; all files owned by each user are encrypted at one time; this is not convenient if only a part of files are needed to be updated or modified..(iv)
ID and TD: The size of indexID indicates the transmission overhead for the user and the storage required to store the indexes for retrieving related files for the cloud. The size of trapdoor TD shows the transmission cost for the data user, because the trapdoor is needed to be transmitted to the cloud to accomplish the test and search processes. We do not compute ID and TD for [19] as [19] only concerns about attribute-based encryption and it does not support the function of searching on keywords. For simplicity, we consider generating the index and trapdoor for only one keyword here. We could tell that the scheme in [18] costs most for transmitting both ID and TD between the user and the cloud server. It is shown from the fifth column that [17, 20] have similar ID size with our scheme, which reveals a small and constant storage is required. For the trapdoor size, scheme in [17] is linearly with the user’s attribute number, while scheme in [20] and ours is constant; furthermore, ours requires less transmission overhead than [20].Table 2
Storage and transmission comparisons.
PK SK CT ID TD VSKE [17] 6 | G | + | G T | 2 ( | S | + 1 ) | G | + | Z p | ( | U | + k ) ( | G | + | G T | ) 2 | G | + | G T | ( 2 | S | + 3 ) | G |  SYL [18] 3 | U | | G | + | G T | ( 2 | U | + 1 ) | G | + 2 | Z p | - ( | U | + 1 ) | G | + | G T | + | Z p | ( 2 | U | + 1 ) | G | + 2 | Z p |  LHL [19] ( | U | + 4 ) | G | 2 k | G | + | Z p | ( k + 2 ) | G | + | G T | - -  ZSQM [20] ( N + 4 ) | G | ( | S | + 3 ) | G | + | Z p | ( N + 2 ) | G | + 2 | G T | | G T | 4 | G |  Ours 5 | G | + | G T | 2 | G | + | Z p | 2 k | G T | 2 | G | + | G T | | G | + | Z p |Table 3
Computation cost comparisons.
Keygen Encrypt Index Trapdoor Test Decrypt VSKE [17] ( 2 | S | + 4 ) C e ( 2 m + 1 ) C e ( 2 | S | + 4 ) C e ( 2 | U | + K ) C e + k C p ( 2 | S | + 1 ) C p + | S | C e T C p + C e T  SYL [18] ( 2 | U | + 1 ) C e + 2 C e T - ( | U | + 1 ) C e + C e T ( 2 | U | + 1 ) C e ( | U | + 1 ) C p + C e T -  LHL [19] 2 ( k + 1 ) C e ( k + 2 ) C e + C p - - - ( 2 k + 3 ) C p + C e T  ZSQM [20] 5 C e + N C p ( N + 3 ) C e + C p + C e T C p ( N + 2 ) C e 2 C e + ( k + 1 ) C p ( N k + 1 ) C p + C e  Ours 4 C e k C e T 2 ( C e + C e T ) 2 ( | S | + 1 ) C e 2 C p + C e C eAccording to the above analyses, our scheme has a better performance in the storage and transmission requirement comparing with the other exsiting schemes.


## 6.2. Computational Cost Simulation and Analysis

In this section we present the analysis in terms of the computational cost and comparisons with those related works listed in Table2. Since operations over Zp cost much less computational time than operations over groups and the pairing operation, we just consider the latter two fundamental cryptographic operations. The results are given in Table 3. It is obvious from the table that our scheme has significantly better efficiency than the other schemes.By adopting the pairing-based cryptography (PBC (URL:https://crypto.stanford.edu/pbc)) library, we perform our experiment in C on a computer with Intel(R) Core(TM) i3-3220 CPU @ 3.30 running Ubuntu 16.04.5 with 4.00 GB system memory. This simulation environment is used to performKeygen andTest, which are executed by the trusted authority and the cloud server with a great computational capability. In contrast, the users or devices in our system are mostly with low computational capability, to simulateEncrypt,Index,Trapdoor, andDecrypt performed by them; we execute our experiment on a client machine with Intel Core Duo CPU running Ubuntu MATE 16.04 with 2 GB system memory. To realize the security requirement of 1024-bit, we use the Type A curve, which is denoted as E(Fq):y2=x3+x with parameter q=512 bits, where the order p of both the group G and group GT is 160 bits and |G|=|GT|=1024 bits. For simplicity, we assume that the user only generates index for one keyword in our simulation. The simulation result is exhibited in Figure 3.Figure 3
Comparison of computational cost.
(a)
Time for key generation (b)
Time for encryption (c)
Time for index generation (d)
Time for trapdoor generation (e)
Time for test (f)
Time for decryptionOnce receiving a request from a user to join in the system, TA generates public and private keys for each user with only four exponential operations in our scheme. Clearly from Figure3(a), the computation cost in our scheme is constant and the smallest among all the schemes. As the attribute number increases, the computational cost for key generation in [17–19] all grows; especially in [18] it climbs up to thousands of milliseconds. Cost in [20] is also constant and similar with ours, this is because we assume the encrypted file number N=1 for simplicity in our experiment. While in reality the scheme in [20] is file-centered, the computational cost for key generation grows with the number of encrypted files increases, but in our scheme the cost for key generation is irrelevant with the encrypted file numbers.After receiving the keys from TA, the user encrypts the files with his/her keys before updating them to the cloud server. Reference [18] focuses on attributed-based encryption to manage users; the data encryption and decryption phase are not described in details; therefore it is not considered in our encryption simulation. Reference [20] is not considered in the encryption phase because the scheme encrypts all files of one user at once, while the others encrypt one file at a time. As shown in Figure 3(b), cost for encryption in our scheme and [19] are increasing linearly with the number of attributes grows, due to the file is encrypted associated with the attributes embedded in the access policy. When the attribute number is 50, our scheme needs 109.96 milliseconds and [19] needs 133.758 milliseconds, which is lightly larger than ours. Reference [17] has the lowest computational cost because they use symmetric encryption method to encryption and the cost shown in Figure 3(b) is for access control in encryption phase.Next is about querying on keywords, which involves the three algorithms:Index,Trapdoor, andTest. The computational cost for them is exhibited in Figures 3(c), 3(d), and 3(e), respectively. Because [19] has no capability for searching based on keywords, it is not considered in our comparison for these three phases. References [17, 18] have a obviously large increase in computation burden when the number of the attributes grows. When the attribute number grows up to 100, almost 15000 milliseconds are required to complement these three algorithms to achieve querying on keywords for the two schemes, which causes a long network delay. Our scheme has a similar computational cost with the scheme in [20] proposed to speed up in the industrial IoT network, which has been proved having a good efficiency in fast query.Last, the computational cost for the decryption phase is shown in Figure3(f). The efficiency for the decryption algorithm is very important because one keyword is always associated with a lot of different files. To decrypt all the returned files in a short time in IoT networks is a key issue in recent researches. As shown in Figure 3(f), our scheme satisfies this demand with only less than 13 milliseconds is required, regardless of the increasing of the attribute number. And the scheme in [17] has a lightly bigger cost than ours. In contrast, the other two schemes’ cost grows enormously with the attributes’ number, which causes a super large computational burden because of the large amount of returned files and the user’s limited computation capability.In summary, our proposed scheme enjoys a good efficiency in storage, transmission requirement, and computational cost, which indicates it is suitable for the healthcare related IoT networks.


## 7. Related Work

### 7.1. Healthcare Related IoT Security

Security is one of the most important issues in the healthcare related IoT Networks. This is not only because the vulnerability of IoT devices themselves, which can be easily attacked or physically destructed, but also because the data collected and processed in IoT networks are highly sensitive and tightly related to our life. Johns Hopkins University developed an hospital-centralized patient monitoring system called MEDiSN [22]. But in this system secure communication especially data integrity and user authentication are not implemented [23]. Similar with MEDiSN, other systems such as CodeBlue [24] and MobiCare [25] are implemented in the infrastructure layer without considering the real communication security.To achieve real communication security, encryption operations are essential. However, most of the existing encryption schemes demand complex computation operations and high process overload. How to overcome these limitations is an important issue. In [26, 27], the authors present a secure and efficient authentication and authorization framework for healthcare related IoT network but high processing power is needed. In [28], the authors implement an IoT-based health prescription assistant and achieve user authentication and access control on their system. However, the data confidentiality is not considered during the transmission process [29]. Although they have reduced some communication and computation latency in their small-scale data experiment, it is still not enough for real world network with super large amount of data [30].


### 7.2. ABE in Cloud Computing Paradigm

As an extension of identity-based encryption, attribute-based encryption was first introduced by Sahai and Waters [13]. It has been applied to a lot of encryption schemes to achieve fine-grained access control over encrypted data. Particulary, ABE was extended by Goyal et al. [31] to form two complementary flavors: key-policy ABE (KP-ABE) and ciphertext-policy ABE (CP-ABE). KP-ABE takes attributes to describe the ciphertexts, and policies over these attributes are associated with users’ keys, while in CP-ABE it is reversed. CP-ABE makes it possible that the users can get access to the encrypted data and decrypt the data only if the access structures match attributes.Same as the originally proposed ABE scheme in [13], the most classic architecture of ABE access control schemes apply a single central authority to take charge of enrolling, updating all attributes and managing keys for all entities. In such centralized ABE frameworks, the most difficult but important part is to achieve efficient revocation for users and attributes. In [32], the authors put forward an expiration time for each attribute to maintain revocation but it turns out having issues in backward and forward. The authors from [33, 34] succeed in overcoming the above issues through adopting the concept of proxy-based re-encryption. Also, lazy revocation [33, 35] and revocable-storage ABE [36] are designed to achieve revocation to prevent the message from unauthorized users.As the IoT networks expand, the centralized ABE paradigm with only one single authority has a great drawback in efficiency due to the super large amount of data. Therefore, multiauthority ABE was introduced by [37], in which a global identifier was assigned by the central authority to each user as a unique ID, aiming to distinguish users without attributes by independent authorities. Furthermore, more works such as [38–40] improve the above scheme by cancelling the user’s consistent GID to avoid privacy leakage and support collusion resistance; this paradigm is called as decentralized ABE.No matter in a centralized or decentralized ABE paradigm, a user may not withstand the financial attempt and share his attributes to other users. In order to avoid a decryption privilege leakage, works in [41, 42] provide access control schemes with traceability, where the user who leaks the decryption key to someone else can be traced and revoked by the system. As people become more concerned about personal privacy, the access policy itself can be taken as sensitive information and need to be protected from unauthorized users. Works in [43] achieve anonymity by designing three protocols together with homomorphic encryption and scrambled circuit evaluation to protect both the policies and the credentials.


### 7.3. Searchable Encryption with ABE in Cloud Computing Paradigm

The searchable encryption was firstly proposed by [44] and has been widely researched and used. It has indicated a new direction for operating searching on ciphertexts in cloud computing [45]. Both the notion of symmetric encryption with keyword search (SESK) and the public key encryption with keyword search (PESK) are gaining a lot of attentions. They have been developed to support different functions, such as works in [18, 46–51]. However, these schemes cannot achieve fine-grained access control on ciphertexts.The attribute-based keyword search (ABKS) was proposed in [52], in which the cloud server checks whether the user has the capability to decrypt the required encrypted ciphertext before searching it by a signature built from the user’s attributes. But this scheme cannot maintain the security of keywords. Some other works also proposed different schemes based on ABKS to support specific functions such as Checkability [19], fuzzy keyword search [53], revocation [54], and verifiability [55]. But most of these works require the users to do complex computation like pairing and exponential operations many times, which is not practical because of the user’s limited computation ability. Therefore, how to transfer the heavy computation burden and reduce the times of complex computation operations without loosing security requirements is the most important challenge for now.


## 7.1. Healthcare Related IoT Security

Security is one of the most important issues in the healthcare related IoT Networks. This is not only because the vulnerability of IoT devices themselves, which can be easily attacked or physically destructed, but also because the data collected and processed in IoT networks are highly sensitive and tightly related to our life. Johns Hopkins University developed an hospital-centralized patient monitoring system called MEDiSN [22]. But in this system secure communication especially data integrity and user authentication are not implemented [23]. Similar with MEDiSN, other systems such as CodeBlue [24] and MobiCare [25] are implemented in the infrastructure layer without considering the real communication security.To achieve real communication security, encryption operations are essential. However, most of the existing encryption schemes demand complex computation operations and high process overload. How to overcome these limitations is an important issue. In [26, 27], the authors present a secure and efficient authentication and authorization framework for healthcare related IoT network but high processing power is needed. In [28], the authors implement an IoT-based health prescription assistant and achieve user authentication and access control on their system. However, the data confidentiality is not considered during the transmission process [29]. Although they have reduced some communication and computation latency in their small-scale data experiment, it is still not enough for real world network with super large amount of data [30].


## 7.2. ABE in Cloud Computing Paradigm

As an extension of identity-based encryption, attribute-based encryption was first introduced by Sahai and Waters [13]. It has been applied to a lot of encryption schemes to achieve fine-grained access control over encrypted data. Particulary, ABE was extended by Goyal et al. [31] to form two complementary flavors: key-policy ABE (KP-ABE) and ciphertext-policy ABE (CP-ABE). KP-ABE takes attributes to describe the ciphertexts, and policies over these attributes are associated with users’ keys, while in CP-ABE it is reversed. CP-ABE makes it possible that the users can get access to the encrypted data and decrypt the data only if the access structures match attributes.Same as the originally proposed ABE scheme in [13], the most classic architecture of ABE access control schemes apply a single central authority to take charge of enrolling, updating all attributes and managing keys for all entities. In such centralized ABE frameworks, the most difficult but important part is to achieve efficient revocation for users and attributes. In [32], the authors put forward an expiration time for each attribute to maintain revocation but it turns out having issues in backward and forward. The authors from [33, 34] succeed in overcoming the above issues through adopting the concept of proxy-based re-encryption. Also, lazy revocation [33, 35] and revocable-storage ABE [36] are designed to achieve revocation to prevent the message from unauthorized users.As the IoT networks expand, the centralized ABE paradigm with only one single authority has a great drawback in efficiency due to the super large amount of data. Therefore, multiauthority ABE was introduced by [37], in which a global identifier was assigned by the central authority to each user as a unique ID, aiming to distinguish users without attributes by independent authorities. Furthermore, more works such as [38–40] improve the above scheme by cancelling the user’s consistent GID to avoid privacy leakage and support collusion resistance; this paradigm is called as decentralized ABE.No matter in a centralized or decentralized ABE paradigm, a user may not withstand the financial attempt and share his attributes to other users. In order to avoid a decryption privilege leakage, works in [41, 42] provide access control schemes with traceability, where the user who leaks the decryption key to someone else can be traced and revoked by the system. As people become more concerned about personal privacy, the access policy itself can be taken as sensitive information and need to be protected from unauthorized users. Works in [43] achieve anonymity by designing three protocols together with homomorphic encryption and scrambled circuit evaluation to protect both the policies and the credentials.


## 7.3. Searchable Encryption with ABE in Cloud Computing Paradigm

The searchable encryption was firstly proposed by [44] and has been widely researched and used. It has indicated a new direction for operating searching on ciphertexts in cloud computing [45]. Both the notion of symmetric encryption with keyword search (SESK) and the public key encryption with keyword search (PESK) are gaining a lot of attentions. They have been developed to support different functions, such as works in [18, 46–51]. However, these schemes cannot achieve fine-grained access control on ciphertexts.The attribute-based keyword search (ABKS) was proposed in [52], in which the cloud server checks whether the user has the capability to decrypt the required encrypted ciphertext before searching it by a signature built from the user’s attributes. But this scheme cannot maintain the security of keywords. Some other works also proposed different schemes based on ABKS to support specific functions such as Checkability [19], fuzzy keyword search [53], revocation [54], and verifiability [55]. But most of these works require the users to do complex computation like pairing and exponential operations many times, which is not practical because of the user’s limited computation ability. Therefore, how to transfer the heavy computation burden and reduce the times of complex computation operations without loosing security requirements is the most important challenge for now.


## 8. Conclusion

In this paper, we design a keyword searchable encryption with fine gained access control for our proposed healthcare related IoT-fog-cloud framework. Through our design, the users could achieve a fast and efficient service by reducing the calculation overload and storage with the help of the fog and cloud, especially the data user only needs to do a exponential operation to retrieve the message. In our scheme, the fogs are capable of helping the trusted authority to manage the users and their attributes through authoring their query keys. In addition, our scheme is very efficient because only the authorized users could download the keyword-matched-part of ciphertexts by refusing unauthorized research and unauthorized users. At last, our scheme is proofed IND-CK-CCA secure and trapdoor indistinguishably secure. We also show our scheme takes less storage and transmission consumption and much less computational cost through theoretical analysis and experimental evaluations.We assume fogs and the cloud do not collude with each other in this paper; next we will consider in achieving the collusion resistance in our proposed IoT-Fog-Cloud system. We are also interested in the user update and the attribute replacement with a more efficient method in our future research. How to improve the efficiency of searching process by designing better structures of indexes and trapdoors for the keywords in the cloud server is also in our future consideration.



---

*Source: 1019767-2019-05-23.xml*