An Access Control Scheme Based on Blockchain and Ciphertext Policy-Attribute Based Encryption

Abstract

Ciphertext policy–attribute-based encryption (CP-ABE), which provides fine-grained access control and ensures data confidentiality, is widely used in data sharing. However, traditional CP-ABE schemes often choose to outsource data to untrusted third-party cloud service providers for storage or to verify users’ access rights through third parties, which increases the risk of privacy leakage and also suffers from the problem of opaque permission verification. This paper proposes an access control scheme based on blockchain and CP-ABE, which is based on multiple authorization centers and supports policy updating. In addition, blockchain technology’s distributed, decentralized, and tamper-proof features are utilized to solve the trust crisis problem in the data-sharing process. Security analysis and performance evaluation show that the proposed scheme improves the computational efficiency by 18%, 26%, and 68% compared to previous references. The proposed scheme also satisfies the indistinguishability under chosen-plaintext attack (IND-CPA).

1. Introduction

With the advent of the big data era, data have become an important economic asset and a new factor of production permeating all walks of life. With increasing data resource sharing, incidents such as data theft and information leakage have occurred repeatedly. In May 2022, General Motors released a statement saying that some online customers had suspicious logins and that hackers had accessed some of their personal information through an online mobile application, including names, email addresses, mailing addresses, interest collections, search history, etc. In December of the same year, Azalea Motors suffered a server misconfiguration that led to the leakage of millions of user information and was subjected to a ransom demand of USD 2.25 million in Bitcoin equivalent. To prevent incidents like these, data owners often want to keep their data under control after they have been shared. Access control is an effective means to protect data security and control the flow and sharing of data. It explicitly allows or restricts the subject’s access to the object in a certain way, allowing users to access data within their legitimate permissions. If not, their operations are prohibited. Traditional access control cannot cope with the characteristics of a high degree of sharing and fast data circulation in the big data environment, and problems such as a single point of failure, difficulty in meeting the principle of minimum authorization, difficulty in dynamically adapting to changes in the environment, and difficulty in verifying policy authority have brought “shackles” to the development of access control technology.

The emergence of Attribute-Based Encryption (ABE) [1] brings a new solution to the above problem, which was first proposed by Sahai et al. in 2005, and subsequently developed into Key Policy–Attribute-Based Encryption (KP-ABE) [2] and Ciphertext Policy–Attribute-Based Encryption (CP-ABE) [3]. Data owners can customize access policies in CP-ABE and embed them in ciphertext. This approach not only realizes fine-grained and flexible access control but also solves the problems of traditional access control, which is challenging to satisfy the principle of minimum authorization and dynamically adapt to environmental changes. However, traditional CP-ABE schemes still have some drawbacks in practical applications. For example, in most CP-ABE schemes, with the help of a fully trusted attribute authorization authority, a single authorization authority needs to manage all users’ attributes and be responsible for the key generation and distribution process, which is a considerable workload. Moreover, if the single authorization center in these schemes fails or is maliciously attacked, many user attribute data will be exposed, and the whole system will be affected [4].

Blockchain technology [5], a widely emerging distributed-ledger-based technology, has become a reasonable choice for conducting trusted access control due to its decentralization, data tampering, traceability, non-falsification, and programmability. However, blockchain’s open and transparent nature makes the security and regulation of data stored in blockchain face a series of challenges [6,7]. If blockchain technology is combined with CP-ABE, the cryptographic mechanism of CP-ABE can ensure the confidentiality, privacy, and security of the data stored on the blockchain. In contrast, blockchain technology can provide functions like trusted authority verification and effective auditing for the existing CP-ABE-based schemes. For example, the programs in reference [8] achieve privacy protection and support the accountability of historical protocols through CP-ABE and blockchain technology. Reference [9] considers the advantages of CP-ABE and blockchain combined with cloud storage systems to share medical information effectively. Still, cloud servers storing a large amount of data can lead to privacy leakage and access control that policy permissions cannot credibly verify.

The leading platforms for blockchain applications are Bitcoin, Ethereum, and Hyperledger Fabric. Bitcoin is the blockchain technology’s prototype but lacks privacy protection and smart contracts. As a result, it cannot be used in complex situations. Ethereum is the public blockchain. However, any transaction on Ethereum requires payment. The public blockchain also has no restrictions on participants, who usually participate anonymously, making the public chain quite difficult to regulate. Fabric, as a representative of the consortium blockchain, requires participants to have explicit identifiers so that a malicious participant can be found directly. Therefore, Fabric is more secure than Ethereum. In addition, Fabric provides strong flexibility, pluggability, and scalability by modularizing the technologies of rights management, authentication, consensus mechanism, etc. Fabric can be more easily applied to complex scenarios by designing and developing smart contracts to execute various business logic.

Fabric can also design and develop smart contracts to implement different business logic, making it easier to apply to complex environments.

In summary, the existing schemes still have problems in access control, such as data leakage caused by semi-trusted cloud service providers, a non-transparent and untrustworthy verification of access privileges, an over-concentration of risk in single authorization centers, and overloaded computation. To solve the above problems, this paper proposes an access control scheme based on blockchain and CP-ABE, based on the characteristics of blockchain being de-trusted, decentralized, non-tamperable, and non-forgeable. The main contributions of this paper are as follows:

• A new blockchain-based attribute-based cryptographic access control model is proposed. The introduction of blockchain in this model realizes the auditability of key parameter transmission and the trusted verification of data integrity, decryption correctness, etc., and solves the opaque verification problem of access rights caused by untrusted third parties. The combination of attribute-based encryption and blockchain guarantees that the data owner autonomously and effectively controls the circulation of shared data and protects the security of shared data.
• An improved CP-ABE algorithm supporting access policy updates is proposed. This algorithm updates the access policy without disclosing the original encrypted data and realizes finer-grained and more flexible one-to-many access control with high efficiency and low overhead.
• Using the threshold secret sharing algorithm to split the private key parameters of data visitors, the user private key needs to be calculated by multiple authorization centers collaboratively. Therefore, a single authorization center does not have the ability to generate user private keys. This method not only solves the problems of poor security, heavy computational burden, and unguaranteed data integrity of a single authorization organization, but also improves user privacy and key security.

2. Related Works

Currently, some research focuses on using a single authorization center for access control of attribute-based encryption in cloud computing environments. For instance, Li et al. [10] suggested a safe data-sharing system based on attribute encryption for users with restricted resources. By boosting the system’s public parameters and transferring a portion of the encrypted calculations to an offline state, this approach removed the majority of the calculation jobs. However, this scheme’s access strategy was limited to a description of positive and negative characteristics, leaving out the overall access control framework. Since we must completely rely on the single authorization center, if it is attacked, all the attributes will be accessed, thus lowering the security of the data stored in the cloud.

A solution with numerous authorization centers was created on the foundation of the conventional centralized single authorization agency solution in order to address the issues of low efficiency and inadequate security of a single authorization center. By expanding attribute sources and decentralizing the central master key, the attribute-based encryption scheme of the authorization center increased the variety of access tactics and encryption security. Sharma et al. [11] resolved the key escrow problems by using two authorities in the key generation process. Data owners and attribute authorities manage the key-related and user access policy details in a distributed manner. A new CP-ABE technique for multi-authorization agencies was also created by Gao et al. [12], which enhances user privacy and key security while significantly reducing the possibility of a single point of failure. A method called T-DPU-MCP-ABE (Traceable and Dynamic Policy Updating Multiauthority Attribute-based Encryption) was proposed by Ling et al. [13] in 2021. Data owners may frequently need to adjust the ciphertext access policy to meet diverse requirements. Updates to rules give data owners flexibility and enable them to fine-tune their encrypted data access restrictions for more precise control. A multi-authorization attribute-based encryption system with policy updating and concealing was suggested by Zhang et al. [14]. The untrusted issue with single attribute authorization is likewise resolved by multiple attribute authorities. Data owners can also easily and affordably adjust the access control policy. However, the above scenario relies on a fully trusted agent or a third-party central authority in addition to a semi-trusted multi-authorization center. In practical scenarios, fully trusted agents and third-party central organizations do not exist, and semi-trusted third parties bring new privacy issues. The multi-authorization center scheme proposed in this paper does not rely on a third party and can solve the trust problem in practical applications.

Blockchain technology [5] is an evolving technology with the advantage of decentralization, which is based on a distributed ledger. The issue of data in cloud storage that can be tampered with and whose integrity cannot be guaranteed has been resolved with the creation of blockchain technology [15]. Additionally, this technology is ideally suited to address issues related to ABE. Therefore, to better realize the secure and dependable large-scale exchange of vast data, researchers have recently integrated blockchain and attribute-based encryption technology. An independently revised key strategy ABE system was put forth by Guo et al. [16]. In addition, utilizing blockchain and distributed database technology protected the integrity of private healthcare data stored in the public cloud, preventing nefarious users or authorizers from tampering with private data from the internal cloud, thereby reducing misdiagnosis caused by tampered electronic health records. This scheme was managed by multiple attribute authorization centers, which was closer to the actual situation. To accomplish fine-grained access control to data, Zuo et al. [17] integrated blockchain with attribute-based encryption technology, making all user operations on the chain immutable and permanently maintained. In order to enable cloud security sharing without the usage of a trusted third party, blockchain was employed to authenticate user identities and manage their access privileges. This system prevented unauthorized users from accessing the data until user identification verification was complete. To protect data and attribute privacy, Gao et al. [18] introduced the ABE approach to the blockchain. Due to the strategy’s limited applicability to the compound order group, efficiency was low. A decentralized architecture was proposed by Vasishta et al. [19] to validate access requests through numerous authorities in a decentralized way using Hyperledger Fabric and Attribute-Based Access Control (ABAC). Reference [20] suggested putting ABAC into practice for decentralized authorization across numerous entities. Each organization in this implementation has a separate smart contract to add properties. A blockchain-based cloud data access authorization updating mechanism that supports keyword retrieval was proposed by Lei et al. [21]. According to reference [22], an industrial client can also validate the legitimacy of an IoT device’s distributor and manufacturer and grant permission for the IoT device to join their IoT network by issuing a network certificate. In reference [23], a multi-layer strategy uses blockchain technology for IoT device authentication and authorization. Some of the above research solutions use blockchain to solve only the cloud storage problem, and some only use blockchain for authorization, which does not involve whether the data owner can control the users who access the data. The proposed scheme in this paper uses the consortium blockchain fabric to verify the data in a trustworthy way and realizes transparent pre-verification of access rights by deploying smart contracts on the blockchain so that the data owner has the right to decide who can access the data and realizes true data security.

3. Access-Control-Scheme-Based Blockchain and CP-ABE

3.1. Main Parameters and Definitions

The main parameters involved in the scheme of this paper are shown in

Table 1. Main parameters and definitions.

Parameters	Definitions
${AA}_s$	Multiple attribute authorization centers
${AA}_i$	Single attribute authorization center
$DU$	Data visitors
$DO$	Data owners
$PK$	system public key
$MSK$	System Master Key
$SK$	user private key
$S$	Attribute sets managed by the Attribute Authorization Center
$e\left(\right)$	bilinear mapping
$G,G_1$	prime cyclic group
${tPart}_{i\in (1,n)}$	Users secretly share key shares
${Tx}_X$	Transactions about X in the blockchain
${adress}_X$	Address of X in the blockchain
${PK}_X$	Public key of X in the blockchain
${SK}_X$	Private key of X in the blockchain
${Enc}_{{PK}_X}\left(Y\right)$	Encrypt Y with the public key of X in the blockchain
$hash\left\{Y\right\}$	Hash operation on Y
${sign}_{{SK}_X}\left(Y\right)$	Sign Y with the private key of X in the blockchain
${Compute}_{{PK}_X}\left(Y\right)$	Countersign Y with the public key of X in the blockchain
$M$	Plaintext
$CT$	Ciphertext
${CT}_{iv}$	Pre-verification ciphertext
${CT}_v$	Decrypted ciphertext
$L_x$	Policy Index Set
$hashm$	plaintext hash
$A_x$	The vector corresponding to the xth row of matrix A
${\rho }^{\prime }\left(j\right)$	Attribute in line j of the policy
$R_{x\in (1,2,3)}$	Policy Comparison Determination Results
${UK}_{xϵ(1,2,3)}$	Policy Updated Key

.

3.2. System Model

The system model proposed in this paper is shown in Figure 1, which includes four types of entities: Data Owner ($DO$), Data Visitor ($DU$), Attribute Authorization Center (${AA}_S$), and Blockchain ($BC$).

1. ${AA}_s$ computes the system public key and system master key and distributes the system public key to $DO$. 2. $DU$ randomly selects the t-value and computes ${tPart}_i$. 3. $DU$ broadcasts the computed ${tPart}_i$ to $BC$ nodes. 4. When the data visitor $DU$ needs to obtain its private key, the attribute authorization center ${AA}_S$ obtains ${tPart}_i$ from $BC$. 5. ${AA}_S$ distributes the private key component of $DU$ obtained by substituting ${tPart}_i$ to $DU$. 6. $DO$ generates the ciphertext by specifying a specific access policy. 7. $DO$ then uploads the ciphertext and the hash value of the plaintext to $BC$. 8. If the access policy needs to be updated, $DO$ sends the updated key to $BC$. 9. $BC$ updates the ciphertext based on the updated key. 10.1 After $DU$ obtains the key component from ${AA}_S$, $BC$ pre-verifies whether $DU$ has the access right to the data uploaded by $DO$. 10.2 If the verification passes, $DU$ can obtain the ciphertext and the hash value of the plaintext from $BC$. 10.3 $DU$ decrypts the ciphertext with its private key. In the above process, the entities undertake the following tasks (see Figure 1):

• ${AA}_S$: Organizations that manage attributes in the system. It manages the respective attributes and generates the master key MSK and system public key PK in step 1. In step 4, it obtains the slice of t, ${tPart}_i$, from the computation nodes in the blockchain and distributes the private key component of $DU$ to the $DU$ in step 5.
• $DU$: Users who want to access the data uploaded by the $DO$. In steps two and three, DU is responsible for computing ${tPart}_{i\in (1,n)}$ and broadcasting it to the blockchain. $DU$ obtains the pre-verification result from the blockchain in part 10.1 of step 10. And if the $DU$ has access to the data, the $DU$ obtains the ciphertext and the hash values of the plaintext in part 10.2 of step 10, decrypts them, and verifies the correctness of $t^{\prime }$ using the private key of the $DU$ in part 10.3. If required, $DU$ can verify the correctness of decryption by querying the blockchain transaction.
• $DO$: The user who owns the data and specifies the attributes the visitor requires. The data owner encrypts the plaintext data using a symmetric key, specifies the access policy $\mathcal{A}$ for the data, encrypts the symmetric key to generate the ciphertext $CT$ in step 6, and uploads the ciphertext and the data digest to the blockchain through a transaction in step 7. Based on the running results of the policy comparison algorithm deployed on the smart contract, $DO$ selects the corresponding update key to send to the blockchain via the transaction in step 8.
• $BC$: Consortium blockchain fabric, a platform that ensures that data are stored and shared in a trusted manner. Users can publish and query transactions on the blockchain, providing storage services to secure data (${tPart}_i$ and ciphertext) and services for trusted authentication. In step 9, the blockchain performs the ciphertext update. The blockchain also does the 10.1 pre-verification part of the decryption phase.

3.3. Security Model

Choice Plaintext Attack (CPA) means that the attacker can select a plaintext message in addition to knowing the encryption algorithm to obtain the encrypted ciphertext, i.e., the attacker knows the chosen plaintext and the encrypted ciphertext. Still, they cannot directly break the key. Proof of security is performed by choosing a game of indistinguishability under a plaintext attack, and a game between an adversary and a challenger describes this game.

• Initialization phase. Challenger $\mathcal{C}$ runs the system initialization algorithm, inputs the security parameter $\lambda$, outputs the system public key PK and sends it to adversary $\mathcal{A}$, and saves the system master key MSK. Adversary $\mathcal{A}$ selects the old access policy $(A,\rho )$ and the new access policy $(A^{\prime },{\rho }^{\prime })$ that it wishes to attack.
• Querying private key phase 1. Adversary $\mathcal{A}$ adaptively submits a series of attribute sets $U=(u_1,u_2,u_3,\dots \dots u_l)$ that do not satisfy the old and new access policies to challenger $\mathcal{C}$. $\mathcal{C}$ runs the key generation algorithm to generate the corresponding key SK to sends it to adversary $\mathcal{A}$.
• Challenge phase. Adversary $\mathcal{A}$ submits two equal-length messages $m_0$ and $m_1$ to challenger $\mathcal{C}$. $\mathcal{C}$ randomly selects $bϵ(0,1)$ and runs a cryptographic algorithm to encrypt $m_b$ under the old access policy $\mathcal{P}$; challenger $\mathcal{C}$ performs a dynamic update of the access policy and generates an updated ciphertext based on the determination result of the old and the new access policies; $\mathcal{C}$ sends the updated ciphertext to adversary $\mathcal{A}$.
• Querying private key phase 2. Similar to Phase 1, adversary $\mathcal{A}$ continues to submit attribute $u_l$ to challenger $\mathcal{C}$ for querying other attribute keys, with the stipulation that $u_l$ still does not satisfy the access policy $\mathcal{P}$.
• Guessing phase. Adversary $\mathcal{A}$ gives a guess $b^{\prime }$ for $b$. The adversary wins the game if $b^{\prime }=b$, since any inactive adversary $\mathcal{A}$ can win this game with a probability $\frac{1}{2}$ by making a random guess on $b$. $\mathcal{A}$’s advantage in this game is defined as

  $${Ad}_{vA}=|Pr\left[b^{\prime }=b\right]-\frac{1}{2}|$$

The goal of the adversary is to guess the value of $b$ with a probability greater than $\frac{1}{2}$. If the above ${Ad}_{vA}$ can be ignored, this cryptosystem is considered indistinguishable under a chosen-plaintext attack and is called IND-CPA secure.

3.4. Operation Flow

The operation flow of the data access control scheme based on blockchain and attribute-based encryption is shown in Figure 2, and the specific implementation details of this scheme are as follows.

3.5. Scheme Construction

3.5.1. Initialization Stage

$AAs$ executes the algorithm. The algorithm inputs the security parameter $\lambda$ and outputs the system public key $PK=(G,G_1,g,H,e\left(g,g\right),\alpha r,g^{\alpha },\alpha \beta )$ and the system master key $MSK=(r,\alpha ,\beta )$ with randomly chosen $r,\alpha ,\beta \in Z_p$. The bilinear mapping $e:G\times G\to G_1$, where $G$ and $G_1$ are cyclic groups of primes order $p$, and $g$ is the generator of $G$. The hash function $H$ maps an attribute in the system to an element in $G$. $S$ denotes the set of attributes managed by the $AAs$.

3.5.2. ${tPart}_i$ Generation Stage

The algorithm is executed by $DU$. The $DU$ inputs random numbers $(m,n)$ and $t\in Z_p$, and uses the threshold secret sharing algorithm to divide $t$ into $n$ slices of $t$, ${tPart}_{i\in (1,n)}$.

$$f\left(x\right)=t+a_{1}x+\cdots +a_m{x}_m$$

(1)

$${tPart}_i=f\left(x_i\right)$$

(2)

$DU$ broadcasts the slices of $t$ to the blockchain via the ${tPart}_i$ storage transaction, and nodes in the blockchain verify the transaction.

3.5.3. ${Tx}_{{tPart}_i\_storage}$ Generation Stage

When Fabric processes each transaction, each link needs to verify the authority of the transaction information, and the application client invokes the certificate $CA$ service through the $SDK$ for registration and enrollment and obtains the identity certificate. So, $DU$, $DO$, and $AAs$ also have their public–private key pairs in Fabric.

After generating the ${tPart}_i$ storage transaction shown in Algorithm 1, $DU$ broadcasts the transaction to other nodes in the blockchain to verify it.

Algorithm 1 ${Tx}_{{tPart}_i\_storage}$ generation transaction.

Input: transaction $id$, ${tPart}_i$, public key ${PK}_{AAs}$ of $AAs$ in the blockchain, the address of nodes ${adress}_{ComNodes}$, private key ${SK}_{DU}$ of $DU$ in the blockchain Output: ${Tx}_{{tPart}_i\_storage}$ transaction

$for$ $1\le i\le n$   $do$     /*$AAs$ encrypt _${tPart}_i$ with their public keys ${PK}_{AAs}$ in the blockchain*/     $E\left({tPart}_i\right)={Enc}_{{PK}_{AAs}}\left({tPart}_i\right)$     /*$DU$ compute the hash value of the transaction $id$, $E\left({tPart}_i\right)$ and the address of the nodes ${adress}_{ComNodes}$.*/     $s_{{tPart}_i}=hash\left\{id,E\left({tPart}_i\right),{adress}_{ComNodes}\right\}$     /*$DU$ sign $s_{{tPart}_i}$ with their private keys ${SK}_{DU}$ in the blockchain*/     $sign={sign}_{{SK}_{DU}}\left(s_{{tPart}_i}\right)$     ${Tx}_{{tPart}_i\_storage}=\left\{id,E\left({tPart}_i\right),{adress}_{ComNodes},sign\right\}$   $return$ ${Tx}_{{tPart}_i\_storage}$

3.5.4. ${Tx}_{{tPart}_i\_storage}$ Verification Stage

Each node receives the ${Tx}_{{tPart}_i\_storage}$ transaction; obtains the transaction $id$, $E\left({tPart}_i\right)$, and ${adress}_{ComNodes}$ from it; and compares it with the $DU$ signed digest $s_{{tPart}_i}$ by computing the hash value $s_{{tPart}_i}^{\prime }$ of the three, as shown in Algorithm 2. If it returns $true$, it means the verification passes, and nodes in the blockchain will obtain $E\left({tPart}_i\right)$ from the ${Tx}_{{tPart}_i\_storage}$ transaction to keep it on behalf of the $AAs$.

Algorithm 2  ${Tx}_{{tPart}_i\_storage}$ verification transaction.

Input:${Tx}_{{tPart}_i\_storage}$, public key ${PK}_{DU}$ of $DU$ in the blockchain Output: verification results

$for$ $1\le i\le n$   $do$     /*Nodes compute the hash value of the transaction $id$, $E\left({tPart}_i\right)$ and the address of the nodes ${adress}_{ComNodes}$.*/     $s_{{tPart}_i}^{\prime }=hash\left\{id,E\left({tPart}_i\right),{adress}_{ComNodes}\right\}$     /*Countersign*/     $s_{{tPart}_i}={Compute}_{{PK}_{DU}}\left(sign\right)$     $if$ $s_{{tPart}_i}^{\prime }=s_{{tPart}_i}$       $return$ $true$     $else$       $return$ $false$

3.5.5. ${Tx}_{{tPart}_i\_sharing}$ generation Stage

In Algorithm 3, $AAs$ obtains $E\left({tPart}_i\right)$ through the ${Tx}_{{tPart}_i\_sharing}=\left\{id,E\left({tPart}_i\right),{adress}_{AAs},sign\right\}$ transaction and decrypts $E\left({tPart}_i\right)$ with its own private key ${SK}_{AAs}$ to obtain ${tPart}_i$. The above three transactions coordinate with transferring ${tPart}_i$ from $DU$ to $AAs$ and, at the same time, record the transmission process of the actual key parameter ${tPart}_i$ on the blockchain. It reduces the security risks faced by ${tPart}_i$ in the process and realizes the traceability of key parameters.

Algorithm 3  ${Tx}_{{tPart}_i\_sharing}$ generation transaction.

Input: transaction $id$, $E\left({tPart}_i\right)$, the address of the $AAs$ ${adress}_{AAs}$, private key ${SK}_{ComNodes}$ of the nodes in the blockchain Output: ${Tx}_{{tPart}_i\_sharing}$ transaction

$for$ $1\le i\le n$   $do$     /*Nodes in the blockchain compute hash value*/     ${sh}_{{tPart}_i}=hash\left\{id,E\left({tPart}_i\right),{adress}_{AAs}\right\}$     /*Nodes sign ${sh}_{{tPart}_i}$ with their private keys ${SK}_{ComNodes}$ in the blockchain*/     $sign={sign}_{{SK}_{ComNodes}}\left({sh}_{{tPart}_i}\right)$     ${Tx}_{{tPart}_i\_sharing}=\left\{id,E\left({tPart}_i\right),{adress}_{AAs},sign\right\}$   $return$ ${Tx}_{{tPart}_i\_sharing}$

3.5.6. Key Generation Stage

The algorithm is executed by the $AAs$ that keep the ${tPart}_i$. The algorithm takes the set of user attributes $U=(u_1,u_2,u_3,\dots \dots u_l)$, ${tPart}_i$, $PK$, and $MSK$ as inputs, and outputs the user’s private key $SK$. The $AAs$ firstly reconstructs the value $t$ secretly, and for each $u_i\in U$, the respective attribute authorization center computes the private key component $D_{i,1}$.

$$g\left(x\right)=\prod _{i=1}^m\frac{x-x_j}{x_i-x_j}$$

(3)

$$t=\sum _{i=1}^m{tPart}_i·g\left(x_i\right)$$

(4)

$$\forall u_i\in U,SK=\left\{D_{i,1},D_2,D_3,D_4\right\}=\left\{D_{i,1}={H\left(u_i\right)}^{rt},D_2=g^{\frac{1}{\beta }},D_3=g^{\alpha t},D_4=g^r\right\}$$

(5)

The user combines the above four key components to obtain $SK=\left\{D_{i,1},D_2,D_3,D_4\right\}$. The above private key generation stage has at least threshold value $m$ attribute authorization centers for collaborative computation to secretly reconstruct the value $t$. Therefore, a single ${AA}_i$ does not have the ability to generate $DU$ key components. When a single authorization center suffers from the attack, the security of the whole system will not be affected, which ensures that the $DU$ private key will not be leaked.

3.5.7. Encryption Stage

The encryption phase is performed by $DO$. This paper adopts the linear secret sharing schemes (LSSS) access structure. The algorithm takes $PK$, plaintext $M$, and $k\times l$ access matrix $A$ as inputs, where $\rho$ maps each row of the matrix to an attribute. The output is the ciphertext $CT$ associated with the access structure $A$. The algorithm chooses the random vector $\overrightarrow{v}=(s,v_2,\dots v_l)\in Z_p^l$, $v_2,\dots v_l$ for sharing the secret $s$. ${\lambda }_x=A_x{\overrightarrow{v}}^T$ is calculated. The random vector $\overrightarrow{\omega }=(0,{\omega }_2,\dots {\omega }_l)\in Z_p^l$ is chosen and ${\omega }_x=A_x{\overrightarrow{\omega }}^T$ is chosen, where $A_x$ represents the vector corresponding to the xth row of matrix $A$. $L_x=\left\{x\left|\rho \right(x)\in S\right\}$ is defined, $z_x\in Z_p$ is chosen at random, and the following is computed:

$$C_M=M{e\left(g,g\right)}^{sr}$$

(6)

$$\begin{array}{cc}\hfill \forall x\in \left[1,k\right],CT& =\left({CT}_{iv},{CT}_v\right)\hfill \\ & =\left\{{{(C}_{x,1},C_{x,2})}_{x\in \left[1,k\right]},{{(C}_{x,3}{,C}_{x,4},C_M)}_{x\in \left[1,k\right]}\right\}\hfill \\ & =\left\{\begin{array}{c}{C}_{x,1}={H\left[\rho \left(x\right)\right]}^{{rz}_x},C_{x,2}=g^{\alpha z_x}{g}^{\alpha },C_{x,3}={H\left[\rho \left(x\right)\right]}^{\alpha \beta }{g}^{{\omega }_x},\\ C_{x,4}=g^{{\lambda }_x},C_M=M{e\left(g,g\right)}^{sr}\end{array}\right\}\hfill \end{array}$$

(7)

In this paper, the shared data are subjected to a blockchain-based decentralized trusted verification of access rights and encryption/decryption correctness, and the ciphertext $CT$ components are classified into two categories: pre-verification ciphertext ${CT}_{iv}$ and decryption ciphertext ${CT}_v$. The ciphertext $CT$ is uploaded to the blockchain and verified through the ${Tx}_{{CT}_{iv}\_storage}$ generation transaction. In the encryption phase, $DO$ also needs to calculate the hash value $hashm$ of the plaintext $M$, upload it to the blockchain through the ${Tx}_{hashm\_storage}$ transaction, and verify it. The ${Tx}_{{CT}_v\_storage}$ generation transaction and ${Tx}_{hashm\_storage}$ generation transaction are similar to the ${Tx}_{{tPart}_i\_storage}$ generation transaction and ${Tx}_{{CT}_v\_storage}$ verification transaction, respectively; and the ${Tx}_{hashm\_storage}$ verification transaction is similar to the ${Tx}_{{tPart}_i\_storage}$ verification transaction.

3.5.8. Policy Comparison Stage

In Algorithm 4, if the $DO$ needs to update the access policy, the $DO$ invokes the policy comparison algorithm deployed in the smart contract, and this algorithm outputs the results $R_1$, $R_2$, and $R_3$ by determining the type of the new policy attribute ${\rho }^{\prime }\left(j\right)$.

Algorithm 4 Policy comparison algorithm.

Input: old policy $(A,\rho )$, new policy $(A^{\prime },{\rho }^{\prime })$ $\mathbf{Output}: R_{x\in (1,2,3)}$

$for$ $j\in [1,k^{\prime }]$ $do$   $if$ ${\rho }^{\prime }\left(j\right)$ exist in $A$ $then$     $if$ $L_x\ne \varnothing$ and $\exists x\in L_x$,$\rho \left(x\right)={\rho }^{\prime }\left(j\right)$       add $(j,x)$ into $R_1$       delete $x$ from $L_x$     else       $\forall x\in [1,k]$,$\rho \left(x\right)={\rho }^{\prime }\left(j\right)$       add $(j,x)$ into $R_2$   else     add $(j,0)$ into $R_3$

3.5.9. Updated Key Generation Stage

At the updated key generation stage, $DO$ inputs $PK$, selects the updated key ${UK}_{x\in (A,B,C)}$ according to the output of the policy comparison algorithm, and constructs new random vectors ${\overrightarrow{v}}^{\prime }\in Z_p^{l^{\prime }}$ and ${\overrightarrow{\omega }}^{\prime }\in Z_p^{l^{\prime }}$, where the first terms are $s$ and $0,$ respectively. $DO$ computes ${\lambda }_j=A_j^{\prime }{{\overrightarrow{v}}^{\prime }}^T$ and ${\omega }_j=A_j^{\prime }{{\overrightarrow{\omega }}^{\prime }}^T$. The generated policy updated key ${UK}_m$ is sent to the blockchain and verified by the ${Tx}_{UpKeygen\_storage}$ transaction, which is similar to the ${Tx}_{{tPart}_i\_storage}$ transaction.

$$\begin{gathered} \forall j\in \left[1,k^{\prime }\right],\left(j,x\right)\in R_1:{UK}_1=\left\{{UK}_{1,A}=g^{{\omega }_j-{\omega }_x},{UK}_{1,B}=g^{{\lambda }_j-{\lambda }_x}\right\} \\ \forall j\in \left[1,k^{\prime }\right],\left(j,x\right)\in R_2:{UK}_2=\left\{a_j,{UK}_{2,A}=g^{{{\omega }_j-a_j\omega }_x},{UK}_{2,B}=g^{{{\lambda }_j-a_j\lambda }_x}\right\}, \end{gathered}$$

where $r_j={r_{x}a}_j$,${\alpha }_j={\alpha }_x{a}_j$ and

$$\forall j\in [1,k^{\prime }],(j,x)\in R_3:{UK}_3=\left\{\begin{array}{c}{UK}_{3,A}={H\left[{\rho }^{\prime }\left(j\right)\right]}^{r_j{z}_j},{UK}_{3,B}=g^{{\alpha }_j{z}_j}{g}^{{\alpha }_j},\\ {UK}_{3,C}={H\left[{\rho }^{\prime }\left(j\right)\right]}^{{\alpha }_j{\beta }_j}{g}^{{\omega }_j},{UK}_{3,D}=g^{{\lambda }_j}\end{array}\right\}$$

3.5.10. Updated Ciphertext Generation Stage

After receiving the policy updated key ${UK}_{xϵ(1,2,3)}$, the blockchain inputs the $PK$ and the old ciphertext $CT$ and updates the ciphertext as follows.

• If ${UK}_1$,

$$\begin{gathered} C_{j,1}^{\prime }=C_{x,1}={H\left[{\rho }^{\prime }\left(j\right)\right]}^{r_j{z}_j} \\ {C}_{j,2}^{\prime }=C_{x,2}=g^{{\alpha }_j{z}_j}{g}^{{\alpha }_j} \\ {C}_{j,3}^{\prime }=C_{x,3}·{UK}_{1,A}={{H\left[\rho \left(x\right)\right]}^{{\alpha }_x{\beta }_x}g}^{{\omega }_x}{g}^{{\omega }_j-{\omega }_x}={H\left[{\rho }^{\prime }\left(j\right)\right]}^{{\alpha }_j{\beta }_j}{g}^{{\omega }_j} \\ {C}_{j,4}^{\prime }=C_{x,4}=g^{{\lambda }_x}·{UK}_{1,B}={g^{{\lambda }_x}g}^{{\lambda }_j-{\lambda }_x}=g^{{\lambda }_j} \end{gathered}$$

• If ${UK}_2$,

$$\begin{gathered} C_{j,1}^{\prime }={{(C}_{x,1})}^{a_j}={H\left[\rho \left(x\right)\right]}^{{a_{j}r}_x{z}_x}={H\left[{\rho }^{\prime }\left(j\right)\right]}^{r_j{z}_j} \\ {C}_{j,2}^{\prime }={{(C}_{x,2})}^{a_j}=g^{{{\alpha }_{x}z}_x{a}_j}{g}^{{\alpha }_x{a}_j}=g^{{{\alpha }_{j}z}_j}{g}^{{\alpha }_j} \\ {C}_{j,3}^{\prime }={{(C}_{x,3})}^{a_j}·{UK}_{2,A}={H\left[\rho \left(x\right)\right]}^{{a_j\alpha }_x{\beta }_x}{g}^{{a_j\omega }_x}·g^{{{\omega }_j-a_j\omega }_x}={H\left[{\rho }^{\prime }\left(j\right)\right]}^{{\alpha }_j{\beta }_j} \\ {C}_{j,4}^{\prime }={{(C}_{x,4})}^{a_j}{UK}_{2,B}=g^{a_j{\lambda }_x}{g}^{{{\lambda }_j-a_j\lambda }_x}=g^{{\lambda }_j}, \end{gathered}$$

where $r_j={a_{j}r}_x$ and ${\alpha }_j={\alpha }_x{a}_j$.

• If ${UK}_3$,

$$\begin{gathered} C_{j,1}^{\prime }={UK}_{3,A}={H\left[{\rho }^{\prime }\left(j\right)\right]}^{r_j{z}_j} \\ {C}_{j,2}^{\prime }={UK}_{3,B}=g^{{\alpha }_j{z}_j}{g}^{{\alpha }_j} \\ {C}_{j,3}^{\prime }={UK}_{3,C}={H\left[{\rho }^{\prime }\left(j\right)\right]}^{{\alpha }_j{\beta }_j}{g}^{{\omega }_j} \\ {C}_{j,4}^{\prime }={UK}_{3,D}=g^{{\lambda }_j} \end{gathered}$$

The blockchain is authorized to re-encrypt the ciphertext, and the policy updated key only reveals the relationship between the old and new access policies. It does not disclose any information about the encrypted data.

3.5.11. Decryption Stage

The decryption phase consists of two parts: pre-verification and decryption. Pre-verification verifies whether the $DU$ has access rights to the data, and the $DU$ invokes the smart contract through the contract generation transaction ${Tx}_{contract}$ and obtains the partial ciphertext before decryption to verify the access rights. If the $DU$ attribute sets satisfy the access policy, the algorithm will output the correct result. Otherwise, it will output $\perp$, as shown in Algorithm 5.

Algorithm 5 Pre-verification algorithm.

$\mathbf{Input}: {CT}_{iv}$, $D_{i,1}$, $D_3$, $PK$ $\mathbf{Output}: result$ or $\perp$

$for$ $1\le i\le n$   $do$     $e\left(C_{x,2},D_{i,1}\right)=e\left(g^{\alpha z_x}{g}^{\alpha },{H\left(u_i\right)}^{r{t}^{\prime }}\right)={e(g,H\left(u_i\right))}^{\alpha z_x{rt}^{\prime }}{·e(g,H\left(u_i\right))}^{\alpha r{t}^{\prime }}$     $e\left(g^{\alpha },D_{i,1}\right)=e\left(g^{\alpha },{H\left(u_i\right)}^{r{t}^{\prime }}\right)={e(g,H\left(u_i\right))}^{\alpha r{t}^{\prime }}$     $e\left(C_{x,1},D_3\right)=e\left({H\left[\rho \left(x\right)\right]}^{{rz}_x},g^{\alpha t^{\prime }}\right)={e\left(H\right(\rho \left(x\right),g)}^{r{z}_x\alpha t^{\prime }}$     $if$ $\frac{e\left(C_{x,2},D_{i,1}\right)}{e\left(C_{x,1},D_3\right)·e\left(C_{x,1},D_3\right)}=1$       $result=\left\{e\left(C_{x,2},D_{i,1}\right),e\left(C_{x,1},D_3\right)\right\}$       $return$ $result$     $else$       $return$ $\perp$

After verifying the access rights, the fully trusted $DU$ receives the $result$, obtains the decrypted ciphertext ${CT}_v$ from the blockchain through the ${Tx}_{{CT}_v\_sharing}$ transaction, and decrypts it with the private key. In the decryption phase, $DU$ inputs $PK$, $DU$’s private key $SK$, and value $t$. If the value of $t$ is the same as the value of $t^{\prime }$ after collaborative computation by $m$ attribute authorization centers in $Keygen$ phase, the following computation is performed:

$$e\left(C_{x,4},D_4\right)=e\left(g^{{\lambda }_x},g^r\right)={e\left(g,g\right)}^{{\lambda }_{x}r}$$

(8)

$${e\left(C_{x,3},D_{i,2}\right)}^{rt}={e\left({H\left[\rho \left(x\right)\right]}^{\alpha \beta }{g}^{{\omega }_x},g^{\frac{1}{\beta }}\right)}^{rt}={e\left(H\right(\rho \left(x\right),g)}^{\alpha rt}·{e\left(g,g\right)}^{\frac{{rt\omega }_x}{\beta }}$$

(9)

$$\tilde{C}=\frac{e\left(C_{x,2},D_{i,1}\right)·{e\left(g,g\right)}^{{\lambda }_{x}r}}{{e\left(H\right(\rho \left(x\right),g)}^{\alpha rt}·{e\left(g,g\right)}^{\frac{{rt\omega }_x}{\beta }}·e\left(C_{x,1},D_3\right)}$$

(10)

In the above process, $t^{\prime }=t$ proves that $m$ semi-trusted attribute authorizations correctly compute the value $t^{\prime }$, and the legitimate $DU$ obtains the correct key component. If $\tilde{C}=\frac{{e(g,g)}^{{\lambda }_{x}r}}{{e(g,g)}^{\frac{{rt\omega }_x}{\beta }}}$), then $DU$ chooses the constant $c_x\in Z_p$ that satisfies $\sum c_x{A}_x=(\mathrm{1,0},\dots ,0)$ and computes

$$\frac{C_M}{\prod {\tilde{C}}^{c_x}}=M^{\prime }$$

(11)

This process generates plaintext $M^{\prime }$. The user $DU$ encrypts the plaintext $M^{\prime }$ obtained from the decryption algorithm with the help of the SHA256 algorithm and compares its hash value $hash{m}^{\prime }$ with the $hashm$ obtained through the blockchain ${Tx}_{hashm\_sharing}$ transaction. If $hash{m}^{\prime }=hashm$, then the decryption is correct and the data are complete.

4. Proof of Security

Definition 1.

(The Decisional q-Parallel Bilinear Diffie–Hellman Exponent problem): Choose a group $G$ of prime order p according to the security parameter. Let $a,s,b_1,\dots ,b_qϵZ_q$ be chosen at random and $g$ be a generator of $G$. If an adversary is given, $\mathit{y}=$

$$\begin{gathered} g,g^s,g^a,\dots ,g^{\left(a^q\right)},g^{\left(a^{q+2}\right)},\dots ,g^{\left(a^{2q}\right)} \\ {\forall }_{1\le j\le q}{g}^{s·b_j}, g^{\frac{a}{b_j}},\dots ,g^{\left(\frac{a^q}{b_j}\right)},g^{\left(\frac{a^{q+2}}{b_j}\right)},\dots ,g^{\left(\frac{a^{2q}}{b_j}\right)} \\ {\forall }_{1\le j,k\le q,k\ne j}{g}^{\frac{as{b}_k}{b_j}},\dots ,g^{\frac{a^{q}s{b}_k}{b_j}} \end{gathered}$$

It must remain difficult to distinguish ${e(g,g)}^{a^{q+1}s}ϵG_T$ from a random element in $G_T$. An algorithm $\mathcal{B}$ that outputs $zϵ(0,1)$ has an advantage $\epsilon$ in solving the decisional q-parallel BDHE in $G$ if

$$\left|Pr\left[\mathcal{B}\left(\mathit{y},T={e(g,g)}^{a^{q+1}s}\right)=0\right]-Pr\left[\mathcal{B}\left(\mathit{y},T=R\right)=0\right]\right|\ge \epsilon$$

We say that the (decision) q parallel-BDHE assumption holds if no polytime algorithm has a non-negligible advantage in solving the decisional q-parallel BDHE problem.

Theorem 1.

Suppose an adversary $\mathcal{A}$ can attack this scheme with a non-negligible advantage ε; in probabilistic polynomial time. Then, a challenger $\mathcal{C}$ can solve the q-Parallel BDHE hypothesis with an advantage of $\epsilon /2$.

Proof of Theorem 1.

The challenger picks two multiplicative cyclic groups $G$ and $G_T$, the generator $g$, and the bilinear mapping $e:G\times G\to G_T$. Set a q-Parallel BDHE challenge with randomly chosen $bϵ\left\{0,1\right\}$, $RϵG_T$, and take $Z={e(g,g)}^{a^{q+1}s}$ if $b=0$; otherwise, take $T=R$.

• Initialization phase.

The challenger $\mathcal{C}$ obtains the access structure $(A^{*},{\rho }^{*})$ that the adversary $\mathcal{A}$ wishes to challenge, and $A^{*}$ is a $k^{*}\times l^{*}$ matrix. $\mathcal{C}$ chooses the random number ${\alpha }^{\prime }\in Z_p$ such that $e\left(g^{\alpha },g^{a^q}\right){e(g,g)}^{{\alpha }^{\prime }}={e(g,g)}^{\alpha }$, with the implication that $\alpha ={\alpha }^{\prime }+a^{q+1}$.

For each $x$ in $A_x$, $\mathcal{C}$ chooses $m_x$ at random. Let $X$ be the set of $x$ satisfying ${\rho }^{*}\left(x\right)=x$. It can be sought that

$$H\left(A_x\right)=g^{m_x}{\prod }_{x\in X}{g}^{\frac{a{A}_{x,1}^{*}}{b_i}}·g^{\frac{a^2{A}_{x,1}^{*}}{b_i}}·\dots ·g^{\frac{a^{l^{*}}{A}_{x,l}^{*}}{b_i}}$$

The above expression $g^{m_x}$ is randomly distributed, so $H\left(A_x\right)$ is also randomly distributed. If $X=\varnothing$, $H\left(A_x\right)=g^{m_x}$.

• Querying private key phase 1.

Adversary $\mathcal{A}$ adaptively submits a set of attributes $U$ not satisfying $(A^{*},{\rho }^{*})$ to ask for the private key. Challenger $\mathcal{C}$ chooses the random number $r\in Z_p$ and finds the vector $\overrightarrow{\omega }=({\omega }_1,{\omega }_2,\dots {\omega }_l)\in Z_p^{l^{*}}$ with the first term ${\omega }_1=1$, $\overrightarrow{\omega }·A_x^{*}=0$ for ${\rho }^{*}\left(x\right)\in U$. Define $K^{\prime }=g^r{\prod }_{x=1}^{l^{*}}{\left(g^{a^{q+1-x}}\right)}^{{\omega }_x}=g^t$, where $t=r+{\omega }_1{a}^q+{\omega }_2{a}^{q-1}+\dots +{\omega }_l{a}^{q-l^{*}+1}$.

Challenger $\mathcal{C}$ cannot model the unknown term $g^{\frac{a^{q+1}}{b_i}}$, so it must be ensured that the $K_x$ expression does not contain a term of the form $g^{\frac{a^{q+1}}{b_i}}$. Challenger $\mathcal{C}$ computes $K=g^{{\alpha }^{\prime }}{g}^{ar}{\prod }_{x=2}^{l^{*}}{\left(g^{a^{q+2-x}}\right)}^{{\omega }_x}$.

If $x\in U$ and there is no $x$ such that ${\rho }^{*}\left(i\right)=x$, one can make $K_x=K^{\prime m_x}$.

If $x\in U$, there is more than one $x$ such that ${\rho }^{*}\left(i\right)=x$, and all equations of the form $g^{\frac{a^{q+1}}{b_i}}$ can be cancelled out by $\overrightarrow{\omega }·A_x^{*}=0$. Let $X$ be the set of $x$ satisfying ${\rho }^{*}\left(x\right)=x$. $\mathcal{C}$ constructs $K_x$ according to the following equation:

$$K_x=K^{\prime m_x}\prod _{i\in X}\prod _{j=1}^{l^{*}}{\left\{{{(g}^{\frac{a^j}{b_i}})}^r\prod _{\begin{array}{c}u=1,\dots l^{*}\\ u\ne j\end{array}}{(g^{\frac{a^{q+1+j-n}}{b_i}})}^{{\omega }_u}\right\}}^{A_{i,j}^{*}}$$

• Challenge phase.

The adversary $\mathcal{A}$ submits two equal-length challenge messages $m_0$ and $m_1$ to the challenger $\mathcal{C}$. $\mathcal{C}$ chooses at random $b\in \left(\mathrm{1,0}\right)$ and the random numbers $y_2^{\prime },\dots ,y_{l^{*}}^{\prime }$ and uses $\overrightarrow{v}$ for secret sharing on $s$.

$$\overrightarrow{v}=(s,sa+y_2^{\prime },s{a}^2+y_3^{\prime },\dots ,s{a}^{l-1}+y_{l^{*}}^{\prime })\in Z_p^{l^{*}}$$

In addition, $\mathcal{C}$ randomly selects $z_1^{\prime },\dots ,z_l^{\prime }$ to generate the challenge ciphertext ${CT}^{*}$ as follows:

$$\begin{gathered} C_M=m_b·Z·e\left(g^s,g^{{\alpha }^{\prime }}\right) \\ {C}_{x,1}=H^{r{z}_l^{\prime }}\left[\rho \left(x\right)\right], C_{x,2}=g^{\alpha z_l^{\prime }}{g}^{\alpha }, C_{x,3}=g^{\alpha \beta }{g}^{{\omega }_x^{\prime }}, C_{x,4}=g^{{\lambda }_x^{\prime }} \end{gathered}$$

• Querying private key phase 2.

Similar to Phase 1.

• Guessing phase.

The adversary $\mathcal{A}$ outputs a guess $b^{\prime }$ for $b$. If $b^{\prime }=b$, challenger $\mathcal{C}$ outputs ${\mu }^{\prime }=0$, denoting $Z={e(g,g)}^{a^{q+1}s}$; otherwise, challenger $\mathcal{C}$ outputs ${\mu }^{\prime }=1$, denoting $Z=R$. $\mathcal{A}$’s advantage in that game is defined as $\epsilon$.

If $\mu =0$, $\mathcal{A}$ obtains a valid ciphertext and $Pr\left[b^{\prime }=b|\mu =0\right]=\frac{1}{2}+\epsilon$;

$\mathcal{C}$ guesses that $b^{\prime }=b$ when ${\mu }^{\prime }=0$ and $Pr\left[{\mu }^{\prime }=\mu |\mu =0\right]=\frac{1}{2}+\epsilon$;

If $\mu =1$, $\mathcal{A}$ obtains invalid information and $Pr\left[b^{\prime }\ne b|\mu =1\right]=\frac{1}{2}$;

$\mathcal{C}$ guesses that $b^{\prime }\ne b$ when ${\mu }^{\prime }=1$ and $Pr\left[{\mu }^{\prime }=\mu |\mu =1\right]=\frac{1}{2}$.

Thus, the advantage of $\mathcal{C}$ in solving the deterministic hypothesis q-Parallel BDHE problem is

$$\begin{array}{cc}\hfill {Ad}_{vA}& =Pr\left[b^{\prime }=b\right]-\frac{1}{2}\hfill \\ & =\frac{1}{2}Pr\left[{\mu }^{\prime }=\mu |\mu =0\right]+\frac{1}{2}Pr\left[{\mu }^{\prime }=\mu |\mu =1\right]-\frac{1}{2}\hfill \\ & =\frac{1}{2}\left(\frac{1}{2}+\epsilon \right)+\frac{1}{2}\times \frac{1}{2}-\frac{1}{2}\hfill \\ & =\frac{\epsilon }{2} \square \hfill \end{array}$$

Based on the q-Parallel BDHE hypothesis, the challenger has a non-negligible advantage, proving that the scheme proposed in this paper is IND-CPA-safe under the q-Parallel BDHE hypothesis.

5. Performance Analysis

5.1. Functional Comparison

This section presents a comparative analysis of the schemes of reference [3,14,24] and this paper in terms of six aspects: access structure, multiple authorization centers, policy update, pre-validation, correctness verification, and blockchain, as shown in

Table 2. Comparison of the performance of different schemes.

Scheme	Blockchain	Pre-Verification	Correctness Verification	Multi-Authorization Center	Policy Update	Access Structure
[3]	×	×	×	×	×	LSSS
[14]	×	×	√	√	√	AND
[24]	√	√	√	×	×	LSSS
Scheme of this paper	√	√	√	√	√	LSSS

. The symbols × and √ represent whether the scheme has the function. Table 2 shows that reference [14] implements decryption correctness verification, and this paper and reference [24] implement decentralized trusted verification based on blockchain, which implements a pre-verification of access rights and verification of decryption correctness, respectively. Among these three schemes, reference [24] has only one authorization center to manage all users’ attributes and key distribution, which is a heavy workload and faces trust crises. Zhang et al. [14] and the scheme proposed in this paper also implement the access policy update function under the premise of multiple authorization centers. However, the access structure of reference [14] adopts a simple AND gate, which supports only the AND form when expressing the access policy and cannot express access policies with more complex logical structures, and is also limited in realizing fine-grained access control. Meanwhile, the multi-authorization center in the system designed in reference [14] needs a fully trusted third-party central authority to distribute global parameters for it, but in some application scenarios, the fully trusted third party does not exist, in which case the semi-trusted multi-authorization center may distribute incorrect private keys to legitimate data visitors, and the practical application scenarios of reference [14] are greatly limited. This is the reason why this paper designs the data visitor to provide the t-value in advance, which ensures that the semi-trusted multi-authorization center still generates the correct private key for the legitimate user in the absence of a third-party fully trusted central authority. In addition, the blockchain introduced in this paper’s scheme also guarantees that the data delivered under the de-trusted condition are not tampered with. In summary, the scheme in this paper realizes the above essential features simultaneously, solves the trust problem of access control systems in practical application scenarios, and is functionally superior to other schemes.

5.2. Comparison of Computation

Table 3. The computational overhead of different schemes.

Scheme	$\mathbf{K}\mathbf{e}\mathbf{y}\mathbf{g}\mathbf{e}\mathbf{n}$	$\mathbf{E}\mathbf{n}\mathbf{c}$	$\mathbf{D}\mathbf{e}\mathbf{c}$	$\mathbf{K}\mathbf{e}\mathbf{y}\mathbf{g}\mathbf{e}\mathbf{n}+\mathbf{E}\mathbf{n}\mathbf{c}+\mathbf{D}\mathbf{e}\mathbf{c}$
[3]	$\left(n_u+2\right){exp}_G$	$\left(3n_p+1\right){exp}_G+{exp}_{G_1}$	$n_p{exp}_{G_1}+(2n_p+1)$e	$\left(n_u+3n_p+3\right){exp}_G+\left(n_p+1\right){exp}_{G_1}+(2n_p+1)$e
[14]	$\left(3n_u+2\right){exp}_G$	$\left(n_p+3\right){exp}_G+n_p{exp}_{G_1}$	$4e$	$\left(3n_u+n_p+5\right){exp}_G+n_p{exp}_{G_1}+4e$
[24]	$5n_u{exp}_G$	$\left(5n_p+2\right){exp}_G+2{exp}_{G_1}$	${exp}_G+(n_p+1)e$	$\left(5n_u+5n_p+3\right){exp}_G+2{exp}_{G_1}+(n_p+1)e$
Scheme of this paper	$\left(n_u+3\right){exp}_G$	$5n_p{exp}_G+{exp}_{G_1}$	${exp}_G+2n_{p}e$	$\left(n_u+5n_p+4\right){exp}_G+{exp}_{G_1}+2n_{p}e$

demonstrates the computational overhead of [3,14,24] and this paper, where $n_u$ and $n_p$ represent the number of attributes and the number of policies, respectively; ${exp}_G$ and ${exp}_{G_1}$ represent the exponential operation in $G$ and $G_1$, respectively; and $e$ is the bilinear operation. Table 3 shows that this paper’s scheme has the lowest total computational overhead in key generation, encryption, and decryption.

5.3. Efficiency Analysis

This experiment is based on Ubuntu 22.04.2 LTS and the Charm-crypto library, running on a computer (Intel(R) Core(TM) i5-7300HQ CPU @ 2.50 GHz,8.00 GB RAM). In this paper, we use a 160-bit group of elliptic curves in hyper-singular curve $y=x^3+x$ over a 512-bit finite field. The experimental data are taken as the average value of the data obtained from 20 runs. This section compares this scheme with the existing schemes mainly in key generation time, encryption time, and decryption time.

Figure 3 shows the variation in key generation time with the number of attributes in [3,14,24] and the proposed scheme in this paper. Since reference [24] needs to create the vector $\mathit{y}$ for decryption, it has the highest computational overhead and the longest key generation time. The key generation time of this paper’s scheme is very low and basically does not vary with the number of attributes, which is close to that of reference [3]. However, the key generation process in reference [3] is managed by only one authorization center, which is inefficient and less secure.

Figure 4 illustrates the variation in encryption time with the number of attributes in [3,14,24] and the proposed scheme in this paper. All the results are linearly related to the number of attributes. Reference [14] is based on the AND gate access structure; its scheme sacrifices more fine-grained access policies for a lower cost encryption time. Reference [3] does not support the policy update function that facilitates the data owner to perform access control. However, in the actual access process, to dynamically adapt to changes in the environment and keep the shared data in a controllable range, the data owner must be able to formulate and update the access policy according to the demand dynamically and flexibly. This paper uses the linear secret sharing scheme, which is practical in that it can be implemented in any monotonic access structure despite the slightly higher encryption cost and can be used for policy updates without compromising user privacy.

Compared with the existing schemes, this paper, in order to ensure that legitimate users will not obtain the wrong key components provided by the semi-trusted attribute authorization centers, chooses to verify the correctness of the $t^{\prime }$ computed by the m attribute authorization centers by the value $t$ provided by the $DU$ in the decryption phase, increasing the ${exp}_G$ operation and making the decryption stage slightly more computationally intensive than in reference [14] and reference [24], as shown in Figure 5. However, in reference [14], only linear operations are required for decryption because this scheme supports only AND gate structures. Reference [24], on the other hand, outsources most of the decryption computation to the blockchain, which significantly increases the cost of using the blockchain.

In order to comprehensively and holistically compare the performance of the four schemes, this paper finds the sum of the key generation time, the encryption, and the decryption time of each scheme, as shown in Figure 6. Figure 6 shows that this paper’s scheme spends the lowest sum of time in the key generation, encryption, and decryption stages, consistent with each scheme’s theoretical and computational overhead results demonstrated in Table 3.

5.4. Blockchain Network Simulation

In the blockchain simulation experiment, this paper builds the Fabric consortium blockchain based on Ubuntu 22.04.2 LTS, which uses the PBFT consensus algorithm. The chaincode used in the scheme is developed with the Golang language. In this paper, the Caliper tool measures the transaction throughput and latency of the generation and verification transactions under different numbers of transactions. The test object of this experiment is a randomly selected node from the blockchain network, and the test content is the generation transaction and the verification transaction with a concurrency of 100–1000.

Throughput is the speed at which the blockchain ledger receives transactions, measured by the number of transactions executed per second. Figure 7 shows the throughput of two types of transactions for different transaction numbers in the blockchain. From Figure 7, as the number of transactions increases, the throughput of a single node remains near 120, indicating that the scheme proposed in this paper has good scalability.

Figure 8 shows the variation in transaction latency with the number of transactions in the proposed scheme. The results show that the latency of both types of transactions increases linearly with the number of transactions because increasing the number of transactions causes the waiting queue to become longer. Nonetheless, the generation transaction and verification transaction time remain within 10 s with a concurrency of 100–1000. Each node has a faster transaction speed, which provides a high-performance service.

6. Conclusions

This paper proposes a multi-authorization access control scheme based on blockchain and CP-ABE, adopting a matrix access structure and supporting policy update functions to realize flexible and fine-grained access control. In this paper, blockchain is combined with attribute-based encryption, where the data owner embeds the access policy into the ciphertext data through attribute-based encryption and later uploads it to the blockchain. The blockchain records the transmission process of the data visitor’s private key to pre-verify the data visitor’s access rights. The combination of the two not only ensures the confidentiality and security of the data on the blockchain, but also realizes the auditable and highly transparent access process, which solves the problems of traditional access control, such as single-point failure, difficulty in meeting the principle of minimum authorization, difficulty in dynamically adapting to changes in the environment, and difficulty in verifying the access rights of the policy.