Single Round-trip Hierarchical ORAM via Succinct Indices

TL;DR

RankORAM solves the practical adoption gap for Hierarchical ORAM by introducing historicalMembership, a succinct client-side data structure that encodes per-block location recency to enable a single-round-trip access and non-interactive server queries. Replacing expensive cuckoo hash tables with permuted arrays at the server, RankORAM achieves amortized bandwidth $4\log n$ blocks and $\mathcal{O}(n + \sqrt{n}\cdot B)$ private memory, while keeping rebuilds amortized constant rounds. The key contributions are the run-length encoded historicalMembership, an oblivious shuffle variant, and an overall architecture that yields substantial memory savings (up to ~100x in experiments) with competitive bandwidth against state-of-the-art passive ORAMs. This enables practical deployment of secure outsourced storage with minimal client-side memory, making Hierarchical ORAM more scalable in real-world cloud settings.

Abstract

Access patterns to data stored remotely create a side channel that is known to leak information even if the content of the data is encrypted. To protect against access pattern leakage, Oblivious RAM is a cryptographic primitive that obscures the (actual) access trace at the expense of additional access and periodic shuffling of the server's contents. A class of ORAM solutions, known as Hierarchical ORAM, has achieved theoretically \emph{optimal} logarithmic bandwidth overhead. However, to date, Hierarchical ORAMs are seen as only theoretical artifacts. This is because they require a large number of communication round-trips to locate (shuffled) elements at the server and involve complex building blocks such as cuckoo hash tables. To address the limitations of Hierarchical ORAM schemes in practice, we introduce Rank ORAM; the first Hierarchical ORAM that can retrieve data with a single round-trip of communication (as compared to a logarithmic number in previous work). To support non-interactive communication, we introduce a \emph{compressed} client-side data structure that stores, implicitly, the location of each element at the server. In addition, this location metadata enables a simple protocol design that dispenses with the need for complex cuckoo hash tables. Rank ORAM requires asymptotically smaller memory than existing (non-Hierarchical) state-of-the-art practical ORAM schemes (e.g., Ring ORAM) while maintaining comparable bandwidth performance. Our experiments on real network file-system traces demonstrate a reduction in client memory, against existing approaches, of a factor of~$100$. For example, when {outsourcing} a database of $17.5$TB, required client-memory is only $290$MB vs. $40$GB for standard approaches.

Figures (3)

• Figure 1: A $\textsf{read}(5)$ in RankORAM. Level 2 (in red) is empty. The position function, supported by historicalMembership, is used to locate an item in a level. For example, $\texttt{position}\xspace(4)=S_1.\textsf{rank}(4)=0$. Therefore, block $4$ is located at index $\pi_1(0)=3$ in level $1$. The read operation queries the sequence of hash tables (a permuted array padded with dummies) looking for item $5$. The server returns dummy elements at levels 0 and 1. The queried item is found and returned to the client at level $3$. After the payload of the block is read, a rebuild occurs. Table $T_2$ is the smallest empty hash table. We then (obliviously) build $T_2$ on the input $5||T_0||T_1$ and mark $T_0$ and $T_1$ as empty.
• Figure 2: The size of client memory across several ORAM implementations for synthetic workloads of varying size and skew. Dashed lines correspond to the size of blockBuffer (temporary client memory needed during reshuffle) for block sizes of 64 bytes and 4 KB. Note that the size of array, HierarchicalORAM and compressedCounters are independent of the block size.
• Figure 3: Client memory vs. update time for compressedCounters on $Z\in\{20,200,2000,20000\}$. The parameter $Z$ represents the size of the dynamic array segments in the component data structures of compressedCounters.

Theorems & Definitions (25)

• Theorem 1
• Definition 1: Oblivious RAM stefanov2011towards
• Definition 2: Functionality: Array Shuffle
• Definition 3: Oblivious Algorithm
• Definition 4: Dummy shuffle functionality
• Lemma 1
• Lemma 2
• proof
• Lemma 3
• proof