1 / 16

Verifiable Oblivious Storage

Verifiable Oblivious Storage. Daniel Apon Jonathan Katz Elaine Shi Aishwarya Thiruvengadam. University of Maryland. Client. Server. Motivating Scenario. D. database D (n blocks of B bits). D. read i. D. state st. D [ i ]. write ( w, i ). D. st. set

cheller
Download Presentation

Verifiable Oblivious Storage

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Verifiable Oblivious Storage Daniel Apon Jonathan Katz Elaine ShiAishwarya Thiruvengadam University of Maryland

  2. Client Server Motivating Scenario D database D (n blocks of B bits) D read i D state st D[i] write (w, i) D st set D[i] := w D’ st’ ...

  3. Our goal is complete oblivious access. This means • hiding the data from the server, and • hiding the data-access pattern from the server. The server is malicious. The client is honest. Efficiency-wise, we aim to minimize: 1) client storage, (prefer small and independentof n) 2) bandwidth, (prefer o(log(n)) overhead, per query) 3) server computation. (prefer o(n), per query)

  4. Previous Solutions

  5. 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

  6. 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]

  7. 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|

  8. 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]

  9. Efficiency of our VOS constructions • Path-VOS: • O(log(n)) server computation • O(1) bandwidth overhead (beats [GO93] lower bound) • Hierarchical-VOS: • Additionally, has Next-Read-Pattern-Hiding property

  10. Rest of the talk • VOS security definition • ORAM-to-VOS construction sketch • Handling malicious servers • Open Questions

  11. Client Server VOS Security: Ideal World OK/abort D “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.

  12. 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 )] t t 1 1

  13. 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’’

  14. 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

  15. 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]

  16. Thank you!

More Related