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 conﬁdential 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 sufﬁcient to

support the enforcement of ﬁne-grained access con-

trol policies and ﬂexible data sharing among dyna-

mic groups of users. Thus, the challenge is to deﬁne

a comprehensive access control mechanism for out-

sourced data while both ensuring data conﬁdentiality

and protecting users’ privacy.

This need for designing security mechanisms to ens-

ure privacy-preserving access control schemes to out-

sourced data ﬁles 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

which enables users to

transfer cryptocurrencies (i.e. bitcoins) securely with

no need for a centralized authority, using a publicly

veriﬁable 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 deﬁned 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 deﬁned algorithms,

based on Ethereum blockchain environment. Section

6 concludes the paper.

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

2 BACKGROUND AND DESIGN

REQUIREMENTS

In this section, we ﬁrst 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

ﬁrst 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 ﬁrst 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

. 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 modiﬁed or

removed for two reasons: ﬁrst, a block modiﬁcation

would lead to wrong veriﬁcation of the chain of hash

values, and second, the block modiﬁcation would re-

quire intensive efforts to change every replicate of the

blockchain supposed to be hosted on a large number

of independent nodes. The veriﬁcation 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

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 deﬁne 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 deﬁned 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,

deﬁned as follows:

• Authenticated access control — the proposed

scheme has to ensure an efﬁcient access control

to outsourced data, where requesting entities are

authenticated.

• Management efﬁciency — the proposed scheme

should offer efﬁcient 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 ﬁrst 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 deﬁned as follows:

• data storage provider (DSP) — it has signiﬁcant

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 deﬁning a whitelist of authorized entities

with respected access rights for a speciﬁc ﬁle sto-

red on DSP. The whitelist is stored in a per ﬁle

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 deﬁning the access rights for each of his data

resource (ﬁle, 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 speciﬁc 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-speciﬁc 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 identiﬁcation

system and the robustness of the authentication pro-

cess rely on BC properties. Indeed, DRs and DOs are

known through their BC identiﬁers, which make them

be uniquely identiﬁed. 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 efﬁcient identiﬁcation 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 speciﬁc aut-

horized DR, from this list. Note that the contract

has to include the address of the DO, its creator,

for assigning modiﬁcation 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 deﬁned (i.e; DR’ addresses

in our case) so that they can be modiﬁed by the DO

w.r.t. subsequent solicitations. That is, the whitelist

can be modiﬁed, 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 ﬁle, outsourced on a remote ser-

ver. Hence, the question is about the deﬁnition of the

relation between the smart contract (C) and the out-

sourced data ﬁle. 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 ﬁle, 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 ﬁle 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 ﬁle.

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 ﬁle thanks to its address stored

in the DSP. A main advantage of our proposed solu-

tion is that the whitelist can be modiﬁed 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 ﬁle, 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 identiﬁed by

the DSP in the input data ﬁeld 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 deﬁned in the whitelist, the DSP

identiﬁes 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 veriﬁable, 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 ﬁrst 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 speciﬁc 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 modiﬁcation activity or attempt a

ﬂooding 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-

speciﬁc 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 ﬁrst 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-

ﬁne 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

which is a speciﬁc 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 deﬁne the attributes of our

contract, namely owner and whitelist. Then, we

deﬁne 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 deﬁned 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-

ﬁes 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.

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 ﬁrst 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 deﬁned. 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 deﬁne 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-

ﬁned 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), deﬁned 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 ﬁrst 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

ﬁle, 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 deﬁned and implemented a

set conﬁguration 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

Similarly to the connection process, the speciﬁed

options for the creation of a new nodes include the

speciﬁcation of listening ports for our nodes. That is,

the init command allows create a node, and ”gene-

sis.json” is a ﬁle that describes the ﬁrst block in the

chain. In particular, for our implementation, we deﬁ-

ned the difﬁculty 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 deﬁne

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” ﬁle. Thanks this script, a

new blockchain is created, a base-account is derived

and the enode (i.e; identiﬁer) is stored on a text ﬁle.

Using the same genesis block, multiple nodes, able to

cooperatively perform tasks on the same BC, can be

created. Finally, a python

script is deﬁned, to re-

cover the saved enodes in the ”enodes.txt” ﬁle, and

generate an addEnode.js javascript

ﬁle 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 deﬁne the authorized accessing

entities’ addresses, via the creation of a whitelist, as

deﬁned in subsection 5.1, and the DR-interface that

enables a DR to request access to a given outsour-

ced data ﬁle. The composite server-interface is deﬁ-

ned w.r.t. two different scripts, where the ﬁrst 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 ﬁrst recover the name of the ﬁle

that will be sent to the remote server. Once recovered,

a DO-DSP connection is instantiated and the data ﬁle

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

https://www.python.org/

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 deﬁnition 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-

ﬁne 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 speciﬁc 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-

ﬁcient whitelists deﬁnition. 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