Conference PaperPDF Available

Decentralised Runtime Monitoring for Access Control Systems in Cloud Federations



Content may be subject to copyright.
Decentralised Runtime Monitoring for Access
Control Systems in Cloud Federations
Md Sadek Ferdous, Andrea Margheri, Federica Paci, Mu Yang, Vladimiro Sassone
University of Southampton
{s.ferdous; a.margheri; f.m.paci; mu.yang; vsassone}
Abstract—Cloud federation is an emergent cloud-computing
paradigm where partner organisations share data and services
hosted on their own clouds platforms. In this context, it is
crucial to enforce access control policies that satisfy the data
protection and privacy requirements of the partner organisations.
However, due to the distributed nature of cloud federations,
the access control system alone does not guarantee that its
deployed components cannot be circumvented while processing
access requests. Therefore, in order to promote accountability
and transparency of access control decisions in federated clouds,
we present a decentralised runtime monitoring architecture based
on a blockchain technology. The logging components and data
of the proposed infrastructure are deployed on the blockchain.
This guarantees that the runtime monitoring components and the
access logs cannot be compromised by malicious users to disguise
their actions. We evaluate the performance of the runtime mon-
itoring infrastructure with respect to detecting policy violations,
and the cost of deploying the logging components and data on
the blockchain.
Index Terms—Access Control, Cloud Federation, Runtime
Monitoring, Blockchain, Security.
The advent of cloud computing has enabled new collabora-
tive scenarios in which users and organisations share resources,
information and services in order to achieve a common goal
or interest. An instance of this trend is provided by federated
clouds [1], [2], [3]. These are cloud systems created dynam-
ically to achieve a business goal, such as sharing computa-
tional resources and/or data. Resource sharing can however
be hindered by security and privacy concerns: organisations
which partner in a federation will consider who can access
their shared resources, for what purposes, and what are the
potential consequences of granting access.
An approach typically adopted to address these concerns is
to deploy a federation-wide access control system to enforce
access control policies attached to the federation by the
resource owner [4]. This means that there will be distributed
components that receive, exchange and process access requests
and their corresponding access decisions. However, in this
distributed setting, it is possible that these components are
circumvented, e.g. an exchange message may be subverted or
a component violated.
To prevent such attacks, this paper proposes a runtime
monitoring solution for distributed access control systems:
Decentralised Runtime Access Monitoring System (DRAMS).
DRAMS enables runtime monitoring of federated access con-
trol policies by including distributed logging probes which
sense access control activities and intercept access requests and
decisions. These logs are then processed to check the integrity
of the monitored components. Differently from classical (cen-
tralised) applications, DRAMS copes with the distributed
nature of federated clouds: multiple components deployed as
part of different computing systems, that interact together to
enforce an access decision. Specifically, there should be an
adequate infrastructure that allows logs collected on distributed
components to be stored with the consensus of all probes.
Hence, the logs can be monitored and appropriate guarantees
on the monitoring checks can be provided to the involved
federated clouds, i.e., they must have non-repudiable evidence
on the integrity of the checks.
To implement this monitoring system, we build DRAMS
upon the access control system of Federation-as-a-Service
(FaaS) [3], a recently proposed approach to cloud federation
devised and developed by the H2020 project SUNFISH [5].
Indeed, we put forward the first application of blockchain
technologies [6] as an infrastructure for storing logs and per-
form non-repudiable monitoring checks. Blockchain is a novel
technology that, besides its application to cryptocurrency,
features fascinating properties of data integrity, distribution
and control. We rely on a blockchain infrastructure to enjoy
these properties while collecting and evaluating access control
logs. More specifically, we utilise an advanced blockchain sys-
tem based on so-called smart-contracts, which are arbitrarily
complex programs deployed and executed autonomously on a
blockchain. This approach is our key to guarantee the integrity
and availability of the stored logs.
To evaluate our approach, we have deployed a proof-of-
concept implementation on top of Ethereum [7], the state-of-
the-art technology for distributed ledgers (blockchain) smart-
contracts. Specifically, we consider a simplified cloud feder-
ation setting and multiple users carrying out different access
strategies on federated resources. The evaluation results indi-
cate that our approach is able to detect every policy violation.
Contribution. This paper presents the first adoption of a
blockchain-based system in the design and implementation of
a runtime monitoring system. We report here the architectural
design, implementation strategy and performance evaluation
of the prototype implementation of DRAMS, a distributed
runtime monitoring system for federated cloud access control,
and discuss the security assurances it provides.
Structure of the paper. Section II introduces background
concepts. Section III comments on the adversary model for
the access control system. Section IV presents the DRAMS
architecture along with the underlying monitoring protocols
and checks. The proof-of-concept implementation is described
in Section V, as well as its performance evaluation. Section
VI discusses on the DRAMS approach, while Section VII
reviews related work. Section VIII reports concluding remarks
and touches upon future work.
This section introduces the access control language XACML
(Section II-A), the access control system of a FaaS cloud feder-
ation (Section II-B) and blockchain technology (Section II-C).
The eXtensible Access Control Markup Language
(XACML) [8] is the de-facto standard for attribute-based
access control [9]. This type of access controls are based
on attributes, i.e. arbitrary security-relevant information
exposed by the system, the involved subjects, the action
to be performed, or by any other entity of the evaluation
context relevant to the rules at hand. The attribute-base model
permits defining fine-grained, flexible and context-aware
access control rules that are expressive enough to uniformly
represent all previous access control models [10], e.g. the
well-known role-based one [11].
XACML consists of an XML language for access control
policies and a structured evaluation process for their enforce-
ment. Each policy enlists the controls on the attribute values to
satisfy to gain the access to protected resources. These controls
are hierarchical structures of positive and negative access
rules, which are combined together by means of strategies
for resolving possible conflicting access decisions (e.g., both
positive and negative access rules apply to an access request).
The XACML policy evaluation process mainly involves the
following components
Policy Decision Point (PDP): it calculates an access deci-
sion for a user’s request based on the available policies.
Policy Enforcement Point (PEP): it enforces the decision
calculated by the PDP in the system.
Indeed, once PEP receives a user’s request, it forwards it to
the PDP, which calculates the access decision. The decision is
then enforced by the PEP.
The evaluation process carried out by the PDP relies, on the
one hand, on contextual information provided by the Policy
Information Point (PIP). On the other hand, it is based on the
access control policies made available by the Policy Retrieval
Point (PRP) and administered by the Policy Administration
Point (PAP). This modularised architecture allows XACML to
be exploited within any application domain.
The decision resulting from the policy evaluation process
can be one among permit,deny,not-applicable and
Figure 1: Distributed Access Control System of FaaS
indeterminate1. The meaning of the first two ones is
obvious, the third one means that there is no policy that
applies to the request and the latter one means that some errors
have occurred during the evaluation. Policies can automatically
manage these errors by using the policy combing strategies.
B. Access Control Systems for Cloud federations
Cloud federation is a recent solution to prompt aggregation
and cooperation of cloud systems [1], [2]. In this context,
the H2020 project SUNFISH [5] devised and developed an
innovative cloud federation solution, Federation-as-a-Service
(FaaS) [3]. FaaS offers a service that allows clouds to create
and manage cloud federations. To securely managing federated
data and inter-cloud interactions, FaaS includes the distributed
access control system based on XACML introduced in [12]
and shown in Figure 1.
The access control system is deployed along with the
tenants (i.e., virtual spaces of computing resources belonging
to different clouds) underlying a FaaS federation. The PDP and
the policy management is placed in the infrastructural tenant
(i.e., the tenant owned by all federation clouds that enabled the
FaaS functionalities). PEP is instead deployed in a distributed
manner on the tenant edge, thus to intercept all communica-
tions, interact with the distributed sources of information (i.e.,
the distributed PIP), and enforce the calculated accesses.
This architecture enables a user from any tenant to access
services hosted in another tenants in a secure and controlled
manner. It indeed enforces the access control protocol defined
by the numbers on the arrows of Figure 1. Specifically, when
a service consumer from Tenant 2 requests a service from
Tenant 1 (step 1), the local PEP forwards (by possibly adding
additional attributes via local interactions with PIP) to the PEP
1For the cognitive, a PDP evaluation process complaint with XACML relies
on specialised indeterminate decisions, so-called extended indeterminate.
However, any specialised indeterminate returned by the PDP is converted
to indeterminate before being sent to the PEP; hence we retain to the
single indeterminate decision.
of the Infrastructural Tenant the access request to authorise
(step 2). The request is then forwarded to the PDP (step 3)
that, on the base of the policies currently in force (step 4),
calculates an access decision; the latter evaluation can require
additional interactions with the local PIP. The access decision
is then sent to the PEP (step 5) and, if positive, forwarded to
the PEP of Tenant 1 (step 6) to enforce the allowed access
(step 7).
C. Blockchain and Smart-Contract
Blockchain is a novel technology that has appeared on the
market in recent years. It was firstly used as a public ledger
for the Bitcoin cryptocurrency [6]. It consists of consecutive
chained blocks, replicated and stored by the nodes of a peer-
to-peer network, where blocks are created in a decentralised
fashion by means of a consensus algorithm called Proof-of-
Work (PoW). The use of PoW enables several data integrity
related properties in blockchain, such as distributed and demo-
cratic control of the data on the chain, distributed consensus
on the chain state, and non-repudiation and persistency of
transactions and data provenance.
Blockchains can be adapted to different needs, indeed,
there can be multiple deployment strategies to pursue; mainly
we have: public, i.e. an unpermissioned system open to any
user, and private, i.e. a permissioned system with control on
operating users. Depending on the blockchain type, parameters
of PoW can be tuned accordingly. For instance, the higher the
difficulty of the hashing procedure is, the higher the time to
obtain integrity guarantees is.
Differently from Bitcoin, new types of blockchains have
recently appeared featuring smart-contracts, that is, programs
deployed and executed on blockchain. Being part of the
blockchain makes contracts and their executions immutable
and irreversible. Smart-contract permits creating so-called de-
centralised applications (DApps), i.e. applications that operate
autonomously and without any control by a system entity.
More specifically, a DApp is configured as a web server
exposing APIs to invoke smart-contract on blockchain.
The state-of-the-art smart-contract blockchain is
Ethereum [7]. It features a virtual machine, called Ethereum
virtual machine (EVM), which allows smart-contracts to
be deployed and executed. Most of all, EVM executes
contracts according to an amount of Ether (i.e., the Ethereum
cryptocurrency) given in input. As the execution of every
contract action costs a certain Ether amount, it follows that,
on the one hand, the termination of contract executions is
always guaranteed and, on the other hand, that to operate on
the public Ethereum it is currently required to pay around
9.6USD per Ether2. Additionally, Ethereum supports an
event-based mechanism that, via specific interfaces, allows
smart-contracts to raise an event signaling to a DApp that a
certain action, e.g. the storing of data, has been carried out in
the smart-contract.
2As per on 16 January, 2017
In this section, we model the capabilities of the adversary
facing the access control system. To accomplish an attack, the
adversary can either directly attack the access control system
or violate the monitoring system.
The access control system of FaaS is mainly based on the
communication protocol previously presented. Therefore, to
model the attacker, we consider the well-known Honest-But-
Curious [13] adversary model. Indeed, an attacker participates
in the protocol and behaves correctly. But, he can intercept,
send (resp., receive) any message to (resp., from) the protocols
to which it participates. Additionally, an attacker can have the
capabilities to violate the integrity of the Infrastructural Tenant
where the PDP is located. Specifically, it can subvert the PDP
evaluation process to return a different decision with respect
to the semantics of the policy currently in force.
Based on these described attack capabilities, we list the
potential threats for federated cloud access control systems.
T1 Compromised communication channel: access requests
and decisions exchanged between the access control
components can be intercepted and modified.
T2 Compromised Policy Evaluation: the PDP evaluation pro-
cess is violated that, e.g., it always returns a specific
According to the access control protocol in Figure 1, threat
T1 refers to the violation of the communication channels
allowing the interactions of steps 2 and 6. For the sake of
presentation, we assume that the intra-tenant communications
between PEP and PDP, i.e. steps 3 and 5, cannot be com-
promised. (This assumption is feasible in the FaaS context,
because the communication within the Infrastructural Tenant
relies on secured VPN tunnels.) Instead, the threat T2 refers to
the PDP evaluation process that generates the access decision
input of step 5.
The latter threat assumes that only the evaluation engine
can be violated, while the evaluated policies cannot be. This
simplifying assumption follows from the FaaS storage means
for access control policies: their integrity in ensured by-
design via a blockchain-based infrastructure (see [3] for further
details). It is also worth noticing that we have only considered
threats on the integrity of the PDP for the sake of presentation.
Threats on other components, e.g. the PIP, can be easily
subsumed under the PDP ones.
The runtime monitoring system is thus in charge of miti-
gating these risks. However, the monitoring system itself can
be prone to attacks that could jeopardise the whole cloud
federation. As the monitoring system does not rely on complex
protocols, an attacker may directly focus on the monitoring
architecture to compromise evidences or to affect service
availability. Therefore, we have the following threats.
T3 Compromised logging system: the monitoring system that
stores logs can be compromised, e.g., an access log is
removed or forged.
T4 Denial-of-Service: the architecture can be the object of a
Denial-of-Service attack that prevents the availability of
the monitoring service.
Addressing the latter threats will then ensure that the
monitoring service is reliable and available.
In this section, we introduce Decentralised Runtime Access
Monitoring System (DRAMS), the runtime monitoring for
cloud federation access control systems. The proposed system
rests on a smart-contract blockchain to store logs and perform
monitoring checks on them. Additionally, DRAMS is equipped
with a formally-grounded policy analyser that permits evalu-
ating whether an access decision is correct according to the
semantics of the policies currently in force in the system.
In the following, we first present the architectural compo-
nents of DRAMS (Section IV-A), then the pursued monitoring
protocol (Section IV-B) and the monitoring checks mitigating
the reported threats (Section IV-C).
A. Architecture
DRAMS is a decentralised monitoring system formed by
the following architectural components
Probing agents: they are responsible for intercepting and
forwarding data to create access logs.
Smart-contract blockchain: it is the smart-contract
blockchain system storing and comparing logs gathered
by probing agents.
Logging Interface: it is the DApp exposing the endpoints
to the probing agents to store intercepted data and to
manage events generated by the smar-contracts.
Analyser: it checks the correctness of the access decisions
calculated for the intercepted requests, with respect to the
policies currently in force in the system.
Indeed, the key element of the system is the blockchain
infrastructure: it is connected via the Logging Interface to all
the other components. The agents are distributed on the mon-
itored components of the access control system. According to
the considered threats, probes are placed on top of PDP and
PEP components.
Besides offering endpoints to access the blockchain, the
Logging Interface also provides symmetric encryption and
decryption functions, which are exploited by the other compo-
nents to store/retrieve encrypted data in/from smart-contracts.
Indeed, as data stored on a blockchain are visible to all users,
encryption is used to protect the data confidentiality and, at the
same time, to maintain plain data to use as inputs to semantic
checks on the system.
The Analyser is a standalone entity that dynamically con-
sumes and evaluates the gathered logs to ensure the correct
enforcement of access decisions. On the base of a logical
representation of the access control policies evaluated by the
PDP, the Analyser checks if for a given request the calculated
response is the expected one. This check has to be specialised
according to the access control policies used by the monitored
system, i.e. XACML.
To this aim, there are available in the literature a few full-
fledged analysis frameworks for XACML [14], [15], [16].
Differently from others, the framework in [16] enjoys the
benefits of using formal method techniques to model and
analyse XACML policies. The pursued approach rests on
FACPL, a formal language to represent XACML, and on its
translation procedure to Satisfiability Modulo Theory (SMT)
constraints [17]. Therefore, the Analyser translates the policies
currently in force to SMT constraints and evaluates their
satisfiability according to monitored requests and responses.
Further details are reported in the following sections.
Figure 2 presents the DRAMS architecture deployed on top
of the FaaS access control system of Figure 1. Specifically,
there is an agent for each tenant where the monitored access
control components (i.e., PDP and PEP) are placed. To enable
the storing of logs in the blockchain, a Logging Interface is
placed in each tenant. The Analyser is logically placed within
the Infrastructural Tenant, but it is deployed within a different
cloud section (i.e., a set of computing resources belonging
to cloud) with respect to the access control components. The
Analyser relies on a Logging Interface to gather and analyse
the access logs.
B. Monitoring Protocol
The runtime monitoring of DRAMS transparently intervenes
in the access control protocol of FaaS. Specifically, with
respect to Figure 1, the system monitors access requests
and responses exchanged during steps 2 and 6. Due to the
assumption of secure intra-communications, we assume that
step 2 directly occurs between the PEP of Tenant 2 and
the PDP; similarly, step 6 occurs between the PDP and the
PEP of Tenant 1. Hence, we abstract from the PEP of the
Infrastructural Tenant; anyway its violation is subsumed by
that of the PDP.
As a matter of notation, we use req (resp., res) to range
over requests (resp., responses) and the subscript pep (resp.,
pdp) to denote that the request/response is sent/received by
PEP (resp., PDP). For instance, respdp refers to the response
generated by the PDP.
The monitoring protocol is reported in Figure 3. To ease the
presentation, we only report the monitoring steps, which are
triggered by both the sending and receiving of the monitored
interactions (recall, steps 5 and 6 of Figure 1). Therefore,
the single authorisation of an access request generates four
monitoring activities.
We comment the steps of Figure 3 in the following.
When a triggering communication activity occurs (step 1),
the corresponding probing agent intercepts the communication
and creates an initial access log (step 2). This log is defined
by the following tuple
ac agent ,hreqId,type,text i
where reqId is the identifier of the monitored re-
quest (or its associated response), type is one among
{reqpdp,reqpep,respdp,respep}, and text corresponds to the
plain text of the intercepted XACML request (or response).
Figure 2: DRAMS architecture deployed on the access control system of a FaaS cloud federation (where ’Section i’ stands for
a set of computing resources belonging to a cloud ‘i’, while LI stands for Logging Interface)
Figure 3: Monitoring Protocol
The generated log ac agent is then sent to the Logging
Interface (step 3). The latter adds a timestamp and performs
the hasing and encryption of the received plain text (step 4).
The resulting access log, ready to be stored on the blockchain,
is thus defined by the following tuple
ac LI ,hreqId,type,n,hash,{text}Ki
where nis the timestamp, hash is the hash value generated by
applying the SHA-256 hashing function to text, and {text}K
is the encrypted text. It is worth noticing that text is stored
in the form of both hash and encrypted data to enable both
on-chain monitoring checks (i.e., the smart-contract checks)
and off-chain checks on the access control policy semantics
(i.e., Analyser checks).
The access log tuples are then stored on the blockchain
smart-contract (step 5). Specifically, the smart-contract groups
the four logs generated by an access request according to its
identifier reqId3. The access control logs maintained by the
smart-contract are thus as follows
ac ,hreqId pdpReq :ac LI1pepReq :ac LI2
pdpRes :ac LI3pepRes :ac LI4i
where tuple fields are named according to the type of ac LIi.
When all the four access logs ac LIiare stored, the smart-
contract checks the hashes (step 6) and, if a violation has
been detected, an alert is generated (step 7). Similarly, by
exploiting the event mechanism of the blockchain, the smart-
contract informs the Analyser about a new access log (step
8). In its own turn, the Analyser checks the correctness of the
calculated response (step 9) and possibly generates a security
alert (step 10). Therefore, the monitoring check at step 6 deals
with threat T1, while that at step 9 deals with threat T2. Both
checks are defined in the next section.
Finally, notice that we address only two interactions for
the sake of presentation, additional flows comprising multiple
entities (e.g., the interactions intra-tenant with the PIP) could
be monitored similarly.
C. Monitoring Checks
In the following, we describe the checks performed during
the monitoring protocol to address the considered threats.
1) T1 - Compromised Communication Channel: Relatively
to threat T1, the blockchain smart-contract performs the com-
parison check defined by Algorithm 1. Specifically, given in
input a smart-contract monitoring tuple ac, it checks if the
sensed PDP and PEP requests correspond. To this aim, it
accesses the tuples ac LIivia the corresponding field label,
e.g. pdpReq to retrieve ac LI1. Then, it retrieves via the
auxiliary function getHash() the corresponding hash value and
compares them each other. If the hashes do not correspond,
a violation of the communication channel has occurred and a
security alert is raised.
3Request identifiers are uniquely generated by-design by the access control
Algorithm 1 Access Logs Comparison Algorithm
Input: a smart-contract logging tuple ac
Output: raise an alert if a discrepancy is found;
1: if ac.pdpReq.getH ash() != ac.pepReq.getH ash() then
2: raise an alert
3: end if
4: if ac.pdpRes.getH ash() != ac.pepRes.getH ash() then
5: raise an alert
6: end if
7: return
2) T2 - Compromised Policy Evaluation: Relatively to
threat T2, the Analyser checks if the responses of an access
log tuple ac are semantically correct with respect to the given
request and the policy in force. To this aim, the SMT-based
policy representation is exploited.
Given pthe policy currently in force4, its SMT-based
representation corresponds to a 4-tuples of SMT constraints,
one for each possible XACML decision (see Section II-A).
The tuple is thus defined as follows
hpermit :cpdeny :cd
not-applicable :cnindeterminate :cii
where cis an SMT constraint. As formally proved in [16],
these constraints ensure that the corresponding FACPL (and,
hence, XACML) policy evaluates an request to a certain
decision dec if and only if the constraint ccorresponding to
dec is satisfiable with respect to the request.
Therefore, once the Analyser receives the sensed request
req and its response res, it first translates req into a set of
SMT assertions, say creq, modelling the attributes forming
the requests. Then, it chooses the SMT policy constraint
corresponding the access decision dec reported in res. Being
the latter constraint cdec, the Analyser checks the satisfiability
of the following SMT assertion
cdec creq
If the assertion is satisfiable, the access decision calculated
by the PDP is correct, hence the PDP has not been violated.
Otherwise, a security alert is raised.
To testify the effectiveness of DRAMS, we have imple-
mented an early prototype of all its components and deployed
them on a simplified cloud federation scenario.
More specifically, the considered federation consists of two
tenants, T1and T2:T1offers three federated services S1,
S2and S3;T2plays the role of the infrastructure tenant.
Consequently, the access control system consists of two PEPs,
one for each tenant, and of a PDP and PRP in tenant T2. The
4Notably, due to the root-based structure of the XACML evaluation process,
we can always assume that only a single policy is in force at a moment. For
the cognitive, a PDP is compliant with XACML only if it features a top-level
combining algorithm composing the available policies into a single policy set.
Table I: Machine Configurations for tenant simulation (graph-
ics card details reported due to the GUI-based PoW algorithm)
Tenant Configuration
Tenant 1 Intel Core i7 Processor i7-4790 3.60GHz,
Quad Core with 8MB Cache, 32GB
DDR3 Memory, AMD Radeon R390 8GB
PCIe Graphics card, 500GB Serial ATA
Hard Drive
Tenant 2 Intel Core i7 Processor i7-4790 3.60GHz,
Quad Core with 8MB Cache, 32GB
DDR3 Memory, AMD Radeon R7 240
2GB PCI Express graphics card, 500GB
Serial ATA Hard Drive
DRAMS components are deployed as in Figure 2: a probing
agent and a LI in each tenant, the Analyser in tenant T2.
On top of this setting, we have then conducted several
experiments to assess the feasibility of deploying DRAMS on
an Ethereum blockchain. The hardware configuration of the
two machines simulating the tenants is reported in Table I.
In the following, we first report the implementation details
(Section V-A), then further information on the considered
test-case (Section V-B), and finally the experiment results
(Section V-C).
A. Implementation Details
First of all, to implement DRAMS, we need a XACML
implementation of PDP and PEP components, thus to regulate
accesses to the considered services. To this aim, we have used
WSO2 Balana [18] to implement the PDP (and its PRP) at
T2, while the PEPs, as well as the three shared services, are
implemented by using the Go programming language [19].
Upon this access control infrastructure, we can thus im-
plement the components of DRAMS. The probing agents
are implemented still by using Go, while the smart-contract
blockchain and the Logging Interface relies on the Ethereum
toolset. More specifically, we have created a private Ethereum
network formed by two nodes, one for each tenant, that
also act as miners, i.e. they do PoW. Instead, the Logging
Interface is implemented by means of Node.js [20], a server-
side JavaScript platform, and Ethereum web3.js, the adapter
to interact with blockchain smart contracts via a web server.
To perform the monitoring checks, Algorithm 1 has been
implemented in terms of a smart-contract written in Solidity,
i.e. a programming language for Ethereum. Listing 1 reports
the main excerpt of the smart-contract code. The contract
represents ac LI logs, i.e. the single log produced by the
Logging Interface, by means of the accessLog data structure;
the 4-tuples ac corresponds instead to the combinedLogs
structure. It offers also two functions, addLog and checkLog, to
store and control access log, respectively. In particular, addLog
takes in input a ac LI log and stores it according to its request
identifier reqId and type type. Instead, checkLog controls, for
a given a request identifier reqId, whether there has been a
violation during the request authorisation. If so, a security alert
Listing 1: Access Control Monitoring
contract Monitor{
struct accessLog {
string requestId;//unique identifier of the Log
string encLog; //encrypted access Log
string logHash; //Hash of the access log
string logType; //Type of the access log
string timeStamp;//Timestamp of the log
boolean fullLog;
struct combinedLogs {
string requestId;
accessLog pepReq;
accessLog pdpReq;
accessLog pdpDec;
accessLog pepDec;
boolean fullLog;
mapping (string => combinedLogs) accLogs;
function addLog(...) public returns (string){
accessLog memory tempLog;//create record
...//create/update record
if (accLogs[reqId].fullLog){
//generate log <<EVENT>> for Analyser
return "Success in storing!";
function checkLog(string reqId) private returns (string){
if (accLogs[reqId].pepReq.logHash != accLogs[reqId].
//generate security alert <<EVENT>>
if (accLogs[reqId].pdpDec.logHash != accLogs[reqId].
//generate security alert <<EVENT>>
return "No alert!";
is propagated via the event mechanism. Similarly, when a ac
contains all the forming logs, a event is propagated to the
Analyser to control the correctness of the calculated response.
Finally, the Analyser is implemented as a Java applica-
tion interacting with the local Logging Interface via JSON-
based invocations. The Analyser features the Java toolchain
of FACPL [3], that in own turn exploits the Xtext parsing
libraries [21] and the SMT solver Z3 [22].
B. Test-Case
To simulate user interactions in the federation scenario, we
created two different users, named Alice and Bob, exposing
different sets of attributes. On the base of these attributes, we
created an access control policy stored in the PRP. Such policy
assigns different access rights to the users for the access to the
available services. Namely, Alice is allowed to access only S1,
while Bob is allowed to access both S1and S2. Instead, none
of the users is allowed to access S3.
Similarly, to simulate a suite of attacks, we assume that
a communication, randomly chosen, for each user is violated,
thus to represent threat T1. Similarly, the PDP is instrumented
to randomly subvert the decision calculated by the PDP before
returning it to the PEP, thus to represent threat T2. As a matter
of fact, these threats are intended to allow Alice and Bob to
both access the forbidden service S3.
To dynamically modify the user load to which DRAMS
is exposed we have used JMeter [23], a widely used open-
source application to load functional behaviours and measure
their performance on web-based applications. Indeed, JMeter
has been configured to define, for each user, the following
functional behaviour: first submitting an access request to S1,
then to S2and finally to S3. It follows that each JMeter
iteration, for each user, generates three access requests and
three corresponding access responses to be stored in the smart
contract. This functional behaviour has been then simulated by
JMeter to an increasing number of active users (i.e., 5, 10, 25,
50, 100) within a period of 3 minutes, 5 minutes, 10 minutes,
20 minutes and 30 minutes, respectively.
C. Feasibility Experiment
The test-case just identified has been applied to the consid-
ered federation scenario to inspect the following aspects
a) Resiliency: the ability of detecting an access control viola-
tions concerning both threats T1 and T2.
b) Cost: the Ether needed for storing the gathered logs in a
(public) Ethereum blockchain.
c) Latency: the time taken to store a log in a block in the
The analysis results of these aspects assess the feasibility
of deploying DRAMS upon Ethereum.
a) Resiliency: The resiliency test has evaluated if the
architecture can detect any discrepancy under a considerable
amount of usage load. As described in Section V-A, each
interaction flow of a user simulates one attack scenario. Hence,
the number of simulated attacks corresponds to the number of
users simulated in a flow, e.g. with 5 simulated users we expect
to have 5 attacks, for 50 users we expect to have 50 attacks and
so on. To this aim, we have counted the number of generated
alerts. Our evaluation suggests that the algorithm has been able
to detect all simulated attacks under the described usage load.
b) Cost: Here, the associated cost corresponds to the
total cost, in Ether, for storing access requests and other related
information for each user. We compute the cost of executing
an iteration while increasing the number of users. Before and
after each iteration, we measure the current balance of the
Ethereum accounts associated with tenants T1and T2. The
cost is then calculated by adding the subtracted value (the
existing balance minus the current balance) for each account.
As reported in Figure 4, the associated cost linearly increases
with the number of users. The cost goes from around 0.38
ETH for 1 user to around 38 ETH for 100 users.
To compare the associated cost with the size, we have also
calculated the size of the stored logs. In an average, the size of
stored access logs for a user is around 25KB which increases
linearly to around 2500KB for 100 users. Therefore, it costs
around 0.0152 (0.38/25 = 0.0152 ETH/KB) ETH to store 1
KB of data in Ethereum at the time of this experiment had
been carried out which is currently equivalent to 0.145 USD.
c) Latency: The latency has been evaluated by calcu-
lating the time it took to store a particular tuple in the
blockchain. The tuple itself is stored via the smart-contract
Figure 4: Number of users vs Cost
which is invoked by a transaction embedded inside a block.
Since there is a latency involved in creating and validating a
block, it is useful to examine the associated latency for storing
tuples under a considerable amount of usage load. The average
latency (in seconds) for each iteration group is presented in
Figure 5. The important observation to make from Figure 5
is that the latency increases considerably (from 56.3s for 1
user to 6572.21s for 100 users) as more users are emulated
to submit access requests. This is because access requests
generate tuples which are then stored using the corresponding
Ethereum client. The Ethereum client buffers the request in
a transaction pool which are then released to the Peer-2-Peer
network for broadcasting among other peers. The rate at which
the tenant releases the buffered transaction is lower than the
rate the tuples are generated when many users simultaneously
submit access requests. Furthermore, the gasLimit value of
0x4c4b40 used to initialise the private blockchain allowed only
one transaction to be included in each block even though there
are numerous transactions in the pool. These two particular
behaviours attribute to the increase in the latency.
Figure 5: Number of users vs Latency
In this section, we explore different aspects of DRAMS. We
first analyse the security of DRAMS (Section VI-A) and then
discuss some of the challenges in deploying the system on a
public blockchain (Section VI-B).
A. Security Considerations
Here, we comment on the security guarantees of DRAMS.
Integrity. DRAMS ensures the integrity of both the algorithm
to detect discrepancies between access control decision taken
and enforced and of the logs (i.e., threat T3). The integrity of
the algorithm for checking discrepancies is ensured because
the algorithm has been implemented as a smart contract that
is deployed and executed on the blockchain and therefore is
immutable. The integrity of the logs is also preserved for the
same reason. An attacker would need to subvert the security
of blockchain consensus protocol in order to be able to modify
the smart contract and the associated logs.
Availability. DRMAS is fully decentralised exposing no single
point of failure. If a single logging agent or the corresponding
Logging Interface is under a Denial-of-Service attack (i.e.,
threat T4) or is compromised in a tenant allowing an attacker
to alter an access request/response, the other components
in other tenants remain functional. DRAMS, leveraging the
blockchain, also provides a strong guarantee of availability of
the stored logs as well as the smart-contract.
Confidentiality. Everything that is stored on the blockchain is
public. However, logs may contain sensitive information about
the access control policies enforced that could be used by
an attacker to gain access on a federated resource. Therefore,
DRAMS protects the confidentiality of the logs by storing
them encrypted with AES 256.
Other security concerns. Finally, we report a few secu-
rity considerations on the Analyser and its exploitation. The
FACPL-based framework ensures compelling properties on
the analysis on XACML policies, hence on detecting PDP
violations. Differently from other analysis framework (e.g.,
those in [14], [15], [16]), it ensures, experimental proves on
its semantic compliance with XACML; the proves have been
defined by using the XACML implementation Balana and the
validation tool X-CREATE [24]. On the other hand, it ensures
that the FACPL translation procedure to SMT constraints is
formally proved correct according to the FACPL semantics.
Furthermore, notice that to ensure the correctness of the
Analyser check, it is crucial to protect the integrity of the
SMT representation of the policy in force. To this aim, we can
exploit an hardware trusted platform to opportunely protect the
integrity of the SMT constraints.
B. Practicalities
Even though the Ethereum-based DRAMS offers com-
pelling properties, there are a few practicalities to take into
account for adopting such a novel system. We explore them
in what follows.
System Integrity. The first practicality concerns the integrity
of the monitoring system. In fact, even though the smart-
contract of DRAMS is immutable, the integrity of the other
components, e.g. the Logging Interface, cannot be guaranteed
by-design, because they are deployed off-chain. Similarly, as
all the Logging Interface instances share a symmetric key
K, its management is of paramount importance. To mitigate
both difficulties, we can introduce a trusted hardware platform
(e.g., Trusted Platform Module) within the system. On the
one hand, it can be leveraged to store the symmetric keys
by increasing the overall system security. On the other hand,
this platform can be utilised to guarantee the integrity of the
off-chain components.
Log Size. The key parameter highly affecting the monitoring
system is the size of the log. In fact, the bigger the size is, the
higher is the time (and the cost) to spend to store the log on the
blockchain. To mitigate this practicality, different proposals are
available. By relying on a private blockchain, where all PoW
parameters can be dynamically tuned according to the needs,
the latency can be maintained under control. However, due
to the limited size of the network and a possibly lightweight
PoW, this solution does not ensure strong integrity guarantees.
Alternatively, a hybrid approach combining classical database
with blockchain system should offer an adequate flexibility
to find a tradeoff between latency, integrity guarantees and,
in case of public chain, cost. A preliminary design to such a
system is presented in [25].
Private vs. Public. Our early prototype of DRAMS is based on
a private Ethereum blockchain where, as just mentioned, we
can tune PoW parameters freely. Instead, to enjoy the strong
integrity guarantees of public blockchain, we must deal with
higher latency and, most of all, with the cost of the consumed
Ether. Besides the cost, which is however an hopeless obstacle,
the latency of public chains is currently around 14s per new
block. Hence, DRAMS cannot be deployed upon a public
chain, unless the number of interactions to be monitored are
not frequent.
This section discusses the related work in the areas of
system monitoring tools (Section VII-A), decentralised access
control (Section VII-B) and blockchain-based access control
(Section VII-C).
A. Monitoring Tools
There has been a long history of utilising monitoring
tools for observing resource utilisation and tracking system
performance, which predate well beyond the cloud paradigm.
With the advent of distributed technologies such as cloud
computing, new demand has emerged that requires monitoring
tools to function in a seamless-distributed manner and to track
new types of system properties. To satisfy these requirements,
existing and new monitoring tools have been adopted and
proposed for such distributed cloud environments.
A number of studies investigate the desirable properties
that a cloud monitoring tool should possess [26], [27], [28].
The identified properties include scalability, adaptability, com-
prehensiveness, extensibility, resiliency, reliability, availability,
accuracy, usability, affordability and achievablity. Then, dif-
ferent tools are analysed against these properties to identify
which tool satisfies which properties. However, the analysis
in these studies consider limited number of security properties
(i.e., reliability and availability), and most of the tools lack
in satisfying these security properties which undermine their
usage to guarantee security assurance.
Most existing monitoring tools, such as Zabbix [29] and
Nagios [30], maintain a client-server architecture where a
client is a monitoring agent deployed to monitor specific
resources in a specific layer and communicates with the server
to transfer monitoring data. The server is responsible to collect
and store monitoring data from the deployed agents, analyse
such data, visualise them using a graphical user interface and
raise an alert if it identifies a fault. Being based on the client-
server architecture, these tools suffer from the most well-
known weakness of the client-server architecture: the single
point of failure. Indeed, these tools cease to function once the
respective server is taken down by an attacker.
Another drawback of these tools is that they do not support
any external access control framework such as XACML and
thus cannot support discrepancy detection over logs created in
different nodes in cloud environment. The solution proposed
in this paper, instead, focuses on a decentralised monitoring
architecture that supports XACML and allows heterogeneous
nodes to have different access control policies.
B. Decentralised Access Control
There have been several consensus maintaining approaches
to dealing with consensus agreement among different (possibly
colluding) entities in different tenants.
The Paxos-style protocol [31] focuses on reaching an agree-
ment with respect to the state of an access request/response
among nodes who may not maintain the same value, due to
some error conditions. For instance, a node may have failed
and hence lost the state value. The consensus is achieved using
a concept of majority and is suitable for scenarios where fault-
tolerance is required. However, in a security-critical system,
a discrepancy regarding an access request/response among
participating entities indicates a high possibility that some
entities act maliciously, or collude with each other, or the
respective access request/response reaching these entities has
been altered, possibly by an attacker.
Sundareswaran et al. [32] present a decentralised approach
for information accountability in the cloud environment utilis-
ing the programmable capability of Java Archive (JAR) files.
Their approach allows the owner of a data to define access
as well as usage control policy and attach the policy with
the corresponding data within a JAR file in order to ensure
accountability, securely log each data access incidence and
enforce access/usage control policy in every single domain
the data is stored within a cloud environment. This approach
is quite interesting, particularly how the security of access logs
have been ensured. However, their approach is unsuitable for
any XACML-based external access control framework
C. Blockchain-Based Access Control
There are interesting proposals that connect the blockchain
technology with access control systems. Enigma [33], for
instance, has proposed a decentralised blockchain-based plat-
form for managing data storing and computation among
parties. In that platform, the blockchain is utilised as the
controller of access control and serves as a tamper-free event
logs. The difference between this approach with our solution
is that we detail the security threats in the context of cloud
federations and integrate important algorithms for detecting
policy violations of access control.
In a similar vein, the survey on the principles and applica-
tions of blockchain technology [34] envisions the potential of
exploiting blockchain as a promising way to manage access
control but restricts the scenario to role based access control
frameworks. Our solution is more general that it can be
applied to other access control frameworks, and provides a
concrete proposal consisting of a blockchain-based monitoring
infrastructure and deployment strategies for cloud federations.
In this paper, we presented DRAMS, a blockchain-based
decentralised monitoring infrastructure for a distributed access
control system. The main motivation of DRAMS is to deploy
a decentralised architecture which can detect policy violations
in a distributed access control system under the assumption
of a well-defined threat model. Being decentralised, DRAMS
exhibits no single point of failure. In addition, its blockchain-
based architecture provides a strong guarantee of integrity
and availability for the stored logs. We have deployed the
architecture we propose for DRAMS in a simulated setting in
which we use a private Ethereum blockchain. Our evaluation
suggests that the proposed architecture is resilient against
the threats of the specified threat model. Considering the
associated cost for deploying such a system, we believe that
our proposed system will be most suitably deployed using a
private blockchain system.
This work can be extended in different directions. Firstly,
we are interested in studying the impact of deploying DR
AMS in a public Ethereum blockchain. In recent times, the
Hyperledger project has gained considerable attention in the
blockchain community [35]. Hyperledger is an open-source
blockchain platform that can accommodate different sets of
block-validating algorithms which might pave out the way for
leveraging blockchain technologies without using any crypto-
currency. This can address one of the biggest challenges for
any large-scale adoption of DRAMS which is the associated
cost. It will be interesting to investigate how Hyperledger can
be exploited for this purpose.
The ultimate idea is to integrate DRAMS in a federated
cloud setting such as SUNFISH, which is designed to be used
by public sector structures consisting of thousands and thou-
sands of users. The flexibility and strong security guarantees
provided by DRAMS drive the desire for such an integration.
However, the latency and, especially, the associated cost might
be the key motivating factors for the successful deployment of
DRAMS in such a cloud setting. The work presented in this
paper aims to lay out the foundation for such a vision.
This work has been supported by the EU H2020 Programme
under the SUNFISH project, grant agreement N. 644666.
[1] A. Celesti, F. Tusa, M. Villari, and A. Puliafito, “How to enhance cloud
architectures to enable cross-federation,” in CLOUD. IEEE, 2010, pp.
[2] T. Kurze, M. Klems, D. Bermbach, A. Lenk, S. Tai, and M. Kunze,
“Cloud Federation,” in Cloud Computing, GRIDs, and Virtualization,
2011, pp. 32–38.
[3] F. P. Schiavo, V. Sassone, L. Nicoletti, and A. Margheri (Eds.), “Faas:
Federation-as-a-service,” CoRR, vol. abs/1612.03937, 2016.
[4] B. Suzic, A. Reiter, F. Reimair, D. Venturi, and B. Kubo, “Secure data
sharing and processing in heterogeneous clouds,” Procedia Computer
Science, vol. 68, pp. 116–126, 2015.
[5] “SecUre iNFormatIon SHaring in federated heterogeneous private clouds
(SUNFISH),” Accessed on 16 January, 2017, http://www.sunfishproject.
[6] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008,
available at
[7] “Ethereum,” Accessed on 16 January, 2017,
[8] Bill Parducci,Hal Lockhart, “eXtensible Access Control Markup Lan-
guage (XACML) Version 3.0,” 22 January, 2013, http://docs.oasis- open.
[9] V. C. Hu, D. R. Kuhn, and D. F. Ferraiolo, “Attribute-based access
control,” IEEE Computer, vol. 48, no. 2, pp. 85–88, 2015.
[10] X. Jin, R. Krishnan, and R. S. Sandhu, “A unified attribute-based access
control model covering dac, MAC and RBAC,” in DBSec. Springer,
2012, pp. 41–55.
[11] D. F. Ferraiolo and D. R. Kuhn, “Role-based access control,” in NIST-
NCSC National Computer Security Conference, 1992, pp. 554–563.
[12] B. Suzic, B. Pr¨
unster, D. Ziegler, A. Marsalek, and A. Reiter, “Balancing
Utility and Security: Securing Cloud Federations of Public Entities,” in
C&TC, ser. LNCS, vol. 10033. Springer, 2016, pp. 943–961.
[13] A. Paverd, A. Martin, and I. Brown, “Modelling and automatically
analysing privacy properties for honest-but-curious adversaries,” Tech.
Rep., 2014.[Online]. Available: https://www. cs. ox. ac. uk/people/an-
drew. paverd/casper/casper-privacy-report. pdf, Tech. Rep.
[14] K. Arkoudas, R. Chadha, and C. J. Chiang, “Sophisticated access control
via SMT and logical frameworks,ACM Trans. Inf. Syst. Secur., vol. 16,
no. 4, p. 17, 2014.
[15] F. Turkmen, J. den Hartog, S. Ranise, and N. Zannone, “Analysis of
XACML policies with SMT,” in POST, ser. LNCS, vol. 9036. Springer,
2015, pp. 115–134.
[16] A. Margheri, M. Masi, R. Pugliese, and F. Tiezzi, “A rigorous framework
for specification, analysis and enforcement of access control policies,”
CoRR, vol. abs/1612.09339, 2016.
[17] L. M. de Moura and N. Bjørner, “Satisfiability modulo theories: intro-
duction and applications,” Commun. ACM, vol. 54, no. 9, pp. 69–77,
[18] WSO2, “Balana: Open source XACML implementation,” 2015, https:
[19] “The Go Programing Language,” Accessed on 1 November, 2016, https:
[20] “Node.js,” Accessed on 16 January, 2017,
[21] Xtext, Language Development Made Easy,
[22] L. M. de Moura and N. Bjørner, “Z3: an efficient SMT solver,” in
TACAS, ser. LNCS, vol. 4963. Springer, 2008, pp. 337–340.
[23] “Apache JMeter,” Accessed on 16 January, 2017, http://jmeter.apache.
[24] A. Bertolino, S. Daoudagh, F. Lonetti, and E. Marchetti, “The X-
CREATE Framework - A Comparison of XACML Policy Testing
Strategies,” in WEBIST. SciTePress, 2012, pp. 155–160.
[25] E. Gaetani, L. Aniello, R. Baldoni, F. Lombardi, A. Margheri, and
V. Sassone, “Blockchain-based database to ensure data integrity in cloud
computing environments,” in ITA-SEC., To Appear.
[26] K. Fatema, V. C. Emeakaroha, P. D. Healy, J. P. Morrison, and T. Lynn,
“A survey of cloud monitoring tools: Taxonomy, capabilities and objec-
tives,Journal of Parallel and Distributed Computing, vol. 74, no. 10,
pp. 2918–2933, 2014.
[27] G. Aceto, A. Botta, W. De Donato, and A. Pescap`
e, “Cloud monitoring:
A survey,” Computer Networks, vol. 57, no. 9, pp. 2093–2115, 2013.
[28] J. S. Ward and A. Barker, “Observing the clouds: a survey and taxonomy
of cloud monitoring,” Journal of Cloud Computing, vol. 3, no. 1, p. 1,
[29] R. Olups, “Zabbix 1.8 network monitoring,” 2010.
[30] W. Barth, “System and network monitoring,” 2008.
[31] L. Lamport et al., “Paxos made simple,” ACM Sigact News, vol. 32,
no. 4, pp. 18–25, 2001.
[32] S. Sundareswaran, A. Squicciarini, and D. Lin, “Ensuring distributed
accountability for data sharing in the cloud,” IEEE Transactions on
Dependable and Secure Computing, vol. 9, no. 4, pp. 556–568, 2012.
[33] G. Zyskind, O. Nathan, and A. Pentland, “Enigma: Decentralized
computation platform with guaranteed privacy,” CoRR, 2015.
[34] M. Pilkington, “Blockchain technology: Principles and applications,”
HAL, Tech. Rep., 2016.
[35] “Hyperledger,” Accessed on 1 November, 2016, https:
... Nevertheless, there are four different blockchains to perform access control, which are cost-expensively maintained with. To consider distributed access control in cloud services [26], a blockchain-based decentralized runtime access monitoring system (DRAMS) is introduced for federated cloud cooperation. As a result, it provides data privacy and data secure sharing. ...
Full-text available
Microgrid is a self-sufficient grid system that covers one or more kinds of distributed energy, where a variety of terminal devices collect, transmit and store electricity data based on fog-based network infrastructure. Due to security and privacy concerns, efficient and secure access control over terminal devices in microgrid is the primary way to prevent unauthorized access and data breach. Therefore, a number of solutions of device management are proposed. However, they are usually prone to single point of failure, decision-centralized, over-manual intervened. To address the problem, we introduce a blockchain-based fast and dynamic access control (FDAC) system for device management in fog-assisted microgrid. In particular, we adopt an attribute-based access control formula to model a flexible, dynamic and fast fine-grained access control system. FDAC deploys four smart contracts that dynamically manages devices, which includes user authentication, subject/object attributes, access policy, decision-making and credit assessment of user behavior. In addition, FDAC employs a Cuckoo filter to speed up policy search in smart contracts and proposes new credit verification algorithm to improve credit rewards and punishments. To clarify practical performance, we build a private blockchain platform to simulate FDAC. Compared to classic traversal approaches for policy search, FDAC maintains higher accuracy and lower time delay.
... Usually, the size of data stored in a single block is small to maintain security standards, however medical data such as imaging and other arrangements can be large in size, relational, and may have the desire to search. DRAMS has been introduced by Ferdous et al. [40] having a decentralized blockchain cognition scheme to ensure a control system having distributed access. The infrastructure possesses an aid to secure data; however, a lack of efficiency in data sharing remains a problem. ...
Full-text available
Healthcare professionals, patients, and other stakeholders have been storing medical prescriptions and other relevant reports electronically. These reports contain the personal information of the patients, which is sensitive data. Therefore, there exists a need to store these records in a decentralized model (using IPFS and Ethereum Decentralized Application) to provide data and identity protection. Many patients recurrently visit doctors and undergo treatments while receiving different prescriptions and reports. In case of an emergency, the doctors and attendants may need and benefit from the patients' medical history. However, they are unable to go through medical history and a wide range of previous reports and prescriptions due to time constraints. In this paper, we propose an AI-assisted blockchain-based framework in which the stored medical records (handwritten prescriptions, printed prescriptions, and printed reports) are stored and processed using various AI techniques like Optical Character Recognition (OCR) to form a single Patient Medical History Report. The report concisely presents only the crucial information for convenience and perusal, and is stored securely over a decentralized blockchain network for later use.
... This is true despite the existing varieties in which blockchain technology has been leveraged, which include far more applications than just cryptocurrency and smart contracts [35,51]. Some of these include: enhancing integrity and privacy of shared cyber security data [39]; replacing conventional trusted third parties to ensure fairness for peer-to-peer content delivery networks [23]; managing public key certificate and revocation status [37]; enhancing the trustworthiness of cryptographic digital signatures in the presence of compromised private signing keys [52,53]; facilitating data integrity and data management in IoT systems [22]; detecting violations of access control policies in cloud environments [16]; managing data provenance, accountabil- ...
We initiate the study on the problem of automated and robust Cyber Security Management (CSM). We exemplify the problem by investigating how CSM should respond to the discovery of cyber intelligence that identifies new attackers, victims, or defense capabilities. Given the complexity of CSM, we divide it into three classes, referred to as Network-centric (N-CSM), Tools-centric (T-CSM) and Application-centric (A-CSM). These lead to a range of functions for examining whether, and to what extent, a network has been compromised. Moreover, we propose to incorporate blockchain (via Hyperledger Fabric) to build a decentralized CSM system, dubbed B2CSM, that ensures the retrieval of valid invocation results for CSM purposes. We also integrate B2CSM with a decentralized storage network (DSN), instantiated by InterPlanetary File System (IPFS), to reduce on-chain storage costs without hindering its robustness. We present the design and implementation of the prototype B2CSM system. Experiments with real-world datasets show that the CSM solutions and system are effective and efficient.
... Tab. 2 identifies these challenges, their nature, and possible solutions. [21] Transparency issues related to TTPs Ethereum and white list policy [22] Forgery attacks S3FS and Ethereum [23] Tenant and service accounts Smart contract and quorum [24] Data privacy Demand response management, and public key infrastructure [25] Data traceability DataProv, ProvChain and CoPS [26] Integrity verification Two-layer blockchain network [28] Access control [29] Illegitimate access Enforcement of access policies Eavesdropping and confidentiality [30] Eavesdropping and alteration Proper integration and confidentiality mechanism Data Authentication [31] Unauthorized access Application of one-way hash function [ ...
Full-text available
The trend of cloud computing is accelerating along with emerging technologies such as utility computing, grid computing, and distributed computing. Cloud computing is showing remarkable potential to provide flexible, cost-effective, and powerful resources across the internet, and is a driving force in today's most prominent computing technologies. The cloud offers the means to remotely access and store data while virtual machines access data over a network resource. Furthermore, cloud computing plays a leading role in the fourth industrial revolution. Everyone uses the cloud daily life when accessing Dropbox, various Google services, and Microsoft Office 365. While there are many advantages in such an environment, security issues such as data privacy, data security, access control, cyber-attacks, and data availability, along with performance and reliability issues, exist. Efficient security and privacy measures should be implemented by cloud service providers to ensure the privacy, confidentiality, integrity, and availability of data services. However, cloud service providers have not been providing enough secure and reliable services to end users. Blockchain is a technology that is improving cloud computing. This revolutionary technology offers persuasive data integrity properties and is used to tackle security problems. This research presents a detailed analysis of privacy and security challenges in the cloud. We demonstrate the importance of security challenges in a case study in the context of smart campus security, which will encourage researchers to examine security issues in cloud computing in the future.
... Implementing access control usually requires three steps: identification, authentication, and authorization. 132 Ferdous et al 133 have introduced DRAMS, a blockchain-based framework for decentralized access control, but does not deal with efficient data sharing. Ancile, an Ethereum framework, 134 is designed to provide secure, interoperable, scalable, and efficient patient medical data access to address sensitive patient data's security and privacy concerns. ...
Full-text available
Blockchain Technology, the fundamental technology behind Bitcoin, has drawn considerable recognition ever since its origin. Its potential has gained significant interest in various applications, varying from the music industry, financial services, Internet-of-Things (IoT), smart grid, edge computing, cybersecurity, and the healthcare industry. However, the information is divided amongst several intermediaries involved with adverse impacts on data quality in the healthcare domain. In the near future, blockchain technology can reshape the way the healthcare industry works by providing personalized and reliable patient data management, reforming the traditional healthcare practices, secure mechanisms for data sharing, efficient pharmaceutical supply chain management, and drug traceability and many more. In this study, an extensive literature review has been provided that includes the different prospects of using blockchain technology in healthcare. The review investigates the work done to enable the amalgamation of IoT and Blockchain in the health ecosystem. Significant blockchain-based healthcare use cases such as data storage, data sharing, drug traceability, clinical trials, and remote patient monitoring are investigated. Further, the Internet of Things and blockchain technology-based SWOT (Strength, Weakness, Opportunity, and Threat) analysis and the challenges linked in the healthcare domain because of the enactment of IoT and blockchain technology are discussed to support advanced studies in this domain.
Full-text available
Blockchain has transitioned beyond the hype to reality, as evidenced by the amount of research it has attracted and by its commercial applications. One popular application of blockchain is in cybersecurity, which is the focus of this paper. Specifically, we performed a systematic literature review of blockchain use cases for cybersecurity, while focusing on articles published over the past decade. Based on our analysis of 111 articles, we developed a classification framework using the thematic analysis approach. This classification framework is designed to offer readers a comprehensive perspective of the potential of blockchain to enhance cybersecurity in different contexts. The findings have implications for research and practice.
Initially, blockchain technology was emerged for the enhancement of financial transactions, as it is independent of the need to have any third party to verify the transactions. Progressively, it has been slightly modified based on the different application-specific requirements such as data security and privacy. One of the emerging applications of blockchain is E-healthcare that concerns mainly about integrity, authenticity, and consistency of patients’ medical records. Due to the evolution of Internet of Things (IoT), a lot of healthcare data is being produced through the use of various devices like smart watches, smart sphygmomanometer, smart thermometer, etc. This imposes the need to concern about scalability along with interoperability. A novel architecture to handle the electronic medical records (EMR) of the patients by various medical entities is proposed. As large amounts of records are to be handled, the healthcare archives are kept in the cloud for streamlining the usage of information among diverse stakeholders. Also, there is a provision to enable the measures that handle security and privacy in the cloud architecture. Suitable public key cryptography and hashing methods are exploited to maintain the past transactions corresponding to the patients’ records. This preserves confidentiality, integrity, and availability. It also prevents the modification or falsification of data by unauthorized persons. Using blockchains, patients’ records can be added only at the end of the database, but they cannot be removed. New records are securely connected to the preceding record using cryptographic hashing. Special node called data validator is used to check the quality and authenticity of user-uploaded data, from which the records can be examined and patient health status reports are prepared. Again, encryption and digital signing are performed on the data to store it back to the blockchain. This proposed system ensures that no individual can modify or damage the verified records that are already stored. Our proposed novel architecture was tested against MIT-BIH Arrhythmia Database, and the stated functionality requirements are met.
Full-text available
As the basic building block of any information security system, identity and access management (IAM) solutions play vital role in enterprise's security programmes. Providing centric solutions for IAM is inefficient in terms of having single point of failure, high cost, duplication and complexity to the users. Recently, emerging the distributed ledger technology (DLT) has attracted significant scientific interests in research areas like identity management, authen-tication and access control processes. In these contexts, Blockchain can offer greater data and rule confidentiality and integrity, as well as increasing the availability of the system by removing the single point of failure in the procedure. In this paper, we provide a comprehensive overview of the IAM solutions based on their basic components including identity management, authentica-tion and access control. In the identity concept, we discuss about self-sovereign identity which enhances privacy and security of distributed digital identities by providing individual's consolidated digital identity and verified attributes for enabling them to utilize their ownership. To offer a clearer understanding of the state of the art, we propose taxonomy to categorize them based on their features. For the conclusion of the paper, we compare the existing methods based on proposed taxonomy. Also, considering the advantages and disadvantages of existing methods, we discussed about the possible future directions. 1 | INTRODUCTION As information systems have dramatically increased the number of their users, identity management (IdM), authentica-tion, and access control (AAC) have become critical factors in resource and information protection. The combination of these security solutions results in identity and access management (IAM) methods. The majority of existing IAM solutions are centralized which have become one of the most challenging security parts in the companies in order to protect user's privacy and have secure and compliant access to IT resources. As a brief explanation, the IAM framework connects multiple interdependent components, including an identities' database, a credential manager, an authentication server, a credential core, a resources database, a resource manager, an access policy engine, and a trust engine to provide information security. 1 The importance of IAM solutions can be projected in IdM and access control components. To provide user-centric services, organizations assemble huge amounts of personal information. The collected data are further utilized for profiling , prediction, and economic growth. In existing IdMs, the management of identities and Personally Identifiable Information (PII) is controlled by Central Authorities (CA), and the user has little or no control over their data sharing and privacy. Furthermore, the collection of PII makes the service providers primary target of attacks and results in
Full-text available
Access control systems are widely used means for the protection of computing systems. They are defined in terms of access control policies regulating the accesses to system resources. In this paper, we introduce a formally-defined, fully-implemented framework for specification, analysis and enforcement of attribute-based access control policies. The framework rests on FACPL, a language with a compact, yet expressive, syntax for specification of real-world access control policies and with a rigorously defined denotational semantics. The framework enables the automatic verification of properties regarding both the authorisations enforced by single policies and the relationships among multiple policies. Effectiveness and performance of the analysis rely on a semantic-preserving representation of FACPL policies in terms of SMT formulae and on the use of efficient SMT solvers. Our analysis approach explicitly addresses some crucial aspects of policy evaluation, as e.g. missing attributes, erroneous values and obligations, which are instead overlooked in other proposals. The framework is supported by Java-based tools, among which an Eclipse- based IDE offering a tailored development and analysis environment for FACPL policies and a Java library for policy enforcement. We illustrate the framework and its formal ingredients by means of an e-Health case study, while its effectiveness is assessed by means of performance stress tests and experiments on a well-established benchmark.
Full-text available
This document is the main high-level architecture specification of the SUNFISH cloud federation solution. Its main objective is to introduce the concept of Federation-as-a-Service (FaaS) and the SUNFISH platform. FaaS is the new and innovative cloud federation service proposed by the SUNFISH project. The document defines the functionalities of FaaS, its governance and precise objectives. With respect to these objectives, the document proposes the high-level architecture of the SUNFISH platform: the software architecture that permits realising a FaaS federation. More specifically, the document describes all the components forming the platform, the offered functionalities and their high-level interactions underlying the main FaaS functionalities. The document concludes by outlining the main implementation strategies towards the actual implementation of the proposed cloud federation solution.
Conference Paper
Full-text available
The eXtensible Access Control Markup Language (XACML) is an extensible and flexible XML language for the specification of access control policies. However, the richness and flexibility of the language (along with the verbose syntax of XML) come with a price: errors are easy to make and difficult to detect when policies grow in size. If these errors are not detected and rectified, they can result in serious data leakage and/or privacy violations leading to significant legal and financial consequences. To assist policy authors in the analysis of their policies, several policy analysis tools have been proposed based on different underlying formalisms. However, most of these tools either abstract away functions over non-Boolean domains (hence they cannot provide information about them) or produce very large encodings which hinder the performance. In this paper, we present a generic policy analysis framework that employs SMT as the underlying reasoning mechanism. The use of SMT does not only allow more fine-grained analysis of policies but also improves the performance. We demonstrate that a wide range of security properties proposed in the literature can be easily modeled within the framework. A prototype implementation and its evaluation are also provided.
Full-text available
The extensive cloud adoption among the European Public Sector Players empowered them to own and operate a range of cloud infrastructures. These deployments vary both in the size and capabilities, as well as in the range of employed technologies and processes. The public sector, however, lacks the necessary technology to enable effective, interoperable and secure integration of a multitude of its computing clouds and services. In this work we focus on the federation of private clouds and the approaches that enable secure data sharing and processing among the collaborating infrastructures and services of public entities. We investigate the aspects of access control, data and security policy languages, as well as cryptographic approaches that enable fine-grained security and data processing in semi-trusted environments. We identify the main challenges and frame the future work that serve as an enabler of interoperability among heterogeneous infrastructures and services. Our goal is to enable both security and legal conformance as well as to facilitate transparency, privacy and effectivity of private cloud federations for the public sector needs.
Blockchain is an immutable, encrypted, distributed ledger technology. While initially devised for and most commonly referenced with cryptocurrencies, there are an increasing number of applications outside finance, many of which are relevant to medical imaging. In this paper, the concepts and principles underlying the technology and applications relevant to medical imaging are discussed, in addition to potential challenges with implementations such as public versus private key access, distributed ledger size constraints, speed, complexity, and security pitfalls. Potential use cases for blockchain specifically relevant to medical imaging include image sharing including direct patient ownership of images, tracking of implanted medical devices, research, teleradiology, and artificial intelligence. While blockchain offers exciting ways to facilitate the storage and distribution of medical images, similar to the advent of picture archiving and communication systems decades ago, it does have several key limitations of which healthcare providers of medical imaging and imaging informatics professionals should be aware.
Conference Paper
Following their practical needs and legal constraints, recent application of the cloud paradigm among public administrations has been focused on the deployment of private clouds. Due to the increasing amount of data and processing requirements, many organizations are considering possibilities to additionally optimize their infrastructures and collaborative processes by employing private cloud federations. In this work, we present our contribution based on three real-world use cases implemented in the course of the SUNFISH project. We consider intra- and inter-organizational processes which demand secure and transparent infrastructure and data sharing. Based on derived requirements for data security and privacy in cloud federations, we propose a security governance architecture which enables a multi-layered, context and process-aware policy enforcement in heterogeneous environments. The proposed architecture relies on the micro-services paradigm to support scalability and provides additional security by integrating reactive and transformative security controls. To prove the feasibility of this work we provide performance evaluation of our implementation.
The specification of access control policies with the XACML language could be an error prone process, so a testing is usually the solution for increasing the confidence on the policy itself. In this paper, we compare two methodologies for deriving test cases for policy testing, i.e. XACML requests, that are implemented in the X-CREATE tool. We consider a simple combinatorial strategy and a XML-based approach (XPT) which exploit policy values and the XACML Context Schema. A stopping criterion for the test cases generation is also provided and used for the comparison of the strategies in terms of fault detection effectiveness.
A peer-to-peer network, enabling different parties to jointly store and run computations on data while keeping the data completely private. Enigma's computational model is based on a highly optimized version of secure multi-party computation, guaranteed by a verifiable secret-sharing scheme. For storage, we use a modified distributed hashtable for holding secret-shared data. An external blockchain is utilized as the controller of the network, manages access control, identities and serves as a tamper-proof log of events. Security deposits and fees incentivize operation, correctness and fairness of the system. Similar to Bitcoin, Enigma removes the need for a trusted third party, enabling autonomous control of personal data. For the first time, users are able to share their data with cryptographic guarantees regarding their privacy.