1. CS7380: Privacy Aware Computing
Oblivious RAM

2. 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

3. 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

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

5. ORAM vs PIR

6. 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

7. 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

8. 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

9. 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

10. 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)

11. 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

12. 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)

13. 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

14. 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

15. 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

16. 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.

17. 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

18. 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

19. 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

20. 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.

21. 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

22. 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)

23. 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:  (2011).

24. 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:  (2011).

25. Summary of a number of methods

26. Main improvements
Storage cost
Reshuffling
Client-server interactions

27. some recent development
Oblivious storage

28. 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.

29. End-to-end running time

30. Cost of encryption/decryption

31. Communication overhead in bytes

32. Number of communication rounds

33. Some code