A Blockchain based Access Control Scheme
Maryline Laurent
, Nesrine Kaaniche
, Christian Le and Mathieu Vander Plaetse
SAMOVAR, CNRS, Telecom SudParis, University Paris-Saclay, Paris, France
Keywords:
Access Control, Data Secrecy, Blockchain, Smart Contract, Ethereum.
Abstract:
Recent years have witnessed the trend of increasingly relying on remote and distributed infrastructures. This
increased the number of reported incidents of security and privacy breaches, mainly due to the loss of data
control. Towards these challenges, we propose a new access control scheme based on emerging blockchain
infrastructures. Our approach relies on the use of smart auditable contracts deployed in blockchain infrastruc-
tures. Thus, it offers transparent and controlled access to outsourced data, such that malicious entities cannot
process data without data owners’ authorization. In fact, the effectiveness of the authentication relies on the
blockchain intrinsic properties. Moreover, an implementation of the proposed solution based on Ethereum
Blockchain is presented to show the applicability of our scheme in real-world scenarios.
1 INTRODUCTION
Data security and privacy are major challenges in the
adoption of remote data storage applications, mainly
due to the loss of data control (Kaaniche and Laurent,
2017b), and thus the possibility for third-party data
storage providers to get privacy-sensitive information
about users and potentially leak confidential informa-
tion about the content. Relying on cryptographic me-
chanisms at the client side is a good alternative to mi-
tigate data secrecy concerns. However, the use of con-
ventional encryption approaches is not sufficient to
support the enforcement of fine-grained access con-
trol policies and flexible data sharing among dyna-
mic groups of users. Thus, the challenge is to define
a comprehensive access control mechanism for out-
sourced data while both ensuring data confidentiality
and protecting users’ privacy.
This need for designing security mechanisms to ens-
ure privacy-preserving access control schemes to out-
sourced data files is emphasized by the recent adop-
tion of the new General Data Protection Regulation
(GDPR), in 2016 (Regulation(EU), 2016) that will
be enforced in every European member state in May
2018. The new key concepts behind the GDPR in-
clude the user consent that must be collected by a ser-
vice provider before processing users’ data, accoun-
tability which makes mandatory that any service pro-
viders prove data processing is compliant to former
user’s consent.
Recently, various accountable technical systems
Member of the Chair Values and Policies of Personal
Information
appeared, namely Bitcoin
1
which enables users to
transfer cryptocurrencies (i.e. bitcoins) securely with
no need for a centralized authority, using a publicly
verifiable open ledger, referred to as blockchain. Con-
sequently, blockchain technologies are widely adop-
ted for data accounting and auditing features, thanks
to their main intrinsic properties, namely, tamper-
proof infrastructure and availability.
In this paper, we propose a new blockchain-based
access control scheme, in a data-owner centric
manner. That is, access privileges are defined by the
data owner, via access control lists associated with
auditable smart contracts, and managed by the block-
chain infrastructure that supports the authentication
of requesting users.
Paper Organization Section 2 introduces the neces-
sary background about the blockchain technology, re-
views blockchain related works for data protection
and highlights the security and privacy requirements
for designing a secure access control scheme. Section
3 presents our proposed blockchain-based access con-
trol mechanisms and details the different procedures.
Section 4 provides a security and privacy discussion
of the proposed access control scheme. Section 5 dis-
cusses the implementation of the defined algorithms,
based on Ethereum blockchain environment. Section
6 concludes the paper.
1
https://bitcoin.org/en/
168
Laurent, M., Kaaniche, N., Le, C. and Plaetse, M.
A Blockchain based Access Control Scheme.
DOI: 10.5220/0006855601680176
In Proceedings of the 15th International Joint Conference on e-Business and Telecommunications (ICETE 2018) - Volume 2: SECRYPT, pages 168-176
ISBN: 978-989-758-319-3
Copyright © 2018 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
2 BACKGROUND AND DESIGN
REQUIREMENTS
In this section, we first introduce the blockchain
technology (subsection 2.1). Then, we detail related
work for data protection (subsection 2.2) and high-
light the design and security requirements (subsection
2.3).
2.1 Blockchain Technology
Bitcoin appeared as an innovative technology ena-
bling users to directly transfer cryptocurrencies in be-
tween with no intermediaries. It is considered as the
first decentralized cryptocurrency transfer system. It
relies on cryptographic proofs of work, digital sig-
natures, and peer-to-peer networking to provide a
distributed ledger containing transactions, and refer-
red to as a blockchain (Crosby et al., 2016), (Swan,
2015). Two approaches, known as permissionless
blockchains, have emerged to implement decentrali-
zed services and applications. The first approach re-
lies on the existing Bitcoin blockchain and builds a
new framework on top of it. The main advantage of
this approach is that the Bitcoin blockchain already
exists and is adopted by many users, which makes
it more secure, transparent and resilient. The dis-
advantage is that blocks are mined every 10 minu-
tes, and the Bitcoin scripting language is not Turing-
complete (Swan, 2015). The second approach is to
build an alternative blockchain with all the desired fe-
atures, which promises full decentralization, such as
Ethereum
2
. Additionally to functions already suppor-
ted by other public blockchain platforms such as bit-
coin, e.g. mining of the digital currencies and tran-
saction management, Ethereum also provides a con-
tract functionality known as smart contract.
Transactions submitted to the Ethereum environment
are organized into blocks and chained to each other
based on a cryptographic hash function, initially re-
lying on a pre-computed genesis block. Once a block
is added to the blockchain, it cannot be modified or
removed for two reasons: first, a block modification
would lead to wrong verification of the chain of hash
values, and second, the block modification would re-
quire intensive efforts to change every replicate of the
blockchain supposed to be hosted on a large number
of independent nodes. The verification and addition
of new blocks to the blockchain is based on the mining
process, which relies on the proof of work feature. In-
deed, miners have to solve a cryptographic challenge
and winners are rewarded. The main idea behind the
2
https://www.ethereum.org/
cryptographic challenge is the regulation of the new
block creation operation.
2.2 Blockchain Related Work for Data
Protection
The nature of the blockchain is particularly suitable
for data accounting and auditing features. It has at-
tracted interest of the research community due to its
shared and fault-tolerance database. Indeed, several
constructions have been introduced to ensure prove-
nance tracking (Fu et al., 2017), (Ouaddah et al.,
2016), (Zyskind et al., 2015), (Kaaniche and Laurent,
2017a).
In (Zyskind et al., 2015), Zyskind et al. presen-
ted a personal data management system that combines
blockchain, considered as an access control modera-
tor, and off-blockchain storage solution. Designed as
unique owners of their personal data, clients are aware
of data collected about them by service providers and
how they are used. However, the (Zyskind et al.,
2015) proposal permits to only define simple per-
mit/deny access policies through a white/blacklisting.
Afterwards, Ouaddah et al. proposed, in (Ouaddah
et al., 2016), a blockchain based access control frame-
work for IoT applications, referred to as FairAccess.
Their proposal relies on the blockchain-based bitcoin
technology as an access moderator that permits to
distribute authorization tokens, where each authori-
zation token represents the data owner signature of
the granted access right. In (Fu et al., 2017), An-
min et al. introduced a blockchain-based auditing sy-
stem for shared data in cloud applications. In order
to mitigate the power abuse of single tracing authori-
ties, (Fu et al., 2017) presents a threshold approach,
where at least t entities have to collaborate to reco-
ver the identity of a malicious user, thus ensuring the
non-frameability of users. Based on a blockchain ar-
chitecture, the proposed construction enables group
users to trace data changes and recover latest correct
data blocks when current data are damaged.
Recently, Neisse et al. discussed design require-
ments of blockchain-based solutions for data prove-
nance tracking (Neisse et al., 2017), namely client-
centric, server-centric and data-centric approaches.
The authors also presented an evaluation of their im-
plementation results, in order to give a comprehensive
overview of different defined approaches. Later, in
(Kaaniche and Laurent, 2017a), Kaaniche and Lau-
rent presented a blockchain-based platform for data
usage auditing while preserving personal data secrecy
and ensuring data availability, relying on the use of
the hierarchical ID-based cryptographic technique.
A Blockchain based Access Control Scheme
169
2.3 Security and Privacy Requirements
Our blockchain-based access control solution has to
consider a set of security and functional properties,
defined as follows:
Authenticated access control the proposed
scheme has to ensure an efficient access control
to outsourced data, where requesting entities are
authenticated.
Management efficiency the proposed scheme
should offer efficient management processes.
Privacy through pseudonymity and unlinkability
measures entities’ privacy is preserved thanks
to the pseudonymity supported by the blockchain
and the inability to directly link some data to an
entity, or an access session to a requesting user
identity. Privacy is strengthened with untraceabi-
lity in case of one-time blockchain accounts, with
one account used per system interaction.
Auditability each data owner should have a
transparent view over how data are collected,
accessed and processed.
3 A NEW BLOCKCHAIN-BASED
ACCESS CONTROL SCHEME
In this section, we first give an overview of our propo-
sed blockchain-based access control scheme in sub-
section 3.1. Then, we detail the different procedures
in subsection 3.2.
3.1 Overview
Our proposed access control scheme relies on four
different entities defined as follows:
data storage provider (DSP) it has significant
resources to govern distributed remote servers and
to host application services. These services can be
used by the data owner to manage his data stored
in the remote servers. Note that the DSP is not an
active client of the blockchain, thus having only
read access and not write access to the blockchain.
data owner (DO) a data owner makes use
of data storage provider’s resources to store and
share data with multiple entities. He is responsi-
ble for defining a whitelist of authorized entities
with respected access rights for a specific file sto-
red on DSP. The whitelist is stored in a per file
smart contract (C) into the blockchain.
data retriever (DR) data retrievers are able to
access the content stored in remote servers, de-
pending on their access rights which are authori-
zations granted by the DO. As the DR is known
as a blockchain client, the blockchain can partici-
pate in the authentication of DR with DSPs before
granting access to outsourced data.
blockchain infrastructure (BC) the blockchain
is considered as an access control mediator, as it
permits to authenticate DRs, to keep traces of each
DR access to data and to preserve the access rights
history of each DO.
The notations used in this paper are listed in Table 1.
Table 1: Our notations.
Notation Description
BC blockchain infrastructure
DSP data storage provider
DO data owner
DR data retriever
C smart contract
Our scheme aims at providing the DO with the ca-
pacity of defining the access rights for each of his data
resource (file, directory, image...), and of dynamically
deleting these rights when needed. Rights are expres-
sed per DR and registered in a smart contract as a whi-
telist of authorized DRs with a detailed specific access
control list. The interest is therefore multifold. First,
no one can alter the list of authorized entities to access
certain resources, as all blockchain-specific operati-
ons are considered as secure and non-corruptible, thus
ensuring non-tamper proofs of data access activities.
Second, our scheme relies on a data owner-centric
model, as the data owner creates a contract for each
outsourced data resource, including the access control
list w.r.t. data usage. Third, the entire identification
system and the robustness of the authentication pro-
cess rely on BC properties. Indeed, DRs and DOs are
known through their BC identifiers, which make them
be uniquely identified. Fourth, any DR access is re-
gistered in BC, thus leading to later possible auditing
activities to take place over the access control system.
As such, the use of BC permits to publish a whitelist
which remains under the control of the DO, to sup-
port efficient identification and authentication proces-
ses of DOs and DRs, and to enable auditing activities
thanks to useful registered traces (whitelists, access
requests).
In a nutshell, DO is responsible for creating a smart
contract in the BC, adding or removing an address
from the whitelist. A DR trying to access the resour-
ces outsourced on a DSP has to go through the corre-
sponding smart contract. He is authorized to access a
SECRYPT 2018 - International Conference on Security and Cryptography
170
resource based on the authentication protocol played
between the DSP and DR with BC support, and the
whitelist registered in the BC. Hence, interactions of
entities with BC support the following rules:
The DO is the only entity that might modify the
whitelist, as he is the owner of the outsourced
data. He must therefore be able to add or remove
an authorized address, referring to a specific aut-
horized DR, from this list. Note that the contract
has to include the address of the DO, its creator,
for assigning modification of right permissions.
The DR is authorized to issue a transaction w.r.t.
the contract to request access to resources. If the
transaction is accepted by the BC, it means both
that the DR is authenticated, and it is authorized
to access the resources. Thus, a successful au-
thentication leads to the smart contract registering
into the blockchain the address of DR as a permit-
ted entity. Note that our scheme assumes that the
comparison process is performed by the hosting
server. As a result, the contract must be passive
when it receives users’ transactions.
Any entity including DSP, can read the content of
the whitelist, for performing the addresses com-
parison, for every DR’s access request.
Note that although the contract script becomes un-
changeable after its deployment on BC, its state may
vary. Indeed, variables are defined (i.e; DR’ addresses
in our case) so that they can be modified by the DO
w.r.t. subsequent solicitations. That is, the whitelist
can be modified, but the contract script cannot.
3.2 Procedures
3.2.1 Whitelist Creation Process
As stated above, each smart contract, created by a data
owner, permits to list the addresses of authorized DRs
to access a given data file, outsourced on a remote ser-
ver. Hence, the question is about the definition of the
relation between the smart contract (C) and the out-
sourced data file. For this purpose, we focus on the
process of the smart contract creation by DO with the
DSP. Note that our blockchain-based access control
mechanism requires the deployment of a client inter-
face, such that each DO can easily perform the white-
list creation process. The different steps, depicted by
Figure 1, are as follows:
1. DO authenticates with DSP and shares the name
of the data file, that he intends to protect, with
DSP.
2. DO creates a smart contract. To do so, the DO
sends a transaction to the null address. The ad-
dress of the created contract is given randomly,
using the client interface. The smart contract has
also to record the whitelist in the BC, in order to
keep the history of the whitelists, such that the
DSP can retrieve the last valid one.
Figure 1: Whitelist Creation Process.
3. DO sends the address of the newly created con-
tract as well as the data file to the remote DSP.
4. DO sends the address of the created contract to
the authorized DRs. In fact, we emphasize that
each authorized DR has to communicate the ad-
dress of the contract, when he wants to access to
the corresponding outsourced data file.
5. DO recovers the address of each authorized DR,
to be included in the whitelist.
6. DO sets up the whitelist, by introducing the ad-
dresses of authorized DRs, via the client interface.
Note that it is also possible to remove an address
from the whitelist using the same process used to add
a newly authorized address. In fact, the contract is lin-
ked to the outsourced file thanks to its address stored
in the DSP. A main advantage of our proposed solu-
tion is that the whitelist can be modified without any
need to interact with the DSP. Indeed, only a hyper-
link to the whitelist is stored on the DSP.
3.2.2 Resource Access Process
When an authorized DR wants to access to an out-
sourced data file, he starts the resource access process
with the remote hosting DSP (cf. Fig.2), as follows:
1. the DR sends an access request to the DSP, via an
off-blockchain channel.
2. the DSP sends a randomly generated nonce to the
requesting DR. Subsequently, the DSP starts lis-
tening to the blockchain by scanning the newly
added transactions associated with the correspon-
ding contract and analyzes transactions containing
the given nonce.
A Blockchain based Access Control Scheme
171
Figure 2: Access to Resources Process.
3. the DR sends a transaction to the contract with
the nonce as input data. Recall that the contract
remains passive during this step, unlike for the so-
licitation issued by the DO. This transaction does
not result in making the contract react, but instead
it leaves a trace on the BC, and it proves the tran-
saction is authentic.
4. Once the generated nonce has been identified by
the DSP in the input data field of a transaction as-
sociated with the corresponding contract, the DSP
selects the address of the entity that issued the
transaction. Then, it compares the authorized ad-
dresses of the whitelist with the originating ad-
dress of the transaction.
5. In the case where the originating address of the
transaction corresponds to one of the authorized
addresses, as defined in the whitelist, the DSP
identifies the DR.
Finally, we have to emphasize the necessity of inclu-
ding a randomly generated nonce for each authenti-
cation session. That is, the nonce permits to prove
the freshness of the transaction to the DSP. This lat-
ter makes the link between a received request and a
successful authentication by the BC thanks to the ge-
nerated nonce. Our access control application ma-
kes use of a public blockchain technology for decen-
tralized authentication, ensuring data auditability and
transparency requirements. In fact, although the list
of authorized addresses is publicly verifiable, it is im-
possible to alter the whitelist, where the DO is the
unique entity that can grant privileges to DRs.
4 SECURITY DISCUSSION
In this section, we first present our threat model.
Then, we provide a security discussion of our pro-
posed blockchain-based access control scheme, with
respect to the security and privacy requirements de-
tailed in section 2.3.
4.1 Threat Model
For designing a secure blokchain-based access con-
trol scheme, we consider that an attacker is able to
read, send and drop a transaction addressed to the
blockchain. The attacker targets data owners, data re-
trievers, data storage providers as well as the block-
chain, as follows:
based on previous data access requests sessions,
as well as provided blockchain data, an attacker
tries to impersonate a data owner to afford a ho-
nest data storage provider some rights to be log-
ged into the blockchain without the legal data ow-
ner’s granted privileges. This attack is conside-
red with respect to the authenticated access cont-
rol and auditability requirements.
an attacker tries an attack against the privacy pro-
perty w.r.t. both data owners, while trying to di-
rectly link a smart contract to a specific owner,
and data retrievers while attempting to link an
access session to a requesting entity.
an attacker attempts to prevent the publication of
a legitimate transaction in the blockchain. For ex-
ample, an attacker may try a DoS attack against
an access list modification activity or attempt a
flooding attack on the blockchain with invalid in-
formation. This attack is considered against the
auditability and the availability requirements.
4.2 Security and Privacy Analysis
AUTHENTICATED ACCESS CONTROL our appro-
ach ensures an authenticated access control for several
reasons here-below listed:
blockchain-based authentication – our scheme re-
lies on the blockchain infrastructure to enforce the
authentication of the participating entities. That
is, each entity has to include its blokchain-account
address to either outsourcing (i.e; for DOs) or
accessing (i.e; for DRs) requests.
access lists’ integrity in our approach, access
control lists are stored in the blockchain as well
as on the remote hosting server. That is, as access
lists are stored on all blockchain nodes, each en-
tity has a copy of all smart contracts. Thus, in or-
der to afford a honest data storage provider some
rights to be logged into the blockchain without
the legal data owner’s granted privileges, the at-
tacker has to corrupt all blockchain-hosting nodes
to tamper access lists.
PRIVACY The privacy property is ensured
thanks to the following technical features:
SECRYPT 2018 - International Conference on Security and Cryptography
172
one smart contract per outsourced data resource –
for each outsourced data resource to a remote ser-
ver, the DO creates a new smart contract which
points out the authorized DRs’ addresses. Thus, it
is impossible for an attacker to link a smart con-
tract with its DO, mainly in case of one-time ac-
counts, as emphasized in section 2.3.
a per-access session nonce for each access ses-
sion, the remote server generates a random nonce
that is used by the requesting DR in its access
transaction w.r.t. the smart contract associated
to the outsourced data resource, thus proving
freshness, and pseudonymity ownership while not
revealing the true identity.
AUDITABILITY Our proposed access control
scheme ensures the auditability requirement as:
tamper-proof architecture all blockchain-
specific operations, such as transaction anchoring
activities, are considered as secure and non-
corruptible, thus ensuring non-tamper proofs of
data access activities.
transparent usage – our approach is based on a pu-
blic blockchain infrastructure, that permits public
access (i.e; read privilege) to the contract and its
associated transactions, to anyone.
Remark 1. As a highly decentralized infrastructure,
the blockchain technology helps also in terms of avai-
lability. It becomes possible to provide liveness gua-
rantees of data usage. To prevent DOS attacks, our
access control mechanism requires that both DSP and
DR use a per-session nonce, randomly generated by
the remote server, such that the DR has to include
the freshly derived nonce in his access request tran-
saction w.r.t. to a given smart contract.
5 IMPLEMENTATION
In this section, we detail the implementation of our
proposed blockchain-based access control scheme,
based on the Ethereum environment, w.r.t. the smart
creation process (cf. Section 5.1), installation scripts
of the blockchain (cf. Section 5.2) and the client in-
terface development (cf. Section 5.3).
For the implementation of our access control
scheme, we first point out three different softwares,
namely the client software for the DO, the client soft-
ware for the DR and the DSP software. Then, we de-
fine the structure of the smart contract that will con-
tain the whitelist, and its instantiating BC script.
5.1 Smart Contract Creation
To implement our smart contract, we are solidity
language
3
which is a specific Ethereum program-
ming language. We note that there exist several
programming languages for smart contract creation,
but solidity is a high-level language that perfectly
matches our design requirements. To be interpretable
by the Ethereum blockchain, the smart contract has
to be compiled into bytecodes. For this purpose,
we used a compiler called browser-solidity. It is a
compiler with a web interface.
Hereafter, we detail the code of each created smart
contract. First, we define the attributes of our
contract, namely owner and whitelist. Then, we
define a set of functions, namely the whitelist and
get whitelist functions for creating the whitelist and
the add(address a) and remove(address a) for adding
and removing DR addresses respectively.
owner is an address that maps the address of the entity
instantiating the contract and whitelist is an array
that is used to store addresses of authorized DRs.
address public owner;
address[] whitelist;
The whitelist () function refers to the constructor. We
assign the owner attribute to the msg.sender address,
such that DO is the unique entity that can get use of
the defined constructor.
function WhiteList() public
{owner=msg.sender;}
The get whitelist () function returns the array of allo-
wed addresses. This function permits to the check if
the whitelist contains a given DR’s address.
function get_whitelist() constant
returns (address[])
{return whitelist;}
The add (address a) function permits to add a new
address to the whitelist. In the following, we detail the
different execution of this function. First, a checking
line code is added to verify if the entity (msg.sender)
trying to modify the existing whitelist is the owner of
the contract (owner).
if(msg.sender==owner){
Then, to save storage capacities and avoid redundancy
and inconsistency, the add (address a) function veri-
fies whether the new address is not already present in
the list. This is particularly important for the deletion
step, ensuring that a given address is presented only
once at the same whitelist.
3
https://solidity.readthedocs.io/en/develop/
A Blockchain based Access Control Scheme
173
for(i=0; i<whitelist.length; i++){
if(whitelist[i] == a){
throw;}}
Afterwards, the adding function checks if there exists
zero entries in the whitelist table. The checking loop
aborts if one of the addresses is zero or if it reaches
the end of the table. In case of the existence of a zero
entry, it is then replaced by the new address otherwise
the new address is appended at the end of the table:
while(i<whitelist.length && whitelist[i] != 0)
{i++;}
if(i!=whitelist.length)
{whitelist[i] = a;}
else
{whitelist.push(a);}
Similarly, the remove (address a) function first checks
whether the requesting entity is the allowed DO
(msg.sender). Then, it points out the corresponding
address to proceed for its deletion. For adding a new
smart contract in the blockchain, several javascript
commands from the geth console (i.e; blockchain in-
terface) are defined. The browser-solidity compiler
provides a script, generated with bytecode to allow
easy integration of smart contracts such as:
var whitelistcontract =
web3.eth.contract([{"constant":false,"inputs":[
{"name":"a","type":"address"}],"name":"add",
"outputs":[],"payable":false,"type":"function"}
,{"constant":true,"inputs":[],"name":"owner",
"outputs":[{"name":"","type":"address"}],"payab
le":false,"type":"function"},{"constant":true,
"inputs":[],"name":"get_whitelist","outputs":
[{"name":"","type":"address[]"}],"payable":fals
e,"type":"function"},{"inputs":[],"payable":fal
se,"type":"constructor"}]);
Notice that the script creates a variable ”whitelistcon-
tract” needed to define the interface of the smart con-
tract such that the web3.eth.contract (...) function ta-
kes as input the contract ABI (i.e; Application Binary
Interface) corresponding to the signature of all the de-
fined contract functions.
To generate a new contract, the variable ”whitelist-
contract” receives a contract instantiation, such that:
var whitelist = whitelistcontract.new({
The whitelistcontract.new (...) function takes as input
the creator of the instance and the bytecode of con-
tract. It also takes a callback function that displays
the address of the contract. Indeed, it is this address
that has to be provided to any entity for interacting
with the newly created contract. In addition, we ad-
ded to this script generated by the compiler a function,
called search(end), defined as follows:
function search(end){
bn=0; while(bn==0){
tx=eth.getTransactionFromBlock(eth.blockNumber);
if(tx!=null && tx.to==null &&
tx.from==eth.coinbase){
bn=eth.blockNumber;}}
The search(end) function returns the address of the
contract to the authorized requesting entity ( ”ow-
ner”).
5.2 Installation Scripts of the
Blockchain
Several scripts have been implemented to enable in-
teraction between the blockchain and the created con-
tract. The first script is designed for the DO that needs
to protect his outsourced data resources. This script
permits to create a whitelist associated with each data
file, add and delete addresses as well as save the cor-
responding whitelist. These functions are accessi-
ble through a user-friendly interface, detailed in sub-
section 5.3, to ease the manipulation of our access
control scheme in real-world applications. In addi-
tion to these scripts, we defined and implemented a
set configuration scripts that allow to deploy and test
the consistency of the proposed construction. First, a
script is launched to enable connection with the BC:
#!/bin/bash
isLaunched=$(ps aux | grep datadir=$1 | head -1)
Consequently, the script checks whether an instance
of geth was launched with the corresponding node
number. If there is no instance, a new instance has to
be created specifying the listening ports to communi-
cate with other nodes. To communicate with the main
node, its exact address, referred to as enode, is then
required as follows:
if [[ ! $isLaunched geth ]] ;
then
geth --datadir="$1" -verbosity 6
--ipcdisable --port 303$1 --nodiscover
--rpcport 81$1 console 2>> $1.log
else geth --datadir="$1" --port 303$1
--nodiscover --rpcport 81$1 attach
ipc://$PWD/$1/geth.ipc
fi
Similarly to the connection process, the specified
options for the creation of a new nodes include the
specification of listening ports for our nodes. That is,
the init command allows create a node, and ”gene-
sis.json” is a file that describes the first block in the
chain. In particular, for our implementation, we defi-
ned the difficulty for mining, and put it relatively low
to speed up operations on our blockchain.
geth --datadir="$1" -verbosity 6 --ipcdisable
--port 303$1 --nodiscover --rpcport 81$1
init genesis.json 2>> $1.log
SECRYPT 2018 - International Conference on Security and Cryptography
174
Afterwards, we create an account, accessible by
”eth.coinbase”. This account permits to the created
node to perform BC transactions. To do so, we define
a default password ”test”, and send the command to
geth using the ”connect.sh” script. Subsequently, we
recover the enode of the created node to be stored as
a result in the ”enodes.txt” file. Thanks this script, a
new blockchain is created, a base-account is derived
and the enode (i.e; identifier) is stored on a text file.
Using the same genesis block, multiple nodes, able to
cooperatively perform tasks on the same BC, can be
created. Finally, a python
4
script is defined, to re-
cover the saved enodes in the ”enodes.txt” file, and
generate an addEnode.js javascript
5
file that permits
to connect different nodes once they are launched.
Note that miner.sh script is also designed to launch
a node in miner mode, as follows:
#!/bin/bash
geth --datadir="$1" --port 303$1 --nodiscover
--rpcport 81$1 --mine
5.3 User Interface
For our access control scheme, we designed one com-
posite server-interface and two simple user interfaces.
Indeed, user interfaces include the DO-interface that
permits to the DO to define the authorized accessing
entities’ addresses, via the creation of a whitelist, as
defined in subsection 5.1, and the DR-interface that
enables a DR to request access to a given outsour-
ced data file. The composite server-interface is defi-
ned w.r.t. two different scripts, where the first script
maintains DOs’ storing requests and the second script
handles DRs’ access requests.
For ease of presentation and submission guidelines–
, only the DO-interface is detailed, w.r.t. to BC com-
mands. To do so, we first recover the name of the file
that will be sent to the remote server. Once recovered,
a DO-DSP connection is instantiated and the data file
is sent to the remote server, as follows:
s = socket.socket()
host = socket.gethostname()
port = 1234
s.connect((host, port))
s.send((dataf+".dat").encode(’ascii’))
The DO then creates a smart contract and retrieves
its associated address, as detailed in subsection 5.1.
The contract address is then sent to the hosting server
such as:
s.send(json.dumps(data).encode(’ascii’))
Afterwards, the DO updates the whitelist dictionary
which corresponds to the new created whitelist as
4
https://www.python.org/
5
https://www.javascript.com/
shown hereafter, where ”whtext” is a variable that dis-
plays the whitelist in the GUI (Graphic User Inter-
face) and ”stringFormat” function allows to obtain a
string of characters representing the whitelist.
whitelist["address"]=address
whitelist["list"]=[]
whtext.set(stringFormat(whitelist))
Finally, the DO-interface proposes two different
functions, as explained in subsection 5.1, namely the
addWL function which allows to add an address to the
whitelist and the removeWL function that removes ad-
dresses from the access list. The definition of both
functions is almost similar.
6 CONCLUSION
In this paper, we presented a new blockchain-based
access control scheme that permits data owners to de-
fine access rights for each of their outsourced data re-
sources on remote storage servers, and to dynamically
delete these granted privileges when needed. Access
rights are expressed per data retriever and registered
in a smart contract as a whitelist of authorized users
with a detailed specific access control list. Our pro-
posed scheme provides an authenticated access cont-
rol, conducted via the blockchain infrastructure, and
ensures an adequate management process w.r.t. ef-
ficient whitelists definition. In addition, thanks to
the pseudonymity supported by the blockchain, our
access control mechanism enables to preserve enti-
ties’ privacy. Stronger unlinkability properties can be
provided in case of one-time blockchain accounts thus
ensuring unlinkability between different access sessi-
ons and between different data resources belonging to
the same owner.
REFERENCES
Crosby, M., Pattanayak, P., Verma, S., and Kalyanaraman,
V. (2016). Blockchain technology: Beyond bitcoin.
Applied Innovation, 2:6–10.
Fu, A., Yu, S., Zhang, Y., Wang, H., and Huang, C. (2017).
Npp: A new privacy-aware public auditing scheme for
cloud data sharing with group users. IEEE Transacti-
ons on Big Data.
Kaaniche, N. and Laurent, M. (2017a). A blockchain-based
data usage auditing architecture with enhanced pri-
vacy and availability.
Kaaniche, N. and Laurent, M. (2017b). Data security and
privacy preservation in cloud storage environments
based on cryptographic mechanisms. Computer Com-
munications, 111:120–141.
A Blockchain based Access Control Scheme
175
Neisse, R., Steri, G., and Nai-Fovino, I. (2017).
A blockchain-based approach for data accounta-
bility and provenance tracking. arXiv preprint
arXiv:1706.04507.
Ouaddah, A., Abou Elkalam, A., and Ait Ouahman, A.
(2016). Fairaccess: a new blockchain-based access
control framework for the internet of things. Security
and Communication Networks, 9(18):5943–5964.
Regulation(EU) (2016). 2016/679 of the european parlia-
ment and of the council of 27 april 2016 on the pro-
tection of natural persons with regard to the proces-
sing of personal data, ojeu l 119/1 of 4.05.2016.
Swan, M. (2015). Blockchain: Blueprint for a new eco-
nomy. O’Reilly Media, Inc.
Zyskind, G., Nathan, O., et al. (2015). Decentralizing pri-
vacy: Using blockchain to protect personal data. In
Security and Privacy Workshops (SPW), 2015 IEEE,
pages 180–184. IEEE.
SECRYPT 2018 - International Conference on Security and Cryptography
176