Secure Sharing of Electronic Medical Records Based on Blockchain and Searchable Encryption

Abstract

In recent years, Electronic Medical Record (EMR) sharing has played an indispensable role in optimizing clinical treatment plans, advancing medical research in biomedical science. However, existing EMR management schemes often face security risks and suffer from inefficient search performance. To address these issues, this paper proposes a secure EMR sharing scheme based on blockchain and searchable encryption. This scheme implements a decentralized management system with enhanced security and operational efficiency. Considering the scenario of EMRs requiring confirmation of multiple doctors to improve safety, the proposed solution leverages Shamir’s Secret Sharing to enable multi-party authorization, thereby enhancing privacy protection. Meanwhile, the scheme utilizes Bloom filter and vector operation to achieve efficient data search. The proposed method maintains rigorous EMR protection while improving the search efficiency of EMRs. Experimental results demonstrate that, compared to existing methodologies, the proposed scheme enhances security during EMR sharing processes. It achieves higher efficiency in index generation and trapdoor generation while reducing keyword search time. This scheme provides reliable technical support for the development of intelligent healthcare systems.

1. Introduction

EMRs are detailed clinical information records formed and systematically recorded by individuals during various diagnosis and treatment activities in medical institutions. They are a crucial core component of personal health records [1]. With the development of medical technology and the advancement of medical informatization, EMRs have gradually become the main way for medical institutions to record, store, and manage patient health information. The widespread adoption of EMRs has significantly enhanced medical service efficiency and quality, while providing patients with a more convenient and comprehensive health monitoring platform. These data are important for doctors so they can develop treatment plans, assess patient condition, and study major diseases [2]. At the same time, achieving the sharing of EMRs can effectively avoid redundant and repetitive medical testing and laboratory procedures, thereby reducing the burden of medical expenses on patients. However, the sharing of EMRs also faces many challenges, such as the authenticity and credibility of EMR data needing to be guaranteed to prevent data tampering or forgery [3]. Security and confidentiality must be strictly guaranteed in the circulation and storage of EMR data. In addition, it is necessary to consider the efficiency of sharing.

The consensus mechanism within blockchain networks (BCNs) provides a foundation for establishing a highly trusted distributed platform [4]. This platform can register and manage users and resources in EMR sharing systems, perform identity authentication, and grant access permissions in low-trust scenarios. Ensured uniqueness by the SHA-256 algorithm [5], data stored in BCNs are tamper-resistant and traceable [6], addressing single points of failure and security vulnerabilities inherent in traditional centralized access control systems. While many researchers have integrated BCNs with access control to mitigate these issues with notable success, the complexity of permission management hinders fine-grained and dynamic control. Furthermore, existing approaches underutilize the computational capabilities of smart contracts and suffer from low system throughput due to the inherent limitations of BCNs [7].

Based on this analysis, a secure EMR sharing scheme that leverages blockchain technology combined with searchable encryption is proposed. The proposed scheme enhances security by using Shamir’s Secret Sharing to achieve multi-party authorization in the scenario of EMR sharing. In addition, vector operation based on the Bloom filter significantly reduces the computational cost of index and trapdoor generation while enhancing search efficiency in EMR sharing systems. The main contributions of this paper are as follows:

An architecture for secure EMR sharing is proposed, consisting of five key components: patients, Electronic Medical Record Service Providers (EMRSPs), Electronic Medical Record Data Users (EMRDUs), blockchain, and the Inter-Planetary File System (IPFS). Shamir’s Secret Sharing is adopted to enable multi-party authorization by trusted doctor nodes, enhancing security in high-risk scenarios. Bloom filter and vector operation are used to improve the query efficiency in the case of large-scale medical data security sharing. The proposed scheme’s performance is empirically evaluated through comprehensive experiments, including theoretical verification, functional evaluation, efficiency assessment of index and trapdoor generation, and search time measurement.

2. Related Works

The research on secure sharing of medical records has been widely explored in recent years. Islam et al. [8] proposed a blockchain-based data security and privacy protection system for public health centers. This system utilizes a SHA-256-based access controller and transaction signatures with consensus strategies to provide security for sharing and storing health data in the blockchain. However, this scheme stores raw data directly in the blockchain, leading to excessive storage pressure on the blockchain network. Waghe et al. [9] proposed a blockchain-enabled cybersecurity framework for protecting patient data in medical informatics. It utilizes a Proof-of-Work (PoW) consensus mechanism and Role-Based Access Control (RBAC) for fine-grained access management, providing adequate protection for sensitive patient data. However, it lacks a multi-party authorization feature. Elghoul et al. [10] proposed a blockchain-based approach for protecting patient medical records in cloud-based healthcare systems, yet it lacks encryption protection for EMRs and fine-grained access control.

Venkatesh et al. [11] introduced an EMR protection scheme capable of resisting interception, man-in-the-middle, and collusion attacks. Sun et al. [12] proposed a distributed and searchable EMR scheme using blockchain and smart contract technology. The encrypted keyword index information of electronic medical records is stored on the Ethereum blockchain. However, the scheme lacks support for multi-keyword simultaneous retrieval. Khatoon [13] proposed a smart contract-based access control framework, but it lacks encryption protection for EMRs. Prathap et al. [14] introduced a bidirectional decryption algorithm enabling two entities to decrypt data, enhancing message security in public clouds by allowing centralized authentication proxies to read transmissions. Lee et al. [15] proposed a smart contract-based EMR data sharing and privacy protection scheme. The adoption of blockchain ensures the integrity of medical data and safeguards patient privacy, but storing raw data directly on the blockchain results in excessive computational and storage burdens. Mhamdi et al. [16] proposed a system based on access control (Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC)) and smart contract methods. This convergence provides decentralized, fine-grained, and dynamic access control management for EMR sharing. Bera et al. [17] proposed an attribute-based scheme for searchable storage and retrieval of EMR in cloud environments. While supporting fine-grained access control and Boolean keyword searches, the scheme does not address multi-party authorization. Wang et al. [18] proposed a secure data sharing scheme featuring deduplication and sensitive data hiding in cloud-assisted EMR systems, allowing authorized researchers to selectively download data based on redundancy rates. The scheme resists brute-force and single-point failure attacks. Luo et al. [19] proposed a lightweight searchable encryption and access control system using quantum-resistant encryption for index generation and a Bloom filter to enhance search efficiency, However, this approach requires substantial computational resources for index construction. Park [20] designed hybrid encryption protocols for EMR data flows by combining symmetric and asymmetric cryptographic techniques with optimized key management. Zhu et al. [21] proposed a secure EMR sharing scheme based on blockchain and quantum-resistant keys and fine-grained access control, utilizing searchable encryption for secure cloud retrieval. Zhang et al. [22] developed a registered keyword searchable encryption method using SM9 named RKSE-SM9 for keyword ciphertext and trapdoor generation, improving security, but it has substantial computational overhead at index and trapdoor generation. Wu et al. [23] designed a blockchain-assisted inner product predicate attribute search scheme named VMKS-ABE to prevent medical data leaks. However, the index generation process has high complexity.

Considering the strengths and limitations of the aforementioned approaches, this paper proposes a secure EMR sharing scheme by using blockchain and searchable encryption. Our solution employs Shamir’s Secret Sharing to enable secure multi-party authorization, utilizes the IPFS to enhance system decentralization, and utilizes the Bloom filter to optimize index and trapdoor generation efficiency while significantly improving the search efficiency of EMRs.

3. Proposed Framework

This paper proposes a secure EMR sharing scheme based on blockchain and searchable encryption. The technical architecture is illustrated in Figure 1.

In the secure EMR sharing system, the blockchain-based platform consists of patients, Electronic Medical Record Service Providers (EMRSPs), Electronic Medical Record Data Users (EMRDUs), the IPFS, blockchain, and smart contracts.

Patients: As the owners of the EMRs, patients submit records to the EMRSP, define access policies, and authorize trusted doctor nodes.

EMRSP: The EMRSP, generally played by the hospital, is responsible for encrypting EMR data and storing it in the IPFS. Through the access policies formulated by the patients, it is ensured that only authorized users can decrypt the data.

EMRDU: As a data requester, the identity of an EMRDU must be authenticated. After completing the correct authentication by the specified doctor node, an effective decryption key can be obtained by the EMRDU.

IPFS: The IPFS is responsible for decentralized storage and management of encrypted medical data. The CID is a unique string that identifies a piece of content, generated based on the content’s hash value. The IPFS provides the Content Identifier (CID) to locate the stored data.

Blockchain and smart contracts: The blockchain system is composed of doctor nodes and is responsible for storing encrypted EMR indexes. The smart contracts within the blockchain automatically perform search operations.

3.1. System Working Sequence

The working sequence diagram of the sharing system is shown in Figure 2.

The proposed scheme starts with the patient submitting the original EMR to the EMRSP. Before the EMRSP uploads the EMR to the IPFS, the EMR is encrypted using a symmetric key. Subsequently, the EMRSP obtains a CID and processes the symmetric key through Shamir’s Secret Sharing to generate shares that are further encrypted through Ciphertext-Policy Attribute-Based Encryption (CP-ABE), while the keywords are transformed into encrypted indexes using the Bloom filter. The indexes are then uploaded to the blockchain, and the shares are distributed to the specified doctor nodes.

For EMR access, the EMRDU first obtains the attribute private key from the EMRSP and collects sufficient key shares from the specified doctor nodes to reconstruct the key. Then, the EMRDU generates a trapdoor for the target keywords and processes the trapdoor by the search smart contract to perform the search operation. If the relevant indexes are searched, the smart contract will return the corresponding CID. Finally, the EMRDU uses the CID to obtain encrypted files from the IPFS and decrypts them using the reconstructed symmetric key to obtain the original EMR content.

3.2. Basic Definition

• $Setup(1^{\lambda })\to (k_s,k_{cp-abe})$: Given the security parameter $\lambda$, the EMRSP randomly generates two keys, $k_s$ and $k_{cp-abe}$. The variable $k_s$ serves as the static symmetric encryption key, and $k_{cp-abe}=(pk,msk)$ represents the CP-ABE key pair, where pk is the public key and msk is the main secret key.
• $KeyGen(pk,msk,attribute,\lambda )\to (ak,sk)$: Given the public key pk, the master secret key msk, and the user’s attribute, the EMRSP returns the corresponding attribute private key $ak$ to the EMRDU. Given the security parameter $\lambda$, the EMRSP generates an encryption key $sk=(M_1,M_2,S)$.
• $Enc(pk,D,policy,k_s)\to (C,Cke{y}_i)$: Given the public key $pk$, EMR set D, access policy, and symmetric key $k_s$, the EMRSP outputs ciphertext C. The symmetric key $k_s$ is split into multiple shares $k_{s1},k_{s2}\cdots k_{si}(i\in [1,N_s])$ using Shamir’s Secret Sharing, where $N_s$ represents the maximum number of all shares. The shares are encrypted to generate ciphertexts $Cke{y}_i(i\in [1,N_s])$ using CP-ABE. Then, the shares are sent to multiple trusted doctor nodes for storage. The encrypted data C will be stored in the IPFS.
• $BuildIndex(I,sk)\to I_D$: This algorithm is designed for file index generation. Specifically, the EMRSP extracts a keyword set W from each original EMR file D and uses them to generate the file index I. I is encrypted using the key $sk=(M_1,M_2,S)$ to generate the encrypted index $I_D$. Then, the collection of all encrypted indexes $I_{DG}$ is stored on the blockchain.
• $Trapdoor(Q,sk)\to Q_D$: The query set $Q$ is encrypted using $sk$ to generate the trapdoor $Q_D$. The EMRDU sends the trapdoor to the search smart contract.
• $Search(I_{DG},Q_D)\to CID$: The search smart contract uses the encrypted index set $I_{DG}$ and trapdoor $Q_D$ to obtain the target file CID. Subsequently, the EMRDU can download the corresponding encrypted EMR from the IPFS via the CID.
• $Dec(ak,CID)\to D$: The EMRDU use the attribute key ak to obtain $k_{si}$ from the specified doctor nodes. The symmetric key can be reconstructed only when a threshold number of shares is collected. The EMRDU downloads the corresponding EMR ciphertext via the CID. The symmetric key is used to obtain the ciphertext.

3.3. Specific Processes

3.3.1. Initialization

The key $k_s$ and key pair $k_{cp-abe}=(pk,msk)$ are generated by the EMESP. The process is as follows:

• Define two multiplicative cyclic groups $G_0$ and $G_1$ of prime order $p$, and let $g$ be a generator of the group $G_0$.
• Define a bilinear map e: $G_0\times G_0\to G_1$.
• Select collision-resistant hash functions $H_1:\left\{\mathrm{0,1}\right\}\to G_0,H_2:\{\mathrm{0,1}{\}}^{\ast }\to {Z_p}^{\ast }$.
• Randomly choose $\alpha ,\beta \in {Z_p}^{\ast }$ and generate the master secret key $msk=(\alpha ,\beta )$.
• Generate a symmetric key $k_s\leftarrow \{\mathrm{0,1}{\}}^{\lambda }$.
• Output the system public parameters $pk=(G_0,G_1,p,g,g^{\beta },e(g,g{)}^{\beta },H_1,H_2)$.

3.3.2. Key Generation

The EMRDU joins the healthcare blockchain.

The key generation algorithm $KeyGen(pk,msk,attribute,\lambda )\to (ak,sk)$ is executed by the EMRSP. The EMRSP randomly selects $r\leftarrow {Z_p}^{\ast }$ for each user attribute. The EMRSP selects $\forall r_j\leftarrow {Z_p}^{\ast }$ ($\forall j\in attribute$) and computes $ak=\{D=g^{{\displaystyle \frac{\alpha +\beta }{\beta }}},\{D_j=H_1(j{)}^{r_j},{D_j}^{\prime }=g^{r_j}{\}}_{\forall j\in attribute}\}$. $sk=(M_1,M_2,S)$ is generated using security parameters $\lambda$, where $M_1,M_2\in R^{\lambda \times \lambda }$ are invertible matrices and $S\in {\left\{\mathrm{0,1}\right\}}^{\lambda }$ is a vector.

3.3.3. Encryption of EMR and Key

The proposed scheme employs symmetric encryption to protect EMR data before uploading it to the IPFS. This design significantly alleviates storage burdens and safeguards sensitive information via cryptographic protection. The detailed workflow of this encryption scheme is as follows:

The EMRSP owns the EMRs, which are denoted as $D=\{D_1,D_2,\cdots ,D_N\}$.

The symmetric encryption algorithm is executed with the symmetric key $k_s$ and EMR dataset D. The EMRSP encrypts each file $D_i(i\in [1,N])$ to generate corresponding ciphertext $C=\{C_1,C_2,\cdots ,C_N\}$, resulting in an encrypted file set C. Subsequently, the entire set C is uploaded to the IPFS for storage.

The EMRSP utilizes Shamir’s Secret Sharing to split the symmetric key into multiple shares, then assigns shares to $N_s$ doctors. The EMRSP randomly selects polynomials $f(x)=a_0+a_{1}x+a_2{x}^2+\cdots +a_{t-1}{x}^{t-1}$, where the constant $a_0=k_s$ is the secret to be shared, t defined as the threshold, and $a_1, a_2,\cdots , a_{t-1}$ are defined as the coefficients. The EMRSP chooses different elements $x_1,x_2,\cdots ,x_{N_s}$ that are non-zero, computing $y_i=f(x_i)$ and getting the subkey $k_{si}=(x_i,y_i)$.

The EMRSP acquires the encryption policy from the patient and constructs an access tree T based on this policy. The detailed construction process is as follows:

For each leaf node x in the tree T, a polynomial $q_x$ is constructed, where the degree of the polynomial is denoted as $d_x$. The polynomial of a leaf node is a constant, meaning its degree is 0. Let $k_x$ represent the threshold value of the node, and $\mathit{deg}(q_x)=d_x=k_x-1$ is set by the EMRSP. The polynomials for all nodes are determined through a level-order traversal beginning at the tree’s root node. The EMRSP randomly selects $s\leftarrow {Z_p}^{\ast }$, sets $q_{root}(0)=s$, and chooses $\mathit{deg}(q_{root})$ random coefficients from the field ${Z_p}^{\ast }$ to determine the coefficients of the polynomial $q_{root}$. For any non-root node, the EMRSP sets the polynomial $q_x(0)=q_{parrent}(x)(index(x))$, where $index(x)$ sequentially labels the child nodes of the parent node from left to right as 1, 2, 3, …. Then, $\mathit{deg}(q_x)$ random coefficients are selected from the field ${Z_p}^{\ast }$ to determine the coefficients of the polynomial $q_x$. Next, let $Y$ denote all the leaf nodes in the tree T. Let $attr(y)(\forall y\in Y)$ represent the attribute string corresponding to the leaf node $y$ since the polynomials of leaf nodes are constants. The hash function $H_1(attr(y))$ maps the attribute string $attr(y)$ to an element in $G_0$. The EMRSP computes the ciphertext $Cke{y}_i$ for shares $k_{si}$ of the symmetric key, which can be expressed as Formula (1):

$$Cke{y}_i=\{T,\tilde{C}=k_{si}e(g,g{)}^{\alpha s},C_2=H^s,\{{C_y}^{\prime }=H_1(attribute(y){)}^{q_y(0)}{\}}_{\forall y\in Y}\}$$

(1)

The encrypted key shares $Cke{y}_i$ are distributed across multiple trusted doctor nodes for storage, as depicted in Figure 3.

3.3.4. Index Generation

The encrypted index generation algorithm $BuildIndex(D,sk)$ is invoked to create the index. Then the index is uploaded to the blockchain for storage. The detailed process is as follows:

• Generate a $\lambda$-bit Bloom filter as the index I for each file $D$ in the EMR dataset.
• Select $l$ independent hash functions.
• Extract the keyword set $W=\{w_1,w_2,\cdots \}$ from file D. The EMRSP inserts it into index I for each keyword $w_i$ by using hash functions.
• Given the security parameter $\lambda$, the encryption key $sk=(M_1,M_2,S)$ is generated. $M_1,M_2\in R^{\lambda \times \lambda }$ are invertible matrices, and $S\in \{\mathrm{0,1}{\}}^{\lambda }$ is a vector.
• The index I is encrypted under key sk, generating the ciphertext index $I_D$. The encrypted index of files and their corresponding file CID form the access index $I_{DG}$ for the EMR dataset $I_{DG}=\{({I_D}_1,CID1),(I_{D_2},CID2),\cdots ,(I_{D_i},CIDi)\}(i\in [1,N_f])$, where $N_f$ is the maximum number of files. The encrypted index generation process is detailed in Algorithm 1:

Algorithm 1: Index Generation

Input: $sk$ , I

Output: $I_D$

1. Select random number $r$ , $r\in {Z_p}^{\ast }$

2. Initialize $I^{\prime }$ = [], $I^{″}$ = []

3: for j = 1 to Length(I)

4: if $s_j=1,s_j\in S$ then

5:  ${i_j}^{\prime }={i_j}^{″}=i_j,{i_j}^{\prime }\in I^{\prime },{i_j}^{″}\in I^{″},i_j\in I$

6: else ${i_j}^{\prime }=0.5$ ×$i_j+r,{i_j}^{″}=0.5\times i_j-r$

7:   end else

8:   end if

9: end for

10: return $I_D=\{{M_1}^T\cdot I^{\prime },{M_2}^T\cdot I^{″}\}$

3.3.5. Trapdoor Generation

Before the search operation, the EMRDU encrypts the query keywords with the key $sk$ to construct the trapdoor through function $Trapdoor(Q,sk)$. The detailed workflow is as follows:

• Generate a $\lambda$-bit Bloom filter Q for the query operation.
• Utilize l independent hash functions $H_j\in H(1\le j\le l)$.
• For each query keyword $q_i(q_i\in Q)$, hash values are computed using the hash functions $H_j\in H(1\le j\le l)$, and the results are inserted into the Bloom filter $Q$.
• The query string Q is encrypted with the key $sk$ to generate the trapdoor. The EMRDU sends the trapdoor to the search smart contract and requests key shares from the trusted-doctor nodes. The trapdoor generation process is detailed in Algorithm 2:

Algorithm 2: Trapdoor Generation

Input: $sk$,$Q$

Output: trapdoor  $Q_D$

1. Select random number $r$ , $r\in {Z_p}^{\ast }$

2. Initialize $Q^{\prime }=\left[\right]$ , $Q^{″}=\left[\right]$

3: for j = 1 to Length(I)

4: if $s_j=0,s_j\in S$ then

5:  ${q_j}^{\prime }={q_j}^{″}=q_j,{q_j}^{\prime }\in Q^{\prime },{q_j}^{″}\in Q^{″},q_j\in Q$

6: else 7.  ${q_j}^{\prime }=0.5\times q_j+r^{\prime },{q_j}^{″}=0.5\times q_j-r^{\prime }$

8:   end else

9:   end if

10: end for 11: $Q_D=\{{M_1}^{-1}\cdot Q^{\prime },{M_2}^{-1}\cdot Q^{″}\}$

12: return $trapdoor\leftarrow Q_D$

3.3.6. Search Phase

After generating the trapdoor, the EMRDU submits the trapdoor to the search smart contract via a blockchain transaction, thereby invoking the contract to initiate the search process. The encrypted index $I_D$ is searched from the blockchain by the smart contract, followed by a match between the trapdoor and the encrypted index set $I_{DG}$.

When the inner product between the trapdoor and index $I_D$ meets or exceeds the value of 1, the corresponding file is identified as a search target. Its CID is then added to the target file set ID. The search process is detailed in Algorithm 3:

Algorithm 3: Search

Input: trapdoor $Q_D$, $I_{DG}$

Output: ID

1: Extract $I_D$ from $I_{DG}$

2: Calculate the inner product of index and trapdoor:

3: ${I_D}^T\cdot Q_D={M_1}^T{I}^{\prime }\cdot {M_1}^{-1}{Q}^{\prime }+{M_2}^T{I}^{″}\cdot {M_2}^{-1}{Q}^{″}=I^T\cdot Q$

4:  if ${I_D}^T\cdot Q_D\ge 1$ . Corresponding CID is added to ID

5:  else find the next file $I_D$ in the index collection $I_{DG}$

6: return ID

3.3.7. Decryption Phase

The ciphertext is fetched from the IPFS upon acquisition of the target CID. Then, the attribute key $ak$ is verified by multiple trusted doctor nodes. Doctors recursively compute $e(g,g{)}^{r{q}_{root(0)}}=e(g,g{)}^{rs}$, which can be expressed as Formula (2):

$$k_{si}={\displaystyle \frac{e(g,g{)}^{rs}\tilde{C}}{e(C,D)}}={\displaystyle \frac{k_{si}e(g,g{)}^{\alpha s}e(g,g{)}^{rs}}{e(h^s,g^{\frac{\alpha +r}{\beta }})}}={\displaystyle \frac{k_{si}e(g,g{)}^{\alpha s}e(g,g{)}^{rs}}{e(g^{\beta s},g^{\frac{\alpha +r}{\beta }})}}$$

(2)

The EMRDU can obtain key shares from trusted doctors. If the EMRDU obtains a threshold number of key shares, the symmetric key is reconstructed via Lagrange interpolation from a threshold number of key shares. The key reconstruction process is shown in Formula (3):

$$f(x)=\sum _{i=1}^t{y}_i\prod _{j=1,j\ne i}^t{\displaystyle \frac{x-x_i}{x_i-x_j}}$$

(3)

When the value of x is 0, $f(0)=k_s$. The process of share collection is depicted in Figure 4.

The decryption process is detailed in Algorithm 4:

Algorithm 4: Decryption

Input: $ak$, CID

Output: D

1: if matcℎ(policy, ak) == false

2: return $\perp$

3: end if

4: else if matcℎ(policy, ak) == true

5: return ${\mathit{k}}_{\mathit{s}\mathit{i}}$ .

6: end else 7. The symmetric key $k_s$ is reconstructed by applying Lagrange interpolation. 8. The destination file corresponding to CID is decrypted via $k_s$ , and the plaintext D is obtained. 9. return D

4. Experimental Results and Analysis

4.1. Theoretical Evaluation

4.1.1. Security

If the threshold is set to t, the symmetric key can only be recovered when at least t-out-of-Ns authorized nodes participate in secret recovery via Lagrange interpolation. This protocol enforces multi-authorization, providing end-to-end verifiable security for EMR sharing. Additionally, security is enhanced through encrypted indexes and trapdoors. It can resist inference attack by encrypting keywords locally.

4.1.2. Correctness

Given identical hash functions, any repeated keyword will always be mapped to the same set of positions in the Bloom filter. This deterministic mapping guarantees that a successful match yields an inner product ≥ 1 between the trapdoor and the encrypted index. By design, the Bloom filter introduces a false positive rate, ensuring 100% recall of matched records while tolerating limited irrelevant retrievals. Such precision–recall trade-offs significantly enhance search efficiency with negligible computational cost.

4.1.3. Single Point of Failure Resilience

The solution employs blockchain to store replicated indexes, introducing redundancy. Although this increases storage overhead, the trade-off is necessary to satisfy EMR confidentiality–integrity–availability requirements. The design guarantees system availability even under f-node failures. By removing single points of failure, decentralized governance inherently mitigates both malicious attacks and systemic risks.

4.2. Functionality Comparison

This paper exhibits the functionality comparison of RKSE-SM9, VMKS-ABE, and this paper in

Table 1. Functionality comparison.

Scheme	RKSE-SM9	VMKS-ABE	Ours
IPFS	×	×	√
Decentralization search	×	√	√
Low cost	×	×	√

“×” indicates the absence of the function, and “√” indicates the presence of the function.

.

This scheme implements a decentralized storage solution by combining the IPFS with blockchain technology, offering distinct advantages over the two baseline schemes. The IPFS relies on P2P transmission between nodes, which may cause delays in medical record retrieval in areas with low connectivity. By exploiting the IPFS’s content-addressed P2P network, data are distributed across multiple nodes, effectively eliminating the single-point-of-failure risk associated with traditional cloud storage systems. The system automatically fragments and distributes data for enhanced fault tolerance while ensuring tamper-proof integrity through CID. Unlike the baseline schemes that depend on computationally expensive bilinear pairings, our approach employs vector operation to significantly reduce match costs. Additionally, the scheme incorporates trusted doctor nodes for auditable multi-party authorization, delivering a blockchain-based EMR sharing scheme that prioritizes both security and regulatory compliance.

4.3. Experimental Results

In this section, we compare the performance of the proposed schemes with the schemes proposed in RKSE-SM9 and VMKS-ABE using performance metrics such as computation efficiency. Table 2 describes the schemes proposed in this paper compared with the schemes proposed in RKSE-SM9 and VMKS-ABE in the encryption phase, the trapdoor generation phase, and the test phase, as well as whether the trapdoor indivisibility is satisfied. We present some basic operation symbols as follows:

• P: The running time of the bilinear pairing operation, which is 5.787 ms;
• M: The running time of the scalar multiplication operation, which is 2.355 ms;
• E: The running time of the exponentiation operation, which is 0.794 ms.

Since this scheme uses vector calculation for the multi-keyword and the hash time is negligible, the index generation time, trapdoor generation time, and search time do not change much with the increase in keywords. In the index generation, the time consumption is mainly concentrated in the calculation of the matrix and vector, and the average time is 1.062 ms; the trapdoor generation time cost is mainly concentrated in the inverse operation of matrix, and the average time is 77.894 ms; and the search time is mainly concentrated in the calculation of vector, and the average time is 0.01 ms.

Let me and ls denote the number of encrypted keywords and search keywords, respectively.

Table 2. Time comparison.

Scheme	EncInd/ms	Trapdoor/ms	Search/ms
RKSE-SM9	me(2M + E)	ls(M)	lsP
VMKS-ABE	(me + 1)E	ls(E)	lsP
Ours	1.062	77.894	0.01

Table 2. Time comparison.

Scheme	EncInd/ms	Trapdoor/ms	Search/ms
RKSE-SM9	me(2M + E)	ls(M)	lsP
VMKS-ABE	(me + 1)E	ls(E)	lsP
Ours	1.062	77.894	0.01

To demonstrate the availability of the proposed scheme, we deployed the model of the scheme in the 16th version of the VMware virtual machine, with a system configuration of dual-core 2 GB memory and a 100 GB hard disk with Ubuntu 20.04.6 64 bit. Each module runs in the Docker container in Hyperledger Fabric v2.5.4. Index generation and trapdoor generation were simulated in Python 3.8.10. To account for variability, we performed 1000 independent tests under identical experimental conditions to obtain the average execution time. The software configuration of the testing environment is shown in

Table 3. Software configuration.

Software Environment	Detailed Information
Operating system	Ubuntu 20.04.6
Docker	v24.0.5
Docker Compose	v1.29.2
Golang	v1.17.1
Hyperledger fabric	v2.5.4
Node	v22.12.0
Npm	v10.9.0
Python	v3.8.10

, and the hardware configuration is shown in

Table 4. Hardware configuration.

Hardware Environment	Detailed Information
CPU	i9-12900H
Memory	16 GB
Hard disk	100 GB

.

4.3.1. Index Generation Time

A comparison of index generation times is shown in Figure 5. The experimental design varies the number of keywords from 10 to 150. The index generation average time of this scheme is 1.062 ms. As the number of keywords increases, the execution time ranges from 55 ms to 825 ms in RKSE-SM9 and from 7.49 ms to 112.35 ms in VMKS-ABE. It can be seen from the data comparison chart that the index generation time of this scheme is shorter than that of the compared existing scheme. The overall process maintains high efficiency after the calculation of the matrix and the vector. In contrast, RKSE-SM9 requires a large amount of multiplication and many exponential operations. VMKS-ABE requires progressively more exponential operations as the number of keywords increases, whereas our scheme achieves multi-keyword encryption through a cryptographic operation. In general, compared with the other two schemes, this scheme is efficient in the index generation algorithm.

4.3.2. Trapdoor Generation Time

A comparison of trapdoor generation time is shown in Figure 6. The experimental design varies the number of keywords from 10 to 150. The average trapdoor generation time of this scheme is 77.894 ms. The data comparison chart shows that the trapdoor generation time of this scheme is shorter than that of the comparison scheme with the increase in keywords. When there are few keywords, because this scheme needs to execute a fixed inverse operation of the matrix, the time consumption is longer than that of the comparison scheme. A large number of multiplication operations are required in RKSE-SM9. It can be seen that the time of RKSE-SM9 increases from 23.55 ms to 353.25 ms. The time of VMKS-ABE increases from 7.94 ms to 112.35 ms, because a large number of exponential operations are required in VMKS-ABE. Compared with RKSE-SM9 and VMKS-ABE, our method achieves lower trapdoor generation time cost with the increase in keywords.

4.3.3. Search Time

A comparison of search times is shown in Figure 7. The experimental design varies the number of keywords from 10 to 150. The average search time of this scheme is 0.01 ms. The search time of RKSE-SM9 is from 57 ms to 855 ms. The search time of VMKS-ABE is from 57.87 ms to 868.05 ms. In our experiments, the superior search performance of our method stems from the faster computation of vector operations. The baseline scheme incurs significant computational overhead due to its reliance on numerous bilinear pairing operations, resulting in prohibitively long processing times for large datasets. The search time in our method is almost constant. Better search performance is enabled by the constant-time complexity in query processing, contrasting with the obvious linear scaling of compared approaches.

When Internet of Medical Things (IoMT) is running, if blockchain is not used, the cloud replaces the blockchain. The trapdoor is stored in the cloud. The requester sends the encrypted security index to the cloud for matching.

The search time based on blockchain is shown in Figure 8. The experimental design varies the number of keywords from 10 to 50. When blockchain is introduced, the search time in this paper is between 112.5 ms and 148.6 ms. The main time consumption is concentrated in the operation of smart contracts. Compared with clouds, the automated operation of smart contracts on blockchain is safer.

The above analysis and experiments show that this scheme has better performance than similar schemes.

5. Conclusions

This study conducted an exploration of a secure EMR sharing scheme based on blockchain and searchable encryption. Leveraging the advantages of blockchain technology, the approach ensured data security and traceability. EMRs were encrypted while enabling keyword-based search by employing searchable encryption techniques. The scheme allowed authorized users to share medical record information. The results demonstrate that this method, building on the characteristics of EMRs, utilized Shamir secret sharing technology to achieve multi-party authorization during the sharing process. Additionally, a secure index and a trapdoor could be implemented by a Bloom filter and vector operation. The proposed solution exhibited a shorter time of index generation and trapdoor generation. The research provided a secure, efficient, and reliable sharing solution for healthcare institutions. In future work, we will explore cross-blockchain EMR sharing and proxy re-encryption technology to expand its applications in smart healthcare, ultimately delivering better medical services to patients.