# A Blockchain-Based Normalized Searchable Encryption System for Medical Data

Authors: Qin Liu; Yun Lian Liu; Min Luo; Cong Peng; Xuan Xiao
Journal: Security and Communication Networks
 (2022)

---

## Abstract

As COVID-19 continues to spread around the world, the healthcare industry has accelerated the transformation to digital healthcare services. In the era of big data, many hospitals prefer to use remote cloud servers to store and manage massive electronic medical data. However, cloud-assisted medical data systems cannot guarantee the confidentiality, integrity, and availability of data. Searchable encryption can effectively address the above challenges by enabling data search on the ciphertext, which achieves the availability of medical data while ensuring data security and privacy. However, the search server may return mismatched search results due to economic interests or single points of failure. Blockchain is a decentralized computing paradigm with public verifiability, which provides an efficient solution to this problem. However, the existing blockchain-based searchable encryption solutions do not consider the flexible search function of multiple users and the restriction of encrypted data for medical scenarios. Therefore, we propose a blockchain-based multiuser normalized searchable encryption (BNSE) scheme and design a blockchain-based normalized searchable encryption system for medical data (BNSEM) based on the scheme. To verify the practicality of the system, we evaluate the performance from both theoretical and experimental aspects.


---

## Body

## 1. Introduction

With the rapid spread of COVID-19 around the world, the healthcare industry has accelerated the shift to digital healthcare services [1, 2]. In the era of big data, many hospitals prefer to use remote cloud servers to store and manage huge amounts of electronic medical data. However, due to the inherent properties of the cloud such as centralization and openness, cloud-assisted medical data systems will face new privacy and security challenges [3]. Firstly, medical data outsourced to cloud servers may be accessed or tampered with by unauthorized users. The confidentiality and integrity of the medical data cannot be guaranteed. Secondly, centralized cloud servers may suffer from a single point of failure, which will result in the unavailability of medical data. Although the traditional encryption technology can ensure security, it is difficult to take into account the availability of outsourced medical data.Searchable encryption (SE) is a critical cryptographic technique to achieve the availability of data while ensuring security and privacy, which enables users to search ciphertext data [4]. In a searchable encryption scheme, the data owner uploads the encrypted data to the cloud server. Then, the user needs to construct a trapdoor and submit it to the cloud server to search for data containing the target keywords. In most cases, the server is regarded as a semihonest third-party entity [5, 6]; i.e., the server will perform the search operation correctly according to the protocol. However, in practical scenarios, the server may return mismatched search results due to economic interest or single point of failure.Blockchain is a decentralized computing paradigm with public verifiability and tamper-proof features [7]. Applying blockchain to searchable encryption can effectively solve the problem of untrustworthy search results from the centralized servers [8–10]. Smart contracts deployed in the blockchain can perform search functions instead of third-party servers and automatically execute search protocols based on trigger conditions to produce correct results. In addition, blockchain nodes record transaction results in an immutable ledger, which guarantees the integrity of the results and eliminates the need for further validation of the results. Even if one or more nodes fail or are corrupted by malicious adversaries, the correctness of the results will not be affected due to the fault tolerance of the blockchain.In the blockchain-based searchable system, data and search structure are stored in a ciphertext state, and thus, the legality of the data in the system cannot be guaranteed. In the medical scenario, the necessary supervision of encrypted medical data is needed to ensure the legality of medical data. For example, supervisors need to filter the search requests that contain illegal keywords to prevent the spread of false medical information. In addition, supervisors are supposed to check the legality of ciphertext data in the remote cloud when they suspect illegal data or when a user files a complaint with the supervisors. The controllability of medical data is key to maintaining a stable healthcare system, yet there is a lack of research related to the supervision of ciphertext data.


### 1.1. Motivation and Contributions

Inspired by the work [11], a blockchain-based searchable public key encryption with forward and backward privacy can be used to design a searchable encryption system for medical data. In medical scenarios, multiuser search functions and dynamic updates for authorized users need to be supported with data sharing requirements. In addition, to ensure the stability of the medical searchable encryption system, the ciphertext data in the system need to be legally supervised. As for the blockchain platform, the consortium chain hyperledger fabric is a good option considering the practicality and privacy. Based on the above analysis and practical application scenarios of the medical data, we propose a blockchain-based multiuser searchable encryption scheme supporting supervision and design a searchable encryption system for medical data based on the scheme. The main contributions of this study are as follows:(i)
We propose a blockchain-based multiuser normalized searchable encryption (BNSE) scheme, which achieves efficient retrieval of ciphertext data in multiuser scenarios and supports the supervision on the ciphertext data(ii)
We design a blockchain-based normalized searchable encryption system for medical data (BNSEM) based on the above scheme, which realizes the application of retrieval on the encrypted medical data(iii)
We evaluate the theoretical performance of the scheme and test the practical performance of the system to verify the availability


### 1.2. Organization

In Section2, we review the existing research work related to the security and functionality of searchable encryption. In Section 3, we introduce the blockchain technology and broadcast encryption, as well as security definition. In Section 4, we describe the specific construction of our proposed scheme BNSE and prove its security. In Section 5, we present the design of our system BNSEM. In Section 6, we provide the security analysis of BNSEM. In Section 7, we conduct a performance evaluation of the system. Section 8 makes a conclusion of this study.


## 1.1. Motivation and Contributions

Inspired by the work [11], a blockchain-based searchable public key encryption with forward and backward privacy can be used to design a searchable encryption system for medical data. In medical scenarios, multiuser search functions and dynamic updates for authorized users need to be supported with data sharing requirements. In addition, to ensure the stability of the medical searchable encryption system, the ciphertext data in the system need to be legally supervised. As for the blockchain platform, the consortium chain hyperledger fabric is a good option considering the practicality and privacy. Based on the above analysis and practical application scenarios of the medical data, we propose a blockchain-based multiuser searchable encryption scheme supporting supervision and design a searchable encryption system for medical data based on the scheme. The main contributions of this study are as follows:(i)
We propose a blockchain-based multiuser normalized searchable encryption (BNSE) scheme, which achieves efficient retrieval of ciphertext data in multiuser scenarios and supports the supervision on the ciphertext data(ii)
We design a blockchain-based normalized searchable encryption system for medical data (BNSEM) based on the above scheme, which realizes the application of retrieval on the encrypted medical data(iii)
We evaluate the theoretical performance of the scheme and test the practical performance of the system to verify the availability


## 1.2. Organization

In Section2, we review the existing research work related to the security and functionality of searchable encryption. In Section 3, we introduce the blockchain technology and broadcast encryption, as well as security definition. In Section 4, we describe the specific construction of our proposed scheme BNSE and prove its security. In Section 5, we present the design of our system BNSEM. In Section 6, we provide the security analysis of BNSEM. In Section 7, we conduct a performance evaluation of the system. Section 8 makes a conclusion of this study.


## 2. Related Work

In 2000, Song et al. [4] proposed the first SE scheme, which is a noninteractive single-keyword search scheme. The drawback of the scheme is that it is extremely inefficient when the number of documents is large. However, this pioneering work still greatly contributed to the research and development of searchable encryption. Later, many works [12, 13] focus on designing efficient security mechanisms to enhance the security. Meanwhile, some works also introduce searchable encryption schemes for functional extensions, including the multiuser SE scheme [14] and the dynamic SE scheme [15].To balance security and efficiency, a practical SE scheme will leak some information to the adversary. However, the information leakage attack undermines the security of SE schemes [16]. Adaptive leakage exploit attacks have brought more attention to forward privacy [17]. Song et al. [12] proposed two schemes FAST and FASTIO, both of which have forward privacy. In addition, Bost et al. [6] presented a formal definition of backward privacy, and backward privacy gradually became a major security property of interest. Chamani et al. [18] proposed improvements in various aspects of performance to the work [6].To avoid the problem of key management and distribution restrictions prevalent in symmetric searchable encryption (SSE) schemes, Boneh et al. [19] proposed the first searchable public key encryption (SPE) scheme, which is a noninteractive single-user search scheme. However, a significant limitation of SPE is that it contains a large number of time-consuming operations, such as bilinear pairs and exponential operations. In 2020, Chen et al. [11] proposed a lightweight SPE scheme with search performance close to the efficient SSE. However, the scheme does not implement multiuser search and cannot share data in multiuser scenarios.From a functional point of view, most of the current research efforts focus on symmetric searchable encryption schemes that support only single-user search mode; i.e., the data user is the data owner. The few SSE schemes that support multiuser search also require the owner to calculate a search trapdoor [20] online. Multiuser searchable encryption (MUSE) [21] is a significant research content of SE with practical research significance. In MUSE, a data owner uploads data to a cloud server and wants to share the data with multiple users. Attribute-based searchable encryption (ABSE) [22] can manage the retrieval of ciphertext data in a multiuser scenario, but it is computationally inefficient and lacks practicality.Broadcast encryption (BE) [23] enables multiuser data sharing and is suitable for scenarios where data users are relatively fixed. Liu et al. [24] designed a multiuser searchable encryption scheme based on a single-user system prototype and inherited the functionality of adding, modifying, and deleting documents from the original dynamic scheme. However, scheme [24] requires online search trapdoor generation and multiple rounds of client-server interaction, which increases the communication overhead. Later, Liu et al. [25] combined public key authenticated encryption supporting keyword search with broadcast encryption BE and proposed a broadcast authenticated encryption primitive BAEKS supporting keyword search, while the scheme reaches a performance bottleneck when the number of users increases to a certain number.In most existing schemes, the search server is regarded as an honest third party that performs the prescribed search protocol [26]. However, the search server may be a malicious third party that returns partial or even mismatched search results due to profit or random failures. The main reason for these problems is that centralized servers have complete control over the data and execute the protocols independently without supervision. In view of this, blockchain technology [7], a decentralized computing paradigm with public verifiability and invariance characteristics, combined with searchable encryption [14] can effectively solve the problem of untrustworthy third-party search results.There are two ways to combine blockchain with searchable encryption, one of which is to use the blockchain for storing credentials and the other is to use the blockchain’s smart contract to perform the search function. The first approach still follows the traditional server-side search by storing the transaction credentials on the blockchain [27]. Cai et al. [8] designed a dynamic and efficient searchable encryption scheme using blockchain. Tang [28] extends searchable encryption by saving essential messages on the blockchain and the scheme performs only a small number of operations on the blockchain, thus reducing the burden on the blockchain. When there are disputes and controversies, the misconduct of participants can be revealed through transactions on the blockchain. However, using the blockchain to store credentials still does not prevent the malicious behavior of servers.Therefore, researchers have also proposed an alternative construction method to design smart contracts that include search functions instead of cloud servers to perform keyword search operation [14]. Chen et al. [29] used electronic medical record EHR file indexes to construct complex logical structures and store them on a blockchain so that data users can search the file indexes using these logical expressions. Hu et al. [20] enabled users to search private databases in a blockchain environment and implement dynamic access control for searches. However, all of the above schemes outsource complex operations or encrypted data to the blockchain, which greatly degrades the performance of the system. Chen et al. [11] designed a blockchain-based searchable public key encryption scheme with only lightweight hash operations.


## 3. Preliminaries

In this section, we introduce the blockchain technology, broadcast encryption, system model, security definition, and design goals.


### 3.1. Blockchain Technology

In 2008, blockchain technology received widespread attention following the publication of the Bitcoin white paper [7]. Blockchain provides a distributed, immutable, secure, transparent, and auditable ledger. The blocks in a blockchain store transactions at a specific time, and their hash values are recorded by a Merkle tree. The transaction data on the blockchain are shared in a P2P (peer-to-peer) network, and the security of the transaction data is ensured by cryptographic primitives (Merkle tree, asymmetric encryption, and digital signatures).Since blockchain operates on a P2P network, a P2P network including a number of blockchain nodes (peer nodes, orderer nodes, etc.) needs to be created before deploying a blockchain platform. Each node provides two keys that can be used for encryption and signature. When a transaction is initiated, one node signs the transaction and broadcasts it to other peer nodes. When another node receives the signed transaction, it needs to verify the validity of the transaction before broadcasting it. The peer nodes (also known as miners) collect enough signatures of this transaction to pack it into a block and store it on the blockchain after passing consensus.Smart contract: a smart contract contains a set of rules and logic, which is a decentralized, information-sharable program code deployed on the blockchain. The parties involve in signing a contract agree on the content of the smart contract and deploy it on the blockchain, which can automate the execution of the contract without relying on any third authority [30]. Smart contracts run automatically once started without the intervention of any contract signatory.


### 3.2. Broadcast Encryption

A public key broadcast encryption scheme consists of four algorithms, namely system setupSetup, key generation KeyGen, encryption Encrypt, and decryption Decrypt, defined as follows:(i)
Setupκ⟶N,EK: with the security parameter κ as input, the maximum capacity N of the broadcast receiver group and the initial encryption key list EK are output.(ii)
KeyGenκ,EK⟶pk,sk: with the security parameter κ and the encryption key list EK as input, the user’s public-private key pair pk,sk is output and the public key pk is added to the key list EK.(iii)
EncryptEK,S,m⟶Cm: the algorithm takes a subset of users S⊆1,2,…,n, encryption key list EK, and a plaintext message m to be broadcast as input. The public keys PK=pk1,…,pkn corresponding to the users in the subset S from the encryption key list EK are selected. The broadcast ciphertext Cm of the message m under encryption using the key set PK is output. Note that the broadcast ciphertext can only be correctly decrypted by the receiver in S.(iv)
Decryptsk,Cm⟶m: taking user’s private key sk and broadcast ciphertext Cm as input, if user ui∈S who has the private key sk, then the user ui can use his private key sk to decrypt the broadcast ciphertext Cm and output the broadcast message m.


### 3.3. System Model

The system model of our BMNSE scheme is shown in Figure1. It consists of six entities: trusted institute (TI), cloud server (CS), blockchain (BC), data owner (DO), data user (DU), and supervisor (SUP). Although the TI and SUP are not involved in the main process of data search, they are still two indispensable entities that play an important role in the execution of the scheme and the maintenance of the ecosystem. Before running scheme, TI first generates the parameters required for system initialization and issues public key certificates for users who join the system, and TI is offline the rest of the time.Figure 1
System model of BNSE.After the initialization is completed, the program needs to perform five main steps, which are described as follows:(1)
Encrypt File. The DO first encrypts the data file using a symmetric encryption algorithm and then encrypts the symmetric key using a public key cryptography algorithm. Finally, DO uploads the ciphertext to CS.(2)
Generate Searchable Encrypted Data Structures. The DO extracts keyword-index pairs from files and generates searchable encrypted data structures. Then, DO uploads the structures to BC.(3)
Search for the Files that Contain the Target Keyword. DU generates a search trapdoor containing the target keyword and then sends the search request containing the trapdoor to a nearby blockchain node. The search request triggers the search process of the smart contract, which then returns the index of all matching encrypted files.(4)
Access the Files. The DU first decrypts the encrypted file index returned by the smart contract in step 3 and then accesses the data in the CS after getting the plaintext index.(5)
Return the Encrypted Data. Based on the file indexes submitted by DU, CS returns the corresponding files.To ensure the legitimacy of the transactional data in the program, the necessary supervision of data cryptography by SUP is required. SUP has two main tasks: first, carrying out periodic audits of cryptographic data stored on CS, and second, scrutinizing the search requests of DU. The purpose of cryptographic data audit is to detect data files that contain illegal or sensitive keywords, timely revoke illegal files hosted on CS, and alert, warn, or punish the corresponding DU. The purpose of scrutinizing search requests is to monitor keyword search requests sent by DOs to the BC in real time and to intercept and warn the noncompliant search requests.Based on the above system model, the following eight algorithms are defined in our scheme:(i)
Setupκ⟶Param: it is executed by TI and takes the security parameter κ as input and the system public parameter Param as output.(ii)
KeyGenParam⟶Qu,du: it is executed by TI and takes the public parameter Param as input and outputs the user’s public-private key pair Qu,du.(iii)
EncryptParam,Qui,DB,Σ⟶EDB: this algorithm is executed by DO. The input parameters contain the system public parameters Param, the public keys Qui of the authorized DUs, the database DB, and an empty mapping Σ. The algorithm outputs the searchable encrypted database EDB and the initialized mapping Σ.(iv)
UpdateParam,Qui′,Z⟶,wk,r,s⟶Z′⟶: this algorithm is executed by DO with input parameters including system parameter Param, public key set Qui′ of the users to be authorized, original broadcast cipher Z⟶, target keyword wk, and secret values r,s saved by DO, where r is the secret value associated with version information and s is the secret value involved in the encryption calculation. The algorithm outputs the updated broadcast cipher Z′⟶.(v)
TrapdoorParam,dui,wk⟶Twk: this algorithm is executed by DU with the input of public parameter Param, authorized user’s private key dui and target keyword wk, and the output of search trapdoor Twk.(vi)
SearchParam,Twk,EDB⟶RSwk: it is automatically executed by the smart contract, takes the system parameter Param, the search trapdoor Twk for the keyword wk, and the encrypted database EDB as input, and outputs the matched search results RSwk.(vii)
DecryptParam,dui,wk,RSwk⟶indwk: this algorithm is executed by DU, which takes the private key dui and the search result set RSwk as inputs and outputs the decrypted file index set indwk.(viii)
SuperviseParam,Qui,dsup,wk⟶Twk: this algorithm is executed by SUP with input parameters including system parameter Param, public keys Qui′ of authorized users, illegal or sensitive keyword wk and private key dsup of supervisor, and outputs search trapdoor Twk of sensitive words.


### 3.4. Security Definition

Similar to [12], we demonstrate the confidentiality of our BMNSE scheme with a real/ideal simulation paradigm. To achieve higher operational efficiency, searchable encryption schemes will disclose some information to the server. The leakage information of our scheme is described by the leakage function ℒ=ℒSetup,ℒKeyGen,ℒEncrypt,ℒTrapdoor,ℒSearch,ℒSupervise. The nonformal definition of the confidentiality of searchable encryption scheme is that no information about the database should be revealed other than the information leaked in the leak function ℒ. The formal definition of confidentiality can be presented by a reality/ideal simulation paradigm containing the game RealSE and IdealSE.Definition 1.
LetΠ=Setup, KeyGen, Encrypt, Trapdoor, Search, Supervise denote the BMNSE scheme, A denote the adversary, and S be a simulator with a leakage function ℒ=ℒSetup,ℒKeyGen,ℒEncrypt,ℒTrapdoor,ℒSearch,ℒSupervise as an parameter. The following two probabilistic game experiments are defined:(i)
RealAΠκ: the game runs the system setup algorithm Setup κ to generate system parameters Param and the key generation algorithm KeyGen Param to generate the user’s public-private key pair Qu,du. The game publishes the public message Param,Qu and keeps the private key du secretly. Then, the adversary A selects a database DB and performs an encrypted query based on the information Param,Qui. Next, the game runs the encryption algorithm EncryptParam,Qu,DB,Σ=EDB and returns the encrypted database EDB to A. A chooses a keyword wk for the trapdoor query, and the game runs the trapdoor generation algorithm TrapdoorParam,dui,wk=Twk and returns the trapdoor Twk to A. Then, A selects a trapdoor Twk for the search query and the game runs the search algorithm SearchParam,Twk,EDB=RS and returns the result set RS to A. The adversary A can repeat the above steps several times and finally output a bit b∈0,1.(ii)
IdealA,SΠκ: the simulator S generates the system public parameter Param←SℒSetup using the leak function of system setup. Then, S generates the user’s public-private key pair du,Qu←SℒKeyGen based on the public parameter Param and the leak function ℒKeyGen and publishes the public key list Qui. Next, the adversary A launches an encrypted query and the simulator S generates an encrypted database EDB←SℒEncrypt and returns it to A. Then, the simulator S uses the leak function of the trapdoor to generate a search trapdoor Twk←SℒTrapdoor in response to a trapdoor query from A. After the adversary issues a search query, the simulator returns the result RS←SℒSearch using the leak function of the search. Finally, the adversary A outputs a bit b∈0,1.
SchemeΠ satisfies ℒ-adaptive security if for any probabilistic polynomial time (PPT) adversary A, there exists a PPT simulator S such that(1)PrRealAΠκ=1−PrIdealA,SΠκ=1≤neglκ,where neglκ is a negligible function.


### 3.5. Design Goals

Combining the above system model and practical application requirements, our scheme should meet the following functional objectives:(i)
Supervisibility. Supervision can ensure the controllability of the cryptographic data. The SUP needs to supervise the encrypted data in the CS and the DU’s search requests to ensure that the data can be stored and used in a legal and compliant manner.(ii)
Multi-user Search. Multiuser search is a basic function in data sharing scenarios. In this scenario, multiple DUs need to be authorized to access the encrypted data to provide easier data retrieval services.(iii)
Dynamic Update. It is an important function of the dynamic searchable encryption scheme. First, after DO generates data files containing preexisting keywords, the encrypted data structure corresponding to the keywords in BC and the data files in CS need to be updated. Secondly, in the multiuser scenario, dynamic update of authorized user DU needs to be implemented.


## 3.1. Blockchain Technology

In 2008, blockchain technology received widespread attention following the publication of the Bitcoin white paper [7]. Blockchain provides a distributed, immutable, secure, transparent, and auditable ledger. The blocks in a blockchain store transactions at a specific time, and their hash values are recorded by a Merkle tree. The transaction data on the blockchain are shared in a P2P (peer-to-peer) network, and the security of the transaction data is ensured by cryptographic primitives (Merkle tree, asymmetric encryption, and digital signatures).Since blockchain operates on a P2P network, a P2P network including a number of blockchain nodes (peer nodes, orderer nodes, etc.) needs to be created before deploying a blockchain platform. Each node provides two keys that can be used for encryption and signature. When a transaction is initiated, one node signs the transaction and broadcasts it to other peer nodes. When another node receives the signed transaction, it needs to verify the validity of the transaction before broadcasting it. The peer nodes (also known as miners) collect enough signatures of this transaction to pack it into a block and store it on the blockchain after passing consensus.Smart contract: a smart contract contains a set of rules and logic, which is a decentralized, information-sharable program code deployed on the blockchain. The parties involve in signing a contract agree on the content of the smart contract and deploy it on the blockchain, which can automate the execution of the contract without relying on any third authority [30]. Smart contracts run automatically once started without the intervention of any contract signatory.


## 3.2. Broadcast Encryption

A public key broadcast encryption scheme consists of four algorithms, namely system setupSetup, key generation KeyGen, encryption Encrypt, and decryption Decrypt, defined as follows:(i)
Setupκ⟶N,EK: with the security parameter κ as input, the maximum capacity N of the broadcast receiver group and the initial encryption key list EK are output.(ii)
KeyGenκ,EK⟶pk,sk: with the security parameter κ and the encryption key list EK as input, the user’s public-private key pair pk,sk is output and the public key pk is added to the key list EK.(iii)
EncryptEK,S,m⟶Cm: the algorithm takes a subset of users S⊆1,2,…,n, encryption key list EK, and a plaintext message m to be broadcast as input. The public keys PK=pk1,…,pkn corresponding to the users in the subset S from the encryption key list EK are selected. The broadcast ciphertext Cm of the message m under encryption using the key set PK is output. Note that the broadcast ciphertext can only be correctly decrypted by the receiver in S.(iv)
Decryptsk,Cm⟶m: taking user’s private key sk and broadcast ciphertext Cm as input, if user ui∈S who has the private key sk, then the user ui can use his private key sk to decrypt the broadcast ciphertext Cm and output the broadcast message m.


## 3.3. System Model

The system model of our BMNSE scheme is shown in Figure1. It consists of six entities: trusted institute (TI), cloud server (CS), blockchain (BC), data owner (DO), data user (DU), and supervisor (SUP). Although the TI and SUP are not involved in the main process of data search, they are still two indispensable entities that play an important role in the execution of the scheme and the maintenance of the ecosystem. Before running scheme, TI first generates the parameters required for system initialization and issues public key certificates for users who join the system, and TI is offline the rest of the time.Figure 1
System model of BNSE.After the initialization is completed, the program needs to perform five main steps, which are described as follows:(1)
Encrypt File. The DO first encrypts the data file using a symmetric encryption algorithm and then encrypts the symmetric key using a public key cryptography algorithm. Finally, DO uploads the ciphertext to CS.(2)
Generate Searchable Encrypted Data Structures. The DO extracts keyword-index pairs from files and generates searchable encrypted data structures. Then, DO uploads the structures to BC.(3)
Search for the Files that Contain the Target Keyword. DU generates a search trapdoor containing the target keyword and then sends the search request containing the trapdoor to a nearby blockchain node. The search request triggers the search process of the smart contract, which then returns the index of all matching encrypted files.(4)
Access the Files. The DU first decrypts the encrypted file index returned by the smart contract in step 3 and then accesses the data in the CS after getting the plaintext index.(5)
Return the Encrypted Data. Based on the file indexes submitted by DU, CS returns the corresponding files.To ensure the legitimacy of the transactional data in the program, the necessary supervision of data cryptography by SUP is required. SUP has two main tasks: first, carrying out periodic audits of cryptographic data stored on CS, and second, scrutinizing the search requests of DU. The purpose of cryptographic data audit is to detect data files that contain illegal or sensitive keywords, timely revoke illegal files hosted on CS, and alert, warn, or punish the corresponding DU. The purpose of scrutinizing search requests is to monitor keyword search requests sent by DOs to the BC in real time and to intercept and warn the noncompliant search requests.Based on the above system model, the following eight algorithms are defined in our scheme:(i)
Setupκ⟶Param: it is executed by TI and takes the security parameter κ as input and the system public parameter Param as output.(ii)
KeyGenParam⟶Qu,du: it is executed by TI and takes the public parameter Param as input and outputs the user’s public-private key pair Qu,du.(iii)
EncryptParam,Qui,DB,Σ⟶EDB: this algorithm is executed by DO. The input parameters contain the system public parameters Param, the public keys Qui of the authorized DUs, the database DB, and an empty mapping Σ. The algorithm outputs the searchable encrypted database EDB and the initialized mapping Σ.(iv)
UpdateParam,Qui′,Z⟶,wk,r,s⟶Z′⟶: this algorithm is executed by DO with input parameters including system parameter Param, public key set Qui′ of the users to be authorized, original broadcast cipher Z⟶, target keyword wk, and secret values r,s saved by DO, where r is the secret value associated with version information and s is the secret value involved in the encryption calculation. The algorithm outputs the updated broadcast cipher Z′⟶.(v)
TrapdoorParam,dui,wk⟶Twk: this algorithm is executed by DU with the input of public parameter Param, authorized user’s private key dui and target keyword wk, and the output of search trapdoor Twk.(vi)
SearchParam,Twk,EDB⟶RSwk: it is automatically executed by the smart contract, takes the system parameter Param, the search trapdoor Twk for the keyword wk, and the encrypted database EDB as input, and outputs the matched search results RSwk.(vii)
DecryptParam,dui,wk,RSwk⟶indwk: this algorithm is executed by DU, which takes the private key dui and the search result set RSwk as inputs and outputs the decrypted file index set indwk.(viii)
SuperviseParam,Qui,dsup,wk⟶Twk: this algorithm is executed by SUP with input parameters including system parameter Param, public keys Qui′ of authorized users, illegal or sensitive keyword wk and private key dsup of supervisor, and outputs search trapdoor Twk of sensitive words.


## 3.4. Security Definition

Similar to [12], we demonstrate the confidentiality of our BMNSE scheme with a real/ideal simulation paradigm. To achieve higher operational efficiency, searchable encryption schemes will disclose some information to the server. The leakage information of our scheme is described by the leakage function ℒ=ℒSetup,ℒKeyGen,ℒEncrypt,ℒTrapdoor,ℒSearch,ℒSupervise. The nonformal definition of the confidentiality of searchable encryption scheme is that no information about the database should be revealed other than the information leaked in the leak function ℒ. The formal definition of confidentiality can be presented by a reality/ideal simulation paradigm containing the game RealSE and IdealSE.Definition 1.
LetΠ=Setup, KeyGen, Encrypt, Trapdoor, Search, Supervise denote the BMNSE scheme, A denote the adversary, and S be a simulator with a leakage function ℒ=ℒSetup,ℒKeyGen,ℒEncrypt,ℒTrapdoor,ℒSearch,ℒSupervise as an parameter. The following two probabilistic game experiments are defined:(i)
RealAΠκ: the game runs the system setup algorithm Setup κ to generate system parameters Param and the key generation algorithm KeyGen Param to generate the user’s public-private key pair Qu,du. The game publishes the public message Param,Qu and keeps the private key du secretly. Then, the adversary A selects a database DB and performs an encrypted query based on the information Param,Qui. Next, the game runs the encryption algorithm EncryptParam,Qu,DB,Σ=EDB and returns the encrypted database EDB to A. A chooses a keyword wk for the trapdoor query, and the game runs the trapdoor generation algorithm TrapdoorParam,dui,wk=Twk and returns the trapdoor Twk to A. Then, A selects a trapdoor Twk for the search query and the game runs the search algorithm SearchParam,Twk,EDB=RS and returns the result set RS to A. The adversary A can repeat the above steps several times and finally output a bit b∈0,1.(ii)
IdealA,SΠκ: the simulator S generates the system public parameter Param←SℒSetup using the leak function of system setup. Then, S generates the user’s public-private key pair du,Qu←SℒKeyGen based on the public parameter Param and the leak function ℒKeyGen and publishes the public key list Qui. Next, the adversary A launches an encrypted query and the simulator S generates an encrypted database EDB←SℒEncrypt and returns it to A. Then, the simulator S uses the leak function of the trapdoor to generate a search trapdoor Twk←SℒTrapdoor in response to a trapdoor query from A. After the adversary issues a search query, the simulator returns the result RS←SℒSearch using the leak function of the search. Finally, the adversary A outputs a bit b∈0,1.
SchemeΠ satisfies ℒ-adaptive security if for any probabilistic polynomial time (PPT) adversary A, there exists a PPT simulator S such that(1)PrRealAΠκ=1−PrIdealA,SΠκ=1≤neglκ,where neglκ is a negligible function.


## 3.5. Design Goals

Combining the above system model and practical application requirements, our scheme should meet the following functional objectives:(i)
Supervisibility. Supervision can ensure the controllability of the cryptographic data. The SUP needs to supervise the encrypted data in the CS and the DU’s search requests to ensure that the data can be stored and used in a legal and compliant manner.(ii)
Multi-user Search. Multiuser search is a basic function in data sharing scenarios. In this scenario, multiple DUs need to be authorized to access the encrypted data to provide easier data retrieval services.(iii)
Dynamic Update. It is an important function of the dynamic searchable encryption scheme. First, after DO generates data files containing preexisting keywords, the encrypted data structure corresponding to the keywords in BC and the data files in CS need to be updated. Secondly, in the multiuser scenario, dynamic update of authorized user DU needs to be implemented.


## 4. A Multiuser Normalized Searchable Encryption Scheme via Blockchain

In this section, we describe the specific construction of BNSE in detail and present its security proof. The algorithms are constructed as follows.Setupκ: the setup algorithm takes the security parameter κ as input. It generates parameters G1,G2,q,P,e for the bilinear map system, where G1 is an additive group and G2 is a multiplicative group with the same prime order q, P is a generator of G1, and e:G1×G1⟶G2 is a bilinear map. Then, the algorithm picks several secure hash functions H0,H1,H2,H3,H4,h1,h2,h3,h4, where H0,H1,H2,H3,H4 involve the elements on G1 or G2, H0:G1⟶ℤq∗, H1:0,1∗⟶G1, H2:0,1∗×0,1∗⟶0,1κ+1, H3:G2⟶0,12κ, H4:G2⟶0,1κ, h1:0,1κ⟶0,12κ, h2:0,1κ⟶0,12κ+logMmax, h3:0,1κ×0,1logMmax⟶0,12κ, and h4:0,1κ×0,1logMmax⟶0,1κ+logMmax+1. Then, the algorithm selects a pseudorandom function F:0,1κ×0,1κ⟶0,1κ, with the inverse permutation F−1. Finally, it outputs the public parameter(2)Param=G1,G2,q,P,e,H0,1,2,3,4,h1,2,3,4,F,F−1.KeyGenParam: du∈ℤq∗ is generated randomly, and Du=du·P is computed. The private key of date user is du, and Du is a secret value to derive the public key. Given the public key of supervisor Qsup, tu∈ℤq∗ is randomly selected and Qu1=tu·Du, Qu2=du·tu·Qsup+Du, and Qu3=H0Du·P are computed. Then, the key generation algorithm outputs the user’s public key(3)Qu=Qu1,Qu2,Qu3.EncryptParam,Qui,DB,Σ: the input parameters of the encryption algorithm contain the system public parameter Param, the authorized data users’ public key Quii∈1,n, where n is the number of authorized users, DB=OP,IND,W, where OP=add,deladd means add file and del means delete files), IND=ind1,ind2,…,indm, W=w1,w2,…,wD, Indwk=indwk1,…,indwkmwkmwk is the number of files containing the keyword wk, and Σkey=value is a mapping that stores the keyword state pointer, which is able to trace back to the last update of the files including the keyword. Then, the following steps are performed:(1)
r∈ℤq∗ is randomly selected, and the version information VI=r·P is computed for the encrypted database.(2)
Knowing that the authorized users of the encrypted data areuii∈1,n and each user’s public key is Qui=Qui1,Qui2,Qui3, s∈ℤq∗ is chosen at random, and let the vector Z⟶=zn,…,z0, where zi is the coefficient of zi in the polynomial ∏i=1nz−Hr·Qui3+s.(3)
For each keywordwk in the keyword set W:(1)
The state pointer mapΣwk⟶ptwkc,c of the keyword wk is retrieved. If the retrieval result is empty, then the state of the current keyword is initialized. Let c←0 and ptwkc←0,1κ, where ptwk0 is not involved in information storage and c is the number of times the keyword wk is updated. If the retrieval result is not empty, no initialization is required. The pseudorandom permutation key kwkc+1←0,1κ is randomly generated, and ptwkc+1=Fkwkc+1,ptwkc is calculated. Subsequently, the local mapping Σwk=ptwkc+1,c+1 is updated.(2)
Given the current keyword’s state pointerptwkc+1 and the symmetric key key of the encrypted file, refptwkc+1=h1ptwkc+1 and incptwkc+1=mwkkwkc+1key⊕h2ptwkc+1 are computed, where mwk=Indwk.(3)
For each file indexindwkj in Indwk, j∈1,mk, the encrypted index EIwkj=H2s,wk‖j⊕op‖indwkj is computed, and then, refindwkj=h3ptwkc+1,j and incindwkj=j‖EIwkj⊕h4ptwkc+1,j are computed.(4)
The trapdoortwk=eH1wk,s·P is computed, and then, reftwk=H3twk and inctwk=ptwkc+1⊕H4twk are computed.(4)
The encrypted database is obtained through the above calculation.(4)EDB=refptwkc+1,incptwkc+1,refindwkj,incindwkjj∈1,mwk,<reftwk,inctwk>.The encrypted database is uploaded in the form of key-value pairsEDBrefptwkc+1=incptwkc+1, EDBrefindwkj=incindwkj, and EDBreftwk=inctwk to the blockchain ledger via the smart contract as a searchable cryptographic data structure of keywords.UpdateParam,Qui,ui′,wk,r,s: the input parameters include the system parameter Param, the set of users to be authorized ui′i′∈n,n′, where n′ is the number of all authorized users, and the secret values r,s saved by the data owner, where the random number r involves the version information of keyword wk and the secret value s is used to generate the trapdoor and encrypted index. Authorization update is performed on the file index set Indwk containing the keyword wk. The vector Z′⟶=zn′,…,z0′ is computed, where zi′ is the coefficient of zi in the polynomial ∏i=1n′z−H0r·Qui′3+s and n′ is the total number of all authorized users.To improve the computation efficiency, the original polynomial ciphertextfz can be used to perform the computation by first subtracting the polynomial fz from the secret value s and then multiplying fz−s with the term generated by the public keys of the users to be authorized to get a new polynomial. Finally, the secret value s is embedded into this polynomial to get a new authorized polynomial f′z. The update process only needs to calculate the relevant terms of the user to be authorized based on the original secret text. In addition, the previously authorized users can still use the original vector Z⟶ to compute the trapdoor and decryption.TrapdoorParam,dui,wk: with the system parameter Param as input, only the authorized user uii∈1,n can use his private key dui to compute the trapdoor of the keyword wk. The steps of the trapdoor calculation are as follows:(1)
The version informationVI=r·P of the keyword wk is obtained. Dui=dui·P is computed such that V=H0Dui·VI, and H0V0,H0V1,…,H0Vn are computed.(2)
SinceH0V is a root of the polynomial ∏i=1nz−H0r·Qui3, ∑i=0nzjH0Vi=s is computed to get the secret value s.(3)
The trapdoor of the keywordwk is output.(5)Twk=eH1wk,s·P.SearchParam,Twk,EDB: the search algorithm is the inverse process of the encryption algorithm, with the public parameter Param, the trapdoor Twk of the keyword wk, and the encrypted database EDB as input parameters. An empty set RSwk←∅ is initialized to store the search results. Then, the following steps are performed:(1)
Given the trapdoorTwk, reftwk′=H3Twk is computed. inctwk′=EDBreftwk′ is retrieved from the encrypted database. If inctwk′=⊥, then the search algorithm is terminated and the search result RSwk=∅ is returned. Otherwise, ptwkc+1=H4Twk⊕inctwk′ is computed.(2)
refptwkc+1′=h1ptwkc+1 is computed, and incptwkc+1′=EDBrefptwkc+1′ is retrieved. If incptwkc+1′=⊥, the search algorithm is terminated and the search result set RSwk is returned. Otherwise, mwkkwkc+1key=incptwkc+1′⊕h2ptwkc+1 is computed.(3)
For eachj∈1,mwk, refindwkj′=h3ptwkc+1,j is computed and incindwkj′=EDBrefindwkj′ is retrieved. j,EIwkj=incindwkj′⊕h4ptwkc+1,j is computed, and then, j,EIwkj is inserted into the search result set RSwk.(4)
Using the state pointerptwkc+1 of the keyword wk and the pseudorandom permutation key kwkc+1 obtained in step 2, the previous state pointer ptwkc=F−1kwkc+1,ptwkc+1 is computed. Let ptwkc+1=ptwkc, and then, step 2 is proceeded.DecryptParam,dui,wk,RSwk: the decryption algorithm is used to decrypt the encrypted indexes in the search results RSwk. Using the secret value s computed in step 2 of the trapdoor algorithm Trapdoor, for each record j,EIwkj of the result set RSwk, op‖indwkj=EIwkj⊕H2s,wk‖j is computed. If op=add, the index indwkj is used to access the corresponding data ciphertext from the cloud server CS and decrypt the ciphertext using the key key obtained in step 2 of the search algorithm to get the plaintext data file. If op=add, it means this file index has been deleted and there is no need to access this file in the cloud server.SuperviseParam,Qui,dsup, W∗: the input parameters include system parameter Param, public keys Qui=Qui1,Qui2,Qui3 of authorized users, the private key dsup of supervisor, and the set of sensitive words W∗. Qui2−dsup·Qui1 is computed to obtain Dui, and the steps are subsequently performed in the trapdoor algorithm Trapdoor to compute the secret value s. After obtaining a set of secret values S=s, the supervisor generates search trapdoors Twk for each secret value s of the sensitive word wk∈W∗. Then, the hash value H4Twk of the trapdoor is calculated and the hash values in the list Lh are stored and uploaded to the BC through the smart contract to realize the supervision of search requests. Second, the trapdoor set Twk is used to get the matching file index ciphertext by executing the search smart contract and the ciphertext is decrypted using the secret value s to get the file index. Finally, the index is used to locate the illegal file containing the sensitive word wk∈W∗ in CS to achieve the supervision of the ciphertext data in CS.Correctness analysis: when generating the searchable encrypted data structure, a broadcast polynomialfz=∏i=1nz−H0r·Qui3+s is constructed. The authorized user ui∈u1,…,un is able to use his private key dui to compute(6)H0H0dui·P·VI=H0H0Dui·r·P=H0r·Qui3.After obtaining the secret values by substituting H0r·Qui3 into the broadcast ciphertext, the search trapdoor Twk=eH1wk,s·P is computed. The trapdoor search steps are described in the soundness proof of the security proof subsection. As for the ciphertext data supervision, given the private key dsup of the supervisor and the partial public key Qui1,Qui2 of the authorized user, Dui is computed as follows:(7)Qui2−dsup·Qui1=dui·tui·Qsup+Dui−dsup·tui·Dui=dui·tui·Qsup+Dui−dui·tui·Qsup=Dui.After gettingDui, the secret value s used for searching and decryption can be calculated as formula (1).Theorem 1.
The BMNSE schemeΠ is a ℒ-adaptive secure searchable encryption if F is a pseudorandom permutation function, the hash function is collision-resistant, the DBDH difficulty problem holds, and the polynomial-based broadcast encryption algorithm is adaptively secure.Proof.
We demonstrate the adaptive security of the scheme through a sequence of games similar to reference [11]. The first game G1 is the real-world game RealAΠκ. Each game is slightly different from the previous one, but they are indistinguishable from the adversary, finally reaching the last ideal world game IdealA,SΠκ. According to the transmission property of indistinguishability, it can be concluded that RealAΠκ is indistinguishable from IdealA,SΠκ, thus completing the proof of confidentiality.
In the second gameG2, it maintains a list of state pointers PList for storing state pointers; i.e., PListw,c=ptc. The state pointers are used in the encryption algorithm, and the game G2 randomly chooses a string ptc←R0,1κ to generate the state pointers instead of using the pseudorandom permutation function F. Because the pseudorandom substitution function F is indistinguishable from the actual random function, the games G2 and G1 are indistinguishable.(8)PrG1=1=PrG2=1.
In the third gameG3, it models all hash functions as random oracles, where each oracle maintains a list to store input/output pairs. For example, given a random oracle H1 with input x, the oracle randomly selects a string y←R0,1l as output, where l is the output length of the hash function, and stores x,y in the list H1-List. Because the hash function is collision-resistant, the games G2 and G3 are indistinguishable.(9)PrG2=1=PrG3=1.
In the fourth gameG4, it computes stwk∈G2 on the basis of twk=eH1wk,s·P by randomly choosing a secret value s in the encryption phase. Also, the game G4 needs to maintain a list TList for storing wk,stwk in response to the trapdoor query from the adversary A. P,sP,H0wk,twk is a tuple based on the DBDH problem, and P,sP,H0wk,twk is a random tuple. If the adversary A can distinguish the games G3 and G4, it means that the adversary is able to distinguish the two tuples, i.e., solve the DBDH problem, which is contrary to the assumption of the hard problem. Thus, the games G3 and G4 are indistinguishable.(10)PrG4=1−PrG3=1≤AdvADBDHκ.
In the last gameG5, the simulator S maintains two lists, one for simulating random oracle queries and another counter that keeps track of the number of encryption updates since the system was initialized. For each encryption query, two random strings are selected. The simulator uses the encryption history to determine the encryption queries for the keyword w. Based on the encryption history, state pointers and keys can be generated and then the random oracle is updated. In the adversary’s perspective, the view generated by the simulator S is completely indistinguishable from the view in the game G4.(11)PrG4=1=PrG5=1=PrIdealA,SΠκ.
Summing up, we can get(12)PrRealAΠκ=1−PrIdealA,SΠκ=1≤AdvADBDHκ,where the advantage of solving the difficult DBDH problem AdvADBDHκ is negligible, so our proposed scheme Π is a ℒ-adaptive secure searchable encryption scheme.


## 5. A Blockchain-Based Normalized Searchable Encryption System for Medical Data

In this section, we present our design of the BNSEM system based on the BNSE scheme presented in the preceding section.


### 5.1. System Architecture

We divide the BNSEM system into three layers: data collection layer, medical data processing layer, and medical data access layer. The system architecture is shown in Figure2. The entities in the system are roughly the same as those in the BNSE scheme, and the difference is that the entities in the medical system are all medical service providers/users, including the medical data owner (MDO), medical data user (MDU), medical cloud server (MCS), and medical consortium blockchain platform (MCB).Figure 2
System architecture of BNSEM.In the medical data collection layer, medical data are mainly generated by doctors and patients. On the one hand, patients will generate corresponding medical data when they visit hospitals. On the other hand, the health data will be generated when patients use home medical tools or wearable medical monitoring devices, which can be used as reference indicators for the diagnosis of doctors.In the medical data processing layer, the patients need to preprocess the data before uploading, including encrypting the medical data, establishing the index of medical file, extracting the keywords in the medical file, and constructing a searchable structure based on the file index and the keywords. Finally, the ciphertext of medical records are uploaded to MCS and the searchable structure are uploaded to MCB.In the medical data access layer, only authorized medical data users can access the patient’s medical data. First, the MDU generates a trapdoor for the target search keyword and sends the search request containing the trapdoor to MCB. Then, the smart contract matches the trapdoor with the searchable structure and returns the corresponding medical file index. Finally, the MDU uses the file index to access medical data in MCS and MCS returns the corresponding data to the MDU.


### 5.2. Medical Data Preprocessing

When a patient goes to the hospital, the doctor makes a diagnosis and generates an electronic medical record. The record includes the diagnosed disease, examination results (medical images, laboratories, etc.), medication prescriptions, and personal information (such as name, age, and gender). Each electronic medical record is treated as a file and has a unique file identifier. The doctor synchronizes the generated medical records to the patient to complete a disease diagnosis process.


#### 5.2.1. Building the Indexes of Medical Records

When owning a specific number of medical data records, the patient can upload the record files. Before uploading, indexes corresponding to the files need to be constructed. For example, when the patient, i.e., MDO, receivesm medical files D=D1,D2,…,Dm, several indexes will be constructed for these files. The information related to the files can be embedded into the indexes according to the actual situation, such as the date and size of the files. The file indexes built for m medical data files D are IND=ind1,ind2,…,indm.


#### 5.2.2. Extracting Keywords from Medical Records

MDO performs keyword extraction for the keywords contained in each file inD. For medical data files, we mainly consider the keyword extraction of name, gender, and age in basic information, disease name, drug prescription in medical indicators, and doctor, hospital, and visit time in treatment information.


#### 5.2.3. Constructing the Inverse Indexes

The keywordsWind1,Wind2,…,Windm extracted from different medical data files in D were integrated to obtain the keyword dictionary W=w1,w2,…,wD. Then, for each keyword wk in the keyword dictionary W, the inverse index Indwk containing the keyword is constructed. A specific construction of the inverse index of medical record files is shown in Figure 3.Figure 3
Process of constructing the inverse indexes.


### 5.3. Medical Consortium Block Chain Platform

In BNSEM system, Hyperledger Fabric is chosen as the medical consortium blockchain (MCB) platform. Because Fabric has a strict access mechanism, it can be managed collaboratively in a polycentric manner by entities from multiple organizations. In addition, the consortium blockchain can best balance the security and efficiency of the system compared with public and private blockchains. Initial access control can be achieved through the access mechanism of Fabric. By deploying smart contracts of Fabric, more fine-grained data access control can be realized.MCB is a federation of multiple healthcare providers, which is built and maintained by different entities such as hospitals, research institutions, regulatory bodies (e.g., healthcare commissions), and insurance and pharmaceutical companies. Organizations with high trust level preselect some peer nodes as consensus nodes according to their management policies (e.g., supervision institutions and hospital management nodes). These designated consensus nodes are responsible for managing and updating the distributed ledger, while other peer nodes can only generate or contribute healthcare data transactions. Consensus nodes require a certain amount of computing power to perform consensus algorithms on transactions. In addition, if the number of consensus nodes increases, the degree of decentralization of the system increases and security and scalability can be improved.MCB enables search structured storage and encrypted medical data retrieval by invoking predesigned and deployed smart contracts. Before MCB operates, the consortium members need to define a number of contracts developed by different organizations covering common terminology, data, rules, and processes to specify the model of data storage and sharing. A client application invokes a smart contract to execute the search protocol. When the execution is complete, the smart contract records the results (i.e., state changes) in the distributed ledger of MCB. Together with the ledger, smart contracts form the core part of the MCB system.


### 5.4. System Design

#### 5.4.1. System Setup

Before the system runs, TI sets security parametersκ and generates system public parameters Param. The system parameters Param include bilinear operation parameters G1,G2,q,P,e, hash functions H/h with different output lengths, and pseudorandom permutation functions F/F−1 with reference to the setup algorithm in Section 4. The system selects AES algorithm as the pseudorandom permutation function to excrypt medical data. The medical data users in the system mainly include the data users’ MDUs and the supervisory institution SUP. Before the users join the system, they need to generate a set of public-private key pairs for data authorization. The public-private key pair of SUP is dsup,Qsup. The public-private key pair of MDU is du,Qu, which is computed in the setup algorithm.


#### 5.4.2. Encryption and Updating of Medical Data

After the system is initialized, MDO will store the encrypted medical data and the corresponding searchable structure to authorize access by multiple MDUs. When patients visit the hospital and get multiple electronic medical records, these medical records will be preprocessed as described in subsection B. Next, MDO gets the file index setIND=ind1,ind2,…,indm, the keyword dictionary W=w1,w2,…,wD, and the file index set Indwk=Indwk1,Indwk2,…. Let the database DB=IND,W,Indwkwk∈W, and a mapping Σ stored locally for keeping the latest status of keywords (i.e., status pointer) is initialized. Then, n MDUs are specified to be authorized, denoted as uii∈1,n, whose public key is Qui.Taking the above parameters as input, the Encrypt data encryption algorithm in Section4 is invoked to encrypt the medical record database DB to obtain the encrypted database; i.e., searchable data structure EDB=refptwkc+1,incptwkc+1,refIndwkj,incIndwkjj∈1,mwk,reftwk,inctwk, where the variable ref is a reference to the subscript value and inc hides the information of the medical file indexes. After generating the encrypted database EDB, the key-value pairs EDBrefptwkc+1=incptwkc+1,EDBrefindwkj=incIndwkj,EDBreftwk=inctwk are uploaded to MCB through a smart contract.Updates include medical data update and authorized user update. There are two types of medical data update: adding and deleting medical record files. When adding medical record files, MDO obtains the state pointerptwkc for the same keyword wk′ as in the previous keyword dictionary W and invokes the Encrypt encryption algorithm in Section 4 to encrypt the newly added medical record database DB′ to update it. When deleting medical record files, MDO performs the operation differently by selecting the del option from OP=add,del. The update of authorized medical data users is achieved by reconstructing the broadcast ciphertext. MDO adds the specified medical data user MDUs as ui′i′∈n+1,n′, where n′ is the total number of new and old authorized users, and the calculation method refers to the Update algorithm.


#### 5.4.3. Retrieval of Encrypted Medical Data

When a patient (MDO) goes to another hospital for treatment, the authorized doctor (MDU) reviews the patient’s past medical records to assist in the diagnosis. The search process for medical records is as follows:Step 1. MDU selects a keywordwk (e.g., hypertension) and generates the search trapdoor Twk by invoking the trapdoor algorithm using his private key.Step 2. MDU sends a search request containing the search trapdoorTwk to the smart contract.Step 3. The smart contract matches the trapdoorTwk with the search structure EDB stored in the blockchain to obtain the encrypted medical indexes EIwkj according to the search algorithm.Step 4. MDU uses the secret values to decrypt the ciphertext index EIwkj to get the plaintext index indwkj and the option add/del corresponding to the index and the file decryption key, key.Step 5. If the option isdel, it indicates that the file has been deleted and no access is needed. On the contrary, MDU will access the medical data stored in the MCS with the indexes.Step 6. MDU decrypts the medical record ciphertext returned from MCS to get the medical record fileD using key.


#### 5.4.4. Supervision of Medical Data and Search Requests

To ensure that the data in BNSEM system can be stored and used legally, supervisors such as the healthcare commission are required to regularly review the encrypted medical data in MCS and monitor the search requests of MDUs in real time. First, SUP maintains a sensitive word dictionaryW′, which includes sensitive keywords such as prohibited drugs, illegal hospitals, and fake doctors. Next, SUP invokes the supervise supervisory algorithm to locate the illegal files containing sensitive words in MCS using the private key dsup. Then, SUP generates trapdoors for each sensitive word in W′, and after hash calculation, a trapdoor hash list is obtained. Finally, SUP uploads the hash list to MCB through smart contracts to filter trapdoors in search requests and intercept the illegal requests containing sensitive words.


## 5.1. System Architecture

We divide the BNSEM system into three layers: data collection layer, medical data processing layer, and medical data access layer. The system architecture is shown in Figure2. The entities in the system are roughly the same as those in the BNSE scheme, and the difference is that the entities in the medical system are all medical service providers/users, including the medical data owner (MDO), medical data user (MDU), medical cloud server (MCS), and medical consortium blockchain platform (MCB).Figure 2
System architecture of BNSEM.In the medical data collection layer, medical data are mainly generated by doctors and patients. On the one hand, patients will generate corresponding medical data when they visit hospitals. On the other hand, the health data will be generated when patients use home medical tools or wearable medical monitoring devices, which can be used as reference indicators for the diagnosis of doctors.In the medical data processing layer, the patients need to preprocess the data before uploading, including encrypting the medical data, establishing the index of medical file, extracting the keywords in the medical file, and constructing a searchable structure based on the file index and the keywords. Finally, the ciphertext of medical records are uploaded to MCS and the searchable structure are uploaded to MCB.In the medical data access layer, only authorized medical data users can access the patient’s medical data. First, the MDU generates a trapdoor for the target search keyword and sends the search request containing the trapdoor to MCB. Then, the smart contract matches the trapdoor with the searchable structure and returns the corresponding medical file index. Finally, the MDU uses the file index to access medical data in MCS and MCS returns the corresponding data to the MDU.


## 5.2. Medical Data Preprocessing

When a patient goes to the hospital, the doctor makes a diagnosis and generates an electronic medical record. The record includes the diagnosed disease, examination results (medical images, laboratories, etc.), medication prescriptions, and personal information (such as name, age, and gender). Each electronic medical record is treated as a file and has a unique file identifier. The doctor synchronizes the generated medical records to the patient to complete a disease diagnosis process.


### 5.2.1. Building the Indexes of Medical Records

When owning a specific number of medical data records, the patient can upload the record files. Before uploading, indexes corresponding to the files need to be constructed. For example, when the patient, i.e., MDO, receivesm medical files D=D1,D2,…,Dm, several indexes will be constructed for these files. The information related to the files can be embedded into the indexes according to the actual situation, such as the date and size of the files. The file indexes built for m medical data files D are IND=ind1,ind2,…,indm.


### 5.2.2. Extracting Keywords from Medical Records

MDO performs keyword extraction for the keywords contained in each file inD. For medical data files, we mainly consider the keyword extraction of name, gender, and age in basic information, disease name, drug prescription in medical indicators, and doctor, hospital, and visit time in treatment information.


### 5.2.3. Constructing the Inverse Indexes

The keywordsWind1,Wind2,…,Windm extracted from different medical data files in D were integrated to obtain the keyword dictionary W=w1,w2,…,wD. Then, for each keyword wk in the keyword dictionary W, the inverse index Indwk containing the keyword is constructed. A specific construction of the inverse index of medical record files is shown in Figure 3.Figure 3
Process of constructing the inverse indexes.


## 5.2.1. Building the Indexes of Medical Records

When owning a specific number of medical data records, the patient can upload the record files. Before uploading, indexes corresponding to the files need to be constructed. For example, when the patient, i.e., MDO, receivesm medical files D=D1,D2,…,Dm, several indexes will be constructed for these files. The information related to the files can be embedded into the indexes according to the actual situation, such as the date and size of the files. The file indexes built for m medical data files D are IND=ind1,ind2,…,indm.


## 5.2.2. Extracting Keywords from Medical Records

MDO performs keyword extraction for the keywords contained in each file inD. For medical data files, we mainly consider the keyword extraction of name, gender, and age in basic information, disease name, drug prescription in medical indicators, and doctor, hospital, and visit time in treatment information.


## 5.2.3. Constructing the Inverse Indexes

The keywordsWind1,Wind2,…,Windm extracted from different medical data files in D were integrated to obtain the keyword dictionary W=w1,w2,…,wD. Then, for each keyword wk in the keyword dictionary W, the inverse index Indwk containing the keyword is constructed. A specific construction of the inverse index of medical record files is shown in Figure 3.Figure 3
Process of constructing the inverse indexes.


## 5.3. Medical Consortium Block Chain Platform

In BNSEM system, Hyperledger Fabric is chosen as the medical consortium blockchain (MCB) platform. Because Fabric has a strict access mechanism, it can be managed collaboratively in a polycentric manner by entities from multiple organizations. In addition, the consortium blockchain can best balance the security and efficiency of the system compared with public and private blockchains. Initial access control can be achieved through the access mechanism of Fabric. By deploying smart contracts of Fabric, more fine-grained data access control can be realized.MCB is a federation of multiple healthcare providers, which is built and maintained by different entities such as hospitals, research institutions, regulatory bodies (e.g., healthcare commissions), and insurance and pharmaceutical companies. Organizations with high trust level preselect some peer nodes as consensus nodes according to their management policies (e.g., supervision institutions and hospital management nodes). These designated consensus nodes are responsible for managing and updating the distributed ledger, while other peer nodes can only generate or contribute healthcare data transactions. Consensus nodes require a certain amount of computing power to perform consensus algorithms on transactions. In addition, if the number of consensus nodes increases, the degree of decentralization of the system increases and security and scalability can be improved.MCB enables search structured storage and encrypted medical data retrieval by invoking predesigned and deployed smart contracts. Before MCB operates, the consortium members need to define a number of contracts developed by different organizations covering common terminology, data, rules, and processes to specify the model of data storage and sharing. A client application invokes a smart contract to execute the search protocol. When the execution is complete, the smart contract records the results (i.e., state changes) in the distributed ledger of MCB. Together with the ledger, smart contracts form the core part of the MCB system.


## 5.4. System Design

### 5.4.1. System Setup

Before the system runs, TI sets security parametersκ and generates system public parameters Param. The system parameters Param include bilinear operation parameters G1,G2,q,P,e, hash functions H/h with different output lengths, and pseudorandom permutation functions F/F−1 with reference to the setup algorithm in Section 4. The system selects AES algorithm as the pseudorandom permutation function to excrypt medical data. The medical data users in the system mainly include the data users’ MDUs and the supervisory institution SUP. Before the users join the system, they need to generate a set of public-private key pairs for data authorization. The public-private key pair of SUP is dsup,Qsup. The public-private key pair of MDU is du,Qu, which is computed in the setup algorithm.


### 5.4.2. Encryption and Updating of Medical Data

After the system is initialized, MDO will store the encrypted medical data and the corresponding searchable structure to authorize access by multiple MDUs. When patients visit the hospital and get multiple electronic medical records, these medical records will be preprocessed as described in subsection B. Next, MDO gets the file index setIND=ind1,ind2,…,indm, the keyword dictionary W=w1,w2,…,wD, and the file index set Indwk=Indwk1,Indwk2,…. Let the database DB=IND,W,Indwkwk∈W, and a mapping Σ stored locally for keeping the latest status of keywords (i.e., status pointer) is initialized. Then, n MDUs are specified to be authorized, denoted as uii∈1,n, whose public key is Qui.Taking the above parameters as input, the Encrypt data encryption algorithm in Section4 is invoked to encrypt the medical record database DB to obtain the encrypted database; i.e., searchable data structure EDB=refptwkc+1,incptwkc+1,refIndwkj,incIndwkjj∈1,mwk,reftwk,inctwk, where the variable ref is a reference to the subscript value and inc hides the information of the medical file indexes. After generating the encrypted database EDB, the key-value pairs EDBrefptwkc+1=incptwkc+1,EDBrefindwkj=incIndwkj,EDBreftwk=inctwk are uploaded to MCB through a smart contract.Updates include medical data update and authorized user update. There are two types of medical data update: adding and deleting medical record files. When adding medical record files, MDO obtains the state pointerptwkc for the same keyword wk′ as in the previous keyword dictionary W and invokes the Encrypt encryption algorithm in Section 4 to encrypt the newly added medical record database DB′ to update it. When deleting medical record files, MDO performs the operation differently by selecting the del option from OP=add,del. The update of authorized medical data users is achieved by reconstructing the broadcast ciphertext. MDO adds the specified medical data user MDUs as ui′i′∈n+1,n′, where n′ is the total number of new and old authorized users, and the calculation method refers to the Update algorithm.


### 5.4.3. Retrieval of Encrypted Medical Data

When a patient (MDO) goes to another hospital for treatment, the authorized doctor (MDU) reviews the patient’s past medical records to assist in the diagnosis. The search process for medical records is as follows:Step 1. MDU selects a keywordwk (e.g., hypertension) and generates the search trapdoor Twk by invoking the trapdoor algorithm using his private key.Step 2. MDU sends a search request containing the search trapdoorTwk to the smart contract.Step 3. The smart contract matches the trapdoorTwk with the search structure EDB stored in the blockchain to obtain the encrypted medical indexes EIwkj according to the search algorithm.Step 4. MDU uses the secret values to decrypt the ciphertext index EIwkj to get the plaintext index indwkj and the option add/del corresponding to the index and the file decryption key, key.Step 5. If the option isdel, it indicates that the file has been deleted and no access is needed. On the contrary, MDU will access the medical data stored in the MCS with the indexes.Step 6. MDU decrypts the medical record ciphertext returned from MCS to get the medical record fileD using key.


### 5.4.4. Supervision of Medical Data and Search Requests

To ensure that the data in BNSEM system can be stored and used legally, supervisors such as the healthcare commission are required to regularly review the encrypted medical data in MCS and monitor the search requests of MDUs in real time. First, SUP maintains a sensitive word dictionaryW′, which includes sensitive keywords such as prohibited drugs, illegal hospitals, and fake doctors. Next, SUP invokes the supervise supervisory algorithm to locate the illegal files containing sensitive words in MCS using the private key dsup. Then, SUP generates trapdoors for each sensitive word in W′, and after hash calculation, a trapdoor hash list is obtained. Finally, SUP uploads the hash list to MCB through smart contracts to filter trapdoors in search requests and intercept the illegal requests containing sensitive words.


## 5.4.1. System Setup

Before the system runs, TI sets security parametersκ and generates system public parameters Param. The system parameters Param include bilinear operation parameters G1,G2,q,P,e, hash functions H/h with different output lengths, and pseudorandom permutation functions F/F−1 with reference to the setup algorithm in Section 4. The system selects AES algorithm as the pseudorandom permutation function to excrypt medical data. The medical data users in the system mainly include the data users’ MDUs and the supervisory institution SUP. Before the users join the system, they need to generate a set of public-private key pairs for data authorization. The public-private key pair of SUP is dsup,Qsup. The public-private key pair of MDU is du,Qu, which is computed in the setup algorithm.


## 5.4.2. Encryption and Updating of Medical Data

After the system is initialized, MDO will store the encrypted medical data and the corresponding searchable structure to authorize access by multiple MDUs. When patients visit the hospital and get multiple electronic medical records, these medical records will be preprocessed as described in subsection B. Next, MDO gets the file index setIND=ind1,ind2,…,indm, the keyword dictionary W=w1,w2,…,wD, and the file index set Indwk=Indwk1,Indwk2,…. Let the database DB=IND,W,Indwkwk∈W, and a mapping Σ stored locally for keeping the latest status of keywords (i.e., status pointer) is initialized. Then, n MDUs are specified to be authorized, denoted as uii∈1,n, whose public key is Qui.Taking the above parameters as input, the Encrypt data encryption algorithm in Section4 is invoked to encrypt the medical record database DB to obtain the encrypted database; i.e., searchable data structure EDB=refptwkc+1,incptwkc+1,refIndwkj,incIndwkjj∈1,mwk,reftwk,inctwk, where the variable ref is a reference to the subscript value and inc hides the information of the medical file indexes. After generating the encrypted database EDB, the key-value pairs EDBrefptwkc+1=incptwkc+1,EDBrefindwkj=incIndwkj,EDBreftwk=inctwk are uploaded to MCB through a smart contract.Updates include medical data update and authorized user update. There are two types of medical data update: adding and deleting medical record files. When adding medical record files, MDO obtains the state pointerptwkc for the same keyword wk′ as in the previous keyword dictionary W and invokes the Encrypt encryption algorithm in Section 4 to encrypt the newly added medical record database DB′ to update it. When deleting medical record files, MDO performs the operation differently by selecting the del option from OP=add,del. The update of authorized medical data users is achieved by reconstructing the broadcast ciphertext. MDO adds the specified medical data user MDUs as ui′i′∈n+1,n′, where n′ is the total number of new and old authorized users, and the calculation method refers to the Update algorithm.


## 5.4.3. Retrieval of Encrypted Medical Data

When a patient (MDO) goes to another hospital for treatment, the authorized doctor (MDU) reviews the patient’s past medical records to assist in the diagnosis. The search process for medical records is as follows:Step 1. MDU selects a keywordwk (e.g., hypertension) and generates the search trapdoor Twk by invoking the trapdoor algorithm using his private key.Step 2. MDU sends a search request containing the search trapdoorTwk to the smart contract.Step 3. The smart contract matches the trapdoorTwk with the search structure EDB stored in the blockchain to obtain the encrypted medical indexes EIwkj according to the search algorithm.Step 4. MDU uses the secret values to decrypt the ciphertext index EIwkj to get the plaintext index indwkj and the option add/del corresponding to the index and the file decryption key, key.Step 5. If the option isdel, it indicates that the file has been deleted and no access is needed. On the contrary, MDU will access the medical data stored in the MCS with the indexes.Step 6. MDU decrypts the medical record ciphertext returned from MCS to get the medical record fileD using key.


## 5.4.4. Supervision of Medical Data and Search Requests

To ensure that the data in BNSEM system can be stored and used legally, supervisors such as the healthcare commission are required to regularly review the encrypted medical data in MCS and monitor the search requests of MDUs in real time. First, SUP maintains a sensitive word dictionaryW′, which includes sensitive keywords such as prohibited drugs, illegal hospitals, and fake doctors. Next, SUP invokes the supervise supervisory algorithm to locate the illegal files containing sensitive words in MCS using the private key dsup. Then, SUP generates trapdoors for each sensitive word in W′, and after hash calculation, a trapdoor hash list is obtained. Finally, SUP uploads the hash list to MCB through smart contracts to filter trapdoors in search requests and intercept the illegal requests containing sensitive words.


## 6. Security Analysis

### 6.1. Forward Privacy

The requirement of forward privacy is that given a previous search trapdoor, the update query does not reveal information about the keywords that were searched in the past; i.e., the previous keyword trapdoor cannot be used to search medical records newly added after the trapdoor was released. In the BNSEM system, the trapdoorTwk is equivalent to a state pointer of keyword wk. With the help of this pointer, the smart contract will find the latest state ptwkc+1 of the keyword wk, which is used to locate the corresponding encrypted medical file index EIindjwk, where j=1,…,mwk. The smart contract then computes the last updated state ptwkc=F−1kwkc+1,ptwkc+1 to search the previously updated medical files.When updating the medical files containing the keywordwk, MDO will compute a new status pointer ptwkc+2=Fkwkc+2,ptwkc+2, which is used to encrypt the file indexes and generate the searchable structure reftwk,inctwk corresponding to the latest version information VI. Due to the security of the pseudorandom permutation function VI, the adversary cannot predict the next state pointer based on the current state pointer ptwkc+1 and the version information. Therefore, the previous search trapdoor cannot be used to search the medical data updated afterward, so forward privacy is guaranteed. The BNSEM system that implements forward privacy can effectively resist file injection attacks and avoid adversaries from inferring the keyword contained in a trapdoor.


### 6.2. Backward Privacy

Backward privacy limits the updated information of a keywordw that an adversary can obtain during a search query on the keyword w. That is, a searchable encryption system satisfies backward privacy if after a keyword-file index pair w,ind is added to the database and then deleted, and a search query on the keyword w will not disclose the index ind. In BNSEM system, encrypting a medical file index yields EIwkj=H2s,wk‖j⊕op‖indwkj, where the secret value s is broadcast encrypted using the authorized MDUs’ public key and can only be decrypted by the authorized MDUs. Since the search result is in the form of ciphertext, even if it is stored publicly on the MCB, the adversary cannot decrypt the broadcast ciphertext to recover the secret value s and cannot learn any useful information about the indexes of medical files. Therefore, the backward privacy of BNSEM can be achieved.


### 6.3. Distribution

Although BNSEM requires the use of a centralized MCS to store encrypted data, the search process is accomplished by smart contracts, which ensures the reliability and correctness of search results. First, to achieve the retrieval of encrypted medical data, the MDO uploads the searchable data structure to the distributed MCB platform by invoking the smart contract with storage function. Second, the MDU runs the trapdoor algorithm and uploads the trapdoor to trigger the smart contract with the search function. The correctness of the whole search process does not rely on the MCS, enabling decentralized search.The blockchain is distributed, and each blockchain node is relatively independent and must be authenticated to join the system. It is difficult for the adversary to manipulate a large number of nodes at the same time to change the network rules and damage the blockchain system, which can effectively resist Sybil attack. In addition, since each search is recorded as an immutable transaction on the blockchain, the number of search requests sent by each MDU cannot be tampered with. The online keyword guessing attack (KGA) can be effectively resisted by setting an upper limit on the number of MDU’s requests.


## 6.1. Forward Privacy

The requirement of forward privacy is that given a previous search trapdoor, the update query does not reveal information about the keywords that were searched in the past; i.e., the previous keyword trapdoor cannot be used to search medical records newly added after the trapdoor was released. In the BNSEM system, the trapdoorTwk is equivalent to a state pointer of keyword wk. With the help of this pointer, the smart contract will find the latest state ptwkc+1 of the keyword wk, which is used to locate the corresponding encrypted medical file index EIindjwk, where j=1,…,mwk. The smart contract then computes the last updated state ptwkc=F−1kwkc+1,ptwkc+1 to search the previously updated medical files.When updating the medical files containing the keywordwk, MDO will compute a new status pointer ptwkc+2=Fkwkc+2,ptwkc+2, which is used to encrypt the file indexes and generate the searchable structure reftwk,inctwk corresponding to the latest version information VI. Due to the security of the pseudorandom permutation function VI, the adversary cannot predict the next state pointer based on the current state pointer ptwkc+1 and the version information. Therefore, the previous search trapdoor cannot be used to search the medical data updated afterward, so forward privacy is guaranteed. The BNSEM system that implements forward privacy can effectively resist file injection attacks and avoid adversaries from inferring the keyword contained in a trapdoor.


## 6.2. Backward Privacy

Backward privacy limits the updated information of a keywordw that an adversary can obtain during a search query on the keyword w. That is, a searchable encryption system satisfies backward privacy if after a keyword-file index pair w,ind is added to the database and then deleted, and a search query on the keyword w will not disclose the index ind. In BNSEM system, encrypting a medical file index yields EIwkj=H2s,wk‖j⊕op‖indwkj, where the secret value s is broadcast encrypted using the authorized MDUs’ public key and can only be decrypted by the authorized MDUs. Since the search result is in the form of ciphertext, even if it is stored publicly on the MCB, the adversary cannot decrypt the broadcast ciphertext to recover the secret value s and cannot learn any useful information about the indexes of medical files. Therefore, the backward privacy of BNSEM can be achieved.


## 6.3. Distribution

Although BNSEM requires the use of a centralized MCS to store encrypted data, the search process is accomplished by smart contracts, which ensures the reliability and correctness of search results. First, to achieve the retrieval of encrypted medical data, the MDO uploads the searchable data structure to the distributed MCB platform by invoking the smart contract with storage function. Second, the MDU runs the trapdoor algorithm and uploads the trapdoor to trigger the smart contract with the search function. The correctness of the whole search process does not rely on the MCS, enabling decentralized search.The blockchain is distributed, and each blockchain node is relatively independent and must be authenticated to join the system. It is difficult for the adversary to manipulate a large number of nodes at the same time to change the network rules and damage the blockchain system, which can effectively resist Sybil attack. In addition, since each search is recorded as an immutable transaction on the blockchain, the number of search requests sent by each MDU cannot be tampered with. The online keyword guessing attack (KGA) can be effectively resisted by setting an upper limit on the number of MDU’s requests.


## 7. Performance Analysis

### 7.1. Performance Comparison

We compare the theoretical performance of our scheme with other multiuser searchable encryption schemes, where the MVSSE [24] and BAEKS [25] schemes are both based on public key cryptography, and Π+[20] is a symmetric searchable encryption scheme. In this study, we compare the computational overheads of the main algorithms of searchable encryption schemes, including encryption algorithm, trapdoor algorithm, and search algorithm. The results of the performance comparison are given in Table 1.Table 1
Comparison of computational overheads.
SchemesEncryptionTrapdoorSearchMVSSE [24]sm+2m∗mul2+2+m∗F+2m∗h2∗sm+2∗mul2+2∗F3∗sm+2m+1∗mul2+m∗F+4m∗hΠ+[20]2m+1∗F5∗F5m∗FBAEKS [25]2n+5∗sm+n∗e+n+1∗hsm+e+mtpn+4∗sm+2∗e+2∗mul2+hOurs2∗sm+e+mtp+F+2m+4∗h3∗sm+e+mtp+h2m+4hThe notations in Table1 are explained as follows: n denotes the number of authorized MDUs and m denotes the number of indexes containing the keyword w. Symbols h, exp, sm, mul2, e, and mtp denote general hash functions (e.g., SHA-256 and SHA-3), exponential operation, scalar multiplication on the group G1, multiplication on the group G2, a bilinear pair from groups G1 to G2, and a map-to-point map. Although the hash functions H0,2,3,4,,h1,2,3,4 used in our scheme differ in input/output lengths, they can all be obtained by simple transformations of the general hash functions and will not add additional complexity. In addition, F/F−1 denotes pseudorandom permutation function (i.e., symmetric cryptography, e.g., AES and DES algorithms). The time overhead of the above operations is shown in Table 2.Table 2
Time cost of basic operations.
Operationsemtpsmmul2F/F−1hTime cost (ms)43.66986.31615.9950.0240.0020.001It shows that the computational overhead of encryption algorithm in most schemes is linearly related to the number of indexesm in Table 1. The BAEKS scheme does not consider the number of indexes containing the keywords. In addition, the encryption computational complexity of BAEKS is linearly related to the number of users, so it is not shown in the computational overhead graph. The scheme Π+ does not describe the broadcast encryption algorithm it uses, so the broadcast encryption overhead cannot be calculated. The encryption computation overheads of our scheme and the MVSSE scheme are 2∗sm+e+mtp+F+2m+4∗h and sm+2m∗mul2+2+m∗F+2m∗h, respectively. Although our scheme contains additional time-consuming operations, they are independent of the number of indexes. The theoretical computational overhead of encryption algorithm for each scheme with respect to the number of file indexes is shown in Figure 4.Figure 4
Comparison of encryption algorithm.As for trapdoor algorithm, the computation overheads of MVSSE,Π+, and our scheme are 2∗sm+2∗mul2+2∗F, 5∗F, and 3∗sm+e+mtp+h, respectively. Although the trapdoor computation overhead of our scheme is slightly higher than other schemes, we avoid key management and distribution operations compared with the symmetric scheme MVSSE. Moreover, the user in the MVSSE scheme cannot generate search trapdoors independently and it requires interactive communication with the server. Similarly, the Π+ scheme requires the data owner to generate and distribute public-private key pairs for multiple recipients, which does not meet the key security specification. The theoretical computational overhead of trapdoor algorithm for each scheme is compared as shown in Figure 5. The computational overhead of our scheme is slightly higher than that of MVSSE scheme, and the trapdoor generation of Π+ scheme only involves pseudorandom permutation operation with minimal time overhead.Figure 5
Comparison of trapdoor algorithm.When performing search operations, the MVSSE scheme contains multiple scalar multiplication operations, which will incur a large computation overhead. The search computation overhead of our scheme is lower than that of the symmetric searchable encryption schemeΠ+ because the computations in the main algorithm of our scheme are hash operations or symmetric cryptographic primitives. Therefore, our scheme is a searchable public key scheme with high search performance. Figure 6 shows the variation of the theoretical search computation overhead with the number of indexes for each scheme. Our scheme has the lowest computation overhead, and the MVSSE scheme has the highest time overhead with the number of indexes.Figure 6
Comparison of search algorithm.


### 7.2. Prototype Implementation

We implement our BNSEM system using the MIRACL cryptographic library (C++) on a PC with 16 GB of RAM, Intel Core i5-7500 CPU, OS Windows 10, and a Fabric consortium blockchain on a PC with 16 GB of RAM, Intel Core i5-7500 CPU, and OS Ubuntu 16.04. In addition, we set the system security parameterκ to 128 bits, implement hash functions with different input and output lengths based on SHA-256, and use the AES algorithm in CBC mode as the pseudorandom permutation function with a key length of 128 bits. Finally, we choose a super-singular elliptic curve y2=x3−3x,p=2255+241+1 to achieve the ASE-128 security level. Next, we perform three simulation tests: the time cost of the encryption algorithm with the number of indexes, the time cost of the search algorithm with the number of indexes, and the time cost of all algorithms under a certain number of indexes of our system.To overall evaluate the efficiency of our system, we test the average time overhead of all algorithms under the condition that the number of indexes containing the keyword is 10000, as shown in Figure7. The key generation requires multiple scalar multiplication operations on the G1 group with a time overhead of about 85 ms. In addition, the time to generate a search trapdoor of the keyword is about 166 ms, while the time overhead to encrypt a search structure with 10000 file indexes is only 287 ms, mainly because the trapdoor algorithm requires the time-consuming operations (bilinear pairs and mtp. The search algorithm in the smart contract is efficient with an average time overhead of about 55 ms for 10000 matched results.Figure 7
Time cost of each algorithm.


## 7.1. Performance Comparison

We compare the theoretical performance of our scheme with other multiuser searchable encryption schemes, where the MVSSE [24] and BAEKS [25] schemes are both based on public key cryptography, and Π+[20] is a symmetric searchable encryption scheme. In this study, we compare the computational overheads of the main algorithms of searchable encryption schemes, including encryption algorithm, trapdoor algorithm, and search algorithm. The results of the performance comparison are given in Table 1.Table 1
Comparison of computational overheads.
SchemesEncryptionTrapdoorSearchMVSSE [24]sm+2m∗mul2+2+m∗F+2m∗h2∗sm+2∗mul2+2∗F3∗sm+2m+1∗mul2+m∗F+4m∗hΠ+[20]2m+1∗F5∗F5m∗FBAEKS [25]2n+5∗sm+n∗e+n+1∗hsm+e+mtpn+4∗sm+2∗e+2∗mul2+hOurs2∗sm+e+mtp+F+2m+4∗h3∗sm+e+mtp+h2m+4hThe notations in Table1 are explained as follows: n denotes the number of authorized MDUs and m denotes the number of indexes containing the keyword w. Symbols h, exp, sm, mul2, e, and mtp denote general hash functions (e.g., SHA-256 and SHA-3), exponential operation, scalar multiplication on the group G1, multiplication on the group G2, a bilinear pair from groups G1 to G2, and a map-to-point map. Although the hash functions H0,2,3,4,,h1,2,3,4 used in our scheme differ in input/output lengths, they can all be obtained by simple transformations of the general hash functions and will not add additional complexity. In addition, F/F−1 denotes pseudorandom permutation function (i.e., symmetric cryptography, e.g., AES and DES algorithms). The time overhead of the above operations is shown in Table 2.Table 2
Time cost of basic operations.
Operationsemtpsmmul2F/F−1hTime cost (ms)43.66986.31615.9950.0240.0020.001It shows that the computational overhead of encryption algorithm in most schemes is linearly related to the number of indexesm in Table 1. The BAEKS scheme does not consider the number of indexes containing the keywords. In addition, the encryption computational complexity of BAEKS is linearly related to the number of users, so it is not shown in the computational overhead graph. The scheme Π+ does not describe the broadcast encryption algorithm it uses, so the broadcast encryption overhead cannot be calculated. The encryption computation overheads of our scheme and the MVSSE scheme are 2∗sm+e+mtp+F+2m+4∗h and sm+2m∗mul2+2+m∗F+2m∗h, respectively. Although our scheme contains additional time-consuming operations, they are independent of the number of indexes. The theoretical computational overhead of encryption algorithm for each scheme with respect to the number of file indexes is shown in Figure 4.Figure 4
Comparison of encryption algorithm.As for trapdoor algorithm, the computation overheads of MVSSE,Π+, and our scheme are 2∗sm+2∗mul2+2∗F, 5∗F, and 3∗sm+e+mtp+h, respectively. Although the trapdoor computation overhead of our scheme is slightly higher than other schemes, we avoid key management and distribution operations compared with the symmetric scheme MVSSE. Moreover, the user in the MVSSE scheme cannot generate search trapdoors independently and it requires interactive communication with the server. Similarly, the Π+ scheme requires the data owner to generate and distribute public-private key pairs for multiple recipients, which does not meet the key security specification. The theoretical computational overhead of trapdoor algorithm for each scheme is compared as shown in Figure 5. The computational overhead of our scheme is slightly higher than that of MVSSE scheme, and the trapdoor generation of Π+ scheme only involves pseudorandom permutation operation with minimal time overhead.Figure 5
Comparison of trapdoor algorithm.When performing search operations, the MVSSE scheme contains multiple scalar multiplication operations, which will incur a large computation overhead. The search computation overhead of our scheme is lower than that of the symmetric searchable encryption schemeΠ+ because the computations in the main algorithm of our scheme are hash operations or symmetric cryptographic primitives. Therefore, our scheme is a searchable public key scheme with high search performance. Figure 6 shows the variation of the theoretical search computation overhead with the number of indexes for each scheme. Our scheme has the lowest computation overhead, and the MVSSE scheme has the highest time overhead with the number of indexes.Figure 6
Comparison of search algorithm.


## 7.2. Prototype Implementation

We implement our BNSEM system using the MIRACL cryptographic library (C++) on a PC with 16 GB of RAM, Intel Core i5-7500 CPU, OS Windows 10, and a Fabric consortium blockchain on a PC with 16 GB of RAM, Intel Core i5-7500 CPU, and OS Ubuntu 16.04. In addition, we set the system security parameterκ to 128 bits, implement hash functions with different input and output lengths based on SHA-256, and use the AES algorithm in CBC mode as the pseudorandom permutation function with a key length of 128 bits. Finally, we choose a super-singular elliptic curve y2=x3−3x,p=2255+241+1 to achieve the ASE-128 security level. Next, we perform three simulation tests: the time cost of the encryption algorithm with the number of indexes, the time cost of the search algorithm with the number of indexes, and the time cost of all algorithms under a certain number of indexes of our system.To overall evaluate the efficiency of our system, we test the average time overhead of all algorithms under the condition that the number of indexes containing the keyword is 10000, as shown in Figure7. The key generation requires multiple scalar multiplication operations on the G1 group with a time overhead of about 85 ms. In addition, the time to generate a search trapdoor of the keyword is about 166 ms, while the time overhead to encrypt a search structure with 10000 file indexes is only 287 ms, mainly because the trapdoor algorithm requires the time-consuming operations (bilinear pairs and mtp. The search algorithm in the smart contract is efficient with an average time overhead of about 55 ms for 10000 matched results.Figure 7
Time cost of each algorithm.


## 8. Conclusion

In this study, we propose a blockchain-based searchable encryption scheme BNSE and design a searchable encryption system BNSEM for medical data based on the scheme. Firstly, the system adopts the smart contract of Fabric to guarantee the accuracy of search results. Secondly, we use polynomial-based broadcast cryptography to implement a multiuser search function. Then, the system achieves legal regulation of medical ciphertext data without violating the privacy of the private key. Finally, we provide the security analysis of BNSEM and perform a test of the time cost of each algorithm. For future work, we have considered functional extensions of multikeyword search and range queries on numerical data.



---

*Source: 9780188-2022-08-23.xml*