Onion ORAM: A Constant Bandwidth Blowup Oblivious RAM [chapter]

Srinivas Devadas, Marten van Dijk, Christopher W. Fletcher, Ling Ren, Elaine Shi, Daniel Wichs
2015 Lecture Notes in Computer Science  
We present Onion ORAM, an Oblivious RAM (ORAM) with constant worst-case bandwidth blowup that leverages poly-logarithmic server computation to circumvent the logarithmic lower bound on ORAM bandwidth blowup. Our construction does not require fully homomorphic encryption, but employs an additively homomorphic encryption scheme such as the Damgård-Jurik cryptosystem, or alternatively a BGV-style somewhat homomorphic encryption scheme without bootstrapping. At the core of our construction is an
more » ... M scheme that has "shallow circuit depth" over the entire history of ORAM accesses. We also propose novel techniques to achieve security against a malicious server, without resorting to expensive and non-standard techniques such as SNARKs. To the best of our knowledge, Onion ORAM is the first concrete instantiation of a constant bandwidth blowup ORAM under standard assumptions (even for the semi-honest setting). Server Computation in ORAM The ORAM model considered historically, starting with the work of Goldreich and Ostrovsky [20, 21, 39] , assumed that the server acts as a simple storage device that allows the client to read and write data to it, but does not perform any computation otherwise. However, in many scenarios investigated by subsequent works [9, 35, 45, 53 ] (e.g., the setting of remote oblivious file servers), the untrusted server has significant computational power, possibly even much greater than that of the client. Therefore, it is natural to extend the ORAM model to allow for server computation, 1 and to distinguish between the amount of computation performed by the server and the amount of communication with the client. Indeed, many recent ORAM schemes have implicitly or explicitly leveraged some amount of server computation to either reduce bandwidth cost [1, 8, 13, 14, 32, 35, 42, 46, 55] , or reduce the number of online roundtrips [52] . We remark that some prior works [1, 35] call themselves oblivious storage (or oblivious outsourced storage) to distinguish from the standard ORAM model where there is no server computation. We will simply apply the term ORAM to both models, and refer to ORAM with/without server computation to distinguish between the two. At first, many works implicitly used server computation in ORAM constructions [13, 14, 35, 42, 46, 52, 55] , without making a clear definitional distinction from standard ORAM. Apon et al. were the first to observe that such a distinction is warranted [1] , not only for the extra rigor, but also because the definition renders the important Goldreich-Ostrovsky ORAM lower bound [21] inapplicable to the server computation setting -as we discuss below. Attempts to "Break" the Goldreich-Ostrovsky Lower Bound Traditionally, ORAM constructions are evaluated by their bandwidth, client storage and server storage. Bandwidth is the amount of communication (in bits) between client/server to serve a client request, including the communication in the background to maintain the ORAM (i.e., ORAM evictions). We also define bandwidth blowup to be bandwidth measured in the number of blocks (i.e., blowup compared to a normal RAM). Client storage is the amount of trusted local memory required at the client side to manage the ORAM protocol and server storage is the amount of storage needed at the server to store all data blocks. In their seminal work [21] , Goldreich and Ostrovsky showed that an ORAM of N blocks must incur a O(log N ) lower bound in bandwidth blowup, under O(1) blocks of client storage. If we allow the server to perform computation, however, the Goldreich-Ostrovsky lower bound no longer applies with respect to client-server bandwidth [1] . The reason is that the Goldreich-Ostrovsky bound is in terms of the number of operations that must be performed. With server computation, though the number of operations is still subject to the bound, most operations can be performed on the server-side without client intervention, making it possible to break the bound in terms of bandwidth between client and server. Since historically bandwidth has been the most important metric and the bottleneck for ORAM, breaking the bound in terms of bandwidth constitutes a significant advance. However, it turns out that this is not easy. Indeed, two prior works [1, 35] have made endeavors towards this direction using homomorphic encryption. Path-PIR [35] leverages additively homomorphic encryption (AHE) to improve ORAM online bandwidth, but its overall bandwidth blowup is still poly-logarithmic. On the other hand, Apon et al. [1] showed that using a fully homomorphic encryption (FHE) scheme with constant ciphertext expansion, one can construct an ORAM scheme with constant bandwidth blowup. The main idea is that, instead of having the client move data around on the server "manually" by reading and writing to the server, the client can instruct the server to perform ORAM request and eviction operations under an FHE scheme without revealing any data and its movement. While this is a very promising direction, it suffers from the following drawbacks: • First, ORAM keeps access patterns private by continuously shuffling memory as data is accessed. This means the ORAM circuit depth that has to be evaluated under FHE depends on the number of ORAM accesses made and can grow unbounded (which we say to mean any
doi:10.1007/978-3-662-49099-0_6 fatcat:vlbwtfqrc5foheq5gtxsyskakq