In dem Artikel wird ein Blockchain-basiertes, gesichertes Löschsystem (BBAD) für IoT-Daten vorgestellt, das sich den Herausforderungen des Datenschutzes und der sicheren Löschung im Cloud-Speicher widmet. Zentralisierter Cloud-Speicher birgt Risiken des unbefugten Zugriffs und unlauterer Praktiken zur Datenlöschung, die BBAD durch dezentrale Blockchain-Technologie abmildern will. BBAD bietet eine feinkörnige Zugriffskontrolle während der Gültigkeit der Daten und stellt die Löschung der Daten nach Ablauf der Gültigkeit sicher, ohne sich auf vertrauenswürdige Dritte zu verlassen. Das System setzt Shamir Secret Sharing für ein sicheres Datenmanagement und intelligente Verträge für die öffentliche Überprüfung der Löschung ein. Das System wurde entwickelt, um die Sicherheit zu erhöhen, den Rechenaufwand zu verringern und die öffentliche Verifizierung zu unterstützen, was es für ressourcenbeschränkte Umgebungen wie IoT geeignet macht. Der Artikel diskutiert das Design, die Implementierung, die Sicherheitsanalyse und den Leistungsvergleich des Systems mit bestehenden Systemen und hebt seine Vorteile in Bezug auf Effizienz und Sicherheit hervor.
KI-Generiert
Diese Zusammenfassung des Fachinhalts wurde mit Hilfe von KI generiert.
Abstract
The massive data generated by the Internet of Things (IoT) is often outsourced to the cloud, leading to a separation between data ownership and management. Access control during the data’s validity period and assured deletion once that period expires are both crucial for protecting privacy. While recent research has primarily focused on access control, assured deletion has received less attention. Existing assured deletion schemes can be classified into key-control based and cryptographic policy based methods, but to varying degrees, they have limitations such as requiring a trusted third party, high encryption overhead, lack of support for deletion verification and fine-grained access control. To address these limitations, we propose BBAD, a blockchain-based assured deletion scheme that leverages smart contracts for fine-grained access control, employs Shamir secret sharing and re-encryption for assured key deletion, and utilizes Merkle Hash Tree (MHT) for public deletion verification. Notably, BBAD eliminates the need for a trusted third party, exhibits low computational overhead, supports customizable deletion time limit, and enables offline verification of deletion for users. Our experimental comparison with two prominent alternatives, Secure Electronic-Document Self-Destructing with Identity-Based Timed-Release Encryption (ESITE) and Key-Policy Attribute-Based Encryption for Assured Deletion (AD-KP-ABE), demonstrates that BBAD reduces data processing time by over 46.5%, data deletion time by 98.4%, and deletion verification time by 99.0%.
Hinweise
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
1 Introduction
Centralized cloud storage is essential for managing massive personal IoT data and supporting edge computing for data processing and analysis. However, it poses challenges due to the inherent separation between data ownership and management. This separation has raised concerns regarding access control and the assured deletion of outsourced data. Outsourced storage providers may grant excessive permissions to malicious users or secretly retain data after claiming it has been deleted, leading to potential privacy breaches [1, 2]. The complexity arises when holding cloud servers accountable for potential data breaches and ensuring compliance with regulations, such as the General Data Protection Regulation (GDPR), in cases of fraudulent data deletion practices [3].
Data security in the IoT affects numerous fields, including healthcare, industrial applications, and smart homes. Taking electronic healthcare as an example in the real world, health monitoring devices collect large amounts of personal health information, which is outsourced for storage. Doctors access this data when creating electronic medical records. If unauthorized users gain access to this data, it can lead to a breach of privacy. When users request to delete their health information, they may worry that the data storage providers have not deleted it as requested. Therefore, in electronic healthcare scenarios, access control and assured data deletion of outsourced data are pressing issues that need to be addressed.
Anzeige
In recent years, edge and fog computing have emerged as effective solutions to address the demands for low-latency and high-security scenarios in the IoT [4‐6]. However, in fog computing, data is still outsourced and stored in fog nodes. Edge computing stores and processes data on edge devices. However, due to the limited resources of these devices, large volumes of data must still be uploaded to the cloud for long-term storage, backup, and further analysis. Therefore, data access control and assured deletion are also crucial in edge and fog computing.
Recently, research on data protection in the IoT has flourished, particularly emphasizing blockchain technology, which is increasingly utilized for its decentralized, auditable, and tamper-proof characteristics to achieve fine-grained access control [7‐9] and privacy protection [10, 11]. Conversely, there is a noticeable lack of attention to assured data deletion, and virtually no research has explored the application of blockchain for assured deletion, which provides a primary motivation for our research.
Existing assured deletion schemes can be broadly classified into key-control based and cryptographic policy based methods. Key-control based schemes store encrypted data in a third party, achieving data deletion by destroying the key. Cryptographic policy based schemes associate ciphertext or keys with access control policies, achieving data deletion by modifying or revoking these policies.
Initial proposals for key-controlled assured data deletion relied on centralized servers [12‐18]. However, these systems were susceptible to dishonest key deletion by the servers, and the risk of key theft or mandatory access by authoritative institutions remained [19]. To mitigate these concerns, distributed key management was introduced, aiming to prevent centralized server-induced inconsistencies with user policies [20‐28]. Distributed Hash Table (DHT) networks like Vuze [29] and other distributed infrastructures [30] provided potential solutions for distributed key-value storage. However, these systems relied on fixed key validity periods for their self-destructing or self-revocable data solutions.
Anzeige
Cryptographic policy based schemes associate data or keys with access control policies. When policies are modified or revoked, access is denied, thereby ensuring assured data deletion. Identity-Based Encryption (IBE) [31] and Attribute-Based Encryption (ABE) [32, 33] provide practical cryptographic frameworks for self-destructing data. Once all users are unauthorized due to attribute changes or policy revocation, the data is considered deleted [23‐27]. However, IBE and ABE, known for their computationally intensive operations, such as scalar multiplication in Elliptic Curve Cryptography (ECC) and bilinear pairing, which are equivalent to thousands of Advanced Encryption Standard (AES) operations, may not be cost-effective for assured deletion. In contrast, symmetric encryption, with its lower computational overhead, can offer a more practical solution when combined with effective key management.
In summary, both categories of existing schemes exhibit certain limitations to varying degrees:
A trusted third party is required. However, in practice, it is challenging to identify a truly reliable third party, and such a party is vulnerable to attacks, resulting in a potential single point of failure.
It does not support fine-grained access control during the data’s validity period.
The encryption and decryption algorithms involve complex computations and incur significant time overhead.
It does not support public verification after data deletion.
Additionally, the aforementioned schemes necessitate storing the key with a third party, which introduces certain security risks. Blockchain-based storage systems, as discussed in studies such as [34‐37], offer promising solutions for secure data management. However, these approaches frequently face performance bottlenecks. The primary challenge stems from the inherent transparency of blockchain and its scalability limitations, particularly when managing a large user base. Notably, whether in permissioned or permissionless blockchain architectures, directly storing secret keys on the blockchain is infeasible for confidentiality.
Therefore, developing a method that combines reliable, fine-grained blockchain-based access control with the efficient DHT-based data storage holds considerable potential as a viable solution. Our research motivation is to introduce blockchain technology into the domain of data assured deletion to overcome challenges such as the lack of fine-grained access control and deletion verification in key-control based deletion schemes, as well as the reliance on trusted third parties and the high encryption overhead in cryptographic policy based schemes.
To address these challenges, we propose a blockchain-based assured deletion (BBAD) scheme that enables fine-grained access control during the data’s validity period. BBAD ensures data deletion after expiration without relying on a trusted third party or complex cryptographic techniques such as bilinear pairing, while also supporting public verification of deletion. This innovative approach simplifies the process and enhances efficiency.
Our contributions are summarized as follows:
1.
We propose a smart contract-based fine-grained access control scheme that eliminates the need for a trusted third party to make authorization decisions. This approach provides granular control over data access during its validity period.
2.
We propose a blockchain-based assured deletion scheme that employs Shamir secret sharing [38] to securely divide and manage ciphertext and keys, allowing the data owner to set a custom deletion time limit. By design, the incomplete ciphertext stored on the cloud server inherently resists ciphertext analysis and brute-force attacks.
3.
We propose a public verification mechanism after deletion using smart contracts and MHT [39]. This method outperforms existing deletion verification schemes by enabling verification even when the data owner is offline and transferring the verification process to the smart contract, thereby reducing the data owner’s burden.
4.
We implement a prototype of this scheme and benchmark its performance against ESITE and AD-KP-ABE, two prominent representatives of their respective categories. The results demonstrate that BBAD reduces time costs by more than 46.5% in data processing, 98.4% in data deletion, and 99.0% in deletion verification.
The remainder of the paper is organized as follows. In Sections 2 and 3, we review some related works and preliminaries. In Section 4, we present the system model, adversary model, premise assumptions and design goals of this scheme. In Section 5, we describe the implementation of the scheme in detail. In Section 6, we present the security analysis of BBAD. In Section 7, we present the performance comparison with existing schemes. In Section 8, we summarize the paper.
2 Related work
The existing literature on assured data deletion can be broadly categorized into two main approaches: key-control based approaches [12‐15, 17, 20‐28] and cryptographic policy based approaches [16, 40, 41]. Key-control based approaches involve encrypting data and entrusting it to a third party, ensuring deletion by permanently destroying the decryption key. In contrast, cryptographic policy based deletion relies on associating data or keys with access control policies. By altering or revoking these policies, it prevents unauthorized access to the data.
2.1 Key-control based data deletion
The initial implementation of key management relied on a centralized server, as demonstrated by Perlman’s proposal [13]. Perlman recommended entrusting keys to an ephemeral server, Ephemerizer, which would delete the keys upon reaching a predefined expiration time. However, this approach exhibited significant dependence on the third-party server, raising concerns about a single point of failure due to potential attacks on the centralized server. Additionally, the server’s honesty in deleting keys was not guaranteed, as it could be compromised by attackers or coerced by authoritative entities into retaining the keys.
As a result, distributed key management has attracted significant attention from researchers. Geambasu’s pioneering work introduced an assured deletion scheme based on DHT, as exemplified by the Vanish prototype system [20]. Vanish split keys using Shamir’s threshold secret sharing technique and distributed the components across different DHT network nodes. The system leveraged the DHT nodes’ inherent property of periodically purging data to eliminate key components, ensuring the irreversibility of the keys. However, Wang et al. found a vulnerability in Vanish’s data storage, as it stored complete ciphertext, making it susceptible to cryptanalysis and brute force attacks upon access.
To address this issue, Wang et al. proposed a secure self-destructing scheme for electronic data (SSDD) [21], which refined the original approach by coupling and extracting the ciphertext for storage. In SSDD, the extracted ciphertext was securely shared along with the key and distributed across the DHT network. This method ensured that the data storage entity retained transformed, incomplete ciphertext, thereby improving resistance against such attacks.
However, the inherent properties of the DHT network make it vulnerable to Sybil attacks [42], which typically involve two primary strategies: port manipulation and key sniffing. In a Sybil attack, an attacker can periodically change their ports to infiltrate the network and capture specific key components. Simultaneously, they can intercept the transmission of the key components. These tactics enable the attacker to potentially accumulate enough key components to reconstruct the key before its destruction, thereby posing a significant security threat.
To mitigate Sybil attacks, researchers have proposed several innovative solutions. Yao et al. introduced ESITE [28], an extension of SSDD, which initially applied IBE to the key. This approach generated key components that were distributed across the DHT network. Even if an attacker obtained a sufficient number of components, they would only be able to decrypt the IBE-encrypted ciphertext, rather than the original key. Similarly, Xiong et al. [27] employed ABE on the key, distributing the original ciphertext and key ciphertext to two separate DHTs and cloud servers after appropriate transformations. This approach also protected against Sybil attacks. However, it still relied on a trusted Key Generation Center (KGC), which introduced a single point of failure. Additionally, both IBE and ABE, due to their reliance on group operations and bilinear pairings, incurred significant computational overhead.
Tian et al. proposed an efficient and secure cloud data deletion scheme (SDUS-AD) [43] that supported dynamic data updates in multi-copy scenarios. However, this scheme lacked fine-grained access control for data, and the search efficiency of the multi-copy association tree required further improvement.
2.2 Cryptographic policy based data deletion
Tang et al. introduced the Secure Overlay Cloud Storage with File Assured Deletion (FADE) scheme [16], where each file was initially encrypted with a data key, which was then protected by a control key associated with access control policies. File deletion in FADE was accomplished by revoking the policy associated with the control key. However, FADE relied on a centralized key manager and employed complex public-key cryptography. Subsequently, more robust deletion methods leveraging ABE were developed. ABE integrates policies and attributes into ciphertexts or keys, allowing only authorized users with specific attributes to access data. By formulating policies and enabling policy revocation or attribute modification, ABE provides fine-grained data access control and assured deletion.
Xue et al. presented the AD-KP-ABE scheme [40], which built upon Key Policy Attribute-Based Encryption (KP-ABE). In this scheme, policies were embedded in keys, while attributes were incorporated into ciphertexts. By modifying the “availability” attribute in the ciphertext, the data became inaccessible to all users. The authors also employed MHT for data owners to verify deletion results. However, this scheme necessitated the involvement of a trusted authority acting as KGC, to generate and distribute keys for users, which was susceptible to attacks and triggered a single point of failure.
Abinaya et al. [44] proposed a Cloud-based Scalable Secure Unique Data Deletion and Verification (CSSDV) policy, which employed Ciphertext Policy Attribute-Based Encryption (CP-ABE) for fine-grained, secure data deletion and verification. The CSSDV system efficiently deleted cloud data by utilizing attribute association trees and rule transposition techniques, and subsequently verified deletion by revoking attributes and re-encrypting the key. However, this approach still necessitated the involvement of a trusted authority.
Tian et al. introduced the Secure and Effective Assured Deletion with Orderly Overwriting (SEAD-OO) scheme [45]. Leveraging CP-ABE, the scheme provided fine-grained access control and secure data sharing. To mitigate the issue of residual ciphertext in the cloud following key deletion, the authors distinguished between logical and physical deletion. Logical deletion involved updating access control policies and revoking keys to modify data access rights, while physical deletion occurred upon the final data owner’s request, ensuring complete removal of the ciphertext from the cloud. However, the blockchain was only involved in the deletion and verification processes, and the encryption and decryption costs remained high.
Tian et al. [46] also introduced an assured deletion scheme that integrated multilevel security principles and dynamic sliding window technology to enhance fine-grained access control. The scheme employed CP-ABE for encryption and decryption. However, similar to the previously discussed ABE-based schemes, this approach relied on a trusted third party and incurred substantial overhead during ABE computation.
We compared the key technologies, main contributions, advantages, and disadvantages of typical assured deletion schemes, as summarized in Table 1.
more fine-grained data access and deletion control
need trusted authority and expensive encryption
Yes
Yes
Yes
2.3 Blockchain based access control
Recent advancements have led to a surge in blockchain-based access control solutions, providing a valuable reference for integrating blockchain technology into data assured deletion processes.
Gong et al. proposed a secure and dynamic access control scheme (SDACS) for the IoT [7], achieving decentralized and fine-grained access control by combining off-chain message authentication with on-chain access control permission verification. However, this scheme may inadvertently leak information about attributes during the permission verification process. Usman et al. [8] proposed an improved role-based access control (RBAC) framework that utilized hyperledger blockchain to meet Industrial IoT (IIoT) requirements, and reduced computational overhead. However, RBAC systems were limited by issues such as role explosion and the manual assignment of roles to network nodes. Additionally, as the network expanded, RBAC systems became increasingly susceptible to policy conflicts. Saha et al. proposed a new smart contract based access control framework for 6G-enabled blockchain to assist healthcare systems (SACS) [9]. However, this scheme had not been tested in a real-world environment to evaluate the operational performance of the deployed access control mechanism.
Additionally, studies [47‐49] have also proposed block-chain based access control models for the IoT, focusing on the security of data within its validity period. However, although the issue of assured data deletion is equally important, these studies have not focused on it. While the problem of assured deletion is precisely the focus of the model we propose. Additionally, [49] employed ECC, while [48] utilized CP-ABE and required a trust authority. In contrast, our solution relies solely on symmetric encryption and hash functions, without the need for a trusted third party.
In summary, existing assured deletion schemes exhibit the following issues to varying extents: reliance on trusted third parties, insufficient support for fine-grained access control, high encryption and decryption overhead, and lack of deletion verification. Existing blockchain-based access control schemes lack attention and research on the issue of assured data deletion. Furthermore, blockchain-based data storage solutions are constrained by scalability limitations, and in our scenario, keys cannot be stored directly on the blockchain. To resolve these challenges, we employ distributed storage servers and Shamir secret sharing to eliminate the need for trusted third parties, and remove the requirement to store keys on the blockchain. We employ smart contracts and attribute-based access control (ABAC) to enable fine-grained access control, apply symmetric encryption and lightweight hash algorithms to reduce encryption and decryption costs, and utilize smart contracts and MHT to verify deletion.
3 Preliminaries
3.1 Shamir secret sharing
The Shamir secret sharing scheme, a cryptographic technique, divides a secret into distinct components and distributes them among multiple participants for secure storage. The secret can be reconstructed only if specific conditions are satisfied. The procedure entails:
1.
Let s denote the secret, n the number of partitions for splitting, and t the threshold value. The secret distributor then constructs a polynomial of degree \(t-1\):
Once \(f_t(s, x)\) is obtained, the secret can be obtained by \(s=f_t(s, 0)\).
3.2 Blockchain
Blockchain is an innovative and transparent distributed ledger and embodies decentralized, tamper-proof, and traceable characteristics. Its architecture, organized in a hierarchical manner, consists of six fundamental layers: data layer, network layer, consensus layer, incentive layer, contract layer, and application layer, each playing a distinct role in facilitating secure and efficient operations.
Blockchain operates on a trustless model, where users do not rely on individual nodes or centralized authorities. Its consensus mechanism ensures secure and stable transactions in the absence of central control and inter-node trust. Each node, driven by self-interest, adheres to predefined rules, verifying the authenticity of records and selectively incorporating them into the blockchain.
The consensus mechanism is pivotal to blockchain’s functioning, and enables honest nodes to maintain a unified view of the ledger by granting bookkeeping privileges to nodes meeting specific criteria. These nodes record transactions, broadcast them, and subsequently, other nodes verify their validity, appending the block to the blockchain.
3.3 Merkle hash tree
Merkle Hash Tree (MHT) is a prevalent data structure that facilitates the verification of data integrity within a collection. This tree, either binary or multi-nary, is constructed through a specific methodology:
1.
A leaf node is a hash value of a data in a set.
2.
A non-leaf node is a value that undergoes further hashing following a specific computational process by its all child nodes.
Ultimately, by verifying the value of the root, the integrity of this set of data can be verified, which is computationally efficient.
4 System design
In this section, we present the system model, adversary model, premise assumptions, and design goals of the BBAD scheme.
Fig. 1
The system model
×
4.1 System model
We assume that the cloud server functions as an outsourced third party for data storage. The system model is illustrated in Fig. 1. The BBAD scheme comprises five entities: data owner, data user, cloud service provider (CSP), a distributed storage server cluster, and blockchain. Consider the electronic healthcare scenario discussed in Section 1, where patients serve as data owners, doctors as data users, and CSP is responsible for storing health information. Health monitoring devices upload users’ health data to CSP. The user expects that only authorized doctors can access this data, and upon the user’s request for deletion, the CSP is expected to permanently delete it, ensuring that no one can access it thereafter. Next, we will provide a detailed introduction to each entity.
The data owner initiates the process by encrypting the original data and splitting the ciphertext into two parts. One part is transformed into secret components, along with the encryption key, using the Shamir secret sharing algorithm, and uploaded to distributed storage servers. The other part is stored on the cloud server. To enforce access control, the data owner configures a policy that restricts access to users meeting specific criteria during the data’s validity period. Concerned about the honesty of CSP and storage servers in deleting data upon expiration, the owner seeks publicly verifiable deletion evidence. After uploading the necessary information to the blockchain, the data owner no longer needs to remain online for deletion verification. Instead, a smart contract on the blockchain automatically performs the verification and records the outcome, even when the owner is offline.
The data user possesses a set of attributes. When a user with specific attributes requests access, they initiate an access request to the blockchain. Upon successful validation of the user’s attributes against the data’s access control policy, the blockchain generates and stores a token, returning an index of the designated storage server. Using the token, the user retrieves the key components and ciphertext components from the server, combines them with the remaining ciphertext from the cloud server, and decrypts the full ciphertext using the key to obtain the original data. Once the data owner’s deletion time limit is reached, access is denied to all users.
The CSP utilizes its extensive computing power and resources to offer cost-effective and convenient storage solutions. However, concerns have been raised about the CSP’s honesty in data deletion, as they may retain user data for ulterior motives, despite claims not. To mitigate this issue, the BBAD scheme employs a strategy in which the CSP stores only partial ciphertext, ensuring that even if the data is compromised, an attacker cannot retrieve the original content.
The distributed storage server cluster is employed to store both key components and ciphertext components. Upon receiving an access request, the servers query the blockchain for the user’s access token. If the token is valid, they release the corresponding secret components. Once the predefined deletion time limit is reached, the servers re-encrypt the secret components, hash the re-encrypted data, and upload the hash values to the blockchain as evidence of deletion. The distributed architecture inherently enhances security by preventing single points of failure. Each server stores a single secret component, and the Shamir secret sharing scheme ensures that reconstructing the ciphertext and key requires compromising a threshold number of servers, thereby providing resilience. Even if an attacker successfully obtains a subset of secret components through Sybil attacks, the key cannot be reconstructed unless the threshold is exceeded.
Blockchain’s inherent properties, such as immutability and traceability, enable it to serve as a decentralized database for securely storing critical data, including deletion time limit, access control policies, and evidence of data deletion. It also utilizes smart contracts to facilitate access control authorization and enable public verification of data deletion. The BBAD scheme consists of two smart contracts: the Access Control Contract (AC) and the Deletion Verification Contract (VC). AC performs tasks like policy upload and query, retrieval of user attributes, authorization decisions, and access token upload and query. VC, on the other hand, handles tasks like deletion time upload and query, hash value storage for re-encrypted secret components, MHT construction, and verification by comparing root values. Once an attacker attempts to steal secret components through Sybil attacks, the contract AC will compare the attacker’s attribute information with the policies defined by the data owner to make authorization decisions. These attributes and policies are stored on the blockchain in a tamper-proof manner, thereby rendering BBAD resistant to Sybil attacks.
4.2 Adversary model
In BBAD scheme, consider the following possible attacks in the outsourced data storage scenario:
The attacker obtains ciphertext from CSP and performs brute force attack and ciphertext analysis attack on it.
Sybil attacks: during the data’s validity period, the attacker tries to steal the key components and ciphertext components from distributed storage servers, and then reconstructs the key and ciphertext.
Upon reaching the pre-configured deletion time limit, distributed storage servers may not honestly delete the key components and ciphertext components, thereby posing a latent risk of data breaches.
4.3 Premise assumptions
To provide a more precise description of BBAD’s working scenarios and functionality, the following assumptions are made:
The data owner and authorized users are considered trustworthy and are unlikely to intentionally disclose the plaintext, ciphertext, keys, or related information.
The transmission channel of data is trustworthy and the data will not be stolen or corrupted when it is transmitted between the user, the CSP, and the storage server.
CSP and distributed storage servers are semi-honest. They do not actively leak data, but may fail to perform deletion operations honestly, exposing data to the risk of leakage.
The storage server will honestly send the relevant secret component to the authorized data users over a secure channel based on the decision information from the blockchain.
Fig. 2
Sequence diagram of the Workflow of BBAD. The interaction steps in Fig. 1 are shown in this figure and labeled with lowercase English letters corresponding to Fig. 1
×
4.4 Design goals
The BBAD scheme is expected to achieve the following goals:
Fine-grained access control
During the data’s validity period, access is strictly regulated for users, ensuring that only those meeting predefined criteria can gain access. User authorization is carefully designed to consider their attribute information, preventing excessive permissions and enabling fine-grained access control.
Data assured deletion
Once the predefined deletion time limit has passed, the original data becomes inaccessible to all parties, including potential attackers. Even if an attacker gains unauthorized access to the cloud or storage servers, the data remains securely protected and unobtainable.
Data deletion verification
Upon completion of the data deletion process by the distributed storage server, verifiable deletion evidence is generated. This ensures that both the data owner and other stakeholders can authenticate the deletion, thereby fostering trust in the data deletion.
Resistance to attacks
BBAD scheme should be able to resist the attacks proposed in Subsection 4.2.
5 Scheme construction
In this section, we present the workflow and main algorithms of BBAD, followed by a time complexity analysis.
To enable fine-grained access control without relying on resource-intensive cryptographic techniques such as ABE, we have developed a series of smart contracts on the blockchain. These contracts securely store user attribute data and access control policies, protecting sensitive information from unauthorized tampering. When a user requests access to a secret component, the smart contract executes the authorization decision-making process.
Supported by a distributed storage server cluster, our proposed scheme leverages blockchain technology to enable assured deletion. The data owner initiates the deletion process by publishing a predefined time limit on the blockchain. Subsequently, they use Shamir secret sharing scheme to generate secret components from the extracted ciphertext and its corresponding key. These secret components are stored in the distributed storage server cluster, while the remaining ciphertext is uploaded to a cloud server. The storage server retrieves the predefined deletion time limit from the blockchain, re-encrypts the secret component, and ensures its inaccessibility to users, thereby guaranteeing the assured deletion of the data.
To enable public post-deletion verification, the data owner precomputes the root hash of the MHT, using the re-encrypted secret components as leaf nodes. This hash is securely uploaded to the blockchain. Upon deletion, the server holding the secret component submits the hash of the re-encrypted secret to the blockchain as a deletion evidence. The smart contract, upon receiving these hashes, verifies the authenticity of the deletion by reconstructing the MHT, recomputing the root hash, and comparing it with the original hash provided by the data owner.
Fig. 3
The schematic diagram of the ciphertext extraction process
×
5.1 Workflow
The workflow of BBAD is shown in Fig. 2, which consists of the following steps:
Step 1:
The data owner initiates the process by specifying the required parameters, followed by the selection of an encryption algorithm and a hash function.
Step 2:
The data owner encrypts the plaintext M to obtain the ciphertext C by a symmetric encryption algorithm (e.g. AES) using a random key K.
Step 3:
The data owner obtains the extracted ciphertext \(C_E\) and the remaining ciphertext \(C_R\) through the ciphertext extraction algorithm.
Step 4:
The data owner generates key components and ciphertext components, collectively called secret components S, through Shamir secret sharing.
Step 5:
The data owner uploads the deletion time limit, the access control policies, and the root hash of the MHT constructed after re-encrypting the secret components S to the blockchain. The attributes are also uploaded to the blockchain when the data user joins the blockchain network.
Step 6:
The data owner sends the secret components S to the distributed storage server and uploads the remaining ciphertext \(C_R\) to the cloud server.
Step 7:
During the data’s validity period, the data user sends an access request to the blockchain.
Step 8:
The smart contract uses ABAC to make authorization decisions based on the policies uploaded by data owner and the attribute information of the data user. If the policy is met, an access token is generated and uploaded to the blockchain.
Step 9:
The data user requests the secret components from the storage server.
Step 10:
The storage server checks the access token from the blockchain and decides whether to return the secret components based on the decision result of the smart contract.
Step 11:
The data user requests the remaining ciphertext from the CSP.
Step 12:
The CSP returns the remaining ciphertext to the data user.
Step 13:
The data user reconstructs the key and full ciphertext through Shamir secret sharing and decrypts it.
Step 14:
Upon reaching the deletion time limit, each storage server re-encrypts the secret component and hashes the ciphertext, then uploads the hash value as a deletion evidence to the blockchain.
Step 15:
Once the blockchain receives all the deletion evidences, the smart contract constructs the MHT and compares the root hash with the original one uploaded by the data owner to verify the data deletion.
5.2 Main algorithms
The BBAD scheme contains the following ten main algorithms. The specific use of several key technologies in the scheme is detailed in the following algorithms, including symmetric encryption in Encrypt, Shamir secret sharing in SharesGen and Decrypt, ABAC in Authorization, and MHT in Verify.
Setup (\(\kappa \), fname)
Given the system’s security parameters \(\kappa \) and the unique data identifier fname, the algorithm outputs a set of parameters for processing fname. These parameters include the number of secret components n, threshold value t, bits in t sub-blocks that are further divided after each extraction p, extraction times q, two hash functions \(H_1{:}\{0,1\}^*\rightarrow \{0,1\}^m\) and \(H_2{:}\{0,1\}^*\rightarrow \{0,1\}^m\), a symmetric encryption algorithm E like AES, and a randomly generated encryption key K. The system parameters are represented by \(params=(n,t,p,q,H_1,H_2,E,K)\). Note that a higher threshold t enhances security but incurs greater computational overhead. Section 6 provides a detailed analysis. Therefore, the data owner must carefully select an appropriate value for t based on the specific conditions and requirements.
Encrypt (params, K, M)
Given the system parameters, encryption key K and the sensitive data plaintext M with length m of the data owner, the ciphertext C is computed using the encryption algorithm E and key K.
Extract (params, C)
Given the system parameters and the ciphertext C, calculate the extracted ciphertext \(C_E\) and the remaining ciphertext \(C_R\) according to the following steps:
1.
Divide the ciphertext C into bit blocks of size u. If the size of the last block is less than u, add zeros at the end. In this way, the ciphertext C is divided into v bit blocks \((v \ge q)\), denoted as \(C_1,C_2,\ldots ,C_v\).
2.
A total of q extraction operations are performed, with the ith extraction (\(1 \le i \le q\)) involving the first \(p \times t\) bits from the bit block \(C_i\), denoted as \(d_i\). This extracted data is then divided into t sub-blocks, \(d_{[i][0]}, d_{[i][1]}, \ldots , d_{[i][t-1]}\), each having a length of p bits. The cumulative result of \(d_1, d_2, \ldots , d_q\) constitutes the extracted ciphertext \(C_E\).
3.
Each ciphertext block \(C_i\) (\(1 \le i \le v\)), has its residual component \(r_i\), computed as the result of removing \(d_i\) from \(C_i\), denoted as \(r_i = C_i \setminus d_i\). If \(q < i \le v\), \(d_i\) is considered null. The sequence \(r_1, r_2, \ldots , r_v\) collectively constitutes the residual ciphertext \(C_R\).
The schematic diagram of the ciphertext extraction process is shown in Fig. 3.
SharesGen (params, \(C_E\), K)
Given the system parameters, the extracted ciphertext \(C_E\) and the key K, the key K is initially divided into t bit blocks \(K_0,K_1,\ldots , K_{t-1}\). \((q+1)\)\((t-1)\)-degree polynomials are constructed using Shamir secret sharing scheme as follows:
Randomly select n distinct natural numbers, \(x_1, x_2, \ldots , x_n\), and substitute these values into each of the \((q+1)\) polynomials derived previously. This process yields the secret component \(S=\{s_1, s_2, \ldots , s_n\}\), where \(s_i = \{x_i, F_1(x_i), F_2(x_i),\)\( \ldots , F_{q+1}(x_i)\}\).
DataUpload (fname, params, S, \(C_R\))
Given the system parameters and the secret component S, a random locator L is chosen as the seed for the random number generator. The generator is then employed to produce n distinct secret component storage indexes, denoted as \(l_1, l_2, \ldots , l_n\). Upload the secret component \(s_i\) together with data identifier fname to the storage server corresponding to index \(l_i\), and upload the remaining ciphertext \(C_R\) together with data identifier fname to the CSP.
InformationUpload (fname, params, DT, P, R, L)
The data owner sets a deletion time limit DT for the data fname and formulates attribute-based access control policies P. Prior to uploading, the data owner locally re-encrypts each secret component using a lightweight hash function, as the objective is to irreversibly destroy the data and no decryption is needed. Subsequently, the data owner constructs an MHT for the re-encrypted components and computes its root value, denoted as R. The data owner then prepares the necessary parameters, params, along with DT, P, R, fname and the random locator L, and uploads them to the blockchain. Once this procedure is completed, the data owner is no longer required to maintain constant online connectivity.
Authorization (fname, ATT)
Upon receiving an access request from a data user within the data’s validity period, the smart contract retrieves the user’s attribute set ATT, and the access control policies P of the data file fname. The user’s attributes ATT are stored on the blockchain upon joining the network. The smart contract employs ABAC to evaluate if the user’s attributes align with the policies. A policy consists of four components: subject attributes (SA), object attributes (OA), behavioral attributes (BA), and environmental attributes (EA). For instance, a policy can be represented in the following format, with the specific content customizable by the data owner.
Where userName, role, userLevel respectively represent the user’s name, role and security level. The data file to be accessed is identified by fname and its security level is represented by fileLevel. The user’s intended action operation is specified as “read” in this context. limitTime signifies the privilege’s validity period following authorization. When user userName initiates a request for operation on data fname, they may receive temporary permission with a validity period of limitTime if there exists a policy that aligns with their role and their security level surpasses the data’s. Upon authorization, the smart contract returns the data locator L, and generates an access token (token = {userName, fname, endTime}), which is then uploaded to the blockchain. This token specifies the time frame during which user userName is authorized to access fname. The data’s policy set may consist of multiple policies, and an access request is granted if any one of these policies is satisfied.
Decrypt (fname, params, \(C_R\), L)
During the data’s validity period, an authorized user retrieves the residual ciphertext \(C_R\) from the CSP and acquires the data locator L from the blockchain. They then compute the indexes of the n storage servers based on L. The data user selects a subset of t servers to obtain the corresponding secret components and employs Lagrangian interpolation to construct the \((q+1)\)\((t-1)\)-degree polynomial, resulting in the extracted ciphertext \(C_E\), and the decryption key K. Merging \(C_E\) with \(C_R\) recovers the original ciphertext C, and decryption using K yields the plaintext M.
ReEncrypt (fname, params, \(s_i\))
Upon reaching the predefined deletion time limit DT, each storage server applies the data owner’s designated encryption algorithm to the secret component \(s_i\). Since re-encryption is used to delete the data without requiring decryption, a lightweight one-way hash function is sufficient. The server employs hash function \(H_1\) to encrypt \(s_i\) into \(s_i^{\prime }\), and subsequently computes the hash value \(hs_i\) of \(s_i^{\prime }\) using \(H_2\). This hash value is then recorded as a deletion evidence on the blockchain.
Verify (fname, hs, R)
Once the blockchain receives the deletion evidence, denoted as hs (\(hs = \{hs_1, hs_2, \ldots , hs_n\}\)), the smart contract constructs an MHT with each \(hs_i\) as a leaf node and computes its new root value \(R^{\prime }\). The public verification of deletion is then conducted by comparing \(R^{\prime }\) with the root value R, initially uploaded by the data owner. This computation is performed by smart contracts, eliminating the need for the data owner to be online and reducing their computational load. The blockchain’s tamper-proof nature ensures security, allowing the data owner to investigate any discrepancies by comparing the pre-calculated re-encrypted secret components with the blockchain-stored deletion evidence from the storage servers. This enables identification of servers that have not honestly deleted the secret component.
In these algorithms above, Setup, Encrypt, Extract, SharesGen, DataUpload and InformationUpload are performed by the data owner, Decrypt is performed by the data user, Authorization and Verify are performed by the smart contract, and ReEncrypt is performed by the distributed storage server.
In Algorithm 1 to 4, we have detailed the operations in BBAD and how the primary algorithms discussed earlier are invoked.
5.3 Time complexity analysis
In this section, we discuss the time complexity of the above calculation process. We divide the workflow of BBAD into three phases: data processing, data deletion, and data deletion verification.
Algorithm 1
Data Processing.
×
Algorithm 2
Data Access.
×
Algorithm 3
Data Deletion.
×
Algorithm 4
Deletion Verification.
×
Data processing
This phase involves a series of data processing steps performed by the data owner before uploading the data. These steps include Encrypt, Extract and SharesGen, as outlined in the algorithms above. Encrypt employs symmetric encryption, and its time complexity is linearly proportional to the data length m, i.e., O(m). Extract requires two layers of loops for q extractions, extracting t sub bit blocks for each bit block, with each sub bit block having a length of p. The time complexity of this process is linearly related to q, t, and p, i.e., O(qtp), which can be approximated as O(m). SharesGen necessitates three layers of loops to select n distinct natural numbers and substitute them into \((q+1)\)\((t-1)\)-degree polynomials for calculation. The time complexity of this process is linearly proportional to n, q, and t, i.e., O(nqt). The above three algorithms are executed sequentially, resulting in a time complexity of \(O(m)+O(nqt)\) for the data processing process.
Data deletion
This phase involves re-encrypting the secret component using a hash function by storage servers, which refers to algorithm ReEncrypt. Due to the form of the secret component being \(s_i = \{x_i, F_1(x_i), F_2(x_i), \ldots , F_{q+1}(x_i)\}\), where the length of \(F_j(x_i)\) (\(1 \le j \le q+1\)) is constant, the length of \(s_i\) is only related to q. We use a hash algorithm to re-encrypt \(s_i\), and the time complexity of this process is linearly proportional to the length of \(s_i\), i.e., O(q).
Data deletion verification
This phase necessitates the data owner to hash the secret components and compute the MHT’s root hash. The smart contract compares this hash with the root hash derived from the deletion evidences provided by the storage servers. This process mainly corresponds to the Verify algorithm mentioned above. The time complexity of hashing the secret components is directly proportional to the length and quantity of the secret components, i.e., O(qn). Since the MHT used is a binary tree, the number of layers is \(\log {n}\). The process of merging hash values from bottom to top involves processing \(\frac{n}{2^k}\) nodes on the k-th layer. Since the complexity of merging two hash values is constant time, the time complexity of the entire verification process is \(O(qn\log {n})\).
6 Security analysis
In this section, we analyze the security of BBAD and compare its functionality with two typical mechanisms, ESITE and AD-KP-ABE, and two state-of-the-art mechanisms, SEAD-OO and the scheme [46].
Assume that the attacker obtains the ciphertext from the CSP. The CSP retains the remaining ciphertext \(C_R\), which consists of the unextracted portions of the original ciphertext. As a result, the attacker is unable to obtain the complete ciphertext C, thereby protecting against brute-force and cryptanalysis attempts.
If an attacker attempts to carry out a Sybil attack in order to steal secret components during the data’s validity period, the data owner’s ABAC policies, predefined in a smart contract, ensure that access is granted only when the user’s attributes align with the policy. These policies, along with user attributes and access tokens, are securely stored on the blockchain and prevent tampering. Furthermore, our implementation of Shamir secret sharing scheme protects the data by requiring the attacker to possess at least t secret components for reconstructing the extracted ciphertext \(C_E\) and key K. The data owner can enhance security by raising t, but this comes at the cost of greater computational overhead.
If a storage server fails to delete the secret component as intended after reaching the predefined deletion time limit, the BBAD scheme requires the server to provide verifiable evidence of deletion. This evidence is then stored on the blockchain and verified by a smart contract. The blockchain’s tamper-proof nature ensures that any failed verification can be traced back to the responsible server by examining the blockchain records.
Table 2 presents a comparative analysis of BBAD with ESITE, AD-KP-ABE, SEAD-OO and scheme [46] in terms of functionality and security. ESITE is a representative scheme for key-control based assured deletion and AD-KP-ABE is a representative scheme for cryptographic policy based assured deletion. SEAD-OO and scheme [46] are both state-of-the-art mechanisms.
The other four schemes necessitate the involvement of a trusted third party acting as a KGC or authorization agency, which is susceptible to attacks and represents a single point of failure. In contrast, BBAD eliminates this dependency by incorporating blockchain technology and distributed storage servers. ESITE lacks fine-grained access control, whereas AD-KP-ABE, SEAD-OO, and scheme [46] achieve it through ABE, though at a significant cost in encryption and decryption overhead. BBAD, however, implements fine-grained access control using smart contracts and ABAC, relying on lightweight symmetric encryption and hash algorithms. In terms of deletion verification, ESITE lacks an associated mechanism, making it impossible to verify deletion outcomes. BBAD and the other three ABE-based schemes use MHT for deletion verification, ensuring that data storage providers honestly delete data. Furthermore, BBAD stores deletion evidence on the blockchain, and the tamper-proof nature of the blockchain guarantees traceability to servers that fail to delete data honestly.
We also analyze the security of the main algorithms: symmetric encryption, secret sharing, and re-encryption.
Symmetric Encryption
The symmetric encryption procedure in this scheme involves not only encryption of data with a random key but also multiple extractions of the encrypted ciphertext. A brute-force attack on the algorithm necessitates access to the entire ciphertext, while the remaining ciphertext \(C_R\) stored in the CSP consists of incomplete data blocks. Consequently, the key space for this encryption method is not solely determined by the length of the random key K (denoted as \(L_1\)), but also by the length of the extracted ciphertext \(C_E\) (denoted as \(L_2\)). This extension of the key space from \(2^{L_1}\) to \(2^{L_1+L_2}\) significantly boosts the security of the employed symmetric encryption mechanism and enhances its resilience against brute-force attacks.
Secret Sharing
The secret sharing mechanism, as depicted in Eq. 4, involves the generation of \((q+1)\)\((t-1)\)-degree polynomials, with each secret component represented as \( s_i = \{x_i, F_1(x_i), F_2(x_i), \ldots , F_{q+1}(x_i)\} \). Given their identical reconstruction procedures, we will analyze the first polynomial in detail, where the coefficients of each term and the constant term correspond to the extracted ciphertext. Reconstructing the extracted ciphertext is the process of solving a system of t-ary linear equations. If an attacker acquires w secret components (where \( w < t \)), a \( w \times t \) coefficient matrix can be obtained, whose rank is at most w. Consequently, the system has \( (t - w) \) free variables. Each bit block \( d_{[i][j]} \) (with \( 1 \le i \le q \) and \( 0 \le j \le t-1 \)) has a length of p, hence the attacker’s brute-force attempt to recover the coefficients of the first polynomial requires a search space of \( 2^{p(t-w)} \). Similarly, considering a key K of length \( L_1 \), the attacker’s search space for it is \( 2^{(t-w)L_1/t} \). Decryption is successful only if all extracted ciphertext and the key from the \( (q+1) \) polynomials are recovered. Thus, the total attack space is \( 2^{(t-w)(p*q+L_1/t)} \).
Re-encryption
Since the purpose of re-encryption is to destroy the data and no decryption is required, a lightweight hash function is sufficient. Our implementation utilizes SHA-256, which is known for its one-way nature and robust collision resistance. Even if an attacker gains access to the re-encrypted data, these properties make it virtually impossible to recover the original information.
7 Performance analysis
In the above schemes, SEAD-OO emphasizes the concepts of logical and physical deletion but lacks a detailed discussion of data processing and other procedures. Scheme [46] focuses on dynamic sliding window access control structures, with reported performance comparable to AD-KP-ABE. Based on these considerations, BBAD’s performance is specifically compared to that of ESITE and AD-KP-ABE for a more targeted evaluation.
7.1 Computation cost
Table 3 lists the time overhead of the three schemes ESITE, AD-KP-ABE and BBAD in terms of data processing, data deletion and deletion verification phases. The meanings of the symbols are as follows. \(T_{AES}\) denotes the time of AES encryption, \(T_{extract}\) denotes the time of ciphertext extraction process, H denotes the time of hash computation, \(T_{share}\) denotes the time of generating the secret components, \(T_{del}\) denotes the time of deleting the data in the DHT, \(T_{exp}\) denotes the time of power operation on the group, \(T_{mul}\) denotes the time of multiplication operation on the group, \(T_{add}\) denotes the time of addition operation on the group, \(T_{div}\) denotes the time of division operation on the group, and \(T_{bm}\) denotes the time of bilinear mapping. k denotes the number of attributes, l denotes the number of values of each attribute, m denotes the length of the data, n denotes the number of secret components, t denotes the threshold, and q denotes the extraction times of ciphertext.
Table 4 lists the time complexity of the three schemes ESITE, AD-KP-ABE and BBAD for the three phases of data processing, data deletion and deletion verification.
In practical scenarios, the data size m is often substantial, while the parameters n, t, k, l, and q tend to be smaller. Comparative analysis reveals that BBAD’s time complexity is virtually indistinguishable from the other two schemes, but it does not necessitate group operations. On the other hand, ESITE involves group operations in data processing phase, and AD-KP-ABE involves group operations in all the three phases. Empirical testing has demonstrated that group operations incur time overheads that are two to three orders of magnitude greater than regular operations. Consequently, BBAD exhibits a theoretically lower time overhead, which will be further examined and discussed in the following subsections.
Table 4
Comparison of time complexity
Phase
ESITE
AD-KP-ABE
BBAD
Data processing
\(O(m)+O(nqt)\)
\(O(kl)+O(m)\)
\(O(m)+O(nqt)\)
Data deletion
O(1)
\(O(k\log {k})\)
O(q)
Deletion verification
/
\(O(k\log {k})\)
\(O(qn\log {n})\)
Table 5
The computational cost of BBAD under different data sizes m
Phase
10KB
100KB
1MB
10MB
Data processing
1.36ms
12.79ms
118.98ms
1387.66ms
Data deletion
0.030ms
0.029ms
0.020ms
0.028ms
Deletion verification
0.218ms
0.224ms
0.216ms
0.205ms
We evaluated the computational overhead of BBAD under different data sizes, with the number of ciphertext chunks \(v = 20\), the number of extraction times \(q = 20\), the number of secret components \(n = 20\), the threshold value \(t = 15\), and the data size m, being 10KB, 100KB, 1MB, and 10MB, respectively. As shown in Table 5, the time cost of data processing is approximately linearly proportional to the data size, while the time cost of data deletion and deletion verification nearly remains constant regardless of the data size.
We also evaluated the computational cost of BBAD under different numbers of secret components, with the number of ciphertext chunks \(v = 20\), the number of extraction times \(q = 20\), the data size m = 1MB, the threshold value \(t = 15\), and the number of secret components n, being 20, 40, 60, and 80. As shown in Table 6, as n increases, the computational cost of data processing slowly increases, the computational cost of data deletion remains almost constant, and the computational cost of deletion verification significantly increases, but still remains very small.
Table 6
The computational cost of BBAD under different numbers of secret components n
Phase
20
40
60
80
Data processing
118.98ms
129.10ms
136.56ms
142.80ms
Data deletion
0.025ms
0.034ms
0.031ms
0.024ms
Deletion verification
0.216ms
0.191ms
0.383ms
0.508ms
7.2 Communication cost
The communication cost refers to the time required for data transmission between various entities in the BBAD scheme, which can be measured by the size of the messages that need to be transmitted. In the BBAD scheme, the three phases of data processing, data access, and data deletion involve communication between different entities.
Data processing
The data owner uploads the parameters, the pre-set deletion time, access controls policies, the root value of MHT, and the random locator to the blockchain. The length of these pieces of information is quite small and fixed, denoted as \(L_{info}\). The data owner uploads n secret components (\(s_i = \{x_i, F_1(x_i), F_2(x_i), \ldots , F_{q+1}(x_i)\}\)) to the storage servers. Due to the fixed length of \(x_i\) and \(F_j(x_i)\) (\(1 \le j \le q+1\)), denoted as \(L_{sec}\), the message length transmitted in this process is \(n(q+2)L_{sec}\). Finally, the data owner uploads the remaining ciphertext to CSP. As described in Subsection 5.2, the total length of the data ciphertext is m, the extraction times is q, the threshold for secret sharing is t, and each of the t sub-blocks has a length of p. Therefore, the length of the remaining ciphertext is \(m-qpt\). Based on the above three processes, the communication cost in the data processing phase is \(L_{info}+n(q+2)L_{sec}+(m-qpt)\).
Data access
The communication cost of this process mainly includes each storage server querying the access token from the blockchain, the storage server transmitting the secret component to the data user, and the CSP transmitting the remaining ciphertext to the data user. The length of the access token is also quite small and fixed, denoted as \(L_{token}\). Similar to the data processing phase, the total length of the secret components to be transmitted is \(t(q+2)L_{sec}\), and the length of the remaining ciphertext is \(m-qpt\). Therefore, the communication cost in the data access phase is \(L_{token}+t(q+2)L_{sec}+(m-qpt)\).
Data deletion
The communication cost of this process comes from the storage server uploading deletion evidence to the blockchain. The deletion evidence is a hash value that varies depending on the hash function used, and its length is represented as \(L_{del}\). Therefore, the communication cost in the data deletion phase is \(nL_{del}\).
7.3 Scheme testing
This section evaluates the BBAD scheme’s performance by comparing the time overhead of its three key phases: data processing, data deletion, and deletion verification, against AD-KP-ABE and ESITE schemes. To ensure a fair comparison, all schemes’ algorithms are implemented in a standardized environment: an Ubuntu 20.04 virtual machine equipped with Python 3.8, an 8GB RAM, an i9-12900H dual-core processor, and a 60GB disk. The pypbc library is employed for group operations and bilinear pairing, SHA256 for hashing, and AES for symmetric encryption.
In general, increasing the number of experimental repetitions stabilizes the mean of the results and reduces error. If the number of repetitions is too small, it may introduce greater uncertainty, potentially undermining the reliability of the conclusions. Conversely, using an excessively large number of repetitions can lead to unnecessary time and resource expenditure. Preliminary tests were conducted before the formal experiments, and based on these results, we determined that approximately 20 repetitions are sufficient to achieve stable outcomes. Therefore, to balance resource utilization with result reliability, all experiments were repeated 20 times, and the results were averaged for a more accurate assessment.
Fig. 4
Time overhead of data processing
×
7.3.1 Data processing
For all three schemes, this process refers to a series of operations performed on the plaintext data by the data owner before uploading it to a cloud server or other storage entities. In the ESITE and BBAD schemes, the number of ciphertext chunks \(v = 20\), the number of extraction times \(q = 20\), the number of secret components \(n = 20\), and the threshold value \(t = 15\). In the AD-KP-ABE scheme, the number of attributes is set to be 10, and each attribute has three values. The time overhead is tested when the data size is 10KB, 100KB, 1MB and 10MB respectively.
As depicted in Fig. 4, the time overhead for data processing in all three schemes increases with the data size, with BBAD exhibiting the lowest overhead. AD-KP-ABE’s data processing consists of two stages: key generation and data encryption, which requires complex group and bilinear pairing computations. ESITE’s process involves four steps: data encryption, ciphertext extraction, IBE on key, and ciphertext component creation. BBAD omits the IBE step, thereby reducing its time consumption.
Specifically, with a data size of 10KB, the data processing time of BBAD is reduced by 95.2% and 95.0% relative to AD-KP-ABE and ESITE, respectively. At a data size of 10MB, BBAD exhibits a 10.3% and 10.0% reduction in data processing time compared to AD-KP-ABE and ESITE, respectively. On average, BBAD achieves a 54.6% and 46.5% reduction in data processing time compared to AD-KP-ABE and ESITE, respectively.
Fig. 5
Time overhead of data deletion
×
7.3.2 Data deletion
Data deletion in ESITE is addressed through automatic turnover of the DHT nodes, therefore it is not included in the analysis. The parameters remain consistent with the previous settings. The time overhead assessments for AD-KP-ABE and BBAD are conducted for data sizes of 10KB, 100KB, 1MB, and 10MB, respectively.
As depicted in Fig. 5, the time overhead of data deletion for both AD-KP-ABE and BBAD remain constant across different data sizes. AD-KP-ABE’s deletion time overhead is consistently around 2.8ms, while BBAD’s is approximately 0.03ms, representing a 98.9% reduction. In AD-KP-ABE, data deletion is achieved by generating a re-encryption key to modify the “availability” attribute in the ciphertext and recalculating the MHT root. This process is independent of data size, depends on the number of attributes, and involves computations on groups. BBAD’s data deletion approach involves re-encrypting the secret component with a hash function, which is less resource-intensive than the group operations in AD-KP-ABE. The time overhead of this process is related to the length of the secret component \((s_i=\{x_i, F_1(x_i), F_2(x_i), \ldots , F_{q+1}(x_i)\})\). However, the length of secret component is unrelated to data size and depends only on the number of ciphertext extraction times, denoted as q.
To further investigate, we examined the correlation between data deletion time and ciphertext extraction times q in the BBAD scheme. Data deletion is accomplished by re-encrypting the secret component \((s_i=\{x_i, F_1(x_i), F_2(x_i),\)\( \ldots , F_{q+1}(x_i)\})\) using a lightweight hash algorithm. The computational overhead is only dependent on the length of \(s_i\), i.e. q. Varying the number of extraction times from 10 to 500, the findings are illustrated in Fig. 6. As the number of extraction times increases, BBAD’s data deletion time also rises, yet it remains impressively low. Even at a high count of 500 extraction times, the deletion time for BBAD remains approximately 0.044ms, representing a 98.4% reduction in comparison to AD-KP-ABE.
Fig. 6
Relationship between deletion time and ciphertext extraction times in BBAD
Fig. 7
Relationship between deletion verification time and the number of attributes in AD-KP-ABE
×
×
7.3.3 Data deletion verification
Data deletion verification is not performed in ESITE, so it is not considered. Figure 7 illustrates the correlation between deletion verification time and the attribute numbers in AD-KP-ABE. The figure reveals that AD-KP-ABE’s deletion verification time remains virtually constant across different attribute numbers, maintaining a consistent level of approximately 71ms. The deletion verification process in AD-KP-ABE necessitates the data owner to re-encrypt the “availability” attribute, compute a new MHT root hash using auxiliary verification information, and then compare it with the received hash. This procedure involves complex group operations.
Fig. 8
Relationship between deletion verification time and the number of extraction times in BBAD
Fig. 9
Relationship between deletion verification time and the number of secret components in BBAD
Table 7
The calculation results of all t-values during data processing
Comparative scheme
10KB
100KB
1MB
10MB
AD-KP-ABE
\(-28.57\)
\(-18.91\)
\(-20.56\)
\( -5.62\)
ESITE
\(-23.31\)
\(-11.48\)
\(-3.47\)
\(-5.40\)
Table 8
The calculation results of all t-values during data deletion and deletion verification
Data deletion
Deletion verification
Comparative scheme
\(m=10\)MB
\(q=500\)
\(n=100\)
\(q=500\)
AD-KP-ABE
\(-31.97\)
\(-31.79\)
\(-112.77\)
\(-113.30\)
Note: We selected the parameter values that maximize the time cost of BBAD in the experiment, including data size m, extraction times q, and number of secret components n, in order to verify that the time cost of BBAD is still much lower than the comparative scheme in the worst-case scenario
×
×
In BBAD, data deletion verification necessitates the data owner to hash the secret components and compute the MHT’s root hash. The smart contract compares this hash value with the root hash value derived from the deletion evidences provided by the storage servers. The time consumed in this process is influenced by the extraction times and the number of secret components. The extraction times affect the length of the secret component, while the number of secret components determines the MHT’s size.
Figure 8 illustrates the correlation between deletion verification time and ciphertext extraction times in BBAD, with a fixed number of 20 secret components. The ciphertext extraction times range from 10 to 500, and the results show that BBAD’s deletion verification time increases as the number of extraction times rises. Notably, even with 500 extraction times, the verification time remains around 0.38ms, significantly lower than the 71ms observed in AD-KP-ABE.
It is noteworthy that with 100 extractions, the verification time slightly decreases from 0.245ms to 0.235ms, which may be an outlier caused by systematic errors and does not affect the overall trend. The number of extraction times, q, impacts the length of the secret component, thereby influencing the hash computation time. However, given the minimal variation in q across the experiments, it is likely that this would not lead to observable changes in verification time. Additionally, normal fluctuations in verification time due to systematic errors are plausible.
Figure 9 presents the relationship between BBAD’s deletion verification time and the number of secret components, with a constant of 20 ciphertext extraction times. The number of secret components influences the number of layers in the MHT and the number of hash calculations, thereby impacting the computational overhead of calculating the root hash. As the number of secret components varies from 20 to 100, the deletion verification time in BBAD increases. Similarly, due to the susceptibility of the low time overhead to systematic errors, there is a slight decrease at a secret component of 40. Notably, even at 100 secret components, the verification time remains around 0.7ms, significantly lower than the 71ms in AD-KP-ABE. This disparity arises from the difference in the verification process: BBAD relies primarily on lightweight hash computations, whereas AD-KP-ABE involves group multiplication and hash computations, resulting in a notably shorter verification time for BBAD.
Together, Figs. 8 and 9 demonstrate that the deletion verification time for BBAD is reduced by 99.0% compared to AD-KP-ABE, even under conditions involving a larger number of extraction times and secret components.
7.3.4 Hypothesis testing
To verify whether the above improvement is statistically significant, we conducted hypothesis testing on the results of each comparative experiment. We use the results of BBAD and AD-KP-ABE at a data size of 1MB in data processing as an example for hypothesis testing. \(\mu _1\) and \(\mu _2\) represent the mean time overhead of BBAD and AD-KP-ABE, respectively, while \(n_1\) and \(n_2\) represent the number of data in each set. The running time of a program follows a normal distribution, so we use a two sample left-hand t-test. The null hypothesis is \(H_0:\mu _1-\mu _2 \ge 0\), and the alternative hypothesis is \(H_1:\mu _1-\mu _2 < 0\). The significance level is \(\alpha = 0.05\), and \(n_1 = n_2 = 20\). The calculation formula for the test statistic t is:
$$\begin{aligned} t = \frac{\mu _1-\mu _2}{\sqrt{\frac{s_1^2}{n_1} + \frac{s_2^2}{n_2}}} \end{aligned}$$
(5)
The mean values of the sample data for BBAD and AD-KP-ABE are 118.98 and 201.16, respectively, and the variances are 154.01 and 165.55, respectively. Substituting them into Eq. 5 yields \(t=-20.56\). In all of our experiments, the degree of freedom is \(n_1 + n_2 - 2 = 38\) and the significance level is \(\alpha = 0.05\). Looking up the t-distribution table, the critical value is found to be \(-1.686\). Given that our \(t=-20.56\) is significantly smaller than the critical value, there is sufficient evidence to reject the null hypothesis \(H_0\) in favor of the alternative hypothesis \(H_1\).
We conducted hypothesis testing on other comparative experiments using the same method. As shown in Tables 7 and 8, all t-values are significantly lower than the critical value, indicating the conclusion that BBAD significantly reduces time overhead compared to the other two schemes is not accidental, but has statistical significance.
Fig. 10
Relationship between average latency and concurrent access requests
Fig. 11
Relationship between average throughput and concurrent access requests
×
×
7.4 Blockchain testing
In this section, we construct a Hyperledger Fabric network environment on an Ubuntu 20.04 virtual machine, employing Docker containers to emulate nodes. The network configuration consists of two organizations, each containing two peer nodes. The chosen consensus mechanism is Etcdraft, and the smart contracts are programmed in JavaScript. To evaluate the performance of blockchain operations (reading and writing) and the computational capabilities of smart contracts, we test three representative functions: the time limit upload function addTime, the time limit retrieval function getTime, and the access control decision function getPermission. Using Hyperledger Caliper, we conduct concurrent requests with a maximum of 5000 in parallel, measuring both the average latency and throughput.
Figures 10 and 11 illustrate the average latency and throughput trends respectively for the three functions as the number of concurrent access requests increases. As the concurrency escalates, the average latency typically declines, while the throughput generally rises. Reading data from Hyperledger exhibits slightly lower latency compared to writing, accompanied by higher throughput. This difference arises from the additional steps involved in writing transactions, such as simulating the execution and signing by Endorser peers, sorting and packing by the Orderer, and uploading the block by Committer peers, all of which contribute to increased latency and decreased throughput. The getPermission function exhibits the highest average latency and lowest throughput, primarily due to its more complex authorization process, which requires more logic and computation. Despite this, its performance remains within acceptable limits.
8 Conclusion
Aiming at the problem that the storing party may not honestly perform data deletion operations in data outsourcing storage, we proposed a blockchain-based data assured deletion scheme that enabled fine-grained access control during data’s validity period and ensured data deletion post-expiration without relying on a trusted third party. The scheme also supports public verification post-deletion. Our analysis demonstrates its security of preventing against ciphertext analysis and brute-force attacks, safeguarding against secret component theft and preventing storage parties from not honestly performing data deletion operations. We implemented the core algorithms of ESITE, AD-KP-ABE, and a prototype of BBAD. The time overhead of our scheme is 54.6% and 46.5% less than AD-KP-ABE and ESITE, respectively, in the data processing phase, 98.4% less than AD-KP-ABE in the data deletion phase, and 99.0% less than AD-KP-ABE in the deletion verification phase. Finally, a performance test on the smart contract substantiates the scheme’s feasibility.
Our scheme is well-suited for deployment in resource-constrained environments, such as IoT environments, due to its enhanced security and reduced time overhead. However, we have only implemented a prototype BBAD system and have not yet tested its deployment in a real-world IoT environment. Since blockchain technology is a determinant of our scheme, we anticipate potential challenges such as energy consumption and scalability in real-world scenarios. In future work, we plan to focus on deploying the BBAD system in actual IoT environments. This will involve addressing challenges such as deployment, maintenance costs, and scalability of BBAD. Additionally, we will explore how the system can be adapted to different IoT infrastructures.
Declarations
Ethics approval
All authors certify that no humans or animals are involved in conduct of this study.
Conflict of interest
All authors certify that they have no affiliations with or involvement in any organization or entity with any financial interest or non-financial interest in the subject matter or materials discussed in this manuscript.
Open Access This article is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License, which permits any non-commercial use, sharing, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if you modified the licensed material. You do not have permission under this licence to share adapted material derived from this article or parts of it. The images or other third party material in this article are included in the article’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by-nc-nd/4.0/.
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
