A blockchain-based traceable and secure data-sharing scheme

System model

In this article, we propose a data-sharing scheme with the aim of improving data security and reducing storage pressure on the blockchain. The system architecture consists of four components as shown in Fig. 1.

• IPFS: Provides off-chain storage services to data owners.

• Authorization center: Generates the required parameters and keys for the data owner and the data demander.

• Data owner: Performs attribute encryption operation on data, transmits the data ciphertext to IPFS, and obtains the hash value of the ciphertext.

• Blockchain: Performs ECC encryption on the hash value of the off-chain data ciphertext and records the identity information of both parties involved in the data-sharing to generate a data-sharing log record.

• Data demander: Obtain the encrypted hash value of the data ciphertext from the blockchain, download the data ciphertext from IPFS by decrypting the hash value, and finally restore the original data through attribute decryption.

Data protection method based on attribute encryption

Ensuring secure storage of data is a prerequisite for data-sharing. Symmetric encryption schemes are susceptible to key leakage, while asymmetric encryption schemes suffer from the problem of large encryption and decryption time overhead. Attribute encryption extends asymmetric encryption algorithms, which not only addresses the issue of key leakage in symmetric encryption schemes, but also allows the attribute private key generated for a user to meet the “one-to-many” encryption and decryption requirements. This means that the data encrypted by one user can be decrypted by multiple users, reducing the overall overhead of encryption and decryption. The formal definition of attribute encryption consists of the following four algorithms (Bethencourt, Sahai & Waters, 2007):

• (1) Setup $(1^{\lambda },U)\to (GP,MSK)$: The authorization center sets the security parameter λ and the global attribute set U, and generates the required public parameter GP and master key MSK through the initialization function Setup.

• (2) KeyGen( $Au,MSK$) $\to SK$: The user submits their attribute set Au, and the authorization center outputs the corresponding attribute private key SK for the user through the KeyGen key generation function and the master key MSK.

• (3) Encrypt $(M,GP,T)\to CH$: The data encryption user sets the access structure T and provides the public parameter GP and the data to be encrypted M. Then, the encryption function Encrypt is executed to generate the data ciphertext CH.

• (4) Decrypt $(SK,Au,CH)\to M$: The decryption user uses the attribute private key SK and attribute set Au as inputs to the decryption function Decrypt, which then restores the ciphertext CH to the original data M.

In the attribute encryption system, the access structure specifies which users corresponding to the attribute set can decrypt the data ciphertext. If a user’s attribute set satisfies the attribute set specified in the access structure, then the private key corresponding to this user’s attribute can successfully decrypt the ciphertext. Therefore, we utilize the attribute encryption method to secure the data under the chain, achieving the “one-to-many” encryption and decryption requirements. The flowchart for the off-chain data protection method based on attribute encryption is illustrated in Fig. 2.

First, the authorization center generates the required parameters through initialization operations. Then, based on the attribute set, the authorization center generates the attribute private key for the data demander. The data owner customizes the access structure, specifying the set of attributes required for ciphertext decryption by the data demander, and encrypts the data. Next, the data owner uploads the encrypted data ciphertext to IPFS, obtains the hash value of the data ciphertext for ECC encryption, and records the identity information of both parties of the data-sharing to the blockchain to generate a data-sharing log record. Finally, the data demander downloads the data ciphertext stored in IPFS through the decrypted hash value and decrypts it using its own attribute private key.

On-chain and off-chain collaborative data security storage scheme

Although attribute encryption technology can fulfill the need for “one-to-many” data encryption and decryption, there is a risk of unauthorized data demanders being able to access the ciphertext of the data through the hash value, given that multiple data demanders with the same attributes can exist simultaneously in the system. To address this concern, we suggest encrypting the hash value of the ciphertext using the ECC encryption algorithm. This additional layer of encryption will safeguard the hash value of the ciphertext on the chain, thereby ensuring the security of the data.

ECC is a cryptographic system that relies on elliptic curves and the discrete logarithm problem. Compared to other encryption methods, ECC is known for its superior efficiency and can achieve a high level of encryption security with shorter keys. The elliptic curve E can be defined as (Koblitz, Menezes & Vanstone, 2000):

(1) $$E:y^2+a_{1}xy+a_{3}y=x^3+a_2{x}^2+a_{4}x+a_5$$where $a_i(i=1,2,3,...,5)\in K$ and $\mathrm{\Delta }\ne 0$, K represents the defined rational number field and $\mathrm{\Delta }$ is the discriminant of the elliptic curve equation:

(2) $$\{\begin{array}{cc}\mathrm{\Delta }=-d_2^2{d}_8-8d_4^3-27d_6^2+9d_2{d}_6\hfill & \hfill \\ d_2=a_1^2+4a_2\hfill & \hfill \\ d_4=2a_4+a_1{a}_3\hfill & \hfill \\ d_6=a_3^2+4a_5\hfill & \hfill \\ d_8=a_1^2{a}_5+4a_2{a}_5-a_1{a}_3{a}_4+a_2{a}_3^2-a_4^2\hfill & \hfill \end{array}$$

When Eq. (2) is satisfied by the elliptic curve E, Eq. (1) is referred to as the Weierstrass equation (Falcão et al., 2018). By further simplifying Eq. (2), we can derive the general expression for the elliptic curve:

(3) $$E:y^2=x^3+ax+b$$where $(a,b,x,y)\in Ep$, Ep is a finite field and p is a large prime number.

ECC encryption involves selecting an elliptic curve $Ep(a,b)$ and choosing a point G on the curve as the base point. Next, a private key r is selected, and the corresponding public key R=rG is calculated, where R and G are points on the elliptic curve $Ep(a,b)$. To encrypt the plaintext, it is embedded into a point on the elliptic curve and the public key $R$ is used to complete the encryption process. To decrypt the ciphertext, the private key $r$ is utilized.

To protect data, it can be encrypted using the public key $R$, with higher efficiency for smaller amounts of data. As elliptic curves cannot be brute-force broken, ECC encryption provides a higher level of security at a lower computational cost. In light of the small data volume of the hash value and the high security requirement, we have opted to use the ECC encryption algorithm. In this study, we have utilized the key generation method from ECDSA (Elliptic Curve Digital Signature Algorithm) to produce the required public key $R$ and private key $r$ for ECC encryption. The specific process is shown in Algorithm 1.

Initially, the data owner obtains the hash value $H_{CH}$ of the data ciphertext in IPFS (line 1). Next, the system initializes the elliptic curve, generates the elliptic group, and completes the encryption algorithm initialization (lines 2–3). All points that satisfy the elliptic curve $Ep(a,b)$ are calculated based on Eq. (3), and the base point $G$ is obtained (lines 4–6). In the second step, the system generates the private key $r$ and public key $R$ for the data demander, and the data demander sends their public key $R$ to the data owner (lines 7–8). Finally, the data owner encrypts the hash value $H_{CH}$ using the data demander’s public key $R$ and stores the encrypted hash on the blockchain (lines 9–10). The data demander then decrypts the hash ciphertext on the blockchain using their private key $r$ (line 11).

Smart contract-based log tracking mechanism

In a blockchain network, events are usually recorded in logs. As operational logs of the blockchain network are continually generated, displaying the logs visually can provide a more intuitive understanding of the entire process of events and enable identity tracking of both sides of data-sharing. Smart contracts (Wang et al., 2020), as an interface for interacting with the blockchain, have the characteristics of automatic execution and irrevocability, which facilitates the automatic storage and querying of data-sharing records. To this end, we have designed a smart contract-based log tracking mechanism that automatically stores data-sharing records on the blockchain through smart contracts and presents them in the form of visual logs. The smart contract’s interface design is presented in Table 1.

Data owners and data demanders can upload and query data-sharing records by accessing the smart contract interface. The process of writing and querying data-sharing records is shown in Algorithm 2.

First, the data owner and data demander register in the system (Lines 1–2). Then, the data owner uses Algorithm 1 to obtain the ciphertext of the encrypted data hash value (lines 3–5). When data-sharing is initiated between the data owner and the data demander, the blockchain records the identity information of both parties and the encrypted hash value, and returns the transaction ID of the data-sharing (lines 6–12). Finally, the data owner or data demander can query the data sharing record from the blockchain based on the transaction ID (lines 13–18).

Experimental environment

In the experiments, we built the blockchain using Hyperledger Fabric (Kumar et al., 2021) and utilized IPFS as the storage platform under the chain. Table 2 shows the software configuration details of the experimental environment.

We developed a user-friendly data-sharing and transmission system that connects with Hyperledger Fabric and IPFS through a web interface, based on the experimental environment configuration. This system allows data owners and data demanders to share data easily within the system.

Off-chain data security experiment

During the data sharing process, data owners store data off-chain in various formats, including video, audio, images, and text. Taking a text file as an example, the encryption result of off-chain data is shown in Fig. 3.

Figure 3A shows the data encryption test interface, while Fig. 3B displays the encryption result of a text file. As shown, enabling attribute-based encryption data protection method presents the shared data in ciphertext, effectively preventing the leakage of shared data under the chain. Moreover, the shared data encrypted by one data owner can be decrypted by multiple data demanders, achieving “one-to-many” encryption and decryption of shared data and reducing the system’s overhead of repeatedly encrypting data. Subsequently, the encrypted data is uploaded, and Fig. 4 shows the hash value of the encrypted data returned by IPFS.

Figure 4A displays the result of the unencrypted hash of the data ciphertext, while Fig. 4B shows the result of the ECC encryption of the hash of the data ciphertext. In Fig. 4A, when the hash value is not encrypted, unauthorized data demanders can download the data ciphertext stored in IPFS directly via the hash value. If the set of attributes of this data demander matches the set of attributes required for the ciphertext decryption, they can decrypt the data ciphertext. In contrast, Fig. 4B shows the encrypted hash value of the data ciphertext stored in IPFS in the form of ciphertext. The ECC encryption algorithm uses a public key for encryption and a private key for decryption. Only the data demander with the decryption private key can decrypt the hash value and obtain the ciphertext of the data in IPFS.

To track the identity of both parties involved in the shared data, we utilize smart contracts to automatically record and track the data-sharing process, and present it in the form of visual logs. Figure 5 shows an example of the visual log.

Figure 5 illustrates the visual log of each sharing record between the data owner and data demander. This log includes details such as the block number, the identity of the sharing parties, and the time of the sharing. This provides real-time tracking of the identities involved in the data sharing process. Additionally, to reduce the storage pressure on the chain, our scheme offloads the storage of shared data to off-chain platforms. Table 3 presents the storage space occupied by the shared data on the chain.

As presented in Table 3, the proposed on-chain and off-chain collaborative data security storage scheme can significantly decrease the occupancy rate of on-chain storage. Furthermore, the proposed secure data storage solution occupies the same amount of space on the chain as the volume of raw data increases. This is because only the encrypted hash of the data is stored on the chain, and the hash size remains constant regardless of the amount of data stored off-chain (Kumar et al., 2021).

Performance analysis of the system

During the process of data-sharing, the system incurs performance overhead which mainly consists of the execution cost of data encryption and decryption, and the transaction cost of the chain. We measure these costs, including the encryption and decryption overhead of raw data, as well as the encryption and decryption overhead of hash values. For instance, using the data in Table 3 as an example, we measure the encryption and decryption overhead of the raw data, while the overhead of hash values encryption and decryption is explained later. To ensure experimental data reliability, the experiment was executed 100 times and averaged, as depicted in Figs. 6 and 7 for encryption and decryption overhead of original data, respectively. Additionally, to test the performance of the proposed scheme during encryption and decryption of original data, it was compared to the schemes proposed by Dong et al. (2020) and Park et al. (2021). Dong et al. (2020) proposed the use of AES symmetric encryption algorithm, while Park et al. (2021) suggested the use of proxy re-encryption technique for data privacy protection. These two schemes were proposed recently and are similar to the technical architecture of the proposed option.

In Figs. 6 and 7, it is evident that AES encryption and decryption incur the lowest execution cost, while proxy re-encryption incurs the highest execution cost. This is mainly because the AES encryption and decryption process uses a byte round-robin conversion operation, making the encryption and decryption of original data relatively fast. However, since AES encryption and decryption utilize the same key, data owners need to share the key with data requesters in advance, which can easily lead to key leakage. On the other hand, the proposed scheme does not require sharing the key during original data encryption and decryption, making it more secure. Furthermore, the proposed scheme is more efficient in original data encryption and decryption compared to the proxy re-encryption technique. This is because the proxy re-encryption technique needs to convert the ciphertext to different ciphertexts through a proxy server for different data requesters to decrypt, which increases the implementation cost of the system.

Regarding the encryption and decryption overhead of hash values, we also measures it. The experiment is executed 100 times to obtain the average value, and the results are presented in Table 4.

Based on Table 4, it can be observed that hash value encryption and decryption have a minimal impact on the system’s efficiency. The designed ECC encryption algorithm not only effectively protects the chain hash values from leakage but also encrypts and decrypts the hash values without significantly reducing the system’s efficiency.

Data throughput refers to the number of transactions completed per second on the blockchain and reflects the transaction cost overhead on the chain. In this study, we measured the throughput of shared data storage and query in the blockchain network and compared it with the scheme without under-chain storage and the Guo et al. (2020) scheme. Guo et al. (2020) proposes the use of a master-slave blockchain architecture to store data. Among them, the slave chain stores the shared data, and the master chain stores the hash of the data, which is similar to the architecture of the proposed scheme. To ensure the reliability of the experimental data, the experiment was repeated 100 times to obtain the average value, and the results are presented in Fig. 8.

Figure 8 demonstrates that the throughput of the scheme without under-chain storage gradually decreases as the data size increases, and the throughput in the Guo et al. (2020) scheme is even lower. Meanwhile, the throughput of the proposed scheme remains constant and is higher than that of the chainless under-storage scheme. This is because the Guo et al. (2020) scheme requires cross-chain operations between the master and slave chains during data storage and query, which unavoidably decreases the efficiency of blockchain storage and query. In contrast, the proposed scheme only stores the encrypted hash value, which is significantly smaller than the shared data directly on the chain. As a result, the proposed scheme has higher throughput.

Data security comparison

We have compared our scheme with other related schemes with regards to off-chain data security, on-chain data security, data integrity, data tracking, trustfulness, authorization, authentication, reliability, and validation. The results are presented in Table 5.

• (1) Off-chain data security

Our data security protection method is based on attribute encryption, in which the data owner encrypts the original data by customizing the access structure to achieve fine-grained access control to the data off-chain, thereby enhancing data security.

• (2) On-chain data security

We use the ECC encryption algorithm to store the data hash as a ciphertext on the blockchain. The data ciphertext can only be downloaded from IPFS if it is decrypted, preventing unauthorized access to the storage address of the data off-chain and enhancing on-chain data security.

• (3) Data integrity

Our proposed collaborative data storage method encrypts and stores off-chain data in IPFS, which can be stored permanently. Moreover, the encrypted hash value stored on the chain cannot be tampered with, ensuring data integrity.

• (4) Data tracking

Through the smart contract interface, data-sharing records are tamper-proof stored on the chain, allowing real-time tracking of the identity of both parties sharing data.

• (5) Trustfulness

Our data security storage scheme stores shared encrypted data by IPFS, while the hashes of the encrypted data are stored by the blockchain. Based on the uniqueness of the hash value, data demanders can compare the hash value of the data under the chain with the decrypted hash value on the chain to verify whether the data is trustworthy, enhancing trustfulness.

• (6) Authorization

Our scheme ensures that only authorized data demanders can decrypt the cryptographic hashes stored on the blockchain and download the data ciphertext stored in IPFS. Additionally, the data ciphertext can be decrypted only if the set of attributes of the data requester matches the set of attributes required for the decryption of the ciphertext, ensuring data confidentiality.

• (7) Authentication

In our scheme, both data owners and demanders must be authenticated by the system to access the system. After authentication, the system provides keys. Our designed data tracking mechanism fully records shared data on the blockchain for easy accountability, ensuring system security.

• (8) Reliability

In this article, we store the original data off-chain, and the uniqueness and irreversibility of the hash value ensures the reliability of the off-chain data, which is further guaranteed by the on-chain storage of cryptographic hash. The cryptographic hash of the data on the chain cannot be changed, ensuring the reliability of the data.

• (9) Validation

In this article, the data stored on and off the chain is presented in ciphertext format. Unauthorized or unverified data demanders querying the blockchain for data will only get the hash ciphertext and will not be able to download the original data ciphertext stored in IPFS. Therefore, the original data ciphertext can only be decrypted by authorized parties, achieving on-chain and off-chain data verifiability.

It is evident that our solution not only ensures secure storage and sharing of data, but also enables tracking the identity of the data sharer.