Blockchain-enabled data governance for privacy-preserved sharing of confidential data

Decentralization

In traditional cloud services, the data owner (DO) typically uploads ciphertext to a cloud storage server, which means the user may take the risk of assuming that the cloud storage server will provide reliable service to ensure the availability of the uploaded data (Wang, Zhang & Zhang, 2018). However, this reliance inherently introduces a single point of failure. Another drawback of centralized cloud services arises when integrating CP-ABE for improved flexibility and scalability: it relies on intermediary entities like a trusted third party (TTP) and a central authority (CA) to perform operations such as attribute key distribution, policy verification, and data retrieval honestly. These operations are critical for ensuring the security and trustworthiness of data access control, but the reliance on centralized entities poses significant risks.

To better safeguard data availability and ensure the reliability and traceability of operations, it is crucial to design decentralized alternatives for trust mechanisms and enforce traceability throughout the access control system (Wang, Zhang & Zhang, 2018). Consider the application scenario described above: if the potential data users (DUs) are not determined in advance, and the purpose of data sharing also includes attracting public attention, such as coordinating a challenging surgery or managing world-level tasks, a blockchain-based solution is inherently advantageous. Blockchain’s decentralized nature allows for broader participation and enables the system to support complex, multi-faceted applications that require secure and transparent access control mechanisms.

A blockchain-based access control system with CP-ABE has the potential to address these issues effectively. By leveraging blockchain, we can eliminate the need for a centralized TTP to control the data. Each node in the network maintains a distributed ledger that tracks a growing list of transactions, which are verified and confirmed by consensus mechanisms before being recorded. The integrity of transactions can be secured by hashing, Merkle trees, time stamping, and incentive mechanisms. This hybrid approach enhances resilience against single-point failures and the misuse of credentials by ensuring that no single entity has complete control over the access control system. Additionally, the decentralized nature of blockchain inherently supports transparency and traceability, preventing any individual authority or entity from acting maliciously without detection (Gao et al., 2020; Hei et al., 2021; Wu et al., 2019).

Practicality

Several blockchain-based access control systems have been proposed since the emergence of public blockchain systems (Nakamoto, 2008) and the advent of Attributed-based Encryption (Sahai & Waters, 2005). Some efforts leverage the immutable public ledger to build a transaction-based access control system for secure data sharing (Maesa, Mori & Ricci, 2017; Ouaddah, Abou Elkalam & Ait Ouahman, 2016; Wang, Zhang & Zhang, 2018). In contrast, others leverage the self-executing smart contracts to establish a smart contract-based access control system for flexibility and traceability (Qin et al., 2021; Hei et al., 2021; Wu, Xu & Zhu, 2023). However, just employing blockchain technology and CP-ABE encryption for an access control system is inadequate for several practical purposes, such as cross-domain data sharing and privacy leakage.

On the one hand, information is not always shared inside a single domain or organization. For example, driver’s licenses and university registration information may be managed by separate entities. If one central authority is responsible for attribute management and key distribution like the proposed system (Kaur, Rani & Kalra, 2024), it also has trust issues, as discussed above. Therefore, multi-authority attribute-based encryption (MA-ABE), originally proposed by Chase (2007), is used to solve the access problem involving attributes belonging to various authorities. This scheme permits any number of independent authorities to distribute secret keys, which the data owner later chooses to encrypt a message. However, this MA-ABE scheme also relies on a CA that issues seeds to each AA, giving the CA the capability to decrypt any ciphertext. To eliminate the need for a ‘super-power’ CA and achieve full decentralization, Lewko & Waters (2011) proposed a fully secure decentralized CP-ABE solution without requiring cooperation among multiple AAs.

Another issue is privacy concerns, which encompass both policy-hiding and receiver privacy. Since in the classic CP-ABE schemes, an access structure specified in terms of user attributes is explicitly transmitted alongside ciphertext, whoever accesses the ciphertext is also aware of the corresponding access policy. Therefore, multi-authority CP-ABE schemes (Chase, 2007; Lewko & Waters, 2011; Rouselakis & Waters, 2015) are still unsuitable for certain use cases since access policies contain sensitive information. This calls for mechanisms to hide access policies for CP-ABE systems. Additionally, DU needs to provide a full set of user attributes to each authority for an attribute key, inevitably compromising the key receiver’s privacy.

In pursuit of addressing these concerns, several CP-ABE schemes that feature policy-hiding have been proposed (Cui et al., 2018; Zhang, Zheng & Deng, 2018; Yang et al., 2018; Gao et al., 2020; Michalevsky & Joye, 2018; Zhang et al., 2021; Kaur, Rani & Kalra, 2024). Despite these efforts, they do not completely fulfill various practical requirements. Some of them (Cui et al., 2018; Zhang, Zheng & Deng, 2018; Gao et al., 2020; Kaur, Rani & Kalra, 2024) only support a single central authority. Schemes such those from Yang et al. (2018) and Zhang et al. (2021) are prone to the leakage of DU’s confidential attribute information during the key generation or encryption process. Michalevsky & Joye (2018) introduced a fully policy-hiding decentralized CP-ABE scheme, which protects attribute information attached to the access policy and even addresses the issue of receiver privacy.

Security

Beyond the basic security goals of access control systems, such as data confidentiality, ABE schemes need to address another security issue: collusion between users. Specifically, even if data users (DUs) collude by sharing their attribute keys, they should not be able to decrypt ciphertexts unless each of their issued attribute keys individually satisfies the access policy (Bethencourt, Sahai & Waters, 2007). Additionally, different types of ABE-based systems address varying security concerns, such as accountability, which is essential in accountable ABE (Zhang et al., 2020b).

In the context of multi-authority or decentralized ABE, the security goal of collusion resistance is further complicated by the possibility of keys being issued by different authorities. More importantly, the corruption of some but not all authorities should not compromise the confidentiality of the system’s data (Lewko & Waters, 2011). However, many existing ABE-based solutions either fail to adequately address security in the presence of adversaries, as seen in the works like (Xue et al., 2017; Wang, Zhang & Zhang, 2018; Wu, Xu & Zhu, 2023), or define security goals for their application scenarios with noticeable omissions, as found in schemes (Gao et al., 2020; Nasiraee & Ashouri-Talouki, 2020; Porwal & Mittal, 2020). In general, the adversarial models in these works are often overly idealized and do not reflect real-world scenarios.

The issue of corrupted attribute authorities is a widely discussed security problem in most existing ABE-based systems that support multi-authority environments (Yang et al., 2018; Qin et al., 2021; Zhang et al., 2021; Zhao et al., 2022). However, these systems are typically proven secure only against static corruption of authorities, where enquiring about corrupt authorities are made at the beginning of the game (Chen et al., 2023). This implies that the set of corrupted authorities must be fixed, and authority keys must be requested upfront, limiting the adversary’s ability to adaptively change its attack strategy. Moreover, these schemes assume that all attribute authorities must join the system simultaneously, an assumption that is impractical in real-world deployments.

We further identify that several ABE schemes realized through inner-product predicate encryption (Michalevsky & Joye, 2018; Tseng & Gao, 2022) are vulnerable to rogue-key attacks under the fully adaptive security model, where an adversary can corrupt authorities at any point in time. In such an attack, a malicious attribute authority (AA) can generate and register an aggregate public key based on public information from other honest authorities. This rogue key can then be used to decrypt ciphertexts without possessing the necessary attribute keys to satisfy the access policy. Furthermore, works such as Zhang et al. (2020a) and Agrawal, Goyal & Tomida (2021), which build upon the scheme in Michalevsky & Joye (2018), may also inherit this vulnerability.

Another potential issue in the setup phase of the MA-ABE scheme, which has not drawn as much attention as corrupt authorities, is the reliance on a central or trusted authority for the generation of the global public key. For instance, in works such as Hei et al. (2021), only the central authority is involved in this global setup process. This assumption introduces the risk of a single point of failure and overlooks the potential for adversaries to introduce a “backdoor” during setup, which could be exploited later to carry out more harmful attacks on ciphertexts. We also identify a potential leakage of sensitive information in the scheme proposed by Michalevsky & Joye (2018) if a trusted setup is not employed for the generation of the global public key.

As a result, the challenge of securely storing user data, enabling efficient data sharing, and managing multi-authority scenarios while concurrently maintaining a balance of decentralization, traceability, privacy, security, and efficiency constitutes a complex problem that requires innovative solutions.

Architecture

The system architecture is shown in Fig. 1.

Initiate

At the start, a fixed-numbered community of size n will be determined, which will include all of the normal attribute authorities AA and one special trusted authority AA_trust. AA_trust represents this community to set the global security parameter to be λ and the generators of the 𝔾₁, 𝔾₂ with prime order p to be g₁, g₂ respectively. Therefore, the bilinear map can be e ˆ : G 1 ∖ 0 × G 2 ∖ 0 → G T.

AA_trust also deploys two distinct system contracts: contract SC_sys for trusted setup and contract SC_util for resolving the problem of allowing complex cryptographic computations to be used in the system. AA_trust also specifies the deadlines (ddl₁, ddl₂, ddl₃) for the Trusted Setup process and sets an authorized list AAlist to restrict SC_sys access. For a simple system description, we assume that each attribute authority AA submits the required transactions within the deadlines.

To realize the generation of PP_ABE, this process highly depends on the interaction between each attribute authority AA and contract SC_sys, which has five main functions, Commit, Reveal, Prove, Compute and Generate with the help from contract SC_utils. Generally, these functions can only be invoked by a blockchain address owned by AA, which is included in the authorized list AAlist, and executed before the pre-defined deadline ddl_1,2,3.

Commit and reveal

Every AA randomly picks a set of elements e: a matrix A ← $ Diagonal matrices in Z p k × k ∪ 1, a matrix U ← $ Z p k + 1 × k + 1¹, their corresponding scalar values, α_A and α_U, and scaled matrixes α_A⋅A, α_U⋅U. Then, AA has (3)e = A , U , α A , α U , α A ⋅ A , α U ⋅ U and then generates a set of s-pair.

For such element s ∈ e, we refer to the s-pair in 𝔾₁ by rp_s and in 𝔾₂ by rp s 2 as Definition 2. These s-pair in both 𝔾₁ and 𝔾₂ are listed as follows:

• For matrix A: rp A , rp A 2 = g , g A

• For matrix U: rp U , rp U 2 = g A ⊺ , g A ⊺ U

• For scalar α_A: rp α A , rp α A 2 = g , g α A

• For scalar α_U: rp α U , rp α U 2 = g , g α U

• For scaled matrix α_AA: rp α A A , rp α A A 2 = g , g α A ⋅ A

• For scaled matrix α_UU: rp α U U , rp α U U 2 = g A ⊺ , g α U ⋅ A ⊺ U

Other than these s-pair listed above, AA also commits each element s ∈ e. For each s ∈ e: h s ≔ COMMIT rp s | | rp s 2

Subsequently, the overall commitment is: (4)h ≔ COMMIT h A | | h U | | h α A | | h α U | | h α A A | | h α U U

After that, AA publishes the commitment h to the contract SC_sys through blockchain transaction by calling function Commit, which works similarly as a hash function.

The state variable h_collector of SC_sys will store the value h with the key as msg.sender, also known as AA’s blockchain address. Apart from h_collector, we define few state variables used in contract SC_sys as follows:

1. h_collector (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its commitment h

2. unverified_elements (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its unverified list of s-pair s L = rp s , rp s 2 | s ∈ e in both 𝔾₁ and 𝔾₂

3. verified_elements (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its verified list of s-pair s L = rp s , rp s 2 | s ∈ e in both 𝔾₁ and 𝔾₂

After h has been received by contract SC_sys, the sender needs to reveal committed element s ∈ e by passing a list of s-pair in both 𝔾₁ and 𝔾₂ (5)L r p = rp s , rp s 2 | s ∈ e as argument of the function Reveal (Algorithm 4) before deadline ddl₁, which checks the existence of the h published by msg.sender, and verifies that indeed h = COMMIT({h_s}||)² as follows:

 
________________________________________________________________________________________________________________ 
Algorithm 4 Contract SCsys: Part 1_______________________________________________________________________________ 
  1:  function REVEAL(Lrp) 
  2:       for all (a,b) ∈ Lrp do 
 3:            h ← h|| HASH(a) || HASH(b) 
  4:       end for 
 5:       if msg.sender / ∈ unverified_elements then                             ⊳ Resubmitting check 
  6:            unverified_elements[msg.sender] ← Lrp 
  7:       end if 
 8:  end function 
 9: 
10:  function PROVE(Lπ) 
11:       Lrp ← unverified_elements[msg.sender] 
12:       for i ← 0,5 do 
13:            (rp,rp2) ← Lrp[i] 
14:            pi ← Lπ[i] 
15:            if not SAMERATIO(rp,rp2) then 
16:                  throw 
17:            end if 
18:            htmp ← h_collector[msg.sender]||HASH(rps) 
19:            if not CHECKPOK(rps,πs,htmp) then 
20:                  throw 
21:            end if 
22:       end for 
23:       verified_elements[msg.sender] ← Lrp 
24:       unverified_elements[msg.sender] = [] 
25:  end function___________________________________________________________________________________________    

Finally, each pair rp s , rp s 2 , s ∈ e will be stored in another state variable unverified_elements with the key as msg.sender.

Verify

After deadline ddl₁ set by AA_trust in the first stage Initiate, the system enters into the stage Verify. In this stage, we need to check that each attribute authority AA possesses the knowledge of the exponent s used in the list of s-pair L.

Every AA generates the proof π_s≔NIZK(rp_s, h||h_s) using Algorithm 2 for each s ∈ e, and broadcasts these proofs as a list (6)L π = π A , π U , π α A , π α U , π α A ⋅ A , π α U ⋅ U through a blockchain transaction to get them verified. The function Prove ( Algorithm 4 ) from contract SC_sys takes input L_π and processes this verification work.

As shown above, it firstly calls function SameRatio, similar to Algorithm 1 , of contract SC_util to examine the authenticity of the published rp_s and rp s 2.

Afterwards, it computes h_tmp≔h||COMMIT(rp_s), and takes h_tmp with verified rp_s and provided π_s as input to the function CheckPoK of contract SC_util, which works similarly as Algorithm 3 and returns true if the given proof π_s is valid.

Finally, the function Prove ( Algorithm 4 ) will remove the list of s-pair L_rp from the state variable unverified_elements and store it in the state variable verified_elements. This indicates that the AA possesses knowledge of the exponents for the set of s-pair.

Compute and generate

In this stage, the system will generate the public parameters for the attribute-based encryption in two rounds by interacting with two functions Compute and Generate of contract SC_sys (Algorithm 5). Some state variables used are defined as follows:

1. V_curr (State Variable): The most recent published value V

2. V_curr′ (State Variable): The most recent published value V′

3. θ_curr (State Variable): The most recent published scalar θ

4. W_curr (State Variable): The most recent published value W

5. W_curr′ (State Variable): The most recent published value W′

6. θ_curr_ (State Variable): The most recent published scalar θ

We also use below notation powerMulti (A, B) for the following Algorithm 6 :

 
________________________________________________________________________________________________________________ 
Algorithm 5 Contract SCsys: Part 2_______________________________________________________________________________ 
26:  function COMPUTE(V,θ,V ′) 
27:      if unverified_elements[msg.sender] ⁄= [] OR block.timestamp < ddl2 OR block.timestamp > ddl3 then 
28:           throw 
29:      end if 
30:      if not V _curr then                                                                               ⊳ Initialize V,θ,V ′ 
31:           V _curr ← V
32:           θ_curr ← θ 
33:           V _curr′ ← V ′ 
34:           return 
35:      end if 
36:      (rpA,rpαA,rpαAA) ← verified_elements[msg.sender] 
37:      acc1 ←SAMERATIO((V _curr,V ),rpA) 
38:      acc2 ←SAMERATIO((θ_curr,θ),rpαA) 
39:      acc3 ←SAMERATIO((V _curr′,V ′),rpAαA) 
40:      if acc1 == acc2 == acc3 == true  then                                                          ⊳ Check validity 
41:           V _curr ← V
42:           θ_curr ← θ 
43:           V _curr′ ← V ′ 
44:      else 
45:           throw 
46:      end if 
47:  end function 
48: 
49:  function GENERATE(W,θ,W′) 
50:      if unverified_elements[msg.sender] ⁄= [] OR block.timestamp < ddl2 OR block.timestamp > ddl3 then 
51:           throw 
52:      end if 
53:      if not W _curr then                                                                             ⊳ Initialize W,θ,W′ 
54:           W _curr ← W 
55:           θ_curr_ ← θ 
56:           W _curr′ ← W′ 
57:           return 
58:      end if 
59:      (rpU,rpαU ,rpαUU) ← verified_elements[msg.sender] 
60:      acc1 ←SAMERATIO((W _curr,W),rpU) 
61:      acc2 ←SAMERATIO((θ_curr_,θ),rpαU ) 
62:      acc3 ←SAMERATIO((W _curr′,W′),rpαUU) 
63:      if acc1 == acc2 == acc3 == true then                                                          ⊳ Check validity 
64:           W _curr ← W 
65:           θ_curr_ ← θ 
66:           W _curr′ ← W′ 
67:      else 
68:           throw 
69:      end if  
70:  end function______________________________________________________________________________________________________________    

 
____________________________________________________________________________________________________________________________________ 
Algorithm 6 Computing power matrix A by matrix B_______________________________________________ 
Require: group elements A and matrix s have same size l × k 
 1:  function POWERMULTI(A,s) 
  2:       for i ← 1,l do 
 3:            for j ← 1,k do 
 4:                  B[i,j] ← A[i,j]s[i,j] 
  5:            end for 
 6:       end for 
 7:       return B 
 8:  end function___________________________________________________________________________________________ 

Round 1: We define the first attribute authority AA as participant P₁, who broadcasts V 1 , θ V 1 , V 1 ′ as argument of function Compute ( Algorithm 5 ) in contract SC_sys. The elements V 1 , θ V 1 , V 1 ′ are constructed as follows: V 1 ≔ g 1 A 1 , θ V 1 ≔ g 1 α A 1 , V 1 ′ ≔ g 1 α A 1 ⋅ A 1. And the next participant P_i,  i =2 , 3, …, n, generates corresponding elements V i , θ V i , V i ′ using Algorithm 6 , and also broadcasts them to the contract SC_sys:

V i ≔ p o w e r M u l t i V i − 1 , A i θ V i ≔ θ V i − 1 α A i V i ′ ≔ p o w e r M u l t i V i − 1 ′ , α A i A i

Since receiving the elements V 1 , θ 1 , V 1 ′ from first participant P₁, function Compute ( Algorithm 5 ) of SC_sys checks the validity of each incoming elements V i , θ V i , V i ′ published by P_i.

In the end, we define the last valid V_i as one piece of the public parameter: g 1 A = p o w e r M u l t i p o w e r M u l t i … p o w e r M u l t i p o w e r M u l t i g 1 A 1 , A 2 , A 3 … , A n .

Round 2: In this round, we also define the first attribute authority AA as participant P₁, who broadcasts W 1 , θ 1 ′ , W 1 ′ as argument of the function Generate ( Algorithm 5 ) in contract SC_sys. The elements W 1 , θ 1 ′ , W 1 ′ are constructed as follows: W 1 ≔ g 1 A ⊺ U 1 , θ 1 ′ ≔ g 1 α U 1 , W 1 ′ ≔ g 1 A ⊺ α U 1 U 1. And the next participant P_i where i = 2, 3, …, n, generates corresponding elements W i , θ W i , W i ′ using Algorithm 6 , and also broadcasts them to the contract SC_sys:

W i ≔ p o w e r M u l t i W i − 1 , U i θ W i ≔ θ W i − 1 α U , i W i ′ ≔ p o w e r M u l t i W i − 1 ′ , α U , i U i

Invoked by these transactions, contract SC_sys checks the validity of each received elements W i , θ W i , W i ′ and updates the value of W_i.

As a result of this procedure, the final piece of the public parameter is defined as the last valid W_i received: g 1 U ⊺ A = W n = P o w e r M u l t i P o w e r M u l t i … P o w e r M u l t i P o w e r M u l t i g 1 A ⊺ U 1 , U 2 , … , U n ⊺

At the end of this stage, each Service User (SU) can easily get the global public parameters PP_ABE of the attribute-based encryption system based on the published values. (7)P P A B E ≔ g 1 , g 2 , g 1 A , g 1 U ⊺ A .

Initiate

The contract SC_auth deployed by trusted authority AA_trust has four main functions, Commit, Reveal, Prove and Generate, which also interacts with utility function SC_util. Its accessibility is also limited by deadlines (ddl₁′, ddl₂′, ddl₃′) and the authorized list AAlist set by AA_trust.

Commit and reveal

Every AA firstly samples a set of elements e′: a matrix X ← $ Z p k + 1 × k + 1, a vector τ ← $ Z p k + 1, two secret elements σ , z ∈ Z p ∗, a scalar α_z and a scaled element α_z⋅z.

Therefore, the AA defines a set e′ for vector commitment as: e ′ ≔ z , α z , α z ⋅ z and also designates: S K ≔ X , τ , σ as the secret key. Then, AA computes a set of s-pair for each element s in both e′ and SK. We refer to the s-pair in 𝔾₁ by rp_s, and the s-pair in 𝔾₂ by rp s 2 as Definition 2. These s-pair are defined as follows:

• For matrix X ⊺ : rp X ≔ g 1 A , g 1 X ⊺ ⋅ A

• For vector τ ⊺ : rp τ ≔ g 1 A , g 1 τ ⊺ A

• For element σ : rp σ 2 ≔ g 2 , g 2 σ

• For element z : rp z , rp z 2 = g , g z

• For scalar α_z: rp α z , rp α z 2 = g , g α z

• For scaled element α_zz: rp α z z , rp α z z 2 = g , g α z ⋅ z

After that, AA computes h′ as follows: (8)h X ≔ COMMIT rp X h τ ≔ COMMIT rp τ h σ ≔ COMMIT rp σ 2 h z ≔ COMMIT rp z | | rp z 2 h α z ≔ COMMIT rp α z | | rp α z 2 h α z ⋅ z ≔ COMMIT rp α z ⋅ z | | rp α z ⋅ z 2 h ′ ≔ COMMIT h X | | h τ | | h σ | | h z | | h α z | | h α z ⋅ z and broadcasts it to the contract SC_auth through blockchain transaction as the argument of the function Commit, which is exactly same as it of the contract SC_sys. It will store the value h′ into state variable h_collector if the transaction is valid.

After h′ recorded by contract SC_auth, AA needs to reveal each committed element by passing two lists of s-pair (9)L s k = rp X , rp τ , rp σ 2 (10)L e ′ = rp s , rp s 2 | s ∈ e ′ as arguments of the function Reveal of the contract SC_auth, which computes the hash result of L_sk and L_vc using function Hash of utility contract SC_util, and compares the result with the value stored in state variable h_collector. Finally, the valid set of s-pair will be stored into state variables unverified_elements and unverified_sk of the contract SC_auth respectively.

Verify

The system enters into the stage Verify after d d l 1 ′ set by trusted authority AA_trust.

First of all, attribute authority AA generates the proof π_s≔NIZK(rp_s, h||h_s) for each s in both e′ and SK, and broadcast these proofs {π} as a list (11)L π ′ = π z , π α z , π α z z , π X , π τ , π σ through transaction before deadline d d l 2 ′. The function Prove of contract SC_auth takes input L π ′ as the argument and checks the validity of these proofs by using utility functions SameRatio and CheckPoK of contract SC_utils. The Reveal-Prove algorithms in the contract SC_auth function similarly to those in contract SC_sys. Both require all authorities to commit their secret keys and later prove that they possess the knowledge of these keys.

We assign each AA an index i ∈ [n − 1], based on the order in which SC_auth receives the complete set of valid published proofs {π}. The trusted authority, denoted as AA_trust, is assigned the index n.

At the end of this stage, we have the verified elements P K i = g 1 X i ⊺ A , e ˆ g 1 , g 2 τ i ⊺ A , g 2 σ and o i ≔ g 1 z i , g 1 α z i , g 1 α z i z i for each AA_i.

Generate

In the last stage Generate, AA_i needs to generate a set of group elements (O, θ_O, O′), selects a reasonable number of supported attributes l_i, and broadcasts them to contract SC_auth before the deadline d d l 3 ′.

The elements (O, θ_O, O′) provided by AA_i are constructed as follows: O i ≔ o i , j = o j z i i ≠ j , j ∈ n θ O i ≔ g 1 α z j α z i i ≠ j , j ∈ n O i ′ ≔ g 1 α z j z j α z i z i i ≠ j , j ∈ n

 
________________________________________________________________________________________________________________ 
Algorithm 7 Contract SCauth__________________________________________________________________________________________ 
  1:  function GENERATE(O,θ,O′,l) 
  2:       if msg.sender / ∈ AAlist OR block.timestamp > ddl then              ⊳ Requirement check 
  3:            throw 
  4:       end if 
 5:       rpz,rpαz,rpαzz ← verified_elements[msg.sender] 
  6:       i ← index[msg.sender] 
  7:       for j ← 0,n − 1 do 
 8:            if i == j then 
 9:                  continue 
10:            end if 
11:            check1 ← SAMERATIO((rpz[1],O[j]),rpz) 
12:            check2 ← SAMERATIO((rpα[1],θ[j]),rpαz) 
13:            check3 ← SAMERATIO((rpαzz[1],O′[j]),rpαzz) 
14:            if check1 == check2 == check3 == true then 
15:                  verified_O[msg.sender] ← O 
16:            else 
17:                  throw 
18:            end if 
19:       end for 
20:       attribute_size[msg.sender] ← l 
21:  end function___________________________________________________________________________________________    

Invoked by this transaction, function Generate ( Algorithm 7 ) of SC_auth firstly checks the validity of elements O i , θ O i , O i ′ and the value of l_i, and then records AA_i’s blockchain address addr with the claimed attribute size l_i. The function Generate and some state variables used are defined as follows:

1. verified_O (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its set of elements o j z i i ≠ j , i , j ∈ n in the public parameter of vector commitment PP_VC

2. attribute_size (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its number of supported attribute

For example, if AA_i owns the set of attributes {entry, mid, senior, agent, manager}, the value of attribute size l_i is 5.

After the contract SC_auth receives all the pairs {o_i, o_i,j, l_i} from AA_i ∈ {AA₁, AA₂, …, AA_n}, every Service User (SU) can get the global parameter for the vector commitment system (12)P P V C ≔ g 1 , g 2 , o i i ∈ n , o i , j i , j ∈ n , i ≠ j and generate a mapping table that maps each blockchain address of AA_i to its corresponding information as shown in Table 3. We use l to represent the size of supported attributes set X and v to represent the owned attributes for each AA.