Epsolute: Efficiently Querying Databases While Providing Differential Privacy Dmytro Bogatov Georgios Kellaris George Kollios Boston University Canada Boston University Boston, MA, USA [email protected] Boston, MA, USA [email protected] [email protected] Kobbi Nissim Adam O’Neill Georgetown University University of Massachusetts, Amherst Washington, D.C., USA Amherst, MA, USA [email protected] [email protected] ABSTRACT KEYWORDS As organizations struggle with processing vast amounts of informa- Differential Privacy; ORAM; differential obliviousness; sanitizers; tion, outsourcing sensitive data to third parties becomes a necessity. ACM Reference Format: To protect the data, various cryptographic techniques are used in Dmytro Bogatov, Georgios Kellaris, George Kollios, Kobbi Nissim, and Adam outsourced database systems to ensure data privacy, while allowing O’Neill. 2021. Epsolute: Efficiently Querying Databases While Providing efficient querying. A rich collection of attacks on such systems Differential Privacy. In Proceedings of the 2021 ACM SIGSAC Conference on has emerged. Even with strong cryptography, just communication Computer and Communications Security (CCS ’21), November 15–19, 2021, volume or access pattern is enough for an adversary to succeed. Virtual Event, Republic of Korea. ACM, New York, NY, USA, 15 pages. https: In this work we present a model for differentially private out- //doi.org/10.1145/3460120.3484786 sourced database system and a concrete construction, Epsolute, that provably conceals the aforementioned leakages, while remaining 1 INTRODUCTION efficient and scalable. In our solution, differential privacy ispre- Secure outsourced database systems aim at helping organizations served at the record level even against an untrusted server that outsource their data to untrusted third parties, without compro- controls data and queries. Epsolute combines Oblivious RAM and mising data confidentiality or query efficiency. The main idea differentially private sanitizers to create a generic and efficient is to encrypt the data records before uploading them to an un- construction. trusted server along with an index data structure that governs We go further and present a set of improvements to bring the which encrypted records to retrieve for each query. While strong solution to efficiency and practicality necessary for real-world adop- cryptographic tools can be used for this task, existing implemen- tion. We describe the way to parallelize the operations, minimize the tations such as CryptDB [56], Cipherbase [2], StealthDB [70] and amount of noise, and reduce the number of network requests, while TrustedDB [3] try to optimize performance but do not provide preserving the privacy guarantees. We have run an extensive set of strong security guarantees when answering queries. Indeed, a se- experiments, dozens of servers processing up to 10 million records, ries of works [9, 17, 34, 37, 40, 41, 43, 45, 51] demonstrate that these and compiled a detailed result analysis proving the efficiency and systems are vulnerable to a variety of reconstruction attacks. That scalability of our solution. While providing strong security and is, an adversary can fully reconstruct the distribution of the records privacy guarantees we are less than an order of magnitude slower over the domain of the indexed attribute. This weakness is promi- than range query execution of a non-secure plain-text optimized nently due to the access pattern leakage: the adversary can tell if RDBMS like MySQL and PostgreSQL. the same encrypted record is returned on different queries. More recently, [33, 35, 43–45] showed that reconstruction attacks arXiv:1706.01552v3 [cs.CR] 27 Sep 2021 CCS CONCEPTS are possible even if the systems employ heavyweight cryptographic • Security and privacy → Database and storage security; Man- techniques that hide the access patterns, such as homomorphic en- agement and querying of encrypted data. cryption [30, 69] or Oblivious RAM (ORAM) [31, 32], because they leak the size of the result set of a query to the server (this is referred to as communication volume leakage). Thus, even some recent sys- tems that provide stronger security guarantees like ObliDB [28], Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed Opaque [75] and Oblix [50] are susceptible to these attacks. This for profit or commercial advantage and that copies bear this notice and the full citation also means that no outsourced database system can be both opti- on the first page. Copyrights for components of this work owned by others than the mally efficient and privacy-preserving: secure outsourced database author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission systems should not return the exact number of records required to and/or a fee. Request permissions from [email protected]. answer a query. CCS ’21, November 15–19, 2021, Virtual Event, Republic of Korea We take the next step towards designing secure outsourced data- © 2021 Copyright held by the owner/author(s). Publication rights licensed to ACM. ACM ISBN 978-1-4503-8454-4/21/11...$15.00 base systems by presenting novel constructions that strike a prov- https://doi.org/10.1145/3460120.3484786 able balance between efficiency and privacy. First, to combat the CCS ’21, November 15–19, 2021, Virtual Event, Republic of Korea Dmytro Bogatov, Georgios Kellaris, George Kollios, Kobbi Nissim, and Adam O’Neill access pattern leakage, we integrate a layer of ORAM storage in our among multiple ORAMs, but this requires tailoring the over- construction. Then, we bound the communication volume leakage head required for differential privacy proportionally to the by utilizing the notion of differential privacy (DP) [24]. Specifically, number of ORAMs, in order to ensure privacy. We present instead of returning the exact number of records per query, we practical improvements and optimization techniques that only reveal perturbed query answer sizes by adding random en- dramatically reduce the amount of fetched noise and the crypted records to the result so that the communication volume number of network roundtrips. leakage is bounded. Our construction guarantees privacy of any • Finally, we provide and open-source a high-quality C++ im- single record in the database which is necessary in datasets with plementation of our system. We have run an extensive set stringent privacy requirements. In a medical HIPAA-compliant set- of experiments on both synthetic and real datasets to em- ting, for example, disclosing that a patient exists in a database with pirically assess the efficiency of our construction and the a rare diagnosis correlating with age may be enough to reveal a impact of our improvements. We compare our solutions to particular individual. the naïve approach (linear scan downloading all data every The resulting mechanism achieves the required level of privacy, query), oblivious processing and maximal padding solution but implemented naïvely the construction is prohibitively slow. We (Shrinkwrap [5]), and to a non-secure regular RDBMS (Post- make the solution practical by limiting the amount of noise and greSQL and MySQL), and we show that our system is very the number of network roundtrips while preserving the privacy competitive. guarantees. We go further and present a way to parallelize the construction, which requires adapting noise-generation algorithms 1.1 Related Work to maintain differential privacy requirements. We group the related secure databases, engines, and indices into Using our system, we have run an extensive set of experiments three categories (i) systems that are oblivious or volume-hiding and over cloud machines, utilizing large datasets — that range up to do not require trusted execution environment (TEE), (ii) construc- 10 million records — and queries of different sizes, and we report tions that rely on TEE (usually, Intel SGX), (iii) solutions that use our experimental results on efficiency and scalability. We compare property-preserving or semantically secure encryption and target against best possible solutions in terms of efficiency (conventional primarily a snapshot adversary. We claim that Epsolute is the most non-secure outsourced database systems on unencrypted data) and secure and practical range- and point-query engine in the outsourced against an approach that provides optimal security (retrieves the database model, that protects both access pattern (AP) and communi- full table from the cloud or runs the entire query obliviously with cation volume (CV) using Differential Privacy, while not relying on maximal padding). We report that our solution is very competitive TEE, linear scan or padding result size to the maximum. against both baselines. Our performance is comparable to that of unsecured plain-text optimized database systems (like MySQL and Obliviousness and volume-hiding without enclave. This category PostgreSQL): while providing strong security and privacy guaran- is the most relevant to Epsolute, wherein the systems provide either tees, we are only 4 to 8 times slower in a typical setting. Compared or both AP and CV protection without relying on TEE. Crypt휖 [59] with the optimally secure solution, a linear scan (downloading all is a recent end-to-end system executing “DP programs”. Crypt휖 the records), we are 18 times faster in a typical setting and even has a different model than Epsolute in that it assumes two non- faster as database sizes scale up. colluding servers, an adversarial querying user (the analyst), and it uses DP to protect the privacy of an individual in the database, To summarize, our contributions in this work are as follows: which includes volume-hiding for aggregate queries. Crypt휖 also does not consider oblivious execution and attacks against the AP. • We present a new model for a differentially private out- Shrinkwrap [5] (and its predecessor SMCQL [4]) is an excellent sourced database system, CDP-ODB, its security definition, system designed for complex queries over federated and distributed query types, and efficiency measures. In our model, thead- data sources. In Shrinkwrap, AP protection is achieved by using versarial honest-but-curious server cannot see the record oblivious operators (linear scan and sort) and CV is concealed by values, access patterns, or exact communication volume. adding fake records to intermediate results with DP. Padding the • We describe a novel construction, Epsolute, that satisfies result to the maximum size first and doing a linear scan over it the proposed security definition, and provide detailed algo- afterwards to “shrink” it using DP, is much more expensive than in rithms for both range and point query types. In particular, Epsolute, however. In addition, in processing a query, the worker to conceal the access pattern and communication volume nodes are performing an 푂 (푛 log푛) cost oblivious sorting, where 푛 leakages, we provide a secure storage construction, utilizing is the maximum result size (whole table for range query), since they a combination of Oblivious RAM [31, 32] and differentially are designed to answer more general complex queries. SEAL [21] private sanitization [10]. Towards this, we maintain an index offers adjustable AP and CV leakages, up to specific bits of leakage. structure to know how many and which objects we need to SEAL builds on top of Logarithmic-SRC [22], splits storage into retrieve. This index can be stored locally for better efficiency multiple ORAMs to adjust AP, and pads results size to a power of 2 (in all our experiments this is the case), but crucially, it can to adjust CV. Epsolute, on the other hand, fully hides the AP and also be outsourced to the adversarial server and retrieved uses DP with its guarantees to pad the result size. PINED-RQ [60] on-the-fly for each query. samples Laplacian noise right in the B+ tree index tree, adding • We improve our generic construction to enable paralleliza- fake and removing real pointers according to the sample. Unlike tion within a query. The core idea is to split the storage Epsolute, PINED-RQ allows false negatives (i.e., result records not Epsolute: Efficiently Querying Databases While Providing Differential Privacy CCS ’21, November 15–19, 2021, Virtual Event, Republic ofKorea
ID ) ( ID )} included in the answer), and does not protect against AP leakage. On 푟1 , SK1 ,..., 푟푛, 푟푛 , SK푛 . We assume that all records have an the theoretical side, Chan et al.[18] (followed by Beimel et al.[8]) identical fixed bit-length, and that search keys are elements ofthe treat the AP itself as something to protect with DP. [18] introduces domain X = {1, . . . , 푁 } for some 푁 ∈ N. Outsourced database a notion of differential obliviousness that is admittedly weaker systems support search keys on multiple attributes, with a set of than the full obliviousness used in Epsolute. Most importantly, [18] search keys for each of the attributes of a record. For the ease of ensures differential privacy w.r.t. the ORAM only, while Epsolute presentation, we describe the model for a single indexed attribute ensures DP w.r.t. the entire view of the adversary. and then show how to extend it to support multiple attributes. A query is a predicate 푞 : X → {0, 1}. Evaluating a query 푞 Enclave-based solutions. Works in this category use trusted execu- on a database D results in 푞(D) = {푟푖 : 푞(SK푖 ) = 1}, all records tion environment (usually, SGX enclave). These works are primarily whose search keys satisfy 푞. concerned with the AP protection for both trusted and untrusted Let Q be a set of queries. An outsourced database system for E memory, unlike psolute which also protects CV. Cipherbase [1, 2] queries in Q consists of two protocols between two stateful parties: was a pioneer introducing the idea of using TEE (FPGA at that time) a user U and a server S (adapted from [43]): to assist with DBMS security. HardIDX [29] simply puts the B+ tree D {( in the enclave, while StealthDB [70] symmetrically encrypts all Setup protocol Πsetup: U receives as input a database = 푟1, ID ) ( ID )} records and brings them in the enclave one at a time for processing. 푟1 , SK1 ,..., 푟푛, 푟푛 , SK푛 ; S has no input. The output for EnclaveDB [57] assumes somewhat unrealistic 192 GB enclave and S is a data structure DS; U has no output besides its state. puts the entire database in it. ObliDB [28] and Opaque [75] assume Query protocol Πquery: U has a query 푞 ∈ Q produced in the fully oblivious enclave memory (not available as of today) and de- setup protocol as input; S has as input DS produced in the vise algorithms that use this fully trusted portion to obliviously setup protocol. U outputs 푞(D); S has no formal output. execute common DBMS operators, like filters and joins. Oblix [50] (Both parties may update their internal states.) provides a multimap that is oblivious both in and out of the enclave. D {( ID For correctness, we require that for any database = 푟1, 푟1 , HybrIDX claims protection against both AP and CV leakages, but ID SK1),..., (푟푛, 푟푛 , SK푛)} and query 푞 ∈ Q, it holds that running E E unlike psolute it only obfuscates them. psolute offers an indis- Πsetup and then Πquery on the corresponding inputs yields for U tinguishability guarantee for AP and a DP guarantee for CV, while the correct output {푟푖 : 푞(SK푖 ) = 1} with overwhelming probability HybrIDX hides the exact result size and only obfuscates the AP. over the coins of the above runs. We call the protocol 휂-wrong if Lastly, Hermetic [74] takes on the SGX side-channel attacks, in- this probability is at least 1 − 휂. cluding AP. It provides oblivious primitives, however, it only offers protection against software and not physical attacks (e.g., it trusts 2.2 Differential Privacy and Sanitization a hypervisor to disable interrupts). Differential privacy is a definition of privacy in analysis thatpro- Solutions against the snapshot adversary. Works in this category tects information that is specific to individual records. More for- 푛 푛 protect against the snapshot adversary, which takes a snapshot mally, we call databases D1 ∈ X and D2 ∈ X over domain X of the data at a fixed point in time (e.g., stolen hard drive). We neighboring (denoted D1 ∼ D2) if they differ in exactly one record. stress that Epsolute provides semantic security against the snap- ( ) shot adversary on top of AP and CV protection. CryptDB [56] is Definition 2.1 ([23, 24]). A randomized algorithm A is 휖, 훿 - D ∼ D ∈ X푛 O a seminal work in this direction offering computations over en- differentially private if for all 1 2 , and for all subsets crypted data. It has since been shown (e.g. [9, 41, 51]) that the of the output space of A, underlying property-preserving schemes allow for reconstruction Pr [A (D1) ∈ O] ≤ exp(휖)· Pr [A (D2) ∈ O] + 훿 . attacks. Arx [55] provides strictly stronger security guarantees by using only semantically secure primitives. Seabed [54] uses an addi- The probability is taken over the random coins of A. tively symmetric homomorphic encryption scheme for aggregates = and certain filter queries. Samanthula .[et al 62] offer a method When 훿 0 we omit it and say that A preserves pure differ- to verify and apply a predicate (a junction of conditions) using ential privacy, otherwise (when 훿 > 0) we say that A preserves garbled circuits or homomorphic encryption without revealing the approximate differential privacy. predicate itself. SisoSPIR [39] presents a mechanism to build an We will use mechanisms for answering count queries with dif- oblivious index tree such that neither party learns the pass taken. ferential privacy. Such mechanisms perturb their output to mask See [15] for a survey of range query protocols in this category. out the effect of any single record on their outcome. The simplest method for answering count queries with differential privacy is the 2 BACKGROUND Laplace Perturbation Algorithm (LPA) [24] where random noise drawn from a Laplace distribution is added to the count to be pub- In this section we describe an outsourced database system adapted lished. The noise is scaled so as to hide the effect any single record from [43], a base for our own model (Section3), and the construc- can have on the count. More generally, the LPA can be used to ap- tions we will use as building blocks in our solution. proximate any statistical result by scaling the noise to the sensitivity of the statistical analysis.1 2.1 Outsourced Database System
We abstract a database as a collection of 푛 records 푟, each with a 1The sensitivity of a query 푞 mapping databases into R푁 is defined to be Δ(푞) = ID D {( 푛 ∥ (D ) − (D ) ∥ unique identifier 푟 , associated with search keys SK: = 푟1, maxD1∼D2∈X 푞 1 푞 2 1. CCS ’21, November 15–19, 2021, Virtual Event, Republic of Korea Dmytro Bogatov, Georgios Kellaris, George Kollios, Kobbi Nissim, and Adam O’Neill
Theorem 2.2 (adapted Theorem 1 from [24]). Let 푞 : D → R푁 . 2.3 Oblivious RAM An algorithm A that adds independently generated noise from a zero- Informally, Oblivious RAM (ORAM) is a mechanism that lets a user mean Laplace distribution with scale 휆 = Δ(푞)/휖 to each of the 푁 hide their RAM access pattern to remote storage. An adversarial coordinates of 푞(D), satisfies 휖-differential privacy. server can monitor the actual accessed locations, but she cannot While Theorem 2.2 is an effective and simple way of answering tell a read from a write, the content of the block or even whether a single count query, we will need to answer a sequence of count the same logical location is being referenced. The notion was first queries, ideally, without imposing a bound on the length of this defined by Goldreich [31] and Goldreich and Ostrovsky [32]. sequence. We will hence make use of sanitization algorithms. More formally, a (휂1, 휂2)-ORAM protocol is a two-party protocol between a user U and a server S who stores a RAM array. In each Definition 2.3. Let Q be a collection of queries. An (휖, 훿, 훼, 훽)- round, the user U has input (표, 푎,푑), where 표 is a RAM operation (r differentially private sanitizer for Q is a pair of algorithms (A, B) or w), 푎 is a memory address and 푑 is a new data value, or ⊥ for read such that: operation. The input of S is the current array. Via the protocol, the • 퐴 is (휖, 훿)-differentially private, and server updates the memory or returns to U the data stored at the 푛 • on input a dataset D = 푑1, . . . ,푑푛 ∈ X , A outputs a data requested memory location, respectively. We speak of a sequence structure DS such that with probability 1 − 훽 for all 푞 ∈ Q, of such operations as a program y being executed under the ORAM. Í |B (DS, 푞) − 푖 푞(푑푖 )| ≤ 훼. An ORAM protocol must satisfy correctness and security. Cor- U Remark 2.4. Given an (휖, 훿, 훼, 훽)-differentially private sanitizer as rectness requires that obtains the correct output of the computa- in Definition 2.3 one can replace the answer B (DS, 푞) with B′(DS, tion except with at most probability 휂1. For security, we require that U 푞) = B (DS, 푞) + 훼. Hence, with probability 1 − 훽, for all 푞 ∈ Q, for every user there exists a simulator SimORAM which provides ′ Í a simulation of the server’s view in the above experiment given 0 ≤ B (DS, 푞) − 푖 푞(푑푖 ) ≤ 2훼. We will hence assume from now on that sanitizers have this latter guarantee on their error. only the number of operations. That is, the output distribution of SimORAM (푐) is indistinguishable from ViewS with probability at The main idea of sanitization (a.k.a. private data release) is to most 휂2 after 푐 protocol rounds. release specific noisy statistics on a private dataset once, which can ORAM protocols are generally stateful, after each execution the then be combined in order to answer an arbitrary number of queries client and server states are updated. For brevity, throughout the without violating privacy. Depending on the query type and the paper we will assume the ORAM state updates are implicit, including notion of differential privacy (i.e., pure or approximate), different up- the encryption key 퐾 generated and maintained by the client. per bounds on the error have been proven. Omitting the dependency Some existing efficient ORAM protocols are Square Root ORAM on 휖, 훿, in case of point queries over domain size 푁 , pure differential [31], Hierarchical ORAM [32], Binary-Tree ORAM [63], Interleave privacy results in 훼 = Θ(log 푁 ) [6], while for approximate differ- Buffer Shuffle Square Root73 ORAM[ ], TP-ORAM [64], Path-ORAM ential privacy 훼 = O(1) [7]. For range queries over domain size 푁 , [65] and TaORAM [61]. For detailed descriptions of each protocol, these bounds are 훼 = Θ(log 푁 ) for pure differential privacy [10, 25], we recommend the work of Chang et al.[19]. The latter three ∗ 1.5 and 훼 = O (log 푁 ) for approximate differential privacy (with ORAMs achieve the lowest communication and storage overheads, ∗ an almost matching lower bound of 훼 = Ω(log 푁 ))[7, 16, 42]. O(log푛) and O(푛), respectively. More generally, Blum et al.[10] showed that any finite query set Q can be sanitized, albeit non-efficiently. 3 DIFFERENTIALLY PRIVATE OUTSOURCED Answering point and range queries with differential privacy. Utilizing DATABASE SYSTEMS the LPA for answering point queries results in error 훼 = O(log 푁 ). In this section we present our model, differentially private outsourced A practical solution for answering range queries with error bounds database system, CDP-ODB, its security definition, query types and very close to the optimal ones is the hierarchical method [25, 36, 72]. efficiency measures. It is an extension of the ODB model inSection2. The main idea is to build an aggregate tree on the domain, and add noise to each node proportional to the tree height (i.e., noise scale 3.1 Adversarial model logarithmic in the domain size 푁 ). Then, every range query is We consider an honest-but-curious polynomial time adversary that answered using the minimum number of tree nodes. Qardaji et al. attempts to breach differential privacy with respect to the input [58] showed that the hierarchical algorithm of Hay et al.[36], when database D. We observe later in Section 3.1.1 that it is impossible combined with their proposed optimizations, offers the lowest error. to completely hide the number of records returned on each query Composition. Finally, we include a composition theorem (adapted without essentially returning all the database records on each query. from [47]) based on [23, 24]. It concerns executions of multiple dif- This, in turn, means that different query sequences may be distin- ferentially private mechanisms on non-disjoint and disjoint inputs. guished, and, furthermore, that differential privacy may not be preserved if the query sequence depends on the content of the data- Theorem 2.5. Let A ,..., A be mechanisms, such that each A 1 푟 푖 base records. We hence, only require the protection of differential provides 휖 -differential privacy. Let D ,..., D be pairwise non- 푖 1 푟 privacy with respect to every fixed query sequence. Furthermore, disjoint (resp., disjoint) datasets. Let A be another mechanism that we relax to computational differential privacy (following [49]). executes A (D ),..., A (D ) using independent randomness for 1 1 푟 푟 In the following definition, the notation View (D, 푞 , . . . , 푞 ) each A , and returns their outputs. Then, mechanism A is Í푟 휖 - Π 1 푚 푖 푖=1 푖 denotes the view of the server S in the execution of protocol Π in 푟 differentially private (resp., max푖=1 휖푖 -differentially private). answering queries 푞1, . . . , 푞푚 with the underlying database D. Epsolute: Efficiently Querying Databases While Providing Differential Privacy CCS ’21, November 15–19, 2021, Virtual Event, Republic ofKorea
Definition 3.1. We say that an outsourced database system Π is Point queries Here X is arbitrary and a query predicate 푞푎 is (휖, 훿)-computationally differentially private (a.k.a. CDP-ODB) if for associated with an element 푎 ∈ X such that 푞푎 (푏) = 1 iff 푎 = 푏. every polynomial time distinguishing adversary A, for every neigh- In an ordered domain, point queries are degenerate range queries. ′ boring databases D ∼ D , and for every query sequence 푞1, . . . , 푞푚 ∈ The equivalent SQL query is: 푚 Q where 푚 = poly(휆), SELECT * FROM table WHERE attribute = a;
h 휆 i 3.3 Measuring Efficiency Pr A 1 , ViewΠ (D, 푞1, . . . , 푞푚) = 1 ≤ We define two basic efficiency measures for a CDP-ODB. h 휆 ′ i exp 휖 · Pr A 1 , ViewΠ D , 푞1, . . . , 푞푚 = 1 + 훿 + negl(휆) , Storage efficiency is defined as the sum of the bit-lengths ofthe where the probability is over the randomness of the distinguishing records in a database relative to the bit-length of a corresponding adversary A and the protocol Π. encrypted database. Specifically, we say that an outsourced database system has storage efficiency of (푎1, 푎2) if the following holds. Fix Remark 3.2 (Informal). We note that security and differential D {( ID ) ( ID )} Í푛 | | any = 푟1, 푟1 , SK1 ,..., 푟푛, 푟푛 , SK푛 and let 푛1 = 푖=1 푟푖 . privacy in this model imply protection against communication volume Let Sstate be an output of S on a run of Πsetup where U has input and access pattern leakages and thus prevent a range of attacks, such D, and let 푛2 = |Sstate|. Then 푛2 ≤ 푎1푛1 + 푎2. as [17, 43, 51]. Communication efficiency is defined as the sum of the lengths 3.1.1 On impossibility of adaptive queries. Non-adaptivity in our of the records in bits whose search keys satisfy the query relative CDP-ODB definition does not reflect a deficiency of our specific to the actual number of bits sent back as the result of a query. protocol but rather an inherent source of leakage when the queries Specifically, we say that an outsourced database system has com- may depend on the decrypted data. Consider an adaptive CDP- munication efficiency of (푎1, 푎2) if the following holds. Fix any 푞 and DS output by Π , let U and S execute Π where U has ODB definition that does not fix the query sequence 푞1, . . . , 푞푚 in setup query advance but instead an arbitrary (efficient) user U chooses them inputs 푞 , and output 푅, and S has input DS. Let 푚1 be the amount during the protocol execution with S. As before, we ask that the S’s of data in bits transferred between U and S during the execution of view is DP on neighboring databases for every such U. We observe Πquery, and let 푚2 = |푅|. Then 푚2 ≤ 푎1푚1 + 푎2. that this definition cannot possibly be satisfied by any outsourced Note that 푎1 ≥ 1 and 푎2 ≥ 0 for both measures. We say that database system without unacceptable efficiency overhead. Note an outsourced database system is optimally storage efficient (resp., that non-adaptivity here does not imply that the client knows all optimally communication efficient) if it has storage (resp., commu- the queries in advance, but rather can choose them at any time nication) efficiency of (1, 0). (e.g., depending on external circumstances) as long as they do not depend on true answers to prior queries. 4 EPSOLUTE ′ To see this, consider two neighboring databases D, D . Database In this section we present a construction, Epsolute, that satisfies ′ D has 1 record with key = 0 and D has none. Furthermore, both the security definition in Section3, detailing algorithms for both have 50 records with key = 50 and 100 records with key = 100. range and point query types. We also provide efficiency guarantees User U queries first for the records with key = 0, and then if there for approximate and pure DP versions of Epsolute. is a record with key = 0 it queries for the records with key = 50, otherwise for the records with key = 100. Clearly, an efficient out- 4.1 General construction sourced database system cannot return nearly as many records Let Q be a collection of queries. We are interested in building when key = 50 versus key = 100 here. Hence, this allows distin- a differentially private outsourced database system for Q, called guishing D, D′ with probability almost 1. Epsolute. Our solution will use these building blocks. To give a concrete scenario, suppose neighboring medical data- bases differ in one record with a rare diagnosis “Alzheimer’s disease”. • A (휂1, 휂2)-ORAM protocol ORAM(·). A medical professional queries the database for that diagnosis first • An (휖, 훿, 훼, 훽)-differentially private sanitizer (A, B) for Q and (point query), and if there is a record, she queries the senior patients negligible 훽, which satisfies the non-negative noise guaran- next (range query, age ≥ 65), otherwise she queries the general tee from Remark 2.4. population (resulting in more records). We leave it open to mean- • A pair of algorithms CreateIndex and Lookup. CreateIn- ingfully strengthen our definition while avoiding such impossibility dex consumes D and produces an index data structure I ID results, and we defer the formal proof to future work. that maps a search key SK to a list of record IDs 푟 corre- sponding to the given search key. Lookup consumes I and = ID ID 3.2 Query types 푞 and returns a list 푇 푟1 , . . . , 푟 |푇 | of record IDs matching In this work we are concerned with the following query types: the supplied query. Range queries Here we assume a total ordering on X. A query Our protocol Π = (Πsetup, Πquery) of Epsolute works as shown 푞 [푎,푏] is associated with an interval [푎,푏] for 1 ≤ 푎 ≤ 푏 ≤ 푁 such in Algorithm1. Hereafter, we reference lines in Algorithm1. See that 푞 [푎,푏] (푐) = 1 iff 푐 ∈ [푎,푏] for all 푐 ∈ X. The equivalent SQL Fig.1 for a schematic description of the protocol. query is: Setup protocol Πsetup. Let U’s input be a database D = {(푟1, SELECT * FROM table WHERE attribute BETWEEN a AND b; ID ) ( ID )} I 푟1 , SK1 ,..., 푟푛, 푟푛 , SK푛 (line2). U creates an index mapping CCS ’21, November 15–19, 2021, Virtual Event, Republic of Korea Dmytro Bogatov, Georgios Kellaris, George Kollios, Kobbi Nissim, and Adam O’Neill
Algorithm 1 Epsolute protocol. ORAM (·) denotes an execution of ORAM protocol (Section 2.3), where U plays the role of the client. ORAM protocol client and server states are implicit. 푆 \ 푇 represents a set of valid record IDs 푆 that are not in the true result set 푇 .
Πsetup Πquery 1 : User U Server S 1 : User U Server S 2 : Input: D Input: ∅ 2 : Input: 푞, I Input: DS 3 : I ← CreateIndex (D) ← (I ) 푞 ← (DS ) 푛 3 : 푇 Lookup , 푞 푐 B , 푞 = ( ID ) 4 : y w, 푟푖 , 푟푖 푖=1 ID 푐 ORAM (y) 4 : y = (r, 푟 , ⊥) 5 : true 푖 푖∈푇 = ( \ ⊥) |푐−|푇 | DS 5 : ynoise r, 푆 푇, 1 6 : DS ← A (SK1,..., SK푁 ) ORAM (y ∥y ) 6 : 푅 true noise 7 : Output: I Output: DS 7 : Output: 푅 Output: ∅ search keys to record IDs corresponding to these keys (line3). U 4.2 Security sends over the records to S by executing the ORAM protocol on Theorem 4.1. Epsolute is (훽 · 푚)-wrong and (휖, 훿)-CDP-ODB the specified sequence (lines4 to5). U generates a DP structure where the negligible term is negl(휆) = 2 · 휂2. DS over the search keys using sanitizer A, and sends DS over to S (line6). The output of U is I and of S is DS; final ORAM states Proof. We consider a sequence of views of S and U are implicit, including encryption key 퐾 (line7). View1 → View2 → View3 → View4 .
Query protocol Πquery. U starts with a query 푞 and index I, View1 is ViewΠ (D, 푞1, . . . , 푞푚). View2 is produced only from S starts with a DP structure DS. One can think of these inputs DS ← A (SK1,..., SK푁 ). Namely, compute 푐푖 ← A (DS, 푞푖 ) for Í as outputs of Πsetup (line2). U immediately sends the query to S, all 푖 and run ORAM simulator on 푖 푐푖 . By ORAM security, which uses the sanitizer B to compute the total number of requests Pr [A(View )] − Pr [A(View )] ≤ 휂 . 푐, while U uses index I to derive the true indices of the records 1 2 2 the query 푞 targets (line3). U receives 푐 from S and prepares two DS ← ′ ′ View3 is produced similarly but A SK1,..., SK푁 instead. ORAM sequences: ytrue for real records retrieval, and ynoise to pad Note that the 푐푖 are simply post-processing on DS via B so the number of requests to 푐 to perturb the communication volume. [A( )] = ( )· [A( )] + ynoise includes valid non-repeating record IDs that are not part of Pr View2 exp 휖 Pr View3 훿 . U ′ the true result set 푇 (lines4 to5). fetches the records, both real View4 = ViewΠ (D , 푞1, . . . , 푞푚). It follows by ORAM security and fake, from S using the ORAM protocol (line6). The output of U [A( )] − [A( )] ≤ is the filtered set of records requested by the query 푞; final ORAM Pr View3 Pr View4 휂2 . states of S and U are implicit (line7). Putting this all together completes the proof. □ The protocols for point and range queries only differ in sanitizer implementations, see Sections 4.5 and 4.6. Note above that in any 4.3 Efficiency execution of Π we have 푐 ≥ 푞(D) with overwhelming proba- query For an ORAM with communication efficiency (푎1, 푎2) and an (훼, 훽)- bility 1 − 훽 (by using sanitizers satisfying Remark 2.4), and thus the differentially private sanitizer, the Epsolute communication effi- protocol is well-defined and its accuracy is 1 − 훽. Also note that the ciency is (푎1, 푎2 · 훼). The efficiency metrics demonstrate how the DP parameter 훿 is lower-bounded by 훽 because sampling negative total storage or communication volume (the number of stored or noise, however improbable, violates privacy, and therefore the final transferred bits) changes additively and multiplicatively as the func- construction is (휖, 훽)-DP. tions of data size 푛 and domain 푁 . We therefore have the following corollaries for the efficiency of the system in the cases of approxi-
Server mate and pure differential privacy. User Searchkey RecordID noise Salary$40K IDs 56,46,89 E Salary$50K IDs 85,38,63 Corollary 4.2. psolute is an outsourced database system with (O( ) ) DPtree(rangequeries) ...... storage efficiency 1 , 0 . Depending on the query type, assume it ORAM read requests Recordindex offers the following communication efficiency. Query: log∗ 푁 “Salaries $40K–$50K" Range queries O(log푛), O 2 log푛
Client ORAM DPhisotgram noise Point queries (O(log푛), O(log푛)) ServerStorage (point queries) User Then, there is a negligible 훿 such that Epsolute satisfies (휖, 훿)-differ- 2 Figure 1: Epsolute construction ential privacy for some 휖. 2Note that the existence of 휖 in this setting implies that the probability of an adversary breaking the DP guarantees is bounded by it. Epsolute: Efficiently Querying Databases While Providing Differential Privacy CCS ’21, November 15–19, 2021, Virtual Event, Republic ofKorea
Proof. By using ORAM, we store only the original data once which is equivalent to and hence, we get optimal storage efficiency. 푁√︁ The communication efficiency depends on the upper bound of ln 2 − 2 1 − 훽 = − the error for each sanitizer when 훿 > 0, as described in Section 2.2 훼푝 휖 and Remark 2.4. The most efficient ORAM protocol to date has O(log푛) communication overhead (see Section 2.3). □ 4.6 Epsolute for range queries Corollary 4.3. Epsolute is an outsourced database system with storage efficiency (O(1), 0). Depending on the query type, assume it For range queries, we implement the aggregate tree method as the offers the following communication efficiency. sanitizer. Specifically, we build a complete 푘-ary tree on the domain, Range queries (O(log푛), O(log 푁 log푛)) for a given 푘. A leaf node holds the number of records falling into Point queries (O(log푛), O(log 푁 log푛)) each bin plus some noise. A parent node holds sum of the leaf values in the range covered by this node, plus noise. Every time a query E 휖 휖 Then, psolute satisfies -differential privacy for some . is issued, we find the minimum number of nodes that cover the Proof. Similarly, we derive the proof by considering the use of range, and determine the required number of returned records by ORAM and the upper bound of the error for each sanitizer when summing these node values. Then, we ask the server to retrieve 훿 = 0 in Section 2.2. □ the records in the range, plus to retrieve multiple random records so that the total number of retrieved records matches the required 4.4 Extending to multiple attributes number of returned records. We will now describe how Epsolute supports multiple indexed The noise per node is drawn from the Laplace distribution with log푘 푁 attributes and what the privacy and performance implications are. mean 훼ℎ and scale 휆 = 휖 . Consistent with Remark 2.4, we The naïve way is to simply duplicate the entire stack of states of determine the mean value 훼ℎ in order to avoid drawing negative U and S, and during the query use the states whose attribute the values with high probability. We have to set 훼ℎ such that if values E log푘 푁 query targets. However, psolute design allows to keep the most are drawn from Laplace 훼ℎ, 휖 at least as many times as expensive part of the state — the ORAM state — shared for all the number of nodes in the tree, they are all positive with high attributes and both types of queries. Specifically, the index I and probability 1 − 훽, for negligible 훽. DP structure DS are generated per attribute and query type, while Again, we can compute the exact minimum required value of 훼ℎ U and S ORAM states are generated once. This design is practical in order to ensure drawing positive values with high probability by since DS is tiny and index I is relatively small compared to ORAM using the CDF of the Laplace distribution. Specifically, 훼ℎ should be states, see Section6. equal to the minimum value that satisfies the following inequality. We note that in case the indices grow large in number, it is 훼 ·휖 nodes practical to outsource them to the adversarial server using ORAM 1 − ℎ 1 − 푒 log푘 푁 ≤ 1 − 훽 and download only the ones needed for each query. In terms of 2 privacy, the solution is equivalent to operating different Epsolute which is equivalent to instances because ORAM hides the values of records and access & ' ln (2 − 2 nodes√︁1 − 훽)· log 푁 patterns entirely. Due to Theorem 2.5 for non-disjoint datasets, the 훼 = − 푘 (1) total privacy budget of the multi-attribute system will be the sum ℎ 휖 of individual budgets for each attribute / index. ⌈log (푘−1)+log 푁 −1⌉ = 푘 푘 푘 −1 + Next, we choose two DP sanitizers for our system, for point and where nodes 푘−1 푁 is the total number of tree for range queries, and calculate the 훼 values to make them output nodes. positive values with high probability, consistent with Remark 2.4. 5 AN EFFICIENT PARALLEL EPSOLUTE 4.5 Epsolute for point queries While the previously described scheme is a secure and correct For point queries, we use the LPA method as the sanitizer to ensure CDP-ODB, a single-threaded implementation may be prohibitively pure differential privacy. Specifically, for every histogram bin, we slow in practice. To bring the performance closer to real-world draw noise from the Laplace distribution with mean 훼푝 and scale requirements, we need to be able to scale the algorithm horizontally. 휆 = 1/휖. To satisfy Remark 2.4, we have to set 훼푝 such that if values In this section, we describe an upgrade of Epsolute — a scalable are drawn from Laplace 훼푝, 1/휖 at least as many times as the parallel solution. number of bins 푁 , they are all positive with high probability 1 − 훽, We suggest two variants of parallel Epsolute protocol. Both of for negligible 훽. them work by operating 푚 ORAMs and randomly assigning to each We can compute the exact minimum required value of 훼푝 in of them 푛/푚 database records. For each query, we utilize the index order to ensure drawing positive values with high probability by I to find the required records from the corresponding ORAMs. For using the CDF of the Laplace distribution. Specifically, 훼푝 should be each ORAM, we execute a separate thread to retrieve the records. equal to the minimum value that satisfies the following inequality. The threads work in parallel and there is no need for locking, since each ORAM works independently from the rest. We present two 1 푁 methods that differ in the way they build and store DP structure 1 − 푒−훼푝 ·휖 ≤ 1 − 훽 2 DS, and hence the number of ORAM requests they make. CCS ’21, November 15–19, 2021, Virtual Event, Republic of Korea Dmytro Bogatov, Georgios Kellaris, George Kollios, Kobbi Nissim, and Adam O’Neill
∗ Algorithm 2 Parallel Epsolute for Π훾 , extends Algorithm1. 푚 is the number of parallel ORAMs. H is a random hash function H : {0, 1} → {1, . . . ,푚}. 훾 and 푘˜0 are computed as in Section 5.2. U and S maintain 푚 ORAM states implicitly.
Πsetup of Π훾 Πquery of Π훾 1 : User U Server S 1 : User U Server S 2 : Input: D Input: ∅ 2 : Input: 푞, I Input: DS 3 : I ← CreateIndex (D,푚) 푞 3 : 푇1, . . . ,푇푚 ← Lookup (퐼, 푞) 푘 ← B ( DS, 푞) ...... for 푗 ∈ {1, . . . ,푚} do (in parallel) ...... D E ˜ ID ID 푐 푘0 4 : 푟, 푟 s.t. H 푟 = 푗 4 : 푐 ← (1 + 훾) 푚 D E 5 : y = (w, 푟 ID, 푟) ...... for 푗 ∈ {1, . . . ,푚} do (in parallel) ...... ID ORAM (y) 5 : ytrue = (r, 푟 , ⊥) 6 : 푗 푖 푖∈푇푗 푐−|푇푗 | 6 : y = (r, 푆 \ 푇 , ⊥) ...... endfor ...... noise 푗 1 DS ORAM푗 (ytrue ∥ynoise) 7 : DS ← A (SK1,..., SK푁 ) 7 : 푅푗
8 : Output: I Output: DS ...... endfor ...... 푚 ∅ 8 : Output: 푅푗 푗=1 Output:
훾 √︃ − 푚 훽 푁 5.1 No- -method: DP structure per ORAM Point queries O 1 + 3 log log 푛 , O log 푚 log푛 푘0 푚 휖 In Πno−훾 , for each ORAM / subset of the dataset, we build a DP index the same way as described in Section4. We note that Theorem 2.5 Then, Πno−훾 satisfies 휖-differential privacy for some 휖. for disjoint datasets applies to this construction: the privacy budget In our experiments, we set 푚 as a constant depending on the 휖 for the construction is the largest (least private) among the 휖’s of infrastructure. However, if푚 is set as O(log푛), the total communica- the DP indices for each ORAM / subset of the dataset. tion overhead of the construction will still exceed the lower-bound The communication efficiency changes because (i) we essentially presented in [46]. add 푚 record subsets in order to answer a query, each having at most 훼 extra random records, and (ii) each ORAM holds fewer 5.2 훾-method: shared DP structure records than before, resulting in a tree of height log 푛 . 푚 DS However, we cannot expect that the records required for each In Π훾 , we maintain a single shared DP structure . When a query query are equally distributed among the different ORAMs in order is issued, we must ensure that the number of records retrieved from log푛 every ORAM is the same. As such, depending on the required to reduce the multiplicative communication cost from log푛 to . ˜ 푚 ˜ 푘0 Instead, we need to bound the worst case scenario which is repre- noisy number of records 푘0, we need to retrieve at most (1 + 훾) 푚 √︂ sented by the maximum number of records from any ORAM that is = −3푚 log 훽 records from each ORAM, see Eq. (2), for 훾 ˜ . Setting required to answer a query. This can be computed as follows. 푘0 1.5 Let 푋푗 be 1 if a record for answering query 푞 is in a specific ˜ log 푁 ˜ log 푁 푘0 = 푘0 + 휖 for range queries and 푘0 = 푘0 + 휖 for point ORAM푗 , and 0 otherwise. Due to the random assignment of records queries, the communication efficiency is as follows. to ORAMs, Pr 푋푗 = 1 = 1/푚. Assume that we need 푘0 records in order to answer query 푞 . The maximum number of records from Corollary 5.2. Let Π훾 be an outsourced database system with (O( ) ) ORAM푗 in order to answer 푞 is bounded as follows. storage efficiency 1 , 0 . Depending on the query type, Π훾 offers the following communication efficiency. 푘 ! ! ! ∑︁0 푘 푘 훾2 √︂ 1.5 ( + ) 0 ≤ − 0 −3푚 log 훽 푛 log 푁 Pr 푋푖 > 1 훾 exp (2) Range queries O 1 + 1.5 log 푚 1 + 휖 , 0 푚 3푚 푘 + log 푁 푖=1 0 휖 √︂ 2 −3푚 log 훽 log 푁 푘0훾 Point queries O 1 + log 푛 1 + , 0 Finally, we need to determine the value of훾 such that exp − 3푚 log 푁 푚 휖 푘0+ 휖 √︃ −3푚 log 훽 is smaller than the value 훽. Thus, 훾 = . The communi- Then, Π훾 satisfies 휖-differential privacy for some 휖. 푘0 cation efficiency for each query type is described in the following Π훾 is depicted in Algorithm2. There are a few extensions to corollary. the subroutines and notation from Algorithm1. CreateIndex and Corollary 5.1. Let Πno−훾 be an outsourced database system with Lookup now build and query the index which maps a search key to storage efficiency (O(1), 0). Depending on the query type, Πno−훾 a pair — the record ID and the ORAM ID (1 to 푚) which stores the offers the following communication efficiency. record. Lines4 to6 of Algorithm2 Πsetup repeat for each ORAM √︃ − 푚 훽 1.5 푁 and operate on the records partitioned for the given ORAM using Range queries O 1 + 3 log log 푛 , O log 푚 log푛 푘0 푚 휖 hash function H on the record ID. A shared DP structure is created Epsolute: Efficiently Querying Databases While Providing Differential Privacy CCS ’21, November 15–19, 2021, Virtual Event, Republic ofKorea
with the sanitizer A (line7). In Algorithm2 Πquery, the total number TrusteduserpartyU UntrustedserverpartyS of ORAM requests is computed once (line4). Lines5 to7 repeat for 3 Computing the amount of noise
2 True indices each ORAM and operate on the subset of records stored in the given DPhistogram DPtree
ORAM. Note that U and S implicitly maintain 푚 ORAM states, and B+ tree 5 ORAM GET requests the algorithm uses the (A, B) sanitizer defined in Section4. Client 4 ORAM requests: ORAM IDs KVS Store Note that we guarantee privacy and access pattern protection on 6 prunning Block IDs fake records a record level. Each ORAM gets accessed at least once (much more 5 ORAM GET requests Lightweight ORAM KVS Store machine than once for a typical query) thus the existence of a particular Application result record in a particular ORAM is hidden.
1 Query: 5 ORAM GET requests ages18to 21 5.3 Practical improvements KVS Store 5 ORAM GET requests Here we describe the optimizations aimed at bringing the construc- User LightweightORAM machine tion’s performance to the real-world demands. KVS Store
5.3.1 ORAM request batching. We have noticed that although the Figure 2: Lightweight ORAM machines diagram. A user sends a query to U modeled as the client machine, which uses local data entire set of ORAM requests for each query is known in advance, the index and DP structures to prepare a set of ORAM requests, which requests are still executed sequentially. To address this inefficiency, are sent to respective ORAM machines. These machines execute the we have designed a way to combine the requests in a batch and ORAM protocol against the untrusted storage of S. reduce the number of network requests to the bare minimum. We have implemented this method over PathORAM, which we use for the (휂1, 휂2)-ORAM protocol, but the idea applies to most tree-based ORAMs (similar to [20]). Our optimization utilizes the fact that all PathORAM leaf IDs emphasize that U is still a single party, therefore, the security and are known in advance and paths in a tree-based storage share the correctness guarantees remain valid. buckets close to the root. The core idea is to read all paths first, The benefit of this approach is that each of the lightweight processes the requests and and then write all paths back. This way machines has its own hardware stack. Communication overhead the client makes a single read request, which is executed much among U machines is negligible compared to the one between U faster than many small requests. Requests are then processed in and S. The approach is also flexible: it is possible to use upto 푚 main memory, including re-encryptions. Finally, the client executes ORAM machines and the machines do not have to be identical. Our the write requests using remapped leaves as a single operation, experiments show that when the same number of CPU cores and saving again compared to sequential execution. amount of RAM are consumed the efficiency gain is upto 5 times. This optimization provides up to 8 times performance boost in our experiments. We note that the gains in speed and I/O overhead 6 EXPERIMENTAL EVALUATION are achieved at the expense of main memory, which is not an issue We have implemented our solution as a modular client-server ap- given that the memory is released after a batch, and our exper- plication in C++. We open-sourced all components of the software iments confirm that. The security guarantees of PathORAM are set: PathORAM [14] and B+ tree [11] implementations and the maintained with this optimization, since the security proof in [65, main query executor [12]. We provide PathORAM and B+ tree com- Section 3.6] still holds. Randomized encryption, statistically inde- ponents as C++ libraries to be used in other projects; the code is pendent remapping of leaves, and stash processing do not change. documented, benchmarked and tested (228 tests covering 100 % of the code). We have also published our datasets and query sets [13]. 5.3.2 Lightweight ORAM servers. We have found in our experi- For cryptographic primitives, we used OpenSSL library (version ments that naïve increase of the number of CPU cores and gigabytes 1.1.1i). For symmetric encryption in ORAM we have used AES-CBC of RAM does not translate into linear performance improvement −256 algorithm [26, 27] with a 256-bits key (i.e., 휂2 = 2 ), for the hash after some threshold. Investigating the observation we have found algorithm H used to partition records among ORAMs we have used E that the psolute protocol, executing parallel ORAM protocols, is SHA-256 algorithm [52]. Aggregate tree fanout 푘 is 16, proven to highly intensive with respect to main memory access, cryptographic be optimal in [58]. operations and network usage. The bottleneck is the hardware — We designed our experiments to answer the following questions: we have confirmed that on a single machine the RAM and network are saturated quickly preventing the linear scaling. Question-1 How practical is our system compared to the most To address the problem, we split the user party U into multi- efficient and most private real-world solutions? ple lightweight machines that are connected locally to each other Question-2 How practical is the storage overhead? and reside in a single trust domain (e.g., same data center). Specifi- Question-3 How different inputs and parameters of the system cally, we maintain a client machine that receives user requests and affect its performance? prepares ORAM read requests, and up to 푚 lightweight ORAM Question-4 How well does the system scale? machines, whose only job is to run the ORAM protocols in parallel. Question-5 What improvements do our optimizations provide? See Fig.2 for the schematic representation of the architecture. We Question-6 What is the impact of supporting multiple attributes? CCS ’21, November 15–19, 2021, Virtual Event, Republic of Korea Dmytro Bogatov, Georgios Kellaris, George Kollios, Kobbi Nissim, and Adam O’Neill
To address Question-1 we have run the default setting using 6.3 Experiment stages conventional RDBMS (MySQL and PostgreSQL), Linear Scan ap- Each experiment includes running 100 queries such that the over- proach and Shrinkwrap [5]. To target Question-2, we measured head is measured from loading query endpoints into memory to the exact storage used by the client and the server for different data, receiving the exact and whole query response from all ORAM ma- record and domain sizes. To answer Question-3, we ran a default chines. The output of an experiment is, among other things, the setting and then varied all parameters and inputs, one at a time. For overhead (in milliseconds), the number of real and noisy records Question-4 we gradually added vCPUs, ORAM servers and KVS fetched and communication volume averaged per query. instances and observed the rate of improvement in performance. For Question-5 we have run the default setting with our optimiza- 6.4 RDBMS, Linear Scan and Shrinkwrap tions toggled. Lastly, for Question-6 we have used two datasets to construct two indices and then queried each of the attributes. On top of varying the parameters, we have run similar workloads using alternative mechanisms — extremes representing highest 6.1 Data sets performance or highest privacy. Unless stated otherwise, the client and the server are in the trusted and untrusted regions respectively, We used two real and one synthetic datasets — California public pay with the network configuration as in Section 6.2. pension database 2019 [67] (referred to as “CA employees”), Public Use Microdata Sample from US Census 2018 [68] (referred to as Relational databases. Conventional RDBMS represents the most “PUMS”) and synthetic uniform dataset. We have used salary / wages efficient and least private and secure solution in our set. While columns of the real datasets, and the numbers in the uniform set MySQL and PostgreSQL offer some encryption options and no also represent salaries. The NULL and empty values were dropped. differential privacy, for our experiments we turned off security We created three versions of each dataset — 105, 106 and 107 features for maximal performance. We have run queries against records each. For uniform dataset, we simply generated the target MySQL and PostgreSQL varying data and record sizes. We used number of entries. For PUMS dataset, we picked the states whose n1-standard-32 GCP VMs in us-east1 region, running MySQL number of records most closely matches the target sizes (Louisiana version 14.14 and PostgreSQL version 10.14. for 105, California for 106 and the entire US for 107). Uniform dataset was also generated for different domain sizes — number of distinct Linear Scan. Linear scan is a primitive mechanism that keeps all values for the record. For CA employees dataset, the set contains records encrypted on the server then downloads, decrypts and 260 277 records, so we contracted it and expanded in the following scans the entire database to answer every query. This method is way. For contraction we uniformly randomly sampled 105 records. trivially correct, private and secure, albeit not very efficient. There For expansion, we computed the histogram of the original dataset are RDBMS solutions, which, when configured for maximum pri- and sampled values uniformly within the bins. vacy, exhibit linear scan behavior (e.g., MS-SQL Always Encrypted Each of the datasets has a number of corresponding query sets. with Randomized Encryption [48] and Oracle Column Transparent Each query set has a selectivity or range size, and is sampled either Data Encryption [53]). For a fair comparison we make the linear uniformly or following the dataset distribution (using its CDF). scan even more efficient by allowing it to download data via parallel threads matching the number of threads and bytes per request to 6.2 Default setting that of our solution. Although linear scan is wasteful in the amount of data it downloads and processes, compared to our solution it has The default setting uses the Π훾 from Section5 and lightweight a benefit of not executing an ORAM protocol with its logarithmic ORAM machines from Section 5.3.2 and Fig.2. We choose the Π훾 overhead and network communication in both directions. because it outperforms Πno−훾 in all experiments (see Question-4 in Section 6.5). In the setting, there are 64 Redis services (8 ser- Shrinkwrap. Shrinkwrap [5] is a construction that answers feder- vices per one Redis server VM), 8 ORAM machines communicating ated SQL queries hiding both access pattern and communication with 8 Redis services each, and the client, which communicates volume. Using the EMP toolkit [71] and the code Shrinkwrap au- with these 8 ORAM machines. We have empirically found this con- thors shared with us, we implemented a prototype that only answers figuration optimal for the compute nodes and network thatwe range queries. This part of Shrinkwrap amounts to making a scan used in the experiments. ORAM and Redis servers run on GCP over the input marking the records satisfying the range, sorting the n1-standard-16 VMs (Ubuntu 18.04), in regions us-east4 and input, and then revealing the result set plus DP noise to the client. us-east1 respectively. Client machine runs n1-highmem-16 VM For the latter part we have adapted Shrinkwrap’s Truncated Laplace in the same region as ORAM machines. The ping time between the Mechanism [5, Definition 4] to hierarchical method58 [ ] in order regions (i.e. between trusted and untrusted zones) is 12 ms and the to be able to answer an unbounded number of all possible range effective bandwidth is 150 MB/s. Ping within a region is negligible. queries. We have emulated the outsourced database setting by using Default DP parameters are 휖 = ln(2) ≈ 0.693 and 훽 = 2−20, two n1-standard-32 servers in different regions12 ( ms ping and which are consistent with the other DP applications proposed in 150 MB/s bandwidth) executing the algorithm in a circuit model the literature [38]. Buckets number is set as the largest power of (the faster option per Shrinkwrap experiments) and then revealing 푘 = 16 that is no greater than the domain of the dataset 푁 . the result to the trusted client. We note that although the complex- Default dataset is a uniform dataset of 106 records with domain ity of a Shrinkwrap query is O(푛 log푛) due to the sorting step, its size 104, and uniformly sampled queries with selectivity 0.5 %. De- functionality is richer as it supports more relational operators, like fault record size is 4 KiB. JOIN, GROUP BY and aggregation. We also note that since MySQL, Epsolute: Efficiently Querying Databases While Providing Differential Privacy CCS ’21, November 15–19, 2021, Virtual Event, Republic ofKorea
PostgreSQL and Shrinkwrap are not parallelized within the query, experiments using more CPUs do not yield higher performance.
6.5 Results and Observations After running the experiments, we have made the following obser- vations. Note that we report results based on the default setting. •E psolute is efficient compared to a strawman approach, RDBMS and Shrinkwrap: it is three orders of magnitude faster than Shrinkwrap, 18 times faster than the scan and only 4–8 times slower than a conventional database. In fact, for different queries, datasets, and record sizes, our system is much faster than the linear scan, as we show next. Figure 4: Linear scan performance, logarithmic scale. The experi- •E psolute’s client storage requirements are very practical: client ments are run for the default setting of 106 records of size 4 KiB and size is just below 30 MB while the size of the offloaded data is 64 threads, with one of the three parameters varying. over 400 times larger. •E psolute scales predictably with the change in its parameters: data size affects performance logarithmically, record size — lin- Linear scan experiments demonstrate the practicality of Epsolute early, and privacy budget 휖 — exponentially. compared to a trivial “download everything every time” approach, •E psolute is scalable: using Π훾 with the lightweight ORAM ma- see Fig.4. Linear scan’s overhead is O(푛) regardless of the queries, chines, the increase in the number of threads translates into linear while Epsolute’s overhead is O(log푛) times the result size. Accord- performance boost. ing to our experiments, Epsolute eclipses the linear scan at 4 KiB, 64 • The optimizations proposed in Section 5.3 provide up to an order threads and only ten thousand records (both mechanisms complete of magnitude performance gain. in about 120 ms). For a default setting (at a million records), the •E psolute efficiently supports multiple indexed attributes. The difference is 18 times, see Fig.4. overhead and the client storage increase slightly due to a lower Because Shrinkwrap sorts the input obliviously in a circuit model, privacy budget and extra local indices. it incurs O(푛 log푛) comparisons, each resulting in multiple circuit For the purposes of reproducibility we have put the log traces of gates, which is much more expensive than the linear scan. Unlike all our experiments along with the instructions on how to run them linear scan, however, Shrinkwrap does not require much client on a publicly available page epsolute.org. Unless stated otherwise, memory as the client merely coordinates the query. While Shrink- the scale in the figures is linear and the 푥-axis is categorical. wrap supports richer set of relational operators, for range queries alone Epsolute is three orders of magnitude faster.
Record 1 KiB 4 KiB 16 KiB 푛 400 KiB 400 B 400 KiB 102 KiB 400 KiB 1.6 MB 105 396 MB 4.6 MB 1.5 GB 14 MB 6.2 GB 51 MB 3.9 MB 400 B 3.9 MB 102 KiB 3.9 MB 1.6 MB 106 3.2 GB 15 MB 12 GB 25 MB 48 GB 62 MB 40 MB 400 B 40 MB 102 KiB 40 MB 1.6 MB 107 Figure 3: Different range-query mechanisms (log scale). Default set- 24 GB 99 MB 96 GB 109 MB 384 GB 146 MB ting: 106 4 KiB uniformly-sampled records with the range 104. 푛 100 104 106 푁 Question-1: against RDBMS, Linear Scan and Shrinkwrap. Table 1: Storage usage for varying data, record and domain sizes. The first experiment we have run using Epsolute is the default The values are as follows. Left top: index I (B+ tree), right top: ag- setting in which we observed the query overhead of 840 ms. To put gregate tree DS, right bottom: ORAM U state and left bottom (bold): this number in perspective, we compare Epsolute to conventional ORAM S state. Italic indicates that the value is estimated. relational databases, the linear scan and Shrinkwrap. For the default setting, MySQL and PostgreSQL, configured for no privacy and maximum performance, complete in 97 ms and Question-2: storage. While Epsolute storage efficiency is near- 220 ms respectively, which is just 8 to 4 times faster than Epsolute, optimal (O(1), 0), it is important to observe the absolute values. see Fig.3. Conventional RDBMS uses efficient indices (B+ trees) to Index I is implemented as a B+ tree with fanout 200 and occupancy locate requested records and sends them over without noise and 70 %, and its size, therefore, is roughly 5.7푛 bytes. Most of the ORAM encryption, and it does so using less hardware resources. In our client storage is the PathORAM stash with its size chosen in a way −32 experiments RDBMS performance is linearly correlated with the to bound failure probability to about 휂1 = 2 (see [65, Theorem result and record sizes. 1]). In Table1, we present Epsolute storage usage for the parameters CCS ’21, November 15–19, 2021, Virtual Event, Republic of Korea Dmytro Bogatov, Georgios Kellaris, George Kollios, Kobbi Nissim, and Adam O’Neill that affect it — data, record and domain sizes. We measured the is explained by the variance among parallel threads. During each sizes of the index I, DP structure DS, and ORAM client and server query the work is parallelized over 푚 ORAMs and the query is states. Our observations are: (i) index size expectedly grows only completed when the last thread finishes. The problem, in distributed with the data size, (ii) DS is negligibly small in practice, (iii) small systems known as “the curse of the last reducer” [66], is when one I and DS sizes imply the efficiency of supporting multiple indexed thread takes disproportionally long to finish. In our case, we run attributes, (iv) S to U storage size ratio varies from 85 in the smallest 64 threads in default setting, and the delay is usually caused by a setting to more than 2 000 in the largest, and (v) one can trade client variety of factors — blocking I/O, network delay or something else storage for ORAM failure probability. We conclude that the storage running on a shared vCPU. This effect is noticeable when a single requirements of Epsolute are practical. thread does relatively little work and small disruptions actually matter; the effect is negligible for large queries.
Figure 5: Privacy budget 휖 Figure 6: Effect of 휖 Figure 8: Record size Figure 9: Data size Figure 10: Domain size Question-3: varying parameters. To measure and understand the impact of configuration parameters on the performance of our Record, data and domain sizes. We have tried 1 KiB, 4 KiB and solution we have varied 휖, record size, data size 푛, domain size 푁 , 16 KiB records, see Fig.8. Trivially, the elapsed time is directly selectivities, as well as data and query distributions. The relation proportional to the record size. that is persistent throughout the experiments is that for given data We set 푛 to 105, 106 and 107, see Fig.9. The observed correlation and record sizes, the performance (the time to completely execute of overhead against the data size is positive but non-linear, 10 times a query) is strictly proportional to the total number of records, fake increment in 푛 results in less than 10 times increase in time. This is and real, that are being accessed per query. Each record access explained by the ORAM overhead — when 푛 changes, the ORAM goes through the ORAM protocol, which, in turn, downloads, re- storage gets bigger and its overhead is logarithmic. encrypts and uploads O(log푛) blocks. These accesses contribute For synthetic datasets we have set 푁 to 100, 104 and 106, see the most to the overhead and all other stages (e.g., traversing index Fig. 10. The results for domain size correlation are more interesting: or aggregate tree) are negligible. low and high values deliver worse performance than the middle Privacy budget 휖 and its effect. We have run the default setting value. Small domain for a large data set means that a query often for 휖 = {0.1, 0.5, ln 2, 1.0, ln 3}. 휖 strictly contributes to the amount results in a high number of real records, which implies significant of noise, which grows exponentially as 휖 decreases, see Fig.5, ob- latency regardless of noise parameters. A sparse dataset, on the serve sharp drop. As visualized on Fig.6, at high 휖 values the noise other hand, means that for a given selectivity wider domain is contributes a fraction of total overhead, while at low values the covered per query, resulting in more nodes in the aggregate tree noise dominates the overhead entirely. contributing to the total noise value.
Figure 7: Selectivity Figure 11: Data distribution Figure 12: Query distribution
Selectivity. We have ranged the selectivity from 0.1 % to 2 % of the Data and query distributions. Our solution performs best on the total number of records, see Fig.7. Overhead expectedly grows with uniform data and uniform ranges, see Figs. 11 and 12. Once a skew the result size. For smaller queries, and thus for lower overhead, the of any kind is introduced, there appear sparse and dense regions relation is positive, but not strictly proportional. This phenomena, that contribute more overhead than uniform regions. Sparse regions observed for the experiments with low resulting per-query time, span over wider range for a given selectivity, which results in more Epsolute: Efficiently Querying Databases While Providing Differential Privacy CCS ’21, November 15–19, 2021, Virtual Event, Republic ofKorea noise. Dense regions are likely to include more records for a given range size, which again results in more fetched records. Both real datasets are heavily skewed towards smaller values as few people have ultra-high salaries.
Figure 14: Query overhead when using multiple attributes. Only A and Only B index one attribute. A and B indexes both attributes and then queries one of them. Alternating indexes both attributes and runs half of the queries against A and another half against B.
Figure 13: Scalability measurements for Π훾 and Πno−훾 attributes A and B respectively. We ran queries against only A, only Question-4: scalability. Horizontal scaling is a necessity for a B and against both attributes in alternating fashion. Each of the ln 2 practical system, this is the motivation for the parallelization in the attributes used 휖 = 2 to match the default privacy budget of ln(2). first place. Ideally, performance should improve proportionally to Fig. 14 demonstrates the query overhead of supporting multiple the parallelization factor, number of ORAMs in our case, 푚. attributes. The principal observation is that the overhead increases For scalability experiments we run the default setting for both only slightly due to a lower privacy budget. The client storage went Πno−훾 and Π훾 (no-훾-method and 훾-method respectively) varying up by just 9 MB, and still constitutes only 3.3 % of the server storage, the number of ORAMs 푚, from 8 to 96 (maximum vCPUs on a which is not affected by the number of indexed attributes. GCP VM). The results are visualized on Fig. 13. We report two positive observations: (i) the 훾-method provides substantially better 7 CONCLUSION AND FUTURE WORK performance and storage efficiency, and (ii) when using this method In this paper, we present a system called Epsolute that can be used 푚 = the system scales linearly with the number of ORAMs. ( 96 is a to store and retrieve encrypted records in the cloud while providing special case because some ORAMs had to share a single KVS.) strong and provable security guarantees, and that exhibits excellent query performance for range and point queries. We use an opti- Improvement (section) Enabled Disabled Boost mized Oblivious RAM protocol that has been parallelized together with very efficient Differentially Private sanitizers that hide both ORAM batching (5.3.1) 840 ms 6 978 ms 8.3x the access patterns and the exact communication volume sizes and Lightweight ORAM machines (5.3.2) 840 ms 4 484 ms 5.3x can withstand advanced attacks that have been recently developed. Both improvements 840 ms 8 417 ms 10.0x We provide a prototype of the system and present an extensive Table 2: Improvements over parallel Epsolute evaluation over very large and diverse datasets and workloads that show excellent performance for the given security guarantees. In our future work, we plan to investigate methods to extend Question-5: optimizations benefits. Table2 demonstrates the our approaches to use a trusted execution environment (TEE), like boosts our improvements provide; when combined, the speedup is SGX, in order to improve the performance even further. We will up to an order of magnitude. also explore a multi-user setting without the need for a shared ORAM request batching (Section 5.3.1) makes the biggest dif- stateful client, and enabling dynamic workloads with insertions ference. We have run the default setting with and without the and updates. We will also consider how adaptive and non-adaptive batching. The overhead is substantially smaller because far fewer security models would change in the case of dynamic environments. I/O requests are being made, which implies benefits across the full One would presumably also require DP of the server’s view in this stack: download, re-encryption and upload. setting. Lastly, we plan to explore other relational operations like Using lightweight ORAM machines (Section 5.3.2) makes a differ- JOIN and GROUP BY. ence when scaling. In the default setting, 64 parallel threads quickly saturate the memory access and network channel, while spreading ACKNOWLEDGMENTS computation among nodes removes the bottleneck. We thank anonymous reviewers and Arkady Yerukhimovich for Question-6: multiple attributes. Epsolute supports multiple in- valuable feedback. We also thank Daria Bogatova for devising the dexed attributes. In Section 4.4 we described that the performance name Epsolute and helping with the plots, diagrams and writing. implications amount to having an index I and a DP structure DS Finally, we thank Johes Bater for sharing Shrinkwrap code and per attribute and sharing the privacy budget 휖 among all attributes. reviewing the prototype. Kobbi Nissim was supported by NSF Grant As shown in Table1, I and DS are the smallest components of No. 2001041, “Rethinking Access Pattern Privacy: From Theory to the client storage. To observe the query performance impact, we Practice”. Dmytro Bogatov and George Kollios were supported by have used the default dataset with domains 104 and 106 as indexed NSF CNS-2001075 Award. CCS ’21, November 15–19, 2021, Virtual Event, Republic of Korea Dmytro Bogatov, Georgios Kellaris, George Kollios, Kobbi Nissim, and Adam O’Neill
REFERENCES [23] Cynthia Dwork, Krishnaram Kenthapadi, Frank McSherry, Ilya Mironov, and [1] Arvind Arasu, Spyros Blanas, Ken Eguro, Manas Joglekar, Raghav Kaushik, Moni Naor. 2006. Our data, ourselves: Privacy via distributed noise generation. In Donald Kossmann, Ravi Ramamurthy, Prasang Upadhyaya, and Ramarathnam Annual International Conference on the Theory and Applications of Cryptographic Venkatesan. 2013. Secure Database-as-a-Service with Cipherbase. In Proceed- Techniques. Springer, 486–503. https://doi.org/10.1007/11761679_29 ings of the 2013 ACM SIGMOD International Conference on Management of [24] Cynthia Dwork, Frank McSherry, Kobbi Nissim, and Adam Smith. 2006. Cali- Data (SIGMOD ’13). Association for Computing Machinery, 1033–1036. https: brating noise to sensitivity in private data analysis. In Theory of cryptography //doi.org/10.1145/2463676.2467797 conference. Springer, 265–284. https://doi.org/10.1007/11681878_14 [2] Arvind Arasu, Spyros Blanas, Ken Eguro, Raghav Kaushik, Donald Kossmann, [25] Cynthia Dwork, Moni Naor, Toniann Pitassi, and Guy N Rothblum. 2010. Differen- Ravi Ramamurthy, and Ramarathnam Venkatesan. 2013. Orthogonal Security tial privacy under continual observation. In Proceedings of the forty-second ACM With Cipherbase. In 6th Biennial Conference on Innovative Data Systems Research symposium on Theory of computing. 715–724. https://doi.org/10.1145/1806689. (CIDR’13). 1806787 [3] Sumeet Bajaj and Radu Sion. 2013. TrustedDB: A trusted hardware-based database [26] Morris Dworkin. 2001. Recommendation for Block Cipher Modes of Operation: with privacy and data confidentiality. IEEE Transactions on Knowledge and Data Methods and Techniques. https://doi.org/10.6028/NIST.SP.800-38A Engineering 26, 3 (2013), 752–765. https://doi.org/10.1109/TKDE.2013.38 [27] Morris Dworkin, Elaine Barker, James Nechvatal, James Foti, Lawrence Bassham, [4] Johes Bater, Gregory Elliott, Craig Eggen, Satyender Goel, Abel Kho, and Jennie E. Roback, and James Dray. 2001. Advanced Encryption Standard (AES). https: Rogers. 2017. SMCQL: Secure Querying for Federated Databases. Proc. VLDB //doi.org/10.6028/NIST.FIPS.197 Endow. 10, 6 (Feb. 2017), 673–684. https://doi.org/10.14778/3055330.3055334 [28] Saba Eskandarian and Matei Zaharia. 2019. ObliDB: Oblivious query processing [5] Johes Bater, Xi He, William Ehrich, Ashwin Machanavajjhala, and Jennie Rogers. for secure databases. PVLDB 13, 2 (2019), 169–183. https://doi.org/10.14778/ 2018. Shrinkwrap: efficient sql query processing in differentially private data 3364324.3364331 federations. Proceedings of the VLDB Endowment 12, 3 (2018), 307–320. https: [29] Benny Fuhry, Raad Bahmani, Ferdinand Brasser, Florian Hahn, Florian Ker- //doi.org/10.14778/3291264.3291274 schbaum, and Ahmad-Reza Sadeghi. 2017. HardIDX: Practical and secure index [6] Amos Beimel, Hai Brenner, Shiva Prasad Kasiviswanathan, and Kobbi Nissim. with SGX. In IFIP Annual Conference on Data and Applications Security and Privacy. 2014. Bounds on the sample complexity for private learning and private data Springer, 386–408. https://doi.org/10.1007/978-3-319-61176-1_22 release. Machine learning 94, 3 (2014), 401–437. https://doi.org/10.1007/s10994- [30] Craig Gentry. 2010. Computing arbitrary functions of encrypted data. Commun. 013-5404-1 ACM 53, 3 (2010), 97–105. https://doi.org/10.1145/1666420.1666444 [7] Amos Beimel, Kobbi Nissim, and Uri Stemmer. 2013. Private learning and sanitiza- [31] Oded Goldreich. 1987. Towards a theory of software protection and simulation tion: Pure vs. approximate differential privacy. In Approximation, Randomization, by oblivious RAMs. In Proceedings of the nineteenth annual ACM symposium on and Combinatorial Optimization. Algorithms and Techniques. Springer, 363–378. Theory of computing. 182–194. https://doi.org/10.1145/28395.28416 https://doi.org/10.1007/978-3-642-40328-6_26 [32] Oded Goldreich and Rafail Ostrovsky. 1996. Software protection and simulation [8] Amos Beimel, Kobbi Nissim, and Mohammad Zaheri. 2019. Exploring Differen- on oblivious RAMs. Journal of the ACM (JACM) 43, 3 (1996), 431–473. https: tial Obliviousness. In Approximation, Randomization, and Combinatorial Opti- //doi.org/10.1145/233551.233553 mization. Algorithms and Techniques (APPROX/RANDOM 2019) (Leibniz Inter- [33] Paul Grubbs, Marie-Sarah Lacharité, Brice Minaud, and Kenneth G Paterson. 2018. national Proceedings in Informatics (LIPIcs), Vol. 145). Schloss Dagstuhl–Leibniz- Pump up the volume: Practical database reconstruction from volume leakage on Zentrum fuer Informatik, 65:1–65:20. https://doi.org/10.4230/LIPIcs.APPROX- range queries. In Proceedings of the 2018 ACM SIGSAC Conference on Computer RANDOM.2019.65 and Communications Security. 315–331. https://doi.org/10.1145/3243734.3243864 [9] Vincent Bindschaedler, Paul Grubbs, David Cash, Thomas Ristenpart, and Vitaly [34] Paul Grubbs, Thomas Ristenpart, and Vitaly Shmatikov. 2017. Why Your En- Shmatikov. 2018. The Tao of Inference in Privacy-protected Databases. PVLDB crypted Database Is Not Secure. In Proceedings of the 16th Workshop on Hot Topics 11, 11 (2018), 1715–1728. https://doi.org/10.14778/3236187.3236217 in Operating Systems. ACM, 162–168. https://doi.org/10.1145/3102980.3103007 [10] Avrim Blum, Katrina Ligett, and Aaron Roth. 2013. A learning theory approach [35] Zichen Gui, Oliver Johnson, and Bogdan Warinschi. 2019. Encrypted databases: to non-interactive database privacy. Journal of the ACM (JACM) 60, 2 (2013), New volume attacks against range queries. In Proceedings of the 2019 ACM SIGSAC 1–25. https://doi.org/10.1145/1374376.1374464 Conference on Computer and Communications Security. 361–378. https://doi.org/ [11] Dmytro Bogatov. 2021. B+ tree (static). https://github.com/epsolute/b-plus-tree. 10.1145/3319535.3363210 [12] Dmytro Bogatov. 2021. Epsolute. https://github.com/epsolute/epsolute. [36] Michael Hay, Vibhor Rastogi, Gerome Miklau, and Dan Suciu. 2010. Boosting the [13] Dmytro Bogatov. 2021. Original and procesed datasets used in this paper. http: Accuracy of Differentially Private Histograms through Consistency. Proc. VLDB //csr.bu.edu/dp-oram/. Accessed: 2021-01-24. Endow. 3, 1–2 (Sept. 2010), 1021–1032. https://doi.org/10.14778/1920841.1920970 [14] Dmytro Bogatov. 2021. PathORAM. https://github.com/epsolute/path-oram. [37] Bijit Hore, Sharad Mehrotra, Mustafa Canim, and Murat Kantarcioglu. 2012. [15] Dmytro Bogatov, George Kollios, and Leonid Reyzin. 2019. A comparative Secure multidimensional range queries over outsourced data. VLDBJ 21, 3 (2012), evaluation of order-revealing encryption schemes and secure range-query pro- 333–358. https://doi.org/10.1007/s00778-011-0245-7 tocols. Proceedings of the VLDB Endowment 12, 8 (2019), 933–947. https: [38] Justin Hsu, Marco Gaboardi, Andreas Haeberlen, Sanjeev Khanna, Arjun Narayan, //doi.org/10.14778/3324301.3324309 Benjamin C Pierce, and Aaron Roth. 2014. Differential privacy: An economic [16] Mark Bun, Kobbi Nissim, Uri Stemmer, and Salil Vadhan. 2015. Differentially method for choosing epsilon. In 2014 IEEE 27th Computer Security Foundations private release and learning of threshold functions. In 2015 IEEE 56th Annual Symposium. IEEE, 398–410. https://doi.org/10.1109/CSF.2014.35 Symposium on Foundations of Computer Science. IEEE, 634–649. https://doi.org/ [39] Yuval Ishai, Eyal Kushilevitz, Steve Lu, and Rafail Ostrovsky. 2016. Private large- 10.1109/FOCS.2015.45 scale databases with distributed searchable symmetric encryption. In Cryptogra- [17] David Cash, Paul Grubbs, Jason Perry, and Thomas Ristenpart. 2015. Leakage- phers’ Track at the RSA Conference. Springer, 90–107. https://doi.org/10.1007/978- abuse attacks against searchable encryption. In Proceedings of the 22nd ACM 3-319-29485-8_6 SIGSAC conference on computer and communications security. 668–679. https: [40] Mohammad Saiful Islam, Mehmet Kuzu, and Murat Kantarcioglu. 2012. Access //doi.org/10.1145/2810103.2813700 Pattern disclosure on Searchable Encryption: Ramification, Attack and Mitigation. [18] T-H. Hubert Chan, Kai-Min Chung, Bruce M. Maggs, and Elaine Shi. 2019. Foun- In 19th Annual Network and Distributed System Security Symposium, NDSS 2012, dations of Differentially Oblivious Algorithms. In Proceedings of the Thirtieth San Diego, California, USA, February 5-8, 2012. The Internet Society. Annual ACM-SIAM Symposium on Discrete Algorithms (San Diego, California) [41] Mohammad Saiful Islam, Mehmet Kuzu, and Murat Kantarcioglu. 2014. Inference (SODA ’19). Society for Industrial and Applied Mathematics, USA, 2448–2467. attack against encrypted range queries on outsourced databases. In Proceedings [19] Zhao Chang, Dong Xie, and Feifei Li. 2016. Oblivious RAM: A dissection and of the 4th ACM conference on Data and application security and privacy. 235–246. experimental evaluation. Proceedings of the VLDB Endowment 9, 12, 1113–1124. https://doi.org/10.1145/2557547.2557561 https://doi.org/10.14778/2994509.2994528 [42] Haim Kaplan, Katrina Ligett, Yishay Mansour, Moni Naor, and Uri Stemmer. 2020. [20] Binyi Chen, Huijia Lin, and Stefano Tessaro. 2016. Oblivious Parallel RAM: Privately Learning Thresholds: Closing the Exponential Gap. In Proceedings of Improved Efficiency and Generic Constructions. In Theory of Cryptography, Thirty Third Conference on Learning Theory (Proceedings of Machine Learning Eyal Kushilevitz and Tal Malkin (Eds.). Springer Berlin Heidelberg, 205–234. Research, Vol. 125). PMLR, 2263–2285. https://doi.org/10.1007/978-3-662-49099-0_8 [43] Georgios Kellaris, George Kollios, Kobbi Nissim, and Adam O’neill. 2016. Generic [21] Ioannis Demertzis, Dimitrios Papadopoulos, Charalampos Papamanthou, and attacks on secure outsourced databases. In Proceedings of the 2016 ACM SIGSAC Saurabh Shintre. 2020. SEAL: Attack Mitigation for Encrypted Databases Conference on Computer and Communications Security. 1329–1340. https://doi. via Adjustable Leakage. In 29th USENIX Security Symposium (USENIX Secu- org/10.1145/2976749.2978386 rity 20). USENIX Association, 2433–2450. https://www.usenix.org/conference/ [44] Evgenios M Kornaropoulos, Charalampos Papamanthou, and Roberto Tamassia. usenixsecurity20/presentation/demertzis 2020. The state of the uniform: attacks on encrypted databases beyond the [22] Ioannis Demertzis, Stavros Papadopoulos, Odysseas Papapetrou, Antonios Deli- uniform query distribution. In 2020 IEEE Symposium on Security and Privacy (SP). giannakis, and Minos Garofalakis. 2016. Practical private range search revisited. IEEE, 1223–1240. https://doi.org/10.1109/SP40000.2020.00029 In Proceedings of the 2016 International Conference on Management of Data. 185– [45] Marie-Sarah Lacharité, Brice Minaud, and Kenneth G Paterson. 2018. Improved 198. https://doi.org/10.1145/2882903.2882911 reconstruction attacks on encrypted data using range query leakage. In 2018 IEEE Epsolute: Efficiently Querying Databases While Providing Differential Privacy CCS ’21, November 15–19, 2021, Virtual Event, Republic ofKorea
Symposium on Security and Privacy (SP). IEEE, 297–314. https://doi.org/10.1109/ https://doi.org/10.1109/ICDE.2018.00082 SP.2018.00002 [61] Cetin Sahin, Victor Zakhary, Amr El Abbadi, Huijia Lin, and Stefano Tessaro. [46] Kasper Green Larsen, Mark Simkin, and Kevin Yeo. 2020. Lower Bounds for 2016. Taostore: Overcoming asynchronicity in oblivious data storage. In 2016 Multi-server Oblivious RAMs. In Theory of Cryptography. Springer International IEEE Symposium on Security and Privacy (SP). IEEE, 198–217. https://doi.org/10. Publishing, 486–503. https://doi.org/10.1007/978-3-030-64375-1_17 1109/SP.2016.20 [47] Frank D McSherry. 2009. Privacy integrated queries: an extensible platform [62] Bharath Kumar Samanthula, Wei Jiang, and Elisa Bertino. 2014. Privacy- for privacy-preserving data analysis. In Proceedings of the 2009 ACM SIGMOD preserving complex query evaluation over semantically secure encrypted data. International Conference on Management of data. 19–30. https://doi.org/10.1145/ In European Symposium on Research in Computer Security. Springer, 400–418. 1559845.1559850 https://doi.org/10.1007/978-3-319-11203-9_23 [48] Microsoft. 2021. MS-SQL Always Encrypted. https://docs.microsoft.com/sql/ [63] Elaine Shi, T-H Hubert Chan, Emil Stefanov, and Mingfei Li. 2011. Oblivious relational-databases/security/encryption/always-encrypted-database-engine. RAM with 푂 (log3 푁 ) worst-case cost. In International Conference on The Theory [49] Ilya Mironov, Omkant Pandey, Omer Reingold, and Salil Vadhan. 2009. Com- and Application of Cryptology and Information Security. Springer, 197–214. https: putational differential privacy. In Annual International Cryptology Conference. //doi.org/10.1007/978-3-642-25385-0_11 Springer, 126–142. https://doi.org/10.1007/978-3-642-03356-8_8 [64] Emil Stefanov, Elaine Shi, and Dawn Xiaodong Song. 2012. Towards Practical [50] Pratyush Mishra, Rishabh Poddar, Jerry Chen, Alessandro Chiesa, and Raluca Ada Oblivious RAM. In Network and Distributed System Security Symposium (NDSS). Popa. 2018. Oblix: An efficient oblivious search index. In 2018 IEEE Symposium on [65] Emil Stefanov, Marten Van Dijk, Elaine Shi, Christopher Fletcher, Ling Ren, Security and Privacy (SP). IEEE, 279–296. https://doi.org/10.1109/SP.2018.00045 Xiangyao Yu, and Srinivas Devadas. 2013. Path ORAM: an extremely simple [51] Muhammad Naveed, Seny Kamara, and Charles V Wright. 2015. Inference attacks oblivious RAM protocol. In Proceedings of the 2013 ACM SIGSAC conference on on property-preserving encrypted databases. In Proceedings of the 22nd ACM Computer & communications security. 299–310. https://doi.org/10.1145/3177872 SIGSAC Conference on Computer and Communications Security. 644–655. https: [66] Siddharth Suri and Sergei Vassilvitskii. 2011. Counting triangles and the curse of //doi.org/10.1145/2810103.2813651 the last reducer. In Proceedings of the 20th international conference on World wide [52] National Institute of Standards and Technology. 2015. Secure Hash Standard web. 607–614. https://doi.org/10.1145/1963405.1963491 (SHS). https://doi.org/10.6028/NIST.FIPS.180-4 [67] Transparent California. 2019. California public pay and pension 2019 dataset. [53] Oracle. 2021. Introduction to Transparent Data Encryption. https://docs.oracle. https://transparentcalifornia.com. com/database/121/ASOAG/introduction-to-transparent-data-encryption.htm. [68] U.S. Census Bureau. 2018. American Community Survey Public Use Microdata [54] Antonis Papadimitriou, Ranjita Bhagwan, Nishanth Chandran, Ramachandran Sample. https://www.census.gov/programs-surveys/acs/microdata.html. Ramjee, Andreas Haeberlen, Harmeet Singh, Abhishek Modi, and Saikrishna [69] Vinod Vaikuntanathan. 2011. Computing blindfolded: New developments in fully Badrinarayanan. 2016. Big Data Analytics over Encrypted Datasets with Seabed. homomorphic encryption. In 2011 IEEE 52nd Annual Symposium on Foundations In 12th USENIX Symposium on Operating Systems Design and Implementation of Computer Science. IEEE, 5–16. https://doi.org/10.1109/FOCS.2011.98 (OSDI 16). USENIX Association, 587–602. [70] Dhinakaran Vinayagamurthy, Alexey Gribov, and Sergey Gorbunov. 2019. [55] Rishabh Poddar, Tobias Boelter, and Raluca Ada Popa. 2019. Arx: an encrypted StealthDB: a scalable encrypted database with full SQL query support. Pro- database using semantically secure encryption. Proceedings of the VLDB Endow- ceedings on Privacy Enhancing Technologies 2019, 3 (2019), 370–388. https: ment 12, 11 (2019), 1664–1678. https://doi.org/10.14778/3342263.3342641 //doi.org/10.2478/popets-2019-0052 [56] Raluca Ada Popa, Catherine MS Redfield, Nickolai Zeldovich, and Hari Balakrish- [71] Xiao Wang, Alex J. Malozemoff, and Jonathan Katz. 2016. EMP-toolkit: Efficient nan. 2011. CryptDB: Protecting confidentiality with encrypted query processing. MultiParty computation toolkit. https://github.com/emp-toolkit. In Proceedings of the Twenty-Third ACM Symposium on Operating Systems Princi- [72] Xiaokui Xiao, Guozhang Wang, and Johannes Gehrke. 2010. Differential privacy ples. 85–100. via wavelet transforms. IEEE Transactions on knowledge and data engineering 23, [57] Christian Priebe, Kapil Vaswani, and Manuel Costa. 2018. EnclaveDB: A secure 8 (2010), 1200–1214. https://doi.org/10.1109/TKDE.2010.247 database using SGX. In 2018 IEEE Symposium on Security and Privacy (SP). IEEE, [73] Dong Xie, Guanru Li, Bin Yao, Xuan Wei, Xiaokui Xiao, Yunjun Gao, and Minyi 264–278. https://doi.org/10.1109/SP.2018.00025 Guo. 2016. Practical private shortest path computation based on oblivious storage. [58] Wahbeh Qardaji, Weining Yang, and Ninghui Li. 2013. Understanding hierarchical In 2016 IEEE 32nd International Conference on Data Engineering (ICDE). IEEE, methods for differentially private histograms. Proceedings of the VLDB Endowment 361–372. https://doi.org/10.1109/ICDE.2016.7498254 6, 14 (2013), 1954–1965. https://doi.org/10.14778/2556549.2556576 [74] Min Xu, Antonis Papadimitriou, Andreas Haeberlen, and Ariel Feldman. 2019. [59] Amrita Roy Chowdhury, Chenghong Wang, Xi He, Ashwin Machanavajjhala, Hermetic: Privacy-preserving distributed analytics without (most) side channels. and Somesh Jha. 2020. Crypt휖: Crypto-assisted differential privacy on untrusted (2019). servers. In Proceedings of the 2020 ACM SIGMOD International Conference on [75] Wenting Zheng, Ankur Dave, Jethro G Beekman, Raluca Ada Popa, Joseph E Management of Data. 603–619. https://doi.org/10.1145/3318464.3380596 Gonzalez, and Ion Stoica. 2017. Opaque: An oblivious and encrypted distributed [60] Cetin Sahin, Tristan Allard, Reza Akbarinia, Amr El Abbadi, and Esther Pacitti. analytics platform. In 14th USENIX Symposium on Networked Systems Design and 2018. A Differentially Private Index for Range Query Processing in Clouds. In Implementation (NSDI ’17). 283–298. 2018 IEEE 34th International Conference on Data Engineering (ICDE). 857–868.