# RACHEM: Reinforced Reliable Computing in Cloud by Ensuring Restricted Access Control
## 2 Literature Survey
### Algorithmic Procedure for RACHEIM
If a match is found for a role, i.e., if \(\text{ID}=\text{ID}_{\text{R}_{\text{i}}}\), the TMM evaluates the secret value for the role \(\text{R}_{\text{i}}\) as \(\text{SE}\text{K}_{\text{R}_{\text{i}}}=\text{HF}\times\text{ID}_{\text{R}_{ \text{i}}}\), where HF 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, \(\text{ID}=\text{ID}_{\text{U}_{\text{K}}}\), and if a suitable correlation exists between the role and the users in the ACL, the TMM evaluates the decryption key, \(\text{D}\text{K}_{\text{U}_{\text{K}}}=\text{HF}^{\text{t}}\text{ID}_{\text{U} _{\text{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 \(\text{R}_{\text{i}}\). The identity-based encryption scheme validates user_id and role_id, role secret value computation, and maintenance of role hierarchy. 3. 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 (\(\text{R}_{\text{k}}\)) request. If a match is found between the new role \(\text{R}_{\text{k}}\) and the existing role \(\text{R}_{\text{x}}\) in the role user list, the new role \(\text{R}_{\text{k}}\) is added to the role hierarchy with the parent role \(\text{R}_{\text{x}}\). The role hierarchy is then updated accordingly. 4. 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 \(\text{U}_{\text{k}}\) with identity \(\text{ID}_{\text{U}_{\text{k}}}\) initiates a request to join a role \(\text{R}_{\text{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 \(\text{ID}_{\text{U}_{\text{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. * Encrypt: The data owner encrypts the original message M with respect to a role \(\text{R}_{\text{i}}\) using the tuple \(<\text{M},\text{Enc}(\text{key})_{\text{R}_{\text{i}}}>\). Then, the encrypted data is sent to the cloud domain. * 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 \(\text{U}_{\text{k}}\text{ID}_{\text{U}_{\text{k}}}\in\){RUL}. If a match is found, role mapping for the user_id is validated. If, for a user_id, \(\text{U}_{\text{k}}\), the legitimate mapping credentials exists then the user is subsequently given the decryption key, \(\text{DK}_{\text{U}_{\text{k}}}\). However, if a match is not found, then the decryption key request is rejected. * 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 \(\text{SEK}_{\text{R}_{\text{i}}}\) differs from the CSP role secret key value is added to the revocation list.