Keywords

1 Introduction

The Internet of Things (IoT) technology has a significant impact on our daily lives and is extensively used in various fields such as transportation [1], smart factory [2], and wireless health monitoring [3]. Personal health data generated by wearable IoT devices, for example, might provide individuals with particular benefits as personal digital assets. Encouraging individuals to share their data can benefit society as a whole.

At present, most organizations or individuals use cloud service providers (CSPs) to store tons of data at lower costs, but the premise of this approach is full trust in cloud service providers. However, this assumption exposes outsourced data to substantial safety and privacy risks.

In response to the challenges of data privacy and tracking malicious users in data sharing, we introduce a novel solution called BACTDS, which supports blockchain-based traceability and fine-grained access control. This paper presents several key contributions, including

  1. 1)

    We introduce a novel access control scheme based on blockchain and ABE that provides traceability and privacy preservation for IoT data sharing. Our proposed scheme encourages the sharing of private data to a certain extent, and users who share personal data should be rewarded.

  2. 2)

    In our proposed system model, data users can interact with the cloud to obtain ciphertext information only if they have permission information and can decrypt the obtained ciphertext to obtain plaintext information only if they meet access policies.

  3. 3)

    Our proposed scheme makes it possible to trace tracking malicious users who have leaked private keys. Our scheme puts user information into polynomials, recovers malicious user identities through lagrangian interpolation polynomials, and then traces malicious users, preventing unlawful key sharing and illegal use.

  4. 4)

    The rigorous security analysis of the BACTDS is under the random oracle model, and the performance analysis and experimental comparisons show the superiority and effectiveness of our scheme over existing solutions.

2 Related Works

CP-ABE [4] is an effective solution for secure data sharing in scenarios where users may have different levels of clearance or authority. Therefore, many papers applied CP-ABE to the blockchain. In particular, Yu et al. [5] developed a lightweight hybrid attribute-based signcryption scheme (LH-ABSC) to address the security issues associated with outsourced data storage, such as data leakage and unauthorized access. Liu et al. [6] introduced a novel multi-authority traceable ABE scheme. The proposed scheme aims to enhance security and efficiency by offloading most of the decryption operations to a cloud server, resulting in reduced computational and equipment overhead. To enable multiple users to share the same ciphertext data without exposing the identity and data information of the data participants, Liang et al. [7] use proxy re-encryption technology for the storage of big data.

Some works exploited the blockchain to realize more secure access control for IoT. Tan et al. [8] proposed a scheme that uses blockchain technology in combination with CP-ABE to enable secure and private sharing of electronic medical records (EMRs) with the ability to track and direct revoke access to COVID-19 EMRs. In a similar vein, Zuan et al. [9] aimed at tracing maliciously modified data by storing raw data and transaction data on separate blockchains. Meanwhile, Liu et al. [10] replaced the traditional search server with a blockchain to improve searchable attribute encryption with efficient revocation and decryption.

In summary, while the existing work above explores the potential of applying blockchain technology and some privacy-preserving techniques to contribute data, there are still some challenges in blockchain-based data sharing. These challenges are how to solve the problem of tracing malicious users and how to reduce storage space costs. To solve these challenges, this scheme adopts a Lagrange interpolation polynomial to store user identities, which greatly reduces the cost of storage space. In addition, the solution also discusses privacy protection and traceability issues such as data collection and access control.

3 System Model

The BACTDS system model comprises various components, including the personal health data owner (DO), wearables, data user (DU), cloud storage (CS), authority center (AC), and blockchain (BC), as illustrated in Fig. 1.

  1. 1)

    Authoritative center (AC): The authoritative center is responsible for generating the system’s public parameters, denoted as PP, and the master private key, denoted as MSK. The PP is then made public, while the MSK is kept confidential by the authoritative center.

  2. 2)

    Personal health data owner (DO): The personal health data owner integrates the information collected from the wearable device to obtain the information m. Next, they use a symmetric key to encrypt the information m, resulting in the \(C{T_{{m}}}\), which is stored in the CS for future access. Then encrypt the symmetric key k with the access policy \((M,\rho )\) made by yourself to obtain the ciphertext CT. CT uploads blockchain storage. At the same time, DO formulates sales rules on the blockchain.

  3. 3)

    Blockchain (BC): The blockchain stores the encrypted ciphertext CT of k and the sales rules made by the data’s owner.

  4. 4)

    Cloud storage (CS): The cloud platform stores the ciphertext \(C{T_{{m}}}\). The restriction on the cloud platform is that only users with tokens can obtain the ciphertext \(C{T_{{m}}}\) from it.

  5. 5)

    Data user (DU): Data users are able to obtain encrypted keys and access policies from the blockchain via CT. If the attribute set S possessed by the data user satisfies the access policy of ciphertext CT, then the symmetric key k can be obtained by decrypting CT. The user can then access the ciphertext \(CT_m\) from its corresponding location in the CS and decrypt it using the symmetric key k to obtain their personal medical and health data m. Data is an important digital asset, and DU is willing to pay for private data on DO.

  6. 6)

    Wearables: Wearables are responsible for collecting records of personal information, which are source authenticated by the BLS signature algorithm and then send to the data owner for aggregation.

Fig. 1.
figure 1

System model.

4 Design of Our Scheme

The entity interactions of the proposed BACTDS scheme is illustrated in Fig. 2. Firstly, the scheme is initialized to upload the PP to the BC. Then, the symmetric encryption algorithm is employed to encrypt the personal information health data and generate the corresponding ciphertext \(CT_m\). The ciphertext \(CT_m\) is uploaded and stored in the CS. Next, the scheme employs ABE that utilizes a ciphertext policy to encrypt the symmetric secret key k. This encryption generates the corresponding ciphertext CT, which is then uploaded and stored on the BC. DU initiates a purchase request to the BC, the BC allows the request and generates the corresponding request permission token. The requested permission information is then transmitted to the CS. The DU sends his token information to the CS, and searches for the license information corresponding to the token, subsequently the CS transfers the ciphertext to the DU.

Fig. 2.
figure 2

Interactions among entities.

The detailed description of our proposed blockchain-based fine-grained access control traceability and reward personal health and medical data sharing scheme is as follows, where the symbols used in this scheme are listed in Table 1.

Table 1. Notations.
  • \(Setup({1^\lambda }) \rightarrow (PP,MSK)\): The system is initialized with a security parameter \(\lambda \), where \(\lambda \) determines the system’s level of security. We define \((\mathbb {G}_1,+)\) and \((\mathbb {G}_2,*)\). The bilinear pairing function is denoted by \(e: \mathbb {G}_1 \times \mathbb {G}_1 \rightarrow \mathbb {G}_2\). Additionally, we define two safe hash functions: \(H: {\{ 0,1\} ^*} \rightarrow \mathbb { Z}_p\) and \(H_1: \mathbb {G}_1 \rightarrow \mathbb {Z}_p\). The attribute universe U is mapped to the group \(\mathbb {Z}_p\) by a mapping function denoted as \(\varPhi : U \rightarrow \mathbb {Z}_p\). Randomly chooses \(g,w,\mu ,\beta ,\eta \in \mathbb {G}_1\), \(\alpha ,a \in \mathbb {Z}_p\), and a probabilistic encryption algorithm (EncDec) with two distinct secret keys \({k_1}\) and \({k_2}\) (where \({k_1},{k_2} \in \mathbb {Z}_p\)). In addition, it selects the symmetric key encryption/decryption algorithm \(({E_{\mathrm{{sym}}}},{D_{sym}})\) with secret key k (where \(k \in {G_2}\) ). Then it initializes the Shamir’s threshold scheme \(ST{S_{(\boldsymbol{k},n)}}\)by selecting an order \({\boldsymbol{k}} - 1\) polynomial f(x) and \({\boldsymbol{k}} - 1\) distinct points \(\{ ({x_1},{y_1}),({x_2},{y_2}),({x_3},{y_3})...,({x_{\boldsymbol{k} - 1}},{y_{\boldsymbol{k} - 1}})\} \) (where \(f({x_i}) = {y_i},i \in [1,\boldsymbol{k} - 1]\)) of the polynomial f(x) for secret storage.

The system’s public parameters PP (publicized and stored on the blockchain) and the master key MSK are:

$$\begin{aligned} PP = (\mathbb {G}_1,\mathbb {G}_2,q,P,g,\mu ,\beta ,w,\eta ,e{(g,g)^\alpha },{g^a},H,{H}_1), \end{aligned}$$
$$\begin{aligned} MSK = (\alpha ,a,b,{k_1},{k_2}). \end{aligned}$$
  • \(KeyGen(PP,MSK,UID,S = \{ att{r_i},i \in [1,n]\mathrm{{ }} \subseteq \mathbb {Z}_p\} ) \rightarrow S{K_{UID,S}}\): Upon receiving the identity UID and corresponding attribute set S from the data user, the AC calculates the secret key of the user:

    $$\begin{aligned} \begin{aligned} {x} = En{c_{{k_1}}}(UID),y = f(x),\zeta = En{c_{{k_2}}}(x||y). \end{aligned} \end{aligned}$$

    And it randomly chooses \({b_1},{b_2},...,{b_n} \in {Z_p}\), and calculates the decryption key of user \(S{K_{UID,S}}\) as follow: \(S{K_{UID,S}} = \{ {K_0},K',{K_1},K'_1{},\{ {K_{\varGamma ,1}},{K_{\varGamma ,2}}\} \mathrm{{ }}, \varGamma \in \mathrm{{[n]}}\} \) where

    $$\begin{aligned} \begin{aligned} {K_0} &= {g^{\alpha /(a + \zeta )}}{w^b}, ~~K' = \zeta ,~~{K_1} = {g^b}, ~~{K'_1} = {g^{ab}}, \\ {K_{\varGamma ,1}} &= {g^{{b_\varGamma }}}, ~~{K_{\varGamma ,2}} = {({\mu ^{att{r_\varGamma }}}{\beta ^{}})^{{\mathrm{{b}}_\varGamma }}}{\eta ^{ - (a + \zeta )b}}, \end{aligned} \end{aligned}$$

    and randomly select a number \({x}_l \in \mathbb {Z}_p\), and calculate its public key \(P{K_{UID}} = {x_l}P\). Therefore, the key pair of DU is used by \(\mathrm{{(}}{\mathrm{{x}}_l},P{K_{UID}})\) for the generation of the license token. To enhance computational efficiency, we map the user’s UID to the cyclic group \(\mathbb {Z}_p\).

  • \(Encrypt(PP,UID,m,(M,p)) \rightarrow (C{T_\mathrm{{m}}},CT): \) First, the DO selects the symmetric key encryption/ decryption algorithm \(({E_{sym}},{D_{sym}})\) with secret key k to encrypt personal health and medical data records m, and calculates the ciphertext as \(C{T_m} = {E_{sy{m_k}}}(m)\). After encrypting the data, the system calculates \({M^*} = H(C{T_m})\), which is a hash of ciphertext, and uploads it to the BC. The purpose of this is to provide an additional layer of security and prevent tampering with the data by adversaries. Next, the ciphertext \({CT_m}\) and \({M^*}\) are sent to the CS and stored. We assume the existence of a matrix M that can generate shares. This matrix has l rows and n columns. For \(i = 1,2,..,l\), a function \(\rho \) is defined to label row i of M with an attribute from the S. In the LSSS-based expression, the access policy is defined as \((M,\rho )\), and \({{s}},{y_2},...,{y_n} \in {\mathbb Z_P}\) are randomly selected to form the secret sharing matrix \({{\boldsymbol{v} = (s,}}{\mathrm{{y}}_2}\mathrm{{,}}{\mathrm{{y}}_3}\mathrm{{,}}...\mathrm{{,}}{\mathrm{{y}}_n}{\mathrm{{)}}^\textrm{T}}\). It gets the vector of the shares \(\lambda = ({\lambda _1},{\lambda _2},...,{\lambda _l})\) by computing the inner product \({\lambda _i} = {M_i}\boldsymbol{v}\) , where \(M_i\) is the i-th row of M. When a specific policy is used to encrypt k, DO provides access control to the data and allows only data users who meet the policy requirements to access the data. DO can complete encryption by itself. To encrypt k, DO first choose a random element \(s \in \mathbb {G}_1\), and then computes \(C = ke{(g,g)^{ \alpha s}}\). Finally, get the ciphertext \(CT = (C{T_1},C{T_2})\), where \(C{T_1}\) contains \(\{ C,{C_0} ,C_0'\}\), \(C{T_2}\) contains \(\{ (M,\rho ),{C_{i,1}} ,{C_{i,2}} ,{C_{i,3}} \}\). The detailed calculation is as follows:

    $$\begin{aligned} \begin{aligned} {C_0} &= {g^{s}},~~{C_0'} = {{g}^{a s}},~~{C_{i,1}} = {{w^{{\lambda _i}}}{\eta ^{{t_i}}} },~~{C_{i,2}} = {({\mu ^{\rho (i)}}\beta )^{ - {t_i} }}, ~~{C_{i,3}} = {g^{{t_i}}}, \end{aligned} \end{aligned}$$

    and \(t_i\) is randomly chosen on \({t_i} \in {Z_p}\), (\(i \in [1,l]\)). Finally, the CT is stored on the BC.

  • \(TokenGen(PP,UID,address,time) \rightarrow Token\): The token generation algorithm inputs the public parameters PP, user UID, account address, and time, and outputs the license token Token. In this phase, smart contracts are utilized to facilitate payments between DO and DU. Once the payment has been successfully made, the smart contract grants a license token to the CS.

Suppose a data user DU is interested in \(DO's\) personal health and medical data and accepts the sales rules published by DO on the blockchain, DU initiates a purchase request and then records it on the BC. The data user who made the purchase is denoted as \(DU_L\). When the BC receives the purchase request of \(DU_L\), the BC performs the following steps:

  1. 1)

    The BC verifies whether the balance of \(DU_L's\) account address meets the pricing of the data owner’s sales rules. If the balance meets the pricing, the next step is performed; Otherwise, the data user’s request is rejected.

  2. 2)

    Generate the licence Token for \(DU_L\), where \(T\mathrm{{oken}} = \{ \mathrm{{sp}}{\mathrm{{e}}_L},{M^*},PK_{UID},{t_s} ,t_s'\} \).

    • \(spe_L\) is the unique identification of Token.

    • \(M^*\) is the hash value of personal health medical data.

    • \(PK_{UID}\) is the public key of \(DU_L\).

    • \(t_s\) is the time stamp of Token.

    • \(t_s'\) is the expiration time of the token.

  3. 3)

    Compute \(\tilde{m} = H(T\mathrm{{o}}ken)\), encrypt Token with \(DU_L'\) public key \(PK_{UID}\) as \(cl=PK_{UID}(Token)\). Then, send \((cl,\tilde{m})\) to \(DU_L\) and send \((Token,\tilde{m})\) to CS.

    • \(Decrypt(PP,S{K_{UID,S}},CT) \rightarrow k\mathrm{{ }}\ or\ \mathrm{{ }} {\bot }\): First, the DU sends his token information Token to the cloud to search the corresponding license information, and then the CS transmits the respective ciphertext \(CT_m\) to the DU. Next, the DU obtains CT from the BC. Then the data user calculates \(I = { i: \rho (i) \in S}\) to check if the attribute set S satisfies the access policy. If yes, a set of constants \({\{ {\omega _i} \in \mathbb {Z}_p\} _{i \in I}}\) such that\(\sum \limits _{i \in I}^{} {{\omega _i}{M_i} = } (1,0,0,...0)\) can be gained, where \({M_i}\) is the i-th row of matrix M. Note that \(\sum \limits _{i \in I}^{} {\omega _i \lambda _i} = s\) if the attribute set S is authorized. Otherwise, the decryption algorithm outputs \({\bot }\). The following is the calculation process:

      $$\begin{aligned} \begin{aligned} {X} & = {e({K_0},C_0^{{{{K}}'}}C_0')}={ e{(g,g)^{ \alpha s}}e{(g,w)^{ s(a + \zeta )b}} }, \\ Y &= \prod \limits _{i \in I} {} {(e({K_1}^{{K'}}K_1',{C_{i,1}})e({K_{\varGamma ,1}},{C_{i,2}})e({K_{\varGamma ,2}},{C_{{{i}},3}}))^{{w_i}}}\\ &= e{(g,w)^{ sb(a + \zeta )}},\\ Z &= X/Y = e{(g,g)^{ \alpha s}}. \end{aligned} \end{aligned}$$

Then output the symmetric key to get the encrypted message \(k = C/Z\). Finally, the DU decrypts the \(CT_m\) obtained from the CS through the obtained symmetric key k, thereby obtaining the desired plaintext information m, where \(m = {D_{sysmk}}(C{T_m})\). Verify whether \({M^*} = H({E_{symk}}(m))\) is equal to determine whether the information has been tampered with by the adversary. If the verification equation is satisfied, the data owner will accept the information m. Otherwise, the message m is rejected.

  • \(Key{{ for Check(PP,MSK,S}}{\mathrm{{K}}_{UID,S}}\mathrm{{)}} \rightarrow \mathrm{{1 \ or\ 0 }}\): Checks whether the form of the key \(\mathrm{{S}}{\mathrm{{K}}_{UID,S}}\) is intact, and outputs 1 if the key form is intact. Execute the key tracking algorithm, otherwise, the algorithm outputs 0, which indicates that the check failed. The key form check is performed by the authority center AC with the following checks:

    $$\begin{array}{l} (1)~ \mathrm{{ }}{K'} \in Z_p^*\mathrm{{ }},\mathrm{{ }}{K_0},{K_1},K_1',{K_{\varGamma ,1}},{K_{\varGamma ,2}} \in \mathbb G_1,\\ (2) ~\mathrm{{ }}e(K_1',{g}) = \mathrm{{e}}({K_1},{{g}^a}),\\ (3)~ \mathrm{{ }}e({K_0},{{g}^a}{g^{{K'}}}) = e(K_1'{K_1}^{{K'}},w)e{(g,g)^\alpha }. \end{array}$$

    If and only if formulas 1, 2, and 3 are true, the key form can be determined to be intact.

  • \(Trace(PP,STS(k,n),MSK,S{K_{UID,S}}) \rightarrow UID{{ \ or\ }} {\bot }\): Once the key-form check for \(S{K_{UID,S}}\) is successfully completed, the algorithm executes the following steps to find the user’s UID to determine the real identity of the data consumer.

  1. 1)

    The tracking algorithm starts by extracting the relevant parameters \(K'\) from \(S{K_{UID,S}}\), and then uses \(K'\) to decrypt and obtain x||y, where \(x||y = D\mathrm{{e}}{\mathrm{{c}}_{{k_2}}}({K'})\).

  2. 2)

    Assuming that let \(\mathrm{{x}}' = x,y' = y\), if \(\mathrm{{(x',y')}} \in \{ ({x_1},{y_1}),({x_2}, {y_2}),({x_3},{y_3})..., ({x_{\boldsymbol{k} - 1}},{y_{\boldsymbol{k} - 1}})\}\), the algorithm identifies a malicious user by calculating \(UID = De{c_{{k_1}}}(x')\) to get the user’s UID.

  3. 3)

    If \(\mathrm{{(x',y')}} \notin \{ ({x_1},{y_1}),({x_2},{y_2}),({x_3},{y_3})...,({x_{\boldsymbol{k} - 1}},{y_{\boldsymbol{k} - 1}})\} \), the algorithm combines the other points \(\{ ({x_2},{y_2}),({x_3}, {y_3})...,({x_{\boldsymbol{k} - 1}},{y_{\boldsymbol{k} - 1}})\} \) and \(\mathrm{{(x',y')}}\) to recover the secret value \(a_0^*\) of STS(k,n) by means of Lagrangian interpolation. Determine whether the equation \(\mathrm{{a}}_0^* = f(0)\) holds, and if the equation holds, find the malicious user by calculating \(UID = D{{e}}{c_{{{{k}}_1}}}({x'})\) to obtain the user’s UID. Otherwise, the algorithm terminates.

5 Security Analysis

5.1 CPA-Security

Theory: No PPT adversary can selectively defeat our scheme against chosen-plaintext attacks (CPA) given the \(q-type\) assumption.

Proof: If there exists a PPT adversary A that can break our scheme with a non-negligible advantage \(\epsilon \) assuming the security of choice, then the adversary A can use this advantage to construct a challenger C that can solve the q-type problem with a non-negligible advantage \(\epsilon \).

5.2 Data Authenticity

IoT wearables are considered untrustworthy, and some unauthorized devices may falsify data records. An intuitive way to solve this issue is using signatures. Specifically, each wearable device uses its own private key si to sign its own transmitted information mi, and the DO use the wearable device’s public key pi to verify the signature \({\sigma }\). However, in IoT applications, there may be tons of devices generating data all the time. Thus, in our scheme, we use BLS aggregate signature algorithm to realize the authentication of source information from IoT wearable devices and improve the verification efficiency of DO. Each wearable device signs the generated data before sending it to the data owner. Then, the DO can perform batch verification. In this way, the source authenticity of the personal medical record is guaranteed efficiently.

5.3 Anonymity

To assure the users’ privacy, the system needs to guarantee anonymity of users. Therefore, our scheme anonymized the user’s private information in two aspects. On one hand, during the key generation phase, the identity information of the user identity UID is encrypted using a probabilistic encryption algorithm. This type of encryption uses random algorithms, which produce different ciphertexts for the same information. Since probabilistic encryption offers polynomial security, it is virtually impossible for adversaries to derive any information about the original plaintext from the ciphertext, even if they perform calculations or attempt to obtain experimental plaintexts. In other words, the ciphertext completely masks any information about the user’s identity, thereby ensuring their anonymity.

On the other hand, it is anonymity protection for the privacy information of data users: in the licensing token generation stage, the DU’s public key is generated by randomly selecting a value \({x}_l \) from \( \mathbb {Z}_p\) and calculated \(P{K_{UID}} = {x_l}P\), the random number \({x}_l \in \mathbb {Z}_p\) is in the hands of the data users, and \(spe_L\) is used to represent the unique identity of the token, which is designed to protect the privacy of DU by not revealing their actual identity information.

6 Experiment Analysis

To establish a clear understanding of proposed scheme’s performance, we use the following notations to represent computational costs. \({C_a}\), \({C_m}\), \({C_p}\), and \({C_{pr}}\) are used to denote the computational overheads of performing point addition operation on \(\mathbb {G}_1\) group, point multiplication operation on \(\mathbb {G}_1\) group, power operation, and bilinear pairing operation. \({C_s}\), \({C_{po}}\), and \({C_h}\) denote the calculation cost of the symmetric encryption and decryption algorithm, the probabilistic encryption and decryption algorithm, and mapping the hash value to \(\mathbb {Z}_p\). Other computational costs are ignored. The calculation cost of each stage is shown in Table 2.

Fig. 3.
figure 3

Encryption time cost comparison.

Fig. 4.
figure 4

Decryption time cost comparison.

Fig. 5.
figure 5

Key generation time for different numbers of attribute.

Table 2. Computational Overhead.

To quantify the computational cost of our scheme, we break it down into several phases and analyze the complexity of each phase separately. In the initialization phase, the computation overheads are \({ 2{C_p}+{C_{pr}}}\). In the key generation phase, the computation overheads are \({{C_a}+(3n+5){C_p}+(2n}{+4){C_m}}+2{C_{po}}\). In the encryption phase, the computation overheads are \({C_h}+{C_s}+(5n+2){C_p}+(2n+5){C_m}\). In the decryption phase, the computation overheads are \({(2n+2){C_{pr}}}{+{C_s}+(n+2){C_m}+(n+2){C_p}}\), and in the tracing phase, the computation overheads are \({5{C_{pr}}+3{C_m}+2{C_{po}}}\).

Through performance comparison, the calculation cost of our scheme is obviously less than that of Tan et al. [8] in the tracking stage. This is because our scheme converts the user information into a point conforming to the f(x) polynomial through calculation and recovers it by Lagrange interpolation polynomial, while the Tan et al. [8] scheme needs to query whether the user’s information is in the registration list before tracing. In the verification phase of tracking, our scheme only needs to check the integrity of the secret key form, which requires a small amount of computation, while the scheme of Tan et al. [8] needs to input the public parameters and intermediate parameters of the user’s attribute set for verification, which requires a large amount of computation.

To measure the effectiveness of our proposed scheme, we conducted a simulation experiment. The hardware setup for this experiment included an Intel(R) Core(TM) i5 CPU @2.2 GHz, 8 GB RAM, and the Windows 10 (64b) operating system. For simulating encryption and decryption operations, we used the Java pair-based cryptography library. To perform our experiments, we opted for a supersingular elliptic curve with a base field consisting of 512-bit elements and a group order size of 160 bits. We illustrate the link between key generation time and the number of attributes in Fig. 5. Both schemes show a linear increase in key generation time as the number of attributes increases. The comparison of encryption time cost is illustrated in Fig. 3. As the number of attributes increased, we observed a gradual increase in the encryption time for both schemes. When the number of attributes is 1, 3, 5, and 7, the data encryption time of the two is basically the same. However we discover the BACTDS scheme spends a slightly longer than Tan et al. [8] scheme when the number of attributes is increasing.

Figure 4 presents a comparison of the decryption time cost. It can be observed that both schemes experience a gradual increase in decryption time as the number of attributes increases. However, it is worth noting that the decryption time of the BACTDS scheme is lower compared to that of the Tan et al. [8] scheme. The reason is that in Tan et al. [8] scheme, the cloud service provider performs the decryption delegation function, providing the patients with new ciphertext and decryption parameters. Only users who satisfy the attributes and possess decryption parameters during decryption can decrypt the ciphertext. In addition, the BACTDS scheme stores the user identity in a probability polynomial, which greatly reduces the storage space cost, while Tan et al. [8] the scheme stores the user identity information in the revocation list, which greatly increases the storage space.

7 Discussions and Conclusion

Our paper introduces a novel fine-grained access control scheme called BACTDS, which utilizes blockchain technology to trace data access and control from the data source. To uphold the security of data, in BACTDS, the data user must satisfy both the attribute set of the access policy and possess the token to obtain the ciphertext information from the cloud and decrypt it to obtain the plaintext information. With the help of the traceability algorithm, the BACTDS recovers the identity of malicious users through lagrangian interpolation polynomials and then traces the malicious users, which can prevent illegal data sharing and misuse of secret keys. Our paper outlines the system and security models for the BACTDS scheme and provides formal security proof under the random oracle model. This proof validates the provable security of our proposed scheme. Through experiments and performance analysis, it is proved that our scheme (BACTDS) is more advantageous in terms of storage space and time consumption, and the BACTDS scheme is effective and attractive.

Distributed data-sharing systems are increasingly being recognized as valuable tools in big data applications. In our future work, we plan to conduct a penalty study to investigate the malicious behaviors of various users and ensure the security of data sharing.