# A Blockchain-based Decentralised and Dynamic Authorisation Scheme for the
Internet of Things

Khizar Hameed<EMAIL_ADDRESS>Ali Raza<EMAIL_ADDRESS>Saurabh Garg<EMAIL_ADDRESS>Muhammad Bilal Amin
<EMAIL_ADDRESS>Discipline of ICT, School of Technology, Environments,
and Design, University of Tasmania, Australia

###### Abstract

An authorisation has been recognised as an important security measure for
preventing unauthorised access to critical resources, such as devices and
data, within the Internet of Things (IoT) networks. To achieve authorisation,
access control mechanisms are extensively utilised, restricting the user’s
actions within the network or system based on predetermined access control
policies with specific control actions. Existing authorisation methods for the
IoT network is based on traditional access control models, which have several
drawbacks, including architecture centralisation, policy tampering, access
rights validation, malicious third party policy assignment and control, and
network-related overheads. The increasing trend of integrating Blockchain
technology with IoT networks demonstrates its importance and potential to
address the shortcomings of traditional IoT network authorisation mechanisms.
However, existing Blockchain-based authorisation solutions for IoT networks
overlook the importance of utilising the full potential of Blockchain
technology and under-perform to handle the dynamicity of the underlying
network in terms of malicious user behaviour, static policies, and
auditability of user requests and resources. This paper proposes a
decentralised secure, dynamic, and flexible authorisation scheme for IoT
networks based on attribute-based access control (ABAC) fine-grained policies
stored on a distributed immutable ledger. We design a Blockchain-based ABAC
policy management framework divided into Attribute Management Authority (AMA)
and Policy Management Authority (PMA) frameworks that use smart contract
features to initialise, store, and manage attributes and policies on the
Blockchain. To achieve flexibility and dynamicity in the authorisation
process, we capture and utilise the environmental-related attributes in
conjunction with the subject and object attributes of the ABAC model to define
the policies. Furthermore, we designed the Blockchain-based Access Management
Framework (AMF) to manage user requests to access IoT devices while
maintaining the privacy and auditability of user requests and assigned
policies. We implemented a prototype of our proposed scheme and executed it on
the local Ethereum Blockchain. Finally, we demonstrated the applicability and
flexibility of our proposed scheme for an IoT-based smart home scenario,
taking into account deployment, execution and financial costs.

###### keywords:

Internet of things , Authorisation , Access control , Blockchain technology ,
Smart contracts , Dynamicity , Attribute-based access control

††journal: Journal Name

##  1 Introduction

Technological innovations for the Internet of Things (IoT) networks are
constantly emerging, resulting in an explosion of connected resources such as
sensors, embedded and intelligent devices [1]. As a result, the globe is set
to experience an unprecedented level of IoT in the following years, with 30
billion connected devices expected by 2025. While the expansion of IoT devices
undoubtedly benefits the economy, it also creates severe security risks for
IoT networks, as sensitive data from IoT devices is collected, analysed,
aggregated, and shared across a variety of IoT-based platforms [2]. For
instance, an adversary may exploit a system vulnerability by deploying a large
number of untrusted devices in order to get unauthorised access to system
resources. Data, services or applications, and hardware components (e.g.,
storage, computation) are the resources of IoT-based systems. Thus, protecting
resources from unauthorised access is a challenging problem in an
untrustworthy IoT-based environment [3].

Authentication and authorisation are the primary security requirements for
protecting system resources. System administrators employ authorisation
methods following authentication procedures to ensure that users are authentic
and meet the initial security criteria for accessing specific resources [4].
To achieve authorisation, access control acts as a protection mechanism to
prevent an unauthenticated user from accessing sensitive resources by
implementing regulation policies that specify what activities the users can
undertake. For example, the regulation imposes selective access controls that
govern who (an entity, such as a company) can access and what (a resource,
such as data) can be accessed under particular scenarios [5].

Numerous access control models have been adopted to protect system resources,
and each model facilitates the mapping of user access levels to specified
metrics. For example, Role-Based Access Control (RBAC) [6] links user access
levels to their roles in an organisation’s structure, Attribute-based access
control (ABAC) [7] links different access control levels to a user’s
attributes, and Capability-based Access Control (CapBAC) [8] assesses a user’s
capabilities to determine the appropriate access control level. Although many
studies indicate that these traditional access control methods can be used in
IoT-based environments, implementing them in real-world situations raises
concerns due to architecture-level capabilities such as centralised networks,
protocol constraints, device heterogeneity, scalability requirements, and
functional limitations in IoT-based environments [9]. Further, untrustworthy
parties can potentially tamper with access policies in distributed
environments, compromising system security by giving access unauthorised
access to the users [10]. Apart from these integration concerns, each access
control method has its own limitations, such as the rigour of fine-grained
authorisation in RBAC, the management of attributes and policies in ABAC, and
the flexibility of access privilege transfer in CapBAC. To summarise,
implementing these traditional access control models to the IoT entails
extensive research to overcome these challenges.

In recent years, the integration of Blockchain technology into the IoT has led
to the development of robust and significant security solutions, most
prominently for distributed and secure authorisation methods in IoT networks.
Due to the numerous potential benefits of Blockchain technology, including
decentralisation, immutability, consensus-mechanism, transparency,
accessibility, autonomy, and accountability, a number of research studies are
focusing on resolving a variety of issues associated with existing
authorisation mechanisms for IoT devices, such as a single point of failure,
data and policy tampering, insufficient control and transparency, and
scalability. For instance, the initial Blockchain-based proposals [11] [12]
[13] [14] for device authorisation in decentralised IoT environments are
focused on resolving issues of a single point of failure and policy tampering
by storing all access control policies as transactions on the distributed
immutable ledger and enforcing all access control policies via the service
providers. Furthermore, with the utilisation of smart contract features in
designing the authorisation schemes for IoT, the authors in [15] [16] [17]
presented the access control schemes that exploit the Blockchain’s smart
contract capabilities to execute the access control policies automatically and
to further achieve transparency by maintaining and storing access permissions
on the different Blockchains such as public and private. Similarly, Hossein et
al. [18] presented an access control mechanism for IoT that employs a
distributed tempered-proof feature of Blockchain to store access rights.
Furthermore, Novo [19] presented a Blockchain-based distributed architecture
for storing arbitrating roles and access control permissions on Blockchain to
address the scalability problem of managing access to restricted devices in
the IoT environments.

###  1.1 Motivation and problem formulation

Following a comprehensive study of the literature on approaches for secure
authorisation in IoT-based networks, we identify the security requirements and
objectives for designing a Blockchain-based trustworthy, flexible, fine-
grained, and dynamic decentralised authorisation scheme. Then, based on the
security requirements, objectives, and gaps in previous works, we derive
motivation and formulate a research problem for our proposed scheme.

####  1.1.1 Security requirements

We outline the following security requirements that must be met in our
proposed scheme to enable secure user authorisation to access critical
resources (e.g., IoT devices) in IoT-based networks: (i) The proposed scheme
must support the decentralised architecture in order to eliminate the single
point of failure issue in existing centralised authorisation or access control
mechanisms, where rules were created and managed by a single authority only,
(ii) Critical resources, such as IoT devices and their stored data must be
protected from unauthorised access, (iii) The scheme must ensure that only
authorised or relevant authorities have the authority to define and modify
policies, guaranteeing that policies are secure in a distributed tamper-proof
manner, (iv) The privacy of users who access system-critical resources and the
security of their sensitive information must be ensured, (v) The user’s
requests to access system-critical resources must be auditable to establish
their behaviour, which contributes to the dynamic nature of the deployed
environment.

####  1.1.2 Objectives

Along with defining the security requirements, we outline the following
objectives of our proposed Blockchain-based authorisation scheme, which must
be met in order to provide users with secure access to IoT devices. For
example, the proposed scheme must ensure a decentralised, secure, and
automated process for capturing, storing, and managing information and
policies on Blockchain. Second, the proposed scheme must determine the
legitimate behaviour of network users and provide secure access to IoT
critical resources. Third, the proposed scheme must provide dynamic
authorisation by capturing context information (i.e., attributes) about
network entities and their deployed environment and dynamically granting
access to IoT resources in response to the changing behaviour. Fourth, the
proposed scheme must enable fine-grained access control, allowing for granting
or denying access to critical IoT resources based on numerous defined
conditions or policies applied to a unique data resource. Fifth, the proposed
scheme must be flexible to a broad range of IoT-based applications. Finally,
the suggested approach must take into account the following parameters:
storage, processing, and energy usage due to the resource-constrained nature
of IoT devices.

####  1.1.3 Research gap

While prior research has demonstrated that Blockchain technology can be
integrated into IoT environments to address the following issues with
authorisation mechanisms such as single point of failure, access rights
validation, data or policy tampering, lack of transparency, and accountability
for granted resources, etc., however, these authorisation mechanisms have
limitations that must be addressed in order to offer effective, secure,
flexible, and dynamic authorisation of IoT devices by the use of prospective
Blockchain features. For instance, the schemes [11] [12] [14] solely rely on
the Blockchain to store the expression of privileges to access resources in
the form of transactions without fully utilising the Blockchain’s
capabilities, such as smart contracts. Moreover, to create and store
predefined access rights on the Blockchain introduces issues with static
access rights, such as in static authorisation schemes [16] [17] that are
incapable of capturing the dynamic policies and coping with the dynamic nature
of IoT networks, such as device mobility, behaviour patterns, the need to
perform critical operations, device compromise and failure, and so on. Some
methods rely on traditional access control models such as access control list
(ACL) [15] and RBAC [20] [21] [22] [23], respectively, and each of which has
its own set of limitations in terms of their inflexible nature, time
consumption, error-prone and coarse-grained level. Further, the authorisation
schemes based on CapBAC models [17]

[24] [25] [26] [27] [28] [29] grant access to resources solely based on
capability tokens created for each policy. Further, employing CapBAC models in
authorisation processes is a time-consuming task requiring generating and
distributing tokens (or capabilities) to all subjects for each resource. It is
also possible that selecting a specific capability while making a request
overburdens the network, which significantly impacts system performance when
there are many users. Finally, the authorisation methods based on ABAC models
have limitations in terms of achieving the privacy of the attributes [16] [30]
[31] [32] [33], collecting and managing the large number of policies and
achieving the flexibility and fine-grained level of access rights [30] [31]
[33] .

Taking into account the inherent issues with traditional access control models
and their integration with IoT, and in order to address the limitations of
existing Blockchain-based authorisation schemes, we proposed a Blockchain-
based trustworthy, flexible, fine-grained, and dynamic decentralised
authorisation mechanism for IoT that makes use of smart contracts to ensure
the full capability of the Blockchain. Furthermore, we use the ABAC model to
build fine-grained rules consisting of a subject, object, and environment-
related attributes to ensure the flexibility and dynamic nature of our
proposed mechanism. To manage fine-grained policies efficiently, we developed
a policy-management framework composed of various smart contract-based modules
that ensure the secure provision of the required access policies to users
requesting to access IoT devices. For the most part, our solution idea is
centred on using smart contracts to implement attribute-based Access Control
regulations. Smart contracts running on the blockchain control both the
policies and the attributes required for evaluating them. To demonstrate the
practicality of our proposed mechanism, we create a proof-of-concept prototype
comprised of a local private Ethereum Blockchain that executes the smart
contract functionality and logic.

###  1.2 Contributions

The following constitute the primary contributions to this paper:

  * 1.

We propose a Blockchain-based decentralised, secure and flexible authorisation
scheme for IoT networks, featured with the smart contracts-based ABAC model to
enforce the execution of authorisation process for providing users with secure
access to IoT resources based on dynamic and fine-grained policies stored on
the distributed immutable ledger.

  * 2.

We designed the ABAC-PMF with smart contract features, consisting of two sub-
components: AMA and PMA, which handle attributes and policies on the
Blockchain, respectively. The AMA initialises, stores, and manages subject,
object, and environment-related attributes to enable flexible and fine-grained
access permissions. On the other hand, PMA initialises, stores, and manages
policies to offer dynamic access to users based on environmental attributes
and defined actions.

  * 3.

We designed the AMF by using the features of smart contracts with the aim of
securely managing user requests to access IoT devices based policies.
Furthermore, AMF maintains a look-up table to ensure the privacy of user
information and the auditability of user requests and assigned policies.

  * 4.

We designed a prototype of our proposed scheme as a proof-of-implementation
and executed the functionality of smart contracts on the local Ethereum
Blockchain setup. Furthermore, to demonstrate the practicality and
applicability of our proposed scheme, we computed the deployment and execution
costs and the financial cost of enabling secure access to IoT devices via an
IoT-based smart home scenario.

###  1.3 Paper organisation

The organisation of this paper is structured as follows: Section 2 covers the
background to our work and literature review of existing Blockchain-based
authorisation schemes. A detailed system architecture of our proposed scheme
consisting of the network model and their assumptions is presented in the
section 3. Section 4 provide a detailed description of the authorisation
process, proposed algorithms, execution flow and qualitative security
analysis. The implementation and evaluation framework of our proposed scheme
is presented in section 5. The performance analysis of the proposed scheme in
terms of deployment and execution costs followed by the financial cost of
deploying IoT-based smart home scenario is discussed in the section 6.
Finally, we conclude our paper in section 7.

##  2 Background and related work

This section begins with a brief discussion of some fundamental concepts,
followed by an introduction to security solutions proposed in recent
literature that utilise Blockchain technology for providing secure access to
users using numerous authorisation mechanisms.

Table 1: A comparative analysis of our proposed scheme with existing smart
contract based authorisation or access control mechanisms for IoT

Ref |  Access control model |  Network type |  Storage requirement | Achieved security requirements and objectives
---|---|---|---|---
DD |  RP |  P |  FL |  DN |  FG |  AD
[34] |  A generic distributed access control framework |  N/A |  Single |  ✓ |  ✗ |  ✓ |  ✗ |  ✓ |  ✓ |  ✗
[35] |  A generalised access control method itilising XACML policies |  Private |  Single |  ✓ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗
[36] |  A generic decentralised blockchain based access control framework |  Private |  Multiple |  ✓ |  ✓ |  ✓ |  ✗ |  ✗ |  ✗ |  ✗
[37] |  A generalised approach based on XACML Policies |  Private |  Single |  ✓ |  ✗ |  ✗ |  ✓ |  ✗ |  ✗ |  ✗
[38] |  A generalised approach based on decentralised identifiers |  N/A |  Multiple |  ✓ |  ✗ |  ✓ |  ✗ |  ✗ |  ✓ |  ✗
[15] |  ACL |  Private |  Single |  ✓ |  ✗ |  ✓ |  ✗ |  ✓ |  ✗ |  ✗
[22] |  RBAC |  Private |  Single |  ✓ |  ✗ |  ✓ |  ✗ |  ✗ |  ✓ |  ✗
[23] |  RBAC |  Public |  Single |  ✓ |  ✓ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗
[19] |  RBAC |  Private |  Single |  ✓ |  ✓ |  ✗ |  ✓ |  ✓ |  ✗ |  ✗
[21] |  RBAC |  Consortium |  Multiple |  ✓ |  ✓ |  ✓ |  ✗ |  ✓ |  ✗ |  ✗
[24] |  CapBAC |  Private |  Multiple |  ✓ |  ✗ |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
[25] |  CapBAC |  Private |  Single |  ✓ |  ✗ |  ✗ |  ✓ |  ✗ |  ✓ |  ✗
[26] |  CapBAC |  Private |  Multiple |  ✓ |  ✗ |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
[27] |  CapBAC |  Private |  Multiple |  ✓ |  ✗ |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
[28] |  CapBAC |  Private |  Single |  ✓ |  ✗ |  ✗ |  ✓ |  ✗ |  ✓ |  ✗
[17] |  CapBAC |  N/A |  Multiple |  ✓ |  ✗ |  ✗ |  ✗ |  ✗ |  ✓ |  ✗
[29] |  CapBAC |  N/A |  Multiple |  ✓ |  ✗ |  ✓ |  ✗ |  ✗ |  ✗ |  ✗
[30] |  ABAC |  Public |  Single |  ✓ |  ✗ |  ✗ |  ✓ |  ✗ |  ✓ |  ✗
[39] |  ABAC |  Private |  Single |  ✓ |  ✗ |  ✓ |  ✓ |  ✓ |  ✓ |  ✗
[16] |  ABAC |  Private |  Single |  ✓ |  ✗ |  ✗ |  ✗ |  ✓ |  ✓ |  ✗
[31] |  ABAC |  Private |  Single |  ✓ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗ |  ✗
[32] |  ABAC |  Private |  Single |  ✓ |  ✗ |  ✗ |  ✓ |  ✓ |  ✓ |  ✗
[40] |  ABAC |  Public |  Multiple |  ✓ |  ✓ |  ✓ |  ✓ |  ✓ |  ✓ |  ✗
[33] |  ABAC |  N/A |  Multiple |  ✓ |  ✓ |  ✗ |  ✗ |  ✓ |  ✗ |  ✗
Our Proposed Scheme |  ABAC |  Private |  Multiple |  ✓ |  ✓ |  ✓ |  ✓ |  ✓ |  ✓ |  ✓

DD = Decentralised and Distributed, RP = Resource Protection, P = Privacy, FL=
Flexibility, DN = Dynamicity, FG = Fine Grained, AD = Auditability

###  2.1 Background

This section discusses Blockchain technology and the ABAC concept, which serve
as the background to our work.

####  2.1.1 Blockchain technology

The Blockchain is the primary technology that underpins Bitcoin and other
cryptocurrencies. Blockchain technology allows for the development of a
trusted network of untrusted nodes in which all network nodes must validate
transactions. In Blockchain, nodes keep track of and verify new transactions
in blocks, eliminating the need for centralised intermediaries. Due to the
fact that all nodes maintain a history of transactions in the form of linked
hashes that make up the Blockchain, any changes made to previously-stored
transactions will be detected by the Blockchain. Miner nodes accept and verify
new transactions prior to insertion into the Blockchain via the consensus
mechanism. In most consensus mechanisms, miner nodes must solve puzzles based
on their computational resources to add verified blocks to the Blockchain.

Another significant feature of Blockchain technology is implementing smart
contracts, which are small pieces of code written in the Blockchain and
activated when certain conditions are met. The successful implementation of
this feature in several Blockchain-based platforms, including Ethereum [41],
enables the development of decentralised and trusted execution platforms, also
known as decentralised applications (dApps). Instead of simply recording data
on an immutable ledger, smart contracts strive to enhance the capabilities of
Blockchain by managing complicated and autonomous computations. The key
principle behind the implementation is to put executable codes on the
Blockchain and make peers execute them by coordinating and cooperating with
each other. Further, the peer nodes establish an agreement when evaluating the
code and storing the results in the Blockchain.

The emergence of outstanding features of Blockchain technology in IoT led to
the design and implementation of a robust platform or applications for
transparently and trustlessly transferring information across the network. For
example, the decentralised and distributed nature of Blockchain enables IoT
components to join the network without the involvement of a third party and
communicate with one another via secure cryptographic protocols, thereby
ensuring the scalability, security, and reliability of both the component and
data. Further, the data is stored on the immutable ledger as permanent
transactions, enabling the network nodes to verify the transactions in the
event of a discrepancy, hence introducing a high level of auditability. In
terms of smart contracts, automatic execution of certain conditions is
possible to aid with a wide range of functions such as controlling access
permissions and executing access requests in secure decentralised
authorisation systems.

####  2.1.2 Attribute-based access control (ABAC)

ABAC is an authorisation paradigm that determines user access to system
resources based on attributes (or characteristics) rather than roles. The
objective of ABAC, like other access models, is to secure both critical system
resources and sensitive data from unauthorised users and their malicious
actions. ABAC ensures that access decisions are made based on the attributes
of the subject (i.e., user), object (i.e., resources), and environment
involved in an access event. For example, the ABAC model determines that users
who do not have ”authorised” attributes as determined by an organisation’s
security policies will not be permitted access to resources or data.

In ABAC, the access policies are described as a logical arrangement of
attributes and actions used to provide access to critical resources. In an
ABAC model, policies make use of a variety of attributes in conjunction with
Boolean logic formulae to determine who is making the request, what resource
is being used, and what action should be taken. There are two types of
attribute values: set and atomic. The difference between atomic and set-valued
characteristics is that set-valued attributes hold more than just one atomic
value.

###  2.2 Related work

Blockchain technology has earned a competitive edge in IoT networks by virtue
of its multiple features, including decentralisation, distributed security,
tamper-resistant, transparency, and autonomy. Recent research has demonstrated
the efforts being made to incorporate these features into the IoT in order to
develop more robust and efficient solutions that address some of the issues
associated with traditional authorisation or access control methods, including
single point of failure, the untrustworthy delegation of access rights, third-
party validation, modification of access rights, lack of transparency and
control, and scalability.

####  2.2.1 Simple Blockchain-based approaches

This section discusses a few Blockchain-based authorisation mechanisms for IoT
networks that rely on the Blockchain as an underlying architecture (without
smart contracts) for defining and storing access policies.

For instance, Dorri et al. [11] presented a Blockchain-based mechanism for
resolving the issue of access control for multiple interacting entities in an
IoT-based decentralised smart home environment, such as the cloud, users, and
IoT devices. Each home has its own private Blockchain in this scheme, where
the multiple miners keep a policy header to control all home access requests.
However, this mechanism mainly focused on distribution and recording access
privileges on the immutable ledger in Blockchain. Further, Maesa et al. [12]
proposed a blockchain-based access control delegation mechanism for storing
and transferring expressions about access rights to a given resource in the
form of transactions. To secure the validation of access rights, Andersen et
al. [14] proposed a scalable decentralisation authorisation mechanism that
grants access to users via advanced cryptographic features. In addition to
access delegation, a reverse discoverable decryption protocol protects shared
access privileges between administrative domains. Pinno et al. [13] presented
a distributed architecture built on Blockchain technology to govern access to
IoT devices and ensure transparent authorisation. This architecture secures
relationships between users and devices using different access control models,
including ACL, CapBAC, and ABAC. Also, Ding et al. [42] proposed an IoT access
management system built on Blockchain that simplifies the process of
authorising IoT devices based on their attributes. The immutability feature of
Blockchain is used to store attribute distribution in the form of transactions
for permission and revocation. While these access control solutions addressed
the aforementioned issues effectively by maintaining access policies on a
tamper-proof ledger, they vastly overstated the full potential of blockchain
technology by utilising its advanced features for performing various
computation functions.

####  2.2.2 Smart contracts-based approaches

As the primary objective of this paper is to propose a Blockchain-based
decentralised, secure authorisation scheme for IoT networks through the use of
Blockchain’s smart contracts feature, we provide a detailed overview of
authorisation mechanisms for IoT networks that make use of smart contracts and
support for various access control models. Furthermore, we perform a detailed
comparison of existing smart contract-based schemes to our proposed scheme in
terms of security requirements and objectives fulfilled, as presented in Table
1.

Along with access delegation, a reverse discoverable decryption protocol is
utilised to maintain the privacy of access rights shared between multiple
administrative domains. Pinno et al. [13] proposed a distributed architecture
built on Blockchain technology to manage access to IoT devices and ensure a
transparent authorisation of IoT devices. By utilising multiple access control
models such as ACL, CapBAC, and ABAC, this architecture enables the secure
establishment of communication between individuals and devices while mapping
their unique characteristics to the relationships utilised in access control
authorisation. Same with the previous solutions, Ding et al. [42] presented a
Blockchain-based access management system for IoT systems that simplifies the
process of authorising IoT devices based on their attributes. In this system,
the immutable feature of Blockchain technology is utilised to store the
distribution of attributes in the form of transactions for authorisation and
revocation processes. While these existing solutions address the single point
of failure and data or policy tempering issues inherent in existing
authorisation or access control schemes by storing access policies on a
tamper-proof ledger, they frequently overlook the full potential of
Blockchain.

To broaden the functional scope of blockchain technology through smart
contracts (i.e., executable codes stored on the Blockchain), the Blockchain
has been hailed as a leading framework for developing decentralised and
trustworthy applications, attracting significant interest from researchers in
the IoT community. For example, Zhang et al. [15] propose a smart contract-
based access control mechanism to overcome the limitations of prior works that
exclusively used the Blockchain to store access rights. This mechanism
provides decentralised and trustworthy access control for IoT systems using
smart contracts, comprising access control, judge, and register contracts.
However, this mechanism relied on a static access control list, which limited
its usage to determining and revoking user access privileges on all objects.
As a result, this mechanism lacks efficiency and scalability.

Andersen et al. [22] presented the WAVE, a decentralised authorisation scheme,
with RBAC to enable the secure authorisation of IoT devices without the need
for a central trusted party. The delegation of resources on the public
Blockchain is accomplished through smart contracts in conjunction with the
delegation trust mechanism. Cruz et al. [23] proposed a Blockchain-based
access roles mechanism for the secure interaction of several trans-
organisations through the use of smart contracts. Likewise, this technique
used RBAC to create user roles and assignments at the organisational level and
verify a user’s role ownership. Further, Novo [19] presented a Blockchain-
based distributed architecture for storing arbitrating roles (i.e., RBAC) and
access control permissions on Blockchain to address the scalability problem of
managing access to restricted devices in the IoT. Numerous restricted IoT
devices are linked concurrently by various flexible management hubs
distributed across the blockchain network. The proposed architecture uses
smart contracts to create the manager node that manages permissioned
Blockchain access control rights. However, this method also utilised the RBAC.
Xu et al. [21] proposed a Blockchain-based decentralised authorise and
permission management method for healthcare data accessed by different
entities related to healthcare such as hospitals, physicians and medical
insurance companies. Authorisation information contains URLs (Universal
Resource Locators) to identify the data approach especially and decouple
patient privacy data from the Blockchain to ensure the effectiveness of the
data processing. In this method, the RBAC model is utilised to define the
authorisation rules in smart contracts, allowing for executing, recording, and
tamper-proofing all private data authorisation operations. However, the
limitations of RBAC-based authorisation methods are that users are granted
access privileges based on their roles, and all users with similar roles have
access to the same amount of data regardless of their restricted authorisation
to fine-granularity access rights. Additionally, because RBAC models are
static in defining access policies and limiting mechanisms to only achieving
coarse-grain access levels, utilising such models in authorisation mechanisms
can be time-consuming for defining and accessing policies and error-prone when
the system has a large number of roles.

CapBAC is another access control model used by various IoT network
authorisation methods to ensure that users have secure and efficient access to
resources. Additionally, this model is intended to overcome the limitations of
RBAC by giving access via identity tokens rather than the users’ roles. To
demonstrate the concept of CapBAC in an IoT-based authorisation mechanism, Xu
et al. [24] presented a decentralised CapBAC framework, called BlendCAC, that
leverages smart contracts and blockchain technologies to enable safe access to
IoT devices. An identity-based capability token management method is suggested
in this framework, which makes use of smart contracts for the initialisation,
registration, transmission, and revocation of access rights on Blockchain.
Furthermore, the work [26] proposes an extension of the work [24] by employing
a similar approach but focusing on additional performance metrics such as
block generation time. Furthermore, the same approach [24] was used in [27] to
investigate the CapBAC model in space situation awareness (SSA) applications.
Space situation awareness (SSA) entails the surveillance of active and
inactive local space objects and the characterisation of the space environment
via the collection and processing of sensor data. Nakamura et al. [25] propose
another authorisation method for IoT networks based on the CapBAC model, in
which smart contracts are primarily used to store and maintain capability
tokes for giving access to IoT devices. Tokens are generated as units of
action performed by users in this method, and the delegation graph is used to
map users to resources. The work [28] is an extension of the [25], with an
emphasis on the implementation of functions (i.e., capability, delegation
graph) proposed in the earlier work for evaluating and analysing gas use.
Moreover, Chai et al. [17] presented an access control method based on CapBAC
for IoT networks, called SFAC, that incorporates smart contracts and
Blockchain technology to ensure that only authorised users have access to
critical information. The suggested method made use of a tokens mechanism that
enables users to request numerous resources in batches rather than
individually. An extension of [17] is presented in [29], with a particular
emphasis on the analysis of the results. However, the disadvantage of CapBAC-
based authorisation systems or access control models is that users are granted
access to resources solely based on capability tokens created for each policy.
Further, employing CapBAC models in authorisation processes is a time-
consuming task that requires generating and distributing tokens (or
capabilities) to all subjects for each resource. It is also possible that
selecting a specific capability while making a request overburdens the
network, which significantly impacts system performance when there are many
users.

To overcome the limitations of RBAC and CapBAC models in terms of nature of
access rights (i.e., static), assignment level (i.e., coarse-grained), reduce
the computation cost of generating tokens and provide dynamic authorisation of
IoT devices, ABAC models are frequently deployed. In ABAC models, different
attributes are used to grant access privileges to IoT devices. By utilising
the device attributes of the ABAC models in IoT-based networks to provide
secure access to underlying resources, Yutaka et al. [39] proposed a
Blockchain-based access control scheme by utilising the smart contracts to
write and enforce the policies. In this scheme, a range of smart contracts,
from registration of attributes to defining the ABAC policies, is written and
executed on Ethereum Blockchain. Finally, the proposed scheme is deployed on
the Local Ethereum Blockchain to demonstrate its feasibility and evaluate its
monetary cost. An extension of the previous work [39] is presented in the
[32], with a focus on enhancing performance evaluation parameters such as
deployment and operating cost. Wang et al. [30] proposed a Blockchain-based
distributed access control framework for IoT networks by utilising the subject
and objects based attributes. In this framework, attributes such as
manufacturer and object specifications provide a finer-grained degree of
access control for resource-constrained IoT devices. Liu et al. [16]
introduced Fabric-IoT, a fabric-based access control system that leverages the
ABAC and Hyperledger fabric Blockchain architectures to enable dynamic and
fine-grained access control rights for IoT networks. Three smart contracts
with distinct functionality (device, policy, and access) are created and
deployed on the Blockchain in this scheme to ensure the secure execution of
access rights. For access rights and delegation of access rights in IoT based
networks, Ali et al. [36] proposed a decentralised Blockchain-based
architecture called xDBAuth, in which the smart contracts are written and
deployed hierarchically, providing permission assignment and access control
for both local and global devices, as well as authenticating in their parent
IoT domains. A similar approach to [16] is given in [31], with the goal of
providing data sharing and access control across IoT devices via the use of
Blockchain and smart contracts. Qin et al. [33] utilised an ABAC model to
propose a lightweight blockchain-based access control scheme called LBAC.
Blockchain is used instead of untrusted cloud servers to perform the
outsourcing decryption on attributes determining the secure access to
resources. To achieve the dynamic nature of authorisation mechanisms for IoT
networks, Putra et al. [40] presented a decentralised access control mechanism
based on the ABAC model in conjunction with a trust and reputation system. The
proposed mechanism sought to achieve dynamic access privileges by focusing on
IoT device compromise scenarios.

Furthermore, various Blockchain-based generic authorisation or access control
systems have been proposed that utilise the smart contract feature to secure
user access to IoT-based networks. Dukkipati et al. [35] proposed a general
access control mechanism based on Blockchain technology to ensure the security
and privacy of IoT access resources. This approach makes use of the smart
contract feature to establish the structure of XACML (Extensible Access
Control Markup Language) based policies that can be executed on the
Blockchain. Further, Ouaddah et al. [34] presented a decentralised reference
model based on the Hyperledger Fabric Blockchain for access control management
tasks such as issuing, fetching and assigning rights to users via new types of
transactions created by modifying the basic transaction structure of
Hyperledger Fabric Blockchain. Esposito et al. [37] designed and implemented a
blockchain-based approach for authentication and authorisation in smart
cities, which is further integrated with FIWARE to overcome its centralised
architecture limitation. In addition, the proposed approach defined the
structure of policies to be recorded on the Blockchain using XACML. Tan et al.
[38] proposed a generic Blockchain-based authorisation, access control and
revocation method for Green Smart Devices (GSDs) to enable safe access to
Green IoT (GIoT) devices through the use of decentralised identities. By
utilising smart contracts implemented on the Blockchain, decentralised IDs are
issued, managed, and revoked.

Figure 1: Network model

##  3 System architecture

This section describes the system architecture for our proposed decentralised,
flexible and dynamic authorisation scheme for IoT devices based on Blockchain
technology. To simplify and clarify the system architecture, we first divide
it into network model components and then define the underlying assumptions
for each component.

###  3.1 Network model

Fig. 1 illustrates the network model for our proposed Blockchain-based secure,
flexible and dynamic decentralised authorisation mechanism for IoT devices.
Our network model comprises the following primary interacting components that
enable authorised users to securely interact with IoT devices via the access
management framework in conjunction with the Ethereum-based ABAC policy
framework, which defines access policies using subject, object, and
environment-related attributes. The details for each component are listed
below.

####  3.1.1 Administrator authority

The administrative authority (AA) is a critical component of the network
model, and it is responsible for the following activities:

  * 1.

Firstly, it is responsible for initialising the overall system configuration,
which includes generating public parameters and uploading them to the
Blockchain. Since our proposed mechanism is based on the Ethereum Blockchain,
this component assigns Ethereum addresses EA = {$ea_{1}$, $ea_{2}$, $ea_{3}$,
…, $ea_{N}$} and public keys PK = {$pk_{1}$, $pk_{2}$, $pk_{3}$, …, $pk_{N}$}
to all interacting modules in this scenario.

  * 2.

Secondly, it is responsible for issuing authentication tokens to IoT devices
based on the inherent attributes of both users (subjects) and IoT devices
(object attributes). We have a N number of IoT devices in our work, and hence
tokens are represented as $T$ = {$T^{1}_{SO}$, $T^{2}_{SO}$, $T^{3}_{SO}$, …,
$T^{N}_{SO}$}. Our previous work [4] describes the whole process of creating
and issuing Blockchain-based authentication tokens in a decentralised IoT
network.

  * 3.

Finally, this component is responsible for registering environmental
attributes (also known as context attributes) associated with both subjects
and objects to define access control policies in the policy management
framework. Our previous work [43] details the process of collecting,
characterising and controlling environmental attributes in IoT networks.

####  3.1.2 ABAC policy management framework (ABAC-PMF)

The ABAC-PMF is a critical component of our proposed network model. This
component serves as the full node in the Blockchain network, as it is
responsible for the overall process of collecting, storing, and managing the
attributes essential to define access control policies. This component is
further subdivided into two components, the details of which are as follows:

  * 1.

Attributes management authority (AMA): The AMA is solely responsible for
collecting, storing, and managing attributes on the Blockchain. We classified
the attributes into three categories for the ABAC model: subject attributes
(SA), object attributes (OA), and environmental attributes (EA). Then, for
each attribute type, we create a smart contract whose primary role is to
collect, store, and manage the attributes associated with each category on the
Blockchain and interact with other components in the network model. We
designated smart contracts as $S_{SA}$, $S_{OA}$, $S_{EA}$, respectively, for
each attribute type such as subject, object, and environment. The section
4.2.3 goes into detail about each smart contract and its working mechanism,
including functions and logic.

  * 2.

Policy management authority (PMA): The PMA is tasked with storing and managing
access control policies, defined in terms of stored attributes, to the
Blockchain. Similarly to creating smart contracts for attribute types, we
created and deployed another smart contract named with policy management
authority, denoted as $S_{PMA}$. The $S_{PMA}$ is responsible for defining,
storing, and managing access policies and providing secure communication with
the access management authority.

####  3.1.3 Access management framework (AMF)

As with the ABAC-PMF component, the AMF is a critical component of our network
model and acts as the full node in the Blockchain network. It is responsible
for handling users’ access requests to IoT devices in accordance with the
access policies defined in the ABAC-PMF. The technique by which user access
requests are handled is a mapping procedure that establishes the relationship
between the subject and the object following stated policies. To manage user
access requests, we designed a lookup table that categorises user requests
according to subject attributes, object attributes, and policies and
determines whether users are permitted to access resources or not.
Additionally, we built an action taken control mechanism within the access
management framework to identify the following steps to respond to user access
requests. To realise this concept, we created a smart contract $S_{AMF}$ that
manages user requests for accessing resources.

####  3.1.4 Blockchain network

In our proposed network model, the administrative authority is responsible for
initialising and configuring the Blockchain network parameters to connect the
other components, such as the ABAC-PMF and AMF. In our case, we deployed a
single Blockchain as a public Blockchain, namely with PB, which provides a
decentralised environment for the flexible and dynamic authorisation of IoT
devices through the execution of access control policies defined in Ethereum-
based smart contracts. Additionally, it enables secure administration and
storage of access control policies on a distributed tamper-resistant ledger. A
PB is operated by individual miners that seek to earn monetary rewards through
block mining.

####  3.1.5 Users

The users are authorised individuals who possesses specific unique
characteristics (i.e., subject attributes), as such Users = {$U^{1}_{s}$,
$U^{2}_{s}$, $U^{3}_{s}$, …, $U^{N}_{s}$}, and is granted access to IoT
devices (i.e., resources) within an IoT network based on defined access
policies for executing various actions. For instance, in a smart building
setup, users are assigned their unique access policies to control and manage
their resources, such as door locks, lights, and security alarms for each
apartment. As our proposed Blockchain-based authorised mechanism is intended
to be general-purpose with multiple benefits such as trustworthiness,
flexibility, and dynamicity, it can be applied to any IoT-based environment,
including smart hospitals, smart transportation, and smart buildings and smart
grids. Users act as light nodes in our network model since they communicate
with the access management authority to gain access to IoT devices.

####  3.1.6 IoT devices

In our network model, IoT devices act as a collection of resources with some
distinct characteristics (i.e., object attributes) and can be accessed only by
authorised users to accomplish a series of tasks within an IoT network. In our
scenario, we have a N number of IoT devices with object attributes, denoted by
Devices = {$D^{1}_{o}$, $D^{2}_{o}$, $D^{3}_{o}$, …, $D^{N}_{o}$}. However,
the main aim of an adversary is always to get access to these IoT devices,
whether single or multiple, to gain unauthorised control of the entire network
and perform various malicious actions such as device failure, data
manipulation, and denial of service attacks. IoT devices serve as light
blockchain nodes in our network model, connecting to the ABAC policy
management framework.

###  3.2 Network model assumptions

Our proposed scheme aims to achieve decentralised, secure, fine-grained and
dynamic authorisation of users to access IoT devices through an ABAC model
implemented using Blockchain technology. Our network model is made up of
several interconnected components that work and communicate together to
realise the concept of IoT device authorisation in a decentralised manner. We
made the following assumptions for each interacting component:

  * 1.

The AA component has the full authority to initialise, control and manage all
the other components of the network model. Also, it distributes the system
parameters such as Ethereum addresses, public and private keys to all other
components in a secure way.

  * 2.

For the IoT network, we used the attacker model proposed in our previous work
[4] to define the attackers’ capabilities. By employing this attacker model,
miners act as completely trusted resource providers, ensuring that IoT
resources are authentic and trustworthy.

  * 3.

The miner nodes control and manage the ABAC-PMF, which act as the full nodes
and communicate with the IoT network for attributes collection via a secure
channel.

  * 4.

Similar to ABAC-PMF, the AMF also acts as the full Blockchain node to manage
the access request and communicate with the Blockchain securely.

  * 5.

Among all the other components, the Blockchain serves as a critical component
that stores and manages attributes, ABAC policies, and user requests for
access to IoT resources. Additionally, no adversary can control more than 51%
of the network nodes to launch the 51% attack. Additionally, the policies are
secure, and tamper-proof maintained on the Blockchain distributed ledger.

  * 6.

Users are light Blockchain nodes that may impersonate malicious users to get
unauthorised access to IoT devices by possessing the users’ attributes.
Additionally, the attacker can intercept communication between the AMF
component and users. However, communication between users and the IoT network
is secure after the users obtain the secure access ticket.

##  4 Proposed Blockchain-based authorisation framework

Following the network and attacker models, this section presents our proposed
flexible and dynamic Blockchain-based authorisation mechanism, which employs
the ABAC model to manage users’ access requests to IoT network resources based
on fine-grained policies in a secure manner. Given that our proposed
authorisation process uses the ABAC model to define access control policies
for resources, it is equally important to discuss the ABAC model’s components,
requirements, benefits, and working mechanism as essentials.

###  4.1 ABAC model essentials

ABAC is an authorisation paradigm that determines access by evaluating an
individual’s attributes (or characteristics) rather than their roles. An ABAC
is a logical access control model that emerged from several classic access
control approaches such as access control lists (ACLs) and role-based access
control (RBAC). ABAC was developed initially to ensure that resources are
protected against unauthorised users and behaviours, such as those that do not
follow organisational security regulations.

There are three primary components in the ABAC model: subject, object, and
action, for which an organisation creates access policies to impose access
decisions during an access activity. For example, the subject may be a user or
an individual who wants to access the system’s objects or resources to perform
desired actions such as reading or writing. As the name implies, the ABAC
model defines access control policies by referencing the attributes of the
components involved in an access event. As a result, the primary requirement
is to determine how to gather, examine, and define the component’s attributes
and their interactions in an environment and to build a set of regulations
that will define which subjects are allowed to access objects depending on the
presence of specified criteria. The working mechanism of an ABAC model is to
compare the attributes of the components to stated policies and then determine
which attribute mapping from subject to object is authorised to perform an
action successfully. Fig. 2 illustrates the framework of the ABAC model, which
consists of related components and their underlying working mechanism.

Figure 2: ABAC framework

###  4.2 Authorisation process

Our proposed authorisation mechanism for IoT devices is based on an Ethereum-
based Blockchain network, in which access is granted to users who possess
specific attributes (subject, object, and environment) defined in access
control policies based on the ABAC model. Furthermore, we built access
management and ABAC-policy management frameworks based on smart contracts that
integrate and communicate with the Ethereum Blockchain in order to manage
users access requests and policies, respectively. To better understand how our
proposed authorisation process works in its whole, we divide it into the
following operational processes and propose algorithms for each one. Table. 2
shows the notations and descriptions used in the Algorithms 1 \- 4.

Table 2: Notations used in the proposed algorithms

Notations | Description
---|---
r | Random seed
PR | Private key
PK | Public key
EAddr | Ethereum address
BC | Blockchain
$U_{i}$ = {$u_{1}$, $u_{2}$, $u_{3}$, …, $u_{n}$} | Users
$D_{i}$ = {$d_{1}$, $d_{2}$, $d_{3}$, …, $d_{n}$} | IoT devices
$M_{Addr}$ | Miner address
$M_{ID}$ | Miner ID
$D_{Addr}$ | IoT device address
$D_{ID}$ | IoT device ID
T | Token
$T_{Sig}$ | Signed Token
SA | Subject attributes
OA | Object attributes
EA | Environmental attributes
$S_{SA}$ | Smart contract for adding subject attributes
$S_{OA}$ | Smart contract for adding abject attributes
$S_{SE}$ | Smart contract for adding environmental attributes
ID | Unique identifier
$a^{s}_{i}$ | Individual subject attribute
$a^{o}_{i}$ | Individual object attribute
$a^{e}_{i}$ | Individual environment attribute
$A^{S}_{i}$ | A set of subject attributes
$A^{O}_{i}$ | A set of object attributes
$A^{E}_{i}$ | A set of environmental attributes
t | Time
Loc | Location
actv | Activity
$T_{x}$ | Blockchain transaction
act | Actions
$P_{i}$ | Policies
$Tx_{Req}$ | Access request
$Att_{i}$ | Attributes set (subject, object, environmental)
d | Decision
at | Action taken
LT | Lookup table
$T_{Acc}$ | Access ticket

####  4.2.1 Initialisation of system parameters

In our proposed mechanism, the authorisation process for IoT devices begins
with generating the system parameters for the Ethereum Blockchain, such as
Ethereum addresses EAddrs and a key pair comprised of a public key PK and a
private key PR. Both EAddrs and PKs are then uploaded to the Blockchain BC for
interaction with other system components, such as users and IoT network, as
illustrated in the network model. The users are represented as U = {$u_{1}$,
$u_{2}$, $u_{3}$, …, $u_{n}$}, where U = {$u_{i}$ $|$ i $\in$ I}, for which I
= {1, …, n}. Further, IoT network consists of number of heterogeneous devices
and represented as D = {$d_{1}$, $d_{2}$, $d_{3}$, …, $d_{n}$}, where D =
{$d_{i}$ $|$ i $\in$ I}, for which I = {1, …, n}. Private keys PRs, on the
other hand, are kept secret by everyone and are not shared with anyone in the
network. We send the private keys over a secure channel to both users and IoT
devices, assuming that the adversaries do not have access to that channel. To
demonstrate how these keys are used in Blockchain-based IoT networks, each IoT
device is assigned a unique PK and PR key pair to generate and validate
transaction signatures, respectively. Furthermore, each IoT device and the
user has their own EAs in the Ethereum Blockchain architecture. The EAs are
the public addresses, which are the last 20 bytes of the keccak hash of the
public key. These parameters are created utilising an off-chain computation
process in our proposed mechanism; however, uploading these parameters to the
Blockchain requires an on-chain computation process. The entire procedure of
initialising system parameters by AA in our system setup is shown in Algorithm
1.

Algorithm 1 Initialisation of Systems Parameters

Input: r, BC, $U_{i}$, $D_{i}$
Output: PKs, PRs, EAddrs

1:procedure Initialisation of Systems Parameters(Random seed)

2: Generate Private Keys, PRs $\leftarrow$ SHA256 (r)

3: Generate Public Keys, PKs $\leftarrow$ secp256k1 (PRs)

4: Generate Ethereum Addresses, EAddrs $\leftarrow$ keccak256(PKs)

5: Send PRs to the respective users $U_{i}$ = {$u_{1}$, $u_{2}$, $u_{3}$, …,
$u_{n}$} and IoT devices $D_{i}$ = {$d_{1}$, $d_{2}$, $d_{3}$, …, $d_{n}$}

6: Upload PKs and EAs to the Blockchain BC

7:end procedure

####  4.2.2 Define and registration of attributes within an IoT network

Following the generation and uploading of public parameters to the Blockchain,
the next step of the proposed authorisation mechanism is to initialise and
register the attributes (i.e. subject, object) utilised in the Blockchain-
based IoT network. In general, users and IoT devices must initialise and
register attributes before our proposed authorisation, as ABAC-PMF will
eventually use these attributes to build policies for IoT device access. For
example, to initialise and register subject attributes SA and object
attributes OA on the Blockchain, please refer to our existing Ethereum
Blockchain-based decentralised authentication work for IoT networks [4], in
which we used tokens composed of subject and object attributes to authenticate
IoT devices. In this work, each IoT device is assigned with a unique
signature-based token that is validated by designated miner devices before
authentication and registration of those attributes to the Blockchain.

Additionally, we use a specific piece of information called context-
information that is obtained from the deployed IoT environment to initialise
and register environmental attributes EA. The context information is commonly
expressed in the form of semantic data that contains relevant information
about the deployed environment and is easily comprehended and interpreted by
people. Please refer to our work [43] for detailed information on the
initialisation, collection, and registration of context information in IoT
networks used as environmental attributes.

The Algorithm 2 summarises the process of initialising and registering the SA,
OA and EA with IoT networks, as described in our previous works.

Algorithm 2 Define and Registration of Attributes

Input: PK, PR, EAddrs, IDs(N), t, Loc, Actv
Output: SA , OA, EA

1:procedure Define and Registration of Attributes

2: Subject Attributes, $S^{a}_{N}$ $\leftarrow$ {$s^{a}_{1}$, $s^{a}_{2}$,
$s^{a}_{3}$, …, $s^{a}_{N}$}

3: for each $S^{a}_{N}$ do

4: if $M_{Addr}$ $\neq$ existing.EAs($M_{Addr}$) & $M_{ID}$ $\neq$
existing.IDs($M_{ID}$) then

5: $s^{a}_{i}$ $\leftarrow$ $M_{Addr}$, $M_{ID}$

6: Subject Attributes Registration($s^{a}_{i}$)

7: else$s^{a}_{i}$ $\leftarrow$ alreadyRegistered()

8: end if

9: end for

10: Object Attributes, $O^{a}_{N}$ $\leftarrow$ {$o^{a}_{1}$, $o^{a}_{2}$,
$o^{a}_{3}$, …, $o^{a}_{N}$}

11: for each $O^{a}_{N}$ do

12: if $D_{Addr}$ $\neq$ existing.EAs($D_{Addr}$) & ($D_{ID}$, $M_{ID}$)
$\neq$ existing.IDs($D_{ID}$,$M_{ID}$) then

13: $o^{a}_{i}$ $\leftarrow$ $D_{Addr}$, $D_{ID}$, $M_{ID}$

14: T $\leftarrow$ Token Generation ($o^{i}_{a}$)

15: $T_{Sig}$ $\leftarrow$ $Signature_{PR}(\textit{T})$

16: Object Attributes Registration ($o^{a}_{i}$)

17: else$o^{a}_{i}$ $\leftarrow$ alreadyRegistered()

18: end if

19: end for

20: Environmental Attributes, $E^{a}_{N}$ $\leftarrow$ {$e^{a}_{1}$,
$e^{a}_{2}$, $e^{a}_{3}$, …, $e^{a}_{N}$}

21: for each $E^{a}_{N}$ do

22: if $D_{ID}$ $\neq$ existing.IDs($D_{ID}$) & t $\neq$ Current.time() & Loc
$\neq$ Location(Subject) & Actv $\neq$ Activity.List(Object) then

23: $e^{a}_{i}$ $\leftarrow$ $D_{ID}$, t, Loc,Actv

24: Environment Attributes Registration ($e^{a}_{i}$)

25: else

26: $o^{a}_{i}$ $\leftarrow$ alreadyRegistered()

27: end if

28: end for

29:end procedure

####  4.2.3 Registration and management of attributes in Blockchain network

After defining and registering the SA, OA and EA with the IoT network, the
next step in our proposed authorisation mechanism is to register and manage
the attributes on Ethereum Blockchain. As described earlier in the network
model, we propose an ABAC-PMF framework with dual responsibilities. First, it
is responsible for collecting, storing, and managing the attributes in the
Blockchain that are collected via the AMA component from the IoT network.
Second, using the PMA component is responsible for defining, storing, and
managing access policies in the Blockchain.

To begin, the AMA component of the ABAC-PMF framework interacts with the IoT
network to collect the attributes recorded on the Blockchain. It is important
to note that this Blockchain is separate from our primary Ethereum Blockchain,
which the IoT network uses to define and register attributes for IoT device
authentication. The AMA component comprises three types of smart contracts:
$S_{SA}$, $S_{OA}$, $S_{EA}$, which are used to collect, store, and manage
attributes relating to the subject, object, and environment, respectively. The
following are the details of the smarts contracts, including the type of
attributes, functions and their working mechanism:

  * 1.

Subject-related attributes: We create a smart contract called $S_{SA}$ to
collect, store and manage subject-related attributes on the Blockchain. The
subjects are often the individuals or users who wish to access system
resources or objects, followed by the policies specifying the types of actions
they are permitted to execute, such as read or write. Each subject in the
network is distinguished from others by a unique identifier, such as an ID.
However, one ID may contain several attributes to demonstrate the possession
of attributes associated with the same ID through the use of different access
policies. For instance, an administrator may have multiple attributes that
enable him or her to access the organisation’s different resources for
controlling the database and network operations.

We define the subject’s attributes as the SID, Ethereum Address (EAddr), Name,
Role and Location in our scenario. Each attribute is a key-value pair with two
values, such as the name and value of the attribute, and is denoted by
$a^{s}_{i}$ = $<name,value>$. A collection of attributes associated with a
given subject is denoted by $A^{S}_{i}$ = {$a^{s}_{1}$, $a^{s}_{2}$,
$a^{s}_{3}$, …, $a^{s}_{N}$}. For instance, the subject k has the attributes
that are denoted by $A^{s}_{k}$ = {SID, EA, Name, Role and Location}.

The smart contract $S_{SA}$ is deployed exclusively by the administrators of
subjects. In this case, the AMA is responsible for executing the $S_{SA}$ on
the Blockchain.

  * 2.

Object-related attributes: Similar to $S_{OA}$, we create a smart contract
called $S_{OA}$ to collect, store and manage object-related attributes on the
Blockchain. The objects are the system resources to which the subject wants to
gain access, including files, services or applications, application
programming interfaces (APIs), or hardware resources. In our case, we focused
specifically on IoT devices as the objects that need to be protected from
attackers via unauthorised access. Similarly to subjects, each object is
distinct due to its unique identity, such as the IP address of IoT devices.
Additionally, each object can have several attributes associated with its ID,
indicating its possession of those attributes. We refer to the object ID as
OID for simplicity.

We describe the object attributes as OID, Ethereum Address (EAddr), Object
name and object type in our case. A collection of attributes associated with a
given object is denoted by $A^{O}_{i}$ = {$a^{o}_{1}$, $a^{o}_{2}$,
$a^{o}_{3}$, …, $a^{o}_{N}$}. For instance, the object k has the attributes
that are denoted by $A^{o}_{k}$ = {OID, EA, Name, Object name and Object
type}.

The smart contract $S_{OA}$ is deployed exclusively by object owners, and in
our case, the AMA is responsible for executing the $S_{OA}$ on the Blockchain.

  * 3.

Environmental-related attributes: To establish dynamic and flexible access
rights for system resources, environmental factors are critical in the broader
context of each access request. Environmental attributes, more precisely, are
contextual data that provide helpful information about environmental elements
such as subjects and objects in terms of their behaviour pattern and
interaction with the deployed environment. For example, contextual information
may include the following: time, location (for both subject and object),
object behaviour pattern, critical operations requirements, authentication
strength, encryption strength, and so forth. In our case, we specify the time,
subject location, object behaviour pattern, and authentication status as
environmental attributes for the purpose of achieving dynamic access rights to
objects. The following is a description of the environmental attributes used
in our case: (i) Time is defined as the time allotted to each subject to
conduct the operations indicated in the policy on the object, (ii) Subject
location refers to a particular location from which resources can be accessed,
(iii) Object behaviour pattern defines the object’s current state, such as an
IoT device that has been compromised and has become malfunctioning, (iv)
Finally, an authentication status specifies the information or state of an IoT
device’s authenticity or non-authenticity.

A collection of attributes associated with a deployed environments is denoted
by $A^{E}_{i}$ = {$a^{e}_{1}$, $a^{e}_{2}$, $a^{e}_{3}$, …, $a^{e}_{N}$}. For
example, a deployed environment k has the attributes $A^{e}_{k}$ = {Time,
Subject location, Object behaviour, Authentication status} for both subject
and object.

Other environment-related attributes, such as critical operations or
activities (e.g., data sense, calculation, transmission, and temperature
control), are included in access policies as core actions. Similarly to the
deployment of $S_{SA}$ and $S_{OA}$ smart contracts, the AMA executes and
deploys the $S_{EA}$ smart contract on the Blockchain.

  * 4.

Management of attributes: Apart from registering attributes on the Blockchain
network via the AMA component, we defined and implemented smart contract
functionalities for updating and revoking subject, object, and environment-
related attributes.

Table 3 presents an example of the subject, object, and environmental
attributes in key-value forms used by our proposed authorisation scheme.

Table 3: Example of attributes utilised in our proposed scheme

Subject Attributes |  Object Attributes |  Environmental Attributes
---|---|---
$<SID:321>$ | $<OID:325>$ | $<Time:E_{Time}-S_{Time}>$
$<EAddr:0\times 43a6cb>$ | $<EAddr:0\times 6d34e2>$ | $<Sub.location:East.AUS>$
$<Name:Charlie>$ | $<Obj.Name:Lock>$ | $<Obj.behaviour:Malicious>$
$<Role:User>$ | $<Obj.Type:Security>$ | $<Auth.status:Auth/Non.Auth>$
$<Location:East.AUS>$ |  |

####  4.2.4 Define and management of access control policies in Blockchain
network

Algorithm 3 Define and Management of Policies

Input: $A^{S}_{i}$ = {$a^{s}_{1}$, $a^{s}_{2}$, $a^{s}_{3}$, …, $a^{s}_{N}$},
$A^{O}_{i}$ = {$a^{s}_{1}$, $a^{s}_{2}$, $a^{s}_{3}$, …, $a^{s}_{N}$},
$A^{E}_{i}$ = {$a^{s}_{1}$, $a^{s}_{2}$, $a^{s}_{3}$, …, $a^{s}_{N}$}, act =
{Read, Write, Execute}
Output: $P_{i}$ = {$P_{1}$, $P_{2}$, $P_{3}$, …, $P_{n}$}

1:procedure addPolicy()

2: Initialisation of Policies $P_{i}$

3: Collection of Attributes {$A^{S}_{i}$, $A^{O}_{i}$,$A^{E}_{i}$} from AMA

4: Define Actions $act_{i}$

5: for each $P_{i}$ do

6: Initialise $Tx_{P_{i}}$ = {$A^{S}_{i}$,$A^{O}_{i}$,$A^{E}_{i}$,$act_{i}$}

7: Store $P_{i}$ on Blockchain

8: end for

9:end procedure

10:procedure UpdatePolicy()

11: if $P_{i}$ $\leftarrow$ searchPolicy($ID_{i}$) then

12: Update Actions $act_{i}$

13: $P_{i}$ $\leftarrow$ addPolicy()

14: Store $P_{i}$ on Blockchain

15: else

16: $P_{i}$ $\leftarrow$ notExisted()

17: end if

18:end procedure

19:procedure RevokePolicy()

20: if $P_{i}$ $\leftarrow$ searchPolicy($ID_{i}$) then

21: Revoke Policy $P_{i}$

22: else

23: $P_{i}$ $\leftarrow$ notExisted()

24: end if

25:end procedure

After successfully registering attributes, the next step in the proposed
authorisation scheme is defining and storing the access control policies on
the Blockchain. As we mentioned earlier, the ABAC-PMF has a second important
component named PMA, responsible for defining, storing and managing the
policies on the Blockchain. In our proposed scheme, the PMA component defines
the more fine-grained policies by adding more attributes related to subject,
object and environment to the Blockchain, thereby achieving more flexible and
dynamic access control to the critical resources of the IoT network. The PMA
component includes the following functions, all of which are built-in smart
contracts, for defining and managing the policies on the Blockchain. The
algorithm 4 demonstrates how access control policies are defined and managed
on the Blockchain.

  * 1.

Adding the new policies: To add a new policy to the Blockchain, the PMA first
interacts with the AMA to get the attributes (subject, object, and
environment) and then initiates a Blockchain transaction ${T_{x}}$ containing
the attributes $A^{a}_{k}$ = {$A^{s}_{k}$, $A^{o}_{k}$, $A^{e}_{k}$} and
actions, act = {Read, Write, Execute} to be defined for giving specific access
to IoT resources. Each policy is stored to the Blockchain with the unique ID,
called $P_{ID}$, which helps to identify the policies uniquely and to retrieve
the policies from the Blockchain. Moreover, we evaluate only those actions
that are relevant to user access to IoT resources, such as reading, writing,
and executing data using those resources, when defining policies. However,
network administrator tasks such as updating device configuration, creating
and deleting devices from registries, and controlling the network are not
covered in policy definition.

Furthermore, to make policies efficient, simple, small in size, and fast to
process and retrieve, we create a structure for policies that is distinct from
the [40] scheme, as this scheme combined all access control parameters and
actions taken into a single policy definition, impeding the policy structure.

  * 2.

Updating the existing policies: As with adding new policies to the Blockchain,
the PMA can also update existing policies in the ABAC-PMF. However, policy
updates are only required when an authorised user requires additional actions
beyond those already specified in the policy. For example, if a user is
initially assigned only read rights but later requires special privileges such
as writing, an updated policy is required. The PMA performs a simple search
operation utilising the unique ID issued to each policy to update the policy.
Although alternative search methods are employed in the current system,
searching policies using those methods takes longer and consumes more gas
[32].

  * 3.

Revoking the existing policies: Along with adding and updating the policies to
the Blockchain, the PMA also has the functionality to revoke the existing
policies from the Blockchain network. However, policy revocation is required
only when some malicious behaviour is detected, and the PMA component gets a
notification from the AMA component to take appropriate action. The policy
revocation may be necessary for two situations: if the user has become
malicious or if specific devices have been compromised.

Table 4 illustrating several policies for the ABAC model. Each policy is
defined to grant users access to IoT devices based on defined single or
multiple attributes and related device actions. For instance, policy $P_{1}$
is specified to provide access to users based on a single set of attributes,
such as subject ID $<SID:123>$, object ID $<OID:112>$, subject location
$<Sub.location:West.AUS>$. Furthermore, numerous attributes with distinct sets
of actions may be used to provide users with more fine-grained access to IoT
devices. For example, policy $P_{2}$ is specified for giving the access to
users on the basis of multiple attributes such as subject ID $<SID:123>$ and
Object Name $<Name:Charlie>$ to access the object with object ID $<OID:112>$
and object name $<Obj.Name:Thermostat>$ and environmental attributes subject
location $<Sub.location:West.AUS>$ and object behaviour $<NonMalicious>$ with
defined actions such as Read and Write.

Table 4: An example of ABAC model policies with defined attributes and actions

Policies | Attributes | Actions
---|---|---
Subject | Object | Environment
$P_{1}$ | $<\textit{SID:123}>$ | $<\textit{OID:112}>$ | $<\textit{Sub.location: West.AUS}>$ | Read
$P_{2}$ |  $<\textit{SID:123}>$ $<\textit{Name:Charlie}>$ |  $<\textit{OID:112}>$ $<Obj.Name:Thermostat:>$ |  $<\textit{Sub.location: West.AUS}>$ $<Obj.Behaviour:NonMalicious>$ |  Read Execute
$P_{3}$ |  $<EAddr:0\times 5fe321>$ $<Role:Admin>$ |  $<\textit{OID:167}>$ $<EAddr:0\times 12a34f>$ $<Obj.Name:Thermostat:>$ |  $<Obj.Behaviour:NonMalicious>$ $<Auth.Status:Auth>$ |  Read Write Execute
$P_{4}$ | $<EAddr:0\times 5fe321>$ | $<OID:345>$ | $<Time:E_{Time}-S_{Time}>$ | Read
$P_{5}$ | $<\textit{SID:145}>$ | $<Obj.Type:Security>$ | $<Sub.location:East.AUS>$ | Write

####  4.2.5 Validation of access request

After successfully registering attributes and managing policies on the
Blockchain through ABAC-PMF, an important and last step in the proposed
authorisation scheme is to grant users access to the resources of IoT networks
that meet the access policy’s specified attributes. As previously stated, we
designed a separate framework called AMF that makes use of smart contract
functions to perform a variety of tasks, including evaluating and managing
user requests, retrieving relevant policies, allocating resources, taking
actions on user requests, making decisions, and auditing user requests and
resources. The Algorithm depicts the entire process of evaluating user
requests to assign resources based on stated policies with specific Boolean
attribute rule sets in the access policy.

To begin the process of authorising users to use the resources of an IoT
network, a user must first submit an access request to AMF via the request
transaction $Tx_{Req}$. A $Tx_{Req}$ is a signed transaction that contains the
users’ attributes (i.e., subject attributes), the access resource identifier
$O_{ID}$, and the requested action act to perform on the accessible resources.
To sign the transaction $Tx_{Req}$, the user used his or her private key PR,
which is generated during the initialisation step of system parameters. It is
important to note that before a user can access the particular IoT resources,
the subject attributes must be registered and stored on the Blockchain. After
receiving the $Tx_{Req}$ from the users, AMF communicates with the Blockchain
to validate the $Tx_{Req}$ using the saved public key PK and determines
whether or not necessary attributes have been registered and stored to the
Blockchain. After successfully validating $Tx_{Req}$ in terms of subject
attributes via Blockchain, the AMF framework retrieves the relevant policy
$P_{i}$ for which the access request was made and maintains a lookup table
containing the user identification $SID_{i}$, the policy identification
$P_{ID}$, the decision made on the request d = {Approved, Denied}, and further
setting the restrictions as action taken at based on the user’s behaviour.
After successfully storing and maintaining the required information in the
lookup table, the AMF issues an access ticket $T_{Acc}$ containing the lookup
table information and issues it to users requesting access to the IoT
network’s requested resources. The $T_{Acc}$ is denoted by the {$SID_{i}$,
$P_{ID}$, d, at}. Finally, after obtaining the $T_{Acc}$ from the AMF, users
communicate with the IoT network via a secure communication channel by
presenting the issued token to the IoT network in order to gain access to the
specific IoT device and data. The communication route between users and the
IoT network is assumed to be secure and maintained by the AA in this case.

Algorithm 4 Validation of Access Request

Input: $Tx_{Req}$, $Att_{i}$ = {$A^{S}_{i}$, $A^{O}_{i}$, $A^{E}_{i}$},
$P_{i}$, d, at, LT
Output: $T_{Acc}$

1:procedure Validation of Access Request

2: Generate Access Request $Tx_{Req}$ $\leftarrow$ $Sig_{PR}$($A^{S}_{i}$)

3: Validate Access Request Val $\leftarrow$ $Validate_{PK}(Tx_{Req})$

4: if Val == Approved and at == $\emptyset$ then

5: Fetch Policies $P_{i}$

6: Fetch Attributes $Att_{i}$

7: Issue $T_{Acc}$ $\leftarrow$ {$S_{ID_{i}}$, $P_{ID}$, d, at}

8: Update LT

9: else

10: $A^{S}_{i}$ $\leftarrow$ NotExisted()

11: at [$A^{S}_{i}$] $\leftarrow$ Blocked

12: Update LT

13: end if

14:end procedure

The main aim of designing the AMF framework in the authorisation scheme
through the use of Blockchain’s smart contract features is twofold: (i) First,
to manage each user request for access to IoT resources separately and
securely, thereby preserving the privacy of their information and data; and
(ii) Second, to make the proposed scheme auditable in terms of user requests
for access to IoT resources, access control policies, and attributes, as well
as to further determine user behaviour for access decision enforcement.

Figure 3: Overall Execution Flow of Proposed Blockchain-based Authorisation
Mechanism

###  4.3 Execution flow

In a decentralised environment, the authorisation procedure for users
accessing IoT devices on the Blockchain network is performed using various
interconnected modules that provide timely responses and act accordingly. Our
proposed Blockchain-based secure, flexible and dynamic authorisation mechanism
for IoT devices consists of the following critical interacting components:
administrative authority, users, IoT network, Ethereum Blockchain, access
management framework and ABAC-policy management framework. These components
enable authorised users to secure access to IoT devices via the ABAC model
built on Ethereum Blockchain. Fig. 3 shows the complete execution flow of the
authorisation process for users accessing IoT devices, from attribute
registration to policy definition and after that managing secure user access
via smart contract features.

The procedure starts with the administrative authority responsible for
initialising and managing the overall system parameters such as Ethereum
addresses and public keys. After initialisation, the parameters are assigned
to the respective authorities, such as AMF and ABAC-PMF, to communicate with
the Ethereum Blockchain and other network model components. Furthermore, the
administrative authority is also responsible for initialising the IoT network
setup, which consists of many heterogeneous IoT devices authenticated via the
Ethereum Blockchain.

The next step in the proposed authorisation scheme is to authenticate
individuals and IoT devices using the token mechanism and then define and
initialise their attributes for use in policy definition. Since our scheme,
compared to previous works [32] [40], uses environment-related attributes to
dynamically grant access to IoT devices depending on their behaviour in IoT
networks, the administrative authority also stores environment-related
attributes in the ABAC-PMF.

Following attributes initialisation, the next step is registering these
attributes with the ABAC-PMF via smart contract capabilities. Each smart
contract is responsible for registering, storing, and managing attributes on
the Ethereum Blockchain through the use of the functionality provided in it.
After registering attributes in ABAC-PMF, the next step is to define policies
based on the registered attributes and prescribed actions for each resource’s
access level and nature. Similar to attributes, the ABAC-PMF are also handled
by smart contracts written to register, store, and manage policies on the
Blockchain.

After successfully defining attributes and policies in the ABAC-PMF, the final
step is to secure user access to IoT devices via the AMF. The AMF is composed
of a lookup table that maps attributes to rules and actions and then
determines whether or not users are permitted to access the particular
resources to which access is being granted. Additionally, this component
ensures the audibility of the user’s access to IoT resources in order to
ascertain their behaviour and actions on them.

###  4.4 Qualitative security analysis

We performed a qualitative security analysis of the proposed authorisation
scheme for IoT networks by considering the achieved security requirements.

For instance, the benefit of incorporating Blockchain technology into our
proposed scheme is that it enables us to achieve decentralisation in order to
address the single-point-of-failure issues inherent in conventional
authorisation mechanisms. The single-point-of-failure problem arises as a
result of compromised system entities such as IoT devices and storage
databases, rendering authentication information and access control policies
unreachable in a single location. On the contrary, by utilising Blockchain,
each distributed party can keep their own database of access control policies
and have their own copy of the data, which results in a high level of data
availability. Furthermore, the use of distributed ledger technology (DLT) in
Blockchain, which is shared and synchronised across several nodes, ensures
that access control policies on the ledger are secure and precisely stored
through the use of cryptography. In our proposed scheme, once access control
policies are stored on Blockchain with the approval of PMA component and
network consensus protocols, these constitute an immutable database, making
unauthorised policy changes nearly impossible. To ensure the security of the
IoT network in terms of protecting IoT devices and their data, we utilise our
existing Blockchain-based decentralised authentication scheme to ensure that
only legitimate users in the IoT network are permitted to register IoT devices
on the Blockchain using authentication tokens (e.g., subject and object
attributes). Upon validating authentication tokens by the miner nodes, the IoT
devices are registered on the Blockchain network. Besides that, since we used
a separate framework (i.e., AMF) in conjunction with Ethereum Blockchain
features to manage the requests of each user accessing IoT devices, access
tickets are generated and assigned to users for each distinct request and
managed appropriately, ensuring the privacy of users’ information. Finally, we
ensured the auditability of user requests to access IoT devices and the
policies associated with them in order to ensure the evaluation of access
control policies is auditable. The lookup table implemented in AMF ensures the
auditability feature of Blockchain technology which is derived from its
immutability and transparency properties.

##  5 Implementation and evaluation framework

As illustrated in Fig. 4, our implementation and evaluation framework is built
on various technology paradigms, including the Ethereum Blockchain, Python,
Web3.py, JSON-RPC, Ganache, Solidity, and Truffle Suite. These technological
paradigms assist us in developing and efficiently evaluating the core
functions of our proposed authorisation scheme. For instance, we implemented
our proposed decentralised prototype for our authorisation scheme on the
Ethereum Blockchain because it is a widely used platform for developing
decentralised applications (dApps) and further allowing the creation of a
secure way to conduct transactions via the elliptic curves cryptography
protocol.

The following are the details concerning these paradigms. The Ethereum
Blockchain is important to our proposed authorisation method since it enables
the efficient deployment and execution of smart contract-defined operations.
We developed our prototype interfaces in Python, which is a dynamic and
scalable language that runs on a wide variety of platforms. We used the
Python-based Web3.py framework, which allowed us to communicate with Ethereum
clients and execute functions written in smart contracts. The JavaScript-based
JSON-RPC protocol is primarily for client-side application communication. We
deployed and tested our proposed authorisation scheme using Ganache, a
Blockchain emulator, without setting up the main Ethereum network. Each node
acts as a personal Ethereum client. We used solidity programming to create the
Ethereum-based smart contracts outlined in our proposed system. Finally, the
Truffle Suite is used to create, implement, and execute smart contracts on the
Ethereum Blockchain.

Figure 4: Evaluation framework

##  6 Performance analysis and results discussion

Our experiments are conducted on a system that meets the requirements listed
in Table 5. We used a Dell Laptop (Intel Core i7-8650U) running Ubuntu 18.4
64-bit. The 64-bit operating system employed the x86_64 CPU architecture,
which has a clock cycle of 2.11 GHz. In addition, our experimental
specification contained 16 GB of RAM.

Table 5: System specifications

Operating systems Operating systems Mode CPU architecture CPU clock cycle RAM
Ubuntu 18.04 64-bits x86_64 2.11 GHz 8 GB

###  6.1 Case study: An IoT-based smart home

The rate at which computing elements, particularly in smart homes, are adopted
depends on the security level given by the specifically designed applications.
An IoT is a significant enabler in the smart home environment, enabling home
automation and improving quality of life. In IoT-based smart homes, smart
gadgets, also known as IoT devices, are deployed throughout the house to
provide the homeowner with a secure environment and control everything
remotely by using the Internet. For example, Intelligent security alarms and
motion detectors can operate intelligently and notify the homeowner if there
has been a security breach. In a smart home environment, a house owner sets up
and deploys the smart devices with the appropriate access control policies to
permit authorised users to act accordingly. However, an adversary always tries
to breach the security policies defined by the homeowner to unauthorised
access to deployed home devices to get the user’s personal information or
data. As a result, developing a secure authorisation framework for IoT-enabled
smart homes that restricts access to only authorised users becomes
increasingly essential.

Given the growing popularity of IoT-based smart home applications for complete
house automation, along with achieving the security of IoT devices and data,
we illustrate the applicability of our proposed Blockchain-based trustworthy,
flexible, fine-grained, and dynamic decentralised authorisation mechanism in
an IoT-based smart home scenario. Furthermore, it is important to note that
the applicability of our proposed scheme is not limited to the smart home
scenario but can be extended to other IoT-based applications such as smart
health, smart city, smart transportation, and so on by properly defining the
attributes and policies of the relevant applications.

In an IoT-based smart home scenario, secure permission is granted to the user
to access the IoT devices based on attribute-based access control policies
defined in the Ethereum-based Blockchain. The users act as the light nodes in
the proposed Blockchain-based system who want to access IoT devices to perform
actions in the IoT network. In comparison, the ABAC-PMF and AMF are critical
components of our proposed scheme, as both served as full nodes (e.g.,
miners), determining user requests and communicating with the Blockchain for
the purpose of accessing and granting access control policies.

###  6.2 Cost evaluation

We estimate the cost evaluation in terms of financial costs involved with
deploying our proposed scheme on the Ethereum Blockchain and then utilising
its functions to provide users with secure and dynamic access control. There
are two types of cost used to evaluate any system deployed on the Ethereum
Blockchain: deployment cost and execution cost. We computed both types of
costs for our proposed authorisation schemes, which are specified in the
subsections 6.2.1 and 6.2.2.

Furthermore, a user interacting with the Ethereum Blockchain must pay a fee in
order to deploy and execute smart contracts using ABIs. In the Ethereum
Blockchain, a unit called Gas is used to measure the amount of money required
to perform the required functions. The miners set the gas price during the
transaction, which is expressed in Gwei. Gas prices (e.g., units) are
calculated to execute smart contracts and their associated functions. In the
Ethereum Blockchain, gas units are transformed to ether, referred to as the
fuel of Blockchain. The more complicated the smart contract function, the more
money (e.g., Gas) the user must pay.

####  6.2.1 Deployment cost

The deployment cost is referred to as the cost of sending (e.g., deploying) a
smart contract to the Ethereum Blockchain. This cost is proportional to the
size of the smart contract, which contains a variety of computing functions
designed to accomplish a variety of activities. For instance, if there are
more functions with high computing demands, such as power and polynomial
functions, the smart contract will be enormous in size and have high
transaction costs.

We determine the deployment cost of our proposed scheme, which is the cost
associated with deploying the various smart contracts on the Ethereum
Blockchain. Since our proposed scheme is composed of two primary components,
the ABAC and AMF, each of which has a distinct set of smart contracts for
performing the authorisation process. For example, the ABAC-PMF component
comprises four smart contracts named $S_{SA}$, $S_{OA}$, $S_{EA}$ and
$S_{PMA}$ that manage the attributes and policies on the Blockchain. In
contrast, the AMF component consists of only one smart contract named
$S_{AMF}$ that manages user requests and the authorisation process.
Furthermore, each smart contract is deployed separately via a single
transaction; the deployment cost is calculated as the amount of Gas spent by
the transaction when it is sent to the Ethereum Blockchain.

Figure 5: Deployment cost of proposed scheme

Fig. 5 depicting the deployment cost of our proposed authorisation scheme on
the Ethereum Blockchain in terms of gas usage. As can be seen, the cost of
deploying the AMF component on Blockchain is relatively high because it
contains numerous smart contract functions for managing various tasks such as
managing user requests, auditability of user requests and policies, managing
the dynamic access process, and making further decisions. Additionally, the
deployment cost of the PMA component on the Ethereum Blockchain is less than
that of the AMF component, as the PMA component is solely responsible for
establishing, storing, and managing policies on the Blockchain. Finally, the
deployment cost of the AMA component in terms of attributes registration
(i.e., subject, object, and environment) is lower than that of other
components.

However, we believe that the cost of deploying a system on Blockchain is
totally dependent on its complexity in terms of the number of defined
functions, their size, and the logic and activities that underpin them.
Therefore, we aimed to minimise the deployment cost in our proposed scheme by
utilising the finest expertise available for designing code with the fewest
possible operations while maintaining the system’s functionality.

####  6.2.2 Execution cost

The execution cost is determined by the cost of the executing computational
operations as a result of the transaction. The transaction cost is calculated
in terms of deploying the smart contract and the data associated with the
transaction.

We calculated the execution cost of performing different operations written in
smart contracts in order to realise the process of implementing a secure,
dynamic, and flexible authorisation mechanism for IoT devices. We compare the
execution cost of our proposed scheme to the existing state-of-the-art
Blockchain-based ABAC control schemes [15] [39]. It is important to note that,
in contrast to existing schemes[15] [39], we additionally used environment-
related attributes to define dynamic and fine-grained access control policies.

Figure 6: Execution cost for managing subject attributes

Fig. 6 depicts the execution cost, in terms of gas consumption, associated
with managing subject attributes via the use of several defined functions in
smart contract $S_{SA}$. The execution cost of registering the subject
attributes is substantially higher in our proposed scheme, as the transaction
involves several attributes to be stored on the Blockchain. Moreover, the
execution cost of updating the subject attributes is less than the execution
cost of revoking the attributes, as revoking requires the specific attributes
to be disabled on the Blockchain. Additionally, the cost of executing the
managing operations on subject attributes under the scheme [15] is greater
than the cost of executing the same operations on subject attributes under the
existing system [39].

Fig. 7 depicts the execution cost, in terms of gas consumption, of managing
object attributes via the usage of several described functions in a smart
contract $S_{OA}$ operated on the Blockchain. Similar to subject attribute
registration, the operation of adding object attributes to the Blockchain
consumes more Gas in terms of execution cost than other activities. Further,
the cost of performing update operations on object properties exceeds the cost
of doing revocation operations. Finally, the overall execution cost of
operations on object attributes is lower for the existing scheme [15] than for
the existing scheme [39].

Figure 7: Execution cost for managing object attributes

Fig. 8 depicts the execution cost associated with conducting various
management operations on environmental attributes defined in the smart
contract $S_{EA}$. As with handling subject and object characteristics, the
cost of registering environmental attributes on the Blockchain is greater than
the cost of modifying and revoking the attributes. However, because the
existing schemes [15] [39] did not employ environmental attributes to define
policies, we are only demonstrating the execution cost of managing
environmental attributes in our proposed scheme.

Figure 8: Execution cost for managing environmental attributes

Fig. 9 illustrating the execution cost of performing different managing
operations on attributes under the AMA component and providing the comparison
of our proposed scheme with the existing schemes [15] [39]. We conclude from
this comparison that our proposed scheme consumes less Gas for performing the
different managing operations on attributes.

Figure 9: Execution cost for AMA management

Fig. 10 depicts the execution cost associated with managing policies on the
Blockchain. Similarly to the various management operations performed on
attributes, we defined the same managing activities for policies on the
Blockchain, including initialise, updating, and revocation. As can be
observed, the cost of initialising policies on the Blockchain is substantially
more than the cost of modifying or revoking policies. Additionally, the cost
of managing policies for the scheme [15] is greater than that of the scheme
[39].

Figure 10: Execution cost for policies management

Fig. 11 illustrates the execution costs associated with managing policies
under our proposed scheme and compares them with the existing schemes [15] and
[39]. We conclude from this comparison that our proposed scheme consumes less
Gas when performing the various management activities on policies.

Figure 11: Execution cost for PMA management

Fig. 12 depicts the execution costs associated with the AMF component
responsible for managing user requests for access to IoT devices. As can be
observed, the cost of executing policies is substantially higher, as the AMF
component is responsible for retrieving policies from the Blockchain and
comparing them to user requests, determining whether the particular user is
permitted to use IoT resources or not. Additionally, the cost of doing various
processes such as evaluating the subject’s attributes, decisions, and taking
action is almost the same

Figure 12: Execution costs for AMF management

###  6.3 Estimated financial cost associated with IoT-based smart home

Table 6: A comparison of the estimated financial costs for our proposed scheme
with existing schemes Our Proposed Scheme
---
Cases |  Miner Nodes |  IoT Devices |  Total No. of Devices |  No. of Transactions |  Transaction Approx. Cost (In Gas) |  Total Gas Consumed |  Gas Cost (ETC) |  Price (AUD)
Case 1 | 5 | 15 | 20 | 300 | 2296088 | 688826400 | 0.68883 | 52.7709905
Case 2 | 25 | 50 | 75 | 1125 | 2296088 | 2583099000 | 2.5831 | 197.891214
Case 3 | 50 | 150 | 200 | 3000 | 2296088 | 6888264000 | 6.88826 | 527.709905
Existing Scheme [15]
Case 1 | 5 | 15 | 20 | 300 | 1910838 | 573251400 | 0.57325 | 43.9167898
Case 2 | 25 | 50 | 75 | 1125 | 1910838 | 2149692750 | 2.14969 | 164.687962
Case 3 | 50 | 150 | 200 | 3000 | 1910838 | 5732514000 | 5.73251 | 439.167898
Existing Scheme [39]
Case 1 | 5 | 15 | 20 | 300 | 2238680 | 671604000 | 2518515000 | 51.4515824
Case 2 | 25 | 50 | 75 | 1125 | 2238680 | 2518515000 | 2.51852 | 192.943434
Case 3 | 50 | 150 | 200 | 3000 | 2238680 | 6716040000 | 6.71604 | 513.515824

Apart from calculating the deployment and execution costs of our proposed
authorisation scheme, we also calculated and evaluated the financial costs of
deploying it using the IoT-based smart home scenario (as illustrated in the
section 6.1). In this scenario, we considered different cases in which the
number of miner nodes and IoT devices is grown incrementally. Further, in each
case, we counted the number of transactions required for performing the
different operations, such as registering attributes to their management,
initialising policies to their management, and then providing secure access to
IoT devices. Further, we estimated the transaction cost, in Gas, for
performing different operations. We used Gwei1111 Ether = 0.000000001 Gwei as
the ether unit since it is the most frequently used gas pricing unit in the
Ethereum Blockchain. We calculate the cost of our proposed scheme using Eq. 1,
which we refer to informally as our work [4]. A single ETC transaction cost is
approximately $76.612221 ETC = $76.61 (AUD)- Writing a paper on November 16,
2021. The financial cost equation is provided below.

$\begin{split}\textrm{Financial Cost}&=\textrm{No. of Transactions}\times\\\
&\textrm{Transactions cost in Gas}\times\\\ &\textrm{Gas cost in
ETC}\times\textrm{ETC cost in AUD}\end{split}$ (1)

Table 6 presents the detailed estimated total financial cost for deploying our
proposed authorisation scheme in terms of the defined smart contracts and the
different functions underlying them to give an idea of the total cost
associated with the IoT smart home scenario. To perform different functions on
the Ethereum Blockchain, we count the number of transactions successfully
performed to provide secure authorisation to IoT devices. Next, we calculate
the financial costs associated with each case (from Case 1 to Case 3) and then
add the costs associated with each case to calculate the overall cost.
Financial costs are expressed in Australian dollars (AUD). Further, we provide
the financial costs comparison of our proposed scheme with the existing
schemes [15] [39].

Fig. 13 demonstrating the financial costs (in Australian Dollars) associated
with deploying our proposed scheme on the Ethereum Blockchain for various
scenarios involving varying numbers of miner devices and IoT devices (as
described in Table6). The financial cost of adopting our proposed scheme for
the defined IoT-based smart house scenario is slightly higher than the
existing schemes [15] and [39]. However, we can confidently state that, in
comparison to existing schemes, our proposed scheme introduced the concept of
environmental-related attributes to enable dynamic and fine-grained policies
and an AMF component for providing secure access to users and enabling
auditability for users and their assigned policies. As a result, our scheme’s
financial costs are almost identical to those of the scheme [15] and slightly
higher than those of the scheme [39].

Figure 13: Financial costs associated with deployment of IoT-based smart home

##  7 Conclusion

In this paper, we propose a Blockchain-based secure, decentralised, and
flexible authorisation scheme to address the issue of unauthorised access to
IoT network devices. We implement the ABAC model using smart contracts, which
enables the process of authorising users with secure access to IoT devices to
be executed based on dynamic and fine-grained policies stored on the
distributed immutable ledger. We designed the ABAC-PMF by utilising smart
contracts to manage attributes and policies on the Blockchain. We divided the
functionality of ABAC-PMF into two sub-components, namely AMA and PMA, which
are responsible for initialisation, storing, and managing attributes (e.g.,
subject, object, environment), and policies, respectively, on the Blockchain.
Furthermore, we designed the AMF to manage user requests to IoT devices based
on policies recorded on the Blockchain and to secure the privacy of users and
the auditability of user requests to access resources and the policies
associated with them. We implemented a prototype as a proof of concept to
evaluate the functionality of our proposed scheme on a local Ethereum
Blockchain setup. Finally, we evaluate the proposed scheme for an IoT-based
smart home scenario in order to determine its applicability in terms of
Ethereum gas consumption and financial cost.

## Declaration of Competing Interest

The authors of this paper declare that they have no known competing financial
interests or personal relationships that could have influenced the work
reported in this paper.

## Funding

This research did not receive any specific grant from funding agencies in the
public, commercial, or not-for-profit sectors

## References

  * [1] L. Atzori, A. Iera, G. Morabito, The internet of things: A survey, Computer networks 54 (15) (2010) 2787–2805.
  * [2] F. Zafar, A. Khan, S. Suhail, I. Ahmed, K. Hameed, H. M. Khan, F. Jabeen, A. Anjum, Trustworthy data: A survey, taxonomy and future trends of secure provenance schemes, Journal of Network and Computer Applications 94 (2017) 50–68.
  * [3] S. Yu, C. Wang, K. Ren, W. Lou, Achieving secure, scalable, and fine-grained data access control in cloud computing, in: 2010 Proceedings IEEE INFOCOM, Ieee, 2010, pp. 1–9.
  * [4] K. Hameed, S. Garg, M. B. Amin, B. Kang, A formally verified blockchain-based decentralised authentication scheme for the internet of things, The Journal of Supercomputing (2021) 1–41.
  * [5] S. Sicari, A. Rizzardi, L. A. Grieco, A. Coen-Porisini, Security, privacy and trust in internet of things: The road ahead, Computer networks 76 (2015) 146–164.
  * [6] D. Ferraiolo, D. R. Kuhn, R. Chandramouli, Role-based access control, Artech house, 2003.
  * [7] V. C. Hu, D. Ferraiolo, R. Kuhn, A. R. Friedman, A. J. Lang, M. M. Cogdell, A. Schnitzer, K. Sandlin, R. Miller, K. Scarfone, et al., Guide to attribute based access control (abac) definition and considerations (draft), NIST special publication 800 (162) (2013) 1–54.
  * [8] S. Gusmeroli, S. Piccione, D. Rotondi, A capability-based security approach to manage access control in the internet of things, Mathematical and Computer Modelling 58 (5-6) (2013) 1189–1205.
  * [9] S. Pal, A. Dorri, R. Jurdak, Blockchain for iot access control: Recent trends and future research directions, arXiv preprint arXiv:2106.04808 (2021).
  * [10] D. Hussein, E. Bertin, V. Frey, A community-driven access control approach in distributed iot environments, IEEE Communications Magazine 55 (3) (2017) 146–153.
  * [11] A. Dorri, S. S. Kanhere, R. Jurdak, P. Gauravaram, Blockchain for iot security and privacy: The case study of a smart home, in: 2017 IEEE international conference on pervasive computing and communications workshops (PerCom workshops), IEEE, 2017, pp. 618–623.
  * [12] D. D. F. Maesa, P. Mori, L. Ricci, Blockchain based access control, in: IFIP international conference on distributed applications and interoperable systems, Springer, 2017, pp. 206–220.
  * [13] O. J. A. Pinno, A. R. A. Gregio, L. C. De Bona, Controlchain: Blockchain as a central enabler for access control authorizations in the iot, in: GLOBECOM 2017-2017 IEEE Global Communications Conference, IEEE, 2017, pp. 1–6.
  * [14] M. P. Andersen, S. Kumar, M. AbdelBaky, G. Fierro, J. Kolb, H.-S. Kim, D. E. Culler, R. A. Popa, $\\{$WAVE$\\}$: A decentralized authorization framework with transitive delegation, in: 28th $\\{$USENIX$\\}$ Security Symposium ($\\{$USENIX$\\}$ Security 19), 2019, pp. 1375–1392.
  * [15] Y. Zhang, S. Kasahara, Y. Shen, X. Jiang, J. Wan, Smart contract-based access control for the internet of things, IEEE Internet of Things Journal 6 (2) (2018) 1594–1605.
  * [16] H. Liu, D. Han, D. Li, Fabric-iot: A blockchain-based access control system in iot, IEEE Access 8 (2020) 18207–18218.
  * [17] B. Chai, B. Yan, A. Dong, J. Yu, Sfac: A smart contract-based fine-grained access control for internet of things, Procedia Computer Science 187 (2021) 335–340.
  * [18] H. Shafagh, L. Burkhalter, A. Hithnawi, S. Duquennoy, Towards blockchain-based auditable storage and sharing of iot data, in: Proceedings of the 2017 on cloud computing security workshop, 2017, pp. 45–50.
  * [19] O. Novo, Blockchain meets iot: An architecture for scalable access management in iot, IEEE Internet of Things Journal 5 (2) (2018) 1184–1195.  doi:10.1109/JIOT.2018.2812239.
  * [20] O. Novo, Blockchain meets iot: An architecture for scalable access management in iot, IEEE Internet of Things Journal 5 (2) (2018) 1184–1195.
  * [21] B. Xu, L. D. Xu, Y. Wang, H. Cai, A distributed dynamic authorisation method for internet+ medical & healthcare data access based on consortium blockchain, Enterprise Information Systems (2021) 1–19.
  * [22] M. P. Andersen, J. Kolb, K. Chen, G. Fierro, D. E. Culler, R. A. Popa, Wave: A decentralized authorization system for iot via blockchain smart contracts, University of California at Berkeley, Tech. Rep (2017).
  * [23] J. P. Cruz, Y. Kaji, N. Yanai, Rbac-sc: Role-based access control using smart contract, Ieee Access 6 (2018) 12240–12251.
  * [24] R. Xu, Y. Chen, E. Blasch, G. Chen, Blendcac: A blockchain-enabled decentralized capability-based access control for iots, in: 2018 IEEE International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), IEEE, 2018, pp. 1027–1034.
  * [25] Y. Nakamura, Y. Zhang, M. Sasabe, S. Kasahara, Capability-based access control for the internet of things: an ethereum blockchain-based scheme, in: 2019 IEEE Global Communications Conference (GLOBECOM), IEEE, 2019, pp. 1–6.
  * [26] R. Xu, Y. Chen, E. Blasch, G. Chen, Blendcac: A smart contract enabled decentralized capability-based access control mechanism for the iot, Computers 7 (3) (2018) 39.
  * [27] R. Xu, Y. Chen, E. Blasch, G. Chen, Exploration of blockchain-enabled decentralized capability-based access control strategy for space situation awareness, Optical Engineering 58 (4) (2019) 041609.
  * [28] Y. Nakamura, Y. Zhang, M. Sasabe, S. Kasahara, Exploiting smart contracts for capability-based access control in the internet of things, Sensors 20 (6) (2020) 1793.
  * [29] B. Chai, B. Yan, J. Yu, G. Wang, Bhe-ac: a blockchain-based high-efficiency access control framework for internet of things, Personal and Ubiquitous Computing (2021) 1–12.
  * [30] P. Wang, Y. Yue, W. Sun, J. Liu, An attribute-based distributed access control for blockchain-enabled iot, in: 2019 International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob), IEEE, 2019, pp. 1–6.
  * [31] T. Sultana, A. Almogren, M. Akbar, M. Zuair, I. Ullah, N. Javaid, Data sharing system integrating access control mechanism using blockchain-based smart contracts for iot devices, Applied Sciences 10 (2) (2020) 488.
  * [32] Y. Zhang, M. Yutaka, M. Sasabe, S. Kasahara, Attribute-based access control for smart cities: A smart-contract-driven framework, IEEE Internet of Things Journal 8 (8) (2020) 6372–6384.
  * [33] X. Qin, Y. Huang, Z. Yang, X. Li, Lbac: A lightweight blockchain-based access control scheme for the internet of things, Information Sciences 554 (2021) 222–235.
  * [34] A. Ouaddah, A. Abou Elkalam, A. Ait Ouahman, Fairaccess: a new blockchain-based access control framework for the internet of things, Security and communication networks 9 (18) (2016) 5943–5964.
  * [35] C. Dukkipati, Y. Zhang, L. C. Cheng, Decentralized, blockchain based access control framework for the heterogeneous internet of things, in: Proceedings of the Third ACM Workshop on Attribute-Based Access Control, 2018, pp. 61–69.
  * [36] G. Ali, N. Ahmad, Y. Cao, S. Khan, H. Cruickshank, E. A. Qazi, A. Ali, xdbauth: Blockchain based cross domain authentication and authorization framework for internet of things, IEEE Access 8 (2020) 58800–58816.
  * [37] C. Esposito, M. Ficco, B. B. Gupta, Blockchain-based authentication and authorization for smart city applications, Information Processing & Management 58 (2) (2021) 102468.
  * [38] L. Tan, N. Shi, K. Yu, M. Aloqaily, Y. Jararweh, A blockchain-empowered access control framework for smart devices in green internet of things, ACM Transactions on Internet Technology (TOIT) 21 (3) (2021) 1–20.
  * [39] M. Yutaka, Y. Zhang, M. Sasabe, S. Kasahara, Using ethereum blockchain for distributed attribute-based access control in the internet of things, in: 2019 IEEE Global Communications Conference (GLOBECOM), IEEE, 2019, pp. 1–6.
  * [40] G. D. Putra, V. Dedeoglu, S. S. Kanhere, R. Jurdak, A. Ignjatovic, Trust-based blockchain authorization for iot, IEEE Transactions on Network and Service Management (2021).
  * [41] G. Wood, et al., Ethereum: A secure decentralised generalised transaction ledger, Ethereum project yellow paper 151 (2014) (2014) 1–32.
  * [42] S. Ding, J. Cao, C. Li, K. Fan, H. Li, A novel attribute-based access control scheme using blockchain for iot, IEEE Access 7 (2019) 38431–38441.
  * [43] K. Hameed, S. Garg, M. B. Amin, B. Kang, A. Khan, A context-aware information-based clone node attack detection scheme in internet of things, Journal of Network and Computer Applications (2021) 103271.