A Lightweight Decentralized Medical Data Sharing Scheme with Dual Verification

Abstract

The rapid growth of smart healthcare improves medical efficiency through electronic data sharing but introduces security risks like privacy leaks and data tampering. However, existing ciphertext-policy attribute-based encryption faces challenges such as single points of failure, weak authentication, and inadequate integrity protection, hindering secure, efficient medical data sharing. Therefore, we propose LDDV, a lightweight decentralized medical data sharing scheme with dual verification. LDDV constructs a lightweight multi-authority collaborative key management architecture based on elliptic curve cryptography, which eliminates the risk of single point of failure and balances reliability and efficiency. Meanwhile, a lightweight dual verification mechanism based on elliptic curve digital signature provides identity authentication and data integrity verification. Security analysis and experimental results show that LDDV achieves 28–42% faster decryption speeds compared to existing schemes and resists specific threats such as chosen plaintext attacks.

1. Introduction

With the development of information technology in modern healthcare, cross-institutional sharing of medical data has become an inevitable trend. The cross-domain flow of such medical data as electronic medical records, medical images, and genomic information provides critical support for precision diagnosis and treatment, disease prediction, and public health decision-making. However, the high value and sensitivity of medical data make it a primary target of cyberattacks [1,2]. IBM Security’s 2023 Cost of a Data Breach Report [3] shows that the healthcare industry has ranked first in economic losses from data breaches for 13 consecutive years. For instance, the 2015 Anthem Inc. data breach in the U.S. led to nearly 80 million users’ personal information being exposed [4]. Such incidents not only inflict significant economic losses and reputational crises on medical institutions but also directly threaten patients’ privacy rights and life safety.

Fundamentally, the security threats to medical data stem from vulnerabilities in the traditional data sharing mechanism following the “institution → generated → platform-aggregated → cloud-stored → remotely accessed” workflow. First, data transmission lacks encryption, making it susceptible to eavesdropping and tampering attacks. Second, the weak identity authentication system fails to effectively prevent identity forgery and unauthorized access. Third, an attack on a single data center may trigger large-scale data breaches or system paralysis [5].

To enhance the security and privacy of data sharing, researchers are actively exploring novel privacy-preserving computing technologies [6,7]. As a core technology among these, attribute-based encryption (ABE) [8,9] tightly binds medical attributes (e.g., clinical roles, institutional credentials) with keys, enabling fine-grained access control during cross-institutional data sharing [10,11]. ABE schemes are categorized based on policy embedding locations: Key-Policy ABE (KP-ABE) [12] embeds policies into keys and appends attributes to ciphertexts, while Ciphertext-Policy ABE (CP-ABE) [13] achieves the inverse by embedding policies in ciphertexts and retaining attributes solely in keys. Real-world cloud data sharing predominantly uses CP-ABE because it allows the data owners to flexibly define complex access control policies, supports fine-grained permission management, and offers stronger scenario adaptability [14]. Users can access data simply by having their attributes satisfy the access policy without exposing personal identity information. Meanwhile, access right determination is dynamically performed based on real-time combinations of user attributes, no longer relying on predefined fixed roles.

However, traditional CP-ABE schemes depend on a single attribute authority (AA) for attribute and key management, suffering from single-point failure and performance bottleneck issues [15]. To address the limitations of single-authority CP-ABE, Lewko and Waters [16] proposed a decentralized multi-authority CP-ABE scheme. Through multiple independent attribute management agencies, it decentralizes the storage of user attributes and keys. Each authority has a lower load, and the authorities can collaborate with each other, significantly improving system security and reliability [17].

Nevertheless, existing multi-authority CP-ABE schemes still face the following key challenges in medical data sharing scenarios: (1) Computational performance bottlenecks. These schemes rely heavily on bilinear pairings for encryption, decryption, and policy verification, leading to performance issues when data sharing demand increases and attributes are updated frequently in resource-constrained settings (e.g., mobile medical devices) [16,18,19]. (2) Insufficient identity authentication. These schemes often assume user trustworthiness and lack robust identity verification mechanisms, exposing risks like identity forgery and session replay [16,20]. While some schemes optimize verification with zero-knowledge proofs [21], their high computational complexity and low efficiency make them impractical for large-scale medical data sharing. (3) Lack of data integrity assurance. Patient safety hinges on medical data integrity, where even minor tampering poses life-threatening risks. Regrettably, existing CP-ABE systems prioritize encryption and access control [22], overlooking integrity protection across storage, transmission, and decryption phases. This gap leaves them lacking effective tamper detection mechanisms.

To address the above challenges, we propose a lightweight decentralized medical data sharing scheme with dual verification (LDDV). LDDV enhances system performance while improving data security and operational efficiency. Specifically, it optimizes computational efficiency, strengthens identity authentication, and ensures robust data integrity protection. These features make LDDV particularly suitable for mobile healthcare environments requiring secure and efficient data sharing. LDDV exhibits broad application potential in real-world medical scenarios [23]. In hospital environments, LDDV facilitates secure cross-departmental sharing of electronic health records. For instance, medical images can be exchanged between emergency and radiology departments using multi-authority attribute management. In telemedicine, LDDV supports real-time encrypted transmission of patient physiological data (e.g., from wearable sensors), facilitating cross-institutional research collaboration and remote monitoring. Its lightweight nature (avoiding bilinear pairings) reduces communication overhead, making it suitable for resource-constrained IoT devices. LDDV provides a secure and efficient solution for dynamic medical data sharing, enhancing collaborative diagnosis efficiency and patient privacy protection. Additionally, LDDV demonstrates potential applications in scenarios such as industrial IoT device authentication and data traceability [24], as well as vehicular ad hoc networks [25].

Our main contributions are summarized as follows:

• We propose a lightweight multi-authority CP-ABE architecture. Using elliptic curve cryptography (ECC), we built a decentralized management framework of multiple attribute authorization authorities. This framework leverages multiple independent authorities to enable collaborative key management, effectively eliminating single points of failure and reducing key management complexity. Meanwhile, we realize fine-grained access control and support real-time attribute revocation via Linear Secret Sharing Scheme (LSSS).
• We design a lightweight dual verification mechanism that simultaneously fulfills identity authentication and data integrity verification. Specifically, through lightweight identity authentication based on the Elliptic Curve Digital Signature Algorithm (ECDSA), we ensure all data users must pass strict signature checks before accessing medical data, thereby effectively resisting identity forgery attacks. Meanwhile, we use dual encryption and data signing techniques to embed the data owner’s digital signature into ciphertext during generation, allowing users to verify both the authenticity of the data source and the integrity of the content.
• We validate the superiority and effectiveness of LDDV through rigorous security analysis and comprehensive experiments. It demonstrates that LDDV not only guarantees security but also delivers high computational efficiency, meeting the practical application requirements of mobile healthcare environments.

The rest of this paper is organized as follows: Section 2 reviews related work on ABE schemes; Section 3 presents relevant background knowledge; Section 4 describes the system model and threat model; Section 5 details the proposed scheme; Section 6 conducts security analysis; Section 7 presents experimental analysis; and Section 8 concludes the paper.

2. Related Work

This section introduces closely related work from three key aspects: single-authority attribute-based encryption (SA-ABE), multi-authority attribute-based encryption (MA-ABE), and attribute-based encryption for medical data sharing.

2.1. Single-Authority Attribute-Based Encryption

The prototype of ABE, termed Fuzzy Identity-Based Encryption (FIBE), was proposed by Sahai and Waters [26]. It extends identities to attribute sets, enabling decryptors to recover plaintext when partial attribute matches occur. However, FIBE only supports static identities and lacks the capability to enforce flexible, complex access policies. Subsequently, Goyal et al. [27] proposed embedding access policies into user keys while associating ciphertexts with attribute sets. In contrast, Bethencourt et al. [13] proposed to embed access policies into ciphertexts and link keys to attribute sets. Both schemes, however, have limited policy expressiveness due to their reliance on linear structures. To overcome this limitation, Bethencourt et al. [13] later introduced a CP-ABE scheme leveraging access tree structures for fine-grained access control

To further enhance security, several works focus on hiding sensitive attributes [28,29], tracing malicious users [30], and permission revocation [31,32]. For example, Hoang et al. [28] utilized proxy re-encryption to dynamically revoke user attributes and reduce the communication overhead of key distribution. Zhang et al. [33] employed an access structure based on LSSS to achieve partial hiding and support efficient key revocation. Wang et al. [34] achieved dual flexibility in encryption and key generation through a single-policy mode. They securely outsourced operations like key generation, encryption, and decryption to cloud servers, significantly reducing the main system’s overhead. Dang et al. [35] proposed a scheme that combines symmetric searchable encryption and multi-feature sensor technology to realize fine-grained access control and prevent unauthorized access.

Although SA-ABE has made some progress in the flexibility of access control policies and privacy protection, it generally suffers from performance bottlenecks and single-point failure issues. When the scale of attributes or the number of users surges, the efficiency of the single authorization center drops significantly. Furthermore, if the single authorization center is attacked or fails, the entire system will encounter critical security breaches and service interruptions.

2.2. Multi-Authority Attribute-Based Encryption

In contrast to SA-ABE, which depends on a single trusted attribute authority, MA-ABE [36,37,38,39,40] adopts a decentralized architecture (see

Table 1. Comparison between MA-ABE approaches.

Source	ECC	Revocation	Identity Authentication	Data Integrity Verification
[16]	✓	✓	✓	×
[18]	✓	×	×	×
[19]	✓	×	×	✓
[20]	✓	✓	×	×
[21]	✓	×	✓	×
[22]	✓	×	✓	×
[41]	✓	✓	✓	×
[42]	✓	×	×	×
LDDV	✓	✓	✓	✓

for a comparison of MA-ABE approaches). This design ensures that key distribution and policy verification efficiency remain stable even with growing attribute numbers, positioning it as a viable solution for large-scale distributed systems, cross-organizational attribute authorization, and healthcare applications.

For example, Lewko and Waters [16] realized a fully independent distributed architecture across authorities using LSSS. Nevertheless, this approach requires extensive computation of bilinear pairings while maintaining a strict assumption of authority trustworthiness. To address this, Rouselakis and Waters [18] proposed a verifiable MA-ABE scheme based on dual-system encryption, allowing for verification of encryption/decryption correctness to prevent authorities/users from submitting incorrect parameters. However, its verification efficiency remains low. Liu [21] used zero-knowledge proofs and attribute obfuscation to hide access policies and user attributes, but this further increased computational complexity. To improve efficiency, Yang et al. [22] proposed an elliptic curve-based encryption method that eliminates bilinear pairings at the cost of reduced policy expressiveness. Wei et al. [41] proposed a forward-secure attribute-based puncturable encryption scheme that supports decentralized key generation and fine-grained access control. Additionally, Zhang et al. [19] presented an MA-ABE scheme supporting policy hiding, dynamic updates, and dynamic ciphertext verification. Peñuelas [20] outsourced encryption/decryption to boost efficiency and used broadcast encryption for attribute revocation. Yet it does not explicitly protect user attribute privacy.

While MA-ABE effectively addresses the performance bottlenecks and security vulnerabilities inherent in centralized authorities, current implementations still face critical limitations regarding both security and efficiency. On the one hand, they lack dual verification for identity and data integrity, leaving them vulnerable to threats like identity forgery and data tampering. On the other hand, complex attribute authentication and high interaction costs make it difficult to balance security and computational efficiency. Therefore, how to achieve more efficient multi-attribute collaborative management while enhancing identity authentication and ensuring data integrity remains a key priority for future research.

2.3. Attribute-Based Encryption for Medical Data Sharing

Initial research on ABE for medical data sharing has focused on establishing foundational frameworks [43,44,45]. A notable example is Banerjee et al.’s [43] centralized cloud-based system, enabling rapid medical history retrieval in emergencies. However, traditional ABE mechanisms suffer from structural limitations regarding dynamic policy updates, hindering adaptation to real-time requirements in modern distributed systems. With the expansion of smart medical systems into multi-institutional scenarios, research has shifted toward developing dynamic access control mechanisms [46]. For instance, Guo et al. [47] proposed a distributed ABE architecture combining independent key updates, multi-permission collaboration, and blockchain to secure cloud-stored data.

As multi-institutional collaborative diagnosis becomes increasingly prevalent, ABE schemes undergo continuous optimization in multiple dimensions [48]. In terms of trusted mechanisms, Gao et al. [49] introduced a reputation evaluation system using reward–punishment mechanisms to constrain cloud service providers’ behavior. For cross-domain collaboration, Saravana et al. [50] developed a multi-authorization model employing user-centric access control algorithms for secure cross-cloud data circulation. Regarding dynamic permissions, Challagidad et al. [42] designed a multi-level authorization system integrated with fine-grained policies to support vertical permission division. Meanwhile, Hao et al. [51] overcame traditional ABE’s permission update limitations through proxy re-encryption and key binding. Notably, Liu et al. [52] implemented a hybrid group signature-blockchain architecture storing medical record signatures on-chain while outsourcing raw data to clouds with proxy re-encryption ensuring secure cross-institutional sharing.

Despite ABE’s advantages in access control flexibility and security, existing solutions face critical challenges: sensitive attribute leakage and excessive terminal computational loads. Most frameworks transmit access policies in plaintext, posing risks of sensitive data exposure (e.g., patient diagnoses and departmental information). Additionally, they inadequately address decryption burdens on mobile devices with constrained processing capabilities. In contrast, our proposed LDDV achieves dual guarantees of identity authentication and data integrity while employing a multi-authority architecture to eliminate single points of failure. This approach balances system reliability and efficiency, offering a novel solution for medical data sharing.

3. Preliminaries

This section presents relevant background knowledge of our work.

3.1. Monotonic Access Structure

Let the attribute set $A=\{A_1,A_2,\dots ,A_k\}$, and let the nonempty set M denote the access control structure. The set M satisfies $M\subseteq 2^A\setminus \{⌀\}$. For all $B,C\subseteq A$, if $B\in M$ and $B\subseteq C$, then $C\in M$. In this case, the nonempty subset M forms a monotonic access control structure. If the set $D\in M$, then D is an authorized set; if the set $D\subseteq A$ and $D\notin M$, then D is an nonauthorized set.

An access structure describes how access permissions are defined. In CP-ABE, the access structure uses attribute combination rules to strictly restrict decryption to users whose attributes satisfy the predefined rules.

3.2. Elliptic Curve Cryptography

ECC is an asymmetric encryption system. Its security stems from the computational complexity of the discrete logarithm problem over elliptic curve finite fields. It constructs core security functions, such as key agreement protocols and digital signature authentication mechanisms, using the algebraic structural properties of its point group operations. Its key features are as follows:

(1)

High security and short key length: ECC offers exponential security strength under classical computation models. It achieves equivalent security to RSA with a key length just 1/6 that of RSA, significantly reducing storage and transmission overhead.

(2)

Efficient computation: Core scalar multiplication operations in ECC can be computed rapidly via optimized algorithms, outperforming RSA in speed while yielding shorter public keys and ciphertexts.

(3)

Resource friendliness: ECC excels on low-power devices. Its lightweight operations minimize computational resource usage and energy consumption.

3.3. Elliptic Curve Digital Signature Algorithm

ECDSA is a digital signature algorithm based on ECC. In ECDSA, public and private keys are generated from an elliptic curve and a fixed base point:

• Private key generation: A random integer d is selected (where $1<d<n$, and n is the order of the large prime associated with the elliptic curve’s base point G).
• Public key generation: The public key P is computed as $P=d·G$, where “·” denotes scalar multiplication on the elliptic curve.

In ECDSA, system parameters, including the definition of elliptic curve, base point G, and order n, are publicly visible. The private key d, however, remains confidential and is held exclusively by the owner for signature generation. Verifiers can validate signature authenticity using the public key P and base point G via elliptic curve point operations, but generating a valid signature must depend on the scalar multiplication corresponding to the private key.

4. System Model and Security Model

This section briefly describes the system model and security model.

4.1. System Architecture

The architecture of the proposed LDDV is shown in Figure 1, which mainly includes four core entities.

(1)

Multi-Attribute Authority (MAA): Each attribute authority (AA) independently manages a set of attributes, responsible for generating user attribute keys and processing attribute revocation. It uses elliptic curve key pairs to generate master keys and signing keys, ensuring the security of attribute keys and data integrity verification.

(2)

Data Owner (DO): The DO encrypts medical data, defines access policies, and generates ciphertext using the CP-ABE mechanism combined with LSSS. It ensures data integrity via ECDSA and collaborates with AAs to obtain system attributes.

(3)

Data User (DU): The DU holds attribute keys obtained from AAs, decrypts data after satisfying the access policy, and verifies data integrity.

(4)

Cloud Service Provider (CSP): The CSP stores encrypted data, verifies data user identities, and issues decryption tokens. It cannot access the plaintext of encrypted data but can release one-time decryption tokens upon successful authentication.

4.2. Formal Definition of LDDV

LDDV comprises several key steps: system initialization (i.e., $\mathit{Setup}$()), attribute key generation, encryption, decryption token generation, decryption, data integrity verification, and attribute revocation. Each of these steps will be described in detail in Section 5.

(1)

$\mathit{Setup}\mathbf{\left(}{\mathbf{1}}^{\mathit{\lambda }}\mathit{\right)}\to \left(\mathit{GP},{\left\{{\mathit{MSK}}_{\mathit{k}},{\mathit{MPK}}_{\mathit{k}}\right\}}_{\mathit{k}=\mathbf{1}}^{\mathit{n}}\right)$: Input the security parameter $\lambda$, output the global parameters $GP$, which include the elliptic curve $E\left({\mathbb{F}}_p\right)$, base point G, hash functions $H_1,H_2$, signature key $S{K}_{sign}$, etc. Generate the master key pair $\{MS{K}_k,MP{K}_k\}$ for each authoritative attribute $A{A}_k$. In addition, the attribute revocation list $CRL$ is created.

(2)

$\mathit{KeyGen}({\mathit{user}}_{\mathit{uid}},{\mathit{S}}_{\mathit{i}},{\mathit{MSK}}_{\mathit{i}},\mathit{exp})\to {\mathit{SK}}_{\mathit{uid},\mathit{i}}$: The attribute authority $A{A}_i$ uses the master key $MS{K}_i$ to generate the key $S{K}_{uid,i}$ for the user_uid with attribute set $S_i$, valid until $exp$.

(3)

$\mathit{Encrypt}(\mathit{GP},\mathit{m},(\mathit{M},\mathit{\rho }),{\mathit{SK}}_{\mathit{sign}})\to \mathit{CT}$: Executed by the DO, this algorithm uses the global parameters $GP$, plaintext m, access structure $(M,\rho )$, and signature key $S{K}_{sign}$ to generate the ciphertext $CT$, which contains ciphertext data, policy components, digital signatures, and other data.

(4)

$\mathit{TokenGen}({\mathit{user}}_{\mathit{uid}},\mathit{S},{\mathit{\sigma }}_{\mathit{req}})\to \mathit{token}/\perp$: Executed by the DO, this algorithm takes the user identifier $use{r}_{uid}$, attribute set S, and request signature ${\sigma }_{req}$ as input. The cloud server verifies the user’s identity and attribute validity; if passed, it generates a decryption token $token$, otherwise outputs ⊥.

(5)

$\mathit{Decrypt}({\mathit{SK}}_{{\mathit{user}}_{\mathit{uid}},\mathit{i}},\mathit{CT},\mathit{token})\to \mathit{m}/\perp$: Run by the DU, this algorithm allows the user to decrypt using the decryption key $S{K}_{use{r}_{uid},i}$, ciphertext CT, and decryption token $token$. If the attributes of the DU satisfy the access policy and the token is valid, decryption succeeds to obtain the plaintext m; otherwise, decryption fails and outputs the error ⊥.

(6)

$\mathit{VerifyIntegrity}(\mathit{m},\mathit{\sigma },{\mathit{PK}}_{\mathit{sign}})\to \mathit{true}/\mathit{false}$: Executed by the DU, this algorithm uses the signature $\sigma$ and signature public key $P{K}_{sign}$ to verify the integrity of the decrypted data m and outputs the verification result.

(7)

$\mathit{AttributeRevoke}({\mathit{user}}_{\mathit{uid}},\mathit{attr})\to {\mathit{CRL}}_{\mathit{i}}^{\prime }$: The attribute authority ${\mathrm{AA}}_i$ revokes the attribute $attr$ of $use{r}_{uid}$ and updates the revocation list $CR{L}_i^{\prime }$.

4.3. Security Model

This section defines the security framework of LDDV, including entity security assumptions, attacker model, and the core security properties the scheme must satisfy.

4.3.1. Entity Security Assumptions

The security assumptions for each entity are as follows:

(1)

AAs: Trusted but independent.

(2)

DO: Fully trusted.

(3)

DU: Partially trusted.

(4)

CSP: Semi-trusted (honest but curious).

4.3.2. Attacker Model

We define the following attacker types and their capabilities:

(1)

External Attacker: Eavesdrops on communication channels, intercepts ciphertexts, forges messages, and injects them into the system. Attempts to decrypt data or disrupt system functions.

(2)

Malicious Insider User: Possesses partial legitimate attribute keys and attempts to access unauthorized data and obtain sensitive information beyond their permissions.

(3)

Malicious CSP: Accesses stored ciphertexts and attempts to derive plaintext or tamper with data.

(4)

Compromised AA: If an AA is compromised, the attacker obtains its master key and forges attribute keys.

4.3.3. Security Properties

The scheme satisfies the following security guarantees:

(1)

Chosen Plaintext Attack (CPA) Security: This scheme is secure under CPA, i.e., a probabilistic polynomial-time (PPT) attacker cannot distinguish between the ciphertexts of two equal-length plaintexts with non-negligible advantage.

(2)

Identity Non-Forgeability: This scheme prevents identity forgery, as the probability of an attacker forging a legitimate user’s identity is negligible.

(3)

Data Integrity: The scheme guarantees data integrity, i.e., users can detect data tampering by an attacker.

(4)

Resistance to Cloud Server Attacks: The CSP cannot decrypt or tamper with data without being detected.

(5)

Attribute Revocation Security: After attribute revocation, users cannot decrypt the corresponding data.

5. Scheme Implementation

This section describes in detail the key steps of LDDV. Commonly used symbols are presented in

Table 2. Definitions and descriptions of symbols.

Symbol	Explanation
$\lambda$	security parameter
$E\left({\mathbb{F}}_p\right)$	elliptic curve, whose order is a prime q
$A{A}_i$	the $i_{th}$ attribute authority
$\mathbb{U}$	user set
$A={\bigcup }_{k=1}^n{\mathrm{A}}_k$	global attribute set, where $A_k$ is the attribute set managed by $A{A}_k$
G	base point of $E\left(F_p\right)$
$\rho$	a matching function that maps the rows of the access matrix to attributes
${\mathbb{Z}}_q$	ring of integers modulo q
$H_1$	a hash function that mapping attribute strings to elements in ${\mathbb{Z}}_q$
$H_2$	a hash function that mapping the user ID to an element in ${\mathbb{Z}}_q$

.

5.1. System Initialization

The system performs initialization. Input security parameters $\lambda$, select a secure elliptic curve $E\left({\mathbb{F}}_p\right)$, choose the base point G on $E\left({\mathbb{F}}_p\right)$ as the generator, select hash functions $H_1:{\{0,1\}}^{*}\to {\mathbb{Z}}_q$ and $H_2:{\{0,1\}}^{*}\to {\mathbb{Z}}_q$, and select a matching function $\rho$ to map the access matrix to attributes. This step provides the basic structure for the system, enabling subsequent encryption, decryption, and access control to operate normally.

Each attribute authority $A{A}_i$ executes the following steps:

(1)

Select random numbers $\{{\alpha }_i,{\beta }_i,{\gamma }_i,{\delta }_i\}$.

(2)

Compute the key: $P{K}_i=\{{\alpha }_i·G,{\beta }_i·G,{\gamma }_i·G,{\delta }_i·G\},S{K}_i=\{{\alpha }_i,{\beta }_i,{\gamma }_i,{\delta }_i\}$.

(3)

Generate the signing private key $si{g}_{s{k}_i}$ and verification public key $si{g}_{p{k}_i}$.

(4)

Initialize attribute management: Create an empty set $managedAttrs=⌀$; register attributes via $RegisterAttribute\left(attr\right)$; maintain the complete attribute name format as “$A{A}_i:attr$”.

(5)

Initialize user public key management and revocation status: Create an empty user public key list $userPubKeys=⌀$ and an empty revocation list $CRL=⌀$.

5.2. Attribute Key Generation

Each AA generates an attribute key for the user $use{r}_{uid}$. First, it checks if the user-submitted attributes fall within its manageable scope and screens for revoked attributes among them. For unrevoked attributes, it concatenates them with the user identifier, validity period, and other metadata to create a seed. Next, it derives keying material via hashing and HKDF, then uses this material to generate an elliptic curve private key—and ultimately the attribute key. It records details such as the attribute key’s validity period and issuance time. Finally, it packages the user identifier, attribute key, and related metadata into a bundle and delivers it to the user.

The following are steps to generate an attribute key for the user $use{r}_{uid}$:

(1)

Parameter Verification: Verify that the attribute set $S\subseteq managedAttrs$; set the key validity period $valid\text{\_}until$.

(2)

Revocation Check: For each $attr\in S$, check if $(user\text{\_}id,attr)\in CRL$. If true, then add $attr$ to the $revoked\text{\_}attrs$ set.

(3)

Generate Attribute Keys: For each unrevoked attribute $attr\in S$, construct the full attribute name $fullAttr=“A{A}_i:attr”$ and the attribute seed $attrSeed=fullAttr\Vert user\text{\_}id\Vert valid\text{\_}until$; then, compute $attr\text{\_}hash=H_1\left(attrSeed\right)$ and derive the key material $dKey$ using HKDF; then, convert the key material $dKey$ into an elliptic curve private key; finally, store the key: $userKeys\left[fullAttr\right]=\left\{key:attrPrivKey,valid\text{\_}until:valid\text{\_}until\right\};$

(4)

Generate Key Package: Return a structure containing the user ID, attribute keys, validity period, issuance time, and revocation attributes.

5.3. Encryption

The following are detailed steps for the DO to encrypt and sign data: First, parse the access policy and construct the corresponding matrix; randomly generate a symmetric key and an initialization vector, then encrypt the data using the AES-GCM mode; compute the attribute hash for each attribute and store the partial key components; finally, encapsulate the symmetric key and its metadata information into key information (key_info), and generate a digital signature with the data owner’s private key. This forms the four-part result: complete ciphertext, policy, signature, and other information. The encryption algorithm is described in Algorithm 1.

Algorithm 1: Encryption

Input: Global parameters $GP$, plaintext m, access structure $(M,\rho )$, signing key $S{K}_{\mathrm{sign}}$.  Output: Ciphertext $CT$. 1  Parse the access policy: $policy\text{\_}tree=PolicyParser.parse\left(policy\text{\_}str\right);$ 2  Construct the LSSS matrix: $matrix, \rho =LSSSMatrixBuilder.build\text{\_}matrix\left(policy\text{\_}tree\right);$ 3  Generate a random symmetric key: $sym\text{\_}key\in {\{0,1\}}^{256};$ 4  Generate a random initialization vector: $iv\in {\{0,1\}}^{128};$ 5  Symmetrically encrypt the data: 6  $cipher=AES\text{\_}GCM(sym\text{\_}key,iv);$ 7  $ciphertext=cipher.encrypt\left(data\right);$ 8  $tag=cipher.finalize\left(\right);$ 9  Encrypt the symmetric key with attributes: 10  $v=(s,r_2,\dots ,r_n);{\lambda }_i=M_i·v,i=1,\dots ,l;\mathrm{attr}=\rho \left(i\right);$ 11  $attr\text{\_}hash=H_1\left(attr\right);$ 12  $\mathrm{shares}\left[attr\right]=\{\mathrm{share}:{\lambda }_i,\mathrm{attr}\text{\_}\mathrm{hash}:attr\text{\_}hash\};$ 13  Assemble key information: 14  $key\text{\_}info=\{key:sym\text{\_}key,iv:iv,tag:tag,valid\text{\_}until:expiry\text{\_}time\};$ 15  $key\text{\_}info\text{\_}enc=HEX\left(JSON\right(key\text{\_}info\left)\right);$ 16  Data signing: 17  $signature=AA.sign\text{\_}data\left(data\right)\vee signature=DO.sign\left(data\right);$ 18  Return ciphertext: $CT$.

5.4. Decryption Token Generation

When initiating a decryption request, DU first submits the user identifier, the set of attributes it owns, and a request signature generated using its private key to the CSP. Upon receiving the DU’s request, the CSP first verifies the user’s signature via existing standard ECDSA (implemented via the cryptography Python library) to ensure the legitimacy of the user’s identity. After successful verification, the CSP checks each attribute in the DU’s submitted attribute set against its currently maintained revocation list $CRL$ for matches. If the DU’s attribute set contains any revoked attributes, the CSP immediately returns an error message to the DU, specifying the revoked attribute(s). If all attributes are valid, the CSP generates a temporary one-time decryption token containing the user identifier, the valid attribute set, and a timestamp, then signs the token with its own private key to ensure the token is tamper-proof and resistant to replay attacks. Finally, the CSP securely returns the signed decryption token to the DU for use in subsequent decryption processes. The CSP executes Algorithm 2 to generate the decryption token.

Algorithm 2: Decryption Token Generation

5.5. Decryption

Before performing decryption, the DU validates the ciphertext integrity by parsing the access policy embedded in the ciphertext structure. Upon confirmation, the DU generates a decryption request signature using its private key and requests a one-time decryption token from the CSP. After obtaining the token, the DU first strictly verifies the token’s signature and checks if the token is still within its validity period. Once the token is confirmed valid and trustworthy, the DU extracts parameters related to symmetric key recovery from the ciphertext structure, including the initialization vector $iv$, authentication tag $tag$, etc. Subsequently, the DU combines the locally held attribute key components and uses the key reconstruction technique under LSSS to recover the symmetric key. It then decrypts the ciphertext data using the AES-GCM algorithm, ultimately obtaining the complete plaintext data. The DU executes Algorithm 3 to decrypt the data.

Algorithm 3: Decryption

5.6. Data Integrity Verification

The DU first checks whether there is a signature field in the ciphertext. Then (see Algorithm 4), it obtains the corresponding verifying key based on the signature and uses the verifying key, plaintext, and signature value to perform verification. If the verification fails, it returns false, indicating that the data has been tampered with; if the verification succeeds, it returns true, indicating that data integrity is guaranteed.

Algorithm 4: Data Integrity Verification

Input: Ciphertext $CT$.  Output: Boolean $is\text{\_}valid$. 1  if  $CT.signature.aa$ is null  then 2  $|\hspace{1em}is\text{\_}valid=False;$ 3  end 4  $verify\text{\_}key=authorities[CT.signature.aa].signing\text{\_}public\text{\_}key;$ 5  $is\text{\_}valid=ECDSA.verify(verify\text{\_}key,CT.plaintext,CT.signature.value);$ 6  return  $is\text{\_}valid.$

5.7. Attribute Revocation

An attribute authority (AA) performs the following steps to revoke user attributes:

(1)

Verify parameters: Ensure that $user\text{\_}id$ and $attribute$ are not empty, and verify that $attribute\in managedAttrs$.

(2)

Update the revocation status:

If $attribute$ is not in $CRL$, set $CRL\left[attribute\right]=\left[\right]$;

if $user\text{\_}id$ is not in $CRL\left[attribute\right]$, append it.

(3)

Update user revocation records:

If $user\text{\_}id$ is not in $revoked\text{\_}attributes$, set $revoked\text{\_}attributes\left[user\text{\_}id\right]=\left[\right]$;

if $attribute$ is not in $revoked\text{\_}attributes\left[user\text{\_}id\right]$, append it.

(4)

Return the updated $CRL$ to the cloud server.

6. Security Analysis

In this section, we present a comprehensive security analysis of LDDV, systematically evaluating its resilience against multiple threat models: security under chosen plaintext attacks, security against user identity forgery attacks, security against cloud server attacks, and security under the attribute revocation mechanism.

6.1. Security Under Chosen Plaintext Attack

Theorem 1.

If the Elliptic Curve Discrete Logarithm Problem (ECDLP) is hard on the elliptic curve $E\left({\mathbb{F}}_p\right)$, then the LDDV scheme is secure under chosen plaintext attack (CPA).

Proof. 

We provide a reduction proof based on ECDLP. Suppose there exists a probabilistic polynomial-time (PPT) adversary $\mathcal{A}$ that can break the IND-CPA security of LDDV with a non-negligible advantage $\epsilon$. We construct an algorithm $\mathcal{B}$ to solve the ECDLP.

Step 1: Challenge Setup. Algorithm $\mathcal{B}$ receives the ECDLP challenge $(G,Z=z·G)$, where the goal is to compute z. $\mathcal{B}$ sets up system parameters as follows: select an elliptic curve $E\left({\mathbb{F}}_p\right)$ of order q, set the base point as G, and select hash functions $H_1,H_2:{\{0,1\}}^{*}\to {\mathbb{Z}}_q$. For each attribute authority $A{A}_i$, choose random numbers ${\beta }_i,{\gamma }_i,{\delta }_i\in {\mathbb{Z}}_q$, set ${\alpha }_i·G=Z$ (embed the ECDLP challenge into the public key), and compute

$${\beta }_i·G={\beta }_i^{\prime }·G,{\gamma }_i·G={\gamma }_i^{\prime }·G,{\delta }_i·G={\delta }_i^{\prime }·G$$

(1)

Then, publish the public key $P{K}_i=\{Z,{\beta }_{i}G,{\gamma }_{i}G,{\delta }_{i}G\}$.

Step 2: Attribute Key Query Simulation. The adversary $\mathcal{A}$ can request attribute keys. For a query (user_id, S), where S is a set of attributes, $\mathcal{B}$ executes: for each attribute $attr\in S$, generate random numbers $r,r_i\in {\mathbb{Z}}_q$, and compute

$$\begin{array}{cc}\hfill attr\text{\_}seed& =“A{A}_i:attr”\Vert ID\Vert valid\text{\_}until\hfill \\ \hfill attr\text{\_}hash& =H_1\left(attr\text{\_}seed\right)\hfill \end{array}$$

(2)

Construct key components:

$$\begin{array}{cc}\hfill K& =r·H_2\left(user\text{\_}id\right)·G\hfill \\ \hfill L& =r·G\hfill \\ \hfill K_j& =r·({\beta }_k·G)+r_i·\left({\gamma }_k·G+H_1\left(attr\right)·{\delta }_k·G\right)\hfill \\ \hfill L_j& =r_i·G\hfill \end{array}$$

(3)

These simulated key components are statistically indistinguishable from the real key components.

Step 3: Challenge Phase. Adversary $\mathcal{A}$ submits two equal-length messages $m_0,m_1$ and an access policy $\Psi$. Algorithm $\mathcal{B}$ randomly selects a bit $b\in \{0,1\}$ and generates a random symmetric key $\mathrm{sym}\text{\_}\mathrm{key}\in {\{0,1\}}^{256}$. It encrypts $m_b$ using AES-GCM to obtain the ciphertext CT. Next, $\mathcal{B}$ constructs a LSSS matrix $(M,\rho )$ to implement $\Psi$. Choose a random $s\in {\mathbb{Z}}_q$ and random vector $\mathbf{v}=(s,v_2,\dots ,v_n)$, then compute shares ${\lambda }_i=M_i·\mathbf{v}$ for each row $M_i$ of M.

For each i, compute

$$\begin{array}{cc}\hfill C_i& ={\lambda }_i·G+r_i·({\beta }_{\rho \left(i\right)}·G),\hfill \\ \hfill C_i^{\prime }& =r_i·G,\hfill \\ \hfill D_i& =r_i·\left({\gamma }_{\rho \left(i\right)}·G+H_1\left(\mathrm{att}\left(i\right)\right)·{\delta }_{\rho \left(i\right)}·G\right)\hfill \end{array}$$

(4)

Bind $sym\text{\_}key$ with $s·Z$ via

$$key\text{\_}info=sym\text{\_}key\oplus KDF(s·Z)$$

(5)

Return the challenge ciphertext:

$$C{T}^{*}=\{CT,key\text{\_}info,{\{C_i,C_i^{\prime },D_i\}}_i,\Psi \}.$$

(6)

Step 4: Guessing Analysis. Adversary $\mathcal{A}$ eventually outputs a guess $b^{\prime }$. If $b^{\prime }=b$, $\mathcal{B}$ infers $\mathcal{A}$ successfully extracted $sym\text{\_}key$. This means $\mathcal{A}$ can compute $s·Z=s·(z·G)=z·(s·G)$, enabling $\mathcal{B}$ to derive z from $\mathcal{A}$’s output and solve ECDLP.

Step 5: Advantage Analysis. If $\mathcal{A}$ has advantage $\epsilon$ against LDDV’s IND-CPA security, $\mathcal{B}$ has advantage at least $\epsilon /q$ in solving ECDLP. Since ECDLP is hard, $\epsilon$ must be negligible. Thus, no PPT attacker can break LDDV’s IND-CPA security with non-negligible advantage. □

6.2. Security Under User Identity Forgery Attack

Theorem 2.

If the ECDSA signature scheme is existentially unforgeable under chosen-message attacks, then the LDDV scheme effectively resists user identity forgery attacks.

Proof. 

We construct a reduction to prove that forging user identities is equivalent to forging ECDSA signatures.

Step 1: Attack Model Setup. Suppose an adversary $\mathcal{A}$ attempts to forge the identity of user u and create a decryption request that passes the cloud server verification.

Step 2: Reduction Construction. Construct algorithm $\mathsf{B}$, which receives the ECDSA challenge and obtains the verification key $vk$. $\mathsf{B}$ sets the verification key of the target user u as $\mathsf{vk}$. For the signing query $q=(u,m)$ from $\mathsf{A}$: if $u\ne u^{*}$, $\mathsf{B}$ signs using its own generated key pair; if $u=u^{*}$, $\mathsf{B}$ forwards m to the ECDSA challenger to obtain the signature.

Step 3: Forgery Attack Analysis. Adversary $\mathcal{A}$ eventually outputs a forged request $(u^{*},attrs,timestamp,si{g}^{*})$. If verification passes, $sig$ is a valid ECDSA signature on the message $m=“u^{*}\left|\right|timestamp\left|\right|attrs”$. If $\mathcal{B}$ never queried the ECDSA challenger for $m^{*}$, $sig$ is a valid signature on m.

Step 4: Security Proof. If $\mathcal{A}$ can successfully forge identities with advantage $\epsilon$, $\mathcal{B}$ can forge ECDSA signatures with the same advantage. Since ECDSA is existentially unforgeable under chosen-message attacks, $\epsilon$ must be negligible. Thus, the success probability of user identity forgery attacks in LDDV is negligible.

Step 5: Identity Verification Mechanism Analysis. LDDV implements identity verification as follows:

(1)

Each decryption request includes

$$\begin{array}{cc}\hfill request\text{\_}message& =user\text{\_}id\Vert timestamp\Vert sorted\text{\_}attributes\hfill \\ \hfill signature& =ECDSA(SK\text{\_}user,request\text{\_}message)\hfill \end{array}$$

(7)

(2)

Cloud server verification: Check $verify(P{K}_{u}ser,request\text{\_}message,signature)=true$ and that the timestamp is within a valid time window.

(3)

The timestamp prevents replay attacks, and the signature ensures identity authenticity.

□

6.3. Security Against Cloud Server Attacks

Theorem 3.

Under the condition that the data owner’s signature key is not leaked, the LDDV scheme can effectively resist various attacks from the cloud server.

Proof. 

We analyze the security of LDDV against cloud server attacks by examining primary attack types.

Type 1: Data Theft Attack. Suppose the cloud server attempts to access unauthorized encrypted data.

-

Cryptographic Barrier. Data is encrypted with AES-GCM, and the symmetric key $sym\text{\_}key$ is protected by ABE (requiring an authorized attribute set for decryption). The cloud server’s advantage in obtaining $sym\text{\_}key$ is:

$$Ad{v}_{CS}^{decrypt}\left(\lambda \right)\le Ad{v}_{\mathcal{A}}^{ND-CPA}\left(\lambda \right)+Ad{v}_{\mathcal{A}}^{AES}\left(\lambda \right)$$

(8)

By Theorem 1 and AES’s security, this advantage is negligible.

-

Token Mechanism Security. Decryption requires a token verified by the cloud server, generated using the user’s valid signature. The token forgery probability is

$$Pr\left[\mathrm{TokenForge}\right]\le {\mathrm{Adv}}_{\mathcal{A}}^{\mathrm{ECDSA}\text{-}\mathrm{forge}}\left(\lambda \right)$$

(9)

By ECDSA’s existential unforgeability, this probability is negligible.

Type 2: Data Tampering Attack. Suppose the cloud server modifies the stored encrypted data.

-

Digital Signature Protection. Each data block has the signature of the data owner, and the signature form is

$$sig=ECDSA(S{K}_{owner},data)$$

(10)

-

Formal Security Proof. Define the success probability of tampering: $Pr\left[\mathrm{Tamper}\right]$. Successful tampering requires generating a valid signature, which is reduced to ECDSA forgery:

$$Pr\left[\mathrm{Tamper}\right]\le Ad{v}_A^{ECDSA-forge}\left(\lambda \right)$$

(11)

Due to the unforgeability of ECDSA, this probability is negligible.

-

End-to-End Verification. The user verifies the signature after decryption. Even if the cloud server modifies the ciphertext, the different decryption result will lead to signature verification failure. Mathematically, if $C{T}^{\prime }\ne CT$, then we have

$$verify(P{K}_{owner},decrypt\left(C{T}^{\prime }\right),sig)=false$$

(12)

Type 3: Denial-of-Service Attack. Assume the cloud server refuses to process requests.

-

The advantage of MAA. The system is distributed across multiple AAs and proxy servers, so the impact of a single point of failure is limited.

-

Formal resilience analysis. Let the system consist of k AAs and m proxy servers. The system availability probability satisfies

$$Pr\left[\mathrm{Available}\right]\ge 1-{(1-p)}^m$$

(13)

where p is the availability probability of a single server. When m increases, the system availability improves significantly.

Type 4: Replay Attack. Assume the cloud server replays old requests.

-

Timestamp Protection: Each request contains a timestamp, and the server checks: $|current\text{\_}time-timestamp|\le threshold$.

-

One-Time Token Usage: Tokens are stored in the cache after generation and deleted immediately after use: $deletecached\text{\_}tokens\left[token\right]$. Replaying a token for a query will return “token not found”.

-

Formal Security Proof: Define the replay success probability $Pr\left[\mathrm{Replay}\right]$, and the replay window is $threshold$. Formally

$$Pr\left[\mathrm{Replay}\right]\le Pr[\mathrm{token}\mathrm{not}\mathrm{expired}\wedge \mathrm{token}\mathrm{not}\mathrm{used}]$$

(14)

$$Pr\left[\mathrm{Replay}\right]\le threshold/T$$

(15)

where T is the average lifetime of a token. By setting a small $threshold$, this probability can be controlled within a negligible range. □

6.4. Security Under Attribute Revocation Mechanism

(1) Revocation Model Definition

-

Revocation Operation. The ${\mathrm{AA}}_k$ adds a user attribute pair $(u,attr)$ to the revocation list $CRL$. This is operationalized as $CRL\left[attr\right].append\left(u\right)$ $revoked\text{\_}attributes\left[u\right].append\left(attr\right)$

-

Formal Definition. Define $RevAttrs\left(u\right)$ as the set of attributes revoked for user u and $Attrs\left(u\right)$ as the set of attributes held by user u. Then, the set of valid attributes for user u can be defined as $ValidAttrs\left(u\right)=Attrs\left(u\right)\setminus RevAttrs\left(u\right)$.

(2) Revocation Immediacy Analysis

LDDV’s revocation mechanism is immediate and there’s no need to update already issued ciphertexts.

-

Proxy Verification Model. Every decryption request is verified by the cloud server, which checks the attribute revocation status. Define $TokenGen(u,attrs)$ as a function that generates a token for user u using attributes $attrs$. If $attrs\cap RevAttrs\left(u\right)\ne Ø$, then $TokenGen(u,attrs)=“\mathrm{revoked}”$.

-

Formal Security Proof. Define the success probability of accessing resources after revocation as $Pr\left[\mathrm{Access}\mid \mathrm{Revoked}\right]$. After user u’s attribute $attr$ is revoked, a token is required for decryption. The token request is validated via

$$CheckRevocation(u,attrs)=\left(attrs\cap RevAttrs\left(u\right)=\varnothing \right)$$

(16)

If $CheckRevocation\left(\right)$ returns false, the token is rejected. Thus

$$Pr\left[\mathrm{Access}\mid \mathrm{Revoked}\right]\le Pr\left[\mathrm{Forging}\mathrm{Token}\right]+Pr\left[\mathrm{Bypassing}\mathrm{Proxy}\right]$$

(17)

Both probabilities on the right-hand side are negligible (proven earlier).

-

Advantage of No Ciphertext Updating. In traditional schemes, revocation requires updating all related ciphertexts, resulting in a delay of $O\left(N\right)$ (where N is the number of ciphertexts). But in our scheme, revocation takes effect immediately on the cloud server, with a delay of $O\left(1\right)$, eliminating exploitation opportunities during revocation delay windows.

(3) Distributed Revocation Consistency

Under a MAA environment, the revocation status must remain consistent across $AA$s.

-

Consistency Guarantee Mechanism. The cloud server centrally maintains the global $CRL$ state. Each $AA$ updates the cloud server’s revocation information via secure channels. Formally, global

$$RevAttrs\left(u\right)=\bigcup _{k}RevAttr{s}_k\left(u\right)$$

(18)

where $RevAttr{s}_k\left(u\right)$ denotes the set of attributes revoked by $A{A}_k$ for user u.

-

Attack Model Analysis. Attackers may attempt to exploit the revocation state synchronization delay ($\Delta t$). The probability that an attacker successfully exploits the window period in the worst case is

$$Pr\left[\mathrm{ExploitWindow}\right]\le \lambda ·\Delta t/T$$

(19)

where $\lambda$ is the request frequency and T is system operation time. With efficient synchronization mechanisms, $\Delta t$ can be minimized to render this probability negligible.

-

Formal Security Proof. Let $RevLog$ denote the revocation operation log. The cloud server’s revocation actions are based on $RevLog$. To bypass revocation, attackers must forge or tamper with $RevLog$. We formalize this as a security reduction:

$$Ad{v}_A^{revoke\text{\_}bypass}\left(\lambda \right)\le Ad{v}_A^{auth\text{\_}channel}\left(\lambda \right)$$

(20)

By the secure channel assumption, this advantage is negligible.

7. Experimental Analysis

In this section, we first analyze the security and functionality of LDDV and the comparison schemes, and then conduct a comparison of computational overhead through experiments.

7.1. Experimental Environment

We conduct experiments on the Windows 11 operating system using Python and the cryptography library, with the running environment being an Intel Core i7-14700HX CPU and an NVIDIA GeForce RTX 4070 Laptop GPU.

7.2. Comparison of Security and Functionality

We compare the functionality of the related schemes in

Table 3. Functionality comparison. Column name ECC stands for “elliptic curve cryptography”, AS denotes “access structure”, OD represents “outsourced decryption”, and DIV means “data integrity verification”.

Source	ECC	Multi-Authority	ABE Type	Revocation	AS	OD	DIV
[53]	✓	×	KP-ABE	×	Tree	✓	✓
[54]	✓	×	CP-ABE	×	Tree	✓	✓
[55]	✓	×	KP-ABE	×	Tree	×	✓
[57]	✓	✓	CP-ABE	×	LSSS	✓	✓
[56]	×	✓	CP-ABE	×	Tree	✓	×
LDDV	✓	✓	CP-ABE	✓	LSSS	×	✓

. Schemes [53,54,55] are single-authority ABE schemes. They use MAC (Message Authentication Code) and hash functions to implement data integrity verification, yet they suffer from single-point failure and performance bottleneck issues. Schemes [53,56] lack an attribute revocation mechanism. Scheme [56] does not implement data integrity verification. Although Scheme [57] has a custom elliptic curve point multiplication-based data integrity verification method, it does not support attribute revocation. LDDV, built on MA-ABE, leverages the data owner’s private key to sign the data, ensuring data integrity and trustworthiness. When a user initiates a decryption request, they sign the request with their own private key, and the cloud server verifies the signature’s validity using the user’s public key to confirm the user’s identity and permissions.

7.3. Computational Overhead Comparison

The comparison of computational costs between LDDV and existing schemes is shown in

Table 4. Comparison of computational overhead.

Source	Initialization	Encryption	Partial Decryption	Decryption	Revocation	Integrity Verification
[53]	$(n+1)M$	$(n+1)M+S+H$	$nM$	$2M+S+H$	–	H
[54]	$6M$	$M+S+H$	$2M$	$M+S+H$	–	H
[55]	$(n+1)M$	$(n+1)M+S+H$	–	$3tM$	–	H
[57]	$2kM$	$(2n+2)M+S+H$	$2nM$	$2M+H+S$	–	$H+M$
[56]	$2E+P$	$(2n+3)E+P$	$2nP+2nE$	E	–	–
LDDV	$kM+2H$	$(n+2)M+S+(n+1)H$	–	$(t+3)M+S+(t+1)H$	$2n_{R}H$	$H+2M$

. In the following, n denotes the number of attributes in the access policy, M denotes the point scalar multiplication on an elliptic curve, k denotes the number of attribute authorities, t denotes the number of valid attributes satisfying the policy for a user, $n_R$ denotes the number of revoked attributes, S denotes symmetric encryption, H denotes hash function computation, P is the symbol representing bilinear pairing, and E is used to denote the exponentiation operation in G and $G_T$.

From Table 4, we can roughly observe that the encryption computational overhead of our scheme is relatively higher than that of Scheme [54], and its decryption overhead is close to those of Schemes [53,55]. This is because our scheme needs to generate temporary keys and perform data integrity signatures to provide token access. The decryption overhead of Scheme [55] is relatively higher than ours, as its access structure is a tree structure: leaf node decryption requires t point scalar multiplications, and non-leaf node aggregation requires $2t$ point scalar multiplications. Scheme [56] has higher encryption overhead than other schemes due to its involvement of bilinear pairing operations, while Schemes [56,57] reduce user-side decryption overhead by adopting outsourced decryption.

Figure 2 shows the comparison of encryption overhead among LDDV, LEABE [55], LACMMAA [57], and EMBASS [56]. It can be found that the encryption overhead of LDDV is close to that of LEABE and lower than those of LACMMAA and EMBASS.

In Figure 3, we consider the outsourced decryption overhead and client-side decryption overhead of Schemes LACMMAA and EMBASS together. It is concluded that LDDV achieves about 28–42% faster decryption speeds compared to LEABE and LACMMAA. Moreover, the decryption overheads of LEABE and LACMMAA are close, with LEABE’s being slightly lower than LACMMAA’s.

From Figure 4, we can see that the data integrity verification overhead of LDDV and LACMMAA is very close under different data sizes. However, the implementation mechanisms differ: LDDV ensures data integrity through digital signature verification, while LACMMAA uses a customized elliptic curve point multiplication verification method. Although the latter is slightly more efficient computationally, its verification process has not undergone the same level of security review as standard algorithms (e.g., ECDSA), posing risks of hash function vulnerabilities and forgery attacks. While LACMMAA has a minor theoretical computational advantage, the actual performance difference between the two in practice is only milliseconds—negligible for the overall system. Thus, LDDV provides significantly enhanced security guarantees under the same computational load.

Figure 5 shows the comparison of key generation time. It can be found that LDDV’s key generation time is extremely close to LACMMAA’s. LEABE, however, binds the access policy to the key, resulting in relatively higher key generation time.

Figure 6 presents the total execution time of the four schemes, where LDDV has the shortest execution time. Meanwhile, LDDV (1) uses digital signatures to verify data user identities; and (2) on the basis of CP-ABE, allows the data owners to sign and verify data integrity using their private keys. Therefore, LDDV offers high security.

8. Conclusions

In this paper, we propose a lightweight decentralized medical data sharing scheme with dual verification (LDDV). On one hand, we construct a decentralized multi-attribute authorization authority management framework using elliptic curve cryptography. In this framework, multiple independent attribute authorities collaboratively manage user attribute keys, effectively avoiding single points of failure and reducing key management complexity. On the other hand, we design a lightweight dual verification mechanism. First, an ECDSA-based signature authentication mechanism is implemented to enhance authentication efficiency with low computational overhead, effectively addressing identity forgery and replay attacks. Second, dual encryption combined with digital signature techniques ensures the integrity and authenticity of medical data. Additionally, the scheme employs LSSS to achieve fine-grained access control and introduces an attribute revocation mechanism to ensure timely updates of access permissions. Security analysis and experimental validation demonstrate that LDDV achieves a balance between security and efficiency.

LDDV currently faces two primary limitations. First, its security framework relies on ECC, which is susceptible to post-quantum attacks. Second, the current implementation requires further optimization for scalable deployment across heterogeneous healthcare environments. Future work will prioritize three strategic enhancements. To address quantum vulnerabilities, we will migrate security protocols to lattice-based or post-quantum attribute-based encryption systems. Concurrently, blockchain integration will be explored for decentralized certificate revocation management, enabling real-time updates across distributed healthcare nodes. Additionally, leveraging IoT-enabled medical devices will facilitate secure real-time health data streaming, while AI-driven analytics will optimize access control policies through anomaly detection mechanisms, ultimately improving both system security and operational efficiency.