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

Authors: Xueli Nie; Aiqing Zhang; Jindou Chen; Youyang Qu; Shui Yu
Journal: Security and Communication Networks
 (2022)

---

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


---

## Body

## 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 Section2. 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.


## 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)). SupposeE 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 d1≤d≤#E to satisfy as follows:(1)P+P+⋯+P︸d=dP=Q.
In cryptosystems, the integerd is usually used as the private key and a point on the curve with coordinates X=xX,yX is used as the public key X. ECDLPAssumption . Suppose that it is difficult to solve the ECDLP in polynomial time.Definition 2.
Computational bilinear Diffie–Hellman (CBDH) problem. We denote an elliptic curve asE and consider a cycling group G of prime order q. Let P be a random element in G and a,b,c∈Zq∗ . The CBDH problem is defined as follows: given an input tuple, P,aP,bP,cP∈G, and eP,Pabc was computed. Assuming that an attacker A can calculate eP,Pabc with the advantage AdvACBDH1λ, If the CBDH assumption holds, the advantage AdvACBDH1λ 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.LetTε1=εlεl−1…ε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 Tε0←0−ENCε, defined as follows:Tε0=εlεl−1…εi+11|εi=0,1⩽i⩽l.A 1-encoding ofε is denoted by Tε1←1−ENCε, defined as follows:Tε1=εlεl−1…εi|εi=1,1⩽i⩽l.From the theorem in [51], we have x>y if and only if Tx1 and Ty0 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.


## 3.1. Complexity Assumptions

Definition 1.
elliptic curve discrete logarithm problem (ECDLP)). SupposeE 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 d1≤d≤#E to satisfy as follows:(1)P+P+⋯+P︸d=dP=Q.
In cryptosystems, the integerd is usually used as the private key and a point on the curve with coordinates X=xX,yX is used as the public key X. ECDLPAssumption . Suppose that it is difficult to solve the ECDLP in polynomial time.Definition 2.
Computational bilinear Diffie–Hellman (CBDH) problem. We denote an elliptic curve asE and consider a cycling group G of prime order q. Let P be a random element in G and a,b,c∈Zq∗ . The CBDH problem is defined as follows: given an input tuple, P,aP,bP,cP∈G, and eP,Pabc was computed. Assuming that an attacker A can calculate eP,Pabc with the advantage AdvACBDH1λ, If the CBDH assumption holds, the advantage AdvACBDH1λ 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.LetTε1=εlεl−1…ε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 Tε0←0−ENCε, defined as follows:Tε0=εlεl−1…εi+11|εi=0,1⩽i⩽l.A 1-encoding ofε is denoted by Tε1←1−ENCε, defined as follows:Tε1=εlεl−1…εi|εi=1,1⩽i⩽l.From the theorem in [51], we have x>y if and only if Tx1 and Ty0 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 Figure1.Figure 1
System architecture.


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


## 4.1. System Architecture

A general searchable blockchain is composed of a data owner, data user, and blockchain network, as shown in Figure1.Figure 1
System architecture.


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


## 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 withfi) extracts a keyword w for the file. It sets two secret keys k1 and k2 for the keyword wi (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 tg. The data owner sends EHR ciphertext with a symmetric key k and uploads it to IPFS. The data owner computes tg as tgjj∈1,l←0−ENCtg, encrypts w, Fw, and ST with k1, k2, and pko into a state ciphertext I, and uploads the encrypted state I to the blockchain. All the state ciphertexts generated by different data owners at different times formulate the state ciphertexts II. If a data user with a public key pki wants to search for a state containing a keyword w′ 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 T1 for this data user. In this token T1, the data owner assigns a valid time ta for searching operations. Additionally, the data owner generates a proof Pfi for the verification of search results. The data user can generate a search trapdoor Tw 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 Pfi. If the search result is valid, the data owner will send the encrypted symmetric key the Ck to blockchain, and the data user will obtain the original EHR with the symmetric key k. 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.Table 1
Notation table.
NotationDescriptionwKeywords extracted from EHRfiwThei−th file containing the keyword wFwAll files containing the keywordwtg,taKeyword generation time and trapdoor authorization timeI,IIState ciphertext and set of state ciphertextCkSymmetric key ciphertextCmEHR ciphertextPfProof for the verification of the search resultTwThe search trapdoor ofwS,SSearched ciphertext and set of searched ciphertextL,L−1a pseudorandom permutation and the inverse permutationSTw,stc,kc,cAn empty map, map state, map key, and a counterVcThe version information about the current encrypted fileEIfiwAn encrypted index containing the keywordwFigure 2
The proposed protocol.


#### 5.1.1. Phase 1: System Setup

Given the system parameterλ, let G,GT be groups of a λ-bit prime order p. P is a generator of G. e:G×G⟶GT is a bilinear map. Let H0:0,1∗⟶G, H1:Zp∗×Zp∗×0,1∗⟶Zp∗, H2:GT⟶0,1λ, H3:G×G×ZP∗⟶Zp∗, H4:G×0,1∗×0,1∗×0,1∗⟶Zp∗, h1:0,1λ⟶0,1λ, and h2:0,1λ×N⟶0,1λ. The system chooses two random elements α,β∈Zp∗ and computes H=αP, T=βP. Let L be a pseudorandom permutation (e.g., DES, AES), denoted as L:0,1λ×0,1λ⟶0,1λ. L−1 is the inverse permutation of F. The Enc⋅ and Dec⋅ are symmetric encryption algorithms and the corresponding decryption algorithm (e.g., AES), respectively.The system parameter isparam=G,GT,e,P,H0,H1,H2,H3,H4,h1,h2,H,T,L,L−1. Furthermore, an empty map ST is initialized, denoted as STkey=value. The DO secretly stores the map.


#### 5.1.2. Phase 2: KeyGen

A data userdi randomly chooses xi∈Zp∗ and computes Xi=xiP. The public and private key pair for di is pki=Xi and ski=xi. A data owner no randomly chooses yo∈Zp∗ and computes Yo=yoP. The public and private key pair for no is pko=Yo and sko=yo.


#### 5.1.3. Phase 3: Data Generation

(1) EHR ciphertext generation: the DO selects a symmetric keyk randomly and executes the algorithm Enc⋅ to generate the EHR ciphertext Cm=Enckm. Then, he/she uploads Cm to IPFS and obtains a hash address HACm for each file.(2) State ciphertext generation: the DO chooses a set of file identifiersFw=f1w,…,fnw containing the keyword w, where n=Fw. Then, the DO performs Algorithm 1 to generate state ciphertext containing the keyword I=Cw,Dvw,Ivi,Evw. Then, the DO sends I to the blockchain. The ciphertexts that contain the same keyword have a hidden relationship as shown in Figure 3. The state stc−1 contains i ciphertexts. By using a pseudorandom permutation L and a key kc, the next state stc is equal to Lkc,stc−1. The state stc has i 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 stc and fast searches for i ciphertexts containing the same keyword in a limited time. It also can improve search efficiency.Figure 3
The hidden star-like structure of keyword ciphertext.Algorithm 1: State ciphertext generation StatekeyCipGen.
Input: a set of file identifiersFw=f1w…,fnw, keyword w, state map STOutput: state ciphertextI(1)
Computetgjj∈1,l←0−ENCtg(2)
Randomly chooseτw∈Zp∗ and compute Vc=τwP∈G(3)
Retrieve fromSTw by w, obtain stc,kc,c, and then sets stc∈0,1∗, kc∈0,1∗, and c=0(4)
Computekc+1=Lyo,kc and stc+1=Fkc+1,stc, update STw=stc+1,kc+1,c+1(5)
For eachtgj∈tgjj∈1,l, compute vj=H1k1,tgj,w(6)
Randomly chooser∈Zp∗ and compute Vj=rvjP for each j∈1,l, Z=rH0w, Cw=V1,V2,…,Vl,Z,tg(7)
Computecfiw=fiw⊕H3Z,k2P,tg and cp=H0fiw⊕H4Z,w,fiw,tg(8)
ComputeDvw=n‖kc+1⊕h1stc+1(9)
Fori∈1,n, compute EIfiw=cfiwcpHAcm and Ivi=h2stc+1,i⊕EIfi0w(10)
ComputeEvw=H2eH0w,Yoτw⊕stc(11)
ReturnI=Cw,Dvw,Ivi,Evw


#### 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 ista (authorization trapdoor time) which can be expressed as an integer. For example, the current time is “Jul. 04” which can be denoted as “ta=0704.” ta needs to be converted to the binary string “ta=1011000000” in the format of 1-encoding. We have ″1″,″101″,″1011″←1−ENCta. We assume the data generation time tg is yesterday “Jul. 03” denoted as “tg=0703.” tg also needs to be converted to the binary string “tg=1010111111” in the format of 0-encoding. We have ″11″,″1011″←1−ENCtg. We find “ta=0704>tg=070,” there is a common element “1011” in both sets. We assume the current time is ta. The DU performs the following operations: Tw=T1,T2.(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 T1 for the DU. It has the property, if he/she also generates a proof Pfi of keyword w′ for the verification of the search result by executing Algorithm 2. The DO sends a token T1 to the DU and proof Pfi to the blockchain, respectively.Algorithm 2: Token generation TokenGen.
Input: keywordw′ with two secret keys k1′ and k2′, version information Vc,Output: tokenT1, proof Pfi(1)
Set the keyword search authorization timeta and compute tajj∈1,l←1−ENCta(2)
For eachtaj∈tajj∈1,l, compute uj=H1k1′,taj,w′(3)
For eachj∈1,l, compute Uj=ujXi and T1=U1,U2,…,Ul,ta(4)
ComputePfi=k2′P+yoh3Xi, h3=H3Xi,Yo,ta(5)
ReturnT1, Pfi(2) Trapdoor Generation. after getting the DO’s authorization token, the DU will generate a search trapdoor Tw with the public key Xi and a token T1. The search trapdoor is calculated as follows: T2=eXi,H0w′eVc,H0w′yo, Tw=T1,T2. The trapdoor Tw 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 ta from the trapdoor Tw. For each state ciphertext I∈I, the search smart contract performs the following operations:(i)
It extractstg from I. If tg<ta, it computes tgjj∈1,l←0−ENCtg and tajj∈1,l←1−ENCta.(ii)
It finds the integerb which satisfies tab=tgb. It checks whether(2)eUb,Z=eVb,xiH0w′.If the equation does not hold, it aborts. Otherwise, it obtains an encrypted keywordCw and adds Cw into the set S.(iii)
It computesB=exiP,H0w′.(1)
It computesEw∗=H2eH0w′,Yoτw=H2T2/B, then retrieves Evw∗=Ew∗⊕stc, and adds Evw∗ into S.(2)
IfEvw∗=⊥, it terminates this algorithm. Otherwise, it obtains state informationstc=H2T2/B⊕Evw∗.(3)
It computesDw∗=h1stc+1 and obtains n|kc+1=Dvw∗⊕Dw∗, where Dvw∗=n|kc+1⊕Dw∗, and adds Dvw∗ into S. If Dvw∗=⊥, it returns S to the DS.(4)
Fori=n to 1, it computes Iai∗=h2stc+1,i, EIfi=Iai∗⊕Ivi∗, obtains index EIfi, and adds EIfi into S.(5)
It computesstc−1=F−1kc,stc, sets stc=stc−1, and goes to step 1.(iv)
Iftg>ta, it aborts.Algorithm 3: Search smart contract construction algorithm.
(1)
functionPutCW,Dvw,Ivi,Evw) payable public returns()(2)
if keyword and state do not exist then(3)
store states ciphertextI(4)
else(5)
returnfalse(6)
end if(7)
end function(8)
functionSearch(Tw)(9)
if keyword authorization time is larger than keyword generation time then(10)
execute the process of search in Phase 5 of the protocol(11)
return matching file indexEIfi(12)
else(13)
returnfalse(14)
end if(15)
end function(2) Verify. he DU obtains search results from the blockchain and verifies whether it is valid by performing Algorithm 4.Algorithm 4: Verification.
Input: keywords ciphertexts setS, token Tw, proof PfiOutput: 1/0.(1)
For eachS∈S, the data user parses S=Cw,EIfi,Svw∗,Hvw∗(2)
It computesh3=H3Xi,Yo,ta, A=Pfi−xih3Yo and fi′=cfi⊕H3Z,A,tg(3)
It checksH0fi′=cp⊕H4Z,w′,fi′,tg(4)
If the equation holds, it returns “1.” Otherwise, it returns “0.”(3) Symmetric Key Ciphertext Generation. after DU sends a valid verification result to the blockchain, the DO will encrypt the symmetric key k under DU’s public key Xi. 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: Ck1=keH,Xi, Ck2=αT. Then, the DO sends the symmetric key ciphertext Ck=Ck1,Ck2 to the blockchain.(4) Decryption. the DU obtains the EHR ciphertext from IPFS using the file address HACm. The symmetric key is calculated as follows: it computes D=xi/βP, k=Ck1/eCk2,D. The DU uses the symmetric key k to get the original EHR by computing m=DeckCm.


## 5.1. Workflow

The data owner of a file (identified withfi) extracts a keyword w for the file. It sets two secret keys k1 and k2 for the keyword wi (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 tg. The data owner sends EHR ciphertext with a symmetric key k and uploads it to IPFS. The data owner computes tg as tgjj∈1,l←0−ENCtg, encrypts w, Fw, and ST with k1, k2, and pko into a state ciphertext I, and uploads the encrypted state I to the blockchain. All the state ciphertexts generated by different data owners at different times formulate the state ciphertexts II. If a data user with a public key pki wants to search for a state containing a keyword w′ 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 T1 for this data user. In this token T1, the data owner assigns a valid time ta for searching operations. Additionally, the data owner generates a proof Pfi for the verification of search results. The data user can generate a search trapdoor Tw 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 Pfi. If the search result is valid, the data owner will send the encrypted symmetric key the Ck to blockchain, and the data user will obtain the original EHR with the symmetric key k. 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.Table 1
Notation table.
NotationDescriptionwKeywords extracted from EHRfiwThei−th file containing the keyword wFwAll files containing the keywordwtg,taKeyword generation time and trapdoor authorization timeI,IIState ciphertext and set of state ciphertextCkSymmetric key ciphertextCmEHR ciphertextPfProof for the verification of the search resultTwThe search trapdoor ofwS,SSearched ciphertext and set of searched ciphertextL,L−1a pseudorandom permutation and the inverse permutationSTw,stc,kc,cAn empty map, map state, map key, and a counterVcThe version information about the current encrypted fileEIfiwAn encrypted index containing the keywordwFigure 2
The proposed protocol.


### 5.1.1. Phase 1: System Setup

Given the system parameterλ, let G,GT be groups of a λ-bit prime order p. P is a generator of G. e:G×G⟶GT is a bilinear map. Let H0:0,1∗⟶G, H1:Zp∗×Zp∗×0,1∗⟶Zp∗, H2:GT⟶0,1λ, H3:G×G×ZP∗⟶Zp∗, H4:G×0,1∗×0,1∗×0,1∗⟶Zp∗, h1:0,1λ⟶0,1λ, and h2:0,1λ×N⟶0,1λ. The system chooses two random elements α,β∈Zp∗ and computes H=αP, T=βP. Let L be a pseudorandom permutation (e.g., DES, AES), denoted as L:0,1λ×0,1λ⟶0,1λ. L−1 is the inverse permutation of F. The Enc⋅ and Dec⋅ are symmetric encryption algorithms and the corresponding decryption algorithm (e.g., AES), respectively.The system parameter isparam=G,GT,e,P,H0,H1,H2,H3,H4,h1,h2,H,T,L,L−1. Furthermore, an empty map ST is initialized, denoted as STkey=value. The DO secretly stores the map.


### 5.1.2. Phase 2: KeyGen

A data userdi randomly chooses xi∈Zp∗ and computes Xi=xiP. The public and private key pair for di is pki=Xi and ski=xi. A data owner no randomly chooses yo∈Zp∗ and computes Yo=yoP. The public and private key pair for no is pko=Yo and sko=yo.


### 5.1.3. Phase 3: Data Generation

(1) EHR ciphertext generation: the DO selects a symmetric keyk randomly and executes the algorithm Enc⋅ to generate the EHR ciphertext Cm=Enckm. Then, he/she uploads Cm to IPFS and obtains a hash address HACm for each file.(2) State ciphertext generation: the DO chooses a set of file identifiersFw=f1w,…,fnw containing the keyword w, where n=Fw. Then, the DO performs Algorithm 1 to generate state ciphertext containing the keyword I=Cw,Dvw,Ivi,Evw. Then, the DO sends I to the blockchain. The ciphertexts that contain the same keyword have a hidden relationship as shown in Figure 3. The state stc−1 contains i ciphertexts. By using a pseudorandom permutation L and a key kc, the next state stc is equal to Lkc,stc−1. The state stc has i 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 stc and fast searches for i ciphertexts containing the same keyword in a limited time. It also can improve search efficiency.Figure 3
The hidden star-like structure of keyword ciphertext.Algorithm 1: State ciphertext generation StatekeyCipGen.
Input: a set of file identifiersFw=f1w…,fnw, keyword w, state map STOutput: state ciphertextI(1)
Computetgjj∈1,l←0−ENCtg(2)
Randomly chooseτw∈Zp∗ and compute Vc=τwP∈G(3)
Retrieve fromSTw by w, obtain stc,kc,c, and then sets stc∈0,1∗, kc∈0,1∗, and c=0(4)
Computekc+1=Lyo,kc and stc+1=Fkc+1,stc, update STw=stc+1,kc+1,c+1(5)
For eachtgj∈tgjj∈1,l, compute vj=H1k1,tgj,w(6)
Randomly chooser∈Zp∗ and compute Vj=rvjP for each j∈1,l, Z=rH0w, Cw=V1,V2,…,Vl,Z,tg(7)
Computecfiw=fiw⊕H3Z,k2P,tg and cp=H0fiw⊕H4Z,w,fiw,tg(8)
ComputeDvw=n‖kc+1⊕h1stc+1(9)
Fori∈1,n, compute EIfiw=cfiwcpHAcm and Ivi=h2stc+1,i⊕EIfi0w(10)
ComputeEvw=H2eH0w,Yoτw⊕stc(11)
ReturnI=Cw,Dvw,Ivi,Evw


### 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 ista (authorization trapdoor time) which can be expressed as an integer. For example, the current time is “Jul. 04” which can be denoted as “ta=0704.” ta needs to be converted to the binary string “ta=1011000000” in the format of 1-encoding. We have ″1″,″101″,″1011″←1−ENCta. We assume the data generation time tg is yesterday “Jul. 03” denoted as “tg=0703.” tg also needs to be converted to the binary string “tg=1010111111” in the format of 0-encoding. We have ″11″,″1011″←1−ENCtg. We find “ta=0704>tg=070,” there is a common element “1011” in both sets. We assume the current time is ta. The DU performs the following operations: Tw=T1,T2.(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 T1 for the DU. It has the property, if he/she also generates a proof Pfi of keyword w′ for the verification of the search result by executing Algorithm 2. The DO sends a token T1 to the DU and proof Pfi to the blockchain, respectively.Algorithm 2: Token generation TokenGen.
Input: keywordw′ with two secret keys k1′ and k2′, version information Vc,Output: tokenT1, proof Pfi(1)
Set the keyword search authorization timeta and compute tajj∈1,l←1−ENCta(2)
For eachtaj∈tajj∈1,l, compute uj=H1k1′,taj,w′(3)
For eachj∈1,l, compute Uj=ujXi and T1=U1,U2,…,Ul,ta(4)
ComputePfi=k2′P+yoh3Xi, h3=H3Xi,Yo,ta(5)
ReturnT1, Pfi(2) Trapdoor Generation. after getting the DO’s authorization token, the DU will generate a search trapdoor Tw with the public key Xi and a token T1. The search trapdoor is calculated as follows: T2=eXi,H0w′eVc,H0w′yo, Tw=T1,T2. The trapdoor Tw 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 ta from the trapdoor Tw. For each state ciphertext I∈I, the search smart contract performs the following operations:(i)
It extractstg from I. If tg<ta, it computes tgjj∈1,l←0−ENCtg and tajj∈1,l←1−ENCta.(ii)
It finds the integerb which satisfies tab=tgb. It checks whether(2)eUb,Z=eVb,xiH0w′.If the equation does not hold, it aborts. Otherwise, it obtains an encrypted keywordCw and adds Cw into the set S.(iii)
It computesB=exiP,H0w′.(1)
It computesEw∗=H2eH0w′,Yoτw=H2T2/B, then retrieves Evw∗=Ew∗⊕stc, and adds Evw∗ into S.(2)
IfEvw∗=⊥, it terminates this algorithm. Otherwise, it obtains state informationstc=H2T2/B⊕Evw∗.(3)
It computesDw∗=h1stc+1 and obtains n|kc+1=Dvw∗⊕Dw∗, where Dvw∗=n|kc+1⊕Dw∗, and adds Dvw∗ into S. If Dvw∗=⊥, it returns S to the DS.(4)
Fori=n to 1, it computes Iai∗=h2stc+1,i, EIfi=Iai∗⊕Ivi∗, obtains index EIfi, and adds EIfi into S.(5)
It computesstc−1=F−1kc,stc, sets stc=stc−1, and goes to step 1.(iv)
Iftg>ta, it aborts.Algorithm 3: Search smart contract construction algorithm.
(1)
functionPutCW,Dvw,Ivi,Evw) payable public returns()(2)
if keyword and state do not exist then(3)
store states ciphertextI(4)
else(5)
returnfalse(6)
end if(7)
end function(8)
functionSearch(Tw)(9)
if keyword authorization time is larger than keyword generation time then(10)
execute the process of search in Phase 5 of the protocol(11)
return matching file indexEIfi(12)
else(13)
returnfalse(14)
end if(15)
end function(2) Verify. he DU obtains search results from the blockchain and verifies whether it is valid by performing Algorithm 4.Algorithm 4: Verification.
Input: keywords ciphertexts setS, token Tw, proof PfiOutput: 1/0.(1)
For eachS∈S, the data user parses S=Cw,EIfi,Svw∗,Hvw∗(2)
It computesh3=H3Xi,Yo,ta, A=Pfi−xih3Yo and fi′=cfi⊕H3Z,A,tg(3)
It checksH0fi′=cp⊕H4Z,w′,fi′,tg(4)
If the equation holds, it returns “1.” Otherwise, it returns “0.”(3) Symmetric Key Ciphertext Generation. after DU sends a valid verification result to the blockchain, the DO will encrypt the symmetric key k under DU’s public key Xi. 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: Ck1=keH,Xi, Ck2=αT. Then, the DO sends the symmetric key ciphertext Ck=Ck1,Ck2 to the blockchain.(4) Decryption. the DU obtains the EHR ciphertext from IPFS using the file address HACm. The symmetric key is calculated as follows: it computes D=xi/βP, k=Ck1/eCk2,D. The DU uses the symmetric key k to get the original EHR by computing m=DeckCm.


## 5.1.1. Phase 1: System Setup

Given the system parameterλ, let G,GT be groups of a λ-bit prime order p. P is a generator of G. e:G×G⟶GT is a bilinear map. Let H0:0,1∗⟶G, H1:Zp∗×Zp∗×0,1∗⟶Zp∗, H2:GT⟶0,1λ, H3:G×G×ZP∗⟶Zp∗, H4:G×0,1∗×0,1∗×0,1∗⟶Zp∗, h1:0,1λ⟶0,1λ, and h2:0,1λ×N⟶0,1λ. The system chooses two random elements α,β∈Zp∗ and computes H=αP, T=βP. Let L be a pseudorandom permutation (e.g., DES, AES), denoted as L:0,1λ×0,1λ⟶0,1λ. L−1 is the inverse permutation of F. The Enc⋅ and Dec⋅ are symmetric encryption algorithms and the corresponding decryption algorithm (e.g., AES), respectively.The system parameter isparam=G,GT,e,P,H0,H1,H2,H3,H4,h1,h2,H,T,L,L−1. Furthermore, an empty map ST is initialized, denoted as STkey=value. The DO secretly stores the map.


## 5.1.2. Phase 2: KeyGen

A data userdi randomly chooses xi∈Zp∗ and computes Xi=xiP. The public and private key pair for di is pki=Xi and ski=xi. A data owner no randomly chooses yo∈Zp∗ and computes Yo=yoP. The public and private key pair for no is pko=Yo and sko=yo.


## 5.1.3. Phase 3: Data Generation

(1) EHR ciphertext generation: the DO selects a symmetric keyk randomly and executes the algorithm Enc⋅ to generate the EHR ciphertext Cm=Enckm. Then, he/she uploads Cm to IPFS and obtains a hash address HACm for each file.(2) State ciphertext generation: the DO chooses a set of file identifiersFw=f1w,…,fnw containing the keyword w, where n=Fw. Then, the DO performs Algorithm 1 to generate state ciphertext containing the keyword I=Cw,Dvw,Ivi,Evw. Then, the DO sends I to the blockchain. The ciphertexts that contain the same keyword have a hidden relationship as shown in Figure 3. The state stc−1 contains i ciphertexts. By using a pseudorandom permutation L and a key kc, the next state stc is equal to Lkc,stc−1. The state stc has i 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 stc and fast searches for i ciphertexts containing the same keyword in a limited time. It also can improve search efficiency.Figure 3
The hidden star-like structure of keyword ciphertext.Algorithm 1: State ciphertext generation StatekeyCipGen.
Input: a set of file identifiersFw=f1w…,fnw, keyword w, state map STOutput: state ciphertextI(1)
Computetgjj∈1,l←0−ENCtg(2)
Randomly chooseτw∈Zp∗ and compute Vc=τwP∈G(3)
Retrieve fromSTw by w, obtain stc,kc,c, and then sets stc∈0,1∗, kc∈0,1∗, and c=0(4)
Computekc+1=Lyo,kc and stc+1=Fkc+1,stc, update STw=stc+1,kc+1,c+1(5)
For eachtgj∈tgjj∈1,l, compute vj=H1k1,tgj,w(6)
Randomly chooser∈Zp∗ and compute Vj=rvjP for each j∈1,l, Z=rH0w, Cw=V1,V2,…,Vl,Z,tg(7)
Computecfiw=fiw⊕H3Z,k2P,tg and cp=H0fiw⊕H4Z,w,fiw,tg(8)
ComputeDvw=n‖kc+1⊕h1stc+1(9)
Fori∈1,n, compute EIfiw=cfiwcpHAcm and Ivi=h2stc+1,i⊕EIfi0w(10)
ComputeEvw=H2eH0w,Yoτw⊕stc(11)
ReturnI=Cw,Dvw,Ivi,Evw


## 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 ista (authorization trapdoor time) which can be expressed as an integer. For example, the current time is “Jul. 04” which can be denoted as “ta=0704.” ta needs to be converted to the binary string “ta=1011000000” in the format of 1-encoding. We have ″1″,″101″,″1011″←1−ENCta. We assume the data generation time tg is yesterday “Jul. 03” denoted as “tg=0703.” tg also needs to be converted to the binary string “tg=1010111111” in the format of 0-encoding. We have ″11″,″1011″←1−ENCtg. We find “ta=0704>tg=070,” there is a common element “1011” in both sets. We assume the current time is ta. The DU performs the following operations: Tw=T1,T2.(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 T1 for the DU. It has the property, if he/she also generates a proof Pfi of keyword w′ for the verification of the search result by executing Algorithm 2. The DO sends a token T1 to the DU and proof Pfi to the blockchain, respectively.Algorithm 2: Token generation TokenGen.
Input: keywordw′ with two secret keys k1′ and k2′, version information Vc,Output: tokenT1, proof Pfi(1)
Set the keyword search authorization timeta and compute tajj∈1,l←1−ENCta(2)
For eachtaj∈tajj∈1,l, compute uj=H1k1′,taj,w′(3)
For eachj∈1,l, compute Uj=ujXi and T1=U1,U2,…,Ul,ta(4)
ComputePfi=k2′P+yoh3Xi, h3=H3Xi,Yo,ta(5)
ReturnT1, Pfi(2) Trapdoor Generation. after getting the DO’s authorization token, the DU will generate a search trapdoor Tw with the public key Xi and a token T1. The search trapdoor is calculated as follows: T2=eXi,H0w′eVc,H0w′yo, Tw=T1,T2. The trapdoor Tw 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 ta from the trapdoor Tw. For each state ciphertext I∈I, the search smart contract performs the following operations:(i)
It extractstg from I. If tg<ta, it computes tgjj∈1,l←0−ENCtg and tajj∈1,l←1−ENCta.(ii)
It finds the integerb which satisfies tab=tgb. It checks whether(2)eUb,Z=eVb,xiH0w′.If the equation does not hold, it aborts. Otherwise, it obtains an encrypted keywordCw and adds Cw into the set S.(iii)
It computesB=exiP,H0w′.(1)
It computesEw∗=H2eH0w′,Yoτw=H2T2/B, then retrieves Evw∗=Ew∗⊕stc, and adds Evw∗ into S.(2)
IfEvw∗=⊥, it terminates this algorithm. Otherwise, it obtains state informationstc=H2T2/B⊕Evw∗.(3)
It computesDw∗=h1stc+1 and obtains n|kc+1=Dvw∗⊕Dw∗, where Dvw∗=n|kc+1⊕Dw∗, and adds Dvw∗ into S. If Dvw∗=⊥, it returns S to the DS.(4)
Fori=n to 1, it computes Iai∗=h2stc+1,i, EIfi=Iai∗⊕Ivi∗, obtains index EIfi, and adds EIfi into S.(5)
It computesstc−1=F−1kc,stc, sets stc=stc−1, and goes to step 1.(iv)
Iftg>ta, it aborts.Algorithm 3: Search smart contract construction algorithm.
(1)
functionPutCW,Dvw,Ivi,Evw) payable public returns()(2)
if keyword and state do not exist then(3)
store states ciphertextI(4)
else(5)
returnfalse(6)
end if(7)
end function(8)
functionSearch(Tw)(9)
if keyword authorization time is larger than keyword generation time then(10)
execute the process of search in Phase 5 of the protocol(11)
return matching file indexEIfi(12)
else(13)
returnfalse(14)
end if(15)
end function(2) Verify. he DU obtains search results from the blockchain and verifies whether it is valid by performing Algorithm 4.Algorithm 4: Verification.
Input: keywords ciphertexts setS, token Tw, proof PfiOutput: 1/0.(1)
For eachS∈S, the data user parses S=Cw,EIfi,Svw∗,Hvw∗(2)
It computesh3=H3Xi,Yo,ta, A=Pfi−xih3Yo and fi′=cfi⊕H3Z,A,tg(3)
It checksH0fi′=cp⊕H4Z,w′,fi′,tg(4)
If the equation holds, it returns “1.” Otherwise, it returns “0.”(3) Symmetric Key Ciphertext Generation. after DU sends a valid verification result to the blockchain, the DO will encrypt the symmetric key k under DU’s public key Xi. 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: Ck1=keH,Xi, Ck2=αT. Then, the DO sends the symmetric key ciphertext Ck=Ck1,Ck2 to the blockchain.(4) Decryption. the DU obtains the EHR ciphertext from IPFS using the file address HACm. The symmetric key is calculated as follows: it computes D=xi/βP, k=Ck1/eCk2,D. The DU uses the symmetric key k to get the original EHR by computing m=DeckCm.


## 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 adversaryA 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 areOE and OT, respectively. Suppose A is an 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 parametersP,aP,bP,cP,eP,Pabc is computed. The challenge C randomly chooses a,b∈Zp and computes Y=aP and X=bP. a and b are secretly stored by DO and DU, respectively. Then, it sends A the system parameter param=G,GT,e,P,H0,H2,h1,h2,F,F−1, the DO’s public key pko=aP, and the DU’s public key pki=bP.H0 queries: C maintains a list of tuples wi,hi,xwi,ci called H0−list for responding to the queries of H0. A makes at most qH0 hash function queries to H0. C receives the queries and responds as follows:(1)
If the querieswi are already in H0−list, C responds hi=Hiwi. Otherwise, it generates a random ci∈0,1 so that Prci=1=1/qtotal1+1, where qtotal1=qE+qT.(2)
Ifci=0, C randomly picks a number xwi∈Zq∗ and computes hi=xwiP. Otherwise, it sets hi=xwicP.(3)
C adds the tuples wi,hi,xwi,ci into H0−list and returns hi to A.H2 queries: H2 queries are similar to the H0 queries. Given an element Q∈GT, C returns a random string T∈0,1∗ and adds Q,T into H2−list.(ii)
Phase 1:A makes some queries.Encryption queries:A queries the keyword wi,Fwi to get encrypted file indexes. C responds as follows:(1)
C performs the aforementioned algorithms to respond H0 and H2 queries to get two lists wi,hi,xwi,ci and Q,E.(2)
C chooses kc+1∗∈0,1∗ instead of computing kc+1=Fsko,kc. Furthermore, C sends the encrypted data Dvw, Ivii=1,…,n to A and adds the tuple stc,kc+1∗,c into the lists Kc+1=kc+1∗ and STwi=stc+1 secretly.(3)
Ifci=0, C computes Q=eH0w,Yτwi and queries H2Q to get the value E=H2Q, where τwi∈Zq∗ is to generate the version CV=τwiP. C returns Evw=E⊕stc to A, where stc+1 is retrieved by wi from the map STwi=stc+1.(4)
Otherwise, it will report failure and end up.Trapdoor queries:A queries the keyword wi to obtain a trapdoor. C responds as follows:(1)
C performs the aforementioned algorithms to respond H0 queries to get the list wi,hi,xwi,ci.(2)
Ifci=0, C retrieves Vc and computes T2=eX,H0wiVc,H0wia. Then, C returns the trapdoor to A.(3)
Otherwise, it will report failure and end up.(iii)
Challenge:A outputs two keyword-file pairs w0,Fw0 and w1,Fw1. Then, he/she sends them to C. C executes as follows:(1)
C performs the aforementioned algorithms to respond H0 queries to obtain the list wi,hi,xwi,ci.(2)
C runs the H0 queries to get H0w0 and H0w1. If ci0 and ci1 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. The tuple denotes the latest state containing the keyword wl.(4)
C computes Hτw=Ewl∗⊕stc+1∗, where Ewl∗∈0,1∗, Ewl∗=H2eH0wl,Yoτwl.(iv)
Phase 2: the phase is the same asPhase 1. The restriction is that the adversary A cannot distinguish w0 and w1.(v)
Guess:A returns a guess l′∈0,1. C selects a random pair Q,E from the H2−list. Then, he/she returns Q/eP,Pxwlτwl which is its guess for the CBDH problem. In addition, C uses xwl and τwl in the challenge phase. Because A must make a query for either H2eH0w0,Yoτw0 or H2eH0w1,Yoτw1, its probability is 1/2. From the H0−list, C can obtain Q=eP,Pabcxlτwl and E=H2eH0wl,Yoτwl. Then, C outputs q/eP,Pxwlτwl as its guess.
In the guessing phase, if the challengerC can succeed in encryption queries and trapdoor queries at the same time, the probability is 1−1/qtotal1+1qtotal1. Due to 1−1/qtotal1+1qtotal1≥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 ci0=ci1=0, its probability is 1−1/qtotal1+12≤1−1/qtotal1+1. So, C must have probability 1/qtotal1 at least in the challenge phase. In the guessing phase, A has the same probability to make H2 queries with element eP,Pabcx0τw0 and eP,Pabcx1τw1. C has a probability of greater than 1/2ε to choose Q=eP,Pabcxlτwl correctly. Thus, the challenger C has the advantage that AdvACBDH1λ≥ε/2e^qtotal1+1qtotal2, where qtotal2=qH1+qH2.


### 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 integerb, which can meet tab=tgb. Especially, it checks whether eUb,Z=eVb,xiH0w′ holds if trapdoor authorization time ta>tg. 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 proofPfi=k2′P+yoh3Xi, the term h3=H3Xi,Yo,ta includes the public key Xi 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 H0fi′=cp⊕H4Z,w′,fi′,tg. 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 st for each keyword w. If a new file identifier containing the keyword w is added to the system, the DO will update st 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: st0,st1,st2,st3. st0 is the initial state without ciphertext. The DO encrypts st0 using a key k1 to obtain the next state st1. st1 is linked to EIf1w⊕h2st1,1 ciphertext, EIf2w⊕h2st1,2 ciphertext, and EIf3w⊕h2st1,3 ciphertext with the same keyword w. Then, the DO utilizes st1 and a key k2 to get the next state st2. st2 has three ciphertexts containing the same keyword w. Similarly, the DO obtains st3 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 Tw to the blockchain. The trapdoor is a pointer to point to the current state st3. Search smart contract computers B=exiP,H0w′ and Ew∗=H2eH0w′,Yoτw=H2T2/B and obtains the state st3=H2T2/B⊕Evw∗. Then, search smart contract can contain three indexes of the state st3 and use a secret key k3 to decrypt the state ciphertext (Dw∗=h1stc+1, 8‖kc=Dvw∗⊕Dw∗ ). Then, the smart contract starts two threads. One is responsible to find the previous state st2=L−1k3,st3. Another one is responsible to search the indexes EIf8w,EIf7w,EIf6w corresponding to the state st3 by computing h2st3,8,h2st3,7,h2st3,6 respectively. By repeating the above process, search smart contracts can find out all matching indexes EIf1w,EIf2w,EIf3w,EIf4w,EIf5w,EIf6w,EIf7w,EIf8w 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 stc and other information to obtain the future state by the pseudorandom permutation F. Thus, the old trapdoor cannot be used to search for future updated data. Forward privacy can be achieved.Figure 4
Keyword encryption and search keyword ciphertext with the hidden star-like structure.


## 6.1. Secure Search

Secure search means that an adversaryA 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 areOE and OT, respectively. Suppose A is an 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 parametersP,aP,bP,cP,eP,Pabc is computed. The challenge C randomly chooses a,b∈Zp and computes Y=aP and X=bP. a and b are secretly stored by DO and DU, respectively. Then, it sends A the system parameter param=G,GT,e,P,H0,H2,h1,h2,F,F−1, the DO’s public key pko=aP, and the DU’s public key pki=bP.H0 queries: C maintains a list of tuples wi,hi,xwi,ci called H0−list for responding to the queries of H0. A makes at most qH0 hash function queries to H0. C receives the queries and responds as follows:(1)
If the querieswi are already in H0−list, C responds hi=Hiwi. Otherwise, it generates a random ci∈0,1 so that Prci=1=1/qtotal1+1, where qtotal1=qE+qT.(2)
Ifci=0, C randomly picks a number xwi∈Zq∗ and computes hi=xwiP. Otherwise, it sets hi=xwicP.(3)
C adds the tuples wi,hi,xwi,ci into H0−list and returns hi to A.H2 queries: H2 queries are similar to the H0 queries. Given an element Q∈GT, C returns a random string T∈0,1∗ and adds Q,T into H2−list.(ii)
Phase 1:A makes some queries.Encryption queries:A queries the keyword wi,Fwi to get encrypted file indexes. C responds as follows:(1)
C performs the aforementioned algorithms to respond H0 and H2 queries to get two lists wi,hi,xwi,ci and Q,E.(2)
C chooses kc+1∗∈0,1∗ instead of computing kc+1=Fsko,kc. Furthermore, C sends the encrypted data Dvw, Ivii=1,…,n to A and adds the tuple stc,kc+1∗,c into the lists Kc+1=kc+1∗ and STwi=stc+1 secretly.(3)
Ifci=0, C computes Q=eH0w,Yτwi and queries H2Q to get the value E=H2Q, where τwi∈Zq∗ is to generate the version CV=τwiP. C returns Evw=E⊕stc to A, where stc+1 is retrieved by wi from the map STwi=stc+1.(4)
Otherwise, it will report failure and end up.Trapdoor queries:A queries the keyword wi to obtain a trapdoor. C responds as follows:(1)
C performs the aforementioned algorithms to respond H0 queries to get the list wi,hi,xwi,ci.(2)
Ifci=0, C retrieves Vc and computes T2=eX,H0wiVc,H0wia. Then, C returns the trapdoor to A.(3)
Otherwise, it will report failure and end up.(iii)
Challenge:A outputs two keyword-file pairs w0,Fw0 and w1,Fw1. Then, he/she sends them to C. C executes as follows:(1)
C performs the aforementioned algorithms to respond H0 queries to obtain the list wi,hi,xwi,ci.(2)
C runs the H0 queries to get H0w0 and H0w1. If ci0 and ci1 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. The tuple denotes the latest state containing the keyword wl.(4)
C computes Hτw=Ewl∗⊕stc+1∗, where Ewl∗∈0,1∗, Ewl∗=H2eH0wl,Yoτwl.(iv)
Phase 2: the phase is the same asPhase 1. The restriction is that the adversary A cannot distinguish w0 and w1.(v)
Guess:A returns a guess l′∈0,1. C selects a random pair Q,E from the H2−list. Then, he/she returns Q/eP,Pxwlτwl which is its guess for the CBDH problem. In addition, C uses xwl and τwl in the challenge phase. Because A must make a query for either H2eH0w0,Yoτw0 or H2eH0w1,Yoτw1, its probability is 1/2. From the H0−list, C can obtain Q=eP,Pabcxlτwl and E=H2eH0wl,Yoτwl. Then, C outputs q/eP,Pxwlτwl as its guess.
In the guessing phase, if the challengerC can succeed in encryption queries and trapdoor queries at the same time, the probability is 1−1/qtotal1+1qtotal1. Due to 1−1/qtotal1+1qtotal1≥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 ci0=ci1=0, its probability is 1−1/qtotal1+12≤1−1/qtotal1+1. So, C must have probability 1/qtotal1 at least in the challenge phase. In the guessing phase, A has the same probability to make H2 queries with element eP,Pabcx0τw0 and eP,Pabcx1τw1. C has a probability of greater than 1/2ε to choose Q=eP,Pabcxlτwl correctly. Thus, the challenger C has the advantage that AdvACBDH1λ≥ε/2e^qtotal1+1qtotal2, where qtotal2=qH1+qH2.


## 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 integerb, which can meet tab=tgb. Especially, it checks whether eUb,Z=eVb,xiH0w′ holds if trapdoor authorization time ta>tg. 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 proofPfi=k2′P+yoh3Xi, the term h3=H3Xi,Yo,ta includes the public key Xi 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 H0fi′=cp⊕H4Z,w′,fi′,tg. 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 st for each keyword w. If a new file identifier containing the keyword w is added to the system, the DO will update st 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: st0,st1,st2,st3. st0 is the initial state without ciphertext. The DO encrypts st0 using a key k1 to obtain the next state st1. st1 is linked to EIf1w⊕h2st1,1 ciphertext, EIf2w⊕h2st1,2 ciphertext, and EIf3w⊕h2st1,3 ciphertext with the same keyword w. Then, the DO utilizes st1 and a key k2 to get the next state st2. st2 has three ciphertexts containing the same keyword w. Similarly, the DO obtains st3 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 Tw to the blockchain. The trapdoor is a pointer to point to the current state st3. Search smart contract computers B=exiP,H0w′ and Ew∗=H2eH0w′,Yoτw=H2T2/B and obtains the state st3=H2T2/B⊕Evw∗. Then, search smart contract can contain three indexes of the state st3 and use a secret key k3 to decrypt the state ciphertext (Dw∗=h1stc+1, 8‖kc=Dvw∗⊕Dw∗ ). Then, the smart contract starts two threads. One is responsible to find the previous state st2=L−1k3,st3. Another one is responsible to search the indexes EIf8w,EIf7w,EIf6w corresponding to the state st3 by computing h2st3,8,h2st3,7,h2st3,6 respectively. By repeating the above process, search smart contracts can find out all matching indexes EIf1w,EIf2w,EIf3w,EIf4w,EIf5w,EIf6w,EIf7w,EIf8w 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 stc and other information to obtain the future state by the pseudorandom permutation F. Thus, the old trapdoor cannot be used to search for future updated data. Forward privacy can be achieved.Figure 4
Keyword encryption and search keyword ciphertext with the hidden star-like structure.


## 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λ=128. We use type A pairing on the elliptic curve y2=x3+x over the field Fp for some prime p=3mod4. 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.Table 2
Comparison of security properties.
PropertiesChen et al. [23]Xu et al. [41]Hu et al. [53]The proposedBlockchain-based√×√√Secure search√√√√Verifiable search×××√Forward privacy√√√√


### 7.3. Communication Overhead

The size of EHR data, an element inG, GT, and Zp are denoted by M,G,GT and Zp 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 Cm to IPFS for storage and the length is M bytes. Then, IPFS sends HAcm to DO, where the length is G+46 bytes. Additionally, DO broadcasts Cm, CK, and HAcm to the blockchain. The total length is 1+2nG+GT+46 bytes, where n is the amount of files containing the keywordw. DU searches the data, the generated communication overhead is GT+nG bytes during the process of data search. DU verifies the authenticity of the search result, the generated communication cost is nG bytes in the data verification phase. At the data access phase, the generated communication cost is M+Q+46 bytes, which is caused by k and Cm. The communication cost is shown in Table 3.Table 3
Communication overhead of the proposed protocol.
StageThe proposedChen et al. [23]Xu et al. [41]Data storageMM—Data broadcast1+2nG+GT+462yQ+ynQ2yGTSearchGT+nGyG+GT+2yQ+ynQyG+GTData verificationnG——Data accessM+Q+46M+ynG—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.


### 7.4. Computational Cost

We compare the computational overhead in Table4. 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.Table 4
Computational overhead of cryptographic algorithms (inms).
AlgorithmsSystemInitStateCipGenTrapdoorSearchVerifySymkeyGenDecn=10Average time14829433665432246Max time35733235276462548Min time9428132459422144n=50Average time1531198122767422345Max time6231228126269432646Min time931174100058422244n=100Average time1862310241763432345Max time5422413256969442647Min time932305100060422243As shown in Table4, we implement the algorithms with file amounts 10, 50, and 100, respectively. We observe that the amount of files n 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 Figure5. 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 n, as shown in Figure 6.Figure 5
Comparisons of computational cost.Figure 6
Computational cost taken by (a) SystemInit, (b) StateCipGen, (c) trapdoor, (d) search, (e) verify, (f) SymkeyGen, and (g) Dec.
(a)(b)(c)(d)(e)(f)(g)Figure6(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 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 files 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(c), it also changes linearly with the amount of files n, 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 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. Because the proposed search algorithm is achieved by smart contract in a limited time, the computational cost of the search is almost unchanged.Figure6(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 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. 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 is1+2nG+GT+46 bytes and data access is M+Q+46 bytes. The G, GT, Q, and M are 64 bytes, 32 bytes, 32 bytes, and 32 bytes, respectively. So, the size of two transactions is Tx1=128n+156 bytes and Tx2=96 bytes, respectively. Because files amounts n affects the Tx1, we set n=10, n=50, and n=100 to implement the transactions on the Ethereum platform.As can be seen from Table5, 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.Table 5
Time consumption of transactions.
TransactionsTx1n=10Tx1n=50Tx1n=100Tx2Length (bytes)143665561295696Average time (ms)59.8357.82623.9147.446Max time (ms)105645113098Min time (ms)4832961437Gas used (wei)127794824663744544114471536


## 7.1. Parameter Settings and Platform

The system security parameter is denoted asλ=128. We use type A pairing on the elliptic curve y2=x3+x over the field Fp for some prime p=3mod4. 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.Table 2
Comparison of security properties.
PropertiesChen et al. [23]Xu et al. [41]Hu et al. [53]The proposedBlockchain-based√×√√Secure search√√√√Verifiable search×××√Forward privacy√√√√


## 7.3. Communication Overhead

The size of EHR data, an element inG, GT, and Zp are denoted by M,G,GT and Zp 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 Cm to IPFS for storage and the length is M bytes. Then, IPFS sends HAcm to DO, where the length is G+46 bytes. Additionally, DO broadcasts Cm, CK, and HAcm to the blockchain. The total length is 1+2nG+GT+46 bytes, where n is the amount of files containing the keywordw. DU searches the data, the generated communication overhead is GT+nG bytes during the process of data search. DU verifies the authenticity of the search result, the generated communication cost is nG bytes in the data verification phase. At the data access phase, the generated communication cost is M+Q+46 bytes, which is caused by k and Cm. The communication cost is shown in Table 3.Table 3
Communication overhead of the proposed protocol.
StageThe proposedChen et al. [23]Xu et al. [41]Data storageMM—Data broadcast1+2nG+GT+462yQ+ynQ2yGTSearchGT+nGyG+GT+2yQ+ynQyG+GTData verificationnG——Data accessM+Q+46M+ynG—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.


## 7.4. Computational Cost

We compare the computational overhead in Table4. 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.Table 4
Computational overhead of cryptographic algorithms (inms).
AlgorithmsSystemInitStateCipGenTrapdoorSearchVerifySymkeyGenDecn=10Average time14829433665432246Max time35733235276462548Min time9428132459422144n=50Average time1531198122767422345Max time6231228126269432646Min time931174100058422244n=100Average time1862310241763432345Max time5422413256969442647Min time932305100060422243As shown in Table4, we implement the algorithms with file amounts 10, 50, and 100, respectively. We observe that the amount of files n 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 Figure5. 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 n, as shown in Figure 6.Figure 5
Comparisons of computational cost.Figure 6
Computational cost taken by (a) SystemInit, (b) StateCipGen, (c) trapdoor, (d) search, (e) verify, (f) SymkeyGen, and (g) Dec.
(a)(b)(c)(d)(e)(f)(g)Figure6(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 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 files 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(c), it also changes linearly with the amount of files n, 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 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. Because the proposed search algorithm is achieved by smart contract in a limited time, the computational cost of the search is almost unchanged.Figure6(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 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. 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 is1+2nG+GT+46 bytes and data access is M+Q+46 bytes. The G, GT, Q, and M are 64 bytes, 32 bytes, 32 bytes, and 32 bytes, respectively. So, the size of two transactions is Tx1=128n+156 bytes and Tx2=96 bytes, respectively. Because files amounts n affects the Tx1, we set n=10, n=50, and n=100 to implement the transactions on the Ethereum platform.As can be seen from Table5, 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.Table 5
Time consumption of transactions.
TransactionsTx1n=10Tx1n=50Tx1n=100Tx2Length (bytes)143665561295696Average time (ms)59.8357.82623.9147.446Max time (ms)105645113098Min time (ms)4832961437Gas used (wei)127794824663744544114471536


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



---

*Source: 1103863-2022-12-13.xml*