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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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!

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!

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

Subtree partitioning Subtree 1 Subtree 2 Subtree 3 Subtree 4 Stash1

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

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

Thank you! https://eprint.iacr.org/2015/1053.pdf