See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/327122315

Blockchain-Based IoT-Cloud Authorization and Delegation

Conference Paper · June 2018

DOI: 10.1109/SMARTCOMP.2018.00038

CITATIONS READS
15 280

3 authors:

Nachiket Tapas Giovanni Merlino

Università degli Studi di Messina Università degli Studi di Messina
13 PUBLICATIONS   200 CITATIONS    80 PUBLICATIONS   935 CITATIONS   

SEE PROFILE SEE PROFILE

Francesco Longo
Università degli Studi di Messina
109 PUBLICATIONS   1,372 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Blockchain and IoT View project

#SmartME View project

All content following this page was uploaded by Nachiket Tapas on 10 April 2019.

The user has requested enhancement of the downloaded file.

 Blockchain-based IoT-Cloud
Authorization and Delegation
Nachiket Tapas∗ , Giovanni Merlino∗ , Francesco Longo∗
∗ Università degli Studi di Messina, Italy

{ntapas,gmerlino,flongo}@unime.it

Abstract—In a Smart City scenario, the authors envisioned crowd-funded initiative aiming at morphing Messina into a
an IoT-Cloud framework for the management of boards and Smart City. The main goal is to disseminate IoT resources
resources scattered over a geographic area. It can also become a throughout the territory of the Messina municipality thus
tool to let device owners contribute freely to the infrastructure.
In comparison to datacenter-oriented Cloud middleware, the creating a ubiquitous sensing and actuation infrastructure and
administrator and the owner of the infrastructure are not one a virtual laboratory to which multiple tenants can contribute
and the same. This translates into the requirement to support with their own resources and on top of which they can develop
delegation-enabled authorization. In this paper, the authors applications and services for research, business, and adminis-
investigate an authorization and delegation model for the IoT- trative activities. Several tenants have been already identified
Cloud based on blockchain technology. In particular, the scheme
is implemented in the form of smart contracts over the Ethereum and yet more to come. The Messina municipality is the main
platform. Indeed, this approach represents an enhancement, #SmartME tenant providing several IoT resources hosting
over a function previously designed in a centralized fashion, by sensing and actuation subsystems monitoring the territory from
enabling the user to audit authorization operations and inspect several points of view, e.g., weather stations, soil monitoring
how access control is actually performed, without blindly trusting stations to prevent hydrogeological instability, water monitor-
the Cloud as a proxy for access to resources.
ing stations for the two salt-water lakes situated in the Ganzirri
Keywords-Smart Cities, IoT, Blockchain, Cloud, Smart Con- locality. The University of Messina also provided several
tracts, Ethereum, access control, authorization, delegation resources in the form of Arduino YUN-based IoT nodes
hosting a set of sensors to monitor temperature, pressure,
I. I NTRODUCTION humidity, quality of air, and other quantities. Finally, private
Cities are complex ecosystems where people, objects, build- citizens have been encouraged in contributing with their own
ings, vehicles, natural elements interact in ways that are often private resources by involving, e.g., meteorology enthusiasts
difficult to analyze and understand. Both social and technologi- and community of makers. Such a complex and dynamic
cal issues merge thus making cities a fertile application domain environment calls for authorization and delegation models
for different sciences and technologies. The concept of Smart and mechanisms. In fact, while the Messina municipality and
City has become pervasive in multidisciplinary research fields, the University of Messina provided their resources almost
ranging from architecture and urban-planning to information permanently, private citizens are more prone to contribute their
and communication technologies (ICT), as a new paradigm to resources only on a temporary basis whenever under demand,
manage and organize the city life. delegating other stakeholders of the system (mainly small and
From the ICT point of view, a Smart City infrastructure can medium enterprises developing innovative applications and
be viewed as a multitude of heterogeneous network-enabled services) to the use of such resources for prototyping and
cyber-physical “things” providing sensing and actuation facil- testing activities.
ities, such as traffic sensors, security cameras, traffic lights as In a recent work [2], we took into consideration
well as citizens’ smartphones. Such huge amount of objects such a challenge and extended our IoT-Cloud framework,
usually belongs to different owners and administrative do- Stack4Things [3], with an access control, authorization, and
mains. Recently, Internet of Things (IoT) has gained attention delegation model trying to overcome the limitations of exist-
as a technological trend aiming at providing methods and ing solutions based on access control protocols and policy
mechanisms for the interconnection and communication of frameworks such as XACML [4] and CCAAC [5] which
such smart objects while Cloud computing has been taken into may result in heavy-weight implementations for resource con-
consideration as the paradigm of reference for managing them strained nodes, such as typical sensor/actuator-hosting boards
elastically, on-demand, and “as-a-service”, after (possibly) and can, therefore, be considered unfeasible. However, the
applying abstraction and virtualization techniques. proposed solution implicitly require the end user to trust the
The heterogeneity in the ownership of Smart City objects Stack4Things framework and its (hidden) behaviour. In this
represents an interesting problem to be investigated, mainly paper, we introduce the use of blockchains to let the user do
related to the management of access control, authorization, without trusting the IoT-Cloud framework, at least for what
and delegation of IoT resources. As an example, let us take regards authorization.
into consideration the #SmartME project [1]. #SmartME is a The rest of the paper is organized as follows. In Section II
there is a description of the background about the middle- of Keystone APIs, due to the requirement to dynamically
ware, the technologies involved, and the motivations. Then, associate API calls to roles, a feature which requires a number
Section III is where the design, notable implementation details, of non-trivial modifications to policy (JSON) files. For such a
and some experimental results are shown. In Section IV a reason, we devised for Stack4Things its own authorization and
selection of related work can be found. Finally, in Section V delegation mechanisms to access resources without resorting
we draw some conclusions and outline future work. to the standard OpenStack approach.

II. BACKGROUND
In this section, we first show the architecture of the
Stack4Things framework, illustrating some details about how
the already existing authorization and delegation mecha-
nisms used to work. Then, we provide some background
about blockchain technologies, with specific reference to the
Ethereum platform [6]. Finally, we list the main motivations
that prompted us in undertaking the present work.

A. Stack4Things authorization and delegation

The overall architecture of Stack4Things is defined in [3]. It
highlights interactions and communication facilities between
end users, the Cloud, and (possibly mobile) sensor- and
actuator-hosting IoT nodes.
On the IoT node side, the Stack4Things lightning-rod rep-
resents the point of contact with the Cloud infrastructure
allowing the end users to manage node-hosted resources even
when nodes are behind a NAT or a strict firewall. This is Fig. 1. Cloud-side Stack4Things architecture with focus on authentication,
ensured by WebSocket-based tunneling and WAMP-based1 authorization, and delegation mechanisms.
messaging between the Stack4Things lightning-rod and its
Cloud counterpart, namely the Stack4Things IoTronic service. Figure 1 shows the Cloud-side Stack4Things architecture
The Stack4Things IoTronic is designed as an OpenStack with specific focus on authentication, authorization, and del-
service, providing end users with the possibility to manage one egation mechanisms. While authentication is implemented
or more nodes, remotely. The main goals of IoTronic lie in by fully relying on Keystone, a specific IoTronic agent,
extending the OpenStack architecture towards the management namely the Stack4Things IoTronic delegation agent, deals with
of mobile/embedded system-hosted sensing and actuation re- authorization and delegation duties. Whenever an API call
sources. is issued by a user on a specific IoT-node and after the
In Stack4Things, authentication mechanisms are imple- authentication token is validated by interacting with Keystone,
mented by leveraging the OpenStack Keystone subsystem. the Stack4Things IoTronic APIs contact the Stack4Things
Keystone is an implementation of the OpenStack Identity IoTronic delegation agent in order for it to check if the user
service, providing authentication and high-level authorization is granted access to the specific operation on that specific
mechanisms through the use of credentials and authentication IoT-node or not. If authorization is granted, the Stack4Things
tokens. To authorize an incoming request, Keystone validates IoTronic APIs deliver the request to the Stack4Things IoTronic
a set of credentials supplied by the issuing user. Initially, the conductor which triggers all the steps that are needed to fulfill
credentials are represented by a username and a password. it, involving other Stack4Things IoTronic agents if required.
As soon as such credentials are validated by Keystone, an Fig. 2 depicts the entity-relationship model for authentica-
authentication token is released that can be exploited by the tion and delegation mechanisms in Stack4Things. The Node
user in subsequent requests. entity represents the set of IoT nodes managed by the IoTronic
OpenStack ensures API protection by exploiting the role- service while the User entity represents the set of users that are
based access control (RBAC) model. Each token issued by somehow allowed to interact with IoT nodes. The Operation
Keystone includes a list of roles for the user. When the user entity models the set of API operations that needs to be
calls a service, that service interprets the set of user roles authorized on specific IoT nodes. The Role entity represents
and determines which operations or resources each role grants the set of IoTronic roles that are currently defined in the
access to. However, delegation mechanisms, i.e., temporarily system.
granting a user permissions to perform an API call on a Finally, the Delegation entity contains the list of roles
specific subset of the resources available as a whole and then assigned to users for each IoT nodes. Delegations can be
revoking them, could be quite hard to implement in terms distinguished in two main categories. First level delegations
represent roles that are assigned to users by default or by an
1 See http://wamp.ws. administrator, e.g., the role IoT-node-owner is automatically
 ID
Name
Description bone, a Turing-complete language, and an unlimited publicly
Timestamp

Name
ID Target node Permission ID
verifiable storage. It can be viewed as a transaction-based
(0,N) (1,N)
Name

Location
Node
(1,N)
Role Operation
Description
state machine where each valid transaction causes the state
Timestamp
Associated role
(0,N)
Timestamp
Timestamp
machine to move to the next state, thus, forming a chain of
ID
states. Bitcoin is the most popular cryptocurrency to date but
Delegated user (1,1) (1,1)
Timestamp
it lacks support for a programming environment to leverage
ID

Name User
(0,N) (1,1)
Delegations
(0,N)
Parent delegation the decentralized environment for other applications. The
Timestamp
(0,N) (1,1) (1,1) Turing-complete language of Ethereum supports the creation
of decentralized applications, called DApps, that work over
Delegating user
a peer-to-peer network. Ethereum handles internal state and
computation via Ethereum Virtual Machine (EVM). Each node
Fig. 2. The entity-relationship model for the authorization and delegation on the peer-to-peer network runs the EVM which executes
mechanisms in Stack4Things.
transactions and code based on global consensus. Ethereum
encourages building and deployment of DApps. Thus, any
assigned to the user that creates a node in the system, centralized service can be decentralized using Ethereum. A
representing the situation in which a user contributes a node to Decentralized Autonomous Organizations (DAO), which is
the system and therefore has all the permissions on that node. fully decentralized, autonomous organization, can be built
Lower level delegations represent roles that are temporally using Ethereum. Another important feature of Ethereum is
assigned to a user by another user that is already granted Smart Contract. Ethereum implements DApps through smart
with that role, or with a role that includes all the considered contracts running on top of the EVM.
permissions. In this sense, they represent an operation of trust In 1994, Nick Szabo - a legal scholar, and cryptographer
from the delegating user to the delegated one. Each lower level - realized that a decentralized ledger could be used for smart
delegation contains the information about the parent delegation contracts2 . Smart Contracts are a formal generalization of a
from which it derives. In this way, the IoTronic implements transaction based state-machine. Also known as self-executing
a multi-level delegation system in which if a delegation is contracts, Blockchain contracts, or digital contracts, smart
revoked all its child delegations are revoked (cascade revo- contracts enables the exchange of cryptocurrency, or any
cation). More details about the legacy mechanisms that have tangible value in a fair, conflict-free way while eliminating any
been enhanced in this work can be found in [2]. third party. Smart contracts can be characterized by three prop-
The red box, in Figure 2, highlights the portion of the data erties namely autonomy, decentralization, and auto-sufficiency.
model that has been implemented on-chain while migrating Autonomy implies once the contract is on the Blockchain,
toward blockchain-based mechanisms. no interaction is required from the initiator of the contract.
Smart contracts are decentralized in nature as they exist on
B. Blockchain, Ethereum, and Smart Contracts the Blockchain. Auto-sufficiency points towards the automatic
In 2008, Satoshi Nakamoto [7] proposed a cryptocurrency execution of contracts based on certain conditions. Smart
named Bitcoin in a completely decentralized environment. contracts particularly solve the problem of a trusted third
Blockchain is the enabling technology behind Bitcoin. A party in any system. The smart contract triggers automatically
Blockchain is a public distributed ledger that stores all trans- on certain programming conditions and is publicly verifiable
actions ever executed in the network. It is a sequence of on the Blockchain, it can eliminate the need for a trusted
blocks in which each block is linked to the previous block entity. Smart contracts can find application in various scenarios
via its cryptographic hash. The design of the Blockchain e.g., real estate law, financial transactions, legal processes,
is such that it resists any modification to data. Once the crowdfunding, insurance premiums.
data has been recorded in a block on the chain it cannot
be altered without changing all subsequent blocks. This im- C. Motivations
mutable nature of blockchain leads to an open, distributed
Accordingly to the mechanisms described in Section II-A,
ledger capable of efficiently recording transactions between
the IoTronic service is supposed to be fully trusted by end
couples of entities and allows public verification. A peer-to-
users that expect it to manage IoT resources and provide
peer network is responsible for managing the distributed ledger
access to them in a fair way. However, malicious adminis-
and a specific protocol is enforced for validating new blocks.
trators and/or unfair internal policies could affect IoTronic
Once the network confirms the validity of a block, the block
supposed behavior by, e.g., forcing it to deny access to specific
is added to the chain permanently. The Blockchain can easily
operations to users with full rights. Moving authentication
be proposed as a generalized framework for managing assets
and delegation mechanisms to the blockchain allows moving
in a distributed way in a read-only manner. Blockchain can
part of the trust to the deployed smart contracts and it can
be particularly useful in situations requiring maintenance of
unmodifiable and verifiable audit trail. 2 See http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/
Ethereum is a decentralized generalized transaction ledger CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart
[6]. The key elements of Ethereum are Blockchain as a back- contracts 2.html.
be considered as a first step in the migration toward a fully checking correctness and removing bugs. In order to tune
decentralized version of the Stack4Things framework. smart contracts’ code size to satisfy gas requirements, we
The aim of the present work is to leverage blockchain designed two separate contracts. Role.sol contract captures
technologies with the following motivations: the association of each role with the corresponding allowed
• Trustness: Ethereum smart contracts are deployed and run operations, while a second contract, named Delegation.sol,
on top of all the nodes in the network and consensus is represents the relationship between users, resources, and roles.
reached each time a smart contract is invoked. Moreover, Composition design strategy is chosen over inheritance with
provided that the user is able to check that the bytecode the goal of reducing coupling between the two smart contracts,
that is deployed on the blockchain is actually coming as both the paradigms are supported by Solidity. Such a
from the claimed source code (this is actually possible decision presents a second advantage: inheritance would lead
and similar services are even provided online by, e.g., to a single contract being actually deployed to the blockchain,
the Etherscan Contract Verification tool3 ), he/she can with corresponding increase in gas consumption.
reasonably be sure that access control is performed the For code development in this second phase, we used the
way it is documented. Truffle framework6 . Truffle is a more powerful development
• Auditing: However, this is not enough to reach a complete environment compared to Remix as it not only acts as a
trustiness in the system because the user should also be Solidity compiler but also allows testing smart contracts
sure that the Stack4Things IoTronic delegation agent is in a flexible way, supporting different testing environments.
actually interacting with the smart contracts to check We initially tested the implemented smart contracts using
for user permissions. Thus, another reason for the use the testRPC and the Ganache tools7 that locally emulate a
of blockchain is the possibility to implement a public complete blockchain on top of the development host. On
auditing system. Thanks to blockchain (and specifically the client side, we used Javascript bindings of the Web3
via Ethereum events and logs), each operation can be libraries to interact with the contracts and to simulate use
logged on the blockchain and the end user is able to cases. Once the system was working as expected, we migrated
check why access to a certain operation/resource has been the contracts on the Ethereum public testnets (i.e. Ropsten, and
granted or denied. Rinkeby) - each of which exhibits specific characteristics and
Note that, in the present work, privacy is not taken into implements different consensus algorithms - to observe real
consideration, as a requirement. In fact, maintaining the public world performance of our system. Performance parameters
auditing system and guaranteeing user privacy at the same time have been recorded to present a comparative study of our
could be complex. Future work will be devoted to investigating experiments.
this aspect. B. Data structures and interfaces
III. B LOCKCHAIN - BASED AUTHORIZATION AND Role.sol smart contract is designed to store the relationship
D ELEGATION between roles and corresponding allowed operations. Thus,
In this section, we first give some details about how the a structure data type, namedAllowedOperations, is used
implementation of the blockchain-based authorization and to group all authorized operations. Solidity facilitates effi-
delegation mechanisms in Stack4Things has been conducted. cient data retrieval via mapping consisting of key-value pair. A
Then, we show how the exploited smart contracts have been second member of the structure is an unsigned integer (named
designed with specific reference to the data structures and their index) whose purpose will be clarified later. A mapping
interfaces. Finally, we provide some experimental results that variable (named roles) is defined with role identifiers (in the
give a first idea about the performance of the overall system. form of bytes32 datatype) as keys pointing to the correspond-
ing AllowedOperations structures. Index variable, with
A. Development process and design choices variable size array (named chkRole), maintains the existence
The implementation of the Ethereum-based authentication of a particular role. A code snippet for the described data
and delegation mechanisms in Stack4Things has been con- structures is provided below.
ducted following an agile development process. We selected struct AllowedOperations {
Solidity4 as our reference language, due to its similarity with bytes32[] operations;
uint index;
Javascript and the better support that the Ethereum community }
provides with respect to other languages, e.g., Serpent. As a
first step, we designed and implemented all the mechanisms mapping (bytes32 => AllowedOperations) roles;
within a single smart contract, with complete functionality. bytes32[] public chkRole;
In this phase, we used the Remix IDE5 that acts as a
Solidity compiler and allows to test simple transactions for Role.sol contract contains several public functions acting as
an interface for the above-reported data structure. Transaction-
3 See https://etherscan.io/verifyContract.
4 See http://solidity.readthedocs.io/. 6 See http://truffleframework.com/.
5 See https://remix.ethereum.org. 7 See http://truffleframework.com/ganache/].
generating functions modify the internal state of the con- user.In this way, transaction-generating calls are recorded on
tract, and thus, need to wait for mining and consume gas, the blockchain as state changes while view requests are stored
e.g., addRole (to add a new role). Other functions, e.g., as logs which can be later accessed from Web3 clients.
getRoles (to obtain the IDs of all the roles in the system)
are declared as view functions which do not alter the internal 1
state of the contract and, thus, do not consume gas. Prototypes Delegation.sol Role.sol
of the addRole and getRoles functions are provided in the 8 3 4
s4t IoTronic
following code snippet as an example. delegation
agents 7 5
function addRole(bytes32 _roleID, bytes32[]
_operationID) public returns (bool)
6
function getRoles() public view returns (bytes32[])
2
The contract contains a view function to check if a specific
s4t
operation is allowed by a specific role. It will be used for IoTronic Ethereum blockchain
database
access authorization of a user.
In the Delegation.sol contract, a DelegationInfo struc-
ture is used to store information about a delegation, i.e., an REST communication
identifier of the delegating user, an identifier of the beneficiary AMQP publish/subscribe
user, an identifier of the IoT resource, and an identifier of the Interaction with database
assigned role. Smart contract function call

struct DelegationInfo {
bytes32 delegatingUserID; Fig. 3. Interaction between s4t IoTronic delegation agent and smart contracts
bytes32 beneficiaryUserID; on the Ethereum blockchain.
bytes32 resourceID;
bytes32 roleID;
uint index; Fig. 4 represents the sequence of interactions that takes
} place when access to a specific operation on a specific IoT
mapping (bytes32 => DelegationInfo) delegInfo; resource needs to be granted to a user. In step 1, the user
requests for a particular operation on a specific IoT resource
bytes32[] public chkDeleg; and the request is redirected to the S4T IoTronic delegation
Similarly to Role.sol contract, we introduce an index to agent by the S4T IoTronic conductor. In step 2, the agent
track the existence of a delegation. As a key for such a checks the S4T IoTronic database for validating the user
mapping, we explored the use of keccak256 hash (shorthand request (e.g., the existence of the IoT resource is checked). In
notation for the KECCAK-256 variant of SHA-3) that allows step 3, after successful validation, the S4T IoTronic delegation
obtaining a single key from a combination of: beneficiary user agent calls the Delegation.sol contract by using the Web3
identifier, IoT resource identifier, and a role identifier. Check- client. A User identifier, an operation identifier, and IoT
ing for the existence of a delegation is similar to what has resource identifier are passed as parameters. In step 4, the
been done in the Role.sol contract, except for the computation Delegation.sol contract requests the roles granting access to the
of the keccak256 hash. Here, an important assumption that considered operation to the Role.sol contract. In step 5, such a
needs to be mentioned is that the identifier of the beneficiary list of roles is returned and the Delegation.sol contract checks
user, the identifier of the IoT resource, and the identifier of the if the user is associated with one of them for the considered
role are considered as primary attributes (i.e., equivalent to a IoT resource. In step 6, the Delegation.sol contract logs the
primary key, combined). On the other hand, the identifier of result in the blockchain and finally, in step 7, it sends the result
the delegating user is considered optional as it is absolutely back to S4T IoTronic delegation agent that, in step 8, sends the
possible to have two different roles being delegated to the result back to the S4T IoTronic conductor. Eventually, access
same user on the same resource by the same delegating user. to the user is granted or not depending on the result.
Given that some default roles are assigned to the user that
creates an IoT node in the system, for the sake of simplicity, C. Preliminary evaluation: experimental results
we considered the IoT Admin to be the delegating user if not In terms of a preliminary performance evaluation, we
specified otherwise. measured the average time required to add a delegation to
Creation of new delegation alters blockchain state and, thus, the blockchain and average time required to retrieve the
generates a transaction. once mined, the changes are perma- response for an access request across different simulators and
nently stored on the blockchain. An access check function public testnets. We used TestRPC and Ganache as simulators
is used to verify if a user is granted a specific operation and Ropsten and Rinkeby as public testnets. Table I shows
on a specific node. In addition to validating user access, the average execution time, variance, and (95%) confidence
the function logs the request on the chain by generating a interval of 1000 consecutive requests to add a delegation
transaction, thus, creating an audit trail for verification by the to the blockchain. Similarly, Table II shows the average
 TABLE I
S IMULATION RESULTS FOR : ADDING DELEGATIONS

Response Simulators / Public Testnets

times [sec] TestRPC Ganache Ropsten Rinkeby
Average 0.8288 ± 0.0253 0.0929 ± 0.0026 18.9269 ± 1.1801 40.0096 ± 1.0690
Variance 0.1667 0.0018 362.5130 297.4485

TABLE II
S IMULATION RESULTS FOR : ACCESS AUTHORIZATION

Response Simulators / Public Testnets

times [msec] TestRPC Ganache Ropsten Rinkeby
Average 172.5450 ± 14.3827 59.4440 ± 1.4865 115.4050 ± 16.0350 122.6510 ± 15.2851
Variance 53847.7437 575.2221 66930.6076 60816.8741

execution time, variance, and confidence (95%) interval of been included, as well as some preliminary results. Ongoing
1000 consecutive access authorization requests. In order to and future work is planned to deploy the smart contracts in
prevent overwhelming of the simulator/testnets, we introduce the #SmartME ecosystem and other Stack4Things-powered
a delay in processing of transactions. To eliminate any bias of testbeds, to experiment the validity of the solution at scale. The
the system, we recorded execution time for 1020 transactions proposed solution will also be compared against promising
and removed 10 initial and 10 final transactions. Access approaches like OAuth2.
authorization requests take an order of magnitude less time
R EFERENCES
when compared to requests for adding a delegation to the
system. The response time for access authorization requests is [1] D. Bruneo, S. Distefano, F. Longo, and G. Merlino, “An IoT testbed for
the Software Defined City vision: the #SmartMe project,” in 2016 IEEE
minimal, which is compliant with our design goals. Compared Int. Conf. on Smart Computing (SMARTCOMP), May 2016, pp. 1–6.
to TestRPC, Ganache performs better, both in terms of adding [2] D. Bruneo, S. Distefano, F. Longo, G. Merlino, and A. Puliafito, “IoT-
a new delegation or validating access. When comparing public cloud authorization and delegation mechanisms for ubiquitous sensing
and actuation,” in 2016 IEEE 3rd World Forum on Internet of Things
testnets, we find that the proposed design performs better (WF-IoT), Dec 2016, pp. 222–227.
on Ropsten testnet which is more closer to main Ethereum [3] F. Longo, D. Bruneo, S. Distefano, G. Merlino, and A. Puliafito,
network. Future work will be devoted to analyzing this results, “Stack4things: a sensing-and-actuation-as-a-service framework for iot
and cloud integration,” Annals of Telecommunications, vol. 72, no. 1,
capturing useful insights for optimizing our implementation. pp. 53–70, Feb 2017.
[4] L. Seitz, G. Selander, and C. Gehrmann, “Authorization framework for
IV. R ELATED WORK the internet-of-things,” in World of Wireless, Mobile and Multimedia
Traditional access control models, like Role-Based Access Networks (WoWMoM), 2013 IEEE 14th Int. Symp. and Workshops on,
2013, pp. 1–6.
Control (RBAC) model [8], depend on a trusted third-party [5] B. Anggorojati, P. N. Mahalle, N. R. Prasad, and R. Prasad, “Capability-
authorization engine to grant access. This creates mistrust in based access control delegation model on the federated iot network,”
the system. Also, such models are based on a centralized in The 15th International Symposium on Wireless Personal Multimedia
Communications, Sept 2012, pp. 604–608.
model, which does not overlap with the distributed architecture [6] G. Wood, “Ethereum: A secure decentralised generalised transaction
of the IoT. ledger,” 2014.
This led us to explore blockchain technology as an access [7] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
[8] D. Ferraiolo, R. Kuhn, and R. Sandhu, “Rbac standard rationale:
control mechanism, due to its distributed nature. A.Ouaddah Comments on ”a critique of the ansi standard on role-based access
et al. [9] used blockchain to store and audit access control control”,” IEEE Security Privacy, vol. 5, no. 6, pp. 51–53, Nov 2007.
policies. L.Chen and H.Reiser [10] store access rights for a [9] A. Ouaddah, A. A. Elkalam, and A. A. Ouahman, “Towards a novel
privacy-preserving access control model based on blockchain technology
resource in a blockchain and manage them via transactions. in iot,” in Europe and MENA Cooperation Advances in Information and
MeDShare proposed by Xia, Qi, et al. [11], for controlling Communication Technologies. Springer, 2017, pp. 523–533.
access to sensitive medical data, uses blockchain to store the [10] L. Y. Chen and H. P. Reiser, “Distributed applications and interoperable
systems, 17th ifip wg 6.1 international conference, dais 2017, held as part
history of operations performed on the data and smart contracts of the 12th international federated conference on distributed computing
to enforce access control. techniques, discotec 2017, neuchâtel, switzerland, june 19–22, 2017.”
Springer, 2017.
V. C ONCLUSIONS AND F UTURE W ORK [11] Q. Xia, E. B. Sifah, K. O. Asamoah, J. Gao, X. Du, and M. Guizani,
“Medshare: Trust-less medical data sharing among cloud service
In this paper, we proposed an enhancement to an IoT-Cloud providers via blockchain,” IEEE Access, vol. 5, pp. 14 757–14 767, 2017.
solution in the form of a decentralized design for resource
access authorization and delegation duties. The proposal fea-
tures blockchain as a technological building block for this
scheme and smart contracts as the main engine for trustless
decentralization and independent audit of operations. Details
about the design and implementation of the contracts have

View publication stats