Leveraging Towards Access Control, Identity Management, and Data Integrity Verification Mechanisms in Blockchain-Assisted Cloud Environments: A Comparative Study

Abstract

Today, IT organizations largely rely on cloud computing services to meet their infrastructure needs, making it the backbone of the industry. However, several challenges remain that need to be effectively addressed. Data breaches, identity and access management problems, unsafe interfaces and APIs, data loss, shared technology vulnerabilities, compliance and legal issues, inadequate data encryption, lack of visibility and control, delayed security patching, and the requirement to have faith in the cloud service provider’s security procedures are the primary security challenges in cloud computing. Blockchain technology has emerged as a promising technology to address many of these security issues. In this paper, an extensive study is carried out to analyze the security issues in the cloud and the categorization of gathered security issues in terms of security requirements, such as confidentiality, integrity, availability, authenticity, and privacy. Research questions are framed to dig deeper into the different blockchain-enabled solutions present to resolve cloud security issues, such as access control, identity management (IDM), and data integrity verification, along with their analysis. In-detail comparative analysis of the above blockchain-assisted solutions is also presented along with the future research directions.

1. Introduction

In the last decade, cloud computing has brought a humongous revolution in the computing paradigm by shifting the focus from thinking of computing resources not as hardware but as software. New-age IT organizations are rapidly migrating towards cloud computing and the reason behind this is improvement in agility, scalability, and efficiency. The reduction in capital expenses, highly dependable disaster recovery management schemes, flexibility in changing the infrastructure requirements as per the demand of the customers, provisioning resources within no time, better availability, and better document controlling are some of the advantages associated with cloud computing [1,2]. The National Institute of Standards and Technology (NIST) has defined cloud computing as “a model for enabling convenient, resource pooling, ubiquitous on-demand access which can be easily delivered with different types of service provider interaction” and has classified the cloud into three service models: Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) [3,4]. Instead of purchasing or installing, by taking out a subscription only users can use the SaaS applications over the internet. PaaS provides the platform to developers for the development, deployment, and execution of applications. With IaaS provided by the cloud, users can access computing resources such as servers, storage, databases (DBs), networking, etc., via the Internet. From early-incepted startups to multinational IT organizations, cloud computing is adopted by all sectors to harness its transformative power, starting from streamlining day-to-day routine IT operations to large-scale intensive computing tasks. It makes computing more ubiquitous by fostering collaborations among geographically dispersed users/entities working on a single task from any corner of the world [5]. The cloud computing paradigm follows a centralized architecture where most of the computing resources such as servers, networking infrastructure, and storage are consolidated and reside at a single data center. There are several advantages associated with this architecture, whereas one of the most common yet important issues which can be highlighted is ‘single point of failure’, where a malicious central entity can easily affect the whole system [6,7]. Cloud-based infrastructure uses the Unified Threat Management (UTM) solution to control the security of all its end points. This UTM solution is a single security solution, and a single appliance provides several security functions at a single point. As a result of this, the attacker or intruder has to disrupt only that single point to bring down the security of the entire system. A blockchain can decentralize and improve cloud security by addressing the issues mentioned above. Instead of relying on a single point, a blockchain uses consensus mechanisms to enable distributed verification of operations. Its distributed ledger ensures tamper-proof logs of operational records, making it easier to detect, audit, and trace attacks.

A blockchain is a widely used decentralized technology, which is considered as a linked list of blocks containing transaction information. It allows each of the nodes to keep a ledger containing the transaction data. Due to this, each transaction happening within the network can be viewed by each of the nodes present in the network. This brings transparency to information sharing. Researchers have started using decentralized blockchain-based technology to mitigate the challenges faced by centralized cloud computing infrastructures to some extent [8]. A blockchain can be leveraged to distribute computing resources, data, and storage across geographically dispersed entities, thereby reducing the chances of a single point of failure [9]. Along with this, it enables transaction data records to be maintained as a distributed ledger in a transparent manner. This immutability helps to maintain the audit trails of the transactions, which increases the accountability and traceability of a user, reducing the risk of a data breach, non-repudiation, and unauthorized access [10,11]. Blockchain-enabled cloud solutions entail costs related to gas fees for smart contract execution and energy consumption to achieve network consensus. The cloud typically requires the involvement of third parties like identity providers (IDPs), System Administrator (SAs), and Third-Party Auditors (TPAs). However, incorporating blockchain technology can reduce costs by eliminating the need for these intermediaries. Blockchain smart contracts can be optimized for cost efficiency through several techniques. For instance, applying the view keyword in Solidity allows verification functions to be executed with zero gas [12]. Additionally, using energy-efficient consensus mechanisms like PoS can significantly reduce energy consumption.

The built-in features of a blockchain such as decentralization, hashing, smart contracts, consensus mechanisms, and Merkle tree increase the security of the transactions.

• Decentralization: It is the core strength of a blockchain that each node maintains a record of all transaction data, which eliminates the need for a central authority. This mitigates the risk of a single point of failure, and the consensus algorithms ensure data consistency across the network [13].
• Hashing: This maintains the confidentiality and integrity of the stored transaction data in a particular block [14].
• Smart contracts: These are executable contract codes run on a blockchain network, which automatically execute transactions when predefined conditions are met. The set of conditions are written in if-then-else form [15].
• Consensus mechanisms: In a blockchain network, consensus refers to the process of achieving a common agreement among participants [15]. A comparison of consensus algorithms like PoW, PoS, DPoS, PBFT, Raft, etc., can be found in [16,17].
• Merkle tree: To ensure data integrity, it concatenates the hashes of all transactions within a block in a chronological order to calculate a root hash, known as the hash of that block [14].

A blockchain can be used in various application areas like finance [18], healthcare [19,20], identity management [21], cloud computing [22], governance [23], Internet of Things (IoT) [24,25], education [26,27], Smartgrid [28], data storage [29], artificial intelligence [30], etc. Various security services using blockchain are defined in [31]. In [32], the storage, scalability, and availability of data in blockchain systems are discussed.

To safeguard the data during transit and at rest in the cloud is paramount. In addition, maintaining the integrity and confidentiality of the data during transactions and privacy during storing is also essential. There may be challenges and loopholes such as access control (access control is the technique that prevents unauthorized users from accessing cloud resources, but a third-party dependency comes with the cloud access control process. The access control policy DB is managed by an SA, due to which access control security is a problem in the cloud [33]), IDM ( centralized IDM in the cloud is a problem where a third-party identity provider is responsible for providing an identity token [34]), integrity verification (a third-party auditor is responsible for checking the integrity of a user’s data stored in the cloud, and this third-party auditor may not be completely trusted [35]), malicious insiders, outside intruders, etc., which need to be closely checked and controlled. Few researchers are focusing on decentralized blockchain-assisted technologies in a cloud environment to achieve utmost security. An extensive body of research work to avoid different kinds of security issues arising in the cloud has been seen in last few years, which has motivated us to conduct a systematic survey on the blockchain-enabled cloud frameworks proposed to resolve some major kinds of security issues of the cloud.

The main aim of this systematic literature review article on blockchain-assisted cloud access control, IDM, and integrity verification mechanisms is to examine the recent related literature based on the above. This will guide researchers to concentrate on existing challenges, driving future innovations.

1.1. Contributions

The major contributions of this research work are listed as follows:

• It performs a systematic review by using the PRISMA [36] guidelines to investigate the cloud security issues, and it classifies the issues in terms of security services such as confidentiality, integrity, availability, authentication, and privacy.
• It presents a thorough study on blockchain-enabled access control, IDM, and data integrity verification solutions for the cloud environment.
• Finally, it provides an in-depth comparative analysis of blockchain-assisted approaches for access control, IDM, and data integrity verification in the cloud environment.

1.2. Article Structure

The structure for the rest of this paper is as follows: Section 2 explains the literature selection method. Section 3 discusses a quick overview of security issues in the cloud and their categorization in terms of security services. Section 4 outlines various blockchain-assisted solutions suggested to address major security challenges in the cloud, and their comparative analysis. Section 5 provides potential directions for further research based on the analysis. Section 6 provides the summary and concluding remarks of this research paper.

2. Literature Selection Methodology

A systematic approach for the literature search started from keyword searching. The phrases with which searches were carried out are “blockchain”, “cloud”, “blockchain with cloud”, “security issues in cloud”, “blockchain-based access control models for cloud”, “blockchain-enabled IDM models for cloud”, and “cloud data integrity verification using blockchain”, used in academic DBs including Google scholar, IEEEXplore, Springer, Elsevier, and Scopus. These phrases were combined using Boolean ’OR’ to gather a comprehensive set of relevant articles. Initially, papers were downloaded from these academic databases with the following distribution: Scopus (66), Google Scholar (42), IEEE Xplore (28), Springer (25), and Elsevier (18). After removing 30 duplicate papers, 149 unique papers remained and 89 were considered by carrying out a preliminary scrutiny by going through their abstracts and conclusions. Out of these, 48 relevant papers published between 2012 and 2024 have been considered for this detailed study.

The distribution of papers across various journal categories, including IEEE, Springer, Elsevier, MDPI, Wiley, and others, is illustrated in the Figure 1.

2.1. Paper Inclusion Criteria

The inclusion criteria for this study were designed based on two main research focuses: the categorization of cloud security issues in terms of security requirements and the study of blockchain-enabled cloud access control, IDM, and integrity verification schemes. The below criteria were designed to ensure the selection of the most relevant papers that would help to address our research questions and meet the objectives of this study.

• The paper must discussed the challenges faced by cloud computing in one of the following areas: security and privacy, data management, or trust management.
• The paper must be an original research paper that introduces a novel blockchain-enabled cloud security solution.
• The proposal must aim to improve one of the following cloud security issues: access control, IDM, and data integrity verification.

2.2. Paper Exclusion Criteria

Forty-one papers were excluded due to one of the following reasons:

• The paper is not focused on cloud-related issues in any of the following areas: security and privacy, data management, trust management (11 papers).
• The paper does not focus on any of the following blockchain-enabled cloud security solutions: access control, IDM, and data integrity verification (13 papers).
• The blockchain-enabled cloud security solution article is not an original contribution, but rather a review paper (14 papers).
• The paper is not written in English (three papers).

This study was conducted following the Preferred Reporting Items for Systematic Reviews and Meta-Analyses (PRISMA), which is shown in Figure 2.

2.3. Research Questions

The following are the research questions which are put forward with the intention to have a thorough and systematic review of the existing literature:

• RQ1. What are the security challenges associated with cloud environments, and how we can categorize them in terms of security requirements, such as confidentiality, integrity, availability, authenticity, and privacy.
• RQ2. What are the different access control schemes proposed for cloud environments that use a blockchain, along with their workings?
• RQ3. What methodologies are used to address IDM issues in cloud environments using a blockchain, and their working procedure?
• RQ4. What are the existing blockchain-enabled models for cloud data integrity verification along with their workings?
• RQ5. Which security parameters are focused on by the existing models to make them secure and their limitations if any?

3. Security Issues in the Cloud

The five major security requirements contributing to information security are confidentiality, integrity, availability, authenticity, and privacy; this discussion is confined to only these areas. A study is performed in this paper to categorize the security issues of the cloud from the perspective of the above-defined security requirements. There are various cloud security issues depicted by various researchers based on different technical perspectives. The noted issues revolving around cloud security from [37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55] are the positioning of Virtual Machine (VM) images in public repositories, operations on plaintext data, data breaches in a cloud DB, resource location, malicious insiders, outside intruders, incomplete data deletion, data backup by a third party, Denial of Service (DoS) attacks, Distributed Denial of Service (DDos) attacks, multi-tenancy, shared resources used by VMs, user IDM, authorization, data storage, privileged access, visibility of VM IP addresses, colocation of data, and loss of control. The detail explanation of all these gathered issues are discussed in the following subsections.

3.1. VMs

VMs are the backbone technologies supplementing the built cloud environment. While in cloud computing the main notion is to think of hardware resources as a software or a service, the VMs are there to support it. The VMs provide an emulated virtual environment where, like physical machines, VM can be created with different operating systems, applications, and storage spaces. The positioning of VM images, visibility of their IP addresses, and resources that are shared with the VMs are a couple of major issues that concern dealing with VMs. A VM image is the blueprint through which users can create their own VM instances. These VM images should not be kept in open repositories due to security concerns. A malevolent user may produce a VM image that contains a covert virus and store it in a public repository. If another user chooses this VM image, the undercover virus will automatically infect that user. This may lead to leakage of sensitive information by compromising confidentiality [40,47]. All of the cloud’s members can see the IP addresses of each VM. This IP address can be used to identify a VM by a malicious user who intends to harm it in some way. The privacy of VMs will be lost as a result [40]. Shared resources can be utilized by VMs; however, not all VMs can use these shared resources. Only VMs that are hosted by the same cloud server are permitted to use the shared resources. Through this scenario, the VMs that are using shared resources can readily discover each other’s internal information. This will hamper the privacy of VMs [40].

3.2. Cloud Data Storage

Several issues are identified in the studies conducted in the literature related to the incoming and outgoing data in the cloud environment. These include operations on plaintext data, incomplete data deletion, the way cloud data backup is handled, loss of control, collocation of data with others, and data breaches in the cloud DB. In the cloud environment, the common operations performed on the data are uploading the data, processing them, and the transfer of the data among different users and servers. In the cloud, the data in transit and at rest need to be protected. If data transfer takes place as plaintext, the confidentiality of the data will be at risk [40]. Proper encryption mechanisms are needed to protect the data at rest, in transit, and also during processing. Ensuring data confidentiality at the lowest possible cost is crucial. Conventional cryptographic algorithms require data to be decrypted before performing any computations, which can be inefficient [45]. Homomorphic encryption offers a more cost-effective solution, as it allows computations to be performed directly on encrypted data without the need for decryption [56]. One of the characteristics of the cloud is to have a good backup facility, which may help the users to obtain the data and service available to them as and when needed. At the same time, every user has the right to request data deletion. However, while deleting the user’s data it should be ensured that the same data will be deleted from every source [40]. Data backup plays a very important role: if in the future any kind of mishap happens with user data, then it can rescue the user data from data loss. The service provider maintains the backup of user data on a regular basis. This is how data availability is ensured; however, if appropriate encryption techniques are not used, it will result in privacy leakage because the service provider (who is storing the backup data) is treated as an untrusted third party [44]. Users store their data on the cloud, where the data and access policies are entirely under the authority of the CSP. Based on the access constraints, the cloud will determine which request it will respond to by transmitting the data. Thus, incompetencies in identity and access management (IAM) may result in major problems [41]. Any malevolent insider or outsider can alter the stored data when IAM is compromised in the cloud [53,55]. Data collision is possible in the cloud if sufficient separation is not maintained. Data privacy will be compromised as a result [50]. If both internal as well external malicious users obtain access to data stored in the cloud DB, then they can tamper with the original data. Consequently, the data integrity will be compromised [52].

3.3. Cloud IAM

Cloud IAM ensures that only authenticated users can access restricted resources when specific access constraints are met. When a user requests access to data on the cloud, the cloud first asks for an identity token. If the user already has a valid toke, then they send it to the cloud; otherwise, they send a request to the IDP for token generation. The IDP generates a token based on the user’s personal information, sends a copy to the user, and also forwards a copy to the cloud. To continue the access process, the user submits the token to the cloud, which then compares both the tokens. If they match, the cloud initiates a request to the SA for the access control list. The SA retrieves this list from the access control policy database and sends it to the cloud. The cloud then checks if the user has the necessary privileges. If authorized, the cloud grants access to the data; otherwise, access is denied [57]. The cloud IAM vulnerabilities include authorization, user IDM, and privileged access. The list of conditions mentioned in the access privileges needs to be satisfied before giving access to stored data in cloud [46]. Failing to do so will have an impact on data access control. The user’s identity need to be validated correctly before granting access. If the secure identity verification procedure is not followed, it will result in a serious issue [51]. Authorization indicates granting someone the authority for the usage of resources. Before giving authority, the service provider needs to check all the restrictions for the specific request; otherwise, it will lead to a critical problem [43].

3.4. Cloud Threats

Threats to the cloud’s security include outside intruders, malicious insiders, and attacks like DoS and DDoS. Insiders are the entities that are internal to the organizations and have default permission to access the data. If the internal user is a malicious one with ill intentions, then this can affect the confidentiality, privacy, and integrity of the data [48]. Among these three, the loss of data integrity can result in a more serious issue than the other two. Whenever outside users obtain access to data in an unauthorized manner, then they are known as outside intruders. Through this scenario, the loss of data integrity can cause a critical problem [48]. When a malicious user sends a lot of fake requests to the service provider, making it busy and exhausting its capacity in responding these requests, this is known as a DoS attack. Due to this, the service provider becomes unavailable for its legitimate users, which leads to the loss of service availability [49]. Whenever fake service requests from multiple sources come to make the service provider unavailable, this kind of attack is named as DDoS [49]. Like DoS, a DDoS attack also leads to an availability problem [54].

Apart from those discussed above, some of the other issues to be mentioned are resource location and multi-tenancy [38]. Data disputes do not occur because of the service provider’s fault. One reason for data conflicts may be the geographical residence of a service provider [38]. Consequently, this will have an impact on data privacy. When several users or tenants of the same or separate organizations use the same resources, this is referred to as multi-tenancy [42]. In this case, the privacy and security of user’s data may be the key problems.

The classification of the above-gathered security issues in terms of the five security requirements comprising confidentiality, integrity, availability, authenticity, and privacy is shown in Figure 3.

4. Blockchain-Assisted Cloud Frameworks: Security Perspective

In this section, on the basis of the above categorization some blockchain-enabled existing solutions are discussed along with their limitations, if any. The security issues of the cloud taken for this survey are access control, IDM, and data integrity verification.

4.1. 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]:

• Dependency on the SA can cause a single point of failure.
• When symmetric key encryption is used, storing both the encrypted data and their decryption key in the cloud can lead to an eavesdropping attack.
• Cloud access control schemes must ensure accountability to trace any malicious activities performed by users.

To avoid this single point of control, C. Yang et al. [33] have proposed “AuthPrivacyChain”. 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 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.

N. Sohrabi 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.

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, Q. Li 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, Short Record (SR) and Long Record (LR). A SR has attributes like channel_ID, block height, and transaction offset. LR stores the data in the form of a key and value pair. The attributes of A LR are data type, data owner name, cloud name, and the path of the data file in the cloud. A SR is generated by the client and distributed among all the consumers by the data owner. Using this SR, anyone can locate the LR in the blockchain. In this model, the operation tracing method is discussed by two protocols, which are operation logging and tracing protocol. Every operation held on the cloud is submitted by the client and recorded by the smart contract. If the operation reaches consensus, then a temporary operation record will be created. After this, the client submits the block height and transaction offset of the temporary operation record. Then, it will be converted into a permanent operation record. The value part of the operation record contains three fields and the traceability field is one of them. This field stores the prior and next operation keys; hence, it will be easy to trace the operation.

A CP-ABE-based access control scheme along with a re-encryption process is suggested in [64]. As per the requested user’s attribute list, the data owner and attribute authority generate an access policy using CP-ABE and they share their generated keys with the user. After obtaining the keys, the user now send a request for secret key generation to a blockchain. The data owner generates the ciphertext of the data using an access structure and for the re-encryption process they share the ciphertext with the attribute authority. The attribute authority then sends the storage request for the re-encrypted text and header information to the CSP. Only the authenticated user can decrypt the re-encrypted data.

Attribute-based access control along with accountability was proposed with the name “BC-ABAC” by the authors of paper [65]. The storage and access procedure of data is shown in Figure 8, where the storage and access steps are defined with the prefixes O and U. First of all, the user provides his/her attributes to Trusted Attribute Authorities (TAAs) for verification, after which the CSP creates an access session for this user. To maintain accountability, after each access session the CSP publishes the URL of all data usages files along with the hash and user address and stores it on a blockchain to make it available publicly, so that all participants of the network can monitor the user activities.

A cloud access control scheme with attribute-based searchable encryption is proposed in the paper [66]. In this paper, the data owner uses the AES algorithm to encrypt the data. Then, they share the access policy and public key with a proxy encryption server, which calculates the proxy-encrypted ciphertext. The data owner now runs an encryption algorithm by parsing the public key, symmetric key, keyword, and proxy-encrypted ciphertext to obtain the ciphertext. To access the data, the user first of all calls the token generation algorithm. Through the keyword and token, a search operation is executed in a blockchain. Whenever the keywords match, the blockchain returns the ciphertext to the user.

Table 1. Comparison of security factors achieved by blockchain-based access control models for cloud environment.

Year, Ref.	Confidentiality	Authentication	Integrity	Availability	Accountability	Privacy
2020, [33]	True	True	True	True	False	False
2020, [61]	True	True	True	True	False	True
2020, [62]	True	True	True	True	False	True
2022, [63]	True	True	True	True	True	False
2022, [64]	True	True	True	True	False	True
2022, [65]	True	True	True	True	True	False
2023, [66]	True	True	True	True	False	False

shows the comparison of the above-discussed models in terms of five security factors, confidentiality, integrity, availability, accountability, and privacy, where factors that are achieved by these models are represented as True, and those that are not with False. There is no suggested technique to trace the records of executed operations in the papers [33,61,62,64,66]. As a result, accountability is compromised. This problem is solved in the models named “CBFF” and “BC-ABAC” [63,65]. In “CBFF” [63], the SR is used to locate the LR in the blockchain, which is shared with all users by the data owner. Due to this, privacy may be compromised. In [65], the data owner stores both the encrypted data and decryption key in the cloud. Now, the third-party cloud is able to read the owner’s data, which could cause privacy leakage. The detailed observation is shown in Table 1.

4.2. Decentralized IDM Approaches

IDM plays a crucial role in the case where users as well as providers are concerned about security. By virtue of IDM, unauthorized users can not obtain access to protected resources. In the case of a cloud environment, the service provider is responsible for the issuance of a user’s requested resources. The resource-requesting user needs to be properly authenticated by an entity known as an IDP [67]. There are different cloud IDM models such as isolated IDM, centralized IDM, federated IDM, and anonymous IDM [34,68]. The problems with all of these models are defined below.

• In isolated IDM, the service provider is responsible for providing service and identity as well. Hence, a single point of failure/centralization issue may be possible [69].
• Centralized IDM is also based on the centralization concept. Here, the service provider is responsible for providing service and all the identity credentials, which are stored in IDP. Due to this, privacy protection issues can arise here [70].
• The centralized problem is solved in federated IDM. Here, the identity information is stored in multiple locations, so security is the main problem with this type of IDM [71,72].
• Anonymous IDM keeps the entities’ identities secret from others. In this scenario, trust issues can arise [73].

To avoid the above-listed issues, researchers have proposed several blockchain-based IDM models for cloud environments, which are discussed below.

To avoid the problems in centralized IDM systems and overcome the issues in federated IDM, K. Bendiab et al. have proposed a blockchain-enabled trust model for IDM in the cloud [74]. In this model, three entities are involved: cloud users, CSPs, and the Trust Management Platform (TMP). The TMP is nothing but a blockchain network and CSPs are the nodes of this network. Here, the authentication and access depend upon two kinds of CSPs, one is the home CSP and the other, with which the resource-requesting user is not registered, is the foreign CSP. An access token is generated by the home CSP for a specific user request. Once the token is validated and stored in blockchain then the foreign CSP will send the requested resource to the user. The workflow of this model is illustrated in Figure 9, which consists of the following steps:

• The cloud user requests protected data from the CSP.
• If the CSP is a foreign CSP for the requested user, then it send the user to its home CSP for authentication purposes.
• The home CSP generates an access token for the user and keeps it in a blockchain.
• The foreign CSP allows the user to access the data, after verifying the access token stored in the blockchain.

In 2019, an Ethereum-based cloud user IDM protocol was proposed [75] to resolve the single point failure in third-party IDM systems. A user, CSP, Ethereum wallet, and Ethereum blockchain are the entities of this model. Users and the cloud need to register first in an Ethereum wallet. After registration, they will receive their public and private key pair. The user will enter their details in a smart contract and by gathering user details the cloud will generate a JSON Web Token (JWT). Then, it is encrypted by key “k” and the encrypted JWT is passed to Base64 (X = Base64(encrypted JWT)). The “k” is encrypted by using the user’s public key and the cloud uploads the X and “k” in smart contracts. The user will receive the X and “k” from the Ethereum blockchain. After decryption, the user will then encrypt the JWT and a random value “r” with the cloud’s public key and send it to the cloud. The cloud will match the received JWT with its previously generated JWT, if matched, and then calculate the hash of the JWT and “r”. Then, it will upload it in a smart contract and send a verification request to the user. The user will also calculate the hash of the JWT and “r” then upload it into the smart contract. The Ethereum blockchain will verify both the hashes; if both are equal, then it permits further communication. The identity verification steps are explained in detail in Figure 10.

As a solution for insider attacks in the cloud DB, a method was suggested by the authors of paper [76]. The authors have proved logically as well as experimentally the theorem, “All authentication conditions of the blockcahin are met if and only if a user authenticated”. The authentication process will be initiated for both insiders and outsiders upon receipt of a request. A user’s authentication is verified by first confirming that their login ID and signature are legitimate, and then verifying that the current index value is correct, and finally authentication is granted.

In [77], the Single Sign-On (SSO) multi-resource access technique is suggested for the cloud environment. The author used three DBs and four smart contracts to implement SSO multi-resource access. When a user submits an access request, they need to provide certain identity information to the access control service gateway. This information is hashed and matched to the hash value kept in the cloud DB. The smart contract verifies the resources to which the requesting user has access permissions if both match. The user receives an SSO token, which enables them to access the resources without multiple sign-on. Figure 11 depicts the SSO token generating process in detail.

The paper [78] suggested blockchain-based identity management, access control, and secure sharing (BC-IAS) in a cloud environment. The article proposes a token-based authentication system where the identity token consists of user_name, user_attribute_tag, and values. A user obtains access to requested resources only if the identity token and access control list are verified. The authors, however, have not discussed the different user attributes used for identity token creation. Also, the paper suggested access provision but no method to maintain access logs. The IAS token generation and user authentication verification is shown in Figure 12.

The detailed observation of the above-discussed solutions is presented in

Table 2. Comparison of blockchain-based IDM models for cloud environment.

Year, Ref.	Availability	Access Control	Privacy	Method Used for Authentication	Time Taken for User Authentication Verification
2018, [74]	True	True	False	Token	-
2019, [75]	True	False	True	JWT and ask security question	2 X time taken for hash (JWT, random number) + time for verification of both hashes
2019, [76]	True	False	False	User signature and current index value verification	Time taken for calculation of x (x = last stored index AND current hash value AND time stamp AND nonce) + verification time for (current index value > x)
2023, [77]	True	True	True	SSO token	Verification time for user’s authentication credential
2023, [78]	True	True	True	User’s attribute token	Verification time for user’s identity attribute

. We have compared the solutions based on the security parameters (privacy, availability, and access control) related to IDM/authentication, the authentication mechanism, and the amount of time it takes to verify the identity. The model discussed in paper [74] has an access control framework but requested data are transferred from a foreign CSP to the user in un-encrypted form, as a result of which the privacy of the data is compromised. In [75], the data access control mechanism is absent.

4.3. Decentralized Data Integrity Verification Techniques

In traditional cloud data integrity verification, entities like a CSP, user, and TPA are involved. Whenever a user issues a challenge to verify the integrity of its data stored in the CSP, the CSP sends a proof of challenge to the TPA. The TPA then compares this proof with the original one generated by the user at the time of data storage [79]. The user will then receive the verification result from the TPA. This challenge–proof verification process can be of different types, such as hash-based verification (which involves generating and comparing hashes of the data file on both the CSP side and the user side to ensure data consistency), and random sampling (instead of verifying the hash of the entire data file, this method checks the integrity of randomly selected data chunks), etc. Some of the problems with the above kinds of data integrity verification are listed below:

• This integrity verification method is controlled by the TPA; hence, centralization/single point of failure is one of the possible problems.
• The verification process is not transparent to the user.

To avoid the TPA for data integrity verification in cloud, the authors of paper [35] have suggested a blockchain-based solution, where they have used a P2P Cloud Storage Server (P2P CSS), blockchain, and Merkle hash tree (MHT). The user splits the data into shards before uploading them to the P2P CSS. Then, the digest of each shard is computed and the MHT is used to obtain the root hash of these shards. The MHT is split into public and private hash trees in this instance. The public hash tree is the portion of the MHT where the data digests of each shard are concatenated with each other to form a root hash, and the private hash is the part in which the digests of each shard are calculated. The user will store the root hash calculated from the MHT on a blockchain and upload the data along with the public hash tree in the P2P CSS. As an acknowledgement of this upload, the P2P CSS sends the data address to the user. The user can run integrity verification of their stored data by choosing a particular shard number and sending the request to the P2P CSS. The cloud calculates the digest of the requested shard and sends the result to the blockchain. After receiving the digest, the blockchain will calculate the root hash and compare it with the previously stored hash. If both are the same, the integrity of the data is maintained, and the blockchain notifies the requested user. The aforementioned process is shown in detail in Figure 13, where the data upload and integrity verification steps are defined by the prefix notations S and V.

A solution is suggested in [80] to overcome the dependency on semi-trusted cloud servers and provide the facility for a user to audit the TPA’s behavior. The working process of this model is divided into two phases: verification of data integrity by the TPA and audit of the TPA’s behavior by the requested user. The TPA retrieves the hash values of the most recent 12 successive blocks on the blockchain in order to verify the integrity. Based on the obtained hash values, the TPA generates a single challenging message and sends it to the cloud. After receiving the challenge message, the cloud calculates the proof and responds to the TPA. The TPA verifies the validity of the proof; if it is legitimate, it creates a single log file. Then, it logs the proof and hash values, and creates a single transaction for the user. The TPA notifies the user if the proof is invalid. The user checks the verification time in the second phase, after which the hash values are extracted from the log entry, a challenging message is generated, and the accompanying proof is verified.

To make data integrity verification transparent to users, in [81] a method is suggested, which uses a cuckoo filter, a lattice signature, rejection sampling, a blockchain, and the cloud. There is no direct communication between the cloud and user. The blockchain is working here as an intermediate between these two entities. First of all, the user will split the data file into blocks of a fixed size, and each block’s signature will be determined by running sigGen(). With the help of a MHT, the signature of the DF is generated by taking the signature of each block as a leaf node. A cuckoo filter is a data structure used by the user to keep the signature of each data block. Then, the user will upload the user_ID, CSP_ID, data file, hash of file, data file_ID, user’s signature, signature set of data blocks, and time stamp to the blockchain. The blockchain sends the aforementioned data to the respective CSP; with this, the data upload is complete. Whenever the cloud receives an integrity verification request from a user through a blockchain, it will first calculate the signature of the data block and prepare a proof by adding the CSP_ID, user_ID, time stamp, data file_ID, data file, calculated signature set of data blocks, and signature of the CSP. Then, the cloud sends the proof to the blockchain and the blockchain will forward the message to the user. The user will compare each data block’s received signatures with the signatures kept in the cuckoo filter. Integrity of the data file is accomplished if they match; otherwise, they do not have integrity. The diagrammatic representation is shown in Figure 14, where the data upload and verification processes are represented with theprefixes S and V.

A multi-cloud storage data auditing scheme is proposed by Zhang et al. [82], where an organizer is there which is responsible for managing the CSPs. The user divides the data into blocks and sends the blocks to the organizer; then, they distribute the blocks among the CSPs. The user then determines each data block’s verification tag and publishes it in smart contracts. The TCSPs compute the tag of the data block they receive and compare the output to the tags that have been published to the blockchain. If the outcome of the comparison is accurate, the CSPs confirm the tags on the smart contracts. The user sends the organizer the set of data block numbers, their coefficients, and a challenge nonce in order to verify the integrity of data. The organizer locates the data blocks first, and then notifies the respective CSPs with the data blocks, coefficient set, and challenge nonce. The CSPs generate the integrity proof and forward it to the organizer. The organizer generates a proof hash by combining all the proofs, and forwards it to the user via blockchain for verification.

A secure auditable and deduplication scheme is proposed in [83], which protects the ownership privacy of users. In this approach, a blockchain is in charge of managing encryption keys and serves as an intermediate entity between the TPA and the CSP. To delegate the auditing task, the user sends the file tag, and public key to the TPA. As per the user’s request, the TPA publishes the challenge data on the blockchain. The blockchain forwards the challenge data to the CSP, which computes the proof and then publishes it on the blockchain. After obtaining the proof from the blockchain, the TPA verifies the proof and if it valid then it publishes the result with a file tag on the blockchain. The detail working procedure of this model is depicted in Figure 15.

A Consortium blockchain-based solution is suggested in [84] to overcome the dependency on the TPA in cloud data integrity verification. The suggested model consists of three phases: set up, auditing, and update phases. The data owner splits the data file into blocks of equal size and the block size is adjustable. Each data block consists of sectors and these sectors are used for tag and proof generation. A rank-based Merkle hash tree is used here to generate the root hash by concatenating the hash of the data blocks. The data owner calls the challenge generation contract with the sample number of data blocks to generate a challenge for data integrity verification. After receives the challenge from the blockchain, the CSP generates the proof and calls the proof verification contract to verify the proof.

Table 3. Comparison of decentralized data integrity verification schemes for cloud environment.

Year, Ref.	Type of Cloud Storage	Mechanism Used	Computation Cost	Communication Cost	Storage Overhead
2018, [35]	Single	Merkle tree	1. Shard Verification: Merkle tree generation X time for each shard hash calculation 2. Merkle tree generation (in a blockchain): sum of output of each leaf node	Merkle tree generation (at user side): sum of output of each leaf node	not addressed
2019, [80]	Single	Tag	1. Server side: exponent in group (G) + group operations in G + multiplication in $Z_p$ + addition in $Z_p$ 2. TPA side: computing e(g,q), where g,q ∈ G + exponent in G + group operations in G + mapping a value into G + hash a value into $Z_p$ + multiplication in $Z_p$	TPA to cloud: number of challenged data blocks X size of each block (here the cost is constant)	not addressed
2021, [81]	Single	Merkle tree and cuckoo filter data structure	1. Client side: 3nMMul + 2nMAdd + nMMod + nMHash 2. CSP side: 2cMul + cAdd + cMod + cHash	CSP’s response on challenge: (no of blocks X signature length of each) + (no. of blocks X size of each file block)	addressed
2021, [82]	Multi	Homomorphic verifiable tag	Analyzed in the form of gas cost for each operation	1. User to organizer: no. of challenged blocks X size of each 2. Organizer to CSPs: no. of challenged blocks X size of each	not addressed
2023, [83]	Single	Tag-based challenge, response method	Analyzed in the form of gas cost for each operation	1. Encryption and signing key generation: (2n + 2) X no. of key servers 2. For auditing: (n tags X size) + (n public keys X size)	not addressed
2024, [84]	Single	Rank-based Merkle hash tree	Tag generation: no. of blocks X (multiplication in G + 2 X exponentiation in G + (no. of sectors in each block X multiplication in $Z_p$))	Audit challenge: (no. of sampled blocks X size) + (no. of sample leaf nodes X size) + (no. of sampled blocks in the sampled files X size)	not addressed

provides a detailed observation of the aforementioned decentralized cloud data integrity solutions. The observation is carried out in terms of whether it is a single/multi-cloud solution, the integrity verification mechanism used, the analysis of computation, the communication cost of the model, and the storage overhead. A blockchain suffers from scalability issues, and in papers [35,80,82,83], the storage overhead problem has not been addressed. However, in paper [81], there is no storage overhead, as the signature data structure is created and stored on the data owner’s side. In this approach, the blockchain functions merely as a mediator. One drawback of this method is that since all verification and computation operations are performed off-chain, it may be vulnerable to replay attacks.

4.4. Comparison of Schemes Discussed in Section 4.1, Section 4.2 and Section 4.3

A summary of the comparison between relevant research in the blockchain-based access control, IDM, cloud DB, and integrity verification frameworks for cloud environments is given in

Table 4. Comparison of schemes discussed under Section 4.1, Section 4.2 and Section 4.3.

Year, Ref.	Management Type	Type of Blockchain	Consensus Method Used	Data Encryption Algorithm	Digital Signature
2020, [33]	Decentralized	Public	-	AES	-
2020, [61]	Decentralized	Ethereum	PoW	AES-128	ECDSA
2020, [62]	Not fully Decentralized	Hyperledger Fabric	-	Multiauthority CP-ABE	-
2022, [63]	Not fully Decentralized	Hyperledger Fabric	Etcdraft	CP-ABE	-
2022, [64]	Not fully Decentralized	Java-based blockchain network	-	CP-ABE	-
2022, [65]	Not fully Decentralized	Quorum Ethereum	Raft and IBFT	DEA	-
2023, [66]	Decentralized	Ethereum	-	AES	-
2018, [74]	Implementation details not found	Implementation details not found	PoS	-	ECDSA
2019, [75]	Decentralized	Ethereum	-	AES and RSA	HMACSHA256
2019, [76]	Implementation details not found	Implementation details not found	-	-	-
2023, [77]	Decentralized	Ethereum	-	-	-
2023, [78]	Implementation details not found	Implementation details not found	-	Hyper Elliptic Curve Cryptography	Hyper Elliptic Curve Cryptography
2018, [35]	Decentralized	Ethereum	-	-	-
2019, [80]	Decentralized	Ethereum	-	-	-
2021, [81]	Not fully Decentralized	Hyperledger Fabric	-	-	Lattice
2021, [82]	Semi decentralized	Consortium	-	-	-
2023, [83]	Decentralized	Ethereum	PoW	AES-256	Blind signature
2024, [84]	Semi decentralized	Hyperledger Fabric	-	-	-

. The several attributes involved in this comparison are the management mode, type of blockchain, consensus method, data encryption algorithm, and digital signature used. In the following subsections, the above attributes are discussed in detail.

Networks can run in a distributed, decentralized, or centralized manner. In centralized networks, there must be one central point/server and every node of the network needs to connect with it. This kind of network is easy to maintain but the problem with such a network is that if this central server fails, then the working of all nodes will be stuck. In a decentralized network, instead of one central entity like a centralized network, more than one central entity is present to increase the availability of the network. Scalability can be one of the problems that arises with this network. In distributed types of networks, there is no single central point or bunch of central points. Control is equally distributed among each node. This kind of network is very complex to implement. Under this categorization of networks, the type of network followed in a paper is defined. Some of them have followed decentralized networks because they have no central point to control and some of them have followed partially decentralized networks, which have still a point of control.

There are two main types of blockchain networks: public and private. A user who wants to be a participant in a public blockchain network can carry out the login process; after that, they can be a participant. There is no restriction for this kind of blockchain network, known as a permissionless network such as Bitcoin, Ethereum, Litecoin, etc. Privacy is the main concern for this public network because there is no restriction over participants; hence, the status of the network is visible to all participants. A private blockchain network is just the opposite of the public one. Only a specific group of nodes are allowed to be a participant in this kind of network. For this reason, it is not a fully decentralized network. Some of the private blockchain networks are Hyperledger, Corda, Ripple, etc. Different kinds of blockchain networks used in the selected research papers are defined under this category. Some of them have used public blockchains and some have used Hyperledger Fabric, which is a distributed ledger technology framework used to build business blockchain applications.

Consensus methods play a very important role in these distributed and decentralized systems, which is already discussed in Section 1.1. The different types of consensus methods used in the selected papers are discussed under this category.

To achieve confidentiality while sharing and storing data, it is necessary to perform encryption. There are several encryption algorithms and under this particular category the different algorithms used for data encryption are mentioned.

A digital signature is used to achieve integrity as well as authenticity of the received data. It is generated by the sender using their private key and it is verified by the receiver using the senders’ public key. In the decentralized frameworks, the different digital signatures used by each paper are defined under this category.

5. Future Research Directions

Although many researchers have proposed various blockchain-based solutions to resolve the security issues threatening the cloud, such as data access control, user IDM, and data integrity verification, but still there are huge research gaps. Future research directions are listed below.

• In blockchain-enabled cloud storage schemes, there is a need for secure symmetric key distribution and the cheater detection approach.
• A blockchain-assisted cloud access control scheme should incorporate a privacy-preserving accountability framework while ensuring efficiency in both storage and cost.
• IDM smart contracts must include a privacy-preserving framework, ensuring minimal user token verification time, low execution costs, and storage efficiency.
• The reduction in the storage overhead in blockchain-based data integrity verification solutions for the cloud is a big concern.
• When it comes to a multi-cloud storage system, an important concern is the even distribution of data files among multiple clouds.

6. Summary

This paper introduces a review of blockchain-assisted solutions to solve the major security problems of the cloud like access control, IDM, and verification of data integrity.

The blockchain-enabled access control schemes have used the access constraints list method. The data owners prepare the list, which is subsequently stored and validated in the blockchain by deploying smart contracts. It has been noticed here that, along with access control, privacy-preserving access log management is also important. The paper presents a comparative analysis of blockchain-enabled access control techniques in terms of five security services. The blockchain-assisted IDM schemes have employed identity token/ signature-based approaches. It has been observed here that the IDM smart contracts must take minimal time for user token verification and have a low gas fee for execution. User token verification can be performed with zero gas, as it only requires a verification or view operation. A comparative analysis of blockchain-assisted IDM schemes in terms of security mechanisms related to IDM/authentication, time to verify user’s authentication, and method of authentication (signature/token) is presented in this paper. The blockchain-enabled data integrity verification solutions have made use of tag/Merkle tree schemes. The storage overhead in blockchain is a concern here with blockchain-enabled data integrity verification solutions, and can be reduced by the adaptation of an Interplanetary File System (IPFS). The decentralized data integrity verification schemes are compared with respect to computational costs and communication costs. This research presents a comparative analysis of the literature investigated for blockchain-enabled access control, IDM, and data integrity verification. This paper also highlights a few future research directions.