Blockchain-enabled Data Governance for Privacy-Preserved Sharing of Confidential Data

Jingchi Zhang, , Anwitaman Datta This work was supported by Ministry of Education (MOE) Singapore’s Tier 2 Grant Award Number MOE-T2EP20120-0003 and Ministry of Education (MOE) Singapore’s Tier 1 Research Integrity Grant 2020 Award Number 020583-00001.

Abstract

In a traditional cloud storage system, users benefit from the convenience it provides but also take the risk of certain security and privacy issues. To ensure confidentiality while maintaining data sharing capabilities, the Ciphertext-Policy Attribute-based Encryption (CP-ABE) scheme can be used to achieve fine-grained access control in cloud services. However, existing approaches are impaired by three critical concerns: illegal authorization, key disclosure, and privacy leakage.

To address these, we propose a blockchain-based data governance system that employs blockchain technology and attribute-based encryption to prevent privacy leakage and credential misuse. First, our ABE encryption system can handle multi-authority use cases while protecting identity privacy and hiding access policy, which also protects data sharing against corrupt authorities. Second, applying the Advanced Encryption Standard (AES) for data encryption makes the whole system efficient and responsive to real-world conditions. Furthermore, the encrypted data is stored in a decentralized storage system such as IPFS, which does not rely on any centralized service provider and is, therefore, resilient against single-point failures. Third, illegal authorization activity can be readily identified through the logged on-chain data. Besides the system design, we also provide security proofs to demonstrate the robustness of the proposed system.

Index Terms:

Attribute-based Encryption, Blockchain, Data Sharing, Governance, Multi-authority, Privacy Enhancing Technology

I Introduction

Notwithstanding the many advantages of cloud computing, which have led to its widespread adoption and continuous growth, it also presents certain risks that prompt the exploration of alternative architectures. In particular, due to the inherent centralization of cloud services, they can become a single point of failure. This presents issues regarding service availability, censorship, and end-user privacy concerns. These challenges are further exacerbated by potential insider attacks and the service provider’s own agency. For instance, Apple’s decision in 2021 to roll out a Child Sexual Abuse Material detection technology by scanning images stored in its iCloud service led to numerous collateral privacy concerns and criticisms[1]. Even though the original plan was eventually abandoned mainly because of strong public backlash, the fundamental vulnerability of such centralized systems being subject to privacy violations or censorship remains.

To address some of these issues inherent in centralized cloud storage, many encryption schemes such as AES, RSA, Proxy Re-encryption (PRE), Identity-based Encryption (IBE), and Attribute-based Encryption (ABE) have been used to secure data confidentiality [2, 3, 4, 5]. However, some encryption schemes may not be applicable for data sharing, which is a common use case.

As an example, consider private electronic health records (EHR) that can be accessed by a patient (data owner, DO) and all the hospitals (data users, DUs) that are involved in the patient’s treatments. When the patient wants to claim the cost of medical treatment, the insurance company, which is a new DU, needs to obtain the patient’s EHR to make a judgment. In a traditional public-key encryption system like RSA, the patient must re-encrypt the EHR using the public key of the insurance company. Similarly, in the IBE scheme, the patient must generate a new identity-based ciphertext for the insurance company. These access control options are limited in terms of flexibility and scalability, as the DO may have to take additional steps on demand to ensure that the encrypted content is accessible to a new DU. In Ciphertext-Policy Attribute-based Encryption (CP-ABE) schemes, each user is associated with a set of attributes. Successful decryption can be carried out only if a user’s attribute set satisfies the access policy embedded in the ciphertext. As a result, once the message has been encrypted using the CP-ABE, it becomes available to all authorized existing and future users. Therefore, CP-ABE is a promising solution for data confidentiality and data sharing.

Traditional CP-ABE schemes may rely on intermediary entities like a Trusted Third Party (TTP) and a Central Authority (CA) for the security and trustworthiness of data access control. For normal cloud users with limited computation resources, the DO usually outsources the ciphertext to the TTP under a specified policy, and the DU may also delegate the decryption task to the TTP in [6, 7]. It also requires the CA to verify attributes across different organizations and issue private keys to every user in the data-sharing system. Therefore, when analyzing the adversarial model of these schemes, researchers tend to make the assumption that TTP or CA are fully trusted [8, 7]. Such a system is vulnerable to access credentials misuse that a malicious CA may purposefully issue attribute keys to some unauthorized users. It is thus crucial to design decentralized alternatives for trust mechanisms and enforce traceability throughout the access control system.

Blockchain-based access control system with CP-ABE has the potential to be an effective solution to these problems. In the absence of a TTP to control the data, each node would share a distributed ledger that keeps track of a growing list of transactions that have been 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. Based on these premises, several blockchain-based access control systems have been proposed since the emergence of public blockchain systems[9] and the advent of Attributed-based Encryption[10]. Some efforts leverage the immutable public ledger to build a transaction-based access control system for secure data sharing[11, 12, 13], while others leverage the self-executing smart contracts to establish a smart contract-based access control system for flexibility and traceability[14, 15].

However, just employing blockchain technology and CP-ABE encryption for an access control system is inadequate for various real-world applications. 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. The same attribute authority cannot be responsible for both attribute management and key distribution. Therefore, multi-authority Attribute-based Encryption [16], first proposed by Chase in 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 are later selected by the data owner for encrypting a message.

Another concern is the privacy issue, which encompasses 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 [16, 17, 18] are also 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 multi-authority CP-ABE schemes that feature policy-hiding have been proposed [19, 20, 21]. Despite these efforts, they do not completely fulfill various practical requirements. Schemes such as [19, 21] are prone to the leakage of DU’s confidential attribute information during the key generation or encryption process. Michalevsky and Joye introduced a fully policy-hiding decentralized CP-ABE scheme [20], which protects attribute information attached to the access policy and even addresses the issue of receiver privacy. However, we identified a vulnerability in this scheme as it is susceptible to rogue-key attack. In this type of attack, a malicious AA can register an aggregate public key using public information from other honest AAs. This key can be used to decrypt the ciphertext despite lacking the necessary attribute keys to satisfy the policy. The attack mechanism on [20] is elaborated in Section VI-F1.

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 privacy, transparency and traceability constitutes a complex problem that requires innovative solutions.

I-A Contributions

In this paper, we propose a multi-party CP-ABE-based storage outsourcing system that uses blockchain technology to limit access credential misuse and privacy leakage. To the best of our knowledge, this is the first practical solution for storage outsourcing to achieve fine-grained access control with user anonymity and flexibility.

The core contributions of this work are as follows:

•

We discern that the decentralized ABE scheme with policy-hiding presented in [20] inherently possesses security vulnerabilities. It is susceptible to a rogue-key attack: A malicious AA can decrypt the ciphertext without the knowledge of the attribute keys required to satisfy the policy. It also encounters a potential risk where an adversary might infer some sensitive information from the published ciphertext, a result of poorly chosen public parameters. These vulnerabilities are thoroughly analyzed in Section VI-F1 and Section VI-G1, respectively.
•

To counteract the rogue-key attack and alleviate some potential risks, we modify the algorithms of Setup and Auth Setup in [20] as described in Definition 5. Firstly, we introduce a multi-party protocol inspired by [22] for public key generation, which is detailed in Trusted Setup of Section V-A. Secondly, we impose a prerequisite for each AA to prove the knowledge of published information during the process of Auth Setup. This is elaborated in Section V-B. We further demonstrate that our enhanced system successfully mitigates the aforementioned security concerns, as outlined in Section VI-F2 and Section VI-G2.
•

In order to further decentralize our proposed system, we integrate blockchain technologies such as smart contracts and content addressing, alongside multi-authority attribute-based encryption. An overview of the system architecture is presented in Section IV and pseudo code of system contracts can be found in Section VIII. This hybrid approach enhances the practicality and security of the system, which makes it resilient against single-point failures and misuse of credentials. Given that transparency and traceability are inherent attributes of blockchain, a blockchain-enabled ABE system actually realizes a balanced solution for data sharing while simultaneously preserving privacy.
•

Overall, we propose a secure, privacy-preserving data governance system based on blockchain technology and an improved decentralized CP-ABE scheme with policy-hiding. Using a combination of Attribute-based Encryption (ABE) and the Advanced Encryption Standard (AES) makes the system practical. The special ABE encryption scheme is capable of handling multi-authority use cases while protecting identity privacy and ABE’s policy. The adoption of AES helps assure the confidentiality of user data, which is furthermore stored in a decentralized storage system, specifically Inter Planetary File System (IPFS), which does not rely on a central service provider and hence does not become a single point failure.

TABLE I: Summary of Access Control System using Attribute-based Encryption (Part I)

Approach	Authority	Policy	Universe	Policy-hiding	Receiver-hiding	Access Control	Storage
[13]	Single	AND	Small	No	No	Smart Contract	IPFS
[14]	Multiple	LSSS	Small	No	No	CSP	CSP
[19]	Multiple	LSSS	Small	No	Yes	CSP	CSP
[23]	Single	AND	Small	Partially	No	CSP	CSP
[24]	Single	AND	Large	Fully	No	Smart Contract	CSP
[25]	Single	LSSS	Large	Partially	No	CSP	CSP
[26]	Single	LSSS	Large	Partially	No	CSP	CSP
[27]	Multiple	LSSS	Large	Fully	No	CSP	CSP
[28]	Multiple	LSSS	Large	Fully	No	CSP	CSP
This work	Multiple	AND	Small	Fully	Yes	Smart Contract	IPFS

In Table I, we compare and position our proposed Blockchain-enabled data governance system with existing works [13, 14, 23, 27, 24, 25, 26, 19, 28] that are closely related to ours with regard to flexibility, scalability, privacy, and decentralization across the following assessment criteria:

1.

Attribute Authority: Whether the authorities involved in CP-ABE schemes are divided into single thus central authority or multi-authority.
2.

Policy: Linear Secret Sharing Scheme (LSSS) which supports AND gate, OR gate, and threshold gate versus only AND.
3.

Attribute Universe: We define the complete set of supported attributes as attribute universe and only take into account two types of universe: large universe and small universe. In large universe ABE, the attribute universe size has no effect on the size of the system’s public key.
4.

Privacy: There are two aspects of privacy involved in CP-ABE schemes: policy-hiding and receiver-hiding. For the policy-hiding scheme, the CP-ABE system is available in two forms: fully hidden and partially hidden. The former means that none of the attributes can be revealed from the access policies, whereas the latter refers to only hiding sensitive attribute values in the access policies. For the receiver-hiding scheme, it prevents any AAs from learning the full set of attributes the receiver (i.e., the DU) possesses, hence relieving the DU from disclosing them while requesting attribute keys.
5.

Storage: From a technical perspective, traditional cloud service provider (CSP) and decentralized storage systems such as IPFS, Storj, and Sia, are two distinct popular solutions for data storage and sharing. CSPs may take advantage of their comprehensive control over data, but end users are exposed to the risks of a single point of failure, privacy violation, and censorship.
6.

Access Control: We indicate whether access control enforcement is through a smart contract and thus logically decentralized or by a cloud service provider and thus logically centralized.

From Table I, we observe that very few schemes [27, 19, 28] achieve fine-grained access control and support multi-authority with privacy-preserved characteristics, such as policy-hiding and receiver privacy. However, they all rely on a trusted third party (TTP) or cloud service provider (CSP) to offer centralized storage and access control management and are thus susceptible to the inherent vulnerabilities of such centralized systems in terms of privacy issues. In contrast, our proposed scheme integrates an IPFS network for decentralized storage and a smart contract for access control management in order to decentralize.

I-B Organization

The rest of the paper is structured as follows: Section II contains related work that reviews traditional Attribute-based Encryption schemes and conducts an analysis of some recent solutions for access control systems with ABE technology, while Section III summarizes the preliminaries that the techniques developed in this paper build upon. The proposed system model and protocols are discussed in depth in Section IV and Section V. Section VI contains systematic security analysis. Finally, our conclusions and future plans are presented in Section VII.

II Related Work

Attribute-based encryption (ABE) was first introduced by Sahai and Waters in 2005 [10]. Subsequently, numerous proposals for single-authority ABE system [29, 30] have been put forth. In these systems, the data owner (DO) encrypts data and employs a boolean formula over a set of attributes to restrict access. If the data user (DU) possesses the secret keys, issued by a central authority (CA) that satisfy the boolean formula attached to the ciphertext, DU can retrieve the original data. However, these single-authority ABE systems [10, 29, 30] encounter constraints such as performance bottlenecks and key escrow issues.

Therefore, Zhang et al proposed an enhanced CP-ABE scheme [31], which alleviates the performance bottleneck issue by reducing the computation cost and ciphertext length. This work has been further explored in [13] to create a framework that integrates decentralized storage, smart contract, and CP-ABE techniques to achieve fine-grained access control.

Another concern with the single-authority ABE system is key escrow, where CA issues all the attribute secret keys, thereby gaining the ability to decrypt each ciphertext generated by data owners. To address this issue, Chase and Chow introduced Multi-authority Ciphertext-policy ABE (MA-CP-ABE) [16] without the need for CA. Lewko and Waters further developed this multi-authority scheme in their work [17] allowing any authority to join or leave the system independently. Based on this work, Qin et al designed a blockchain-based multi-authority access control scheme to address performance and single-point failure issues [14].

In an effort to extend the usability of CP-ABE schemes, Nishide et al. presented a desirable property, hidden access policy, in [23]. This approach protects sensitive attribute values while leaving attribute names public, denoted as partially-hiding. Since then, multiple enhanced schemes [32, 24, 25, 26, 27] have been proposed. To support a wide variety of access structures, a fully secure policy-hiding CP-ABE was proposed in [32]. Gao et al used the optimized scheme of [32] to build a blockchain-based access control system in [24] that achieves trustworthy access while maintaining the privacy of policy and attributes. To improve the expressiveness of the access policy, a partially hidden CP-ABE scheme under the Linear Secret Sharing Scheme (LSSS) policy was proposed in [25]. Zhang et al proposed a privacy-aware access control system in [26], denoted as PASH, which supports a large universe CP-ABE scheme with partially hidden CP-ABE. We note that there is another, stricter form of policy-hiding CP-ABE, fully hiding CP-ABE, with which no information of the attributes is revealed with the access policies. Currently, fully hiding CP-ABE can only be indirectly achieved by inner product encryption (IPE) or by using threshold policies [7]. There are several similar approaches providing policy-hiding as well as ensuring accountability for key abuse, for example, Li’s work [27] based on large universe Attribute-Based Encryption construction [33] and Wu’s scheme [34] based on attribute bloom filter (ABF) [35].

Nevertheless, most of the aforementioned schemes either neglect the attribute of policy-hiding or exist as single-authority ABE systems. This gap is addressed by multi-authority CP-ABE schemes with a hidden access policy [36, 37, 20, 28]. The multi-authority CP-ABE scheme featuring policy-hiding was initially introduced by Zhong et al in [36], and subsequently improved by Belguith in [37] that significantly diminishes computational cost by delegating the decryption work to a semi-trusted cloud server. In 2018, Michalevsky and Joye [20] put forward the first practical decentralized CP-ABE scheme with the policy-hiding property. This scheme provides a security proof in the random oracle model and supports various types of access policies, including conjunctions, disjunctions, and threshold policies. Furthermore, Michalevsky and Joye addressed the issue of receiver privacy through the use of vector commitment. However, it has its limitations, including its support for only fixed-size attributes and authorities, and the requirement for coordination among authorities during the setup phase. Most critically, we demonstrate that it is vulnerable to a rogue-key attack, where a compromised authority may decrypt the ciphertext even in the absence of the requisite attribute keys.

In addition to the above, there are a few other proposals [19, 28] in this area that, unfortunately, give rise to additional issues. For instance, a system developed by Yang et al. in [19] keeps the user’s identity private from the attribute authority (AA) if they are not in the same domain. Yet, this approach creates a new privacy issue that users might request AAs within the domain to ask secret attribute keys from other AAs on their behalf, implying that an AA could potentially possess a complete set of a DU’s secret keys. Zhao et al. presented a data sharing scheme [28] that adopts the access policy of linear secret sharing scheme (LSSS) and supports multi-authority CP-ABE scheme with policy-hiding to achieve the privacy-preserving functionality. However, this system is vulnerable to user key abuse due to its dependence on a single central authority for key generation.

III Preliminary

To initiate, we revisit certain foundational principles employed within our system. A summary of crucial notations utilized throughout the manuscript is provided in Table II.

TABLE II: Notation Description

Notation	Description
$\mathbb{G}_{1},\mathbb{G}_{2}$	Two additive cyclic groups of prime order $p$
$\mathbb{G}_{T}$	A multiplicative cyclic group of the same order $p$ .
$\mathbb{Z}_{p}$	A set of integers modulo $p$
$\lambda$	A security parameter that measures the input size of the system
$p$	A prime number used for groups $\mathbb{G}_{1},\mathbb{G}_{2},\mathbb{G}_{T}$ and $\mathbb{Z}$
$i,j$	Two indexes used to represent $i$ th ( $j$ th) element or position in a sequence or set
$k$	The parameter associated with the k-lin assumption, representing the linear independence of group elements.
$PP_{ABE}$	Public parameters for the use of Attribute-Based Encryption
$PP_{VC}$	Public parameters for the use of Vector Commitment
$\alpha$	A scalar used for generation of $PP_{ABE}$ and $PP_{VC}$
$e$	A set of secret elements used for Trusted Setup
$e^{\prime}$	A set of secret elements used for Authority Setup
$h$	A hash of committed elements in Trusted Setup
$h^{\prime}$	A hash of committed elements in Authority Setup
$\pi$	A proof of knowledge for an element
$\bm{rp}_{s}$	A s-pair of the element $s$ in group $\mathbb{G}_{1}$ . The superscript $2$ of $\bm{rp}_{s}^{2}$ represent s-pair elements in group $\mathbb{G}_{2}$
$L$	A list of s-pair consisting of all the committed group elements
$PK$	A public key owned by AA, which is used for ABE encryption
$SK$	A secret key owned by AA, which is used for ABE encryption
$\bm{X}$	A secret matrix element in $SK$
$\bm{\tau}$	A secret vector element in $SK$
$\sigma$	A secret value in $SK$
$\bm{A},\bm{U}$	The secret exponents used in $PP_{ABE}$
$K$	A component of the attribute key generated by the attribute authority corresponds to an individual attribute.
$sk$	The consolidated secret key issued by an attribute authority. Given that an attribute authority can oversee multiple attributes, $sk$ might comprise several $K$ components, each representing a distinct attribute.
$\bm{x}$	A policy vector
$\bm{v}$	An attribute vector
$\bm{C}$	A Vector Commitment associated with a specific Data User, derived from its attribute vector and global identifier
$m$	A special message used in Vector Commitment
$op$	An opening proof to reveal the Vector Commitment
$o_{i},o_{i,j}$	The elements in $PP_{VC}$ where $i,j\in[n],i\neq j$
$z$	A secret exponent of group element $o$
$\bm{aux}$	A collection of message $m$
$\mathcal{U}$	A set of attribute authorities in the universe
$n$	The number of attribute authorities includes $\textit{AA}_{\text{trust}}$ in the system
$\mathcal{X}$	A set of attributes in the universe
$l$	The number of supported attributes
$\mathcal{S}$	A set of attributes possessed by each attribute authority
$\mathcal{R}$	A set of attributes possessed by data user
$F$	A file shared by data owner
$AK$	An AES key used to encrypt the file $F$
$CT_{F}$	An encrypted sharing file $F$ encrypted by AES system
$M$	A metadata consisting related information of $CT_{F}$
$kw$	A keyword used in metadata to ease the data retrieval process
$CT_{M}$	An encrypted metadata $M$ encrypted by ABE system
$loc$	A location address in IPFS for a file $F$
$addr$	A blockchain address
$GID$	A Data User’s Global identifier
$BPK$	A public key registered in a blockchain
$BSK$	A private key registered in a blockchain
IPFS	The InterPlanetary File System

III-A Bilinear Mapping

Consider $\mathcal{G}$ as an algorithm that accepts a security parameter $\lambda$ and constructs three multiplicative cyclic groups of prime order $p$ : $\mathbb{G}_{1}=\langle g_{1}\rangle,\mathbb{G}_{2}=\langle g_{2}\rangle$ , and $\mathbb{G}_{T}$ . We introduce $\hat{e}$ as a bilinear map, with $\hat{e}:\mathbb{G}_{1}\times\mathbb{G}_{2}\rightarrow\mathbb{G}_{T}$ . The bilinear map $\hat{e}$ has the following characteristics:

1.

Bilinearity: for all $a,b\in\mathbb{Z}$ , $\hat{e}(g_{1}^{a},g_{2}^{b})=\hat{e}(g_{1},g_{2})^{ab}$ .
2.

Non-degeneray: $\hat{e}(g_{1},g_{2})\neq 1$ .
3.

Computability: for all $a,b\in\mathbb{Z}$ , $\hat{e}(g_{1}^{a},g_{2}^{b})$ can be efficiently computed.

III-B Auxiliary methods and definitions

We make an assumption of possessing an algorithm, denoted as COMMIT, which takes strings of arbitrary length as input and produces outputs as determined by a random oracle. While this assumption aids our security analysis, in practical implementations, we could use the BLAKE-2 hash function in place of COMMIT.

Algorithm 1 Commit of string

h

h

is a string

2:function COMMIT(

h

)

output\leftarrow

maps

h

to random integer in

\mathbb{Z}_{p}^{*}

4: return

output

5:end function

For the inputs $h$ that can not be mapped directly to integers, especially in the case of group elements, we represent them using byte-strings.

Additionally, we introduce several auxiliary methods to facilitate the verification procedure for certain special properties.

The following definitions and claims are first proposed in the work [22]

Definition 1.

Given a bilinear mapping $\hat{e}:\mathbb{G}_{1}\setminus\{0\}\times\mathbb{G}_{2}\setminus\{0\}\rightarrow\mathbb{G}_{T}$ , elements $A,B\in\mathbb{G}_{1}\backslash\{0\}$ and $C,D\in\mathbb{G}_{2}\backslash\{0\}$ . If $\hat{e}(A,D)=\hat{e}(B,C)$ , we may use the term $\mathbf{SameRatio}((A,B),(C,D))$ to represent this relation.

Algorithm 2 Determin if two pairs

(A,B)

and

(C,D)

have certain relationship

A,B\in\mathbb{G}_{1}\backslash\{0\}

and

C,D\in\mathbb{G}_{2}\backslash\{0\}

2:function SameRatio(

(A,B),(C,D)

)

3: if

\hat{e}(A,D)=\hat{e}(B,C)

then

4: return true

5: else

6: return false

7: end if

8:end function

Definition 2.

Given a bilinear mapping $\hat{e}:\mathbb{G}_{1}\setminus\{0\}\times\mathbb{G}_{2}\setminus\{0\}\rightarrow\mathbb{G}_{T}$ , $s\in\mathbb{Z}_{p}^{*}$ and cyclic group of order $p$ , an s-pair is a pair $(A,B)$ such that $A,B\in\mathbb{G}_{1}$ , or $A,B\in\mathbb{G}_{2}$ ; and $s\cdot A=B$ . For such an s-pair $(A,B)$ in $\mathbb{G}_{1}$ or $\mathbb{G}_{2}$ , we may represent it using the notation $\bm{rp}_{s}$ or $\bm{rp}_{s}^{2}$ respectively.

Claim 1.

SameRatio $((A,B),(C,D))=$ true) if and only if there exists $s$ such that $(A,B)$ is an s-pair in $\mathbb{G}_{1}$ and $(C,D)$ is an s-pair in $\mathbb{G}_{2}$ .

Proof.

Suppose there exist one element $s^{\prime}$ that $s\cdot A=B$ , $s^{\prime}\cdot C=D$ and $s\neq s^{\prime}\pmod{p}$ . For some $a,c\in\mathbb{Z}_{p}^{*}$ , we have $A=a\cdot g_{1}$ and $C=c\cdot g_{2}$ . As defined in Definition 1, none of the elements $(a,c,s,s^{\prime})$ is $0$ .

Therefore,

	$\displaystyle\hat{e}(A,D)=\hat{e}(a\cdot g_{1},s^{\prime}\cdot C)=g_{T}^{acs^{\prime}}$
	$\displaystyle\hat{e}(B,C)=\hat{e}(s\cdot A,c\cdot g_{2})=g_{T}^{acs}$

if and only if $s=s^{\prime}\pmod{p}$ , otherwise, $\mathbf{SameRatio}((p,q),(f,H))=$ false. As a result, no such $s^{\prime}$ exists. ∎

Finally, we can construct our special s-pair as follows

Definition 3.

Given a bilinear mapping $\hat{e}:\mathbb{G}_{1}\setminus\{0\}\times\mathbb{G}_{2}\setminus\{0\}\rightarrow\mathbb{G}_{T}$ and a matrix $s\in\mathbb{Z}_{p}^{l\times k}$ , a special s-pair is a pair $(A,B)$ such that $A,B\in\mathbb{G}_{1}^{l\times k}$ or $A,B\in\mathbb{G}_{2}^{l\times k}$ ; and

B[i,j]=A[i,j]^{s[i,j]}

For such a special s-pair $(A,B)$ in $\mathbb{G}_{1}$ or $\mathbb{G}_{2}$ , we may also denote it as $\bm{rp}_{s}$ . Given that a vector can be considered a matrix with a single column, we can also use the notation $\bm{rp}_{s}$ to represent an s-pair when $s\in\mathbb{Z}_{p}^{k}$ .

III-C Assumptions

Given a bilinear mapping $\hat{e}:\mathbb{G}_{1}\setminus\{0\}\times\mathbb{G}_{2}\setminus\{0\}\rightarrow\mathbb{G}_{T}$ with associated generators $\{g_{1},g_{2},g_{T}\}$ and group order $p$ , our work builds upon a variety of standard assumptions, which are detailed below.

Assumption 1.

Symmetric External Diffie-Hellman (SXDH) assumption [38]
It is hard to distinguish $\mathcal{D}_{0}=(g_{1},g_{2},g_{1}^{a},g_{1}^{b},g_{1}^{ab})$ from $\mathcal{D}_{1}=(g_{1},g_{2},g_{1}^{a},g_{1}^{b},g_{1}^{c})$ where $a,b,c\xleftarrow[]{\$}\mathbb{Z}_{p}$ . This also holds to the tuples $\mathcal{D}_{0}^{\prime}=(g_{1},g_{2},g_{2}^{a},g_{2}^{b},g_{2}^{ab})$ and $\mathcal{D}_{1}^{\prime}=(g_{1},g_{2},g_{2}^{a},g_{2}^{b},g_{2}^{c})$ in different group.

Assumption 2.

K-Linear assumption [39]
It is hard to distinguish $\mathcal{D}_{0}=(g_{1},g_{2},g_{1}^{a_{1}},g_{1}^{a_{2}},\dots,g_{1}^{a_{k}},g_{1}^{a_{1}b_{1}},g_{1}^{a_{2}b_{2}},\dots,g_{1}^{a_{k}b_{k}},g_{1}^{b_{1}+b_{2}+\dots+b_{k}})$ from $\mathcal{D}_{1}=(g_{1},g_{2},g_{1}^{a_{1}},g_{1}^{a_{2}},\dots,g_{1}^{a_{k}},g_{1}^{a_{1}b_{1}},g_{1}^{a_{2}b_{2}},\dots,g_{1}^{a_{k}b_{k}},g_{1}^{c})$ where $a_{1},\dots,a_{k},b_{1},\dots,b_{k},c\xleftarrow[]{\$}\mathbb{Z}_{p}$ . This also holds in the group $\mathbb{G}_{2}$ .

For $a_{1},a_{2},...,a_{k}\xleftarrow{\$}\mathbb{Z}_{p}^{*}$ , we have the construction of

\bm{A}=\begin{pmatrix}a_{1}&0&&0\\ 0&a_{2}&&0\\ \vdots&\ddots&&\\ 0&0&\cdots&a_{k}\\ 1&1&\cdots&1\\ \end{pmatrix}\in\mathbb{Z}^{(k+1)\times k}_{p}

(1)

and

\bm{a}^{\perp}=\begin{pmatrix}a_{1}^{-1}\\ a_{2}^{-1}\\ \vdots\\ a_{k}^{-1}\\ -1\\ \end{pmatrix}\in\mathbb{Z}^{(k+1)}_{p}

(2)

, with $\bm{A^{\intercal}a}^{\perp}=0$ .

Assumption 3.

Special k-Linear assumption [20]
Given a randomly generated matrix $\bm{A}\in\mathbb{Z}_{p}^{(k+1)\times k}$ and a vector $\bm{s}\in\mathbb{Z}_{p}^{(k+1)}$ , the tuples $\mathcal{D}_{0}=(g_{1},g_{2},g_{1}^{\bm{A}},g_{1}^{\bm{As}})$ and $\mathcal{D}_{1}=(g_{1},g_{2},g_{1}^{\bm{A}},g_{1}^{\bm{s}})$ are computationally indistinguishable by any polynomial-time $\mathcal{A}$ . The structure of matrix $\bm{A}$ is described in Eq.1 and the vector $\bm{a}$ is derived from $\bm{A}$ as detailed in Eq.2.

Assumption 4.

Square Computational Diffie-Hellman assumption [40]
Given $(g,g^{a})$ for a random number $a$ in a cyclic group $\mathbb{G}$ of order $p$ , a $PPT$ algorithm $\mathcal{A}$ outputs $g^{a^{2}}$ with non-negligible probability.

Assumption 5.

Knowledge of Coefficient assumption [41]
Given a string of arbitrary length $h$ , and a uniformly chosen $C\in\mathbb{G}_{2}$ (independent of $h$ ), an efficient algorithm $\mathcal{A}$ exists that can randomly generate $B\in\mathbb{G}_{1}$ and $D\in\mathbb{G}_{2}$ . Meanwhile, for the same inputs $(C,h)$ , there is an efficient deterministic algorithm $\mathcal{X}$ cable of extracting a scalar $b$ . The probability that:

1.

$\mathcal{A}$ ‘succeeds’, meaning it satisfies the condition: SameRatio( $(g_{1},B),(C,D)$ )
2.

$\mathcal{X}$ ‘fails’, meaning $B\neq g_{1}^{b}$

is negligible.

III-D Proof of Knowledge

We adopt the well-established Schnorr Identification Protocol [42], utilizing it as our Non-interactive Zero-knowledge Proof (NIZK). Provided with an s-pair $rp_{s}=(A,B=s\cdot A)$ and a string $h$ , we establish NIZK (Algorithm 3). This can serve as a proof that the originator of the string $h$ is aware of $s$ in the s-pair $rp_{s}$ .

Algorithm 3 Construct a proof of knowledge of

s

rp_{s}

is an s-pair

h

is a string

3:function NIZK(

rp_{s}=(A,B),h

)

\alpha\xleftarrow[]{\$}\mathbb{Z}_{p}^{*}

R\leftarrow\alpha\cdot A

c\leftarrow

COMMIT

(R||h)\in\mathbb{Z}_{p}^{*}

u\leftarrow\alpha+c\cdot s

8: return

\pi=(R,u)

9:end function

Furthermore, we define VerifyNIZK (Algorithm 4), which checks the validity of the provided proof $\pi$ .

Algorithm 4 Verify a proof of knowledge of

s

rp_{s}

is an s-pair

h

is a string

3:function VerifyNIZK(

rp_{s}=(A,B),\pi=(R,u),h

)

c\leftarrow

COMMIT

(R||h)\in\mathbb{Z}_{p}^{*}

5: if

u\cdot A==R+c\cdot B

then

6: return true

7: else

8: return false

9: end if

10:end function

III-E Vector Commitment

We ensure our attribute-hiding property through the utilization of a Vector Commitment scheme, as described in [43]. The summarized scheme is as follows:

Definition 4.

This Vector Commitment system commits to an ordered sequence of attribute elements $\bm{v}=(v_{1},v_{2},\cdots,v_{l+1})$ as commitment $\bm{C}$ , then opens it in a certain position of $\bm{v}$ to a corresponding attribute authority (AA), and finally proves that only authorized value existed in the previously supplied commitment $\bm{C}$ . The system normally consists of 4 algorithms:

•

Key Generation $(1^{\lambda},n)\rightarrow PP_{VC}$ : This is a Decentralized Key Generation (DKG) algorithm. It takes as input the security parameter $\lambda$ and the number of attribute authorities, $n$ , in the system, and outputs global public parameters $PP_{VC}=\{g_{1},g_{2},\{o_{i}\},\{o_{i,j}\}\}$ where $i,j\in[n],i\neq j$ . The element $o_{i}$ is generated and published by $\textit{AA}_{i}$ . Following that, the elements $\{o_{i,j}\}$ can be issued by each $\textit{AA}_{i}$ based on the shared $\{o_{i}\}$ .
•

Commitment $(\bm{aux}=\{m_{i}\}_{i\in[n]})\rightarrow\bm{C}$ : This algorithm is run by a Data User (DU). It takes as input the message $m_{i}$ generated based on the authorized attributes from $\textit{AA}_{i},i\in[n]$ , and outputs the commitment $\bm{C}$ .
•

Open $(m_{i},i,\bm{aux})\rightarrow op_{i}$ : This algorithm is also run by a DU. It takes as input the auxiliary information $\bm{aux}$ and index $i$ , and outputs the opening proof $op_{i}$ .
•

Verify $(\bm{C},m_{i},i,op_{i})\rightarrow(1~{}or~{}0)$ : The Verify algorithm is run by AA. It takes as inputs the commitment $\bm{C}$ , message $m_{i}$ , index $i$ , and opening proof $op_{i}$ , and outputs the result of the verification. It outputs $1$ when it accepts the proof.

III-F Decentralized Inner-Product Predicate Encryption

Definition 5.

A Multi-authority Attribute-based Encryption with policy-hiding scheme [20] consists of a tuple of Probabilistic Polynomial-Time (PPT) algorithms, such that:

•

Setup $(1^{\lambda})\rightarrow PP$ : The global setup algorithm is a decentralized generation algorithm that takes as input the security parameter $\lambda$ and then outputs the public parameters $PP$ .
•

Authority Setup $(PP,i)\rightarrow(PK_{i},SK_{i})$ : The authority setup algorithm is run by each $\textit{AA}_{i}$ . It takes as input public parameter $PP$ and authority index $i$ , and outputs a pair of authority keys $(PK_{i},SK_{i})$ .
•

Key Generation $(PP,i,SK_{i},\{PK\},GID,\bm{v})\rightarrow sk_{i,GID,\bm{v}}$ : The key generation algorithm is run by each $\textit{AA}_{i}$ . It takes as input the global public parameters $PP$ , the authority index $i$ , its secret key $SK_{i}$ , all the public keys $\{PK_{i}\}_{i\in[n]}$ , and DU’s global identifier $GID$ and the attribute vector $\bm{v}$ , and outputs the secret keys $sk_{i,GID,\bm{v}}$ .
•

Encryption $(PP,\{PK\},\bm{x},F)\rightarrow CT_{F}$ : The data encryption algorithm is run by a Data Owner (DO). It takes as inputs the global parameters $PP$ , the public keys of all the authorities $\{PK_{i}\}_{i\in[n]}$ , the ciphertext policy vector $\bm{x}$ and a file $F$ , and outputs a ciphertext $CT_{F}$ .
•

Decryption $(\{sk_{i,GID,\bm{v}}\}_{i\in n},CT_{F})\rightarrow F$ : The decryption algorithm is run by the authorized DU. It takes as inputs the collection of secret keys $\{sk_{i,GID,\bm{v}}\}$ from $\textit{AA}_{i}$ and the ciphertext $CT_{F}$ , and outputs the message $F$ if the access policy has been satisfied.

It’s important to highlight that the algorithms delineated above do not hide the attributes vector $\bm{v}$ from the authorities. Rather, we incorporate the vector commitment $\bm{C}$ as an input for the Key Generation process. The detail of this procedure will be provided in the context of Section V.

IV System Overview

IV-A System Architecture

The system architecture is shown in Figure 1,

Refer to caption — Figure 1: The system consists of 6 processes, each of which is represented by a different color: Blue for the process Trusted Setup, orange for the process Authority Setup, gray for the process Data User Registration, black for the process Key Generation, yellow for the process Encryption and Upload, and green for the process Download and Decryption. And these connectors, Single or Double-Arrow, indicate the interactions between service users and two blockchain networks, Ethereum and IPFS. Note that these 4 contracts deployed on Ethereum are used for data governance, while IPFS is used for data storage. For a detailed description of the system flow between smart contracts, IPFS, and various entities, please check Section IV for the Interaction Overview and Section V for the System Design.

which comprises the following logical entities:

Data Owner (DO): DO is an entity (individual or organization) that owns a certain file $F$ . For secure storage and sharing, DO encrypts $F$ using the AES key $AK$ and uploads the encrypted file $CT_{F}$ to the IPFS network, records the returned file location $loc$ , and embeds $AK$ and $loc$ into the metadata $M$ which is subsequently encrypted using the ABE system and published $CT_{M}$ in the Ethereum network.

Data User (DU): DU is a data client for DO. It asks the attribute authority AA for permission to get the necessary attribute secret keys $\{sk\}$ , which are then used to decrypt the associated $CT_{M}$ stored on the Ethereum network. After getting the key $AK$ and the location $loc$ from $M$ , DU can download the encrypted file $CT_{F}$ from the IPFS network and recover the original file $F$ .

Attribute Authority (AA): AA is an entity (individual or organization) that contributes to the generation of the public parameters of the ABE system $PP_{ABE}$ and the vector commitment scheme $PP_{VC}$ , publishes the public key $PK$ for the DO to encrypt metadata $M$ , owns a set of attributes and issues secret key $sk$ for the owned attributes upon the request of the DU.

Trusted Attributed Authority ( $\textit{AA}_{\text{trust}}$ ): $\textit{AA}_{\text{trust}}$ is a trusted attribute authority that mainly generates a secret key $sk$ for DU and deploys system contracts for setup and registration. $\textit{AA}_{\text{trust}}$ , unlike normal AA, owns no attributes but is in charge of a specific position in the attribute vector $\bm{v}$ .

Service User ((SU)): In the system, (SU) is a general entity comprising DO, DU and AA.

Participant ( $P$ ): $P$ is a special entity that represents each AA during the process of Trusted Setup. The index $i$ of $P_{i}$ denotes the chronological order of each piece of public parameter generated and shared by AA.

Trust Setup Contract ( $SC_{sys}$ ): The contract $SC_{sys}$ is deployed to the Ethereum network by the $\textit{AA}_{\text{trust}}$ and can only be invoked by an authorized AA within the time window specified. It is responsible for generating the global public parameters $PP_{ABE}$ .

Authority Setup Contract $(SC_{auth})$ : Contract $SC_{auth}$ is deployed to the Ethereum network by the $\textit{AA}_{\text{trust}}$ . It can only be invoked by the authorized AA within the specified time window. It is used to generate the global public parameters $PP_{VC}$ and to keep track of the valid information about AA’s address $addr$ , public key $PK$ , and supported attributes $\mathcal{S}$ .

User Registration Contract $(SC_{reg})$ : Contract $SC_{reg}$ is deployed to the Ethereum network by the $\textit{AA}_{\text{trust}}$ and can be invoked by all the potential DUs. To register the $addr$ in the system, DU needs to make sufficient payment to the $SC_{reg}$ and then get back the $GID$ which can later be used to request secret key $sk$ from AA.

Utility Contract ( $SC_{util}$ ): Contract $SC_{util}$ is deployed to the Ethereum network by the $\textit{AA}_{\text{trust}}$ and can only be invoked by other contracts deployed by $\textit{AA}_{\text{trust}}$ . It is mainly used to verify group elements published by AA.

Log Contract ( $SC_{log}$ ): Contract $SC_{log}$ is deployed to the Ethereum network by the $\textit{AA}_{\text{trust}}$ . When it receives a new transaction from DO, it records the encrypted data $CT_{M}$ of metadata $M$ and triggers the event to the subscribers.

Blockchain: Each user (DO, DU, AA and $\textit{AA}_{\text{trust}}$ ) possesses a pair of keys $(BPK,BSK)$ and a corresponding wallet address $addr$ on the blockchain. Our system employs two blockchains: IPFS for data storage and Ethereum for data governance.

IV-B Interactions overview

In this section, we describe the overview of our proposed system to show how smart contracts, IPFS, vector commitment, and MA-CP-ABE with policy-hiding are composed together to build a secure, privacy-preserving, and blockchain-enabled data governance system. When it ought to be clear from the context, we omit most indices, like $i$ and $j$ of elements, and superscript in $\bm{rp}_{s}^{2}$ for readability.

1.
Trusted Setup
1. 1
  
  First, a community of normal attribute authorities (AAs) with size $n-1$ and a special trusted attribute authority ( $\textit{AA}_{\text{trust}}$ ) must be determined. $\textit{AA}_{\text{trust}}$ selects the security parameter $\lambda$ and two generators $g_{1},g_{2}$ for the bilinear mapping, and defines following algorithms: COMMIT, NIZK, VerifyNIZK and powerMulti.
2. 2
  
  $\textit{AA}_{\text{trust}}$ deploys one system contract $SC_{sys}$ and one utility contract $SC_{util}$ .
3. 3
  
  Each AA randomly samples a set of secret elements $e$ : two matrixes $\bm{A}\in\mathbb{Z}_{p}^{(k+1)\times k}$ and $\bm{U}\in\mathbb{Z}_{p}^{(k+1)\times(k+1)}$ , two scalars $\alpha_{\bm{A}}$ and $\alpha_{\bm{U}}$ in $\mathbb{Z}_{p}^{*}$ , and two scaled matriex $\alpha_{\bm{A}}\cdot\bm{A}$ and $\alpha_{\bm{U}}\cdot\bm{U}$ , and publishes a corresponding set of s-pair $\{\bm{rp}_{\bm{A}},\bm{rp}_{\bm{U}},\bm{rp}_{\alpha_{\bm{A}}},\bm{rp}_{\alpha_{\bm{U}}},\bm{rp}_{\alpha\cdot\bm{A}},\bm{rp}_{\alpha\cdot\bm{U}}\}$ as defined in Def.2 and Def.3 to the contract $SC_{sys}$ .
4. 4
  
  After that, AA computes and publishes the commitments $h:=\text{{COMMIT}}(\{h_{s}\}||)$ as showed in Alg. 1 to $SC_{sys}$ , where $h_{s}:=\text{{COMMIT}}(\bm{rp}_{s}),s\in e$ .
5. 5
  
  Every AA then needs to prove the knowledge of each element $s\in e$ by outputting the proofs $\{\pi_{s}\}$ using algorithm NIZK (Alg. 3) as the argument of function Prove of contract $SC_{sys}$ , which verifies them using algorithm VerifyNIZK (Alg. 4).
6. 6
  
  In the Round 1, we define one attribute authority AA as participant $P_{1}$ who firstly publishes group elements in $\mathbb{G}_{1}$ : $(V_{1}:=g_{1}^{\bm{A}_{1}},\theta_{V_{1}}:=g_{1}^{\alpha_{\bm{A}_{1}}},V_{1}^{\prime}:=g_{1}^{\alpha_{\bm{A}_{1}}\cdot\bm{A}_{1}})$ , based on the previously verified set of elements $e$ .
7. 7
  
  Participant $P_{i=2,\dots,n}$ computes $(V_{i},\theta_{V_{i}},V_{i}^{\prime})$ based on previous $(V_{i-1},\theta_{V_{i-1}},V_{i-1}^{\prime})$ using algorithm powerMult (Alg. 5) and publishes these as the arguments of the function Compute of contract $SC_{sys}$ to check validity.
8. 8
  
  We define the last valid $V$ received by contract $SC_{sys}$ as one piece of the public parameter $g_{1}^{\bm{A}}$ .
9. 9
  
  In the Round 2, the first AA, also known as participant $P_{1}$ , publishes group elements in $\mathbb{G}_{1}$ : $(W_{1}:=((g_{1}^{\bm{A}})^{\intercal})^{\bm{U}_{1}},\theta_{W_{1}}:=g_{1}^{\alpha_{\bm{U}_{1}}},W_{1}^{\prime}:=((g_{1}^{\bm{A}})^{\intercal})^{\alpha_{\bm{U}_{1}}\bm{U}_{1}})$ , also based on the previously verified set of elements $e$ .
10. 10
  
  Participant $P_{i}$ , where $i=2,\dots,n$ computes its $(W_{i},\theta_{W_{i}}^{\prime},W_{i}^{\prime})$ based on previous $(W_{i-1},\theta_{W_{i-1}}^{\prime},W_{i-1}^{\prime})$ using algorithm powerMult and publishes these as the arguments of the function Generate.
11. 11
  
  We also define the last valid $W$ received by contract $SC_{sys}$ as last piece of the public parameter $g_{1}^{\bm{U}^{\intercal}\bm{A}}$ . Therefore, we have $PP_{ABE}:=\{g_{1},g_{2},g_{1}^{\bm{A}},g_{1}^{\bm{U}^{\intercal}\bm{A}}\}$ .
2.
Authority Setup
1. 1
  
  $\textit{AA}_{\text{trust}}$ deploys contract $SC_{auth}$ for authority setup.
2. 2
  
  Each AA randomly samples another set of secret element $e^{\prime}$ : a matrix $\bm{X}\in\mathbb{Z}_{p}^{(k+1)\times(k+1)}$ , a vector $\bm{\tau}\in\mathbb{Z}_{p}^{k+1}$ , two numbers $\sigma,z\in\mathbb{Z}_{p}^{*}$ , a scalar $\alpha_{z}$ and a scaled number $\alpha_{z}\cdot z$ . Using that, AA takes $SK:=\{\bm{X},\bm{\tau},\sigma\}$ as secret keys, and publishes a corresponding set of s-pair $\{\bm{rp}_{\bm{X}},\bm{rp}_{\bm{\tau}},\bm{rp}_{\sigma},\bm{rp}_{z},\bm{rp}_{\alpha_{z}\cdot z}\}$ to the contract $SC_{auth}$ .
3. 3
  
  After that, AA computes and publishes the commitment $h^{\prime}:=\text{{COMMIT}}(\{h_{s}\}||)$ to $SC_{auth}$ , where $h_{s}:=\text{{COMMIT}}(\bm{rp}_{s}),s\in e^{\prime}$ .
4. 4
  
  Every AA then needs to prove the knowledge of elements $s\in e^{\prime}$ by generating the proofs $\{\pi_{s}\}$ using algorithm NIZK as the argument of function Prove of contract $SC_{auth}$ for validity check.
5. 5
  
  We define each AA with index $i\in[n-1]$ based on the receiving order of the complete set of valid $\{\pi_{s}\}_{s\in e^{\prime}}$ and set attribute authority $\textit{AA}_{\text{trust}}$ with index $n$ .
6. 6
  
  Therefore, we have the verified sets of elements $PK_{i}:=\{g_{1}^{\bm{X}_{i}^{\intercal}\cdot\bm{A}},\hat{e}(g_{1}^{\bm{\tau}_{i}^{\intercal}\bm{A}},g_{2}),g_{2}^{\sigma}\}$ and $\{o_{i}:=g_{1}^{z_{i}},g_{1}^{\alpha_{z_{i}}},g_{1}^{\alpha_{z_{i}}\cdot z_{i}}\}$ for each $AA_{i}$ .
7. 7
  
  In the last stage, for each $i,j\in[n],j\neq i$ , $AA_{i}$ needs to compute a set of group elements in $\mathbb{G}_{1}:(O_{i}:=\{(o_{j})^{z_{i}}\},\theta_{O_{i}}:=\{(g_{1}^{\alpha_{z_{j}}})^{\alpha_{z_{i}}}\},O^{\prime}_{i}:=\{(g_{1}^{\alpha_{z_{j}}\cdot z_{j}})^{\alpha_{z_{i}}\cdot z_{i}}\}$ . Then $AA_{i}$ publishes these elements, with the number of supported attributes $l_{i}$ as the argument of the function Setup.
8. 8
  
  The contract $SC_{auth}$ checks the validity of these elements published by $AA_{i},i\in[n]$ and then registers its address $addr_{i}$ with the elements $(l_{i},PK_{i})$ .
9. 9
  
  In the end, we have $PP_{VC}:=\{g_{1},g_{2},\{o_{i}\}_{i\in[n]},\{o_{i,j}\}_{i,j\in[n],i\neq j}\}$ for vector commitment scheme.
3.

Data User Registration
1. 1
  
  $\textit{AA}_{\text{trust}}$ deploys contract $SC_{reg}$ for service registration.
2. 2
  
  Data User (DU) makes a direct registration payment to the contract $SC_{reg}$ to get the global identifier $GID$ which is the hash value of DU’s address $addr$ .
3. 3
  
  Afterwards, DU can setup a secure channel with each $AA_{i},i\in[n]$ that possesses the needed attributes and can verify DU’s identity.
4. 4
  
  $AA_{i}$ verifies DU’s identity and sends back the set of acknowledged attributes $\mathcal{R}_{i,GID}$ through the secure channel.
5. 5
  
  Upon receiving all the $\mathcal{R}_{i,GID}$ from $AA_{i}$ , DU defines a set of ‘N/A’ attributes $\mathcal{R}_{j,GID}$ for those $AA_{j},i\neq j$ can not issue the attribute set and finally gets a complete set of attributes $\mathcal{R}_{GID}$ by combing $\mathcal{R}_{i,GID}$ and $\mathcal{R}_{j,GID}$ together.
4.

Key Gen
1. 1
  
  DU generates an attribute vector $\bm{v}_{GID}$ from set of attributes $\mathcal{R}_{GID}$ , creates a vector commitment $\bm{C}$ for $\bm{v}_{GID}$ and sends it with opening proof $op_{i}$ to each $AA_{i},i\in[n]$ through separate secure channels.
2. 2
  
  $AA_{i},i\in[n]$ firstly checks the validity of its responsible part in the commitment $\bm{C}$ using $op_{i}$ , then issues DU’s requested attribute secret key $sk_{i,GID,\bm{C}}$ , and finally sends it back to DU through the channel.
3. 3
  
  Upon receiving responses from each $AA_{i},i\in[n]$ , DU gets a complete set of secret keys $\{sk_{i,GID,\bm{C}}\}_{i\in[n]}$ .
5.
Encryption and Upload
1. 1
  
  $\textit{AA}_{\text{trust}}$ deploys last system contract $SC_{log}$ to record encrypted related information of file $F$
2. 2
  
  Data Owner (DO) randomly samples an AES key $AK$ , encrypts $F$ to obtain the ciphertext $CT_{F}$ , and uploads it to the IPFS network.
3. 3
  
  After successfully receiving the $CT_{F}$ from DO, IPFS network returns a special hash value $loc$ as a file location on the IPFS network.
4. 4
  
  Then, DO constructs a metadata $M:=(K,loc)$ , specifies a policy vector $\bm{x}$ based on selected attributes from each $AA_{i}$ , uses published $\{PK_{i}\}$ to encrypt the metadata $M$ and publishes this encrypted information $CT_{M}$ to contract $SC_{log}$ .
6.
Download and Decryption
1. 1
  
  DU reads every new coming $CT_{M}$ from the contract $SC_{log}$ and checks if its owned secret keys $\{sk_{i,GID,\mathbf{C}}\}_{i\in[n]}$ satisfies the access policy $\bm{x}$ to recover the metadata $M$ .
2. 2
  
  DU retrieves the file location $loc$ and AES key $AK$ from the metadata $M$ and requests the ciphertext $CT_{F}$ from the IPFS network with the file location $loc$ .
3. 3
  
  DU uses the AES key $AK$ to recover the original file $F$ .

V System Design

In this section, we provide more details on Trusted Setup, Authority Setup, Data User Registration, Key Generation, Encryption and Upload, and Download and Decryption processes.

V-A Trusted Setup

The process of Trusted Setup consists of 4 stages: Initiate, Commit and Reveal, Verify, and Generate, and finally outputs the global public parameter $PP_{ABE}$ for the ABE system.

In the initial three stages, each attribute authority AA sends its transactions independently to the contract $SC_{sys}$ . In contrast, during the final Generate stage, each participant $P$ (where we use the placeholder notation $P$ in Commit and Reveal to represent each AA) must send transactions to $SC_{sys}$ in a sequential manner. This sequentiality is necessary because each incoming transaction is generated based on the preceding $P$ ’s transaction received by contract $SC_{sys}$ .

V-A1 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 $\textit{AA}_{\text{trust}}$ . $\textit{AA}_{\text{trust}}$ represents this community to set the global security parameter to be $\lambda$ and the generators of the $\mathbb{G}_{1},\mathbb{G}_{2}$ with prime order $p$ to be $g_{1},g_{2}$ respectively. Therefore, the bilinear map can be $\hat{e}:\mathbb{G}_{1}\setminus\{0\}\times\mathbb{G}_{2}\setminus\{0\}\rightarrow\mathbb{G}_{T}$ .

$\textit{AA}_{\text{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. $\textit{AA}_{\text{trust}}$ also specifies the deadlines $(ddl_{1},ddl_{2},ddl_{3})$ for the process Trusted Setup and sets an authorized list $AAlist$ to restrict $SC_{sys}$ access. For a simple description of the system, we assume that each attribute authority AA submits the required transactions within the deadlines. The pseudo codes of these two contracts are provided in Appendix VIII-A and VIII-D, respectively.

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}$ . Some variables used here are listed below:

1.

$msg.sender$ (Global Variable): The sender of the message or transaction.
2.

$block.timestamp$ (Global Variable): The current block timestamp as seconds.
3.

$AAlist$ (State Variable): A list of pre-verified blockchain addresses belonging to attribute authorities set by a trusted authority.
4.

$ddl_{1}$ (State Variable): A deadline that only allows transaction calls within the pre-set time window for the stage Commit and Reveal.
5.

$ddl_{2}$ (State Variable): A deadline that only allows transaction calls within the pre-set time window for the stage Verify.
6.

$ddl_{3}$ (State Variable): A deadline that only allows transaction calls within the pre-set time window for the stage Compute and Generate.

V-A2 Commit and Reveal

Every AA randomly picks a set of elements $e$ : a matrix $\bm{A}\xleftarrow{\$}\{\text{Diagonal matrices in }\mathbb{Z}_{p}^{k\times k}\}\cup\begin{pmatrix}\mathbf{1}\end{pmatrix}$ , a matrix $\bm{U}\xleftarrow{\$}\mathbb{Z}_{p}^{(k+1)\times(k+1)}$ ¹¹1The value of $k$ in this context does not derive from the security parameter $\lambda$ . Rather, it is a reference to the k-Lin assumption 2 upon which our construction is predicated., their corresponding scalar values, $\alpha_{\bm{A}}$ and $\alpha_{\bm{U}}$ , and scaled matrixes $\alpha_{\bm{A}}\cdot\bm{A},\alpha_{\bm{U}}\cdot\bm{U}$ .

Then, AA has

e=\{\bm{A},\bm{U},\alpha_{\bm{A}},\alpha_{\bm{U}},\alpha_{\bm{A}}\cdot\bm{A},\alpha_{\bm{U}}\cdot\bm{U}\}

(3)

and then generates a set of s-pair.

For such element $s\in e$ , we refer to the s-pair in $\mathbb{G}_{1}$ by $\bm{rp}_{s}$ and in $\mathbb{G}_{2}$ by $\bm{rp}_{s}^{2}$ as Definition 2. These s-pair in both $\mathbb{G}_{1}$ and $\mathbb{G}_{2}$ are listed as follows:

•

For matrix $\bm{A}$ : $(\bm{rp_{\bm{A}}},\bm{rp_{\bm{A}}}^{2})=(g,g^{\bm{A}})$
•

For matrix $\bm{U}$ : $(\bm{rp_{\bm{U}}},\bm{rp_{\bm{U}}}^{2})=(g^{\bm{A}^{\intercal}},g^{\bm{A}^{\intercal}\bm{U}})$
•

For scalar $\alpha_{\bm{A}}$ : $(\bm{rp}_{\alpha_{\bm{A}}},\bm{rp}_{\alpha_{\bm{A}}}^{2})=(g,g^{\alpha_{\bm{A}}})$
•

For scalar $\alpha_{\bm{U}}$ : $(\bm{rp}_{\alpha_{\bm{U}}},\bm{rp}_{\alpha_{\bm{U}}}^{2})=(g,g^{\alpha_{\bm{U}}})$
•

For scaled matrix $\alpha_{\bm{A}}\bm{A}$ : $(\bm{rp}_{\alpha_{\bm{A}}\bm{A}},\bm{rp}_{\alpha_{\bm{A}}\bm{A}}^{2})=(g,g^{\alpha_{\bm{A}}\cdot\bm{A}})$
•

For scaled matrix $\alpha_{\bm{U}}\bm{U}$ : $(\bm{rp}_{\alpha_{\bm{U}}\bm{U}},\bm{rp}_{\alpha_{\bm{U}}\bm{U}}^{2})=(g^{\bm{A}^{\intercal}},g^{\alpha_{\bm{U}}\cdot\bm{A}^{\intercal}\bm{U}})$

Other than these s-pair listed above, AA also commits each element $s\in e$ using Algorithm 1. For each $s\in e$ :

h_{s}:=\textsc{COMMIT}(\bm{rp}_{s}||\bm{rp}_{s}^{2})

Subsequently, the overall commitment is:

h:=\textsc{COMMIT}(h_{\bm{A}}||h_{\bm{U}}||h_{\bm{\alpha_{\bm{A}}}}||h_{\alpha_{\bm{U}}}||h_{\alpha_{\bm{A}}\bm{A}}||h_{\alpha_{\bm{U}}\bm{U}})

(4)

After that, AA publishes the commitment $h$ to the contract $SC_{sys}$ through blockchain transaction. The state variable $h\_collector$ of $SC_{sys}$ (Algorithm 7) 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-pairs $L=\{(\bm{rp}_{s},\bm{rp}_{s}^{2})|s\in e\}$ in both $\mathbb{G}_{1}$ and $\mathbb{G}_{2}$
3.

$verified\_elements$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its verified list of s-pairs $L=\{(\bm{rp}_{s},\bm{rp}_{s}^{2})|s\in e\}$ in both $\mathbb{G}_{1}$ and $\mathbb{G}_{2}$

After $h$ has been received by contract $SC_{sys}$ , the sender needs to reveal committed element $s\in e$ by passing a list of s-pair in both $\mathbb{G}_{1}$ and $\mathbb{G}_{2}$

L_{rp}=\{(\bm{rp}_{s},\bm{rp}_{s}^{2})|s\in e\}

(5)

as argument of the function Reveal (Algorithm 8) before deadline $ddl_{1}$ , which checks the existence of the $h$ published by $msg.sender$ , and then verify that indeed $h=\textsc{COMMIT}(\{h_{s}\}||)$ ²²2For brevity, we will use this shorthand notation to represent the above concatenation where $s$ takes on all value in the set $e=\{\bm{A},\bm{U},\alpha_{\bm{A}},\alpha_{\bm{U}},\alpha_{\bm{A}}\bm{A},\alpha_{\bm{U}}\bm{U}\}$ by using the utility function Hash (Algorithm 17), which works similarly as Algorithm 1. Finally, each pair $(\bm{rp}_{s},\bm{rp}_{s}^{2}),s\in e$ will be stored in another state variable $unverified\_elements$ with the key as $msg.sender$ .

V-A3 Verify

After deadline $ddl_{1}$ set by $\textit{AA}_{\text{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 $\pi_{s}:=\textsc{NIZK}(\bm{rp}_{s},h||h_{s})$ using Algorithm 3 for each $s\in e$ , and broadcasts these proofs as a list

L_{\pi}=\{\pi_{\bm{A}},\pi_{\bm{U}},\pi_{\alpha_{\bm{A}}},\pi_{\alpha_{\bm{U}}},\pi_{\alpha_{\bm{A}}\cdot\bm{A}},\pi_{\alpha_{\bm{U}}\cdot\bm{U}}\}

(6)

through a blockchain transaction to get them verified. The function Prove (Algorithm 9) from contract $SC_{sys}$ takes input $L_{\pi}$ and processes this verification works.

The function Prove firstly calls function SameRatio of contract $SC_{util}$ (Algorithm 18) similar as Algorithm 2 to examine the authenticity of the published $\bm{rp}_{s}$ and $\bm{rp}_{s}^{2}$ . Afterwards, it computes $h_{tmp}:=h||\textsc{COMMIT}(\bm{rp}_{s})$ , and takes $h_{tmp}$ with verified $\bm{rp}_{s}$ and provided $\pi_{s}$ as input to the function CheckPoK of contract $SC_{util}$ (Algorithm 19), which works similarly as Algorithm 4 and returns true if the given proof $\pi_{s}$ is valid. Finally, the function Prove 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.

V-A4 Compute and Generate

In this stage, the system will generate the public parameters for the attribute-based encryption in two rounds. We use below notation powerMulti $(A,B)$ for the following algorithm 5:

Algorithm 5 Computing power matrix

A

by matrix

B

1:group elements

A

and matrix

s

have same size

l\times k

2:function powerMulti(

A,s

)

3: for

i\leftarrow 1,l

4: for

j\leftarrow 1,k

B[i,j]\leftarrow A[i,j]^{s[i,j]}

6: end for

7: end for

8: return

B

9:end function

Round 1: We define the first attribute authority AA as participant $P_{1}$ , who broadcasts $(V_{1},\theta_{V_{1}},V_{1}^{\prime})$ as argument of function Compute in contract $SC_{sys}$ (Algorithm 10). The elements $(V_{1},\theta_{V_{1}},V_{1}^{\prime})$ are constructed as follows:

	$\displaystyle V_{1}$	$\displaystyle:=g_{1}^{\bm{A}_{1}}$
	$\displaystyle\theta_{V_{1}}$	$\displaystyle:=g_{1}^{\alpha_{\bm{A}_{1}}}$
	$\displaystyle V_{1}^{\prime}$	$\displaystyle:=g_{1}^{\alpha_{\bm{A}_{1}}\cdot\bm{A}_{1}}$

And the next participant $P_{i},i=2,3,\dots,n$ , generates corresponding elements $(V_{i},\theta_{V_{i}},V_{i}^{\prime})$ using Algorithm 5, and also broadcasts them to the contract $SC_{sys}$ :

	$\displaystyle V_{i}$	$\displaystyle:=\textsc{powerMulti}(V_{i-1},\bm{A}_{i})$
	$\displaystyle\theta_{V_{i}}$	$\displaystyle:=(\theta_{V_{i-1}})^{\alpha_{\bm{A}_{i}}}$
	$\displaystyle V_{i}^{\prime}$	$\displaystyle:=\textsc{powerMulti}(V_{i-1}^{\prime},\alpha_{\bm{A}_{i}}\bm{A}_{i})$

Since receiving the elements $(V_{1},\theta_{1},V_{1}^{\prime})$ from first participant $P_{1}$ , function Computer of $SC_{sys}$ checks the validity of each incoming elements $(V_{i},\theta_{V_{i}},V_{i}^{\prime})$ published by $P_{i}$ .

In the end, we define the last valid $V_{i}$ as one piece of the public parameter:

g_{1}^{\bm{A}}=\textsc{powerMulti}(\textsc{powerMulti}(\dots(\\ \textsc{powerMulti}(\textsc{powerMulti}(g_{1}^{\bm{A}_{1}},\bm{A}_{2}),\bm{A}_{3})\dots,\bm{A}_{n})

Round 2: In this round, we also define the first attribute authority AA as participant $P_{1}$ , who broadcasts $(W_{1},\theta_{1}^{\prime},W_{1}^{\prime})$ as argument of the function Generate in contract $SC_{sys}$ (Algorithm 11). The elements $(W_{1},\theta_{1}^{\prime},W_{1}^{\prime})$ are constructed as follows:

	$\displaystyle W_{1}$	$\displaystyle:=((g_{1}^{\bm{A}})^{\intercal})^{\bm{U}_{1}}$
	$\displaystyle\theta_{1}^{\prime}$	$\displaystyle:=g_{1}^{\alpha_{\bm{U}_{1}}}$
	$\displaystyle W_{1}^{\prime}$	$\displaystyle:=((g_{1}^{\bm{A}})^{\intercal})^{\alpha_{\bm{U}_{1}}\bm{U}_{1}}$

And the next participant $P_{i}$ where $i=2,3,\dots,n$ , generates corresponding elements $(W_{i},\theta_{W_{i}},W_{i}^{\prime})$ using Algorithm 5, and also broadcasts them to the contract $SC_{sys}$ :

	$\displaystyle W_{i}$	$\displaystyle:=\textsc{powerMulti}(W_{i-1},\bm{U}_{i})$
	$\displaystyle\theta_{W,i}$	$\displaystyle:=(\theta_{W_{i-1}})^{\alpha_{\bm{U},i}}$
	$\displaystyle W_{i}^{\prime}$	$\displaystyle:=\textsc{powerMulti}(W_{i-1}^{\prime},\alpha_{\bm{U},i}\bm{U}_{i})$

Invoked by these transactions, contract $SC_{sys}$ checks the validity of each received elements $(W_{i},\theta_{W_{i}},W_{i}^{\prime})$ 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}^{\bm{U}^{\intercal}\bm{A}}=W_{n}=\textsc{PowerMulti}(\textsc{PowerMulti}(\dots(\\ \textsc{PowerMulti}(\textsc{PowerMulti}(((g_{1}^{\bm{A}})^{\intercal})^{\bm{U}_{1}},\bm{U}_{2}),\dots,\bm{U}_{n}))))^{\intercal}

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.

PP_{ABE}:=\{g_{1},g_{2},g_{1}^{\bm{A}},g_{1}^{\bm{U}^{\intercal}\bm{A}}\}

(7)

V-B Authority Setup

This step consists of 3 stages: Commit and Reveal, Verify, and Generate, and finally outputs another global public parameter $PP_{VC}$ and public key $PK$ for each attribute authority AA.

V-B1 Initiate

The contract $SC_{auth}$ deployed by trusted authority $\textit{AA}_{\text{trust}}$ has 4 main functions, Commit, Reveal, Prove and Generate, which also interacts with utility function $SC_{util}$ . Its accessibility is also limited by deadlines $(ddl_{1}^{\prime},ddl_{2}^{\prime},ddl_{3}^{\prime})$ and the authorized list $AAlist$ set by $\textit{AA}_{\text{trust}}$ . The pseudo-code of contract $SC_{auth}$ is provided in Appendix VIII-B.

V-B2 Commit and Reveal

Every AA firstly samples a set of elements $e^{\prime}$ : a matrix $\bm{X}\xleftarrow{\$}\mathbb{Z}_{p}^{(k+1)\times(k+1)}$ , a vector $\bm{\tau}\xleftarrow{\$}\mathbb{Z}_{p}^{k+1}$ , two secret elements $\sigma,z\in\mathbb{Z}_{p}^{*}$ , a scalar $\alpha_{z}$ and a scaled element $\alpha_{z}\cdot z$ .

Therefore, the AA defines a set $e^{\prime}$ for vector commitment as:

e^{\prime}:=\{z,\alpha_{z},\alpha_{z}\cdot z\}

and also designates:

SK:=\{\bm{X},\bm{\tau},\sigma\}

as the secret key. Then, AA computes a set of s-pair for each element $s$ in both $e^{\prime}$ and $SK$ . We refer to the s-pair in $\mathbb{G}_{1}$ by $\bm{rp}_{s}$ , and the s-pair in $\mathbb{G}_{2}$ by $\bm{rp}_{s}^{2}$ as Definition 2. These s-pair are defined as follows:

•

For matrix $\bm{X}^{\intercal}:\bm{rp}_{\bm{X}}:=(g_{1}^{\bm{A}},g_{1}^{\bm{X}^{\intercal}\cdot\bm{A}})$
•

For vector $\bm{\tau}^{\intercal}:\bm{rp}_{\bm{\tau}}:=(g_{1}^{\bm{A}},g_{1}^{\bm{\tau}^{\intercal}\bm{A}})$
•

For element $\sigma:\bm{rp}^{2}_{\sigma}:=(g_{2},g_{2}^{\sigma})$
•

For element $z:(\bm{rp}_{z},\bm{rp}^{2}_{z})=(g,g^{z})$
•

For scalar $\alpha_{z}$ : $(\bm{rp}_{\alpha_{z}},\bm{rp}^{2}_{\alpha_{z}})=(g,g^{\alpha_{z}})$
•

For scaled element $\alpha_{z}z$ : $(\bm{rp}_{\alpha_{z}z},\bm{rp}^{2}_{\alpha_{z}z})=(g,g^{\alpha_{z}\cdot z})$

After that, AA computes $h^{\prime}$ using Algorithm 1 as follows:

\begin{gathered}h_{\bm{X}}:=\textsc{COMMIT}(\bm{rp}_{\bm{X}})\quad h_{\bm{\tau}}:=\textsc{COMMIT}(\bm{rp}_{\bm{\tau}})\\ h_{\sigma}:=\textsc{COMMIT}(\bm{rp}^{2}_{\sigma})\quad h_{z}:=\textsc{COMMIT}(\bm{rp}_{z}||\bm{rp}_{z}^{2})\\ h_{\alpha_{z}}:=\textsc{COMMIT}(\bm{rp}_{\alpha_{z}}||\bm{rp}_{\alpha_{z}}^{2})\\ h_{\alpha_{z}\cdot z}:=\textsc{COMMIT}(\bm{rp}_{\alpha_{z}\cdot z}||\bm{rp}_{\alpha_{z}\cdot z}^{2})\\ h^{\prime}:=\textsc{COMMIT}(h_{\bm{X}}||h_{\bm{\tau}}||h_{\sigma}||h_{z}||h_{\alpha_{z}}||h_{\alpha_{z}\cdot z})\end{gathered}

(8)

and broadcasts it to the contract $SC_{auth}$ through blockchain transaction as the argument of the function Commit (Algorithm 12), which will store the value $h^{\prime}$ into state variable $h\_collector$ if the transaction is valid. Apart from $h\_collector$ , several other state variables are defined in the contract $SC_{auth}$ , described as follows:

1.

$h\_collector$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority $\bm{AA}$ to its commitment $h^{\prime}$
2.

$unverified\_sk$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority $\bm{AA}$ to its list of unverified elements $SK$
3.

$unverified\_elements$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority $\bm{AA}$ to its list of unverified group elements $e^{\prime}$ in both $\mathbb{G}_{1}$ and $\mathbb{G}_{2}$

After $h^{\prime}$ recorded by contract $SC_{auth}$ , AA needs to reveal each committed element by passing two lists of s-pair

	$\displaystyle L_{sk}$	$\displaystyle=\{\bm{rp}_{\bm{X}},\bm{rp}_{\bm{\tau}},\bm{rp}^{2}_{\sigma}\}$		(9)
	$\displaystyle L_{e^{\prime}}$	$\displaystyle=\{(\bm{rp}_{s},\bm{rp}_{s}^{2})\|s\in e^{\prime}\}$		(10)

as arguments of the function Reveal (Algorithm 13), which computes the hash result of $L_{sk}$ and $L_{vc}$ using utility contract $SC_{util}$ (Algorithm 17), 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.

V-B3 Verify

The system enters into the stage Verify after $ddl_{1}^{\prime}$ set by trusted authority $\textit{AA}_{\text{trust}}$ .

First of all, attribute authority AA generates the proof $\pi_{s}:=\textsc{NIZK}(\bm{rp}_{s},h||h_{s})$ for each $s$ in both $e^{\prime}$ and $SK$ , and broadcast these proofs $\{\pi\}$ as a list

L_{\pi}^{\prime}=\{\pi_{z},\pi_{\alpha_{z}},\pi_{\alpha_{z}z},\pi_{\bm{X}},\pi_{\bm{\tau}},\pi_{\bm{\sigma}}\}

(11)

through transaction before deadline $ddl_{2}^{\prime}$ . The function Prove of contract $SC_{auth}$ (Algorithm 14) takes input $L_{\pi}^{\prime}$ as the argument. It checks the validity of these proofs by using utility functions SameRatio and CheckPoK of contract $SC_{utils}$ (Algorithm 18 and 19).

We assign each AA an index $i\in[n-1]$ , based on the order in which $SC_{auth}$ receives the complete set of valid published proofs $\{\pi\}$ . The trusted authority, denoted as $\textit{AA}_{\text{trust}}$ , is assigned the index $n$ .

At the end of this stage, we have the verified elements $PK_{i}=(g_{1}^{\bm{X}_{i}^{\intercal}\bm{A}},\hat{e}(g_{1},g_{2})^{\bm{\tau}_{i}^{\intercal}\bm{A}},g_{2}^{\sigma})$ and $\{o_{i}:=g_{1}^{z_{i}},g_{1}^{\alpha_{z_{i}}},g_{1}^{\alpha_{z_{i}}z_{i}}\}$ for each $\textit{AA}_{i}$ .

V-B4 Generate

In the last stage Generate, $\textit{AA}_{i}$ needs to generate a set of group elements $(O,\theta_{O},O^{\prime})$ , selects a reasonable number of supported attributes $l_{i}$ , and broadcasts them to contract $SC_{auth}$ before the deadline $ddl_{3}^{\prime}$ .

The elements $(O,\theta_{O},O^{\prime})$ provided by $\textit{AA}_{i}$ are constructed as follows:

	$\displaystyle O_{i}$	$\displaystyle:=o_{i,j}=\{(o_{j})^{z_{i}}\}_{i\neq j,j\in[n]}$
	$\displaystyle\theta_{O_{i}}$	$\displaystyle:=\{(g_{1}^{\alpha_{z_{j}}})^{\alpha_{z_{i}}}\}_{i\neq j,j\in[n]}$
	$\displaystyle O^{\prime}_{i}$	$\displaystyle:=\{(g_{1}^{\alpha_{z_{j}}z_{j}})^{\alpha_{z_{i}}z_{i}}\}_{i\neq j,j\in[n]}$

Invoked by this transaction, function Generate of $SC_{auth}$ (Algorithm 15) firstly checks the validity of elements $(O_{i},\theta_{O_{i}},O^{\prime}_{i})$ and the value of $l_{i}$ , and then records $\textit{AA}_{i}$ ’s blockchain address $addr$ with the claimed attribute size $l_{i}$ . For example, if $\textit{AA}_{i}$ owns the set of attributes $\{entry,mid,senior,agent,manager\}$ , the value of attribute size $l_{i}$ is $5$ .

TABLE III: A example of address-AA-attribute vector Mapping Table

Address	$addr_{1}$		$addr_{2}$	……	$addr_{n-1}$		$addr_{n}$
Attribute Authority	$\textit{AA}_{1}$		$\textit{AA}_{2}$	……	$\textit{AA}_{n-1}$		$\textit{AA}_{\text{trust}}$
Attribute Representation	$v_{1}$	$v_{2}$	$v_{3}$	……	$v_{l-1}$	$v_{l}$	$v_{l+1}$

After the contract $SC_{auth}$ receives all the pairs $\{o_{i},o_{i,j},l_{i}\}$ from $\textit{AA}_{i}\in\{\textit{AA}_{1},\textit{AA}_{2},...,\textit{AA}_{n}\}$ , every Service User (SU) can get the global parameter for the vector commitment system

PP_{VC}:=\{g_{1},g_{2},\{o_{i}\}_{i\in[n]},\{o_{i,j}\}_{i,j\in[n],i\neq j}\}

(12)

and generate a mapping table that maps each blockchain address of $\textit{AA}_{i}$ to its corresponding information as shown in Table III. We use $l$ to represent the size of complete supported attributes set $\mathcal{X}$ and $v$ to represent the owned attributes for each AA.

V-C Data User Registration

To get the global identifier $GID$ which will be used in the process of Key Generation, the data user (DU) needs to register the owned address $addr_{DU}$ by calling the function user_register of the contract $SC_{REG}$ (Algorithm 16).

DU needs to send predefined amount of GWEI to the contract $SC_{REG}$ as the registration fee payment. This amount defaults to 1000000 GWEI, which is approximately equivalent to 1.63 USD as of September 2023. In return, DU receives a value $GID$ , which is the hash value of DU’s address $addr_{DU}$ , also known as the $msg.sender$ of this transaction call.

Following that, DU establishes a secure channel or employs some off-chain methods with $\textit{AA}_{i}$ that have the required attributes and can verify DU’s identity. We assume that DU is an agent for one insurance company, and the company itself runs the consensus node of $\textit{AA}_{i}$ in this system. Therefore, DU may easily get verified by showing an ID badge to the person who manages the $\textit{AA}_{i}$ . DU then requests that $\textit{AA}_{i}$ issues a set of attributes $\mathcal{R}_{i,GID}$ in regards to DU’s identity. The format of a set of attributes might look like this: $(entry,N/A,N/A,agent,N/A)$ out of the full set of attributes $(entry,mid,senior,agent,manager)$ .

For those $\textit{AA}_{j},j\neq i$ that do not contain the needed attributes or cannot verify DU’s identity, DU may just set $\mathcal{R}_{j,GID}$ to be $(N/A,N/A,N/A)$ with $l_{j}=3$ .

Finally, DU receives $\mathcal{R}_{i,GID}$ from $\textit{AA}_{i}$ , sets $\mathcal{R}_{j,GID}$ for $\textit{AA}_{j},j\neq i$ , and combines them as the set of attributes $\mathcal{R}_{GID}$ which will be used in the process of Key Generation.

V-D Key Generation

Without loss of generality, we suppose that there are a total set of attributes $\mathcal{X}$ , indexed from 1 to $l$ and a total set of attributes authorities $\mathcal{U}$ including $\textit{AA}_{\text{trust}}$ , indexed from 1 to $n$ . Assume that the attribute authority $\textit{AA}_{i}$ has a subset of attributes $\mathcal{S}_{i}$ , then we have $\mathcal{S}_{i}\cap\mathcal{S}_{j}=\emptyset$ for $i\neq j$ and $i,j\in|n|$ and $\mathcal{S}_{1}\cup\mathcal{S}_{2}...\cup\mathcal{S}_{n}=\mathcal{X}$ .

To get the secret key $sk_{i,GID,\bm{C}}$ which is comprised of multiple key parts $\{K_{j,GID,\bm{C}}\}_{j\in\mathcal{S}_{i}}$ from $\textit{AA}_{i}$ , Data User (DU) must initially generate the attribute vector $\bm{v}_{GID}$ . This is based on $\mathcal{R}_{GID}$ that was acquired during the Data User Registration process.

Given that the DU’s set of attributes $\mathcal{R}_{i,GID}\in\mathcal{X}$ and the mapping Table III generated from the process Authority Setup, the attribute vector $\bm{v}_{GID}$ is set as follows:

1.

Set the first $l$ entries such that $v_{k}$ = $\begin{cases}1&i\in R_{GID}\\ 0&i\notin R_{GID}\\ \end{cases}$
2.

Set the $l+1$ entry to be 1. ( $\textit{AA}_{\text{trust}}$ is responsible for this entry)

Then, DU randomly chooses $r_{1},r_{2},...,r_{n}\xleftarrow{\$}\mathbb{Z}_{p}^{*}$ for each AA and combines the arguments $r_{i}$ with the attribute vector $\bm{v}_{i,GID}$ (represented as a bit string) to produce a committed value $m_{i}:=\textsc{COMMIT}(v_{i,1}||v_{i,2}\dots v_{i,j}||r_{i})$ , where $i\in[n],j\in[|\mathcal{S}_{i}|]$ .

TABLE IV: A example of

m

for Vector Commitment

Attribute Authority	$\textit{AA}_{1}$			$\textit{AA}_{2}$
Attributes	entry	mid	senior	agent	manager
Vector Element	$v_{1}$	$v_{2}$	$v_{3}$	$v_{4}$	$v_{5}$
Element Value	1	0	0	1	0
nonce	$r_{1}$			$r_{2}$
$m_{i}$	COMMIT( $v_{1}\|\|v_{2}\|\|v_{3}\|\|r_{1}$ )			COMMIT( $v_{4}\|\|v_{5}\|\|r_{2}$ )

In Table IV, for instance, we have two attribute authorities $\textit{AA}_{1}$ and $\textit{AA}_{2}$ that possess attributes (entry, mid, senior) and (agent, manager) respectively. If there is a data user DU with a set of attributes $\mathcal{R}=$ (entry, agent), DU’s attribute vector is $\bm{v}=(1,0,0,1,0)$ . For $\textit{AA}_{1}$ and $\textit{AA}_{2}$ , DU samples two random values $r_{1},r_{2}\xleftarrow{\$}\mathbb{Z}_{p}^{*}$ and then computes auxiliary information $\bm{aux}=(m_{1},m_{2})$ using COMMIT (Algorithm 1).

In general, based on the public parameter for vector commitment $PP_{VC}=\{g_{1},g_{2},\{o_{i}\}_{i\in[n]},\{o_{i,j}\}_{i,j\in[n],i\neq j}\}$ , generated in Authority Setup, DU can calculate the commitment $\bm{C}$ on the attribute vector $\bm{v}$ from its $\mathcal{R}$ :

\displaystyle\bm{C}:=o_{1}^{m_{1}}o_{2}^{m_{2}}\dots o_{n}^{m_{n}}

To request the secret key part $K_{j,GID,\bm{C}},j\in\mathcal{S}_{i}$ , DU establishes another secure channel with $\textit{AA}_{i}$ and sends commitment $C$ along with an opening $op_{i}$ and nonce $r_{i}$ . Such opening $op_{i}$ is calculated as follows:

op_{i}=\prod^{n}_{j=1,j\neq i}o_{i,j}^{m_{j}}=(\prod^{n}_{j=1,j\neq i}o_{j}^{m_{j}})^{z_{i}}

Based on the DU’s $GID$ , $\textit{AA}_{i}$ firstly retrieves the information of the set of attributes $\mathcal{R}_{i,GID}$ which have been issued in the previous process Data User Registration and then verifies commitment $\bm{C}$ using the opening $op_{i}$ and nonce $r_{i}$ received

\hat{e}(\bm{C}/o_{i}^{m_{i}^{\prime}},g_{2}^{z_{i}})\stackrel{{\scriptstyle?}}{{=}}\hat{e}(op_{i},g_{2})

where $m_{i}^{\prime}$ is the value calculated by the $\mathcal{R}_{i,GID}$ issued to DU. If the above check passes, $\textit{AA}_{i}$ uses a pre-defined random oracle $\mathcal{H}:\mathbb{G}_{2}\times\{0,1\}^{\lambda}\times\mathbb{Z}_{p}^{k+1}\rightarrow\mathbb{Z}_{p}^{k+1}$ to generate masking value $\bm{\mu_{i}}\in\mathbb{Z}_{p}^{*}$

\bm{\mu_{i}}=\sum_{j=1}^{i-1}\mathcal{H}(y_{j}^{\sigma_{i}},GID,\bm{C})-\sum_{j=i+1}^{n}\mathcal{H}(y_{j}^{\sigma_{i}},GID,\bm{C})

and hash functions $H_{1}(GID,\bm{C}),...,H_{k+1}(GID,\bm{C})$ to generate $g_{2}^{\bm{h}}$ where $\bm{h}\in\mathbb{Z}_{p}^{k+1}$

\bm{h}:H(GID,\bm{C})=(H_{1}(GID,\bm{C}),...,H_{k+1}(GID,\bm{C}))^{\intercal}

Finally, $\textit{AA}_{i}$ computes the secret keys

sk_{i,GID,\bm{C}}:=\{K_{j,GID,\bm{C}}\}_{j\in\mathcal{S}_{i}}

(13)

, which consists of key parts

K_{j,GID,\bm{C}}:=g_{2}^{\bm{\tau_{i}}-v_{j}\bm{X}_{i}\bm{h}+\bm{\mu_{i}}}

(14)

for each possessed attributes by $\textit{AA}_{i}$ and send $sk_{i,GID,\bm{C}}$ back to the DU through the secure channel.

To get the special secret key part $sk_{n,GID,\bm{C}}$ for the $l+1$ entry, DU also needs to communicate with trusted authority $\textit{AA}_{\text{trust}}$ and provides the commitment $\bm{C}$ with the opening $op_{n}$ and nonce $r_{n}$ through the secure channel. As shown in the Table III, $\textit{AA}_{\text{trust}}$ sets the $m_{n}^{\prime}$ to be COMMIT( $(v_{l+1}||r_{n})$ ) where $v_{l+1}=1$ and then checks the following equation

\hat{e}(\bm{C}/o_{n}^{m_{n}^{\prime}},g_{2}^{z_{n}})\stackrel{{\scriptstyle?}}{{=}}\hat{e}(op_{n},g_{2})

If it passes, $\textit{AA}_{\text{trust}}$ computes the secret key part similar as $sk_{i,GID,\bm{C}}$

sk_{n,GID,\bm{C}}:=K_{l+1}=g_{2}^{\bm{\tau_{n}}-v_{n}\bm{X}_{n}\bm{h}+\bm{\mu_{n}}}

(15)

and sends it back to DU.

Upon receiving all the responses from each $\textit{AA}_{i},i\in[n]$ , DU will finally gets a complete set of secret keys $\{sk_{i,GID,\bm{C}}\}_{i\in[n]}$ .

V-E Encryption and Upload

Given that Attribute-based Encryption (ABE) is significantly more expensive than symmetric key encryption[44], the files that the data owner (DO) wants to share are not directly encrypted with ABE. Instead, hybrid encryption of ABE and AES is used for efficiency.

First of all, DO randomly samples an AES key $AK$ from the key space and encrypts the file $F$ to be the ciphertext $CT_{F}$ .

Then, DO uploads the ciphertext $CT_{F}$ to IPFS and records the file location $loc$ returned by IPFS. The metadata message $M$ can then be constructed as:

M:=(K,loc)

Using the policy vector $\bm{x}$ discussed above, DO samples a random vector $\bm{s}\in\mathbb{Z}_{p}^{k}$ , generates a policy vector $\bm{x}:=(x_{1},x_{2},...,x_{n})\in\mathbb{Z}_{p}^{n}$ acting as the ciphertext policy, and outputs the ciphertext $CT_{M}$ consisting of

	$\displaystyle ct_{0}=g_{1}^{\bm{As}}$		(16)
	$\displaystyle ct_{i}=g_{1}^{(x_{i}\bm{U}^{\intercal}+\bm{X}_{i}^{\intercal})\bm{As}}$		(17)
	$\displaystyle ct^{\prime}=M\cdot\hat{e}(g_{1},g_{2})^{\bm{\tau}^{\intercal}\bm{As}}$		(18)

, where $\bm{\tau}=\sum_{i=1}^{n}\bm{\tau}_{i}$ .

Lastly, the ciphertext $CT_{M}$ is sent to the contract $SC_{log}$ with the optional keyword $kw$ that may ease the data retrieval process. The contract $SC_{log}$ will emit this new uploading information to the subscribers as follows:

Algorithm 6 Data Sharing

msg.sender==DO

2:function log(

ct,kw

)

Log.add(ct,kw)

4: emit Log

(ct,kw)

5:end function

7:function get(

index

)

8: if

index==-1

then

9: return

Log

10: end if

11: if

index

is valid then

12: return

Log[index]

13: end if

14:end function

V-F Download and Decryption

As Algorithm 6 shows, all the encrypted metadata $CT_{M}$ will be recorded sequentially. If the Data User (DU) is interested in one of DO’s files, DU may subscribe to the event created by the contract $SC_{log}$ and call the Function GET (Algorithm 6) to obtain the encrypted metadata $CT_{M}$ .

To decrypt the ciphertext $CT_{M}$ , DU computes

\hat{e}(ct_{0},\prod_{j=1}^{l+1}K_{j})\cdot\hat{e}(\prod ct_{i}^{v_{i}},\bm{h})=\hat{e}(g_{1},g_{2})^{\bm{\tau^{\intercal}As}}

and tries to recover the message

ct^{\prime}/\hat{e}(g_{1},g_{2})^{\bm{\tau^{\intercal}As}}=M^{\prime}

(19)

If DU’s attribute vector $\bm{v}$ satisfies the policy vector $\bm{x}$ selected by DO, DU can retrieve the AES key $AK$ and file location $loc$ from the metadata $M$ . Finally, DU downloads the encrypted file $CT_{F}$ from the IPFS based on the location $loc$ , and uses $AK$ to decrypt $CT_{F}$ to recover the original file $F$ .

Correctness. Since $CT_{M}=(ct_{0},\{ct_{i}\}^{n}_{i=1},ct^{\prime})$ , $\{sk_{i,GID,\bm{C}}=\{K_{j}\}_{j\in\mathcal{R}_{i}}\}$ and $n=l+1$ , we can compute

	$\displaystyle\hat{e}(ct_{0},\prod_{j=1}^{l+1}K_{j})\cdot\hat{e}(\prod_{i=1}^{n}ct_{i}^{v_{i}},\bm{H}(GID,\bm{C}))$
	$\displaystyle=\hat{e}(g_{1}^{\bm{As}},g_{2}^{\sum^{n}_{i=1}\bm{\tau}_{i}-v_{i}\bm{X_{i}h+\mu_{i}}})$
	$\displaystyle\cdot\hat{e}(g_{1}^{\sum^{n}_{i=1}v_{i}(x_{i}\bm{U}^{\intercal}+\bm{X}_{i}^{\intercal})\bm{As}},g_{2}^{\bm{h}})$
	$\displaystyle=\hat{e}(g_{1},g_{2})^{\bm{\tau}^{\intercal}\bm{As}-\sum^{n}_{i=1}v_{i}\bm{h}^{\intercal}\bm{X}_{i}^{\intercal}\bm{As}}$
	$\displaystyle\cdot\hat{e}(g_{1},g_{2})^{\bm{<x,v>h^{\intercal}U^{\intercal}As}+\sum^{n}_{i=1}v_{i}\bm{h^{\intercal}X_{i}^{\intercal}As}}$
	$\displaystyle=\hat{e}(g_{1},g_{2})^{\bm{\tau}^{\intercal}\bm{As}}\cdot\hat{e}(g_{1},g_{2})^{\bm{<x,v>h^{\intercal}U^{\intercal}As}}$

If $<\bm{x,v}>=0$ , we obtain $\hat{e}(g_{1},g_{2})^{\bm{\tau^{\intercal}As}}$ and can recover the message.

VI System Analysis

VI-A Performance Analysis

In this section, we compare our proposed Blockchain-enabled data governance system with previously discussed related works [13, 14, 23, 27, 24, 25, 26, 19, 28] in terms of performance and security. In Table V, we position these aforementioned works that are closely related to our work, providing comprehensive comparisons across the following assessment criteria:

TABLE V: Summary of access control system using Attribute-based Encryption

Approach	Group	Security	Encryption	Decryption
[13]	Prime	S-Rom	$3$ exp	$2$ pair
[14]	Composite	F-Rom	$(5I+1)$ exp+pair	$2I$ pair+ $I$ exp
[19]	Composite	F-ROM	$(7I+1)$ exp	$2I$ pair + $4I$ exp
[23]	Prime	S-STM	$(3n+1)$ pair*	$(3n+1)$ pair*
[24]	Composite	F-STM	$(l+2)$ exp	$(l+1)$ pair
[25]	Prime	S-STM	$(8I+2)$ exp	$(6I+1)$ pair + $I$ exp
[26]	Composite	F-STM	$(6I+4)$ exp*	$(I+2)$ pair + $2I$ exp*
[27]	Prime	S-STM	$(5I+2)$ exp	$(3I+1)$ pair + $I$ exp
[28]	Prime	S-STM	$5I$ pair + 4exp + 2pm	$2I$ pair + $3I$ exp
This work	Prime	S-ROM	$(2n+1)$ exp	2 pair + $2n$ exp

Several works did not present the computational complexity information. In such instances, we have either extrapolated the complexity on our own or referenced results presented in the survey by Zhang et al. [7]. The latter are highlighted with ^∗.

1.

Group: There are two types of groups used in CP-ABE: prime-order and composite-order groups. It is noted that the design of prime-order CP-ABE is more efficient than composite-order CP-ABE but is more challenging to achieve full security.
2.

Security Model: Standard model (STM) and random oracle model (ROM) are two typical types of security models considered in the CP-ABE scheme. And adversaries are categorized into selective adversaries and adaptive adversaries. If a CP-ABE scheme is secure against adaptive adversaries under the standard model, we denote this scheme as F-STM achieving full security. Likewise, S-ROM represents a CP-ABE scheme robust against selective adversaries under the random oracle model, and F-ROM if it is secure against adaptive adversaries under the random oracle model.
3.
Computation Cost: This assessment considers both the encryption and decryption costs in terms of their complexity, measured in terms of certain standard (cryptographic) operations. The following notations are used:
1. –
  
  $exp$ : exponentiation operation
2. –
  
  $pair$ : bilinear pair operation
3. –
  
  $pm$ : point multiplication operation
4. –
  
  $I$ : the access policy complexity for Linear Secret Sharing Scheme (LSSS)
5. –
  
  $l$ : the size of attributes
6. –
  
  $n$ : the size of attribute authorities

In terms of computational costs, bilinear pairing (pair) is the most expensive operation compared to exponentiation (exp) and point multiplication (pm), and the LSSS is a special matrix whose rows are labeled by attributes such that the cost of $I$ might be similar as $n$ or $l$ . Consequently, our scheme is superior to most of these works with respect to encryption and decryption cost, as shown in Table V, but it is constrained in terms of the conjunction access policy. More precisely, for ciphertext $CT_{M}$ consisting of

	$\displaystyle ct_{0}=g_{1}^{\bm{As}}$
	$\displaystyle ct_{i}=g_{1}^{(x_{i}\bm{U}^{\intercal}+\bm{X}_{i}^{\intercal})\bm{As}}$
	$\displaystyle ct^{\prime}=M\cdot\prod_{i=1}^{n}(\hat{e}(g_{1},g_{2})^{\bm{\tau}_{i}^{\intercal}\bm{A}})^{s}$

, $ct_{0}$ costs $1$ exp, $ct_{i}$ costs $n$ exp, and $ct^{\prime}$ costs another $n$ exp as the result $\hat{e}(g_{1},g_{2})^{\bm{\tau}_{i}^{\intercal}\bm{A}}$ is given by each public key $PK_{i}$ . Similarly, for decrypting ciphertext $CT_{M}$ , the formula $\hat{e}(ct_{0},\prod_{j=1}^{l+1}K_{i})\cdot\hat{e}(\prod ct_{i}^{v_{i}},\bm{h})$ costs $2$ pair + $2n$ exp.

VI-B Policy Hiding

Policy-hiding means that the ciphertext policy is hidden from inspection. In our approach, we achieve a weaker concept known as weakly attribute-hiding, which ensures that the policy remains unknown to all parties except those who can decrypt the ciphertext. Our access control system is constructed on top of the decentralized inner-product predicate encryption scheme in [20]. Combined with special policy encoding, the proposed construction in Michalevsky’s work is proved to be weakly attribute-hiding against chosen plaintext-attack under Assumption 3 in the presence of corrupt authorities.

[20] also provides detailed proof that, in the absence of corrupted authorities, the advantage of a PPT adversary $\mathcal{A}$ in winning a sequence of games, beginning with the actual scheme and ending with a challenge ciphertext, is negligible in the security parameter $\lambda$ against a challenger $S$ .

However, the privacy of attributes can not be maintained if adversary $\mathcal{A}$ colludes with a corrupt authority and asks it to provide it with an attribute key $K_{j},j\in[l+1]$ for a special value $v_{j}\in\mathcal{S}_{i}$ .

K_{j}=g_{2}^{\bm{\tau_{i}}-v_{i}\bm{X}_{i}\bm{h}+\bm{\mu_{i}}}

Let $\mathcal{R}$ represent a subset of attributes included in the ciphertext policy. One of the naive constructions of policy vector $\bm{x}$ might be as follows:

1.

Set the first $l$ entries such that $x_{i}$ = $\begin{cases}1&i\in\mathcal{R}\\ 0&i\notin\mathcal{R}\\ \end{cases}$
2.

Set the $l+1$ entry to $-|\mathcal{R}|$ .

If DO sets the policy vector to be $\bm{x}=(1,1,0,0,0,-2)$ and DU has the attribute vector to be $\bm{v}=(1,1,0,1,0,1)$ , it’s easily to get $\bm{x}\cdot\bm{v}=0$ , which is the precondition of the successful decryption. A trustworthy authority should only issue keys for values $v_{i}=0$ or $v_{i}=1$ . A corrupted authority, on the other hand, can provide an adversary with a key issued for a specific value $v_{i}$ , which may ”satisfy” the policy vector despite lacking all necessary attributes. If the policy vector is still to be $\bm{x}=(1,1,0,0,0,-2)$ and the corrupted AA issues the key for the attribute vector $\bm{v}=(2,0,0,0,0,0)$ , we can also get $\bm{x}\cdot\bm{v}=0$ . As a result, rather than using $0~{}or~{}1$ to indicate the absence or presence of an attribute, the enhanced scheme in [20] encodes the required attributes using randomly sampled $r_{i}$ over a large field, defeating an attempt to craft a key by arbitrarily selecting a value $v_{i}$ that would result in a zero inner product.

VI-C Receiver Privacy

According to the Definition 5, the receiver must provide its attribute vector $\bm{v}$ to each attribute authority AA from which a key is requested. In consequence, AA learns not only if the user possesses the attribute that AA owns, but also all of the user’s other attributes. This appears to violate the privacy of the user in a decentralized setting.

Therefore, Michalevsky and Joye propose an enhancement that provides additional privacy protection for the attribute vector $\bm{v}$ in their work [20], which uses it to hide the set of receiver attributes $\bm{v}$ from authorities. This technique is called position-binding Vector Commitments, introduced by Catalano and Fiore [43]. Our access control system is based on this work, but it has been slightly modified to work with asymmetric pairings $\hat{e}:\mathbb{G}_{1}\times\mathbb{G}_{2}\rightarrow\mathbb{G}_{T}$ , which meets two security requirements under Assumption 4:

1.

Position Hiding: Even after seeing some openings for certain positions, an adversary cannot tell whether a commitment was made to a sequence of messages, $(m_{1},\cdots,m_{n})$ or $(m_{1}^{\prime},\cdots,m_{n}^{\prime})$ .
2.

Position Binding: An adversary should not be able to open a vector commitment to two different messages at the same position.

Since hiding is not a critical property and can be easily achieved in the realization of vector commitments [43], only the proof of position binding is provided below:

Proof.

Suppose an efficient adversary $\mathcal{A}$ can produce two valid openings $op$ to different messages $(m,m^{\prime})$ at the same position $i$ . In that case, we can build an algorithm $\mathcal{B}$ that uses $\mathcal{A}$ to break the Square Computational Diffie-Hellman assumption.

As we know from Definition 4, for a sequence of messages $m_{1},m_{2},\dots,m_{n}$ and public parameter $pp=(g_{1},g_{2},\{o_{i}\}_{i\in[n]},\{o_{i,j}\}_{i,j\in[n],i\neq j})$ , the vector commitment is $\bm{C}=o_{1}^{m_{1}}o_{2}^{m_{2}}\cdot o_{n}^{m_{n}}$ and the opening for position $i$ is $op_{i}=(\prod^{n}_{j=1,j\neq i}o_{j}^{m_{j}})^{z_{i}}$ .

The efficient algorithm $\mathcal{B}$ takes as input a tuple $(g_{1},g_{1}^{r},g_{2}^{r})$ and aims to compute $g_{1}^{r^{2}}$ to break Assumption 4.

First, $\mathcal{B}$ selects a random position $i\xleftarrow{\$}[n]$ on which adversary $\mathcal{A}$ will break the position binding. Next, $\mathcal{B}$ chooses $z_{j}\xleftarrow{\$}\mathbb{Z}^{*}_{p}$ where $\forall j\in[n],j\neq i$ and then computes:

	$\displaystyle\forall j\in[n]\setminus{i}:o_{j}=g_{1}^{z_{j}},o_{i,j}=(g_{1}^{r})^{z_{j}},o_{i}=g_{1}^{r}$
	$\displaystyle\forall k,j\in[n]\setminus{i},k\neq j:o_{k,j}=g_{1}^{z_{k}z_{j}}$

Second, $\mathcal{B}$ sets $pp=(g_{1},g_{2},\{o_{i}\}_{i\in[n]},\{o_{i,j}\}_{i,j\in[n],i\neq j})$ and runs $\mathcal{A}(pp)$ , that outputs a tuple $(\bm{C},m,m^{\prime},j,op_{j},op_{j}^{\prime})$ such that $m\neq m^{\prime}$ and both $op_{j}$ and $op_{j}^{\prime}$ are valid.

Finally, $\mathcal{B}$ computes

g_{1}^{r^{2}}=(op_{i}^{\prime}/op_{i})^{(m_{i}-m_{i}^{\prime})^{-1}}

Since openings verify the two messages $(m_{i},m_{i}^{\prime})$ correctly at position $i$ , then it holds:

\hat{e}(\bm{C},g_{2}^{r})=\hat{e}(o_{i}^{m_{i}},g_{2}^{r})\hat{e}(op_{i},g_{2})=\hat{e}(o_{i}^{m_{i}^{\prime}},g_{2}^{r})\hat{e}(op_{i}^{\prime},g_{2})

which means that

\hat{e}(o_{i},g_{2}^{r})^{m_{i}-m_{i}^{\prime}}=\hat{e}(op_{i}^{\prime}/op_{i},g_{2})

Since $o_{i}=g_{1}^{r},op_{i}^{\prime}/op_{i}=(g_{1}^{r^{2}})^{m_{i}-m_{i}^{\prime}}$ ,
we have:

	$\displaystyle\hat{e}(o_{i},g_{2}^{r})^{m_{i}-m_{i}^{\prime}}=\hat{e}(g_{1},g_{2})^{r^{2}(m_{i}-m_{i}^{\prime})}$
	$\displaystyle\hat{e}(op_{i}^{\prime}/op_{i},g_{2})=\hat{e}((g_{1}^{r^{2}})^{m_{i}-m_{i}^{\prime}},g_{2})=\hat{e}(g_{1},g_{2})^{r^{2}(m_{i}-m_{i}^{\prime})}$

, which justifies the correctness of $\mathcal{B}$ ’s output. Therefore, if the Square Computational Diffie-Hellan assumption holds, the scheme satisfies the position-binding property. ∎

VI-D Other Security Requirements

VI-D1 Trustability

Most existing solutions require an intermediary entity to ensure reliable and secure data management, resulting in expensive costs to prevent a single point of failure and privacy leakage. To overcome these obstacles, our approach employs the blockchain’s distribution, decentralization, transparency, and immutability characteristics. By publishing the encrypted metadata, which consists of the AES key $AK$ and file location $loc$ , to the blockchain, we can maintain the integrity of access control management without requiring any intermediaries.

VI-D2 Traceability

Our system can track and validate access control data on the blockchain. Any activities, including setup, registration, key generation, encryption, and data uploading, are recorded as immutable transactions.

VI-E Collusion Attack Analysis

A fundamental requirement for an ABE scheme is to prevent collusion attacks. Let $\textit{DU}_{1}$ and $\textit{DU}_{2}$ be two users, possessing sets of secret keys $sk_{1}$ and $sk_{2}$ , corresponding to the attribute vector $\bm{v}=(v_{1},v_{2},\cdots,v_{l},v_{l+1})$ . $sk_{1}$ consists of key-parts $\{K_{1,j}\}_{j\in[l+1]}$ that enable obtaining a secret related to attribute $v$ from every attribute authorities $\textit{AA}_{i}$ for $\textit{DU}_{1}$ ’s processed attributes element $v\in\mathcal{R}_{1}$ . $sk_{2}$ consists of key-parts $\{K_{2,i}\}_{i\in[l+1]}$ that enable obtaining a secret related to attribute element $v_{j}$ from every attribute authorities $\textit{AA}_{i}$ for $\textit{DU}_{2}$ ’s processed attributes $v\in\mathcal{R}_{2}$ . The collusion prevention is against that $\textit{DU}_{1}$ and $\textit{DU}_{2}$ can mix their key-parts $(\{K_{1,j}\},\{K_{2,j}\})$ in a way that constructs a secret key $sk^{\prime}$ to a new vector $\bm{v}^{\prime}$ such that $v\in\mathcal{R}_{1}\cup\mathcal{R}_{2}$ . Otherwise, users can collude to decrypt the ciphertext, which is not accessible for either of them.

Therefore, we propose two mechanisms to restrict key combinations:

1.

Global Identifier associates each secret key $sk$ with an identity by incorporating it into the key parts $K$ issued by the attribute authorities.
2.

Masking Term maps a combination of the public keys of all other authorities $\{g_{2}^{\sigma}\}$ , global identifier $GID$ , and the vector commitment $\bm{C}$ to a random element

It is worth noting that our scheme necessitates one special authority $\textit{AA}_{n}$ to be trusted specifically to issue keys only for $v_{l+1}\neq 0$ . As previously discussed, this design choice ensures our scheme’s security, even if some corrupt authorities collude with adversaries to compute a key for any distinct value $v$ within the attribute vector $\bm{v}$ .

VI-F Rogue-key Attack Analysis

First, we provide proof that the original scheme, as proposed by Michalevsky et al. [20] and outlined in Definition 5, is vulnerable to a Rogue-key Attack. Following this, we discuss how our blockchain-based data governance mechanism effectively mitigates this vulnerability.

VI-F1 Attack

We demonstrate that a corrupt authority can learn the key parts $K_{l+1}$ corresponding to $v_{l+1}\in\bm{v}$ issued by trusted authority $\textit{AA}_{\text{trust}}$ and thus decrypt the ciphertext in Michalevsky and Joys’s scheme [20], without having the required secret key $sk$ satisfying the attached access policy. This is a typical attack, called Rogue-key Attack, in which the adversary uses a public key, a function of honest users’ keys [45].

Proof.

First, an adversarial authority $\textit{AA}_{ad}$ holds until all the other attribute authorities $\textit{AA}_{i},i\neq ad,i\in n$ publish their public keys.

PK_{i}=(g_{1}^{\bm{X}_{i}^{\intercal}\bm{A}},\hat{e}(g_{1},g_{2})^{\bm{\tau}_{i}^{\intercal}\bm{A}},y:=g_{2}^{\sigma})

and then calculates the public key as follows:

	$\displaystyle g_{1}^{\bm{X}_{ad}^{\intercal}\bm{A}}:=-\sum_{j=0,j\neq ad}^{n}g_{1}^{\bm{X}_{j}^{\intercal}\bm{A}}$
	$\displaystyle\hat{e}(g_{1},g_{2})^{\bm{\tau}_{ad}^{\intercal}\bm{A}},y_{ad}:=g_{2}^{\sigma_{i}}$

Second, an adversarial data user $\textit{DU}_{ad}$ creates an attribute vector $\bm{v}^{\prime}=(0,0,\cdots,0,1)$ and requrests key parts $K_{i}$ from all the attribute authorities $\textit{AA}_{i}$ .

As in the encryption phase, data owner DO will collect all the public keys $PK_{i},i\in[n+1]$ from each $\textit{AA}_{i}$ and outputs the cipher text $CT$ consisting of

	$\displaystyle ct_{0}=g_{1}^{\bm{As}}$
	$\displaystyle ct_{i}=g_{1}^{(x_{i}\bm{U}^{\intercal}+\bm{X}_{i}^{\intercal})\bm{As}}$
	$\displaystyle ct^{\prime}=m\cdot\hat{e}(g_{1},g_{2})^{\bm{\tau}^{\intercal}\bm{As}}$

, where $\bm{\tau}=\sum_{i=1}^{n}\bm{\tau}_{i}$

Third, given the ciphertest $(ct_{0},\{ct_{i}\},ct^{\prime})$ and received secret keys $\{K_{i}\}$ , adversary $\textit{DU}_{ad}$ decrypts it as following:

	$\displaystyle\hat{e}(ct_{0},\prod_{j=1}^{l+1}K_{i})\cdot\hat{e}(\prod_{i=1}^{n}ct_{i}^{v_{i}},\bm{H}(GID,\bm{C}))$
	$\displaystyle=\hat{e}(g_{1}^{\bm{As}},g_{2}^{\sum^{n}_{i=1}\bm{\tau}_{i}-v_{i}\bm{X}_{i}\bm{h}+\bm{\mu}_{i}})$
	$\displaystyle\cdot\hat{e}(g_{1}^{\sum^{n}_{i=1}v_{i}(x_{i}\bm{U}^{\intercal}+\bm{X}_{i}^{\intercal})\bm{As}},g_{2}^{\bm{h}})$
	$\displaystyle=\hat{e}(g_{1},g_{2})^{\bm{\tau}^{\intercal}\bm{As}-\sum^{n}_{i=1}v_{i}\bm{h}^{\intercal}\bm{X}_{i}^{\intercal}\bm{As}}$
	$\displaystyle\cdot\hat{e}(g_{1},g_{2})^{\bm{<x,v>h^{\intercal}U^{\intercal}As}+\sum^{n}_{i=1}v_{i}\bm{h^{\intercal}X_{i}^{\intercal}As}}$
	$\displaystyle=\hat{e}(g_{1},g_{2})^{\bm{\tau}^{\intercal}\bm{As}}\cdot\hat{e}(g_{1},g_{2})^{\bm{<x,v>h^{\intercal}U^{\intercal}As}}$

Since $\textit{DU}_{ad}$ ’s attribute vector is $\bm{v}^{\prime}=(0,0,\cdots,0,1)$ , we have

\hat{e}(g_{1},g_{2})^{\bm{\tau}^{\intercal}\bm{As}}\cdot\hat{e}(g_{1},g_{2}^{\bm{h}})^{x_{l+1}\bm{U}^{\intercal}\bm{As}}

(20)

In order to decrypt the ciphertext, we need to cancel out the last element in the above Equation 20. Therefore, adversary $\mathcal{A}$ could use the published $\{ct_{i}\}$ to calculate attacking component $\omega$ .

	$\displaystyle\omega:$	$\displaystyle=\prod g_{1}^{(x_{i}\bm{U}^{\intercal}+\bm{X}_{i}^{\intercal})\bm{As}}$
		$\displaystyle=g_{1}^{\sum x_{i}\bm{U}^{\intercal}\bm{As}}\cdot g_{1}^{\sum(\bm{X}_{i}^{\intercal}\bm{A})\bm{s}}$

Based on $g_{1}^{\bm{X}_{ad}^{\intercal}\bm{A}}:=-\sum_{j=0,j\neq ad}^{n}g_{1}^{\bm{X}_{j}^{\intercal}\bm{A}}$ , we obtain $\omega=g_{1}^{\sum_{i=1}^{n}x_{i}\bm{X}^{\intercal}\bm{As}}$ and can further cancel the last component in the Equation 20 as $x_{l+1}=-\sum_{i=1}^{n}x_{i}$ .

In the end, the adversary recovers the message by computing

ct^{\prime}/\hat{e}(g_{1},g_{2})^{\bm{\tau}^{\intercal}\bm{As}}=m.

∎

VI-F2 Proof of security of our approach

One way to mitigate rogue-key attack requires proof of knowledge upon public key registration with a certificate authority (CA) [45]. In the absence of a CA, Non-interactive Zero-knowledge Proof (NIZK) could be utilized to solve this security issue in a decentralized manner, as has been the case for our approach.

Proof.

In the process of Authority Setup, every AA needs to generate a commitment of secrets used for public key $PK$ , and then creates its proof of knowledge using NIZK (Algorithm 3).

Since NIZK is built upon Schnorr Identification Protocol [42], our scheme is resistant to rogue-key attacks under the Assumption 5, i.e., Knowledge of Coefficient Assumption [41]. Particularly, given a simple example $(\bm{rp}_{s}=(A,B=s\cdot A),h)$ , adversary $\mathcal{A}$ can not generate a valid NIZK of $B$ without knowing $s$ with non-negligible probability.

As defined in the NIZK of $s$ (Algorithm 3), a valid proof is $\pi=(R,u)$ such that

	$\displaystyle\alpha$	$\displaystyle\xleftarrow[]{\$}\mathbb{Z}_{p}^{*}$
	$\displaystyle R$	$\displaystyle\leftarrow\alpha\cdot A$
	$\displaystyle u$	$\displaystyle\leftarrow\alpha+c\cdot s$

, where $c$ is deterministic by $R$ and a given string $h$ . Thus, if such $(R,u)$ is provided to $\mathcal{A}$ and $s$ used to generate $u$ is unknown, $\mathcal{A}$ can construct a pair $(x,y=u\cdot A-R)$ for a given $(\bm{rp}_{s}=(A,B=s\cdot A),h)$ and also there exists an efficient deterministic $\mathcal{X}$ that outputs $c$ .

However, because of the Knowledge of Coefficient Assumption [22], the probability that both

1.

$\mathcal{A}$ ‘succeeds’, meaning it satisfies the condition: SameRatio( $(A,x),(B,y)$ )
2.

$\mathcal{X}$ ‘fails’, meaning $x\neq g_{1}^{c}$

is negligible. Thus, adversary $\mathcal{A}$ can not generate a valid proof without knowing $s$ based on given information. In other words, $\mathcal{A}$ can not generate a public key $PK$ with a valid NIZK, if and only if $\mathcal{A}$ has the knowledge of $PK$ ’s exponent $s$ . As such, our scheme is secure against the rogue-key attack that malicious AA can not register a $PK$ that is a function of others.

∎

VI-G Inferring the Secret Vector in Ciphertext

With its further study of the Decentralized Policy-hiding ABE scheme [20], we also identified a potential risk associated with the generation of public parameters during Setup. The detail of the risk and proof of security is described in the following sections.

VI-G1 Vulnerability

As defined in Definition 5, a trusted third-party (TTP) or an attribute authority (AA) needs to pick a set of random numbers $a_{1},a_{2},\dots,a_{k}\xleftarrow{\$}\mathbb{Z}^{*}_{p}$ , and then generate a random matrix $\bm{A}=\begin{pmatrix}a_{1}&0&&0\\ 0&a_{2}&&0\\ \vdots&\ddots&&\\ 0&0&\cdots&a_{k}\\ 1&1&\cdots&1\\ \end{pmatrix}\in\mathbb{Z}^{(k+1)\times k}_{p}$ with
$\bm{a}^{\perp}=\begin{pmatrix}a_{1}^{-1}\\ a_{2}^{-1}\\ \vdots\\ a_{k}^{-1}\\ -1\\ \end{pmatrix}\in\mathbb{Z}^{(k+1)}_{p}$ , which $\bm{A^{\intercal}a}^{\perp}=0$ during Setup.

Proof.

If the above generation is conducted by a PPT adversary $\mathcal{A}$ , or if the sensitive information $\bm{a}^{\perp}$ is exposed, $\mathcal{A}$ can infer the value of $g_{1}^{\bm{s}}$ from any published ciphertext $CT$ .

As we know, to generate a ciphertext $CT$ , data owner (DO) firstly samples a random vector $\bm{s}=(s_{1},s_{2},\dots,s_{k})\in\mathbb{Z}_{p}^{k}$ , then creates a policy vector $\bm{x}=(x_{1},x_{2},...,x_{n-1},x_{n})\in\mathbb{Z}_{p}^{n}$ acting as the ciphertext policy, and finally outputs the ciphertext $CT$ consisting of

	$\displaystyle ct_{0}=g_{1}^{\bm{As}}$
	$\displaystyle ct_{i}=g_{1}^{(x_{i}\bm{U}^{\intercal}+\bm{X}_{i}^{\intercal})\bm{As}}$
	$\displaystyle ct^{\prime}=M\cdot\hat{e}(g_{1},g_{2})^{\bm{\tau}^{\intercal}\bm{As}}$

, where $\bm{\tau}=\sum_{i=1}^{n}\bm{\tau}_{i}$ and $\hat{e}(g_{1},g_{2})^{\bm{\tau}_{i}^{\intercal}}$ collected from published public keys $PK_{i}$ .

Since

\bm{As}=\begin{pmatrix}a_{1}s_{1}\\ a_{2}s_{2}\\ \vdots\\ a_{k}s_{k}\\ s_{1}+s_{2}+\dots+s_{k}\\ \end{pmatrix}

$\mathcal{A}$ can use the result $ct_{0}=g_{1}^{\bm{As}}$ and known $\bm{a}$ to calculate:

(g_{1}^{\bm{As}})^{\bm{a}}=g_{1}^{\bm{Asa}}

For the exponent $\bm{Asa}$ , we have

	$\displaystyle\bm{Asa}$	$\displaystyle=\begin{pmatrix}a_{1}s_{1}\\ a_{2}s_{2}\\ \vdots\\ a_{k}s_{k}\\ s_{1}+s_{2}+\dots+s_{k}\\ \end{pmatrix}\cdot(a_{1}^{-1},a_{2}^{-1},\dots,a_{k}^{-1},-1)$
		$\displaystyle=\begin{pmatrix}s_{1}&a_{1}a_{2}^{-1}s_{1}&\dots&a_{1}a_{k}^{-1}s_{1}&-a_{1}s_{1}\\ a_{1}^{-1}a_{2}s_{2}&s_{2}&\dots&a_{2}a_{k}^{-1}s_{2}&-a_{2}s_{2}\\ \vdots&\ddots&&\\ a_{1}^{-1}a_{k}s_{k}&a_{2}^{-1}a_{k}s_{k}&\dots&s_{k}&-a_{k}s_{k}\\ a_{1}^{-1}\sum{s}&a_{2}^{-1}\sum{s}&\cdots&a_{k}^{-1}\sum{s}&-\sum{s}\\ \end{pmatrix}$

It is simple to determine that the $i$ th elements from exponents $\bm{As}$ and $\bm{a}$ partially cancel each other out, and the remaining element $s_{i}$ is the targeting exponent. Therefore, adversary $\mathcal{A}$ might extrapolate $g_{1}^{\bm{s}}$ from the published ciphertext $ct_{0}=g_{1}^{\bm{Asa}}$ with the knowledge of $\bm{a}^{\perp}$ .

∎

VI-G2 Proof of security with our approach

One potential mitigation of the inferring attack is to generate a composite public parameter $PP$ by multiple AA, such that neither of those individual AAs knows the secrets $\bm{a}$ . This is achieved relying on the Knowledge of Exponent Assumption (KEA), introduced by Damgård in [46], more precisely:

Proof.

From the Section V-A4 Round 1, the first participant $P_{1}$ samples a random matrix $\bm{A}_{1}$ and a scalar $\alpha_{\bm{A}_{1}}$ , constracts the elements $(V_{1}=g_{1}^{\bm{A}_{1}},\theta_{V_{1}}=g_{1}^{\alpha_{\bm{A}_{1}}},V_{1}^{\prime}=g_{1}^{\alpha_{\bm{A}_{1}}\bm{A}_{1}})$ , and publishes these information for the next participant.

Upon receiving the $(V_{1},\theta_{V_{1}},V_{1}^{\prime})$ , $P_{2}$ samples his own random matrix $\bm{A}_{2}$ and a scalar $\alpha_{\bm{A},2}$ , calculates

	$\displaystyle V_{2}$	$\displaystyle:=\textsc{powerMulti}(V_{1},\bm{A}_{2})$
	$\displaystyle\theta_{V_{2}}$	$\displaystyle:=(\theta_{V_{1}})^{\alpha_{\bm{A}_{2}}}$
	$\displaystyle V_{2}^{\prime}$	$\displaystyle:=\textsc{powerMulti}(V_{1}^{\prime},\alpha_{\bm{A}_{2}}\bm{A}_{2})$

using Algorithm 5, and also broadcasts them to the next participant.

Similarly, the next participant performs the same operation until the very last one. In the end, we have a composite

g_{1}^{\bm{A}}=\textsc{powerMulti}(\textsc{powerMulti}(\dots(\\ \textsc{powerMulti}(\textsc{powerMulti}(g_{1}^{\bm{A}_{1}},\bm{A}_{2}),\bm{A}_{3})\dots,\bm{A}_{n})

, and no participant learns the secrets of others unless one must collude with every other participant under Assumption 5.

Another security concern is the consistency that an adversary with index $i$ can sample different $(\bm{A}_{i},\bm{A}_{i}^{\prime})$ and $(\alpha_{\bm{A}_{i}},\alpha_{\bm{A}_{i}}^{\prime})$ to compute $V_{i},\theta_{V_{i}}$ and $V_{i}^{\prime}$ , rendering final composite invalid and unusable.

Since a set of group elements

e=(\bm{A},\bm{U},\alpha_{\bm{A}},\alpha_{\bm{U}},\alpha_{\bm{A}}\cdot\bm{A},\alpha_{\bm{U}}\cdot\bm{U})\cdot g

in both $\mathbb{G}_{1}$ and $\mathbb{G}_{2}$ has been committed and revealed by each AA as described in Section V-A2, we may validate that adversary’s $(V_{i},\theta_{V_{i}},V_{i}^{\prime})$ is a proper multiple of $P_{i-1}$ ’s components:

	$\displaystyle\hat{e}(V_{i},g_{2})$	$\displaystyle=\hat{e}(V_{i-1},g_{2}^{\bm{A}_{i}})$
	$\displaystyle\hat{e}(\theta_{V_{i}},g_{2})$	$\displaystyle=\hat{e}(\theta_{V_{i-1}},g_{2}^{\alpha_{i}})$
	$\displaystyle\hat{e}(V_{i}^{\prime},g_{2})$	$\displaystyle=\hat{e}(V_{i-1}^{\prime},g_{2}^{\alpha_{\bm{A},i}\bm{A}_{i}})$

Even if all the other participants have collaborated, this is still a robust and sufficient setup scheme, even if only one participant is honest and does not reveal its secrets. Hence, the greater the number of unrelated participants in a trusted setup, the less likely the possibility of invalid and unusable public parameter $PP_{ABE}$ [47].

∎

VII Concluding Remarks

Securing cloud data access and protecting identity privacy are legitimate concerns for many use cases, which this work addresses with a blockchain-based data governance system that is secure and privacy-preserving. A combination of attribute-based encryption (ABE) and the Advanced Encryption Standard (AES) makes the system efficient and responsive to real-world conditions. Our ABE encryption system can handle multi-authority scenarios while protecting identity privacy and hiding ABE’s policy.

However, because our system is built on top of Michalevsky’s scheme[20] and Bowe’s setup [22], it has inevitably inherited a few drawbacks: First, it only supports fixed-size attributes and authorities, which means that any changes to these may necessitate requesting a new system setup or a new key for DU from all authorities. Second, because each AA’s public key must be shared with others for the computation of masking terms $\mu_{i}$ , the system requires coordination among authorities during the setup phase. Third, an authorized user should be unable to learn which attributes were included in the encryption policy, which is a desirable property called strongly attribute-hiding. However, our system can only achieve weakly attribute-hiding, such that the policy is hidden from all entities other than authorized users. Finally, implementing trusted setup to protect against rogue-key attacks further complicates the entire setup process posing limitations to scenarios in which authorities might join and leave frequently. Addressing these shortcomings comprise our planned future work.

References

[1] Clark Mitchell. Activists respond to apple choosing encryption over invasive image scanning plans, 2022.
[2] M Sudha and M Monica. Enhanced security framework to ensure data security in cloud computing using cryptography. Advances in Computer Science and its Applications, 1(1):32–37, 2012.
[3] OD Alowolodu, BK Alese, AO Adetunmbi, OS Adewale, and OS Ogundele. Elliptic curve cryptography for securing cloud computing applications. International Journal of Computer Applications, 66(23), 2013.
[4] Liang Yan, Chunming Rong, and Gansen Zhao. Strengthen cloud computing security with federal identity management using hierarchical identity-based cryptography. In IEEE International Conference on Cloud Computing, pages 167–177. Springer, 2009.
[5] Caixia Yang, Liang Tan, Na Shi, Bolei Xu, Yang Cao, and Keping Yu. Authprivacychain: A blockchain-based access control framework with privacy protection in cloud. IEEE Access, 8:70604–70615, 2020.
[6] Matthew Green, Susan Hohenberger, and Brent Waters. Outsourcing the decryption of $\{$ ABE $\}$ ciphertexts. In 20th USENIX Security Symposium (USENIX Security 11), 2011.
[7] Yinghui Zhang, Robert H Deng, Shengmin Xu, Jianfei Sun, Qi Li, and Dong Zheng. Attribute-based encryption for cloud computing access control: A survey. ACM Computing Surveys (CSUR), 53(4):1–41, 2020.
[8] Ming Li, Shucheng Yu, Yao Zheng, Kui Ren, and Wenjing Lou. Scalable and secure sharing of personal health records in cloud computing using attribute-based encryption. IEEE transactions on parallel and distributed systems, 24(1):131–143, 2012.
[9] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. Decentralized Business Review, page 21260, 2008.
[10] Amit Sahai and Brent Waters. Fuzzy identity-based encryption. In Annual international conference on the theory and applications of cryptographic techniques, pages 457–473. Springer, 2005.
[11] Damiano Di Francesco Maesa, Paolo Mori, and Laura Ricci. Blockchain based access control. In IFIP international conference on distributed applications and interoperable systems, pages 206–220. Springer, 2017.
[12] Aafaf Ouaddah, Anas Abou Elkalam, and Abdellah Ait Ouahman. Fairaccess: a new blockchain-based access control framework for the internet of things. Security and communication networks, 9(18):5943–5964, 2016.
[13] Shangping Wang, Yinglong Zhang, and Yaling Zhang. A blockchain-based framework for data sharing with fine-grained access control in decentralized storage systems. Ieee Access, 6:38437–38450, 2018.
[14] Xuanmei Qin, Yongfeng Huang, Zhen Yang, and Xing Li. A blockchain-based access control scheme with multiple attribute authorities for secure cloud data sharing. Journal of Systems Architecture, 112:101854, 2021.
[15] Yiming Hei, Jianwei Liu, Hanwen Feng, Dawei Li, Yizhong Liu, and Qianhong Wu. Making ma-abe fully accountable: A blockchain-based approach for secure digital right management. Computer Networks, 191:108029, 2021.
[16] Melissa Chase. Multi-authority attribute based encryption. In Theory of cryptography conference, pages 515–534. Springer, 2007.
[17] Allison Lewko and Brent Waters. Decentralizing attribute-based encryption. In Annual international conference on the theory and applications of cryptographic techniques, pages 568–588. Springer, 2011.
[18] Yannis Rouselakis and Brent Waters. Efficient statically-secure large-universe multi-authority attribute-based encryption. In International Conference on Financial Cryptography and Data Security, pages 315–332. Springer, 2015.
[19] Yan Yang, Xingyuan Chen, Hao Chen, and Xuehui Du. Improving privacy and security in decentralizing multi-authority attribute-based encryption in cloud computing. IEEE Access, 6:18009–18021, 2018.
[20] Yan Michalevsky and Marc Joye. Decentralized policy-hiding abe with receiver privacy. In European Symposium on Research in Computer Security, pages 548–567. Springer, 2018.
[21] Leyou Zhang, Juan Ren, Li Kang, and Baocang Wang. Decentralizing multi-authority attribute-based access control scheme with fully hidden policy. International Journal of Network Security, 23(4):588–603, 2021.
[22] Sean Bowe, Ariel Gabizon, and Matthew D Green. A multi-party protocol for constructing the public parameters of the pinocchio zk-snark. In International Conference on Financial Cryptography and Data Security, pages 64–77. Springer, 2018.
[23] Takashi Nishide, Kazuki Yoneyama, and Kazuo Ohta. Attribute-based encryption with partially hidden encryptor-specified access structures. In International conference on applied cryptography and network security, pages 111–129. Springer, 2008.
[24] Sheng Gao, Guirong Piao, Jianming Zhu, Xindi Ma, and Jianfeng Ma. Trustaccess: A trustworthy secure ciphertext-policy and attribute hiding access control scheme based on blockchain. IEEE Transactions on Vehicular Technology, 69(6):5784–5798, 2020.
[25] Hui Cui, Robert H Deng, Junzuo Lai, Xun Yi, and Surya Nepal. An efficient and expressive ciphertext-policy attribute-based encryption scheme with partially hidden access structures, revisited. Computer Networks, 133:157–165, 2018.
[26] Yinghui Zhang, Dong Zheng, and Robert H Deng. Security and privacy in smart health: Efficient policy-hiding attribute-based access control. IEEE Internet of Things Journal, 5(3):2130–2145, 2018.
[27] Jiguo Li, Yichen Zhang, Jianting Ning, Xinyi Huang, Geong Sen Poh, and Debang Wang. Attribute Based Encryption with Privacy Protection and Accountability for CloudIoT. IEEE Transactions on Cloud Computing, 10(2):762–773, April 2022.
[28] Chenbin Zhao, Li Xu, Jiguo Li, He Fang, and Yinghui Zhang. Toward secure and privacy-preserving cloud data sharing: Online/offline multiauthority cp-abe with hidden policy. IEEE Systems Journal, 16(3):4804–4815, 2022.
[29] Vipul Goyal, Omkant Pandey, Amit Sahai, and Brent Waters. Attribute-based encryption for fine-grained access control of encrypted data. In Proceedings of the 13th ACM conference on Computer and communications security, pages 89–98, 2006.
[30] John Bethencourt, Amit Sahai, and Brent Waters. Ciphertext-policy attribute-based encryption. In 2007 IEEE symposium on security and privacy (SP’07), pages 321–334. IEEE, 2007.
[31] Yinghui Zhang, Dong Zheng, Xiaofeng Chen, Jin Li, and Hui Li. Computationally Efficient Ciphertext-Policy Attribute-Based Encryption with Constant-Size Ciphertexts. In Sherman S. M. Chow, Joseph K. Liu, Lucas C. K. Hui, and Siu Ming Yiu, editors, Provable Security, volume 8782, pages 259–273. Springer International Publishing, Cham, 2014.
[32] Junzuo Lai, Robert H Deng, and Yingjiu Li. Fully secure cipertext-policy hiding cp-abe. In Information Security Practice and Experience: 7th International Conference, ISPEC 2011, Guangzhou, China, May 30–June 1, 2011. Proceedings 7, pages 24–39. Springer, 2011.
[33] Yannis Rouselakis and Brent Waters. Practical constructions and new proof methods for large universe attribute-based encryption. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security, pages 463–474, 2013.
[34] Axin Wu, Yinghui Zhang, Xiaokun Zheng, Rui Guo, Qinglan Zhao, and Dong Zheng. Efficient and privacy-preserving traceable attribute-based encryption in blockchain. Annals of Telecommunications, 74:401–411, 2019.
[35] Changyu Dong, Liqun Chen, and Zikai Wen. When private set intersection meets big data: an efficient and scalable protocol. In Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security, pages 789–800, 2013.
[36] Hong Zhong, Wenlong Zhu, Yan Xu, and Jie Cui. Multi-authority attribute-based encryption access control scheme with policy hidden for cloud storage. Soft Computing, 22:243–251, 2016.
[37] Sana Belguith, Nesrine Kaaniche, Maryline Laurent, Abderrazak Jemai, and Rabah Attia. Phoabe: Securely outsourcing multi-authority attribute based encryption with policy hidden for cloud assisted iot. Computer Networks, 133:141–156, 2018.
[38] Lucas Ballard, Matthew Green, Breno De Medeiros, and Fabian Monrose. Correlation-resistant storage via keyword-searchable encryption. Cryptology ePrint Archive, 2005.
[39] Dan Boneh, Xavier Boyen, and Hovav Shacham. Short group signatures. In Annual international cryptology conference, pages 41–55. Springer, 2004.
[40] Mike Burmester, Yvo Desmedt, and Jennifer Seberry. Equitable key escrow with limited time span (or, how to enforce time expiration cryptographically) extended abstract. In International Conference on the Theory and Application of Cryptology and Information Security, pages 380–391. Springer, 1998.
[41] Sean Bowe, Ariel Gabizon, and Ian Miers. Scalable multi-party computation for zk-snark parameters in the random beacon model. Cryptology ePrint Archive, 2017.
[42] Claus-Peter Schnorr. Efficient identification and signatures for smart cards. In Advances in Cryptology—CRYPTO’89 Proceedings 9, pages 239–252. Springer, 1990.
[43] Dario Catalano and Dario Fiore. Vector commitments and their applications. In International Workshop on Public Key Cryptography, pages 55–72. Springer, 2013.
[44] Xinlei Wang, Jianqing Zhang, Eve M Schooler, and Mihaela Ion. Performance evaluation of attribute-based encryption: Toward data privacy in the iot. In 2014 IEEE International Conference on Communications (ICC), pages 725–730. IEEE, 2014.
[45] Thomas Ristenpart and Scott Yilek. The power of proofs-of-possession: Securing multiparty signatures against rogue-key attacks. In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pages 228–245. Springer, 2007.
[46] Ivan Damgård. Towards practical public key systems secure against chosen ciphertext attacks. In Annual International Cryptology Conference, pages 445–456. Springer, 1991.
[47] Zooko Wilcox. The Design of the Ceremony, October 2016.

VIII Appendix

VIII-A System Contracts

The function Commit and the state variable $h\_collector$ are defined as following:

1.

$h\_collector$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its commitment $h$

Algorithm 7 Contract

SC_{sys}

: Part 1

1:function Commit(

h

)

2: if

msg.sender\notin AAlist

block.timestamp>ddl_{1}

then

\triangleright

Requirement check

3: throw

4: end if

5: if

msg.sender\notin h\_collector

then

\triangleright

Resubmitting check

h\_collector[msg.sender]\leftarrow h

7: end if

8:end function

The function Reveal and some state variables used are defined 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-pairs $L=\{(\bm{rp}_{s},\bm{rp}_{s}^{2})|s\in e\}$ in both $\mathbb{G}_{1}$ and $\mathbb{G}_{2}$

Algorithm 8 Contract

SC_{sys}

: Part 2

9:function Reveal(

L_{rp}

)

10: if

msg.sender\notin h\_collector

block.timestamp>ddl_{1}

then

\triangleright

Requirement check

11: throw

12: end if

13: for all

(a,b)\in L_{rp}

14:

h\leftarrow h||

Hash(a)

||

Hash(b)

15: end for

16: if

h\_collector(msg.sender)\neq h

then

\triangleright

Check validity

17: throw

18: end if

19: if

msg.sender\notin unverified\_elements

then

\triangleright

Resubmitting check

20:

unverified\_elements[msg.sender]\leftarrow L_{rp}

21: end if

22:end function

The function Prove and some state variables used are defined as follows:

1.

$verified\_elements$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its verified list of s-pairs $L=\{(\bm{rp}_{s},\bm{rp}_{s}^{2})|s\in e\}$ in both $\mathbb{G}_{1}$ and $\mathbb{G}_{2}$

Algorithm 9 Contract

SC_{sys}

: Part 3

23:function Prove(

L_{\pi}

)

24: if

unverified\_elements[msg.sender]==[]

block.timestamp<ddl_{1}

block.timestamp>ddl_{2}

then

25: throw

26: end if

27:

L_{rp}\leftarrow unverified\_elements[msg.sender]

28: for

i\leftarrow 0,5

29:

(rp,rp2)\leftarrow L_{rp}[i]

30:

pi\leftarrow L_{\pi}[i]

31: if not SameRatio(

rp,rp2

) then

32: throw

33: end if

34:

h_{tmp}\leftarrow h\_collector[msg.sender]||\textsc{Hash}(rp_{s})

35: if not CheckPoK(

rp_{s},\pi_{s},h_{tmp}

) then

36: throw

37: end if

38: end for

39:

verified\_elements[msg.sender]\leftarrow L_{rp}

40:

unverified\_elements[msg.sender]=[]

41:end function

The function Compute and some state variables used are defined as follows:

1.

$V\_curr$ (State Variable): The most recent published value $V$
2.

$V\_curr^{\prime}$ (State Variable): The most recent published value $V^{\prime}$
3.

$\theta\_curr$ (State Variable): The most recent published scalar $\theta$

Algorithm 10 Contract

SC_{sys}

: Part 4

42:function Compute(

V,\theta,V^{\prime}

)

43: if

unverified\_elements[msg.sender]\neq[]

block.timestamp<ddl_{2}

block.timestamp>ddl_{3}

then

44: throw

45: end if

46: if not

V\_curr

then

\triangleright

Initialize

V,\theta,V^{\prime}

47:

V\_curr\leftarrow V

48:

\theta\_curr\leftarrow\theta

49:

V\_curr^{\prime}\leftarrow V^{\prime}

50: return

51: end if

52:

(rp_{\bm{A}},rp_{\alpha_{\bm{A}}},rp_{\alpha_{\bm{A}}\bm{A}})\leftarrow verified\_elements[msg.sender]

53:

acc_{1}\leftarrow

SameRatio(

(V\_curr,V),rp_{\bm{A}}

)

54:

acc_{2}\leftarrow

SameRatio(

(\theta\_curr,\theta),rp_{\alpha_{\bm{A}}}

)

55:

acc_{3}\leftarrow

SameRatio(

(V\_curr^{\prime},V^{\prime}),rp_{\bm{A}\alpha_{\bm{A}}}

)

56: if

acc_{1}==acc_{2}==acc_{3}==

true then

\triangleright

Check validity

57:

V\_curr\leftarrow V

58:

\theta\_curr\leftarrow\theta

59:

V\_curr^{\prime}\leftarrow V^{\prime}

60: else

61: throw

62: end if

63:end function

The function Generate and some state variables used are defined as follows:

1.

$W\_curr$ (State Variable): The most recent published value $W$
2.

$W\_curr^{\prime}$ (State Variable): The most recent published value $W^{\prime}$
3.

$\theta\_curr\_$ (State Variable): The most recent published scalar $\theta$

Algorithm 11 Contract

SC_{sys}

: Part 5

64:function Generate(

W,\theta,W^{\prime}

)

65: if

unverified\_elements[msg.sender]\neq[]

block.timestamp<ddl_{2}

block.timestamp>ddl_{3}

then

66: throw

67: end if

68: if not

W\_curr

then

\triangleright

Initialize

W,\theta,W^{\prime}

69:

W\_curr\leftarrow W

70:

\theta\_curr\_\leftarrow\theta

71:

W\_curr^{\prime}\leftarrow W^{\prime}

72: return

73: end if

74:

(rp_{\bm{U}},rp_{\alpha_{\bm{U}}},rp_{\alpha_{\bm{U}}\bm{U}})\leftarrow verified\_elements[msg.sender]

75:

acc_{1}\leftarrow

SameRatio(

(W\_curr,W),rp_{\bm{U}}

)

76:

acc_{2}\leftarrow

SameRatio(

(\theta\_curr\_,\theta),rp_{\alpha_{\bm{U}}}

)

77:

acc_{3}\leftarrow

SameRatio(

(W\_curr^{\prime},W^{\prime}),rp_{\alpha_{\bm{U}}\bm{U}}

)

78: if

acc_{1}==acc_{2}==acc_{3}==

true then

\triangleright

Check validity

79:

W\_curr\leftarrow W

80:

\theta\_curr\_\leftarrow\theta

81:

W\_curr^{\prime}\leftarrow W^{\prime}

82: else

83: throw

84: end if

85:end function

VIII-B Authority Setup Contracts

Function Commit and the state variable $h\_collector$ are defined as following:

1.

$h\_collector$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its commitment $h$

Algorithm 12 Contract

SC_{auth}

: Part 1

1:function Commit(

h

)

2: if

msg.sender\notin AAlist

block.timestamp>ddl_{1}

then

\triangleright

Basic check

3: throw

4: end if

5: if

msg.sender\notin h\_collector

then

\triangleright

Duplicate Sub check

h\_collector[msg.sender]\leftarrow h

7: end if

8:end function

The function Reveal and some state variables used are defined as follows:

1.

$h\_collector$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority $\bm{AA}$ to its commitment $h^{\prime}$
2.

$unverified\_sk$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority $\bm{AA}$ to its list of unverified elements $SK$
3.

$unverified\_elements$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority $\bm{AA}$ to its list unverified group elements $e^{\prime}$ in both $\mathbb{G}_{1}$ and $\mathbb{G}_{2}$

Algorithm 13 Contract

SC_{auth}

: Part 2

9:function Reveal(

L_{sk},L_{vc}

)

10: if

msg.sender\notin h\_collector

block.timestamp>ddl_{1}^{\prime}

msg.sender\in unverified\_elements

then

11: throw

12: end if

13: for all

a\in L_{sk}

14:

h\leftarrow h||\textsc{Hash}(a)

15: end for

16: for all

(a,b)\in L_{vc}

17:

h\leftarrow g||\textsc{Hash}(a)||\textsc{Hash}(b)

18: end for

19: if

h\_collector[msg.sender]\neq h

then

\triangleright

Check validity

20: throw

21: end if

22:

unverified\_elements[msg.sender]\leftarrow L_{vc}

23:

unverified\_sk[msg.sender]\leftarrow L_{sk}

24:end function

The function Prove and related state variables are defined as follows:

1.

$verified\_elements$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its list of verified group elements in $e^{\prime}$
2.

$verified\_sk$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority $\bm{AA}$ to its list of verified elements in $PK_{ind}$
3.

$counter$ (State Variable): An integer counter initialized to $0$ . It is used to track the number of valid attribute authorities.
4.

$index$ (State Variable): A mapping collection from the blockchain address belonged to one attribute authority to its index $i$

Algorithm 14 Contract

SC_{auth}

: Part 3

25:function Prove(

L_{\pi}

)

26: if

unverified\_elements[msg.sender]==[]

block.timestamp<ddl_{1}^{\prime}

block.timestamp>ddl_{2}^{\prime}

then

27: throw

28: end if

29:

L_{e^{\prime}}\leftarrow unverified_{e}lements[msg.sender]

30:

L_{tmp}\leftarrow[]

31: for all

(a,b)\in L_{e^{\prime}}

32: if not SameRatio(

a,b

) then

33: throw

34: end if

35:

L_{tmp}

.add

(a)

36: end for

37:

L_{sk}\leftarrow unverified_{s}k[msg.sender]

38:

L_{tmp}\leftarrow L_{tmp}||L_{sk}

39: for all

i\leftarrow 0,5

40:

rp\leftarrow L_{tmp}[i]

41:

h_{tmp}\leftarrow h\_collector[msg.sender]||

Hash(

rp

)

42: if not CheckPoK(

rp,L_{\pi}[i],h_{tmp}

) then

43: throw

44: end if

45: end for

46:

verified\_elements[msg.sender]\leftarrow L_{e^{\prime}}

47:

unverified\_elements[msg.sender]\leftarrow[]

48:

verified\_sk[msg.sender]\leftarrow L_{sk}

49:

verified\_sk[msg.sender]\leftarrow[]

50:

counter\leftarrow counter+1

51:

index[msg.sender]\leftarrow counter

52:end function

The function Setup 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\neq j,i,j\in[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

Algorithm 15 Contract

SC_{auth}

53:function Generate(

O,\theta,O^{\prime},l

)

54: if

msg.sender\notin AAlist

block.timestamp>ddl

then

\triangleright

Requirement check

55: throw

56: end if

57:

rp_{z},rp_{\alpha_{z}},rp_{\alpha_{z}z}\leftarrow verified\_elements[msg.sender]

58:

i\leftarrow index[msg.sender]

59: for

j\leftarrow 0,n-1

60: if

i==j

then

61: continue

62: end if

63:

check1\leftarrow\textsc{SameRatio}((rp_{z}[1],O[j]),rp_{z})

64:

check2\leftarrow\textsc{SameRatio}((rp_{\alpha}[1],\theta[j]),rp_{\alpha_{z}})

65:

check3\leftarrow\textsc{SameRatio}((rp_{\alpha_{z}z}[1],O^{\prime}[j]),rp_{\alpha_{z}z})

66: if

check1==check2==check3==

true then

67:

verified\_O[msg.sender]\leftarrow O

68: else

69: throw

70: end if

71: end for

72:

attribute\_size[msg.sender]\leftarrow l

73:end function

VIII-C User Registration Contracts

Function user_register and the state variable $collector$ are defined as following:

1.

$collector$ (State Variable): A mapping collection from the $addr_{DU}$ of $DU$ to the value of global identifier $GID$

Algorithm 16 Contract

SC_{reg}

1:function user_register

2: if

msg.value\leq 1000000

then

\triangleright

Registration fee around 1 USD

3: throw

4: end if

GID\leftarrow Hash(msg.sender)

collector[msg.sender]\leftarrow GID

\triangleright

Assign unique GID

7:end function

VIII-D Utility Function Contracts

The three main functions Hash, SameRatio and CheckPoK are defined as following:

Algorithm 17 Contract

SC_{utils}

: Part 1

1:function Hash(

m

)

2: Divide

m

in small pieces of message blocks

msgs

h\leftarrow IV

\triangleright

Pre-defined Initialization Vector

4: for all

msg\in msgs

args\leftarrow

abi.encodePacked

(12,h,msg,\dots)

6: Assembly

success\leftarrow

staticcall

(\mathtt{0x09},args,h)

8: if

success==0

then

9: revert

(0,0)

10: end if

11: End

12: end for

13: return

h

14:end function

Algorithm 18 Contract

SC_{utils}

: Part 2

15:function SameRatio(

rp1,rp2

)

16:

input\leftarrow(-rp1[0],rp2[1],rp1[1],rp2[0])

17: Assembly

18:

success\leftarrow

staticcall

(\mathtt{0x08},input,output)

19: if

success==0

then

20: revert

(0,0)

21: end if

22: End

23: return true

24:end function

Algorithm 19 Contract

SC_{utils}

: Part 3

25:function CheckPoK(

rp_{s},\pi_{s},h_{s}

)

26:

c\leftarrow

Hash

(\pi_{s}[0]||h_{s})

27:

input_{1}\leftarrow(rp_{s}[0],\pi_{s}[1])

\triangleright

u\cdot f

28:

input_{2}\leftarrow(rp_{s}[1],c)

\triangleright

c\cdot H

29: Assembly

30:

success_{1}\leftarrow

staticcall

(\mathtt{0x07},input_{1},result_{1})

31:

success_{2}\leftarrow

staticcall

(\mathtt{0x07},input_{2},result_{2})

32: if

success_{1}\times success_{2}==0

then

33: revert

(0,0)

34: end if

35:

input_{3}\leftarrow(\pi_{s}[0],result_{2})

\triangleright

R+c\dot{H}

36:

success_{3}\leftarrow

staticcall

(\mathtt{0x06},input_{3},result_{3})

37: if

success_{3}==0

then

38: revert

(0,0)

39: end if

40: End

41:

output\leftarrow(result_{1}==result_{3})

42: return

output

43:end function