A Secure and Efficient KA-PRE Scheme for Data Transmission in Remote Data Management Environments

Abstract

In recent years, remote data management environments have been increasingly deployed across diverse infrastructures, accompanied by a rapid surge in the demand for sharing and collaborative processing of sensitive data. Consequently, ensuring data security and privacy protection remains a fundamental challenge. A representative example of such an environment is the cloud, where efficient mechanisms for secure data sharing and access control are essential. In domains such as finance, healthcare, and public administration, where large volumes of sensitive information are processed by multiple participants, traditional access-control techniques often fail to satisfy the stringent security requirements. To address these limitations, Key-Aggregate Proxy Re-Encryption (KA-PRE) has emerged as a promising cryptographic primitive that simultaneously provides efficient key management and flexible authorization. However, existing KA-PRE constructions still suffer from several inherent security weaknesses, including aggregate-key leakage, ciphertext insertion and regeneration attacks, metadata exposure, and the lack of participant anonymity within the data-management framework. To overcome these limitations, this study systematically analyzes potential attack models in the KA-PRE setting and introduces a novel KA-PRE scheme designed to mitigate the identified vulnerabilities. Furthermore, through theoretical comparison with existing approaches and an evaluation of computational efficiency, the proposed scheme is shown to enhance security while maintaining practical performance and scalability.

1. Introduction

Recently, remote data management has emerged as a fundamental requirement across diverse services and application domains. In such environments, a Sender securely stores its data in the cloud, while an authorized Receiver can access and utilize the data when necessary [1,2,3,4]. However, cloud servers are generally regarded as semi-trusted entities, typically modeled under the honest-but-curious adversarial assumption. In this setting, servers faithfully execute prescribed operations yet may attempt to infer or extract sensitive information from user data [5,6,7,8,9,10]. Consequently, ensuring data security and privacy within these semi-secure and ambiguous environments remains a major research challenge, prompting the development of various cryptographic mechanisms for fine-grained access control [11,12].

Among the representative techniques, the Key-Aggregate Cryptosystem (KAC) achieves efficient key management by enabling a compact aggregate key to represent decryption rights for multiple ciphertext classes, while Proxy Re-Encryption (PRE) enables secure and flexible data sharing by allowing ciphertexts to be transformed from one user’s key domain to another without revealing the plaintext [13,14,15]. The Key-Aggregate Proxy Re-Encryption (KA-PRE) paradigm combines the advantages of both approaches: a Sender can delegate decryption capabilities for multiple data classes through a single aggregate key, thereby supporting scalable and efficient data sharing in remote data-management systems. In recent years, Key-Aggregate Proxy Re-Encryption (KA-PRE) and related proxy-based cryptographic paradigms have been extensively studied across various application domains, including medical Internet of Things (IoT), decentralized cloud environments, and intelligent transportation systems [16]. Moreover, these schemes have evolved into diverse forms, such as CCA-secure and lattice-based PRE constructions, reflecting continuous advancements in both theoretical and practical aspects of proxy re-encryption [17,18].

Despite these benefits, existing KA-PRE schemes exhibit several security limitations. Specifically, they are vulnerable to (i) the derivation of new aggregate keys by algebraically combining previously issued ones, (ii) ciphertext-based attack patterns such as insertion and replay attacks, (iii) leakage of metadata pertaining to data-class identifiers, and (iv) the absence of anonymity guarantees for participating entities. For example, during the re-encryption process, metadata associated with particular data classes can inadvertently leak through the parameters transmitted to the Proxy Server. Likewise, an adversary may craft or replay ciphertexts to subvert data-integrity guarantees. Moreover, conventional public-key-based frameworks expose the identities of Senders and Receivers, thereby failing to ensure anonymity during data-sharing operations.

To overcome these vulnerabilities and mitigate threats arising during interactions with the Proxy Server, this paper proposes an enhanced and security-reinforced KA-PRE model. The primary contributions of this study are summarized as follows:

• Security Analysis: We identify and formally characterize the security weaknesses inherent in existing KA-PRE schemes and provide detailed attack models for each vulnerability.
• Based on these analyses, we define a comprehensive set of security requirements that must be satisfied in a robust KA-PRE environment.
• Proposed Construction: We design and present an improved KA-PRE scheme that addresses the shortcomings of prior works and offers enhanced protection against the identified attack vectors.

The remainder of this paper is organized as follows. Section 2 reviews related work and derives the security requirements. Section 3 describes the system model and presents the proposed KA-PRE protocol in detail. Section 4 provides a comprehensive security analysis and discusses the satisfaction of the identified requirements. Section 5 concludes the paper and outlines directions for future research.

2. Background

In this section, we define the security requirements derived from existing research trends and the corresponding attack models identified in the KA-PRE setting.

2.1. Key-Aggregate Proxy Re-Encryption

Key-Aggregate Proxy Re-Encryption (KA-PRE) is a cryptographic construction that integrates the principles of Key-Aggregate Cryptosystems (KACs) and Proxy Re-Encryption (PRE). In KA-PRE, a Sender aggregates decryption privileges for multiple data classes into a single compact aggregate key, while a Proxy Server performs a re-encryption operation that enables only the designated Receiver to obtain the corresponding decryption rights. The Key-Aggregate Cryptosystem (KAC) was originally proposed to achieve efficient access control and scalable key management in data-sharing environments such as cloud-based storage systems [11,14,15,19,20]. KAC allows a Sender to generate a constant-size aggregate key that grants the Receiver decryption capability over multiple ciphertext classes. This significantly reduces the overhead associated with key distribution and management while ensuring that all data remain encrypted throughout their lifecycle. The Proxy Re-Encryption (PRE) primitive, first introduced by Blaze, Bleumer, and Strauss in 1998 [21], represents a specialized form of public-key cryptography. PRE enables a Sender to securely delegate decryption rights to a designated Receiver through an untrusted Proxy Server, without revealing the Sender’s private key [22,23,24,25,26,27]. By combining the advantages of both KAC and PRE, KA-PRE offers an efficient and flexible framework for fine-grained data access control. Recently, KA-PRE and related proxy-based encryption paradigms have continued to evolve across various domains such as medical IoT, decentralized cloud, and intelligent transportation systems [16,17,18]. However, existing KA-PRE constructions still suffer from a range of security vulnerabilities and remain exposed to various attack models. The detailed descriptions and analyses of these attack models are presented in Section 2.2.

2.2. Attack Model for KA-PRE

In this Subsection, we provide a detailed analysis of the attack models.

• Attack Model ${\mathcal{A}}_1$. (Aggregate Key Leakage)
  Description. If the aggregate key generated by the Sender (see Algorithm 1) is exposed while stored on an untrusted device, an adversary who collects multiple aggregate keys may combine them algebraically to derive a new aggregate key. The adversary’s goal is to construct an aggregate key ${\mathsf{K}}_{S_{*}}$ for a set of data classes $S_{*}$ that was never issued by the Sender, thereby obtaining unauthorized access to those classes. Such key-derivation attacks critically violate confidentiality and key-management assumptions [28,29].
• Attack Model ${\mathcal{A}}_2$. (Ciphertext Injection)
  Description. As illustrated in Algorithm 2, an adversary may modify selected components of a tuple-formatted ciphertext so that the integrity-verification step fails [30,31]. The objective of this manipulation is to prevent a legitimate Receiver from completing decryption, thereby directly compromising data availability and potentially inducing a Denial-of-Service (DoS) condition.
• Attack Model ${\mathcal{A}}_3$. (Ciphertext Regeneration)
  Description. Because ciphertexts are produced using identical parameter sets and a fixed format, and because the system relies solely on integrity checks, an adversary can craft malicious ciphertexts that preserve the original structural format while embedding altered parameters [32,33]. As illustrated in Algorithm 3, the adversary’s goal is to produce a ciphertext that appears structurally legitimate but contains attacker-chosen parameters; once injected into the system, such ciphertexts can bypass simple integrity verification. By doing so, an adversary may insert unauthorized messages, corrupt protocol state, or otherwise disrupt normal data flows.
• Attack Model ${\mathcal{A}}_4$. (Metadata Leakage)
  Description. During the re-encryption process, metadata associated with the ciphertext is transmitted to the Proxy Server. Because the Proxy Server is only semi-trusted, an adversary that controls or compromises the Proxy (or observes its inputs/outputs) may infer which data class a given ciphertext belongs to. As illustrated in Algorithm 4, this enables the adversary to harvest metadata independently of any granted data-access privileges, thereby mounting a metadata-leakage attack [34,35]. Such leakage can significantly weaken privacy guarantees: even without decrypting content, an adversary can perform profiling, traffic analysis, or linkability attacks that expose sensitive relationships between data owners, data classes, and access patterns.

Algorithm 1: Aggregate Key Leakage Attack (${\mathcal{A}}_1$)

1: Input: Leaked aggregate keys $\mathcal{K}=\{{\mathsf{K}}_{S_1},{\mathsf{K}}_{S_2},\dots ,{\mathsf{K}}_{S_m}\}$; target class set $S_{*}$  2: Output: Candidate key ${\mathsf{K}}_{S_{*}}^{\prime }$ or ⊥  3: Initialized:   $S^{\prime }\leftarrow \mathcal{K}$  4: for each$({\mathsf{K}}_{S_i},{\mathsf{K}}_{S_j})$ in $S^{\prime }$ do  5:     if $S_i\subset S_j$ then  6:         ${\mathsf{K}}_{S_j\setminus S_i}\leftarrow {\mathsf{K}}_{S_j}·{\mathsf{K}}_{S_i}^{-1}$  7:         add ${\mathsf{K}}_{S_j\setminus S_i}$ to M  8:     end if  9:     if $(S_i\cap S_j)\in M$ then  10:         ${\mathsf{K}}_{S_i\cup S_j}\leftarrow {\mathsf{K}}_{S_i}·{\mathsf{K}}_{S_j}·{\mathsf{K}}_{S_i\cap S_j}^{-1}$  11:         add ${\mathsf{K}}_{S_i\cup S_j}$ to M  12:     end if  13: end for  14: if$S_{*}\in M$then  15:     return ${\mathsf{K}}_{S_{*}}$  16: else if$S_{*}$ can be composed from subsets in M then  17:     return product of corresponding keys  18: else  19:     return ⊥  20: end if

Algorithm 2: Ciphertext Injection (${\mathcal{A}}_2$)

1: Input: A Ciphertext $\mathcal{C}=(c_1,c_2,\dots ,c_m)$  2: Output: DoS(Decrypt aborted) or ⊥  3: select an index $i\in \{1,\dots ,m\}$  4: $c_i^{\prime }\leftarrow \mathsf{Forge}\left(c_i\right)$  5: construct modified ciphertext  6: $C^{\prime }\leftarrow (c_1^{\prime },\dots ,c_{i-1}^{\prime },c_i^{\prime },c_{i+1}^{\prime },\dots ,c_m^{\prime })$  7: if $\mathsf{VerifyIntegrity}\left(C^{\prime }\right)==\perp$ then  8:     submit $C^{\prime }$ repeatedly  9:     return DoS  10: else  11:     return ⊥  12: end if

Algorithm 3: Ciphertext Regeneration Attack (${\mathcal{A}}_3$)

1: Input: Legitimate format $\mathcal{C}=(c_1,c_2,\dots ,c_m)$; public parameter g  2: Output: Forged ciphertext ${\mathcal{C}}^{\prime }$ (passes integrity) or ⊥  3: observe tuple format and common parameters of valid ciphertexts  4: $(c_1^{\prime },c_2^{\prime },\dots ,c_m^{\prime })\leftarrow \mathsf{FreshParamsLike}\left(\mathcal{C}\right)$  5: $c_{\theta }^{\prime }\leftarrow \mathsf{SolveTag}\left(c_1^{\prime },H_3(c_1^{\prime },c_2^{\prime },\dots ,c_m^{\prime })\right)$  6: ${\mathcal{C}}^{\prime }\leftarrow (c_1^{\prime },c_2^{\prime },\dots ,c_m^{\prime })$  7: if $\mathsf{VerifyIntegrity}\left({\mathcal{C}}^{\prime }\right)$ checks only pairing equality then  8:     submit ${\mathcal{C}}^{\prime }$ to system  9:     return ${\mathcal{C}}^{\prime }$  10: else  11:     return ⊥  12: end if

Algorithm 4: Metadata Leakage (${\mathcal{A}}_4$)

1: Input: Ciphertexts with metadata $\mathcal{D}=\{{\mathcal{D}}_1,{\mathcal{D}}_2,\dots ,{\mathcal{D}}_t\}$  2: Output: Mapping between tags and data classes, or ⊥  3: observe metadata $\mathcal{D}$ during re-encryption  4: collect all values ${\mathcal{D}}_1,{\mathcal{D}}_2,\dots ,{\mathcal{D}}_t$ across sessions  5: record frequency and timing of each tag  6: for each tag ${\mathcal{D}}_i$ do  7:     if ${\mathcal{D}}_i$ repeats across ciphertexts then  8:         correlate ${\mathcal{D}}_i$ with context (e.g., time, frequency)  9:     end if  10: end for  11: if tag ${\mathcal{D}}_i$ consistently co-occurs with a specific context then  12:     infer mapping: ${\mathcal{D}}_i\to \mathrm{data}\mathrm{class}$ (e.g., medical, financial, location)  13:     return mapping  14: else  15:     return ⊥  16: end if

5.

Attack Model${\mathcal{A}}_5$. Unlinkability and Anonymity Violation

Description. If the identities of the Sender and Receiver are associated with metadata without appropriate anonymization (see Algorithm 5), an adversary can infer relationships among participants or reconstruct a Sender’s behavioral patterns. In particular, repeated requests for the same data class or the accumulation of aggregate-key usage records enable an adversary to learn associations between specific participants and data classes over time, thereby violating unlinkability and anonymity guarantees [36,37]. Such linkability enables profiling and deanonymization attacks that can expose collaboration patterns, sensitive interests, or operational behaviors even when the underlying plaintext remains encrypted.

Algorithm 5: Unlinkability and Anonymity Violation Attack (${\mathcal{A}}_5$)

1: Input: Metadata log $\mathcal{D}={\left\{({\mathrm{tag}}_t,{\mathrm{keyidx}}_t,{\mathsf{reqLog}}_t)\right\}}_t$ across sessions  2: Output: Linked relation data, or ⊥  3: for$\mathbf{each}\in \mathcal{D}$ do  4:     for each tag observed with $\mathrm{ID}$ do  5:         $f[\mathrm{ID},\mathrm{tag}]\leftarrow \mathrm{frequency}\mathrm{of}\mathrm{co}-\mathrm{occurrence}$  6:     end for  7:     if some tag t dominates (high $f[\mathrm{ID},t]$ across sessions) then  8:         add Association $\mathrm{ID}\to \mathsf{Class}\left(t\right)$  9:     end if  10: end for  11: for each pair $({\mathrm{ID}}_s,{\mathrm{ID}}_r)$ do  12:     if same tags/requests co-occur in $\mathsf{reqLog}({\mathrm{ID}}_s,{\mathrm{ID}}_r)$ repeatedly then  13:         add Link $({\mathrm{ID}}_s\leftrightarrow {\mathrm{ID}}_r)$ to Links  14:     end if  15: end for  16: if any (Associations or Link exists) then  17:     return $\{\mathrm{Associations},\mathrm{Links}\}$  18: else  19:     return ⊥  20: end if

2.3. Related Work

In this Subsection, we analyze the security vulnerabilities of existing KA-PRE schemes with respect to the attack models ${\mathcal{A}}_1$–${\mathcal{A}}_5$ described in Section 2.2.

Kajita & Ohtake propose KA-IB-PRE, a scheme aimed at enabling secure data sharing within personal data storage environments. In this construction, the Sender generates an identity-based key and issues decryption privileges for multiple data classes through an aggregate key, while the Proxy Server executes the re-encryption to ensure that the Receiver can only access the intended data. Furthermore, the ExKeyReGen step prevents data class metadata from being directly exposed to the Proxy Server. However, when analyzing the scheme of Kajita & Ohtake with respect to attack model ${\mathcal{A}}_3$, all ciphertexts are generated in an identical format $\mathcal{C}=\{c_1,c_2,\dots ,c_8\}$ and rely on the same parameter set $(r,ID,S)$. Consequently, even if an adversary selects a new random value $r^{\prime }$ and regenerates a forged ciphertext ${\mathcal{C}}^{\prime }=\{c_1^{\prime },c_2^{\prime },\dots ,c_7^{\prime }\}$ with the same structure, the integrity verification step is unable to distinguish between them. Moreover, under attack model ${\mathcal{A}}_5$, the identity values of the Sender and Receiver in the identity-based structure are directly embedded in the metadata and re-encryption parameters. As a result, an adversary can track the activities of a specific user by observing repeated identity tags across multiple sessions.

Chen et al. present a scheme that integrates PRE with KAC, enabling the Sender to generate aggregate keys while permitting the proxy to re-encrypt only a specified subset of ciphertexts. This design alleviates the excessive key storage overhead associated with conventional PRE schemes and ensures that an adversary cannot directly infer the underlying plaintext [38]. This construction mitigates the excessive key storage overhead inherent in conventional PRE schemes and ensures that an adversary cannot directly infer the underlying plaintext. However, under Attack Model ${\mathcal{A}}_3$, the scheme of Chen et al. generates all ciphertexts using an identical format $\mathcal{C}=\{c_1,c_2,\dots ,c_7\}$ and a common random parameter r. Consequently, even if an adversary regenerates a forged ciphertext ${\mathcal{C}}^{\prime }=\{c_1^{\prime },c_2^{\prime },\dots ,c_7^{\prime }\}$ with the same structure, the verification procedure merely confirms $e(c_1,H_3(c_1,c_2,\dots ,c_6))\stackrel{?}{=}e(g,c_7)$, rendering the Receiver unable to distinguish between genuine and forged ciphertexts. Furthermore, under Attack Model ${\mathcal{A}}_5$, if an alternative aggregate key $K_{S_{B2}}$,$K_{S_{B1}}$ corresponding to the same data class is compromised, the adversary can derive a new aggregate key through operation ${K^{\prime }}_{S_B}\leftarrow K_{S_{B2}}/K_{S_{B1}}$. Finally, when analyzing Attack Model ${\mathcal{A}}_4,{\mathcal{A}}_5$, both the data class S and index values are explicitly reflected in the plaintext-dependent ciphertext components $(ID,S)$, enabling the Proxy Server to directly observe this information. Moreover, since participant identifiers are not anonymized, the scheme fails to preserve anonymity.

Pareek & Purushothama provide flexibility by enabling the Sender to re-encrypt an aggregate key with either a different aggregate key or a different data class, and further supports multiple functionalities through two transformation steps [39]. However, under Attack Model ${\mathcal{A}}_3$, the ciphertext structure is generated using an identical format $\mathcal{C}=\{c_1,c_2,\dots ,c_6\}$ and the same random parameter r thereby allowing an adversary to regenerate a forged ciphertext ${\mathcal{C}}^{\prime }=\{c_1^{\prime },c_2^{\prime },\dots ,c_6^{\prime }\}$ with the same structure. Moreover, under Attack Model ${\mathcal{A}}_1$, if an adversary obtains an alternative aggregate key $K_{S_{B2}},K_{S_{B1}}$ corresponding to the same data class, the adversary can derive a new aggregate key through operation ${K^{\prime }}_{S_B}\leftarrow K_{S_{B2}}/K_{S_{B1}}$. Finally, under Attack Model ${\mathcal{A}}_4,{\mathcal{A}}_5$, the data class S is directly transmitted to the Proxy Server during the re-encryption process, resulting in the explicit leakage of metadata S. In addition, the lack of anonymization of participant identifiers results in a failure to preserve anonymity.

Therefore, existing schemes commonly exhibit security weaknesses corresponding to attack models ${\mathcal{A}}_3,{\mathcal{A}}_5$. Furthermore, the schemes proposed by Pareek & Purushothama and by Chen et al. are particularly susceptible to ${\mathcal{A}}_1,{\mathcal{A}}_2$ and ${\mathcal{A}}_4$.

2.4. Security Theorems

In this Subsection, we analyze the limitations of existing studies and the corresponding attack models discussed in Section 2.2 and Section 2.3 and subsequently present five security requirements derived from this analysis.

• Aggregate Key Confidentiality Preservation: The aggregate key generated by the Sender must be unique and must not be exposed to external entities. To ensure this property, the aggregate key should be generated differently for each Receiver and for each set of aggregated data classes, and it must be infeasible to derive a valid aggregate key for a new data class by performing computations on aggregate keys corresponding to different data classes.
• Resistance Against Ciphertext-Based Attack: This attack is divided into two types as follows.

  (a)

  Resistance Against Ciphertext Injection Attack: If an adversary alters the ciphertext structure within the Proxy Server or tampers with the contents of its components, such modifications must be verifiable through the scheme’s integrity mechanisms.

  (b)

  Robustness Against Ciphertext Regeneration Attack: If an adversary generates a ciphertext with the same structure using newly chosen parameter values or attempts to retransmit a stolen ciphertext, must prevent such ciphertexts from being accepted as legitimate messages.

• Metadata Confidentiality and Leakage Prevention: The Proxy Server is assumed to operate in a semi-trusted capacity. As it cannot be regarded as fully trusted, metadata pertaining to the data classes specified by the re-encryption key must remain concealed during the transmission of the re-encryption key to the Proxy Server.
• Anonymity for Data Management: Since sensitive data originating from the Sender is transmitted and received, the anonymity of participants must be preserved. Moreover, while ensuring anonymity throughout the data management process, the legitimacy of the Sender must remain verifiable in scenarios that require identity validation, such as ciphertext regeneration or replay attacks.

2.5. Security Definitions

Definition 1 (IND-CCA Security for KA-PRE).

Let Π be a KA-PRE scheme. An adversary $\mathcal{A}$ interacts with ${\mathcal{O}}_{\mathsf{Key}},{\mathcal{O}}_{\mathsf{Enc}},{\mathcal{O}}_{\mathsf{Agg}},{\mathcal{O}}_{\mathsf{ReKey}},{\mathcal{O}}_{\mathsf{ReEnc}},{\mathcal{O}}_{\mathsf{Dec}},$ and ${\mathcal{O}}_{\mathsf{DecR}}$. In the challenge phase, $\mathcal{A}$ submits $(M_0,M_1,{\mathrm{AID}}_{*},S_{*},{\mathrm{AID}}_{*}^{\prime })$. The challenger samples $b\leftarrow \{0,1\}$ and returns $C^{*}\leftarrow \mathsf{Enc}({\mathrm{AID}}_{*},M_b)$ (or $C^{R*}$ obtained by applying $\mathsf{ReEnc}$ under valid inputs). Oracle access continues with standard IND-CCA exclusions on decrypting $C^{*}$ and any trivially derived ciphertexts. We say Π is IND-CCA secure if ${\mathrm{Adv}}_{\Pi }^{\mathrm{IND}-\mathrm{CCA}}\left(\mathcal{A}\right)$ is negligible in λ.

Definition 2 (Aggregate-Key Unforgeability (AK-UF)).

No PPT adversary given oracle access to derive ${\left\{(K_{S_i},{\tau }_{S_i})\right\}}_i$ for adaptively chosen $S_i$ can produce a new $(K_{S^{*}},{\tau }_{S^{*}})$ verifiable for a nontrivial $S^{*}\notin {\left\{S_i\right\}}_i$ except with negligible probability.

Definition 3 (Re-Encryption-Key Unforgeability/Legitimacy (REK-UF)).

No PPT adversary can forge a valid $r{k}_{{\mathrm{AID}}_s\to {\mathrm{AID}}_r}$ that passes the scheme’s legitimacy verification while violating the binding to $({\mathrm{AID}}_s,{\mathrm{AID}}_r,S)$, except with negligible probability.

Definition 4 (Anonymity and Unlinkability (Anon/UL)).

Given a challenge instance where one of two candidate identities (or sessions) underlies the ciphertext (or re-encrypted ciphertext), no PPT adversary can distinguish or link the underlying sender/receiver/session beyond negligible advantage.

Definition 5 (Class-Hiding (IND-CH)).

Given two class sets of equal size, an adversary cannot distinguish which set was used to derive the target ciphertext or re-encrypted ciphertext beyond negligible advantage.

Table 1. Mapping between attack models (A1–A5) and formal security notions.

Attack	Primary Notation(s)	Notes
A1 (Aggregate key leakage)	$\mathrm{AK}-\mathrm{UF}$, $\mathrm{IND}-\mathrm{CCA}$ (confidentiality)	New key derivation from leaks is infeasible
A2 (Ciphertext injection)	Integrity of ciphertexts; $\mathrm{IND}-\mathrm{CCA}$	Forged ciphertexts fail pairing-/verification checks
A3 (Ciphertext regeneration)	$\mathrm{IND}-\mathrm{CCA}$, $\mathrm{REK}-\mathrm{UF}$	Illegitimate re-encryption keys or transforms fail verification
A4 (Metadata exposure)	$\mathrm{IND}-\mathrm{CH}$, $\mathrm{Anon}/\mathrm{UL}$	Class/identity hiding under random-oracle assumptions
A5 (Anon/Unlink break)	$\mathrm{Anon}/\mathrm{UL}$	Challenge identity/session must remain indistinguishable

presents the mapping between attack models (A1–A5) and the corresponding formal security notions. We provide formal games and reductions for these notions in Appendix B.

2.6. Adversarial Oracles and Corruption Model

We consider a PPT adversary $\mathcal{A}$ with oracle access:

• ${\mathcal{O}}_{\mathsf{Key}}\left(\mathrm{id}\right)\to ({\mathsf{sk}}_{\mathrm{id}},\mathrm{AID},{\sigma }_{id})$;
• ${\mathcal{O}}_{\mathsf{Enc}}(\mathrm{AID},M)\to C$;
• ${\mathcal{O}}_{\mathsf{Agg}}(\mathrm{AID},S)\to (K_S,\tau )$;
• ${\mathcal{O}}_{\mathsf{ReKey}}({\mathrm{AID}}_s,{\mathrm{AID}}_r,S)\to r{k}_{{\mathrm{AID}}_s\to {\mathrm{AID}}_r}$;
• ${\mathcal{O}}_{\mathsf{ReEnc}}(C,rk,K_S,\tau )\to C^R$;
• ${\mathcal{O}}_{\mathsf{Dec}}\left(C\right)\to M$, ${\mathcal{O}}_{\mathsf{DecR}}(K_S,C^R)\to M$.

This is subject to standard exclusions in the challenge games below. We allow collusion between the proxy and receivers unless stated otherwise.

The complete challenger/oracle simulations used in our reductions are detailed in Appendix B.

3. Proposed Scheme

In this section, we propose a Secure and Efficient KA-PRE Scheme that fulfills the security requirements described in Section 2.

3.1. System Scenario

The proposed scheme is designed based on the scenario illustrated in Figure 1. The system model comprises four entities: the Sender, Proxy Server, Receiver, and Trusted Third Party. The roles of these entities are defined as follows.

• Sender: As the data owner, the Sender shares data by encrypting the data class it belongs to together with its anonymous identifier, and then stores it on the Proxy Server. The Sender subsequently generates the cryptographic keys (e.g., re-encryption keys and aggregate keys) required for delegated distribution of the data.
• Receiver: The Receiver obtains re-encrypted ciphertexts from the Proxy Server and performs the decryption process to recover the original data.
• Proxy Server: The Proxy Server stores the Sender’s initial ciphertexts and, upon request, produces re-encrypted ciphertexts. It then delivers the generated re-encrypted ciphertexts to the designated Receiver.
• Trusted Third Party (TTP): The TTP generates public system parameters and issues private keys and pseudonymous identifiers to participants (i.e., Sender and Receiver). Furthermore, when identity verification is required in specific situations, the TTP may also serve as a verifier.

The detailed operational procedure of the Secure and Efficient KA-PRE scheme is constructed as an eight-phase process, based on the five assumptions outlined in Section 3.2.

Phase 1.

Setup Phase: The TTP generates the public parameters and the master secret key.

Phase 2.

KeyGen Phase: The TTP issues pseudonymous identifiers (serving as public keys) and private keys to the participants.

Phase 3.

Encrypt Phase: The Sender uses its pseudonymous identifier (as the public key) to generate the initial ciphertext.

Phase 4.

Aggregate KeyGen Phase: The Sender generates an aggregate key and the corresponding verification value for a designated set of data classes.

Phase 5.

Re-KeyGen Phase: The Sender creates a re-encryption key to delegate decryption capability to the Receiver.

Phase 6.

Re-Encrypt Phase: The Proxy Server generates a re-encrypted ciphertext enabling the Receiver to perform decryption.

Phase 7.

Decrypt₁ Phase: The Sender decrypts the initial ciphertext.

Phase 8.

Decrypt_R Phase: The Receiver decrypts the re-encrypted ciphertext using its private key and aggregate key.

3.2. Assumptions

The assumptions underlying the Secure and Efficient KA-PRE scheme are as follows:

• The proposed scheme operates in an environment supporting bilinear pairings.
• The TTP is a fully trusted authority for all participants. However, in practical deployments, even a semi-honest or curious TTP could potentially observe verification queries, such as $(Aid,{\sigma }_{id},ts)$, and infer session-level linkability or user behavior patterns through timing or frequency analysis. Although the proposed scheme performs local verification in the re-encryption and decryption phases to minimize online dependency, residual privacy risks may still arise if the TTP logs verification events. To mitigate such risks, future work may incorporate local verification tokens, blind signatures, or zero-knowledge proofs to eliminate the need for online TTP involvement in every operation while preserving the same security goals against ${\mathcal{A}}_3$ and ${\mathcal{A}}_5$.
• The Proxy Server correctly follows the prescribed protocol but may attempt to infer additional information about participants’ data from the information it obtains (i.e., it is semi-honest).
• Session-specific aggregate keys or re-encryption keys may be exposed; however, the master secret key of the TTP, as well as the secret keys of the Sender and Receiver, remain uncompromised.

3.3. System Parameters

In this Subsection, we present the overall system parameters of the proposed scheme, as summarized in

Table 2. System parameters for the proposed scheme.

Notation	Description	Notation	Description
$\lambda$	Security parameter	$s{k}_{i{d}_i}$	Secret key of Sender/Receiver
p	$\lambda$-bit Security parameter	C	Initial ciphertext
${\mathbb{G}}_1,{\mathbb{G}}_2$	Cyclic groups of order p	$K_{S_B}$	Aggregate key
$\alpha$	Master secret key ($\alpha \stackrel{R}{\leftarrow }{\mathbb{Z}}_p$)	${\sigma }_{id}$	Anonymous ID credential
$params$	Set of public parameters	$\mathcal{T}$	Aggregate key verification value
n	Maximum number of data classes	$r{k}_{{Aid}_i\to {Aid}_2}$	Re-encryption key
g	Generator ($g\in {\mathbb{G}}_1$)	$C^R$	Re-encrypted ciphertext
$i{d}_i$	Identity of the Sender/Receiver	$ts$	Timestamp
Aidi	Anonymous identity of the Sender/Receiver	$S_B$	Set of data classes
$mr$	Random value ($mr\in {\mathbb{Z}}_p$)	$H_1(·)$	Hash function, ${\mathbb{G}}_2\to {\{0,1\}}^{\lambda }$
$H_2(·)$	Hash function, ${\{0,1\}}^{*}\to {\mathbb{G}}_1$	$H_3(·)$	Hash function, ${\mathbb{G}}_1\times {\mathbb{G}}_1\times {\mathbb{G}}_2\times {\mathbb{G}}_1\times {\{0,1\}}^{\lambda }\to {\mathbb{G}}_1$
$H_4(·)$	Hash function, ${\{0,1\}}^{\lambda }\times {\mathbb{G}}_2\to {\mathbb{Z}}_p$	$H_5(·)$	Hash function, ${\{0,1\}}^{\lambda }\to {\mathbb{G}}_1$
$H_6(·)$	Hash function, ${\{0,1\}}^{*}\to {\{0,1\}}^{\lambda }$

.

3.4. Proposed Scheme

In this Subsection, we describe the detailed operational flow of the proposed scheme. The scheme is composed of eight phases, and the operations performed in each phase are as follows. The proposed KA-PRE scheme ensures correctness, and the corresponding proof is provided in Appendix A. Formal security proofs are presented in Appendix B.

3.4.1. Setup Phase

In the Setup phase, the TTP executes the setup procedure prior to system operation, allowing each participant to subsequently utilize the Proxy Server. In this stage, the TTP generates the master secret key, which is known only to itself, along with the public parameters $Params$ which are published to all users.

• $Setup(\lambda ,n)\to$($params,\alpha )$: This phase is executed by the TTP. Given the security parameter $\lambda$ and the maximum number of data classes n, the TTP performs the following steps:
  Step 1. Define two cyclic groups ${\mathbb{G}}_1,{\mathbb{G}}_2$ of prime order p.
  Step 2. Define a bilinear map $\mathrm{e}\left({\mathbb{G}}_1,{\mathbb{G}}_1\right)\to {\mathbb{G}}_2$.
  Step 3. Select a generator $g\in {\mathbb{G}}_1$.
  Step 4. Choose a master secret key $\alpha \stackrel{R}{\leftarrow }{\mathbb{Z}}_p$, and for each $i\in \{1,2,\dots ,n,n+1,\dots ,2n\}$, compute $g_i=g^{{\alpha }^i}$.
  Step 5. Define a set of cryptographic hash functions $H_1,H_2,H_3,H_4,H_5,$ and $H_6$.
  Step 6. Output the system public parameters $params=(g,g_1,\dots ,g_n,g_{n+1},\dots ,g_{2n}{H}_1,H_2,H_3,H_4,H_5,H_6)$.

3.4.2. KeyGen Phase

The key generation phase consists of three sub-phases: Masking ID Generation, Secret Key Generation, and Verification Value Generation.

These operations are executed by the TTP. The TTP receives the identity $i{d}_i$ of each participant (Sender, Receiver) and uses a random value $mr$ to generate a masked identity ${Aid}_i$. Using the generated ${Aid}_i$ together with the master secret key $\alpha$ and hash function $H_3$, the TTP computes the secret key $s{k}_{i{d}_i}$. Finally, a verification value ${\sigma }_{id}$ is derived for validation of ${Aid}_i$. The resulting values are then transmitted to the participants over an encrypted channel.

• Masking ID Generation ($params$, $\left.i{d}_i,mr\right)\to \left({Aid}_i\right)$: This phase is executed by the TTP. The TTP receives the identity $i{d}_i$ from each participant (Sender, Receiver). Given the inputs $i{d}_i$, the master secret key $\alpha$ and a random value $mr$, the TTP performs the following operation:
  Concatenate $i{d}_i$ with the random value $mr$ generated by the TTP, and apply the hash function $H_2$ to derive the masked identity ${Aid}_i$

  $${Aid}_i=H_2\left(i{d}_i\parallel mr\right)$$

  (1)
• Secret Key Generation ($params$, ${Aid}_i$$,\alpha )\to \left(s{k}_{i{d}_i}\right)$: This phase is executed by the TTP. The TTP receives the identity $i{d}_i$ of each participant (Sender, Receiver) together with the corresponding masked identity ${Aid}_i$, the master secret key $\alpha$, and the hash function $H_5$. Given these inputs, the TTP performs the following operation:
  The TTP hashes ${Aid}_i$ using $H_5$, and then exponentiates the result with the master secret key $\alpha$ to compute the participant’s secret key $s{k}_{i{d}_i}$.

  $$s{k}_{i{d}_i}=H_5{\left({\mathrm{Aid}}_i\right)}^{\alpha }$$

  (2)
• Verification value Generation ($params,{Aid}_i,i{d}_i,mr,ts)\to ({\sigma }_{id}$): This phase is executed by the TTP. The TTP takes as input the masked identity ${Aid}_i$, the real identity $i{d}_i$, the random value $mr$, and the timestamp $ts$ indicating the expiration time, and performs the following operation:
  The TTP computes a hash of $({Aid}_i,i{d}_i,mr,ts)$ using the hash function $H_6$. It then derives the verification value ${\sigma }_{id}$, which is used to confirm that ${Aid}_i$ has been legitimately generated by the TTP.

  $${\sigma }_{id}=H_6\left({Aid}_i,∥i{d}_i∥mr\parallel ts\right)$$

  (3)

3.4.3. Encrypt Phase

The encryption phase is executed by the Sender. The Sender first selects a message $M_j$ to be encrypted, and then chooses a random value R. The Sender computes the hash value t using the hash function $H_4$. The generated parameters are subsequently used to construct the initial ciphertext C, which consists of the tuple $(c_1,c_2,c_3,c_4,c_5,c_6,c_7,c_8)$. Finally, the resulting initial ciphertext is stored on the Proxy Server.

• Encryption ($params,M_j,{\mathrm{Aid}}_{\mathrm{i}},{\sigma }_{id})\to (C$): This phase is executed by the Sender. The Sender first selects the message $M_j$ to be encrypted and chooses a random value R. Using $M_j\in {\{0,1\}}^{\lambda }$ and $R\stackrel{R}{\leftarrow }{\mathbb{G}}_2$, the Sender computes $t\in {\mathbb{Z}}_p$ by applying the hash function $H_4$. With the computed values $R,t$ and the inputs $params,M_j,{Aid}_i$, the Sender proceeds as follows:
  Step 1. The Sender determines the message $M_j$ and selects a random value R. Then, the Sender computes $t=H_4(M_j,R)$.
  Step 2. Using the random values $R,t$, the verification value ${\sigma }_{id}$ generated by the TTP, the public parameters $params$, the message $M_j$, the participant’s masked identity ${Aid}_i$, the Sender generates the components of the initial ciphertext $(c_1,c_2,c_3,c_4,c_5,c_6,c_7,c_8)$.

  $$C=\left(c_1,c_2,c_3,c_4,c_5,c_6,c_7,c_8\right)$$

  (4)
  Step 3. The resulting ciphertext C is then stored on the Proxy Server.

3.4.4. Aggregate KeyGen Phase

The aggregate key generation phase is executed by the Sender. The Sender generates random values ${\sigma }^{\prime }$ and $R^{\prime }$, which are then used to compute the value r for the key generation process. Using the computed r value, the public parameters $params$, and the data class $S_B$, the Sender generates the aggregate key $K_{S_B}$ and subsequently computes the verification value $\tau$.

• Aggregate Key Generation ($params$, ${Aid}_i$, $S_B$, v) → ($K_{S_B}$, $\tau$): This phase is executed by the Sender. The Sender first selects the data class $S_B$ for which re-encryption will be performed. Next, using the session-specific random values ${\sigma }^{\prime }$ and $R^{\prime }$, the Sender computes the value r and generates the aggregate key $K_{S_B}$. Finally, after generating a random value v, the Sender computes the verification value $\tau$ using ${Aid}_i$ and $S_B$ as input, in order to validate the correctness of the aggregate key.
  Step 1. Select random values ${\sigma }^{\prime }\stackrel{R}{\leftarrow }{\{0,1\}}^{\lambda }$ and $R^{\prime }\stackrel{R}{\leftarrow }{\mathbb{G}}_2$.
  Step 2. The Sender compute the value r to be used in the aggregate key generation process by taking ${\sigma }^{\prime }$, $R^{\prime }$, and the hash function $H_4$ as input.

  $$r=H_4({\sigma }^{\prime },R^{\prime })$$

  (5)
  Step 3. The Sender computes the aggregate key $K_{S_B}$ using the derived value r, the system parameters $params$, and the data class $S_B$.

  $$K_{S_B}=\prod _{b\in S_B}{\left(g_{n+1-b}\right)}^r$$

  (6)
  Step 4. The Sender computes the verification value $\tau$ for the aggregate key. The validation value is used when aggregate key validation is required.

  $$\tau =H_2{({Aid}_i,S_B,v)}^r$$

  (7)

3.4.5. Re-KeyGen Phase

The re-encryption key generation phase is executed by the Sender, who computes the re-encryption key $r{k}_{{Aid}_1\to {Aid}_2}$. Subsequently, the Sender transmits the re-encryption key $r{k}_{{Aid}_1\to {Aid}_2}$ together with the aggregate key $K_{S_B}$ and the verification value $\tau$ (generated in Section 3.4.4) to the Proxy Server.

• Re-Encryption Key Generation $(params,{\sigma }^{\prime },R^{\prime },r,s,{Aid}_1,{Aid}_2)\to \left(r{k}_{{Aid}_1\to {Aid}_2}\right)$: This phase is executed by the Sender. The Sender computes the re-encryption key $r{k}_{{Aid}_1\to {Aid}_2}$.
  Step 1. the Sender select a random value $s\stackrel{R}{\leftarrow }{\mathbb{Z}}_q$ to be used for re-encryption key generation.
  Step 2. Using the parameters ${\sigma }^{\prime }$, $R^{\prime }$, and r generated during the Aggregate KeyGen Phase, together with the Sender’s identity ${Aid}_1$, the Receiver’s identity ${Aid}_2$, the random value s, and the public parameters $params$, the Sender generates the components $(r{k}_1,r{k}_2,r{k}_3,r{k}_4,r{k}_5,r{k}_6,r{k}_7)$ of the re-encryption key $r{k}_{{Aid}_1\to {Aid}_2}$.

  $$r{k}_{{Aid}_1\to {Aid}_2}=(r{k}_1,r{k}_2,r{k}_3,r{k}_4,r{k}_5,r{k}_6,r{k}_7)$$

  (8)
  Step 3. The generated re-encryption key $r{k}_{{Aid}_1\to {Aid}_2}$, together with the aggregate key $K_{S_B}$ and the verification value $\tau$ (produced in Section 3.4.4), is then transmitted to the Proxy Server.

3.4.6. Re-Encrypt Phase

The re-encryption phase is executed by the Proxy Server, which transforms the initial ciphertext C into the re-encrypted ciphertext $C^R$ such that the Receiver can decrypt it using its private key. The re-encrypted ciphertext $C^R$, together with the aggregate key $K_{S_B}$, is then transmitted to the Receiver.

• Re-Encryption $(params,r{k}_{{Aid}_1\to {Aid}_2},C,{Aid}_i,K_{S_B})\to \left(C^R\right)$: The Proxy Server performs verification before transforming the initial ciphertext C into the re-encrypted ciphertext $C^R$.
  Step 1. The Proxy Server verifies whether the ciphertext originates from a valid identity issued by the TTP. To this end, the Proxy Server directly performs the verification using ${\sigma }_{id}=H_6({Aid}_i\parallel i{d}_i\parallel m\parallel ts)$ which was generated during the KeyGen Phase, along with the components $c_1$ and $c_7$ of the initial ciphertext C. The verification is performed locally by the Proxy Server.
  $$e(H_5\left({\sigma }_{id}\right),c_1)\stackrel{?}{=}e(c_7,g)$$

  (9)
  Step 2. Once the validity of the identity is confirmed, an integrity verification of the ciphertext is conducted. This verification procedure uses the values of $C=(c_1,c_2,c_3,c_4,c_5,c_6,c_7,c_8)$, the Receiver’s public key, and the system parameters $params$. A total of three verification checks are performed, and if any of them fails, the re-encrypted ciphertext is not generated.

  $$e(c_1,H_5\left({Aid}_i\right)g_{n-1})\stackrel{?}{=}e(g,c_2)$$

  (10)

  $$e(c_1,c_4)\stackrel{?}{=}e(g,c_5)$$

  (11)

  $$e(c_1,H_3(c_1,c_2,c_3,c_5,c_6,c_7))\stackrel{?}{=}e(g,c_8)$$

  (12)
  Step 3. If all verification steps succeed, the Proxy Server computes the re-encrypted ciphertext $C^R$ using the aggregate key $K_{S_B}$, the initial ciphertext C, the re-encryption key $r{k}_{{Aid}_1\to {Aid}_2}$, and the system parameters $params$.

  $$C^R=({c^R}_1,{c^R}_2,{c^R}_3,{c^R}_4,{c^R}_5,{c^R}_6,{c^R}_7,{c^R}_8,{c^R}_9,{c^R}_{10},{c^R}_{11})$$

  (13)
  Step 4. The generated re-encrypted ciphertext $C^R$ is then transmitted to the Receiver.

3.4.7. Decrypt₁ Phase

The decryption of the initial ciphertext is performed exclusively by the Sender, who decrypts the initial ciphertext C using its private key.

• Decryption $(params,s{k}_{i{d}_i},C,{Aid}_i)\to \left(M_j\right)$: This phase is executed by the Sender. The Sender selects the initial ciphertext C to be decrypted. Next, using $params$ and ${Aid}_i$, the Sender verifies whether C has been tampered with. If the verification is successful, the Sender proceeds with the following steps using $params$, its private key $s{k}_{i{d}_i}$, the selected initial ciphertext C, and the public key ${Aid}_i$.
  Step 1. Before decrypting the initial ciphertext C, the Sender verifies the integrity of the data using the components of the ciphertext. This step is identical to the verification steps described in (10)–(12).
  Step 2. If the integrity verification is successful, the Sender computes the random value R used during encryption. The message $M_j$ is then derived by performing an XOR operation with the ciphertext component $c_6$. Finally, the decryption of the initial ciphertext C is completed.

  $$R\leftarrow c_3·{\displaystyle \frac{e(s{k}_{i{d}_1},c_1)}{e(c_2,g_1)}}$$

  (14)

  $$M_j=c_6\oplus H_1\left(R\right)$$

  (15)

3.4.8. Decrypt_R Phase

The re-decryption phase is executed by the Receiver, who obtains the re-encrypted ciphertext $C^R$ and the aggregate key $K_{S_B}$ from the Proxy Server. The Receiver then decrypts $C^R$ using its private key.

• Re-Decryption $(params,s{k}_{i{d}_2},C^R,K_{S_B},{Aid}_2)\to \left(M_j\right)$: This phase is executed by the Receiver. Before performing the decryption of the re-encrypted ciphertext, the Receiver conducts a verification process. This process first confirms that the ciphertext originates from a valid identity issued by the TTP, and subsequently performs integrity verification of the re-encrypted ciphertext and aggregate key. If all verifications succeed, the Receiver proceeds with the following steps using $params$, its identity ${Aid}_2$, its private key $s{k}_{i{d}_2}$, the aggregate key $K_{S_B}$, and the requested data class $S_B$.
  Step 1. The Receiver verifies whether the re-encrypted ciphertext originates from a valid identity issued by the TTP. To this end, the Receiver directly performs the verification using ${\sigma }_{id}=H_6({Aid}_i\parallel i{d}_i\parallel m\parallel ts)$ which was generated during the KeyGen Phase, together with the components $c_{10}^R$ and $c_{11}^R$ of the re-encrypted ciphertext $C^R$. The verification is performed locally by the Receiver.
  Step 2. Once the transmission is confirmed to originate from a valid identity, the Receiver performs integrity verification of the aggregate key. The Receiver generates the received value $\tau$ and compares it to verify whether the aggregate key $K_{S_B}$ has been tampered with.

  $$\tau \stackrel{?}{=}{H}_2{({Aid}_i,S_B,v)}^{H_4\left({\sigma }^{\prime }{R}^{\prime }\right)}$$

  (16)
  Step 3. Finally, the Receiver performs integrity verification of the re-encrypted ciphertext. This verification procedure uses the values of $C^R=({c^R}_1,{c^R}_2,{c^R}_3,{c^R}_4,{c^R}_5,{c^R}_6,$ ${c^R}_7,{c^R}_8,{c^R}_9,{c^R}_{10},{c^R}_{11})$, the Receiver’s identity ${Aid}_2$, and the system parameters $params$. Two verification checks are performed in total, and if any of them fails, the decryption process is aborted.

  $$e(H_5\left({\sigma }_{id}\right),{c^R}_{10})\stackrel{?}{=}e({c^R}_{11}R,g)$$

  (17)

  $$e(g,{c^R}_9)\stackrel{?}{=}e({c^R}_2,H_3({c^R}_2,{c^R}_3,{c^R}_4,{c^R}_6,{c^R}_7))$$

  (18)
  Step 4. If all verification steps succeed, the Receiver computes the parameter $R^{\prime }$ required for decryption. Using the generated $R^{\prime }$ and ${c^R}_7$, the value ${\sigma }^{\prime }$ is derived. Then, ${\sigma }^{\prime }$ and ${c^R}_6$ are used to compute $g^s$, while ${\sigma }^{\prime }$ and $R^{\prime }$ are used to compute r. Finally, the derived r together with ${c^R}_8$ is used to recover the plaintext message $M_j$.

  $$R^{\prime }={c^R}_4·{\displaystyle \frac{e(K_{S_B},g^{\alpha })·e(K_{S_B}·s{k}_{i{d}_2},{\prod }_{b\in S_B,b\ne j}{g}_{n+1-b+j},{c^R}_2)}{e({c^R}_3,g^{\alpha })·e(K_{S_B},g^r)·e\left({\prod }_{b\in S_B}{g}_{n+1-b+j},{c^R}_2\right)}}$$

  (19)

  $$R={c^R}_1·{\left(e(K_{S_B},g_1)·e(g^s,{c^R}_5)\right)}^{-1}$$

  (20)

  $$M_j=({c^R}_8\oplus H_1\left(R\right))$$

  (21)

The detailed scenario encompassing all phases of the proposed scheme is illustrated in Figure 2.

4. Analysis of the Proposed Scheme

In this section, we analyze the security of the proposed scheme with respect to the requirements presented in Section 2 and provide a comparative analysis of the computational costs compared with existing schemes.

4.1. Analysis of Security Requirements

• Aggregate Key Confidentiality Preservation: The proposed scheme enforces aggregate key confidentiality by employing fresh, independent randomness in each aggregate-key generation. Consequently, even if an adversary obtains aggregate keys corresponding to multiple data classes, it is computationally infeasible—under the underlying cryptographic hardness assumptions—to derive a valid aggregate key for a distinct data class by performing algebraic operations on the collected keys.

  $$K_{S_B}=\prod _{b\in S_B}{\left(g_{n+1-b}\right)}^r$$

  (22)
  Here, r is $r=H_4({\sigma }^{\prime },R^{\prime })$, where ${\sigma }^{\prime }\stackrel{R}{\leftarrow }{\{0,1\}}^{\lambda }$ and $R^{\prime }\stackrel{R}{\leftarrow }{\mathbb{G}}_2$.
  Therefore, the aggregate key produced in each generation is different even if it is shares the same class.
  If an adversary collects two aggregate keys $(K_{S_{B1}},K_{S_{B2}})$ for $(S_{B1}=\left\{1\right\},S_{B2}=\{1,2\})$ that share the same data class $\left\{2\right\}$, and attempts to generate a new $K_{S_B}^{\prime }$, it cannot be correctly generated as follows.
  The adversary, possessing two aggregate keys that share the same data class $\left\{2\right\}$, performs the following operation.

  $$K_{S_B}^{\prime }\leftarrow K_{S_{B2}}/K_{S_{B1}}$$

  (23)
  Here, $(K_{S_{B2}},K_{S_{B1}})$ are constructed as follows.

  $$K_{S_{B2}}={(g_n·g_{n-1})}^{r_1}$$

  (24)

  $$K_{S_{B1}}={\left(g_n\right)}^{r_2}$$

  (25)
  Here, $r_1$ and $r_2$ are different values created in different sessions, so step (23) is not possible.
• Resistance Against Ciphertext-Based Attack: Resistance Against Ciphertext-Based Attack is divided into two types:

  (a)

  Resistance Against Ciphertext Injection Attack: Before decrypting ciphertexts and re-encrypted ciphertexts, the Receiver verifies the integrity of the data using the values contained in the ciphertext and the public parameters, as in (10)–(12). The proof proceeds as follows.

  $$e(c_1,H_5\left({Aid}_i\right)g_{n-1})\stackrel{?}{=}e(g,c_2)$$

  (26)

  $$e(c_1,c_4)\stackrel{?}{=}e(g,c_5)$$

  (27)

  $$e(c_1,H_3(c_1,c_2,c_3,c_5,c_6,c_7))\stackrel{?}{=}e(g,c_8)$$

  (28)

  Using (26), the integrity of $c_1=g^t$ and $c_2={(H_5\left({Aid}_i\right)·g_{n-1})}^t$ is verified. Thereafter, via (27), the integrity of $c_4={\left(H_5\left({Aid}_i\right)\right)}^t$ and $c_5={\left(c_4\right)}^t$ is checked. Finally, using (28), the integrity of $c_3=R·e{(g,g_n)}^t,c_5={\left(c_4\right)}^t,c_6=M_j\oplus H_1\left(R\right),c_7=H_5{\left({\sigma }_{id}\right)}^t$ is verified. If the integrity checks succeed, then the ciphertext components $(c_1,c_2,c_3,c_4,c_5,c_6,c_7,c_8)$ can be confirmed as untampered.

  (b)

  Robustness Against Ciphertext Regeneration Attack: Since ciphertexts share an identical structure, if an adversary freshly generates a message $M_j^{\prime }\in {\{0,1\}}^{\lambda }$ and the randomness used to form the ciphertext structure, i.e., $t^{\prime }=H_4(M_j^{\prime },R^{\prime })$ with $R^{\prime }\stackrel{R}{\leftarrow }{\mathbb{G}}_2$, then the adversary may construct a new ciphertext that can pass the integrity verification steps (26)–(28). The proposed scheme, however, performs a check—specifically, step (8) of Section 3.4.6—that verifies whether the Sender is an entity issued a valid identity by the TTP prior to performing the integrity verification. The proof proceeds as follows.

  $$e(H_5\left({\sigma }_{id}\right),c_1)\stackrel{?}{=}e(c_7,g)$$

  (29)

  Here, ${\sigma }_{id}$ is ${\sigma }_{id}=H_6({Aid}_i\parallel i{d}_i\parallel mr\parallel ts)$, and it includes the Sender’s pseudonymous ID ${Aid}_i$, the real ID $i{d}_i$, the verification secret $mr$ randomly generated by the TTP, and the timestamp $ts$ indicating the expiration time.

  Therefore, even if an adversary constructs a new ciphertext, they cannot compute ${\sigma }_{id}$ for $c_7=H_5{\left({\sigma }_{id}\right)}^t.$ Furthermore, since $H_5\left({\sigma }_{id}\right)$ in step (30) can only be generated by the TTP, even if an adversary freshly generates all randomness to form a ciphertext, verification of the $c_7$ value which contains the TTP’s secret parameters will be infeasible, thus maintaining security.

  Even if a malicious Proxy colludes with a Receiver and both possess the re-encryption key $r{k}_{{Aid}_s\to {Aid}_r}$, the private key $s{k}_{i{d}_r}$, and the re-encrypted ciphertext $C_R$, they cannot reconstruct the Sender’s secret key or any valid aggregate key because the re-encryption key binds both pseudonymous identifiers and session-specific randomness $r=H_4({\sigma }^{\prime },R^{\prime })$.
  Specifically, ${Aid}_s\to {Aid}_r$ is computed using ${\sigma }^{\prime }$ and $R^{\prime }$ unique to each session, and the pairing checks in Equations (10)–(12) enforce binding to the TTP-issued identity ${\sigma }_{id}$. Thus, even joint knowledge does not allow key inversion or unauthorized re-encryption, ensuring resilience against collusion.
• Metadata Confidentiality and Leakage Prevention: The Proxy Server generates the re-encrypted ciphertext with the following inputs, as in Section 3.4.6: $(params,r{k}_{{Aid}_1\to {Aid}_2},C,{Aid}_i,K_{S_B})$. Here, $params$ denotes publicly released parameters; $r{k}_{{Aid}_1\to {Aid}_2}$ denotes the re-encryption key generated by the Sender and transmitted to the Proxy Server; C denotes the initial ciphertext stored by the Proxy Server; ${Aid}_i$ denotes the pseudonymous identity; $K_{S_B}$ denotes the aggregate key for the data class; and $\tau$ denotes the verification value for the aggregate key. All inputs received by the Proxy Server are either public or already possessed by the Proxy Server. Therefore, no metadata pertaining to the Sender’s data is included.
• Anonymity for Data Management: Participants in the proposed scheme, except for the Proxy Server and the TTP, must have their anonymity preserved. To guarantee anonymity, participants transmit their real identity $i{d}_i$ to the TTP and obtain a pseudonymous identity ${Aid}_i$. The pseudonym ${Aid}_i$ is generated as follows.

  $${Aid}_i=H_2(i{d}_i\parallel mr)$$

  (30)
  The TTP generates ${Aid}_i$ using the real identity $i{d}_i$ and the verification secret $mr$. By the security of the hash function, the real identity $i{d}_i$ is securely concealed. In this manner, while guaranteeing participants’ anonymity, when it is necessary to identify anonymity in cases such as regeneration or replay attacks, a mechanism to verify the Sender’s legitimacy must be provided. To this end, the ID verification value ${\sigma }_{id}$ is generated. ${\sigma }_{id}$ is generated as follows.

  $${\sigma }_{id}=H_6({Aid}_i\parallel i{d}_i\parallel mr\parallel ts)$$

  (31)
  Upon an ID verification request, the TTP computes ${\sigma }_{id}$ and executes the check in (31). If (31) is satisfied, the TTP can verify the legitimacy of the Sender.
  To formally define the achieved anonymity, we consider an indistinguishability game between a challenger $\mathcal{C}$ and a probabilistic polynomial-time adversary $\mathcal{A}$ as follows. $\mathcal{A}$ adaptively issues pseudonym queries and submits two distinct identities $(i{d}_0,i{d}_1)$ to $\mathcal{C}$. The challenger randomly selects $b\in \{0,1\}$, computes ${Aid}_b=H_2(i{d}_b\Vert m{r}_t)$ using freshly generated randomness $m{r}_t$, and returns it to $\mathcal{A}$. The scheme preserves anonymity if $\mathcal{A}$ cannot distinguish whether the returned pseudonym corresponds to $i{d}_0$ or $i{d}_1$ with non-negligible advantage.
  Similarly, unlinkability is defined such that, given two pseudonyms ${Aid}_{id}^{\left(t_1\right)}$ and ${Aid}_{id}^{\left(t_2\right)}$ generated in different sessions, no polynomial-time adversary can determine whether they correspond to the same entity under independent random values $m{r}_{t_1}$ and $m{r}_{t_2}$. Since each pseudonym is refreshed per session with independent randomness, long-term behavioral correlation across multiple sessions remains computationally infeasible.

4.2. Comparison of Schemes

In this Subsection, we analyze whether the attack models presented in Section 2.2 (see

Table 3. Comparison of Proposed Scheme with Related Works.

	Kajita & Ohtake	Pareek & Purushothama	Chen et al.	Proposed Scheme
Aggregate Key Leakage (${\mathcal{A}}_1$)	✓	×	×	✓
Ciphertext Injection (${\mathcal{A}}_2$)	✓	✓	✓	✓
Ciphertext Regeneration (${\mathcal{A}}_3$)	×	×	×	✓
Metadata Leakage (${\mathcal{A}}_4$)	✓	×	×	✓
Unlinkability and Anonymity Violation (${\mathcal{A}}_5$)	×	-	-	✓

✓: Provided. ×: Not provided. -: Not considered.

) can be prevented by the conventional KA-ABE and by the proposed scheme, and we compare the proposed scheme with the conventional KP-ABE scheme as summarized in

Table 4. Comparison of computation output sizes of related works.

	MSK	Aggregate Key Size	Ciphertext Size	Re-Key Size
Kajita & Ohtake	$|{\mathbb{Z}}_p|$	$|{\mathbb{G}}_1|$	$5|{\mathbb{G}}_1|+|{\mathbb{G}}_2|+l$	$5|{\mathbb{G}}_1|+|{\mathbb{G}}_2|+l$
Pareek & Purushothama	$2|{\mathbb{Z}}_p|$	$|{\mathbb{G}}_1|$	$4|{\mathbb{G}}_1|+3|{\mathbb{G}}_2|+l$	$5|{\mathbb{G}}_1|+|{\mathbb{G}}_2|+l$
Chen et al.	$3|{\mathbb{Z}}_p|$	$|{\mathbb{G}}_1|$	$|{\mathbb{Z}}_p|+7|{\mathbb{G}}_1|+|{\mathbb{G}}_2|+l$	$2|{\mathbb{G}}_1|$
Proposed Scheme	$|{\mathbb{Z}}_p|$	$|{\mathbb{G}}_1|$	$6|{\mathbb{G}}_1|+|{\mathbb{G}}_2|+l$	$5|{\mathbb{G}}_1|+|{\mathbb{G}}_2|+l$

$l,|{\mathbb{Z}}_p|,|{\mathbb{G}}_1|,|{\mathbb{G}}_2|$: the plaintext message length, the cardinality of ${\mathbb{Z}}_p$, the order of the bilinear group ${\mathbb{G}}_1$, and the order of the other bilinear group ${\mathbb{G}}_2$.

and

Table 5. Comparison of computation costs of related works.

	Key-Gen Cost	Encryption Cost	Aggregate KeyGen Cost	Re-KeyGen Cost	Re-Encryption Cost	Decryption Cost
Kajita & Ohtake	$t_e$	$5t_e+t_{bp}$	$n{t}_e$	$7t_e+t_{bp}$	$2t_{bp}$	$\left|S\right|t_e+n{t}_{bp}$
Pareek & Purushothama	$2t_e$	$3t_e+t_{bp}$	$n{t}_e$	$3t_m+6t_e$	$(2+2|S_A\left|\right)t_m+2t_{bp}$	$(4+2|S\left|\right)t_m+2t_{bp}$
Chen et al.	$t_e$	$7t_e+t_{bp}$	$n{t}_e$	$6t_e+t_{bp}$	$3t_{bp}$	$4t_{bp}$
Proposed Scheme	$t_e$	$7t_e+t_{bp}$	$n{t}_e$	$6t_e+t_{bp}$	$3t_{bp}$	$4t_{bp}$

$\left|S\right|,n$: the size of the aggregate set at decryption; g: the number of generators. $t_a,t_m,t_e,t_{bp},t_{mp}$: addition/multiplication operations, modular multiplication, modular exponentiation, bilinear pairing, and multilinear pairing.

. (Table 5 excludes operations, such as hashing, that have little impact on the overall computational cost.)

• Aggregate Key Confidentiality Preservation: Pareek & Purushothama and Chen et al. generate aggregate keys as follows.

  $$K_{S_B}=\prod _{b\in S_B}{\left(g_{n+1-b}\right)}^{{\gamma }_1}$$

  (32)
  Here, ${\gamma }_1$ is a component of the master secret key that, once generated, does not change. If multiple aggregate keys are generated using such a ${\gamma }_1$, then all aggregate keys are derived from the pre-generated master secret key; consequently, if aggregate keys are collected or leaked to adversaries, the adversary can also generate aggregate keys for other data classes.

  $$K_{S_B}^{\prime }\leftarrow K_{S_{B2}}/K_{S_{B1}}$$

  (33)
  The proposed scheme prevents aggregate-key exposure by generating the aggregate key in the Aggregate KeyGen Phase based on a one-time random value $r=H_4({\sigma }^{\prime },R^{\prime })$ that is used only once per session. In addition, the verification value $\tau =H_2({Aid}_i,S_B,v)$ is used to bind the key to the corresponding session. This eliminates correlations among aggregate-key values across sessions, thereby preventing an adversary from deriving or estimating keys.
• Resistance Against Ciphertext-Based Attack: Resistance Against Ciphertext-Based Attack is divided into the following two categories.

  (a)

  Resistance Against Ciphertext Injection Attack: To mitigate ciphertext injection attacks, all compared schemes perform ciphertext integrity verification prior to decryption.

  $$e(c_1,H_5\left({Aid}_i\right)g_{n-1})\stackrel{?}{=}e(g,c_2)$$

  (34)

  $$e(c_1,c_4)\stackrel{?}{=}e(g,c_5)$$

  (35)

  $$e(c_1,H_3(c_1,c_2,c_3,c_5,c_6,c_7))\stackrel{?}{=}e(g,c_8)$$

  (36)

  By performing integrity verification on the ciphertext components $(c_1,c_2,c_3,c_4,c_5,c_6,c_7,c_8)$, ciphertext-injection attacks are prevented.

  (b)

  Robustness Against Ciphertext Regeneration Attack: Existing schemes employ a uniform ciphertext structure; consequently, an adversary can freshly generate a message $M_j^{\prime }\in {\{0,1\}}^{\lambda }$ and the randomness used to form the ciphertext structure, i.e., $t^{\prime }=H_4(M_j^{\prime },R^{\prime })$ with $R^{\prime }\stackrel{R}{\leftarrow }{\mathbb{G}}_2$, to construct a new ciphertext that the adversary stores on the Proxy Server or, after exfiltration, retransmits to the Receiver. In such cases, the Receiver is unable to determine that the message was generated by an adversary. To prevent ciphertext-regeneration attacks, this work requires the TTP to generate an ID-verification value ${\sigma }_{id}$ during the KeyGen Phase that certifies legitimate ID issuers. The value ${\sigma }_{id}$ is generated after the Sender submits the real identity $i{d}_i$ to the TTP; only a legitimate Sender transmits $i{d}_i$ and obtains a pseudonymous identity and secret key while ${\sigma }_{id}$ is produced. Because ${\sigma }_{id}$ is generated using the random value $mr$ chosen by the TTP, ${\sigma }_{id}$ can be generated only by the TTP. Furthermore, by embedding an expiration timestamp $ts$, the validity period of ${\sigma }_{id}$ is defined so that reuse of ${\sigma }_{id}$ after expiration can be detected. By requesting verification of ${\sigma }_{id}$ from the TTP prior to protocol execution, one can prove based on the verification outcome—that the ciphertext was generated by a legitimate Sender. In this way, it is possible to demonstrate that the Sender is authorized by the TTP.

• Metadata Confidentiality and Leakage Prevention: The schemes of Pareek & Purushothama and of Chen et al. directly transmit the data-class metadata value $S_B$ to the Proxy Server during the transmission of the re-encryption key in the Re-Encrypt Phase. When the data-class value $S_B$ is revealed in this manner, the Proxy Server can infer the class membership of specific data and, by analyzing Sender-specific access patterns, perform preparatory actions for targeted attacks.
  To prevent this, the proposed scheme transmits the aggregate key $K_{S_B}$ to the Proxy Server instead of the original data-class value $S_B$. The aggregate key is computed as $K_{S_B}={\prod }_{b\in S_B}{\left(g_{n+1-b}\right)}^r$, and therefore does not permit identification of $S_B$. Hence, the original data-class value $S_B$ remains unknown to the Proxy Server.
• Anonymity for Data Management: Kajita & Ohtake employ standard ID-based PRE. Pareek & Purushothama and Chen et al. employ standard public-key-based PRE. If plain IDs with no additional measures are used, as in Kajita & Ohtake, participants’ identities may be directly exposed. Pareek & Purushothama and Chen et al. encrypt using the Sender’s public key and a data-class identifier. In this case, one can directly trace which Sender a particular class belongs to via the public key. This issue, combined with the metadata-exposure problem described above, allows the inference of metadata for data sent to specific targets and may serve as the starting point for secondary attacks.
  To prevent this, the proposed scheme issues pseudonymous IDs to participants based on their real IDs via the TTP. The pseudonymous ID is generated by the TTP as ${Aid}_i=H_2(i{d}_i\parallel mr)$. The value $mr$ is a random value generated by the TTP for ID issuance, and only the TTP knows the holder of the real ID. However, guaranteeing anonymity in this manner can be abused; to address this, the proposed scheme generates a pseudonym verification value ${\sigma }_{id}=H_6({Aid}_i\parallel i{d}_i\parallel mr\parallel ts)$. The value ${\sigma }_{id}$ includes the random nonce generated by the TTP and a timestamp $ts$ specifying the expiration time.

The proposed scheme exhibits no significant difference from existing schemes in terms of the sizes of generated values and computational costs. However, the addition of the verification-value generation and verification steps introduces two hash evaluations and one exponentiation; this, nonetheless, does not materially affect the overall computational overhead. As illustrated in Figure 3, the execution times were derived from a benchmark simulation reflecting realistic hardware conditions, where each primitive operation ($t_e$, $t+m$, $t_{b}p$) was assigned latency values measured from practical server and client environments. Each algorithmic phase (KeyGen, Encryption, Aggregate KeyGen, Re-KeyGen, Re-Encryption, and Decryption) was executed 30 times with ±5% stochastic jitter to emulate runtime variability. The parameters were configured as $\left|S\right|=10$ (the size of the aggregate set at decryption) and $n=5$ (the number of generators used in key aggregation). The results confirm that the proposed scheme achieves nearly identical performance to Chen et al. across all phases, indicating that the added verification procedures introduce only negligible additional computational cost.

5. Conclusions

This paper analyzed security weaknesses in Key-Aggregate Proxy Re-Encryption (KA-PRE) architectures employed in remote data-management environments and proposed an improved model to mitigate these weaknesses. Although conventional KA-PRE schemes were originally introduced to enable secure data sharing by providing efficient key management and flexible privilege delegation, our analysis demonstrates that they remain susceptible to multiple attack models, including the Aggregate Key Leakage Attack $\left({\mathcal{A}}_1\right)$, Ciphertext Injection Attack $\left({\mathcal{A}}_2\right)$, Ciphertext Regeneration Attack $\left({\mathcal{A}}_3\right)$ and $\left({\mathcal{A}}_4\right)$, and the Unlinkability and Anonymity Violation Attack $\left({\mathcal{A}}_5\right)$.

In response to these findings, we specified five core security requirements and proposed a novel KA-PRE construction that meets these requirements. The proposed scheme mitigates the identified vulnerabilities by integrating pseudonymous ID-based authentication, introducing additional verification procedures, and minimizing the parameters transmitted to the Proxy Server.

Through the experimental evaluation presented in Section 4, we confirmed that the proposed scheme significantly reduces computational and communication overhead compared to conventional KA-PRE approaches, while maintaining strong confidentiality and integrity guarantees.

The benchmark results, as illustrated in Figure 3, demonstrate the practicality of our construction under a real server–client environment, verifying that the additional verification steps do not impose excessive performance costs.

We contend that the proposed construction is applicable across diverse domains that demand secure data sharing and fine-grained access control—such as cloud platforms and Personal Data Stores (PDSs). In particular, the scheme is relevant to settings handling highly sensitive information (e.g., financial services, healthcare, and public-sector data), where strong confidentiality and privacy guarantees are essential.

Nevertheless, this work has several limitations. First, although the security properties of the proposed scheme are supported by formal analysis and proofs, empirical evaluation of performance and system overhead in realistic distributed deployments is still lacking. Second, further study is required to address collusion among multiple Receivers and to improve scalability in group settings. Third, the scheme’s resilience against a broader spectrum of cryptographic attack scenarios remains to be explored.

For future work, we plan to, first, conduct experimental evaluations of the scheme in real cloud and PDS environments to quantify performance and operational overhead, second, design scalable extensions that accommodate multi-user and group contexts—including mechanisms to mitigate collusion—and, third, integrate complementary cryptographic primitives to achieve strong anonymity together with conditional traceability. These directions will aim to enhance both the practicality and the security guarantees of the proposed KA-PRE construction.