A Challenge-Response Assisted Authorisation Scheme for Data Access in Permissioned Blockchains

Abstract

Permissioned blockchains can be applied for sharing data among permitted users to authorise the data access requests in a permissioned blockchain. A consensus network constructed using pre-selected nodes should verify a data requester’s credentials to determine if he or she have the correct permissions to access the queried data. However, current studies do not consider how to protect users’ privacy for data authorisation if the pre-selected nodes become untrusted, e.g., the pre-selected nodes are manipulated by attackers. When a user’s credentials are exposed to pre-selected nodes in the consensus network during authorisation, the untrusted (or even malicious) pre-selected nodes may collect a user’s credentials and other private information without the user’s right to know. Therefore, the private data exposed to the consensus network should be tightly restricted. In this paper, we propose a challenge-response based authorisation scheme for permissioned blockchain networks named Challenge-Response Assisted Access Authorisation (CRA³) to protect users’ credentials during authorisation. In CRA³, the pre-selected nodes in the consensus network do not require users’ credentials to authorise data access requests to prevent privacy leakage when these nodes are compromised or manipulated by attackers. Furthermore, the computational burden on the consensus network for authorisation is reduced because the major computing work of the authorisation is executed by the data requester and provider in CRA³.

1. Introduction

Permissioned blockchain networks stem from blockchain [1,2] as a decentralised network structure used for trading or sharing data among permitted users (nodes). Permissioned blockchain networks have been applied in numerous fields, including security services [3,4], Internet of Things (IoT) [5,6], and reputation systems [7,8]. In a permissioned blockchain network, there are numerous pre-selected nodes that constitute the consensus network to realise authorisation that tolerate Byzantine faults, avoiding a single point of failure and providing system scalability [9,10].

In current studies, pre-selected consensus nodes are normally assumed to be trusted in order to authorise the data access and to transport users’ private data in a consensus network [11]. However, one important issue that has not been considered is that users’ private data can be utilised by the pre-selected nodes in the consensus network during authorisation, since these nodes may be manipulated by the attacker to be untrusted (malicious). To be specific, in many current designs of authorisation for permissioned blockchains [10,12], the nodes in a consensus network require the use of many users’ private information (e.g., credentials and personal information) to authorise their data access requests. When some nodes are compromised by an attacker, the users’ private information can be disclosed to an attacker without any barriers.

Furthermore, if pre-selected nodes in the consensus network are malicious, such nodes can exploit a user’s private data to analyse his or her behaviour without such a user’s right to know that this violates their privacy. For example, when a permissioned blockchain network is applied to smart power grids or smart charging, the behaviour of the registered user can be analysed based upon the uploading time and length of his or her electric bills if the nodes are malicious or compromised in the consensus network [13,14]. Similarly, in an eHealth scenario, a patient’s private information could be leaked with respect to the above situation.

However, research regarding privacy protection for authorisation in a permissioned blockchain is currently in its infancy. Many studies does not consider how to protect users’ private information during authorising data access in permissioned blockchains, as they regard the consensus network (pre-selected nodes) as a fully trusted part. Even though some recent studies (e.g., [15]) start to raise concerns protecting users’ private information in the authorisation of a permissioned blockchain, such methods may leak users’ private information to particular nodes in the consensus network of the permissioned blockchain. Therefore, in a permissioned blockchain, the protection of users’ private information is still an open problem to be addressed for the authorisation of data access by the untrusted consensus network.

In this paper, our major novelty lies in considering privacy protection for the requisite authorisation so as to avoid privacy leakage when some nodes of the consensus network are untrusted (malicious or compromised) in a permissioned blockchain. A Challenge-Response Assisted Access Authorisation (CRA³) scheme based on the challenge-response mechanism is proposed to protect users’ private information during the authorisation for data access. The contributions of this paper are summarised as follows.

• Unlike many mainstream designs [10,12,16] that cannot protect users’ private information in the authorisation, CRA³ can realise authorisation without revealing the access permissions and other private information of users to nodes in the consensus network and keep users anonymous in the permissioned blockchain because we consider the consensus network as untrusted.
• A theoretical security model and proof are illustrated formally to show that CRA³ can achieve the confidentiality of indistinguishability under chosen-ciphertext attacks (IND-CCA) [17] to avoid privacy leakage during the authorised data access in a permissioned blockchain.
• Compared with [12,16], the communication overhead decreases because the size of the information needed for the authorisation is much smaller in our designed algorithms.
• Most of the computing work for authorising the data access request is executed by the data requester and provider to decrease the transaction cost and the burden on the consensus network.

The rest of this paper is organised as follows. The related work is presented in Section 2 and the preliminaries are introduced in Section 3 to help understand our concrete algorithms for our CRA³ scheme. Then, the problem we try to solve and the algorithm definitions of our CRA³ scheme are described in Section 4. After that, our proposed CRA³ scheme is demonstrated in Section 5, followed by a theoretical security analysis in Section 6. Furthermore, the experiments and the comparison of the results are demonstrated in Section 7 to analyse the performance of CRA³ in terms of the computational time consumption, the communication overhead, and the transaction fee for authorisation. Finally, we conclude our work in Section 8.

2. Related Work

The authors in [12] presented a personal data transmission scheme via blockchain consensus networks. In their scheme, the stored personal data are transmitted by a blockchain with constructed access policies to authorise data access via a consensus network. As they regard the consensus network as a trusted network, all of the users’ private data (including access permissions) are exposed to the consensus network in their scheme. If some nodes in the consensus network are compromised, the transmitted personal data can be revealed to attackers. The Healthcare Data Gateways scheme (HDG) [16] has a similar issue in the gateway (consensus part) design; users’ access tokens can be accessed via the gateway without any secure precaution.

Reference [18] discusses several applications of blockchain in IoT scenarios have been discussed including wireless software updates, smart charging, and car sharing services. However, there is no consideration for privacy protection in the consensus network when blockchains are applied to the above scenarios. A transaction framework for permissioned blockchains with a group policy was proposed, but the group policy was determined only by computing power without any data access control for users [19].

In the smart grid area, the authors in [20] proposed how to build permissioned blockchain networks for bill collection and power load adjustment. There are two reasons for utilising permissioned blockchain networks: first, the decentralisation feature of blockchain can achieve a fail-safe state to avoid a single point of failure; second, the structure of permissioned networks can block unauthenticated and unauthorised access. However, when some nodes are manipulated by the attackers in a consensus network, the solution to avoid privacy leakage is not discussed. More recently, an energy trading system supported by a permissioned blockchain was proposed by Gai et al. [15], where message validation was considered for a scenario of smart grids. The authors utilised group signature [21] to construct an identity validation algorithm to validate the edge nodes (and their messages) during the activities defined by the smart contracts. However, for the process of identity validation, the leader of the permissioned nodes knows the real identity of each node in the system setup phase. Meanwhile, this trading system can only ensure data integrity (signature) of messages but cannot provide confidentiality protection because messages between two edge nodes are plain to all permissioned nodes without any encryption. Furthermore, the issue of key revocation [22,23] is quite complicated and is not considered in such a large-scale decentralised system [24].

3. Preliminaries

3.1. Permissioned Blockchain Networks

The network structure of a permissioned blockchain shown in Figure 1 is the same as that of a public blockchain. All the nodes are anonymous in the network. However, the data (ledger) in each node are private, which means the data access between the two nodes should be authorised to ensure one node has the permissions to access the data in another node.

Meanwhile, the private ledger of each node is a blockchain structure. Each block contains data, a cryptographic hash value (h) and a timestamp (ts) in the blockchain [1]. The hash value for establishing the link between two blocks is generated by the following rules:

$$h_i=\left\{\begin{array}{cc}Hash\left(dat{a}_1\right|\left|t{s}_1\right)& ,i=1\hfill \\ Hash\left(h_{i-1}\right|\left|dat{a}_i\right|\left|t{s}_i\right)& ,i=2,\dots ,n\hfill \end{array}\right.$$

3.2. Lagrange Interpolating Polynomial

Let q be a prime and

$$f\left(x\right)=a_0+a_{1}x+\dots +a_{t-1}{x}^{t-1}\left(modq\right)$$

with a polynomial of degree t, where $a_0,a_1,\dots a_t\in {\mathbb{Z}}_q$ are coefficients. Given any t points $\{(x_1,y_1),\dots ,(x_t,y_t)\}$ on $f\left(x\right)$, the coefficient $a_0=f\left(0\right)$ can be computed with Lagrange interpolating polynomial

$$f\left(0\right)=\sum _{i\in A}{\mathsf{\Delta }}_i{y}_i\left(modq\right),$$

where ${\mathsf{\Delta }}_i={\displaystyle \prod _{j\in A/\left\{i\right\}}}\frac{x_j}{x_j-x_i}\left(modq\right)$ are the Lagrange interpolation coefficients and $A=\{1,2,\dots ,t\}$. Note that $f\left(x\right)$ can be reconstructed with any t points based on polynomial theory; however, $f\left(x\right)$ cannot be reconstructed ($f\left(0\right)$ cannot be computed either) with any points fewer than t [25].

4. Problem and Definitions

In this section, we first describe our scheme model and the targeted security problem we try to address. Then, seven algorithms are defined to construct our proposed CRA³ scheme in the second part, which is followed by the security definitions including the correctness and confidentiality of our CRA³ as the last part.

4.1. Problem Statement

The proposed scheme model is demonstrated in Figure 2 with three entities: two users (nodes) and the consensus network (constructed by pre-selected nodes in the permissioned blockchain network), denoted by $U_A$ (data requester), $U_B$ (data provider) and $C{N}_{pm}$, respectively. Since all the nodes in the network are anonymous (unknown identities), one node cannot trust another node in the permissioned blockchain network. Therefore, the consensus network $C{N}_{pm}$ is needed as a mediator to finish the validations in the challenge-response phase. If $U_A$ has the correct permissions to access his/her requested data, $U_B$ establishes a secret channel with $U_A$ to transport the encrypted data after the authorisation.

Since the nodes in $C{N}_{pm}$ are assumed to be untrusted, one untrusted node can output the incorrect result of the authorisation and collect the user’s private data from the communication in the challenge-response phase. If a node outputs the incorrect authorisation result, the consensus network can punish this dishonest node according to the applied consensus mechanism (e.g., Byzantine fault tolerance). On the other hand, if a malicious node collects the user’s data from the challenge-response communication and then attempts to reveal the user’s credentials (or other private information), our proposed scheme should prevent the private data leakage. Hence, the purpose of our proposed scheme is to authorise data access without involving the users’ credentials ($U_{id}=\{U_1,U_2,\dots ,U_n\}$) whilst ensuring the transported data is confidential, i.e., $\forall M\in {\{0,1\}}^{\ast },C=f\left(M\right)$, and any probabilistic polynomial-time algorithm $\mathcal{A}$ computes M or $U_{id}$ with its advantage $Ad{v}_{\mathcal{A}}^{C{N}_{pri}}=Pr[c=M\vee c\subseteq U_{id}|c=\mathcal{A}(C,D_{Ch},D_{Re})]<\epsilon$, where M is plaintext data, C is encrypted data that transmitted between $U_A$ and $U_B$, $D_{Ch}$ and $D_{Re}$ denote the data used in the processes Challenge and Response, respectively, and $\epsilon$ represents a negligible probability.

4.2. Scheme Definitions

In this section, we introduce the credentials used in the authorisation and define all of the seven algorithms that comprise our proposed CRA³ scheme.

Credentials for authorisation: The credentials used for authorisation are the identity attributes. For instance, in the hospital scenario, if a doctor wants to request a patient’s medical records, the identity attributes can be the patient’s name, age, medical record number, social number, and so on. We assume that in reality, the patient has shared the identity attributes and a unique reference number to identify the needed identity attributes for the doctor’s data request before inquiring about the data. We denote unique reference number (key) and the identity attributes (values) by $Rn$ and the sequence $A{T}^v=\{A{T}_1^v,A{T}_2^v,\dots ,A{T}_n^v\}$, respectively.

• Setup ($\lambda$): This algorithm takes the security parameter $\lambda$ and generates the public parameter $pp$.
• Request ($pp$): $U_A$ uses the algorithm to send a data access request Q to $U_B$ via $C{N}_{pm}$.
• Challenge ($pp,Q$): $U_B$ constructs and sends the challenge $Ch$ to $U_A$ with the identity attributes sequence $A{T}^v$.
• Response ($pp,Ch$): $U_A$ uses its own sequence $A{T}^{\prime v}$ to calculate and send the response $Re$ to the $C{N}_{pm}$.
• Authorise ($Ch$, $Re$): $C{N}_{pm}$ validates the correctness of the response $Re$ based upon the challenge $Ch$.
• Encrypt ($pp,M,A{T}^v$): $U_B$ uses this algorithm to encrypt the requested data M then return the ciphertext C and a point P (for decryption use) to $U_A$.
• Decrypt ($pp,C$, P, $A{T}^{\prime v}$): $U_A$ decrypts the encrypted data C to retrieve the requested data M with the given point P.

4.3. Security Definition

The definitions of correctness and the IND-CCA (indistinguishability under chosen-ciphertext attacks) security (confidentiality) for our CRA³ scheme are illustrated as follows.

4.3.1. Correctness

For any $pp\leftarrow$Setup(λ) and any plaintext $M\in {\{0,1\}}^{\ast }$, the CRA³ scheme is correct if $Decrypt(pp,C,A{T}^{\prime v})=M$ always holds, where $C=Encrypt(pp,M,A{T}^v)$.

4.3.2. Confidentiality (IND-CCA Security)

Formally, the adversary defined to prove the theoretical security of our proposed CRA³ scheme is: Type-IND adversary.

Type-IND adversary: In the Authorise phase, the adversary cannot determine the message that the given challenge ciphertext is encrypted from, even though the sequence of the identity attributes $A{T}^v$ is revealed to the adversary.

Game 1.Let ${\mathcal{A}}_1$ be the given Type-IND adversary, and the index of the target data provider be t $(1⩽t⩽n)$. The game played by the challenger $\mathcal{C}$ and the adversary ${\mathcal{A}}_1$ is described with the following five phases:

• Initialise:
  $\mathcal{C}$ first generates the public parameter $pp$ via running the algorithm $Setup$. Then, $\mathcal{C}$ generates n data providers (key-value pairs) $\{R{n}^i,A{T}^{v_i}\}(1⩽i⩽n)$ and the target data provider is $\{R{n}^t,A{T}^{v_t}\}$. The generated $pp$ and all $R{n}^i(1⩽i⩽n)$ are given to the adversary ${\mathcal{A}}_1$.
• Queries:
  The following queries can be requested by ${\mathcal{A}}_1$ for polynomial times in the game:
  • Identity attributes query $\left(i\right)$: $\mathcal{C}$ responds with the sequence of the random identity attributes $rA{T}^{v_i}$;
  • Encrypt query$(M,i)$: $\mathcal{C}$ outputs the ciphertext $C=Encrypt(pp,M,A{T}^{v_i})$ and the point P on the constructed polynomial $f\left(x\right)$ in the Encrypt phase;
  • Decrypt query$(C,P,i)$: $\mathcal{C}$ decrypts C via running the algorithm Decrypt, then responds with the plain message.
• Challenge:
  ${\mathcal{A}}_1$ submits two equal-length messages $M_0^{\ast }$ and $M_1^{\ast }$. $\mathcal{C}$ picks $\rho {\in }_R\{0,1\}$, and then computes and returns the challenge ciphertext $C^{\ast }=Encrypt(pp,M_{\rho }^{\ast },A{T}^{v_i})$.
• Constraints:
  • $(M_0^{\ast },t)$ and $(M_1^{\ast },t)$ are not allowed to appear in the above Encrypt query;
  • The target data provider’s index t and the challenge ciphertext $C^{\ast }$ are not allowed to appear in the above Decrypt query.
• Guess:
  ${\mathcal{A}}_1$ can win the game if its output ${\rho }^{\prime }{\in }_R\{0,1\}$ satisfies the condition $\rho ={\rho }^{\prime }$.
  Now, the advantage of ${\mathcal{A}}_1$ could be defined as:

  $$Ad{v}_{{\mathcal{A}}_1}^{IND-CCA}\left(\lambda \right)=|Pr[\rho ={\rho }^{\prime }]-\frac{1}{2}|.$$

Note that the probability analysis is presented after the Guess phase in the formal confidentiality proof of our CRA³ scheme.

Definition 1

(IND-CCA Security). The CRA³ scheme is IND-CCA secure if the advantage $Ad{v}_{{\mathcal{A}}_1}^{IND-CCA}\left(\lambda \right)$ of any probabilistic polynomial-time adversary ${\mathcal{A}}_1$ is negligible.

5. Proposed Scheme CRA³

In this section, we illustrate our proposed CRA³ scheme (Challenge-Response Assisted Access Authorisation) with the seven algorithms defined in Section 4.2, including Setup, Request, Challenge, Response, Authorise, Encrypt, and Decrypt. In CRA³, AES (Advanced Encryption Standard [26]) is used to encrypt the requested data and the Lagrange interpolating polynomial is utilised to construct challenge-response authorisation and protect the encrypting/decrypting key of AES.

• Setup ($\lambda$):
  This procedure outputs public parameters $pp$ with the security parameter $\lambda$ using the following steps.
  • Generate a big prime q ($q>2^{\lambda }$);
  • Select one secure cryptographic hash function $H:{\{0,1\}}^{\ast }\to {\{0,1\}}^{\lambda }$;
  • Select a symmetric encryption algorithm, e.g., $AES$ (Advanced Encryption Standard);
  • Output the public parameters $pp=(q,H,AES)$.
• Request ($pp$):
  The user $U_A$ (data inquirer) prepares the query Q via the following steps.
  • Decide on the data to be requested. Note that $U_A$ should have the corresponding identity attributes (a sequence, $A{T}^{\prime v}$) and the unique reference number ($R_n)$ that is shared by $U_B$. For illustrating the remaining parts of the proposed scheme, we assume the requested data is in one block $B_{id}$;
  • Prepare the unique reference number $Rn$ then send the request $Q=(B_{id},Rn)$ to $U_B$ through $C{N}_{pm}$.
• Challenge ($pp,Q$):$U_B$ generates the challenge $Ch$ based upon the request Q from $U_A$ via the following steps.
  • Prepare the sequence of the identity attributes (values): $A{T}^v=\{A{T}_1^v,A{T}_2^v,\dots ,A{T}_n^v\}$ based upon the unique reference number $Rn\in Q$;
  • Calculate the hash value of each element in the sequence $A{T}^v$ to get the sequence $A{H}^v=\{H\left(A{T}_1^v\right),H\left(A{T}_2^v\right),\dots ,H\left(A{T}_n^v\right)\}$;
  • Construct a polynomial $f\left(x\right)=H\left(A{T}_1^v\right)+H\left(A{T}_2^v\right)x+\dots +H\left(A{T}_n^v\right)x^{n-1}\left(modq\right)$, then pick n random points on the polynomial $f\left(x\right)$ as a set: $P=\left\{(x_i,y_i)\right|(x_i,y_i)\in f\left(x\right)\wedge i=1\dots n\}$;
  • Construct two sequences $P_x$ and $P_y$ of all the $x_i$ and all the $y_i$ in P: $P_x=\left\{x_i\right|x_i\in f\left(x\right)\wedge (x_i,f\left(x_i\right))\in P\wedge i=1\dots n\}$ and $P_y=\left\{y_i\right|y_i=f\left(x_i\right)\wedge x_i\in P_x\wedge i=1\dots n\}$;
  • Calculate the hash value of the sequence $P_y$: $P{H}_y=H(y_1,y_2,\dots ,y_n),y_1,y_2,\dots ,y_n\in P_y$;
  • Send the challenge $P_x$ to $U_A$ through $C{N}_{pm}$. Note that $C{N}_{pm}$ should keep the $Ch=\left(P{H}_y\right)$ to execute the following Authorise phase.
• Response ($pp,Ch$):
  $U_A$ generates the response $Re$ to the challenge $P_x$ from $U_B$ via the following steps.
  • Prepare the sequence of the identity attributes $A{T}^{\prime v}=\{A{T}_1^{\prime v},A{T}_2^{\prime v},\dots ,A{T}_n^{\prime v}\}$ (shared by $U_B$) based upon $R_n\in Q$;
  • Construct a new polynomial $g\left(x\right)=H\left(A{T}_1^{\prime v}\right)+H\left(A{T}_2^{\prime v}\right)x+\dots +H\left(A{T}_n^{\prime v}\right)x^{n-1}\left(modq\right)$;
  • Take $P_x\in Ch$ to calculate the sequence $P_y^{\prime }=\left\{y_i^{\prime }\right|y_i^{\prime }=g\left(x_i\right)\wedge x_i\in P_x\wedge i=1\dots n\}$ and then hash the sequence $P_y^{\prime }$: $P{H}_y^{\prime }=H(y_1^{\prime },y_2^{\prime },\dots ,y_n^{\prime }),y_1^{\prime },y_2^{\prime },\dots ,y_n^{\prime }\in P_y^{\prime }$;
  • Send the response $Re=\left(P{H}_y^{\prime }\right)$ to the consensus network $C{N}_{pm}$.
• Authorise ($Ch,Re$):
  The consensus network $C{N}_{pm}$ validates the two hash values in $Ch$ and $Re$. If $P{H}_y(\in Ch)=P{H}_y^{\prime }(\in Re)$ holds (consensus check point), it means that the user $U_A$ can be authorised to access the requested data $B_{id}$ and the next phases are conducted; otherwise, the agent layer should deny the access request from $U_A$.
• Encrypt ($pp,Q,A{T}^v$):
  $U_B$ encrypts the requested data via the following steps.
  • Acquire the requested data M based upon $B_{id}\in Q$ from $U_A$ and then calculate the hash value $H_M$ of the data M: $H_M=H\left(M\right)$;
  • Generate a secure key $k\in {\mathbb{Z}}_q$ for the symmetric encryption;
  • Use $AES$ to encrypt M with key k to get the ciphertext $C=AE{S}_k(M,H_M)$. For decrypting $AE{S}_k(M,H_M)$ to recover the plain data M, $AE{S}_k^{\prime }$ is defined as the decryption process: $M=AE{S}_k^{\prime }(C=AE{S}_k(M,H_M))$;
  • Follow Section 3.2 to construct a polynomial $f^{\ast }\left(x\right)$ of degree n with k and $A{T}^v$: $f^{\ast }\left(x\right)=k+H\left(A{T}_1^v\right)x+H\left(A{T}_2^v\right)x^2+\dots +H\left(A{T}_n^v\right)x^n\left(modq\right)$;
  • Generate a random integer $x_p\in {\mathbb{Z}}_q$ and calculate a point $P(x_p,y_p=f^{\ast }\left(x_p\right))$;
  • Return $(C,P)$ to $U_A$ through a secret channel.
• Decrypt ($pp,C,P,A{T}^{\prime v}$):
  $U_A$ can decrypt the ciphertext C after passing the Authorise phase via the following steps.
  • Use the sequence $A{T}^{\prime v}$ organised in the former Response phase to construct a polynomial $g^{\ast }\left(x\right)$: $g^{\ast }\left(x\right)=a_0+H\left(A{T}_1^{\prime v}\right)x+H\left(A{T}_2^{\prime v}\right)x^2+\dots +H\left(A{T}_n^{\prime v}\right)x^n\left(modq\right)$. Note that $a_0$ is an unknown coefficient;
  • Follow the Lagrange interpolation polynomial in the Section 3.2 to reconstruct the polynomial $g^{\ast }\left(x\right)$ fully, and then recover the key $k=g\left(0\right)=a_0\in {\mathbb{Z}}_q$ for $AES$ decryption with the point $P(x_p,y_p)$: $k=y_p-H\left(A{T}_1^{\prime v}\right)x_p-H\left(A{T}_2^{\prime v}\right)x_p^2-\dots -H\left(A{T}_n^{\prime v}\right)x_p^n\left(modq\right)$;
  • Decrypt C to retrieve the plaintext $(M,H_M)=AE{S}_k^{\prime }\left(C\right)=AE{S}_k^{\prime }\left(AE{S}_k(M,H_M)\right)$;
  • If $H\left(M\right)=H_M$ holds, this algorithm outputs M; otherwise, it outputs ⊥.

6. Theoretical Analysis of CRA³

In this section, we first show the correctness of our proposed authorisation CRA³ scheme and then prove the confidentiality of CRA³. After that, the (data) integrity of CRA³ is illustrated in the third subsection, which is followed by a comparison of the security features in different blockchain-related authorisation schemes, as given in the last subsection.

6.1. Correctness

In the Authorise phase, if the data requester has the correct sequence of the identity attributes $A{T}^{\prime v}$, the condition $A{T}^v=A{T}^{\prime v}$ holds,

$A{T}^v=A{T}^{\prime v}$

$\iff \{H\left(A{T}_1^v\right),H\left(A{T}_2^v\right),\dots ,H\left(A{T}_n^v\right)\}=\{H\left(A{T}_1^{\prime v}\right),H\left(A{T}_2^{\prime v}\right),\dots ,H\left(A{T}_n^{\prime v}\right)\}$

$\iff f\left(x\right)=g\left(x\right)$

$\iff P_y=P_y^{\prime }\left(forthegiven{P}_x\right)$

$\iff P{H}_y=P{H}_y^{\prime }$.

This means that the data requester can pass the Authorise phase if and only if this requester has the correct corresponding sequence of the identity attributes for the requested blocks.

To satisfy the condition in the correctness definition, the authorised data requester should retrieve the key $k\in {\mathbb{Z}}_q$ for $AES$ decryption with the given point $P(x_p,y_p)$ on the polynomial $f\left(x\right)$ in the Decrypt phase. Meanwhile, P should present on the correct reconstructed polynomial as well. Since the condition $\{H\left(A{T}_1^v\right),H\left(A{T}_2^v\right),\dots ,H\left(A{T}_n^v\right)\}=\{H\left(A{T}_1^{\prime v}\right),H\left(A{T}_2^{\prime v}\right),\dots ,H\left(A{T}_n^{\prime v}\right)\}$ holds after the Authorise phase, the reconstructed polynomial $g\left(x\right)$ is the same as the original polynomial $f\left(x\right)$ except for the unknown first coefficient $a_0=k$. Therefore, determining the secret key $g\left(0\right)=a_0=k\in {\mathbb{Z}}_q$ for $AES$ decryption requires only one point (shareholder) $P(x_p,y_p)$:

$k=a_0$

$=g\left(x_p\right)-A{T}_1^{\prime v}{x}_p-A{T}_2^{\prime v}{x}_p^2-\dots -A{T}_n^{\prime v}{x}_p^n$

$=f\left(x_p\right)-A{T}_1^{\prime v}{x}_p-A{T}_2^{\prime v}{x}_p^2-\dots -A{T}_n^{\prime v}{x}_p^n$

$=f\left(x_p\right)-A{T}_1^v{x}_p-A{T}_2^v{x}_p^2-\dots -A{T}_n^v{x}_p^n$

$=k\left(modq\right)$.

Hence, the authorised data requester can reconstruct the polynomial $g\left(x\right)$ and restore the correct key k in the Decrypt phase to ensure $Decrypt(pp,C,A{T}^{\prime v})=M$ holds, where $C=Encrypt(pp,M,A{T}^v)$.

6.2. Confidentiality (IND-CCA Security)

Theorem 1.

According to Definition 1 above, the proposed CRA³ scheme is IND-CCA secure based on the Lagrange interpolating polynomial against the type-IND adversary in the random oracle model.

To be specific, let γ be a random oracle and ${\mathcal{A}}_1$ be a Type-IND adversary with the advantage $Ad{v}_{{\mathcal{A}}_1}^{IND-CCA}$ against our proposed scheme. Hypothetically, ${\mathcal{A}}_1$ requests a total of $Q_{\gamma }>0$ queries to the oracle γ; then there is an algorithm $\mathcal{C}$ that can determine all the correct coefficients for the given Lagrange interpolating polynomial with the advantage of at least $\frac{2}{Q_{\gamma }}Ad{v}_{{\mathcal{A}}_1}^{IND-CCA}$.

Proof. 

A polynomial $f\left(x\right)$ with the sequence of the identity attributes $A{T}^{v_i}=\{A{T}_1^{v_i},A{T}_2^{v_i},\dots ,A{T}_n^{v_i}\}(1⩽i⩽n)$ and a secure hash function $H:{\{0,1\}}^{\ast }\to {\{0,1\}}^{\lambda }$ consist of an instance of the Lagrange interpolating polynomial, where $f\left(x\right)=a_0^i+H\left(A{T}_1^{v_i}\right)x+H\left(A{T}_2^{v_i}\right)x^2+\dots +H\left(A{T}_n^{v_i}\right)x^n$. The target data provider’s index is defined as t$(1⩽t⩽n$). The challenger $\mathcal{C}$ aims to determine $A{T}^{v_t}$ via executing ${\mathcal{A}}_1$ as the subroutine. Next, $\mathcal{C}$ and ${\mathcal{A}}_1$ play the game defined in Section 4.3.2.

• Initialise
  $\mathcal{C}$ first generates the public parameter $pp=(q,H,AES)$ and then sends $pp$ to ${\mathcal{A}}_1$. After that, $\mathcal{C}$ generates n data providers (key-value pairs) $\{R{n}^i,A{T}^{v_i}|1⩽i⩽n\}$ and the target data provider is denoted by $\{R{n}^t,A{T}^{v_t}\}$. Note that all the generated $R{n}^i(1⩽i⩽n)$ are given to the adversary ${\mathcal{A}}_1$. Finally, $\mathcal{C}$ initialises one empty lists $Lis{t}_{\gamma }$ and updates it continuously in the random oracle query Identity attributes query. If the same input is asked multiple times, the same answer will be returned.
• Queries
  $\mathcal{C}$ can respond to the queries requested by ${\mathcal{A}}_1$ polynomial times in the following ways.
  • Identity attributes query $\left(i\right)$: $\mathcal{C}$ generates the sequence of the identity attributes $rA{T}^{v_i}=\{rA{T}_1^{v_i},rA{T}_1^{v_i},\dots ,rA{T}_n^{v_i}\}$ randomly and saves $(i,rA{T}^{v_i})$ in $Lis{t}_{\gamma }$ if it is the first time that i is queried. Then $\mathcal{C}$ respond with the sequence $rA{T}^{v_i}$. Otherwise, $\mathcal{C}$ should retrieve the sequence $rA{T}^{v_i}$ from $Lis{t}_{\gamma }$ directly then return it to ${\mathcal{A}}_1$.
  • Encrypt query$(M,i)$: $\mathcal{C}$ uses the algorithm Encrypt to output the ciphertext $C=Encrypt(pp,M,A{T}^{v_i})$ and the point P (P should be on the polynomial constructed with $A{T}^{v_i}$ in the algorithm Encrypt).
  • Decrypt query$(C,P,i)$: $\mathcal{C}$ tries to decrypt C via running $Decrypt(pp,C,P,A{T}^{v_i})$ then responds with the plain message. Note that there is a conditional branch caused by i to be discussed.
  If $i=t$, for each item $(i,rA{T}^{v_i})$ in $Lis{t}_{\gamma }$, $\mathcal{C}$ executes the operations.

  −

  Reconstruct the Lagrange interpolating polynomial $g^{\ast }\left(x\right)$ with $rA{T}^{v_i}$ and P to determine the secret key $k=a_0$ for AES decryption.

  −

  Recover $(M,H_M)$ by computing $AE{S}_k^{\prime }\left(C\right)=AE{S}_k^{\prime }\left(AE{S}_k(M,H_M)\right)$.

  −

  If $H\left(M\right)=H_M$ holds, $\mathcal{C}$ returns M to ${\mathcal{A}}_1$. If there is no item in the $Lis{t}_{\gamma }$ that satisfies the condition, $\mathcal{C}$ returns ⊥ to ${\mathcal{A}}_1$.

  If $i\ne t$, $\mathcal{C}$ runs the $Decrypt(pp,C,P,A{T}^{v_i})$ algorithm directly and then sends the output to ${\mathcal{A}}_1$ as the answer.

• Challenge
  ${\mathcal{A}}_1$ submits two messages $M_1^{\ast },M_2^{\ast }\in {\{0,1\}}^{\lambda }$ with the same length to $\mathcal{C}$, then $\mathcal{C}$ picks one random bit $\rho$ from the set $\{0,1\}$. Finally, $\mathcal{C}$ computes the ciphertext $C^{\ast }$ of $M_{\rho }^{\ast }$ via the following steps:
  • Choose a secret key $k\in {\mathbb{Z}}_q$ for AES encryption and decryption;
  • Determine $f^{\ast }\left(x\right)=k+H\left(A{T}_1^{v_t}\right)x+H\left(A{T}_2^{v_t}\right)x^2+\dots +H\left(A{T}_n^{v_t}\right)x^n$;
  • Pick a random point $P^{\ast }(x^{\ast },f^{\ast }\left(x^{\ast }\right))$ on $f^{\ast }\left(x\right)$;
  • Compute $C^{\ast }=AE{S}_k(M_{\rho }^{\ast },H\left(M_{\rho }^{\ast }\right))$.
  Finally, $\mathcal{C}$ sends the ciphertext $C^{\ast }$ and the point $P^{\ast }$ to the adversary ${\mathcal{A}}_1$.
• Constraints
  • $(M_0^{\ast },t)$ and $(M_1^{\ast },t)$ are not allowed to appear in the above Encrypt query;
  • The target data provider’s index t and the challenge ciphertext $C^{\ast }$ are not allowed to appear in the above Decrypt query.
• Guess
  ${\mathcal{A}}_1$ outputs one bit ${\rho }^{\prime }$ from the set $\{0,1\}$. At the same time, $\mathcal{C}$ picks a random element $(i,rA{T}^{v_i})$ from $Lis{t}_{\gamma }$ as the answer to the above given instance of the Lagrange interpolating polynomial.
• Probability analysis
  An event $\mathcal{E}$ is defined as that the adversary ${\mathcal{A}}_1$ requests a query for the target sequence $A{T}^{v_t}$ in the Identity attributes query during the described game above. If the event $\mathcal{E}$ has happened, $A{T}^{v_t}$ occurs in at least one item of $Lis{t}_{\gamma }$ at the end of this game.

However, if $\mathcal{E}$ does not happen, it means that $Pr[{\rho }^{\ast }={\rho }^{{\ast }^{\prime }}|\neg \mathcal{E}]=\frac{1}{2}$ holds. Meanwhile, the condition $Ad{v}_{{\mathcal{A}}_1}^{IND-CCA}⩽|Pr[\rho ={\rho }^{\prime }]-\frac{1}{2}|$ holds because of the definition of the type-IND adversary (${\mathcal{A}}_1$). Based upon the above analysis, the next two derivations can be illustrated.

$$\begin{array}{cc}Pr[\phi ={\phi }^{\prime }]\hfill & =Pr[\phi ={\phi }^{\prime }|\mathcal{E}]Pr\left[\mathcal{E}\right]+Pr[\phi ={\phi }^{\prime }|\neg \mathcal{E}]Pr[\neg \mathcal{E}]\hfill \\ \hfill & ⩽Pr\left[\mathcal{E}\right]+Pr[\phi ={\phi }^{\prime }|\neg \mathcal{E}]Pr[\neg \mathcal{E}]\hfill \\ \hfill & =Pr\left[\mathcal{E}\right]+\frac{1}{2}Pr[\neg \mathcal{E}]\hfill \\ \hfill & =Pr\left[\mathcal{E}\right]+\frac{1}{2}(1-Pr\left[\mathcal{E}\right])\hfill \\ \hfill & =\frac{1}{2}+\frac{1}{2}Pr\left[\mathcal{E}\right]\hfill \\ Pr[\phi ={\phi }^{\prime }]\hfill & ⩾Pr[\phi ={\phi }^{\prime }|\neg \mathcal{E}]Pr[\neg \mathcal{E}]\hfill \\ \hfill & =\frac{1}{2}Pr[\neg \mathcal{E}]\hfill \\ \hfill & =\frac{1}{2}-\frac{1}{2}Pr\left[\mathcal{E}\right]\hfill \end{array}$$

Hence, we can deduce that the following derivation holds:

$$Ad{v}_{{\mathcal{A}}_1}^{IND-CCA}⩽|Pr[\rho ={\rho }^{\prime }]-\frac{1}{2}|⩽\frac{1}{2}Pr\left[\mathcal{E}\right].$$

We can simplify this derivation such that $Pr\left[\mathcal{E}\right]⩾2Ad{v}_{{\mathcal{A}}_1}.$

In conclusion, at the end of the game between the challenger $\mathcal{C}$ and the adversary ${\mathcal{A}}_1$, the probability of the target sequence $A{T}^{v_t}$ being in the element(s) of $Lis{t}_{\gamma }$ is at least $2Ad{v}_{{\mathcal{A}}_1}^{IND-CCA}$. Hence, the probability of generating the correct answer $\rho ={\rho }^{\prime }$ is at least $\frac{2}{Q_{\gamma }}Ad{v}_{{\mathcal{A}}_1}^{IND-CCA}$, where $Q_{\gamma }$ represents the total number of the elements in the list $Lis{t}_{\gamma }$. □

6.3. Data Integrity

In our CRA³ scheme, the hash value $H_M=H\left(M\right)$ generated in the Encrypt algorithm can provide the data integrity of M. In the Decrypt algorithm, if the received C or P is incorrect or manipulated by the attacker in the communication between $U_A$ and $U_B$, the wrong C (or P) leads to the abnormal result of AES decryption result so that $(M,H_M)=AE{S}_k^{\prime }\left(C\right)$ are incorrect (where $C=AE{S}_k(M,H_M)$ and k is computed from P. Therefore, the condition $H\left(M\right)=H_M$ (step 4) cannot hold, which means our data integrity check can detect an abnormal C or P to protect the data integrity of M.

6.4. Comparison of Security Features

In

Table 1. Comparison of the security features in different blockchain-related authorisation schemes.

Scheme	Blockchain Type	Consensus Network Type	Security Features
			Authorisation	Confidentiality	Integrity
[12]	Public/Permissioned	Trusted	√	× 1	× 1
[16]	Public	Trusted	√	×	×
[19]	Permissioned	Trusted	×	×	×
[15]	Permissioned	Trusted	√	×	√
CRA3 *	Permissioned	Trusted/Untrusted	√	√	√

¹ The scheme depends on the deployed database to support the mentioned security feature. * CRA³: our proposed scheme, Challenge-Response Assisted Access Authorisation.

, we compare the implemented security features of different blockchain-related authorisation schemes from the state-of-the-art of related work with that of our CRA³ scheme. It is clear that most of the compared schemes can support permissioned blockchains but CRA³ is the only one that can support an untrusted consensus network. Meanwhile, our CRA³ can also provide authorisation, confidentiality, and integrity for data access. However, in other compared schemes, the integrity feature is only implemented by [15] and no scheme considers confidentiality. The Decentralizing Privacy (DP) [12] scheme requires a database as a storage media; however, the DP scheme itself cannot support confidentiality or integrity.

7. Performance Evaluation and Results

The performance simulation and results are illustrated and discussed in this section. Two Raspberry Pi 2s [27] with Wi-Fi (as the mobile devices of the users $U_A$ and $U_B$) and one conventional computer with an Intel i5 processor running at 3.30 GHz (as a node of the consensus network in the permissioned blockchain) were used to perform the simulation. The local computational time efficiency for executing CRA³ was evaluated with respect to the time cost for transmitting encrypted data over Wi-Fi and the transaction fee (gas) of the consensus node in the simulation. Since there is yet no clear best practice to be used as a baseline for comparison, we selected an authorisation scheme for blockchain-based storage named Decentralizing Privacy (DP) [12] as our baseline. The authorisation supported by a trusted third party (TTP) in DP is policy-based but not anonymous, since the TTP knows the users’ identities. However, the designed authorisation in CRA³ is attribute-based and anonymous. Note that all the implemented experiments used the equivalent cryptographic security level (128-bit) [28], and that the transaction fee (gas) was calculated based upon the bytecodes generated by Ethereum Virtual Machine (EVM) [29] with PoA (Proof of Authority) [30] as the consensus mechanism.

First, the number of the attributes used for authorisation was varied from two to 10 in CRA³ (respective of policies in DP) to compare the time taken for local computation including authorisation, encryption, and decryption algorithms in the two schemes implemented on a conventional computer. The averaged results over 10 runs are shown in Figure 3. In the authorisation phase (Figure 3a), the time cost in both schemes increased with a similar trend when the number of attributes used was small. If the number of attributes used rose up to 10, our CRA³ scheme needed 25% more time to authorise the access when compared with the DP scheme. For the encryption and decryption phases, the time cost for the DP scheme kept stable whilst the time cost of the CRA³ scheme increased slowly, increasing with the number of attributes. On average, the time cost of the CRA³ scheme was 55% lower than that of the DP scheme; see Figure 3b,c.

Meanwhile, we measured the time cost for transporting data between users and $C{N}_{pm}$ (see Section 4.1) over Wi-Fi (Figure 4). The data included the attributes (i.e., policies) used for authorisation, the encrypted data (128 bytes) and the keys used for decryption in the two schemes. Since CRA³ only transmits two points in the Authorise phase whereas the DP scheme requires two policy lists for authorisation, the time consumption for transmitting data via Wi-Fi in CRA³ was about 24% lower than that in the DP scheme. Furthermore, the time cost in CRA³ had a lower growth rate when compared with the DP scheme.

Thus, we summarise the total time cost of both local computation and data transmission via Wi-Fi in Figure 5. The total time cost in CRA³ was around 30% lower than that in the DP scheme. While the number of used attributes (i.e., policies) increased, the DP scheme consumed far more time than CRA³, in total.

Finally, the transaction fee (gas) for the Authorise phase performed in the consensus network was evaluated in a conventional computer (Figure 6). While the transaction fee of CRA³ kept stable (and was non-sensitive to the variation of used attributes), the transaction fee increased by the number of used policies in the DP scheme. This is because the DP scheme compares two policy lists in the transaction for authorisation but CRA³ only compares two points regardless of the number of used attributes.

8. Conclusions

In this paper, we proposed a privacy-enhanced authorisation CRA³ scheme under a consideration of untrusted nodes occurring in a consensus network of permissioned blockchain. Unlike existing work [10,12,16], CRA³ does not expose users’ credentials to the untrusted nodes in the consensus network for authorising data access. By applying CRA³ in a permissioned blockchain, users (data providers) can share private data with valid data requesters without leaking their private information. Therefore, CRA³ can help people to safeguard their privacy and prevent potential privacy leakage (e.g., caused by attackers) in permissioned blockchains. In terms of the communication overhead, CRA³ reduces the time cost for the communication during the authorisation since the size of the required data for authorising data access request is much smaller when compared with other methods. Furthermore, our consensus verification only relies on one equation and other computational work is executed by the data requester and receiver; hence, the consensus cost (transaction fee) is visibly cut down to save the user’s cost and the computational resource of the consensus network (i.e., lower workload) simultaneously.