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

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).


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 1.
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.

2.
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. 3.
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.

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 finetune 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.

Main Parameters and Definitions
The main parameters involved in the scheme of this paper are shown in Table 1.

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∈ (1,n) and broadcasting it to the blockchain. 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 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.

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 C runs the system initialization algorithm, inputs the security parameter λ, outputs the system public key PK and sends it to adversary A, and saves the system master key MSK. Adversary A selects the old access policy (A, ρ) and the new access policy (A , ρ ) that it wishes to attack. • Querying private key phase 1. Adversary A adaptively submits a series of attribute sets U = (u 1 , u 2 , u 3 , . . . . . . u l ) that do not satisfy the old and new access policies to challenger C. C runs the key generation algorithm to generate the corresponding key SK to sends it to adversary A. • Challenge phase. Adversary A submits two equal-length messages m 0 and m 1 to challenger C. C randomly selects b (0, 1) and runs a cryptographic algorithm to encrypt m b under the old access policy P; challenger 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; C sends the updated ciphertext to adversary A. • Querying private key phase 2. Similar to Phase 1, adversary A continues to submit attribute u l to challenger C for querying other attribute keys, with the stipulation that u l still does not satisfy the access policy P.
• Guessing phase. Adversary A gives a guess b for b. The adversary wins the game if b = b, since any inactive adversary A can win this game with a probability 1 2 by making a random guess on b. A's advantage in this game is defined as The goal of the adversary is to guess the value of b with a probability greater than 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.

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

Initialization Stage
AAs executes the algorithm. The algorithm inputs the security parameter λ and outputs the system public key PK = (G, G 1 , g, H, e(g, g), αr, g α , αβ) and the system master key MSK = (r, α, β) with randomly chosen r, α, β ∈ Z p . The bilinear mapping e : G × G → 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.

tPart i Generation Stage
The algorithm is executed by DU. The DU inputs random numbers (m, n) and t ∈ Z p , and uses the threshold secret sharing algorithm to divide t into n slices of t, tPart i∈ (1,n) .
DU broadcasts the slices of t to the blockchain via the tPart i storage transaction, and nodes in the blockchain verify the transaction.

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 f or 1 ≤ i ≤ n do /*AAs encrypt _tPart i with their public keys PK AAs in the blockchain*/ E(tPart i ) = Enc PK AAs (tPart i ) /*DU compute the hash value of the transaction id, E(tPart i ) and the address of the nodes adress ComNodes .*/ s tPart i = hash{id, E(tPart i ), adress ComNodes } /*DU sign s tPart i with their private keys SK DU in the blockchain*/ sign = sign SK DU (s tPart i ) Tx tPart i _storage = {id, E(tPart i ), adress ComNodes , sign} 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(tPart i ), and adress ComNodes from it; and compares it with the DU signed digest s tPart i by computing the hash value s tPart i 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(tPart i ) from the Tx tPart i _storage transaction to keep it on behalf of the AAs. In Algorithm 3, AAs obtains E(tPart i ) through the Tx tPart i _sharing = {id, E(tPart i ), adress AAs , sign} transaction and decrypts E(tPart i ) 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(tPart i ), the address of the AAs adress AAs , private key SK ComNodes of the nodes in the blockchain Output: Tx tPart i _sharing transaction f or 1 ≤ i ≤ n do /*Nodes in the blockchain compute hash value*/ sh tPart i = hash{id, E(tPart i ), adress AAs } /*Nodes sign sh tPart i with their private keys SK ComNodes in the blockchain*/ sign = sign SK ComNodes (sh tPart i ) Tx tPart i _sharing = {id, E(tPart i ), adress AAs , sign} 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 , . . . . . . 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 ∈ U, the respective attribute authorization center computes the private key component D i, 1 .
The user combines the above four key components to obtain SK = {D i,1 , D 2 , D 3 , D 4 }. 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.

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 × l access matrix A as inputs, where ρ 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 The random vector is chosen, where A x represents the vector corresponding to the xth row of matrix A. L x = {x|ρ(x) ∈ S} is defined, z x ∈ Z p is chosen at random, and the following is computed: 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.

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 ρ (j).

Updated Key Generation Stage
At the updated key generation stage, DO inputs PK, selects the updated key UK x∈(A,B,C) according to the output of the policy comparison algorithm, and constructs new random vectors → v ∈ Z l p and → ω ∈ Z l p , where the first terms are s and 0, respectively. DO com- The generated policy updated key UK m is sent to the blockchain and verified by the Tx U pKeygen_storage transaction, which is similar to the Tx tPart i _storage transaction.
where r j = r x a j ,α j = α x a j and

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 , where r j = a j r x and α j = α x a j .
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.

Decryption Stage
The decryption phase consists of two parts: pre-verification and decryption. Preverification 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 ⊥, as shown in Algorithm 5.

Algorithm 5 Pre-verification algorithm.
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 after collaborative computation by m attribute authorization centers in Keygen phase, the following computation is performed: In the above process, t = t proves that m semi-trusted attribute authorizations correctly compute the value t , and the legitimate DU obtains the correct key component.
), then DU chooses the constant c x ∈ Z p that satisfies ∑ c x A x = (1, 0, . . . , 0) and computes This process generates plaintext M . The user DU encrypts the plaintext M obtained from the decryption algorithm with the help of the SHA256 algorithm and compares its hash value hashm with the hashm obtained through the blockchain Tx hashm_sharing transaction. If hashm = hashm, then the decryption is correct and the data are complete.

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 , . . . , b q Z q be chosen at random and g be a generator of G. If an adversary is given, y = g, g s , g a , . . . , g (a q ) , g (a q+2 ) , . . . , g (a 2q ) It must remain difficult to distinguish e(g, g) a q+1 s G T from a random element in G T . An algorithm B that outputs z (0, 1) has an advantage ε in solving the decisional q-parallel BDHE in G if 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 A can attack this scheme with a non-negligible advantage ε; in probabilistic polynomial time. Then, a challenger C can solve the q-Parallel BDHE hypothesis with an advantage of ε/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 × G → G T . Set a q-Parallel BDHE challenge with randomly chosen b {0, 1}, R G T , and take Z = e(g, g) a q+1 s if b = 0; otherwise, take T = R. • Initialization phase.
The challenger C obtains the access structure (A * , ρ * ) that the adversary A wishes to challenge, and A * is a k * × l * matrix. C chooses the random number α ∈ Z p such that e g α , g a q e(g, g) α = e(g, g) α , with the implication that α = α + a q+1 .
For each x in A x , C chooses m x at random. Let X be the set of x satisfying ρ * (x) = x. It can be sought that The above expression g m x is randomly distributed, so H(A x ) is also randomly distributed. If X = ∅, H(A x ) = g m x .
Adversary A adaptively submits a set of attributes U not satisfying (A * , ρ * ) to ask for the private key. Challenger C chooses the random number r ∈ Z p and finds the vector → ω = (ω 1 , ω 2 , . . . ω l ) ∈ Z l * p with the first term ω 1 = 1, Challenger C cannot model the unknown term g a q+1 b i , so it must be ensured that the K x expression does not contain a term of the form g a q+1 b i . Challenger C computes If x ∈ U and there is no x such that ρ * (i) = x, one can make K x = K m x .
If x ∈ U, there is more than one x such that ρ * (i) = x, and all equations of the form g a q+1 b i can be cancelled out by → ω·A * x = 0. Let X be the set of x satisfying ρ * (x) = x. C constructs K x according to the following equation: The adversary A submits two equal-length challenge messages m 0 and m 1 to the challenger C. C chooses at random b ∈ (1, 0) and the random numbers y 2 , . . . , y l * and uses → v for secret sharing on s.
Similar to Phase 1.
The adversary A outputs a guess b for b. If b = b, challenger C outputs µ = 0, denoting Z = e(g, g) a q+1 s ; otherwise, challenger C outputs µ = 1, denoting Z = R. A's advantage in that game is defined as ε.

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. 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.  Table 3 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.

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 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.  [3,14,24] and this paper. 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 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.  [3,14,24] and this paper.
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. Figure 6. Time of key generation + encryption + decryption for references [3,14,24] and this papers.

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.

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 preverify 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.