Towards a Trustworthy SGX-Based Data Provenance System

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

Nesrine Kaaniche1 a, Sana Belguith2 b, Maryline Laurent3 c, Ashish Gehani4 and Giovanni Russello5 1Department of Computer Science, University of Shefﬁeld, Shefﬁeld, U.K. 2School of Science, Engineering and Environment, University of Salford, Manchester, U.K. 3Telecom SudParis, Institut Polytechnique de Paris, France 4Computer Science Laboratory, SRI International, U.S.A. 5Cyber 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 interest, 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 enables 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 curity of data stored in clouds is of great importance, as the user delegates the management of his data to Data provenance refers to the chain of ownership of a a service provider who is not considered as a fully piece of data that covers who created it, who mod- trusted entity. Therefore, data provenance is more ified and accessed it (Moreau et al., 2010). Data and more needed in cloud computing services to en- provenance is important to investigate security inci- sure users’ data auditing and accountability. Man- dents where these data are analysed to detect mali- aging data provenance in clouds is challenging as cious actions, data breaches and access policy viola- these data may reveal private information about the tions. Many solutions have been proposed to collect, stored data or the users. Thus, there is a need to store and manage provenance data (Zafar et al., 2017). protect the provenance data against unauthorized ac- However, many challenges have been raised by these cess while preserving the privacy of users. To address systems as they need to ensure both (i) a secure col- these challenges, several secure provenance systems lection and verifiability/integrity of provenance data, have been introduced. Some systems have imple- and (ii) the confidentiality and secure storage of col- mented cryptographic mechanisms such as homomor- lected data. phic encryption to search over provenance data (As- The increased use of cloud computing services ghar et al., 2012) or attribute based encryption to en- adds new challenges to data provenance systems. Se- sure encrypted access control over provenance data (Belguith et al., ). Some other research works have a https://orcid.org/0000-0002-1045-6445 addressed the secure collection of provenance data re- b https://orcid.org/0000-0003-0069-8552 lying on trusted software and/or hardware tools such c https://orcid.org/0000-0002-7256-3721 as Trusted Platform Module (TPM) (Taha et al., 2015;

225

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 Copyright c 2020 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

SECRYPT 2020 - 17th International Conference on Security and Cryptography

Ko and Will, 2014). Recently, Blockchain technol- sented in Section 5 before introducing the security ogy have been leveraged to ensure a tamper-proof and and privacy analysis in Section 6. The paper is con- available data provenance systems (Li et al., 2019; cluded and future works are presented in Section 8. Ramachandran and Kantarcioglu, 2018). Contributions — In this paper, we present Prov- Trust, an Intel SGX and blockchain based data prove- 2 RELATED WORK AND nance architecture that provides a secure and privacy preserving data provenance generation and storage. REQUIREMENTS Prov-Trust relies on the distributed tamper-proof In this section, we first review data provenance solu- nature of the blockchain technology, cryptographic tions. Then, we details the security and privacy re- techniques and trusted hardware, i.e, Intel SGX to se- quirements that have to be fulfilled by the proposed curely collect and store data provenance while pre- solution. serving the privacy of sensitive information. Opera- tions over data are monitored in real time to collect 2.1 Data Provenance Solutions provenance data, that support the compliance of access control policy enforcement and intrusion detec- Data provenance refers to the chain of ownership of a tion based on provenance middlewares (Gehani and piece of data that covers who created it, who modified Tariq, 2012). and accessed it (Moreau et al., 2010). Data prove- Prov-Trust relies on Intel SGX enclave to ensure a nance is used to investigate security incidents where trusted execution of the provenance kernel to collect, data provenance is analysed to detect malicious ac- store and query provenance records. The use of SGX tions, data breaches and access policy violations. Ex- enclave protects data provenance and users’ creden- tensive research has been conducted on data prove- tials against malicious hosting and processing parties. nance in database, file workflow and operating sys- The Prov-Trust framework does not rely on a trusted tems (Suen et al., 2013) and many provenance man- third party to store provenance data while perform- agement systems have been proposed (Zafar et al., ing their verification using smart contracts and voting 2017). PASS is one of the first systems that have been process. Indeed, a smart contract is used to monitor designed to provide automatic collection and mainte- the changes performed over a document while imple- nance of provenance data (Muniswamy-Reddy et al., menting access control policies and maintaining all 2006). Improved versions of PASS that supports users’ accesses/modification to the document. The the integration of multiple levels of abstractions have vote contract allows a set of designated users to vote been introduced after its first release (Muniswamy- for/against the change of a set of defined provenance Reddy et al., 2008). PASSv2 operates within the change events, namely ”download” and ”transfer”. three levels of abstraction: the system call bound- The storage of the provenance data in Prov-Trust is ary, a workflow specification language, and a domain- done using either the log events of Smart Contracts specific application level. HiFi is a kernel level prove- or blockchain’s transactions depending on the provenance system that uses Linux Security Modules to nance change event, which enables low storage costs. gather provenance data (Pohly et al., 2012). These Finally, Prov-Trust ensures an accurate privacy- generated data can be forensically analysed to detect preserving auditing process based on blockchain malicious activities thanks to the tracking of the ker- traces and achieved thanks to events’ logs are signed nel and application actions within the Linux system. by SGX enclaves, transactions being registered after SPADE (Gehani, 2016) is a provenance middleware each vote session, and enciphering of linking infor- providing users with a framework to collect, store and mation with respect to an attribute based encryption query provenance data that are generally data graphs and re-randomizable encryption schemes (Kaaniche describing the history of processes ran over a piece of and Laurent, 2018). data. Open Provenance Model (OPM) is a methodol- Paper Organization — This paper is organized ogy representing the provenance graphs in three types as follows. Section 2 presents a literature review of of nodes: artifacts, processes and agents (Moreau data provenance solutions while defining security and et al., 2011). functional requirements for the proposed architecture. The emergence of cloud computing created a need An overview of Prov-Trust underlying technologies to adapt/develop provenance systems to track data namely, Blockchain and Intel SGX is introduced in changes in such highly distributed systems. Col- Section 3. Afterwards, we define the network model lecting provenance data is particularly challenging and we present an overview of Prov-Trust phases in in complex systems such as cloud computing that Section 4. The detailed phases of Prov-trust are pre- presents multiple layers of interacting software and

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

hardware. Cloud computing systems are dynamic and contract and Vote contract. The Document Tracker heterogeneous systems involving several components smart contract is used to monitor the operations per- provided by different providers. Many data prove- formed over a given document while the vote contract nance systems have been designed for cloud comput- specifies the voting protocol. A voting process is used ing. SPADEv2 (Gehani, 2016) has been introduced to validate every provenance change event. as an open source tool supporting both graph and re- These solutions do not address a trusted genera- lational database storage and querying in a distributed tion of the provenance data, yet unforgeability is a system which makes it adapted for cloud computing. security requirement that needs to be achieved while S2Logger is a solution designed to capture and visu- generating and storing provenance data. The unforge- alise end-to-end provenance data across all guest and ability means that an adversary cannot forge a valid host physical machines in distributed virtualised envi- provenance record either by modifying any existing ronments such as cloud computing (Suen et al., 2013). one or directly introducing a new forged provenance As provenance data usually contain sensitive in- record without being detected. Hence, unforgeability formation that should be kept secure. Additionally, guarantees the tamper evidence (Asghar et al., 2012; provenance data can be modified or forged by a mali- Taha et al., 2015). A first attempt to use Trusted Plat- cious attacker to mislead investigation and analysis of form Module to ensure trust in provenance genera- events logs. Assuring a trusted data provenance will tion had been introduced by Bock et al. (Bock¨ et al., enable users to verify the operations performed over 2010). This solution presented a data provenance col- their data. Therefore, provenance data should fulfill lection solution using a TPM chip and the AMD Se- a set of security criteria such as confidentiality, in- cure Virtual Machine (SVM) technology. This solu- tegrity, unforgeability,non-repudiation and availabil- tion has been enhanced further by Taha et al. (Taha ity (Zafar et al., 2017). The Secure Provenance et al., 2015) by adding the integrity and availability of (SPROV) scheme is one of the first provenance solu- the provenance data to the solution. tions that considered security features (Hasan et al., In our proposed solution Prov-Trust, we leverage 2009). SPROV automatically collects data prove- Blockchain technology and trusted hardware; the In- nance besides providing security assurances of con- tel SGX to provide trustworthy and secure provenance fidentiality and integrity of these data. Asghar et al. data. (Asghar et al., 2012) designed a secure data provenance storage system that enables secure and pri- 2.2 Security and Functional vacy preserving search over provenance data based on Requirements cryptographic algorithms. To fulfill availability and integrity requirements, Prov-Trust has to fulfill the following security and Blockchain systems have been used to store and man- functional requirements, defined as: age provenance data. Blockchain has been first lever- • Data Confidentiality of Provenance Data — the aged in data provenance systems in 2017 by intro- proposed framework has to ensure the secrecy of ducing Provchain (Liang et al., 2017). Provchain is collected provenance data as well as associated a data provenance system based on blockchain for a meta-data. cloud applications. In Provchain, OPM has been used • Verifiability/Integrity — the integrity of prove- to collect provenance data in real-time. Afterwards, nance records is important during their storage, operations history are saved in blockchain transac- processing, and transport. Given the nature of tions. This enables auditors to validate the operations most of the provenance data, integrity is gener- by consulting the transactions receipts. BlockCloud ally considered as the most important assurance (Shetty et al., 2017) monitors users activities in real to achieve trustworthy provenance. time using special classes of events namely, hooks and listeners that enables the generation of provenance • Accountability — accountability refers to the data. The provenance data are stored in transactions traceability capability. In fact, as data are stored that are broadcasted to the core of blockchain net- and processed in remote servers, a data owner work created by a specific set of validating virtual ma- should be provided with a complete transparent chines. Similar to Provchain solution, the provenance view over data collection, access and processing auditor validates the data using the transactions re- operations. ceipts. SmartProvenance (Ramachandran and Kantar- • Auditability — the proposed solution has to en- cioglu, 2018) applies Ethereum Smart Contracts to able authorized auditing authorities to initiate an provide data provenance. SmartProvenance is based investigation and obtain consistent proofs when on two smart contracts, namely Document Tracker non-compliant activities have been recorded.

227 SECRYPT 2020 - 17th International Conference on Security and Cryptography

• Privacy Preservation — the privacy requirement running inside the enclave hosted by the Intel SGX mainly refers to the unlinkability. For instance, hardware. This attestation is a cryptographic signa- Prov-Trust has to guarantee that created smart ture certifying the hash of the contents of the enclave. contracts by the same data owner can not be linked The user verifies the attestation key used to generate by public verifiers as well as non-authorized ser- the signature against an endorsement certificate cre- vice providers or/and users. Furthermore, BC- ated by the trusted hardware’s manufacturer. In a nut- transactions associated to the same data should shell, the SGX attestation enables the user to verify not be linked. the creation of the enclave in a trusted SXG, the integrity of the data and the code loaded into the enclave, and creating a secure communication channel 3 BACKGROUND between the enclave and an external user.

In the following, we introduce the technologies that 3.2 Blockchain Technology we use to develop Prov-Trust. We first detail the trusted hardware Intel SGX in subsection 3.1, then the Blockchain has been very popular since its intro- Blockchain technology in subsection 3.2. duction in 2008. Bitcoin1 was the first blockchain technology appeared as a means to transfer cryp- 3.1 Intel SGX tocurrency without reliance on a central entity which makes it the first fully decentralised transfer system. The trusted hardware has been introduced to solve Blockchain is a set of transactions grouped to- the issue of secure remote computation, which means gether in a distributed ledger that is relying on a that a user can securely execute a software on a dis- combination of technologies such as digital signature, tant untrusted party. The trusted hardware creates a peer to peer networking and cryptographic proof of secure container enabling a user to upload his soft- work (Swan, 2015). Blockchain is a number of trans- ware and data to the secure container where compu- actions or event recorded and saved in a public ledger tations are performed while protecting their confiden- (Crosby et al., 2016). These records are shared by all tiality and integrity. Trusted hardware solutions have network nodes, updated by miners, monitored by ev- been introduced such as TPM (Main, 2007) and TXT eryone, and owned and controlled by no one (Swan, (Grawrock, 2009). 2015). These network nodes are end-users using their Intel’s Software Guard Extensions (SGX) is the personal computers or mobiles while the miners are latest iteration of designing trusted hardware solu- nodes that have an extensive computational resources tions (McKeen et al., 2013). Intel SGX is a set of used to validate the transaction. CPU extensions enabling the creation of a trusted iso- In order to implement the decentralised ser- lated execution environments. This isolated execu- vices and applications of blockchain, two types of tion environment which is referred to as Enclave, en- blockchain exist currently on the market: public ables running an application residing in the enclave or permissionless blockchain and private or permis- while protecting its confidentiality and integrity from sioned blockchain. Permissionless blockchain is a other software including an untrusted operating sys- framework built on the existent blockchain technol- tem. Physically, the enclave is located inside a hard- ogy: Bitcoin. This enables the framework to be ware guarded area of memory called Enclave Page more resilient, transparent and secure as Bitcoin is Cache (EPC). already utilised by many users. However, permis- Besides isolated code and execution, Intel SGX sionless blockchain needs to mine the blocks every 10 enables two more functionalities which are sealing minutes and the used scripting language is not Turing- and attestation. Sealing is defined as the procedures of complete (Swan, 2015). storing and encrypting private data on a storage disk Permissioned blockchain is a blockchain enabling (Intel, 2016; Cui et al., 2018; Kaaniche et al., 2020). the same functionalities as the permissionless one The SGX processor uses a secret key denoted by Root such as mining the cyptocurrency, full decentralisa- Seal Key that is physically embedded in the hardware tion and transactions validation. On top of these func- by the manufacturer. Upon creating the enclave, a seal tionalities, permissioned blockchain enables estab- key is derived from the root seal key, which will be lishing contracts referred to as smart contract along used to encrypt and store the existent data once the with an automated and expressive language to write enclave is deleted. The second property is the attesta- the smart contracts. tion that is used to prove to a user that his communication is being performed with a software residing and 1https://bitcoin.org/en/

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

Recently, permissioned blockchains are witness- nodes may not know about details of other users’ ing an increased interest across multiple domains. activities. This type of blockchain is considered as a promising • Provenance Auditor (PA) — can retrieve all the solution to apply blockchain technology in multiple provenance data from the blockchain transactions business applications where end-users do not need to and registered events’ logs, w.r.t. associated cre- trust each other neither to be identified. Ethereum2 dentials. Indeed, only authorized PAs can deci- and the Hyperledger 3 are among the most known pher linking information, re-construct the whole permissionless blockchains (Wood, 2014). In permis- provenance graphs and correlate the provenance sioned blockchain, there exists a central entity that entry to the data owner. manages read/write rights operations among participating peers. • Validators (V) — are participants, also referred to In our proposed solution, Prov-Trust, we rely as voters, who vote for/against the change of a set on the Hyperledger to store and manage the prove- of provenance change events, namely ”download” nance data. The Hyperledger project is an initiative and ”transfer”, using a vote protocol. We assume launched to facilitate the application of blockchain that validators may be chosen based on a reputa- technologies in business applications. It provides a tion system. modular consensus protocol ensuring efficient scal- • Blockchain Network (BC) — consists of glob- ability and enhanced performances while executing ally participating nodes. All the provenance data thousands of transactions per second (Vukolic, 2017). will be recorded in form of blocks and verified by It is actually developed and supported by a large con- blockchain nodes. sortium of world-leading companies. • SGX Enclave — is responsible for processing user queries and returning results to users without leaking any content and access pattern to the 4 Prov-Trust: A SGX/Blockchain CS. SGX enclave is also considered to be trusted. BASED DATA PROVENANCE In particular, both integrity and confidentiality of SCHEME the code and data inside the enclave are protected with inherent cryptographic mechanisms. Based In this section, we first define the network model on the cryptographic signature provided by the by detailing the different entities involved in Prov- SGX, information provided by SPADE client are Trust, in subsection 4.1. Afterwards, we present an certified to be generated by a trusted software. overview of the proposed solution 4.2. • Cloud Service Provider (CSP) — offers a cloud storage service and is responsible for user regis- 4.1 Network Model tration. CSPs can benefit from the Prov-Trust system in the following aspects. First, they are able As shown in Figure 1, Prov-Trust involves seven en- to audit the publicly available data changes. In ad- tities, defined as follows: dition, through provenance data, they can also detect intrusion from anomalous behaviours, when • Data Owner (DO) — who owns data con- privileges are granted . tents and has sharing relationship on other users’ data, may opt for the provenance service, where the provenance data is stored on the public 4.2 Overview blockchain. A data owner can be a data user in the case he accesses and makes changes on the doc- Prov-Trust relies on three main layers, supporting dif- ument where these changes are logged as prove- ferent execution steps (i) the system initialisation, de- nance data. noted as SYS INIT, (ii) the data provenance storage • Data User (DU) — has access to the document/- phase, i.e., STORAGE, and (iii) the auditing process, data granted by the owner. He is able to change referred to as AUDIT. In the following, we provide an the document and log the changes as provenance overview of different execution layers and detail the trails on the blockchain. Data changes made by interaction flow between entities (Figure 2): the user can be monitored and validated by vote During the SYS INIT phase, the system is set up nodes, depending on requested changes, but the and each entity is assigned with a pair public and private keys. Indeed, SGX enclaves are installed on their 2https://www.ethereum.org/ respective hosting devices and provided with associ- 3https://www.hyperledger.org/ ated keys.

229 SECRYPT 2020 - 17th International Conference on Security and Cryptography

Store/access data CSP SPADE CSP Data client

Owner SPADE SPADE client client

SGX Enclave SGX Enclave

CSP

SPADE client Provenance SPADE SGX Enclave Auditor client User Verification script

Provenance Database

Block Block Block Header Header i Header i-1 i+1 Validators/Miners Figure 1: Prov-Trust Architecture.

Data Owner Service Provider Smart Contract Voters BC Public Parameters SYS-INIT Secret Keys

Smart Contract Creation STORAGE (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- It specifies the process of voting and the choice of cols, namely the Create and Evt. voters. During the Create protocol, the DO has first to The vote-doc smart contract is mainly required create a smart contract (SC), denoted by prov-doc, to validate both the download and transfer actions. per data file that he intends to track its change/access Note that the vote is not necessary as the data owner events. The prov-doc contains the Access Control may directly grant the permission to the requesting List (ACL) on the data content, i.e., which actions entity. and/or entities are authorized. It also contains the For the Evt, two sub-cases are considered, de- ACL on the events’ logs of the associated smart con- pending on the design choice of the DO. On one tract. Note that the creation of prov-doc has to be hand, when a DU wants to perform some actions on a anchored into a BC transaction. data file, excluding the download and transfer ac- The DO may also –optionally– createa vote smart tions, an event log will be added to the thread of the contract associated with the prov-doc smart contract. prov-doc smart contract. Note that each event log The vote SC, referred to as vote-doc, describes the has to be signed by the SGX enclave of the requesting voting protocol associated with the related data file. entity. On the other hand, when DU wants to do ei-

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

ther a download or a transfer action, the vote-doc events. The prov-doc contains two main parts : the smart contract is called. At the end of the vote pro- Access Control List (ACL) on both the data content, cess, a BC transaction needs to be added including i.e., which actions and/or entities are authorized, and the vote result, and signed by a chosen voter. the events’ logs. Note that for ease of presentation, For the AUDIT phase, Prov-Trust considers two we refer to ACLs to any access control mechanism se- auditing processes. In fact, the auditing process can lected by the DO, to be enforced on his data. ACLs on be performed either by the DO or an authorized prove- data contents may be encrypted, however, they have nance auditor. As several parts of the event logs and to be accessible to the CSP, the PA as well as vot- BC transactions are encrypted, the chaining process, ers, if a voting smart contract was created. ACLs on permitting the PA to reconstruct the provenance graph provenance data should ensure the access to involved associated to a specific data file, is ensured as de- parties, with respective privileges, as implied by legis- scribed in (Kaaniche and Laurent, 2018). lation, namely data owners, data processors and con- trollers, and auditing authorities. For this purpose, DO establishes a direct secure 5 Prov-Trust PHASES channel with the CSP, where CSP and DO authenti- cate each other thanks to their respective (pkEi ,skEi ) pair of keys (cf. Section 5.1). The creation of In this section, we present the concrete construction prov-doc has to be anchored into a BC transaction. of Prov-Trust phases. The transaction is identified with a Tid parameter. Through this channel, DO might initiate a data storage 5.1 System Initialisation request to the CSP, to infer some parameters for the smart contract prior to launching the smart contract The SYS INIT phase includes two different algo- into the blockchain, up-to the approval of the contract rithms, defined as follows: by the CSP and transmission of data to its servers. • Setup(ξ) → (pp,msk) – given the security param- This process is then registered in the blockchain eter ξ, this algorithm generates the public param- by the involved CSP, such as a SC creation transaction eters pp. is added. It is defined as follows: • KeyGen(pp,E ) → (pk ,sk ) – derives the pub- i Ei Ei TC = {Tid,C,C,SCid,σkCSP } lic and private keys of an entity Ei, where E ∈ {DO,DU,PA,V}, i ∈ {1,N}; N is the number • Tid,C – denotes the transaction identifier, which of actors supported by the system. It takes contains a unique fresh random and a binary identifier associated with the SC generation process. as input pp and the entity’s identifier Ei. The KeyGen algorithm returns the entity’s pair of keys • C – refers to the type of the transaction: it corre-

(pkEi ,skEi ). sponds here to the creation of a smart contract.

We assume that each device di, running the SPADE • SCid – is the smart contract identifier. tool, i.e., data provenance algorithm, has a private • σkCSP – is the signature of all the above fields, by key denoted by kEi . This proprietary key is used to the SGX enclave of the storing server, approving sign events associated to DO’s data files. Note that the SC as well as the associated ACLs. a DO may have several devices, thus running differ- Note that the transaction identifier id is then shared ent enclaves on each device. Similarly, the CSP runs T with the server and the corresponding user DO. As a different SGX enclave with respect to each storage S presented in section 4.2, the DO may also create a server. vote-doc contract that defines the voting protocol associated with the corresponding data file and the pro- 5.2 Data Provenance Storage cess of voting and the choice of voters 4 (Remark 1). The vote-doc smart contract is mainly required to As introduced above, the data provenance STORAGE validate both the download and transfer actions, phase relies on the Create and Evt protocols. detailed in subsection 5.2.2. 5.2.1 The Create Process Remark 1. Blockchain-based Reputation Systems. Reputation systems are important for distributed ap- Create The protocol defines the process of creating 4For ease of presentation, we will not detail the process smart contracts associated to data contents. First, the of the voting process. Note that, in our proof of concept, DO first creates the prov-doc smart contract, per data we implemented a threshold-based voting protocols, while file that he intends to track its access and processing precisely identifying the voting nodes.

231 SECRYPT 2020 - 17th International Conference on Security and Cryptography

plications in which users have to be made account- data and associated to the corresponding SC. able for their actions, namely e-commerce websites. The vote-doc SC is performed, once a download The Blockchain technology is suitable for supporting or transfer query is initiated. Note that both queries reputation systems thanks to its intrinsic properties, refer to the transfer of data contents to another en- namely integrity and availability of registered infor- tity, i.e., download corresponds to the transfer for mation (Li et al., 2018). Thus, Prov-Trust may employ data users, transfer is related to data processors’ a reputation system for validators, i.e., voters, where queries. The transfer query launches the execution raters are BC clients. That is, each validator’s rate of the vote-doc smart contract, w.r.t. the requesting depends on the set of performed honest rating and de- CSP and a transaction is added by the CSP to the BC tected malicious actions. defined as: Prov-Trust considers the behavior of all participating TT : (Tid,T ;T;sid,idCSP ;VR;σV ,enc(MCSP );σk ) raters for the reliability of the data. If a validator has B A CSPA high reputation value, it will be frequently selected by • Tid,T – denotes the transaction identifier, which owners, users and service providers. For this purpose, contains a unique fresh random and a binary iden- we set t as the threshold value of reputation, such that tifier associated with the transfer process. if the validator’s reputation is greater than t, so it is • T – refers to the type of the transaction, i.e., trans- considered as honest. The reputation value assigned fer query. to each validator is multi-dimensional, which is based • (sid,idCSPB ) – sid is the transfer session identifier on clients and providers’ positive and negative rates with the corresponding processing entity, where as well as on rates given by authorized auditors (c.f., idCSP denotes its associated identifier. Table 1). As such, two weight values α and β are de- B fined to calculate the resulting rate for each validator • VR – represents the result of the voting process. as RV = αRaud + βRint , where Raud is the score com- • σV – is the signature of the voting process’s result puted based on auditors rates and Rint is the score concatenated with the session identifier sid. computed based on users and servers rates. • enc(MCSPA ) – represents the encryption of a message MCSP , based on an ABE mechanism, i.e., Table 1: Validator’s Score Table. A encABE , where MCSPA contains two different mes- Type Activity Score sages as MCSPA = Tid,C||Tid,T/D, where Tid,C is the continuous selection 1.0 creation transaction identifier and Tid,T/D is the positive recommended selection 0.75 previous transaction identifier added by the SGX favorite 0.25 enclave of the processing server, w.r.t. the process blacklist −1.0 on the DO’s outsourced or collected data. Notice negative not recommended −0.5 that Tid,C enables PA to check granted privileges w.r.t. outsourced data contents in CSP servers.

• σk – is the signature of all the above fields, by The Rint is based on the positive activity, denoted by CSPA pos and negative activity, denoted by neg, computed the SGX enclave of the storing server. as: Remark 2. Multi-level Encryption of Data Usage  n n n pos = ∑ DO ∑ CSP ∑ p pos Transaction’s History. Note that CSPs may rely on  i=1 j=1 k=1 i jk nDO nCSP nn a multi-level ABE scheme (Kaaniche and Laurent, neg = ∑i=1 ∑ j=1 ∑k=1 negi jk 1 pos 1 neg 2017),(Kaaniche et al., 2018), to encrypt their mes-  Rint = [ ] + [ ] 2 nDO+nCSP 2 nDO+nCSP sages MCSPA and MCSPB respectively. That is, de- where: nDO is the number of participating own- pending on their associated credentials (i.e; certi- ers, nCSP is the number of participating servers, np is fied attributes), authorized authorities can access to the number of positive activities, n is the number of n a sub-sets of the encrypted message MCSPi defined as negative activities MCSPi = Tid,C||Tid,T/D. For instance, the authorized provenance auditor PA may be allowed to only check 5.2.2 The Evt Process the consistency of the actual transaction. Similarly, the download query is anchored in a The Evt process defines the chronological steps for transaction such as (i) endorsing transactions associated with the retrieval T (T D s ,id V , ,enc(M ) ) and transfer of data contents, and (ii) prov-doc logs D : id,D; ; id DU ; R σV CSP ;σkCSP associated with data files’ access and versioning. • Tid,D – denotes the transaction identifier, which Note that these logs are not anchored as transactions, contains a unique fresh random and a binary iden- however, they are pinned as SGX-based provenance tifier associated with the download process.

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

• D – refers to the type of the transaction, i.e., down- compliance with legislation, the consideration of load query. clients’ given consents, ···. For this purpose, the • (s ,id ) – s is the download session identifier authorized PA identify the creation transactions, as id DU id well as associated processing and granted privileges with the corresponding user, where idDU denotes its DU identity. Note that DU identity can be re- update transactions, and compare the consistency of placed by authorized users group identifier. information with SC history logs and provenance database. On the other side, when a data owner re- • VR – represents the result of the voting process. quests a private audit for a misuse of his personal • σV – is the signature of the voting process’s result data, he shares the creation identifiers of the suspected concatenated with the session identifier sid. smart contracts with the PA. As such, the auditing authority is able to lead an investigation, i.e., interpret • enc(MCSP) – represents the encryption of MCSP, the content of blockchain transactions associated by i.e., containing two messages such as MCSP = the provenance database and to detect non-compliant Tid,C||Tid,T/D, where Tid,C is the creation transac- activities, while crawling blockchain transactions cor- tion identifier and Tid,T/D is the previous transac- responding to the provided smart contracts’ identi- tion identifier added by the SGX enclave of the fiers, We note that private auditing has to be paid by processing server, w.r.t. the process on the DO’s the audited service provider, if non-compliant activi- outsourced or collected data. ties are reported.

• σkCSP – is the signature of all the above fields, by the SGX enclave of the storing server. Remark 3. Update of Granted Privileges. When 6 SECURITY AND PRIVACY a data owner DO wants to change granted DISCUSSION privileges to a given CSP, a consent negoti- ation should be conducted and a new transaction is added to the blockchain, such that This section first introduces the considered adversaries. Then, it discusses the security and privacy {Tid,U ,U,suid,encABE (ACLup||Tid,C),σk }, such CSP guarantees, as detailed in subsection 2. that Tid,U is the transaction update identifier, suid is the session identifier, encABE (ACLup||Tid,C) is the encryption of updated access privileges associated 6.1 Threat Model with the creation transaction identifier and σkCSP is the signature of all the previous fields, by the SGX The Prov-Trust system considers two types of attack- enclave of the storing server. ers: an external adversary and an internal adversary, defined as follows: 5.3 Auditing • The External Adversary: is a user who is not au- Prov-Trust supports three levels of auditing capabili- thorized to the document in the system, but is able ties, referred to as, public auditing, data owner audit- to modify the provenance data of the outsourced ing, data provenance auditing. document, i.e., including SC events and history First, the public auditing may be run by end-users, logs. The external adversary does not have neither while investigating the consistency between different access to the location of the storing server nor the BC transactions. The main public process relies on deciphering key. The attacker can only know the verifying enclaves’ signatures across endorsed trans- document identifier and exploit it to launch an at- actions. Note that relying on their granted privileges, tack against the blockchain based data provenance certain users may access related data, for instance, by system. We assume that the adversary can not cor- deciphering the first level of ABE scheme, associated rupt the information transmitted between SGX en- with the previous process transaction. clave and users. Second, the data owner auditing consists of veri- • The Internal Adversary: is an entity who is fying the storage and processing of his own data con- granted access to the document by the owner in tents, outsourced to different CSPs. Note that DOs the Prov-Trust system. This adversary is able to are not able neither to link other DOs’ transactions, makes changes over the document and therefore nor identify them. log these operations on the blockchain as prove- Finally, the data provenance auditing permits nance data. An internal attacker is unable to grant provenance auditors to audit service providers, i.e., access to another user over this document which verifying the fulfilment of ACLs’ requirements, the is assumed not his own document. However, this

233 SECRYPT 2020 - 17th International Conference on Security and Cryptography

attacker can try to log corrupted provenance data -multi-level- ABE scheme (Belguith et al., 2018a; in the blockchain. Belguith et al., 2018c; Belguith et al., 2018b), and is only accessible by a group of authorized enti- We assume that the cloud provider is not fully trusted ties. and all the outsourced data files are encrypted. Once the data provenance service is enabled, the user will • fine-grained encrypted access to data – data con- be able to trace the data and the provenance auditor is tents and provenance trials are protected thanks to allowed to access all the provenance trails. the usage of both ACLs and a -multi-level- ABE scheme (Kaaniche and Laurent, 2017). Recall 6.2 Security and Privacy Analysis that, on one side, ACLs refer to any access control mechanism selected by the DO, to be enforced on This section discusses the security properties, with his data. ACLs on data contents may be encrypted respect to the defined threat model. Indeed, the pri- -up-to the DO-, however, they have to be accessi- vacy preservation (subsection 6.2.1), confidentiality ble to the CSP, the PA as well as voters, if a voting (subsection 6.2.2), auditability (subsection 6.2.3) and smart contract was created. ACLs on provenance availability (subsection 6.2.4) are analysed while con- data ensure the access to involved parties, with sidering different adversaries. respective privileges. On the other side, multi- level ABE applied on processing transactions en- 6.2.1 Privacy Preservation sure fine-grained access to data provenance trails by authorized PAs, and enhance unlinkability of As detailed in subsection 2.2, the privacy property is processing actions on DO’s data by external ad- beyond the confidentiality guarantee and mainly con- versaries. siders the unlinkability feature and is ensured in the As the public ledger only registers random values or Prov-Trust approach thanks to the following features: encrypted information, no significant information can • signed transactions with several SGX-enclaves – be learnt from the blockchain. linking smart contracts in between as issued by the same owner is not possible, as smart con- 6.2.3 Auditability tracts’ creation transaction are signed by the SGX- enclaves of the processing servers. As such, a The proposed approach ensures the auditability research over the blockchain ledger for the same quirement as follows: signing enclaves (assumed to match the same • signed transactions – the Prov-Trust solution re- owner) is inconclusive, as the processing server is lies on signed transactions, by the SGX-enclaves storing data contents of different owners and the of the storing server. Thus, both smart contract same data content can be stored by several servers creation and data processing transactions must be (for replication purposes). signed by the involved entities, i.e, SGX enclaves • one smart contract per a data file – each smart con- and validators respectively. Signed transactions tract is specific to a data file and has its own iden- ensure that each activity has been efficiently per- tifier, a randomly generated value. Thus, it is even formed by the holder of the used private key, not possible to link two smart contracts provided which is certified by the device’s manufacturer. with two different IDs to the same owner. As such, the resistance of the chosen signature scheme against forgery attacks has a direct impact 6.2.2 Confidentiality on the fulfillment of the auditability requirement (Intel, 2016), (Laurent et al., 2018). Prov-Trust is resistant against data secrecy attacks • approval of smart contracts creation – the service against data provenance trials, as discussed here-after: provider is requested to approve each smart con- • only freshly and randomly generated identifiers tract creation by the data owner DO, by using the and enciphered information are published in the secret key associated with the SGX enclave of the BC infrastructure – the DO is in charge of spec- involved storing server. More precisely, the signature σ associated with the creation of a partic- ifying the ACLs w.r.t. the data file and its re- kCSP lated provenance trials, while associating a ran- ular smart contract, and to prove its authenticity dom identifier. The data file identifier is pub- and its legitimacy. lished only once, in the creation transaction of the • tamper-proof architecture – as emphasized above, prov-doc smart contract. For other processing all blockchain-specific operations, such as trans- transaction, the file identifier is enciphered using a action anchoring activities, are considered as

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

secure and non-corruptible, thus ensuring non- built with javascript language and supports modern tamper proofs of data processing and managing tools including node.js, npm, and CLI. events (Laurent et al., 2018). In the following, we introduce the proof-of- • transparent usage – the proposed approach is concept implemented by developing the vote protocol based on a consortium blockchain infrastructure, based on the Hyperledger Composer framework while that permits public access (i.e; read privilege) the defining an access control list that is checked by the contract and its associated transactions, to anyone. voters to grant access to the different users. vote-doc Thus, it provides a transparent view over how data To implement the smart contract, we are collected and accessed. start by defining the access rights for different types of entities where we differentiate between two types: 6.2.4 Availability data users and data owners, also called clients. Clients creates the data file and upload it on the cloud storage The Prov-Trust solution ensures availability assur- service while users access, read or modify it. Both are ance and liveness guarantees of data usage, as re- identified with two different identifiers: clientId for lying on a highly decentralized infrastructure. We data owners and userId for data users. An example of also point out the similarity between the well known the defined access control list is shown in Listing 1. double spending problem in bitcoin architectures (Karame et al., 2015) and the attack aiming at pre- Listing 1: An example of the Access Control List. venting a valid transaction to be registered in the rule ParticipantSystem { description: ”Grant any participants the right to see blockchain. Indeed, both assume that an adversary every resource” participant: ”org.vote.Utilisateur” has control over more than a half of the blockchain operation : READ nodes, the achievement of which is assumed difficult r e s o u r c e : ”**” a c t i o n : ALLOW (Karame et al., 2015). } rule ContributorHasRightToRead { description: ”If a user contributes to a document, he has a c c e s s t o the document” participant(user): ”org.vote.Utilisateur” 7 PROOF OF CONCEPT o p e r a t i o n : READ, UPDATE resource(doc): ”org.vote.Document” condition: (doc in user.documentsModifiables) In order to evaluate the performances and the de- a c t i o n : ALLOW } ployment of the proposed Prov-Trust solution, we rule OwnerHasRightToReadAndUpdate { first created a BC-testing environment for our prove- description: ” The client has always the right to see and u p d a t e t o nance architecture and started by implementing the access its own document ” participant(client ): ”org.vote.Client” vote protocol along with the Access Control func- o p e r a t i o n : READ, UPDATE tionality. For our implementation, we had to choose resource(doc): ”org.vote.Document” condition :( client . getIdentifier()==doc.owner. one of two blockchain options: Ethereum or the Hy- getIdentifier ()) a c t i o n : ALLOW perledger. We have chosen the second as it enables } a general description of transactions while provid- rule UserHasRightToCreateABlock { description: ”Users can right in the blockchain” ing users with tools to develop their own personal- participant: ”org.vote.Utilisateur” o p e r a t i o n : CREATE ized blockchains adapted to the needs of their busi- resource :”org.vote.modifierDocument” 5 nesses. Hyperledger is an open source collabora- a c t i o n : ALLOW 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 We define assets by the documents created by a user, develop enterprise-oriented solutions. We have cho- where each document is identified by its unique iden- sen Hyperledger Composer to be deployed the Trust- tifier documentId. We also define two events related Prov underlying technology as it is more adapted to to the type of actions performed on the data file. The create the access control functions and to evaluate first event is related to the modification of the doc- the solution smoothly. Hyperledger Composer sup- ument while the second is related to the update of ports the existing Hyperledger Fabric blockchain in- granted privileges, i.e., addition of a user to the list frastructure and runtime, which supports pluggable of participants authorized to access the data content. blockchain consensus protocols to ensure that trans- we also define two transactions related to either the actions are validated according to policy by the des- modification of the assets, i.e., the document or the ignated business network participants. Hyperledger is modification of the list of participants. Each transaction is followed by the related event. In other words, 5https://www.hyperledger.org one transaction is related to the change in the access

235 SECRYPT 2020 - 17th International Conference on Security and Cryptography

rights of users by adding new users. The second trans- As future work, we aim to finish the implemen- action initiates the vote protocol and implement the tation of Prov-Trust and test the performance of the modification (i.e., download) of the data file based on data provenance generation within the Intel SGX be- the vote result as shown in Figure2. If the vote is suc- sides adding more sophisticated encryption and pri- cessful the event is published in the blockchain (c.f., vacy preserving schemes while storing and auditing Listing 3). the data stored in blockchain.

Listing 2: The event publication. let documentModificationEvent = getFactory ().newEvent(NS, ’documentModification ’); ACKNOWLEDGMENTS documentModificationEvent. resultat=false ; documentModificationEvent . protocoleVote=maj. protocoleVote ; This material is based upon work supported by if (maj. protocoleVote==”MAJORITE”) { i f ( nbOui>nbNon ){ the National Science Foundation under Grant ACI- documentModificationEvent. resultat=true ; 1547467. Any opinions, ﬁndings, and conclusions or } } recommendations expressed in this material are those if (maj. protocoleVote==”UNANIMITE”) { of the authors and do not necessarily reﬂect the views if (nbNon==0){ documentModificationEvent. resultat=true ; of the National Science Foundation. } }

Listing 3: The vote protocol implementation. REFERENCES if (documentModificationEvent. resultat==true){ await documentRegistry.update(document); } Asghar, M. R., Ion, M., Russello, G., and Crispo, B. (2012). documentModificationEvent . documentId=document. Securing data provenance in the cloud. In Open prob- getIdentifier (); lems in network security, pages 145–160. Springer. documentModificationEvent. utilisateurId=contributeurId ; documentModificationEvent . chaineRemplacee=chaineRemplacee; Belguith, S., Kaaniche, N., and Hammoudeh, M. Anal- documentModificationEvent. chaineInseree=maj. chaineInseree ; ysis of attribute-based cryptographic techniques and emit(documentModificationEvent ); their application to protect cloud services. Transac- } tions on Emerging Telecommunications Technologies, page e3667. The solution can be tested using the graphic interface Belguith, S., Kaaniche, N., Laurent, M., Jemai, A., and provided by Composer Playground. It is necessary Attia, R. (2018a). Phoabe: Securely outsourcing multi-authority attribute based encryption with policy to load the different files such as permission, query hidden for cloud assisted iot. Computer Networks, and transaction files. For more information, the im- 133:141–156. 6 plementation files are accessible in Github . 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 8 CONCLUSION Computing (SCC), pages 245–248. IEEE. Belguith, S., Kaaniche, N., Russello, G., et al. (2018c). Prov-Trust is a distributed data provenance architec- Lightweight attribute-based encryption supporting ac- ture designed to ensure a secure, tamper-proof and cess policy update for cloud assisted iot. In Proceed- privacy preserving provenance data in cloud com- ings of the 15th International Joint Conference on puting systems. It is relying on a novel use of In- e-Business and Telecommunications-Volume 1: SE- tel SGX trusted hardware to collect provenance data CRYPT, pages 135–146. SciTePress. while storing them in Blockchain using transactions Bock,¨ B., Huemer, D., and Tjoa, A. M. (2010). Towards more trustable log files for digital forensics by means and smart contracts. Prov-Trust provides a secure and of “trusted computing”. In 2010 24th IEEE Interna- authorized auditing function to enable an auditor or tional Conference on Advanced Information Network- the data owner to verify the operations performed over ing and Applications, pages 1020–1027. IEEE. the data stored in cloud storage services. A security Crosby, M., Pattanayak, P., Verma, S., and Kalyanaraman, and privacy analysis has been detailed to prove the V. (2016). Blockchain technology: Beyond bitcoin. fulfillment of the defined requirements. We have also Applied Innovation, 2:6–10. presented a proof of concept of the proposed system Cui, S., Belguith, S., Zhang, M., Asghar, M. R., and Rus- by implementing the vote system. sello, G. (2018). Preserving access pattern privacy in sgx-assisted encrypted search. In 2018 27th Interna- 6https://github.com/nathanael-denis/blockchain- tional Conference on Computer Communication and vote/blob/master/blockchain-based-voting- Networks (ICCCN), pages 1–9. IEEE. system/lib/logic.js Gehani, A. (2016). https://github.com/ashish-gehani/spade.

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

Gehani, A. and Tariq, D. (2012). c. In Proceedings of Main, T. (2007). Part 2 tpm structures. Specification ver- the 13th International Middleware Conference, Mid- sion, 1. dleware ’12, pages 101–120, New York, NY, USA. McKeen, F., Alexandrovich, I., Berenzon, A., Rozas, C. V., Springer-Verlag New York, Inc. Shafi, H., Shanbhogue, V., and Savagaonkar, U. R. Grawrock, D. (2009). Dynamics of a Trusted Platform: A (2013). Innovative instructions and software model building block approach. Intel Press. for isolated execution. Hasp@ isca, 10(1). Hasan, R., Sion, R., and Winslett, M. (2009). Preventing Moreau, L., Clifford, B., Freire, J., Futrelle, J., Gil, Y., history forgery with secure provenance. ACM Trans- Groth, P., Kwasnikowska, N., Miles, S., Missier, P., actions on Storage (TOS), 5(4):1–43. Myers, J., et al. (2011). The open provenance model core specification (v1. 1). Future generation computer Intel (2016). Introduction to Intel SGX sealing. systems, 27(6):743–756. https://software.intel.com/en-us/blogs/2016/05/ 04/introduction-to-intel-sgx-sealing. Last accessed: Moreau, L. et al. (2010). The foundations for provenance September 10, 2018. on the web. Foundations and Trends® in Web Science, 2(2–3):99–241. Kaaniche, N., Belguith, S., and Russello, G. (2018). Ema- lab: Efficient multi authorisation level attribute based Muniswamy-Reddy, K.-K., Barillari, J., Braun, U., Hol- access control. In International Conference on Net- land, D. A., Maclean, D., Seltzer, M. I., and Holland, work and System Security, pages 187–201. Springer. S. D. (2008). Layering in provenance-aware storage systems. Kaaniche, N. and Laurent, M. (2017). Attribute based en- Muniswamy-Reddy, K.-K., Holland, D. A., Braun, U., and cryption for multi-level access control policies. In Seltzer, M. I. (2006). Provenance-aware storage sys- 14th International Conference on Security and Cryp- tems. In Usenix annual technical conference, general tography (SECRYPT). track, pages 43–56. Kaaniche, N. and Laurent, M. (2018). Bdua: Blockchain- Pohly, D. J., McLaughlin, S., McDaniel, P., and Butler, K. based data usage auditing. In 2018 IEEE 11th Inter- (2012). Hi-fi: collecting high-fidelity whole-system national Conference on Cloud Computing (CLOUD), provenance. In Proceedings of the 28th Annual Com- pages 630–637. IEEE. puter Security Applications Conference, pages 259– Kaaniche, N., Laurent, M., and Levallois-Barth, C. (2020). 268. Id-based user-centric data usage auditing scheme for Ramachandran, A. and Kantarcioglu, M. (2018). Smart- distributed environments. Frontiers in Blockchain, provenance: A distributed, blockchain based dat- 3:17. aprovenance system. In Proceedings of the Eighth Karame, G., Androulaki, E., Roeschlin, M., Gervais, A., ACM Conference on Data and Application Security and Capkun, S. (2015). Misbehavior in bitcoin: A and Privacy, pages 35–42. ACM. study of double-spending and accountability. ACM Shetty, S., Red, V., Kamhoua, C., Kwiat, K., and Njilla, L. Transactions on Information and System Security (2017). Data provenance assurance in the cloud us- (TISSEC), 18(1):2. ing blockchain. In Disruptive Technologies in Sensors Ko, R. K. and Will, M. A. (2014). Progger: An effi- and Sensor Systems, volume 10206, page 102060I. In- cient, tamper-evident kernel-space logger for cloud ternational Society for Optics and Photonics. data provenance tracking. In 2014 IEEE 7th Interna- Suen, C. H., Ko, R. K., Tan, Y. S., Jagadpramana, P., and tional Conference on Cloud Computing, pages 881– Lee, B. S. (2013). S2logger: End-to-end data track- 889. IEEE. ing mechanism for cloud data provenance. In 2013 Laurent, M., Kaaniche, N., Le, C., and Vander Plaetse, M. 12th IEEE International Conference on Trust, Secu- (2018). A blockchain-based access control scheme. In rity and Privacy in Computing and Communications, 15th International Conference on Security and Cryp- pages 594–602. IEEE. tography (SECRYPT), pages 168–176. Swan, M. (2015). Blockchain: Blueprint for a new econ- omy. O’Reilly Media, Inc. Li, H., Gai, K., Fang, Z., Zhu, L., Xu, L., and Jiang, P. (2019). Blockchain-enabled data provenance in cloud Taha, M. M. B., Chaisiri, S., and Ko, R. K. (2015). Trusted datacenter reengineering. In Proceedings of the 2019 tamper-evident data provenance. In 2015 IEEE Trust- ACM International Symposium on Blockchain and Se- com/bigdatase/ispa, volume 1, pages 646–653. IEEE. cure Critical Infrastructure, pages 47–55. Vukolic, M. (2017). Rethinking permissioned blockchains. Li, Y., Marier-Bienvenue, T., Perron-Brault, A., Wang, X., In Proceedings of the ACM Workshop on Blockchain, and Pare,´ G. (2018). Blockchain technology in busi- Cryptocurrencies and Contracts, BCC ’17, pages 3–7, ness organizations: A scoping review. In Proceedings New York, NY, USA. ACM. of the 51st Hawaii International Conference on Sys- Wood, G. (2014). Ethereum: A secure decentralised gen- tem Sciences. eralised transaction ledger. Ethereum Project Yellow Paper, 151. Liang, X., Shetty, S., Tosh, D., Kamhoua, C., Kwiat, K., and Njilla, L. (2017). Provchain: A blockchain- Zafar, F., Khan, A., Suhail, S., Ahmed, I., Hameed, K., based data provenance architecture in cloud environ- Khan, H. M., Jabeen, F., and Anjum, A. (2017). Trust- ment with enhanced privacy and availability. In Pro- worthy data: A survey, taxonomy and future trends of ceedings of the 17th IEEE/ACM International Sympo- secure provenance schemes. Journal of Network and sium on Cluster, Cloud and Grid Computing, pages Computer Applications, 94:50–68. 468–477. IEEE Press.

237