RACHEIM: Reinforced Reliable Computing in Cloud by Ensuring Restricted Access Control

Abstract

Cloud computing has witnessed rapid growth and notable technological progress in recent years. Nevertheless, it is still regarded as being in its early developmental phase, with substantial potential remaining to be explored—particularly through integration with emerging technologies such as the Metaverse, Augmented Reality (AR), and Virtual Reality (VR). As the number of service users increases, so does the demand for computational resources, leading data owners to outsource processing tasks to remote cloud servers. The internet-based delivery of cloud computing services consequently expands the attack surface and impacts the trust relationship between the service user and the service provider. To address these challenges, this study proposes a restricted access control framework based on homomorphic encryption (HE) and identity-based encryption (IBE) mechanisms. A formal analysis of the proposed model is also conducted under an unauthenticated communication model. Simulation results indicate that the proposed approach achieves a 20–40% reduction in encryption and decryption times, respectively, compared with existing state-of-the-art homomorphic encryption schemes. The simulation was performed using a 2048-bit key and data size, consistent with current industry standards, to improve key management efficiency. Additionally, the role-based hierarchy was implemented in a Salesforce cloud environment to ensure secure and restricted access control.

1. Introduction

Existing cryptographic systems often lack robust governance mechanisms to manage exploited or vulnerable Cloud Service Providers (CSPs) and hypervisors. As a result, there is a pressing need to safeguard the integrity of data owners’ assets from potentially compromised CSPs. Additionally, traditional role-based access control (RBAC) models do not sufficiently incorporate identity and access management (IAM) policies required to validate user role credentials effectively. Therefore, enhancing RBAC with stronger IAM mechanisms is essential to ensure secure data access within cloud computing environments.

Over time, the attack surface of cloud systems has expanded considerably, primarily due to unauthorized access and sophisticated network-based threats such as Denial-of-Service (DoS) attacks, Sybil attacks, and collusion attacks. These threats undermine the reliability and trustworthiness of service providers in the eyes of end-users, necessitating advanced security frameworks that can mitigate these vulnerabilities and reinforce user confidence.

1.1. Cloud Security

Cloud computing follows a data-centric model, where securing data storage, transmission, and access is of paramount importance. The cloud is home to numerous machine clusters for providing computing power. The cloud infrastructure enables the allocation of virtually provisioned resources requested by the customer. A centralized controller module helps in maintaining efficient communication between the customer and the service provider. An illustrative representation of the computing and data-centric model for cloud computing services is provided in Figure 1.

The data-centric approach in cloud computing can be broadly categorized into intra-data center and inter-data center models. In the intra-data center model, services provided to customers are hosted within a single, centralized data repository. Conversely, the inter-data center model involves the distribution of cloud services and resources across multiple data centers, all managed by a single CSP. In both cases, the responsibility for ensuring data security at the cloud end lies primarily with the service provider.

Cloud security encompasses a comprehensive set of procedures, tools, policies, and controls designed to protect data, applications, and infrastructure hosted within cloud environments. It is essential for addressing internal and external threats that target diverse business models, such as Business-to-Business (B2B) and Business-to-Customer (B2C). As organizations and individuals increasingly depend on cloud services to store, process, and access sensitive information, ensuring the security and privacy of cloud-hosted resources becomes paramount. Cloud security includes key components such as data protection, access control, regulatory compliance, and threat mitigation.

Among the major challenges in cloud security are the prevention of unauthorized access and the maintenance of data confidentiality. Data breaches remain a significant concern, as they compromise the integrity and reliability of user data while also damaging the trust relationship between Service Users (SUs) and Service Providers (SPs). Recent high-profile breaches [1,2,3] have resulted in the exposure of sensitive user credentials, affecting thousands of users. According to an IBM study [4,5,6], global financial losses due to data breaches are projected to rise to USD 10.5 trillion by 2025. Therefore, it is imperative to strengthen existing Intrusion Detection Systems (IDS) and enforce strict compliance in cloud configurations to ensure that only verified users are granted access to sensitive data. Among these measures, access control plays a critical role by defining and enforcing the rules for who can access specific data, resources, and applications in the cloud.

The traditional RBAC models [7,8,9,10] are less effective in validating the user role credentials for granting access permissions. These models assign permissions to roles and roles to users. However, they often do not include strong cryptographic methods to validate whether a user genuinely possesses a particular role at the time of access request. For instance, the work illustrated in [7] focuses more on attributes rather than verifying role credentials linked to a user identity in real time. The research in [10] attempts to implement RBAC using Attribute-Based Encryption (ABE), but it predominantly maps roles to attributes without incorporating robust authentication of user role bindings through cryptographic credentials such as role secrets.

Furthermore, models like those in [7,10] define access policies at the point of data encryption using ABE. However, these policies are static and inflexible, making it challenging to adapt to dynamic scenarios involving role changes, revocations, or temporary privilege grants—common in modern cloud computing environments. Attribute-based RBAC implementations generally lack real-time credential validation and auditability, both of which are crucial in security-sensitive and compliance-driven cloud infrastructures.

Traditional RBAC models also tend to assume the existence of a trusted identity management system but do not cryptographically bind roles to users in a verifiable and tamper-resistant manner. For example, the research work illustrated in [8] employs a homomorphic encryption scheme to ensure data privacy but does not integrate it with role-based access decisions that require identity validation. Likewise, the work suggested in [9] proposes a scalable and fine-grained access control system using proxy re-encryption and key policies, yet the approach presumes trusted key management and does not explicitly verify user role legitimacy during access enforcement.

These models often depend on centralized control mechanisms and pre-defined encryption structures, which are unsuitable for the dynamic, scalable, and multi-tenant nature of cloud environments. Therefore, while traditional RBAC schemes and their extensions in [7,8,9,10] provide a foundational framework for access control, they fall short in delivering secure and dynamic validation of user role credentials. Addressing these gaps requires the integration of hard security mechanisms, such as cryptographic role secrets, real-time authentication, and dynamic access policy updates, which are either inadequately handled or entirely absent in existing schemes.

Data security at the cloud level can be compromised by various threats, including data breaches, unauthorized data access, Service-Level Agreement (SLA) violations, and cloud service abuse [11,12,13]. Major cloud platforms such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud, and Oracle Cloud each employ their own proprietary security mechanisms to mitigate these risks.

Oracle Cloud Infrastructure (OCI), for example, provides a comprehensive framework for managing user identities and controlling access to cloud resources. Its IAM system allows administrators to define precise access control policies, determining who can access specific resources and what actions they are permitted to perform. These policies are applied to user groups within organizational compartments, enabling fine-grained access control. OCI also supports advanced security features such as Single Sign-On (SSO), Multi-Factor Authentication (MFA), and identity federation, which collectively facilitate secure and seamless user authentication and authorization across Oracle’s ecosystem and integrated third-party applications [14].

In the broader cloud computing industry, as of Q4 2024, AWS led the global cloud infrastructure market with a 31% share, followed by Microsoft Azure at 25%, and Google Cloud at 10%. IBM Cloud and Oracle Cloud accounted for smaller market shares, with 4% and 2%, respectively. These figures reflect the highly competitive nature of the cloud service landscape, where Oracle continues to expand its footprint by offering robust IAM solutions and integrated security services [15].

The security and access control features of AWS function according to a shared security responsibility framework, in which AWS maintains the underlying security of the cloud infrastructure, and the service users are responsible for protecting workloads that they utilize on AWS [16,17]. The identity and access management in Microsoft Azure is supported using Azure Active Directory (AD) for role and service delegation. The role manager can grant and manage access privileges with Azure AD for RBAC. Azure AD provides conformity to safeguard the Cloud domain from unauthorized access by confirming whether the requested role resource’s Application Programming Interface (API) call contains valid membership information; if not, the access is restricted [18]. Google Cloud grants permissions to their end users for data access by grouping them into roles and then authenticating them by their respective Google accounts [19]. Both Google Cloud and Azure support API access with authentication keys and Open Authorization (OAuth), an authorization framework that enables users to grant third-party applications access to their resources without sharing their credentials. Azure’s identity management is broader and more enterprise-oriented, leveraging Azure AD for stronger identity federation and governance. Google Cloud, in contrast, centers around Google identities and service accounts, offering a simpler, more consumer-centric model that is effective for many cloud-native applications:

• Google Cloud APIs often use service accounts and OAuth scopes;
• Azure APIs rely heavily on Azure AD app registrations, tokens, and permissions (delegated or application) via the Microsoft Identity Platform.

In Google Cloud, the RBAC mechanism allows users to execute pipelines within a specified namespace but restricts them from modifying associated artifacts or runtime compute profiles [20]. Google Cloud’s IAM further enhances security by offering automated access control recommendations. These policies identify overly permissive access rights and adjust them based on access patterns observed among similar users within the enterprise.

IBM Cloud adopts a zero-trust network architecture to ensure granular access control. Rather than granting users broad permissions, service users are assigned the minimum necessary privileges required to complete specific tasks. These privileges are revoked immediately upon task completion, thereby minimizing the potential attack surface and reducing the risk of lateral movement within the network [21].

Cloud-level security is critical for sustaining revenue generation and operational efficiency, as it directly influences customer trust, service reliability, and regulatory compliance. A strong correlation exists between cloud security and organizational performance. If the trust between service providers and service users is compromised due to security breaches, it may jeopardize ongoing and future business relationships. Such breaches can also damage the provider’s reputation, result in customer attrition, and lead to substantial revenue loss.

Moreover, security incidents can disrupt business operations, causing downtime, reduced productivity, and additional expenses associated with recovery and remediation. By proactively investing in robust cloud security measures, organizations can mitigate these risks, ensure uninterrupted service delivery, and enhance operational resilience. Effective implementation of cloud security practices also supports regulatory compliance, helping businesses avoid legal penalties and financial sanctions.

In the contemporary digital and cloud-centric landscape, security has become a key differentiator for service providers. Organizations that demonstrate a strong commitment to data protection and compliance are more likely to attract new clients and retain existing ones. Consequently, investments in cloud security not only strengthen defense mechanisms but also provide a strategic advantage that drives growth and revenue.

1.2. Motivation

The foundation of cloud computing lies in the collaborative integration of advanced technologies to foster innovation, enhance server interaction, and overcome the inherent limitations of distributed cloud infrastructure. However, increased server interaction often results in heightened risk of service abuse. The presence of multiple abstraction layers within cloud architectures significantly expands the system’s vulnerability surface. Additionally, establishing trust between stakeholders—particularly in the formulation and enforcement of SLAs—remains a persistent challenge. Insecure computing interfaces can compromise data confidentiality, integrity, and accountability, placing a critical responsibility on service providers to ensure secure access platforms.

The Application Programming Interface (API) plays a central role in enabling interaction and communication within cloud environments. APIs offer mechanisms for encryption, authentication, and activity monitoring. However, these mechanisms can be susceptible to malicious exploitation, especially in the presence of weak API security configurations. Furthermore, multitenancy—wherein multiple users share the same infrastructure—is a key contributor to increased vulnerabilities, broader attack surfaces, and higher instances of cloud exploitation [3,7,8,9].

Existing cryptographic systems have proven insufficient in enforcing robust privileged access control mechanisms [22,23,24,25,26,27,28]. Traditional access control models, such as RBAC and Attribute-Based Access Control (ABAC), have demonstrated effectiveness in defining restricted access. However, they often fall short in delivering flexible access management and real-time identity validation, particularly in scenarios that demand dynamic updates during role allocation or revocation [10,29,30].

Traditional RBAC models are constrained by static role assignments, limiting their effectiveness in dynamic, multi-tenant cloud environments where user roles and access privileges change frequently. This inflexibility introduces considerable administrative overhead, as manual updates to role hierarchies and permissions are required to reflect contextual and user-specific changes. Such processes are time-consuming, prone to errors, and hinder system scalability, increasing the risk of misconfigurations and unauthorized access. These limitations highlight the necessity for adaptive and automated access control mechanisms, integrated with cryptographic techniques such as partial homomorphic encryption, to enhance both security and scalability.

ABAC allows access decisions based on user and resource attributes. However, if the number of attributes increases, the performance overhead and complexity of the computing domain also increases. To overcome these limitations and to strengthen the IAM policies, business enterprises can investigate innovative and novel approaches like establishing dynamic authorization frameworks that permit the evaluation of access policies in real-time based on user attributes. One approach would be to implement constant monitoring and enable adaptive access control mechanisms based on user attributes that can dynamically adjust permissions based on evolving risk profiles.

Service users are often skeptical regarding the privacy and security concerns needed to safeguard their data in the computing domain. This, mistrust further raises concerns regarding severe cloud attacks, and persistent threats facilitated by the means of phishing, the introduction of malware, hacked third-party networks, and direct attacks [31]. Some additional threats to cloud security encompass direct attacks, potential loss of data, and the inability of the administrator to determine the extent of attacks. The untrusted service nodes tend to increase the overhead and complexity of a Trust Management System (TMS) and introduce security threats like collusion attacks, DoS attacks, Sybil attacks, and on–off attacks [32,33,34,35,36].

The collusion attack is an extremely common type of security attack. It includes a group of fake nodes jeopardizing the reputation of a trustworthy service user by producing false rating values and providing redundant data in the service-user matrix. Yet another type of attack is the Sybil attack, in which the malicious nodes initially fabricate fake identities. These fake IDs later generate random recommendations or ratings to undermine the trust value or rating of a trustworthy node, thereby having an impact on the ability to function and the credibility of the TMS.

The cloud computing domain has experienced some major data breach issues over time [4,6,19,37]:

• Forever 21 data breach: In August 2023, over 500,000 customers’ data was compromised that leaked the details of client names, dates of birth, bank account details, and Social Security numbers to an illegal third-party that gained access.
• Discord.io Data Breach: Discord.io suffered a data breach in August 2023 in which nearly 760,000 users’ data was impacted through leakage of confidential information such as usernames and passwords.
• Pizza Hut/KFC Data Breach: Personal data of customers was made publicly accessible during a ransomware attack in January 2023.
• Data Leakage in ChatGPT: A major security issue identified in March 2023 was in ChatGPT’s version 4 (GPT-4), developed by OpenAI, San Francisco, United States. The vulnerability in its open-source library led to the unintended disclosure of users’ personal information, including their chat histories and credit card details.
• The Security breach of Facebook: In April 2019, this breach impacted approximately 540,000 user records, while around 49 million records were affected in the Instagram security breach data loss in May 2019.
• The IBM Data Breach Investigation Report illustrated that more than 1980 data breaches have been encountered across various sectors during the first semester of 2022, an increase of around 32% over the first semester of 2021 and approximately 68% increase till first semester of 2023 [4,5].

Furthermore, a statistical analysis on top cloud cyber-attacks reveals that the most common type of attacks on cloud domain include Man-in-the-Middle attack, Denial-of-Service attack, Insider Threats, Malware Injection, Cross-Site-Scripting (XSS), Advanced persistent threats, Account Hijacking, Insecure API, and Misconfiguration Exploits [38,39,40,41,42]. The Attribute-Based Access Control policy illustrated in [38] enforces access decisions based on dynamic attributes like user role, request context, resource sensitivity, etc., instead of static rules alone. However, as the number of users, attributes, and environmental conditions grow, maintaining and evaluating large sets of attribute-based rules becomes increasingly difficult and computationally expensive. This can lead to inconsistent policy enforcement and delays in real-time access decisions, especially in distributed cloud systems.

The cloud computing domain adopts a multi-tenancy model for resource computation, boosts innovation, and overcomes infrastructure constraints through increased server interaction. A vulnerable interface can hamper the confidentiality, integrity, and availability of the user data uploaded to the cloud. This creates a lack of trust between the SUs and SPs. The accelerated dependency of service users on the cloud has increased nefarious activities and can harm the trust and reputation of the system, jeopardizing the authenticity of services and users.

Hence, the problem at hand is to design secure frameworks that can handle the issues prevalent in the existing cloud computing environments. Traditional cryptographic approaches utilize a secret key for data access operations and to perform computations on the encrypted text. A vulnerable CSP can be a convenient target for malicious attacks by an intruder on the network. The existing IAM policies lack suitable security measures to handle insider attacks. Hence, to investigate the issues regarding the exploitation of a vulnerable CSP and that of a revoked user, a two-phase access control scheme is proposed in this work. The first phase of this reinforced hybrid access control scheme integrates Role-based Access and Homomorphic Encryption (RBAHE). The second phase amalgamates RBAC with identity-based encryption policies to strengthen the identity and access management in the Cloud domain. The former scheme encapsulates the original data and the computation operator in a homomorphic encryption function. This function is then forwarded through a secure channel to hide the contents of the data owner from the CSP, thereby not trusting the service provider blindly. The model then configures RBAC policies to restrict unauthorized data access and manage key permissions using the user role mapping credentials in the Access Control List (ACL).

In particular, the proposed approach integrates hard security mechanisms “Cryptography and Access Control” to ensure data integrity in Cloud Computing Systems. The primary hard security mechanisms used in this work are as follows:

(i)

Encryption that maintains authentication and confidentiality. IBE ensures that only verified users can decrypt: confirms user identity. Broadcast encryption maintains data confidentiality during group transmission.

(ii)

Access control to enforce role-based permissions.

The integration of cryptography (identity-based encryption with broadcast encryption) with role-based access control provides a robust and layered security framework for cloud systems. It ensures that only authorized users can access data via assigned role_ids, data confidentiality is preserved during transmission, and the integrity and trustworthiness of access mechanisms are maintained. This research investigates the security issues in the cloud domain to validate the user role credentials, maintain the reputation of cloud computing systems, identify malicious service nodes through the membership credentials of the ACL, and suggest a mitigation scheme to handle revoked users.

1.3. Key Contributions

The key contributions of this work are summarized as follows:

• To propose a secure framework that enables resource computation at the Cloud Service Provider using hard security mechanisms such as access control and cryptography;
• To provide dynamic access control by supporting real-time updates to Access Control Lists and revocation lists and by managing access privileges and membership credentials through identity validation and role hierarchies;
• To develop an efficient revocation and user management scheme that ensures seamless control over user access in dynamic environments;
• To secure role-based access control by binding each role to a secret value, validated via the ACL to prevent misuse or unauthorized privilege escalation;
• To ensure secure distribution and access of decryption keys to authorized users only;
• To prevent unauthorized service access by issuing randomized role secret values and encryption keys, effectively invalidating malicious or revoked users.

In this study, we propose a secure and dynamic access control framework, tailored for cloud computing environments, leveraging hard security mechanisms, namely access control and cryptography, to ensure secure resource computations at the CSP. The framework introduces a dynamic and role-aware access management model that enables the secure updating of access control policies, efficient revocation of user privileges, and controlled membership management through identity validation and role hierarchies. Access is restricted by managing the ACL and revocation list in real-time, and roles are secured using role secret values, which are validated via the ACL to ensure only legitimate users can obtain the corresponding decryption keys. Unauthorized users are actively invalidated through the assignment of randomized values for both the role secret and the decryption key. These mechanisms collectively contribute to enhanced data protection, fine-grained access control, and trust enforcement within the cloud infrastructure.

The rest of the paper is organized as follows: Section 2 illustrates the literature survey; Section 3 discusses the proposed access control mechanisms, highlighting various access control models to ensure security in cloud computing systems; experimental results and their comparative analysis are shown in Section 4; formal analysis of the proposed approach is illustrated in Section 5; and, finally, the conclusion of the proposed work is showcased in Section 6. The abbreviations used in this manuscript are listed in Abbreviations section.

2. Literature Survey

Cloud computing plays a pivotal role in driving digital transformation. Contemporary business models increasingly recognize the cloud as both a service delivery platform and a storage solution that accelerates transactional processes and promotes business growth. Survey trends presented in [43] highlight substantial expansion across B2B and B2C models, facilitated by rapid technological advancements and the growing reliance on cloud services—particularly for data storage and the adoption of hybrid cloud solutions. A recent forecast on cloud dependency [44] projects that by the end of 2025, more than 70% of organizational workloads will be migrated to cloud platforms.

This unprecedented reliance on cloud infrastructure has also made enterprises more vulnerable to malicious activities and cloud-specific cyberattacks. If these threats escalate beyond anticipated thresholds, they may severely compromise the credibility and reliability of computing systems. As such, ensuring robust cloud security has become a critical priority.

Over the years, numerous research efforts have been directed toward addressing cloud security concerns. This section reviews key contributions in the field and highlights persisting security gaps and challenges that must be addressed to advance secure cloud computing environments.

2.1. Cloud Security Using Cryptographic Approaches

Cryptosystems play a significant role in protecting sensitive user data in the computing domain. However, not all cryptosystems are appropriate for data processing in the encrypted domain. The traditional encryption methods like Data Encryption Standard (DES) [45] and Advanced Encryption Standard (AES) [46] permit the convenient storage of data in the encrypted form. In order to carry out computations on the encrypted data, the traditional cryptosystems require privileged access to the secret key, which perhaps is a primary security concern. The amount of effort a data owner invests during downloading and decrypting the data locally can incur huge computational costs. Conventional encryption methods have been unable to maintain the algebraic associations between the encoded data and the original data. Hence, there is a need for an encryption scheme that secures complex computations in the cloud. To implement privacy preservation on the outsourced data, Craig Gentry [47] introduced the homomorphic encryption scheme that permits the CSP to perform computations on the encrypted data. Later, a series of studies were carried out over the years describing the contribution of Fully Homomorphic Encryption (FHE) schemes to ensure data integrity and cloud security [48,49,50,51,52,53,54,55,56,57,58,59]. Homomorphic encryption (HE) is a cryptographic scheme based on public key encryption that permits the cloud to execute some algebraic operations on the ciphertext such that when the file is decrypted at the receiver’s end, the result obtained matches the original data.

2.2. Cloud Security Using Access Control Schemes

The cloud computing framework employs RBAC and ABAC policies to regulate identity and access management. The key features of RBAC include the assignment of roles to authorized cloud services, validation of user role credentials, and management of service transactions based on rules defined in the ACL. The primary objective of the ABAC policy is to prevent unauthorized users from accessing the network, user data, and IT resources.

ABAC enforces restrictions on unauthorized access by implementing comprehensive IAM constraints. The customization enabled by ABAC allows administrators to modify and adjust access control rules to align with the specific needs of the organization [60]. The rapid growth and widespread adoption of cloud computing in recent years has underscored the need for models that ensure secure access rights in the cloud environment [61,62]. Conventional encryption models often do not address access rights based on user roles or assigned functionalities [63]. Therefore, enforcing restricted access policies in cloud environments is essential for maintaining data confidentiality [64]. A notable approach involves integrating cryptographic schemes with access control mechanisms.

In the RBAC model, a role represents an authorized set of permissions assigned to a user for performing specific tasks within a computing domain [65]. User requests are processed following a critical evaluation. Authenticated users become participants in the ACL and are granted a secret key to access public data when an appropriate role is assigned. An administrative entity, referred to as the role manager, oversees the relationships between roles (role → role) and between roles and users (role → user). The role manager first validates a user’s eligibility for a specific role, then monitors the role parameters to ensure compliance with membership requirements and evaluates the hierarchical relationships among roles. For each role-to-user mapping, role parameters are updated within the cloud domain. To protect sensitive data, the data owner encrypts the information, and only authorized roles are permitted to decrypt the file using a secret key. This mechanism is referred to as Role-Based Encryption (RBE) [66]. Although various access control approaches, such as those proposed in [32,67,68], provide defensive measures against malicious activities, they do not directly address methods for mitigating cloud-specific attacks.

The RBAC model was initially introduced in [69] and subsequently enhanced in studies such as [70,71,72,73]. Given that hierarchical structures effectively model access control, a hierarchical cryptographic scheme was proposed in [74] to represent access control mechanisms. The challenges associated with outsourcing cryptographic access control policies were first discussed in [75]. Subsequently, several schemes were introduced in [76,77,78], presenting cost-effective approaches to access control. To incorporate identity-based validation, a hierarchical identity-based encryption (HIBE) scheme was proposed in [79,80,81], emphasizing that only users within a predefined hierarchical tree structure have the right to decrypt encrypted messages. Users outside this hierarchy are denied access. An improved HIBE scheme was later introduced in [82] to address the bottleneck of identity validation through private key generation. However, this approach was vulnerable to single-point failure if the integrity of the root private key generator was compromised. Consequently, there has been a significant shift from traditional access control mechanisms towards Hierarchical Key Management (HKM), as discussed in [83].

An integrated approach for assessing the vulnerability of an Industrial Control System and protecting the system from cyber-physical attacks was proposed in [84]. However, the work did not present a mitigation scheme and risk analysis if the integrity of the computing system itself has been compromised. Furthermore, a probabilistic approach to measure the reliability of a task and ensure data security in the event of unauthorized access and data theft was suggested in [85] by executing multiple task-solver versions concurrently. However, the work did not consider coherency amongst tasks while analyzing the system failure. In this context, coherency refers to the logical or operational dependencies that may exist between the different versions of a task, such as synchronization requirements, shared data processing, or consistency constraints in composite results. By assuming complete independence among the versions, the model overlooked application scenarios where inter-version communication or result integration is necessary. This assumption may restrict the applicability of their approach to real-world cloud systems where task interdependence is critical for correctness and secure access management. Addressing such coherency aspects is essential to extend the reliability model to more complex cloud-based applications.

Table 1. Summary of literature review.

Research Work	Contributions	Gaps
[43]	Demonstrates growth in B2B and B2C cloud adoption.	Does not address cloud security or access control.
[44]	Forecasts over 70% business workload will migrate to cloud by 2025.	Security challenges with increased cloud adoption not addressed.
[45,46]	Enable convenient storage of encrypted data using DES and AES.	Incapable of computation without revealing secret key.
[47]	Introduced homomorphic encryption for computation on encrypted data.	Limited efficiency and practical implementation concerns.
[48,49,50,51,52,53,54,55,56,57,58,59]	Describes evolution of Fully Homomorphic Encryption (FHE) for cloud security.	Challenges in practical deployment of FHE due to high overhead.
[60]	ABAC allows flexible access control through attribute-based rules.	Lacks detailed encryption scheme integration.
[61,62]	Highlights the necessity of secure access models in growing cloud environments.	Conventional models lack access enforcement mechanisms.
[63,64]	Points out the limitations of conventional encryption in enforcing access rights.	Do not enforce user role privileges securely.
[66]	Proposed Role-Based Encryption (RBE) to secure cloud access control.	Limited to role mapping; lacks dynamic revocation handling.
[32,67,68]	Proposed models address nefarious activity but not cloud attacks explicitly.	No mechanisms for direct mitigation of attacks.
[69,70,71,72,73]	RBAC evolution and improvement over time.	Does not support encryption-integrated access control.
[74]	Introduced hierarchical cryptographic models for access control.	Initial model, lacks revocation and audit features.
[75,76,77,78]	Suggested economic schemes for outsourcing access control.	Limited to policy definition without cryptographic depth.
[79,80,81]	Proposed HIBE to control access using hierarchical identities.	Requires full hierarchical structure; rigid in dynamic settings.
[82]	Suggested private key generation scheme in HIBE; suffers single-point failure.	Fails under root key compromise; lacks resilience.
[83]	Shifted to Hierarchical Key Management (HKM).	Does not integrate cryptographic access validation.
[84]	Introduced Industrial Control System (ICS) vulnerability and cyber-physical attack assessments.	Lacks mitigation schemes if system is compromised.
[85]	Proposed probabilistic task reliability model under unauthorized access.	Ignores task dependency and synchronization challenges.

illustrates a summary of the literature review.

2.3. Identified Research Gaps and Objectives

In recent times, researchers have suggested various cryptographic and access control solutions to protect the data of the owner that is uploaded onto the cloud [86,87,88,89,90]. The work illustrated in [86] introduced a RBAC framework that leverages partial homomorphic encryption (PHE) to ensure fine-grained data access control in cloud environments. The model allows computations on encrypted data without decryption, maintaining data confidentiality while enabling efficient access control. The work of [87] demonstrates a novel RBAC scheme combining identity-based encryption (IBE) and broadcast encryption to securely manage cloud data access. This dual encryption strategy strengthens user authentication and streamlines data sharing among authorized groups without compromising security. Furthermore, a trust-oriented role-based access control for maintaining data integrity in the cloud was provisioned in [88]. This paper enhanced security in traditional RBAC by incorporating trust evaluation mechanisms, aiming to prevent insider threats and unauthorized access. It used trust metrics to dynamically adjust access permissions, ensuring that only trusted entities can access sensitive data. A recommendation-driven trust model was proposed in [89] that predicted trustworthiness of a service user based on previous interactions and ratings. This model enhanced security in cloud systems by intelligently assessing user behavior and guiding access decisions using predicted trust scores. To demonstrate identity governance, an identity-based broadcast encryption scheme was suggested in [90]. The paper focused on reducing computational overhead while preserving security standards, particularly in multi-user data sharing scenarios. Although various schemes have been proposed across domains such as privileged access, IAM, RBAC, and ABAC, some critical research gaps (REG) still remain, as outlined below:

REG-1: The traditional cryptosystems do not incorporate governance schemes to handle vulnerable CSP, so there is a need to hide the contents of the owner’s data from the CSP itself.

REG-2: The conventional role-based access control models do not have efficient identity-based access management policies to validate user role credentials and to handle unauthorized activities by the revoked users.

To handle the identified research gaps, this work formulates the following research objectives (REO). This sub-section depicts the coherency between the identified gaps and the formulated research objectives to ensure security in cloud computing systems.

REO-1 (Addressing REG-1): To design a secure access control framework that integrates cryptographic mechanisms for enabling confidential resource computation at the CSP, thereby ensuring that data content remains hidden from the CSP itself.

Coherency with REG-1: Traditional cryptosystems lack privacy from CSP; REO-1 aims to protect data confidentiality even from the service provider.

The key implementation aspects are as follows:

• Integration of partial homomorphic encryption to perform operations on encrypted data without revealing plaintext;
• Use of access control mechanisms to restrict unauthorized data access, even from internal CSP actors;
• Encryption key management strategies that prevent CSP-level decryption, ensuring end-to-end confidentiality.

REO-2 (addressing REG-2): To develop a dynamic, identity-aware role-based access control mechanism that enables secure policy updates, effective revocation, and credential validation through ACL and role secrets, to prevent unauthorized access by revoked or malicious users.

The key implementation aspects are as follows:

• Dynamic updates to ACL and revocation list;
• Role hierarchy and identity validation;
• Use of role secret values and ACL for validation;
• Invalidating unauthorized users.

Coherency with REG-2: Traditional RBAC models lack robust identity verification and revocation handling; this objective introduces dynamic, identity-driven enforcement.

3. Proposed Model—Reinforced Restricted Access to Handle Vulnerable CSP Using Homomorphic Encryption and Ensure Identity Management (RACHEIM)

The proposed model enhances access control policies and enforces identity management in cloud computing systems by securely channeling the original data through a cipher cloud gateway (CCG), ensuring that the data is transmitted in encrypted form from the data owner to the CSP.

3.1. Working Principle of RACHEIM

In its initial phase, the proposed model employs a division-based homomorphic encryption scheme, utilizing a division operation to encrypt the data before it is uploaded to the cloud. Following encryption, the model enforces restricted access control through an RBAC mechanism. The proposed framework, RACHEIM, adopts an integrated approach to ensure secure and restricted access by managing secret key privileges based on user-to-role mapping credentials.

During the second phase, the model implements an appropriate revocation scheme to address unauthorized service requests. Over time, there has been a significant surge in malicious web-based services, particularly those utilizing ransomware models [91]. These models compromise systems by issuing fraudulent permissions. The identity management component of RACHEIM effectively identifies and blocks such adversarial access attempts. Furthermore, it revokes malicious users from the ACL and places them on a revocation list.

The proposed work underscores the importance of a role-based hierarchy in enforcing restricted access. Consequently, any service request to access cloud data is revoked by the Trusted Manager Module (TMM) and the Role Monitor Module (RMM) if the requesting user is not listed in the ACL. A primary concern for CSPs is the prevention of unauthorized access by previously authorized users whose access rights have since been revoked. RACHEIM addresses this by initializing role-based access parameters for the integrated model, with an RBAC controller subsequently managing privilege rights. This controller maps user-to-role credentials, as illustrated in [29], to represent the inheritance relationships among various roles. The proposed approach constructs an ACL consisting of permissible users and roles, managing data access accordingly. Figure 2 illustrates the working of the proposed model.

The prime entities of the proposed model are the data owner, cipher cloud gateway, service user, ACL, Trusted Manager Module, Role Monitor Module, and the revocation list, as discussed below:

(i)

Data Owner: The data owner is the primary entity whose data is under consideration for resource computation. Since the local servers of business enterprises have a heavy load of data, they often outsource their data for resource computations to cloud servers. Outsourcing of the data increases the possibility of data breach issues.

(ii)

Cipher Cloud Gateway: The cipher cloud gateway encapsulates the owner’s data with the arithmetic operator received from him with a homomorphic encryption function.

(iii)

Service User: A service user in the RACHEIM model has two variants: (a) an authentic user that has a valid user-to-role membership in the ACL; (b) an adversary that aims to inject malicious script in the Cloud domain through the service request.

(iv)

Access Control List (ACL): An ACL is a set of rules that specify which users/ roles are authorized to access data. The permission to grant a service is validated by authenticating appropriate role mapping in the ACL. If, for a requested service, a role-to-user mapping is not found in the ACL, then the respective request is revoked, and restricted access control is ensured.

(v)

Trusted Manager Module (TMM): This module manages the relationship among the roles in the role-based hierarchy. The TMM supervises the privilege rights and manages them strictly according to the authorized roles. Once the data access rights and permissions are validated, the TMM generates the keys for authentic service users and roles. The TMM is an integral component of RACHEIM.

(vi)

Role Monitor Module (RMM): This module administers the roles. Hence, contrary to the traditional RBAC schemes, the need to assign role managers for individual tasks is eliminated in this work. Both the TMM and the RMM are extensive entities for handling system credentials.

(vii)

Revocation List: A user may have had a valid user-to-role membership in the ACL at a particular instant. However, if the user behaves maliciously later by either issuing random service requests or by issuing computational resources beyond the controlled range of the assumed threshold. Such users are then revoked from the ACL and put on the revocation list. The administrator revokes the user through the system call $\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{o}\mathrm{k}\mathrm{e}\left(\mathrm{u}\mathrm{s}\mathrm{e}{\mathrm{r}}_{\mathrm{i}\mathrm{d}},{\mathrm{r}\mathrm{o}\mathrm{l}\mathrm{e}}_{\mathrm{x}}\right).$

3.2. Identity and Key Validation in RACHEIM

The proposed work suggests a two-phase restricted access mechanism by validating identity and key credentials as follows. The owner of the data prepares a message encapsulating the data and the arithmetic operator through which computation is to be carried out on the data. The query for resource computation then passes through the interface of the CCG. Furthermore, the secure cipher cloud gateway safeguards the data by enclosing the original data and the division operator using the HE algorithm. This encrypted text is then uploaded onto the cloud domain along with the division operator, through which the computation is to be performed. This hides the contents of the owner’s data and resource computation details from an untrusted CSP. Equations (1)–(3) illustrate the encryption and decryption processes for the proposed approach RACHEIM using a division-based approach [92,93]. Encryption is carried out using Equation (1):

$$\mathrm{C}={\left(\mathrm{V}\right)}^{\mathrm{e}} \mathrm{m}\mathrm{o}\mathrm{d}\left(\mathrm{n}\right)$$

(1)

The CSP stores the result of the homomorphic encryption carried out using the division operator between two ciphertexts C₁ and C₂ as, ${\mathrm{C}}_1={{(\mathrm{V}}_1)}^{\mathrm{e}}\left(\mathrm{m}\mathrm{o}\mathrm{d} \mathrm{n}\right)$ and ${\mathrm{C}}_2={{(\mathrm{V}}_2)}^{\mathrm{e}}\left(\mathrm{m}\mathrm{o}\mathrm{d} \mathrm{n}\right)$—and stores the value of the encoded text in C3 in the cloud to show division operation as an inverse multiplication using Equation (2):

$${{\mathrm{C}}_3=\left({\mathrm{V}}_1{\times \mathrm{V}}_2^{-1}\right)}^{\mathrm{e}}\mathrm{m}\mathrm{o}\mathrm{d}\left(\mathrm{n}\right)$$

(2)

Decryption is performed using Equation (3):

$${\mathrm{V}=\left(\mathrm{C}\right)}^{\mathrm{d}}\mathrm{m}\mathrm{o}\mathrm{d} \mathrm{n}$$

(3)

where (d, n) is the generated private key for decryption.

This model ensures data confidentiality and privacy even if the integrity of a CSP is compromised. The proposed model also suggests that the data owner need not blindly trust the CSP. Hence, it is imperative that during resource computation, the contents of the original data must be hidden from the CSP. In addition, RACHEIM also ensures that malicious attacks do not jeopardize the owner’s data during any stage of the service communication. The work executes this by integrating partial homomorphic encryption with role-based access control. The use of homomorphic encryption enables secure computations on encrypted data without revealing its contents, protecting confidentiality, even from the CSP. Role-based access control further restricts data access through encrypted role keys and authenticated identity verification, preventing unauthorized use and privilege escalation. The framework also includes dynamic updates to access policies and revocation mechanisms, ensuring that revoked or malicious users are denied access in real-time. Together, these measures secure the data during storage, processing, and transmission, effectively mitigating risks from insider threats, interception, and misuse.

In the proposed framework, all computations performed by the CSP are executed in encrypted form and are governed by the RBAC module. For each incoming service request, an identity management module is activated to verify the existence of a valid data entry. The validated identity and its corresponding role mapping are then cross-checked against the ACL. If a valid mapping is found, access is granted; otherwise, the request is denied. To ensure robust data integrity, the proposed model introduces a two-phase authentication mechanism. In the first phase, the system verifies the user-to-role mapping within the ACL. If a valid entry exists, the request proceeds to the second phase. This phase involves validating the key permissions associated with the request. Upon successful validation, the sender’s private key is securely shared with the authorized service user to facilitate decryption. The key parameters and system components used for simulating the proposed RACHEIM model are detailed in

Table 2. Description of parameters.

Parameters	Description
$\mathrm{u},\mathrm{v}$	Distinct and independent large prime numbers
$(\mathrm{e},\mathrm{n})$	Public Key Components
$(\mathrm{d},\mathrm{n})$	Private Key Components
$\mathrm{C}({\mathrm{C}}_1,{\mathrm{C}}_2)$	Cipher Text values are derived after encryption and on which computation operation is performed.
$\mathrm{C}3$	Cipher Text variable that stores the result of the computation.
$\mathrm{Ø}\left(\mathrm{n}\right)$	Euler totient
$\mathrm{u}\mathrm{s}\mathrm{e}\mathrm{r}\_\mathrm{i}\mathrm{d}$	ID value assigned to the user
$\mathrm{r}\mathrm{o}\mathrm{l}\mathrm{e}\_\mathrm{i}\mathrm{d}$	ID value assigned to the role
$\mathrm{T}\mathrm{H}\mathrm{R}\mathrm{E}\mathrm{S}\mathrm{H}\mathrm{O}\mathrm{L}\mathrm{D}$	Timestamp-based threshold value for the number computational resource request issued from a role
${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$	Request ID for user ${\mathrm{U}}_{\mathrm{K}}$
${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$	Request ID for role ${\mathrm{R}}_{\mathrm{i}}$
$\left\{\mathrm{R}\mathrm{U}\mathrm{L}\right\}$	Role user list
${\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}$	Role Secret Value for the role ${\mathrm{R}}_{\mathrm{i}}$
${\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}$	Decryption key for user ${\mathrm{U}}_{\mathrm{K}}$
${\mathrm{E}\mathrm{n}\mathrm{c}\left(\mathrm{k}\mathrm{e}\mathrm{y}\right)}_{{\mathrm{R}}_{\mathrm{i}}}$	Encryption key for role ${\mathrm{R}}_{\mathrm{i}}$
$\mathrm{T}\mathrm{M}\mathrm{M}$	Trusted Monitor Manager
$\mathrm{R}\mathrm{M}\mathrm{M}$	Role Monitor Module
$\mathrm{C}\mathrm{S}\mathrm{P}$	Cloud service provider
${(\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}},\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{o}\mathrm{k}\mathrm{e})$	Instruction to revoke a user with identity ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$
${(\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}})\prime$	Random role secret value for role ${\mathrm{R}}_{\mathrm{i}}$
${\left({\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}\right)}^{\prime }$	Random decryption key for user ${\mathrm{U}}_{\mathrm{K}}$
${\mathrm{R}}_{\mathrm{i}}$	Role ${\mathrm{R}}_{\mathrm{i}}$
$\mathrm{H}\mathrm{F}$	Hash function (generated to compute role secret value and decryption key)
$\mathrm{A}\mathrm{C}\mathrm{L}$	Access Control List (ACL)
${\mathrm{U}}_{\mathrm{K}}$	User—${\mathrm{U}}_{\mathrm{K}}$
$\mathrm{X}$	Attacker
$\mathrm{W}=\left\{{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_1,}{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_2,}..{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_{\mathrm{n}}}\right\}$	Set of fake role identities created by the attacker
$\mathrm{Y}=\left\{{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_1,}{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_2,}..{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_{\mathrm{m}}}\right\}$	Set of role identities created by the challenger
$\mathrm{V}=\{{\mathrm{i}\mathrm{d}}_{{\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{u}}_1,}...{\mathrm{i}\mathrm{d}}_{{\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{u}}_{\mathrm{p}}}\}$	Set of revoked users maintained by the challenger

, providing insight into the architecture’s operational configuration and evaluation metrics.

3.3. Algorithmic Procedure for RACHEIM

This section illustrates the algorithmic procedure for RACHEIM. The work manages restricted access control by integrating modified identity and broadcast-based encryption schemes and RBAC policy. The approach has seven algorithms for identity-based encryption to implement RBAC. These include system setup, extraction of a user, role management, addition of a user, encryption, decryption, and revocation.

The algorithmic approach for RACHEIM is given below (Algorithm 1).

Algorithm 1: RACHEIM

Function Setup()

{

Initiate the system and permit requests;

if (the request is within the permissible range of created ACL)

Permit request to enter Extract phase;

else

Reject the request;

}

Function Extract()

{

Input: new request (either ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$ or ${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$);

if (request == new request)

{

Check ACL for the mapping of ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$ to ${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$;

if (requested ID == ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$)

TMM computes and grants ${\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}$ to the user;

else if (ID == ${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$)

TMM computes and grants the tuple <${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}},{\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}$> to RMM;

}

}

Function Role_Management()

{

Input: ${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$, {RUL}, role_attributes = {read, write, modify};

if (attributes of ${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$ match attributes of any role in {RUL})

{

Assign ${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$ a new parent role ID;

Update the role hierarchy;

}

}

Function Add_User_to_Role()

{

Input: ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$, {RUL}, ${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$;

if (${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$ ∉ {RUL})

{

RMM sends a tuple <${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}},{\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}$> to CSP;

if (CSP returns a valid ${\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}$ value for ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$)

Add user ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$ to the role ${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$;

else

Reject the add user request;

}

}

Function Revoke_User()

{

Input: ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$, {RUL}, Role (${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$);

For each user ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$ where the ${\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}$ value is inconsistent with CSP:

{

(i) RMM initiates (${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$, revoke) at the CSP’s end;

(ii) CSP generates random values of secret keys:

${\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}^{\prime }$ and ${\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}^{\prime }$ to prevent nefarious activities by the revoked users;

}

}

Function Encrypt()

{

The data owner encrypts a message V (Plaintext) related to role ${\mathrm{R}}_{\mathrm{i}}$

using Equations (1) and (2) through a secure encryption scheme;

Generate Ciphertext (C) and send to CSP;

Ciphertext can only be decrypted by authenticated users;

}

Function Decrypt()

{

Input: ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$, Role(${\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$);

if (${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$ ∈ {RUL})

{

CSP returns ${\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}$ to the user;

User sends tuple <CT, ${\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}$> to CSP;

Access is granted and file is decrypted using Equation (3);

}

else if (${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$∉ {RUL} OR ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$∈ {revoked user list})

{

CSP generates random values:

${\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}^{\prime }$ and ${\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}^{\prime }$ for unauthorized request IDs;

}

}

Each module defined in the algorithmic procedure is defined below as follows:

(i)

Setup: This procedure handles new service requests. A service request can be for the addition of a new user_id or a new role_id. The proposed model restricts a limit on the number of role_ids an SU holds in a role-based hierarchy. Any service request exceeding the permissible limit is rejected at the administrator end by the TMM and at the extraction stage by the monitor role module (RMM).

(ii)

Extraction: This stage forwards the service requests initiated during the setup phase to the Trusted Group Manager module. Following calculations are carried out by the TMM. New service request parameters are matched with the existing identities (roles or users) in the ACL. If a match is found for a role, i.e., if $\mathrm{I}\mathrm{D}={\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$, the TMM evaluates the secret value for the role ${\mathrm{R}}_{\mathrm{i}}$ as ${\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}=\mathrm{H}\mathrm{F}\times {\mathrm{I}\mathrm{D}}_{{\mathrm{R}}_{\mathrm{i}}}$, where $\mathrm{H}\mathrm{F}$ is the hash function generated to calculate the role secret value and decryption key. This secret key value is forwarded to the monitor module in the next stage.

If the initiated service request holds a user’s identity, $\mathrm{I}\mathrm{D}={\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$, and if a suitable correlation exists between the role and the users in the ACL, the TMM evaluates the decryption key, ${\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}=\mathrm{H}\mathrm{F}\mathrm{*}{\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$ and allocates it to the authenticated user. The TMM as an authoritative entity handles the secret key value computation for a role. This stage maintains a role user list, RUL, that manages the details of all the users related to the role ${\mathrm{R}}_{\mathrm{i}}$. The identity-based encryption scheme validates user_id and role_id, role secret value computation, and maintenance of role hierarchy.

(iii)

Role Management: This phase manages the entries of the role user list (RUL) and the computed role secret values for a role generated in the previous stage. The RMM analyses the attributes of a new role (${\mathrm{R}}_{\mathrm{k}})$ request. If a match is found between the new role ${\mathrm{R}}_{\mathrm{k}}$ and the existing role ${\mathrm{R}}_{\mathrm{x}}$ in the role user list, the new role ${\mathrm{R}}_{\mathrm{k}}$ is added to the role hierarchy with the parent role ${\mathrm{R}}_{\mathrm{x}}$. The role hierarchy is then updated accordingly.

(iv)

Grant Access: This phase is critical to the security of the cloud framework. During addition of a service user, two aspects must be taken care of—a new user may be requesting the system access or an existing user requesting a service. This sub-section of the RACHEIM assumes that a new user initiating the service request for role acquisition has never had the system access. Hence, when a user U_k with identity ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{k}}}$ initiates a request to join a role R_i,, the RMM adds the user to the role user list and forwards it to the cloud. The SP validates the characteristics of the user ${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{k}}}$ from the RUL. If a match is found, the RMM adds the role to the role hierarchy and assigns it suitable user-to-role membership.

(v)

Encrypt: The data owner encrypts the original message M with respect to a role ${\mathrm{R}}_{\mathrm{i}}$ using the tuple $<\mathrm{M},{\mathrm{E}\mathrm{n}\mathrm{c}\left(\mathrm{k}\mathrm{e}\mathrm{y}\right)}_{{\mathrm{R}}_{\mathrm{i}}}>$. Then, the encrypted data is sent to the cloud domain.

(vi)

Decrypt: Identity validation and restricted access control are the major concerns of the proposed work. Granting a decryption key to a service user gives him complete data access. This work suggests the authentication of a service user at two stages. Initially, a check is made of the identity of the requesting user ${\mathrm{U}}_{\mathrm{k}},$${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}}$$\in$$\left\{\mathrm{R}\mathrm{U}\mathrm{L}\right\}$. If a match is found, role mapping for the user_id is validated. If, for a user_id, ${\mathrm{U}}_{\mathrm{k}},$ the legitimate mapping credentials exists then the user is subsequently given the decryption key, ${\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}$. However, if a match is not found, then the decryption key request is rejected.

(vii)

Revoke: The role secret values computed by the TMM play a crucial part in validating the authenticity of a service user. The role secret value plays a crucial role in removing an SU from the assigned role. Every user ID whose ${\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}$ differs from the CSP role secret key value is added to the revocation list. The RMM issues (${\mathrm{I}\mathrm{D}}_{{\mathrm{U}}_{\mathrm{K}}},\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{o}\mathrm{k}\mathrm{e})$ to the CSP and random values of ${\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}$ and ${\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}$ values, ${(\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}})\prime \mathrm{a}\mathrm{n}\mathrm{d} ({\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}})\prime$ are generated by the CSP to manage the revoked users at later stages. The flowchart for the algorithmic procedure of the proposed model is depicted in Figure 3.

3.4. Security Analysis of RACHEIM

In recent times, there has been a significant growth in the need for the cloud and the reliance of SUs in the cloud domain. If the projections made in [94] come to frutition, by the end of 2025, more than 80 percent of IT-rendering enterprises will scale their business outsourcing to the cloud domain. Hence, it becomes imperative for the service providers to associate and build strong security. RACHEIM uses role-based hierarchical relationships to demonstrate appropriate user-to-role mapping in the ACL. The identity management module initiates a system call to check if the key privileges are authenticated.

RACHEIM security analysis defines access control through role hierarchy as “A partially ordered set of roles R (r₁, r₂, r₃ …...r_i, r_j.. r_n), with a reflexive-transitive inheritance relation inherits (r_i, r_j) where r_i inherits all permissions from r_j. The ACL maps each user u ∈ U to a role r ∈ R, and permissions are assigned to roles. Access is granted if there exists a valid assignment assign (u, r) such that permission holds true for that role, considering the inherited permissions across the hierarchy. This function returns a permit or deny decision based on the user’s identity, role assignment”. Once the testimony is attained for both of the two phases, authorized access is said to be granted. Figure 4 shows an inheritance-based role hierarchy with double authentication.

RACHEIM suggests a mitigation scheme to handle cloud assaults like Privilege Escalation, Service Injection threats, Sybil attacks through the dynamic update of roles, key parameters and revoked users.

3.4.1. Privilege Escalation and Service-Injection Attack

RACHEIM handles the Service-Injection Attacks and Escalation of Privileges by monitoring the inherent role-based hierarchy. The role-based hierarchical relationship shown in Figure 4 illustrates that the roles R₂ and R₃ inherit their permissions and accessibility from their parent role R₁. Access privileges are managed by the role-inheritance hierarchy. The proposed model implements least privilege policy by performing the following:

• Ensuring that the role R₁ has permissions strictly required for role hierarchy control, not unnecessary access to sensitive data;
• Following Key Isolation Rule for each role that maintains cryptographic separation between the roles, so that even if R₁ is compromised, it does not expose the access keys to roles R₂-R₆;
• Appropriate validation rules are executed at each stage for every role using Salesforce Cloud to check user-to-role mapping and access permissions;
• Continuously monitoring role inheritance hierarchy to identify any excessive privilege propagation.

Role R₂ may have permission to issue a write operation for transactions accessed by roles R₄ and R₅. However, role R₃ may only have permission to read those files. Roles R₄ and R₅, not being direct descendants of role R₁, may inherit write permissions from their parent role R₂, while role R₃ may not inherit these permissions directly from R₁. Hence, if role R₃ issues a write request, the data access is denied. Hence, restricted access is managed using the hierarchical structure.

3.4.2. Scheme to Monitor Sybil Attack

A malicious attacker deceives the system by creating various unauthorized fake identities and attaining majority agreements in his favor. To protect the system from Sybil attacks, this work suggests the initiation of checkpoints at two stages. At stage 1, identity validation through ACL (user → role mapping) is carried out. If the user’s identity does not map to any registered role in the ACL, the request is flagged as suspicious. This prevents fake identities from progressing further in the access process. At stage 2, privilege validation is carried out through role hierarchy. The system maintains an inheritance-based role hierarchy where higher-level roles can delegate specific permissions to child roles (e.g., R₁ → R₂ → R₄). Each request is matched against the privilege list associated with the role, taking into account inherited constraints. If a lower-level role attempts to execute a write or delete operation which is not defined in its permissible limits, the system denies the request immediately and flags the user.

To strengthen access validation, the system uses partial homomorphic encryption (PHE), which allows computations on encrypted data. Hence, even if a Sybil identity manages to pass initial stages, it cannot hamper the encrypted data without appropriate decryption key. Thus, the integrity of the data is not jeopardized.

The model associates a role secret value to each role. If multiple fake identities attempt to use the same secret value or decryption key, the system can infer the likelihood of a Sybil attack and invalidate the request, generate random key values, and initiate the revocation process.

3.4.3. Scheme for Dynamic Update of Access Parameters and Handling Revoked Users

The proposed work intends to identify the attackers who wish to hamper the integrity of the computing domain as discussed below.

Consider an attacker, who issues a set of fake role identities, $\mathrm{W}=\left\{{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_1,}{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_2,}\dots \dots ..{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_{\mathrm{n}}}\right\}$ to attack the challenger (genuine set of user_ids or role_ids). The security setup algorithm is executed by the challenger to identify the type of service request. When the attacker issues queries to the system, the challenger then builds roles set with public identities $\mathrm{Y}=\left\{{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_1,}{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_2},\dots \dots ..{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_{\mathrm{m}}}\right\}$, and executes the extract algorithm to generate role secrets and construct the role hierarchy. For a system to be fully secured, the set $\mathrm{W}\cap \mathrm{Y}$ must be identified as a null { } set. The challenger also maintains a set $\mathrm{V}=\left\{{\mathrm{i}\mathrm{d}}_{{\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{u}}_1,}{\mathrm{i}\mathrm{d}}_{{\mathrm{r}}_{\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{u}2},}\dots \dots ..{\mathrm{i}\mathrm{d}}_{{\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{u}}_{\mathrm{p}}}\right\}$, that stores the details of the revoked user ID’s.

The process of selecting a user for a specified role is performed in two phases.

Phase 1: In this phase, the proposed model analyses the service requests issued from a revoked user. A revoked user issue queries similar to those when he had permissible rights to the system. The service queries issued by the attacker are categorized as follows:

Case 1: The attacker releases a user ID that has no role mapping to the set of roles with public identities mentioned in set $\mathrm{Y}$ issued by the challenger. The challenger, on receiving this request, executes the extract algorithm. As no match is found in the ACL, the attacker’s request is denied.

Case 2: The attacker releases a user ID that matches that of a revoked user when validated against the set $\mathrm{V}$ using the extract query. The challenger then issues a system call add user. The MRM initiates a tuple $<{\mathrm{i}\mathrm{d}}_{{\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{u}}_1},\mathrm{a}\mathrm{d}\mathrm{d}\_\mathrm{u}\mathrm{s}\mathrm{e}\mathrm{r}>$ to the CSP, where ${\mathrm{i}\mathrm{d}}_{{\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{u}}_1}$ is the id of the revoked user, whose match is found in the set $\mathrm{V}$. When the CSP encounters that the id initiating the request for accessing the system is a revoked user, they generate random role secret and decryption key values ${(\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}})\prime \mathrm{a}\mathrm{n}\mathrm{d} ({\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}})\prime$. These random key values are then forwarded by the challenger to the attacker. The attacker is given fake role secret and decryption key values. The attacker believes that as it has the role secret key ${(\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}})\prime$ and the decryption key $\left({\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}\right)\prime$, the data access battle is won.

Phase 2: During this phase, the attacker initiates system calls using the role secret and decryption key values received in the previous phase. However, since fake values of ${(\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}})\prime$ and ${\left({\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}\right)}^{\prime }$ were sent by the challenger, the attacker is neither able to access the data by acquiring a suitable role and nor is he able to decrypt it. Moreover, the attacker is revoked and added to the revocation list.

3.4.4. Threat-Response Mapping for RACHEIM

The proposed work discusses risks such as Sybil attacks (identity spoofing). To enhance the clarity of the proposed model, a formal threat-based tabular interpretation of the STRIDE framework (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is depicted in

Table 3. Threat-response mapping for RACHEIM.

Threat Category (STRIDE)	Potential Attack Scenario	Mitigation Strategy Proposed in RACHEIM	Security Mechanism Employed
Spoofing	Impersonation of a legitimate user to gain unauthorized access.	User identity is validated against the ACL and role hierarchy before request processing.	Role–user mapping validation, ACL checks, and role secret verification.
Tampering	Malicious modification of data during processing or transit.	CSP performs computations only on encrypted data without access to plaintext.	Partial homomorphic encryption (PHE) for secure data processing.
Repudiation	Malicious user denies initiating or performing an action.	All user role transactions are logged and verified against time-stamped request tokens and identity credentials.	Immutable logging and authenticated role-token validation.
Information Disclosure	Exposure of sensitive data to unauthorized users or CSP.	Encrypted data and role-based decryption keys prevent CSP or unauthorized roles from accessing content.	Encryption with hidden content from CSP; role-bound decryption.
Denial-of-Service (DoS)	Overloading the system with invalid or excessive requests.	Requests are validated in two checkpoints: identity-role mapping and privilege validation before execution.	Request throttling and dual-stage access validation mechanism.
Escalation of Privileges	Unauthorized user tries to perform privileged operations.	Access is restricted based on hierarchical role parameters and identity checks; revoked roles cannot regain privileges.	Hierarchical role-based access control (RBAC) with dynamic revocation support.

.

4. Simulation Results

The simulation for RACHEIM has been carried out in two phases.

4.1. Analysis Based on Time

The simulation for the proposed model has been carried out in Python 3.13 on an Intel (R) Core (TM) i-7 processor, 1 TB HDD, 16.0 GB RAM, with Windows 11 Operating System. The service request of the data owner is handled by the cipher cloud gateway, which transforms the original data into an encrypted form. The ciphertext is then uploaded to the centralized cloud and the role-based access control policies are applied.

The baseline cryptographic scheme for performance evaluation of the proposed model RACHEIM is the RSA Multiplicative Homomorphic Encryption Scheme [93]. The comparison is also carried out with the Paillier Additive Homomorphic Encryption Scheme [92].

Table 4. Comparative analysis of cryptographic schemes for RACHEIM.

Scheme	Homomorphic Type	Key Size (bits)	Ciphertext Size (KB)	Encryption Time (ms)	Decryption Time (ms)	Homomorphic Op. Time (ms)
RACHEIM (Proposed)	Partial (Division-based)	2048	1.1	10.3	6.2	13.1
Paillier (Additive HE)	Partial (Additive)	2048	1.5	12.4	6.8	15.2
RSA (Multiplicative HE)	Partial (Multiplicative)	2048	1.8	14.7	8.3	17.5

represents a quantitative comparison of the proposed RACHEIM model with two widely recognized partial homomorphic encryption schemes. The evaluation considers key performance metrics including encryption time, decryption time, ciphertext size, and key size across a range of standardized configurations.

Each data point presented in Figure 5a,b and Figure 6a,b represents the mean of 30 independent simulation runs, all conducted under identical experimental conditions to ensure statistical reliability and minimize the influence of transient system load or random noise. The error bars included in the simulation plots represent ±1 standard deviation and 95% confidence intervals, offering a statistically sound summary of performance variability. This statistical treatment affirms the improvements achieved by the proposed RACHEIM model in both encryption and decryption times when compared with baseline homomorphic encryption schemes. Figure 5a,b present a comparative analysis of encryption and decryption times, respectively, with varying key sizes and fixed data sizes. As shown in Figure 5a, when the key size increases from 512 bits to 2048 bits, the RACHEIM model achieves a 20% reduction in encryption time compared to the RSA multiplicative homomorphic encryption scheme and a 40% reduction relative to the Paillier additive homomorphic encryption scheme. Similarly, Figure 5b demonstrates that for key sizes up to 1024 bits, RACHEIM exhibits a 15% reduction in decryption time compared to the RSA multiplicative scheme and a 20% reduction compared to the Paillier additive scheme. These results clearly indicate the computational efficiency and performance advantage of the RACHEIM model under varying cryptographic configurations.

Figure 6a,b presents a graphical analysis of encryption and decryption times across various data sizes while maintaining a fixed key size of 2048 bits, consistent with current industry standards. The comparative evaluation demonstrates that the proposed RACHEIM model achieves significantly reduced decryption times compared to traditional homomorphic encryption schemes. Specifically, RACHEIM exhibits a 15% reduction in decryption time relative to the RSA Multiplicative Homomorphic Encryption (HE) approach and approximately a 20% reduction compared to the Paillier Additive HE scheme. These findings further validate the computational efficiency of RACHEIM when processing variable data sizes under standardized cryptographic conditions.

The proposed model constructs a role hierarchy by comparing the parameters associated with each role. If the parameters of a new role match those of an existing role within the hierarchy, the request is approved and the role is integrated into the hierarchy; otherwise, the request is denied. In this framework, the data owner is responsible for performing the encryption, while authorized users, identified through valid role permissions, carry out the decryption.

The simulation results presented in Figure 7 demonstrate that the encryption and decryption execution times remain nearly constant, even as the number of service users assigned to a role increases. This indicates that the model efficiently supports scalability without imposing additional computational overhead as the user base grows.

4.2. Role Hierarchy Validation

To validate the proposed role hierarchy mechanism, the simulation was conducted within a real-world Salesforce cloud environment. This setup enabled the evaluation of service node behavior in an operational cloud domain and facilitated the assessment of privileged access through role-based hierarchy enforcement. The simulation allowed for the identification of malicious nodes by verifying user role credentials against the defined membership information in the ACL. The validation results confirm that the simulated outcomes are consistent with the behavior observed in the real-world Salesforce environment. Specifically, the model effectively mitigates privilege escalation attacks, enforces restricted access control, and supports the dynamic construction of a role hierarchy based on ACL-defined membership credentials. The role hierarchy framework illustrated in Figure 4 has been successfully validated and visualized within the Salesforce environment, as depicted in Figure 8 and Figure 9, respectively.

4.3. Performance Overhead and Scalability Analysis

Performance impact and scalability concerns associated with RACHEIM are discussed below:

• The proposed work has been simulated using the Salesforce cloud platform that supports dynamic user role configurations, hierarchical access models, and scalable resource provisioning. This enabled the validation of the system’s performance in the context of evolving access demands and enterprise role hierarchies.
• The proposed approach incorporates partial homomorphic encryption specifically for securing sensitive access control elements such as role secret values and user decryption keys, rather than encrypting bulk data. This selective encryption strategy significantly reduces computational costs and ensures that performance bottlenecks are avoided during frequent access validations.
• Furthermore, to enhance scalability, the RACHEIM model leverages Salesforce’s metadata-driven policy management, which allows for dynamic updates of access control policies and inheritance hierarchies without requiring re-encryption of existing data. The work also implements a checkpoint-based validation mechanisms which limits redundant cryptographic operations and further minimizes latency, particularly as the role hierarchy expands.

Hence, the proposed model ensures an access control scheme that not only strengthens security but also maintains operational efficiency across hierarchical role structures, making it suitable for scalable and real-world cloud environments.

5. Formal Analysis of RACHEIM

To validate the simulation of the proposed approach, this section demonstrates a formal security analysis of the RACHEIM scheme using Canetti and Krawczyk’s Adversary Model (C and K) [95]. This work manifests formal theorems to preserve confidentiality, maintain role secrecy, and revoke unauthorized access.

Theorem 1

(Confidential Secret Key Preservation under Encrypted Computation). Let P be the key exchange protocol implemented in the RACHEIM model, operating under the assumptions of the Canetti–Krawczyk (C and K) security framework. In the presence of an unauthenticated communication model (UM), where adversaries can observe, intercept, and inject messages, the RACHEIM protocol ensures that the confidentiality and integrity of the secret key is preserved, provided that the underlying encryption and key derivation functions are semantically secure and resistant to replay and impersonation attacks.

Proof Sketch:

For preserving the generated Secret Key in the RACHEIM approach, the formal analysis considers the Party Corruption attack, wherein a vulnerable CSP (considered as a Party) could leak the credentials of the computed public and private keys to the attacker. The RACHEIM approach utilizes homomorphic encryption while encrypting the data and then uploads the encrypted data on the CSP. Hence, even if the integrity of the CSP is compromised, the secrecy of the key is maintained. Furthermore, if the adversary manages to steal the key credentials in the unauthenticated link model (UM), due to a vulnerable CSP, the privacy of the owner’s data is still maintained since the CSP does not have direct access to the original data. The homomorphic nature allows computation without decryption, and the key is never exposed to the CSP. Hence, confidentiality is preserved. □

Initial information:

SIG SECRET KEY

Step1: The initiator {Data Owner (DO)} initiates the Key Generation request (DO, u, v, time t_i) // u and v are random large prime numbers, and t_i is the time instance at which a request is initiated.

Step2: Compute n = (u*v), for each new time instance t_i.

Step3: Compute (Division-based_PHE using (n, e))

Step4: Send → Compute (encrypted text, division-operator) to CSP

Upon receiving the encrypted data and the division operator, the CSP performs the computation on the encrypted text. Hence, the CSP does not have any direct access to the original data.

Theorem 2

Let A be an adversary operating under the Canetti–Krawczyk (C and K) model attempting unauthorized access to cloud resources by leveraging a previously issued Secured Cookie Value (SCV). The RACHEIM protocol, which employs an ACL-validated role hierarchy and cryptographic role-secret mappings, ensures that unauthorized service requests are invalidated and that Perfect Forward Secrecy (PFS) is preserved. This holds even if the SCV is shared between the authentic user and an attacker.

Proof Sketch:

The incapability of the attacker to distinguish between the actual key value and the random key values, assures “Perfect Forward Secrecy”. The security analysis for the RACHEIM approach illustrates that the attacker maintains a set of fake role identities and the challenger maintains a set of authentic public identities and revoked role identities. To safeguard the system from continuous attacks, the formal analysis of the RACHEIM approach under the unauthenticated communication link model assumes that the attacker initiates the request to access the role secret value and the decryption key. The role secret value and decryption key ensures dual layer authentication by allowing only the users mapped at appropriate level in the role hierarchy to derive valid decryption keys. Further, malicious user_ids are revoked from the system and random values for role secret and decryption key ensure the soundness of access control. This theorem prevents privilege escalation and enforces consistent role-based access control across branches. □

Initial information:

SIG KEY-PERMISSION

Step:1 Establish Session (user_id, role_id, ACL, S = Session)

If (S =1), and If (role_id, user_id)$\in$ ACL, go to Step2, // {S = 1} implies an active session.

else if S = 0 (session expires), re-establish the session.

Step:2 For each active role_id, on input (role_id, KEY-PERMISSION MODULE)

Initiate (PROTOCOL Perfect_Forward_Role_Key_Secrecy)

Initial information

SIG_Perfect Forward Role and Key Secrecy

${\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}}^{\prime }:$ $\mathrm{Random} \mathrm{value} \mathrm{of} \mathrm{Role} \mathrm{secret} \mathrm{key}$

${\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}}^{\prime }:$ $\mathrm{Random} \mathrm{value} \mathrm{of} \mathrm{Decryption} \mathrm{key}$

Step 1: The attacker initiates a query {id, data access} to the system.

Step 2: The Monitor-Role-Module of the RACHEIM validates the identity of the requested id. If a match exists between the requested id and the revoked id, then random deceptive key values are generated for role secret and decryption key ${(\mathrm{S}\mathrm{E}\mathrm{K}}_{{\mathrm{R}}_{\mathrm{i}}})\prime \mathrm{a}\mathrm{n}\mathrm{d} ({\mathrm{D}\mathrm{K}}_{{\mathrm{U}}_{\mathrm{K}}})\prime .$

Step 3: The attacker falsely believes that he has won the battle of data access since he is unable to distinguish between the actual key values and the fake key values.

The security analysis for the RACHEIM approach emulates the notion of Perfect Forward Secrecy stated in C and K model and validates that the proposed work complies with the C and K adversary model.

Step 4: If the session is active and the KEY PERMISSIONS = Denied, the attacker does obtain the access to the system, but is not able to fabricate the messages or hamper the integrity of the system.

Step 5: An authentic service user qualifies for the KEY PERMISSION PROTOCOL and then decrypts the data encapsulated under the HE function using the SECRET KEY.

Hence, the RACHEIM approach complies with the Secure Key-Exchange protocol and Network Authentication protocol to deal with the vulnerable CSP achieve the research gap REG-1. The proposed model complies with the Perfect Forward Secrecy protocol of the C and K adversary model to ensure restricted access control and achieve the research gap REG-2. The formal results demonstrate that RACHEIM not only protects data confidentiality but also guarantees policy-compliant, revocation-aware access enforcement in dynamic cloud environments.

6. Conclusions

The cloud ecosystem, by its multi-tenant nature, is inherently vulnerable to unauthorized access and network-based attacks. To address these security challenges, this study proposes a reinforced framework—RACHEIM—designed to mitigate risks associated with vulnerable CSPs and to enhance identity and access management (IAM) policies through a two-phase mechanism. In the first phase, the proposed model integrates role-based access control (RBAC) with a homomorphic encryption scheme via a secure cipher cloud gateway. The model encapsulates the original data into an encrypted form using a division-based operator, thereby preserving data integrity and safeguarding against malicious intrusions. Simulation results demonstrate that RACHEIM significantly reduces encryption and decryption execution times compared to conventional homomorphic encryption approaches, such as Multiplicative RSA and Additive Paillier schemes. In the second phase, RACHEIM enforces identity management and privileged access through a dynamic role hierarchy, effectively securing cloud computing systems from unauthorized and malicious users. Simulation findings show that the proposed model achieves approximately 40% reduction in encryption time and 20% reduction in decryption time compared to the Paillier additive homomorphic encryption method. Furthermore, RACHEIM outperforms the RSA multiplicative approach with an approximate 20% improvement in encryption efficiency and a 15% improvement in decryption performance. The simulation was conducted in alignment with current industry standards, using a 2048-bit key size and data size. Additionally, the role hierarchy mechanism was validated in a real-world Salesforce cloud environment, confirming the practical feasibility of the proposed approach. The model’s key permission validation and dynamic policy update capabilities were further substantiated through formal analysis based on Canetti and Krawczyk’s adversarial communication model, ensuring rigorous verification of access control logic under threat conditions.

7. Future Work and Limitations

The proposed work presents a robust framework for secure access control using role-based mechanisms and partial homomorphic encryption. However, there is considerable scope for further enhancement and application. In our future work, we aim to integrate machine learning-based anomaly detection systems within the access control layer to dynamically monitor access patterns and proactively identify malicious service nodes that may indicate potential insider threats. These adaptive techniques can complement the static ACLs and RBAC models, thereby strengthening security in multi-tenant cloud infrastructures. Additionally, we intend to expand the proposed model to support cross-cloud federated identity and access management (IAM), particularly in hybrid and multi-cloud deployments. This would involve implementing interoperability mechanisms to handle authentication and policy enforcement across various cloud providers while maintaining user privacy and data security. The proposed model can also be adapted to support immersive technologies like AR, VR, and the Metaverse. These technologies rely heavily on cloud-based data sharing and multi-user environments. RACHEIM can support these emerging technologies through the following actions:

• Providing secure access enforcement to spatial data and user-generated assets stored in the cloud through role-tokenized credentials;
• Allowing dynamic role mapping and key distribution for participants in collaborative environments (e.g., multiple VR users with differing access levels);
• Preserving data confidentiality during real-time computations (e.g., rendering 3D models or avatar interactions) via partial homomorphic encryption without revealing plaintext data to the cloud or third parties.

Future studies may also consider the overhead introduced by encryption at scale and explore lightweight cryptographic primitives or post-quantum secure algorithms to maintain performance without compromising security. These extensions will make the system more resilient, scalable, and suitable for real-world enterprise applications that demand high agility and robust security compliance.