Transcript [slides]

Oblivious Parallel RAM:
Improved Efficiency and Generic
Constructions
Binyi Chen
UCSB
joint work with
Huijia (Rachel) Lin Stefano Tessaro
Cloud Computing
File 5 is
important
Read file 5
……
Read file 5
Client
Honest
……
Read file 5
Access pattern
reveals information
Honest but curious
Oblivious RAM
1
v ’1
…
…
1
v1
…
…
…
…
N’
v’N’
N
vN
wrt (b1, v1)
Read (a)
ORAM
Client
va
rd (b2)
rd (b3)
Obliviousness: Adv only know # of logical accessses given the
Translates
everyAlways
logicalreturn/update
access into actual
on server
Correctness:
the accesses
correct value
actual accesses
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
Multiple clients
– Scalable
cloud storage services
Traditional
ORAM
does
not support
– Multi-processor
architectures
parallel access
• Performance enhancement
Parallel program
– Parallel computing
Oblivious Parallel RAM [BCP’16]
read(a1)
Honest but curious
C1
va1
msg2
wrt(bj,vj)
Channels
…
Round i
read(am-1)
Cm-1
vam-1
msg1
rd(bi)
write(am,v’am)
vam
Cm
Honest
Adv’s view =
clients comm + data accesses
Correctness:
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
The only OPRAM [BCP’16]
w(log3N) client-server
comm overhead
Best ORAM
O(log2N) overhead
Result 1: An OPRAM with (amortized) clientserver comm overhead O(log2N).
Result 2: Every ORAM can be transformed into
an OPRAM with O(logN) factor increase in
complexity
The challenge
In the parallel setting:
Multiple clients might need to access
the same storage cell simultaneously
How to coordinate obliviously?
[BCP’16]:
Our solution:
Expensive coordination
protocol
Partitioning: Each client
manages disjoint partition
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
Can be moved to
the server with
recursion
Position
Map
BL
………
Stash
Client
Server
Path-ORAM
[Stefanov et. al. 13]
Should only access a
random path for each
logical access
B
Access B
Stash
Position
Map
many blocks
B  LL’
………
Move to
the leaf?
Client
L’
random
L
N
Path-ORAM
Only Flush
path L
[Stefanov et. al. 13]
Stash
Re-encrypt
& put
to the
Fetch every
block
lowest on
possible
path Lposition
Position
Map
B
B  L’
………
Client
many blocks
L’
random
L
N
small
All clients want to access a
distinct logical address
All clients share the
position map locally
First Attempt
M clients retrieve and flush m paths
independently, w/o coordination
Paths always
overlap!!
Our solution
Partitioning
C2
C1
C3
Partitioning
Simulate our first attempt:
Retrieve & flush m paths
Stash
Blocks
from Stashfor
& all
Client
i responsible
upper
logm
levels
go to
stash
blocks
whose
path
ends
in i
if its path subtree
ends in subtree
i
i
Subtree 1
Stash1
Subtree 2
Stash2
Subtree 3
Stash3
logm
Subtree 4
Stash4
How to retrieve values?
The
requested
Client
blocks’
the Addresses
block-path
pathsfor
inretrieving
subtree
request
to client
a random
j
EachSecurity,
clienti jsends
isso
responsible
the
requested
far:
are
allj form
distinct
If Bi’sby
path
subtree
ends
in
STsubtree
subtree
j j random
blocks
traversing
ST
j
Path-assignments
are
independent
and
Subtree 1
Subtree 2
Subtree 3
Subtree 4
ST1
ST2
ST3
ST4
B1?
Stash1
B2?
Stash2
B3?
Stash3
B4?
Stash4
How to re-insert the blocks
to the new paths?
L’1 B1
L’2 B2
L’3 B3
L’4 B4
Sending
the block into
Oblivious
Routing
[BCP’16]
Leaksback
information:
subtree
thatsending
the
Hides L’i while
obliviously
Bi to
Bthe
i’s new assignment
new path belongs
to
corresponding
client
Subtree
1
Subtree
2
Subtree
3
Efficient!
O(logm logN)
Subtree
4
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
Tricky!
Blocks are placed at even lower position
Stash size is bounded
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
Generic OPRAM
A new
OPRAM
A new
ORAM
Subtree partitioning
Subtree
1
Stash1
Subtree
2
Stash2
Subtree
3
Stash3
Subtree
4
Stash4
Partitioning
P1
Replace the
subtree partitions
with ORAMs
O1
ORAM1
Stash
P2
O2
P3Queueing
process&
cuckoo hashing
enter the game
ORAM2
Stash
O3
ORAM3
Stash
P4
Server
O4
ORAM4
Stash
Wrap-up
Result 1: An OPRAM with (amortized) clientserver comm overhead O(log2N).
Result 2: ORAM  OPRAM
Thank you!
https://eprint.iacr.org/2015/1053.pdf