Prov-Trust: Towards a Trustworthy SGX-based Data Provenance System

Nesrine Kaaniche

1 a

, Sana Belguith

2 b

, Maryline Laurent

3 c

, Ashish Gehani

and Giovanni Russello

Department of Computer Science, University of Shefﬁeld, Shefﬁeld, U.K.

School of Science, Engineering and Environment, University of Salford, Manchester, U.K.

Telecom SudParis, Institut Polytechnique de Paris, France

Computer Science Laboratory, SRI International, U.S.A.

Cyber Security Foundry, The University of Auckland, New Zealand

Keywords:

Intel SGX, Privacy Preserving, Data Provenance, Blockchain, Data Integrity.

Abstract:

Data provenance refers to records of the inputs, entities, systems, and processes that inﬂuence data of in-

terest, providing a historical record of the data and its origins. Secure data provenance is vital to ensure

accountability, forensics investigation of security attacks and privacy preservation. In this paper, we propose

Prov-Trust, a decentralized and auditable SGX-based data provenance system relying on highly distributed

ledgers. This consensually shared and synchronized database allows anchored data to have public witness,

providing tamper-proof provenance data, enabling the transparency of data accountability, and enhancing the

secrecy and availability of the provenance data. Prov-Trust relies on Intel SGX enclave to ensure a trusted

execution of the provenance kernel to collect, store and query provenance records. The use of SGX enclave

protects data provenance and users’ credentials against malicious hosting and processing parties. Prov-Trust

does not rely on a trusted third party to store provenance data while performing their veriﬁcation using smart

contracts and voting process. The storage of the provenance data in Prov-Trust is done using either the log

events of Smart Contracts or blockchain’s transactions depending on the provenance change event, which en-

ables low storage costs. Finally, Prov-Trust ensures an accurate privacy-preserving auditing process based on

blockchain traces and achieved thanks to events’ logs that are signed by SGX enclaves, transactions being

registered after each vote session, and sealing the linking information using encryption schemes.

1 INTRODUCTION

Data provenance refers to the chain of ownership of a

piece of data that covers who created it, who mod-

iﬁed and accessed it (Moreau et al., 2010). Data

provenance is important to investigate security inci-

dents where these data are analysed to detect mali-

cious actions, data breaches and access policy viola-

tions. Many solutions have been proposed to collect,

store and manage provenance data (Zafar et al., 2017).

However, many challenges have been raised by these

systems as they need to ensure both (i) a secure col-

lection and veriﬁability/integrity of provenance data,

and (ii) the conﬁdentiality and secure storage of col-

lected data.

The increased use of cloud computing services

adds new challenges to data provenance systems. Se-

https://orcid.org/0000-0002-1045-6445

https://orcid.org/0000-0003-0069-8552

https://orcid.org/0000-0002-7256-3721

curity of data stored in clouds is of great importance,

as the user delegates the management of his data to

a service provider who is not considered as a fully

trusted entity. Therefore, data provenance is more

and more needed in cloud computing services to en-

sure users’ data auditing and accountability. Man-

aging data provenance in clouds is challenging as

these data may reveal private information about the

stored data or the users. Thus, there is a need to

protect the provenance data against unauthorized ac-

cess while preserving the privacy of users. To address

these challenges, several secure provenance systems

have been introduced. Some systems have imple-

mented cryptographic mechanisms such as homomor-

phic encryption to search over provenance data (As-

ghar et al., 2012) or attribute based encryption to en-

sure encrypted access control over provenance data

(Belguith et al., ). Some other research works have

addressed the secure collection of provenance data re-

lying on trusted software and/or hardware tools such

as Trusted Platform Module (TPM) (Taha et al., 2015;

Kaaniche, N., Belguith, S., Laurent, M., Gehani, A. and Russello, G.

Prov-Trust: Towards a Trustworthy SGX-based Data Provenance System.

DOI: 10.5220/0009889302250237

In Proceedings of the 17th International Joint Conference on e-Business and Telecommunications (ICETE 2020) - SECRYPT, pages 225-237

ISBN: 978-989-758-446-6

225

Ko and Will, 2014). Recently, Blockchain technol-

ogy have been leveraged to ensure a tamper-proof and

available data provenance systems (Li et al., 2019;

Ramachandran and Kantarcioglu, 2018).

Contributions — In this paper, we present Prov-

Trust, an Intel SGX and blockchain based data prove-

nance architecture that provides a secure and privacy

preserving data provenance generation and storage.

Prov-Trust relies on the distributed tamper-proof

nature of the blockchain technology, cryptographic

techniques and trusted hardware, i.e, Intel SGX to se-

curely collect and store data provenance while pre-

serving the privacy of sensitive information. Opera-

tions over data are monitored in real time to collect

provenance data, that support the compliance of ac-

cess control policy enforcement and intrusion detec-

tion based on provenance middlewares (Gehani and

Tariq, 2012).

Prov-Trust relies on Intel SGX enclave to ensure a

trusted execution of the provenance kernel to collect,

store and query provenance records. The use of SGX

enclave protects data provenance and users’ creden-

tials against malicious hosting and processing parties.

The Prov-Trust framework does not rely on a trusted

third party to store provenance data while perform-

ing their veriﬁcation using smart contracts and voting

process. Indeed, a smart contract is used to monitor

the changes performed over a document while imple-

menting access control policies and maintaining all

users’ accesses/modiﬁcation to the document. The

vote contract allows a set of designated users to vote

for/against the change of a set of deﬁned provenance

change events, namely ”download” and ”transfer”.

The storage of the provenance data in Prov-Trust is

done using either the log events of Smart Contracts

or blockchain’s transactions depending on the prove-

nance change event, which enables low storage costs.

Finally, Prov-Trust ensures an accurate privacy-

preserving auditing process based on blockchain

traces and achieved thanks to events’ logs are signed

by SGX enclaves, transactions being registered after

each vote session, and enciphering of linking infor-

mation with respect to an attribute based encryption

and re-randomizable encryption schemes (Kaaniche

and Laurent, 2018).

Paper Organization — This paper is organized

as follows. Section 2 presents a literature review of

data provenance solutions while deﬁning security and

functional requirements for the proposed architecture.

An overview of Prov-Trust underlying technologies

namely, Blockchain and Intel SGX is introduced in

Section 3. Afterwards, we deﬁne the network model

and we present an overview of Prov-Trust phases in

Section 4. The detailed phases of Prov-trust are pre-

sented in Section 5 before introducing the security

and privacy analysis in Section 6. The paper is con-

cluded and future works are presented in Section 8.

2 RELATED WORK AND

REQUIREMENTS

In this section, we ﬁrst review data provenance solu-

tions. Then, we details the security and privacy re-

quirements that have to be fulﬁlled by the proposed

solution.

2.1 Data Provenance Solutions

Data provenance refers to the chain of ownership of a

piece of data that covers who created it, who modiﬁed

and accessed it (Moreau et al., 2010). Data prove-

nance is used to investigate security incidents where

data provenance is analysed to detect malicious ac-

tions, data breaches and access policy violations. Ex-

tensive research has been conducted on data prove-

nance in database, ﬁle workﬂow and operating sys-

tems (Suen et al., 2013) and many provenance man-

agement systems have been proposed (Zafar et al.,

2017). PASS is one of the ﬁrst systems that have been

designed to provide automatic collection and mainte-

nance of provenance data (Muniswamy-Reddy et al.,

2006). Improved versions of PASS that supports

the integration of multiple levels of abstractions have

been introduced after its ﬁrst release (Muniswamy-

Reddy et al., 2008). PASSv2 operates within the

three levels of abstraction: the system call bound-

ary, a workﬂow speciﬁcation language, and a domain-

speciﬁc application level. HiFi is a kernel level prove-

nance system that uses Linux Security Modules to

gather provenance data (Pohly et al., 2012). These

generated data can be forensically analysed to detect

malicious activities thanks to the tracking of the ker-

nel and application actions within the Linux system.

SPADE (Gehani, 2016) is a provenance middleware

providing users with a framework to collect, store and

query provenance data that are generally data graphs

describing the history of processes ran over a piece of

data. Open Provenance Model (OPM) is a methodol-

ogy representing the provenance graphs in three types

of nodes: artifacts, processes and agents (Moreau

et al., 2011).

The emergence of cloud computing created a need

to adapt/develop provenance systems to track data

changes in such highly distributed systems. Col-

lecting provenance data is particularly challenging

in complex systems such as cloud computing that

presents multiple layers of interacting software and

SECRYPT 2020 - 17th International Conference on Security and Cryptography

226

hardware. Cloud computing systems are dynamic and

heterogeneous systems involving several components

provided by different providers. Many data prove-

nance systems have been designed for cloud comput-

ing. SPADEv2 (Gehani, 2016) has been introduced

as an open source tool supporting both graph and re-

lational database storage and querying in a distributed

system which makes it adapted for cloud computing.

S2Logger is a solution designed to capture and visu-

alise end-to-end provenance data across all guest and

host physical machines in distributed virtualised envi-

ronments such as cloud computing (Suen et al., 2013).

As provenance data usually contain sensitive in-

formation that should be kept secure. Additionally,

provenance data can be modiﬁed or forged by a mali-

cious attacker to mislead investigation and analysis of

events logs. Assuring a trusted data provenance will

enable users to verify the operations performed over

their data. Therefore, provenance data should fulﬁll

a set of security criteria such as conﬁdentiality, in-

tegrity, unforgeability,non-repudiation and availabil-

ity (Zafar et al., 2017). The Secure Provenance

(SPROV) scheme is one of the ﬁrst provenance solu-

tions that considered security features (Hasan et al.,

2009). SPROV automatically collects data prove-

nance besides providing security assurances of con-

ﬁdentiality and integrity of these data. Asghar et al.

(Asghar et al., 2012) designed a secure data prove-

nance storage system that enables secure and pri-

vacy preserving search over provenance data based on

cryptographic algorithms.

To fulﬁll availability and integrity requirements,

Blockchain systems have been used to store and man-

age provenance data. Blockchain has been ﬁrst lever-

aged in data provenance systems in 2017 by intro-

ducing Provchain (Liang et al., 2017). Provchain is

a data provenance system based on blockchain for a

cloud applications. In Provchain, OPM has been used

to collect provenance data in real-time. Afterwards,

operations history are saved in blockchain transac-

tions. This enables auditors to validate the operations

by consulting the transactions receipts. BlockCloud

(Shetty et al., 2017) monitors users activities in real

time using special classes of events namely, hooks and

listeners that enables the generation of provenance

data. The provenance data are stored in transactions

that are broadcasted to the core of blockchain net-

work created by a speciﬁc set of validating virtual ma-

chines. Similar to Provchain solution, the provenance

auditor validates the data using the transactions re-

ceipts. SmartProvenance (Ramachandran and Kantar-

cioglu, 2018) applies Ethereum Smart Contracts to

provide data provenance. SmartProvenance is based

on two smart contracts, namely Document Tracker

contract and Vote contract. The Document Tracker

smart contract is used to monitor the operations per-

formed over a given document while the vote contract

speciﬁes the voting protocol. A voting process is used

to validate every provenance change event.

These solutions do not address a trusted genera-

tion of the provenance data, yet unforgeability is a

security requirement that needs to be achieved while

generating and storing provenance data. The unforge-

ability means that an adversary cannot forge a valid

provenance record either by modifying any existing

one or directly introducing a new forged provenance

record without being detected. Hence, unforgeability

guarantees the tamper evidence (Asghar et al., 2012;

Taha et al., 2015). A ﬁrst attempt to use Trusted Plat-

form Module to ensure trust in provenance genera-

tion had been introduced by Bock et al. (B

ock et al.,

2010). This solution presented a data provenance col-

lection solution using a TPM chip and the AMD Se-

cure Virtual Machine (SVM) technology. This solu-

tion has been enhanced further by Taha et al. (Taha

et al., 2015) by adding the integrity and availability of

the provenance data to the solution.

In our proposed solution Prov-Trust, we leverage

Blockchain technology and trusted hardware; the In-

tel SGX to provide trustworthy and secure provenance

data.

2.2 Security and Functional

Requirements

Prov-Trust has to fulﬁll the following security and

functional requirements, deﬁned as:

• Data Conﬁdentiality of Provenance Data — the

proposed framework has to ensure the secrecy of

collected provenance data as well as associated

meta-data.

• Veriﬁability/Integrity — the integrity of prove-

nance records is important during their storage,

processing, and transport. Given the nature of

most of the provenance data, integrity is gener-

ally considered as the most important assurance

to achieve trustworthy provenance.

• Accountability — accountability refers to the

traceability capability. In fact, as data are stored

and processed in remote servers, a data owner

should be provided with a complete transparent

view over data collection, access and processing

operations.

• Auditability — the proposed solution has to en-

able authorized auditing authorities to initiate an

investigation and obtain consistent proofs when

non-compliant activities have been recorded.

Prov-Trust: Towards a Trustworthy SGX-based Data Provenance System

227

• Privacy Preservation — the privacy requirement

mainly refers to the unlinkability. For instance,

Prov-Trust has to guarantee that created smart

contracts by the same data owner can not be linked

by public veriﬁers as well as non-authorized ser-

vice providers or/and users. Furthermore, BC-

transactions associated to the same data should

not be linked.

3 BACKGROUND

In the following, we introduce the technologies that

we use to develop Prov-Trust. We ﬁrst detail the

trusted hardware Intel SGX in subsection 3.1, then the

Blockchain technology in subsection 3.2.

3.1 Intel SGX

The trusted hardware has been introduced to solve

the issue of secure remote computation, which means

that a user can securely execute a software on a dis-

tant untrusted party. The trusted hardware creates a

secure container enabling a user to upload his soft-

ware and data to the secure container where compu-

tations are performed while protecting their conﬁden-

tiality and integrity. Trusted hardware solutions have

been introduced such as TPM (Main, 2007) and TXT

(Grawrock, 2009).

Intel’s Software Guard Extensions (SGX) is the

latest iteration of designing trusted hardware solu-

tions (McKeen et al., 2013). Intel SGX is a set of

CPU extensions enabling the creation of a trusted iso-

lated execution environments. This isolated execu-

tion environment which is referred to as Enclave, en-

ables running an application residing in the enclave

while protecting its conﬁdentiality and integrity from

other software including an untrusted operating sys-

tem. Physically, the enclave is located inside a hard-

ware guarded area of memory called Enclave Page

Cache (EPC).

Besides isolated code and execution, Intel SGX

enables two more functionalities which are sealing

and attestation. Sealing is deﬁned as the procedures of

storing and encrypting private data on a storage disk

(Intel, 2016; Cui et al., 2018; Kaaniche et al., 2020).

The SGX processor uses a secret key denoted by Root

Seal Key that is physically embedded in the hardware

by the manufacturer. Upon creating the enclave, a seal

key is derived from the root seal key, which will be

used to encrypt and store the existent data once the

enclave is deleted. The second property is the attesta-

tion that is used to prove to a user that his communica-

tion is being performed with a software residing and

running inside the enclave hosted by the Intel SGX

hardware. This attestation is a cryptographic signa-

ture certifying the hash of the contents of the enclave.

The user veriﬁes the attestation key used to generate

the signature against an endorsement certiﬁcate cre-

ated by the trusted hardware’s manufacturer. In a nut-

shell, the SGX attestation enables the user to verify

the creation of the enclave in a trusted SXG, the in-

tegrity of the data and the code loaded into the en-

clave, and creating a secure communication channel

between the enclave and an external user.

3.2 Blockchain Technology

Blockchain has been very popular since its intro-

duction in 2008. Bitcoin

was the ﬁrst blockchain

technology appeared as a means to transfer cryp-

tocurrency without reliance on a central entity which

makes it the ﬁrst fully decentralised transfer system.

Blockchain is a set of transactions grouped to-

gether in a distributed ledger that is relying on a

combination of technologies such as digital signature,

peer to peer networking and cryptographic proof of

work (Swan, 2015). Blockchain is a number of trans-

actions or event recorded and saved in a public ledger

(Crosby et al., 2016). These records are shared by all

network nodes, updated by miners, monitored by ev-

eryone, and owned and controlled by no one (Swan,

2015). These network nodes are end-users using their

personal computers or mobiles while the miners are

nodes that have an extensive computational resources

used to validate the transaction.

In order to implement the decentralised ser-

vices and applications of blockchain, two types of

blockchain exist currently on the market: public

or permissionless blockchain and private or permis-

sioned blockchain. Permissionless blockchain is a

framework built on the existent blockchain technol-

ogy: Bitcoin. This enables the framework to be

more resilient, transparent and secure as Bitcoin is

already utilised by many users. However, permis-

sionless blockchain needs to mine the blocks every 10

minutes and the used scripting language is not Turing-

complete (Swan, 2015).

Permissioned blockchain is a blockchain enabling

the same functionalities as the permissionless one

such as mining the cyptocurrency, full decentralisa-

tion and transactions validation. On top of these func-

tionalities, permissioned blockchain enables estab-

lishing contracts referred to as smart contract along

with an automated and expressive language to write

the smart contracts.

https://bitcoin.org/en/

SECRYPT 2020 - 17th International Conference on Security and Cryptography

228

Recently, permissioned blockchains are witness-

ing an increased interest across multiple domains.

This type of blockchain is considered as a promising

solution to apply blockchain technology in multiple

business applications where end-users do not need to

trust each other neither to be identiﬁed. Ethereum

and the Hyperledger

are among the most known

permissionless blockchains (Wood, 2014). In permis-

sioned blockchain, there exists a central entity that

manages read/write rights operations among partici-

pating peers.

In our proposed solution, Prov-Trust, we rely

on the Hyperledger to store and manage the prove-

nance data. The Hyperledger project is an initiative

launched to facilitate the application of blockchain

technologies in business applications. It provides a

modular consensus protocol ensuring efﬁcient scal-

ability and enhanced performances while executing

thousands of transactions per second (Vukolic, 2017).

It is actually developed and supported by a large con-

sortium of world-leading companies.

4 Prov-Trust: A SGX/Blockchain

BASED DATA PROVENANCE

SCHEME

In this section, we ﬁrst deﬁne the network model

by detailing the different entities involved in Prov-

Trust, in subsection 4.1. Afterwards, we present an

overview of the proposed solution 4.2.

4.1 Network Model

As shown in Figure 1, Prov-Trust involves seven en-

tities, deﬁned as follows:

• Data Owner (DO) — who owns data con-

tents and has sharing relationship on other users’

data, may opt for the provenance service, where

the provenance data is stored on the public

blockchain. A data owner can be a data user in the

case he accesses and makes changes on the doc-

ument where these changes are logged as prove-

nance data.

• Data User (DU) — has access to the document/-

data granted by the owner. He is able to change

the document and log the changes as provenance

trails on the blockchain. Data changes made by

the user can be monitored and validated by vote

nodes, depending on requested changes, but the

https://www.ethereum.org/

https://www.hyperledger.org/

nodes may not know about details of other users’

activities.

• Provenance Auditor (PA) — can retrieve all the

provenance data from the blockchain transactions

and registered events’ logs, w.r.t. associated cre-

dentials. Indeed, only authorized PAs can deci-

pher linking information, re-construct the whole

provenance graphs and correlate the provenance

entry to the data owner.

• Validators (V) — are participants, also referred to

as voters, who vote for/against the change of a set

of provenance change events, namely ”download”

and ”transfer”, using a vote protocol. We assume

that validators may be chosen based on a reputa-

tion system.

• Blockchain Network (BC) — consists of glob-

ally participating nodes. All the provenance data

will be recorded in form of blocks and veriﬁed by

blockchain nodes.

• SGX Enclave — is responsible for processing

user queries and returning results to users with-

out leaking any content and access pattern to the

CS. SGX enclave is also considered to be trusted.

In particular, both integrity and conﬁdentiality of

the code and data inside the enclave are protected

with inherent cryptographic mechanisms. Based

on the cryptographic signature provided by the

SGX, information provided by SPADE client are

certiﬁed to be generated by a trusted software.

• Cloud Service Provider (CSP) — offers a cloud

storage service and is responsible for user regis-

tration. CSPs can beneﬁt from the Prov-Trust sys-

tem in the following aspects. First, they are able

to audit the publicly available data changes. In ad-

dition, through provenance data, they can also de-

tect intrusion from anomalous behaviours, when

privileges are granted .

4.2 Overview

Prov-Trust relies on three main layers, supporting dif-

ferent execution steps (i) the system initialisation, de-

noted as SYS INIT, (ii) the data provenance storage

phase, i.e., STORAGE, and (iii) the auditing process,

referred to as AUDIT. In the following, we provide an

overview of different execution layers and detail the

interaction ﬂow between entities (Figure 2):

During the SYS

INIT phase, the system is set up

and each entity is assigned with a pair public and pri-

vate keys. Indeed, SGX enclaves are installed on their

respective hosting devices and provided with associ-

ated keys.

Prov-Trust: Towards a Trustworthy SGX-based Data Provenance System

229

CSP

Block

Header i

Block

Header

i-1

Block

Header

i+1

CSP

Provenance

Database

Validators/Miners

Verification

script

Store/access data

User

Data

Owner

SPADE

client

SPADE

client

SPADE

client

SGX Enclave

SPADE

client

SGX Enclave

SPADE

client

SGX Enclave

Provenance

Auditor

Figure 1: Prov-Trust Architecture.

Data Owner

Service Provider

Smart Contract

Voters BC

Public Parameters

Secret Keys

SYS-INIT

STORAGE

Smart Contract Creation

(prov-doc and vote-doc)

Smart Contract Creation Transaction Signed by SGX

Access/Versioning

Operations

prov-doc SC Launch

Storage of prov-doc Logs Signed by SGX

Download/Transfer

Operations

vote-doc SC Launch

Voters Invited

Processing Transaction

Figure 2: Prov-Trust Workﬂow.

The STORAGE phase encompasses two main proto-

cols, namely the Create and Evt.

During the Create protocol, the DO has ﬁrst to

create a smart contract (SC), denoted by prov-doc,

per data ﬁle that he intends to track its change/access

events. The prov-doc contains the Access Control

List (ACL) on the data content, i.e., which actions

and/or entities are authorized. It also contains the

ACL on the events’ logs of the associated smart con-

tract. Note that the creation of prov-doc has to be

anchored into a BC transaction.

The DO may also –optionally– createa vote smart

contract associated with the prov-doc smart contract.

The vote SC, referred to as vote-doc, describes the

voting protocol associated with the related data ﬁle.

It speciﬁes the process of voting and the choice of

voters.

The vote-doc smart contract is mainly required

to validate both the download and transfer actions.

Note that the vote is not necessary as the data owner

may directly grant the permission to the requesting

entity.

For the Evt, two sub-cases are considered, de-

pending on the design choice of the DO. On one

hand, when a DU wants to perform some actions on a

data ﬁle, excluding the download and transfer ac-

tions, an event log will be added to the thread of the

prov-doc smart contract. Note that each event log

has to be signed by the SGX enclave of the requesting

entity. On the other hand, when DU wants to do ei-

SECRYPT 2020 - 17th International Conference on Security and Cryptography

230

ther a download or a transfer action, the vote-doc

smart contract is called. At the end of the vote pro-

cess, a BC transaction needs to be added including

the vote result, and signed by a chosen voter.

For the AUDIT phase, Prov-Trust considers two

auditing processes. In fact, the auditing process can

be performed either by the DO or an authorized prove-

nance auditor. As several parts of the event logs and

BC transactions are encrypted, the chaining process,

permitting the PA to reconstruct the provenance graph

associated to a speciﬁc data ﬁle, is ensured as de-

scribed in (Kaaniche and Laurent, 2018).

5 Prov-Trust PHASES

In this section, we present the concrete construction

of Prov-Trust phases.

5.1 System Initialisation

The SYS INIT phase includes two different algo-

rithms, deﬁned as follows:

• Setup(ξ) → (pp, msk) – given the security param-

eter ξ, this algorithm generates the public param-

eters pp.

• KeyGen(pp, E

) → (pk

,sk

) – derives the pub-

lic and private keys of an entity E

, where E ∈

{DO,DU,PA,V }, i ∈ {1, N}; N is the number

of actors supported by the system. It takes

as input pp and the entity’s identiﬁer E

. The

KeyGen algorithm returns the entity’s pair of keys

(pk

,sk

We assume that each device d

, running the SPADE

tool, i.e., data provenance algorithm, has a private

key denoted by k

. This proprietary key is used to

sign events associated to DO’s data ﬁles. Note that

a DO may have several devices, thus running differ-

ent enclaves on each device. Similarly, the CSP runs

a different SGX enclave with respect to each storage

server.

5.2 Data Provenance Storage

As introduced above, the data provenance STORAGE

phase relies on the Create and Evt protocols.

5.2.1 The Create Process

The Create protocol deﬁnes the process of creating

smart contracts associated to data contents. First, the

DO ﬁrst creates the prov-doc smart contract, per data

ﬁle that he intends to track its access and processing

events. The prov-doc contains two main parts : the

Access Control List (ACL) on both the data content,

i.e., which actions and/or entities are authorized, and

the events’ logs. Note that for ease of presentation,

we refer to ACLs to any access control mechanism se-

lected by the DO, to be enforced on his data. ACLs on

data contents may be encrypted, however, they have

to be accessible to the CSP, the PA as well as vot-

ers, if a voting smart contract was created. ACLs on

provenance data should ensure the access to involved

parties, with respective privileges, as implied by legis-

lation, namely data owners, data processors and con-

trollers, and auditing authorities.

For this purpose, DO establishes a direct secure

channel with the CSP, where CSP and DO authenti-

cate each other thanks to their respective (pk

,sk

)

pair of keys (cf. Section 5.1). The creation of

prov-doc has to be anchored into a BC transaction.

The transaction is identiﬁed with a T

parameter.

Through this channel, DO might initiate a data storage

request to the CSP, to infer some parameters for the

smart contract prior to launching the smart contract

into the blockchain, up-to the approval of the contract

by the CSP and transmission of data to its servers.

This process is then registered in the blockchain

by the involved CSP, such as a SC creation transaction

is added. It is deﬁned as follows:

= {T

id,C

,C,SC

,σ

CSP

}

• T

id,C

– denotes the transaction identiﬁer, which

contains a unique fresh random and a binary iden-

tiﬁer associated with the SC generation process.

• C – refers to the type of the transaction: it corre-

sponds here to the creation of a smart contract.

• SC

– is the smart contract identiﬁer.

• σ

CSP

– is the signature of all the above ﬁelds, by

the SGX enclave of the storing server, approving

the SC as well as the associated ACLs.

Note that the transaction identiﬁer id

is then shared

with the server S and the corresponding user DO. As

presented in section 4.2, the DO may also create a

vote-doc contract that deﬁnes the voting protocol as-

sociated with the corresponding data ﬁle and the pro-

cess of voting and the choice of voters

(Remark 1).

The vote-doc smart contract is mainly required to

validate both the download and transfer actions,

detailed in subsection 5.2.2.

Remark 1. Blockchain-based Reputation Systems.

Reputation systems are important for distributed ap-

For ease of presentation, we will not detail the process

of the voting process. Note that, in our proof of concept,

we implemented a threshold-based voting protocols, while

precisely identifying the voting nodes.

Prov-Trust: Towards a Trustworthy SGX-based Data Provenance System

231

plications in which users have to be made account-

able for their actions, namely e-commerce websites.

The Blockchain technology is suitable for supporting

reputation systems thanks to its intrinsic properties,

namely integrity and availability of registered infor-

mation (Li et al., 2018). Thus, Prov-Trust may employ

a reputation system for validators, i.e., voters, where

raters are BC clients. That is, each validator’s rate

depends on the set of performed honest rating and de-

tected malicious actions.

Prov-Trust considers the behavior of all participating

raters for the reliability of the data. If a validator has

high reputation value, it will be frequently selected by

owners, users and service providers. For this purpose,

we set t as the threshold value of reputation, such that

if the validator’s reputation is greater than t, so it is

considered as honest. The reputation value assigned

to each validator is multi-dimensional, which is based

on clients and providers’ positive and negative rates

as well as on rates given by authorized auditors (c.f.,

Table 1). As such, two weight values α and β are de-

ﬁned to calculate the resulting rate for each validator

as R

= αR

aud

+ βR

int

, where R

aud

is the score com-

puted based on auditors rates and R

int

is the score

computed based on users and servers rates.

Table 1: Validator’s Score Table.

Type Activity Score

continuous selection 1.0

positive recommended selection 0.75

favorite 0.25

blacklist −1.0

negative not recommended −0.5

The R

int

is based on the positive activity, denoted by

pos and negative activity, denoted by neg, computed

as:











pos =

∑

i=1

∑

CSP

j=1

∑

k=1

pos

i jk

neg =

∑

i=1

∑

CSP

j=1

∑

k=1

neg

i jk

int

[

pos

CSP

] +

[

neg

CSP

]

where: n

is the number of participating own-

ers, n

CSP

is the number of participating servers, n

the number of positive activities, n

is the number of

negative activities

5.2.2 The Evt Process

The Evt process deﬁnes the chronological steps for

(i) endorsing transactions associated with the retrieval

and transfer of data contents, and (ii) prov-doc logs

associated with data ﬁles’ access and versioning.

Note that these logs are not anchored as transactions,

however, they are pinned as SGX-based provenance

data and associated to the corresponding SC.

The vote-doc SC is performed, once a download

or transfer query is initiated. Note that both queries

refer to the transfer of data contents to another en-

tity, i.e., download corresponds to the transfer for

data users, transfer is related to data processors’

queries. The transfer query launches the execution

of the vote-doc smart contract, w.r.t. the requesting

CSP and a transaction is added by the CSP to the BC

deﬁned as:

: (T

id,T

;T ; s

,id

CSP

;σ

,enc(M

CSP

);σ

CSP

)

• T

id,T

– denotes the transaction identiﬁer, which

contains a unique fresh random and a binary iden-

tiﬁer associated with the transfer process.

• T – refers to the type of the transaction, i.e., trans-

fer query.

• (s

,id

CSP

) – s

is the transfer session identiﬁer

with the corresponding processing entity, where

CSP

denotes its associated identiﬁer.

• V

– represents the result of the voting process.

• σ

– is the signature of the voting process’s result

concatenated with the session identiﬁer s

• enc(M

CSP

) – represents the encryption of a mes-

sage M

CSP

, based on an ABE mechanism, i.e.,

enc

ABE

, where M

CSP

contains two different mes-

sages as M

CSP

= T

id,C

||T

id,T /D

, where T

id,C

is the

creation transaction identiﬁer and T

id,T /D

is the

previous transaction identiﬁer added by the SGX

enclave of the processing server, w.r.t. the process

on the DO’s outsourced or collected data. Notice

that T

id,C

enables PA to check granted privileges

w.r.t. outsourced data contents in CSP servers.

• σ

CSP

– is the signature of all the above ﬁelds, by

the SGX enclave of the storing server.

Remark 2. Multi-level Encryption of Data Usage

Transaction’s History. Note that CSPs may rely on

a multi-level ABE scheme (Kaaniche and Laurent,

2017),(Kaaniche et al., 2018), to encrypt their mes-

sages M

CSP

and M

CSP

respectively. That is, de-

pending on their associated credentials (i.e; certi-

ﬁed attributes), authorized authorities can access to

a sub-sets of the encrypted message M

CSP

deﬁned as

CSP

= T

id,C

||T

id,T /D

. For instance, the authorized

provenance auditor PA may be allowed to only check

the consistency of the actual transaction.

Similarly, the download query is anchored in a

transaction such as

: (T

id,D

;D;s

,id

,σ

,enc(M

CSP

);σ

CSP

)

• T

id,D

– denotes the transaction identiﬁer, which

contains a unique fresh random and a binary iden-

tiﬁer associated with the download process.

SECRYPT 2020 - 17th International Conference on Security and Cryptography

232

• D – refers to the type of the transaction, i.e., down-

load query.

• (s

,id

) – s

is the download session identiﬁer

with the corresponding user, where id

denotes

its DU identity. Note that DU identity can be re-

placed by authorized users group identiﬁer.

• V

– represents the result of the voting process.

• σ

– is the signature of the voting process’s result

concatenated with the session identiﬁer s

• enc(M

CSP

) – represents the encryption of M

CSP

i.e., containing two messages such as M

CSP

id,C

||T

id,T /D

, where T

id,C

is the creation transac-

tion identiﬁer and T

id,T /D

is the previous transac-

tion identiﬁer added by the SGX enclave of the

processing server, w.r.t. the process on the DO’s

outsourced or collected data.

• σ

CSP

– is the signature of all the above ﬁelds, by

the SGX enclave of the storing server.

Remark 3. Update of Granted Privileges. When

a data owner DO wants to change granted

privileges to a given CSP, a consent negoti-

ation should be conducted and a new trans-

action is added to the blockchain, such that

id,U

,U, su

,enc

ABE

(ACL

||T

id,C

),σ

CSP

}, such

that T

id,U

is the transaction update identiﬁer, su

is the session identiﬁer, enc

ABE

(ACL

||T

id,C

) is the

encryption of updated access privileges associated

with the creation transaction identiﬁer and σ

CSP

the signature of all the previous ﬁelds, by the SGX

enclave of the storing server.

5.3 Auditing

Prov-Trust supports three levels of auditing capabili-

ties, referred to as, public auditing, data owner audit-

ing, data provenance auditing.

First, the public auditing may be run by end-users,

while investigating the consistency between different

BC transactions. The main public process relies on

verifying enclaves’ signatures across endorsed trans-

actions. Note that relying on their granted privileges,

certain users may access related data, for instance, by

deciphering the ﬁrst level of ABE scheme, associated

with the previous process transaction.

Second, the data owner auditing consists of veri-

fying the storage and processing of his own data con-

tents, outsourced to different CSPs. Note that DOs

are not able neither to link other DOs’ transactions,

nor identify them.

Finally, the data provenance auditing permits

provenance auditors to audit service providers, i.e.,

verifying the fulﬁlment of ACLs’ requirements, the

compliance with legislation, the consideration of

clients’ given consents, ···. For this purpose, the

authorized PA identify the creation transactions, as

well as associated processing and granted privileges

update transactions, and compare the consistency of

information with SC history logs and provenance

database. On the other side, when a data owner re-

quests a private audit for a misuse of his personal

data, he shares the creation identiﬁers of the suspected

smart contracts with the PA. As such, the auditing au-

thority is able to lead an investigation, i.e., interpret

the content of blockchain transactions associated by

the provenance database and to detect non-compliant

activities, while crawling blockchain transactions cor-

responding to the provided smart contracts’ identi-

ﬁers, We note that private auditing has to be paid by

the audited service provider, if non-compliant activi-

ties are reported.

6 SECURITY AND PRIVACY

DISCUSSION

This section ﬁrst introduces the considered adver-

saries. Then, it discusses the security and privacy

guarantees, as detailed in subsection 2.

6.1 Threat Model

The Prov-Trust system considers two types of attack-

ers: an external adversary and an internal adversary,

deﬁned as follows:

• The External Adversary: is a user who is not au-

thorized to the document in the system, but is able

to modify the provenance data of the outsourced

document, i.e., including SC events and history

logs. The external adversary does not have neither

access to the location of the storing server nor the

deciphering key. The attacker can only know the

document identiﬁer and exploit it to launch an at-

tack against the blockchain based data provenance

system. We assume that the adversary can not cor-

rupt the information transmitted between SGX en-

clave and users.

• The Internal Adversary: is an entity who is

granted access to the document by the owner in

the Prov-Trust system. This adversary is able to

makes changes over the document and therefore

log these operations on the blockchain as prove-

nance data. An internal attacker is unable to grant

access to another user over this document which

is assumed not his own document. However, this

Prov-Trust: Towards a Trustworthy SGX-based Data Provenance System

233

attacker can try to log corrupted provenance data

in the blockchain.

We assume that the cloud provider is not fully trusted

and all the outsourced data ﬁles are encrypted. Once

the data provenance service is enabled, the user will

be able to trace the data and the provenance auditor is

allowed to access all the provenance trails.

6.2 Security and Privacy Analysis

This section discusses the security properties, with

respect to the deﬁned threat model. Indeed, the pri-

vacy preservation (subsection 6.2.1), conﬁdentiality

(subsection 6.2.2), auditability (subsection 6.2.3) and

availability (subsection 6.2.4) are analysed while con-

sidering different adversaries.

6.2.1 Privacy Preservation

As detailed in subsection 2.2, the privacy property is

beyond the conﬁdentiality guarantee and mainly con-

siders the unlinkability feature and is ensured in the

Prov-Trust approach thanks to the following features:

• signed transactions with several SGX-enclaves –

linking smart contracts in between as issued by

the same owner is not possible, as smart con-

tracts’ creation transaction are signed by the SGX-

enclaves of the processing servers. As such, a

search over the blockchain ledger for the same

signing enclaves (assumed to match the same

owner) is inconclusive, as the processing server is

storing data contents of different owners and the

same data content can be stored by several servers

(for replication purposes).

• one smart contract per a data ﬁle – each smart con-

tract is speciﬁc to a data ﬁle and has its own iden-

tiﬁer, a randomly generated value. Thus, it is even

not possible to link two smart contracts provided

with two different IDs to the same owner.

6.2.2 Conﬁdentiality

Prov-Trust is resistant against data secrecy attacks

against data provenance trials, as discussed here-after:

• only freshly and randomly generated identiﬁers

and enciphered information are published in the

BC infrastructure – the DO is in charge of spec-

ifying the ACLs w.r.t. the data ﬁle and its re-

lated provenance trials, while associating a ran-

dom identiﬁer. The data ﬁle identiﬁer is pub-

lished only once, in the creation transaction of the

prov-doc smart contract. For other processing

transaction, the ﬁle identiﬁer is enciphered using a

-multi-level- ABE scheme (Belguith et al., 2018a;

Belguith et al., 2018c; Belguith et al., 2018b), and

is only accessible by a group of authorized enti-

ties.

• ﬁne-grained encrypted access to data – data con-

tents and provenance trials are protected thanks to

the usage of both ACLs and a -multi-level- ABE

scheme (Kaaniche and Laurent, 2017). Recall

that, on one side, ACLs refer to any access control

mechanism selected by the DO, to be enforced on

his data. ACLs on data contents may be encrypted

-up-to the DO-, however, they have to be accessi-

ble to the CSP, the PA as well as voters, if a voting

smart contract was created. ACLs on provenance

data ensure the access to involved parties, with

respective privileges. On the other side, multi-

level ABE applied on processing transactions en-

sure ﬁne-grained access to data provenance trails

by authorized PAs, and enhance unlinkability of

processing actions on DO’s data by external ad-

versaries.

As the public ledger only registers random values or

encrypted information, no signiﬁcant information can

be learnt from the blockchain.

6.2.3 Auditability

The proposed approach ensures the auditability re-

quirement as follows:

• signed transactions – the Prov-Trust solution re-

lies on signed transactions, by the SGX-enclaves

of the storing server. Thus, both smart contract

creation and data processing transactions must be

signed by the involved entities, i.e, SGX enclaves

and validators respectively. Signed transactions

ensure that each activity has been efﬁciently per-

formed by the holder of the used private key,

which is certiﬁed by the device’s manufacturer.

As such, the resistance of the chosen signature

scheme against forgery attacks has a direct impact

on the fulﬁllment of the auditability requirement

(Intel, 2016), (Laurent et al., 2018).

• approval of smart contracts creation – the service

provider is requested to approve each smart con-

tract creation by the data owner DO, by using the

secret key associated with the SGX enclave of the

involved storing server. More precisely, the signa-

ture σ

CSP

associated with the creation of a partic-

ular smart contract, and to prove its authenticity

and its legitimacy.

• tamper-proof architecture – as emphasized above,

all blockchain-speciﬁc operations, such as trans-

action anchoring activities, are considered as

SECRYPT 2020 - 17th International Conference on Security and Cryptography

234

secure and non-corruptible, thus ensuring non-

tamper proofs of data processing and managing

events (Laurent et al., 2018).

• transparent usage – the proposed approach is

based on a consortium blockchain infrastructure,

that permits public access (i.e; read privilege) the

contract and its associated transactions, to anyone.

Thus, it provides a transparent view over how data

are collected and accessed.

6.2.4 Availability

The Prov-Trust solution ensures availability assur-

ance and liveness guarantees of data usage, as re-

lying on a highly decentralized infrastructure. We

also point out the similarity between the well known

double spending problem in bitcoin architectures

(Karame et al., 2015) and the attack aiming at pre-

venting a valid transaction to be registered in the

blockchain. Indeed, both assume that an adversary

has control over more than a half of the blockchain

nodes, the achievement of which is assumed difﬁcult

(Karame et al., 2015).

7 PROOF OF CONCEPT

In order to evaluate the performances and the de-

ployment of the proposed Prov-Trust solution, we

ﬁrst created a BC-testing environment for our prove-

nance architecture and started by implementing the

vote protocol along with the Access Control func-

tionality. For our implementation, we had to choose

one of two blockchain options: Ethereum or the Hy-

perledger. We have chosen the second as it enables

a general description of transactions while provid-

ing users with tools to develop their own personal-

ized blockchains adapted to the needs of their busi-

nesses. Hyperledger

is an open source collabora-

tive project hosted by The Linux Foundation. It is

not a blockchain technology on itself but it is more a

strategy combining multiple blockchain platforms to

develop enterprise-oriented solutions. We have cho-

sen Hyperledger Composer to be deployed the Trust-

Prov underlying technology as it is more adapted to

create the access control functions and to evaluate

the solution smoothly. Hyperledger Composer sup-

ports the existing Hyperledger Fabric blockchain in-

frastructure and runtime, which supports pluggable

blockchain consensus protocols to ensure that trans-

actions are validated according to policy by the des-

ignated business network participants. Hyperledger is

https://www.hyperledger.org

built with javascript language and supports modern

tools including node.js, npm, and CLI.

In the following, we introduce the proof-of-

concept implemented by developing the vote protocol

based on the Hyperledger Composer framework while

deﬁning an access control list that is checked by the

voters to grant access to the different users.

To implement the vote-doc smart contract, we

start by deﬁning the access rights for different types

of entities where we differentiate between two types:

data users and data owners, also called clients. Clients

creates the data ﬁle and upload it on the cloud storage

service while users access, read or modify it. Both are

identiﬁed with two different identiﬁers: clientId for

data owners and userId for data users. An example of

the deﬁned access control list is shown in Listing 1.

Listing 1: An example of the Access Control List.

r u l e P a r t i c i p a n t S y s t e m {

d e s c r i p t i o n : ” G r a n t any p a r t i c i p a n t s t h e r i g h t t o s e e

e v e r y r e s o u r c e ”

p a r t i c i p a n t : ” o rg . v o t e . U t i l i s a t e u r ”

o p e r a t i o n : READ

r e s o u r c e : ”

”

a c t i o n : ALLOW

}

r u l e Con t r i b u t o r H a s R i g h t T o R e a d {

d e s c r i p t i o n : ” I f a u s e r c o n t r i b u t e s to a d oc ument , he has

a c c e s s t o

t h e d oc ume nt ”

p a r t i c i p a n t ( u s e r ) : ” o r g . v o t e . U t i l i s a t e u r ”

o p e r a t i o n : READ, UPDATE

r e s o u r c e ( do c ) : ” o r g . v o t e . Document ”

c o n d i t i o n : ( doc i n u s e r . d o c u m e n t s M o d i f i a b l e s )

a c t i o n : ALLOW

}

r u l e OwnerHasRightToReadAndUpdate {

d e s c r i p t i o n : ” The c l i e n t h a s alwa y s t h e r i g h t t o s e e and

u p d a t e t o

a c c e s s i t s own doc ument ”

p a r t i c i p a n t ( c l i e n t ) : ” o r g . v o t e . C l i e n t ”

o p e r a t i o n : READ, UPDATE

r e s o u r c e ( do c ) : ” o r g . v o t e . Document ”

c o n d i t i o n : ( c l i e n t . g e t I d e n t i f i e r ( ) = = doc . owne r .

g e t I d e n t i f i e r ( ) )

a c t i o n : ALLOW

}

r u l e Us e r HasR i g h t ToCr e a t eABl o c k {

d e s c r i p t i o n : ” U s e r s c a n r i g h t i n t h e bl o c k c h a i n ”

p a r t i c i p a n t : ” o rg . v o t e . U t i l i s a t e u r ”

o p e r a t i o n : CREATE

r e s o u r c e : ” o r g . v o t e . m o d i f ierDo c u m e n t ”

a c t i o n : ALLOW

}

We deﬁne assets by the documents created by a user,

where each document is identiﬁed by its unique iden-

tiﬁer documentId. We also deﬁne two events related

to the type of actions performed on the data ﬁle. The

ﬁrst event is related to the modiﬁcation of the doc-

ument while the second is related to the update of

granted privileges, i.e., addition of a user to the list

of participants authorized to access the data content.

we also deﬁne two transactions related to either the

modiﬁcation of the assets, i.e., the document or the

modiﬁcation of the list of participants. Each transac-

tion is followed by the related event. In other words,

one transaction is related to the change in the access

Prov-Trust: Towards a Trustworthy SGX-based Data Provenance System

235

rights of users by adding new users. The second trans-

action initiates the vote protocol and implement the

modiﬁcation (i.e., download) of the data ﬁle based on

the vote result as shown in Figure2. If the vote is suc-

cessful the event is published in the blockchain (c.f.,

Listing 3).

Listing 2: The event publication.

l e t doc u m e n t M o d i f i c a t i o n E v e n t = g e t F a c t o r y ( ) . n ew Event (NS ,

’ docume n t M o d i f i c a t i o n ’ ) ;

d o c u m e n t M o d i f i c a t i o n E v e n t . r e s u l t a t = f a l s e ;

d o c u m e n t M o d i f i c a t i o n E v e n t . p r o t o c o l e V o t e =maj . p r o t o c o l e V o t e ;

i f ( maj . p r o t o c o l e V o t e ==”MAJORITE”) {

i f ( nbOui>nbNon ){

d o c u m e n t M o d i f i c a t i o n E v e n t . r e s u l t a t = t r u e ;

}

i f ( maj . p r o t o c o l e V o t e ==”UNANIMITE ” ) {

i f ( nbNon ==0){

d o c u m e n t M o d i f i c a t i o n E v e n t . r e s u l t a t = t r u e ;

}

Listing 3: The vote protocol implementation.

i f ( d o c u m e n t M o d i f i c a t i o n E v e n t . r e s u l t a t == t r u e ) {

a w a i t d o c u m e n t R e g i s t r y . u p d a t e ( doc um ent ) ;

}

d o c u m e n t M o d i f i c a t i o n E v e n t . d o cum e n tId=d ocu me nt .

g e t I d e n t i f i e r ( ) ;

d o c u m e n t M o d i f i c a t i o n E v e n t . u t i l i s a t e u r I d = c o n t r i b u t e u r I d ;

d o c u m e n t M o d i f i c a t i o n E v e n t . c h a i n e R e m p l a cee = c h a i n e Remplacee ;

d o c u m e n t M o d i f i c a t i o n E v e n t . c h a i n e I n s e r e e =maj . c h a i n e I n s e r e e ;

e m i t ( d o c u m e n t M o d i f i c a t i o n E v e n t ) ;

}

The solution can be tested using the graphic interface

provided by Composer Playground. It is necessary

to load the different ﬁles such as permission, query

and transaction ﬁles. For more information, the im-

plementation ﬁles are accessible in Github

8 CONCLUSION

Prov-Trust is a distributed data provenance architec-

ture designed to ensure a secure, tamper-proof and

privacy preserving provenance data in cloud com-

puting systems. It is relying on a novel use of In-

tel SGX trusted hardware to collect provenance data

while storing them in Blockchain using transactions

and smart contracts. Prov-Trust provides a secure and

authorized auditing function to enable an auditor or

the data owner to verify the operations performed over

the data stored in cloud storage services. A security

and privacy analysis has been detailed to prove the

fulﬁllment of the deﬁned requirements. We have also

presented a proof of concept of the proposed system

by implementing the vote system.

https://github.com/nathanael-denis/blockchain-

vote/blob/master/blockchain-based-voting-

system/lib/logic.js

As future work, we aim to ﬁnish the implemen-

tation of Prov-Trust and test the performance of the

data provenance generation within the Intel SGX be-

sides adding more sophisticated encryption and pri-

vacy preserving schemes while storing and auditing

the data stored in blockchain.

ACKNOWLEDGMENTS

This material is based upon work supported by

the National Science Foundation under Grant ACI-

1547467. Any opinions, ﬁndings, and conclusions or

recommendations expressed in this material are those

of the authors and do not necessarily reﬂect the views

of the National Science Foundation.

REFERENCES

Asghar, M. R., Ion, M., Russello, G., and Crispo, B. (2012).

Securing data provenance in the cloud. In Open prob-

lems in network security, pages 145–160. Springer.

Belguith, S., Kaaniche, N., and Hammoudeh, M. Anal-

ysis of attribute-based cryptographic techniques and

their application to protect cloud services. Transac-

tions on Emerging Telecommunications Technologies,

page e3667.

Belguith, S., Kaaniche, N., Laurent, M., Jemai, A., and

Attia, R. (2018a). Phoabe: Securely outsourcing

multi-authority attribute based encryption with policy

hidden for cloud assisted iot. Computer Networks,

133:141–156.

Belguith, S., Kaaniche, N., Mohamed, M., and Russello,

G. (2018b). C-absc: cooperative attribute based sign-

cryption scheme for internet of things applications.

In 2018 IEEE International Conference on Services

Computing (SCC), pages 245–248. IEEE.

Belguith, S., Kaaniche, N., Russello, G., et al. (2018c).

Lightweight attribute-based encryption supporting ac-

cess policy update for cloud assisted iot. In Proceed-

ings of the 15th International Joint Conference on

e-Business and Telecommunications-Volume 1: SE-

CRYPT, pages 135–146. SciTePress.

ock, B., Huemer, D., and Tjoa, A. M. (2010). Towards

more trustable log ﬁles for digital forensics by means

of “trusted computing”. In 2010 24th IEEE Interna-

tional Conference on Advanced Information Network-

ing and Applications, pages 1020–1027. IEEE.

Crosby, M., Pattanayak, P., Verma, S., and Kalyanaraman,

V. (2016). Blockchain technology: Beyond bitcoin.

Applied Innovation, 2:6–10.

Cui, S., Belguith, S., Zhang, M., Asghar, M. R., and Rus-

sello, G. (2018). Preserving access pattern privacy in

sgx-assisted encrypted search. In 2018 27th Interna-

tional Conference on Computer Communication and

Networks (ICCCN), pages 1–9. IEEE.

Gehani, A. (2016). https://github.com/ashish-gehani/spade.

SECRYPT 2020 - 17th International Conference on Security and Cryptography

236

Gehani, A. and Tariq, D. (2012). c. In Proceedings of

the 13th International Middleware Conference, Mid-

dleware ’12, pages 101–120, New York, NY, USA.

Springer-Verlag New York, Inc.

Grawrock, D. (2009). Dynamics of a Trusted Platform: A

building block approach. Intel Press.

Hasan, R., Sion, R., and Winslett, M. (2009). Preventing

history forgery with secure provenance. ACM Trans-

actions on Storage (TOS), 5(4):1–43.

Intel (2016). Introduction to Intel SGX sealing.

https://software.intel.com/en-us/blogs/2016/05/

04/introduction-to-intel-sgx-sealing. Last accessed:

September 10, 2018.

Kaaniche, N., Belguith, S., and Russello, G. (2018). Ema-

lab: Efﬁcient multi authorisation level attribute based

access control. In International Conference on Net-

work and System Security, pages 187–201. Springer.

Kaaniche, N. and Laurent, M. (2017). Attribute based en-

cryption for multi-level access control policies. In

14th International Conference on Security and Cryp-

tography (SECRYPT).

Kaaniche, N. and Laurent, M. (2018). Bdua: Blockchain-

based data usage auditing. In 2018 IEEE 11th Inter-

national Conference on Cloud Computing (CLOUD),

pages 630–637. IEEE.

Kaaniche, N., Laurent, M., and Levallois-Barth, C. (2020).

Id-based user-centric data usage auditing scheme for

distributed environments. Frontiers in Blockchain,

3:17.

Karame, G., Androulaki, E., Roeschlin, M., Gervais, A.,

and Capkun, S. (2015). Misbehavior in bitcoin: A

study of double-spending and accountability. ACM

Transactions on Information and System Security

(TISSEC), 18(1):2.

Ko, R. K. and Will, M. A. (2014). Progger: An efﬁ-

cient, tamper-evident kernel-space logger for cloud

data provenance tracking. In 2014 IEEE 7th Interna-

tional Conference on Cloud Computing, pages 881–

889. IEEE.

Laurent, M., Kaaniche, N., Le, C., and Vander Plaetse, M.

(2018). A blockchain-based access control scheme. In

15th International Conference on Security and Cryp-

tography (SECRYPT), pages 168–176.

Li, H., Gai, K., Fang, Z., Zhu, L., Xu, L., and Jiang, P.

(2019). Blockchain-enabled data provenance in cloud

datacenter reengineering. In Proceedings of the 2019

ACM International Symposium on Blockchain and Se-

cure Critical Infrastructure, pages 47–55.

Li, Y., Marier-Bienvenue, T., Perron-Brault, A., Wang, X.,

and Par

e, G. (2018). Blockchain technology in busi-

ness organizations: A scoping review. In Proceedings

of the 51st Hawaii International Conference on Sys-

tem Sciences.

Liang, X., Shetty, S., Tosh, D., Kamhoua, C., Kwiat, K.,

and Njilla, L. (2017). Provchain: A blockchain-

based data provenance architecture in cloud environ-

ment with enhanced privacy and availability. In Pro-

ceedings of the 17th IEEE/ACM International Sympo-

sium on Cluster, Cloud and Grid Computing, pages

468–477. IEEE Press.

Main, T. (2007). Part 2 tpm structures. Speciﬁcation ver-

sion, 1.

McKeen, F., Alexandrovich, I., Berenzon, A., Rozas, C. V.,

Shaﬁ, H., Shanbhogue, V., and Savagaonkar, U. R.

(2013). Innovative instructions and software model

for isolated execution. Hasp@ isca, 10(1).

Moreau, L., Clifford, B., Freire, J., Futrelle, J., Gil, Y.,

Groth, P., Kwasnikowska, N., Miles, S., Missier, P.,

Myers, J., et al. (2011). The open provenance model

core speciﬁcation (v1. 1). Future generation computer

systems, 27(6):743–756.

Moreau, L. et al. (2010). The foundations for provenance

on the web. Foundations and Trends® in Web Science,

2(2–3):99–241.

Muniswamy-Reddy, K.-K., Barillari, J., Braun, U., Hol-

land, D. A., Maclean, D., Seltzer, M. I., and Holland,

S. D. (2008). Layering in provenance-aware storage

systems.

Muniswamy-Reddy, K.-K., Holland, D. A., Braun, U., and

Seltzer, M. I. (2006). Provenance-aware storage sys-

tems. In Usenix annual technical conference, general

track, pages 43–56.

Pohly, D. J., McLaughlin, S., McDaniel, P., and Butler, K.

(2012). Hi-ﬁ: collecting high-ﬁdelity whole-system

provenance. In Proceedings of the 28th Annual Com-

puter Security Applications Conference, pages 259–

268.

Ramachandran, A. and Kantarcioglu, M. (2018). Smart-

provenance: A distributed, blockchain based dat-

aprovenance system. In Proceedings of the Eighth

ACM Conference on Data and Application Security

and Privacy, pages 35–42. ACM.

Shetty, S., Red, V., Kamhoua, C., Kwiat, K., and Njilla, L.

(2017). Data provenance assurance in the cloud us-

ing blockchain. In Disruptive Technologies in Sensors

and Sensor Systems, volume 10206, page 102060I. In-

ternational Society for Optics and Photonics.

Suen, C. H., Ko, R. K., Tan, Y. S., Jagadpramana, P., and

Lee, B. S. (2013). S2logger: End-to-end data track-

ing mechanism for cloud data provenance. In 2013

12th IEEE International Conference on Trust, Secu-

rity and Privacy in Computing and Communications,

pages 594–602. IEEE.

Swan, M. (2015). Blockchain: Blueprint for a new econ-

omy. O’Reilly Media, Inc.

Taha, M. M. B., Chaisiri, S., and Ko, R. K. (2015). Trusted

tamper-evident data provenance. In 2015 IEEE Trust-

com/bigdatase/ispa, volume 1, pages 646–653. IEEE.

Vukolic, M. (2017). Rethinking permissioned blockchains.

In Proceedings of the ACM Workshop on Blockchain,

Cryptocurrencies and Contracts, BCC ’17, pages 3–7,

New York, NY, USA. ACM.

Wood, G. (2014). Ethereum: A secure decentralised gen-

eralised transaction ledger. Ethereum Project Yellow

Paper, 151.

Zafar, F., Khan, A., Suhail, S., Ahmed, I., Hameed, K.,

Khan, H. M., Jabeen, F., and Anjum, A. (2017). Trust-

worthy data: A survey, taxonomy and future trends of

secure provenance schemes. Journal of Network and

Computer Applications, 94:50–68.

Prov-Trust: Towards a Trustworthy SGX-based Data Provenance System

237