Verifiable Oblivious Storage Daniel Apon Jonathan Katz Elaine Shi Aishwarya Thiruvengadam University of Maryland
Motivating Scenario D database D state st st st’ ... D’ read i D[i] Client Server Motivating Scenario D database D (n blocks of B bits) D read i D state st D[i] write (w, i) st D set D[i] := w st’ ... D’
The server is malicious. The client is honest. Our goal is complete oblivious access. This means hiding the data from the server, and hiding the data-access pattern from the server. Efficiency-wise, we aim to minimize: 1) client storage, (prefer small and independent of n) 2) bandwidth, (prefer o(log(n)) overhead, per query) 3) server computation. (prefer o(n), per query)
Previous Solutions
Private Information Retrieval (PIR) Client Server Private Information Retrieval (PIR) D := Enc(D) read query st D response Typically, focuses on reads (but achieves O(1) bandwidth overhead) requires server comp linear in n = |D| semi-honest server; possibly, D stored in plaintext
Oblivious RAM (ORAM) st st’ D’ D := Enc(D) read/write query Client Server Oblivious RAM (ORAM) D := Enc(D) read/write query st D st’ D’ Server is an inert storage medium (recent exceptions: [WS08], [MBC14]) Lower Bound: Requires log(n) bandwidth overhead [GO93]
Interactively compute f(st, query,D) Client Server Secure Computation D := Enc(D) D st, query Interactively compute f(st, query,D) st’, response D’ Requires server comp and bandwidth linear in n = |D|
Our Contributions Formally define Verifiable Oblivious Storage (VOS) Simulation-based security against malicious server Efficient VOS constructions (beat all ORAMs in bandwidth) Generic compiler: ORAM-to-VOS Optimizations from Path-ORAM [SDSFRYD13] and Hierarchical-ORAM [KLO12] Applications of VOS Dynamic proofs of retrievability [CKW13]
Efficiency of our VOS constructions Path-VOS: O(log(n)) server computation O(1) bandwidth overhead (beats [GO93] lower bound) Hierarchical-VOS: Server Computation Bandwidth (for B suff. large) sublinear in n O(B) -- ie, O(1) bandwidth overhead polylog in n O(B log(n) / loglog(n)) Additionally, has Next-Read-Pattern-Hiding property
Rest of the talk VOS security definition ORAM-to-VOS construction sketch Handling malicious servers Open Questions
F VOS Security: Ideal World D OK / abort “op request” query (no input) Client Server VOS Security: Ideal World D OK / abort F “op request” query (no input) st If OK,F updates D locally. OK / abort st response / abort st’ VOS Security. Real-life execution should “simulate” this interaction.
Quick review: FHE A fully homomorphic encryption (FHE) scheme allows: Setup. Outputs (sk, pk) Encrypt. (pk, m) ciphertext [m] Decrypt. (sk, [m]) message m Eval. (C, [m ], …, [m ]) [C(m , …, m )] 1 t 1 t
VOS Construction Sketch: ORAM-to-VOS (semi-honest) Client Server VOS Construction Sketch: ORAM-to-VOS (semi-honest) I need to read/write to index [j]. [st], [ ] read/write to i st [ ] D [st] [j] index [j] index j ... st’ [st’ ],[ ] D’ [st’ ], [ ] response to i st’’
Handling malicious servers Malicious security by applying SNARKs Succinct Non-interactive ARgument of Knowledge for NP Basic properties of SNARKs: Succinct proofs: size = O(k), for security parameter k << n Time to prove “x is in L” ~ size of NP verifier circuit for L Key challenge. Ensure server uses o(n) time to build a SNARK claiming all memory is intact and fresh
Open questions and follow-up work Beat ORAM bandwidth from weaker assumptions? (E.g. no SNARKs) Practical VOS constructions? (No FHE) E.g. [MBC13] with better bounds? More expressive access control? E.g. [WNLSSH14] but with verifiability? Non-interactive RAM evaluation on encrypted data. [AFKLSZ14, GHRW14]
Thank you!