1. Oblivious Parallel RAM: Improved Efficiency and Generic Constructions
Binyi Chen
UCSB
joint work with
Huijia (Rachel) Lin Stefano Tessaro

2. Cloud Computing Access pattern reveals information File 5 is important
Read file 5 ……
Client
Honest
Access pattern
reveals information
Honest but curious

3. Oblivious RAM 1
v’1 … N’
v’N’ 1 v1 … N vN
wrt (b1, v1)
Read (a)
ORAM
rd (b2) va
rd (b3)
Client
Obliviousness: Adv only know # of logical accessses given the actual accesses
Translates every logical access into actual accesses on server
Correctness: Always return/update the correct value

4. Client-server communication / block size
Efficiency
Bandwidth overhead:
Client-server communication / block size
Efficiency: communication/computation complexity of the client is significantly smaller than O(N) (e.g. polylog(N) )
N = # of logical blocks

5. ORAM in the parallel setting
Crucial for real world application
Scalable cloud storage services
Multi-processor architectures
Performance enhancement
Parallel computing
Multiple clients
Traditional ORAM does not support parallel access
Parallel program

6. Oblivious Parallel RAM [BCP’16]
read(a1)
Honest but curious C1
va1
wrt(bj,vj)
msg2
Channels
Round i …
read(am-1)
Cm-1
vam-1
rd(bi)
msg1
write(am,v’am) Cm
Adv’s view =
clients comm + data accesses
vam
Honest

7. Correctness: Obliviousness: Efficiency:
Always return/update the correct value
Obliviousness:
Only know the # of rounds of clients’ logical accesses
after observing the communication/actual accesses
Efficiency:
Small inter-client & client-server communication

8. Generic transformation
The only OPRAM [BCP’16]
w(log3N) client-server
comm overhead
Best ORAM
O(log2N) overhead
Result 1: An OPRAM with (amortized) client-server comm overhead O(log2N).
We close the gap!
ORAM & OPRAM
Equivalent?
Result 2: Every ORAM can be transformed into an OPRAM with O(logN) factor increase in complexity
Generic transformation

9. The challenge In the parallel setting: [BCP’16]: Our solution:
Multiple clients might need to access
the same storage cell simultaneously
How to coordinate obliviously?
[BCP’16]:
Expensive coordination protocol
Our solution:
Partitioning: Each client
manages disjoint partition

10. the partitioning technique Generic construction from ORAM to OPRAM
Roadmap
Starting point
Review of Path-ORAM
Efficient OPRAM:
the partitioning technique
Generic construction from ORAM to OPRAM

11. Path-ORAM [Stefanov et. al. 13]
Bucket: Z=O(1) blocks B
random L
N = # of logical blocks
Server
Position Map
B  L
………
Can be moved to
the server with
recursion
Stash
Client

12. Path-ORAM [Stefanov et. al. 13]
Should only access a
random path for each
logical access
Stash
Access B
Position Map
B  L’
………
Position Map
B  L
……… B
many blocks
Move to
the leaf?
Client L’
random L N

13. lowest possible position
Path-ORAM [Stefanov et. al. 13]
Only Flush
path L
Stash
small
Re-encrypt & put to the
lowest possible position
Fetch every block
on path L
Position Map
B  L’
……… B
Client
many blocks L’
random L N

14. Tree ORAM  Tree OPRAM Simplifying assumptions
All clients want to access a distinct logical address
All clients share the
position map locally

15. First Attempt Our solution Partitioning
M clients retrieve and flush m paths
independently, w/o coordination
Paths always overlap!!
Our solution
Partitioning C2 C1 C3

16. Partitioning Stash Simulate our first attempt:
Retrieve & flush m paths
Stash
Blocks from Stash &
upper logm levels go to stashi
if its path ends in subtree i
Client i responsible for all
blocks whose path ends in
subtree i
logm
Subtree 1
Subtree 2
Subtree 3
Subtree 4
Stash1
Stash2
Stash3
Stash4

17. How to retrieve values? Security, so far: Addresses are all distinct
Each client j is responsible for retrieving the requested blocks by traversing subtree STj
Client i sends the block-path request to client j
If Bi’s path ends in subtree j
The requested blocks’ paths in subtree j form a random subtree STj
Security, so far: Addresses are all distinct
Path-assignments are independent and random
Subtree 1
Subtree 2
Subtree 3
Subtree 4
ST1
ST2
ST3
ST4
B1?
B3?
Stash1
B2?
Stash2
Stash3
B4?
Stash4

18. How to re-insert the blocks to the new paths?
Oblivious Routing[BCP’16]
Hides L’i while obliviously sending Bi to corresponding client
Sending back the block into
the subtree that the
new path belongs to
Leaks information:
Bi’s new assignment
Efficient!
O(logm logN)
Subtree 1
Subtree 2
Subtree 3
Subtree 4

19. Client j flushes blocks in subtree STj Distinction to PathORAM
Subtree Flushing
Client j flushes blocks in subtree STj
Distinction to PathORAM
Optimize the positions within the entire sub-tree instead of an individual path
Overflow analysis
Blocks are placed at even lower position
Stash size is bounded
Tricky!

20. Removing restrictions
Multiple clients access the same (logical) block?
The access patterns coincide
Elect leader + random fake reads
[BCP’16]
Move the position map to the server by Recursion
See our paper!

21. OPRAM is not much harder!
Generic OPRAM ?
A new OPRAM
A new ORAM
OPRAM is not much harder!
Generic construction
Partitioning

22. Subtree partitioning Subtree 1 Subtree 2 Subtree 3 Subtree 4 Stash1

23. Partitioning P1 P2 P3 P4 Server Replace the
subtree partitions with ORAMs
Queueing process&
cuckoo hashing enter the game
Server O1 O2 O3 O4
ORAM1
ORAM2
ORAM3
ORAM4
Stash
Stash
Stash
Stash

24. Partitioning Wrap-up Result 2: ORAM  OPRAM
Result 1: An OPRAM with (amortized) client-server comm overhead O(log2N).
Partitioning
Result 2: ORAM  OPRAM

25. Thank you!