A Hierarchical Key Management Scheme for Efficient Outsourced Computation in Cloud Storage Services

Abstract

This study addresses the high computational overhead associated with updating encryption keys and authentication information by delegating these tasks to cloud storage services. This approach reduces the burden on data owners and facilitates the establishment of a robust cloud storage ecosystem. Our evaluation focuses on three critical performance metrics for cloud security mechanisms: 1. Computational Complexity: The processing time and frequency required for encryption, decryption, and verification. 2. Communication Complexity: The volume and length of message exchanges. 3. Storage Overhead: The space required to maintain a comprehensive cloud storage system. We propose a hierarchical key management scheme that enables data owners to update file encryption keys efficiently without impacting other users within the Cloud Storage Service (CSS) environment. By eliminating the need for owners to store all keys in a hierarchical tree, our scheme minimizes the computational cost of key updates. Ultimately, this approach enhances efficiency for both data owners and receivers, making it particularly suitable for resource-constrained mobile devices.

1. Introduction

Recently, cloud computing has emerged as a pivotal paradigm in science and technology, with numerous providers launching diverse cloud-based solutions [1,2], such as Amazon EC2/S3 [3] and Microsoft Azure. Among these, cloud storage services (CSS) are the most widely adopted by general users, exemplified by platforms like Dropbox, SkyDrive, Amazon S3, and Google Drive [4]. Driven by the principles of on-demand network access and ubiquitous availability, mobile devices—particularly smartphones and tablets—have become indispensable tools for accessing these services. Consequently, providers have increasingly released dedicated mobile client applications to enhance user convenience. However, these mobile platforms often prioritize accessibility over robust security mechanisms. Even when security is implemented, the associated computational and storage overhead must remain minimal due to the inherent constraints of mobile devices, such as limited processing power, bandwidth, and battery life. Therefore, the development of lightweight security protocols has become a critical research imperative [5,6].

The primary objectives of cloud storage services are twofold: to enable ubiquitous file access and to facilitate secure data sharing among authorized users. Consequently, implementing efficient access control remains a critical security challenge within the cloud storage domain [7]. Current research generally categorizes access control mechanisms into three primary types: Access Control Lists (ACL), Attribute-Based Access Control (ABAC), and File Groups.

• Access Control Lists (ACL): A file-centric approach where each data object maintains a record of users authorized for access [8].
• Attribute-Based Access Control (ABAC): A method that defines access permissions based on a diverse set of users and system attributes [3,9].
• File Groups: A structure where a directory is created for a specific group of authorized users, and all files within that directory inherit the group’s access permissions.

Although ABAC provides superior fine-grained control, its inherent computational and storage overhead often exceeds the limited capabilities of mobile devices. To solve the problem, we proposed a scheme by integrating file groups with access right lists [10]. This hybrid approach offers enhanced efficiency while significantly reducing the computational and storage demands on the user.

Within the context of cloud storage services, the most fundamental approach to ensuring data confidentiality is to encrypt files locally prior to cloud transmission. However, this strategy becomes inefficient when files are shared across a diverse user base, particularly during the revocation of user access rights [5,11]. To address this, Hwang and Sun [10] proposed an optimized scheme that enables data owners to manage multi-user access. This mechanism allows each user to access all authorized files using a single key, while the data owner manages access control through a hierarchical shared-key tree and periodic key renewal messages.

Despite these improvements, the scheme relies heavily on symmetric encryption and decryption operations, resulting in substantial computational overhead for resource-constrained mobile devices. Furthermore, the following limitations persist [12]:

• Storage Overhead for Data Owners: The data owner is required to maintain all keys within the hierarchical tree structure, leading to increased storage complexity.
• Scalability of Key Renewal Costs: The computational cost associated with processing renewed key messages is significant for both data owners and users. Since the scheme employs symmetric encryption, the frequency of decryption operations increases linearly with the depth and complexity of the key tree, further straining device resources.

To address the aforementioned limitations, this paper proposes an enhanced, high-efficiency scheme tailored for mobile device users. In alignment with established security standards for cloud storage services [4], our proposed framework fulfills the following critical requirements:

• Data Confidentiality: To prevent unauthorized access or data leakage from malicious cloud service providers and external attackers, an efficient encryption and decryption mechanism is essential to ensure the integrity and privacy of data stored in the cloud.
• Access Control: The cloud infrastructure must rigorously validate all download requests to ensure that only users with verified access rights can retrieve specific data objects.
• Efficient Authorization and Revocation: The data owner must be able to manage user registration and revocation seamlessly. Notably, the revocation process should be executed without necessitating updates or affecting the access privileges of the remaining authorized users.
• Streamlined Key Management: Minimizing the administrative burden on the data owner is a primary objective. The data owner should be able to manage all files and authorized users with a minimal set of cryptographic keys. Furthermore, each authorized user should be able to access all permitted files using a single, unified secret key.
• Lightweight Computation: To accommodate the limited resources of mobile platforms, the scheme must minimize the computational overhead for both data owners and users during all system operations.

Recent privacy-preserving cloud architectures increasingly employ layered protection mechanisms to mitigate unauthorized access, metadata leakage, and information exposure in semi-trusted distributed environments. In such architectures, over-encryption mechanisms are commonly adopted to provide additional confidentiality isolation between data owners, cloud service providers, and authorized users.

Unlike conventional single-layer encryption frameworks, privacy-preserving architectures often combine encryption, re-key management, access-control enforcement, and secure key-distribution mechanisms to reduce the risks associated with outsourced cloud storage and multi-user data sharing.

Motivated by these privacy-preserving design principles, the proposed scheme adopts a lightweight hierarchical over-encryption framework integrating sign-then-encrypt protection, hierarchical re-key derivation, and user-specific secret-key isolation. This design enables efficient access control and confidentiality preservation while maintaining low computational overhead for mobile and lightweight cloud environments.

The organization of the paper is as follows: In the next section, we give security assumptions, present the notation, and describe our scheme. In Section 3, the security analysis and performance evaluation are discussed. Section 4 presents our contributions, drawbacks, and conclusion of the presented scheme.

2. The Proposed Key Management Scheme

This section outlines the system assumptions and the notations employed in the proposed scheme. A comprehensive description of the operational phases and detailed steps is provided in Section 2.3.

2.1. System Assumptions

The design of the proposed scheme is predicated on the following assumptions and operational constraints:

• Semi-trusted (Honest-but-Curious) Cloud Infrastructure: The Cloud Storage Service (CSS) provider is modeled as a semi-trusted (honest-but-curious) entity. Specifically, the CSS is assumed to correctly execute protocol operations, maintain storage availability, and enforce access-control procedures, while potentially attempting to infer sensitive information from stored ciphertexts, re-key materials, and access patterns [13].
  The proposed scheme therefore protects data confidentiality against curious cloud providers and unauthorized users without assuming full trust in the CSS infrastructure.
  We additionally consider a limited collusion scenario between the CSS and revoked users. In this setting, revoked users may cooperate with the CSS to obtain historical ciphertexts, stored re-key messages, or access-control metadata. However, after revocation, the Data Owner regenerates updated hierarchical path keys and renewed file encryption keys while excluding the revoked users’ secret keys from the newly generated re-key messages. Consequently, the system must ensure that unauthorized entities, including the CSS provider itself, cannot access the plaintext of files stored in the cloud. The revoked users cannot derive updated file encryption keys for future ciphertext versions even if the CSS shares previously stored cryptographic materials.
  It should be noted that the proposed scheme primarily targets semi-trusted cloud environments rather than fully malicious cloud infrastructures. Therefore, the current framework does not attempt to defend against adversarial CSS behaviors such as arbitrary protocol deviation, forged re-key material injection, unauthorized ciphertext modification, or deliberate access-control bypass attacks.
  Defending against fully malicious cloud providers would require additional mechanisms such as verifiable auditing, trusted execution environments, blockchain-assisted verification, or formally verified access-control protocols, which are beyond the scope of the present lightweight key-management design.
• Service Availability and Connectivity: The CSS provider is required to maintain constant online availability. Conversely, data owners and authorized users are only expected to be online during active file operations or data retrieval [14].
• System Scalability and Efficiency: The proposed tree-based architecture achieves maximum efficiency in scenarios where a high volume of users shares access to a relatively smaller set of files [10]. Under these conditions, the benefits of minimized key storage and management overhead are most pronounced.
• Public Key Infrastructure (PKI): We assume the existence of a trusted Certificate Authority (CA) responsible for issuing and managing cryptographic key pairs. Each entity—including the data owner, CSS provider, and all users—possesses a valid public key pair, ensuring secure key distribution and identity verification across the system.
• Adversary Model and Threat Assumptions: The proposed scheme considers the following adversarial entities and attack scenarios:

  (a)

  Honest-but-Curious CSS: The Cloud Storage Service (CSS) correctly executes storage and transmission protocols but may attempt to infer sensitive information from stored ciphertexts, access right lists, or re-key messages. However, the CSS does not possess users’ private keys or secret keys.

  (b)

  External Eavesdropper: An external attacker may intercept communication messages transmitted over public channels. The attacker is assumed to have full access to transmitted ciphertexts but cannot break standard asymmetric or symmetric cryptographic primitives.

  (c)

  Malicious User: An unauthorized or malicious user may attempt to access files beyond their granted privileges by exploiting intercepted re-key messages or previously obtained credentials.

  (d)

  Revoked User: A revoked user may retain previously issued secret keys and historical re-key messages and attempt to derive updated file encryption keys after revocation.

  (e)

  Collusion Attack: We additionally consider limited collusion scenarios between a revoked user and the honest-but-curious CSS. The adversary may combine previously stored re-key materials and encrypted files to recover updated file keys. However, since updated re-key messages are generated using renewed path keys and exclude the revoked user’s secret key, the colluding parties cannot derive valid updated encryption keys.

• The proposed scheme assumes standard cryptographic hardness assumptions for hash functions, symmetric encryption, and public-key encryption mechanisms.

2.2. Cryptographic Primitives

The proposed scheme employs the Elliptic Curve Integrated Encryption Scheme (ECIES) for asymmetric encryption and the Elliptic Curve Digital Signature Algorithm (ECDSA) for message authentication and integrity verification. ECIES is adopted to provide confidentiality for transmitted messages, while ECDSA ensures authenticity and non-repudiation between communicating entities. Both cryptographic primitives are selected due to their lightweight computational characteristics and suitability for resource-constrained mobile cloud environments.

In this work, the term “over-encryption” refers to a layered protection mechanism combining digital signatures and public-key encryption. Specifically, the sender first signs the message to provide authenticity and integrity protection and subsequently encrypts the signed message using the recipient’s public key to ensure confidentiality over insecure communication channels.

2.3. Notation

The cryptographic notations and symbols employed throughout the proposed scheme are summarized in

Table 1. Notation table.

Notation	Significance
$P{U}_X$	Public key of person X.
$P{V}_X$	Private key of person X.
$K_O$	Data Owner’s secret key.
$K_U$	User’s secret key.
$ARL$	Access Right List of all authorized users.
$FL$	File list.
$UID$	User’s ID.
n	The number of files the data owner has.
s	The number of authorized users.
k	The number of file groups.
m	The number of internal key of file group.
$FI{D}_i$	File ID, $i=1,...,n$.
$c_{F_i}$	The re-key counter of $F_i$.
$K_{F_i}$	File encryption key of file i, $i=1,...,n$.
$K_{r_i}$	Root key of the file group i, $i=1,...,k$.
$K_{t_i}$	Internal key of the file group i, $i=1,...,m$.
$EK$	Asymmetric encryption function.
$DK$	Asymmetric decryption function.
$h(·)$	A one-way hash function.
⨁	An exclusive or operator.
T	System time stamp.
$Sig{n}_{P{V}_X}\left(M\right)$	Digital signature on message M using the private key of entity X.
$Verif{y}_{P{U}_X}(M,\sigma )$	Signature verification using the public key of entity X.
$En{c}_{P{U}_X}\left(M\right)$	Public-key encryption using the public key of entity X.
$De{c}_{P{V}_X}\left(C\right)$	Public-key decryption using the private key of entity X.
$\sigma$	Digital signature value.

. The asymmetric key pair for any entity is denoted as $(P{U}_X,P{V}_X)$, where $P{U}_X$ and $P{V}_X$ represent the public and private keys, respectively. Specifically, these refer to the data owner ($P{U}_O,P{V}_O$), the cloud server ($P{U}_C,P{V}_C$), and the authorized user ($P{U}_U,P{V}_U$) within the system. To manage data security, the data owner maintains a master secret key, $K_O$, which is utilized to derive individual file encryption keys, $K_{F_i}$. Similarly, each authorized user is assigned a personal secret key, $K_U$, enabling the derivation of file encryption keys for which they have been granted access. Additionally, $c_{F_i}$ denotes a cryptographic counter associated with each file. This counter is incremented by one upon each key update, serving as a versioning index for the generation of the most recent file encryption key.

2.4. The Proposed Scheme

The proposed scheme builds upon the framework introduced in [10], with the primary objective of mitigating computational overhead for both data owners and authorized users, while simultaneously reducing the storage requirements for data owners. The overall system architecture is illustrated in Figure 1, comprising three principal entities: the Data Owner (DO), the Cloud Storage Service (CSS) provider, and the authorized user.

• Data Owner (DO): An entity, such as an enterprise or an individual, that maintains a large repository of data and seeks to share these resources with authorized parties.
• Cloud Storage Service (CSS): A provider that facilitates data persistence, provides fundamental access control mechanisms, and ensures the security of stored files.
• Authorized User: A participant who subscribes to or prepays for access to specific files owned by the DO and retrieves them through the CSS infrastructure.

During the initial configuration, the DO establishes a hierarchical tree structure to manage the access privileges of all users and encrypts each file independently prior to cloud transmission. Subsequently, authorized users obtain the necessary credentials from the DO to download and decrypt files from the CSS. The operational flow of the proposed protocol is categorized into three distinct phases: the setup phase, the registration phase, and the download phase.

2.4.1. Setup Phase

In the setup phase, the Data Owner (DO) prepares the files for secure cloud storage and defines the access control policies for potential users. The workflow of this phase is illustrated in Figure 2.

1.

Key Generation and Initialization: The DO compiles a file list ($FL$) containing the file identifier ($FID$), file name, encryption key ($K_{F_i}$), and a renewal counter ($c_{F_i}$) for each data object. The DO then defines a master secret key $K_O$ and assigns a unique secret key $K_U$ to each user U. Each file encryption key $K_{F_i}$ is derived using a one-way hash function: $K_{F_i}=h(K_O\parallel FID\parallel c_{F_i})$.

2.

Hierarchical Access Tree Construction: The DO organizes access privileges using a shared-key tree structure, as depicted in Figure 3. The DO embeds the master key $K_O$ into all trees, while individual user keys $K_U$ are integrated into specific trees based on their granted access rights. For instance, if user $U_1$ is authorized only for file $F_1$, they are assigned to the first tree. Conversely, user $U_4$, with access to both $F_1$ and $F_2$, is placed in the second tree. Although users within the same tree share identical access levels, their unique secret keys $K_U$ facilitate targeted key updates, ensuring that re-keying operations do not disrupt the access of non-revoked users.

3.

Re-key Message Generation: To enable key retrieval, the DO computes re-key messages using XOR operations and hash functions. Specifically, the DO generates $R_O=K_{t_i}\oplus h\left(K_O\right)$ and $R_{U_i}=K_{t_i}\oplus h\left(K_{U_i}\right)$ for the owner and user $U_i$, respectively, allowing them to derive the internal tree key $K_{t_i}$. Subsequently, $R_{t_i}=K_{r_i}\oplus h\left(K_{t_i}\right)$ and $R_{r_i}=K_{F_i}\oplus h\left(K_{r_i}\right)$ are generated, providing authorized entities with the means to progressively decrypt and obtain the final file encryption key $K_{F_i}$.

4.

Data Outsourcing: Finally, the DO constructs an Access Right List ($ARL$) that maps user identifiers ($UID$) to their authorized encrypted files, denoted as $FI{D}_i\parallel E_{K_{F_i}}\left(F_i\right)$. The DO then transmits the $ARL$, the encrypted data objects, and the associated re-key messages to the CSS for storage.

2.4.2. Registration Phase

To access files owned by the DO, a new user must undergo the registration process to obtain the necessary authorization credentials. The workflow for this phase is depicted in Figure 4.

• Access Request and Verification: The user initiates the registration request by first generating a digital signature:

  $${\sigma }_U=Sig{n}_{P{V}_U}(UID,\left\{FID\right\},T),$$

  where $UID$ denotes a user identifier; $\left\{FID\right\}$ denotes a set of requested file identifiers; T denotes a timestamp used to prevent replay attacks.
  The user then encrypts the request message together with the signature using the Data Owner’s public key:

  $$En{c}_{P{U}_O}(UID,\left\{FID\right\},T,{\sigma }_U).$$
  Upon receiving the request, the Data Owner decrypts the ciphertext using its private key and verifies the authenticity of the request using the user’s public key $P{U}_U$.
  After successful verification, the Data Owner generates a unique secret key $K_U$ for the user and computes the associated re-key message:

  $$R_U=K_t\oplus h\left(K_U\right).$$
  The Data Owner subsequently distributes the authorization credentials securely to the user and the CSS provider.
• Credential Distribution: The DO securely distributes the credentials by transmitting $E_{P{U}_U}\left(E_{P{V}_O}(UID,K_U,T)\right)$ to the user and $E_{P{U}_C}\left(E_{P{V}_O}(FID,R_U)\right)$ to the CSS. This ensures that the user receives their private secret key while the CSS stores the re-key information necessary for file retrieval.

2.4.3. Download Phase

When an authorized user seeks to retrieve a file from the CSS, the download phase is initiated. The operational sequence for this phase is illustrated in Figure 5.

• File Request and Verification: When an authorized user requests a file from the CSS, the user first generates a signed request message:

  $${\sigma }_U=Sig{n}_{P{V}_U}(UID,FID,T),$$

  and transmits:

  $$En{c}_{P{U}_C}(UID,FID,T,{\sigma }_U).$$
  Upon receiving the request, the CSS validates the user’s access privileges by consulting the Access Right List ($ARL$). After verifying the user’s access privileges through the Access Right List (ARL), the CSS generates a digital signature:

  $${\sigma }_C=Sig{n}_{P{V}_C}(E{K}_{K_F}\left(F\right),R_U,R_t,R_r),$$

  and transmits the following encrypted response to the user:

  $$En{c}_{P{U}_U}(E{K}_{K_F}\left(F\right),R_U,R_t,R_r,{\sigma }_C).$$
  The authorized user decrypts the message using the private key $P{V}_U$ and verifies the signature using the CSS public key $P{U}_C$ to ensure message authenticity and integrity. This response comprises the encrypted file alongside the corresponding re-key messages necessary for decryption.
• Key Recovery and Decryption: Upon receipt, the user decrypts the outer layers of the message to retrieve the encrypted file and re-key parameters. Using their unique secret key $K_U$, the user derives the file encryption key $K_F$ through a sequential cryptographic unwrapping process:

  $$\begin{array}{ccc}\hfill K_t& =& R_U\oplus h\left(K_U\right);\hfill \\ \hfill K_r& =& R_t\oplus h\left(K_t\right);\hfill \\ \hfill K_F& =& R_r\oplus h\left(K_r\right).\hfill \end{array}$$
  If the user possesses the correct authorization and secret key, the file encryption key $K_F$ is successfully recovered. Finally, the encrypted file is decrypted using:

  $$F=D_{K_F}\left(E{K}_{K_F}\left(F\right)\right).$$

2.4.4. Revocation and Re-Key Procedure

When a user $U_r$ is revoked from the system, the Data Owner (DO) performs a localized re-key operation within the affected hierarchical shared-key tree. The revocation process only affects the cryptographic path from the revoked user’s leaf node to the corresponding tree root and associated file encryption keys.

Specifically, the DO regenerates the following cryptographic components:

• The internal tree keys along the affected path: $K_t^{new}$,
• The corresponding root key of the affected file group: $K_r^{new}$.
• The updated file encryption key for protected files: $K_F^{new}=h(K_O\parallel FID\parallel c_F^{new})$, where the file counter is incremented as: $c_F^{new}=c_F+1$. Subsequently, the DO generates updated re-key messages

  $$R_U^{new}=K_t^{new}\oplus h\left(K_U\right)$$

  $$R_t^{new}=K_r^{new}\oplus h\left(K_t^{new}\right)$$

  $$R_r^{new}=K_F^{new}\oplus h\left(K_r^{new}\right)$$

  for all non-revoked users within the affected group.

The revoked user’s secret key is excluded from the newly generated re-key messages. Therefore, even if the revoked user retains previously issued ciphertexts or historical re-key materials, the updated file encryption key cannot be derived.

The DO then securely transmits the updated re-key materials and newly encrypted file versions to the CSS. Remaining authorized users can derive the updated file encryption key using their existing personal secret key $K_U$, without requiring redistribution of new personal credentials.

The following is the revocation procedure for User $U_r$:

• Input: Revoked user $U_r$, affected file group $G_i$
• Step 1: Identify the hierarchical path from $U_r$ to the root node.
• Step 2: Regenerate all internal keys on the affected path:

  $$K_t^{new}$$
• Step 3: Regenerate the corresponding root key:

  $$K_r^{new}$$
• Step 4: Increment file counter:

  $$c_F\leftarrow c_F+1$$
• Step 5: Generate updated file encryption key:

  $$K_F^{new}=h(K_O\parallel FID\parallel c_F)$$
• Step 6: Generate updated re-key messages for remaining users:

  $$R_U^{new},R_t^{new},R_r^{new}$$
• Step 7: Upload updated ciphertexts and re-key materials to CSS.
• Output: Only non-revoked users can derive $K_F^{new}$.

3. Discussion and Analysis

Under the above adversary model, the proposed scheme satisfies the following security properties.

3.1. Security Analysis

Under the adversary model defined in Section 2.1, we evaluate whether the proposed scheme satisfies the required security properties for cloud storage services. Specifically, we consider honest-but-curious cloud servers, external eavesdroppers, malicious users, revoked users, and limited collusion attacks between revoked users and the CSS provider. In this section, we evaluate the proposed scheme against the security requirements established in Section 1. We demonstrate how our framework successfully satisfies the following five critical criteria for secure cloud storage services.

• Data Confidentiality under Semi-trusted Cloud Assumptions. Under the defined adversary model, an external eavesdropper or an honest-but-curious CSS may intercept encrypted files, re-key messages, or communication traffic. However, all files are encrypted using symmetric encryption before being outsourced to the cloud. Moreover, the re-key messages are protected through one-way hash functions and XOR operations, ensuring that adversaries without the corresponding secret keys cannot derive valid file encryption keys.

• Even if the CSS stores all ciphertexts and access-related information, it cannot recover the plaintext because it does not possess the users’ private keys or secret keys required for the hierarchical key derivation process.

• Under the defined adversary model, the CSS may store all encrypted files, access-right mappings, and historical re-key materials. However, since the CSS does not possess the legitimate user secret keys required for hierarchical key derivation, it cannot independently recover valid file encryption keys.

• Moreover, after user revocation, newly generated re-key materials exclude revoked users from the updated hierarchical key path. Therefore, even if the CSS colludes with revoked users, future file encryption keys remain computationally infeasible to derive under the assumed cryptographic primitives.

• Recent studies have further highlighted that privacy leakage in distributed and intelligent computing systems may arise not only from direct ciphertext exposure but also from model updates, shared outputs, metadata analysis, and indirect inference attacks [15]. In particular, cloud-assisted artificial intelligence environments introduce additional risks related to information leakage during data sharing, access synchronization, and update propagation.

• The proposed scheme mitigates these risks by enforcing hierarchical access control, lightweight re-key isolation, and user-specific key derivation mechanisms. Even if encrypted files and historical re-key materials are exposed through cloud storage infrastructures, unauthorized entities remain unable to derive valid file encryption keys without possessing the corresponding secret credentials.

• Access Control. The CSS provider enforces access control by verifying the user’s identity against the Access Right List (ARL). Upon successful authorization, the CSS encapsulates the encrypted file and relevant re-key messages within a layer of asymmetric encryption using the recipient’s public key. Since decryption requires the corresponding private key, only the intended authorized user can access the contents. Consequently, unauthorized entities are strictly prohibited from obtaining both the encrypted data and the necessary re-key parameters.

• The proposed scheme prevents malicious or unauthorized users from accessing files beyond their granted privileges. Before delivering encrypted files, the CSS verifies the requester against the Access Right List (ARL). Furthermore, the encrypted file and corresponding re-key messages are additionally protected using the recipient’s public key.

• Therefore, even if an attacker intercepts the transmitted messages, successful decryption still requires possession of the legitimate private key and the corresponding secret key $K_U$. Unauthorized users cannot derive the correct hierarchical keys needed to recover the file encryption key $K_F$.

• Efficient Authorization and Revocation. The Data Owner (DO) facilitates fine-grained authorization by assigning a unique secret key to each user. By utilizing the re-key message $R_U$, users can leverage their individual secret key $K_U$ to retrieve the file encryption key. In the event of user revocation, the DO simply updates the cryptographic path from the revoked user’s leaf node to the root, renewing $K_t,K_r,K_F$ and the associated re-key messages ($R_r,R_t,R_U$). By excluding the revoked user’s secret key from the newly generated $R_U$, revocation is achieved efficiently without necessitating updates for the remaining authorized users.

• The proposed scheme provides resistance against revoked-user attacks under the defined adversary model. When a user is revoked, the Data Owner updates the cryptographic path from the revoked leaf node to the root by renewing $K_t$, $K_r$, $K_F$, and the associated re-key messages. Because the newly generated re-key message $R_U$ no longer includes the revoked user’s secret key, previously revoked users cannot derive updated file encryption keys even if they retain historical re-key messages or previously downloaded ciphertexts. In addition, non-revoked users remain unaffected during the revocation process, thereby significantly reducing the communication and computational overhead associated with re-key distribution.

• The proposed revocation mechanism provides forward secrecy for future file versions. After revocation, newly updated ciphertexts are protected using refreshed file encryption keys derived from updated counters and renewed hierarchical path keys. Consequently, revoked users cannot access subsequently updated files.

• However, if revoked users have previously downloaded ciphertexts encrypted under older file keys, those historical ciphertexts may remain accessible. Therefore, the proposed scheme focuses on efficient forward secrecy rather than retroactive backward secrecy for previously obtained data.

• Key Management. The proposed scheme utilizes a hierarchical shared-key tree structure [16] to enable dynamic file encryption key updates while maintaining system stability. By embedding the DO’s master key $K_O$ into each shared-key tree, the proposed scheme reduces the need for the Data Owner (DO) to explicitly store all internal tree keys and root keys within the hierarchy. Instead, the DO can dynamically derive the required cryptographic keys when necessary. Both the DO and authorized users are required to store only a single secret key. From this single key, the DO can derive all necessary file encryption keys and tree nodes, significantly streamlining key management.

• Resistance to Limited Collusion Attacks. We additionally consider a limited collusion scenario between an honest-but-curious CSS and revoked users. Although the CSS may store encrypted files and historical re-key messages, the colluding parties still cannot derive valid updated file encryption keys because the renewed re-key messages are generated using updated path keys that exclude the revoked user’s secret key.

• Consequently, access to future encrypted files remains protected even if previously exposed ciphertexts and outdated re-key materials are shared among colluding adversaries.

• It should be noted that the storage complexity discussed in this work distinguishes between cryptographic key storage and system metadata storage. Specifically:
  • The File List (FL) stores file identifiers, counters, and associated metadata, resulting in a storage complexity proportional to the number of files: $O\left(n\right)$.
  • The Access Right List (ARL) maintains user authorization relationships, whose storage complexity depends on the number of authorized users and access mappings: $O\left(s\right)$. or higher in practical deployments.
  • The primary optimization achieved by the proposed scheme concerns hierarchical key material storage. Traditional hierarchical key management approaches often require explicit storage of internal tree keys and root keys for all groups. In contrast, the proposed scheme only requires the DO to maintain the master secret key: $K_O$ from which hierarchical keys can be dynamically derived.

• Lightweight Computation. To optimize performance for mobile environments, our scheme replaces the intensive symmetric encryption operations used in [10] with efficient XOR operations and one-way hash functions for re-key message generation. This substitution significantly reduces the computational overhead required for users to retrieve file encryption keys, fulfilling the requirement for a lightweight security protocol suitable for resource-constrained devices.

• Recent studies on predictive healthcare security frameworks have demonstrated that advanced encryption, decryption, and intelligent prediction mechanisms may introduce considerable computational overhead in resource-constrained environments [17]. For example, predictive protection frameworks utilizing BObMNN-based security analysis require repeated encryption/decryption operations and continuous model-processing procedures for healthcare data protection.

• Compared with such predictive security frameworks, the proposed scheme primarily relies on lightweight XOR operations and SHA-256 hash computations for hierarchical re-key generation and file-key derivation. Consequently, the computational burden imposed on mobile devices and lightweight cloud users is significantly reduced while still maintaining practical access-control and confidentiality protections.

The present work focuses on lightweight practical security for mobile cloud environments and therefore emphasizes adversary-based security reasoning and operational efficiency rather than formal game-based cryptographic proofs. A fully provable security framework will be considered as future work.

3.2. Performance Evaluation

The proposed scheme extends the framework of Hwang and Sun [10] with the primary goal of optimizing computational overhead for both data owners (DO) and users.

Table 2. Comparison of key management, storage, and computing cost with others.

	Our Scheme	Du et al. [18]	Tian [19]	Zheng et al. [20]
Core	Hierarchical Tree	RBAC	Zero Trust	Cloud-Edge-End
Mechanism	+ XOR/Hash	+ PDP (Medical)	+ CP-ABE	+ ABAC
Storage Cost
DO (Owner)	$FL,ARL,K_O$	Roles, Policies, Tag List	$MK,PK,\mathrm{Attributes}$	$MSK,PK,\mathrm{Revocation}\mathrm{List}$
User	$K_U$ (Single Key)	Role Keys	$S{K}_{attr}$ (Attribute-based)	$S{K}_{attr}$ + $S{K}_{edge}$
CSS (Cloud)	$ARL,\left\{E{K}_{K_{F_i}}\right\},\left\{R_x\right\}$	$EncData,\mathrm{Proof}\mathrm{Tags}$	$EncData,\mathrm{Access}\mathrm{Tree}$	$EncData,$ Re-keys
Key Management
Revocation Complexity	Low (Path update only)	High (Role reassignment)	High (Attribute re-keying)	Medium (Edge assisted)
Revoke Affected	None (Targeted)	Other users in same role	Users with same attributes	Users in specific end-nodes
Computing Cost
DO (Owner)	$n{T}_{E{K}_S}+8T_{AS}+\mathcal{O}\left(m\right)T_{XOR,h}$	$T_{PDP}+T_{Sign}+T_{Enc}$	$T_{Setup}+\mathcal{O}\left(A\right)T_e$	$T_{Gen}+\mathcal{O}\left(A\right)T_p$
User	$8T_{AS}+T_{D{K}_S}+3T_{XOR,h}$	$T_{Verify}+T_{Dec}$	$T_{Dec}+\mathcal{O}\left(A\right)(T_p+T_e)$	$T_{Dec}+\mathcal{O}\left(D\right)T_p$
CSS (Cloud)	$8T_{AS}$	$T_{Challenge}+T_{Verify}$	$T_{Match}$	$T_{Trans}+T_{Verify}$
Main Advantage	Lightweight (No Pairing)	Data Integrity (PDP)	Anonymity & Zero Trust	Edge Computing Efficiency

Notations for Computational Cost: $T_{AS}$: Time for Asymmetric Encryption/Decryption. $T_{E{K}_S}/T_{D{K}_S}$: Time for Symmetric Encryption/Decryption. $T_{XOR,h}$: Time for XOR or Hash operation (Minimal). $T_p$: Time for Bilinear Pairing operation (High). $T_e$: Time for Modular Exponentiation. $T_{PDP}$: Time for Provable Data Possession verification. $\mathcal{O}\left(A\right)$: Complexity scales with the number of attributes. $\mathcal{O}\left(D\right)$: Complexity scales with the tree depth.

provides a comprehensive comparison between the proposed scheme and the baseline approaches [18,19,20].

The computational complexity of the proposed phases is summarized as follows:

• Setup Phase: The DO performs n hash operations to generate file encryption keys, n symmetric encryptions for file protection, and $(1+s+k+m)$ hash and XOR operations to produce re-key messages ($R_O,\left\{R_{U_i}\right\},\left\{R_{r_i}\right\},\left\{R_{t_i}\right\}$). Additionally, two asymmetric encryptions are applied to secure the $ARL$ and associated messages, while the CSS requires two asymmetric decryptions for data ingestion.
• Registration Phase: The user performs two asymmetric encryptions to secure the request ($UID$, $\left\{FID\right\}$, and T). The DO subsequently performs two asymmetric decryptions, followed by a hash and an XOR operation. To complete the process, the DO executes four asymmetric encryptions to distribute credentials, which the user and CSS then decrypt using two asymmetric decryptions each.
• Download Phase: The user initiates the request with two asymmetric encryptions. The CSS performs two asymmetric decryptions for verification, followed by two asymmetric encryptions to deliver the encrypted file and re-key messages. Finally, the user employs two asymmetric decryptions, three hash and XOR operations to derive the file encryption key, and one symmetric decryption to access the file content.

To further substantiate the practical advantages of the proposed scheme, it is essential to move beyond a qualitative functional overview and perform a rigorous quantitative analysis. While existing frameworks from 2025 introduce advanced features such as Zero-Trust architectures and cloud-edge collaboration, they often rely on heavy cryptographic primitives that may not be sustainable for all environments. To provide a clearer perspective on the operational efficiency of our approach, we evaluate several key performance metrics—including computational latency, storage complexity, and energy consumption—against these state-of-the-art schemes. By benchmarking standard cryptographic operations on ARM-based mobile architectures, we establish a performance baseline that highlights the suitability of each method for resource-constrained devices. The detailed quantitative comparison is summarized in

Table 3. Comparison with a rigorous quantitative analysis.

Feature/Reference	Proposed Scheme	Du et al. [18]	Tian [19]	Zheng et al. [20]
Security	Hierarchical Tree	Multi-level Role (RBAC)	Zero Trust	Cloud-Edge-End
Architecture	+ XOR/Hash	+ PDP Proof	+ CP-ABE	+ ABAC
Core Operation Type	SHA-256 Hash / XOR	Bilinear Pairing + ECC	Pairing + MapToPoint	Pairing + Attribute Update
User Computation Cost	Typically $<1$ ms	$50\sim 150$ ms	$200\sim 500$ ms (Scales with A)	$80\sim 200$ ms (Edge-assisted)
DO Storage Cost	$O\left(1\right)$ or $O(logn)$	$O\left(n\right)$ (Scales with data blocks)	$O\left(A\right)$ (Scales with attributes)	$O\left(D\right)$ (Scales with tree depth)
User Key Length	256 bits (Single Key)	$1024\sim 2048$ bits	$>2048$ bits (Linear with A)	$>1024$ bits (Scales with depth)
Revocation Traffic	$O(logn)$ XOR messages	$O\left(\mathrm{Role}\right)$ re-assignment	$O\left(A\right)$ attribute updates	$O\left(D\right)$ edge synchronization
Energy Consumption	Negligible	Moderate (Frequent pairing)	High (Significant battery impact)	Moderate (Edge-offloaded)
Mobile Suitability	High (Resource-constrained)	Moderate (Medical terminals)	Low (Computation-intensive)	Moderate (Edge-dependent)

.

The quantitative values shown in Table 3 are intended to provide a comparative estimation of the computational characteristics of different cryptographic primitives rather than direct end-to-end implementation benchmarks of the proposed protocol. The ranges are derived from representative computational costs widely discussed in prior literature concerning SHA-256 hashing, XOR operations, bilinear pairing, modular exponentiation, and CP-ABE-related cryptographic operations [21].

In the proposed scheme, lightweight operations primarily consist of SHA-256 hash computations and XOR operations, whereas the compared schemes rely heavily on bilinear pairings and modular exponentiation, which are significantly more computationally intensive on resource-constrained mobile devices.

Based on the comprehensive comparison in Table 3, the proposed scheme demonstrates significant superiority over state-of-the-art literature from 2025, particularly in its suitability for resource-constrained mobile environments. In summary, the proposed scheme offers four distinct advantages:

• Optimal Hierarchical Key Storage Efficiency: Unlike recent schemes such as Du et al. [18] and Tian [19], which require the Data Owner (DO) to maintain complex role-tag lists or attribute sets, our scheme significantly reduces storage overhead. By utilizing a hierarchical tree structure where only $FL,ARL,$ and $K_O$ are required, we achieve a constant or logarithmic storage complexity with respect to hierarchical cryptographic key materials ($O\left(1\right)$ or $O(logn)$), Metadata Storage (FL/ARL): $O\left(n\right)$ and $O\left(s\right)$, eliminating the need for DOs to store large quantities of internal hierarchical or root keys. Therefore, the proposed scheme does not eliminate the inherent metadata storage requirements associated with maintaining file and authorization information. Instead, the optimization focuses on reducing the storage burden of hierarchical cryptographic key materials, particularly internal tree keys and root keys, which commonly dominate traditional hierarchical key management systems.
• High-Performance Computational Optimization: While the 2025 frameworks (Tian [19] and Zheng et al. [20]) rely on computationally intensive Bilinear Pairing ($T_p$) and Modular Exponentiation ($T_e$) operations, our scheme substitutes these with efficient Hash and XOR operations ($T_{XOR,h}$). As Hash operations are approximately three orders of magnitude faster than Pairings, our scheme achieves nearly instantaneous processing times (<1 ms), whereas ABE-based counterparts often exceed 200 ms.
• Streamlined Key Management and Revocation: The proposed scheme offers a low-complexity revocation mechanism. Revocation only requires a targeted path update in the hierarchical tree, ensuring that non-revoked users remain unaffected. In contrast, Attribute-Based Encryption (ABAC/CP-ABE) schemes often suffer from high revocation costs due to the necessity of re-keying large sets of attributes across the entire system.
• Minimal Client-Side Burden: By enabling users to maintain only a single secret key ($K_U$), our scheme avoids the “key explosion” problem seen in attribute-based or role-based schemes where key length scales linearly with attributes or roles. This lightweight footprint makes our approach the most viable solution for battery-sensitive mobile devices, edge-assisted IoT systems, and moderately resource-constrained environments.

The quantitative metrics presented in Table 3 provide a comprehensive evaluation of the proposed scheme compared to state-of-the-art literature from 2025. The data highlights a significant performance gap, particularly in terms of operational efficiency and resource management for mobile environments:

• Computational Latency: The results indicate that the user-side computation cost of the proposed scheme remains under 1 ms, which is significantly lower than the $50\sim 500$ ms required by the schemes of Du et al. [18], Tian [19], and Zheng [20]. This drastic reduction is achieved by substituting expensive Bilinear Pairing operations, prevalent in 2025 frameworks, with high-speed SHA-256 hashing and XOR logic. On ARM-based mobile processors, this transition not only saves hundreds of clock cycles but also prevents processor throttling and overheating during frequent access requests.

• Storage and Complexity Scaling: By integrating the Data Owner’s (DO) master key directly into the hierarchical tree structure, the proposed scheme successfully limits storage overhead to a constant or logarithmic scale ($O\left(1\right)$ or $O(logn)$). In contrast, the methods proposed by Du et al. [18] and Tian [19] face linear growth challenges due to data tags and attribute sets, respectively. Our approach demonstrates superior scalability as the volume of files and users increases within the cloud ecosystem.

• Mobile Suitability and Energy Efficiency: The energy consumption data reveals a direct correlation between cryptographic primitive selection and battery impact. The proposed scheme requires users to manage only a 256-bit single key, drastically reducing local memory footprints compared to the $>2048$-bit attribute keys required by CP-ABE-based schemes. Furthermore, the revocation traffic is minimized to $O(logn)$, ensuring that authority updates remain rapid and reliable even under low-bandwidth mobile network conditions.

The quantitative results in Table 3 substantiate that the proposed lightweight mechanism not only maintains security standards comparable to current mainstream literature but also holds a decisive technical advantage in meeting the practical “low-energy, high-responsiveness” requirements of modern mobile devices.

3.3. Communication Overhead and Revocation Traffic

In addition to computational efficiency, communication overhead is also an important consideration in low-bandwidth IoT environments. During the revocation process, the proposed scheme requires the Data Owner (DO) to distribute updated re-key materials along the affected hierarchical path.

The revocation communication complexity is proportional to: $O(logn)$ where n denotes the number of users or tree nodes within the hierarchical structure.

Unlike CP-ABE-based revocation mechanisms, which often require retransmission of large attribute-update components or complete ciphertext re-encryption, the proposed scheme only distributes lightweight XOR/hash-based re-key materials, including: $R_U,R_t,R_r$. Each re-key message primarily contains hash-derived key materials with sizes comparable to standard cryptographic hash outputs (e.g., SHA-256 outputs of 256 bits). Consequently, the communication overhead introduced during revocation remains relatively small compared to pairing-based revocation approaches.

For example, assuming SHA-256-based re-key components of 256 bits, a single revocation update involving three re-key parameters requires approximately:

$$3\times 256=768 \mathrm{bits}$$

excluding protocol headers and transmission metadata.

Even for hierarchical trees with multiple affected levels, the resulting communication overhead remains substantially lower than CP-ABE-based schemes requiring large attribute-update structures or pairing-related ciphertext updates.

Nevertheless, although the proposed revocation mechanism significantly reduces computational overhead, communication overhead may still become non-negligible in ultra-low-bandwidth IoT sensing environments with highly constrained transmission capacity, intermittent connectivity, or energy-harvesting limitations.

Therefore, the proposed scheme is more suitable for lightweight mobile devices, edge-assisted IoT systems, and moderately resource-constrained environments rather than extremely bandwidth-limited sensing nodes.

4. Conclusions

This paper presents a refined hierarchical key management scheme designed to minimize the storage and computational overhead for data owners and users within cloud storage environments. By integrating the data owner’s secret key directly into the hierarchical shared-key tree, the proposed scheme eliminates the necessity for the owner to locally store internal tree keys ($K_t$) and root keys ($K_r$) for each file group. Furthermore, we significantly optimized the generation and processing of re-key messages. Given that the computational cost of a single symmetric encryption operation is approximately equivalent to 100 hash operations, our substitution of symmetric encryption with lightweight hash and Exclusive-OR (XOR) operations provides a substantially more efficient and responsive user experience.

Although the proposed scheme provides practical resistance against multiple common attack scenarios in cloud storage services, this work does not aim to establish a formal provable-security framework under standard cryptographic models. Instead, the primary focus is on lightweight computation, efficient key management, and practical deployability for mobile cloud environments. Formal security proofs and stronger collusion-resistant constructions will be considered in future work.

Although the proposed scheme significantly reduces computational overhead through lightweight XOR/hash-based re-key operations, the practical applicability of the framework may still be constrained in ultra-low-power IoT sensing environments with extremely limited bandwidth, memory capacity, intermittent connectivity, or energy-harvesting limitations. Therefore, the proposed framework is more suitable for mobile cloud systems, edge-assisted IoT architectures, and moderately constrained devices rather than highly restricted sensing nodes operating under severe communication and energy constraints.

In summary, the proposed scheme introduces a high-performance key management methodology that prioritizes resource efficiency. Under this framework, users are required to maintain only a single cryptographic key and perform a minimal number of hash and XOR operations to derive authorized re-key messages. This approach drastically reduces complexity compared to traditional methods involving multiple symmetric operations or modular exponentiations. Moreover, the lightweight re-keying mechanism streamlines the user revocation process; the data owner can revoke access without necessitating the regeneration of secret keys or the redistribution of authorization credentials to the remaining users, thereby significantly mitigating communication overhead.