# RACHEM: Reinforced Reliable Computing in Cloud by Ensuring Restricted Access Control
## 2 Literature Survey
### Algorithmic Procedure for RACHEIM
\begin{table}
\begin{tabular}{p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt} p{56.9 pt}} \hline \hline
**Scheme** & \begin{tabular}{c} **Homomorphic** \\ **Type** \\ \end{tabular} & \begin{tabular}{c} **Key Size** \\ **(bits)** \\ \end{tabular} & \begin{tabular}{c} **Ciphertext** \\ **Size (KB)** \\ \end{tabular} & \begin{tabular}{c} **Encryption** \\ **Time (ms)** \\ \end{tabular} & \begin{tabular}{c} **Decryption** \\ **Time (ms)** \\ \end{tabular} \\ \hline RACHEIM (Proposed) & \begin{tabular}{c} Partial \\ (Division- \\ based) \\ \end{tabular} & 2048 & \(1.1\) & 10.3 & 6.2 & 13.1 \\ \hline Paillier (Additive HE) & \
\begin{tabular}{c} Partial \\ (Additive) \\ \end{tabular} & 2048 & \(1.5\) & 12.4 & 6.8 & 15.2 \\ \hline RSA (Multiplicative HE) &
\begin{tabular}{c} Partial (Multi- \\plicative) \\ \end{tabular} & 2048 & \(1.8\) & 14.7 & 8.3 & 17.5 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Comparative analysis of cryptographic schemes for RACHEIM. Figure 5: (a) Encryption time analysis with key size. (b) Decryption time analysis with key size. Figure 6: (a) Encryption time analysis with data size. (b) Decryption time analysis with data size. 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. ### 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 Figures 8 and 9, respectively. Figure 7: Analysis of encryption and decryption time with increase in the number of service users.