## 4 Blockchain-Assisted Cloud Frameworks: Security Perspective
### Decentralized Access Control Mechanisms  
Access control is one of the core security factors that says only authorized persons are allowed to obtain access to requested resources within an approved time slot. Along with access control, authentication, authorization, and auditing need to be achieved. In conventional access control schemes, all the access constraints are stored in the access control policy DB, which is managed by an SA. The problems with this framework are as follows [58,59]:  
1. Dependency on the SA can cause a single point of failure. 2. When symmetric key encryption is used, storing both the encrypted data and their decryption key in the cloud can lead to an eavesdropping attack. 3. Cloud access control schemes must ensure accountability to trace any malicious activities performed by users. To avoid this single point of control, [PERSON] et al. [33] have proposed \"AuthPrivacy-Chain\". Before this, in 2019 [60] an access control framework was proposed where authors use Ciphertext-Policy Attribute-based Encryption (CP-ABE) for better security and the Ethereum blockchain. Here, in [33], authorization- and access-related information is stored in a blockchain. Whenever a resource request comes, first of all the cloud service provider (CSP) gathers some information like user address, resource information, and the hash of  
Figure 3: Categorization of cloud security issues based on five security requirements. resource_ID. After this, they call the smart contract by giving an input of all the above parameters and the blockchain will return the encrypted access constraints for the requested user. After obtaining the access constraints, the cloud will verify whether the user will obtain the access to the resource or not. The detailed workflow of \"AuthPrivacyChain\" is shown below in Figure 4.  
[PERSON] et al. [61] have suggested a blockchain-based access control framework named \"BACC\", which has given importance to the security of a symmetric key. The data owner uploads the encrypted data in the cloud and divides the decryption key into \"n\" pieces. The decryption key will then be stored in the \"t\" master nodes (miner node) of a blockchain as a result of which an unauthorized party cannot access it. At the time of key reconstruction, the user needs at least \"k\" key pieces among the \"n\". The data storage and access procedure of \"BACC\" is defined in Figure 5. The data storage steps are defined with the prefix O and data access steps with the prefix U.  
Figure 4: Workflow of data access in model “AuthPrivacyChain” [33]. Many researchers have suggested multi-authority-based models to avoid a single point of failure in traditional cloud access frameworks. To build trust among these multiple authorities, a blockchain-assisted solution is proposed in [62]. In this framework, there are five entities: certificate authority, attribute authorities, CSP, data owner, and data users. Here, mutual trust is built among multiple authorities, and to implement cross-domain management of user attributes it uses blockchain smart contracts. Whenever a sender sends a data access request to the CSP, the attribute authorities generate and submit the user attribute sub-tokens to the blockchain. After gathering attribute tokens, the blockchain will generate u_ID for the user and sends the decryption token to the user. In Figure 6, the data access procedures of the user is defined with prefix notation U, and data storage procedures with prefix notation O. To ensure data accountability in multi-cloud access control models, [PERSON] et al. have suggested a model named \"CBFF\" [63]. The procedure for data upload and access of this model is shown in Figure 7. The steps involved in data upload are defined with the prefix O and the steps for data access are defined with the prefix U. It uses two types of data records,  
Figure 5: Data storage and access procedure of model “BACC” [61]. Figure 6: Data storage and access mechanism of “BMAC” model [62]. Short Record (SR) and Long Record (LR).