2019 IEEE International Conference on Blockchain (Blockchain)

A Permissioned Blockchain based Access Control

System for IOT
MD Azharul Islam Sanjay K. Madria
Department of Computer Science Department of Computer Science
Missouri University of Science and Technology, USA Missouri University of Science and Technology, USA
[email protected] [email protected]

Abstract—IoT devices produce a lot of valuable and sensitive policies are often very high level and obscure. Moreover,
data that is often shared with external parties to provide different there is no way for the data owner to verify whether the
kinds of useful services. Traditional IoT access control systems requester is complying with the agreement and not collecting
are centralized and do not include all the stakeholders in the anything more than what was agreed upon. On top of that,
access control decision making process. To fill this gap, we
propose a permissioned blockchain based access control system it is hard to tell if different service providers implement their
for IoT where a different phase of access control like creating security mechanisms properly. This gives the malicious parties
access policy and making the access control decision happens an opportunity to get access to the user’s confidential and
based on the consensus of all the stakeholders. To be more sensitive IoT device data by exploiting any security backdoor
specific, we design and implement Attribute Based Access Control that may exist.
(ABAC) in a permissioned blockchain called Hyperledger Fabric
and leverage its smartcontract and distributed consensus to The above mentioned problems of IoT data security mainly
enable a distributed access control for IoT. The effectiveness stem from the fact that different parties involved in the
of our proposed system is demonstrated by the performance IoT ecosystem are under different administrative entity and
evaluation result in an IoT testbed. there may be a lack of trust between them. Using traditional
Index Terms—IOT, Blockchain, Access control
approaches like [1], it is impossible to ensure the active par-
I. I NTRODUCTION ticipation of all mutually untrusted parties in different aspects
of the IoT access control mechanism, like fixing the access
As IoT devices are becoming more popular, security and policy and making the access control decision. Blockchain
privacy of the heterogeneous data produced by these devices offers a great platform to build distributed applications for
have become more important than ever before. This is because mutually untrusted parties by eliminating the need of a trusted
the data produced by IoT devices can contain extremely private central authority. At a high level, blockchain is a distributed
information like audio and video clips from smart surveillance immutable ledger maintained by a network of peers where all
systems, medical information from fitness devices, location the peers in the network at any given point of time agrees on a
and activity pattern or even daily schedule of individuals in single identical version of the ledger through some consensus
the house hold. Often times, IoT devices are not utilized to protocol.
their full potential unless this data is shared with different
service providers. For example, data from fitness devices The blockchain empowering the cryptocurrencies like bit-
may need to be shared with the physician and the hospital, coin [2] and Ethereum [3] are called public or permissionless
temperature sensor data may need to be shared with the blockchain as no permission is needed for a peer to participate
emergency department and service providers like Amazon and in the blockchain. While public blockchain is well-suited
Google can collect user data through smart home devices like for cryptocurrency, it has a scalability issue that limits the
Echo, Google home etc. to ensure better quality of service. number of transactions the network can process referred to
While sharing the IoT device data with other parties, there as blockchain bloat [4]. For example, bitcoin can process
are two fundamental questions that need to be asked: 1) Who only a maximum of seven transactions per minute. This is
is accessing the shared data? and 2) What data is accessed? due to the fact that the block creation frequency (1 block
Answer to the first question determines whether the data falls per 10 minutes) and size (1MB) is limited [2]. The security
into the hands of the wrong parties. On the other hand, the of the public blockchain relies on the proof of work (PoW)
second question is to find out whether IoT data requester is where all the peers in the network validate all the transactions
collecting anything without the data owner’s consent. and try to solve a computationally intensive cryptographic
Currently, how data requester collects user data from IoT puzzle. The hardness of the puzzle is set so that a new block
devices lacks transparency and even doubtful in some cases. is created every 10 minutes. Due to the network latency,
This is because the owner has no role in the access control of there exist multiple forks of the blockchain and it can take
how the data will be shared with the data consumer. Although up to six hours to eventually reach a consensus. That is
in some cases, requesters provide the owner with some kind why transaction wait time is very high in pubic blockchain
of agreement policy that the owner has to agree on to enjoy (sometimes up to six hours). Though, consensus protocols
the intended service. This leaves the data owner with no other like proof of stake (PoS) are there, the transaction wait
choice but to trust the data consumer blindly. These agreement time is still high in public blockchain [5]. However, in the
private or permissioned blockchain, the transactions are much
This research has been partially funded by NSF grant CNS 1460697. faster. This is because it does not rely on PoW or PoS.

978-1-7281-4693-5/19/$31.00 ©2019 IEEE 469

DOI 10.1109/Blockchain.2019.00071
Rather, it incorporates much faster consensus protocols like directly intended for IoT. Besides, role-based access control
Byzantine Fault Tolerance (BFT) and yet provides a way to was considered in this work which is not a good fit for IoT
secure the transactions among a group of participants with access control involving a large scale of heterogeneous devices
verified identities who have a common goal but do not fully with lack of standardization.
trust each other [5]. As a result, it is a better fit for IoT
III. BACKGROUND
access control. This inspires us to propose an access control
system for IoT which is based on permissioned blockchain. In this section, we discuss the necessary background of
By utilizing the smartcontract, we implement attribute based for our proposed system. First, we discuss how resource is
access control (ABAC) in the blockchain which is a great managed inside an IoT network. Then, we discuss different
fit for IoT than other access control mechanisms such as components of Hyperledger Fabric.
role based access control or identity based access control. A. Resource Management in an IoT Network
This is because IoT ecosystem consists of a huge number
of IoT devices that varies in functionalities, characteristics Many standards in line with the IEEE 802.15.4 radio [12]
and capabilities. Only ABAC can offer expressive fine-grained were defined by the IETF for IoT networks. IoT-Auth [1]
access control in such a diverse environment. We implement adopted many of these well defined protocols to manage
our access control system in Hyperledger Fabric [5] which is resource within an IoT network. For this purpose, the gateway
an open source implementation of a permissioned blockchain, maintains three data structures: Routing Table, Resource Table,
and evaluate its effectiveness in an IoT testbed. Our results and Data Table. There are following steps involved:
1) Device Discovery: The first step is to do the device
also demonstrates the practicality of our proposed system. The
discovery. It is done according to the Routing Protocol for Low
most closely related work to ours is [6] which is a physical
Power and Lossy Networks (RPL) protocol. More specifically,
access control management system based on permissioned
a network coordinator or sink node initiates this process by pe-
blockchain. However, it is not specifically intended for IoT
riodically sending in the IoT network the Destination Oriented
and it can not therefore enforce fine-grained access control
Directed Acyclic Graph (DODAG) Information Object (DIO)
like ours as role based access control was used. IoT access
message. A newly joining device replies with the Destination
control systems proposed in [7]–[10] are also related to ours.
Advertisement Object (DAO) message. The sink node forwards
Since they are based on public blockchain, it is needless to say
this message to the gateway. The gateway stores the identifier
that all of them inherit the the existing limitations of the public
of all the active IoT end nodes along with their communication
blockchain. Besides, access control mechanisms proposed in
path in the Routing Table.
these works are not as sophisticated as ABAC.
2) Resource Discovery: The gateway starts the process by
Our contributions can be summerized as follows:
sending a GET message to the well-known URI of the IoT de-
• To the best of our knowledge, we are the first to propose vice called ./well-known/core. The IoT device sends a response
a private blockchain based IoT access control system message in the Constrained RESTful Environments (CoRE)
based on attribute based access control. Since our scheme Link Format. The response message includes information such
is based on private blockchain, the access requests are as resource type (rt), interface description (rt), and maximum
resolved much faster than that of a public blockchain. size estimate (sz). These information are processed and stored
• We report a full implementation of our proposed system in the Resource Directory.
in a permissioned blockchain platform called Hyperledger 3) Data collection: The gateway collects data from the
Fabric and prove its practicality by evaluating its perfor- intended IoT device as new data is available. Data is stored in
mance in an IoT testbed environment. the Data Table along with its identity information.
II. R ELATED WORK B. Hyperledger Fabric
Besides cryptocurrency, the adoption of blockchain is also Hyperledger Fabric is an opensource implementation of a
noticeable in the IoT spectrum. For example, an access control permissioned blockchain [5]. It offers a modular architec-
mechanism based on bitcoin was proposed in [4], [7]. Since, ture allowing different kinds of pluggable functionalities by
bitcoin does not support smartcontract, the proposed access leveraging well known and proven technologies. One of the
control mechanism is very basic and does not offer fine- most powerful aspect of Hyperledger Fabric is that it gives a
grained access control for heterogeneous IoT devices. [8] pro- platform to run smartcontracts on the blockchain. Smartcon-
posed an architecture for scalable access management of IoT tracts are special kinds of programs that can be written using
devices based on Ethereum smartcontract where blockchain is traditional programming language such as GO to perform
run in the IoT devices. It was implemented in a small scale different kinds of operations on the underlying blockchain.
local Ethereum test network. However, it is not clear how it is We discuss the core building blocks of Hyperledger Fabric as
going to work in the original pubic Ethereum network. Dorri et follows:
al. proposed a solution in [9]–[11] where an overlay network 1) Peer, Organization, and Client: In Hyperledger Fabric,
is formed by the IoT nodes. Multiple overlay nodes form a peers are the nodes that host the blockchain and runs the
cluster with an elected cluster head (CH) for each cluster. The smartcontract. There could be two basic types of peers based
CHs maintains a newly proposed pubic blockchain. It has a on the role it takes up: validating peer and non-validating
new transaction format and does not have smartcontract which peer. A validating peer runs the consensus protocol, executes
makes implementation of sophisticated access control policy and validates transactions, and maintains the blockchain. A
really hard. An access control management system based on non-validating peer acts as a proxy to connect the external
private blockchain has been proposed in [6] although it was not applications/clients to the validating peers. Some peers can

470
take up a special role of endorsing transactions referred to as
endorsing peers. Peers are part of a conceptual entity called
the organization. Each peer is part of some organization and
multiple organizations collectively maintain the blockchain.
On the other hand, clients are the entities that submit transac-
tion requests to the blockchain. They are normally third-party
applications written by the provided SDK.
2) Membership Service Provider (MSP): The permission
to participate in the blockchain is handled by the MSP. For
example, every peer needs to collect enrollment certificate and
transaction certificate from the designated certificate authority
(CA) of the MSP to connect to the network and submit trans-
actions, respectively. Each organization can have a separate
MSP that independently operates its own membership service.
3) Transaction Endorsement: Hyperledger fabric does not
rely on proof-of-work or proof-of-stake to maintain the im-
mutability of the blockchain or to prevent double spending. Fig. 1: System Architecture
Rather, it relies on the endorsement policy that states which
peers need to endorse a transaction to be considered as (such as temperature, pressure, humidity, luminosity, etc.) to
a valid one. An endorsement policy is written using en- healthcare data generated by wearable devices or even image,
dorsement policy syntax. For example, endorsement policy audio and video data generated by surveillance systems.
OR(’Org1.peer1’, AND(’Org2.peer2’, ’Org3.peer3’)) states 2) Requester: Any party that accesses data generated by
that transaction needs to be endorsed by either peer1 of Org1 IoT devices is a requester. Normally, a party who relies on the
or by both peer2 of Org2 and peer3 of Org3. IoT data to provide different kinds of service is considered as
4) Ordering Service: The ordering service accepts endorsed data requester. For instance, google, amazon provides services
transactions from the client, orders them according to the like music streaming, voice search result etc. based on the data
plugged-in consensus protocol, and delivers them to the des- provided by google home, amazon echo. Emergency service
ignated peers to be written in the blockchain. It guarantees the providers such as hospitals, fire service etc. are also requesters
proper ordering of the transactions that ensures the consensus. since emergency services may rely on the IoT device such as
5) Chaincode: Chaincode is similar to smartcontract in the elderly monitoring device, or different healthcare devices for
context of Hyperledger Fabric. These are piece of programs data. Different research organizations may also rely on user
written in traditional programming language such as Go, IoT data to conduct scientific research and survey. Finally,
java, and node.js and can manipulate the blockchan. In this regulatory organizations are also considered as requester since
paper, we will use the term smart contract and chaincode they may need to access IoT data for auditing purpose. These
interchangeably. requesters are generally external to the IoT local network and
6) Blockchain Data Structures: Blockchain in Hyperledger access IoT data by through access control mechanism imposed
Fabric incorporating two different kinds of data structures: by blockchain.
state and ledger. State stores the latest state of the blockchain
by modeling it as a key-value storage (KVS). It is maintained B. Components
and hosted by the peers and can be manipulated from the The main components of our system are the local IoT
chaincode, triggered by transactions. On the other hand, ledger networks and the blockchain. A brief discussion of these
stores the verifiable history of all the unsuccessful attempts components are given below:
and successful change made in the state as a totally ordered 1) Local IoT Network: Each local IoT network is composed
hashchain of blocks of transactions. of one or more IoT devices, a sink node and a gateway. The
IV. P ROPOSED S YSTEM A RCHITECTURE sink node works like a network coordinator for all the IoT
devices and is connected to the gateway. The gateway acts as
We discuss our system architecture in this section. Our an interface to the external world to access any resource within
proposed architecture is depicted in Fig.1. In the following the local IoT network. A gateway can have its own public IP
subsections, we first discuss the main actors of our system. address or may be connected to the cloud that provides it
Then, we discuss the main components followed by how the with a public interface so that resource requesters can access
constrained IoT resource is accessed by a requester who is IoT data from outside the local IoT network. It manages all
external to the IoT network. the information available within the IoT network. For this
purpose, it maintains three data structures named as Routing
A. Actors Table, Resource Dictionary, and Data Table. According to our
There are mainly two types of actors in our system as architecture, there can be many local IoT networks as such,
discussed below: each representative of an IoT equipped smart home, office or
1) Resource Provider/Owner: This actor is basically the school etc.
owner of the IoT equipped smart home, smart office, school 2) Blockchain: The blockchain in our architecture is a
etc. where variety of IoT devices produce different kinds of permissioned one, implemented in Hyperledger Fabric. All the
data. The data could range from environment sensing data attributes and ABAC policies upon validation are stored in the

471
 TxID, τ = Sig(H(TxID), SK Re ) to the gateway indicating its
intention to access the IoT resource (step 12). In step 13, the
gateway checks the authenticity of the request by verifying the
requester’s signature as in H(TxID) == Ver(τ , VK Re ). Later in
step 14, the gateway queries the blockchain for transaction Tx
with TxID and gets the Tx as response. Then (in step 15),
upon confirming if the transaction was marked as accept, the
gateway retrieves the session key k by decrypting C with its
decryption key as k = Dec(C, DK Ow ). The gateway checks if
the resource is sent to the proper requester by verifying σ
using Eqn. 2 with the same verification key used to verify τ .
If the requested resource according to the policy is available in
the Data Table, the gateway sends to the requester the data D
Fig. 2: Resource Access right away by symmetrically encrypting it with k as in E(D,k)
(step 18). Otherwise, the gateway polls the resource from the
blockchain. It also works as a policy enforcement point for designated IoT device(s). That is why steps 16 and 17 are
any access request to a particular IoT resource. In brief, the shown in dotted arrows.
blockchain provides an unified ABAC platform for the entire
IoT ecosystem. V. D ETAILS OF OUR ABAC MODEL
C. Resource Access Process by the Requester In this section, we discuss our attribute based access con-
The sequence diagram presented in Fig. 2 shows how the trol (ABAC) model in detail. This includes how we model
IoT resource is accessed by the requester. Steps 1, 2, 3, and 4 attributes and policies and how those policies are evaluated
is for the Device Discovery and populating the Routing Table. against attributes.
Steps 5, 6, and 7 are to complete the Resource Discovery
process and populate the Resource Table as described in A. Modeling Attributes
Sec. III-A. At this point, a requester who is external to the Attribute is a core component of our ABAC system. We
IoT local network, can request for IoT resource. First, the model attribute as a multi-component data structure. Each
requester sends the authorization request as an access request attribute is composed of three components: name, value, and
transaction Tx (step 8). Let PK Ow and DK Ow be the public and type. Name is simply a string. On the other hand, value can
private key of the IoT resource provider/owner respectively; be any data type such as string, numeric, date etc. The general
Enc and Dec be the public key encryption and decryption representation of an attribute is as follows:
algorithm respectively; SK Re and VK Re be the requester’s
signing and verification key respectively; Sig and Ver be the attti = (name, t, val) (4)
DSA (Digital Signature Algorithm) signing and verification
algorithm respectively, and H(.) be a secure hash function. In name, t, and val stands for the name, type, and value of the
the authorization request, the requester sends the following attribute, respectively. We use the dot (.) operator to access an
information: assigned member of an attribute, i.e. attti .val is used to access
the assigned values of attti . The set of all possible values of an
Req = (Resource Location, policyID, C), σ (1)
attribute attti is denoted as Val(attti ) = {vali,j : 1 ≤ j ≤ Mi }.
Resource Location is Eqn. 1 is the IP address or public M i is the total number of possible values of atti . In our system,
interface of the gateway of the intended IoT network, PolicyID we consider the following four types of attributes:
is the ID of the ABAC policy that determines the access control 1) Subject Attribute: This type of attribute is used to com-
rule of the resource. C = Enc(k, PK Ow ), where k is a session pletely describe the requester or the resource owner. Examples
key. Signature σ is computed as σ = Sig(H(Req), SK Re ). of subject attribute can be the organization, title, rank etc. Let
In step 9, each endorsing peer in the blockchain first checks attSub
i and NSub be a subject attribute and the total number
the validity of the request by checking the following equality: of subject attributes in the system, respectively. Then, the set
of all subject attributes are expressed as Attr(Sub) = {attSub i :
H(Req) == Ver(σ, VK Re ) (2)
1 ≤ i ≤ NSub }.
Then, the policy corresponding to the PolicyID is retrieved 2) Resource Attribute: Anything that can describe the IoT
from the blockchain. Each endorsing peer evaluates the re- resource properly are considered as resource attributes and
quest in the smartcontract against the policy. In step 10, the is denoted as attRes i . For example, the IoT resource name,
transaction is marked as accept / reject based on the consensus type, identifier etc. are resource attributes. If there are NRes
protocol and committed in the blockchain. The following resource attributes in the system, then all resource attributes
information is saved in the transaction: are represented as Attr(Res) = {attRes i : 1 ≤ i ≤ NRes }.
3) Environment Attribute: Time, location etc. related at-
TxID, Tx = (Req, σ, Decision) (3)
tributes are considered as environment attributes and are repre-
Here, TxID is a unique ID for Tx, and Decision can have as sented as attEnv
i . We assume that there are NEnv environment
a value either accept or reject. Then, the requester gets the attribute in total and express them as Attr(Env) = {attEnv i :
TxID from the blockchain (step 11). Later, the requester sends 1 ≤ i ≤ NEnv }.

472
 4) Action Attribute: Any type of action the requester or Finally, the satisfaction of a complete policy P by an attribute
resource owner is allowed to perform falls into this category. set A = {ASub , ARes , AEnv , AAct } is represented by the follow-
Example includes attributes such as read, write, delete, update ing notation:
etc. Action attributes are represented as attAct
i . Let Attr(Act)

be the set of all NAct possible action attributes in the system false, if ∃At ∈ A : Pt  At = false,
PA=
which is expressed as Attr(Act) = {attAct
i : 1 ≤ i ≤ NAct }. true, otherwise.
B. Modeling Policy VI. ABAC IMPLEMENTATION IN H YPERLEDGER FABRIC
A policy is expressed as a boolean expression that defines In this section, we discuss how our ABAC model discussed
the access rule to a resource in terms of attributes and their in the previous section is implemented in Hyperledger Fabric.
corresponding values. In our ABAC model, policies are very The first step towards our ABAC implementation is to form the
expressive as both attribute values and attributes themselves blockchain network. After that, attribute creation and assign-
are boolean expressions. A complete policy consists of at- ment, policy creation and resource access request are done by
tribute value expression and attribute expression as discussed sending transactions to the blockchain by the requester. These
below: steps are discussed in the following subsections.
1) Attribute Value Expression: Allowed values of an at-
tribute attti in a policy are expressed as the following boolean A. Forming the Blockchain Network
expression: The permission to join the blockchain is managed by the
MSP (Managed Service Provider) of some high-level orga-
Eattti := Exp (E[, E]) (5)
nizations. For our ABAC implementation in the Hyperledger
In Eqn. 5, Exp is either AND or OR joining two boolean Fabric, we assume that there exist multiple high level orga-
expressions and E is either an attribute value vali,j ∈ Val(attti ) nizations. For example, an organization may represent all the
or a recursive call to Exp. regulatory institutions, companies like google, amazon who
2) Attribute Expression: For each attribute type t, we use a provide IoT based services can have their own authoritative
separate policy Pt . Each such policy is a boolean expression organizations in the blockchain, and research institutions can
composed of t type attributes as in: have an authoritative organization as well. Finally, the data
owners must be part of some organization also. For example, a
Pt := Exp (E[, E]) (6) smart city can play the role of an organization for all the smart
home owners of that city. Each organization may have one or
In the above equation, E is either an attribute value expression more running peers. It is worth noting that the data owners
Eattti or a recursive call to Exp. Finally, the combined policy need to have their own running peers to be able to directly
is written as a conjunction of all four types of policies as in take part in the access control decision making process of their
Eqn. 7: data. There will be some dedicated nodes that will perform the
P = PSub AND PRes AND PEnv AND PAct (7) ordering service. Peers from different organizations along with
the ordering service collectively form and run the blockchain.
C. Policy Evaluation
B. Setting up the Endorsement Policy
Granting an access request for a resource is determined by
evaluating a policy against a set of subject, object, environment The consensus in hyperledger fabric largely depends on the
and action attributes. A complete policy P contains four at- endorsement policy. This is because it dictates who need to en-
tribute expressions and each attribute in an attribute expression dorse a particular transaction to be considered by the validating
contains an attribute value expression. So, evaluation of P can peers as a valid one. A data owner fixes the endorsement policy
be broken down into following two parts: by creating a configuration transaction in the blockchain. The
1) Evaluation of Attribute Value Expression: If S ⊂ endorsement policy along with the identity of all the endorsing
Val(attti ) is a set of assigned values to a particular attribute attti , peers are embedded in this transaction. An endorsement policy
and I is the minimum number of values required to satisfy creates a logical channel between the endorsing peers and the
the boolean expression in Eattti , then we say that attti satisfies ordering service. In order to be committed in the blockchain,
Eattti if I ⊂ S. It is expressed by the following notation: transactions submitted to a channel need to be endorsed by the
channel’s endorsing peers according to the endorsement policy.

true, if I ⊂ S, Different data owners will have different endorsement policies.
Eattti  attti = Hence, many channels as such will exist in the Hyperledger
false, otherwise. Fabric.
2) Evaluation of Attribute Expression: Let It be the min- C. Attribute Management
imum number of required attributes to satisfy the boolean
expression in Pt , and Eattti  attti = true for ∀attti ∈ It where For an ABAC system to function properly, attributes should
Eattti ∈ Pt . Then we say that attribute set At ⊂ Att(t) satisfies be created with name, type and a set of allowable values.
Pt if It ⊂ At , and it is represented by the following notation: After creating attributes, they need to be assigned to different
 entities. Subject attributes are created and assigned to the spe-
true, if It ⊂ At , cific subject by an attribute authority through an administration
Pt  At = point. There are multiple such authorities, each with authority
false, otherwise.
over different set of subject attributes. In our blockchain based

473
ABAC model, the MSP of each organization plays the role as a key-value pair with key being policyID = H(P), and the
of this attribute authority. Resource attributes on the other value being the policy itself.
hand are created and assigned to the specific resource by the Meta Policy: Some policies may require meta policy. It
owner of that resource. Environment and action attributes are determines things like who can modify or delete the actual
system wide common, and must be created by the regulatory policy P, the validity period of P etc. Meta policy is denoted
organizations. We use general terms attribute creator and issuer by MP and modeled in the similar fashion as the original
to refer to the entity responsible for attribute management. policy except the resource attribute expression PRes points
In practice, they are the same entity. Attribute creation and to P. Meta policy is included in the blockchain transaction
assignment is handled by a smart contract function named when the policy is created. Default meta policy applies to the
AttributeMgr and details are discussed below. policies that do not have any meta policy. According to the
1) Attribute Creation: No attribute can be used in our default policy, only the resource owner can modify or delete
system without registering it in the blockchain. To register the policy. For the security purpose, meta policy is assumed
an attribute, the creator first sends a transaction request in the to be immutable.
bockchain. Within the transaction, the complete attribute struc- A smartcontract function named PolicyMgr is responsible
ture as in Eqn. 4 is embedded. AttributeMgr parses the attribute for policy management tasks such as checking the semantics
from the transaction, checks the semantics, and converts it into while policy creation and modifying the policy according to
a json object. Besides name, type and value, some additional the meta policy.
fields such as creatorID, organization name (orgName) are
E. Policy Evaluation
also added in the json object. Upon endorsement, ordering and
verification phase, the json object is written in the key-value The policy evaluation logic is implemented in a smart
storage of Hyperledger Fabric called the state. One critical contract function called ACDecMaker (access control de-
issue of ABAC system is the conflict resolution of attributes. cision maker). The endorsing peers responsible for en-
Conflict during the attribute creation occurs when two different dorsing resource access request transaction Tx (Eqn. 3)
attributes with the same name are created by two different invoke this smartcontract. ACDecMaker takes as input
creators. For example, manager attribute of org A is different Req = (Resource Location, policyID, C), σ and checks if the
from the manager attribute of org B. The system should allow access policy P corresponding to the policyID is satisfied by
both org A and org B to create manager attribute. At the same the relevant attribute set A. The algorithm for ACDecMaker
time, the system should know the difference between them. is shown in Alg. 1.
AttributeMgr resolves this issue prior to writing the attribute in
the state by creating unique IDs for each attribute as follows: Algorithm 1
  Procedure: ACDecMaker ( Req, σ)
IDattti = H orgName || creatorID || attti .name || attti .t 1: get policy P from the state database for key Req.policyID
2: get the relevant attribute set A = {ASub , ARes , AEnv , AAct }
IDattti is used as the key for the attribute when stored in the
from the state database
state. Two attributes with the same key cannot be stored in the
3: if H(Req) != Ver(σ, VK Re ) then
state. This allows the creation of attributes with same name
4: return (TxID, Tx = (Req, σ, reject))
by two different creators while restricting same creator from
5: end if
creating duplicate attributes.
6: for each (At , Pt ) in (A, P) do
2) Attribute Assignment: After attribute creation, the issuer 7: if Pt  At == true then
has to assign the attribute along with the appropriate set of 8: continue
values to the proper entities. It is important to take enough se- 9: else
curity measures so that attributes cannot be altered or tampered 10: return (TxID, Tx = (Req, σ, reject))
with to maliciously satisfy an access policy. To accomplish 11: end if
this, we cryptographically bound attributes to the entities. 12: end for
During attribute assignment, the attribute issuer would add 13: return (TxID, Tx = (Req, σ, accept))
the attributes to the attributes field of an X.509 attribute
certificate (AC) according to the IETF standard [13]. The
issuer sends this certificate by embedding it in a blockchain VII. E XPERIMENT
transaction. AttributeMgr verifies the certificate and converts
it in a json object to store it in the state. Finally, it is stored in We did a full implementation of our blockchain based access
the state after endorsement, ordering and verification phase. control system in order to demonstrate the practicality of our
solution. In the following section, we first provide details of
D. ABAC Policy Management our implementation, i.e. blockchain and IoT network testbed
implementation. Then, we evaluate the performance of our
In our blockchain based access control system, access to system by experiments.
the restricted IoT resource is controlled by the ABAC access
policy. Both the IoT resource owner and requester first agrees A. The IoT Network
on a policy which is expressed according to our policy model We have developed an IoT testbed in our lab using MEM-
as discussed in Sec. V-B. The policy is sent in a blockchain SICs TelosB Mote TPR2420CA devices [14]. TPR2420CA
transaction. The transaction has to be endorsed by both the bundles many essential elements required to perform IoT
resource owner and the requester. It is then written in the state based lab studies such as an integrated temperature, light

474
TABLE I: Endorsement policy for IoT resource access control 800 block size: 10

Latency (ms.)
of different IoT groups
600 block size: 20
ID Endorsement Policy Intended IoT group block size: 30
1 Any peer from OrgA, OrgB or OrgC Group 1 400
2 At least one peer from each Org Group 2
3 All peers from OrgA, OrgB, and OrgC Group 3 200
0
20 40 60
and humidity sensor, an IEEE 802.15.4 radio with integrated Transaction Arrival Rate (tps)
antenna etc. In our testbed, we divide the sensors into three
groups: group 1, 2, and 3. Each group has four TPR2420CA Fig. 3: Attribute Creation
devices- three of them act as IoT end device and one serves as 1,000
block size: 10

Latency (ms.)
the purpose of a sink node. All three sink nodes are connected 800
block size: 20
to a PC through a USB hub and directly communicate with the 600 block size: 30
PC through USB port. For each group, the PC runs a separate 400
gateway program. The gateway program is written in java and
200
uses SQLite for storing Routing Table, Resource Dictionary,
and Data Table. Each group along with the gateway forms an 0
20 40 60
individual IoT network. The device discovery and the resource
discovery within the IoT network is done according to the Transaction Arrival Rate (tps)
IEEE 802.15.4 standard as discussed in Sec. III-A. Each group Fig. 4: Attribute Assignment
of our testbed represents an IoT equipped smart home, office
or school etc. in real life. creation, attribute is assigned to different entities. In our
experimental setup, we create 20 subject, 20 resource, 10
B. The Blockchain Network environment and 5 action attributes, each having 5 values.
Our blockchain network has been implemented in Hyper- Five different ABAC policies were created with the number
ledger Fabric v1.3 [15]. We have considered three different of attributes required to be satisfied ranging from 10 to 50.
organizations: OrgA, OrgB, and OrgC for our Hyperledger
Fabric setup. We assume that all IoT resource owners be- C. Workloads and Experimental results
long to OrgA and each of them has a running peer under
OrgA (OrgA.peer1-3). OrgB is the representative organiza- We show the performance of our scheme in terms of
tion for all resource requesters and there are five running how fast different ABAC actions can be performed. All the
peers (OrgB.peer1-5) under it. Finally, we assume that OrgC results presented are averaged over five runs. Three of the
represents all regulatory organizations and there are three most important fabric configurable parameters are the stateDB,
running peers (OrgC.peer1-3) under it. All peers of OrgA are endorsement policy, and block size. Between the two choices
hosted in a desktop with Intel® Core [email protected] GHz × 4 of GoLevelDB and CouchDB, we choose stateDB as it was
processor and 8 GB RAM running Ubuntu 16.04. A desktop shown in [16] that GoLevelDB has better throughput and faster
with Xeon(R) [email protected] GHz × 8 processor and 16 GB read/write. A new block is created when either the number of
RAM running Ubuntu server 16.04.3 was used to host all the pending transactions since the last written block reaches the
OrgB peers. Peers of OrgC run in a desktop which has the block size or timeout happens. We set the timeout to be 1
similar configuration as that of OrgA. As the ordering service, second. Then, we examine the latency for attribute creation,
we have two orderer nodes backed by a kafka-zookeeper attribute assignment and policy creation operations for block
cluster. The ordering service runs in a separate desktop having size values 10, 20, and 30 with three different transaction
the same configuration as that of OrgA. arrival rates (20, 40 and 60 transactions per second). It is
We have written a java web based client application us- noticeable from Fig. 3, 4, and 5 that the latency increases with
ing the fabric client SDK to interact with the blockchain. the increase in block size. For example, when the transaction
This client application provides a simple interface to create arrival rate for attribute creation (Fig. 3) is at 40, an increase
attributes, assign attributes to a particular entity and create in the block size from 10 to 30 increases the latency by 3-fold
ABAC policy targeting a specific resource. from 255 ms. to 805 ms. This is because with larger block
During the bootstrap phase, the MSP of each organization size, a pending transaction has to wait a little longer at the
provides the participants with necessary crypto materials, i.e. orderer queue causing delay in the transaction writing rate in
certificates, signature keys, and encryption keys. Then, three the blockchain on average. Between attribute creation, attribute
different endorsement policies are created for three different assignment, and policy creation, we observe that attribute
IoT groups as in Table I. After setting up the endorsement assignment takes longer on average compared to the other two
policies, our smartcontract with three main functions, i.e. operations. The reason for this is that AttributeMgr in this case
AttributeMgr, PolicyMrg, and ACDecMaker is installed in each verifies the signatureVale in X.509 attribute certificate
peer. Then, the MSP of each organization creates subject which is an expensive cryptographic operation. Across the
attributes and registers in the blockchain. Environment and board, we notice the lowest latency when the transaction
action attributes are created by the MSP of OrgC. Finally, arrival rate is at 40 tps and the block size is 10. Note that,
the resource attributes for each IoT group is created by their we use the first endorsement policy in Table I for the three
respective owner using the client application. After attribute experiments discussed above.

475
 1,000 VIII. C ONCLUSION AND F UTURE W ORK
block size: 10
Latency (ms.)

800 Any public blockchain based IoT access control system

block size: 20 inherits the shortcomings of a public blockchain. On the other
600 block size: 30 hand, permissioned blockchain can overcome these limitations
400
with a very small number of peers whose identities are verified
200 but are not necessarily trusted to each other. This motivates
0 us to design and implement a permissioned blockchain based
20 40 60 access control system for IoT in Hyperledger Fabric. By using
Transaction Arrival Rate (tps) attribute based access control (ABAC) as our access control
model, we can provide fine-grained access control while
Fig. 5: Policy Creation IoT devices share resource (data) with external parties. By
running experiments in an IoT testbed, we have fine-tuned our
blockchain network for access control by finding the optimum
3.5 parameter values for our network (block timeout = 1s, block
3 size = 20 at 40 transactions per second). Using the optimum
Latency (Sec.)

without access control Group 1 parameter values, we show that our access control system can
2.5 Group 2 Group 3 serve access request of IoT resources much faster than public
2
blockchain. The ABAC policy evaluation algorithm we have
1.5 used is NP-complete. Thus, in our future work, we plan to
1 reduce the latency even more by optimizing this algorithm.
0.5 R EFERENCES
0 [1] S. Sciancalepore, G. Piro, D. Caldarola, G. Boggia, and G. Bianchi,
10 20 30 40 50 “Oauth-iot: An access control framework for the internet of things
Required number of attributes to satisfy ABAC policy based on open standards,” in 2017 IEEE Symposium on Computers and
Communications (ISCC), pp. 676–681, IEEE, 2017.
[2] S. Nakamoto et al., “Bitcoin: A peer-to-peer electronic cash system,”
Fig. 6: Latency of serving IoT resource access request 2008.
[3] G. Wood, “Ethereum: A secure decentralised generalised transaction
ledger,” Ethereum project yellow paper, vol. 151, pp. 1–32, 2014.
For the next experiment (Fig. 6), we set the block size to [4] A. Ouaddah, A. Abou Elkalam, and A. Ait Ouahman, “Fairaccess: a new
be 10 and transaction arrival rate at 40 tps which was found blockchain-based access control framework for the internet of things,”
to be the optimum for our Hyperledger Fabric setup. Besides, Security and Communication Networks, vol. 9, pp. 5943–5964, 2016.
[5] E. Androulaki, A. Barger, V. Bortnikov, C. Cachin, K. Christidis,
hash function H, public key encryption (Enc, Dec), and digital D. De Caro, C. Ferris, G. Laventman, Y. Manevich, et al., “Hyperledger
signature (Sig, Ver) were implemented using SHA-256, RSA- fabric: a distributed operating system for permissioned blockchains,” in
1024, and DSA with 1024 bits key size, respectively. With Proceedings of the Thirteenth EuroSys Conference, p. 30, ACM, 2018.
[6] S. Rouhani, V. Pourheidari, and R. Deters, “Physical access control
these parameters fixed, we measure the latency of serving IoT management system based on permissioned blockchain,” arXiv preprint
resource access request for different types of ABAC policies arXiv:1901.09873, 2019.
in different IoT groups configured with different endorsement [7] A. Ouaddah, A. A. Elkalam, and A. A. Ouahman, “Towards a novel
privacy-preserving access control model based on blockchain technology
policies as stated in Table I. As a baseline comparison, the in iot,” in Europe and MENA Cooperation Advances in Information and
latency of serving IoT resource is shown when no access Communication Technologies, pp. 523–533, Springer, 2017.
control mechanism is in place. We observe that latency is the [8] O. Novo, “Blockchain meets iot: An architecture for scalable access
management in iot,” IEEE Internet of Things Journal, vol. 5, no. 2,
lowest (.4 sec.) when there is no access control mechanism pp. 1184–1195, 2018.
in place. On the other hand, group 3 has much higher latency [9] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, “Blockchain for
compared to group 1 and 2. The reason is that the endorsement iot security and privacy: The case study of a smart home,” in 2017 IEEE
International Conference on Pervasive Computing and Communications
policy of group 3 requires all 11 peers to endorse a transaction Workshops (PerCom Workshops), pp. 618–623, IEEE, 2017.
while group 1 and 2 requires only 1 and 3, respectively. The [10] A. Dorri, S. S. Kanhere, and R. Jurdak, “Towards an optimized
latency also increases with the increase in required number blockchain for iot,” in The second international conference on Internet-
of-Things design and implementation, pp. 173–178, ACM, 2017.
of attributes to satisfy ABAC policy. This is because ABAC [11] A. Dorri, S. S. Kanhere, and R. Jurdak, “Blockchain in internet of things:
policy evaluation algorithm is NP-complete and therefore, the challenges and solutions,” arXiv preprint arXiv:1608.05187, 2016.
complexity increases with the number of attributes in the [12] M. R. Palattella, N. Accettura, X. Vilajosana, T. Watteyne, L. A.
Grieco, G. Boggia, and M. Dohler, “Standardized protocol stack for
policy. the internet of (important) things,” IEEE communications surveys &
Public blockchain based IoT access control schemes are still tutorials, vol. 15, no. 3, pp. 1389–1406, 2013.
[13] S. Farrell, R. Housley, and S. Turner, “An internet attribute certificate
limited by the very high transaction latency. For example, profile for authorization,” tech. rep., 2010.
it may take several hours before a bitcoin transaction is [14] “Telosb motes, 2017.” http://www.memsic.com/info/aceinna-
committed in the blockchain. So, it is not suitable for any landing.cfm?nu=/wireless-sensor-networks.
[15] “Hyperledger fabric v1.3.” https://hyperledger-
IoT access control scenario requiring low transaction latency. fabric.readthedocs.io/en/release-1.3/whatsnew.html.
For instance, medical emergency service requires quick access [16] P. Thakkar, S. Nathan, and B. Viswanathan, “Performance benchmarking
to the wearable device data of elderly people. Our permis- and optimizing hyperledger fabric blockchain platform,” in 2018 IEEE
26th International Symposium on Modeling, Analysis, and Simulation of
sioned blockchain based scheme can serve IoT resource access Computer and Telecommunication Systems (MASCOTS), pp. 264–276,
request much faster (around 4 sec.) by utilizing the low IEEE, 2018.
transaction latency in Hyperledger Fabric.

476