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

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 (CRA3) to protect users’ credentials during authorisation. In CRA3, 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 CRA3.


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 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. • 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 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.

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].

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: Hash(h i−1 ||data i ||ts i ), i = 2, ..., n

Lagrange Interpolating Polynomial
Let q be a prime and f (x) = a 0 + a 1 x + ... + a t−1 x t−1 (mod q) with a polynomial of degree t, where a 0 , a 1 , ...a t ∈Z q are coefficients. Given any t points are the Lagrange interpolation coefficients and A = {1, 2, ..., t}.
Note that f (x) can be reconstructed with any t points based on polynomial theory; however, f (x) cannot be reconstructed ( f (0) cannot be computed either) with any points fewer than t [25].

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 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.

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 CN 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 CN 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 CN 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 , ..., U n }) whilst ensuring the transported data is confidential, i.e., ∀M ∈ {0, 1} * , C = f (M), and any probabilistic polynomial-time algorithm A computes M or U id with its advantage Adv 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 ε represents a negligible probability.

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 3 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 Decrypt (pp, C, P, AT v ): U A decrypts the encrypted data C to retrieve the requested data M with the given point P.

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

Confidentiality (IND-CCA Security)
Formally, the adversary defined to prove the theoretical security of our proposed CRA 3 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 AT v is revealed to the adversary. Game 1. Let 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 C and the adversary A 1 is described with the following five phases: • Initialise: C first generates the public parameter pp via running the algorithm Setup. Then, C generates n data providers (key-value pairs) The generated pp and all Rn i (1 i n) are given to the adversary A 1 .

•
Queries: The following queries can be requested by A 1 for polynomial times in the game:

1.
Identity attributes query (i): C responds with the sequence of the random identity attributes rAT v i ; 2.
Encrypt query(M, i): C outputs the ciphertext C = Encrypt(pp, M, AT v i ) and the point P on the constructed polynomial f (x) in the Encrypt phase; 3.
Decrypt query(C, P, i): C decrypts C via running the algorithm Decrypt, then responds with the plain message.
(M * 0 , t) and (M * 1 , t) are not allowed to appear in the above Encrypt query; 2.
The target data provider's index t and the challenge ciphertext C * are not allowed to appear in the above Decrypt query. •

Guess:
A 1 can win the game if its output ρ ∈ R {0, 1} satisfies the condition ρ = ρ . Now, the advantage of A 1 could be defined as: Note that the probability analysis is presented after the Guess phase in the formal confidentiality proof of our CRA 3 scheme.

Proposed Scheme CRA 3
In this section, we illustrate our proposed CRA 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 (λ):
This procedure outputs public parameters pp with the security parameter λ using the following steps.
Select one secure cryptographic hash function H : Select a symmetric encryption algorithm, e.g., AES (Advanced Encryption Standard); 4.

Request (pp):
The user U A (data inquirer) prepares the query Q via the following steps.

1.
Decide on the data to be requested. Note that U A should have the corresponding identity attributes (a sequence, AT 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 ; 2.
Prepare the unique reference number Rn then send the request Q = (B id , Rn) to U B through CN pm .
• Challenge (pp, Q): U B generates the challenge Ch based upon the request Q from U A via the following steps.

1.
Prepare the sequence of the identity attributes (values): Calculate the hash value of each element in the sequence AT v to get the sequence Construct a polynomial f (x) = H(AT v 1 ) + H(AT v 2 )x + ... + H(AT v n )x n−1 (mod q), then pick n random points on the polynomial f (x) as a set: Construct two sequences P x and P y of all the x i and all the y i in P: Calculate the hash value of the sequence P y : PH y = H(y 1 , y 2 , ..., y n ), y 1 , y 2 , ..., y n ∈P y ; 6.
Send the challenge P x to U A through CN pm . Note that CN pm should keep the Ch = (PH y ) 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
Take P x ∈Ch to calculate the sequence P y = {y i |y i = g(x i )∧x i ∈P x ∧i = 1...n} and then hash the sequence P y : PH y = H(y 1 , y 2 , ..., y n ), y 1 , y 2 , ..., y n ∈P y ; 4.
Send the response Re = (PH y ) to the consensus network CN pm . •

Authorise (Ch, Re):
The consensus network CN pm validates the two hash values in Ch and Re. If PH y (∈Ch) = PH y (∈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 . Generate a secure key k ∈ Z q for the symmetric encryption; 3.
Use AES to encrypt M with key k to get the ciphertext C = AES k (M, H M ). For decrypting AES k (M, H M ) to recover the plain data M, AES k is defined as the decryption process: Follow Section 3.2 to construct a polynomial f * (x) of degree n with k and AT v : Generate a random integer x p ∈ Z q and calculate a point P(x p , y p = f * (x p )); 6.
Return (C, P) to U A through a secret channel.
• Decrypt (pp, C, P, AT v ): U A can decrypt the ciphertext C after passing the Authorise phase via the following steps.

1.
Use the sequence AT v organised in the former Response phase to construct a polynomial Note that a 0 is an unknown coefficient; 2.
Follow the Lagrange interpolation polynomial in the Section 3.2 to reconstruct the polynomial g * (x) fully, and then recover the key k = g(0) = a 0 ∈ Z q for AES decryption with the point If H(M) = H M holds, this algorithm outputs M; otherwise, it outputs ⊥.

Theoretical Analysis of CRA 3
In this section, we first show the correctness of our proposed authorisation CRA 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.

Correctness
In the Authorise phase, if the data requester has the correct sequence of the identity attributes AT v , the condition AT v = AT v holds, ⇔ P y = P y ( f or the given P x ) ⇔ PH y = PH y . 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 ∈ Z q for AES decryption with the given point P(x p , y p ) on the polynomial f (x) in the Decrypt phase. Meanwhile, P should present on the correct reconstructed polynomial as well. Since the condition , ..., H(AT v n )} holds after the Authorise phase, the reconstructed polynomial g(x) is the same as the original polynomial f (x) except for the unknown first coefficient a 0 = k. Therefore, determining the secret key g(0) = a 0 = k ∈ Z q for AES decryption requires only one point (shareholder) P(x p , y p ): Hence, the authorised data requester can reconstruct the polynomial g(x) and restore the correct key k in the Decrypt phase to ensure Decrypt(pp, C, AT v ) = M holds, where C = Encrypt(pp, M, AT v ).
The target data provider's index is defined as t (1 t n). The challenger C aims to determine AT v t via executing A 1 as the subroutine. Next, C and A 1 play the game defined in Section 4.3.2.
• Initialise C first generates the public parameter pp = (q, H, AES) and then sends pp to A 1 . After that, C generates n data providers (key-value pairs) {Rn i , AT v i |1 i n} and the target data provider is denoted by {Rn t , AT v t }. Note that all the generated Rn i (1 i n) are given to the adversary A 1 . Finally, C initialises one empty lists List γ 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 C can respond to the queries requested by A 1 polynomial times in the following ways.

1.
Identity attributes query (i): C generates the sequence of the identity attributes n } randomly and saves (i, rAT v i ) in List γ if it is the first time that i is queried. Then C respond with the sequence rAT v i . Otherwise, C should retrieve the sequence rAT v i from List γ directly then return it to A 1 .

2.
Encrypt query(M, i): C uses the algorithm Encrypt to output the ciphertext C = Encrypt(pp, M, AT v i ) and the point P (P should be on the polynomial constructed with AT v i in the algorithm Encrypt).

3.
Decrypt query(C, P, i): C tries to decrypt C via running Decrypt(pp, C, P, AT 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, rAT v i ) in List γ , C executes the operations.

−
Reconstruct the Lagrange interpolating polynomial g * (x) with rAT v i and P to determine the secret key k = a 0 for AES decryption. If there is no item in the List γ that satisfies the condition, C returns ⊥ to A 1 .
If i =t, C runs the Decrypt(pp, C, P, AT v i ) algorithm directly and then sends the output to A 1 as the answer.
• Challenge A 1 submits two messages M * 1 , M * 2 ∈{0, 1} λ with the same length to C, then C picks one random bit ρ from the set {0, 1}. Finally, C computes the ciphertext C * of M * ρ via the following steps: 1.
Choose a secret key k∈Z q for AES encryption and decryption; 2. Determine Pick a random point P * (x * , f * (x * )) on f * (x); 4. Compute Finally, C sends the ciphertext C * and the point P * to the adversary A 1 .
The target data provider's index t and the challenge ciphertext C * are not allowed to appear in the above Decrypt query.
• Guess A 1 outputs one bit ρ from the set {0, 1}. At the same time, C picks a random element (i, rAT v i ) from List γ as the answer to the above given instance of the Lagrange interpolating polynomial. •

Probability analysis
An event E is defined as that the adversary A 1 requests a query for the target sequence AT v t in the Identity attributes query during the described game above. If the event E has happened, AT v t occurs in at least one item of List γ at the end of this game.
However, if E does not happen, it means that Pr[ρ * = ρ * |¬E ] = 1 2 holds. Meanwhile, the condition Adv I ND−CCA A 1 |Pr[ρ = ρ ] − 1 2 | holds because of the definition of the type-IND adversary (A 1 ). Based upon the above analysis, the next two derivations can be illustrated. Hence, we can deduce that the following derivation holds: We can simplify this derivation such that Pr[E ] 2Adv A 1 .
In conclusion, at the end of the game between the challenger C and the adversary A 1 , the probability of the target sequence AT v t being in the element(s) of List γ is at least 2Adv I ND−CCA Hence, the probability of generating the correct answer ρ = ρ is at least 2 Q γ Adv I ND−CCA A 1 , where Q γ represents the total number of the elements in the list List γ .

Data Integrity
In our CRA 3 scheme, the hash value H M = H(M) 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 ) = AES k (C) are incorrect (where C = AES k (M, H M ) and k is computed from P. Therefore, the condition H(M) = 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.

Comparison of Security Features
In Table 1, 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 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.

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 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.
First, the number of the attributes used for authorisation was varied from two to 10 in CRA 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. Meanwhile, we measured the time cost for transporting data between users and CN 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 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. 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 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. 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 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. Transaction cost (gas) CRA 3 DP Figure 6. Transaction fee of CRA 3 and DP [12] for authorisation.

Conclusions
In this paper, we proposed a privacy-enhanced authorisation CRA 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.