Oblivious RAM

An Oblivious RAM (ORAM) simulator is a compiler that transforms algorithms in such a way that the resulting algorithms preserve the input-output behavior of the original algorithm but the distribution of memory access pattern of the transformed algorithm is independent of the memory access pattern of the original algorithm. The definition of ORAMs is motivated by the fact that an adversary can obtain nontrivial information about the execution of a program and the nature of the data that it is dealing with, just by observing the pattern in which various locations of memory are accessed during its execution. An adversary can get this information even if the data values are all encrypted. The definition suits equally well to the settings of protected programs running on unprotected shared memory as well as a client running a program on its system by accessing previously stored data on a remote server. The concept was formulated by Oded Goldreich in 1987.

Definition

A Turing machine (TM), the mathematical abstraction of a real computer (program), is said to be oblivious if for any two inputs of the same length, the motions of the tape heads remain the same. Pippenger and Fischer proved that every TM with running time $T(n)$ can be made oblivious and that the running time of the oblivious TM is $O(T(n)\log T(n))$. A more realistic model of computation is the RAM model. In the RAM model of computation, there is a CPU that can execute the basic mathematical, logical and control instructions. The CPU is also associated with a few registers and a physical random access memory, where it stores the operands of its instructions. The CPU in addition has instructions to read the contents of a memory cell and write a specific value to a memory cell. The definition of ORAMs capture a similar notion of obliviousness memory accesses in this model.

Informally, an ORAM is an algorithm at the interface of a protected CPU and the physical RAM such that it acts like a RAM to the CPU by querying the physical RAM for the CPU while hiding information about the actual memory access pattern of the CPU from the physical RAM. In other words, the distribution of memory accesses of two programs that make the same number of memory accesses to the RAM are indistinguishable from each other. This description will still make sense if the CPU is replaced by a client with a small storage and the physical RAM is replaced with a remote server with a large storage capacity, where the data of the client resides. It is an extension of the notion of Oblivious Turing machines to the RAM model of computation.

The following is a formal definition of ORAMs. Let $\Pi$ denote a program requiring a memory of size $n$ when executing on an input $x$. Suppose that $\Pi$ has instructions for basic mathematical and control operations in addition to two special instructions ${\mathsf {read}}(l)$ and ${\mathsf {write}}(l,v)$, where ${\mathsf {read}}(l)$ reads the value at location $l$ and ${\mathsf {write}}(l,v)$ writes the value $v$ to $l$. The sequence of memory cell accessed by a program $\Pi$ during its execution is called its memory access pattern and is denoted by ${\tilde {\Pi }}(n,x)$.

A polynomial-time algorithm, $C$ is an Oblivious RAM (ORAM) compiler with computational overhead $c(\cdot )$ and memory overhead $m(\cdot )$, if $C$ given $n\in N$ and a deterministic RAM program $\Pi$ with memory-size $n$ outputs a program $\Pi _{0}$ with memory-size $m(n)\cdot n$ such that for any input $x$, the running-time of $\Pi _{0}(n,x)$ is bounded by $c(n)\cdot T$ where $T$ is the running-time of $\Pi (n,x)$, and there exists a negligible function $\mu$ such that the following properties hold:

• Correctness: For any $n\in \mathbb {N}$ and any string $x\in \{0,1\}^{*}$, with probability at least $1-\mu (n)$, $\Pi (n,x)=\Pi _{0}(n,x)$.
• Obliviousness: For any two programs $\Pi _{1},\Pi _{2}$, any $n\in \mathbb {N}$ and any two inputs, $x_{1},x_{2}\in \{0,1\}^{*}$ if $|{\tilde {\Pi }}_{1}(n,x_{1})|=|{\tilde {\Pi }}_{2}(n,x_{2})|$, then ${{\tilde {\Pi }}_{1}}'(n,x_{1})$ is $\mu$-close to ${{\tilde {\Pi }}_{2}}'(n,x_{2})$ in statistical distance, where ${\Pi _{1}}'=C(n,\Pi _{1})$ and ${\Pi _{2}}'=C(n,\Pi _{2})$.

Note that the above definition uses the notion of statistical security. One can also have a similar definition for the notion of computational security.

History of ORAMs

ORAMs were introduced by Goldreich et al. where in the key motivation was stated as software protection from an adversary who can observe the memory access pattern (but not the contents of the memory).

The main result in this work is that there exists an ORAM compiler that uses $O(n)$ server space and incurs a running time overhead of $2^{O({\sqrt {\log n\log \log n}})}$ when making a program that uses $n$ memory cells oblivious. This work initiated a series of works in the construction of oblivious RAMs that is going on till date. There are several attributes that need to be considered when we compare various ORAM constructions. The most important parameters of an ORAM construction are the amounts of client storage, the amount of server storage and the time overhead in making one memory access. Based on these attributes, the construction of Kushilevitz et al. is the best known ORAM construction. It achieves $O(1)$ client storage, $O(n)$ server storage and $o(\log ^{2}n)$ access overhead.

Another important attribute of an ORAM construction is whether the access overhead is amortized or worst-case. Several of the earlier ORAM constructions have good amortized access overhead guarantees, but have $\Omega (N)$ worst-case access overheads. Some of the ORAM constructions with polylogarithmic worst-case computational overheads are. The constructions of were for the random oracle model, where the client assumes access to an oracle that behaves like a random function and returns consistent answers for repeated queries. They also noted that this oracle could be replaced by a pseudorandom function whose seed is a secret key stored by the client, if one assumes the existence of one-way functions. The papers were aimed at removing this assumption completely. The authors of also achieve an access overhead of $O(\log ^{3}n)$, which is just a log-factor away from the best known ORAM access overhead.

While most of the earlier works focus on proving security computationally, there are more recent works that use the stronger statistical notion of security.

One of the only known lower bounds on the access overhead of ORAMs is due to Goldreich et al. They show a $\Omega (\log {n})$ lower bound for ORAM access overhead, where $n$ is the data size. There is also a conditional lower bound on the access overhead of ORAMs due to Boyle et al. that relates this quantity with that of the size of sorting networks.

A simple ORAM scheme

A statistically secure ORAM compiler constructed by Chung and Pass will be described in the following with the proof of its correctness. The compiler on input $n$ and a program $\Pi$ with its memory requirement $n$, outputs an equivalent oblivious program $\Pi '$.

If the input program $\Pi$ uses $r$ registers, the output program $\Pi '$ will need $r+n/{\alpha }+{\text{poly}}\log {n}$ registers, where $\alpha >1$ is a parameter of the construction. $\Pi '$ uses $O(n{\text{ poly}}\log n)$ memory and its (worst-case) access overhead is $O({\text{poly}}\log n)$.

The ORAM compiler is very simple to describe. Suppose that the original program $\Pi$ has instructions for basic mathematical and control operations in addition to two special instructions ${\mathsf {read}}(l)$ and ${\mathsf {write}}(l,v)$, where ${\mathsf {read}}(l)$ reads the value at location $l$ and ${\mathsf {write}}(l,v)$ writes the value $v$ to $l$. The ORAM compiler, when constructing $\Pi '$, simply replaces each ${\mathsf {read}}$ and ${\mathsf {write}}$ instructions with subroutines ${\mathsf {Oread}}$ and ${\mathsf {Owrite}}$ and keeps the rest of the program the same. It may be noted that this construction can be made to work even for memory requests coming in an online fashion.

The ORAM compiler substitutes the read and write instructions in the original program with subroutines Oread and Owrite.

Memory organization of the oblivious program

The program $\Pi '$ stores a complete binary tree $T$ of depth $d=\log(n/\alpha )$ in its memory. Each node in $T$ is represented by a binary string of length at most $d$. The root is the empty string, denoted by $\lambda$. The left and right children of a node represented by the string $\gamma$ are $\gamma 0$ and $\gamma 1$ respectively. The program $\Pi '$ thinks of the memory of $\Pi$ as being partitioned into blocks, where each block is a contiguous sequence of memory cells of size $\alpha$. Thus, there are at most $\lceil n/\alpha \rceil$ blocks in total. In other words, the memory cell $r$ corresponds to block $b=\lfloor r/\alpha \rfloor$.

At any point of time, there is an association between the blocks and the leaves in $T$. To keep track of this association, $\Pi '$ also stores a data structure called position map, denoted by $Pos$, using $O(n/\alpha )$ registers. This data structure, for each block $b$, stores the leaf of $T$ associated with $b$ in $Pos(b)$.

Each node in $T$ contains an array with at most $K$ triples. Each triple is of the form $(b,Pos(b),v)$, where $b$ is a block identifier and $v$ is the contents of the block. Here, $K$ is a security parameter and is $O({\text{poly}}\log n)$.

Description of the oblivious program

The program $\Pi '$ starts by initializing its memory as well as registers to $\perp$. Describing the procedures ${\mathsf {Owrite}}$ and ${\mathsf {Oread}}$ is enough to complete the description of $\Pi '$. The procedure ${\mathsf {Owrite}}$ is given in Algorithm~\ref{Owrite}. The inputs to the procedure are a memory location $l\in [n]$ and the value $v$ to be stored at the location $l$.

Here, we give a high level overview of the ${\mathsf {Owrite}}$ sub-routine. The task of the ${\mathsf {FETCH}}$ phase is to look for the location $l$ in the tree $T$. Suppose pos is the leaf associated with the block containing location $l$. For each node $N$ in $T$ on the path from root to $pos$, this procedure goes over all triples in $N$ and looks for the triple corresponding to the block containing $l$. If it finds that triple in $N$, it removes the triple from $N$ and writes back the updated state of $N$. Otherwise, it simply writes back the whole node $N$. In the next phase, it updates the block containing $l$ with the new value $v$, associates that block with a freshly sampled uniformly random leaf of the tree, writes back the updated triple to the root of $T$. The last phase, which is called ${\mathsf {FLUSH}}$, is an additional operation to release the memory cells in the root and other higher internal nodes. Specifically, the algorithm chooses a uniformly random leaf $pos^{*}$ and then tries to push down every node as much as possible along the path from root to $pos^{*}$. It aborts outputting an overflow if at any point some bucket is about to overflow its capacity.

The procedure ${\mathsf {Oread}}$ is similar to ${\mathsf {Owrite}}$ and we do not give a full pseudo-code for that. For the ${\mathsf {Oread}}$ procedure, the input is just a memory location $l\in [n]$ and it is almost the same as ${\mathsf {Owrite}}$. In the ${\mathsf {FETCH}}$ stage, if it does not find a triple corresponding to the location $l$, it returns $\perp$ as the value at location $l$. In the ${\mathsf {PUT\_BACK}}$ phase, it will write back the same block that it read to the root, after associating it with a freshly sampled uniformly random leaf.

Oblivious simulation

Now that we have define both $RAM$ and $ObliviousRAM$, it is left only specify what is meant by an $Oblivious$ $Simulation$of an arbitrary $RAM$ program on an $ObliviousRAM$, our notion of simulation is minimal one: it only requires that both machines compute the same function. The $RAM$ simulation presented in the sequel are simulations in a much stronger sense: specifically, they are “on-line”. On the other hand, an oblivious simulation of a $RAM$ is not merely a simulation by an oblivious RAM. In addition, we require that inputs having identical running-time on the original $RAM$, maintain identical running-time on the Oblivious $RAM$, so that the obliviously condition applies to them in a non-vacuous manner. For the sake of simplicity, we present only definition for oblivious simulation of deterministic RAMs.

Definition of $Oblivious$ $Simulation$ of $RAM$: Given $probabilistic-RAM'_{k'}$, and $RAM_{k}$, we say that a $probabilistic-RAM'_{k'}$, obliviously simulates $RAM_{k}$ if the following conditions hold.

1. The $probabilistic-RAM'_{k'}$ simulates $RAM_{k}$ with probability 1. In other words, for every input y, and every choice of an oracle function $f$, the output of $oracle-RAM'_{k'}$, on input $y$ and access to oracle $f$, equals the output of $RAM_{k}$ on input $y$.

2. The $probabilistic-RAM'_{k'}$ is oblivious. (We stress that we refer here to the access pattern of $RAM'_{K'}$ on a fixed input and a randomly chosen oracle function.)

3. The random variable representing the running-time of $probabilistic-RAM'_{k'}$ is fully specifies by the running-time $RAM_{k}$ (on input $y$).(Here again we refer to the behavior of $RAM'_{K'}$ on fixed input and a randomly chosen oracle function.)

Hence, the access pattern in an oblivious simulation (which is a random variable defined over the choice of the random oracle) has a distribution depending only on the running-time of the original machine. Namely, let ${{\mathcal {\bar {A}}}^{k}(y)}$ denote the access pattern in an oblivious simulation of the computation of $RAM_{k}$ on input $y$. Then, ${{\mathcal {\bar {A}}}^{k}(y_{1})}$ and ${{\mathcal {\bar {A}}}^{k}(y_{2})}$ are identically distributed if the running-time of $RAM_{k}$ on these inputs (i,e., $y_{1}$ and $y_{2}$) is identical.

We note that in order to define oblivious simulations of $oracle-RAMs$, we have to supply the simulating $RAM$ with two oracles (i.e., one identical to the oracle of the simulated machine and the other being a random oracle). Besides, these two oracles can be incorporated into one, but in any case the formulation will be slightly more cumbersome.

We need to define the overhead of oblivious simulation.

Definition of Overhead of Oblivious Simulations:

Given $probabilistic-RAM'_{k'}$, $RAM_{k}$, and suppose that a $probabilistic-RAM'_{k'}$, obliviously simulates the computation of $RAM_{k}$, and let y: $g:\Bbbk \mapsto \Bbbk$ be a function. We say that the overhead of the simulation is at most $g$ if, for every $y$, the expected running-time of $RAM'_{K'}$ on input $y$ is bounded above by $g(T)\cdot T$, where $T$ denoted the running-time of $RAM_{k}$ on input $y$.

Solution

Computer model construction

• Two parts: Memory and Processors
• Internal memory of process: $c\log \left\vert Memory\right\vert$
• Interaction: $fetch(address)$, $store(address,value)$
• Processor has access to random oracle
• Computation starts with a program and an input in $Memory$
• One step: fetch one cell - update value and Processor memory - store

Oblivious execution

We want to hide orders of access to cells of $Memory$, thus we define Oblivious Execution as for all programs of size $m$ working in time $t$, an order of fetch/store address is the same. The weaker requirement is for all programs of size $m$ working in time $t$, order of fetch/store address has the same distribution.

Basic solution

Naive simulation

1. We store encrypted pairs(address, value) in memory cells
2. For every fetch/store we scan through all memory. If the address is wrong, re-encrypt and store the data, otherwise, do the job which means encrypt and store the results.

Cost of simulation: $tm$ time, $m$ memory

Square root solution

We need to protect order of accesses and number of accesses. Because $Memory=MainPart(m+{\sqrt {m}})\mid Shelter{\sqrt {m}}$, the idea comes that: firstly we divide computation in epochs of ${\sqrt {m}}$ steps each. Then on each original step, we make one fetch to the $MainPart$ and scan through all the $Shelter$.

Square Root simulation

1. Store input in the $MainPart$
2. Add ${\sqrt {m}}$ dummy cells to the $MainPart$
3. for every epoch of ${\sqrt {m}}$ steps
   1. Permute all cells in the $MainPart$(using permutation $\pi$ from random oracle)
   2. For each process($i$) scan through the $Shelter$. If $i-th$ element is not founded, fetch it from $\pi (i)$, otherwise fetch next dummy cell
   3. Update(Obliviously) the $MainPart$ using the $Shelter$ values

Cost of simulation: $t{\sqrt {m}}$ time, $m+2{\sqrt {m}}$ memory

Buffer solution

Buffer solution refers to Oblivious Hash Table. Suppose we have a memory of initial program: $(a_{1},v_{1}),...,(a_{m},v_{m})$

1. Take a hash function h : $[1...m]\rightarrow [1...m]$
2. Prepare $m\times \log m$ table
3. Put $(a_{i},v_{i})$ to a random free call in $h(a_{i})-th$ column
4. The chance of overflow is less than $1/m$

Simulation:

1. Construct (obliviously) a hash table
2. For every step $fetch(i)$ of initial program
   1. Scan through $h(i)$ column
   2. Update the target cell

Cost of simulation : $t\log m$ time, $m\log m$ memory

Hierarchical construction

Data structure : Oblivious Data Structure

• $k-buffer$ = table $2^{k}\times k$
• Hierarchical Buffer Structure = $1-buffer,...,\log t-buffer$
• Initial position : input in last buffer, all others are empty

Hierarchical simulation

Simulation of processing cell $i$:

1. Scan through $1-buffer$
2. For every j scan through $h(i,j)$-th column in $j-buffer$
3. Put the updated value to the first buffer

Periodic rehashing

Refreshing the data structure:

1. Every $2^{j-1}$ steps unify $j$-th and $j-1$-th buffer
2. Delete doubles
3. Using new hash function put all data to $j-th$ level

Invariant: For every moment of time for every $I$ buffers from 1 to $I$ all together contain at most $2^{I-1}$ elements.

Cost of simulation: $O(t\cdot (\log t)^{3})$ time, $O(m\cdot (\log m)^{2})$ memory

Omitted details: realization of oblivious hashing and random oracle

Trivial solution

The trivial solution is, for every read or write operation, read from and write to every single element in the array, only performing a meaningful action for the address specifies in the single operation.

The trivial solution of Oblivious Algorithm(S) will scan through the entire array for each operation and then consult every element in RAM. For sequence S, such that |S| = m, perform on an array of size n, the running time complexity of the Oblivious-Algorithm(S) is Ω(m*n). Therefore, when n is incredibly large, this algorithm is actually inefficient.

Sorting network

When allowing for parallel comparators, we can trivially sort an array in O(n) time. But there are much better sorting networks. Optimally, there is a way to getting O(n logn) comparisons in O(logn) parallel time.

References

• J. Bentley (2000), Programming Pearls 2nd Edition. Addison-Wesley, Inc. ISBN 0-201-65788-0
• Eyal Kushilevitz, Steve Lu, and Rafail Ostrovsky. On the (in) security of hash-based oblivious ram and a new balancing scheme. In Proceedings of the twenty-third annual ACM-SIAM symposium on Discrete Algorithms, pages 143–156. SIAM, 2012.
• Knuth, D. E. (1973). The Art of Computer Programming, volume 3: Sorting and Searching.Addison Wesley.
• Oded Goldreich, Rafail Ostrovsky. Software protection and simulation on oblivious RAMs. Published in Journal of the ACM (JACM), volume 43 issue 3, May 1996, page 431-473.
• Yuqun Chen, Ramarathnam Venkatesan, Matthew Cary, Ruoming Pang, Saurabh Sinha, and Mariusz H. Jakubowski. Oblivious hashing: A stealthy software integrity verification primitive. Microsoft research, 2002.

See also

• Oblivious data structure
• Cache-oblivious algorithm