3-Party Secure Computation of 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) F ORAM D ss s 1 s s n ⟷ D[x] P 1 P P n (x 1 x x n ) ⟷ x Secure Computation of (O)RAM Access (SC-ORAM)

P 1 P P n F ORAM D (x 1 x x n ) ⟷ x s 1 s s n ⟷ D[x] ss Compare to Oblivious RAM [GO’96,...] : ORAM: Client & Server, D,x hidden to S, but known to Client SC-ORAM: n Players, D,x hidden to any t out of n players SC-ORAM = Sec.Comp of F ORAM : sharing of D,x ⟶ sharing of D[x]

Secure Computation of (O)RAM Access (SC-ORAM) F ORAM D (x 1 x x n ) ⟵ x s 1 s s n ⟶ s = D[x] ss Compare to Multi-Server ORAM [OS’97, LO’14] : n-Server ORAM: Single Client, no privacy against Client n-Server Private DB: Many Clients, one query ⇒ one entry of D 1 st Application: n-Server Private Database (  n-Server SPIR)* Client SC-ORAM = Sec.Comp of F ORAM : sharing of D,x ⟶ sharing of D[x] P 1 P P n

Secure Computation of (O)RAM Access (SC-ORAM) P 1 P P n F ORAM F RAM-PROGRAM D2D2 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 2 nd 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(|instr P |) + (#r/w)*polylog(|D|)) SC-ORAM = Sec.Comp of F ORAM : sharing of D,x ⟶ sharing of D[x] ⇒ 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, xEnc MK (D; r) D[x] Recall: ORAM: 1 Server, D private, x and D[x] (and D) open to Client SC-ORAM: >1 Server, D,x hidden to any t out of n players Enc MK (D; r’)

Client 2 ORAM Scheme + Secure Comp. of Client’s Code Server MK 2, x 2 Enc MK (D; r) v2v2 2. Compute Client’s Code using 2PC (/MPC) Client 1 MK 1, x 1 v1v1 [2PC] MK, x D[x] = v 1 ⨁ v 2 P1P1 P2P2 Recall: ORAM: 1 Server, D private, x and D[x] (and D) open to Client nC-ORAM: >1 Server, D,x hidden to any t out of n players Generic SC-ORAM Construction [OS’97,GKKKMRV’12]

ORAM Scheme + Secure Comp. of Client’s Code 3. ORAM + SC give us SC-ORAM: sharing of D & x  sharing of D[x] Client 2 Server MK 2, x 2 Enc MK (D; r)v2v2 Client 1 MK 1, x 1 v1v1 [2PC] P1P1 P2P2 D[x] = v 1 ⨁ v 2 MK, x For efficient MPC of RAM programs we need ORAM whose Client is “Secure-Computation Friendly” Generic SC-ORAM Construction [OS’97,GKKKMRV’12] [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|=2 20

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] P3P3 z 0, z 1 z 0, z 1 : random strings c : random bit z c, c m 0 ⨁ z π, m 1 ⨁ z  π π = b ⨁ c m 0, m 1 P1P1 P2P2 bit b 2 Parties: OT needs PK crypto [IR’89] 3 Parties: OT needs 4 xor ops b=0 ⇒ c= π ⇒ z c = z π ⇒ P 2 can read m 0 b=1 ⇒ c= π ⇒ z c = z  π ⇒ P 2 can read m 1

Our Question: Would SC-ORAM be faster given 3 players with honest 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)!

Our Question: Would SC-ORAM be faster given 3 players with honest majority? Our result: 3PC for SC-ORAM with (k · log 3 |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| = 2 20 to 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 = [N 1 | N 2 |... |N h ] e.g. m=30, h=6, τ=|N i |=5 N1N1 L1L1 Server Client retrieve & decrypt T1T1 T0T0 2τ2τ L1L1 d i ·w... N1N1 L2L2 N2N2 T2T2 L2L2 N 1 |N 2 L3L3 N3N3 and so on T h

Our 3P-SC-ORAM : 3PC for Tree-ORAM [Shi+’11] Basic structure of Tree-ORAM: Recursive Tree+Array Lookup N1N1 L1L1 Server Client T1T1 T0T0 2τ2τ L1L1 d i ·w... N1N1 L2L2 N2N2 T2T2 L2L2 N 1 |N 2 L3L3 N3N3 and so on T h Split address space of m bits into h chunks of τ=m/h bits each N = [N 1 | N 2 |... |N h ] e.g. m=30, h=6, τ=|N i |=5 Client’s code is a sequence of array look-ups... 3PC idea: ⦁ secret-share all data (T i ’s and N) between P 1 & P 2 send matching entry to P 3 via Shared Conditional OT

Our 3P-SC-ORAM : 3PC for Tree-ORAM [Shi+’11] 3PC Tool: Conditional OT on Shared Inputs P1P1 P2P2 P3P3 N * = N * 1 ⨁ N * 2 N i = N i 1 ⨁ N i 2 for all i L i = L i 1 ⨁ L i 2 for all i Ni1Ni1 Li1Li1... Ni2Ni2 Li2Li2 N 1 *, N *, N 2 *, L i for (N i,L i ) s.t. N i =N * Client’s code is a sequence of array look-ups... 3PC idea: ⦁ secret-share all data (T i ’s and N) between P 1 & P 2 send matching entry to P 3 via Shared Conditional OT NiNi LiLi... N1N1 L1L1 NnNn LnLn

Our 3P-SC-ORAM : 3PC for Tree-ORAM [Shi+’11] 3PC Tool: Conditional OT on Shared Inputs Client’s code is a sequence of array look-ups... 3PC idea: ⦁ secret-share all data (T i ’s and N) between P 1 & P 2 send matching entry to P 3 via Shared Conditional OT P3P3 P1P1 P2P2 Ni1Ni1 Li1Li1... Ni2Ni2 Li2Li2 N * = N * 1 ⨁ N * 2 N i = N i 1 ⨁ N i 2 for all i L i = L i 1 ⨁ L i 2 for all i Note that N* = N i iff N * 1 ⨁ N i 1 = N * 2 ⨁ N i 2 a i b i L i for (N i,L i ) s.t. N i =N * L i 1 ⨁ L i 2 for i s.t. a i = b i N 1 *, N 2 *,

Our 3P-SC-ORAM : 3PC for Tree-ORAM [Shi+’11] 3PC Tool: Conditional OT on Shared Inputs P3P3 P1P1 P2P2 Ni1Ni1 Li1Li1... Ni2Ni2 Li2Li2 N * = N * 1 ⨁ N * 2 N i = N i 1 ⨁ N i 2 for all i L i = L i 1 ⨁ L i 2 for all i Note that N* = N i iff N * 1 ⨁ N i 1 = N * 2 ⨁ N i 2 a i b i N 1 *, N 2 *, L i 1 ⨁ L i 2 for i s.t. a i = b i aiai bibi This is a String Equality Problem: 2PC, Yao’s GC: O(k·n) SHAs 2PC, DH-KE: O(n) Exps 3PC, correlated $: 4n AESs ( cost of secure transmission of retrieved ORAM path)

Our 3P-SC-ORAM : 3PC for Tree-ORAM [Shi+’11] 3PC Tool: Conditional OT on Shared Inputs P1P1 P2P2 P 1 & P 2 know same PRF key k L i 1 ⨁ L i 2 for i s.t. a i = b i Li1Li1... aiai Li2Li2 bibi a i =b i ⇒ v i =w i ⇒ C i =D i ⇒ P 3 recovers L i 1 ⨁ L i 2 i-th PRF inputs masked by OTP i P3P3 Problem: P 3 learns position i where the a i = b i match occurs! (In the Tree-ORAM this means learning the searched address) 3PC Solution: P 1 & P 2 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 N1N1 L1L1 Server Client T1T1 T0T0 2τ2τ L1L1 w... N1N1 L2L2 N2N2 T2T2 L2L2 N 1 |N 2 L3L3 N3N3 and so on T h 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 N1N1 L1L1 Server Client T1T1 T0T0 2τ2τ L1L1 w... N1N1 L2L2 N2N2 T2T2 L2L2 N 1 |N 2 L3L3 N3N3 and so on T h 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 τ ·log 2 |D|) bits 3PC: (I) P 3 learns movement logic (src/dst indexes) on secret-shared path with randomly permuted buckets: GC on 2w·log|D| bits (II) P 3 assists P 1,P 2 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|=2 20, 105ms for |D|=2 28 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 “P 1 /P 2 permute & P 3 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