CS7380: Privacy Aware Computing Oblivious RAM

Motivation Starting from software protection Prevent from software piracy A valid method is using hardware key to protect the validity of the software; hardware key cannot be duplicated Still the memory access between the HW and SW components can leak information Attacker can deceive or skip the checking with the HW component

Basic ORAM achitecture Randomized access patterns Cannot be distinguished From a client to another ORAM Emulator Server Client - Has cache -stores probabilistically encrypted data items - Honest but curious

Oblivious RAM definition How to protect from observing memory access pattern? Memory access is probabilistic The probabilistic distribution is independent of the input

ORAM vs PIR

Trivial solution Everything is in the cache, no server access Or, scan the whole server memory each time 3. Client access the memory slot at most once, then the emulator permutates the accesses

Some theoretical results Thereom (1990): Any ORAM emulator must perform Omega(tlogt) operations to simulate t operations Thereom (2010): Any ORAM emulator must either perform Omega(tloglogt) operations or use storage Omega(N2-o(1)) on the server to simulate t operations

Practical settings o(N) client storage o(N) amortized overhead Handling repeated accesses to addresses Desired optimal ORAM O(log N) worst-case overhead O(1) client storage between operations O(1) client memory usage during operations Stateless client: no need to trace historical queries

Oblivious shuffling Pseudo Random Permutation(PRP): A key-based generated permutation cannot be distinguished from a pure random permutation P(key, {1..n}) -> a unique permutation of {1..n} Oblivious shuffling: given a permutation, the data can be shuffled with a set of ops independent of data or permutation Using oblivious sorting network

Example: oblivious sorting An array: A Operation: OSWAP(I, J), if A[i] > A[j] swap To sort 4 elements, regardless of the actual values, you can perform the following sequence of operations 1. OSWAP(1, 2), OSWAP(3, 4) 2. OSWAP(1, 3), OSWAP(2, 4) 3. OSWAP(2, 3)

Oblivious sorting Batcher: n log2 n, fast in practice AKS: n log n, slow in practice Randomized shell sort: n log n, fast in practice

Key operations Oblivious random permutation define a random mapping f: {1,2,..,n} -> {1,2,..,nlogn}. Use the tag f(i) for each item i. So that (i)=k if f(i) is the k-smallest in f(1)..f(n) Using Batcher’s Sorting Network to sort tags f(i) to achieve permutation – the sequence of access if fixed, independent of input. For each access, read the pair and rewrite them (re-encrypted) binary search over the sorted tags f(i) to find (i)

First solution: the square-root algorithm Cache N N N For each accesses, permute the first n+ memory For accessing a word, check the cached words first. If it is there, we access one of the dummy words 3. If it is not there, find the permuted location (i). 4. Write data into the cache 5. Reshuffle with new permutation key and flush cache after every reads t steps of original RAM access can be simulated with t+sqrt(N) steps ORAM N N N

Performance Let the cache and dummy memory be C, respectively Cost: 1. Scan cache, cache length j at j-th access 2. Binary search over N+C items to find pi(i) After C steps, reshuffle (N+C) items, which costs (N+C)log(N+C) Client maintains the cache

The hierarchical algorithm Each memory cell is modeled as (Vi, Xi) Vi is the location, Xi is the value Basic idea Consider the cache memory as a buffer; extend it to multiple levels of buffers Use oblivious hash function

Hierarchical ORAM Construction Use Hierarchy of Buffers (hash tables) of different sizes Server: log N “levels” for N items. Level i contains 2i buckets. Each bucket contains log N slots. Client: PRP key Ki for each level. PRP Keys 1 K1 2 K2 3 = data K3 4 K4 O. Goldreich and R. Ostrovsky. Software protection and simulation on oblivious RAMs. Journal of the ACM, 43(3), 1996.

initially load data into the lowest buckets For each level If (V, X) is already found, randomly pick a bucket to access Otherwise, check the next level bucket Put (V, X) to the 1st level (may cause overflowing to the lower levels). If the first i levels are full, move all 1 to i levels to i+1 levels and empty the first i levels

Reading Check the bucket h_i(V) from each level i Only one real match Remaining are dummy entries dummy real dummy dummy dummy dummy Client Server

Writing Chose a new hash for level i+1, Server (before) Client shuffle values Server (after) Writing Chose a new hash for level i+1, Shuffle consecutively filled levels. Write into next unfilled level. Clear the source levels

Hierarchical ORAM Construction (cont’d) When level i overflows: pick new PRP key for levels i and i+1, then shuffle data in levels i and i+1 together into level i+1 using new key Algorithm: Oblivious hashing* Aim: Hash keys into buckets. The advisory cannot get information about the load factor of each bucket and the mapping between keys and buckets. Shuffle buffers with frequency inversely proportional to their sizes Level i is shuffled after every 2i ops. *: Ostrovsky, Rafail. "Efficient computation on oblivious RAMs." Proceedings of the twenty-second annual ACM symposium on Theory of computing. ACM, 1990.

Security H_i(V) is never used twice Once found, moved to the 1st level Level overflow happens, then moved to the next level with a new hash function

Cost analysis time cost: Storage cost (N log N) Each level cost O(log N), total log N levels Cost per access: O(log2N) shuffling cost: O(Nlog3N) – worst case average O(log3 N) Storage cost (N log N)

Partition ORAM Subdivide the O-RAM into much smaller partitions the operations performed on the partitions can be handled much more efficiently. Each partition is a full functional ORAM scheme Stefanov, Emil, Elaine Shi, and Dawn Song. "Towards practical oblivious RAM.” arXiv preprint arXiv:1106.3652 (2011).

Partition ORAM (cont’d) Position map to track which partition each item resides in Cache read/updated blocks in a random partition’s cache slot Evict items in cache slots periodically to its ORAM partition Stefanov, Emil, Elaine Shi, and Dawn Song. "Towards practical oblivious RAM.” arXiv preprint arXiv:1106.3652 (2011).

Summary of a number of methods

Main improvements Storage cost Reshuffling Client-server interactions

some recent development http://www.emilstefanov.net/Research/ObliviousRam/ Oblivious storage

Performance Evaluation A paper in VLDB16 Oblivious RAM:A Dissection and Experimental Evaluation Two machines: client and server Client: 6GB main memory Server: 95GB main memory and 1TB hard disk Connected by 1Gbps Ethernet Storage engine: MongoDB on the server AES encryption + SHA2 hash provided by CryptoPP Implement different ORAM schemes in a unified testbed.

End-to-end running time

Cost of encryption/decryption

Communication overhead in bytes

Number of communication rounds

Some code https://github.com/InitialDLab/SEAL-ORAM