Time-Enabled and Verifiable Secure Search for Blockchain-Empowered Electronic Health Record Sharing in IoT

,


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 Tings (IoT) devices, such as intelligent wearable devices and smart watches. Te electronic health records are stored electronically in a digital format which is maintained by a hospital. EHRs are highly private and have great fnancial value. As a consequence, more and more researchers pay wide attention to the sharing of EHR via IoT devices in recent years [1,2]. Te sharing of EHR can help doctors efectively assess patients' conditions and make correct disease diagnosis [3]. Moreover, it is benefcial 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 benefts 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][8][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 keywordbased verifable searchable encryption schemes had been presented in [12,13]. Even though these works combine diferent cryptographic algorithms and cloud computing for EHR sharing to realize data security, there are still some security threats. Te 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][16][17]. Blockchain is considered a distributed public ledger to store patients' health records for sharing [18,19]. It has signifcant features of immutability, decentralization, anonymity, transparency, and tamper resistance [20][21][22]. Search efciency plays a key role in the blockchain. Blockchainbased 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 verifable 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 fle 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 fnd 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.
Te 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. Te IPFS is used to store EHR ciphertext in a decentralized way. Blockchain is deployed to achieve data confdentiality and searchability.
(ii) We propose a time-bound and verifable secure search protocol. Time control helps the data owner automatically revoke the user's access right and prevent the user from accessing future data. Te verifable encryption algorithm ensures that the search result is not falsifed. Te ciphertexts containing the same keyword have a hidden starchain structure. Te data user can send a trapdoor to the blockchain and then quickly fnd all matching fles by the hidden star-chain structure during a limited time while prohibiting from predicting future states. In this way, search efciency improves signifcantly.
(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.
Te 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. Ten, 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.

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. Tis article achieved patient's data sharing to diferent 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 fulfll 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.
Te ongoing trends are integrating the cloud with health blockchain to achieve a variety of security goals [27][28][29][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. Tis 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 cloudassisted eHealth system was proposed to protect outsourced EHRs from illegal modifcation using blockchain technology [30]. In this work, the EHRs were outsourced by authenticated participants. In order to ensure tamper-proofng, each operation on outsourcing EHRs was integrated into the public blockchain as a transaction.

Searchable Encryption.
Searchable encryption plays an important role in EHR sharing. Searchable encryption can be classifed into two categories: symmetric key encryption [31] and public key encryption [32]. Searchable encryption was frst introduced by Song et al. [33]. It was also the frst 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 flter and message authentication code to classify health information fles, flter fake data, and check data integrity. In order to verify whether the cloud has faithfully executed the search operations, a multiuser verifable 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]. Te 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. Te author [38] proposed a timed-release computational secret sharing and threshold encryption. Tis article used a time-release function instead of a time server to reduce overhead. Te ongoing work [39] proposed 0encoding and 1-encoding to generate the time key. However, these works had low search efciency.
In order to improve the search efciency, some schemes with hidden data structures were proposed in [23,40,41]. Users desired to fnd 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. Tis work could not fulfll the need for a fast search. It could not prevent authorized users from accessing future data [40]. Te 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.

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 modifed or altered once it is deployed on blockchain [44]. Te authors [45] proposed a blockchainbased searchable encryption scheme for EHR sharing, and used the complex Boolean expression to extract EHRs to construct the indexes. Tey 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 ofline 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. Teir scheme reduced query communication overhead and storage overhead on the blockchain. Jiang et al. [49] introduced a blockchainbased 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 efciency, a blockchain-based searchable public key encryption scheme with forward and backward privacy was presented in [23]. Te hidden data structure was used to achieve forward and backward privacy. Tey 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.
Te existing works proposed various blockchainbased 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 specifc 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.

Preliminaries
We present the required preliminaries of this work in this section.

Complexity Assumptions
Defnition 1. elliptic curve discrete logarithm problem (ECDLP)). Suppose E is an elliptic curve, P and Q are two primitive elements. Given #E the number of points on the curve, the ECDLP is getting the integer d(1 ≤ d ≤ #E) to satisfy as follows: In cryptosystems, the integer d is usually used as the private key and a point on the curve with coordinates X � (x X , y X ) is used as the public key X. ECDLPAssumption . Suppose that it is difcult to solve the ECDLP in polynomial time.

Defnition 2.
Computational bilinear Dife-Hellman (CBDH) problem. We denote an elliptic curve as E and consider a cycling group G of prime order q. Let P be a random element in G and a, b, c ∈ Z * q . Te CBDH problem is defned as follows: given an input tuple, (P, aP, bP, cP) ∈ G, and e(P, P) abc was computed. Assuming that an attacker A can calculate e(P, P) abc with the advantage Adv CBDH A (1 λ ), If the CBDH assumption holds, the advantage Adv CBDH A (1 λ ) must be ignored.
3.2. 0-Encoding and 1-Encoding. 0-encoding and 1-encoding are two types of encoding. Tey 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 [1] be an l-bit binary string, where ε [i] denotes the i-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

Forward Privacy.
Forward privacy [52] requires that the previous search trapdoors do not search for the new updated fles. 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. Tere will exist some attacks or data abuse (e.g., malicious users or servers may deduce keywords from this trapdoor). Tus, 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.

System Model
Tis section frst proposes a general system architecture based on the searchable blockchain via IoT devices. On this basis, we highlight the threats model and security objectives.

System Architecture.
A general searchable blockchain is composed of a data owner, data user, and blockchain network, as shown in Figure 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 fle identifers with hidden data structures are encrypted and then formed into encrypted states. Te 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.

Data User (DU).
Data users include medical institutions or insurance companies who want to access patients' health records. Tey can search for intended keywords on the blockchain. Tey frst need to send a search request to the data owner and get a search authorization token. Ten, 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. Te 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.

Blockchain Network.
IPFS is used to store EHR ciphertext and return the corresponding fle addressees to DO. In the blockchain, diferent entities have diferent access rights. Only authorized data users can use the trapdoor to search for desired data in the blockchain. Te 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 fnd out all the matching keywords with hidden star-like structures.

Treat 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.

The Proposed Protocol
In this section, we introduce the proposed protocol in detail.

Workfow.
Te data owner of a fle (identifed with f i ) extracts a keyword w for the fle. It sets two secret keys k 1 and k 2 for the keyword w i (the data owner sets the same keys k 1 and k 2 for the keyword w even though it may be extracted from diferent fles at a diferent time). We suppose that the EHR and keyword generation time is t g . Te data owner sends EHR ciphertext with a symmetric key k and uploads it to IPFS. Te data owner computes t g as t gj j∈ [1,l] ←0 − ENC(t g ), encrypts w, F(w), and ST with k 1 , k 2 , and pk o into a state ciphertext I, and uploads the encrypted state I to the blockchain. All the state ciphertexts generated by diferent data owners at diferent times formulate the state ciphertexts II. If a data user with a public key pk i wants to search for a state containing a keyword w ′ from the fle collection of a data owner, the data user sends a search request to the data owner. Te data owner will generate a keyword search authorization token T 1 for this data user. In this token T 1 , the data owner assigns a valid time t a for searching operations. Additionally, the data owner generates a proof P f i for the verifcation of search results. Te data user can generate a search trapdoor T w with the authorization token and its secret key. Te data user with the trapdoor calls for search smart contract to fast search for the intended keywords from set II stored on the blockchain. Te data user can verify the correctness of the search result with its secret key and proof P f i . If the search result is valid, the data owner will send the encrypted symmetric key the C k to blockchain, and the data user will obtain the original EHR with the symmetric key k. Te proposed protocol construction is presented below. Te major notations used in the proposed protocol are listed in Table 1. Te detailed process of the proposed protocol is shown in Figure 2.
Te system chooses two random elements α, β ∈ Z * p and computes H � αP, T � βP. Let L be a pseudorandom permutation (e.g., DES, AES), denoted as is the inverse permutation of F. Te Enc(·) and Dec(·) are symmetric encryption algorithms and the corresponding decryption algorithm (e.g., AES), respectively.

Phase 3: Data Generation.
(1) EHR ciphertext generation: the DO selects a symmetric key k randomly and executes the algorithm Enc(·) to generate the EHR ciphertext C m � Enc k (m). Ten, he/she uploads C m to IPFS and obtains a hash address HA C m for each fle.
(2) State ciphertext generation: the DO chooses a set of fle identifers F(w) � (f 1 (w), . . . , f n (w)) containing the keyword w, where n � |F(w)|. Ten, the DO performs Algorithm 1 to generate state ciphertext containing the keyword I � (C w , D vw , I vi , E v w ). Ten, the DO sends I to the blockchain. Te ciphertexts that contain the same keyword have a hidden relationship as shown in Figure 3. Te state st c− 1 contains i ciphertexts. By using a pseudorandom permutation L and a key k c , the next state st c is equal to L(k c , st c− 1 ). Te state st c has i ciphertexts. If the DU wants to access desired data, he/she will generate a trapdoor. Te trapdoor is considered a pointer. It points to a current state st c and fast searches for i ciphertexts containing the same keyword in a limited time. It also can improve search efciency.

Phase 4: Data Request.
Time control means the DO controls the access time of the DU. Tat 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 t a (authorization trapdoor time) which can be expressed as an integer. For example, the current time is "Jul. 04" which can be denoted as "t a � 0704." t a needs to be converted to the binary string "t a � 1011000000" in the format of 1-encoding. We have . We assume the data generation time t g is yesterday "Jul. 03" denoted as "t g � 0703." t g also needs to be converted to the binary string "t g � 1010111111" in the format of 0-encoding. We We fnd "t a � 0704 > t g � 070," there is a common element "1011" in both sets. We assume the current time is t a . Te DU performs the following operations: T w � (T 1 , T 2 ).
(1) Token Generation. when the DU wants to access the DO's EHR, he/she will send a request to the DO. Ten, the DO generates a time-bound keyword authorization token T 1 for the DU. It has the property, if he/she also generates a proof   (2) Trapdoor Generation. after getting the DO's authorization token, the DU will generate a search trapdoor T w with the public key X i and a token T 1 . Te search trapdoor is calculated as follows: . Te trapdoor T w is sent to the blockchain for searching the desired data.

Phase 5: Data Access
(1) Search. the DU designs a smart contract to securely search the intended index in Algorithm 3. Te DU extracts t a from the trapdoor T w . For each state ciphertext I ∈ I, the search smart contract performs the following operations: (i) It extracts t g from I. If t g < t a , it computes t gj j∈ [1,l] ←0 − ENC(t g ) and t aj j∈ [1,l] ←1− ENC(t a ). (ii) It fnds the integer b which satisfes t ab � t gb . It checks whether If the equation does not hold, it aborts. Otherwise, it obtains an encrypted keyword C w and adds C w into the set S. (iii) It computes B � e(x i P, H 0 (w ′ )).
and goes to step 1.
(iv) If t g > t a , it aborts.
(2) Verify. he DU obtains search results from the blockchain and verifes whether it is valid by performing Algorithm 4.
(3) Symmetric Key Ciphertext Generation. after DU sends a valid verifcation result to the blockchain, the DO will encrypt the symmetric key k under DU's public key X i . Te 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. Te symmetric key ciphertext is calculated as follows: C k1 � ke(H, X i ), C k2 � αT. Ten, the DO sends the symmetric key ciphertext C k � (C k1 , C k2 ) to the blockchain.
(4) Decryption. the DU obtains the EHR ciphertext from IPFS using the fle address HA C m . Te symmetric key is calculated as follows: it computes D � (x i /β)P, k � C k 1 /e(C k 2 , D). Te DU uses the symmetric key k to get the original EHR by computing m � Dec k (C m ).

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 A cannot distinguish the keyword from the keyword ciphertext or search trapdoor. Te 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. Te random oracles of algorithm encryption and trapdoor are O E and O T , respectively. Suppose A is an Input: a set of fle identifers F(w) � (f 1 (w) . . . , f n (w)), keyword w, state map ST Output: state ciphertext I (1) Compute t gj j∈ [1,l] ←0 − ENC(t g ) (2) Randomly choose τ w ∈ Z * p and compute V c � τ w P ∈ G (3) Retrieve from ST[w] by w, obtain (st c , k c , c), and then sets st c ∈ 0, 1 { } * , k c ∈ 0, 1 { } * , and c � 0 (4) Compute k c+1 � L(y o , k c ) and st c+1 � F(k c+1 , st c ), update ST[w] � (st c+1 , k c+1 , c + 1) (5) For each t gj ∈ t gj j∈ [1,l] , compute v j � H 1 (k 1 , t gj , w) (6) Randomly choose r ∈ Z * p and compute V j � rv j P for each j ∈ [1, l], Z � rH 0 (w), attacker who has the advantage ε to attack the proposed chosen-plaintext attack game. We build a challenger C. He/ she plays a game with A to compute the solution to the CBDH problem as follows: (i) Setup: given the CBDH parameters (P, aP, bP, cP),e(P, P) abc is computed. Te challenge C randomly chooses a, b ∈ Z p and computes Y � aP and X � bP. a and b are secretly stored by DO and DU, respectively. Ten, it sends A the system parameter param � (G, G T , e, P, H 0 , H 2 , h 1 , h 2 , F, F − 1 ), the DO's public key pk o � aP, and the DU's public key pk i � bP. H 0 queries: C maintains a list of tuples (w i , h i , x w i , c i ) called H 0 − list for responding to the queries of H 0 . A makes at most q H 0 hash function queries to H 0 . C receives the queries and responds as follows: (2) If c i � 0, C randomly picks a number x w i ∈ Z * q and computes h i � x w i P. Otherwise, it sets h i � x w i cP. Input: keyword w′ with two secret keys k 1 ′ and k 2 ′ , version information V c , Output: token T 1 , proof P f i (1) Set the keyword search authorization time t a and compute t aj j∈ [1,l] ←1 − ENC(t a ) (2) For each t aj ∈ t aj j∈ [1,l] , compute u j � H 1 (k 1 ′ , t aj , w′) Input: keywords ciphertexts set S, token T w , proof P f i Output: 1/0. (1) For each S ∈ S, the data user parses S � (C w , If the equation holds, it returns "1." Otherwise, it returns "0." ALGORITHM 4: Verifcation. 8 Security and Communication Networks Encryption queries: A queries the keyword (w i , F(w i )) to get encrypted fle indexes. C responds as follows: (1) C performs the aforementioned algorithms to respond H 0 and H 2 queries to get two lists F(sk o , k c ). Furthermore, C sends the encrypted data D vw , (I v i ) i�1,...,n to A and adds the tuple (4) Otherwise, it will report failure and end up.
Trapdoor queries: A queries the keyword w i to obtain a trapdoor. C responds as follows: (1) C performs the aforementioned algorithms to respond H 0 queries to get the list . Ten, C returns the trapdoor to A. (3) Otherwise, it will report failure and end up.
(iii) Challenge: A outputs two keyword-fle pairs (w 0 , F(w 0 )) and (w 1 , F(w 1 )). Ten, he/she sends them to C. C executes as follows: (1) C performs the aforementioned algorithms to respond H 0 queries to obtain the list (w i , h i , x w i , c i ).
(2) C runs the H 0 queries to get H 0 (w 0 ) and H 0 (w 1 ). If c i0 and c i1 are both equal to 0, then C will report failure and end up. (3) C randomly chooses a bit l ∈ 0, 1 { }. C performs encryption queries and maintains the tuple. Te tuple denotes the latest state containing the keyword w l .
. (iv) Phase 2: the phase is the same as Phase 1. Te restriction is that the adversary A cannot distinguish w 0 and w 1 . (v) Guess: A returns a guess l ′ ∈ 0, 1 { }. C selects a random pair (Q, E) from the H 2 − list. Ten, he/she returns Q/e(P, P) x w l τ w l which is its guess for the CBDH problem. In addition, C uses x w l and τ w l in the challenge phase. Because A must make a query for either H 2 (e(H 0 (w 0 ), Y o ) τ w 0 ) or H 2 (e(H 0 (w 1 ), Y o ) τ w 1 ), its probability is 1/2. From the H 0 − list, C can obtain Q � e(P, P) abcx l τ w l and E � H 2 (e(H 0 (w l ), Y o ) τ w l ). Ten, C outputs q/e(P, P) x w l τ w l as its guess.
In the guessing phase, if the challenger C can succeed in encryption queries and trapdoor queries at the same time, the probability is (1 − 1/q total1 + 1) q total1 . Due to (1 − 1/q total 1 + 1) q total 1 ≥ 1/e, the probability that the challenger C does not abort during the game is greater than 1/e, where e is the base of the natural logarithm. In the challenge phase, if c i 0 � c i1 � 0, its probability is (1 − (1/(q total1 + 1))) 2 ≤ 1 − (1/(q total1 + 1)). So, C must have probability 1/q total 1 at least in the challenge phase. In the guessing phase, A has the same probability to make H 2 queries with element e(P, P) abcx 0 τ w 0 and e(P, P) abcx 1 τ w 1 . C has a probability of greater than 1/2ε to choose Q � e(P, P) abcx l τ w l correctly. Tus, the challenger C has the advantage that Adv CBDH Te keyword ciphertext is encrypted by DO's public key. Te 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 0encoding and 1-encoding to get a time-bound trapdoor for controlling the access permission of the data user in a limited time. It fnds the integer b, which can meet t ab � t gb . Especially, it checks whether e(U b , Z) � e(V b , x i H 0 (w ′ )) holds if trapdoor authorization time t a > t g . If the equation holds, the data user will fnd the desired data. Te eligible data user is allowed to fnd the records of the data owner generated before the authorization time. Tus, other users cannot obtain any efective information during the process of keyword search.

Verifable Search.
In phase 3 of the protocol, the EHR ciphertext stored in IPFS is encrypted with the data owner's symmetric key. Te 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 verifcation of search results. We recall that in proof P f i � k 2 ′ P + y o h 3 X i , the term h 3 � H 3 (X i , Y o , t a ) includes the public key X i of the authorized data user. Terefore, the search result is only verifed 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. Te search result can be verifed by the eligible user who checks . If the result of the verifcation is valid, the eligible user will decrypt the EHR ciphertext by obtaining the symmetric key. In this way, a verifable search can be achieved.

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 st for each keyword w. If a new fle identifer containing the keyword w is added to the system, the DO will update st and send it to the blockchain. In order to better Security and Communication Networks understand fast search and forward privacy, we give a sample, as shown in Figure 4. Tere exists four states: 3 . st 0 is the initial state without ciphertext. Te DO encrypts st 0 using a key k 1 to obtain the next state 2) ciphertext, and EI f 3 (w) ⊕h 2 (st 1 , 3) ciphertext with the same keyword w. Ten, the DO utilizes st 1 and a key k 2 to get the next state st 2 . st 2 has three ciphertexts containing the same keyword w. Similarly, the DO obtains st 3 which also has three ciphertexts. Te DO uploads all encrypted states to the blockchain. When the DU wants to access intended data, he/she sends a trapdoor T w to the blockchain. Te trapdoor is a pointer to point to the current state st 3 . Search smart contract computers B � e(x i P, H 0 (w ′ )) and E * w � H 2 (e(H 0 (w ′ ), Y o ) τ w ) � H 2 (T 2 /B) and obtains the state st 3 � H 2 (T 2 /B)⊕E * v w . Ten, search smart contract can contain three indexes of the state st 3 and use a secret key k 3 to decrypt the state ci- . Ten, the smart contract starts two threads. One is responsible to fnd the previous state st 2 � L − 1 (k3, st 3 ). Another one is responsible to search the indexes EI f 8 (w) , EI f 7 (w) , EI f 6 (w) corresponding to the state st 3 by computing , h 2 (st 3 , 6) respectively. By repeating the above process, search smart contracts can fnd out all matching indexes EI f 1 (w) , EI f 2 (w) , EI f 3 (w) , EI f 4 (w) , EI f 5 (w) , EI f 6 (w) , EI f 7 (w) , EI f 8 (w) } quickly. From the above process, we know that the trapdoor as a pointer points to the latest state. Te hidden star-like structure and smart contract improve search efciency. Tus, it achieves fast search. In our scheme, the adversary cannot use the current state st c and other information to obtain the future state by the pseudorandom permutation F. Tus, the old trapdoor cannot be used to search for future updated data. Forward privacy can be achieved.

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. Ten, 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. Te system security parameter is denoted as λ � 128. We use type A pairing on the elliptic curve y 2 � x 3 + x over the feld F p for some prime p � 3 mod 4. 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 trufe @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.

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 verifable search. Notably, some of the schemes have the properties of forward privacy and secure search, which are important security goals in EHR sharing systems. Te comparison result shows that our proposed scheme can provide a promising solution to keyword search services.

Communication Overhead.
Te size of EHR data, an element in G, G T , and Z p are denoted by |M|, |G|, |G T | and Z p bytes ,respectively. Te hash address in IPFS is 46 bytes. Te communication overhead includes fve phases: data storage, data broadcast, search, data verifcation, and data access. In the data storage phase, DO sends EHR ciphertext C m to IPFS for storage and the length is |M| bytes. Ten, IPFS sends HA c m to DO, where the length is |G| + 46 bytes. Additionally, DO broadcasts C m , C K , and HA c m to the blockchain. Te total length is ((1 + 2n)|G| + |G T | + 46 bytes, where n is the amount of fles containing the keywordw. DU searches the data, the generated communication overhead is |G T | + n|G| bytes during the process of data search. DU verifes the authenticity of the search result, the generated communication cost is n|G| bytes in the data verifcation phase. At the data access phase, the generated communication cost is |M| + |Q| + 46 bytes, which is caused by k and C m . Te 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 y. 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.

Computational Cost.
We compare the computational overhead in Table 4. Te 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. Te matching test of state ciphertext and trapdoor is executed in the Search algorithm. Te DU receives the matching result and verifes its validity. Ten, 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 fle amounts 10, 50, and 100, respectively. We observe that the amount of fles n afects the computational cost of StateCipGen and Trapdoor algorithms, because these algorithms contain fle sets. However, other algorithms are not afected by fle sets.
Besides, the comparison of computational cost is depicted in Figure 5. Te result shows that our scheme becomes increasingly efcient than Chen et al. [23] scheme with the increasing amount of fles. Te proposed scheme is higher than the Xu et al. [41] scheme in terms of computational costs. Tis is because the proposed scheme has many cryptographic algorithms related to the amount of fles. Xu et al.'s [41] scheme has only one pairing operation and a few cryptographic algorithms related to the amount of fles, so     [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 fles n, as shown in Figure 6. 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. Te system init computational cost for all the schemes changes linearly with the amount of fles n. 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 fles n, 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  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 fles n, 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. Tis 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.

Time Consumption Evaluation.
Te 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 (1 + 2n)|G| + |G T | + 46 bytes and data access is |M| + |Q| + 46 bytes. Te G, G T , Q, and |M| are 64 bytes, 32 bytes, 32 bytes, and 32 bytes, respectively. So, the size of two transactions is Tx 1 � 128n + 156 bytes and Tx 2 � 96 bytes, respectively. Because fles amounts n afects the Tx 1 , we set n � 10, n � 50, and n � 100 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 fles set is large, it will afect the speed of the transactions. In addition, a transaction's length also afects gas consumption.

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. Te proposed scheme also realizes a time-bound and verifable 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 confdentiality and employ a hidden star-chain structure to achieve fast search and forward private. Ten, the performance analysis and proof of the proposed protocol testifes 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
Te authors declare that they have no conficts of interest.