Kate ATaleofTwoTrees:OneWrites,andOtherReads · Kate ATaleofTwoTrees:OneWrites,andOtherReads...

Proceedings on Privacy Enhancing Technologies ; 2020 (2):519–536

Duc V. Le*, Lizzy Tengana Hurtado, Adil Ahmad, Mohsen Minaei, Byoungyoung Lee, and AniketKateA Tale of Two Trees: One Writes, and Other ReadsOptimized Oblivious Accesses to Bitcoin and other UTXO-based Blockchains

Abstract: The Bitcoin network has offered a new way ofsecurely performing financial transactions over the inse-cure network. Nevertheless, this ability comes with thecost of storing a large (distributed) ledger, which hasbecome unsuitable for personal devices of any kind. Al-though the simplified payment verification (SPV) clientscan address this storage issue, a Bitcoin SPV client hasto rely on other Bitcoin nodes to obtain its transac-tion history and the current approaches offer no privacyguarantees to the SPV clients.This work presents T 3, a trusted hardware-securedBitcoin full client that supports efficient oblivioussearch/update for Bitcoin SPV clients without sacrific-ing the privacy of the clients. In this design, we leveragethe trusted execution and attestation capabilities of atrusted execution environment (TEE) and the ability tohide access patterns of oblivious random access machine(ORAM) to protect SPV clients’ requests from poten-tially malicious nodes. The key novelty of T 3 lies in theoptimizations introduced to conventional ORAM, tai-lored for expected SPV client usages. In particular, bymaking a natural assumption about the access patternsof SPV clients, we are able to propose a two-tree ORAMconstruction that overcomes the concurrency limitationassociated with traditional ORAMs. We have imple-mented and tested our system using the current BitcoinUnspent Transaction Output (UTXO) Set. Our experi-ment shows that T 3 is feasible to be deployed in practicewhile providing strong privacy and security guaranteesto Bitcoin SPV clients.

Keywords: Secure Enclaves, Intel SGX, ORAM, Bitcoin,Bitcoin clients, Oblivious accesses

DOI 10.2478/popets-2020-0039Received 2019-08-31; revised 2019-12-15; accepted 2019-12-16.

*Corresponding Author: Duc V. Le: Purdue University,E-mail: [email protected] Tengana Hurtado: National University of Colombia,E-mail: [email protected], most of this work was donewhile the author was at Purdue UniversityAdil Ahmad: Purdue University, E-mail: [email protected] Minaei: Purdue University, E-mail:[email protected]

1 IntroductionOver the last few years, we have seen a great inter-est in public blockchain in the community. The Bit-coin blockchain offered a way to provide security andprivacy for financial transactions. However, due to thehuge adoption by the community, the size of the Bitcoinblockchain has become too large for small and resource-constrained devices such as personal laptops or mobilephones, raising not only performance but also privacyconcerns in the community. As of October 2018, the sizeof the unindexed Bitcoin blockchain is 230 GB.

To this end, Bitcoin’s simplified payment verifica-tion (SPV) client has become a widely-adopted solu-tion to resolve a storage problem for constrained de-vices. Nakamoto [45] sketched the idea of SPV clientsin the Bitcoin whitepaper, and in the Bitcoin improve-ment proposal 37 (BIP37) [33], Mike Hearn combinesNakamoto’s idea with Bloom filters to standardize thedesign of Bitcoin SPV clients. This design has becomea de facto standard for other SPV clients such as Bit-coinJ [5] and Electrum [8].

The core of SPV clients is in only downloading andthen verifying part of the blockchain that is relevant tothe SPV client itself. In particular, the SPV client loadsits addresses into a Bloom filter and sends the filter toa Bitcoin full client, and The Bitcoin full client will usethe filter sent by the client to identify if a block containstransactions that are relevant to the SPV client, andonce it finds the block, it will send a modified block thatonly contains relevant transactions along with Merkleproofs for those transactions.

However, the current SPV solution relied on Bloomfilters raises security and privacy concerns to the SPVclients when communicates with potentially maliciousnodes. In particular, Gervais et al. [30] show that it ispossible for a malicious node to learn several addresses

Byoungyoung Lee: Seoul National University, E-mail: [email protected], most of this work was done while theauthor was at Purdue UniversityAniket Kate: Purdue University, E-mail: [email protected]

A Tale of Two Trees: One Writes, and Other Reads 520

of the client from the Bloom filter with high probability.Moreover, if the adversarial node can collect two filtersissued by the same client, then a considerable numberof addresses owned by the client will be leaked.

To provide a strong privacy guarantee for SPVclients, one needs a solution that can hide wal-lets/addresses queried by the SPV clients [34]. Whilesuch a system can be built using private informationretrieval (PIR) primitives, the existing cryptographicPIR solutions [37, 48] are not scalable to handle millionsof Bitcoin users. On the other hand, to gain more effi-ciency, one can use ORAM and TEE to propose genericPIR systems [28, 35, 53]. However, as we will see laterin the paper, naively combining ORAM scheme as it iswith TEE makes the practicality of those generic sys-tems questionable when used in a large network like Bit-coin due to the lack of concurrency in ORAM as well asthe limitation of TEE with restricted memory.Our Contributions. This work aims not only to de-sign a system that provides SPV clients with privacy-preserving access to the Bitcoin blockchain data but alsoto consider other practical aspects on how to scale sucha system to handle client requests in a large-scale. Ourcontributions can be summarized as follows:

Firstly, we present a design for a system that canhandle up to thousands of requests per minute from Bit-coin SPV clients based on a restricted access ObliviousRandom Access Memory (ORAM) and the trusted ex-ecution capabilities of TEE. In particular, one of themain contributions of our design is the optimization ac-cess in the prominent tree-based ORAM schemes thatallow those ORAM schemes to support concurrent ac-cesses which is essential for handling SPV clients’ re-quests. In this design, the access privacy guarantee isstill maintained because of our natural assumption thatthe rational Bitcoin SPV clients should only query fortheir particular transaction once before the arrival ofa new Bitcoin block. Nevertheless, we later show thateven when the SPV clients are irrational then the pri-vacy for such clients is only compromised for a shortperiod of time. The security guarantee of T 3 also relieson the trusted execution capabilities of TEE that al-lows SPV clients to perform ORAM operations securelyand remotely. Our generic design works with otherblockchains, any tree-based ORAM schemes [54, 55, 60],and any TEE with attestation capability.

Secondly, we implemented a prototype of T 3 andevaluated its performance to demonstrate the practi-cality of our approach. More specifically, we extractedthe unspent transaction outputs set of Bitcoin in Oc-tober 2018 and used it to measure the performance of

the system when handling clients’ requests. The imple-mentation of T 3 also adopts standard techniques (i.e.,oblivious operations using cmov [14, 49, 53]) to be secureagainst known side-channel attacks [39, 40, 62]. More-over, the use of recursive ORAM constructions in T 3

makes the system much more suitable for TEE with re-stricted trusted memory like Intel SGX. We then showthat the running time of the ORAM read access de-creases linearly with the number of the threads used.Our implementation is available at [13].

Finally, we conclude that putting natural restric-tions on the access patterns on oblivious memory canlead to significant performance improvement and betterORAM design. While the applicability of T 3 in cryp-tocurrencies beyond Bitcoin is apparent, we believe ourwork will also motivate further research on obliviousmemory with restricted access patterns.Comparison. The BITE system [43] is a concur-rent work that also employs the Oblivious Databaseconstruction for SPV client privacy. The main ideaof the BITE construction is to combine the use ofnon-recursive Path-ORAM [55] construction and TEE(such as Intel SGX) to propose a generic system thatoffers SPV client with oblivious access to the database.However, BITE did not address several shortcomings ofusing Path-ORAM as it is and TEE with restrictedmemory in practice. In particular, the BITE design didnot consider using recursive ORAM constructions toreduce the trusted memory usage; therefore, the effi-ciency of the system will be degraded once the size ofthe database gets too large. Moreover, due to the in-herent lack of concurrency in tree-based ORAM such asPath-ORAM, naively using Path-ORAM makes BITEunsuitable for handling thousands of Bitcoin client’s re-quests per minute as well as thousands of updates ev-ery fixed period of times (e.g., 10 minutes for Bitcoin).In this work, we investigate the use of both recursivePath-ORAM and recursive Circuit-ORAM to under-stand the actual performance and the actual storageoverhead put on the full node. Importantly, we proposea two-tree ORAM design to further enhance the perfor-mance of standard ORAM accesses as well as to allowconcurrent requests from the SPV client.

Charkborti and Sion propose ConcurORAM [19]that also uses a two-tree design for Path-ORAM toallow non-blocking eviction procedures, and the systemperiodically synchronizes two trees to maintain users’access privacy. However, it is not suited for TEEs withlimited trusted memory (such as Intel SGX). We elab-orate on this later in the paper.


2 Design Goals and SolutionOverview

In this section, we define the system components, out-line our security goals, and give an overview of how oursystem works.

2.1 System Components

There are three key components of this system: the Bit-coin network, a client, and an untrusted full node. TheBitcoin network is a set of nodes that maintains theBitcoin blockchain, and the network validates and relaysthe new Bitcoin block produced by miners. A client isa Bitcoin simplified payment verification node that re-motely connects to the secure TEE on the untrustedfull node to perform oblivious searches on the unspenttransaction output (UTXO) set. The client is also ableto connect to the Bitcoin Network to obtain other net-work metadata such as the latest Bitcoin block header.A full node is an untrusted entity made up of twocomponents: an untrusted full node and several trustedTEEs (i.e., the managing, reading, and writing TEEs).Moreover, the untrusted full node stores three encrypteddatabases which are the read-once ORAM tree, the orig-inal ORAM tree, and the Bitcoin header chain. The un-trusted full node hosts a potentially malicious Bitcoinclient (e.g., bitcoind) that handles the communicationwith the Bitcoin Network.

2.2 Design Goals

The goal of our system is to leverage the trusted exe-cution capabilities of a Trusted Execution Environment(TEE) with attestation to design a public Bitcoin fullnode that supports oblivious search and update on thecurrent Bitcoin unspent transaction output database.Our system aims to provide data confidentiality andprivacy to Bitcoin SPV clients on a large scale by us-ing standard encryption and Oblivious RAM techniqueson the current set of unspent transaction outputs. Themain goals that T 3 tries to achieve are:Privacy. T 3 aims to provide privacy and confiden-tiality to SPV clients’ requests. In particular, the sys-tem allows SPV clients to obliviously search its relevanttransactions without revealing their addresses to poten-tially malicious providers by using TEE to encrypt the

data and using ORAM schemes to eliminate known sidechannel leakages [14, 35, 49, 53].Validity. The SPV client should be able to obtainvalid information based on the provided addresses, anda malicious adversary should not able to tamper theBlockchain data with invalid transaction outputs.Completeness. The system should provide clientswith access to most of its relevant transactions in orderto determine balance or to obtain essential informationto form new transactions.Efficiency. The system should be practical to de-ploy. More specifically, the system should be efficientenough to handle different concurrent SPV clients’ re-quests without compromising the privacy of the clients.

2.3 Solution Overview

The idea of using ORAM schemes and trusted ex-ecution environments to construct database systemsthat support oblivious accesses has been investigatedby the research community [28, 35, 53]. However, theefficiency and scalability of those systems are ham-pered by the lack of concurrency of traditional ORAMschemes [55, 60].

In this work, we design T 3 to overcome the limi-tations of efficiency and concurrency plaguing existingsystems. Our design is motivated by the following obser-vations. The first observation is that each ORAM accessin a standard tree-based ORAM setting is a combinationof two operations: a read-path operation and an evictionoperation. By separating the effects of two operationsinto two different trees: a read-once ORAM tree and anoriginal ORAM tree, one can use read-path operationon the read-once ORAM tree to handle clients’ requestssimultaneously while performing a non-blocking evic-tion operation on the original ORAM tree sequentially.

The second observation is that the access privacyguarantee of this approach relies on the characteristicof the Bitcoin blockchain. In particular, the Bitcoin net-work generates new Bitcoin block on average of 10 min-utes, and if we require T 3 to periodically synchronizethese the two trees, then the privacy of clients’ queriesare preserved. Moreover, if we assume that upon receiv-ing transactions belonged to its addresses, the rationalclient should not query same transactions again untilthe next block arrives, the proposed approach on theseparation of read-path and eviction procedure not onlydoes not affect the privacy guarantees of ORAM accessbut also allows T 3 to efficiently handle more clients’requests. More importantly, we argue that even when


4

Read-onceORAM OriginalORAM

R-Enclave R-Enclave W-Enclave6

EvictQueue

BTCDaemon

BitcoinNetwork

SPVClients

1

2

3

5

6

1

2

3

5

8

SecureChannelUnsecureChannel

#

#UpdateSteps

ReadSteps

7

ManagingEnclave

BitcoinBlockHeaderDatabaseWriteQueue

4

Fig. 1. Overview of T 3 design. The encrypted ORAM databases are stored in full node’s untrusted memory region. Steps 1 - 6 de-scribe the flow of the request sent from SPV clients. Steps 1 - 8 show the flow of the update procedure when T 3 receives new block.

the SPV clients are irrational by submitting requestsfor the same transaction more than once, the privacyof those clients is only compromised for a short period(i.e., 10 minutes for the Bitcoin network) because T 3

will always synchronize the old instance of the read-once ORAM tree with the more updated instance of theoriginal ORAM tree. With the intuition of T 3 describedabove, we outline the workflow of our design in fig. 1:Full node Initialization 1 - 8 : Initially, the managingTEE will initialize a writing TEE that creates an emptyORAM tree. For each of Bitcoin block obtained fromthe network, the managing TEE verifies the proof ofwork of the block before passing relevant update datato the writing TEE in order to populate the ORAMtree. With the current size of the Bitcoin blockchain,this operation may take several hours. However, oncethe TEEs catch up with the current state of the Bitcoinblockchain, we expect that the TEE only has to performa batch of update accesses on the ORAM tree every10 minutes. When the initialization is completed, themanaging TEE creates two copies of the ORAM treewhich are the read-once ORAM tree and the originalORAM tree.Oblivious read-once Protocol 1 - 6 : To obtain itsunspent outputs, the client first performs the remote at-testation to the managing TEE. The remote attestationmechanism allows the client to verify the correctness ofprogram execution inside the TEE. More importantly,after a successful attestation, the client can use standardkey exchange mechanism [27] to share a secret sessionkey with the TEE in order to establish a secure connec-tion with the managing TEE. Upon receiving client’s

connection requests, the managing TEE creates a read-ing TEE with its copies of the ORAM position map andthe ORAM stash to handle client subsequent requests.Next, after having a secure channel, the client will sendhis Bitcoin addresses along with the proof of ownershipof those addresses to the TEE. The reading TEE will usea mapping function to map Bitcoin addresses into theORAM block identification number and performs read-once ORAM access on the ORAM tree. In particular,those read-once ORAM access do not involve the evic-tion procedure which requires re-encrypting and remap-ping the ORAM block. The eviction procedure will beperformed on the original ORAM tree by the writingTEE.Oblivious Write Protocol 1 - 8 : The T 3 requires toupdate the ORAM tree via batch of write accesses ev-ery 10 minutes on average. In particular, T 3 will relyon a standard Bitcoin client to handle the communi-cation with the Bitcoin network to obtain blockchaindata 1. Thus, T 3 needs to verify the block relayed by apotentially malicious Bitcoin client before updating theORAM tree. More specifically, in the design, T 3 storesa separate Bitcoin header chain to verify the proof ofwork and the validity of all transactions inside a Bitcoinblock. After the verification, the managing TEE forms abatch of ORAM updates and delegates those updates tothe writing TEE. Once those updates are finished, themanaging TEE will queue up read requests from SPV

1 This feature can be easily included in the future implementa-tion of T 3.


clients to allow the writing TEE to finish the evictionrequests from the read TEEs during the updating in-terval. As soon as the writing TEE finishes performingthose eviction requests, the managing TEE updates theposition map and stash, and makes the ORAM tree usedby the writing TEE become the new ORAM tree usedby reading TEE. At this point, the reading TEE canuse the new tree instance to respond to clients’ requestswhile the writing TEE performs the eviction procedureon another copy of the same ORAM tree.

3 Preliminaries and Threat Model

3.1 Trusted Execution Environment

The design of T 3 relies on a trusted execution environ-ment (TEE) to prove the correctness of the computa-tions. In particular, TEE is a trusted hardware thatprovides both confidentiality and integrity of compu-tations as well as offer an authentication mechanism,known as attestation, for the client to verify computa-tion correctness. In this work, we chose Intel SGX [23]to be the building block of our system. However, withminor modifications, the design of our system can beextended to any TEE with attestation capabilities suchas Keystone-enclave [10] and Sanctum [24] as othertrusted execution environments might not have thesame strengths/weaknesses as Intel SGX.

Intel SGX is a set of hardware instructions intro-duced with the 6th Generation Intel Core processors.We use Intel SGX as a TEE for the execution of anORAM controller on the untrusted full node. The rel-evant elements of SGX are as follows. Enclave is thetrusted execution unit that is located in a dedicated por-tion of the physical RAM called the enclave page cache(EPC). The SGX processor makes sure that all othersoftware components on the system cannot access theenclave memory. Intel SGX supports both local andremote attestation mechanisms to allow remote par-ties or local enclaves to authenticate and verify if theprogram is correctly executed within an SGX context.More importantly, attestation protocols provide the au-thentication required for a key exchange protocol [23],i.e., after a successful attestation, the concerned partiescan agree on a shared session key using Diffie-HellmanKey Exchange [27] and create a secure channel.Limitations. Intel SGX comes with various limitationsthat have been uncovered by the academic communityover the past few years. Some of these limitations are:

– Side-Channel Attacks:While Intel SGX providessecurity guarantees against direct memory attacks,it does not provide systematic protection mech-anisms against side-channel attacks such as pagetable-based [39, 62], cache-based [18], and branch-prediction-based [40]. Through page table and cacheattacks, a privileged attacker can observe cache-line-granular (i.e., 64B) memory access patternsfrom the enclave program. On the other hand, thebranch-prediction attack can potentially leak all thecontrol-flow taken by the enclave program.

– Enclave Page Cache Limit: The size of theEnclave Page Cache (EPC) is limited to around96MB [15]. Although Intel SGX alleviates thislimitation by supporting page-swapping betweentrusted memory region and untrusted memory re-gion, this operation is expensive due to encryptionand integrity verification [15, 23].

– System Calls: Intel SGX programs are restrictedto ring-3 privileges and therefore rely on the un-trusted OS for ring-0 operations such as file andnetwork I/O. Various previous works try to solvethis problem using library OSes [58] and/or othertechniques [35].

Oblivious Operations inside the Enclave. Severaltechniques [35, 46, 49, 53] have been introduced to mit-igate side-channel attacks on the SGX. In this work,we built our system based on the implementations ofboth Zerotrace [53] and Obliviate [14]. Therefore, our sys-tem inherited standard secure operations from both ofthese libraries. In particular, their implementations usean oblivious access wrapper by using the x86 instruc-tion cmov as introduced by Raccoon [49]. Using cmov,the wrapper accesses every single byte of a memory ob-ject while reading or writing only the required bytes inmemory. From the perspective of an attacker (which canonly observe access-patterns), this is the same as read-ing or modifying every byte in memory. We refer readersto [14, 49, 53] for detailed descriptions of these obliviousoperations.

3.2 Oblivious Random Access Machine

Oblivious Random Access Machine (ORAM) was firstintroduced by Goldreich et al [31] for software protec-tion against piracy. The core of ORAM is to hide theaccess patterns resulted from reading and writing ac-cesses on encrypted data. The security of ORAM canbe described as follows.


Definition 1. [55] Let→y= (opi, bidi, datai)i∈[n] denote

a sequence of accesses where opi ∈ {read,write}, bidiis the identifier, and datai denotes the data being writ-ten. For an ORAM scheme Σ, let AccessΣ(

→y ) denote a

sequence of physical accesses pattern on encrypted dataproduced by

→y . We say: (a) The scheme Σ is secure if

for any two sequences of accesses →x and→y of the same

length, AccessΣ(→x ) and AccessΣ(→y ) are computationally

indistinguishable. (b) The scheme Σ is correct if it re-turns on input

→y data that is consistent with

→y with

probability ≥ 1− negl(|→y |) i.e negligible in |

→y |

Tree-based ORAM schemes. One strategy of de-signing an ORAM scheme is to follow the tree paradigmproposed by Shi et al. [54] and Stefanov et al. [55]. Intree-based ORAM, the client encrypts their databaseinto N different encrypted data blocks and obliviouslystores those data blocks in a binary tree of heightdlog2(N)e. Each node in the tree is called a bucket, andeach bucket can contain up to Z blocks. The client alsomaintains a position map, to indicate which path a datablock resides on. Finally, the client needs to have a stashto store a path retrieved from the server.

Each access in both ORAM schemes requires twooperations: a ReadPath operation and an Evict opera-tion. Intuitively, ReadPath takes as input the ORAMblock identifier, bid, accesses the position map, and re-trieves the path that block bid resides onto the stash, S.After performing ORAM access (i.e. read/write) on theidentified block, the block is assigned to a different pathand pushed back to the tree via the Evict operation. Ingeneral, the Evict operation takes a stash and the as-signed path as input, writes back blocks from stash tothe assigned path, and updates the position map.Path-ORAM/Circuit-ORAM scheme. In thiswork, we consider two popular tree-based constructionsof ORAM: Path-ORAM [55] and Circuit-ORAM [60].While Path-ORAM offers simple ReadPath andEvict operations, Circuit-ORAM offers a smallercircuit complexity for the Evict procedure. Thus,Circuit-ORAM is more efficient when imple-mented with Intel SGX. As noted in [35, 53, 60],Circuit-ORAM can operate with Z = 2 comparedto Z = 4 as in Path-ORAM; therefore, the server stor-age overhead is significantly reduced. Moreover, the sizeof stash in Circuit-ORAM is smaller compared to thesize of stash in Path-ORAM; this allows a more effi-cient performance when scanning the stash as one needsto scan the whole path and stash to avoid side-channelleakage.

Recursive ORAM. In a non-recursive tree-basedORAM setting, the client has to store a position mapof the size O(N) bits. This approach, however, is notsuitable for a resource-constrained client. Stefanov et.al [55] presented a technique that reduces the size ofthe position map to O(1). The main idea of those con-structions is to store a position map as another ORAMtree in the server, and the client only store the posi-tion map of the new ORAM tree. The client recurselystores the position map into another ORAM tree un-til the size of the position map is small enough to besaved on the client’s storage. One main drawback ofthose constructions is the increased cost in the commu-nication between a client and the server. In our setting,this cost can be safely ignored because the communica-tion between client and server becomes the I/O accessbetween TEE and the random access memory.

3.3 Blockchain

The Bitcoin blockchain is a distributed data structuremaintained by a network of nodes. On average of 10minutes, the network outputs a block which is a combi-nation of transactions and a block header. Each blockheader contains relevant information about the Bitcoinblock such as Merkle root, nonce, network difficulty. TheMerkle root can be used to verify the membership of Bit-coin transactions, and the nonce and difficulty are usedto check the proof of work. Each Bitcoin transactioncontains a set of inputs and outputs where transactioninputs are unused outputs of previous transactions.Unspent Transaction Output Database. In theBitcoin network, the balance of a Bitcoin address isdetermined by the values of those outputs that havenot been used in other transactions. These outputs arecalled Unspent Transaction Outputs (UTXO). More-over, in the implementation of common Bitcoin nodessuch as Bitcoin core [2], Bitcoin nodes maintain a sepa-rate database that keeps track of all unspent transactionoutputs and other metadata of the Bitcoin blockchain.Therefore, we realize that if a full node can securelyupdate and maintain the integrity of the UTXO set viawhile provides SPV clients with oblivious accesses to theUTXO set, the privacy of the SPV client is preserved.Bitcoin transaction types. In the Bitcoin, trans-actions are classified based on the structure of the in-put and output scripts. In particular, there are fivetypes of standard script templates which are Pay-to-Pubkey (P2PK), Pay-to-PubkeyHash (P2PKH), Pay-to-ScriptHash (P2SH), Multisig, and Nulldata. Intuitively,


scripting in Bitcoin provides a way to prove the owner-ship of the coins.

In this work, we only consider two types of trans-actions: Pay-to-PubkeyHash (P2PKH) transaction andPay-to-ScriptHash (P2SH) transaction. According to[26, 44], those two types of transactions made up of97-99% of the UTXO set. Also, one can assume that thePay-to-Pubkey-Hash transaction is one variant of thePay-to-Script-Hash transaction because both transac-tion types require the spender’s knowledge of the preim-age of the hash digest before being able to spend thoseoutputs. For simplicity, from this point on, we assumethat the only information needed to obtain the unspentoutput is the public key hash, pkh. All other transac-tion types such as Multisig and P2PK can be easilysupported in the future.Block creation interval. The block creation time inBitcoin is the time that the network takes to generate anew block, and block creation time is specified to be 10minutes on average by the network. We call the waitingperiod between the most recent block and a new block,block creation interval. In this work, we discretize timeas block creation intervals.Deterministic Wallet. In Bitcoin, a deterministicwallet [7] is a system that allows the creation of severalpublic addresses on-fly from a single seed. The mainidea of deterministic wallets is to generate an unlimitednumber of addresses for a client to help mitigate the riskof reusing addresses [1]. Thus, ideally, in Bitcoin, usersare expected to create a new address for each personwho is paying, and after receiving the coin, the addressshould never be used again. Therefore, it is reasonableto expect that the number of unspent outputs for eachaddress is one.UTXO-based Blockchains. After the advent of Bit-coin, the blockchain community has developed differentcryptocurrencies to address the shortcomings of Bitcoin.While the employed underlying cryptographic primi-tives are different, the transaction structure of thosecryptocurrencies follows the similar design paradigm asin Bitcoin: Transactions are formed based on outputs ofprevious transactions, and the creation of transactionsforms new unspent outputs, and the notion of balancein these cryptocurrencies is determined by the valuesof those unspent outputs. We called those UTXO-basedcryptocurrencies. Few examples of UTXO-based curren-cies are Litecoin [11], Dash [6], and Zcash [51]. Thus, asthe design will become apparent in later sections, weargue that the design of T 3 applies not only to Bitcoinbut also to other UTXO-based blockchains.

3.4 Threat Model

We assume that SPV clients are honest and rationalwhich means that before during the block creation in-terval, an SPV client should not request the full node fortransaction outputs of the same public key hash morethan once.

The underlying remote attestation service providedby TEE is assumed to be secure and trusted. The localattestation between enclaves is secure. The full nodeand its programs are assumed to be untrusted exceptfor programs running within an enclave.

We assume that the adversary who controls the op-erating system can read/inject/modify encrypted mes-sages sent by enclaves. The adversary also can observememory access patterns of both trusted and untrustedmemory. Also, the computation power of the adversaryis assumed to be limited. In particular, during the blockcreation interval, the adversary should not have enoughcomputation power to forge a new Bitcoin block thatsatisfies the current Bitcoin network difficulty. As thetime of writing, the network difficulty [4] is around6 × 109; therefore, the expected number of hashes tomine a Bitcoin block is roughly 272.

The full node’s attacks on availability are out ofscope. More specifically, denial of service (DoS) attacksby system admin and untrusted operating system areout of the scope. Otherwise, such adversaries can pre-vent the enclaves from receiving new bitcoin block byshutting down the communication channel between theenclave and the Bitcoin network as the enclave has torely on the untrusted OS to perform system calls suchas file and network I/O. On the other hand, for DoSattacks from the client, we will outline possible DoS at-tacks and offer solutions to mitigate them in Section 6.

4 Proposed SystemIn this section, we describe how T 3 stores the UTXOset by exploring different mappings between the un-spent transaction outputs and the ORAM blocks. Next,we demonstrate how Intel SGX can be considered asa trusted execution unit to access ORAM and performread/write operations in an oblivious manner. Finally,we will describe how the system handles clients’ requestsduring a write operation.


4.1 Storage Structure of the UTXO set

In this part, we show how UTXO set is stored in theORAM tree.

4.1.1 Bitcoin unspent transaction output mapping

In the design of T 3, the SPV clients only know his/heraddresses (i.e., the public key hashes); therefore, to re-turn the outputs belonging to the client’s address, TEEneeds to know the mapping between the address andthe ORAM block identification.

In this work, we propose two secure mappings tostore unspent outputs in the ORAM tree as naive map-ping may lead to attacks on the system. Both ap-proaches use standard pseudorandom function (PRF)along with a secret key generated by the enclave. Thefirst approach is to map a single Bitcoin address intoa single ORAM block, and the second approach is tomap a Bitcoin address into multiple ORAM blocks. Wewill later explain the trade-off between these two ap-proaches.Single address into single ORAM block. In thisdesign, during the initialization, we require the programinside the enclave to use a PRF to map the public keyhash to ORAM block identification. The secret key ofthe PRF is generated inside the enclave; thus, the map-ping is known only to the SGX. We define the mappingas follow:– bid← OBlockMap(pkh, kb): the function takes as in-

put a 20-bytes hash digest pkh and a secret keykb, it outputs the block identification number bid ∈{0, . . . , N − 1}.The PRF approach offers some flexibility when de-

ciding the size of an ORAM blocks and the size of heightof the ORAM tree. These two factors affect the sizeof the position map (resp. number of recursive levels)for non-recursive (resp. recursive) ORAM constructions.However, since the output domain of OBlockMap(·, ·) islimited to the size of the ORAM blocks, there will ex-ist collisions. The following claim gives us a loose upperbound on the number of addresses that should be storedinside an ORAM block.

Enclave

pkh

kb

OBlockMap() ORAM bid

Fig. 2. Single address into Single ORAM block.

Lemma 1. (Addresses per ORAM block) Let m be thenumber of public key hashes, N be the number of ORAMblocks. If the OBlockMap() acts as a truly random func-tion, then the maximum number of addresses in eachORAM block is smaller than e ·m/N with a probability1− 1/N .

Proof. This is a standard max-load analysis. We referreaders to [25] for detailed analysis. We note that thereexists a tighter bound, but we use e · m/N bounds tosimplify the equation.

The second approach of Figure 2 gives us a high leveloverview of this approach.Single address into many ORAM blocks. Map-ping a single address into a single ORAM block incursless work on the full node as it requires a single ORAMaccess for an address. However, if one wants to alloweach address to have more than one output, using thefirst approach implies that the storage overhead will in-crease linearly. Thus, we need a different mapping with-out linear increasing in storage overhead. To fix thisshortcoming, the system needs to assign unspent out-puts into ORAM block uniformly. One method is toallow a client to specify the number of ORAM accessesto obtain all of its unspent outputs as long as the num-ber of requests does not exceed certain threshold. Wedefine the mapping as follows:– {bidi}i∈{0,...,δ−1} ← OBlockMap(pkh, kb, δ): the

function takes as input a 20-bytes hash digest pkh, asecret key kb, and a number δ where the maximumvalue of δ is specified by the system. It outputs a setof block identification numbers {bidi}i∈{0,...,δ−1} ⊆{0, . . . , N − 1}.

This approach also introduces some leakage as some ad-dresses may contain more unspent outputs than oth-ers. Alternatively, the system can fix the value of δORAM accesses for all addresses with the expense ofperformance (i.e., one address incurs constant ORAMaccesses). Similarly, the storage overhead of T 3 can becomputed using the following claim:

Lemma 2. (UTXO per ORAM block) Let m be thenumber of unspent outputs, N be the number of ORAMblocks. If the OBlockMap acts as a truly random func-tion, then the maximum number of outputs in eachORAM block is smaller than e · m/N with probabilityat least 1− 1/N

The proof is identical to proof of lemma 1. Figure 3offers an overview of the both approaches.


Enclave

pkh

kb

OBlockMap()ORAM bid

δ = 2 ORAM bidpkh

Enclavekb

OBlockMap()ORAM bidORAM bid

δ = 2max = 3

Fig. 3. Single Address into One/Many ORAM block(s). One ap-proach allows the SPV client to specify the number of ORAMaccesses with a maximum threshold. The other approach mapssingle address into a constant number of ORAM access

4.1.2 Storage

In this system, we require the untrusted full node tostore three separate databases which are the read-onceORAM tree, the original ORAM tree, and the block-header chain. In particular, Read-Once ORAM Treeserves as a dedicated storage to handle clients’ requests.The structure of the tree is identical to the standardORAM tree. Original ORAM Tree is where all stan-dard ORAM eviction operations are performed. In thiswork, we also require the enclave to maintain the Bit-coin Header Chain to verify the proof of work of thebitcoin block sent by other bitcoin clients. The headerchain is stored in the untrusted memory with an in-tegrity check.

4.2 Oblivious Read and Write Protocols

In T 3, the SPV client is the party who invokes read ac-cesses, and the Bitcoin network is the party who invokeswrite accesses. The TEE in the full node is the one thatperforms both of those accesses on behalf of the clientand the Bitcoin network.

4.2.1 Full Node’s System Components

Before explaining how oblivious read and write accesseswork, we first start outlining the different componentsof our design. The full node is initialized with differentenclaves: Managing Enclave Em coordinates otherenclaves and to handle requests from the clients. Themanaging enclave also handles the communication withother Bitcoin client or local Bitcoin client (bitcoind) viarequest procedure calls (RPC) to obtain Bitcoin blocks.Upon receiving the Bitcoin block, the managing enclavealso verifies the integrity of the block using a separatedheader chain. Reading Enclave Er is a dedicated en-clave initialized by the managing enclave. It has a copyof ORAM position map and its own stash. The readingenclave operates on the read-once ORAM tree. Also, thereading enclave only performs ORAM ReadPath opera-


R-Enclave R-Enclave W-Enclave

EvictQueue

SPVClients

1

2

3

5

6

ManagingEnclave

SecureChannel

#ReadSteps

4

Fig. 4. The read protocol. Steps 1 - 5 describes how T 3 receivesand responds to the client, and for each request, the writing en-clave performs the Eviction procedure of ORAM on the originalORAM tree during step 6 .

tions to obtain data while ORAM Eviction operationswill be handled by the writing enclave. Writing En-clave Ew performs Eviction procedure for each readrequest, and performs ORAM writing accesses when anew Bitcoin block arrives from the Bitcoin network.

4.2.2 Oblivious read-once Protocol

In this part, we describe how a remote client can per-form a read access on the UTXO set.Notation. First, let’s denote Kb to be the blockmapping key, bid to be the ORAM block identification.We let (Enc,Dec) denote an authenticated encryptionscheme. We assume that the the full node has alreadybeen initialized with a writing enclave, Ew and a man-aging enclave, Em. The managing enclave has a similarcopy of the position map as the map in the writing en-clave. Figure 4 presents the oblivious read protocol ofT 3. The oblivious read protocol can be described as fol-lows:

1. The client establishes a secure channel 2

with the managing enclave 1 : First, the client per-forms a remote attestation with the secure managingenclave, Em, and agrees on a session key, Ks. The clientencrypts his address along with the proof of ownershipof that address, and sends the encrypted query to thefull node to be passed to Em. For simplicity, we assume

2 The standard instantiation of a secure channel is usingSSL/TLS channel


that the plaintext only contains a public key hash, pkh,that the client is interested in, and the proof of own-ership of the pkh is φ, C ← EncKs

(pkh, φ). Note thatthere are different ways to prove the ownership of pub-lic key hash/addresses. In Bitcoin, if the public key isnever revealed before, the proof of ownership can simplybe the public key (i.e. φ = pk such that H(pk) = pkh).Alternatively, the system can enforce a client to providethe signature and the public key to prove the ownershipof the public key hash.

2. The managing enclave initializes a readingenclave 2 : after receiving a client’s request, Em ini-tializes a dedicated reading enclave, Er to handle theclient’s future requests. Also, we require that the en-claves authenticate each other, and the existence of asecure channel between enclaves. Moreover, the readingenclave has its copy of the position map, its own stash,the block mapping key Kb, and the agreed session keyKs.

3. The managing enclave identifies and for-wards ORAM Block ID to both reading andwriting enclaves 2 : After decrypting the ciphertext(pkh, φ) ← DecKs

(C), Em verifies the proof φ and pkh,then uses OBlockMap(·, ·) 3 function to learn the ORAMblock ID, bid ← OBlockMap(pkh,Kb) where Kb is thesecret key generated by the enclave during initializa-tion for mapping purposes. After obtaining the ORAMid, bid, the managing enclave forwards bid to the writ-ing enclave for the eviction procedure, and forwards the(pkh, bid) to the reading enclave.

4. The reading enclave performs read-onceORAM access on the read-once ORAM tree 3 :Based on the given bid, the reading enclave performsORAM read only accesses on the ORAM tree to obtainthe block. If the block contains the unspent output thatbelongs to the public key pkh, the reading enclave addsoutputs into the response R. To mitigate the size leak-age, the response R is padded with dummy data if thereis no UTXO found.

5. The reading enclave responds to theClient 4 - 5 : The enclave encrypts the response, R,using the session key Ks then sends it to the client.

6. The writing enclave performs the evictionprocedure on the original ORAM tree 6 : Afterobtaining the bid from themanaging enclave, the updateenclave will perform a standard ORAM read accesses onthe original ORAM tree. The goal of this procedure is

3 for simplicity, we assume that the one-to-one mapping is usedhere


R-Enclave R-Enclave W-Enclave6

EvictQueue

BTCDaemon

BitcoinNetwork

SPVClients

1

2

3

5

8

SecureChannelUnsecureChannel

#UpdateSteps

7

ManagingEnclave

BitcoinBlockHeaderDatabaseWriteQueue

ProspectiveRead

6 ... 85...1

a ... bDuringstepaandb

4

Fig. 5. Oblivious write protocol. During steps 1 - 5 , the manag-ing enclave receives and responds to SPV client request as usual.During steps 6 - 8 , read requests from clients are queued up,and the managing enclave resume these requests after updatingthe read-once ORAM tree.

to use the Eviction procedure inside standard ORAM op-eration to rerandomize the location of the actual block.No actual data is return in this step.

4.2.3 Oblivious Write Protocol

We explain how T 3 handles oblivious write accesseswhile handling clients’ requests as follow:

1. The managing enclave verifies a new Bit-coin block 1 - 3 : Once a bitcoin block arrives to thesystem from the Bitcoin network, the managing enclaveEm can obtain it from the Bitcoin client. The enclaveneeds to verify the integrity of the new block by com-puting the Merkle root and verifying the proof of workto make sure that the block has not been tampered bythe untrusted OS. For the detail of these computations,we refer readers to [3]. Moreover, as discussed in sec-tion 4.1, to verify a newly arrived block, the system isrequired to keep a separate block headers chain with in-tegrity check in the untrusted memory. Once Em verifiesthe bitcoin block, Em starts pruning the transactions toobtain relevant information of the transactions’ inputsand outputs. Then, Em uses OBlockMap(·, ·) to find theORAM block identification to queue up ORAM writerequests to the writing enclave. During this process, theoblivious read protocol performs as normal on the read-once ORAM tree.

2. The managing enclave sends write re-quests to the writing enclave 4 : Once the prun-ing process completes, the Em starts sending write re-quests based on data extracted from the bitcoin block tothe writing enclave, Ew. On otherhand, for each eviction


request resulted from SPV client’s requests, Em startsqueuing up those eviction requests.

3. The writing enclave performs write ac-cesses on the original ORAM tree 4 - 5 : Uponreceiving writing requests from Em, the Ew performs allwriting requests in the writing queue on the originalORAM tree.

4. The writing enclave finishes all eviction re-quests queued up on the original ORAM tree 6 -7 : Once finished updating the tree, the Ew signals Emto start queuing up clients’ requests and performs alleviction requests incurred by SPV clients’ read requestsduring update interval. Finally, when it finishes, it sig-nals the Em to update the read-once ORAM tree andmake a copy of the position map.

5. The managing enclave performs an up-date the read-once ORAM tree and the origi-nal ORAM tree and enclave metadata 8 : In par-ticular, Em discards the current copy of the read-onceORAM tree, and makes 2 identical copies of the mostupdated original ORAM tree. One is used as read-onceORAM tree, and the other is used as original ORAMtree. Also, the new position map and new stash are up-dated for the managing enclave. Once this process is fin-ished, Em starts answering SPV clients’ requests again.Figure 5 gives us an overview of the oblivious write pro-tocol.

5 Evaluation and ComparisonIn this section, we describe our configuration, our exper-imental results, and the storage overhead of the systembased on the analysis of the UTXO set on the Bitcoinblockchain. Moreover, we give a comparison between T 3

and the current existing SPV solution in term of per-formance and communication overhead. Finally, we ad-dress the capabilities of T 3 compared to other relatedworks.

5.1 Configuration

Software. We implemented our system with C++ us-ing Intel SGX SDK v2.1.3. The implementation of theORAM controller is built on top the Zerotrace [53] imple-mentation. In order to handle the communication withthe Bitcoin network, we have used libjson-rpc-cpp [9]framework to build C++ wrapper functions to commu-nicate with the Bitcoin daemon (bitcoind [2]) from in-side the enclave through JSON-RPC calls. For extract-

ing the UTXO database, we used the bitcoin-tool im-plementation proposed in [26]. This allows us to savetime during the initialization phase. Finally, we usedpython-bitcoinlib [12] to compare the performance ofT 3 with the current existing SPV solution.Database. To reduce the time of initializingboth ORAM trees from the genesis block, we usedbitcoin-tool implementation proposed in [26] to ex-tract the Bitcoin UTXO set in February 2019. We havedownloaded a snapshot of the Bitcoin blockchain includ-ing block 0 to 551, 731, containing a total of 58, 156, 895Unspent Transaction Outputs (UTXO). Figure 6 showsthe distribution of the unspent transaction outputs peraddress. Despite the Bitcoin community’s suggestion [1]against the address reuse, we find that more than 7%of the addresses have more than 2 UTXOs. However,to give one the benefit of doubt, we considered at mosttwo UTXOs per wallet ID. This results in covering morethan 92% of all the UTXOs per wallet ID. Also, as dis-cussed in section 4, by using different mapping, one cancover more percentage of Bitcoin addresses.

0 1 2 3 4 5 6 7 8 9

Number of unspent outputs per address

0.0

0.2

0.4

0.6

0.8

1.0

Per

centa

geof

add

ress

es 85.58

6.472.37 1.21 0.82 0.58 0.38 0.29

≈ 8% of all addresseshave more than 2 UTXOs

Fig. 6. Number of transactions per wallet ID. By allowing eachaddress can have up to 2 UTXO, T 3 can cover approximate 92%of the UTXO set.

Hardware. We evaluated the performance of T 3 on adesktop which is equipped with Intel(R) Xeon(R) Sil-ver 4116 CPU @ 2.10GHz, 128GB RAM. Since Intel(R)Xeon(R) silver 4116 is not SGX-enabled CPU, we obtainthe performance results by running our implementationin the simulation mode. However, we expect to not havemuch of a performance difference when executing in thetwo different modes. More specifically, we have testedthe performance of T 3 using a smaller ORAM tree in thehardware mode on a commodity desktop equipped withSGX-enabled Intel Core i7. Comparing the hardwareand simulation mode results (i.e., simulation on the In-tel Core i7 CPU), we see no noticeable difference in therunning time of both read-once and standard ORAMaccesses.


T 3 (Path-ORAM, Z = 4) T 3 (Circuit-ORAM, Z = 2)N Block Size read-once Access Standard ORAM access read-once Access Standard ORAM access

220 6528 bytes (96 utxos) 16.34 ms 30.40 ms 2.13 ms 6.45 ms221 3264 bytes (48 utxos) 9.24 ms 16.58 ms 1.27 ms 3.76 ms222 2176 bytes (32 utxos) 7.56 ms 12.42 ms 1.05 ms 2.92 ms223 1088 bytes (16 utxos) 4.12 ms 7.78 ms 0.72 ms 2.09 ms224 544 bytes (8 utxos) 2.43 ms 5.89 ms 0.64 ms 1.70 ms

Table 1. Performance of two different types of Path/Circuit-ORAM accesses on different block size.

5.2 Experimental Results

We have implemented the proof of concept of T 3 usingmultiple threads. As reported in [32, 56], as long as thetotal amount of memory used by all threads does notexceed the EPC limit, the performance gain should besimilar to the use of different enclaves. In this work,we implemented all functionalities in one single enclave,and we used multiple threads to concurrently accessesthe ORAM trees.System parameters We tested our systemwith both recursive Path-ORAM and recursiveCircuit-ORAM using different tree size N =220, 221, 222, 223, 224. We allow each Bitcoin address tohave up to 2 unspent transaction outputs, and we usethe single address into single ORAM block mapping ap-proach described in section 4.1 to map addresses intoORAM block. Finally, we use claim 1 to determine thesize of each ORAM block.Performance of read-once and standard ORAMaccesses. In T 3, the reading enclave performs read-once accesses to handle client’s requests in an efficientmanner. Table 1 presents an overall performance ofa standard ORAM access as well as the performanceof a read-once access for both Circuit-ORAM andPath-ORAM. For this experiment, we took the aver-age running time of 10000 accesses.

As shown in the results, ORAM constructions withsmaller block sizes provide a better performance in bothschemes. The reason is that oblivious operations likeoblivious comparisons and cmov-based stash scan aremore efficient because of a smaller size stash. Moreover,Circuit-ORAM gives a better performance comparedto Path-ORAM, as it can operate on a smaller blockcompared to Path-ORAM, and this requires muchsmaller stash size allowing much faster oblivious exe-cution.Parallelization. Since there is no race condition inread-once accesses, the design of T 3 allows differentthreads to concurrently perform read-once accesses onthe read-once ORAM tree. Compared to other oblivi-ous system like Bite [53], T 3 is able to handle bursty

T 3 (Path-ORAM) T 3 (Circuit-ORAM)Number of threads1 2.43 ms 0.64 ms2 1.40 ms 0.58 ms3 0.90 ms 0.43 ms4 0.73 ms 0.35 ms

Table 2. Performance gain of multiple-thread read-once access onPath/Circuit-ORAM with N = 224 block size = 544 bytes.

client read requests concurrently while the eviction re-quests are distributed sequentially during the block cre-ation interval. To measure this performance gain, weused multiple threads to access the read-once enclaveand perform read-once access simultaneously on a treeof size N = 224 and ORAM block of size 544 bytes.Table 2 shows the performance of T 3 implementedusing multiple threads for both Circuit-ORAM andPath-ORAM.Comparison to current SPV solutions. We give acomparison in term of performance and communicationoverhead over several number of requests to the exist-ing SPV client’s solution and to BITE [43] Obliviousdatabase.

1. Performance: Figure 7 gives us an overview ofthe performance of T 3 compared to the performance ofthe current existing SPV with Bloom filter solution andthe performance of BITE Oblivious database. In par-ticular, it shows the response latency from the client’sperspective. In this comparison, a request for the SPVsolution with Bloom filter solution means the time thefull node takes to scan one Bitcoin block, and a re-quest for T 3 and BITE means the time it takes to per-form an ORAM access on the ORAM tree. For T 3, weused N = 224 and block of size 544 bytes for bothPath-ORAM with Z = 4 and Circuit-ORAM withZ = 2. For BITE database, based on our understand-ing of their construction, we re-implemented BITE us-ing non-recursive construction of Path-ORAM, and weused the same ORAM block of size 32kB which leads tothe number of block is N = 217. Also, we also provide anadditional construction of BITE which is implementedusing recursive Path-ORAM and suggested parameters


0 20 40 60 80 100 120 140 160

Number of requests

100

101

102

103

104

Ru

nn

ing

Tim

e(m

s)in

log

scal

e

T 3 (Recursive PathORAM), Z = 4, N = 224

T 3 (Recursive CircuitORAM), Z = 2, N = 224

BITE (Path ORAM), Z = 4, N = 217

Improved BITE (Recursive PathORAM), Z = 4, N = 224

SPV with Bloom Filter FPR = 1%


Fig. 7. Performance of T 3 using Path/Cicruit ORAM withblock of size 544B, the current SPV with Bloom filter, OriginalBITE oblivious database block of size 32kB, and improved BITEwith block of size 544B. For the SPV client with Bloom filter, weused the false positive rate of 1% and 5%.

for T 3 where the tree is of size 224 and block of size544B. Figure 7 gives us the overall performance of threeexisting solutions.The performance of T 3 is better than the performanceof the SPV with Bloom filter solution because T 3 doesnot to recompute the Merkle path again for each trans-action as well as to use Bloom filter to scan the block.Also, T 3 outperforms BITE oblivious database as theBITE system does not consider the use of recursiveORAM construction. Another reason is that the sizeof the ORAM block used in BITE is large; hence, thecost of oblivious operation like cmov-based stash scanbecomes more expensive. Thus, we envision and realizean improved construction of BITE using recursive con-struction of Path-ORAM to demonstrate the practicalimpact of using recursive ORAM construction on TEEwith restricted memories.

2. Communication Overhead: In term of communi-cation between client and full node, T 3 offers much lowercommunication overhead compared to the existing so-lution for SPV clients. T 3 does not need to provide theSPV clients with the Merkle proofs to its relevant trans-actions because all those proofs are validated by the In-tel SGX before being added the ORAM tree. Also, dueto the false positive rate used in the Bloom filter, thetraditional full node will send additional irrelevant infor-mation to the SPV client. Figure 8 shows an overview ofthe communication cost of T 3 compared to the currentsolution. To give an estimation of the communicationcost of the current SPV solution, we assumed that eachrequest requires a separate Merkle proof. Moreover, weset the size of the transaction data is approximatelyfpr · BlockSize bytes where the fpr is the false positiverate and the BlockSize is the size of the Bitcoin block.

0 10 20 30 40 50 60 70 80

Number of requests

0

2000

4000

6000

8000

Com

mu

nic

atio

nC

ost

(KB

)

T 3



Fig. 8. Communication cost of T 3 and the current SPV solution.Since both systems return the information of unspent outputs tothe client, the communication overhead of BITE will be equal tothe communication overhead of T 3.

To obtain estiation, we used block 551731 that has theblock size of 1149 KB and contains 3017 transactions.In practice, we would expect the Bitcoin blocks to havedifferent sizes which results the communication cost tobe different across blocks. Therefore, the results in fig. 8is only a pessimistic estimation on the communicationoverhead using the current SPV solution. We omit thecomparison to the communication overhead of BITE be-cause both T 3 and BITE return a fixed amount a datato the SPV clients.Storage Overhead As noted in the previous section,using ORAM incurs a constant size blow up of the stor-age of the UTXOs (e.g., ≈ 4× for Circuit-ORAM,6-8× for Path-ORAM). In particular, for Path-ORAMwith Z = 4, the storage cost of ORAM trees is about≈ 51GB, and for Circuit-ORAM with Z = 2, the stor-age cost of two ORAM tree is around ≈ 26GB. For in-tegrity protection, T 3 only requires the full node to storethe Bitcoin header chain with integrity check which isapproximately 44MB in the untrusted region.

5.3 Comparison with Other ObliviousSystems

We compare T 3 with Bite [43] Oblivious Databasethat also uses ORAM and TEE to provide a genericPIR system for Bitcoin client, ConcurORAM [19]that provides concurrency access to ORAM clients,Obliviate [14] that prevents leakage from file systemaccesses, and ZeroTrace that proposes an efficientgeneric oblivious memory access primitives. section 5.3compares those systems based on the capabilities of sup-porting concurrency access, enabling recursive construc-tion, and preventing side-channel leakage.

For generic trusted hardware-based systems likeBite oblivious database and Obliviate, while provid-ing protection against side-channel leakage, those sys-


Capabilities

System Concurrency Recursive Construction Side-channel Protection

ConcurORAM [19] 3 7 - a

Obliviate [14] 7 7 3

Zerotrace [53] 7 3 3

Bite Oblivious Database [43] 7 7 3

T 3 3 3 3

a ConcurORAM does not aim to provide side-channel protec-tion for TEE. Hence, we omit this comparison.Table 3. Comparison between T 3 and other oblivious systems.

tems do not consider the use of recursive ORAM con-struction to reduce the EPC memory usage. Hence,the performance of those systems will degrade oncethe database becomes too large. Other works that har-nesses the use of recursive ORAM construction are Ze-rotrace; however, concurrency is not supported in thecurrent version of Zerotrace. ConcurORAM is a re-cent ORAM construction that offers concurrency ac-cesses from the clients; however, due to more optimizedeviction strategy and complex synchronization sched-ule, the recursive construction of ConcurORAM in-troduces implementation challenges.

6 System Analysis

6.1 Security Claims

In order to prove the security properties of T 3’s design,we put forth six claims, each of which represents thesecurity of a major component of T 3 in term of privacygoal.Claim 1. The managing enclave does not leakuser-related information to an attacker. Themanaging enclave is responsible for three tasks — (a)converting wallet IDs to UTXOs, (b) creating and man-aging threads which will perform read operations on theread-once ORAM tree, and (c) handle the updates tobe performed on the original ORAM tree. Firstly, theconversion of wallet IDs to their respective UTXOs isprivate since the channel between clients and the man-aging enclave is secured by the shared key during theremote attestation process. When receiving addressesfrom a client, the managing enclave uses blockmappingfunction (described in 4.1.1) to map each address to afixed number of ORAM blocks. This does not reveal in-formation about the number of outputs belonging to anaddress. Secondly, each read thread performs the sameoperations irrespective of the wallet ID provided to it,i.e., each thread simply retrieves an ORAM block usingORAM accesses implemented with cmov-based oblivi-

ous executions. Lastly, the only thing revealed by theupdate process of T 3 is the number of blocks updatedinto the Write Tree. However, this is public informationand T 3 does not try to hide it. Each update is performedusing an ORAM access which ensures that the attackeris unaware of the final position of each block.Claim 2. The optimized read operations on read-once ORAM tree do not leak information. Asexplained in section 4.2.2, the read-once ORAM treeis accessed using an optimized read operation whichchooses not to shuffle and write-back the retrieved pathto the read-once ORAM tree. However, as suggested bythe Bitcoin protocol and the analysis of the UTXO setshown in section 5.1, a majority of the addresses are gen-erated once only to receive new output from the sender.Thus, the read operations are secure as each path cor-responding to a UTXO should only be accessed onceduring a read interval and will be shuffled before thenext interval. On the other hand, the leakage happensonly when the client queries the same address again;however, the client does not need to request again asthere are no new transactions for the next block cre-ation interval.Claim 3. The write operations performed on theoriginal ORAM tree do not leak information.There are two specific operations performed on the orig-inal ORAM tree— (a) the UTXOs are updated basedon the updated bitcoin block, and (b) the previously ac-cessed ORAM blocks are shuffled. However, all of theseupdating accesses are standard ORAM operations im-plemented in a side-channel-resistant manners as previ-ously done by [14, 53]. Therefore, all write operationsreveal no information about a user’s UTXO.Claim 4. The data fetched from the untrustedworld to the TEE is correct. There are two majorsources of data transferred from the untrusted to thetrusted world — (a) the updated block fetched from theBitcoin daemon after a fixed interval and (b) the ORAMtree blocks which are fetched from the untrusted worldinto the TEE. As mentioned in 4.2.3, Bitcoin blocks arefetched from outside the enclave. However, T 3 verifiesthe integrity of the Bitcoin block based on the proof ofwork and the header chain, and since the cost of produc-ing a valid block is expensive, we argue that T 3 shouldbe able to obtain valid block from the Bitcoin network.Also, T 3 maintains a Merkle Hash Tree (MHT) of theORAM trees and therefore prevents malicious tamper-ing by verifying all encrypted data fetched from the un-trusted memory using the MHT.


Claim 5. The multiple threads involved do notcreate synchronization issues. It is worth-notingthat multiple threads are only involved while accessingthe Read Tree of T 3. Thanks to the optimized read op-eration, T 3 does not run into synchronization bugs sincethere is no memory region that could be simultaneouslywritten to by more than one thread. In particular, eachthread shares the position map but only reads from theposition map. Each thread contains its own stash mem-ory which is written to separately by each thread.Claim 6. The memory interactions within theenclave are side-channel-resistant. The designof T 3 incorporates defenses against the side-channelthreats [39, 40, 62] plaguing Intel SGX. In particular,we used ORAM operations to hide all data access pat-terns on the untrusted memory region, and we incorpo-rated similar oblivious operation techniques introducedin [14, 49, 53] to prevent operations inside the enclavefrom leaking sensitive information. Finally, the imple-mentation of T 3 is also secure against branch-predictionattacks since each individual operation (e.g., accessingRead Tree, updating Write Tree etc.) takes the same se-quence of branches and therefore reveals no informationto the attacker, from the accessed branches.

6.2 Other Goals Achieved by T 3

In this subsection, in addition to the Privacy goal de-scribe in section 6.1, we explain how T 3 achieves theother goals mentioned in subsection 2.2.Validity. Under the assumption that the adversarydoes not have enough computational power to form anew Bitcoin block, the system will only obtain validtransaction by verifying the Merkle root and the proofof work of the Bitcoin block.Completeness. By offering different ways of mappingbetween Bitcoin addresses and ORAM block id, we canoffer services to 92− 96% of all clients with some trade-off between storage overhead and performance.Efficiency. First, our system is able to handle burstyrequests from client concurrently because of the two-treedesign. Second, we minimize the downtime of the systemby having the writing enclave performed updates on onetree and reading enclave handled clients’ requests on theother tree. The full node’s downtime now depends on thenumber of requests that the system receives when thewriting enclave performs ORAM updates on the origi-nal ORAM tree. Finally, by enforcing clients to providethe proof of ownership of the address, we prevent otherclients from querying addresses that do not belong to

them; hence, we reduce the number of redundant re-quests from the clients.

6.3 Other attacks and Countermeasures

Denial of Service Attacks from MaliciousClients. While the design of T 3 is practical, a mali-cious client can still incur a large processing time on thefull node by creating lots of addresses and sending largenumber of requests for those requests. One way to miti-gate such attack is to apply fees on users of the service.Another approach to mitigate denial of service attackis to use a cuckoo filter [29] to load and delete unspentaddresses from the UTXO set upon update. Upon re-ceiving requests from client, the managing enclave canverify if the address matches the filter as well as theproof of ownership of that address before performingORAM accesses.Spectre and Related Attacks [38, 42]. T 3 canemploy any TEE which is vulnerable to digital side-channels (i.e., access pattern-inference attacks such aspage table, cache, branch prediction, etc.) but is secureagainst micro-architectural defects (i.e., reading mem-ory contents directly from the TEE). Speculative execu-tion attacks, which fall into the micro-architectural de-fects category, is a concern; however, Intel has recentlyreleased hardware patches to address those. Therefore,T 3 can be effectively used alongside patched processorsto provide SPV client protections against digital side-channel attacks.

7 Related Work

General SGX Systems. Haven [16] is a pioneer-ing work on SGX computing enabling native applica-tion SGX porting on windows. Graphene [20] providesa linux-based LibOS for SGX programs. Ryoan [36]retrofits Native Client to provide sandboxing mecha-nisms for Intel SGX. Eleos [47] provides a user-spaceextension of enclave memory using custom encryption.T 3 uses some concepts from Eleos especially in the waywe store the ORAM tree using custom encryption out-side the SGX enclave.SGX Side-channels. There are three main memory-based side-channel vulnerabilities disclosed within In-tel SGX, namely, page table-based attacks [62], cache-based attacks [18], and branch-prediction attacks [39].Furthermore, since SGX relies on the untrusted OS for


system-call handling, it is also vulnerable to IAGO at-tacks [21]. Leaky Cauldron [59] presents an overview ofthe possible attack vectors against SGX programs. T 3 issecure against all disclosed memory-based side-channelssince it uses oblivious RAM (ORAM) to protect theaccess-patterns. Furthermore, T 3 uses oblivious mem-ory primitives to secure the runtime ORAM operationsas well as its library.Oblivious Systems. Raccoon [49] provided a tech-nique to protect a small part of a user program againstall digital side-channels. Obliviate [14] and Zero-Trace [53] used ORAM-based operations to protectfiles and data arrays respectively inside Intel SGX.Thang Hoang et al. [35] proposed a combination of TEEand ORAM to design oblivious search and update plat-form for large dataset. Eskandarian et al. [28] lever-aged Intel SGX and Path ORAM to propose obliviousSQL database management system. ConsenSGX [52]also used TEE and ORAM to address the scalabilityproblem in the Tor network by allowing Tor client toobliviously fetch parts of the network view from theserver for path selection.

Recently, Chakraborti et al. proposed a new paral-lel ORAM scheme called ConcurORAM [19]. ConcurO-RAM also uses two-tree structure to propose a non-blocking eviction procedure, and the system periodi-cally synchronizes two trees to maintain the privacyof the user’s access pattern. However, ConcurORAMcannot be trivially extended to a recursive ORAM con-struction because of concurrent data structure accesses.Nevertheless, if ConcurORAM can be implemented intoa recursive ORAM construction, we believe that Con-curORAM can be an interesting alternate solution forthe ORAM scheme used in the design of T 3. Anotherparallel ORAM construction is TaoStore [50]. TaoStoreassumes a trusted proxy that handles concurrent client’srequests. However, similar to ConcurORAM, the imple-mentation of TaoStore is limited to the non-recursiveconstruction of Path ORAM.TEE for Cryptocurrencies. Obscuro [57] is a Bit-coin transaction mixer implemented in Intel SGX thataddresses the linkability issue of Bitcoin transactions.Teechan [41] is an off-chain payment micropaymentchannel that harnesses TEE to increase transactionthroughput of Bitcoin. Bentov et al. [17] proposed a newdesign that uses Intel SGX to build a real-time cryp-tocurrency exchange. Another example is the Town-crier system [63] that uses TEE for securely transfer-ring data to smart contract. Another prominent exam-ple is Ekiden [22] which proposed off-chain smart con-

tract execution using TEE. Finally, ZLite [61] systemuses ORAM and TEE to provide SPV clients with obliv-ious access. However, similar to BITE, ZLite employednon-recursive Path-ORAM as it is, and thus, the scal-ability and efficiency of the system is inherently limited.

8 ConclusionIn this paper, we developed a system design that sup-ports an efficient oblivious search on unspent trans-action outputs for Bitcoin SPV clients while securelymaintains the state of the Bitcoin UTXO set via anoblivious update protocol. Our design leverages theTEE capabilities of Intel SGX to provide strong pri-vacy and security guarantees to Bitcoin SPV client evenwith the presence of a potentially malicious full node.Moreover, by putting reasonable assumptions on the ac-cessing frequency of the SPV clients, we present differ-ent optimizations in standard tree-based ORAM con-struction that offers both privacy and efficiency to theclients. We showed that the prototype of the system ismuch more efficient than the use of standard ORAMand TEE construction as it is. Also, our implementa-tion shows one order of magnitude performance gainwhen combining recursive ORAM construction the cur-rent existing construction to stress the importance ofusing recursive ORAM construction in TEE with re-stricted memory.

Finally, while the applicability of T 3 in cryptocur-rencies beyond Bitcoin is apparent, we believe our workwill motivate further research on oblivious memorywith the restricted access patterns and other complexblockchains (i.e. Ethereum) that maintain much biggerstate than the UTXO state.

AcknowledgementsWe thank our shepherd Travis Mayberry and all theanonymous reviewers for their insightful comments andsuggestions towards improving the paper quality. Wethank Sajin Sasy for giving us access to the sourcecode of Zerotrace to build a prototype implementationof this system. This work has been partially supportedby the National Science Foundation under grant CNS-1719196.


References[1] Address reuse. https://en.bitcoin.it/wiki/Address_reuse.

Accessed in Dec 2019.[2] Bitcoin core. https://bitcoin.org/en/bitcoin-core/. Accessed

in Dec 2019.[3] Bitcoin Developer Reference. https://bitcoin.org/en/

\developer-reference. Accessed in Dec 2019.[4] Bitcoin difficulty and network hash rate. https://

bitcoinwisdom.com/bitcoin/difficulty. Accessed in Nov 2019.[5] Bitcoinj. https://bitcoinj.github.io/. Accessed in Dec 2019.[6] Dash. https://www.dash.org/. Accessed in Dec 2019.[7] Deterministic wallet. https://en.bitcoin.it/wiki/

Deterministic_wallet. Accessed in Dec 2019.[8] Electrum Bitcoin Wallet. https://electrum.org/. Accessed in

Dec 2019.[9] Json-roc-cpp. https://github.com/cinemast/libjson-rpc-cpp.

Accessed in Dec 2019.[10] Key stone project. https://keystone-enclave.org/. Accessed

in Dec 2019.[11] Litecoin. https://litecoin.org/. Accessed in Dec 2019.[12] Python-bitcoinlib. https://github.com/petertodd/python-

bitcoinlib. Accessed in Dec 2019.[13] T3 prototype implementation, 2019. https://github.com/

TEE-3/T3.[14] Adil Ahmad, Kyungtae Kim, Muhammad Ihsanulhaq Sar-

faraz, and Byoungyoung Lee. OBLIVIATE: A data obliviousfilesystem for intel SGX. In NDSS, 2018.

[15] Sergei Arnautov, Bohdan Trach, Franz Gregor, ThomasKnauth, Andre Martin, Christian Priebe, Joshua Lind, DivyaMuthukumaran, Dan O’Keeffe, Mark L. Stillwell, DavidGoltzsche, Dave Eyers, Rüdiger Kapitza, Peter Pietzuch,and Christof Fetzer. SCONE: Secure linux containers withintel SGX. In OSDI, 2016.

[16] Andrew Baumann, Marcus Peinado, and Galen Hunt. Shield-ing applications from an untrusted cloud with haven. InOSDI, 2014.

[17] Iddo Bentov, Yan Ji, Fan Zhang, Lorenz Breidenbach, PhilipDaian, and Ari Juels. Tesseract: Real-time cryptocurrencyexchange using trusted hardware. In CCS, 2019.

[18] Ferdinand Brasser, Urs Müller, Alexandra Dmitrienko, KariKostiainen, Srdjan Capkun, and Ahmad-Reza Sadeghi. Soft-ware grand exposure: SGX cache attacks are practical. InWOOT, 2017.

[19] Anrin Chakraborti and Radu Sion. ConcurORAM: High-throughput stateless parallel multi-client ORAM. In NDSS,2019.

[20] Chia che Tsai, Donald E. Porter, and Mona Vij. Graphene-sgx: A practical library OS for unmodified applications onSGX. In USENIX ATC, 2017.

[21] Stephen Checkoway and Hovav Shacham. Iago Attacks:Why the System Call API is a Bad Untrusted RPC Interface.SIGARCH Comput. Archit. News, 2013.

[22] R. Cheng, F. Zhang, J. Kos, W. He, N. Hynes, N. Johnson,A. Juels, A. Miller, and D. Song. In EuroSP, 2019.

[23] Victor Costan and Srinivas Devadas. Intel sgx explained.Cryptology ePrint Archive, Report 2016/086, 2016. https://eprint.iacr.org/2016/086.

[24] Victor Costan, Ilia Lebedev, and Srinivas Devadas. Sanctum:Minimal hardware extensions for strong software isolation. In25th USENIX Security Symposium, 2016.

[25] Artur Czumaj. Lecture notes on approximation and ran-domized algorithms. http://www.ic.unicamp.br/~celio/peer2peer\/math/czumaj-balls-into-bins.pdf. Accessed in2019.

[26] Sergi Delgado-Segura, Cristina Pérez-Solà, GuillermoNavarro-Arribas, and Jordi Herrera-Joancomartí. Analysisof the bitcoin UTXO set. In BITCOIN, 2018.

[27] W. Diffie and M. Hellman. New directions in cryptography.IEEE Transactions on Information Theory, 1976.

[28] Saba Eskandarian and Matei Zaharia. Oblidb: Obliviousquery processing for secure databases. PVLDB, 2019.

[29] Bin Fan, Dave G. Andersen, Michael Kaminsky, andMichael D. Mitzenmacher. Cuckoo filter: Practically betterthan bloom. In Proceedings of the 10th ACM Internationalon Conference on Emerging Networking Experiments andTechnologies, CoNEXT ’14, 2014.

[30] Arthur Gervais, Srdjan Capkun, Ghassan O. Karame, andDamian Gruber. On the privacy provisions of bloom filters inlightweight bitcoin clients. In ACSAC, 2014.

[31] O. Goldreich. Towards a theory of software protection andsimulation by oblivious rams. In STOC, 1987.

[32] Danny Harnik, Eliad Tsfadia, Doron Chen, and Ronen I.Kat. Securing the storage data path with SGX enclaves.CoRR, abs/1806.10883, 2018.

[33] Mike Hearn and Matt Corallo. Connection Bloom filtering,2012.

[34] Ryan Henry, Amir Herzberg, and Aniket Kate. Blockchainaccess privacy: Challenges and directions. IEEE Security &Privacy, 16(4):38–45, 2018.

[35] Thang Hoang, Muslum Ozgur Ozmen, Yeongjin Jang,and Attila A. Yavuz. Hardware-Supported ORAM in Ef-fect: Practical Oblivious Search and Update on Very LargeDataset. In PoPETs, 2019.

[36] Tyler Hunt, Zhiting Zhu, Yuanzhong Xu, Simon Peter, andEmmett Witchel. Ryoan: A distributed sandbox for un-trusted computation on secret data. In OSDI, 2016.

[37] Angela Jäschke, Björn Grohmann, Frederik Armknecht, andAndreas Schaad. Short paper: Industrial feasibility of privateinformation retrieval. In SECRYPT, 2017.

[38] Paul Kocher, Jann Horn, Anders Fogh, , Daniel Genkin,Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp,Stefan Mangard, Thomas Prescher, Michael Schwarz, andYuval Yarom. Spectre attacks: Exploiting speculative execu-tion. In S&P, 2019.

[39] Jaehyuk Lee, Jinsoo Jang, Yeongjin Jang, Nohyun Kwak,Yeseul Choi, Changho Choi, Taesoo Kim, Marcus Peinado,and Brent ByungHoon Kang. Hacking in darkness: Return-oriented programming against secure enclaves. In 26thUSENIX Security Symposium, 2017.

[40] Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim,Hyesoon Kim, and Marcus Peinado. Inferring fine-grainedcontrol flow inside SGX enclaves with branch shadowing. In26th USENIX Security Symposium, 2017.

[41] Joshua Lind, Oded Naor, Ittay Eyal, Florian Kelbert,Emin Gün Sirer, and Peter Pietzuch. Teechain: A securepayment network with asynchronous blockchain access. InSOSP, 2019.

https://en.bitcoin.it/wiki/Address_reuse

https://bitcoin.org/en/bitcoin-core/

https://bitcoin.org/en/\developer-reference

https://bitcoin.org/en/\developer-reference

https://bitcoinwisdom.com/bitcoin/difficulty

https://bitcoinwisdom.com/bitcoin/difficulty

https://bitcoinj.github.io/

https://www.dash.org/

https://en.bitcoin.it/wiki/Deterministic_wallet

https://en.bitcoin.it/wiki/Deterministic_wallet

https://electrum.org/

https://github.com/cinemast/libjson-rpc-cpp

https://keystone-enclave.org/

https://litecoin.org/

https://github.com/petertodd/python-bitcoinlib

https://github.com/petertodd/python-bitcoinlib

https://github.com/TEE-3/T3

https://github.com/TEE-3/T3

https://eprint.iacr.org/2016/086


http://www.ic.unicamp.br/~celio/peer2peer\/math/czumaj-balls-into-bins.pdf

http://www.ic.unicamp.br/~celio/peer2peer\/math/czumaj-balls-into-bins.pdf


[42] Moritz Lipp, Michael Schwarz, Daniel Gruss, ThomasPrescher, Werner Haas, Anders Fogh, Jann Horn, StefanMangard, Paul Kocher, Daniel Genkin, Yuval Yarom, andMike Hamburg. Meltdown: Reading kernel memory fromuser space. In 27th USENIX Security Symposium, 2018.

[43] Sinisa Matetic, Karl Wüst, Moritz Schneider, Kari Kosti-ainen, Ghassan Karame, and Srdjan Capkun. BITE: Bitcoinlightweight client privacy using trusted execution. In 28thUSENIX Security Symposium, 2019.

[44] Mohsen Minaei, Pedro Moreno-Sanchez, and Aniket Kate.R3c3: Cryptographically secure censorship resistant ren-dezvous using cryptocurrencies. Cryptology ePrint Archive,Report 2018/454, 2018. https://eprint.iacr.org/2018/454.

[45] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cashsystem,” http://bitcoin.org/bitcoin.pdf, 2008.

[46] Olga Ohrimenko, Felix Schuster, Cedric Fournet, AasthaMehta, Sebastian Nowozin, Kapil Vaswani, and ManuelCosta. Oblivious multi-party machine learning on trustedprocessors. In 25th USENIX Security Symposium, 2016.

[47] Meni Orenbach, Pavel Lifshits, Marina Minkin, and MarkSilberstein. Eleos: Exitless os services for sgx enclaves. InEuroSys, 2017.

[48] K. Qin, H. Hadass, A. Gervais, and J. Reardon. Applyingprivate information retrieval to lightweight bitcoin clients. In2019 Crypto Valley Conference on Blockchain Technology(CVCBT), 2019.

[49] Ashay Rane, Calvin Lin, and Mohit Tiwari. Raccoon: Closingdigital side-channels through obfuscated execution. In 24thUSENIX Security Symposium, 2015.

[50] Cetin Sahin, Victor Zakhary, Amr El Abbadi, Huijia Lin, andStefano Tessaro. Taostore: Overcoming asynchronicity inoblivious data storage. In S&P, 2016.

[51] E. B. Sasson, A. Chiesa, C. Garman, M. Green, I. Miers,E. Tromer, and M. Virza. Zerocash: Decentralized Anony-mous Payments from Bitcoin. In S&P, 2014.

[52] Sajin Sasy and Ian Goldberg. ConsenSGX: Scaling anony-mous communications networks with trusted execution envi-ronments. PoPETs, 2019.

[53] Sajin Sasy, Sergey Gorbunov, and Christopher W. Fletcher.Zerotrace : Oblivious memory primitives from intel SGX. InNDSS, 2018.

[54] Elaine Shi, T. H. Hubert Chan, Emil Stefanov, and MingfeiLi. Oblivious ram with o((logn)3) worst-case cost. In ASI-ACRYPT 2011.

[55] Emil Stefanov, Marten van Dijk, Elaine Shi, ChristopherFletcher, Ling Ren, Xiangyao Yu, and Srinivas Devadas.Path oram: An extremely simple oblivious ram protocol. InCCS, 2013.

[56] Florian Tramer and Dan Boneh. Slalom: Fast, verifiable andprivate execution of neural networks in trusted hardware. InInternational Conference on Learning Representations, 2019.

[57] Muoi Tran, Loi Luu, Min Suk Kang, Iddo Bentov, and Pra-teek Saxena. Obscuro: A bitcoin mixer using trusted execu-tion environments. In ACSAC, 2018.

[58] Chia-Che Tsai, Kumar Saurabh Arora, Nehal Bandi,Bhushan Jain, William Jannen, Jitin John, Harry A. Kalod-ner, Vrushali Kulkarni, Daniela Oliveira, and Donald E.Porter. Cooperation and security isolation of library osesfor multi-process applications. In EuroSys, 2014.

[59] Wenhao Wang, Guoxing Chen, Xiaorui Pan, Yinqian Zhang,XiaoFeng Wang, Vincent Bindschaedler, Haixu Tang, andCarl A. Gunter. Leaky cauldron on the dark land: Under-standing memory side-channel hazards in sgx. In CCS, 2017.

[60] Xiao Wang, Hubert Chan, and Elaine Shi. Circuit oram: Ontightness of the goldreich-ostrovsky lower bound. In CCS,2015.

[61] Karl Wüst, Sinisa Matetic, Moritz Schneider, Ian Miers, KariKostiainen, and Srdjan Capkun. ZLiTE: Lightweight Clientsfor Shielded Zcash Transactions using Trusted Execution.In International Conference on Financial Cryptography andData Security, 2019.

[62] Yuanzhong Xu, Weidong Cui, and Marcus Peinado.Controlled-Channel attacks: Deterministic side channelsfor untrusted operating systems. In S&P, 2015.

[63] Fan Zhang, Ethan Cecchetti, Kyle Croman, Ari Juels, andElaine Shi. Town crier: An authenticated data feed for smartcontracts. In CCS, 2016.


Kate ATaleofTwoTrees:OneWrites,andOtherReads · Kate ATaleofTwoTrees:OneWrites,andOtherReads...

Documents

Transcript of Kate ATaleofTwoTrees:OneWrites,andOtherReads · Kate ATaleofTwoTrees:OneWrites,andOtherReads...