Abstract
The collection and sharing of electronic health records (EHRs) via the Internet of Things (IoT) can enhance the accuracy of disease diagnosis. However, it is challenging to guarantee the secure search of EHR during the sharing process. The advent of blockchain is a promising solution to address the issues, owing to its remarkable features such as immutability and anonymity. In this paper, we propose a novel blockchain-based secure sharing system over searchable encryption and hidden data structure via IoT devices. EHR ciphertexts of data owners are stored in the interplanetary file system (IPFS). A user with proper access permissions can search for the desired data with the data owner’s time-bound authorization and verify the authenticity of the search result. After that, the data user can access the relevant EHR ciphertext from IPFS using a symmetric key. The scheme jointly uses searchable encryption and smart contract to realize secure search, time control, verifiable keyword search, fast search, and forward privacy in IoT scenarios. Performance analysis and proof demonstrate that the proposed protocol can satisfy the design goals. In addition, performance evaluation shows the high scalability and feasibility of the proposed scheme.
1. Introduction
Electronic health records (EHRs) are digital records that are the collection of patients’ health records. An increasing number of EHR data are collected from Internet of Things (IoT) devices, such as intelligent wearable devices and smart watches. The electronic health records are stored electronically in a digital format which is maintained by a hospital. EHRs are highly private and have great financial value. As a consequence, more and more researchers pay wide attention to the sharing of EHR via IoT devices in recent years [1, 2]. The sharing of EHR can help doctors effectively assess patients’ conditions and make correct disease diagnosis [3]. Moreover, it is beneficial to improve the quality of medical service [4].
Generally, data searching is the preliminary of data sharing. EHR searching via IoT devices brings the issues of security and privacy leakage. Firstly, protecting patients’ private and sensitive information from leaking is important during the process of EHR searching as it includes personal benefits and reputation [5]. Secondly, only authentic data can improve the precision of the treatments and disease research [6]. Furthermore, patients should automatically revoke user access rights to protect his/her sensitive information.
To preserve data privacy, a data owner generally encrypts medical data before uploading it to the cloud and the cloud performed the encrypted keyword queries by using searchable encryptions [7–9]. However, the encrypted data searching based on the cloud may bring a great challenge for revoking users’ access rights. Time-bound searchable encryption schemes were proposed to solve this issue [10, 11]. For dishonest behaviors of the cloud, a series of keyword-based verifiable searchable encryption schemes had been presented in [12, 13]. Even though these works combine different cryptographic algorithms and cloud computing for EHR sharing to realize data security, there are still some security threats. The cloud is a semitrusted center to store, manage, and share EHRs, which may turn to loss, abuse, and leakage of data [9, 14]. Due to the centralization characteristic of a cloud server, it will cause single-point failure if the cloud server is attacked or lacks monitoring.
Fortunately, blockchain technology is proposed to be an advantageous solution for addressing the above problems [15–17]. Blockchain is considered a distributed public ledger to store patients’ health records for sharing [18, 19]. It has significant features of immutability, decentralization, anonymity, transparency, and tamper resistance [20–22]. Search efficiency plays a key role in the blockchain. Blockchain-based searchable encryption had been proposed to support fast search [23]. Albeit blockchain-based searchable encryption for EHR sharing system is prospective, it still faces the following challenges:(1)How to realize data security with time-bound and verifiable secure search in blockchain via IoT devices?(2)How to guarantee that only eligible entities are authorized to access the EHR?(3)How to achieve a fast search without disclosing patients’ private information?
In order to tackle the abovementioned problems, we present a blockchain-based secure EHR sharing scheme with searchable encryption. It is tailor-made for IoT scenarios. In this work, an interplanetary file system (IPFS) [24] stores EHR ciphertext. All keywords with hidden star-like structures are encrypted and uploaded to the blockchain for ensuring data users quickly find out the intended EHR and protecting the security and privacy of the data. Besides, searchable encryption and smart contract are used to achieve that only eligible users are able to access health data after obtaining the data owner’s authorization.
The main contributions of the proposed scheme are summarized as follows:(i)We devise a novel framework that combines IPFS and blockchain to achieve a secure search for EHR sharing via IoT devices. The IPFS is used to store EHR ciphertext in a decentralized way. Blockchain is deployed to achieve data confidentiality and searchability.(ii)We propose a time-bound and verifiable secure search protocol. Time control helps the data owner automatically revoke the user’s access right and prevent the user from accessing future data. The verifiable encryption algorithm ensures that the search result is not falsified. The ciphertexts containing the same keyword have a hidden star-chain structure. The data user can send a trapdoor to the blockchain and then quickly find all matching files by the hidden star-chain structure during a limited time while prohibiting from predicting future states. In this way, search efficiency improves significantly.(iii)We design smart contracts to achieve secure search. Furthermore, we deploy the smart contracts on the Ethereum platform and conduct extensive evaluations to demonstrate the feasibility and performance of the proposed scheme.
The remainder of the paper is organized as follows: an overview of the related work is conducted in Section 2. Preliminaries of the proposed protocol are presented in Section 3. In Section 4, we propose the system architecture, threat model, and design goals. In Section 5, the proposed protocol is formed and discussed in detail. Then, the performance analysis and proof of our scheme are introduced in Section 6. Section 7 evaluates the performance of the proposed protocol through extensive simulations. Finally, Section 8 concludes this work.
2. Related Work
In this section, we introduce the most relevant research on searchable encryption schemes based on blockchain.
2.1. EHR Sharing
EHR sharing can help to improve the accuracy of diagnosis [3]. However, EHR sharing brings some problems including security and privacy preservation in the system. In order to prevent sensitive data from leakage, some EHR sharing schemes based on searchable encryption algorithms were presented in [25, 26]. Zhang et al. [25] proposed an identity-based authorized searchable encryption scheme (IBASE) to encrypt diagnostic data with patients in cloud-assisted eHealth information systems. This article achieved patient’s data sharing to different doctors. However, there exist multiple interactions between the patient and the doctor, which may reveal the patient’s private information and increase his/her computational burden. Attribute encryption could be introduced to fulfill these requirements. Eltayieb et al. [26] proposed an attribute-based signcryption scheme to provide secure data sharing in the cloud environment. Furthermore, the smart contract solved the problem of cloud storage such as returning wrong results as in the traditional cloud server.
The ongoing trends are integrating the cloud with health blockchain to achieve a variety of security goals [27–30]. As EHRs were fragmented across decentralized hospitals, which hindered data sharing and puts patients’ privacy at risk, [27] proposed a blockchain-based privacy-preserving data sharing for EHRs. In this article, the original EHRs were stored securely in the cloud and the indexes are reserved in a tamper-proof blockchain. Moreover, the zero-knowledge proof and the proxy reencryption technology provided strong privacy preservation in data sharing. In [28], the authors proposed a complete medical information system model based on blockchain technology, to realize the goal of safe storage and sharing of medical problems. This system designed an anonymous medical data sharing scheme based on cloud servers and proxy reencryption algorithm to improve the security of private medical data sharing. Zou et al. [29] proposed a blockchain-based medical data sharing and privacy-preserving eHealth system named SPChain. To achieve quick retrieval, they devised special keyblocks and microblocksfor patients to store their EHRs. A secure cloud-assisted eHealth system was proposed to protect outsourced EHRs from illegal modification using blockchain technology [30]. In this work, the EHRs were outsourced by authenticated participants. In order to ensure tamper-proofing, each operation on outsourcing EHRs was integrated into the public blockchain as a transaction.
2.2. Searchable Encryption
Searchable encryption plays an important role in EHR sharing. Searchable encryption can be classified into two categories: symmetric key encryption [31] and public key encryption [32]. Searchable encryption was first introduced by Song et al. [33]. It was also the first scheme that supported keyword searching for encrypted data. In recent years, some cloud-assisted schemes have been proposed for searchable encryption [34]. A privacy-preserving sharing scheme for patient health information was proposed, which made use of the searchable encryption technique with keyword rang search and multikeyword search [35]. Since the cloud is untrustworthy, this article [35] used a bloom filter and message authentication code to classify health information files, filter fake data, and check data integrity. In order to verify whether the cloud has faithfully executed the search operations, a multiuser verifiable searchable symmetric encryption was presented in [31]. Authorized users could search data and verify the authenticity of the search result to improve the accuracy of the result. Since authorized users’ access rights are always valid, it is insecure.
In order to automatically revoke a user’s access right, a time key was introduced in [36]. The key seal was encapsulated in the ciphertext at the very beginning of the encryption. It implied that all users including data owner were constrained by the time period. Later, Yang and Ma [37] proposed a conjunctive keyword search with a designated tester and timing-enabled proxy reencryption function. It utilized a time server to generate a time token for the users. Moreover, it achieved time-controlled access right revocation to prevent authorized users from accessing the future EHR. The author [38] proposed a timed-release computational secret sharing and threshold encryption. This article used a time-release function instead of a time server to reduce overhead. The ongoing work [39] proposed 0-encoding and 1-encoding to generate the time key. However, these works had low search efficiency.
In order to improve the search efficiency, some schemes with hidden data structures were proposed in [23, 40, 41]. Users desired to find out more ciphertexts in one step. However, the scheme in [41] reduced the number of computation-intensive operations without searching for at least two matching ciphertexts in only one step. This work could not fulfill the need for a fast search. It could not prevent authorized users from accessing future data [40]. The scheme [23] did not consider dynamically revoking users’ access rights.
Although all the above works realized search based on cloud technology, there is still a challenge: the cloud is not a completely trusted center that may collude with other entities to get the users’ private information.
2.3. Searchable Blockchain
In order to address the above problems, some schemes adopted blockchain technology to achieve secure search [42, 43] due to its following advantages: decentralization, privacy preservation, immutability, fault tolerance, and the ability to implement smart contracts.
Due to the advantage of unforgeability, a smart contract cannot be modified or altered once it is deployed on blockchain [44]. The authors [45] proposed a blockchain-based searchable encryption scheme for EHR sharing, and used the complex Boolean expression to extract EHRs to construct the indexes. They designed smart contracts in blockchain to replace the centralized server for protecting users’ sensitive information. Zheng et al. [46] utilized blockchain and sampling techniques with attributed-based encryption to realize fair outsourced decryption. Moreover, the work used smart contracts in blockchain to ensure that the proxy could always get the reward with the valid outsourced decryption.
Public key encryption with a keyword search scheme based on blockchain was presented in [47]. It employed multiple key servers to encrypt keywords for resisting off-line keyword guess attacks. Cai et al. [48] utilized hashing technique and searchable encryption algorithm with the assistance of blockchain to achieve secure search on-chain task-matching authorization. Their scheme reduced query communication overhead and storage overhead on the blockchain. Jiang et al. [49] introduced a blockchain-based architecture called SearchChain, a peer-to-peer keyword search system. It supported encrypted retrieval over an authorized keyword set while accessing a user to search his/her desired data and hiding the retrieval privacy in the decentralized environment. In order to reduce computation complexity and improve search efficiency, a blockchain-based searchable public key encryption scheme with forward and backward privacy was presented in [23]. The hidden data structure was used to achieve forward and backward privacy. They utilized smart contracts to guarantee that search results were correct and immutable. However, these works did not automatically revoke the user’s access right and verify the authenticity of the search result.
The existing works proposed various blockchain-based searchable encryption schemes with security and privacy preservation. Actually, some schemes presented a concept or structure for a blockchain-based EHR sharing scheme without proposing a detailed solution to a specific application scenario. In this work, we propose a novel blockchain-based framework for EHR sharing by using searchable encryption and distributed storage technology to achieve privacy preservation and data security. Besides, we design the detailed protocol and implement smart contracts on the Ethereum test platform.
3. Preliminaries
We present the required preliminaries of this work in this section.
3.1. Complexity Assumptions
Definition 1. elliptic curve discrete logarithm problem (ECDLP)). Suppose is an elliptic curve, and are two primitive elements. Given the number of points on the curve, the is getting the integer to satisfy as follows:In cryptosystems, the integer is usually used as the private key and a point on the curve with coordinates is used as the public key . . Suppose that it is difficult to solve the in polynomial time.
Definition 2. Computational bilinear Diffie–Hellman (CBDH) problem. We denote an elliptic curve as and consider a cycling group of prime order . Let be a random element in and . The CBDH problem is defined as follows: given an input tuple, , and was computed. Assuming that an attacker can calculate with the advantage , If the CBDH assumption holds, the advantage must be ignored.
3.2. 0-Encoding and 1-Encoding
0-encoding and 1-encoding are two types of encoding. They are used to turn the “greater than” problem into a “set intersection” problem [50]. In order to avoid duplication, more details of the two encodings can be seen in [51]. We only introduce some results of the algorithms.
Let be an -bit binary string, where denotes the -th bit of . Keyword search authorization and keyword generation time are encoded in a binary string in our work. A 0-encoding of is denoted by , defined as follows:
.
A 1-encoding of is denoted by , defined as follows:
.
From the theorem in [51], we have if and only if and have a common element.
3.3. Forward Privacy
Forward privacy [52] requires that the previous search trapdoors do not search for the new updated files. An update query leaks no information about the keywords searched in the past. If a searchable encryption scheme has not forward privacy, a search token can be used to retrieve documents added after the token is issued. There will exist some attacks or data abuse (e.g., malicious users or servers may deduce keywords from this trapdoor). Thus, forward privacy is able to address the above issues. In our scheme, we utilize forward privacy to protect users’ private information and prevent searching for future data using the previous trapdoor.
4. System Model
This section first proposes a general system architecture based on the searchable blockchain via IoT devices. On this basis, we highlight the threats model and security objectives.
4.1. System Architecture
A general searchable blockchain is composed of a data owner, data user, and blockchain network, as shown in Figure 1.
4.1.1. Data Owner (DO)
Data owners contain patients who generate health records by interacting with doctors or obtaining data from smart devices, such as wearable devices and smart watches. Health records may draw interest from other institutions or companies. To protect their privacy and data security, data owners will encrypt their original data and send them to IPFS. Furthermore, the corresponding keywords and file identifiers with hidden data structures are encrypted and then formed into encrypted states. The data owners upload the encrypted states to the blockchain for searching and sharing, which will help patients to improve the accuracy of disease diagnosis. Only the data owner can authorize a data user to search for the intended keywords and decrypt the ciphertext.
4.1.2. Data User (DU)
Data users include medical institutions or insurance companies who want to access patients’ health records. They can search for intended keywords on the blockchain. They first need to send a search request to the data owner and get a search authorization token. Then, the DU generates a search trapdoor using his/her public key and token. After that, they call the search smart contract on the blockchain for searching. The results are sent to data users, who will verify the results by using the proof in the search authorization token. If the responses are true, the data user can access the data owners’ data.
4.1.3. Blockchain Network
IPFS is used to store EHR ciphertext and return the corresponding file addressees to DO. In the blockchain, different entities have different access rights. Only authorized data users can use the trapdoor to search for desired data in the blockchain. The search transactions are packed into blocks. A smart contract is composed of data and code, which is an automatically executed script. We deploy a search smart contract in the proposed blockchain. Search smart contract helps authorized data users quickly find out all the matching keywords with hidden star-like structures.
4.2. Threat Model and Design Goals
In our scheme, all participating users honestly perform protocols and smart contracts. However, they are curious to obtain others’ private information from encrypted states. Some malicious attackers may forge and modify the data during the transmissions. A revoked data user may attempt to search for encrypted states and access medical data. Based on the system model and threats, our scheme is designed to realize the following goals.
4.2.1. Secure Search
In this system, only authorized data user is allowed to search for the desired keyword or access the data owner’s health records. The adversary cannot guess any private information from the search trapdoor. They cannot distinguish the encrypted keywords from the given keywords in the trapdoor.
4.2.2. Time Control
After obtaining a search token from a data owner, the eligible data user can search the intended file indexes and health records. Nevertheless, data users cannot utilize the same search trapdoor to access the data owner’s future data. That is to say, a keyword search using a search token is time-bound.
4.2.3. Verifiable Search
Data users should be able to verify the correctness of the search results from the blockchain. The verification should be based on proof generated by the data owner. After passing the verification, the data user can access the requested data.
4.2.4. Fast Search and Forward Privacy
When the DU obtains the time-controlled authorization token from DO, he/she can generate a search trapdoor to fast search for all intended data by the hidden data structure in the smart contract. The attacker cannot utilize an old trapdoor to do some operations, such as searching for future updated files, testing the future updated files, and obtaining any other information about the future updated files. It means the old trapdoor is outdated.
5. The Proposed Protocol
In this section, we introduce the proposed protocol in detail.
5.1. Workflow
The data owner of a file (identified with ) extracts a keyword for the file. It sets two secret keys and for the keyword (the data owner sets the same keys k1 and k2 for the keyword w even though it may be extracted from different files at a different time). We suppose that the EHR and keyword generation time is . The data owner sends EHR ciphertext with a symmetric key and uploads it to IPFS. The data owner computes as , encrypts , , and with , , and into a state ciphertext , and uploads the encrypted state to the blockchain. All the state ciphertexts generated by different data owners at different times formulate the state ciphertexts . If a data user with a public key wants to search for a state containing a keyword from the file collection of a data owner, the data user sends a search request to the data owner. The data owner will generate a keyword search authorization token for this data user. In this token , the data owner assigns a valid time for searching operations. Additionally, the data owner generates a proof for the verification of search results. The data user can generate a search trapdoor with the authorization token and its secret key. The data user with the trapdoor calls for search smart contract to fast search for the intended keywords from set II stored on the blockchain. The data user can verify the correctness of the search result with its secret key and proof . If the search result is valid, the data owner will send the encrypted symmetric key the to blockchain, and the data user will obtain the original EHR with the symmetric key . The proposed protocol construction is presented below. The major notations used in the proposed protocol are listed in Table 1. The detailed process of the proposed protocol is shown in Figure 2.
5.1.1. Phase 1: System Setup
Given the system parameter , let be groups of a -bit prime order . is a generator of . is a bilinear map. Let , , , , , , and . The system chooses two random elements and computes , . Let be a pseudorandom permutation (e.g., DES, AES), denoted as . is the inverse permutation of . The and are symmetric encryption algorithms and the corresponding decryption algorithm (e.g., AES), respectively.
The system parameter is . Furthermore, an empty map is initialized, denoted as . The DO secretly stores the map.
5.1.2. Phase 2: KeyGen
A data user randomly chooses and computes . The public and private key pair for is and . A data owner randomly chooses and computes . The public and private key pair for is and .
5.1.3. Phase 3: Data Generation
(1) EHR ciphertext generation: the DO selects a symmetric key randomly and executes the algorithm to generate the EHR ciphertext . Then, he/she uploads to IPFS and obtains a hash address for each file.
(2) State ciphertext generation: the DO chooses a set of file identifiers containing the keyword , where . Then, the DO performs Algorithm 1 to generate state ciphertext containing the keyword . Then, the DO sends to the blockchain. The ciphertexts that contain the same keyword have a hidden relationship as shown in Figure 3. The state contains ciphertexts. By using a pseudorandom permutation and a key , the next state is equal to . The state has ciphertexts. If the DU wants to access desired data, he/she will generate a trapdoor. The trapdoor is considered a pointer. It points to a current state and fast searches for ciphertexts containing the same keyword in a limited time. It also can improve search efficiency.
|
5.1.4. Phase 4: Data Request
Time control means the DO controls the access time of the DU. That is to say, time control enables that the search trapdoor is valid before the authorized access time. In order to realize time control, we use 0-encoding and 1-encoding. In this system, the current time is (authorization trapdoor time) which can be expressed as an integer. For example, the current time is “Jul. 04” which can be denoted as “.” needs to be converted to the binary string “” in the format of 1-encoding. We have . We assume the data generation time is yesterday “Jul. 03” denoted as “.” also needs to be converted to the binary string “” in the format of 0-encoding. We have . We find “,” there is a common element “1011” in both sets. We assume the current time is . The DU performs the following operations: .
(1) Token Generation. when the DU wants to access the DO’s EHR, he/she will send a request to the DO. Then, the DO generates a time-bound keyword authorization token for the DU. It has the property, if he/she also generates a proof of keyword for the verification of the search result by executing Algorithm 2. The DO sends a token to the DU and proof to the blockchain, respectively.
|
(2) Trapdoor Generation. after getting the DO’s authorization token, the DU will generate a search trapdoor with the public key and a token . The search trapdoor is calculated as follows: , . The trapdoor is sent to the blockchain for searching the desired data.
5.1.5. Phase 5: Data Access
(1) Search. the DU designs a smart contract to securely search the intended index in Algorithm 3. The DU extracts from the trapdoor . For each state ciphertext , the search smart contract performs the following operations:(i)It extracts from . If , it computes and .(ii)It finds the integer which satisfies . It checks whether If the equation does not hold, it aborts. Otherwise, it obtains an encrypted keyword and adds into the set .(iii)It computes .(1)It computes , then retrieves , and adds into .(2)If , it terminates this algorithm. Otherwise, it obtains state information.(3)It computes and obtains , where , and adds into . If , it returns to the DS.(4)For to 1, it computes , , obtains index , and adds into .(5)It computes , sets , and goes to step 1.(iv)If , it aborts.
|
(2) Verify. he DU obtains search results from the blockchain and verifies whether it is valid by performing Algorithm 4.
|
(3) Symmetric Key Ciphertext Generation. after DU sends a valid verification result to the blockchain, the DO will encrypt the symmetric key under DU’s public key . The generated symmetric key ciphertext is uploaded to the blockchain. When the DU accesses the desired data, he/she will decrypt it with a symmetric key. The symmetric key ciphertext is calculated as follows: , . Then, the DO sends the symmetric key ciphertext to the blockchain.
(4) Decryption. the DU obtains the EHR ciphertext from IPFS using the file address . The symmetric key is calculated as follows: it computes , . The DU uses the symmetric key to get the original EHR by computing .
6. Performance Analysis and Proof
In this section, we analyze how the proposed scheme achieves the design goals.
6.1. Secure Search
Secure search means that an adversary cannot distinguish the keyword from the keyword ciphertext or search trapdoor. The proposed protocol is secure in the random oracle model assuming the CBDH assumption holds. According to the security game in [23], the security proof is as follows.
Proof. The random oracles of algorithm encryption and trapdoor are and , respectively. Suppose is an attacker who has the advantage to attack the proposed chosen-plaintext attack game. We build a challenger . He/she plays a game with to compute the solution to the CBDH problem as follows:(i)Setup: given the CBDH parameters is computed. The challenge randomly chooses and computes and . and are secretly stored by DO and DU, respectively. Then, it sends the system parameter , the DO’s public key , and the DU’s public key . queries: maintains a list of tuples called for responding to the queries of . makes at most hash function queries to . receives the queries and responds as follows:(1)If the queries are already in , responds . Otherwise, it generates a random so that , where .(2)If , randomly picks a number and computes . Otherwise, it sets .(3) adds the tuples into and returns to . queries: queries are similar to the queries. Given an element , returns a random string and adds into .(ii)Phase 1: makes some queries. Encryption queries: queries the keyword to get encrypted file indexes. responds as follows:(1) performs the aforementioned algorithms to respond and queries to get two lists and .(2) chooses instead of computing . Furthermore, sends the encrypted data , to and adds the tuple into the lists and secretly.(3)If , computes and queries to get the value , where is to generate the version . returns to , where is retrieved by from the map .(4)Otherwise, it will report failure and end up. Trapdoor queries: queries the keyword to obtain a trapdoor. responds as follows:(1) performs the aforementioned algorithms to respond queries to get the list .(2)If , retrieves and computes . Then, returns the trapdoor to .(3)Otherwise, it will report failure and end up.(iii)Challenge: outputs two keyword-file pairs and . Then, he/she sends them to . executes as follows:(1) performs the aforementioned algorithms to respond queries to obtain the list .(2) runs the queries to get and . If and are both equal to 0, then will report failure and end up.(3) randomly chooses a bit . performs encryption queries and maintains the tuple. The tuple denotes the latest state containing the keyword .(4) computes , where , .(iv)Phase 2: the phase is the same as Phase 1. The restriction is that the adversary cannot distinguish and .(v)Guess: returns a guess . selects a random pair from the . Then, he/she returns which is its guess for the CBDH problem. In addition, uses and in the challenge phase. Because must make a query for either or , its probability is . From the , can obtain and . Then, outputs as its guess.In the guessing phase, if the challenger can succeed in encryption queries and trapdoor queries at the same time, the probability is . Due to , the probability that the challenger does not abort during the game is greater than , where is the base of the natural logarithm. In the challenge phase, if , its probability is . So, must have probability at least in the challenge phase. In the guessing phase, has the same probability to make queries with element and . has a probability of greater than to choose correctly. Thus, the challenger has the advantage that , where .
6.2. Time Control
The keyword ciphertext is encrypted by DO’s public key. The eligible user can get a time-bound keyword search authorization trapdoor to search for a target keyword. As described in phase 5 of the protocol, we use 0-encoding and 1-encoding to get a time-bound trapdoor for controlling the access permission of the data user in a limited time. It finds the integer , which can meet . Especially, it checks whether holds if trapdoor authorization time . If the equation holds, the data user will find the desired data. The eligible data user is allowed to find the records of the data owner generated before the authorization time. Thus, other users cannot obtain any effective information during the process of keyword search.
6.3. Verifiable Search
In phase 3 of the protocol, the EHR ciphertext stored in IPFS is encrypted with the data owner’s symmetric key. The corresponding keywords from the EHR are encrypted by DO’s public key. In phase 4 of the protocol, the eligible users can get a search trapdoor from DO. He/she also gets a proof for the verification of search results. We recall that in proof , the term includes the public key of the authorized data user. Therefore, the search result is only verified by the data user. In phase 5 of the protocol, when an eligible user sends a trapdoor to the search smart contract in the blockchain, he/she will obtain a search result. The search result can be verified by the eligible user who checks . If the result of the verification is valid, the eligible user will decrypt the EHR ciphertext by obtaining the symmetric key. In this way, a verifiable search can be achieved.
6.4. Fast Search and Forward Privacy
In order to avoid repeatability, we refer to more details about forward privacy in [52]. We will only introduce a simple description here. In our proposed scheme, a DO maintains a state for each keyword . If a new file identifier containing the keyword is added to the system, the DO will update and send it to the blockchain. In order to better understand fast search and forward privacy, we give a sample, as shown in Figure 4. There exists four states: . is the initial state without ciphertext. The DO encrypts using a key to obtain the next state . is linked to ciphertext, ciphertext, and ciphertext with the same keyword . Then, the DO utilizes and a key to get the next state . has three ciphertexts containing the same keyword . Similarly, the DO obtains which also has three ciphertexts. The DO uploads all encrypted states to the blockchain. When the DU wants to access intended data, he/she sends a trapdoor to the blockchain. The trapdoor is a pointer to point to the current state . Search smart contract computers and and obtains the state . Then, search smart contract can contain three indexes of the state and use a secret key to decrypt the state ciphertext (, ). Then, the smart contract starts two threads. One is responsible to find the previous state . Another one is responsible to search the indexes corresponding to the state by computing respectively. By repeating the above process, search smart contracts can find out all matching indexes quickly. From the above process, we know that the trapdoor as a pointer points to the latest state. The hidden star-like structure and smart contract improve search efficiency. Thus, it achieves fast search. In our scheme, the adversary cannot use the current state and other information to obtain the future state by the pseudorandom permutation . Thus, the old trapdoor cannot be used to search for future updated data. Forward privacy can be achieved.
7. Implementation and Evaluation
In this section, we utilize Java programming language and JPBC library to execute the proposed algorithms. We deploy the designed smart contract on the Ethereum test platform. Firstly, we give some parameter settings and platforms. Then, we compare security properties with other schemes. Furthermore, the communication and computational costs of our protocol are analyzed. Finally, we evaluate the performance of the smart contract on the blockchain.
7.1. Parameter Settings and Platform
The system security parameter is denoted as . We use type A pairing on the elliptic curve over the field for some prime . We implement the cryptographic primitives by using JPBC library and Java on a laptop computer with Intel (R) Core (TM) i5-7400 CPU @3.00 GHz, 8 GB RAM, and Microsoft Windows 10 operating system. Additionally, Ganache (client version) is used to build a local test chain on a Linux system. Smart contract framework and solidity compilers are truffle @0.5.0 and sold @0.5.0, respectively. We utilize solidity language to write the data into a smart contract and then upload them to the blockchain. NodeJS’s Web3js library interacting with smart contracts on the blockchain is achieved to directly obtain the time cost of sending a transaction. Due to the limited space, the detailed deployment process is skipped.
7.2. Comparisons of Security Properties
We compare the security properties of the proposed scheme with other works by Che et al. [23], Xu et al. [41], and Hu et al. [53] in Table 2. From Table 2, we conclude that our scheme achieves a verifiable search. Notably, some of the schemes have the properties of forward privacy and secure search, which are important security goals in EHR sharing systems. The comparison result shows that our proposed scheme can provide a promising solution to keyword search services.
7.3. Communication Overhead
The size of EHR data, an element in , , and are denoted by and bytes ,respectively. The hash address in IPFS is 46 bytes. The communication overhead includes five phases: data storage, data broadcast, search, data verification, and data access. In the data storage phase, DO sends EHR ciphertext to IPFS for storage and the length is bytes. Then, IPFS sends to DO, where the length is bytes. Additionally, DO broadcasts , , and to the blockchain. The total length is bytes, where is the amount of files containing the keyword. DU searches the data, the generated communication overhead is bytes during the process of data search. DU verifies the authenticity of the search result, the generated communication cost is bytes in the data verification phase. At the data access phase, the generated communication cost is bytes, which is caused by and . The communication cost is shown in Table 3.
We compare our communication cost with other two works Chen et al. [23] and Xu et al. [41], in which the amount of keyword is denoted by . As can be observed in Table 3, our scheme in the process of data broadcast is higher communication overhead as compared to Xu et al. [41]. Chen et al.’s [23] scheme in the process of data access has a higher communication cost than our scheme. Nevertheless, in the process of search, our communication cost of the process of data search is lower.
7.4. Computational Cost
We compare the computational overhead in Table 4. The algorithm SystemInit simulates the system initialization phase. A DO generates state ciphertext containing the keyword in StateCipGen. As for a DU, the algorithm Trapdoor generates a search token for him/her. The matching test of state ciphertext and trapdoor is executed in the Search algorithm. The DU receives the matching result and verifies its validity. Then, the DO generates symmetric key ciphertext performed by SymkeyGen. Finally, the symmetric key ciphertext is decrypted in the Dec algorithm.
As shown in Table 4, we implement the algorithms with file amounts 10, 50, and 100, respectively. We observe that the amount of files affects the computational cost of StateCipGen and Trapdoor algorithms, because these algorithms contain file sets. However, other algorithms are not affected by file sets.
Besides, the comparison of computational cost is depicted in Figure 5. The result shows that our scheme becomes increasingly efficient than Chen et al. [23] scheme with the increasing amount of files. The proposed scheme is higher than the Xu et al. [41] scheme in terms of computational costs. This is because the proposed scheme has many cryptographic algorithms related to the amount of files. Xu et al.’s [41] scheme has only one pairing operation and a few cryptographic algorithms related to the amount of files, so the computational cost of Xu et al.’s [41] scheme is the smallest one of the three. In order to better show the results, we plotted the computation cost of each algorithm with the amount of files , as shown in Figure 6.
(a)
(b)
(c)
(d)
(e)
(f)
(g)
Figure 6(a) indicates the computational cost taken by the system init algorithm of the proposed and other related works Chen et al. [23] scheme and Xu et al. [41] scheme. The system init computational cost for all the schemes changes linearly with the amount of files . Figure 6(b) shows the computational cost of the data generation algorithm from the data owner. We can observe that it also increases linearly with the amount of files , and Chen et al.’s [23] scheme has a higher computational cost compared to Xu et al.’s [41] scheme and the proposed scheme. Xu et al.’s [41] scheme is the smallest computational cost of the three. Because it has only one pairing operation, the computational cost of the data generation has hardly changed. Figure 6(c) shows the computational cost of the trapdoor generation algorithm from the data user. As can be observed from Figure 6(c), it also changes linearly with the amount of files , and our scheme and Chen et al.’s [23] scheme have higher computational costs as compared to Xu et al.’s [41] scheme. Figure 6(d) presents the computational cost of the search algorithm at blockchain. It also varies linearly with the amount of files , and Chen et al.’s [23] scheme has a higher computational cost compared to Xu et al.’s [41] scheme and the proposed scheme. Because the proposed search algorithm is achieved by smart contract in a limited time, the computational cost of the search is almost unchanged.
Figure 6(e) presents the computational cost of verifying algorithm from the data user. As can be observed the Figure 6(e), the verify algorithm for the proposed scheme varies linearly with the amount of files , while the other two schemes are constant. In the proposed scheme, he/she needs to verify the authenticity of the search result when the data user receives the search result from the blockchain. Figure 6(f) indicates the computational cost taken by the symmetric key algorithm at the data owner’s end. From Figure 6(f), we observe that our scheme about the computational cost is higher than other schemes. This is because only when the data user obtains the right search result, he/she can get the encrypted symmetric key from the data owner. Figure 6(g) shows the computational cost taken by the decryption algorithm at the data user’s end. From Figure 6(g), we can see that the computational cost of our scheme and Xu et al.’s [41] scheme are constant, while Chen et al. [23] scheme has a higher computational cost compared to Xu et al.’s [41] scheme and the proposed scheme, because Chen et al.’s [23] scheme has more hash operations and keywords.
7.5. Time Consumption Evaluation
The time consumption of sending a transaction to the blockchain is related to the length of the data package. According to the section computational cost, we know that the length of state ciphertext is bytes and data access is bytes. The , , , and are 64 bytes, 32 bytes, 32 bytes, and 32 bytes, respectively. So, the size of two transactions is bytes and bytes, respectively. Because files amounts affects the , we set , , and to implement the transactions on the Ethereum platform.
As can be seen from Table 5, the time consumption is related to a transaction’s length for publishing a transaction in the blockchain. If the amount of files set is large, it will affect the speed of the transactions. In addition, a transaction’s length also affects gas consumption.
8. Summary and Future Work
In this work, we present a blockchain-based EHR sharing scheme via IoT devices that combines searchable encryption and IPFS to realize the storage and sharing of EHR. The proposed scheme also realizes a time-bound and verifiable secure search mechanism with eligible users in the blockchain. Firstly, we propose an EHR sharing framework among multiple users. Secondly, we use searchable encryption and smart contract to ensure data confidentiality and employ a hidden star-chain structure to achieve fast search and forward private. Then, the performance analysis and proof of the proposed protocol testifies the achievement of design objectives. Furthermore, we also evaluate the performance of communication overhead and computational cost of the proposed protocol compared to other schemes.
Future work under progress is that we lay more focus on lightweight and dynamic searchable encryption schemes. In addition, we also plan to integrate federated learning [54], edge computing [55, 56], and IoT [57] in this scenario to better enhance privacy protection.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported in part by the National Natural Science Foundation of China under grant 62072005, in part by the Natural Science Foundation of Anhui Province under grant 2108085Y22, and Anhui Provincial Engineering Laboratory on Information Fusion and Control of Intelligent Rabot (grant no. IFCIR2020008).