# Towards Supporting Attribute-Based Access Control
in Hyperledger Fabric Blockchain

Amshumaan Pericherla, Proteet Paul, Shamik Sural, Jaideep Vaidya,
Vijayalakshmi Atluri

► To cite this version:

Amshumaan Pericherla, Proteet Paul, Shamik Sural, Jaideep Vaidya, Vijayalakshmi Atluri. Towards Supporting Attribute-Based Access Control in Hyperledger Fabric Blockchain. 37th IFIP International Conference on ICT Systems Security and Privacy Protection (SEC), Jun 2022, Copenhagen, Denmark. pp.360-376, 10.1007/978-3-031-06975-8\_21. hal-05319890

HAL Id: hal-05319890

https://inria.hal.science/hal-05319890v1

Submitted on 17 Oct 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

ifip

International Federation for Information Processing

This document is the original author manuscript of a paper submitted to an IFIP
conference proceedings or other IFIP publication by Springer Nature. As such, there
may be some differences in the official published version of the paper. Such
differences, if any, are usually due to reformatting during preparation for publication or
minor corrections made by the author(s) during final proofreading of the publication
manuscript.
# Towards Supporting Attribute-Based Access Control in Hyperledger Fabric Blockchain

Amshumaan Pericherla¹, Proteet Paul¹, Shamik Sural¹(✉), Jaideep Vaidya², and Vijay Atluri²

¹ Indian Institute of Technology Kharagpur, Kharagpur, India
{amshumaan6pericherla,proteetpaul}@iitkgp.ac.in, shamik@cse.iitkgp.ac.in

² Rutgers University, Newark, USA
jsvaidya@business.rutgers.edu, atluri@rutgers.edu

**Abstract.** Hyperledger Fabric (HLF) is an open-source platform for deploying enterprise-level permissioned blockchains where users from multiple organizations can participate. Preventing unauthorized access to resources in such blockchains is of critical importance. Towards addressing this requirement, HLF supports different access control models. However, support for Attribute-Based Access Control (ABAC) in the current version of HLF is not comprehensive enough to address various requirements that arise when multiple organizations interact in an enterprise setting. To address those shortcomings, in this paper, we develop and present methods for providing full ABAC functionality in Hyperledger Fabric. Performance evaluation under different network configurations using the Hyperledger Caliper benchmarking tool shows that the proposed approach is quite efficient in practice.

**Keywords:** Hyperledger Fabric · Access control · ABAC · Blockchain · Smart contract · Chaincode

## 1 Introduction

A blockchain is a distributed ledger built on top of a decentralized peer-to-peer network, providing mechanisms for secure transfer of assets among its participants without the need for any intermediary. Transparency of the ledger combined with a secure execution platform provided by smart contracts has led to a widespread adoption of the blockchain technology across multiple industries. It has resulted in the development of novel applications in several domains like IoT, healthcare, supply chain, e-governance, etc.

There is no central authority in blockchains for monitoring user actions within the network. Hence, an access control mechanism needs to be exercised for preventing unauthorized access to the network resources, especially in enterprises. Some of the recent work [10, 14, 16, 23] propose enforcement of access control
models such as Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC) for public blockchains like Ethereum. It may be noted that a public blockchain has no restriction on peers in joining the network. Any user can create a peer node on the network and access the data on the blockchain.

Hyperledger Fabric (HLF) [2], on the other hand, is an open-source tool for deploying enterprise-level permissioned blockchains. Unlike its public counterpart, a private blockchain introduces an additional authentication layer to control the users joining the network. Even though the users are authenticated, it is necessary to restrict access to the network resources for certain users, thus enforcing confidentiality and integrity policies. While other access control models are supported, HLF does not have any specific feature for aiding the implementation of ABAC. The only current feature of HLF that can be used is the concept of client certificates generated by certifying authorities. Most of the recent literature like [12] and [18] use the HLF network as an intermediary data store between off-chain users and resources for maintaining authorization related components. Some of the other work [9] considers only limited features of ABAC,

In contrast to such existing approaches, we propose a method for utilizing the full capabilities of ABAC in HLF. We target the cases where clients on the network act as users and resource owners, and resources are stored directly on the blockchain. The key contributions of this paper are summarized below:

i. We develop a novel approach for supporting attribute-based access control over the assets managed in any Hyperledger Fabric installation by appropriately designing its components on the decentralized network.

ii. We build a complete Golang library for implementing the approach on a Hyperledger Fabric network. Performance tests are run on workloads under different configurations using the Hyperledger Caliper benchmarking tool.

iii. We make both the library and the docker network for deploying an ABAC-enabled HLF instance publicly available through GitHub for reproducibility of our results and supporting the open source initiative.

The rest of the paper is organized as follows. Section 2 introduces the key concepts related to HLF and ABAC. In Sect. 3, we present our approach for supporting ABAC functionality in HLF along with the developed libraries and the workflow for system setup. The implementation details and experimental results are discussed in Sect. 4. Section 5 reviews related work in this field. Finally, Sect. 6 concludes the paper and provides directions for future research.

# 2 Preliminaries

In this section, we discuss some of the background concepts that would help in understanding our research contributions in the later part of the paper.

## 2.1 Hyperledger Fabric

Blockchain [22] is a distributed ledger spread over a completely decentralized peer-to-peer network without any hierarchy. As the name suggests, a blockchain
<figure><img src="image_3.png" /><figcaption>Fig. 1. Structure of a hyperledger fabric network</figcaption></figure>

maintains a chain of blocks on the ledger recorded in chronological order linked using cryptographic techniques. Hyperledger Fabric<fnref n="1" /> [2] is a framework for deploying permissioned blockchains with a modular structure with pluggable components for consensus mechanism, datastore, etc. HLF runs the component services in docker containers to isolate the application layer from physical resources. Any node needs to be authorized to enter the network. Figure 1 shows the overall structure of a typical HLF network. The main components are described below.

**Chaincode** - Chaincode is the HLF term for smart contracts originally introduced in the context of Ethereum. A smart contract refers to the business logic while a chaincode refers to the deployable entity enclosing this logic. Chaincodes are the only entry points for users or applications to access the ledger.

**Peer** - Peers are the client nodes on the network. They host the ledger, chaincodes, create/sign transactions and blocks.

**Orderer** - These are the special nodes that ensure block delivery across the network to all peers using a consensus protocol for ordering the transactions.

**Organization (Org)** - An HLF network can span multiple organizations, each controlling its peers on the network. Different organizations can contribute their resources to the network.

**Membership Service Provider (MSP)** - It uses certifying authorities (CAs) to create and manage identities for network members. An MSP generates necessary authentication material for all the participants to join the network that qualifies HLF as a permissioned network. Different Orgs can have independent MSPs.

**Channel** - It is a private subnet of communication among a collection of peers. A channel can include peers from multiple organizations. Every channel has an individual ledger which is replicated among all the peers on that channel.

**Ledger** - Ledger contains the data and transaction history in the HLF network. An HLF Ledger has two components - a) Blockchain, which contains blocks

<footnote n="1">¹ https://www.hyperledger.org/use/fabric.</footnote>
with transactions chained to previous blocks by including their hash values, and b) World State, which is a ledger database describing the current ledger state. Any update to this state database is recorded on the blockchain.

*Client* - Clients belong to specific organizations and are registered using that organization's MSP to generate necessary certificates and key pairs for authorization to invoke the chaincodes on the network.

## 2.2 Attribute-Based Access Control

Attribute-based access control [4,8] is a fine-grained access control model that decides whether to give access based on the attributes (characteristics) of the user, object and environment, as well as the requested permission. Access granting decision is built upon the concept of an access control policy, which is a set of access rules that are comprised of logical combinations of the above-mentioned attributes and their values. When an access request is made, the rules are evaluated with respect to the pre-assigned attributes. ABAC subsumes several other access control models as they are considered to be special cases of ABAC with appropriately defined attribute sets. For example, RBAC [19] can be implemented by embedding user-role relations into a user attribute called role and role-permission relations into corresponding rules in the access control policy.

In its general form, an ABAC system consists of five components - UA, RA, EA, OP, POL, each of which is described below:

*UA* - Represents the attributes of users like identity, name, and other application specific attributes.

*RA* - Represents the attributes of a resource. It includes resource ID, owner, confidentiality level as well as other application specific attributes.

*EA* - Refers to environment attributes. It is used to capture context information like time of access, IP address of the requester, etc., which enables a fine level of control to be built in the access logic.

*OP* - Refers to the type of operation on the resource that a user is requesting. The operations can be resource-specific like read, update, delete, etc. This ensures different levels of user control on the resource.

*POL* - Refers to the access control policy of an organization. It is comprised of a set of rules, each defined in terms of the above-mentioned components. Based on the rules in *POL*, an incoming access request is either granted or denied.

An ABAC reference monitor intercepts every user request. It then retrieves the required attributes and matches them with the available policy. The request is further processed only if there is at least one rule in the policy that is satisfied.

# 3 Enabling ABAC in Hyperledger Fabric

While planning for ABAC support in HLF, having a traditional centralized reference monitor would defeat the very purpose of using blockchain technology, i.e., decentralized operation, trust independence, transparency and immutability. It would require a trusted third party to maintain and administer the reference
monitor, making it susceptible to attacks, raising trust concerns and forming
a source of single-point of failure in an otherwise distributed system. Hence,
the access decision needs to be made in a distributed manner, involving all the
network nodes and considering the majority decision. We take advantage of the
inherent capabilities of HLF in obviating the above issues. It is felt that the
blockchain ledger itself can be used to maintain necessary information related to
access control including the complete history of access requests and their deci-
sions. This is because the ledger is immutable and distributed across every peer,
with consistency ensured by the consensus protocols. Such a design also provides
a natural means for auditing, a desirable property of any reference monitor.

Besides designing the reference monitor, another major challenge from the
perspective of supporting ABAC in HLF is how and where to securely config-
ure the ABAC components, resources on the blockchain. After exploring vari-
ous alternatives with their potential merits and demerits, we address this chal-
lenge by storing public attributes and policy on the ledger, while the sensitive-
attributes and resources on certificates and private collections. It may be noted
that directly implementing the policy logic in chaincodes would necessitate re-
installation on all nodes for even a minor change in the policy. Instead, in the
proposed design, a policy can be modified on the ledger without any overhead
at other nodes.

Our approach focuses on designing a generalized access control framework
for a set of organizations participating in the private blockchain. The users are
all on-network peers and the resources are also stored on the network managed
by owners internal to the network. A resource can be any type of asset supported
by the blockchain. No external entity is involved at any step.

## 3.1 Configuring ABAC Components

We first explain how to configure and store different ABAC components on the
HLF network. These can then be accessed and used for access decisions during
a request. The proposed configuration for each component is described below.

**Resource.** A resource can be of any type that can be stored on the blockchain, e.g., a restricted URL, file data, images, etc. While registering a resource on the channel state, the transaction contains its key-value information along with the timestamp. If this transaction is packed into a block and stored on the ledger, any user on the network would then be able to query the ledger to get this transaction and hence, the resource. To guard against such disclosure, we use a feature of HLF called private data that enables us to securely store the resource.

*Private Data Collection* - It is a database maintained separately from the
state database. This data is replicated through a *gossip* protocol only to the
peers of respective organizations specified in the collection configuration. The
ledger state at each peer for two representative organizations Org1 and Org2 is
shown in Fig. 2. Any input data is stored in a transient storage at the anchor
peers till it is successfully copied to all the peers. After replication, the hash value
<figure><img src="image_4.png" /><figcaption>Fig. 2. Ledger states for multiple organizations</figcaption></figure>

of the input data is written to the transaction on the ledger. This is useful while accessing actual data to validate that it is not tampered with. The resource data is available only to the peers of the respective organization. At least one node from the resource's organization should be available to retrieve the resource. These collections can be accessed using the STUB API of HLF.

A resource in the private collection is structured as a JSON object. When multiple MSPs are involved for different organizations, the same ID might get assigned to different clients across these MSPs. To circumvent the problem, we maintain the owner's public key in the resource for resolving any ambiguity.

**User Attributes.** We divide the user attributes (*UA*) into two subsets, namely (i) public attributes, denoted by *UA*<sub>pub</sub>, that are shared among all the network users and (ii) sensitive attributes, denoted by *UA*<sub>priv</sub>, that other network users cannot access. Attributes in *UA*<sub>priv</sub> are stored on the client X.509 certificate generated by the MSP during enrollment. These X.509 certificates contain client ID, MSP ID, a public key and other subject related information. The generated client ID is unique within an MSP. We can also mention attribute-value pairs to be stored on the certificate during enrollment with MSP. These certificates are accessible to chaincodes through a CID library. In contrast, *UA*<sub>pub</sub> attributes are stored on the channel state in the JSON format. They also have a pub-key field for resolving ambiguity when multiple MSPs are involved.

**Resource Attributes.** We divide the *RA* also into two subsets, namely, (i) public resource attributes, denoted by *RA*<sub>pub</sub>, that consist of visible attributes and (ii) private resource attributes, denoted by *RA*<sub>priv</sub>, that consist of sensitive attributes. Attributes in *RA*<sub>pub</sub> are stored on the channel state in JSON format similar to *UA*<sub>pub</sub>. *RA*<sub>pub</sub> also has a pub-key field for the same reason as mentioned above. As an alternative, the client ID and MSP ID pair from the certificate can also be used for verification since the combination is unique for every client. *RA*<sub>priv</sub> has a similar format but is stored on the Org private collection, similar to resources, instead of the channel state. This is to maintain the required additional privacy to keep them hidden to users on the network.
<figure><img src="image_5.png" /><figcaption>Fig. 3. Deployment locations of ABAC components</figcaption></figure>

**Environment Attributes.** The environment attributes (*EA*) can be very specific to a use case. They typically need to be inferred from the context during an access request mediation. Chaincodes can be programmed accordingly to retrieve these attributes considering the requester details and the present context.

**Access Control Policy.** *POL*, the access policy, consists of several rules. At least one of these rules needs to be satisfied for a user to be granted the desired access when requested. These rules are stored on the ledger in JSON format and can be added/deleted/modified whenever necessary only by the Admin user. As the rules are attribute-based in ABAC, giving resource owners the right to add rules might result in inadvertently granting of unauthorized access to other resources having the same attribute values. Each rule is comprised of ID, necessary attributes and a set of access constraints on *UA*, *RA*, *EA* and *OP*. All these constraints need to be valid for the respective rule to be satisfied.

**Decision Unit.** It is mandatory for every user request to be intercepted by a decision unit (*DU*) for performing the access check. In an HLF network, interacting with the ledger is possible only through chaincodes. So having the *DU* as a chaincode with the resource access methods will require every user request for any resource to be made using this chaincode. This chaincode can then retrieve all the respective attributes, policies and validate the request.

Consider an HLF network for academic resource sharing within a university. Faculty (owners) can save classified data (resource) in a private collection on the network, registering attributes like ID, department, domain, etc., on the ledger based on sensitivity. Student (users) attributes like student id, department and year of study are registered on the certificates or ledger accordingly. When a student requests a resource, these attribute values are matched against the access constraints (e.g., same department, year of study >= 3, etc.), and the access decision is recorded on the ledger that can be audited if necessary.

## 3.2 Managing ABAC Components

To manage the ABAC components on the HLF network as proposed in Sect. 3.1, we have developed a Golang library and made it publicly available with detailed
<table><caption>**Table 1.** Golang library methods</caption><thead><tr><td>ABAC component</td><td>Related methods</td></tr></thead><tbody><tr><td>Resource</td><td>addResource(), updateResource(), getResource()</td></tr><tr><td>User attributes</td><td>registerUAPub(), updateUAPub(), getUAPub()<br>getUAPriv()</td></tr><tr><td>Resource attributes</td><td>registerRAPriv(), updateRAPriv(), getRAPriv()<br>registerRAPub(), updateRAPub(), getRAPub()</td></tr><tr><td>Access policies</td><td>registerPolicy(), updatePolicy(), getPolicy(), getPolicySet()</td></tr><tr><td>Decision unit</td><td>اناContext(), validateAccess()</td></tr></tbody></table>

**Algorithm 1.** updateRAPriv() method

1: **procedure UPDATERAPRIV(RID, ownerID, ATTRIBUTES, COLLECTION)**
2:     **RA**<sub>priv</sub> = stub.GetPrivateData(COLLECTION, RID)
3:     **if** **RA**<sub>priv</sub> = **NULL** **then**
4:         **Res** = getResource(RID, COLLECTION)
5:         **if** **Res.**ownerID ≠ Hash(**ownerID**, **Res.ownerPubKey**) **then**
6:             **Return** "Invalid Owner Credentials"
7:             **RA**<sub>priv</sub> = [RID, **Res.ownerID**, **Res.ownerPubKey**, ATTRIBUTES]
8:             **stub**.PutPrivateData(COLLECTION, RID, **RA**<sub>priv</sub>)
9:             **Return** "Registered Private Resource Attributes"
10:        **else if** **RA**<sub>priv</sub>.ownerID ≠ Hash(**ownerID**, **RA**<sub>priv</sub>.ownerPubKey) **then**
11:            **Return** "Invalid Owner Credentials"
12:        **RA**<sub>priv</sub><sup>new</sup> = [RID, **RA**<sub>priv</sub>.ownerID, **RA**<sub>priv</sub>.ownerPubKey, ATTRIBUTES]
13:        **stub**.PutPrivateData(COLLECTION, RID, **RA**<sub>priv</sub><sup>new</sup>)
14:        **Return** "Updated Private Resource Attributes"

documentation<fnref n="2" />. Table 1 lists all the available methods in this library. These methods can be used directly in the chaincodes by importing the library. To ensure that only an authorized client can carry out an activity, she has to digitally sign her identity in the request, which can be verified using her public key. Few methods are detailed in the following algorithms. The rest are also developed along similar lines and hence not repeated here for the sake of brevity.

Algorithm 1 takes resource ID, owner ID with digital signature (ownerID = Hash[owner ID, owner Private Key]), and updated private attributes (key-value pairs) for the resource as input and updates the RA<sub>priv</sub> on the private collection. Here we refer to the client maintaining the resource as its owner. CID and STUB libraries are provided by HLF for retrieving user details and interacting with the ledger respectively. Steps 2 and 3 check if RA<sub>priv</sub> for that resource is already registered. If not, it is added to the private collection in Steps 4 to 9. Steps 5 and 10 verify if the requester is the actual owner of the resource. In Steps 12 to 14, the RA<sub>priv</sub> is updated with given input attributes and then written to the private collection. The transaction hash gets recorded on the ledger.

<footnote n="2">² Available at https://github.com/g4gekkouga/HLF_ABAC.</footnote>
<caption>**Algorithm 2.** `validateAccess()` method</caption>

1: **procedure** VALIDATEACCESS(*userID*, *RID*, *OP*, *COLLECTION*) (ResourceData)
2:     *UserID* = *cid.GetClientIdentity()*.GetID()
3:     *userCert* = *cid.GetClientIdentity()*.GetX509Certificate()
4:     *UA*<sub>priv</sub> = *userCert.GetAttributes()*
5:     *UA*<sub>pub</sub> = getUAPub(*UserID*)
6:     **if** *UserID* ≠ Hash(*UserID*, *UA*<sub>pub</sub>.userPubKey) **then**
7:         Return "Invalid User Credentials"
8:     *UA* = [*UA*<sub>priv</sub>, *UA*<sub>pub</sub>]
9:     *RA*<sub>priv</sub> = getRAPriv(*RID*, *COLLECTION*)
10:    *RA*<sub>pub</sub> = getRAPub(*RID*)
11:   *RA* = [*RA*<sub>priv</sub>, *RA*<sub>pub</sub>]
12:   *EA* = Context()
13:   *POL* = getPolicy()
14:   **for** Rule in *POL* **do**
15:       **if** validate(Rule, *UA*, *RA*, *EA*, *OP*) = TRUE **then**
16:           *Resource* = RESOURCE(*RID*, *COLLECTION*)
17:           Return *Resourcearker*.ResourceData
18:       Return "Access Declined"

Algorithm 2 takes as input the resource ID, digitally signed user ID (*userid* = Hash[*user ID*, *user Private Key*]), operation on the resource and resource collection. Here, a client requesting the access is referred to as the user. All the required attributes and policies are retrieved in Steps 4 to 13. Step 6 verifies user credentials to ensure that *UA*<sub>pub</sub> belongs to the invoking client. Steps 13 to 17 check if the attributes satisfy any of the rules. If so, the resource is obtained from the private collection and returned to the user. Else, access is denied.

## 3.3 Execution Workflow

We now describe the workflow of our proposed design of ABAC in Hyperledger Fabric from setup to access mediation using Fig. 4. The Step 0 mentioned in the figure for deploying the blockchain is detailed below:

i. First, configure the CA and MSP for all the organizations to generate the certificates and identities. Next, configure the peer and the orderer nodes, and pack the respective certificates to enroll on MSP. Then, generate certificates for Admin using CA for each organization and enroll them on the MSP.

ii. Define a private collection on each organization to store its resources. Configure the settings for these collections according to the requirement.

iii. Create a channel for all the peers and orderers from different organizations to join. Next, install the chaincodes on the peers and approve them from necessary peers to commit the chaincodes to the channel.

While configuring peer nodes, we can use different services for the state database. By default, HLF provides two database services, both of which were
<figure><img src="image_6.png" /><figcaption>Fig. 4. Proposed ABAC workflow</figcaption></figure>

duly considered by us for their relative advantages and shortcomings. The first one is GoLevelDB, a simple key-value store database that is embedded into the peer process and runs on the same peer container. The other is CouchDB, an external database that runs alongside its peer on a separate container. CouchDB is also a key-value store and supports all the features of LevelDB. As a document object store, it can maintain data in JSON format and also support indexing. This facilitates execution of complex JSON queries on the value field apart from the key queries. Such a feature helps during the auditing and reporting process.

After the blockchain is deployed (Step 0), Steps 1 to 11 in Fig. 4 specify the subsequent tasks to be followed for exercising access mediation. The Admin enrolls required clients on the MSP and stores their public attributes on the blockchain. These clients can act as both users and resource owners. Owners now add resources to a private collection and store or update the resource attributes on the blockchain. Admin registers the access control rules on the blockchain. When the user makes a request, it is processed by the Decision Unit (a chaincode), and the requested resource is returned upon successful verification.

Our approach makes use of the security guarantees of the HLF itself. No additional security flaw is introduced. HLF architecture is natively secure in terms of design, confidentiality and privacy [3]. It also ensures secure storage and execution of any chaincode making HLF robust in preventing manipulation of business logic during execution. Peer-to-peer communications are secured using the transport layer security (TLS). The TLS certificates and key pairs issued by the CA for peers and orderers are included in their respective docker containers deployed on individual machines. When interacting with a peer container, these certificates are used for both client and server authentication during the TLS handshake, thus ensuring network integrity. Thus, security in terms of local enforcement depends on the security guarantees of Docker and in particular the isolation properties of Docker containers.

Note that the administration is responsible for issuing or modifying user attributes, policy rules, etc. Any change to these components requires invoking respective methods within *DU* chaincode. When a user makes an access request,
it reaches all the nodes in the network. At each node, the access decision is made independently after processing the request using the *DU* chaincode. The orderer nodes use consensus protocols to create transactions on the ledger through a majority decision. Thus, even if an attacker modifies the *DU* on his own node to grant access, the consensus will still need to be reached for acceptance. Similarly, when an admin makes a register/modify request for attributes, policy, etc., it also reaches all the nodes and is processed individually. While these transactions are endorsed by all the peers by default considering the admin credentials, they are still recorded on the ledger simultaneously on all the peers and can be audited.

# 4 Implementation and Experimental Evaluation

In this section, we first present the implementation details of our proposed approach in Hyperledger Fabric followed by experimental results under different scenarios. The performance is measured with the help of the Hyperledger Caliper benchmarking tool.

## 4.1 Network Implementation

First, we deploy a custom HLF network to test our approach with the help of chaincodes. This docker network prototype is being made freely available by us to the research community along with the detailed steps for its deployment<fnref n="3" />. We use virtual instances on the Google Cloud Platform to deploy this HLF network and record the latency observed by an instance that functions as an individual node on the network. Hyperledger Explorer<fnref n="4" />, an open-source web-based tool for visualizing the activities on the underlying blockchain, is used for tracking the deployed peers, channel state, and the recorded transactions on the network.

We initially deploy a vanilla smart contract (call it Reference Chaincode), which is a chaincode to store and return a resource without any access check. Next, we deploy a second smart contract (call it Proposed Chaincode), which has the full functionality of the workflow described in Fig. 4. It uses the developed Golang library to record the attributes, policy, resources, etc., and exercise access check before returning the desired resource. The Reference Chaincode acts as a baseline against which the actual ABAC enhanced chaincode (Proposed Chaincode) is benchmarked. This is to eliminate any idiosyncrasy in the network or system behavior due to the hardware or software configurations. It also lets us focus our study on the actual performance of the proposed access mechanism rather than the entire network itself. Both these chaincodes are included in the docker network being made openly available.

<footnote n="3">³ Available at https://github.com/g4gekkouga/HLF_Custom_Network.</footnote>

<footnote n="4">⁴ https://www.hyperledger.org/use/explorer.</footnote>
<figure><img src="image_7.png" /><figcaption>Fig. 5. Variation in latency with network traffic</figcaption></figure>

## 4.2 Performance Evaluation

To evaluate our approach, we build a synthetic dataset for the ABAC system. This dataset contains randomly generated attributes for users, resources, environmental context, and rules defined on these attributes. To execute these transactions from the Proposed and Reference Chaincodes on the HLF network, we use the open-source benchmarking tool Hyperledger Caliper<fnref n="5" />. We use CouchDB for the state database and Raft consensus for the HLF network as default. We consider 100 users, 100 resources and 50 rules on the network by default.

Any access request is originated from a user as a transaction for operating on a system resource. These transactions call the `validateAccess()` method described in Algorithm 2. For an accurate estimation of the additional latency introduced due to the access check, we record the difference in latency between access transaction execution through the Proposed and the Reference Chaincodes.

Figure 5 shows the variation in ABAC-mediated access latency with increasing number of concurrent transactions in the entire network. The latency values are averaged over 10 transactions as recorded on one of the nodes. It is observed that there is an initial lowering of latency, which is due to an increase in the number of transactions being packed into a single block on the ledger, resulting in a decrease in the latency for each transaction. After the transaction count in a block reaches its limit, there is a need to add more than one block and hence, the latency starts slowly increasing due to higher network congestion.

The impact of the number of different ABAC components on latency is depicted in Figs. 6a and 6b. In these figures, cardinalities of the other components are set to default values except for the ones that were varied. It is observed that change in the number of rules in the policy (Fig. 6b) has a higher impact than the number of users or resources (Fig. 6a). This is because increasing the number of rules requires processing of more access constraints unlike for users and resources, which requires searching a larger state space. Also, an equal increase in the number of resources results in a slightly higher latency than for users as seen in Fig. 6a. This is because in the first case, two of the components, namely, resources and *RA*, are increased compared to only *UA* in the latter case.

<footnote n="5">⁵ https://www.hyperledger.org/use/caliper.</footnote>
<figure><img src="image_8.png" /><figcaption>Fig. 6. Variation in latency with the number of ABAC components</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Fig. 7. Additional latency for different design choices</figcaption></figure>

Overall, from Figs. 5 and 6, it is observed that there is not much increase in latency in any of the situations. This shows that the proposed authorization step using ABAC contributes very little additional processing time compared to the default network transmission and ledger interactions.

For studying the impact of alternative design choices as discussed in Sect. 3, we vary the database service used for both channel state and private collections as shown in Figs. 7(a) and (b). In each of these, the result of one choice is shown as a ratio of the other. From Fig. 7a, it observed that GoLevelDB outperforms CouchDB mainly for access transactions in a general use case. This is because LevelDB runs on a peer, unlike CouchDB that executes in a separate container. As a result, the rate of information transfer, which is greater in an access request, is higher. In general, if the entire policy is to be considered, LevelDB is a better choice since it has lower latency. But in specific cases where only a subset of rules need to be verified based on the attribute set, CouchDB can be effectively used since it is more robust, supports indexing, richer queries.

Figure 7b shows the performance comparison between the design choices of having all the attributes as public vs private. For keeping them as private, the
<figure><img src="image_10.png" /><figcaption>Fig. 8. Resource consumption for access requests at 200 Txns/s</figcaption></figure>

<table><caption>**Table 2.** Comparison with the current state-of-the-art</caption><thead><tr><th>Features</th><th>Our model</th><th>Iftekar et al. [9]</th><th>Liu at al. [12]</th><th>Stamatellis et al. [20]</th><th>Rouhani et al. [18]</th></tr></thead><tbody><tr><td>Domain</td><td>General AC</td><td>IOT</td><td>IOT</td><td>Healthcare</td><td>General AC</td></tr><tr><td>UA</td><td>Private, Public</td><td>Private</td><td>Private</td><td>Private (only ID)</td><td>Private</td></tr><tr><td>RA</td><td>Private, Public</td><td>Private</td><td>Public</td><td>Private (only ID)</td><td>Private</td></tr><tr><td>EA</td><td>Supported</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td>Pol</td><td>On ledger</td><td>In chaincode</td><td>In chaincode</td><td>-</td><td>On Ledger</td></tr><tr><td>Users</td><td>Network peers</td><td>External</td><td>External</td><td>External</td><td>External</td></tr><tr><td>Resources</td><td>Private collection</td><td>Off chain</td><td>Off chain</td><td>Off chain</td><td>Off chain</td></tr><tr><td>Benchmark</td><td>Caliper</td><td>Caliper</td><td>-</td><td>-</td><td>Caliper</td></tr></tbody></table>

access request latency is 56% higher compared to public. The same for register requests is 34%. This is due to relatively more interactions with the private space for access requests compared to the register requests.

Figure 8 depicts the resource consumption averaged over all the peer, orderer nodes. For both, there is a nominal difference in resource usage between the Proposed and the Reference Chaincodes, implying that the overhead of introducing ABAC is quite low. The difference is lower at the orderer node since only the consensus protocol runs at the orderer nodes and access control has no impact. As the actual access request is processed on the peer nodes, there is a minor increase in resource usage at peer nodee. Comparing Figs. 8a and 8b, it is observed that memory consumption is greater for orderers because they collect decisions from all the peers for running the consensus protocol. In contrast, access requests are handled at the peers, thus needing greater processing power.

In real-world applications, the networks are usually highly scaled-up with multiple organizations and peers. Hence, peer-to-peer communication would result for the major part of the depicted latency. As long as the network scales up with the cardinality of the ABAC components, the percentage of additional latency introduced due to access check over the default transaction latency will remain similar to that in the experimental results reported above.
# 5 Related Work

With a rapid proliferation of permissioned blockchains in large organizations, research on access control in this domain is also gaining pace. In this section, we review some of the related work in the literature.

Rouhani et al. [17] survey various state-of-the-art access control mechanisms for both public and private blockchains. Iftekhar et al. [9] detail an HLF network setup and chaincode installation process for implementing access control in IoT networks. Only user attributes from client X.509 certificates are considered to write access logic in chaincodes with no support for the other ABAC elements. Another secure data transmission method for IoT devices was proposed by Liang et al. [11] to test the private blockchain network communication performance and security factors for its compatibility in real-world use cases. Liu et al. [12] propose using HLF as an intermediary unit between the users and the IoT device resources. They use three chaincodes to manage policies, resource URLs and access control, respectively. Attributes are, however, not stored on the ledger. Instead, they are received with the request and verified using cryptographic techniques. We compare our work with other existing approaches in Table 2.

Stamatellis et al. [20] propose another similar healthcare framework using HLF where the user id from MSP is used for verification using Idemix to provide anonymity. However, these frameworks lack the ABAC logical access components. A chaincode based access control, specifically for RFID systems, was proposed by Figueroa et al. [7]. However, only *UA* from the MSP *Certs* are considered and *RA* are stored on the state database. Access logic is directly written in chaincode. Thus, any update to the access logic requires re-installing the access chaincode making it quite inflexible. There are also a few other domain-specific models for IoT [5, 13], cloud federation [6], edge computing [21], etc., using HLF similar to the above solutions though with certain variations.

Akhtar et al. [1] develop a blockchain-based auditable access control mechanism for distributed business processes where the access policy is encoded within the smart contracts. Rouhani et al. [18] propose a distributed ABAC system using the HLF network. Users and resources are considered external to the network. Only their attributes and policies are stored on the ledger using chaincodes. An enforcement point intercepts the user requests and redirects them to HLF. There is, however, no support for user certificates as the requester is not a client on the network. Also, only the public attributes are considered. The HLF network is used merely as an intermediary for deciding access rights. Marcus et al. propose a decentralized ledger-based access control [15] tested using an HLF network. The owner stores hashed resource and its access policy containing the public keys of allowed users (similar to ACL) on the ledger. A ring signature scheme is used to verify the requester's id and reconstruct the resource upon access verification.

A critical review of related work highlights an evident lack of generalized and full ABAC support for Hyperledger Fabric. Most of the proposed solutions are either domain-specific or consider only limited ABAC features. Our work fills
this gap and improves upon all the previous work by exercising a highly flexible,
dynamic, and fully functional ABAC for Hyperledger Fabric.

6 Conclusions

In this paper, we have proposed a novel approach for supporting complete
attribute-based access control functionality in a HLF network. We have detailed
the underlying architecture and workflow for exercising access control through
this method. An extensive evaluation using the Caliper benchmarking tool shows
that the performance of this approach for different use cases is very promising.
The additional overhead is within reasonable limits considering that security is
significantly enhanced through ABAC. We also make the network prototype and
the Golang library available to the research community through Github.

Future work in this area would include supporting verifiable credentials for
providing ad hoc access for a requester external to the network by using her
VCs as UA for policy evaluation. Besides, we plan to include support for more
EA in the Golang library. We also aim to extend the library for other chaincode
languages supported by HLF. This architecture is also generalized enough to
support ABAC in any permissioned blockchain irrespective of the platform.

**Acknowledgments.** This research was supported by the National Institutes of Health under award R35GM134927, the Cisco University Research Program Fund under Silicon Valley Community Foundation award number 2020-220329 (3696), and by a research gift received from Cisco University Research. The content is solely the responsibility of the authors and doesn't necessarily represent the official views of agencies funding the research.

References

1. Akhtar, A., et al.: Blockchain based auditable access control for distributed business processes. In: 40th IEEE International Conference on Distributed Computing Systems, pp. 12–22 (2020)

2. Androulaki, E., et al.: Hyperledger fabric: a distributed operating system for permissioned blockchains. In: Proceedings of 13th EuroSys Conference, pp. 1–15 (2018)

3. Brotsis, S., et al.: On the security and privacy of hyperledger fabric: challenges and open issues. In: IEEE World Congress on Services, pp. 197–204 (2020)

4. Chung, T.H., et al.: Guide to attribute based access control (ABAC) definition and considerations. NIST Spec. Publ. 800(162), 162–800 (2014)

5. Ding, S., et al.: A novel attribute-based access control scheme using blockchain for IOT. IEEE Access 7, 38431–38441 (2019)

6. Ferdous, M.S.A.A.: Decentralised runtime monitoring for access control systems in cloud federations. In: IEEE 37th International Conference on Distributed Computing Systems, pp. 2632–2633 (2017)

7. Figueroa, S., et al.: An attribute-based access control using chaincode in RFID systems. In: 10th IFIP International Conference on New Technologies, Mobility and Security, pp. 1–5 (2019)
8. Hu, V.C., et al.: Attribute-based access control. Computer **48**(2), 85–88 (2015)

9. Iftekhar, A., et al.: Hyperledger fabric access control system for internet of things layer in blockchain-based applications. Entropy **23**(8), 1054 (2021)

10. Li, H., Han, D.: Edurss: a blockchain-based educational records secure storage and sharing scheme. IEEE Access **7**, 179273–179289 (2019)

11. Liang, W., et al.: A secure fabric blockchain-based data transmission technique for industrial internet-of-things. IEEE Trans. Ind. Inf. **15**(6), 3582–3592 (2019)

12. Liu, H., et al.: Fabric-iot: a blockchain-based access control system in IOT. IEEE Access **8**, 18207–18218 (2020)

13. Ma, M., et al.: Privacy-oriented blockchain-based distributed key management architecture for hierarchical access control in IoT scenario. IEEE Access **7**, 34045–34059 (2019)

14. Maesa, D., et al.: A blockchain based approach for the definition of auditable access control systems. Comput. Secur. **84**, 93–119 (2019)

15. Markus, I., et al.: Dacc: decentralized ledger based access control for enterprises. In: 2019 IEEE International Conference on Blockchain and Cryptocurrency, pp. 345–351 (2019)

16. Ouaddah, A., et al.: Fairaccess: a new blockchain-based access control framework for the internet of things. Secur. Commun. Netw. **9**(18), 5943–5964 (2017)

17. Rouhani, S., et al.: Blockchain based access control systems: state of the art and challenges. In: 2019 IEEE International Conference on Web Intelligence, pp. 423–428 (2019)

18. Rouhani, S., Belchior, R., Cruz, R.S., Deters, R.: Distributed attribute-based access control system using permissioned blockchain. World Wide Web **24**(5), 1617–1644 (2021). https://doi.org/10.1007/s11280-021-00874-7

19. Sandhu, R., et al.: Role-based access control models. Computer **29**(2), 38–47 (1996)

20. Stamatellis, C., et al.: A privacy-preserving healthcare framework using hyperledger fabric. Sensors **20**(22), 6587 (2020)

21. Stanciu, A.: Blockchain based control system for edge computing. In: 21st International Conference on Control Systems and Computer Science, pp. 667–671 (2017)

22. Xu, M., Chen, X., Kou, G.: A systematic review of blockchain. Financ. Innov. **5**(1), 1–14 (2019). https://doi.org/10.1186/s40854-019-0147-z

23. Zhang, Y., et al.: Attribute-based access control for smart cities: a smart-contract-driven framework. IEEE Internet Things J. **8**(8), 6372–6384 (2021)