Deterministic, Stash-Free Write-Only ORAM

Abstract

Write-Only Oblivious RAM (WoORAM) protocols provide privacy by encrypting the contents of data and also hiding the pattern of write operations over that data. WoORAMs provide better privacy than plain encryption and better performance than more general ORAM schemes (which hide both writing and reading access patterns), and the write-oblivious setting has been applied to important applications of cloud storage synchronization and encrypted hidden volumes. In this paper, we introduce an entirely new technique for Write-Only ORAM, called DetWoORAM. Unlike previous solutions, DetWoORAM uses a deterministic, sequential writing pattern without the need for any "stashing" of blocks in local state when writes fail. Our protocol, while conceptually simple, provides substantial improvement over prior solutions, both asymptotically and experimentally. In particular, under typical settings the DetWoORAM writes only 2 blocks (sequentially) to backend memory for each block written to the device, which is optimal. We have implemented our solution using the BUSE (block device in user-space) module and tested DetWoORAM against both an encryption only baseline of dm-crypt and prior, randomized WoORAM solutions, measuring only a 3x-14x slowdown compared to an encryption-only baseline and around 6x-19x speedup compared to prior work.

rORAM: Efficient Range ORAM with O(log2 N) Locality

“…In fact, the reduction in I/O requests makes rORAM faster than Path ORAM even for SSDs (around 30x) and network block devices (around 10x). As noted previously [36], ensuring locality of accesses improves performance on SSDs while the reduced number of round-trips required to fetch all blocks in a range makes rORAM faster for network block devices.…”

“…First introduced by Blass et al [11] in the context of protecting hidden volumes, a randomized procedure was used to achieve obliviousness. Later, Roche et al [36] showed that writeobliviousness can be achieved with deterministic, sequential writing patterns. However, the data locality of reads was not evaluated, and depends largely on the write pattern itself.…”

“…If the client is not capable of storing the map locally, it can be stored recursively in a series of O(log N ) smaller ORAMs on the server. Alternatively, one can use an oblivious data structure (more specifically, an oblivious trie [36,41]) to store the position map. In either solution, the total communication overhead for a single access with Path ORAM is O(log 2 N ).…”

“…If stored locally, this extra data is handled at no added cost, but typically the size of the position map would exceed local storage requirements, and would need to be stored securely in the remote storage. Typically this requires a recursive ORAM or an oblivious trie [36,41] to store the position map obliviously -both Fig. 4.…”

“…Pointer-based oblivious data structures. To solve the problem of updating multiple ORAMs where data may be duplicated, we propose a new distributed position map construction leveraging pointer-based oblivious data structure techniques, initially introduced by Wang et al [44] and subsequently used by several ORAM solutions [15,35,36,44]. In particular, alongside each physical block we store the path tag of that block in all ORAMs, as shown in Figure 4.…”