Efficient and Secure Medical Data Sharing: An Improved CP-ABE Scheme with Outsourced Decryption

Abstract

Addressing the challenges of privacy leakage, fragmented data silos, and high computational overhead in traditional ciphertext-policy attribute-based encryption (CP-ABE) for medical data sharing, this paper proposes an improved CP-ABE framework with outsourced decryption, integrated with consortium blockchain and the InterPlanetary File System (IPFS). The framework introduces a medical-scenario-adapted CP-ABE architecture based on a lightweight FAME design, optimizing attribute key generation and transformation key design to accommodate resource-constrained medical terminals. A hybrid encryption system is employed, combining symmetric encryption for high-efficiency processing of large medical data and CP-ABE for fine-grained access control of symmetric keys. To reduce user computational burden, a proxy-assisted secure decryption architecture is implemented, where the proxy server handles most decryption tasks while ensuring resistance to malicious proxy behavior. Furthermore, the framework provides rigorous formal security verification, achieving IND-CPA security and resilience against collusion and malicious proxy attacks. Comprehensive performance evaluations demonstrate significant improvements in key generation, encryption, and decryption efficiency, offering a better balance between security and efficiency for practical medical data sharing applications.

1. Introduction

The use of electronic medical systems has become a widespread practice in modern healthcare facilities due to the rapid development of electronic information and Internet of Things (IoT) technologies. The use of standardized electronic medical information has increasingly replaced paper records. The aggregation and comprehensive analysis of such data have significantly enhanced clinical diagnostic accuracy, improved the efficiency of healthcare service delivery, and facilitated research in precision medicine. However, most medical institutions set up closed information systems separately, and thus, medical data circulates within the institution but not across it. Sharp data silos have, therefore, cropped up, hindering the integrated development of the industry and the full utilization of high-value medical resources [1,2]. At the same time, sensitive data such as personal identity, medical history, physiological signs, and genetic data are a significant part of medical data. Unauthorized access, leakage, or misuse of such information may result in patient privacy violations, as well as security incidents like identity theft and medical fraud [3,4].

Ciphertext-policy attribute-based encryption (CP-ABE) is a possible cryptographic scheme of fine-grained access control and has been widely studied in the medical data sharing setting [5]. Nevertheless, existing CP-ABE-based solutions have significant limitations, including large computational overheads, slow decryption speeds on resource-constrained medical terminals, and a lack of protection against advanced attacks encountered in real medical settings. As a result, achieving safe, effective, and fine-grained sharing of medical data has become an urgent and critical research agenda.

Coined by Nakamoto [6], blockchain is a distributed ledger technology that has evolved to consortium forms that can be implemented in industry. Its properties of decentralization, tamper resistance, transparency, and traceability have resulted in extensive use in medical data sharing applications, similar to how blockchain is applied to ensure provenance and traceability in other fields such as cultural heritage donations [7,8,9]. This distributed architecture works well to address trust issues between multi-party medical institutions and eradicates bottlenecks of centralized management, thus creating a reliable technical basis of cross-institutional medical data interchange, which is also consistent with the core characteristics of blockchain decentralization as summarized in related studies [10]. Nevertheless, blockchain schemes do not provide fine-grained access control and direct encryption protection of sensitive medical data, only credibility of access records and storage logic. Current state-of-the-art schemes that combine blockchain with attribute-based encryption are limited by insufficient integration between encryption and blockchain systems or by an inability to balance fine-grained control and system efficiency in medical settings [11]. Thus, it is now urgent to combine high-efficiency and secure ciphertext-policy attribute-based encryption (CP-ABE) systems with blockchain to achieve overall security and feasibility in medical data sharing.

Attribute-based encryption (ABE) is a cryptographic primitive, which supports flexible one-to-many encryption and fine-grained access control [12]. ABE can be classified into key-policy ABE (KP-ABE) and ciphertext-policy ABE (CP-ABE) depending on the location of the access policy. In CP-ABE, Data Owners can add access policies to ciphertexts, and the decryption can only be successful if the attributes of the user match the policy. This feature is especially useful in medical data sharing situations in which permission management needs to be dynamic and differentiated [4,11]. However, the expensive bilinear pairing and exponentiation algorithms of traditional CP-ABE schemes create significant computational overheads that are inefficient for limited-resource devices such as medical terminals (e.g., mobile medical devices and portable tablets) in the medical field [5]. Outsourced decryption has become a popular optimization strategy to reduce user computational loads and increase practicability in medical settings, in which the vast majority of decryption tasks are offloaded to high-performance proxy servers.

In recent years, the integrated architecture of CP-ABE, outsourced decryption, blockchain, and IPFS has gradually become a typical technical route for medical data sharing, as it can effectively address the pain points of data silos, privacy leakage, and inefficient access control in medical scenarios [11]. Nevertheless, existing schemes based on this integrated architecture still have obvious limitations that hinder their practical deployment in real medical environments. First, many studies only combine these mature technologies without targeted optimization for the characteristics of medical data (e.g., large volume, high sensitivity) and resource-constrained medical terminals, leading to unclear core innovations, insufficient practical performance, and difficulty in meeting the actual needs of cross-institutional medical data sharing. Second, most schemes focus on reducing computation overhead through outsourced decryption but ignore potential security threats such as malicious proxy behavior and user collusion attacks, which may lead to sensitive medical data leakage or unauthorized access [5]. Third, few works provide rigorous formal security proofs under strong security models; most only offer heuristic security analysis, making it difficult to resist advanced attacks in complex medical environments. These critical gaps directly weaken the security, efficiency, and availability of existing systems in practical medical deployment, highlighting the necessity of our research. Specifically, unlike the existing mature but imperfect integrated architecture that merely splices CP-ABE, outsourced decryption, blockchain, and IPFS without targeted innovation, this paper conducts in-depth optimization and innovative design for the unique pain points of medical data sharing scenarios, focusing on solving the core defects of existing fusion schemes (i.e., poor medical adaptability, insufficient security, and lack of rigorous security proof) rather than simply combining these mature technologies.

To fill in the above research gaps and overcome significant barriers to medical data sharing, we propose a secure and efficient sharing model that is based on an improved CP-ABE with outsourced decryption, complemented with consortium blockchain and IPFS distributed storage. The main contributions are presented systematically as below:

• Based on the lightweight FAME architecture, a CP-ABE architecture adapted to medical scenarios is outsourced [13]. Contrary to the traditional outsource models in the previous literature, the generation of attribute keys, as well as the design of transformation keys, is optimized to match resource-constrained medical user terminals.
• A hybrid encryption system is used to balance efficiency and security. Symmetric encryption works with large medical data for high performance, and the symmetric key is also provided with CP-ABE protection to allow fine-grained access control. This design significantly improves system performance in terms of processing large-scale medical images and inspection data.
• The proxy-assisted secure decryption architecture is developed to reduce the computational requirements of the users. The proxy server does most of the decryption work, and the users are left with minimal calculations. Also, malicious proxy resistance is added, which exceeds the security levels of traditional ABE frameworks.
• Strict formal security verification shows that the framework achieves IND-CPA security and is not susceptible to collusion attacks and malicious proxy attacks. This work reinforces the security underpinnings of genuine medical applications, in contrast to most current strategies that provide merely heuristic security discourse.
• Large-scale performance comparisons and experimental analyses confirm the fact that the suggested framework has significant benefits in terms of key generation, encryption, and decryption efficiency. Another trade-off between security and efficiency is better, which makes it more realistic to apply to real medical data sharing systems.

The following parts are organized in the following way. Section 2 reviews the literature on the related topics of medical data sharing, CP-ABE, and blockchain technology. In Section 3, the system model, security requirements, and formal definitions are provided. Section 4 outlines how the proposed framework is going to be constructed in detail. Section 5 provides proper and formal security analysis. Section 6 assesses performance by conducting experimental tests. This paper is brought to an end by Section 7.

2. Related Work

Medical data sharing is key to the improvement of clinical diagnosis efficiency, innovation in medical research, and the optimization of public health services. However, there are major challenges, such as privacy leaks, difficult fine-grained access control, and high computational costs to end users (e.g., medical staff using mobile devices), that remain. Ciphertext-policy attribute-based encryption (CP-ABE) and, more generally, attribute-based encryption (ABE) have become a fundamental technology to overcome these challenges thanks to their ability to attach access controls to ciphertexts and provide fine-grained access control. This chapter analyzes the current developments in research on medical data sharing and attribute encryption and outlines limitations of the current literature on the topic that the proposed scheme seeks to overcome.

2.1. Research Progress of Medical Data Sharing

Researchers have thoroughly studied secure medical data sharing frameworks over the last few years, and encryption technology with access control mechanisms has become the most popular research direction. The basis of traditional methods is identity-based encryption (IBE) or role-based access control (RBAC), but these have limitations in flexibility and fine-grained control, unlike some advanced blockchain-aided schemes that adopt signature mechanisms to enhance security in e-health services [14]. IBE relies on fixed user identities, which do not support the dynamic attribute assignment among medical personnel (e.g., job transfers, promotion), whereas RBAC only provides role-based access control, which is insufficient to support the refined permission management requirements of sensitive medical material (e.g., distinguishing access rights between junior and senior physicians within the same department).

CP-ABE has been widely used in medical data sharing scenarios to address these problems. Under the encryption of content, the Data Owners (patients) have the ability to set access policies based on the attributes of the user (e.g., department of the medical staff, professional title, degree of authorization), whereby the user must satisfy policy criteria to be able to decrypt and access the content. This fine-grained and flexible control mechanism closely aligns with permission management requirements in medical data sharing, rendering CP-ABE the preferred technology in existing related research.

2.2. Research Progress of CP-ABE in Medical Data Sharing

To support the features of sharing medical data (e.g., large content volume, limited computational capabilities of end users, and high security) with CP-ABE, a sequence of improvement studies has been carried out, with researchers mainly focusing on reducing computational overhead, enhancing security, and optimizing system architecture. In particular, the research development based on the literature on the topic is discussed below.

Xiang et al. [15] introduced a CP-ABE model with outsourced decryption to reduce the computational overheads for medical end users. Resolving important management issues in centralized systems, they implemented a flexible key management mechanism that overcomes problems, such as single points of failure, key escrow, and privacy leakage, and a fair incentive mechanism to motivate network node participation. Whereas the local computational costs are effectively minimized, the security issues of malicious proxy behavior during the outsourced decryption are not considered, which is a crucial issue in the real-world setting of medical data sharing.

Yin et al. [16] proposed a decentralized CP-ABE model that does not rely on a single, Trusted Authority, which is closer to the distributed nature of medical settings. Theoretical evidence showed that it was resistant to selected keyword and selected plaintext attacks, thus guaranteeing content confidentiality. Nonetheless, the overhead of communication, caused by the decentralized architecture, makes it inappropriate in large-scale situations.

Su et al. [17] introduced a hidden-policy ABE model of medical settings that implements fine-grained access control and obfuscates particular policy content to protect the privacy of owners and users. A decryption system was added as an auxiliary to minimize user computation costs, and smart contracts have been added to provide multi-keyword ranked search over encrypted content, which significantly enhances usability. However, there is no explicit collusion resistance verification, which is a drawback, as the possibility of collusion between malicious medical personnel to bypass the access control and steal sensitive data exists.

Xiang et al. [18] designed a searchable CP-ABE scheme that integrates access control and searchable encryption, supporting policy hiding and resisting chosen keyword attacks. This scheme effectively solves the problem of efficient retrieval of encrypted medical data, but it has the drawback of high encryption overhead, which makes it unsuitable for real-time encryption of large-scale medical data (e.g., medical imaging data).

Ghopur et al. [19] addressed the limitations of existing multi-authority CP-ABE systems caused by centralized authorities by proposing a decentralized multi-authority ABE scheme. In their design, each authority independently issues keys and supports multi-keyword search, while maintaining security against chosen keyword attacks. However, the scheme does not take into account the dynamic updating of user attributes, which is a common scenario in medical settings (e.g., medical staff changing departments or obtaining new authorization).

Roy et al. [20] proposed a hierarchical multi-authority ABE scheme that improves encryption efficiency by parallelizing encryption using a multi-level access tree. Their scheme also supports policy hiding and attribute revocation, but the revocation mechanism is relatively complex and incurs high computational overhead, which increases the burden on the entire system.

Xie et al. [21] introduced edge servers and fog nodes into the encryption and decryption process of medical data: edge servers are responsible for performing ABE encryption on patients’ electronic medical records, while fog nodes assist users with decryption using a proxy re-encryption mechanism. They used aggregated signatures to ensure data integrity, but the integration of edge and fog nodes increases the system complexity, and the scheme lacks effective audit mechanisms for third-party nodes.

2.3. Limitations of Existing Schemes

Although significant progress has been made in the application of CP-ABE to medical data sharing scenarios, related frameworks continue to have a number of critical limitations, as discussed below.

To start with, computational efficiency and security balance are still not achieved. The vast majority of frameworks either focus on reducing computational overheads while ignoring the security risks posed by malicious third parties (e.g., proxy servers) or focus on the security but at a high cost, not reflecting the real world in which end users have limited computational resources but have a high security need.

Second, the resistance to collusion attacks and malicious proxy conduct is not considered in detail. Hackers can also cooperate with malicious medical personnel or external agents to bypass access controls, and proxy servers (e.g., Cloud Servers) can be used to steal or otherwise modify content during auxiliary decryption. Current designs either do not provide explicit collusion resistance checking or do not attempt to create specific mechanisms to counter malicious proxy behavior.

Third, flexibility to changing medical settings is inadequate. The current frameworks can hardly accommodate dynamic updates of user attributes and real-time requirements of massive operations, which makes them inapplicable in intricate and changing medical settings.

To overcome these limitations, this paper introduces an effective and secure CP-ABE-based model to share medical data, achieving a high balance between computational efficiency and security; enhancing resistance to collusion attacks and malicious proxy behavior; and enhancing adaptability to dynamic medical conditions.

3. System Architecture and Definitions

3.1. Scheme Model

This scheme involves seven entities, as shown in Figure 1: the Trusted Authority (TA), the Cloud Server (CS), the Data Owner (DO), the Data Controller (DC), the Data User (DU), the blockchain (BC), and the InterPlanetary File System (IPFS). The definitions of each entity are as follows:

Trusted Authority (TA): The TA is in charge of system initialization and generates public parameters and master keys of attribute-based encryption. At registration stages, DUs’ attribute secret keys are created based on their attribute sets, as are public–private key pairs. DUs use these pairs to encrypt the attribute secret key and use it to generate the transformation key.

Cloud Server (CS): A CS is a computationally powerful server. When DUs send requests indicating pre-decryption, transformation keys are used to perform a partial decryption of ciphertexts, and partially decrypted data is sent back to requesting DUs.

Data Owner (DO): DOs are usually patients who obtain daily health data through mobile medical devices that need to be transmitted to medical facilities. Alternatively, the medical records generated during hospital visits need to be stored in medical systems. Such information is used by these institutions and might be delegated by DOs to other organizations. DOs establish access policies that regulate accessibility and only permit DUs with particular attributes. Information and access control policies are transmitted to DCs.

Data Controller (DC): DCs are medical facilities where DOs are treated and which are permitted to use DO medical data. The original medical content is symmetrically encrypted and uploaded as ciphertexts to IPFS. Then, symmetric keys are encrypted according to DO access policies, and the ciphertexts are uploaded to the blockchain infrastructure along with file hash addresses.

Data User (DU): DUs meet data policy requirements. After registration, DUs generate attribute transformation (pre-decryption) keys from their attribute secret keys and send them to the CS. In decryption processes, pre-decryption requests are initially sent to the CS. Once the CS has performed pre-decryption, DUs use the result to reassemble the original content.

Blockchain (BC): Access policies, encrypted symmetric keys, keywords, and file hash addresses uploaded by owners are stored on the blockchain infrastructure. It supports two smart contracts: Upload Contract and Search Contract. The Upload Contract records the contents uploaded by controllers in blockchain ledgers. The Search Contract allows DUs to search ledgers with provided keywords and returns results to querying DUs.

InterPlanetary File System (IPFS): Medical content is stored in the IPFS, which returns hash addresses indicating storage locations. At the request of DUs, files are retrieved using hash addresses and sent to requesting DUs.

3.2. Formal Definition of the Scheme

The proposed scheme consists of six polynomial-time algorithms that cover the entire workflow of attribute-based encryption, including system initialization, user registration, pre-decryption key generation, data encryption, pre-decryption, and final decryption. Formal definitions of each algorithm are below:

• The TA executes the system initialization algorithm $Setup\left(1^{\lambda }\right)\to (PP,msk)$ as follows: Input the system security parameter $\lambda$, output the system public parameters $PP$ and the system master secret key $msk$. This algorithm also completes the initialization of the consortium blockchain and the private IPFS system.
• The TA executes the registration algorithm $Register(msk,S)\to (usk,upk,ask)$ as follows: Input the system master key $msk$ and the user attribute set S, output the user secret key $usk$, user public key $upk$ and attribute secret key $ask$.
• The DU executes the pre-decryption key generation algorithm $Generateprekey(usk,upk,$$ask)\to presk$ as follows: Input the user secret key $usk$, public key $upk$ and attribute secret key $ask$, output the pre-decryption key $presk$. The user then sends this key to the Cloud Server (CS) for decryption outsourcing.
• The DC executes the data encryption algorithm $Encrypt(m,\mathbb{A},PP)\to (CT,c)$ as follows: Input the original medical data m, access policy $\mathbb{A}$ and public parameters $PP$. First, use the AES algorithm to encrypt the data with the symmetric key $esk$ to obtain the ciphertext c, then use the CP-ABE algorithm to encrypt $esk$ to obtain the attribute ciphertext $CT$.
• The CS executes the pre-decryption algorithm $PreDecrypt(PP,CT,presk)\to C{T}_1$ as follows: Input the public parameters $PP$, attribute ciphertext $CT$ and user pre-decryption key $presk$. After verifying that the attributes satisfy the access policy, the CS performs partial decryption operations, outputs intermediate result (pre-decrypted ciphertext) $C{T}_1$ and returns it to the user.
• The DU executes the final decryption algorithm $Decrypt(usk,C{T}_1,c)\to m$ as follows: Input the user secret key $usk$, pre-decrypted ciphertext $C{T}_1$ and symmetric ciphertext c. The user first recovers the symmetric key $esk$, then uses $esk$ to decrypt c to restore the original medical data m.

3.3. Security Model

We define the indistinguishability under chosen-plaintext attack (IND-CPA) security for our hybrid encryption scheme. The security game is played between a probabilistic polynomial-time (PPT) adversary $\mathcal{A}$ and a challenger $\mathcal{C}$. The game proceeds as follows.

Definition 1

(data confidentiality). The scheme achieves data confidentiality if for any PPT adversary $\mathcal{A}$, the advantage in the following game is negligible in the security parameter λ.

Game IND-CPA:

• Initialization. $\mathcal{A}$ submits a challenge access policy ${\mathbb{A}}^{\ast }$ to $\mathcal{C}$. $\mathcal{C}$ runs the system setup algorithm $\mathsf{Setup}\left(1^{\lambda }\right)$ to generate the public parameters $PP$ and the master secret key $msk$. $\mathcal{C}$ sends $PP$ to $\mathcal{A}$.
• Phase 1 (key queries). $\mathcal{A}$ adaptively queries any attribute set S such that S does not satisfy ${\mathbb{A}}^{\ast }$. For each such query, $\mathcal{C}$ does the following:
  • Generates a unique user secret key $usk$ and user public key $upk$ for the attribute set S by simulating the $\mathsf{Register}$ algorithm.
  • Computes the corresponding attribute secret key $ask$ and pre-decryption key $presk$ using the master secret key $msk$ and the user’s $usk$.
  • Returns $(ask,presk)$ to $\mathcal{A}$.
  The challenger maintains a record of all issued keys to ensure consistency (i.e., the same attribute set always receives the same $usk$). No further restriction is imposed; the challenger answers all such queries honestly.
• Challenge. $\mathcal{A}$ outputs two equal-length messages $m_0,m_1$ (representing medical data). $\mathcal{C}$ randomly chooses $b\in \{0,1\}$ and computes the challenge ciphertext $(C{T}^{\ast },c^{\ast })$ by encrypting $m_b$ under the challenge policy ${\mathbb{A}}^{\ast }$ using $\mathsf{Encrypt}(m_b,{\mathbb{A}}^{\ast },PP)$. $\mathcal{C}$ sends $(C{T}^{\ast },c^{\ast })$ to $\mathcal{A}$.
• Phase 2 (key queries). Same as Phase 1. $\mathcal{A}$ may continue to query attribute sets that do not satisfy ${\mathbb{A}}^{\ast }$. The adversary is not allowed to query any attribute set that satisfies ${\mathbb{A}}^{\ast }$, as such a query would trivially allow decryption of the challenge ciphertext.
• Guess. $\mathcal{A}$ outputs a guess $b^{\prime }\in \{0,1\}$. If $b^{\prime }=b$, $\mathcal{A}$ wins.

The adversary’s advantage is defined as

$${Adv}_{\mathcal{A}}^{\mathrm{IND}\text{-}\mathrm{CPA}}\left(\lambda \right)=\left|Pr[b^{\prime }=b]-{\displaystyle \frac{1}{2}}\right|.$$

The scheme is IND-CPA secure if for all PPT adversaries $\mathcal{A}$, ${Adv}_{\mathcal{A}}^{\mathrm{IND}\text{-}\mathrm{CPA}}\left(\lambda \right)$ is negligible in $\lambda$.

4. Construction

This paper describes an outsourced decryption CP-ABE (FAME-WB) architecture based on the FAME architecture to achieve fine-grained access control of medical content on the blockchain infrastructure. In encryption stages, the encryption algorithms first encrypt medical contents, thus facilitating the easy processing of large volumes of information and increasing encryption efficiency. Then, the symmetric keys are encrypted by the CP-ABE framework based on access policies. This enables fine-grained access permission control of the content. A proxy server is implemented to reduce computational loads on users and assist in the decryption process. In particular, users create transformation keys based on their attribute secret keys and send them to the proxy servers. In the decryption process, proxy servers are used to perform transformation operations on the ciphertexts; thus, decryption computations are offloaded and user overhead is significantly lowered. Finally, medical content is recovered by users employing decrypted symmetric keys.

Security verification proves that the proposed framework is resilient to chosen-plaintext attacks and guarantees content confidentiality. The experimental section provides comprehensive performance analysis and comparisons with other approaches, proving that the proposed framework is superior in computational efficiency. Moreover, the performance test of the blockchain and IPFS confirms the viability of the proposed solution.

4.1. FAME-WB Scheme

This scheme consists of four steps: system initialization, registration, data encryption, and data decryption. The detailed algorithm descriptions are as follows.

4.1.1. System Initialization

The TA executes $Setup\left(1^{\lambda }\right)\to (PP,msk)$. Based on the input security parameter $\lambda$, the TA generates $(p,{\mathbb{G}}_1,{\mathbb{G}}_2,{\mathbb{G}}_T,e,g_1,g_2)$, ${\mathbb{G}}_1,{\mathbb{G}}_2$, where ${\mathbb{G}}_1,{\mathbb{G}}_2$ are multiplicative cyclic groups of prime order p, $g_1$ is a generator of ${\mathbb{G}}_1$, and $g_2$ is a generator of ${\mathbb{G}}_2$. The pairing $e:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_T$ is a bilinear map. A hash function $H_1:{\left\{0,1\right\}}^{\ast }\to {\mathbb{G}}_1$ is chosen. Random values $a_1,a_2\leftarrow {}_R\mathbb{Z}_p^{\ast }$ and $d_1,d_2,d_3\leftarrow {}_R\mathbb{Z}_p^{\ast }$ are selected. Compute $L_1=g_2^{a_1},L_2=g_2^{a_2}$ and $D_1=e{(g_1,g_2)}^{d_1{a}_1+d_3},D_2=e{(g_1,g_2)}^{d_2{a}_2+d_3}$. Output the public parameters $PP=(g_1,g_2,L_1,L_2,D_1,D_2,H_1)$. Then, randomly choose $b_1,b_2\leftarrow {}_R\mathbb{Z}_p^{\ast }$ and retain the master secret key as $msk=(g_1,g_2,a_1,a_2,b_1,b_2,g_1^{d_1},g_1^{d_2},g_1^{d_3})$. Finally, initialize the consortium blockchain and the private IPFS system. Participating medical institutions join the consortium blockchain.

4.1.2. Registration

Attribute Key Generation

The Data User (DU) requests registration from the Trusted Authority (TA) by sending an attribute set S. The TA then executes the registration algorithm with the master secret key $msk$ and the attribute set S as inputs: $Register(msk,S)\to (usk,upk,ask)$.

The TA randomly selects $usk,r_1,r_2{\leftarrow }_R{\mathbb{Z}}_p^{\ast }$ and uses the master key components $a_1,a_2,b_1,b_2$ to compute $s{k}_0=(s{k}_{0,1},s{k}_{0,2},s{k}_{0,3})=(g_2^{b_1{r}_1},g_2^{b_2{r}_2},g_2^{r_1+r_2})$.

The user’s public key is calculated as $upk=(up{k}_1,up{k}_2)=(g_1^{{\displaystyle \frac{usk}{a_1}}},g_1^{{\displaystyle \frac{usk}{a_2}}})$.

Then, for each attribute $y\in S$ and for $z=1,2$, the TA randomly selects ${\sigma }_y{\leftarrow }_R{\mathbb{Z}}_p^{\ast }$ and computes

$$s{k}_{y,z}=H_1{\left(y1z\right)}^{{\displaystyle \frac{b_1{r}_1}{a_z}}}·H_1{\left(y2z\right)}^{{\displaystyle \frac{b_2{r}_2}{a_z}}}·H_1{\left(y3z\right)}^{{\displaystyle \frac{r_1+r_2}{a_z}}}·g_1^{{\displaystyle \frac{{\sigma }_y}{a_z}}}.$$

(1)

Define $s{k}_y=(s{k}_{y,1},s{k}_{y,2},g_1^{-{\sigma }_y})$.

Then, for $z=1,2$, the TA randomly selects ${\sigma }^{\prime }{\leftarrow }_R{\mathbb{Z}}_p^{\ast }$ and computes

$$s{k}_z^{\prime }=g_1^{d_z}·H_1{\left(011z\right)}^{{\displaystyle \frac{b_1{r}_1}{a_z}}}·H_1{\left(012z\right)}^{{\displaystyle \frac{b_2{r}_2}{a_z}}}·H_1{\left(013z\right)}^{{\displaystyle \frac{r_1+r_2}{a_z}}}·g_1^{{\displaystyle \frac{{\sigma }^{\prime }}{a_z}}}.$$

(2)

Then compute $s{k}_3^{\prime }=g_1^{d_3}·g_1^{-{\sigma }^{\prime }}$.

Define $s{k}^{\prime }=(s{k}_1^{\prime },s{k}_2^{\prime },s{k}_3^{\prime })$ and the attribute secret key as $ask=(S,s{k}_0,s{k}_{y\in S},s{k}^{\prime })$.

Finally, output the tuple $(ask,usk,upk)$ and return it to the DU.

Pre-Decryption Key Generation

After receiving the public/private key and the attribute secret key, the DU executes the algorithm $Generateprekey(usk,upk,ask)\to presk$ to generate the pre-decryption key. The DU randomly selects ${\alpha }_1,{\alpha }_2{\leftarrow }_R{\mathbb{Z}}_p^{\ast }$. For each attribute $y\in S$ and for $z=1,2$, compute

$$pres{k}_{y,z}=s{k}_{y,z}·up{k}_z^{{\alpha }_1}.$$

(3)

We then compute the third component as

$$pres{k}_{y,3}=s{k}_{y,3}·g_1^{-usk·{\alpha }_1}.$$

(4)

Define $pres{k}_y=(pres{k}_{y,1},pres{k}_{y,2},pres{k}_{y,3})$.

For $z=1,2$, compute

$$pres{k}_z^{\prime }=s{k}_z^{\prime }·up{k}_z^{{\alpha }_2}.$$

(5)

Then randomly select ${\beta }_1{\leftarrow }_R{\mathbb{Z}}_p^{\ast }$, and compute

$$s{k}_b=g_1^{{\beta }_1},pres{k}_3^{\prime }=s{k}_3^{\prime }·g_1^{-usk·{\alpha }_2}·s{k}_b^{usk}.$$

(6)

Define $pres{k}^{\prime }=(pres{k}_1^{\prime },pres{k}_2^{\prime },pres{k}_3^{\prime })$.

Finally, output the pre-decryption key as $presk=(S,s{k}_0,pres{k}_y,pres{k}^{\prime },s{k}_b)$ and send it to the Cloud Server (CS).

4.1.3. Data Decryption

Pre-Decryption

When the Data User (DU) requests data, it invokes a smart contract to obtain the ciphertext $CT$ and then sends $CT$ to the Cloud Server (CS) for pre-decryption. The CS first checks whether the attribute set S in the pre-decryption key $presk$ satisfies the access structure embedded in the ciphertext $\mathbb{A}=(M,\pi )$. If not, decryption is aborted. Otherwise, the proxy server proceeds with the following operations: $PreDecrypt(PP,CT,presk)\to C{T}_1$.

Define the set $I\subset \{1,2,\dots ,n_1\}$ as $I=\{j:\pi (j)\in S\}$. Then compute the linear combination ${\sum }_{i\in I}{\theta }_i·M_i=(1,0,\dots ,0)$ to obtain the coefficients ${\left\{{\theta }_i\right\}}_{i\in I}$. The proxy server computes the numerator and denominator of the intermediate decryption result:

$$num=c{t}^{\prime }·e\left(\prod _{i\in I}c{t}_{i,1}^{{\theta }_i},s{k}_{0,1}\right)·e\left(\prod _{i\in I}c{t}_{i,2}^{{\theta }_i},s{k}_{0,2}\right)·e\left(\prod _{i\in I}c{t}_{i,3}^{{\theta }_i},s{k}_{0,3}\right),$$

(7)

$$\begin{array}{cc}\hfill den& =e\left(pres{k}_1^{\prime }·\prod _{i\in I}pres{k}_{\pi \left(i\right),1}^{{\theta }_i},c{t}_{0,1}\right)·e\left(pres{k}_2^{\prime }·\prod _{i\in I}pres{k}_{\pi \left(i\right),2}^{{\theta }_i},c{t}_{0,2}\right)\hfill \\ \hfill & ·e\left(pres{k}_3^{\prime }·\prod _{i\in I}pres{k}_{\pi \left(i\right),3}^{{\theta }_i},c{t}_{0,3}\right).\hfill \end{array}$$

(8)

Then compute the intermediate result $prect={\displaystyle \frac{num}{den}}$ and output the pre-decrypted ciphertext $C{T}_1=(prect,c{t}_{0,3})$. Finally, the CS sends $C{T}_1$ to the DU.

Final Decryption

Upon receiving $C{T}_1$, the DU executes the decryption algorithm $Decrypt(usk,s{k}_b,C{T}_1)\to esk$ to recover the symmetric key $esk$, computed as

$$esk=prect·e\left(s{k}_b^{usk},c{t}_{0,3}\right).$$

(9)

Then, using the hash address of the file, the DU downloads the encrypted data $c{t}^{\prime }$ from IPFS and performs $AES.Dec(esk,c{t}^{\prime })$ to recover the original medical data m.

4.2. Correctness Verification

This subsection provides the correctness proof of the proposed scheme. In the outsourced decryption process, the partially decrypted ciphertext is expressed as $prect=num/den$. We derive the expressions for $num$, $den$, and $prect$, respectively, and clarify each key derivation step to ensure readability.

First, we derive the expression of $num$. The computation begins with the evaluation of ${\displaystyle \prod _{i\in I}}c{t}_{i,k}^{{\theta }_i}$ for $k=1,2,3$, which is the core aggregation operation of the ciphertext components. By using the critical linear reconstruction condition ${\sum }_{i\in I}{\theta }_i{M}_i=(1,0,\dots ,0)$, we expand and rearrange the product terms step by step, and the detailed derivation for a general k is shown as follows:

$$\begin{array}{cc}\hfill \prod _{i\in I}c{t}_{i,k}^{{\theta }_i}& =\prod _{i\in I}\left(H_1{\left(\pi \left(i\right)k1\right)}^{{\theta }_i{s}_1}·H_1{\left(\pi \left(i\right)k2\right)}^{{\theta }_i{s}_2}·\prod _{j=1}^{n_2}{\left[H_1{\left(0jk1\right)}^{s_1}·H_1{\left(0jk2\right)}^{s_2}\right]}^{{\theta }_i{M}_{i,j}}\right)\hfill \\ \hfill & =\left(\prod _{j=1}^{n_2}{\left[H_1{\left(0jk1\right)}^{s_1}·H_1{\left(0jk2\right)}^{s_2}\right]}^{{\sum }_{i\in I}{\theta }_i{M}_{i,j}}\right)·\left(\prod _{i\in I}{H}_1{\left(\pi \left(i\right)k1\right)}^{{\theta }_i{s}_1}·H_1{\left(\pi \left(i\right)k2\right)}^{{\theta }_i{s}_2}\right)\hfill \\ \hfill & =\left(\prod _{j=1}^{n_2}{\left[H_1{\left(0jk1\right)}^{s_1}·H_1{\left(0jk2\right)}^{s_2}\right]}^{{\delta }_{j1}}\right)·\left(\prod _{i\in I}{H}_1{\left(\pi \left(i\right)k1\right)}^{{\theta }_i{s}_1}·H_1{\left(\pi \left(i\right)k2\right)}^{{\theta }_i{s}_2}\right)\hfill \\ \hfill & =\left(H_1{\left(01k1\right)}^{s_1}·H_1{\left(01k2\right)}^{s_2}\right)·\left(\prod _{i\in I}{H}_1{\left(\pi \left(i\right)k1\right)}^{{\theta }_i{s}_1}·H_1{\left(\pi \left(i\right)k2\right)}^{{\theta }_i{s}_2}\right).\hfill \end{array}$$

(10)

Next, we compute the bilinear mapping value $num/c{t}^{\prime }$ based on the above result. This step combines the hash functions, random parameters, and bilinear pairing properties. We expand the formula for $t\in \{1,2\}$ and split the combined terms to get the explicit expression:

$${\displaystyle \begin{array}{cc}\hfill \frac{num}{c{t}^{\prime }}& =\prod _{t\in \{1,2\}}[e{(H_1\left(011t\right),g_2)}^{b_1{r}_1{s}_t}·e{(H_1\left(012t\right),g_2)}^{b_2{r}_2{s}_t}·e{(H_1\left(013t\right),g_2)}^{(r_1+r_2)s_t}\hfill \\ \hfill & ·\prod _{i\in I}(e{(H_1\left(\pi \left(i\right)1t\right),g_2)}^{b_1{r}_1{\theta }_i{s}_t}·e{(H_1\left(\pi \left(i\right)2t\right),g_2)}^{b_2{r}_2{\theta }_i{s}_t}\hfill \\ \hfill & ·e{(H_1\left(\pi \left(i\right)3t\right),g_2)}^{(r_1+r_2){\theta }_i{s}_t})]\hfill \\ \hfill & =e{(H_1\left(0111\right),g_2)}^{b_1{r}_1{s}_1}·e{(H_1\left(0121\right),g_2)}^{b_2{r}_2{s}_1}·e{(H_1\left(0131\right),g_2)}^{(r_1+r_2)s_1}\hfill \\ \hfill & ·e{(H_1\left(0112\right),g_2)}^{b_1{r}_1{s}_2}·e{(H_1\left(0122\right),g_2)}^{b_2{r}_2{s}_2}·e{(H_1\left(0132\right),g_2)}^{(r_1+r_2)s_2}\hfill \\ \hfill & ·\prod _{i\in I}(e{(H_1\left(\pi \left(i\right)11\right),g_2)}^{b_1{r}_1{\theta }_i{s}_1}·e{(H_1\left(\pi \left(i\right)21\right),g_2)}^{b_2{r}_2{\theta }_i{s}_1}\hfill \\ \hfill & ·e{(H_1\left(\pi \left(i\right)31\right),g_2)}^{(r_1+r_2){\theta }_i{s}_1})\hfill \\ \hfill & ·\prod _{i\in I}(e{(H_1\left(\pi \left(i\right)12\right),g_2)}^{b_1{r}_1{\theta }_i{s}_2}·e{(H_1\left(\pi \left(i\right)22\right),g_2)}^{b_2{r}_2{\theta }_i{s}_2}\hfill \\ \hfill & ·e{(H_1\left(\pi \left(i\right)32\right),g_2)}^{(r_1+r_2){\theta }_i{s}_2}).\hfill \end{array}}$$

(11)

Next, we simplify the denominator $den$. It can be observed that $den$ is the product of three independent bilinear pairings, corresponding to three groups of partial secret keys and ciphertext components. We compute these three bilinear pairing terms separately to show the internal structure clearly.

First term: This term is constructed by the first partial secret key and ciphertext $c{t}_{0,1}$. By substituting the definitions of $pres{k}_1^{\prime }$, $pres{k}_{\pi \left(i\right),1}$ and $c{t}_{0,1}$, and using the bilinearity of the pairing function, we expand the formula as:

$$\begin{array}{cc}\hfill & e\left(pres{k}_1^{\prime }·\prod _{i\in I}pres{k}_{\pi \left(i\right),1}^{{\theta }_i},c{t}_{0,1}\right)\hfill \\ \hfill & =e(g_1^{d_1}·H_1{\left(0111\right)}^{{\displaystyle \frac{b_1{r}_1}{a_1}}}·H_1{\left(0121\right)}^{{\displaystyle \frac{b_2{r}_2}{a_1}}}·H_1{\left(0131\right)}^{{\displaystyle \frac{r_1+r_2}{a_1}}}·g_1^{{\displaystyle \frac{{\sigma }^{\prime }}{a_1}}}·up{k}_1^{{\alpha }_2}\hfill \\ \hfill & ·\prod _{i\in I}{H}_1{\left(\pi \left(i\right)11\right)}^{{\displaystyle \frac{b_1{r}_1{\theta }_i}{a_1}}}·H_1{\left(\pi \left(i\right)21\right)}^{{\displaystyle \frac{b_2{r}_2{\theta }_i}{a_1}}}·H_1{\left(\pi \left(i\right)31\right)}^{{\displaystyle \frac{(r_1+r_2){\theta }_i}{a_1}}}·g_1^{{\displaystyle \frac{{\sigma }_y}{a_1}}}·up{k}_1^{{\alpha }_1},g_2^{a_1{s}_1})\hfill \\ \hfill & =e{(g_1,g_2)}^{d_1{a}_1{s}_1}·e{(H_1\left(0111\right),g_2)}^{b_1{r}_1{s}_1}·e{(H_1\left(0121\right),g_2)}^{b_2{r}_2{s}_1}\hfill \\ \hfill & ·e{(H_1\left(0131\right),g_2)}^{(r_1+r_2)s_1}·e{(g_1,g_2)}^{{\sigma }^{\prime }{s}_1}·e{(g_1,g_2)}^{usk{\alpha }_2{s}_1}\hfill \\ \hfill & ·\prod _{i\in I}[e{(H_1\left(\pi \left(i\right)11\right),g_2)}^{b_1{r}_1{\theta }_i{s}_1}·e{(H_1\left(\pi \left(i\right)21\right),g_2)}^{b_2{r}_2{\theta }_i{s}_1}\hfill \\ \hfill & ·e{(H_1\left(\pi \left(i\right)31\right),g_2)}^{(r_1+r_2){\theta }_i{s}_1}·e{(g_1,g_2)}^{{\sigma }_y{\theta }_i{s}_1}·e{(g_1,g_2)}^{usk{\alpha }_1{\theta }_i{s}_1}].\hfill \end{array}$$

(12)

Second term: This term corresponds to the second partial secret key and ciphertext $c{t}_{0,2}$. Following the same expansion rule as the first term, we obtain the following result:

$$\begin{array}{cc}\hfill & e\left(pres{k}_2^{\prime }·\prod _{i\in I}pres{k}_{\pi \left(i\right),2}^{{\theta }_i},c{t}_{0,2}\right)\hfill \\ \hfill & =e(g_1^{d_2}·H_1{\left(0112\right)}^{{\displaystyle \frac{b_1{r}_1}{a_2}}}·H_1{\left(0122\right)}^{{\displaystyle \frac{b_2{r}_2}{a_2}}}·H_1{\left(0132\right)}^{{\displaystyle \frac{r_1+r_2}{a_2}}}·g_1^{{\displaystyle \frac{{\sigma }^{\prime }}{a_2}}}·up{k}_2^{{\alpha }_2}\hfill \\ \hfill & ·\prod _{i\in I}{H}_1{\left(\pi \left(i\right)12\right)}^{{\displaystyle \frac{b_1{r}_1{\theta }_i}{a_2}}}·H_1{\left(\pi \left(i\right)22\right)}^{{\displaystyle \frac{b_2{r}_2{\theta }_i}{a_2}}}·H_1{\left(\pi \left(i\right)32\right)}^{{\displaystyle \frac{(r_1+r_2){\theta }_i}{a_2}}}·g_1^{{\displaystyle \frac{{\sigma }_y}{a_2}}}·up{k}_2^{{\alpha }_1},g_2^{a_2{s}_2})\hfill \\ \hfill & =e{(g_1,g_2)}^{d_2{a}_2{s}_2}·e{(H_1\left(0112\right),g_2)}^{b_1{r}_1{s}_2}·e{(H_1\left(0122\right),g_2)}^{b_2{r}_2{s}_2}\hfill \\ \hfill & ·e{(H_1\left(0132\right),g_2)}^{(r_1+r_2)s_2}·e{(g_1,g_2)}^{{\sigma }^{\prime }{s}_2}·e{(g_1,g_2)}^{usk{\alpha }_2{s}_2}\hfill \\ \hfill & ·\prod _{i\in I}[e{(H_1\left(\pi \left(i\right)12\right),g_2)}^{b_1{r}_1{\theta }_i{s}_2}\hfill \\ \hfill & ·e{(H_1\left(\pi \left(i\right)22\right),g_2)}^{b_2{r}_2{\theta }_i{s}_2}·e{(H_1\left(\pi \left(i\right)32\right),g_2)}^{(r_1+r_2){\theta }_i{s}_2}·e{(g_1,g_2)}^{{\sigma }_y{\theta }_i{s}_2}\hfill \\ \hfill & ·e{(g_1,g_2)}^{usk{\alpha }_1{\theta }_i{s}_2}].\hfill \end{array}$$

(13)

Third term: This term is derived from the third partial secret key and ciphertext $c{t}_{0,3}$. After substitution and bilinear pairing expansion, the expression is simplified as:

$$\begin{array}{cc}\hfill & e\left(pres{k}_3^{\prime }·\prod _{i\in I}pres{k}_{\pi \left(i\right),3}^{{\theta }_i},c{t}_{0,3}\right)\hfill \\ \hfill & =e\left(g_1^{d_3}·g_1^{-{\sigma }^{\prime }}·g_1^{-usk{\alpha }_2}·s{k}_b^{usk}·\prod _{i\in I}{g}_1^{-{\sigma }_y{\theta }_i}·g_1^{-usk{\alpha }_1{\theta }_i},g_2^{s_1+s_2}\right)\hfill \\ \hfill & =e{(g_1,g_2)}^{d_3(s_1+s_2)}·e{(g_1,g_2)}^{-{\sigma }^{\prime }(s_1+s_2)}·e{(g_1,g_2)}^{-usk{\alpha }_2(s_1+s_2)}\hfill \\ \hfill & ·e{(g_1,g_2)}^{usk{\beta }_1(s_1+s_2)}\hfill \\ \hfill & ·\prod _{i\in I}\left[e{(g_1,g_2)}^{-{\sigma }_y{\theta }_i(s_1+s_2)}·e{(g_1,g_2)}^{-usk{\alpha }_1{\theta }_i(s_1+s_2)}\right].\hfill \end{array}$$

(14)

Multiplying these three terms together, all the redundant security parameters including $usk$, ${\alpha }_1$, ${\alpha }_2$, ${\sigma }^{\prime }$, and ${\sigma }_y$ are completely canceled out, which is the key property of our outsourced decryption design. Subsequently, we calculate the final partially decrypted ciphertext $prect=num/den$:

$$\begin{array}{cc}\hfill prect={\displaystyle \frac{num}{den}}& ={\displaystyle \frac{esk·e{(g_1,g_2)}^{d_1{a}_1{s}_1+d_2{a}_2{s}_2+d_3(s_1+s_2)}}{e{(g_1,g_2)}^{d_1{a}_1{s}_1+d_2{a}_2{s}_2+d_3(s_1+s_2)}·e{(g_1,g_2)}^{usk{\beta }_1(s_1+s_2)}}}\hfill \\ \hfill & ={\displaystyle \frac{esk}{e{(g_1,g_2)}^{usk{\beta }_1(s_1+s_2)}}}.\hfill \end{array}$$

(15)

During the ciphertext recovery phase, the Data User only needs to perform a simple computation to recover the symmetric key $esk$:

$$esk=prect·e\left(s{k}_b^{usk},c{t}_{0,3}\right).$$

To verify the correctness, we substitute the expression of $prect$ into the recovery formula. By using the definition of secret keys and bilinear pairing properties, the intermediate terms cancel each other out, and we can directly obtain the symmetric key:

$$prect·e\left(s{k}_b^{usk},c{t}_{0,3}\right)={\displaystyle \frac{esk}{e{(g_1,g_2)}^{usk{\beta }_1(s_1+s_2)}}}·e(g_1^{usk{\beta }_1},g_2^{s_1+s_2})=esk.$$

(16)

Finally, the user decrypts the symmetric ciphertext c using $esk$ to recover the original medical data $m=AES.Dec(esk,c)$.

5. Security Proof and Analysis

Based on the security model presented by the proposed framework and appropriate cryptographic assumptions, the IND-CPA security is presented in this section with detailed security verification conducted from two fundamental viewpoints: explicit collusion resistance and malicious proxy behavior resistance, integrated with realistic medical data sharing scenarios and attribute-based encryption (ABE) properties. It is emphasized that the proposed framework is medical-data-sharing-specific, and its access control system based on ABE is one of the most suitable approaches to address permission management requirements. The access policies are built based on the features of medical entities (e.g., department of medical staff, professional title, authorization level) and content types (e.g., patient diagnosis records, genetic information, imaging reports), which ensures that only the appropriate authorities have access to the relevant sensitive information. Every security demonstration and verification hereafter is closely incorporated with this practical setting and fully demonstrates that the framework is secure and can be applied in real medical data sharing and ABE application scenarios.

5.1. Security Proof

Theorem 1.

If the Computational Bilinear Diffie–Hellman (CBDH) problem is hard and the FAME scheme is IND-CPA secure [13] and AES is secure [22], then the proposed scheme is also IND-CPA secure.

Proof. 

Assume there exists a probabilistic polynomial-time (PPT) adversary $\mathcal{A}$ that can break the IND-CPA security of our scheme. The challenger $\mathcal{C}$ constructs an algorithm $\mathcal{B}$ that uses $\mathcal{A}$ to solve the hard CBDH problem and break the security of the FAME scheme and AES, which contradicts the hardness assumption of the CBDH problem and the security of FAME and AES, thus proving the IND-CPA security of the proposed scheme. □

Initialization: $\mathcal{A}$ selects a challenge access policy ${\mathbb{A}}^{\ast }$ (specifically designed for medical data access, e.g., “only cardiologists with 5+ years of clinical experience can access patients’ cardiac interventional therapy records”) and sends it to $\mathcal{C}$. $\mathcal{C}$ inputs the security parameter $\lambda$ and runs the system setup $Setup\left(1^{\lambda }\right)\to (PP,msk)$. $\mathcal{C}$ randomly chooses $a_1,a_2\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{\ast }$ (where ${\mathbb{Z}}_p^{\ast }$ denotes the multiplicative group of integers modulo a prime p) and $d_1,d_2,d_3\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{\ast }$, and computes parameters $L_1=g_2^{a_1}$, $L_2=g_2^{a_2}$, $D_1=e{(g_1,g_2)}^{d_1{a}_1+d_3}$, and $D_2=e{(g_1,g_2)}^{d_2{a}_2+d_3}$. Here, ${\mathbb{G}}_1$, ${\mathbb{G}}_2$, and ${\mathbb{G}}_T$ are multiplicative cyclic groups of prime order p, $g_1$ is a generator of ${\mathbb{G}}_1$, $g_2$ is a generator of ${\mathbb{G}}_2$, and $e:{\mathbb{G}}_1\times {\mathbb{G}}_2\to {\mathbb{G}}_T$ is a bilinear pairing (all are standard definitions in cryptographic assumptions). The public parameters are $PP=(g_1,g_2,L_1,L_2,D_1,D_2,H_1)$ (where $H_1$ is a cryptographic hash function) and the master secret key is $msk=(g_1,g_2,a_1,a_2,b_1,b_2,g_1^{d_1},g_1^{d_2},g_1^{d_3})$. Then, $\mathcal{C}$ randomly selects $usk,v,s_1,s_2\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{\ast }$ and sets $w=s_1+s_2$. Let $(g_1^{usk},g_1^v,g_2^w)\in {\mathbb{G}}_1^2\times {\mathbb{G}}_2$ be a CBDH challenge tuple, where the CBDH problem is defined as follows: given $(g_1^a,g_1^b,g_2^c)\in {\mathbb{G}}_1^2\times {\mathbb{G}}_2$ with $a,b,c{\leftarrow }_R{\mathbb{Z}}_p^{\ast }$, compute $e{(g_1,g_2)}^{abc}\in {\mathbb{G}}_T$. An empty list is set to record attribute sets and pre-decryption keys. Then, $PP$ and the tuple $(g_1^{usk},g_1^v,g_2^w)$ are sent to $\mathcal{B}$, who forwards $PP$ to $\mathcal{A}$.

Query Phase 1: $\mathcal{A}$ queries $\mathcal{B}$ for an attribute private key and pre-decryption key for an attribute set $S_1^{\ast }$ (e.g., “general practitioners in the general internal medicine department”, which does not satisfy ${\mathbb{A}}^{\ast }$). $\mathcal{B}$ checks if $S_1^{\ast }$ satisfies the access policy ${\mathbb{A}}^{\ast }$. If it does, $\mathcal{B}$ aborts and returns failure. Otherwise, $\mathcal{B}$ queries $\mathcal{C}$ for the attribute private key for $S_1^{\ast }$. $\mathcal{C}$ runs $Register(msk,S_1^{\ast })\to (us{k}^{\ast },up{k}^{\ast },as{k}^{\ast })$. $\mathcal{C}$ checks whether $g_1^{us{k}^{\ast }}$ equals $g_1^u$ or $g_1^v$; if so, it aborts the game. Otherwise, $\mathcal{C}$ uses the private key $us{k}^{\ast }$ and public key $up{k}^{\ast }$ to run $Generateprekey(us{k}^{\ast },up{k}^{\ast },as{k}^{\ast })\to pres{k}^{\ast }$ to generate the pre-decryption private key $pres{k}^{\ast }$. $\mathcal{C}$ returns $us{k}^{\ast },up{k}^{\ast },as{k}^{\ast }$, and $pres{k}^{\ast }$ to $\mathcal{B}$, who forwards them to adversary $\mathcal{A}$.

Query Phase 2: The adversary $\mathcal{A}$ queries $\mathcal{B}$ for a pre-decryption private key for an attribute set $S^{\ast }$ (e.g., “cardiologists with 5+ years of clinical experience”, which satisfies ${\mathbb{A}}^{\ast }$). $\mathcal{B}$ checks if $S^{\ast }$ satisfies the access policy ${\mathbb{A}}^{\ast }$. If yes, $\mathcal{B}$ queries $\mathcal{C}$ for the pre-decryption key for $S^{\ast }$; otherwise, $\mathcal{B}$ aborts and returns failure.

Firstly, $\mathcal{C}$ generates attribute keys by randomly selecting $r_1,r_2\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{\ast }$, then computes $s{k}_0=(s{k}_{0,1},s{k}_{0,2},s{k}_{0,3})=(g_2^{b_1{r}_1},g_2^{b_2{r}_2},g_2^{r_1+r_2})$ using $usk$ and the master secret key components $a_1,a_2,b_1,b_2$ (where $b_1,b_2$ are random parameters generated in the system setup phase). The public key is $upk=(up{k}_1,up{k}_2)=(g_1^{{\displaystyle \frac{usk}{a_1}}},g_1^{{\displaystyle \frac{usk}{a_2}}})$. Then, for each attribute $y\in S^{\ast }$ (e.g., “cardiology department”, “5+ years of clinical experience”) and $z=1,2$, randomly select ${\sigma }_y\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{\ast }$ and compute

$$s{k}_{y,z}=H_1{\left(y1z\right)}^{{\displaystyle \frac{b_1{r}_1}{a_z}}}·H_1{\left(y2z\right)}^{{\displaystyle \frac{b_2{r}_2}{a_z}}}·H_1{\left(y3z\right)}^{{\displaystyle \frac{r_1+r_2}{a_z}}}·g_1^{{\displaystyle \frac{{\sigma }_y}{a_z}}}$$

(17)

Set $s{k}_y=(s{k}_{y,1},s{k}_{y,2},g_1^{-{\sigma }_y})$. For $z=1,2$, randomly select ${\sigma }^{\prime }\stackrel{R}{\leftarrow }{\mathbb{Z}}_p^{\ast }$ and compute

$$s{k}_z^{\prime }=g_1^{d_z}{H}_1{\left(011z\right)}^{{\displaystyle \frac{b_1{r}_1}{a_z}}}·H_1{\left(012z\right)}^{{\displaystyle \frac{b_2{r}_2}{a_z}}}·H_1{\left(013z\right)}^{{\displaystyle \frac{r_1+r_2}{a_z}}}·g_1^{{\displaystyle \frac{{\sigma }^{\prime }}{a_z}}}$$

(18)

Calculate $s{k}_3^{\prime }=g_1^{d_3}·g_1^{-{\sigma }^{\prime }}$, and set $s{k}^{\prime }=(s{k}_1^{\prime },s{k}_2^{\prime },s{k}_3^{\prime })$. The attribute private key is $as{k}_1^{\ast }=(S^{\ast },s{k}_0,s{k}_{y\in S^{\ast }},s{k}^{\prime })$. Output $(as{k}_1^{\ast },upk)$. Then, $\mathcal{C}$ generates the pre-decryption private key by running $Generateprekey(usk,upk,as{k}_1^{\ast })\to pres{k}_1^{\ast }$. $\mathcal{C}$ returns $pres{k}_1^{\ast }$ to $\mathcal{B}$, who forwards it to $\mathcal{A}$.

Challenge: $\mathcal{A}$ chooses two messages $(m_0,m_1)$ of equal length (corresponding to sensitive medical data, e.g., $m_0$: “Patient X’s cardiac interventional therapy: successful stenting, no complications”, $m_1$: “Patient Y’s cardiac interventional therapy: stent implantation failed, need reoperation”) and sends them to $\mathcal{B}$, who forwards them to $\mathcal{C}$. $\mathcal{C}$ randomly selects $b\in \{0,1\}$, generates a symmetric encryption key $esk$, then computes $c{t}^{\prime }=AES.Enc(esk,m_b)$ as the symmetric ciphertext (used to encrypt core medical data). Next, $\mathcal{C}$ encrypts $esk$ under the access policy ${\mathbb{A}}^{\ast }$ to produce the attribute ciphertext, computing $c{t}_0=(c{t}_{0,1},c{t}_{0,2},c{t}_{0,3})=(L_1^{s_1},L_2^{s_2},g_2^w)$. Suppose ${\mathbb{A}}^{\ast }=(M,\pi )$ (where M is a matrix corresponding to the access policy, and $\pi$ is a mapping that maps each row of M to an attribute, following the standard linear secret sharing scheme (LSSS) definition) with M of dimension $n_1\times n_2$, indexed by $i,j$. For $k=1,2,3$ and $i=1,\dots ,n_1$ (corresponding to different medical data access constraints), the Data Owner computes

$$c{t}_{i,k}=H_1{\left(\pi \left(i\right)k1\right)}^{s_1}·H_1{\left(\pi \left(i\right)k2\right)}^{s_2}·\prod _{j=1}^{n_2}{[H_1{\left(0jk1\right)}^{s_1}·H_1{\left(0jk2\right)}^{s_2}]}^{M_{i,j}}$$

(19)

Set $c{t}_i=(c{t}_{i,1},c{t}_{i,2},c{t}_{i,3})$. Also, compute $c{t}^{\prime }=D_1^{s_1}·D_2^{s_2}·esk$. The attribute ciphertext is $CT=({\mathbb{A}}^{\ast },c{t}_0,c{t}_1,\dots ,c{t}_{n_1},c{t}^{\prime })$. The symmetric ciphertext $c{t}^{\prime }$ and attribute ciphertext $CT$ are returned to $\mathcal{B}$, who forwards them to $\mathcal{A}$.

Query Phase 3: Repeat Query Phase 1 with a different attribute set $S_2^{\ast }$ (e.g., “neurologists in the neurology department”) for attribute private key and pre-decryption key queries.

Guess: $\mathcal{A}$ outputs a guess $b^{\ast }$ for b. $\mathcal{B}$ forwards $b^{\ast }$ to $\mathcal{C}$. If $b^{\ast }=b$, $\mathcal{C}$ outputs 1; otherwise, 0.

Analysis: If $\mathcal{A}$ can break the IND-CPA security of the scheme, it means the symmetric key $esk$ can be recovered correctly, and $b^{\ast }$ can be guessed with non-negligible advantage (where a negligible function $\mathrm{negl}\left(\lambda \right)$ denotes a function that vanishes faster than the inverse of any polynomial in $\lambda$). Then $\mathcal{B}$ can break the security of the FAME scheme and AES. Using $CT$ and the pre-decryption key $pres{k}_1^{\ast }$, $\mathcal{B}$ runs $PreDecrypt(PP,CT,preas{k}_1^{\ast })$ to obtain the pre-decryption ciphertext $C{T}_1=(prect,c{t}_{0,3})$. From the correctness analysis, we have $prect=esk/e{(g_1,g_2)}^w$. Then, $C{T}_1$ and $as{k}_1^{\ast }$ are given to the adversary $\mathcal{A}$ to guess $b^{\ast }$. Therefore, if there exists an adversary $\mathcal{A}$ that can break the IND-CPA security of the scheme, it can be used to solve the CBDH problem and break the security of the FAME scheme and AES. In the medical data sharing scenario, this proof ensures that unauthorized entities (e.g., malicious external attackers, medical staff without corresponding attributes) cannot crack the encrypted medical data, which is the core security guarantee of the ABE-based medical data sharing scheme.

5.2. Security Analysis

This subsection conducts in-depth security analysis from two key aspects (collusion resistance and malicious proxy behavior resistance) closely combined with the medical data sharing scenario and ABE characteristics to comprehensively verify the security of the scheme in practical application.

5.2.1. Collusion Resistance Analysis

Collusion attack refers to multiple adversaries with different attribute sets colluding with each other, combining their attribute private keys and pre-decryption keys to decrypt ciphertexts that none of them can decrypt individually. In the medical data sharing scenario, collusion attacks are particularly dangerous—they may occur between malicious medical staff (e.g., a general nurse and a non-authorized physician colluding to access patient surgical records) or external attackers colluding with internal staff, which poses a serious threat to patient privacy. As an ABE-based scheme, collusion resistance is a core security requirement to ensure that the attribute-based access control mechanism is not bypassed.

The proposed scheme achieves collusion resistance through the following explicit mechanisms, which are closely combined with the medical data sharing scenario and ABE characteristics:

• User-Specific randomization in key generation. For each Data User (medical staff), the Trusted Authority (TA) independently samples random exponents ${\sigma }_y$, ${\sigma }^{\prime }$, ${\alpha }_1$, ${\alpha }_2$ during the registration and pre-decryption key generation phases. These random values are embedded into the attribute secret key $ask$ and the pre-decryption key $presk$. Because the randomness is statistically independent across users, keys from different users cannot be combined to produce a valid key for any attribute set that is not already satisfied by a single user’s attributes.
• LSSS reconstruction constraint with blinding factors. The access policy $\mathbb{A}=(M,\pi )$ is realized via a linear secret sharing scheme (LSSS). Decryption requires finding coefficients ${\left\{{\theta }_i\right\}}_{i\in I}$ such that ${\sum }_{i\in I}{\theta }_i{M}_i=(1,0,\dots ,0)$, where I corresponds to the set of rows whose labels $\pi \left(i\right)$ belong to the user’s attribute set. Even if the union of attribute sets from multiple colluding users satisfies the access policy (e.g., $\bigcup S_j$ meets ${\mathbb{A}}^{\ast }$), the decryption algorithm $\mathsf{PreDecrypt}$ operates on a single user’s pre-decryption key $presk$ at a time. The LSSS reconstruction must use the shares derived from one user’s key because the ciphertext components are paired with that user’s specific blinding factors (e.g., $r_1,r_2,{\alpha }_1,{\alpha }_2$). When two different users’ keys are mixed, the mismatched random exponents prevent cancellation in the pairing operations, making it impossible to reconstruct the secret.
• Binding to user secret key. Each user’s pre-decryption key is blinded with their own user secret key $usk$ via terms like $up{k}_z^{{\alpha }_1}$ and $g_1^{-usk·{\alpha }_1}$, where $up{k}_z=g_1^{usk/a_z}$. Different users have distinct $usk$ values randomly chosen by the TA. Any attempt to combine $presk$ from two users results in mismatched exponents that do not cancel during the final decryption step $esk=prect·e(s{k}_b^{usk},c{t}_{0,3})$. Hence, even if colluding users pool their keys, they cannot recover the symmetric key $esk$ or the original medical data.

Formal argument: Assume a set of colluding users with attribute sets $S_1,\dots ,S_k$ and corresponding pre-decryption keys $pres{k}^{\left(1\right)},\dots ,pres{k}^{\left(k\right)}$. Suppose, for contradiction, that they can jointly decrypt a ciphertext encrypted under policy ${\mathbb{A}}^{\ast }$ that no individual $S_j$ satisfies. To succeed, they must be able to compute the intermediate value $prect$ as defined in Equations (7) and (8). However, the computation of $num$ and $den$ requires pairing ciphertext components with a single user’s $presk$ (specifically, the terms ${\prod }_{i\in I}pres{k}_{\pi \left(i\right),1}^{{\theta }_i}$ all come from the same $presk$). The LSSS coefficients ${\theta }_i$ are computed based on the rows whose attributes are present in that user’s key. If the user’s key does not contain all necessary attributes, the set I is insufficient. Because the adversary cannot merge attributes from different users into one $presk$ (the random blinding factors are user-specific), the combined effort does not yield a valid reconstruction. Therefore, the scheme is collusion-resistant.

This analysis holds under the standard assumption that the TA is trusted and does not collude with adversaries. In the medical data sharing scenario, the proposed scheme effectively prevents malicious medical staff or external attackers from bypassing the ABE-based access control through collusion.

5.2.2. Malicious Proxy Behavior Analysis

In the proposed ABE-based medical data sharing scheme, the Cloud Server (CS) acts as a proxy to perform partial decryption, which reduces the computational burden on Data Users (medical staff) who often use mobile devices (such as tablet computers) with limited computing resources to access medical data. However, the proxy (Cloud Server) may be malicious and attempt to obtain sensitive medical data (such as patient HIV diagnosis records) or tamper with the pre-decrypted ciphertext (such as modifying the patient’s blood pressure data) during the pre-decryption process. Therefore, analyzing the resistance of the scheme to malicious proxy behavior is crucial to ensure the security of medical data in the ABE-based sharing process.

The proposed scheme resists malicious proxy behavior through the following targeted designs, which are tailored to the medical data sharing scenario:

• Pre-decryption key limitation: The pre-decryption key $presk$ sent by the medical staff (Data User) to the proxy only contains partial decryption information and does not include the user’s secret key $usk$ or the symmetric key $esk$. The proxy can only perform partial decryption to generate the intermediate ciphertext $C{T}_1=(prect,c{t}_{0,3})$, but cannot recover the symmetric key $esk$ or the original medical data m alone. For example, the Cloud Server cannot obtain the patient’s HIV diagnosis result by only holding the pre-decryption key, which ensures that the proxy cannot directly access sensitive medical data, fundamentally preventing the proxy from stealing core medical information.
• Final decryption by Data User: The final decryption process must be completed by the medical staff (Data User) using their own secret key $usk$. The proxy only provides the intermediate result $prect$, and the medical staff needs to compute $esk=prect·e(s{k}_b^{usk},c{t}_{0,3})$ to recover the symmetric key (where $s{k}_b$ is a component of the user’s attribute private key), then decrypt the symmetric ciphertext $c{t}^{\prime }$ to obtain the original medical data. Even if the proxy tampers with $prect$ (e.g., modifying the intermediate result of blood pressure data), the medical staff can detect the tampering by verifying the correctness of the decrypted data (e.g., through hash checks or medical data validity verification, such as checking whether the blood pressure value is within a reasonable range), which is particularly important for medical data that requires high accuracy. This two-step decryption mechanism ensures that the proxy cannot tamper with medical data without being detected.
• Blockchain-based audit: The ciphertext hash address, access policy, and pre-decryption records (such as which medical staff accessed which medical data, when, and the proxy’s pre-decryption operations) are stored on the blockchain, which is immutable and transparent. If the proxy performs malicious behavior (such as tampering with the pre-decrypted ciphertext or leaking the pre-decryption key), the behavior can be traced and audited through the blockchain ledger, and the proxy can be held accountable. This audit mechanism further constrains the proxy’s behavior and ensures the integrity of the ABE-based medical data sharing process, providing a traceable security guarantee.

In the medical data sharing scenario, the malicious proxy behavior analysis ensures that the Cloud Server, as a third-party entity, cannot obtain or tamper with sensitive medical data, thus maintaining the confidentiality and integrity of medical data during the pre-decryption process. This enables medical staff to safely use Cloud Servers to reduce their computational burden without concerns about medical data leakage or tampering. It serves as an important supplement to the ABE-based security mechanism.

Summary: The proposed scheme achieves IND-CPA security, with explicit collusion resistance and resistance to malicious proxy behavior. All security proofs and analyses are closely combined with the medical data sharing scenario and attribute-based encryption characteristics. This clearly proves that the scheme is secure and reliable in practical medical data sharing and ABE application scenarios, effectively protecting the confidentiality, integrity, and availability of sensitive medical data.

6. Simulation Experiments

This section evaluates the proposed scheme through both theoretical and experimental analysis. The experiments aim to verify that the proposed scheme addresses the key challenges in medical data sharing and attribute-based encryption, including insufficient fine-grained access control, heavy user-side decryption overhead, and inefficient access control. The evaluation adopts time consumption as the core metric to quantify the efficiency of each algorithm phase. Meanwhile, the deployment based on blockchain and IPFS ensures system scalability for distributed medical data sharing. Finally, we present the deployment of the blockchain and IPFS platforms as well as the results of the performance tests.

6.1. Theoretical Analysis

Table 1. Contrast of functional features, ✓: Supported, ×: Not supported.

Scheme	Scheme [23]	Scheme [24]	Scheme [25]	Ours
Distributed Storage	✓	✓	✓	✓
Data Confidentiality	✓	✓	✓	✓
Fine-grained Access Control	×	×	✓	✓
Outsourced Decryption	×	×	×	✓

compares the proposed scheme with other existing schemes in terms of functional features, including distributed storage, data confidentiality, fine-grained access control, and outsourced decryption. Jayabalan’s scheme [23] and Azbeg’s scheme [24] both achieve distributed storage of shared medical data based on blockchain and IPFS. In terms of access control, Jayabalan’s scheme employs symmetric and asymmetric encryption (RSA), combined with smart contracts, to manage data access. Azbeg’s scheme uses proxy re-encryption and dynamic smart contract authorization to implement access control. However, both schemes provide coarse-grained access control. Although the scheme proposed in [25] supports fine-grained access control, it does not support outsourced decryption. As shown in Table 1, the proposed scheme outperforms the others by supporting outsourced decryption, thereby reducing users’ computational overhead.

We now analyze the computational overhead of the proposed scheme. Let T denote the number of attributes, $n_1$ and $n_2$ denote the number of rows and columns of the access structure matrix, respectively, and I denote the number of attributes used during decryption.

• Key generation: The Trusted Authority (TA) performs $8T+11$ exponentiation operations, $6T+9$ multiplication operations, and $6T+6$ hash operations in the group ${\mathbb{G}}_1$. Additionally, 3 exponentiation operations are performed in the group ${\mathbb{G}}_2$.
• Pre-decryption key generation: The Data User (DU) performs $2T+6$ exponentiation operations and $2T+4$ multiplication operations in ${\mathbb{G}}_1$.
• Encryption: The Data Controller (DC) performs one symmetric encryption operation, $12n_1{n}_2+6n_1$ exponentiations, $6n_1$ multiplications, and $6n_1+6n_2$ hash operations in ${\mathbb{G}}_1$, and 3 exponentiations in ${\mathbb{G}}_2$.
• Pre-decryption: The Cloud Server (CS) performs $6I$ exponentiations and 3 multiplications in ${\mathbb{G}}_1$, along with 6 multiplications and 6 bilinear pairing operations in ${\mathbb{G}}_T$.
• Final decryption: The Data User (DU) performs 1 exponentiation in ${\mathbb{G}}_1$, 1 multiplication and 1 bilinear pairing in ${\mathbb{G}}_T$, followed by one symmetric decryption operation.

Based on this analysis, the computational overhead for the Data User (DU) remains within a reasonable range.

In summary, compared to other schemes, the proposed scheme offers better security and functionality. It preserves data confidentiality, achieves fine-grained access control, and demonstrates practical feasibility. The combination of blockchain and IPFS also provides good scalability for medical data sharing scenarios.

6.2. Experimental Analysis

This section presents the experimental simulation of the proposed scheme. All experiments are conducted under the same environment and repeated to obtain average results. The operating system used was Ubuntu 20.04.6 (Canonical Ltd., London, UK). The Python programming language (version 3.8.10, Python Software Foundation, Wilmington, DE, USA) was employed for algorithm implementation. Hyperledger Fabric v2.2.1 (Linux Foundation, San Francisco, CA, USA) was utilized as the blockchain platform. The InterPlanetary File System (IPFS) v0.10.0 (Protocol Labs, San Francisco, CA, USA) was adopted for distributed storage. The cryptographic algorithms were implemented using the Charm-Crypto library (Johns Hopkins University, Baltimore, MD, USA). The evaluation metrics include key generation time, encryption time, decryption time, pre-decryption key generation time, and outsourced decryption time, which are standard metrics to verify the efficiency of the proposed scheme in solving the challenges of medical data sharing. The components of the development environment used the implementation are listed in

Table 2. Development environment.

Component	Version
Operating System	Ubuntu 20.04.6
Programming Language	Python 3.8.10
Blockchain Platform	Hyperledger Fabric v2.2.1
IPFS	v0.10.0

.

The hardware components used in the development of the experimental platform included an Intel i5-12490F processor and 32 GB of RAM, which were installed on the Ubuntu 20.04.6 operating system. The algorithm was written in Python 3.8.10 using the Charm-Crypto cryptographic library. The simulation covered five phases: key generation, content encryption, pre-decryption key generation, outsourced decryption, and content decryption. Averaging the results of multiple experimental runs ensures reliability.

Figure 2 shows key comparisons of key generation times in the proposed framework with different numbers of attributes against those of the Chase, Chen, and Han frameworks. The experimental results indicate that the key generation time increases for all methods with an increase in the number of attributes, which is expected. Among these, the Han strategy consistently achieves the best performance across all attribute scales. The Chen strategy has the highest overhead, and this overhead increases particularly steeply with the number of attributes. The performance of the proposed framework is based on a general adaptation of the Chase approach; it is slightly lower in some cases but significantly better than that of the Chen strategy, so the proposed framework’s performance is generally in the upper-middle range. It is important to note that key generation is usually a one-time process during system initialization and thus has little impact on the overall system performance. Although the proposed framework cannot be considered the best in this metric, it offers greater advantages in decryption efficiency and security. Moreover, with the introduction of an outsourcing mechanism, the computational load on the user side can be reduced, ensuring that key generation overheads do not significantly affect realistic system behavior.

Figure 3 shows a comparison of the time consumption during the encryption phase among the proposed scheme and the schemes of Chen [26], Chase [13], and Han [27]. When the number of attributes exceeds 100, the proposed scheme outperforms the Chase scheme in terms of time efficiency. At 10 attributes, the time consumption of the proposed scheme is nearly identical to that of the Chase scheme. However, as the number of attributes increases, the proposed scheme demonstrates better performance than the Waters scheme. When the number of attributes grows from 10 to 100, the proposed scheme is nearly twice as fast as the Chen scheme. The Han scheme, on the other hand, consumes more time than the proposed scheme.

Figure 4 shows a comparison of the time consumption during the decryption phase among the proposed scheme and the schemes of Chen, Chase, and Han. As illustrated in the figure, the decryption time of the proposed scheme remains unaffected by the number of attributes, which is consistent with the theoretical time complexity analysis. The decryption time of both the Chen and Chase schemes is approximately five times that of the proposed scheme. In the case of the Han scheme, decryption time increases with the number of attributes, whereas the proposed scheme performs better in comparison.

Figure 5 illustrates the variation in time consumption for generating the pre-decryption key as the number of attributes increases in the proposed scheme. As shown in the figure, the time required for generating the pre-decryption key increases linearly with the number of attributes. Since the generation of the pre-decryption key can be performed offline and only needs to be done once, it has minimal impact on the overall execution of the scheme.

Figure 6 shows the variation in time consumption for outsourced decryption in the proposed scheme as the number of attributes increases, with the number of attributes as the independent variable and the results averaged over 100 runs. It can be observed that the time consumption for outsourced decryption remains nearly constant. This is because the number of pairing operations—which dominate the overall cost—stays fixed. Although the number of exponentiation operations increases linearly in the scheme, their impact is not significant, as exponentiation is much less time-consuming compared to pairing operations.

7. Conclusions

This paper proposes a secure and efficient medical data sharing scheme to address key challenges in medical data sharing. By integrating multiple technologies, the scheme effectively reduces the computational burden of users, achieves fine-grained access control, ensures data confidentiality, and verifies the feasibility of practical deployment. Compared with traditional schemes, it has obvious advantages in efficiency and security, making notable progress in solving medical data sharing problems and providing a more practical solution.

The scheme still has limitations. It fails to address dynamic changes of user attributes and lacks effective privacy protection for user attribute information, with certain overhead in communication and storage. Future research will focus on improving the adaptability of the scheme, introducing relevant privacy protection technologies, and optimizing the integration of related technologies to enhance the scheme’s applicability in practical scenarios.