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

^{*}

## Abstract

**:**

^{3}) to protect users’ credentials during authorisation. In CRA

^{3}, 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

^{3}.

## 1. Introduction

^{3}) 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
^{3}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
^{3}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. - 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.

^{3}scheme. Then, the problem we try to solve and the algorithm definitions of our CRA

^{3}scheme are described in Section 4. After that, our proposed CRA

^{3}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

^{3}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

## 3. Preliminaries

#### 3.1. Permissioned Blockchain Networks

#### 3.2. Lagrange Interpolating Polynomial

## 4. Problem and Definitions

^{3}scheme in the second part, which is followed by the security definitions including the correctness and confidentiality of our CRA

^{3}as the last part.

#### 4.1. Problem Statement

#### 4.2. Scheme Definitions

^{3}scheme.

- 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

^{3}scheme are illustrated as follows.

#### 4.3.1. Correctness

^{3}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)

^{3}scheme is: Type-IND adversary.

**Game 1.**Let ${\mathcal{A}}_{1}$ be the given Type-IND adversary, and the index of the target data provider be t $(1\u2a7dt\u2a7dn)$. 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}}\}\phantom{\rule{4pt}{0ex}}(1\u2a7di\u2a7dn)$ and the target data provider is $\{R{n}^{t},A{T}^{{v}_{t}}\}$. The generated $pp$ and all $R{n}^{i}\phantom{\rule{4pt}{0ex}}(1\u2a7di\u2a7dn)$ 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}|.$$

^{3}scheme.

**Definition**

**1**

^{3}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^{3}

^{3}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

^{3}, 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}\phantom{\rule{4pt}{0ex}}\left(mod\phantom{\rule{4pt}{0ex}}q\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}),\phantom{\rule{4pt}{0ex}}{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}\phantom{\rule{4pt}{0ex}}\left(mod\phantom{\rule{4pt}{0ex}}q\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}),\phantom{\rule{4pt}{0ex}}{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}\phantom{\rule{4pt}{0ex}}\left(mod\phantom{\rule{4pt}{0ex}}q\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}\phantom{\rule{4pt}{0ex}}\left(mod\phantom{\rule{4pt}{0ex}}q\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}\phantom{\rule{4pt}{0ex}}\left(mod\phantom{\rule{4pt}{0ex}}q\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^{3}

^{3}scheme and then prove the confidentiality of CRA

^{3}. After that, the (data) integrity of CRA

^{3}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

#### 6.2. Confidentiality (IND-CCA Security)

**Theorem**

**1.**

^{3}scheme is IND-CCA secure based on the Lagrange interpolating polynomial against the type-IND adversary in the random oracle model.

**Proof.**

- 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\u2a7di\u2a7dn\}$ and the target data provider is denoted by $\{R{n}^{t},A{T}^{{v}_{t}}\}$. Note that all the generated $R{n}^{i}\phantom{\rule{4pt}{0ex}}(1\u2a7di\u2a7dn)$ 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 analysisAn 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.

#### 6.3. Data Integrity

^{3}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

^{3}scheme. It is clear that most of the compared schemes can support permissioned blockchains but CRA

^{3}is the only one that can support an untrusted consensus network. Meanwhile, our CRA

^{3}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

^{3}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

^{3}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.

^{3}(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

^{3}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

^{3}scheme increased slowly, increasing with the number of attributes. On average, the time cost of the CRA

^{3}scheme was 55% lower than that of the DP scheme; see Figure 3b,c.

^{3}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

^{3}was about 24% lower than that in the DP scheme. Furthermore, the time cost in CRA

^{3}had a lower growth rate when compared with the DP scheme.

^{3}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

^{3}, in total.

^{3}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

^{3}only compares two points regardless of the number of used attributes.

## 8. Conclusions

^{3}scheme under a consideration of untrusted nodes occurring in a consensus network of permissioned blockchain. Unlike existing work [10,12,16], CRA

^{3}does not expose users’ credentials to the untrusted nodes in the consensus network for authorising data access. By applying CRA

^{3}in a permissioned blockchain, users (data providers) can share private data with valid data requesters without leaking their private information. Therefore, CRA

^{3}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

^{3}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.

## Author Contributions

## Funding

## Acknowledgments

## Conflicts of Interest

## References

- Nakamoto, S. Bitcoin: A Peer-to-peer Electronic Cash System. Available online: https://nakamotoinstitute.org/bitcoin/ (accessed on 31 October 2008).
- Sukhwani, H.; Martínez, J.M.; Chang, X.; Trivedi, K.S.; Rindos, A. Performance modeling of pbft consensus process for permissioned blockchain network (hyperledger fabric). In Proceedings of the 2017 IEEE 36th Symposium on Reliable Distributed Systems (SRDS), Hong Kong, China, 26–29 September 2017; pp. 253–255. [Google Scholar]
- Noyes, C. Bitav: Fast anti-malware by distributed blockchain consensus and feedforward scanning. arXiv
**2016**, arXiv:1601.01405. [Google Scholar] - Kopp, H.; Mödinger, D.; Hauck, F.; Kargl, F.; Bösch, C. Design of a privacy-preserving decentralized file storage with financial incentives. In Proceedings of the 2017 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW), Paris, France, 26–28 April 2017; pp. 14–22. [Google Scholar]
- Zhang, Y.; Wen, J. An IoT electric business model based on the protocol of bitcoin. In Proceedings of the 2015 18th International Conference on Intelligence in Next Generation Networks (ICIN), Paris, France, 14 June 2015; pp. 184–191. [Google Scholar]
- Zhang, X.; Poslad, S. Blockchain support for flexible queries with granular access control to electronic medical records (EMR). In Proceedings of the 2018 IEEE International Conference on Communications (ICC), Kansas City, KC, USA, 20–24 May 2018; pp. 1–6. [Google Scholar]
- Sharples, M.; Domingue, J. The blockchain and kudos: A distributed system for educational record, reputation and reward. In European Conference on Technology Enhanced Learning; Springer: Berlin/Heidelberg, Germany, 2016; pp. 490–496. [Google Scholar]
- Liu, C.; Chai, K.K.; Zhang, X.; Chen, Y. Peer-to-peer electricity trading system: Smart contracts based proof-of-benefit consensus protocol. Wirel. Netw.
**2019**, 25, 1–12. [Google Scholar] [CrossRef][Green Version] - Buterin, V. On Public and Private Blockchains. Available online: https://blog.ethereum.org/2015/08/07/on-public-and-private-blockchains/ (accessed on 7 August 2015).
- Androulaki, E.; Barger, A.; Bortnikov, V.; Cachin, C.; Christidis, K.; De Caro, A.; Enyeart, D.; Ferris, C.; Laventman, G.; Manevich, Y.; et al. Hyperledger fabric: A distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference, Porto, Portugal, 23–26 April 2018; p. 30. [Google Scholar]
- Smetanin, S.; Ometov, A.; Komarov, M.; Masek, P.; Koucheryavy, Y. Blockchain Evaluation Approaches: State-of-the-Art and Future Perspective. Sensors
**2020**, 20, 3358. [Google Scholar] [CrossRef] [PubMed] - Zyskind, G.; Nathan, O. Decentralizing privacy: Using blockchain to protect personal data. In Proceedings of the Security and Privacy Workshops (SPW), San Jose, CA, USA, 21–22 May 2015; pp. 180–184. [Google Scholar]
- Quirós-Tortós, J.; Ochoa, L.F.; Lees, B. A statistical analysis of EV charging behavior in the UK. In Proceedings of the 2015 IEEE PES Innovative Smart Grid Technologies Latin America (ISGT LATAM), Montevideo, Uruguay, 5 October 2015; pp. 445–449. [Google Scholar]
- Hafez, O.; Bhattacharya, K. Queuing analysis based PEV load modeling considering battery charging behavior and their impact on distribution system operation. IEEE Trans. Smart Grid
**2016**, 9, 261–273. [Google Scholar] [CrossRef] - Gai, K.; Wu, Y.; Zhu, L.; Xu, L.; Zhang, Y. Permissioned blockchain and edge computing empowered privacy-preserving smart grid networks. IEEE Internet Things J.
**2019**, 6, 7992–8004. [Google Scholar] [CrossRef] - Yue, X.; Wang, H.; Jin, D.; Li, M.; Jiang, W. Healthcare data gateways: Found healthcare intelligence on blockchain with novel privacy risk control. J. Med. Syst.
**2016**, 40, 218. [Google Scholar] [CrossRef] [PubMed] - Wenbo, M. Modern Cryptography: Theory and Practice; Prentice Hall PTR: Upper Saddle River, NJ, USA, 2003. [Google Scholar]
- Dorri, A.; Steger, M.; Kanhere, S.S.; Jurdak, R. Blockchain: A distributed solution to automotive security and privacy. IEEE Commun. Mag.
**2017**, 55, 119–125. [Google Scholar] [CrossRef][Green Version] - Min, X.; Li, Q.; Liu, L.; Cui, L. A permissioned blockchain framework for supporting instant transaction and dynamic block size. In Proceedings of the 2016 IEEE Trustcom/BigDataSE/ISPA, Tianjin, China, 23 August 2016; pp. 90–96. [Google Scholar]
- Pop, C.; Cioara, T.; Antal, M.; Anghel, I.; Salomie, I.; Bertoncini, M. Blockchain based decentralized management of demand response programs in smart energy grids. Sensors
**2018**, 18, 162. [Google Scholar] [CrossRef] [PubMed][Green Version] - Ateniese, G.; Camenisch, J.; Joye, M.; Tsudik, G. A practical and provably secure coalition-resistant group signature scheme. In Annual International Cryptology Conference; Springer: Berlin/Heidelberg, Germany, 2000; pp. 255–270. [Google Scholar]
- Boneh, D.; Shacham, H. Group signatures with verifier-local revocation. In Proceedings of the 11th ACM Conference on Computer and Communications Security, Washington, DC, USA, 25–29 October 2004; pp. 168–177. [Google Scholar]
- Ling, S.; Nguyen, K.; Roux-Langlois, A.; Wang, H. A lattice-based group signature scheme with verifier-local revocation. Theor. Comput. Sci.
**2018**, 730, 1–20. [Google Scholar] [CrossRef][Green Version] - Perera, M.N.S.; Nakamura, T.; Hashimoto, M.; Yokoyama, H. Traceable and Fully Anonymous Attribute Based Group Signature Scheme with Verifier Local Revocation from Lattices. In International Conference on Network and System Security; Springer: Berlin/Heidelberg, Germany, 2019; pp. 675–684. [Google Scholar]
- Dawson, E.; Donovan, D. The breadth of Shamir’s secret-sharing scheme. Comput. Secur.
**1994**, 13, 69–78. [Google Scholar] [CrossRef] - Daemen, J.; Rijmen, V. Reijndael: The Advanced Encryption Standard. Dobb J. Softw. Tools Prof. Program.
**2001**, 26, 137–139. [Google Scholar] - Monk, S. Programming the Raspberry Pi: Getting Started with Python; Mcgraw-Hill: New York, NY, USA, 2013. [Google Scholar]
- Barker, E.; Barker, W.; Burr, W.; Polk, W.; Smid, M. Recommendation for key management part 1: General (revision 3). Nist Spec. Publ.
**2012**, 800, 1–147. [Google Scholar] - Wood, G. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Proj. Yellow Pap.
**2014**, EIP-151, 1–32. [Google Scholar] - Ekparinya, P.; Gramoli, V.; Jourjon, G. The attack of the clones against proof-of-authority. arXiv
**2019**, arXiv:1902.10244. [Google Scholar]

**Figure 2.**The system model of our proposed Challenge-Response Assisted Access Authorisation (CRA

^{3}) scheme.

**Figure 3.**The time cost comparison of local computation on a Raspberry Pi 2 between CRA

^{3}and DP (Decentralise Privacy scheme [12]).

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 | √ | × | √ |

CRA^{3} * | Permissioned | Trusted/Untrusted | √ | √ | √ |

^{1}The scheme depends on the deployed database to support the mentioned security feature. * CRA

^{3}: our proposed scheme, Challenge-Response Assisted Access Authorisation.

© 2020 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Zhang, X.; Liu, C.; Chai, K.K.; Poslad, S.
A Challenge-Response Assisted Authorisation Scheme for Data Access in Permissioned Blockchains. *Sensors* **2020**, *20*, 4681.
https://doi.org/10.3390/s20174681

**AMA Style**

Zhang X, Liu C, Chai KK, Poslad S.
A Challenge-Response Assisted Authorisation Scheme for Data Access in Permissioned Blockchains. *Sensors*. 2020; 20(17):4681.
https://doi.org/10.3390/s20174681

**Chicago/Turabian Style**

Zhang, Xiaoshuai, Chao Liu, Kok Keong Chai, and Stefan Poslad.
2020. "A Challenge-Response Assisted Authorisation Scheme for Data Access in Permissioned Blockchains" *Sensors* 20, no. 17: 4681.
https://doi.org/10.3390/s20174681