© Wuhan University 2024

0 Introduction

With the continuous development of internet technology and technological innovation, cloud computing has revolutionized data sharing by providing extensive storage and management services to individuals and various industries. Despite its convenience, data sharing through cloud computing poses numerous security issues^{[1, 2]}. One of the main issues is the lack of trust that users have in cloud service providers. These providers are vulnerable to external attacks from adversaries and internal threats posed by malicious employees, posing significant data security risks to data sharing. To address these challenges, cryptographic access control schemes such as Attribute-Based Encryption (ABE) and blockchain technology have emerged. Initially proposed by Bethencourt et al^[3], the ciphertext-policy attribute-based encryption (CP-ABE) scheme maps user attributes and access policies into an access structure, allowing specific users who meet the access structure criteria to decrypt data. This feature aligns well with the requirements of data access control in cloud environments. Subsequently, researchers have proposed various data sharing solutions by applying this algorithm in different domains. However, many existing schemes^[4-6] suffer from the issue of excessive authority and a single point of bottleneck, where all parties are compelled to trust a single attribute authority. This vulnerability can lead to single points of failure and performance bottlenecks. In practical applications, attributes are typically managed in a distributed manner by different institutions. To solve this issue, Chase et al^[7,8] introduced the first multi-authority ABE scheme. This scheme manages multiple unrelated attribute domains through different authorities, facilitating the distribution of user attributes across multiple management institutions. Subsequently, several extension schemes^[9-12] were proposed. However, they still face the challenge of a single point of bottleneck. If one institution goes down or fails, all attributes managed by that institution become invalid. Li et al^[13] proposed a TMACS (threshold multi-authority access control) scheme that leverages threshold secret sharing algorithms to achieve joint attribute management, thus addressing the single point of bottleneck issue and enhancing system robustness. However, this scheme requires users to communicate with multiple institutions, which increases the communication costs.

Qin et al^[14] suggested using blockchain and smart contracts to connect users and attribute authorities (AAs), reducing user-side computational costs. However, key verification is lacking during attribute key generation, compromising key security and reliability.

To address the challenges associated with cross-domain collaboration among multiple authorities and mitigate single points of failure, this paper introduces BDAE—a blockchain-based and decentralized attribute-based encryption access control scheme. By utilizing smart contracts, BDAE establishes mutual trust among various authority institutions. Collaborative computation of attribute sub-tokens facilitates the generation of decryption tokens for users, enabling decentralized data access control. Additionally, blockchain technology ensures trustworthy and tamper-resistant access logs, allowing data owners to monitor user access behavior seamlessly. In summary, our contributions can be summarized as follows:

1) Proposal of BDAE, a decentralized access control scheme based on Hyperledger Fabric^[15] and distributed key generation. This approach ensures trusted key management, addressing the single point of bottleneck and key verification issues.

2) Utilization of smart contracts and blockchain's identity management features to enable the distributed issuance of attribute certificates for users, providing fine-grained data access control and sharing solutions.

3) Exploitation of the decentralized and auditable nature of blockchain technology, ensuring tamper-resistant data sharing processes and enhancing overall security and reliability.

4) Comprehensive analysis of the system's functionalities and performance, demonstrating that the scheme reduces decryption overhead on the user side without compromising privacy, thereby meeting the requirements of practical applications.

1 Overview

1.1 System Model

As illustrated in Fig. 1, the system comprises five distinct entities and a blockchain network, including multiple Certificate Authorities (CAs), multiple AAs, Data Owner (DO), Data User (DU), the Interplanetary File System (IPFS) for data storage, and a peer-to-peer blockchain network.

Fig. 1 Blockchain-based multi-authority access control system model

CAs: The blockchain network adopts a distributed architecture with multiple organizations, each equipped with a CA. The CA is responsible for issuing attribute certificates to members within the organization, such as users and AAs, and generating network identity credentials for them. It is important to note that the CA does not participate in the generation of attribute keys for users and AAs.

AAs: They are responsible for attribute management and attribute key generation. Users can request attribute tokens from AAs based on the attributes carried by their certificates. In contrast to traditional multi-authority CP-ABE systems, we optimized the expression strategy for attributes and each attribute name possesses multiple attribute values, which are jointly managed by multiple authorities. This creates a many-to-many mapping relationship between attribute sets and authorities. The attribute management model is illustrated as Fig. 2.

Fig. 2 Attribute management model

IPFS: IPFS^[16] is a content-addressable and peer-to-peer hypermedia distribution protocol that aims to create a persistent and distributed storage and file sharing network. Nodes in the IPFS network collectively form a distributed file system. IPFS is a replacement for traditional cloud service providers and provides data storage services for data owners in the system, and users can retrieve files from the network using only the Content Identifier (CID).

DO: To enhance data encryption efficiency, all DOs should encrypt the original data using symmetric encryption algorithms such as AES, DES, etc., before uploading files to IPFS. Subsequently, the data access policy is defined, and the symmetric encryption key is encrypted using attribute-based encryption algorithms. Finally, CID and the encrypted key are uploaded to the blockchain.

DU: By applying for identity credentials from the CA, each user obtains a certificate with globally unique ID, referred to as globally unique identity (GID). All users can download ciphertext from IPFS freely, but only those who meet the access policy can obtain decryption tokens through attributes in certificates, thereby completing data decryption.

Blockchain: The blockchain provides a decentralized, tamper-resistant, and cross-domain collaborative data interaction platform. Communication between all entities is carried out through the blockchain network. The blockchain ledger stores the publicly initialized parameters and metadata, ensuring data audibility and reliability.

1.2 Workflow

The workflow of the system comprises five different stages: Certificate Generation, System Initialization, Encrypt, Token Generation, and Decrypt. As illustrated in Fig. 3, each stage is represented by a different color.

Fig. 3 Procedure flow of the system mode

①Certificate Generation: The system employs collaborative network topology across various organizations and domains. Fabric CA issues certificates to members of each organization. Administrators within each organization submit registration requests, and Fabric CA processes these requests to generate certificates with a GID and associated attributes. These certificates serve as the sole access tokens for members to engage with the blockchain network. Fabric CA can also invalidate certificates upon request or in case of user violations.

②System Initialization: As depicted below, system initialization consists of three steps.

1) GlobalSetUp(λ)→GP

$\lambda$ is a safe parameter for determining the size of a finite group. The system administrator runs initialization algorithm to generate the global parameter GP. Subsequently, customized attribute management policies for authorities are formulated and then uploaded to the blockchain. In the real life, an attribute usually has multiple attribute values. For example, a person's work department can be production, sales, or logistics. In order to facilitate the management of attributes, this paper designs a convenient data structure to store policies. These policies follow the format depicted in Fig. 4, for example, the attribute name W_i has k attribute values, which are jointly managed by n_iAAs, and the key reconstruction threshold is t_i.

Fig. 4 An instance of attribute management policy

2) AASetUp (GP, AID)→(AA)

Each AA retrieves the GP from the blockchain and employs it alongside its authority GID to execute the algorithm, thus formally initializing itself as an authority entity.

3) KeyNegotiate (AMP)→({subPK},{subSK})

All AAs, upon acquiring the all AMPs from the blockchain, conduct key negotiation based on the policies. The negotiated keys serve as private keys for attributes under their management domain, and the corresponding sub-public keys are uploaded to the blockchain.

4) KeyGenerate({subPK})→(GPK)

The smart contract is responsible for gathering sub-public keys from various authorities on-chain. Subsequently, the system administrator merges the set of sub-public keys {subSK} off-chain to generate the global public key GPK, which is then uploaded to the blockchain.

③Encryption: After retrieving GP and GPK from the blockchain, the data owner encrypts his data and uploads the ciphertext to IPFS. The metadata MD is also uploaded to the blockchain and stored in JSON format as shown in Fig. 5. The index of the ciphertext in IPFS is represented by CID_IPFS, serving as the sole proof of the ciphertext's retrieval.

Fig. 5 An instance of meta data

1) SymEncryption(M)→CT

Due to the complexity of operations like pairings in ABE, efficiency is lower compared to symmetric encryption. To ensure efficient data encryption, a hybrid encryption approach is adopted, and the ciphertext CT is uploaded to IPFS.

2) Encrypt (K, (A, ρ),GP, GPK)→CT_KEY

Data owner executes this algorithm, inputting the symmetric encryption key K, access structure (A, ρ), global parameter GP, and global public key GPK to generate the key ciphertext CT_KEY.

④Token Generation: To decrypt data, user accesses the blockchain network for a decryption token. The smart contract identifies user attributes from his certificate, triggering relevant events and sending token generation requests to respective authorities according to the attribute management policy. Multiple authorities monitor and respond by sending sub-tokens to the user.

SubTokenGen(g₁^R, subSK, GP, GID)→(subTK)

The algorithm is executed off-chain by multiple AAs. Differing from traditional multi-authority CP-ABE schemes where attribute sub-keys are directly distributed to users by authorities, our proposed method transmits sub-keys to users through the blockchain network. Users are required to provide the blinding factor g₁^R, R∈$\mathbb{Z}$_p to prevent attribute sub-keys leakage. Once obtaining the user's GID, the authority uses its subSK to generate an attribute sub-token subTK which is then transmitted to the blockchain.

⑤Decryption: To generate an attribute token, the data user needs to merge sub-tokens for the same attribute name retrieved them from the blockchain. Then user can decrypt the key ciphertext CT_KEY and ultimately decrypt the ciphertext CT obtained from IPFS using a decryption algorithm.

1) TokenGen({subTK})→(AT)

This algorithm is executed by users to merge sub-token set for the same attribute, generating an attribute token AT corresponding to the set.

2) Decrypt({AT}, CT_KEY, R, GP)→(KEY)

The algorithm takes the token set {AT} corresponding to the data user's attribute set, the key ciphertext CT_KEY, and the global parameter GP as input. It then derives the symmetric key KEY used for decrypting the original data's ciphertext.

2 Data Sharing Scheme

We introduce a blockchain-based scheme designed to facilitate communication among multiple AAs, streamlining cross-domain attribute management through the use of smart contracts. Users exclusively interact with the blockchain, simplifying communication complexities. On the blockchain, three distinct smart contracts operate in separate channels—Attribute Management Contract (AMC), Key Management Contract (KMC), and Metadata Management Contract (DMC)—ensuring data isolation and enhancing security. Off the blockchain, the key negotiation function addresses the single-point bottlenecks found in traditional schemes. Below, we present a detailed data access control scheme.

2.1 System Initialization

GlobalSetUp: The administrator selects cyclic groups G₁, G₂, and G_Tof order p. A bilinear mapping e: G₁ × G₂→ G_T and a Hash function: H {0,1}^⃰→G are defined. The Hash function maps GID to G elements. The resulting global parameters, GP= (p, g₁,g₂, g_T, H), are established. Then the system administrator defines attribute management policies, uploading them to the blockchain using smart contract AMC.

AASetUp: Upon obtaining the global parameters GP from the blockchain, each attribute authority AA initializes an attribute authority instance using its own GID. This step prepares for generating attribute key SK in subsequent stages.

KeyNegotiate: During initialization, AAs get attribute management policies from the blockchain and negotiate keys off-chain based on the policy. We upgraded the traditional secret sharing scheme^[17] with a Pedersen-based verifiable method^[18], significantly boosting security compared to previous approaches^[13,14]. This ensures both decentralization and verification, preventing any single authority from possessing the master keys and avoiding the scenario where other authorities receive fragments of incorrect keys. Importantly, in achieving information-theoretic security, the scheme has an information rate of 1, surpassing Pedersen's 1/2. The process involves four stages:

1) Sub-share generation

For each attribute value, key negotiation is conducted among cooperating AAs. Assuming attribute value V_i1under attribute W_i is managed by {AA₁, AA₂,…, AA_ni}, each AA_k ,k∈{1,2,…,n_i}selects two random numbers α_i , β_i ∈$\mathbb{Z}$_p as their sub-secrets. Then they respectively generate two polynomials $f_k(x),f_k^{\mathrm{\text{'}}}(x)$ of degree t_i-1with coefficients randomly chosen from $\mathbb{Z}$_p, satisfying f_k(0)= α_iand f_k'(0)= β_i. Thus, the master private key for V_i1 can be computed as follow:

${\alpha }_{i\mathrm{1}}={\displaystyle \sum _{i=\mathrm{1}}^{n_i}}{\alpha }_i,{\beta }_{i\mathrm{1}}={\displaystyle \sum _{i=\mathrm{1}}^{n_i}}{\beta }_i$(1)

However, AAs cannot directly access each other's sub-secrets, so AA_k needs to compute sub-shares S_kj=f_k(x_j),S_kj'=f_k' (x_j), j∈{1,…,n_i}\{k} for others. Simultaneously, it computes its own sub-shares S_kk=f_k(x_k), S_kk'=f_k' (x_k), where x∈$\mathbb{Z}$_p represents the identifier of each AA during key negotiation.

2) Sub-share exchange

After generating sub-shares, AAs proceed to exchange them. Prior research^[13,14,17] did not focus on verifying the correctness of share exchange, neglecting potential tampering or malicious alterations during distribution. To tackle this issue, we implement the Verifiable Secret Sharing (VSS) scheme.

● Public commitment

Given g and h as two generators of the group G_q, where $\mathrm{l}\mathrm{o}{\mathrm{g}}_g^h$ is unknown and q represents the order of elliptic curve in user's public keys. Let E(s,t)=g^sh^tbe the commitment. SoAA_k is required to compute the commitment C and reveal it to the other AAs.

$C=\{E(f_{k\mathrm{0}},f_{k\mathrm{0}}^{\mathrm{\text{'}}}),E(f_{k\mathrm{1}},f_{k\mathrm{1}}^{\mathrm{\text{'}}}),\dots ,E(f_{k(t_i-\mathrm{1})},f_{k(t_i-\mathrm{1})}^{\mathrm{\text{'}}})\}$(2)

● Distribute sub-share

The AA_kencapsulates sub-shares within a structure named “deal”, expressed as deal = {C, f_k(x_j), f_k'(x_j), g, h}, and encrypts it using the AES-GCM symmetric encryption algorithm. During encryption, the authority generates a signature for identity verification using its private key from blockchain. The sealing process is detailed in Algorithm 1. AES-GCM mode, chosen for its support of parallel encryption and decryption alongside identity verification, is preferred over other AES encryption modes.

● Verify sub-share

The consortium of AA_j (j∈{1, …, n_i}\{k}) who manage the attribute value V_i1 need to perform the following steps after receiving the sealfrom AA_k. First,AA_j validates the signature of the temporary public key dhPub using the AA_k's public key. Upon successful verification, AA_j reconstructs the temporary encryption key dhKey using its own private key and decrypts the ciphertext to obtain the deal. The process is demonstrated in Algorithm 2.

If the decryption of the ciphertext is successful, AA_jemploys the commitment C to validate the correctness of the sub-share. The validation equation is expressed as follows:

$\begin{array}{l}E(f_k(x_j),f_k^{\mathrm{\text{'}}}(x_j))=g^{f_k(x_j)}{h}^{f_k^{\mathrm{\text{'}}}(x_j)}\\ =E(f_{k\mathrm{0}},f_{k\mathrm{0}}^{\mathrm{\text{'}}})\cdot E(f_{k\mathrm{1}},f_{k\mathrm{1}}^{\mathrm{\text{'}}}{)}^{x_j}\cdots E(f_{k\left(t-\mathrm{1}\right)},f_{k(t-\mathrm{1})}^{\mathrm{\text{'}}}{)}^{{x_j}^{t_i-\mathrm{1}}}\\ ={\displaystyle \prod _{n=\mathrm{0}}^{t_i-\mathrm{1}}}{E}_n^{x_j^n}\end{array}$(3)

According to Ref. [18], we can calculate the information rate:

$\frac{\mathrm{s}\mathrm{i}\mathrm{z}\mathrm{e}\mathrm{o}\mathrm{f}\mathrm{s}\mathrm{e}\mathrm{c}\mathrm{r}\mathrm{e}\mathrm{t}}{\mathrm{s}\mathrm{i}\mathrm{z}\mathrm{e}\mathrm{o}\mathrm{f}\mathrm{s}\mathrm{h}\mathrm{a}\mathrm{r}\mathrm{e}}=\frac{\mathrm{2}}{\mathrm{2}}=\mathrm{1}$(4)

3) Master share generation

After receiving n_i-1 sub-shares (S_jk, S_jk') from other n_i-1 AAs, AA_k computes its master share as the attribute private key share for V_i1, which can be computed as follows:

$\{\begin{array}{l}\mathrm{S}{\mathrm{K}}_{i\mathrm{1},k}={\displaystyle \sum _{j=\mathrm{1}}^{n_i}}{S}_{jk}\\ \mathrm{T}{\mathrm{K}}_{i\mathrm{1},k}={\displaystyle \sum _{j=\mathrm{1}}^{n_i}}{S}_{jk}^{\mathrm{\text{'}}}\end{array}$(5)

The attribute public key share is computed as:

$\{\begin{array}{l}\mathrm{S}{\mathrm{P}}_{i\mathrm{1},k}=e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{\mathrm{S}{\mathrm{K}}_{i\mathrm{1},k}}\\ \mathrm{T}{\mathrm{P}}_{i\mathrm{1},k}=g_{\mathrm{2}}^{\mathrm{T}{\mathrm{K}}_{i\mathrm{1},k}}\end{array}$(6)

Next, AA_k securely saves the private key share while publicly uploading the public key share to the blockchain.

4) Global pub-key generation

Once the blockchain receives all attribute public key shares, the system administrator utilizes the smart contract KMC to gather t_i shares, generating global pub-key generation GPK. And then it will be uploaded to the blockchain for use by the data owner. The public key generation algorithm is a variant of Lagrange interpolation. For example, the public key $\mathrm{S}{\mathrm{P}}_{V_{i\mathrm{1}}}$ for attribute value V_i1 is computed as follows:

$\begin{array}{l}\mathrm{S}{\mathrm{P}}_{i\mathrm{1}}={\displaystyle \prod _{k=\mathrm{1}}^{t_i}}\mathrm{S}{\mathrm{P}}_{i\mathrm{1},k}^{{\displaystyle \prod _{j\ne k}^{t_i}}\frac{x_j}{x_j-x_k}}\\ ={\displaystyle \prod _{k=\mathrm{1}}^{t_i}}e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{(\mathrm{S}{\mathrm{K}}_{i\mathrm{1},k}{\displaystyle \prod _{j=\mathrm{1},j\ne k}^{t_i}}\frac{x_j}{x_j-x_k})}\\ =e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{{\displaystyle \sum _{k=\mathrm{1}}^{t_i}}(\mathrm{S}{\mathrm{K}}_{i\mathrm{1},k}{\displaystyle \prod _{j=\mathrm{1},j\ne k}^{t_i}}\frac{x_j}{x_j-x_k})}\\ =e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{{\alpha }_{i\mathrm{1}}}\end{array}$(7)

and

$\begin{array}{l}\mathrm{T}{\mathrm{P}}_{i\mathrm{1}}={\displaystyle \prod _{k=\mathrm{1}}^{t_i}}\mathrm{T}{\mathrm{P}}_{i\mathrm{1},k}^{{\displaystyle \prod _{j\ne k}^{t_i}}\frac{x_j}{x_j-x_k}}\\ ={\displaystyle \prod _{k=\mathrm{1}}^{t_i}}e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{(\mathrm{T}{\mathrm{K}}_{i\mathrm{1},i}{\displaystyle \prod _{j=\mathrm{1},j\ne k}^{t_i}}\frac{x_j}{x_j-x_k})}\\ =e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{{\displaystyle \sum _{k=\mathrm{1}}^{t_i}}(\mathrm{T}{\mathrm{K}}_{i\mathrm{1},k}{\displaystyle \prod _{j=\mathrm{1},j\ne k}^{t_i}}\frac{x_j}{x_j-x_k})}\\ =e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{{\beta }_{i\mathrm{1}}}\end{array}$(8)

And the calculation for TP_i1 is the same as that for SP_i1. Thus, the GPK is a collection of all attribute public keys in the system, denoted as GPK= {SP, TP}.

2.2 Encrypt

After obtaining the GP and GPK, the data owner defines an access policy and employs the attribute-based encryption algorithm to encrypt the symmetric encryption key K. An access structure can be represented as an LSSS access structure (A, ρ), where A represents an m×l matrix. The ρ maps the x-th row of M to an attribute ρ(x)∈A_tt1,…, A_ttU. For each row of A, the data owner selects a random vector v=(s, y₂, y₃,…, y_l) ∈$\mathbb{Z}$_p, where s is a secret value and y₂,y₃,…,y_l are used to share the secret s. Let λ_x =A_x v, where A_x represents the row x of A. The data owner selects a random vectorw= (0, w₁, w₂, …, w_l) ∈$\mathbb{Z}$_p, and computes w_x =A_x w. Random values r₁,r₂, …,r_m ∈$\mathbb{Z}$_p are chosen. The ciphertext is then calculated as follows:

$\begin{array}{l}{C}_{\mathrm{0}}=Ke(g_{\mathrm{1}},g_{\mathrm{2}}{)}^S,C_{\mathrm{1},x}=e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{{\lambda }_x}e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{{\alpha }_{\rho (x)}{r}_x},\\ C_{\mathrm{2},x}=g_{\mathrm{2}}^{r_x},C_{\mathrm{3},x}=g_{\mathrm{2}}^{{\beta }_{\rho (x)}{r}_x}{g}_{\mathrm{2}}^{w_x}\forall x\end{array}$(9)

2.3 Token Generation

Before decrypting data, users must acquire decryption sub-tokens. Our scheme optimizes communication efficiency by allowing users to interact exclusively with the blockchain network. The smart contract KMCautomates the extraction of attribute values from the user's certificate and facilitates communication with multiple AAs to obtain sub-tokens.

SubTokenGen: Each AA_ksets up an event listener off-chain. When a user triggers the token generation function through smart contract KMC, an immediate event is activated. For example, if the attribute value V_i1 embedded in the user's certificate corresponds to AA_k's attribute management domain, AA_k generates the relevant sub-token. The sub-token can be expressed as:

$\mathrm{S}{\mathrm{T}}_{i\mathrm{1},k}=(g_{\mathrm{1}}^R{)}^{\mathrm{S}{\mathrm{K}}_{i\mathrm{1},k}}H{(\mathrm{G}\mathrm{I}\mathrm{D})}^{\mathrm{T}{\mathrm{K}}_{i\mathrm{1},k}}$(10)

where SK_i1,k,TK_i1,k are the attribute sub-private keys possessed by AA_k. Subsequently, AA_k sends the sub-token to the blockchain using the smart contract.

TokenGen: Since each attribute value corresponds to multiple sub-tokens, data user needs to aggregate sub-tokens belonging to the same attribute value. The aggregation algorithm is a variant of Lagrange interpolation, as shown for attribute value V_i1:

$\mathrm{A}{\mathrm{T}}_{i\mathrm{1},\mathrm{G}\mathrm{I}\mathrm{D}}={\displaystyle \prod _{k=\mathrm{1}}^{t_i}}\mathrm{S}{\mathrm{T}}_{i\mathrm{1},k}^{{\displaystyle \prod _{j=\mathrm{1},j\ne k}^{t_i}}\frac{x_j}{x_j-x_k}}=(g_{\mathrm{1}}^R{)}^{{\alpha }_{i\mathrm{1}}}H{(\mathrm{G}\mathrm{I}\mathrm{D})}^{{\beta }_{i\mathrm{1}}}$(11)

The user's tokens for all attribute values can be expressed as a token collection {AT_GID}.

2.4 Decrypt

The decryption algorithm can be executed by data users who meet the access policy. The user U who has obtained metadata MD and global parameters GP from the blockchain must use the token set AT_GID and blinding factor R as input. Let A_U be a sub-matrix of A, where A_Uis an n×l matrix. Each row of this matrix corresponds to an attribute in U's attribute set S_U. If S_U satisfies the access structure (A, ρ), then there always exists a suitable vector $\mathit{h}$=($h_{\mathrm{1}}$,$h_{\mathrm{2}}$,…, $h_l$)$\in$${\mathbb{Z}}_p^l$ such that $\stackrel{⃑}{\mathit{e}}$=$A_U$·$h$, where $\stackrel{⃑}{\mathit{e}}$ =($\mathrm{1}$,$\mathrm{0}$,…, $\mathrm{0}$) $\in$${\mathbb{Z}}_p^l$.

To alleviate the computational burden on users, it is essential for the blockchain to shoulder a portion of the associated computational costs. Utilizing the token set $\mathrm{A}{\mathrm{T}}_{\rho (x),\mathrm{G}\mathrm{I}\mathrm{D}}$ of user U, for each such x, user invoke smart contract to compute:

$P=\prod _x{C}_{\mathrm{1},x}^{h_x},Q={\prod _x\left(\frac{e(H(\mathrm{G}\mathrm{I}\mathrm{D}),C_{\mathrm{3},x})}{e(\mathrm{A}{\mathrm{T}}_{\rho (x),\mathrm{G}\mathrm{I}\mathrm{D}},C_{\mathrm{2},x})}\right)}^{h_x}$(12)

The blockchain returns the calculation result (P, Q) to user. According to it, users only need to perform calculations based on the following formula:

$\begin{array}{l}\prod _x{\left(\frac{C_{\mathrm{1},x}^R\cdot e(H(\mathrm{G}\mathrm{I}\mathrm{D}),C_{\mathrm{3},x})}{e(\mathrm{A}{\mathrm{T}}_{\rho (x),\mathrm{G}\mathrm{I}\mathrm{D}},C_{\mathrm{2},x})}\right)}^{h_x}\\ =\prod _x(e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{{\lambda }_{x}R}e{\left(H(\mathrm{G}\mathrm{I}\mathrm{D}),g_{\mathrm{2}}{)}^{w_x}\right)}^{h_x}=P^{R}Q\end{array}$(13)

Then, using the vector h, we can compute equation:

$\begin{array}{l}\mathit{s}={(\mathrm{1,0},\cdots ,\mathrm{0})}^{\mathrm{T}}(s,y_{\mathrm{2}},\cdots ,y_l)\\ ={\vec{\mathit{e}}}^{\mathrm{T}}\cdot \vec{\mathit{v}}={\mathit{h}}^{\mathrm{T}}\cdot {\mathit{A}}_U^{\mathrm{T}}\cdot \vec{\mathit{v}}\\ ={\mathit{h}}^{\mathrm{T}}\cdot {\vec{\mathit{\lambda }}}_U\\ =\sum _{x\in U}{h}_x\cdot {\lambda }_x\end{array}$(14)

and

$\begin{array}{l}\sum _{x\in U}{w}_x\cdot h_x={\mathit{w}}^{\mathrm{T}}\cdot {\mathit{A}}_U\cdot \mathit{h}\\ =(\mathrm{0},w_{\mathrm{1}},\cdots ,w_l{)}^{\mathrm{T}}\cdot (\mathrm{1,0},\cdots ,\mathrm{0})\\ =\mathrm{0}\end{array}$(15)

Therefore, we can compute the equation:

$P^{R}Q=e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{RS}$(16)

Finally, we obtain the decrypted message:

$K=\frac{C_{\mathrm{0}}}{(e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^{RS}{)}^{\mathrm{1}/R}}=\frac{C_{\mathrm{0}}}{e(g_{\mathrm{1}},g_{\mathrm{2}}{)}^S}$(17)

3 Scheme Analysis

3.1 Security and Robustness

Each attribute token in the system is jointly managed by n AAs. Due to the t threshold parameter, adversaries require compromising t or more AAs to acquire decryption keys for a specific attribute. Similarly, the system's normal operation necessitates t or more AAs to be online. This section analyzes the system's security and robustness.

Security: The system's security depends on the management of attribute values by AAs. The security assessment focuses on the probability, denoted as λ, representing an adversary's likelihood of illicitly obtaining an attribute key by compromising a specific AA. This metric forms the basis of the system's security analysis

${\displaystyle \sum _{i=\mathrm{0}}^{t-\mathrm{1}}}\left(\begin{array}{l}i\\ n\end{array}\right){\lambda }^i{\left(\mathrm{1}-\lambda \right)}^{n-i}$(18)

Robustness: System resilience is measured by the probability of continuous operation despite AA failures, Instances like crashes or offline status in AAs could obstruct users' access to managed sub-keys. Let μ denote the likelihood of individual AA operational failures. The calculation for system robustness is as follows:

${\displaystyle \sum _{i=t}^n}\left(\begin{array}{l}i\\ n\end{array}\right){\mu }^i{\left(\mathrm{1}-\mu \right)}^{n-i}$(19)

To understand security and robustness better, we varied parameter values in comparative experiments (Fig. 6). For a fixed corruption probability λ, increasing t enhances system security, yet larger t values do not always ensure better security. On the other hand, higher n, the number of AAs, improves system robustness even with higher corruption probabilities. However, as n increases, system security decreases. Thus, balancing n and t is crucial for optimal performance in practical applications.

Fig. 6 Probability of security and robustness

3.2 Comparison of Functionality

In Table 1, we compare the scheme with previous multi-authority ABE schemes. The evaluation metrics include bilinear groups, auditability, access structure, robustness, identity management, and key verification. Table 1 shows that the proposed scheme offers more comprehensive functionality compared with previous schemes.

3.3 Performance Analysis

We performed simulations to assess the computational costs of our scheme in comparison to previous ones. To ensure fair experimental comparisons, all schemes were implemented using 256-bit BN elliptic curves with prime order. The experimental setup utilized a physical machine with an AMD Ryzen7 4800U CPU. All tests were conducted on a virtual machine running CentOS 7.9, with an allocation of 8GB of memory. Additionally, all algorithms were implemented using the Golang programming language.

Given diverse access policies, we tested computational overhead under two extreme scenarios. To minimize performance impact, we varied attributes per test round, repeating 100 times at different intervals for averages. As shown in Fig. 7, the results show that there is a linear rise in encryption time with increasing attributes for all schemes. Although our scheme exhibits a slight performance advantage over LW^[9], it notably surpasses DIPPE^[12].

Fig. 7 Comparison of user side computational overhead under different access policies

In decryption, our proposed scheme notably reduces user-side computational costs. In fact, due to the blinding factor, even if partial decryption calculations are handed over to smart contracts or third-party servers, no information will be leaked, making the decryption process both secure and efficient. By seamlessly performing outsourced calculations without compromising privacy, users only need to execute an exponential operation and a simple multiplication for final decryption. Importantly, this execution time remains constant, independent of attribute count, ensuring efficient decryption on the user side.

4 Conclusion

In this paper, we propose a multi-authority attribute-based encryption scheme based on blockchain and distributed key generation which is called BDAE for data access control. Our work enhances system robustness by managing each attribute with multiple organizations and solving the single bottleneck problem. The use of blockchain technology ensures the security and traceability of the data sharing process. For future work, we will focus more on reducing user overhead in encryption calculation.

References

All Tables

All Figures

	Fig. 1 Blockchain-based multi-authority access control system model
In the text

	Fig. 2 Attribute management model
In the text

	Fig. 3 Procedure flow of the system mode
In the text

	Fig. 4 An instance of attribute management policy
In the text

	Fig. 5 An instance of meta data
In the text

	Fig. 6 Probability of security and robustness
In the text

	Fig. 7 Comparison of user side computational overhead under different access policies
In the text