thang hoang*, muslum ozgur ozmen, yeongjin jang, and ... · composed of two main encrypted data...

Proceedings on Privacy Enhancing Technologies ; 2019 (1):172–191

Thang Hoang*, Muslum Ozgur Ozmen, Yeongjin Jang, and Attila A. Yavuz

Hardware-Supported ORAM in Effect: PracticalOblivious Search and Update on Very LargeDatasetAbstract: The ability to query and update over en-crypted data is an essential feature to enable breach-resilient cyber-infrastructures. Statistical attacks onsearchable encryption (SE) have demonstrated the im-portance of sealing information leaks in access patterns.In response to such attacks, the community has pro-posed the Oblivious Random Access Machine (ORAM).However, due to the logarithmic communication over-head of ORAM, the composition of ORAM and SEis known to be costly in the conventional client-servermodel, which poses a critical barrier toward its practicaladaptations.In this paper, we propose a novel hardware-supportedprivacy-enhancing platform called Practical ObliviousSearch and Update Platform (POSUP), which enablesoblivious keyword search and update operations on largedatasets with high efficiency. We harness Intel SGX torealize efficient oblivious data structures for oblivioussearch/update purposes. We implemented POSUP andevaluated its performance on a Wikipedia dataset con-taining ≥ 229 keyword-file pairs. Our implementationis highly efficient, taking only 1 ms to access a 3KBblock with Circuit-ORAM. Our experiments have shownthat POSUP offers up to 70× less end-to-end delay with100× reduced network bandwidth consumption com-pared with the traditional ORAM-SE composition with-out secure hardware. POSUP is also at least 4.5× fasterfor up to 99.5% of keywords that can be searched com-pared with state-of-the-art Intel SGX-assisted searchplatforms.

Keywords: Secure Enclaves, Intel SGX, Oblivious DataStructures, Oblivious Search/Update.

DOI 10.2478/popets-2019-0010Received 2018-05-31; revised 2018-09-15; accepted 2018-09-16.

*Corresponding Author: Thang Hoang: EECS, OregonState University, E-mail: [email protected] Ozgur Ozmen: EECS, Oregon State University,E-mail: [email protected] Jang: EECS, Oregon State University, E-mail:[email protected] A. Yavuz: CSE, University of South Florida, E-mail:[email protected]. Part of this work done while the authorwas at Oregon State University.

1 IntroductionThe data privacy and utilization dilemma is a com-mon problem in various applications, including, but notlimited to, data outsourcing and breach-resilient sys-tems. Recent data breach incidents targeting online ap-plications (e.g., Apple iCloud, Equifax, British Airways)have shown the importance of protecting data confi-dentiality on the untrusted cloud environment. A naiveapproach is to leverage standard encryption techniquessuch as AES. Unfortunately, such techniques also pre-vent the user from performing even simple queries (e.g.,search or update) on encrypted data, thereby diminish-ing the data utilization.

Searchable Encryption (SE) techniques have beenproposed to offer data confidentiality and search/updatefunctionalities simultaneously. This is achieved by cre-ating an encrypted index (EIDX), which represents thekeyword-file relationships in encrypted files (EDB), bothof which are outsourced to the cloud. One area of SEresearch focuses on designing new SE schemes (e.g.,[14, 43, 55, 68]) with provable security that offer var-ious trade-offs in terms of security, functionality, andefficiency. The other area of research aims to enable en-crypted queries that are compliant with legacy infras-tructure such as database management systems (e.g.,mySQL, mongoDB) [1, 2, 4, 33, 41, 47, 58–60]. De-spite their merits, all these techniques leak access pat-terns, which results in statistical analysis attacks (e.g.,[13, 13, 31, 40, 50, 54, 61, 82]).

The Oblivious Random Access Machine(ORAM) [29] can hide access pattern and, therefore,it can seal the leaks in SE. Unfortunately, becauseORAM is bandwidth-heavy, using ORAM for SE iscostly in the conventional client-server model. To re-duce this communication overhead, recent studies haveinvestigated the support of ORAM with secure hard-ware [3, 24, 51, 63, 65]. Initial studies designed customhardware (e.g., FPGA) to enhance ORAM perfor-mance, and therefore, they might not be easily inte-grated into commercial server systems with a legacy ar-chitecture (e.g., [24, 51, 63]). With the advent of trustedexecution environments on commodity hardware, thedeployment of such hardware-supported cryptographicprimitives becomes more feasible. Intel SGX [17, 37, 38]

Hardware-Supported ORAM in Effect: Practical Oblivious Search and Update on Very Large Dataset 173

has been explored to enable efficient cryptographic oper-ations such as oblivious memory access primitives [3, 65]and functional encryption [23].

Our Objective. The goal of this paper is to take theORAM supported by a commodity secure hardwareto the next level, in which we develop oblivious datastructures using Intel SGX to offer practical oblivi-ous search/update operations on very large datasets.We implemented our techniques to demonstrate theirefficiency compared with state-of-the-art approaches.

1.1 MotivationWe elaborate on some of the key challenges of enablingoblivious search and update operations on large en-crypted outsourced data as follows.ORAM-SE Composition in Standard Client-Server Model. Due to the ORAM logarithmic band-width blowup, the performance of ORAM and SE com-position in the standard network setting was shown tobe inefficient [7, 35, 53]. Naveed et al. [53] conducted ananalytical analysis and concluded that this combinationis worse than streaming the entire outsourced data forsome keyword distributions. Hoang et al. [35] performedreal experiments on the cloud environment and furtherdemonstrated the inefficiency of a direct ORAM and SEcomposition in the client-server model. Our experimentin this paper further confirms that the ORAM and SEcomposition incurs high delays for a large dataset withstandard network settings. Our experiment in section 6has shown that this approach incurs one to two ordersof magnitude more client-server bandwidth overhead forboth keyword search and update operations.State-of-the-art Hardware-Supported ObliviousSearch Platforms. Existing systems [25, 73] requiresecure hardware (e.g., Intel SGX) to process the en-tire outsourced data (e.g., encryption/decryption) foreach search query to completely hide the access pattern.Unfortunately, this approach might also incur a highdelay when dealing with a large amount of outsourceddata since its cost grows linearly with the database size.Moreover, state-of-the-art solutions did not fully inves-tigate the update capability, which seems an essentialfeature of data-outsourcing applications.

ZeroTrace [65] proposed efficient oblivious memoryprimitives by harnessing recursive Circuit-ORAM withIntel SGX. This design is efficient for generic oblivi-ous access purposes, where it does not require storingthe position map and uses Circuit-ORAM, which is morecomputation-efficient than Path-ORAM when harnessedwith secure hardware. Since the authors focus on generic

oblivious memory primitives, oblivious search and up-date functionalities were not investigated in this work.

1.2 Our ContributionsIn this paper, we design a new hardware-assistedprivacy-enhancing platform that we refer to as Prac-tical Oblivious Search and Update Platform (POSUP).Our proposed POSUP enables oblivious (single/multi)-keyword search and update operations on very largedatasets in a much more efficient and practical mannercompared with existing techniques.

Our system design is inspired from ZeroTrace [65],where we synergize SGX-supported ORAM with Obliv-ious Data Structure (ODS) [78] to enable obliviouskeyword search and update operations on encrypteddata. This synergy (i) addresses the network bandwidthand communication hurdles of ORAM-SE compositionin the client-server setting; (ii) eliminates the cost ofprocessing the entire database inside Intel SGX as in[25, 73]; and more importantly, (iii) allows for operationon a large outsourced database without being restrictedby Intel SGX memory as in [3]. This composition alsoenables efficient oblivious keyword update capacity. Wefurther outline our contributions as follows:(1) New oblivious search and update platform design

with SGX: We construct ODS instantiations forEIDX and EDB by harnessing Intel SGX withPath-ORAM [71] and Circuit-ORAM [76]. POSUP al-lows for some query types such as single keywordand multi-keyword queries. Moreover, POSUP sup-ports an efficient oblivious update via our optimiza-tion tricks that exploit some special characteristicsof the underlying oblivious data structures.

(2) Full-fledged implementation and evaluation: We im-plemented POSUP and evaluated its performanceon commodity hardware with a large dataset (e.g., afull-size Wikipedia English corpus) containing hun-dreds millions of keyword-file pairs and millions offiles. Our implementation is efficient, taking only 1ms to obliviously access a 3KB block with SGXhardware. Our experimental results showed thatPOSUP incurs much lower end-to-end delay thanstate-of-the-art solutions as follows:• Compared with the ORAM-SE composition inthe conventional client-server model (without asecure hardware), POSUP incurs 100× less net-work bandwidth overhead and and 1000× fewernetwork communication round-trips. As a re-sult, the end-to-end delay of POSUP is two or-ders of magnitude lower than that of this ap-proach for both keyword search and update op-erations (see section 6 for detailed experiments).


– Compared with processing the entire databasein Intel SGX (e.g., [25, 73]), POSUP requiresless data to be processed by the enclave(i.e. O(logN) vs. O(N), where N is the size ofoutsourced database). This results in POSUPhaving 10× lower end-to-end delay than the ex-isting techniques for up to 99.5% of keywords(see section 6). If the number of searched filesis small, POSUP can be 100× faster. Moreover,POSUP allows oblivious updating, which doesnot seem to be fully investigated in state-of-the-art SGX-assisted platforms (e.g., [25]).

(3) Putting hardware-supported ORAM in real effect:We take the concept of hardware-supported ORAMprimitives to the next level, wherein we developoblivious data structures and routines with opti-mizations to provide practical search and updatefunctionalities on large databases, which was not in-vestigated by existing hardware-supported memoryprimitives (e.g., ZeroTrace). Our implementationwill be available at: www.github.com/thanghoang/POSUP.

2 POSUP OverviewWe first outline our objective and then describe our sys-tem model followed by our threat model.Objective. POSUP’s objective is to utilize a publiccloud server, which is equipped with commodity securehardware, as secure storage that supports search anddynamic update operations over very large encrypteddatasets. To this end, POSUP aims at deploying a prac-tical oblivious encrypted search and update platformto guarantee data confidentiality and no access pat-tern leakage during search and update operations, alongwith a trusted execution. Specifically, to defeat attacksagainst data confidentiality and access pattern leak-ages, POSUP creates a commodity hardware-supportedORAM and Oblivious Data Structure (ODS) platform,which enables oblivious searches and updates efficiently,even for very large datasets. To defeat attacks againstthe server’s execution logic, POSUP runs its ORAM andODS controllers in an enclave protected by Intel SGX.

2.1 System ModelWe first describe our system composition and then sum-marize our POSUP workflow.System Composition. Figure 1 illustrates the com-ponents of POSUP and its composition: a client, an un-trusted server, and a trusted enclave on the server.

Untrusted Memory

ODS Access

SERVER

Recursive ORAM

Index Paths

File IDs

File Paths

4

5

67Files

2

Files 8

3

1

File Position Map

+ODS-DB

Stash

ODS Access

Session key 𝐾𝑠 ORAM key 𝑘𝑜

EnclaveCLIENT

ODS-IDXStash

+

Keyword Hash Table

Keywords 𝑤 Keywords 𝑤

Fig. 1. An overview of POSUP workflow. Encrypted data struc-tures (e.g., ODS-IDX, ODS-DB) stored at the server’s untrustedmemory are created by the client in the initialization phase(described in subsection 4.1). 1 – 2 : The client encrypts the(search/update) query with session key (Ks) and sends it to theenclave. 3 – 6 : The enclave performs oblivious accesses (e.g.,ODS, recursive ORAM) on encrypted data structure componentsto retrieve/update files involved with the query. 7 – 8 : The en-clave encrypts the query results with Ks and sends back to theclient.

A client (the box on the left side) is a remote entitythat generates and manages recursive ORAM and ODScomponents on the untrusted server via an encryptionkey ko. After initializing the system, the client can senda query to update data on the server or to search dataand then receive the search results from the server.

The server comprises two parts: an untrusted serverand a trusted enclave. (i) The untrusted server providesstorage for recursive ORAM and ODS data structures.(ii) The enclave is a trusted part of the server and ex-ecutes ORAM and ODS controller (while protected byIntel SGX). On behalf of the client, the enclave per-forms all oblivious search/update operations upon theclient’s request on the encrypted data structures storedon the untrusted server. To do this, the enclave receivesthe encryption key ko from the client via a secure chan-nel at the initialization.POSUP Workflow. Figure 1 outlines the overview ofoblivious search and update in POSUP.• Initialization: The client first performs the remote at-testation of the enclave (provided by Intel SGX), whichis running on the untrusted server. This attestation stepnot only verifies that the program running in the enclaveis intact but also exchanges cryptographic keys (a ses-sion key Ks) to establish a secure (encrypted) channelbetween the client and the enclave. After establishingthe secure channel, the client also sends a key ko to theenclave, which will be used for ORAM operations.

Upon receiving the key, the enclave on the serverwill initialize encrypted data structures. Our POSUP is

www.github.com/thanghoang/POSUP

www.github.com/thanghoang/POSUP


composed of two main encrypted data structures:ODS-IDX, which is an encrypted index that representskeyword-file relations, and ODS-DB, which stores en-crypted files. Both data structures are stored in theserver’s untrusted memory. We employ the ODS tech-niques proposed in [77] to instantiate ODS-IDX andODS-DB. This data structure initialization step happensonly at the first connection. In other words, to performsearch and update operations, the client requires onlythat a session key (Ks) be exchanged with the enclave.• Oblivious Search/Updates Queries: 1 The client en-crypts the search (resp. update) query with the sessionkey Ks, and sends it to the enclave (through the un-trusted server). 2 Upon receiving the encrypted query,the enclave decrypts it with Ks. 3 The enclave scansthe entire keyword hash table1 to retrieve block IDs andtheir location (path) in ODS-IDX that correspond to thequery. 4 If the query is to search, the enclave performsODS accesses on ODS-IDX using the ORAM key ko

to get matching file IDs. 5 The enclave determines thelocation of file IDs in ODS-DB by executing recursiveORAM accesses with ORAM key ko on the file positionmap structure. 6 The enclave performs ODS accesseson ODS-DB with ko to retrieve file(s) associated withthe query. 7 The enclave encrypts retrieved files withKs and sends them to the client. 8 The client recov-ers encrypted files with Ks. The enclave performs thesame procedure as search for handling the update query,where it first performs a keyword hash table scan andODS accesses on ODS-IDX to update blocks in the en-crypted index, followed by a recursive ORAM access onthe file position map and an ODS access on ODS-DB toupdate file blocks in the encrypted files.

All these strategies enable us to achieve obliviouskeyword search/update operations more efficiently thanprocessing the entire ODS-DB and ODS-IDX in the en-clave [25, 73]. Our system is also more efficient thanthe direct application of existing SGX-ORAM memoryprimitives [65] because we harness the ODS techniquefor both ODS-DB and ODS-IDX, which reduces the num-ber of recursive calls when executing an oblivious key-word search/update query.

2.2 Threat ModelWe build POSUP based on the following assumptions asits threat model. The client is fully trusted and transfersonly the ORAM encryption key ko to the enclave afterestablishing a secure channel with the enclave (There-fore, untrusted parts of server cannot obtain this key).

1 Since keyword universe is arbitrarily large, it is mandatoryto maintain a hash table that uniquely matches each keywordto a block ID in the encrypted index for a given dataset (seesubsection 4.1 for more details).

To establish this secure channel, we rely on the remoteattestation protocol provided by Intel SGX. Thus, weneed a trusted authority (right now, it is Intel) for thisremote attestation protocol; however, this does not haveto be Intel if we utilize a different kind of secure enclave(e.g., Sanctum [18]). We assume the server is untrustedexcept for the enclave. Specifically, we do not trust anyof the server’s logic that includes a virtual machine mon-itor, operating system and drivers, software that man-ages storage, etc. This is a general assumption for a sys-tem that utilizes an enclave because Intel SGX isolatesand applies encryption to the enclave’s memory spaceusing hardware mechanisms.Side-channel attacks against Intel SGX.Intel SGX does not come without limitations; it suf-fers from various side-channel attacks in cache ac-cess [10, 30, 32, 49], memory access [11, 81], regis-ters [48], etc [42, 80]. Unfortunately, preventing side-channel attacks against Intel SGX entirely is a verychallenging task. Instead of making POSUP side-channelfree, we aim only to make POSUP secure against sev-eral known side-channel attacks on Intel SGX, whichare mentioned above. For simplicity, we do not focuson securing POSUP against size and timing informationleakage, which can be easily achieved via padding. Werefer the reader to subsection 4.4 for a more detaileddiscussion.

3 Building Blocks3.1 ORAMThe security of ORAM can be defined as follows.

Definition 1 (ORAM security [71]). Let ~x =(opi, ui, datai)q

i=1 be a data request sequence, whereopi ∈ {read(ui, datai),write(ui, datai)}, ui is the logi-cal address to be read/written and datai is the data atui to be read/written. Let AP(~x) be an access patternobserved by the server given a data request sequence ~x.

An ORAM scheme is secure if for any two data re-quest sequences ~x and ~y of the same length, their accesspatterns AP(~x) and AP(~y) are (computationally or per-fectly or statistically) indistinguishable.

Path-ORAM. Stefanov et al. proposed Path-ORAM [71],the most efficient and simple ORAM scheme, whichfollows the tree paradigm by Shi et al. [66]. In thisparadigm, there are three components: (i) a completebinary tree (stored at the server) with N leaf nodes thatcan store up to N data blocks. Each node in the tree iscalled a bucket, which can store up to Z blocks, all ofwhich are IND-CPA encrypted; (ii) a position map (pos)that associates each data block with a random leaf node


(i.e., path ID); (iii) a stash component (S) to temporar-ily store some blocks. Both pos and S are maintainedby the client. To access a block with Path-ORAM, theclient retrieves its path from pos and then performs aread operation (ReadPath) on its path, in which all realblocks in the path are fetched into S. The client updatesthe retrieved block with a new random path in pos andthen performs an eviction operation (Evict) to push theblocks in S back to the read path such that each blockresides somewhere in an intersection node between theread path and its assigned path toward the leaf. No-tice that the pos component can be stored on the serverin the form of smaller ORAMs via recursion [66, 71].In Path-ORAM, the stash size was proven to be upper-bounded by the security parameter λ as |S| = O(λ)blocks, which characterizes the overflow probability andstatistical security. We describe the detailed algorithmsof Path-ORAM in the Appendix.

Circuit-ORAM. Circuit-ORAM [76] reduces the circuitcomplexity of Path-ORAM by minimizing the numberof blocks that are involved during read and eviction.Each bucket has meta-data that store the informationabout real blocks and their path ID.Read: Similar to the original tree ORAM in [66], theclient reads all data in the path, but keeps only the blockof interest in the stash and removes it from the path.The removal process can be implemented efficiently byflipping only one bit in the bucket meta-data.Eviction: The client prepares a list of blocks to bepushed down in the eviction path by scanning the meta-data of buckets in the path. The client picks one blockin the stash (if any) that can be pushed to the deepestlevel of the tree and then traverses from the root tothe leaf node. In each level, the client drops the on-hold block and picks at most one block to be put intoa deeper level. For each data access, the client invokestwo eviction procedures, with the eviction path beingselected randomly or deterministically, as in [28] (seethe Appendix for details).

Circuit-ORAM incurs approximately 1.25×more I/Oaccesses than Path-ORAM. However, it has a smallercircuit size, and therefore, it is more efficient to beimplemented with Intel SGX [65]. Circuit-ORAM has asmaller bucket size (Z = 2 vs. Z = 4 in Path-ORAM)and, therefore, incurs less server storage. Similar toPath-ORAM, the stash size in Circuit-ORAM was provento be upper-bounded by the security parameter, i.e.,|S| = O(λ) blocks.

3.2 System Building BlocksWe use Intel SGX as a trusted execution environmentto protect the execution of the ORAM controller on

the untrusted server. We run the logic in an SGX en-clave, which guarantees the isolation and confidential-ity of its execution, to protect the ORAM controllerlogic from attacks. We utilize the remote attestationprotocol of Intel SGX to check the integrity of our logicand securely exchange/provision secret keys for storingORAM data structures, as well as to protect communi-cation channels between the enclave and the client. Wealso implement our logic in the enclave using obliviousprimitives in the Intel processor such as CMOV and SETEinstructions to prevent potential access pattern leakage.

As building blocks of POSUP, we utilize the follow-ing components of Intel SGX:• Enclave: An enclave is a trusted execution unit

of Intel SGX, and it is protected by isolation and in-tegrity/confidentiality guarantees. Intel SGX isolatesthe enclave’s execution by providing a private memorycalled the enclave page cache (EPC), which resides in areserved space in DRAM (the processor reserved mem-ory, PRM) [17]. The EPC is isolated from the other soft-ware security domains by SGX’s hardware mechanism.Thus, SGX blocks any software attempt to read/writeenclave’s memory from user-level as well as privileged-level (including operating systems and virtual machinemonitor) attackers. Moreover, because SGX encrypts(with integrity check) the data before storing it on toDRAM, EPC stores only encrypted data on it. There-fore, any hardware attempt to read enclave’s memorywill not leak any meaningful information, and any tam-pering to enclave’s memory will be detected (and thenSGX stops the enclave’ execution).• Remote attestation and key exchange: SGX sup-

ports the remote attestation of the enclave to authen-ticate whether the configuration of the enclave is cor-rect and to share a secret key for secure communica-tion [17, 39] only after the authentication. When a re-mote attestation request initiated by a client is deliveredto the enclave, the SGX subsystem will run the trustedquoting enclave, which creates a measurement (i.e., hashof configurations, loaded program with a nonce, and apublic key material for key exchange) of the enclave andsigns it (with the quoting enclave’s key). This measure-ment will be submitted to the Intel Attestation Service(IAS) to verify the quoting enclave’s signature; the re-sult will be signed by IAS and then will be delivered tothe client. By verifying IAS’s signature on the result,the client ensures that a correct enclave is running onthe server. The attestation message also includes publickey parameters of the Diffie-Hellman key exchange ofthe client and the enclave so that a client can securelycommunicate with the enclave after this process, by en-crypting data using the shared secret.


• Privacy concerns on relying on Intel SGX: Theroot of trust of Intel SGX relies on an infrastructureprovided by Intel (e.g., the Intel Attestation Service andthe quoting enclave). Our current implementation usesIntel SGX for its secure enclave; therefore, its privacyis bound to Intel’s discretion. However, we believe thatthis is just an implementation-specific issue and thatthe use of alternative open-source secure enclaves suchas Sanctum [18] on the RISC-V architecture [79] couldrelax this restriction, e.g., by distributing trust over thePublic Key Infrastructure (PKI), similar to how Trans-port Layer Security (SSL/TLS) works in practice.• System calls: Because an enclave is a part of the

user-level process, Intel SGX does not provide any pro-tection on privileged operations such as system calls,e.g., file and network I/O, etc. Because such operationshave to be performed by the untrusted OS, the en-clave must encrypt data before transferring them to theOS. For example, a network communication between theclient and the enclave should apply encryption to theirconnection, and a file write operation should store onlyencrypted data. For this purpose, Intel provides cryp-tographic libraries and tools for secure data migrationbetween the enclave and the OS so the enclave can se-curely communicate across the security boundary if itis provisioned with a secret key for the encryption; thiscan be done securely via remote attestation.Secure operations inside enclave. We implementoblivious assignment (oupt) and oblivious equality com-parison (ocmp) functions based on CMOV and SETE in-structions proposed in prior works [57, 62], which donot leak access patterns via control-flow side-channelattacks when POSUP executes the ORAM controller in-side the enclave as follows.• pred← ocmp(x, y): It takes as input two values x, y,and outputs pred = 1 if x = y or pred = 0 otherwise.

• z ← oupt(pred, x, y): It takes as input two values x,y and a boolean pred. It assigns z ← y if pred = 1,and z ← x otherwise.We refer interested readers to prior works [57, 62] for

a detailed description of these functions. Note that ourocmp function slightly differs from what was originallyproposed in [57], where we employ SETE instead of SETGinstruction for equality checking.

B ← OGet(S, bID):1: B ←⊥2: for i = 1, . . . , |S| do3: v ← ocmp(S[i].bID, bID)4: B ← oupt(v, S[i], B)5: return B

Fig. 2. OGet function in POSUP.

ODS-IDX

Real file blocks

ODS-DB

Real index blocksPointer to next block Pointer to next block

Block ID(bID)

Path(pID)

1 12 4

Keyword Block ID(bID)

Path(pID)

Count(𝜎)

hello 1 2 15world 2 3 8

Keyword position map File position map(stored at the server recursively

in small ORAMs)(stored at the server in encrypted form)

Fig. 3. Illustration of ODS-IDX and ODS-DB packaged intoORAM tree in POSUP. Blanked nodes denote dummy blocks,while colored nodes denote real file/index blocks. In colorednodes, pattern-filled nodes denote the head block of linked lists.

ZeroTrace [65] proposed OReadPath and OEvict,which are secure versions of ReadPath and Evict tree-based ORAM functions, respectively, both of which areexecuted by the enclave without leaking side-channel ac-cess patterns. We implemented our version of OReadPathand OEvict and refer readers to ZeroTrace [65] for a de-tailed description. In OReadPath and OEvict, we scanthe entire stash and path and then use ocmp andoupt to put real blocks from the path to the stash,or vice versa. This results in Path-ORAM being morecomputation-expensive than Circuit-ORAM as follows.Since Path-ORAM pushes all real blocks from the pathto the stash or vice-versa, its OReadPath and OEvict in-cur two nested loops, where we must scan the entirestash for each path slot access to hide the access pat-tern. Circuit-ORAM processes only one targeted blockat a time and only incurs two separate loops that scanthe entire path once to get target blocks and the entirestash. As a result, Circuit-ORAM is more computation-efficient than Path-ORAM when dealing with a largedataset and large block size (see section 6). We thenimplement the OGet function (Figure 2), which readsa block ID from the stash S into the enclave withoutleaking access patterns via ocmp and oupt.

4 The Proposed PlatformWe first describe the oblivious data structures inPOSUP. We then present the oblivious search and up-date protocol in detail.

4.1 Oblivious Data StructuresFigure 3 presents the overview of ODS-IDX and ODS-DBin POSUP. ODS-IDX and ODS-DB follow the tree


ODS.Setup(DB):1: B ← ∅;B′ ← ∅2: W := (w1 . . . , wM )← Extract all unique keywords in DB3: Construct inverted index IDX ←

(〈wi, ~idi〉Mi=1

), where

~idi := (〈idi1 , 1〉 . . . , 〈idin , 1〉) are file IDs containing wi

4: for each file fi ∈ F do5: Split fi into mi chunks of size |B|6: Bij .DATA← j-th chunk; Bij .pID $←− [2L] ∀j ∈ [m]7: for j = 1, . . . , mi − 1 do8: Bij .NextID← Bij+1.bID9: Bij .NextPath← Bij+1.pID10: posf [Bi1.bID]← Bi1.pID11: B ← B ∪ {Bi1, . . . , Bimi}12: ODS-DB← BuildORAMTreeko (B)13: BuildRecursiveORAM(posf )14: for each keyword wi ∈ W do15: ~idi ← IDX[wi]16: Split ~idi to m′i chunks (ci1, . . . , cim′

i) each of size |B′|

17: B′ij .DATA← cij ; B′ij .pID $←− [2L′ ] ∀j ∈ [m′]18: for j = 1, . . . , m′i − 1 do19: B′ij .NextID← B′ij+1.bID20: B′j .NextPath← B′ij+1.pID

21: B′ ← B′ ∪ {B′i1, . . . , B′im′

i

}

22: ODS-IDX← BuildORAMTreeko (B′)23: TW[wi]← (Bi1.bID, Bi1.pID, |ci1|) for each wi ∈ W

Fig. 4. Setup algorithm to construct oblivious data structures inour system. 2-3: Construct inverted index (IDX) from files (DB).4-12: Build ODS-DB from DB. 13: Build recursive ORAM struc-ture for file position map (posf ). 14-22: Build ODS-IDX fromIDX. 23: Build keyword hash table (TW). All data in ORAMstructures (12,22) are encrypted with ORAM key ko. B, B′ de-note an ORAM block in ODS-DB and ODS-IDX, resp. L and L′

denote the height of ODS-DB and ODS-IDX, resp. |B| denotesthe size of B. [x] denotes {1, . . . , x}.

ORAM paradigm in [66] because POSUP harnessesPath-ORAM and Circuit-ORAM as oblivious access cryp-tographic primitives. We create a search index (IDX)from a set of plaintext files (DB) and then package IDXand DB into ODS-IDX, ODS-DB, respectively, as follows.Encrypted index. We construct IDX as an invertedindex, in which given DB as the input, we extract uniquekeywords and associate each keyword wi with the list ofcorresponding file IDs idij that wi appears in as wi :=(idi1 . . . , idin

). We divide the list of each keyword in IDX

into multiple chunks of the same size and package theminto separate tree ORAM blocks. We use the pointertrick (i.e., linked list in [78]) to connect these blocks witheach other, where the information of successive blocksis stored in their predecessors. Thus, each block is inthe form of B :=

(bID,DATA,NextID,NextPath

), where

bID is the block ID; DATA := (〈id1, σ1〉, . . . , 〈idn′ , σn′〉)is the block data, which contains a partial list of file IDs(id) as well as their state (σ ∈ {0, 1}) indicating whether

they are added or deleted; NextID and NextPath are theID and the path of the next block, respectively. Finally,we create ODS-IDX by putting all constructed blocksinto a tree ORAM structure.Keyword position map. Since keywords are arbi-trary and can be of any length, POSUP maintains ahash table data structure (TW) to map each arbitrarykeyword to an ORAM block ID (bID) as well as its path(pID) in ODS-IDX. Additionally, POSUP stores a counter(βi) for each keyword in TW to indicate the actual num-ber of 〈id, β〉 pairs that are stored in the head block ofthe list. So, TW is of the form 〈key, value〉, where keyis the hash of the keyword and value contains a triplet(bID, pID, β). We denote the access operation to thevalue component in TW as (bID, pID, β)← TW[wi].

In POSUP, we maintain TW under the encryptedform in the storage server. This allows the client to bestateless and easily extensible to the multi-client setting(see subsection 4.3 for further discussion). Since, to thebest of our knowledge, there is no oblivious hash tablemechanism, the enclave performs a linear scan on TWfor reading/writing component(s) in TW to hide the ac-cess pattern. Notice that recursive-ORAM might not beapplied on TW because it requires deterministic indexesto operate, while keywords to be accessed are arbitrary.Encrypted files. We apply the same principle as inthe encrypted index construction to build ODS-DB fromDB. Since each file is organized into a linked list, we setB.bID = id, where B is the first block in the list and id isthe ID of the file that B represents. Given that the sizeof IDX is generally smaller than that of DB, we buildODS-IDX and ODS-DB as two separate oblivious datastructures, where the block size of ODS-IDX is smallerthan that of ODS-DB.File position map. POSUP maintains the file posi-tion map to keep track of the path of the head block ineach ODS linked list. Note that we can index file IDswith an integer from 1 to N , where N is the total num-ber of files in DB since POSUP focuses on search and up-date functionalities on keywords appearing in DB. Thisallows us to maintain the file position map via a re-cursive ORAM in the server side. Our design needs toperform only recursive ORAM access to get the path ofthe starting block, while the path of other blocks in thelinked list is obtained from their predecessor due to theODS technique. This reduces the number of recursivecalls on the file position map compared with the directapplication of oblivious memory primitives (e.g., [3, 24])for enabling oblivious query functionality.

We present the detailed algorithm to constructODS-IDX and ODS-DB in Figure 4. We encryptODS-IDX and ODS-DB with ORAM key ko and storeboth ODS-IDX and ODS-DB on the server’s untrusted


memory. The stash components required by underlyingORAM schemes are also encrypted with ko and storedin the server’s untrusted memory. They are loaded anddecrypted in the enclave when needed.

4.2 Update and Search ProtocolsSince search operations require us to clear stale datathat might arise due to previous update operations, wefirst introduce the oblivious update protocol in POSUPand then describe the oblivious search.

4.2.1 Oblivious Update

For simplicity, we assume that the file to be updated(fid) is already present at the client side. The updateoperation incurs fid to be added/deleted/modified fromEDB, and some keyword-file pairs to be added/deletedfrom EIDX. Intuitively, for each keyword (wi) to be up-dated in fid, the client requests the enclave to add idalong with the update state (add/delete) to an emptydata slot in the head block of the linked list, which rep-resents the search result of wi in EDB. If there is noavailable slot, the enclave picks an empty block2 in EDB,adds update information into it and then links it withthe current head block of the linked list by updatingits NextID and NextPath values. This strategy results inblocks close to the head of the list containing the latestupdated file IDs. Figure 5 outlines the oblivious updateprotocol with the following details.1) Update ODS-IDX: The client updates the file content,and forms a list of keywords (−→w ) to be added or deletedin the updated file (fid) ( 1 ). The client encrypts theupdate query (q) containing id and −→w withKs and sendsit to the enclave. The enclave decrypts q with Ks ( 2 )and then accesses the entire keyword position map (TW)to retrieve the block ID (bID), path (pID), and currentcounter (β) of updated keywords ( 3 ). For each updatedkeyword (wi), the enclave checks whether there is anempty slot in the head block of wi in ODS-IDX ( 3 ).If this does not hold, the enclave gets the ID and thepath of an empty block in ODS-IDX ( 5 ) and updatesthis block as the new head of the linked list of wi inTW ( 6 ). Notice that POSUP performs all comparisonand update operations in the oblivious manner usingocmp and oupt functions described in subsection 3.2 toprevent instructional leakage. Once the target block isdetermined, the enclave performs an ORAM access onODS-IDX to add id and the update state (σ) into it( 7 –11). Specifically, for each updated keyword (wi), theenclave first executes OReadPath with path pIDi ( 7 ) to

2 ID of empty blocks can be stored in a separate data structure(e.g., list).

𝐾𝑠: Session key𝑘𝑜: ORAM key

Client Untrusted Memory

𝑤,𝑓id ← Dec𝐾𝑠 (𝑞)

𝐵𝑖 ← OGet(𝑆, bID𝑖)

Add (id,𝜎𝑖) to 𝐵𝑖 . DATA

OReadPath𝑘𝑜 𝑆

pID𝑖

OEvict𝑘𝑜

7

8

ODS-IDX+

Stash 𝑆

ODS-DB+

Stash 𝑆′

𝑆,𝐵𝑖

File Position

Map

⋮ ⋮ OReadPath𝑘𝑜

OEvictOEvict OEvict𝑘𝑜

bID′, pID′,𝑓id

1

2) ORAMaccess

on ODS-IDX

3)Recursive

ORAM access on file

position map

4) ODS access on

ODS-DB

Secure Enclave

𝑤 ← GetUpdtKW(𝑓id)

𝑓id ←Update (𝑓′id)

𝑞 ← Enc𝐾𝑠 𝑤, 𝑓id

bID′ = id

KeywordHash TableTW

(bID� 𝑖 , pID� 𝑖) ← getEmptyBlk(TW)bID𝑖 , pID𝑖 ,𝛽𝑖 ← TW[𝑤𝑖]

bID� 𝑖 ← oupt 𝑣𝑖 , bID𝑖 , bID� 𝑖𝛽𝑖 ← oupt 𝑣𝑖 ,𝛽𝑖 + 1,1

pID� 𝑖 $← 1, … ,𝑁

𝑣𝑖 ← ocmp(𝛽𝑖 , |𝐵|)

TW 𝑤𝑖 ← bID� 𝑖 , pID� 𝑖 ,𝛽𝑖

𝑤 = 𝑤1,𝜎1 , … , 𝑤𝑚,𝜎𝑚

𝐵𝑖 . NextID ← oupt 𝑣𝑖 ,𝐵𝑖 . NextID, bID𝑖𝐵𝑖 . NextPath ← oupt 𝑣𝑖 ,𝐵𝑖 . NextPath, pID𝑖

Follow similar logic from ORAM Access on ODS-IDX

in steps -

no

bID′𝑖 ← 𝐵′. NextIDpID′𝑖 ← 𝐵′. NextPath

𝐵′

yes

1) Load entire TW to

Enclave

ack msg

𝑖 = 1

Repeat above steps ( - ) for 𝑖 = 2, … ,𝑚

2

3

4

5

6

910

11

13

14

15

16

17bID′ = 0 ?

3 11

7 11

12

Fig. 5. Our oblivious update protocol. 1 - 2 : Generate (en-crypted) update query. 3 - 6 : Access on entire keyword hash ta-ble (TW). 7 -12: Update encrypted index (ODS-IDX) via ORAMaccess. 13-14: Recursive ORAM access on file position map toretrieve location of updated file. 15-17: Update the file via ODSaccess on encrypted files (ODS-DB).


fetch the block (Bi) of ID bIDi from ODS-IDX into thestash (S). Second, it reads Bi from S via OGet ( 8 ) andthen adds 〈id, σ〉 to the block data (Bi.DATA) ( 9 ). If Bi

was previously empty, it updates the pointer of Bi tolink it with the current block head of wi (10). Finally,the enclave performs OEvict to write the updated Bi

back to ODS-IDX (11).2) Update ODS-DB: Given the ID (id) of the updatedfile (13), the enclave executes recursive ORAM accesseson the file position map to retrieve the location of idin ODS-DB (14). The enclave splits the updated file fidinto several chunks and then executes ODS access onODS-DB to update the ORAM data blocks in the linkedlist of fid with these chunks (15–17).

We can see that the deletion in POSUP does notactually delete some real data in ODS-IDX but insteadperforms addition with the state bit (σ = 0). This lazydeletion enables the efficient update, which only requiresO(1) access on the encrypted index compared with O(r)in the actual deletion due to the search, where r is thenumber of files in which the updated keyword appears.The price to pay for this efficiency is the cost of increas-ing the actual size of the search index and the searchcomplexity. To mitigate this impact, after k (system pa-rameter) successive updates, POSUP performs a dummysearch on the most frequently updated keyword to dogarbage collection, since the search operation in POSUPwill clear stale data appearing in blocks toward the tailof the linked list, as described in the next section.

4.2.2 Oblivious Search

Figure 6 presents the oblivious search protocol inPOSUP. First, the client executes the remote attesta-tion protocol with the enclave to establish a securecommunication channel with a session key (Ks). Theclient then encrypts the search query of the form q =w1 ?1 · · · ?m−1 wm with Ks, where ?i ∈ {∨,∧} ( 1 ) andsends it to the enclave. The enclave decrypts q with Ks

to obtain the list of searched keywords (wi) and per-forms the following operations.1) Access on keyword hash table (TW): The enclavescans TW entirely to get the block ID (bIDi) and itspath (pIDi) in the index (ODS-IDX) of each wi ( 2 ).2) ODS access on ODS-IDX: For each 〈bIDi, pIDi〉 pair,the enclave performs an ODS access on ODS-IDX (con-taining multiple ORAM accesses) to retrieve all blocksin the linked list, all of which form the entire list offile IDs (Ri) matching wi ( 3 –11). According to our up-date strategy (see subsubsection 4.2.1), blocks towardthe head of the oblivious linked list will contain fileIDs with the most up-to-date update state. Hence, dur-ing the block update operation ( 5 ), the enclave will

𝐾𝑠: Session key𝑘𝑜: ORAM key

Client Untrusted Memory

OReadPath𝑘𝑜 𝑆

pID𝑖

OEvict𝑘𝑜

ODS-IDX+

Stash 𝑆

ODS-DB+

Stash 𝑆′

𝑆,𝐵

File Position

Map

⋮ ⋮ OReadPath𝑘𝑜

OEvictOEvict OEvict𝑘𝑜

1

2) ORAMaccess on ODS-IDX

3)Recursive

ORAM access on file

position map

4) ODS access on

ODS-DB

Secure Enclave

KeywordHash

Table TW

Follow similar logic from ODS Access on ODS-IDX in

steps - for each pair bID𝑖

′ , pID𝑖′ , 1 ≤ 𝑖 ≤ 𝑛

1) Load entire TW to

Enclave

2

11

13

14

15

16

𝑞 ← Enc𝐾𝑠(𝑞′)

𝑞′ = 𝑤1 ⋆1 … ⋆𝑚−1 𝑤𝑚

𝑞 𝑤1 ⋆1 … ⋆𝑚−1 𝑤𝑚 ← Dec𝐾𝑠 (𝑞)

bID𝑖 , pID𝑖 ← TW[𝑤𝑖]

TW 𝑤𝑖 . pID𝑖$← 1, … ,𝑁

(for 1 ≤ 𝑖 ≤ 𝑚)

𝐵𝑖 ← OGet(𝑆, bID𝑖)

Update block 𝐵𝑖

Add 𝐵𝑖.DATA to 𝑅𝑖

𝑖 = 𝑚?

bID𝑖 ← oupt 𝑣𝑖 ,𝐵𝑖 . NextID, bID𝑖+1pID𝑖 ← oupt 𝑣𝑖 ,𝐵𝑖 . NextPath, pID𝑖+1

𝑣𝑖 ← ocmp(𝐵𝑖 . NextID, 0)

bID′1, … , bID𝑛

′ ← (𝑅1⋆1 … ⋆𝑚−1 𝑅𝑚) 12

bID1′ , pID1

′ , … , bIDn′ , pID𝑛

′

𝐹1, … ,𝐹𝑛

Enc𝐾𝑠 𝐹1, … ,𝐹𝑛Dec𝐾𝑠(𝐹1, … ,𝐹𝑛)

3

4

5

67

8

9

1718

yes

no

𝑖 ← oupt 𝑣𝑖 , 𝑖, 𝑖 + 110

3 11

Fig. 6. Detailed search protocol. 1 - 2 Generate encrypted searchquery (q). 3 -12 ODS access on ODS-IDX to retrieve file IDsmatching with q. 13-14 Recursive ORAM access on file positionmap to get the location of matched files. 15-18 ODS access onODS-DB to retrieve all matched files and send to the client.

clear stale file IDs in the accessed block if they are al-ready present in Ri, or their most recent update statusis “delete.” Once the block becomes empty (meaning itdoes not contain any file IDs left), the enclave will storeits ID in the empty list in TWso that it can be re-used


later in the update operation. After the block is accessedwith ORAM, the enclave determines if it links with an-other block via ocmp ( 8 ). If this holds, the enclave getsthe next block information ( 9 ) and continues the obliv-ious access as above. Otherwise, it processes the nextsearched keyword (10).

Note that we perform all these conditional checksand processing in an oblivious manner via ocmp andoupt functions. This prevents POSUP from leaking theinformation regarding size of individual searched key-words (11) but only the total amount of data that areprocessed due to the search query.3) Recursive ORAM access on file position map: Afterthe file IDs (stored in Ri) of each keyword wi are re-trieved, the enclave performs union/intersection on Ri

according to ?i to get the final list of file IDs matchingq (12)3. For each block bID′i in the joint list, the enclaveperforms recursive ORAM access (13) on the file posi-tion map structure to retrieve the corresponding pathpID′i of bID′ in ODS-DB (14).4) ODS access on ODS-DB: The enclave performs a se-quence of ODS accesses on ODS-DB with the same logicas ODS-IDX accesses to retrieve the file content of eachbID′i (15–16). Finally, the enclave encrypts all the re-trieved files with the session key Ks (17), and sendsthem to the client for decryption (18).Discussion. One might observe that although POSUPcan support boolean queries, the strategy we have ap-plied is simple, in which we conduct an oblivious searchon each keyword present in the query first, followedby taking the union/ intersection over all the searchresults. This trivial strategy is not (sub)optimal andmight be inefficient for some complex boolean forms,in which each keyword appears in a large proportionof databases, but the final combination only returns afew results. Nonetheless, our main focus in this paperis to demonstrate the effectiveness of using secure hard-ware to improve the performance of searchable encryp-tion and ORAM composition in practice. Therefore, webuild the POSUP platform by leveraging a simple obliv-ious data structure in the form of a single linked list,which seems only optimal for single keyword queries andefficient update. We leave the POSUP optimization forother query functionalities (e.g., ranked query, conjunc-tive query) as open research questions.

Another limitation of POSUP is the linear scan ofthe keyword hash table in the enclave due to our col-lision concern when obliviously mapping arbitrary key-words to a finite set (block IDs). To improve this, onemight consider using the power of two choices hash-ing technique [64] to minimize the collision probability,

3 Since the file ID (id) is assigned to the ID (bID) of the headblock in the linked list, we use id and bID interchangeably.

thereby enabling (recursive) ORAM operations atop thekeyword hash table. We will also leave this as an openresearch question to be investigated in the future work.

4.3 Extension to Multi-user SettingIn POSUP, the client is stateless. Thus, it is easy toextend POSUP into the multi-user setting including adata owner (who owns n outsourced files), a storageserver, and k users (who want to search/update on n

files) as follows. The data owner creates an access con-trol data structure (ACDS) to grant permission (e.g.,search/update) for k users on n files. The data owner en-crypts and sends ACDS to the enclave, along with the en-crypted index (ODS-DB) and encrypted files (ODS-DB)that are constructed, as described in subsection 4.1, allof which are stored in the server’s untrusted memory(e.g., SSD).

Given that a user wants to search for a keyword,he/she will authenticate with the enclave using, for ex-ample, the user identifier and password. If authenti-cated, the enclave performs oblivious access on ODS-IDX(as described in subsubsection 4.2.2) to obtain file IDsmatching the query. For each file ID, the enclave ac-cesses ACDS with ORAM to check whether the user hasthe read permission on the file. If so, the enclave per-forms oblivious access on ODS-DB to retrieve the fileand sends it to the user. The same principle applies tothe file update procedure. Roughly speaking, the en-clave first authenticates the user and then obliviouslyaccesses ACDS to check whether the user has the up-date permission on the file. If permitted, the enclaveexecutes the oblivious update protocol as presented insubsubsection 4.2.1.

4.4 SecurityODS and ORAM. We design and build POSUP byusing ODS and ORAM, and therefore, its security isinherited from the security of these tools. Specifically,these tools guarantee that POSUP hides all access pat-terns on ODS-IDX and ODS-DB, given that they havethe same length as in Definition 1.

In POSUP, we can observe from Figure 5 and Fig-ure 6 that search and update operations incur the sameoblivious access procedures on encrypted data struc-tures. In particular, given a search/update query, the en-clave first performs (i) access on the entire keyword hashtable and then, (ii) ODS access(es) on ODS-IDX, fol-lowed by (iii) recursive ORAM access(es) on the file po-sition map, and finally (iv) ODS access(es) on ODS-DB.In the update protocol, add and delete operations alsoinvoke the same oblivious access procedure, where theydiffer from each other only in terms of the state bit


value (σ), which is encrypted in the view of the attacker.Hence, in general, any search/update queries that are ofthe same size and incur the same number of (recursive)ORAM and ODS accesses are indistinguishable.Size information leakage. Since ORAM and ourlinked list ODS do not hide the number of obliviousaccesses, POSUP might leak the size of the query, whichcan allow the attacker to distinguish access patterns,thereby learning information about the query. The sizeinformation can be inferred in several points when theenclave performs oblivious operations as follows. In thesearch protocol (Figure 6), the size can be learned byan attacker from (i) the search query ( 1 ); (ii) the num-ber of accesses on the keyword hash table ( 2 ) and theencrypted index (11,12); (iii) the number of recursiveORAM accesses on the file position map (13,14) andencrypted files (16); (iv) and the result returned to theclient (17). Similarly, in the update protocol (Figure 5),the size can be leaked from the update query ( 1 , 2 ),or the number of accesses on encrypted data structures(12,17).

To mitigate the impact of size leakage, we can applypadding to all aforementioned positions. For instance,for the query that requires less than n′ total ORAMaccesses, one can add dummy ORAM accesses on bothODS-IDX and ODS-DB, and dummy recursive ORAMaccesses on the file position map to quantize the totalnumber to be n′, thus making the query size indistin-guishable by the attacker. We can further apply paddingto obfuscate the actual size of the search/update queryas well as the size of (search) results being sent from theenclave to the client at the end of the protocol. However,we notice that such padding strategies are generallyapplication-specific, which fully depends on the char-acteristics of a particular dataset and user preferences,and also might incur heavy bandwidth and processingoverhead as the trade-off. This is because padding willincrease the cost of oblivious operations less than n′

(suppose the number of required operations is n) to beequal to that of n′ actual operations (where n′ > n ).We refer the reader to Ryoan [36] for its parts of data-oblivious communication as well as quantizing process-ing time to learn more on how the size quantization bypadding can thwart such a side channel attack.Other side-channel attacks against enclave. Al-though the enclave of Intel SGX provides security guar-antees such as data confidentiality and integrity againstdirect memory access attacks, it is not free from side-channel attacks. POSUP does not aim to defeat allsorts of side-channel attacks, which seems to be a verydifficult task; instead, we try to build POSUP as abest-effort approach to make it secure against knownside-channel attacks. The use of recursive ORAM and

ODS in POSUP naturally defeats side-channel attackson data access patterns such as cache side-channel at-tacks [10, 30, 32]. Employing oblivious data comparison(ocmp) and oblivious data assignment (oupt) in POSUP(see subsection 3.2) defeats attacks on the control-flowside channel [11, 49, 81] because these primitives elimi-nate conditional branches on processing secrets. There-fore, such attacks cannot measure a difference in control-flow for different secrets.

5 ImplementationWe implemented POSUP with C/C++ using theIntel SGX SDK v1.7. Our implementation contains atotal of around 4.9K lines of code for trusted anduntrusted modules. For cryptographic operations in-side the enclave, we leveraged Intel SGX SDK libraryfunctions including sgx_aes_ctr_encrypt for encrypt-ing ORAM with AES-CTR mode and sgx_read_randfor pseudo-random number generation. We imple-mented Path-ORAM and Circuit-ORAM controllers inan enclave to execute ODS access on ODS-DB andODS-IDX. As mentioned in section 4, our platform storesORAM stashes encrypted in the untrusted memory(RAM/SSD), and they are loaded into the enclave whenneeded.

6 EvaluationWe first describe our configuration and evaluationmethodology, followed by the main experimental results.

6.1 Configuration and MethodologyHardware. We evaluated the performance of our sys-tem on a commodity HP Desktop, which supports IntelSGX and is equipped with Intel E3-1230 v5 @ 3.4 GHzCPU, 16GB RAM and 512GB SSD.Dataset. Our dataset is the full Wikipedia Englishcorpus enwiki v.20180120. To extract text data from thecorpus, we used WikiExtractor [5] Python script and ex-tracted 5,554,594 distinct text-only articles (i.e., filesin our term) from enwiki. To collect the keywordsfor the search, we implemented a standard tokeniza-tion method to extract unique alphabetical and non-alphabetical keywords from the dataset. The total num-ber of unique keywords in the dataset is 7,075,917 andthe total number of keyword-file pairs is 863,782,383.The total size of the database (DB) is 27 GB (on thedisk), and the total size of the search index (IDX) is6.9 GB. Figure 7 presents the size distribution of textarticles in the enwiki dataset.


2022242628210212214216218220

10.90.80.70.60.50.40.30.20.10

File size (bytes) in log scale

Fraction

offiles

Fig. 7. File size distribution in enwiki dataset in CDF. An (x, y)point denotes that y fraction of files are sized larger than x bytes.Based on this distribution, we choose the block size of ODS-DBas 3KB because more than 50% of files are smaller than 3KB.

Network. To assume a general use case of a mobileclient and a cloud server, we use Wi-Fi as the commu-nication channel between the client and the server andthen mimic the bandwidth and latency of using Ama-zon EC2 from our lab. The average network latency andtransmission throughput are 18 ms and 150 Mbps, re-spectively.Configurations and Methodology. We comparePOSUP with the implementation of existing designs,namely ORAM-SE and EntireSGX. The following repre-sents the configuration of each implementation and howwe compare each with POSUP.• POSUP configuration We constructed ODS-IDX andODS-DB with ORAM tree structures with 24 and 23levels, respectively, to store the entire files (7,075,917≤ 223). Because more than 50% of files in our datasetare smaller than 3KB (shown in Figure 7), we selectedthe block size of ODS-DB to be 3KB to balance the ef-ficiency and storage overhead. Likewise, we selected theblock size of ODS-IDX to be 512B, because the major-ity of search keywords appears in less than 512 files (seeFigure 8c). We represent a file identifier with a 4-byteinteger. This results in ODS-IDX being obliviously ac-cessed up to four times for most search cases. We setthe stash size of both ORAM schemes as 80 to achievenegligible overflow probability [71, 76].• ORAM-ODS-SE - Direct ORAM-SE composition ina traditional client-server model (without secure hard-ware). In this setting, we used the same configurationas in POSUP, where we integrate ODS into the ORAM-SE composition for fair comparison with POSUP. Wealso set the size of ODS-IDX and ODS-DB to be iden-tical to POSUP. ORAM-ODS-SE differs from POSUPin terms of the ORAM communication channel (overnetwork vs. local bus) and the keyword position map

Table 1. Execution time of a single ODS on ODS-IDX andODS-DB, and recursive ORAM on file position map in POSUP.We ran each operation 500 times and took the average value.

Operation Execution Time (µs)Path-ORAM Circuit-ORAM

ODS access on ODS-IDXI/O Access 134 144Enclave Process 2,362 686Total 2,496 830

ODS access on ODS-DBI/O Access 156 285Enclave Process 3,909 746Total 4,065 1,031

Recursive ORAM on file position mapI/O Access 34 41Enclave Process 13,246 4,631Total 13,280 4,672

location (client vs. server). For the ORAM scheme,we employed Path-ORAM for ORAM-ODS-SE becauseit requires less access to ORAM, so it is more efficientthan Circuit-ORAM in the conventional client-server net-work setting. For the evaluation, we measured all delayswhen a client is accessing ODS and recursive ORAM onODS-IDX and ODS-DB stored on the Amazon EC2 withthe above network throughput and latency (18 ms and150 Mbps). Note that our analysis is conservative, be-cause we tend not to take into account the impact ofside factors (e.g., disk I/O).• EntireSGX - Processing the entire outsourced data inIntel SGX. We measured the search delay by decryptingthe entire EIDX and EDB inside the enclave. We used themaximum heap size (i.e., 95 MB) allowed to the enclaveto subsequently decrypt EIDX and EDB to maximize itsperformance. In other words, EIDX and EDB are loadedand processed (decrypt/encrypt) in 95 MB chunks se-quentially inside the enclave. For the update cost, wemeasured the delay of decryption and re-encryption ofthe entire EIDX and EDB inside the enclave. Noticethat in POSUP, we selected the size of ODS-IDX andODS-DB that have sufficient empty spaces for later ad-dition of the same amount of dataset size in the setupphase (i.e., 27GB file with 6.9GB index). Hence, wedouble the size of EIDX and EDB in EntireSGX to as-sume it can also support addition, similar to POSUP,for fair comparison between two techniques.


6.2 Experiment Results

6.2.1 Micro Benchmark

POSUP is efficient, where it takes less than 1 ms toaccess a 3KB block in Circuit-ORAM-sized 107 GB.

We first conducted a micro benchmark of POSUP toinvestigate the delay of performing a single recursiveORAM and ODS access. Three factors cause delay ineach operation: (i) the time to read/write ORAM datafrom the hard disk to the memory and vice versa (i.e.,I/O access); (ii) the time for an enclave to secure ORAMoperations, such as applying encryption and decryp-tion on the data (i.e., encryption overhead); (iii) theamount of data to be processed in each ODS operationon ODS-IDX and ODS-DB, expressed as:

DODS = H · |B| · Z · k, (1)

where H and |B| are the height and block size ofODS-IDX (or ODS-DB), respectively; and (Z, k) = (4, 2)are the bucket size and the number of read/write opera-tions in Path-ORAM, respectively. When Circuit-ORAMis used, (Z, k) = (2, 5). The amount of data (in bytes)to be processed for each recursive ORAM on the fileposition map posf is:

Dposf=

l∑i=1

(|B| · Z · k ·

(log2

(NRi

)+ 1)), (2)

where N is the total number of files, R = |B|/4 is thecompression ratio (assume that a path ID is representedby 4 bytes) and l = blogR Nc.

Table 1 presents the execution time of each ODSaccess on ODS-IDX and ODS-DB and recursive ORAMon posf in our current configuration. Note that the per-formance changes for the different parameter configura-tions (e.g., for a different H, |B|, Z, or k) according toEquation 1 and Equation 2.I/O Access. The I/O access in POSUP is efficient be-cause we implemented the caching technique proposedin [51], where we cache the first K levels of the ORAMtree structures on the RAM. In this experiment, we used4 GB of memory to cache 2/3 levels of both ODS-IDXand ODS-DB, which significantly reduced I/O delayfrom 520-767µs to ≤285µs. Compared to Path-ORAM,Circuit-ORAM incurs 1.25× more I/O access, and there-fore, its I/O latency is slightly higher than that ofPath-ORAM. Because the recursive ORAM structure ofthe file position map is small (i.e., ≈0.2 GB), we storethe entire map directly on the RAM. This results in itsI/O access delay being negligible (i.e., ≤41 µs).Enclave Process. Processing data in the enclavehas more effect on the access delay than I/O access

because it handles encryption and decryption whenreading data from ORAM. Another point that we ob-served from Table 1 is that the cost of executing thePath-ORAM controller in the enclave is much higherthan that of Circuit-ORAM because its read/eviction ismore aggressive. Specifically, when using Path-ORAMcontroller, the enclave must perform O(logN) · |S| num-ber of encryptions/decryptions, where |S| = 80 isthe stash size. In contrast, using the Circuit-ORAMcontroller requires O(logN) + |S| number of encryp-tions/decryptions. Therefore, our benchmarked resulthas shown that integrating Path-ORAM with securehardware is much less efficient than Circuit-ORAM dueto the multiplied factor |S|, which is 80. The processingdelay of recursive ORAM is high because this requiresthe enclave to perform additional ORAM encryptionsand decryptions on O(logN) recursion levels.

Table 1 also illustrates that it takes 830 µs toobliviously access a 512B block in ODS-IDX withCircuit-ORAM. That is, the latencies of performingsingle-keyword searches on ODS-IDX in many cases arelikely similar to each other, and they are mostly dom-inated by the number of files to be returned (see sub-subsection 6.2.2).

We now illustrate the formula for calculating thenumber of ODS and recursive ORAM accesses incurredin each search and update query. Given a search queryq with n keywords wi, let mi and m′ be the num-ber of files matching wi and the final q, respectively.The search q on POSUP incurs

∑ni=1 d

mi

|B|e accesses onODS-IDX plus m′ recursive ORAM accesses on posf andplus

∑m′

i=1 d|fi||B′|e accesses on ODS-DB, where B,B′ are

block sizes of ODS-IDX and ODS-DB, respectively, and|fi| is the size of file fi in m′ files. Given an updated filef with m updated keywords in it, the cost is m accesseson ODS-IDX plus one recursive ORAM access on posf

plus d |f ||B|e accesses on ODS-DB.Because the delay in I/O access and encryption in

an enclave is stable (i.e., does not change between ac-cesses), our measurement of the actual search and up-date delay in POSUP respected the above formulas andthe micro benchmark in Table 1. Moreover, as ex-plained in subsection 4.1, each search/update operationin POSUP additionally incurs one-time decryption andre-encryption of the entire keyword hash table (TW),which costs 210 ms for 188 MB-sized TW constructedfrom the enwiki dataset.

In the following, we present actual benchmarked de-lay for search and update operations to showcase the ef-ficiency of our system compared with other techniques.


20 22 24 26 28 210 212 214 216 218 220 222102

103

104

105

106

107

108

109

Number of files returned

Delay

(ms)

(log

)

POSUP (Circuit-ORAM)POSUP (Path-ORAM)EntireSGXORAM-ODS-SE

(a) End-to-end delay in POSUP and its counterparts regardinghow many files are returned in a single-keyword search.

20 22 24 26 28 210 212 214 216 218 220 222

0

10

102

103

104

105

106


Networkba

ndwidth

increase

(MB)(log

)

POSUP (Circuit-ORAM)POSUP (Path-ORAM)EntireSGXORAM-ODS-SE

(b) Network bandwidth increase of POSUP and its counterparts.Hardware-assisted techniques do not incur network overhead.

20 22 24 26 28 210 212 214 216 218 220 222

0.10.20.30.40.50.60.70.80.9

1

99.5%


Fraction

ofkeyw

ords

(CCDF)

(c) Keyword distribution in enwiki dataset. An (x, y) point de-notes that y fraction of keywords appear in less than x files.

20 22 24 26 28 210 212 214 216 218 220 222

010

102103104105106107


Amou

ntof

data

(MB)(log

) POSUP (Circuit-ORAM)POSUP (Path-ORAM)EntireSGXORAM-ODS-SE

(d) Amount of data being accessed and processed by SGX ofPOSUP and its counterparts.

Fig. 8. Detailed search delay of POSUP and its counterparts. In (a), the delay of POSUP and EntireSGX was included with the timeto transmit files to the client with 150 Mbps network throughput and 18 ms latency. POSUP is more efficient than both EntireSGXand ORAM-ODS-SE for 99.5% of keywords, as indicated by the red dashed lines.

6.2.2 Search Delay

POSUP consumes 100× less network bandwidth andrequires 1,000× fewer communication round-tripsthan ORAM-ODS-SE. POSUP incurs 4.5× - 245× lessprocessing time in the enclave than EntireSGX for re-turning < 212 files as the search result, which falls in> 99.5% fraction of keywords that can be searched inour dataset. This results in the search delay of POSUPbeing up-to 74× and 232× lower than ORAM-ODS-SEand EntireSGX, respectively.

Figure 8a presents the end-to-end delay of pro-cessing a keyword search query in POSUP, com-pared with ORAM-ODS-SE and EntireSGX techniques.POSUP (the blue line) is hundreds of times faster thanORAM-ODS-SE (the purple line) for any search querybeing performed. This is mainly because POSUP per-forms ORAM-controlling operations in an enclave, so itdoes not incur significant network communication over-

head like ORAM-ODS-SE, as shown in Figure 8b; in-stead, the enclave reads a large amount of data fromthe memory, which is faster and cheaper than accessingover the network. ORAM-ODS-SE incurs overhead notonly in bandwidth (i.e., 100× more than POSUP) butalso in generating a large number of network round-trips(i.e., 1000× more than POSUP) due to multiple roundsincurred in the recursive ORAM and ODS operations.This is the main bottleneck of ORAM-ODS-SE, giventhat the network latency is hard to improve in practice.

When compared with EntireSGX, POSUP is one totwo orders of magnitude faster than EntireSGX for morethan 99.5% of keywords that can be searched. In Fig-ure 8a, when searching keywords that returns ≤ 212

files, POSUP is more efficient than EntireSGX. Figure 8cpresents the (accumulative) keyword distribution onenwiki. The Zipf’s law distribution [56] shown in Fig-ure 8c indicates that the cases returning ≤ 212 files arethe majority (99.5%), and this indicates that POSUP is


more efficient than EntireSGX for a large fraction of key-words in practice. This is because the enclave in POSUPonly works with a small amount of data per ORAM ac-cess, while EntireSGX works with the entire index anddataset as its working set, as presented in Figure 8d. Fora small fraction of keywords (< 0.5%), the end-to-enddelay of POSUP is slower than that of EntireSGX.Thisis because a large number of ORAM and ODS accesseson ODS-IDX and ODS-DB require data processing in en-clave more than processing the entire dataset. The costof executing Path-ORAM and Circuit-ORAM in POSUPis C ·r ·8 log2(N) and C ·r ·10 log2 N , respectively, wherer is the number of file blocks matched with the searchquery, N = 223 is the total number of file blocks inODS-DB, and C is a constant factor. This formula im-plies that if r ≥ N

C·k·log2 N , where k ∈ {8, 10}, thenprocessing the entire database in the enclave is bet-ter than performing ORAM. Our benchmark result inFigure 8a respects this formula. Theoretically, POSUPshould incur more memory accesses than accessing theentire memory when it processes more than 215 files.The graph shows that overhead start to become signif-icant when 213 files are returned, we can assume theconstant C as 4, and then POSUP processes more than

N4·k·log2 N file blocks in the enclave.Padding overhead. Padding so that a search queryhas the same size as another query will result in a to-tal delay of two queries becoming similar. For example,padding on one-file-involved queries to make their sizethe same to four-file-involved queries incurs 46% extradelay (239ms) compared with the non-padding case.

6.2.3 Update Delay

The update delay of POSUP is 40× lower thanORAM-ODS-SE. This is because of the network band-width and round-trip overhead of ORAM-ODS-SE, asdiscussed in subsubsection 6.2.2.We selected the file with the largest size (i.e., 290KB)in enwiki and performed the update benchmark on thatfile for a different number of unique keywords that canbe updated (add/delete) in it. Figure 9 presents theend-to-end update delay of POSUP and its counter-parts. POSUP is one order of magnitude faster (40×)than ORAM-ODS-SE because it does not increase band-width and round-trip overhead, as analyzed in subsub-section 6.2.2. POSUP with Circuit-ORAM produces thehighest throughput so that it achieves the lowest updatedelay among its counterparts. POSUP is up to 3, 300×faster than EntireSGX due to the inevitable overhead inI/O writing required by the design of EntireSGX. An up-date in EntireSGX requires re-encrypting the entire dataand write them back to the disk. Therefore, the update

20 22 24 26 28 210 212 214102

103

104

105

106

107

Number of updated keywords

Delay

(ms)

(log

) POSUP (Circuit-ORAM)POSUP (Path-ORAM)EntireSGXORAM-ODS-SE

Fig. 9. End-to-end delay of updating a 290KB file with a differ-ent number of updated keywords involved.

delay of POSUP is three orders of magnitude faster thanEntireSGX.

6.2.4 Storage Overhead

The server storage overhead of EntireSGX is more effi-cient than that of POSUP and ORAM-ODS-SE. This isbecause, in POSUP and ORAM-ODS-SE, IDX and EDBare arranged as tree-ORAM structures, which incur aconstant (e.g., 1.5×-2×) size blowup. Specifically, thetotal server storage of POSUP is |TW| + |ODS-IDX| +|ODS-DB| + |posf | = 0.19 + 34 + 97 + 0.19 ≈ 131GBif POSUP uses Circuit-ORAM. The corresponding over-head is 0.19 + 68 + 194 + 0.38 ≈ 262GB if POSUP usesPath-ORAM. Note that some capacity of the ORAMstructure is reserved to enable oblivious update (e.g.,addition/deletion). Therefore, our server storage over-head presented above can allow the further addition of3× more IDX and DB presented in subsection 6.1.

7 Related WorkSearching on encrypted data. Searchable Encryp-tion (SE) [67] enables the client to conduct search op-erations on encrypted data. Curtmola et al. [19] pro-posed a secure Symmetric SE (SSE) scheme that sup-ports a single-keyword search, followed by refinementswith improved search functionalities (e.g., [12, 72, 75])and security (e.g., [16, 46]). Kamara et al. [44] pro-posed a Dynamic SSE (DSSE) scheme that supportsupdate functionality. Afterward, several DSSE schemesproposed offering different features in terms of secu-rity (e.g., [9]), efficiency (e.g., [14, 22, 45]), and queryfunctionalities (e.g., [15, 43, 74]). Another line of re-search focuses on developing encrypted query techniquesthat are compliant with legacy systems. For instance,


ShadowCrypt [33] and Mimesis Aegis [41, 47] proposeencrypted search/update operations as an intermedi-ate cryptographic service layer, which allows the clientto interact with online applications without modify-ing server infrastructure. CryptDB [59] and its variants(e.g., [1, 2, 4, 58, 60]) leverage property-preserving en-cryptions (e.g., [6, 8]) to perform encrypted structuredqueries (e.g., SQL) to legacy database management sys-tems (e.g., MongoDB).Security vulnerability of encrypted search so-lutions. All the aforementioned techniques leak ac-cess pattern, which results in various types of statisti-cal inference attacks. For instance, by exploiting accesspattern leakages in DSSE, it is possible to determinewhich keyword has been searched with high probability(e.g., [13, 40, 50, 82]). The legacy-compatible encryptedsearch techniques leak substantial additional informa-tion beyond the access pattern because of property-preserving encryption techniques [13, 31, 54, 61].Solutions to remedy security vulnerabilities.ORAM [29] can hide both read and write access pat-terns, and therefore, it has been considered to seal suchleakages in oblivious storage [7, 69, 70] and search-able encryption [26, 53]. Despite its merits, ORAMincurs a poly-logarithmic bandwidth blowup [71, 76],which has been shown to be costly for searchableencryption in the standard client-server network set-ting [7, 53, 68]. Although ORAMs with constant client-server bandwidth blowups have been proposed recently(e.g., [20, 34]), they either incur higher delay thanbandwidth-logarithmic ORAMs because of homomor-phic encryption (e.g., [27]), or require multiple comput-ing servers, which increases the deployment cost in prac-tice.

The ORAM communication lower bound has beenwell-established [29, 76]. Thus, recent studies start tolook for the support of secure hardware to make ORAMfor client-server applications more practical. The idea ofORAM and secure-hardware composition was first sug-gested by concurrent studies in [24, 51, 63]. With the ad-vent of widely available trusted execution environmentson commodity hardware (e.g., Intel SGX), the deploy-ment of hardware-supported cryptographic primitiveshas become more feasible. For instance, ZeroTrace [65]and Obliviate [3] leveraged Intel SGX with ORAM toenable oblivious memory primitives and file access op-erations, respectively. Intel SGX was also used to de-sign a functional encryption framework in [23]. Eskan-darian and Zaharia proposed ObliDB [21], which har-nesses Intel SGX and Path-ORAM to enable obliviousSQL queries on database systems. Concurrent with thiswork, Mishra et al. proposed Oblix [52], an oblivioussearch and update platform that harnesses Intel SGX,

Path-ORAM and oblivious data structures as similar toPOSUP.

8 ConclusionIn this paper, we developed a new SGX-supportedoblivious search and update platform called POSUP.We achieved this by realizing efficient SGX-assistedoblivious data structures that enable practical oblivi-ous search and update operations. We implemented anddeployed POSUP on commodity hardware and evalu-ated its performance on a very large dataset (full-sizeEnglish Wikipedia corpus). The experiments showedthat POSUP achieves two to three orders of magnitudeless bandwidth blowup and communication round-tripsthan the conventional client-server models for oblivioussearch and updates. Similarly, POSUP offers one order ofmagnitude less processing blowup over alternatives thatprocess the entire outsourced database inside SGX.

AcknowledgmentsWe would like to thank all the anonymous reviewers fortheir insightful comments and suggestions to improvethe quality of this paper. This work is partially sup-ported by the NSF CAREER Award CNS-1652389.

References[1] Always encrypted. https://docs.microsoft.com/en-us/sql/

relational-databases/security/encryption/always-encrypted-database-engine/.

[2] Google encrypted big query. https://github.com/google/encrypted-bigquery-client/.

[3] A. Ahmad, K. Kim, M. I. Sarfaraz, and B. Lee. Obliviate:A data oblivious file system for intel sgx. In Symposium onNetwork and Distributed System Security (NDSS), 2018.

[4] A. Arasu, S. Blanas, K. Eguro, R. Kaushik, D. Kossmann,R. Ramamurthy, and R. Venkatesan. Orthogonal securitywith cipherbase. In CIDR. Citeseer, 2013.

[5] attardi. WikiExtractor. https://github.com/attardi/wikiextractor.

[6] M. Bellare, A. Boldyreva, and A. O’Neill. Deterministic andefficiently searchable encryption. In Annual InternationalCryptology Conference, pages 535–552. Springer, 2007.

[7] V. Bindschaedler, M. Naveed, X. Pan, X. Wang, andY. Huang. Practicing oblivious access on cloud storage:the gap, the fallacy, and the new way forward. In Proceed-ings of the 22nd ACM SIGSAC Conference on Computerand Communications Security, pages 837–849. ACM, 2015.

[8] A. Boldyreva, N. Chenette, Y. Lee, and A. O’neill. Order-preserving symmetric encryption. In Annual InternationalConference on the Theory and Applications of Cryptographic

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-database-engine/



https://github.com/google/encrypted-bigquery-client/

https://github.com/google/encrypted-bigquery-client/

https://github.com/attardi/wikiextractor

https://github.com/attardi/wikiextractor


Techniques, pages 224–241. Springer, 2009.[9] R. Bost, B. Minaud, and O. Ohrimenko. Forward and back-

ward private searchable encryption from constrained crypto-graphic primitives. Technical report, IACR Cryptology ePrintArchive 2017, 2017.

[10] F. Brasser, U. Müller, A. Dmitrienko, K. Kostiainen, S. Cap-kun, and A. Sadeghi. Software Grand Exposure: SGX CacheAttacks Are Practical. In Proceedings of the 11th USENIXWorkshop on Offensive Technologies (WOOT), Vancouver,BC, Canada, Aug. 2017.

[11] J. V. Bulck, N. Weichbrodt, R. Kapitza, F. Piessens, andR. Strackx. Telling Your Secrets without Page Faults:Stealthy Page Table-Based Attacks on Enclaved Execution.In USENIX Security, 2017.

[12] N. Cao, C. Wang, M. Li, K. Ren, and W. Lou. Privacy-preserving multi-keyword ranked search over encrypted clouddata. IEEE Transactions on parallel and distributed systems,25(1):222–233, 2014.

[13] D. Cash, P. Grubbs, J. Perry, and T. Ristenpart. Leakage-abuse attacks against searchable encryption. In Proceedingsof the 22nd ACM CCS, pages 668–679. ACM, 2015.

[14] D. Cash, J. Jaeger, S. Jarecki, C. S. Jutla, H. Krawczyk, M.-C. Rosu, and M. Steiner. Dynamic searchable encryption invery-large databases: Data structures and implementation.IACR Cryptology ePrint Archive, 2014:853, 2014.

[15] D. Cash, S. Jarecki, C. Jutla, H. Krawczyk, M.-C. Roşu,and M. Steiner. Highly-scalable searchable symmetric en-cryption with support for boolean queries. In Advances inCryptology–CRYPTO 2013, pages 353–373. Springer, 2013.

[16] M. Chase and S. Kamara. Structured encryption and con-trolled disclosure. In Advances in Cryptology - ASIACRYPT2010, volume 6477 of Lecture Notes in Computer Science,pages 577–594, 2010.

[17] V. Costan and S. Devadas. Intel SGX explained. CryptologyePrint Archive, Report 2016/086, 2016. http://eprint.iacr.org/2016/086.pdf.

[18] V. Costan, I. Lebedev, S. Devadas, et al. Secure ProcessorsPart II: Intel SGX security analysis and MIT Sanctum Ar-chitecture. Foundations and Trends® in Electronic DesignAutomation, 11(3):249–361, 2017.

[19] R. Curtmola, J. Garay, S. Kamara, and R. Ostrovsky.Searchable symmetric encryption: improved definitions andefficient constructions. In Proceedings of the 13th ACMCCS, pages 79–88. ACM, 2006.

[20] S. Devadas, M. van Dijk, C. W. Fletcher, L. Ren, E. Shi,and D. Wichs. Onion oram: A constant bandwidth blowupoblivious ram. In Theory of Cryptography Conference, pages145–174. Springer, 2016.

[21] S. Eskandarian and M. Zaharia. An obliviousgeneral-purpose SQL database for the cloud. CoRR,abs/1710.00458, 2017.

[22] M. Etemad, A. Küpçü, C. Papamanthou, and D. Evans.Efficient dynamic searchable encryption with forward privacy.Proceedings on Privacy Enhancing Technologies, 2018(1):5–20, 2018.

[23] B. Fisch, D. Vinayagamurthy, D. Boneh, and S. Gorbunov.Iron: functional encryption using intel sgx. In Proceedingsof the 2017 ACM SIGSAC Conference on Computer andCommunications Security, pages 765–782. ACM, 2017.

[24] C. W. Fletcher, M. v. Dijk, and S. Devadas. A secure pro-cessor architecture for encrypted computation on untrustedprograms. In Proceedings of the seventh ACM workshop onScalable trusted computing, pages 3–8. ACM, 2012.

[25] B. Fuhry, R. Bahmani, F. Brasser, F. Hahn, F. Kerschbaum,and A.-R. Sadeghi. Hardidx: practical and secure index withsgx. In IFIP Annual Conference on Data and ApplicationsSecurity and Privacy, pages 386–408. Springer, 2017.

[26] S. Garg, P. Mohassel, and C. Papamanthou. Tworam:Round-optimal oblivious ram with applications to searchableencryption. IACR Cryptology ePrint Archive, 2015:1010,2015.

[27] C. Gentry. A fully homomorphic encryption scheme. PhDthesis, Stanford University, 2009.

[28] C. Gentry, K. A. Goldman, S. Halevi, C. Julta, M. Raykova,and D. Wichs. Optimizing oram and using it efficiently forsecure computation. In International Symposium on PrivacyEnhancing Technologies Symposium, pages 1–18. Springer,2013.

[29] O. Goldreich. Towards a theory of software protection andsimulation by oblivious rams. In Proceedings of the nine-teenth annual ACM symposium on Theory of computing,pages 182–194. ACM, 1987.

[30] J. Götzfried, M. Eckert, S. Schinzel, and T. Müller. CacheAttacks on Intel SGX. In Proceedings of the 10th EuropeanWorkshop on Systems Security (EuroSec), 2017.

[31] P. Grubbs, T. Ristenpart, and V. Shmatikov. Why yourencrypted database is not secure. In Proceedings of the16th Workshop on Hot Topics in Operating Systems, pages162–168. ACM, 2017.

[32] M. Hähnel, W. Cui, and M. Peinado. High-Resolution SideChannels for Untrusted Operating Systems. In Proceedingsof the 2017 USENIX Annual Technical Conference (ATC),Santa Clara, CA, July 2017.

[33] W. He, D. Akhawe, S. Jain, E. Shi, and D. Song. Shad-owcrypt: Encrypted web applications for everyone. In Pro-ceedings of the 2014 ACM SIGSAC Conference on Computerand Communications Security, pages 1028–1039. ACM,2014.

[34] T. Hoang, C. D. Ozkaptan, A. A. Yavuz, J. Guajardo, andT. Nguyen. S3oram: A computation-efficient and constantclient bandwidth blowup oram with shamir secret sharing.In Proceedings of the 2017 ACM SIGSAC Conference onComputer and Communications Security, pages 491–505.ACM, 2017.

[35] T. Hoang, A. Yavuz, and J. Guajardo. Practical and securedynamic searchable encryption via oblivious access on dis-tributed data structure. In Proceedings of the 32nd AnnualComputer Security Applications Conference (ACSAC). ACM,2016.

[36] T. Hunt, Z. Zhu, Y. Xu, S. Peter, and E. Witchel. Ryoan:A distributed sandbox for untrusted computation on secretdata. In Proceedings of the 12th USENIX Symposium onOperating Systems Design and Implementation (OSDI),Savannah, GA, Nov. 2016.

[37] Intel Corporation. Intel Software Guard Extensions Program-ming Reference (rev1), Sept. 2013. 329298-001US.

[38] Intel Corporation. Intel Software Guard Extensions Program-ming Reference (rev2), Oct. 2014. 329298-002US.

[39] Intel Corporation. Intel Software Guard ExtensionsSDK for Linux OS (Developer Reference), 2016. https://download.01.org/intel-sgx/linux-1.7/docs/Intel_SGX_SDK_Developer_Reference_Linux_1.7_Open_Source.pdf.

[40] M. S. Islam, M. Kuzu, and M. Kantarcioglu. Access patterndisclosure on searchable encryption: Ramification, attackand mitigation. In NDSS, volume 20, page 12, 2012.

http://eprint.iacr.org/2016/086.pdf

http://eprint.iacr.org/2016/086.pdf

https://download.01.org/intel-sgx/linux-1.7/docs/Intel_SGX_SDK_Developer_Reference_Linux_1.7_Open_Source.pdf




[41] Y. Jang. Building Trust in the User I/O in Computer Sys-tems. Georgia Institute of Technology, Aug. 2017.

[42] Y. Jang, J. Lee, S. Lee, and T. Kim. SGX-Bomb: LockingDown the Processor via Rowhammer Attack. In Proceed-ings of the 2nd Workshop on System Software for TrustedExecution (SysTEX), Shanghai, China, Oct. 2017.

[43] S. Kamara and T. Moataz. Boolean searchable symmetricencryption with worst-case sub-linear complexity. In AnnualInternational Conference on the Theory and Applications ofCryptographic Techniques, pages 94–124. Springer, 2017.

[44] S. Kamara, C. Papamanthou, and T. Roeder. Dynamicsearchable symmetric encryption. In Proceedings of the2012 ACM Conference on Computer and CommunicationsSecurity, pages 965–976. ACM, 2012.

[45] K. S. Kim, M. Kim, D. Lee, J. H. Park, and W.-H. Kim.Forward secure dynamic searchable symmetric encryptionwith efficient updates. In Proceedings of the 2017 ACMSIGSAC Conference on Computer and CommunicationsSecurity, pages 1449–1463. ACM, 2017.

[46] K. Kurosawa and Y. Ohtaki. UC-secure searchable symmet-ric encryption. In Financial Cryptography and Data Security(FC), volume 7397 of Lecture Notes in Computer Science,pages 285–298. Springer Berlin Heidelberg, 2012.

[47] B. Lau, S. P. Chung, C. Song, Y. Jang, W. Lee, andA. Boldyreva. Mimesis aegis: A mimicry privacy shield-a sys-tem’s approach to data privacy on public cloud. In USENIXSecurity Symposium, pages 33–48, 2014.

[48] J. Lee, J. Jang, Y. Jang, N. Kwak, Y. Choi, C. Choi,T. Kim, M. Peinado, and B. B. Kang. Hacking in dark-ness: Return-oriented programming against secure enclaves.In USENIX Security, pages 523–539, 2017.

[49] S. Lee, M.-W. Shih, P. Gera, T. Kim, H. Kim, andM. Peinado. Inferring Fine-grained Control Flow InsideSGX Enclaves with Branch Shadowing. In USENIX Security,2017.

[50] C. Liu, L. Zhu, M. Wang, and Y.-a. Tan. Search patternleakage in searchable encryption: Attacks and new construc-tion. Information Sciences, 265:176–188, 2014.

[51] M. Maas, E. Love, E. Stefanov, M. Tiwari, E. Shi,K. Asanovic, J. Kubiatowicz, and D. Song. Phantom: Prac-tical oblivious computation in a secure processor. In Pro-ceedings of the 2013 ACM SIGSAC conference on Computer& communications security, pages 311–324. ACM, 2013.

[52] P. Mishra, R. Poddar, J. Chen, A. Chiesa, and R. A. Popa.Oblix: An efficient oblivious search index. In Security andPrivacy (S&P), 2018 IEEE Symposium on. IEEE, 2018.

[53] M. Naveed. The fallacy of composition of oblivious ram andsearchable encryption. In Cryptology ePrint Archive, Report2015/668, 2015.

[54] M. Naveed, S. Kamara, and C. V. Wright. Inference attackson property-preserving encrypted databases. In Proceedingsof the 22nd ACM SIGSAC Conference on Computer andCommunications Security, pages 644–655. ACM, 2015.

[55] M. Naveed, M. Prabhakaran, and C. A. Gunter. Dynamicsearchable encryption via blind storage. In Security andPrivacy (S&P), 2014 IEEE Symposium on, pages 639–654.IEEE, 2014.

[56] M. E. Newman. Power laws, pareto distributions and zipf’slaw. Contemporary physics, 46(5):323–351, 2005.

[57] O. Ohrimenko, F. Schuster, C. Fournet, A. Mehta,S. Nowozin, K. Vaswani, and M. Costa. Oblivious multi-party machine learning on trusted processors. In USENIXSecurity Symposium, pages 619–636, 2016.

[58] A. Papadimitriou, R. Bhagwan, N. Chandran, R. Ramjee,A. Haeberlen, H. Singh, A. Modi, and S. Badrinarayanan.Big data analytics over encrypted datasets with seabed. InOSDI, pages 587–602, 2016.

[59] R. A. Popa, C. Redfield, N. Zeldovich, and H. Balakrish-nan. Cryptdb: protecting confidentiality with encryptedquery processing. In Proceedings of the Twenty-Third ACMSymposium on Operating Systems Principles, pages 85–100.ACM, 2011.

[60] R. A. Popa, E. Stark, J. Helfer, S. Valdez, N. Zeldovich,M. F. Kaashoek, and H. Balakrishnan. Building web applica-tions on top of encrypted data using mylar. In NSDI, pages157–172, 2014.

[61] D. Pouliot and C. V. Wright. The shadow nemesis: Infer-ence attacks on efficiently deployable, efficiently searchableencryption. In Proceedings of the 2016 ACM SIGSAC Con-ference on Computer and Communications Security, pages1341–1352. ACM, 2016.

[62] A. Rane, C. Lin, and M. Tiwari. Raccoon: Closing digitalside-channels through obfuscated execution. In USENIXSecurity Symposium, pages 431–446, 2015.

[63] L. Ren, X. Yu, C. W. Fletcher, M. Van Dijk, and S. De-vadas. Design space exploration and optimization of pathoblivious ram in secure processors. ACM SIGARCH Com-puter Architecture News, 41(3):571–582, 2013.

[64] A. W. Richa, M. Mitzenmacher, and R. Sitaraman. Thepower of two random choices: A survey of techniques andresults. Combinatorial Optimization, 9:255–304, 2001.

[65] S. Sasy, S. Gorbunov, and C. Fletcher. Zerotrace: Obliviousmemory primitives from intel sgx. In Symposium on Networkand Distributed System Security (NDSS), 2018.

[66] E. Shi, T.-H. H. Chan, E. Stefanov, and M. Li. Oblivi-ous ram with o ((logn) 3) worst-case cost. In Advances inCryptology–ASIACRYPT 2011, pages 197–214. Springer,2011.

[67] D. X. Song, D. Wagner, and A. Perrig. Practical techniquesfor searches on encrypted data. In Proceedings of the 2000IEEE Symposium on Security and Privacy, pages 44–55.IEEE Computer Society, 2000.

[68] E. Stefanov, C. Papamanthou, and E. Shi. Practical dy-namic searchable encryption with small leakage. In AnnualNetwork and Distributed System Security Symposium –NDSS, volume 14, pages 23–26, 2014.

[69] E. Stefanov and E. Shi. Multi-cloud oblivious storage. InProceedings of the 2013 ACM SIGSAC conference on Com-puter & communications security, pages 247–258. ACM,2013.

[70] E. Stefanov and E. Shi. Oblivistore: High performance obliv-ious cloud storage. In Security and Privacy (SP), 2013 IEEESymposium on, pages 253–267. IEEE, 2013.

[71] E. Stefanov, M. Van Dijk, E. Shi, C. Fletcher, L. Ren,X. Yu, and S. Devadas. Path oram: an extremely simpleoblivious ram protocol. In Proceedings of the 2013 ACMSIGSAC conference on Computer and Communications secu-rity, pages 299–310. ACM, 2013.

[72] W. Sun, B. Wang, N. Cao, M. Li, W. Lou, Y. T. Hou, andH. Li. Privacy-preserving multi-keyword text search in thecloud supporting similarity-based ranking. In ACM SIGSACAsiaCCS, pages 71–82. ACM, 2013.

[73] W. Sun, R. Zhang, W. Lou, and Y. T. Hou. Rearguard:Secure keyword search using trusted hardware. In IEEEINFOCOM, 2018.


[74] B. Wang, S. Yu, W. Lou, and Y. T. Hou. Privacy-preservingmulti-keyword fuzzy search over encrypted data in the cloud.In INFOCOM, 2014 Proceedings IEEE, pages 2112–2120.IEEE, 2014.

[75] C. Wang, N. Cao, J. Li, K. Ren, and W. Lou. Secure rankedkeyword search over encrypted cloud data. In IEEE 30thInternational Conference on Distributed Computing Systems,pages 253–262. IEEE, 2010.

[76] X. Wang, H. Chan, and E. Shi. Circuit oram: On tightnessof the goldreich-ostrovsky lower bound. In Proceedingsof the 22nd ACM SIGSAC Conference on Computer andCommunications Security, pages 850–861. ACM, 2015.

[77] X. S. Wang, Y. Huang, T. H. Chan, A. Shelat, and E. Shi.Scoram: oblivious ram for secure computation. In Proceed-ings of the 2014 ACM SIGSAC Conference on Computer andCommunications Security, pages 191–202. ACM, 2014.

[78] X. S. Wang, K. Nayak, C. Liu, T. Chan, E. Shi, E. Stefanov,and Y. Huang. Oblivious data structures. In Proceedingsof the 2014 ACM SIGSAC Conference on Computer andCommunications Security, pages 215–226. ACM, 2014.

[79] A. Waterman, Y. Lee, D. A. Patterson, and K. Asanovic.The RISC-V Instruction Set Manual, Volume I: Base User-level ISA. EECS Department, UC Berkeley, Tech. Rep.UCB/EECS-2011-62, 2011.

[80] N. Weichbrodt, A. Kurmus, P. Pietzuch, and R. Kapitza.AsyncShock: Exploiting synchronisation bugs in Intel SGXenclaves. In Proceedings of the 21th European Sympo-sium on Research in Computer Security (ESORICS), Crete,Greece, Sept. 2016.

[81] Y. Xu, W. Cui, and M. Peinado. Controlled-channel attacks:Deterministic side channels for untrusted operating systems.In Proceedings of the 36th IEEE Symposium on Securityand Privacy (Oakland), San Jose, CA, May 2015.

[82] Y. Zhang, J. Katz, and C. Papamanthou. All your queriesare belong to us: The power of file-injection attacks onsearchable encryption. In 25th USENIX Security Sympo-sium (USENIX Security 16), pages 707–720, 2016.

AppendixFigure 10 outlines the general access procedurethat tree-based ORAM schemes (e.g., Path-ORAM,Circuit-ORAM) follow. We present the detailed algo-rithms of Path-ORAM [71] in Figure 11. We give thedetailed algorithm of Circuit-ORAM [76] with the de-terministic eviction strategy [28] in Figure 12, whichexecute subroutines in Figure 13.

Tree-basedORAM.Access(op, bID, data∗):1: x← pos[bID]2: pos[bID] $←− [0...2L−1]3: S ← ReadPath(x)4: data← Read block with ID bID from S

5: if op = write then6: S ← (S − {(bID, data)}) ∪ {(bID, data∗)}7: Execute Evict procedure8: return data

Fig. 10. General access procedure in tree-based ORAM schemes.

PathORAM.ReadPath(x):1: for l = 1, . . . , L do2: S ← S ∪ ReadBucket(P (x, l))

PathORAM.Evict:1: Let x be the read path in PathORAM.ReadPath procedure2: for l = L, . . . , 1 do3: S′ ← {(bID, data′) ∈ S : P (x, l) = P (pos[bID], l)}4: S′ ← Select min(|S′|, Z) blocks from S′

5: S ← S − S′

6: WriteBucket(P (x, l), S′)

Fig. 11. Path-ORAM protocol. The ReadBucket(·) function takesas input a target bucket, reads all blocks in the bucket, and out-puts only real blocks.

CircuitORAM.ReadPath(x):1: for l = 0, . . . , L do2: if (bID, data)← ReadAndRm(P (x, l), bID) 6= ⊥ then3: S ← S ∪ (bID, data)

CircuitORAM.Evict:1: Let t be a global timestamp initialized with 02: x← order-reversal of base-2 digits of (t mod 2L)3: t← t + 14: Execute PrepareDeepest(x) and PrepareTarget(x) subrou-

tines to pre-process arrays deepest and target5: hold← ⊥; dest← ⊥6: for i = 0, . . . , L do7: towrite := ⊥8: if (hold 6= ⊥) and (i = dest) then9: towrite← hold10: hold← ⊥; dest← ⊥11: if target[i] 6= ⊥ then12: hold← read and remove deepest block in P (x, i)13: dest← target[i]14: Place towrite into bucket P (x, i) if towrite 6= ⊥15: Repeat steps 2-14

Fig. 12. Circuit-ORAM protocol with deterministic eviction. TheReadAndRm(·, ·) function takes a target bucket and the blockID bID to be accessed (determined in Access function) as input,reads all real blocks from the bucket input, removes the blockwith ID bID if it appears in the target bucket, and outputs bIDalong with its data data.


PrepareTarget(x):1: dest← ⊥; src← ⊥, target← (⊥, . . . ,⊥)2: for i = L, . . . , 0 do3: if i = src then4: target[i]← dest; dest← ⊥; src← ⊥5: if ((dest = ⊥ and P (x, i) has empty slot) or

(target[i] 6= ⊥)) and (deepest[i] 6= ⊥) then6: src← deepest[i]7: dest← i

PrepareDeepest(x):1: deepest← (⊥, . . . ,⊥) src← ⊥; goal← −12: if stash S is not empty then3: src← 04: goal ← Deepest level that a block in the stash S can

legally reside on path P (x)5: for i = 1, . . . , L do6: if goal ≥ i then deepest[i]← src7: ` ← Deepest level that a block in P (x, i) can legally

reside on path P (x)8: if ` > goal then9: goal← `

10: src← i

Fig. 13. Circuit-ORAM eviction subroutines.

thang hoang*, muslum ozgur ozmen, yeongjin jang, and ... · composed of two main encrypted data...

Documents