Previous studies led by Juels et al. [7] have developed the concept of Proofs of Retrievability, which allows a verifier to confirm the authenticity and retrievability of a specific file. Shacham et al. [8] have built on this concept by integrating Boneh-Lynn-Shacham (BLS) signatures and pseudorandom functions, resulting in reduced times for queries and responses. Additionally, Ateniese et al. [9] have introduced the Provable Data Possession model, which allows users to verify if their data, hosted on untrustworthy servers, is unaltered without retrieving it. These approaches, however, require continuous communication between the user and the service provider, which can lead to significant performance burdens for the user.

To mitigate the impact on user performance, incorporating a third-party auditor for verification purposes has been suggested. For instance, Zhu et al. [10] introduced a data integrity verification approach that uses a short signature algorithm, ensuring privacy while enabling public auditing via a centralized auditor. Similarly, Ping et al. [11] developed a scheme for data integrity checks using algebraic signatures and elliptic curve cryptography. This approach delegates the role of verifying outsourced data integrity to an intermediary. Moreover, Lu et al. [12] proposed a more efficient auditing method where the third-party auditor generates block tags and conducts integrity checks, relieving the user of these tasks. Furthermore, Huang et al. [13] designed a privacy-preserving data integrity system that takes different data auditing frequencies into consideration. The system aims to reduce the auditing costs that third-party auditors charge for users who do not regularly verify their data files. However, ensuring the security of third-party auditors remains a critical issue that this article aims to address.

In the realm of blockchain-based research, a significant focus has been on applications within cloud storage that replace traditional third-party auditors with blockchain technology to manage and permanently record auditing tasks, thus ensuring mutual honesty among participants. In this context, Huang et al. [14] introduced a collaborative blockchain system to audit cloud data storage. Here, instead of a single auditor, consensus nodes collectively perform auditing tasks and maintain data integrity against diverse threats. However, some models exclude blockchain from essential verification processes. Yue et al. [15] developed a blockchain scheme that utilizes Merkle trees and random challenge numbers to verify the integrity of cloud data. Wei et al. [16] created a system that allows multiple parties to collaboratively verify data trustworthiness by utilizing blockchain’s smart contract features to track data modifications. Shu et al. [17] developed a decentralized framework that operates similarly to a traditional third-party auditor, but with reduced risks of compromised auditors and hostile blockchain miners due to its self-governing structure. Tian et al. [18] introduced a blockchain-enabled secure de-duplication and collective auditing methodology for distributed storage systems. This methodology incorporates a dual direction shared auditing process, facilitating decentralized public auditing without the need for a traditional intermediary. Zhao et al. [19] presented a blockchain-supported public auditing scheme, offering conditional anonymity and privacy preservation. It is designed to withstand man-in-the-middle attacks and ensure the integrity of stored data, along with protecting data privacy and offering conditional anonymity for users’ identities. Guo et al. [20] devised a reversible, blockchain-aided attribute-based encryption mechanism with an escrow-free setup, addressing the key escrow issue by using federated blockchains instead of conventional key management entities. Kumari et al. [21] proposed a cloud-based data auditing method to assure the integrity of healthcare data. Furthermore, Li et al. [22] devloped a novel certificateless data ownership verification system, which emphasizes both effectiveness and privacy preservation. While the existing approaches have potential benefits, they suffer from two major limitations. Similarly, Li [23] introduced a blockchain-based privacy-preserving system to enhance logistics in the context of the Internet of Things. The proposed approach makes use of hash functions to detect data integrity, ciphertext-policy attribute-based encryption to achieve secrecy, and smart contracts to manage data access. Firstly, they are not very efficient as they require extensive computation and communication among the network participants. Secondly, the privacy of user data files is not properly addressed, which raises security concerns. Our proposed scheme aims to overcome these issues and provide a more efficient and secure solution that guarantees the integrity and secrecy of data stored on the public cloud.

This section describes the proposed system, at a high level, for preserving the secrecy and integrity of data files stored on the public cloud. The proposed system comprises five entities: Data owner, cloud storage, blockchain network, smart contract, and oracle interface. We explain the role of each entity and its interactions with other entities as follows:

Data owner (DO). This entity can be represented as an individual user or organization that wants to outsource their data files to the public cloud storage and also check the integrity of such outsourced files. To maintain data confidentiality, the data owner enciphers the data files before outsourcing them.

Public cloud storage (PCS). This entity is responsible for serving the data owner by storing and maintaining their data files. Since data stored on the cloud is controlled by a non-trusting third party, the data owner encrypts their data files before outsourcing them. In addition to providing storage services, it should also provide proof of data correctness whenever the data owner asks for it.

Blockchain network (BN). This entity represents the underlying peer-to-peer network. It enables the deployment and execution of smart contracts on top of it.

Smart contract (SC). This entity is represented as a script running on the blockchain network. It has a specific address to be called at. The data owner sends the metadata for a data file to be stored on the contract state. When the data owner wants to verify the integrity of their data files stored on the public cloud, they can issue an audit request through the smart contract to the public cloud. Furthermore, the smart contract can perform some computations to check whether the auditing response received from the cloud storage is correct.

Interface oracle (IO). This entity is represented as an off-chain entity that enables communication between the blockchain smart contract and public cloud storage. Smart contracts cannot communicate with the outside world except with the help of blockchain oracles. That is, we rely on an interface oracle for forwarding the auditing request from the smart contract to the cloud as well as delivering the auditing response from the cloud to the contract. In other words, it can be thought of as an intermediary between the smart contract and cloud storage.

The proposed auditing scheme’s high-level workflow is illustrated in Fig. 1, covering both data outsourcing and auditing processes as follows. Firstly, to outsource data, the data owner must encrypt the data file and compute its metadata. The encrypted data file is then transmitted to the public cloud for storage, while its corresponding metadata is recorded on the smart contract for future data auditing purposes. Secondly, to audit an outsourced data file, the data owner can submit an audit request through the smart contract to the public cloud. The smart contract utilizes an oracle interface to send the auditing request and receive the auditing response from the public cloud. Once the smart contract receives the auditing response, it verifies the accuracy of the provided response and notifies the data owner about the integrity of their outsourced data files.

We consider the following criteria as design requirements for our proposed scheme. First, the smart contract should be able to verify the integrity of outsourced data files without the need to store them on the blockchain or retrieve them from the public cloud. That means the smart contract does not need a copy of the data files to perform the auditing task. Secondly, the proposed scheme should preserve the secrecy of outscored data files by preventing everyone (except the data owner) from accessing such data files. Blockchain network nodes, for instance, should not be able to view or read the content of data files. In addition, the smart contract code should not have any bugs or vulnerabilities that can be utilized to access the content of data files or manipulate the auditing results.

Various assumptions have been considered in our proposed scheme, which are as follows. First, we treat the public cloud as a non-trusted entity. That is, we rely on a smart contract integrated with an oracle interface to audit the data files stored on the cloud periodically. Secondly, the smart contract is assumed to honestly perform the data auditing task. However, since the contract code is placed on a public blockchain network, one might exploit the contract code to view the content of data files. We assume the contract is securely designed to prevent such malicious activities. Finally and more importantly, we assume that the oracle interface can securely deliver the communications between the smart contract and the public cloud.

This section describes the details of our proposed data auditing scheme. The first phase of our scheme concerns data preparation and storage, while the second phase concerns challenges the public cloud to provide proof of data correctness.

The proposed scheme is executed in two distinct phases. The initial phase involves data preparation and storage and is primarily carried out by the data owner. On the other hand, the second phase is responsible for verifying data integrity.

Algorithm 1 shows the generic steps for implementing the first phase. Firstly, the data owner encrypts the data files and generates their verification metadata. We implement this phase using Python. For data file encryption, we leverage the Crypto.Cipher package by importing the AES class. We generate a key of 192 bit long k_s and then run the cipher. encrypt method to encrypt the data file. The encrypted data file C is then forwarded to the public cloud for storage. To generate the verification metadata, the data owner first selects two prime numbers and generates public and private ECC keys. To generate the ECC keys, we leverage the ECC class by importing the Crypto.PublicKey package. The verification metadata C_m is computed using the Python mod package. The data owner then sends C_m to the smart contract for any future data integrity checks.

Algorithm 2 shows the generic steps for the implementation of the second phase. We implement this phase as a smart contract running on the Ethereum network and Python code running on the public cloud. We consider the Ethereum network over other private blockchains like Hyperledger since it is an open network where anyone can join and participate in the network. In addition, it offers high levels of transparency and security in comparison to private networks. To check the integrity of data files stored on the cloud, the data owner sends a transaction to the smart contract whenever the integrity of a data file needs to be checked. The transaction should contain the ID of the encrypted file, a temporary key, and the multiplication of a random integer and the ECC public key. The smart contract transaction is then executed by generating an auditing request R_a as a challenge and forwarding it to the public cloud through an oracle interface. We discuss the details of the smart contract implementation in the following section. Upon receiving the R_a, the public cloud storage computes the data auditing response. We implement the cloud as a server running a Python code to compute the auditing response. The cloud server generates a random integer using a keyed random function algorithm and then calculates the auditing response R_s by applying the modular arithmetic operation stated in Line 8. The cloud then sends R_s to the smart contract as proof of data correctness. When the smart contract receives R_s from the cloud, it executes a verification method to check whether the received response R_s is valid or not. The data owner will then be informed about the result of the data integrity check.

Our proposed auditing system heavily depends on smart contracts, which serve as the system’s foundation. To implement the data auditing activities in the system, we utilize the Solidity language to create an Ethereum smart contract. This smart contract is responsible for managing the auditing requests and verifying the correctness of the auditing responses. The smart contract is designed to ensure complete transparency and immutability throughout the auditing process. We use the Remix tool [24] to develop and test the smart contract, which provides various features such as code editing, error debugging, and smart contract deployment. We leverage the Ethereum Sepolia test network [25] for deploying and executing the smart contract. This approach offers several advantages, including testing the smart contract using unreal tokens, which can help identify vulnerabilities before posting the smart contract on the main network. In this section, we discuss the development of the smart contract integrated into the auditing system.

The smart contract is responsible for issuing an auditing request, sending the request to the public cloud, obtaining the auditing response from the cloud, and verifying the received response. We present the detailed implementation of the two most important functions of our smart contract, which are issueAuditReq and verifyAuditRes. These functions are meant to highlight the key functionality and operation of the auditing system.

issueAuditReq Function. This function is triggered whenever a data owner sends a transaction to execute it. It accepts three input parameters (file ID, a key, and an integer value), concatenates them, and then produces the auditing request to be forwarded to the public cloud. We note that the three parameters are of different types. The file ID and the integer value are of type unit, whereas the key is of a byte type. In Solidity, there is no straightforward way to concatenate values of different types. That is, we leverage a Solidity function called abi.encodePacked to convert the integer values into bytes. Then, we use the bytes.concat method to concatenate the three byte sequences into a single-byte sequence representing the auditing request.

verifyAuditRes Function. This function is executed upon receiving the auditing response from the cloud to verify the response’s correctness. To verify the auditing response, there is a need to generate a random integer x. We utilize the Keccak256 hash function to implement a keyed random function to generate x. Since the Solidity language does not directly support randomness, we use block properties such as the block’s timestamp.

We leverage the Chainlink oracles [26] to enable communication between our smart contract and the public cloud. We import a Chainlink oracle interface called AggregatorV3Interface to pass the auditing request and retrieve the auditing response from the cloud through the Ethereum Virtual Machine.

In this section, we calculate the computation costs, in seconds, required by the data owner, smart contract, and public cloud for different sizes of data files. Generally, the computational complexity of our proposed scheme is acceptable. The utilization of an oracle interface to connect both the smart contract and the public cloud adds an extra layer of computational complexity. Still, there is no other way to enable a smart contract to interact with an external entity except with blockchain oracles.

For the data owner, we measure the time it takes to encrypt the data file and generate its auditing metadata. We use the AES algorithm with a 192-bit key for data encryption. For metadata, a single modular multiplication operation is required. Fig. 2a shows the computation time in seconds for encrypting a data file and generating its metadata, considering different sizes (in Megabytes) of data files.

For the smart contract, we measure the time it takes to issue an auditing request and verify the auditing response. To issue an auditing request, there is a need to generate a temporary key k and a random integer s in addition to performing a multiplication operation. After generating the request, the smart contract sends it to the cloud through an oracle interface. Once the auditing response is received from the cloud, the contract verifies the response by generating a random integer and performing two modular multiplication operations. Fig. 2b shows the computation time in seconds for issuing an auditing request and verifying the correctness of the received auditing response, considering the data file sizes (in Megabytes). We note that the computation time reported considers the network delay required to pass the auditing request and response from and to the oracle interface. The actual computation would be much less than that if we ignored the network delay.

For the public cloud, we measure the time it takes to compute the auditing response. The cloud needs to first generate a random integer in addition to performing a multiplication operation and a modular multiplication operation. Fig. 2c shows the computation time in seconds for computing the auditing response, considering the data file sizes (in Megabytes).

This section presents the results of the smart contract that we have developed. We first show and discuss the vulnerability assessment results obtained from the Slither security auditing tool. Furthermore, we present the cost associated with deploying and executing the smart contract.

It is crucial to ensure the secrecy of user data, which is stored with a non-trusting entity called Public Cloud Storage (PCS). The primary concern is to prevent unauthorized access to the user’s data by malicious PCSs or attackers while it is stored on the cloud. Additionally, it is important to protect the content of the user’s data during the auditing process at the smart contract. In this section, we discuss how our designed scheme prevents data exposure to unauthorized parties.

Our scheme presents a formidable barrier to malicious parties attempting to access the user’s data. The file is encrypted by the user using symmetric encryption primitives before being uploaded to the cloud, as explained in Section 3.3. Therefore, these malicious parties need knowledge of the secret key, which is securely held by the data owner, to decipher the file and access its contents. As a result, malicious parties are effectively prevented from accessing the user’s data.

Hypothesis. The proposed mechanism prohibits unauthorized malicious parties from accessing the users’ data files stored on the public cloud.

Proof. If a malicious party tries to gain access to the user’s data files stored on the cloud, they will need to have the user’s secret key. This is because all data files in our proposed system are enciphered with the user’s secret key before being uploaded to the cloud. Whenever the secret key is protected from malicious parties, it is not feasible to gain any information about the user’s data.

If a malicious party tries to access the data content from the metadata stored on the smart contract storage, it will not succeed because the verification metadata is computed using the owner’s secret key. Malicious actors, therefore, must obtain the owner’s secret key in order to access the user’s data from the metadata. Moreover, during the auditing process, the smart contract cannot gain knowledge of the data content from the received audit response since the response is not generated from the original data.

Our proposed scheme is highly effective in guarding against data leakage to malicious parties or potential attackers. This robust protection is primarily due to the encryption of the data file before its upload to the cloud.

The proposed scheme permits data owners to verify the integrity of their outsourced data through reliance on smart contracts and blockchain oracles. This section illustrates to what extent the proposed scheme can accurately ascertain data integrity, assuming the honest behavior of PCSs. Subsequently, we will demonstrate the system’s resilience against dishonest PCSs.

Hypothesis. Given that the PCS honestly computes the required auditing response for the auditing request received from the smart contract, the smart contract can deem the auditing response valid. We can show that R_V is equivalent to R_S by utilizing the commutative property of an elliptic curve as follows: RV;=s⋅Vmodn RV=s⋅x⋅Cmmodn RV=s⋅x⋅C⋅Gmodn (8)RV=RS

Hypothesis. The PCS is not able to deceive the proposed system by incorrectly computing the auditing response.

Proof. The PCS may engage in dishonest activity, attempting to deceive the smart contract during the data integrity verification process. Here, we show that it is not feasible to deceive the proposed system by computing an invalid auditing response by discussing two potential malicious behaviors. The first possible malicious behavior is that the PCS may compute R_S without retaining the actual data. However, this is not feasible within our proposed scheme because generating the proof necessitates accessing the encrypted data file to produce a valid response during auditing. The second malicious behavior is that the PCS might consider reusing previous auditing responses as responses to the auditing requests received from the smart contract. Nevertheless, this behavior is impractical because the PCS would need to generate a fresh random integer for every response generated, as discussed in Section 3.3. That is, the PCS cannot use previous responses as they will be rejected by the smart contract as invalid.

In conclusion, it is evident from this discussion that our proposed scheme only accepts auditing responses when the PCSs honestly compute them. Furthermore, our scheme is resilient against any deceptive attempts by the PCSs during data auditing.