3-Party Secure Computation of Oblivious RAM Sky Faber (UC Irvine) Stanislaw Jarecki (UC Irvine) Sotirios Kentros (Salem State U) Boyang Wei (UC Irvine)

3-Party Secure Computationof Oblivious RAM

Sky Faber (UC Irvine)

Stanislaw Jarecki (UC Irvine)

Sotirios Kentros (Salem State U)

Boyang Wei (UC Irvine)

June 23, 2015

ESSA, Bertinoro

Presentation Plan

1. Intro: Why Secure Computation of ORAM (SC-ORAM)?

2. Background: Secure Computation for Tree-ORAM [Shi+’11]

3. Our Protocol: 3-Party setting simplifies secure computation: 3-Party Shared Conditional OT Data-movement Logic via GC’s Data-movement itself by (inexpensive) OT’s

4. Looking Forward: Extensions, Directions, Questions

3-Party Secure Computation of (O)RAM

Input: secret-sharing of array D

secret-sharing of index x (and value v)

Output: secret-sharing of D[x] (or s-sharing of modified D)

FORAM

D

ss

sss1 s2 ..... sn ⟷ D[x]

P1 P2 ..... Pn

(x1 x2 ..... xn) ⟷ x

Secure Computation of (O)RAM Access (SC-ORAM)


P1 P2 ..... Pn

FORAM

D

(x1 x2 ..... xn) ⟷ x

s1 s2 ..... sn ⟷ D[x]

ss

ss

Compare to Oblivious RAM [GO’96,...]:

ORAM: Client & Server, D,x hidden to S, but known to ClientSC-ORAM: n Players, D,x hidden to any t out of n players

SC-ORAM = Sec.Comp of FORAM: sharing of D,x ⟶ sharing of D[x]


FORAM

D

(x1 x2 ..... xn) ⟵ x

s1 s2 ..... sn ⟶ s = D[x]

ss

ss

Compare to Multi-Server ORAM [OS’97, LO’14] :

n-Server ORAM: Single Client, no privacy against Clientn-Server Private DB: Many Clients, one query ⇒ one entry of D

1st Application: n-Server Private Database ( n-Server SPIR)*

Client


P1 P2 ..... Pn


P1 P2 ..... Pn

FORAM

FRAM-PROGRAM

D2

var stack

x,y,z ,...Instr 1,2,...

Each Instruction Computed by Standard MPC (Yao, BGW, ...)

read(x) or write(x,v)

v=D(x)

,v

2nd Application: Sec. Comp. of RAM Program [OS’97,DMN’11,GKKKMRV’12]

Sec. Comp. of RAM programs:• Inputs can be entered at polylog overhead• MPC of P(D) costs O(|instrP|) + (#r/w)*polylog(|D|))


⇒ MPC on

“big data”

secret-shared values

Generic SC-ORAM Construction [OS’97,GKKKMRV’12]

Client

1. Take (Client-Server) ORAM:

ORAM Scheme + Secure Comp. of Client’s Code ⟶ SC-ORAM

Server

MK , x EncMK(D; r)

D[x]

Recall:ORAM: 1 Server, D private, x and D[x] (and D) open to ClientSC-ORAM: >1 Server, D,x hidden to any t out of n players

EncMK(D; r’)

Client2

ORAM Scheme + Secure Comp. of Client’s Code

Server

MK2 , x2 EncMK(D; r)

v2

2. Compute Client’s Code using 2PC (/MPC)

Client1

MK1 , x1

v1

[2PC]

MK , x

D[x] = v1 ⨁ v2

P1 P2

Recall:ORAM: 1 Server, D private, x and D[x] (and D) open to ClientnC-ORAM: >1 Server, D,x hidden to any t out of n players


ORAM Scheme + Secure Comp. of Client’s Code

3. ORAM + SC give us SC-ORAM: sharing of D & x ⟶ sharing of D[x]

Client2 Server

MK2 , x2 EncMK(D; r)

v2

Client1

MK1 , x1

v1

[2PC]

P1 P2

D[x] = v1 ⨁ v2

MK , x

For efficient MPC of RAM programs we need ORAM whose Client is “Secure-Computation Friendly”


[GKKKMRV’12a]: GO’96 ORAM + Yao + PK-based SS-OPRF gadget[GKKKMRV’12b]: Tree-ORAM [Shi+’11] + Yao[WHCSS’14]: Tree-ORAM with modifications + 2PC ⇒ circuits smaller but still large, e.g. 4.6M gates for |D|=220

Our Question:Would SC-ORAM be faster given 3 players with honest

majority?

Why hope so? 3 Parties ⇒ 2 Parties with correlated randomness

Example: Oblivious Transfer with Precomputation [Bea’95]

P3

z0 , z1

z0 , z1 : random strings

c : random bit

zc , c

m0 ⨁ zπ , m1 ⨁ zπ

π = b ⨁ c

m0 , m1

P1 P2

bit b

2 Parties: OT needs PK crypto [IR’89]

3 Parties: OT needs 4 xor ops

b=0 ⇒ c=π ⇒ zc = zπ ⇒ P2 can read m0

b=1 ⇒ c=π ⇒ zc = z π ⇒ P2 can read m1


majority?

Is trading off security for efficiency a good deal?

Which system is better for some privacy-protecting application:

System #1:• needs 2 servers• security protected if only 1 out of 2 are corrupted• each query takes 10 seconds

System #2: • needs 3 servers• security protected if only 1 out of 3 are corrupted• each query takes 100 milliseconds

Who knows?

Let’s first see what efficiency we can achieve for (t,n) = (1,3)!


majority?

Our result: 3PC for SC-ORAM with (k·log3|D|) cost per access*k = security parameter

*(assuming O(1) record length: better for larger records)

[WHCSS’14] achieve same asymptotic bounds for 2PC-ORAM

But in practice the difference might be 2 orders of magnitude:

• [WHCSS’14] uses GCs with 4.6M – 13M gates for |D| = 220 to 229

- the smallest-circuit variant uses heuristic estimates for some parameter choices- 2PC GCs need O(k) public key ops for OT’s

• Our prototype runs on 3 amazon servers connected by LAN, and 70% of its CPU cost is GC’s with 69K – 233K gates for above |D|’s

+ for conservative parameters+ not counting several “easy” optimizations

Our 3P-SC-ORAM : 3PC for Tree-ORAM [Shi+’11]Basic structure of Tree-ORAM: Recursive Tree+Array Lookup

Split address space of m bits into h chunks of τ=m/h bits each N = [N1 | N2 | ... |Nh] e.g. m=30, h=6, τ=|Ni|=5Ti is a binary tree of depth di=i·τ, its nodes are buckets of length w ORAM = (T0,T1,T2,...,Th) set w =O() [or O()]

N1 L1

ServerClient

retrieve& decrypt

T1T0

2τ

L1

di·w

...

N1 L2N2

T2

L2

...

N1|N2 L3N3

and so on...

... Th

Our 3P-SC-ORAM : 3PC for Tree-ORAM [Shi+’11]Basic structure of Tree-ORAM: Recursive Tree+Array Lookup

N1 L1

ServerClient

T1T0

2τ

L1

di·w

...

N1 L2N2

T2

L2

...

N1|N2 L3N3

and so on...

... Th

Split address space of m bits into h chunks of τ=m/h bits each N = [N1 | N2 | ... |Nh] e.g. m=30, h=6, τ=|Ni|=5Ti is a binary tree of depth di=i·τ, its nodes are buckets of length w ORAM = (T0,T1,T2,...,Th) set w =O() [or O()]

Client’s code is a sequence of array look-ups...

3PC idea: ⦁ secret-share all data (Ti’s and N) between P1 & P2

• send matching entry to P3 via Shared Conditional OT

Our 3P-SC-ORAM : 3PC for Tree-ORAM [Shi+’11]3PC Tool: Conditional OT on Shared Inputs

P1 P2

P3

N* = N*1 ⨁ N*2

Ni = Ni1 ⨁ Ni

2 for all i

Li = Li1 ⨁ Li

2 for all i

Ni1 Li

1

...

......

...

Ni2 Li

2

...

......

...N1*, N*, N2*,

Li for (Ni,Li)s.t. Ni =N*




Ni Li

...

......

...

N1 L1

Nn Ln





P3

P1 P2

Ni1 Li

1

...

......

...

Ni2 Li

2

...

......

...

N* = N*1 ⨁ N*2

Ni = Ni1 ⨁ Ni

2 for all i

Li = Li1 ⨁ Li

2 for all i

Note that N* = Ni iff N*1⨁ Ni1 = N*2⨁ Ni

2

ai bi

Li for (Ni,Li)s.t. Ni =N*

Li1 ⨁ Li

2 for i s.t. ai = bi

N1*, N2*,


P3

P1 P2

Ni1 Li

1

...

......

...

Ni2 Li

2

...

......

...

N* = N*1 ⨁ N*2

Ni = Ni1 ⨁ Ni

2 for all i

Li = Li1 ⨁ Li

2 for all i

Note that N* = Ni iff N*1⨁ Ni1 = N*2⨁ Ni

2

ai bi

N1*, N2*,

Li1 ⨁ Li


ai bi

This is a String Equality Problem:2PC, Yao’s GC: O(k·n) SHAs2PC, DH-KE: O(n) Exps3PC, correlated $: 4n AESs ( cost of secure transmission

of retrieved ORAM path)


P1 P2P1 & P2 know same PRF key k

Li1 ⨁ Li


Li1

...

......

...

ai Li2

...

......

bi

...[ ={ [⨁ { [

[

ai =bi ⇒ vi =wi ⇒ Ci=Di ⇒ P3 recovers Li1⨁ Li

2

i-th PRF inputs masked by OTPiP3

Problem: P3 learns position i where the ai = bi match occurs!

(In the Tree-ORAM this means learning the searched address)

3PC Solution: P1 & P2 shift their lists by (correlated) random offset j⇒ (i,j) is a secret-sharing of the located array entry

Our 3P-SC-ORAM : 3PC for Tree-ORAM [Shi+’11]The other half: Eviction

N1 L1

ServerClient

T1T0

2τ

L1

w

...

N1

L2N2

T2

L2

...

N1|N2

L3N3

and so on...

... Th

Eviction: In retrieved path, move any array as far down towards the leaf in its “target label” L.SC-ORAM: To reduce circuit size, use constrained eviction strategy, e.g

• choose only O(1) arrays to move in each bucket• move arrays only one hop down• more complex strategies for Tree-ORAM with stash

we use these

Our 3P-SC-ORAM : 3PC for Tree-ORAM [Shi+’11]The other half: Eviction

N1 L1

ServerClient

T1T0

2τ

L1

w

...

N1

L2N2

T2

L2

...

N1|N2

L3N3

and so on...

... Th

Eviction: Move O(1) arrays one hop down towards their “target leaf” L.

2PC: Oblivious shift on all path data: GC on O(w·2τ·log2|D|) bits

3PC: (I) P3 learns movement logic (src/dst indexes) on secret-shared

path with randomly permuted buckets: GC on 2w·log|D| bits

(II) P3 assists P1,P2 data movement, using 3-Party OT ( sec.trans.)

3P Sec.Comp.-ORAM, seemingly faster than 2P SC-ORAM’s asymptotic close to 2PC SC-ORAM [WHCSS’14] constants much smaller e.g. GC with 69K vs. 4M(*) gates costs “close” (w/o GC’s) to underlying Client-Server ORAM

# rounds (+3), bandwidth and computation ( 7x)

Implementation tested on Amazon Web Servers 80ms/query for |D|=220, 105ms for |D|=228 on 3 lowest-tier (free!) servers servers located in 3 different “availability zones” (probably same LAN) off-line precomputation 8x (little attention paid to off-line...) will make it open source

Simple improvements TBD: “linear scan” on address prefix, pack D records (if small) with address postfix all GC’s use 2x2 gates: Eval can be done with single SHA op. ⇒ 2x faster

Other directions (examples): parallel access, batched access: more complex eviction circuit... use stash [SDSFRYD’13] for O(1) buckets: more complex eviction circuit... general (t,n) ? The “P1/P2 permute & P3 gets the outputs” idea doesn’t scale... secure-computation friendly multi-server ORAM, comp. to O(log n) of [LO’14] extend ORAM’s functionality (Array) to other datastructures for RAM programs

Conclusions, Extensions, Directions

Documents

3-Party Secure Computation of Oblivious RAM Sky Faber (UC Irvine) Stanislaw Jarecki (UC Irvine) Sotirios Kentros (Salem State U) Boyang Wei (UC Irvine)