# RACHEM: Reinforced Reliable Computing in Cloud by Ensuring Restricted Access Control
## 2 Literature Survey
### Algorithmic Procedure for RACHEIM
#### 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 \(\rightarrow\) 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\({}_{1}\rightarrow\) R\({}_{2}\rightarrow\) R\({}_{4}\)). 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}=\{\mathrm{id}_{\mathrm{r}_{1}}\mathrm{id}_{\mathrm{r}_{2}},\ldots \ldots\ldots\mathrm{id}_{\mathrm{r}_{n}}\}\) 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}=\{\mathrm{id}_{\mathrm{r}_{1}}\mathrm{id}_{\mathrm{r}_{2}},\ldots \ldots\mathrm{id}_{\mathrm{r}_{m}}\}\), 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{id}_{\mathrm{revu_{1}}}\mathrm{id}_{\mathrm{revu_{2}}}, \ldots\ldots\mathrm{id}_{\mathrm{revu_{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 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 V using the extract query. The challenger then issues a system call add user.