sophos and diane
play

Sophos and Diane Searchable Symmetric Encryption with (Very) Low - PowerPoint PPT Presentation

Sophos and Diane Searchable Symmetric Encryption with (Very) Low Overhead Raphael Bost, Brice Minaud RHUL ISG seminar, November 24th 2016 Plan 1. Symmetric Searchable Encryption. 2. Leakage and Forward-Privacy. 3. Sophos and Diane schemes. 4.


  1. Sophos and Diane Searchable Symmetric Encryption with (Very) Low Overhead Raphael Bost, Brice Minaud RHUL ISG seminar, November 24th 2016

  2. Plan 1. Symmetric Searchable Encryption. 2. Leakage and Forward-Privacy. 3. Sophos and Diane schemes. 4. Proof Models.

  3. Symmetric Searchable Encryption Search queries Adversary! Server with Adversary? Client database ‣ Client stores encrypted database on server. ‣ Client can perform search queries. ‣ Privacy of data and queries is retained. Example: private email storage. ‣ Dynamic SSE: also allows update queries.

  4. Symmetric Searchable Encryption Two databases: ‣ Document database. Encrypted documents d i for i ≤ D . ‣ (Reverse) Index database DB. Pairs ( w , i ) for each keyword w and each document index i such that d i contains w . DB = {( w , i ) : w ∈ d i }

  5. Symmetric Searchable Encryption ‣ Search ( w ) query: Retrieve DB( w ) = { i : w ∈ d i }. ‣ Update ( w , i ) query: Add ( w , i ) to DB. After getting DB( w ) from a search query, the client is likely to retrieve documents in DB( w ) from the document database. ‣ This leaks DB( w ).

  6. Is leakage necessary? Leaking DB( w ) for search queries is nearly unavoidable. In a nutshell, ORAM approaches either leak it or are very ine ffi cient [Nav15]. Note: still feasible in some restricted settings.

  7. How bad is leakage? • Assume a priori knowledge of frequency and correlation of keywords. ▻ IKK12 (NDSS'12) and CGPR15 (CSS'15) show how to identify (most) keywords. • Assume the adversary can inject arbitrary documents. ▻ CGPR15 and ZKP16 (USENIX Sec'16) show how to immediately identify searched keywords.

  8. File injection w 0 w 0 w 1 w 1 w 2 w 2 w 3 w 3 w 4 w 4 w 5 w 5 w 6 w 6 w 7 w 7 ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ File A File A ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ File B File B ✔ ✔ ✔ ✔ ✔ ✔ ✔ ✔ File C File C Idea of ZKP16: for W keywords, inject log( W ) files containing W/2 keywords each as above. When Search ( w ) is searched, DB( w ) directly leaks w . E.g. DB( w ) contains A, B but not C, then w = w 2 .

  9. Adaptive file injection Proposed countermeasure : at most T keywords/file. ▻ Attacke requires (K/T) ・ log(T) injections. Adaptive version: enhancement of frequency attack: ▻ Adaptive attack requires less injections, e.g. log(T), assuming some prior knowledge. This last attack uses update leakage: Most SE schemes leak if a newly inserted document matches a previous search query. ▻ Need forward privacy : oblivious updates.

  10. Forward Privacy Forward privacy : Update queries leak nothing. • The encrypted database can be securely built online. • Only one existing scheme SPS14 (NDSS'14): ORAM-like construction. Ine ffi cient updates. Large client storage.

  11. Sophos ( Σ o φ o ς ) and Diane Sophos: introduced at CCS'16 [Bost16]: • Dynamic, forward-private SSE scheme. • Low overhead. • Simple. Diane: work-in-progress.

  12. Sophos ( Σ o φ o ς ) Fix a keyword w . Let i k be the k-th document containing w . ... UT 0 UT 1 UT 2 UT k DB stores enc( i k ) at position UT k .

  13. Sophos ( Σ o φ o ς ) Fix a keyword w . Let i k be the k-th document containing w . π π π π ... ST 0 ST 1 ST 2 ST k ... π -1 π -1 π -1 π -1 ... H H H H UT 0 UT 1 UT 2 UT k DB stores enc( i k ) at position UT k . Let π be a trapdoor permutation (e.g. RSA).

  14. Sophos ( Σ o φ o ς ) Fix a keyword w . Let i k be the k-th document containing w . π π π π ... ST 0 ST 1 ST 2 ST k ... π -1 π -1 π -1 π -1 ... H H H H ks 0 UT 1 ks 1 UT 2 ks 2 UT 0 UT k ks k DB stores enc( i k ) = i k ⊕ ks k at position UT k . Let π be a trapdoor permutation (e.g. RSA).

  15. Sophos ( Σ o φ o ς ) Fix a keyword w . Let i k be the k-th document containing w . π π π π ... ST 0 ST 1 ST 2 ST k ST k ... π -1 π -1 π -1 π -1 ... H H H H ks 0 UT 1 ks 1 UT 2 ks 2 UT 0 UT k ks k UT k ‣ Update ( w , i ): send (UT k , i ⊕ ks k ). ‣ Search ( w ): send ST k .

  16. Client Storage Sophos assumes the client stores c w = |DB( w )| for every keyword. ▻ Client-side storage: W ・ log(D), with: W = #keywords D = #documents This is enough! Everything else is generated pseudo-randomly. Nice feature of RSA: x d · d ··· d = x d c mod φ ( N ) mod N Makes computing ST c faster.

  17. Summary of Sophos Computation Communication Client FS Storage Update Search Update Search O (1) O (c w ) O (1) O (c w ) O (1) ✘ [CJJ+14] O (log 2 N ) O (c w +log 2 N ) O (log N ) O (c w +log N ) O (N a ) ✓ [SPS14] O (1) O (c w ) O (1) O (c w ) O (Wlog(D)) ✓ Sophos optimal Leakage: • L Search ( w ) = DB( w ) and content of previous search and update queries on w . • L Update ( w , i ) = ∅ . Forward-private!

  18. Summary of Sophos • Provable forward-privacy. • Very simple. • E ffi cient search (IO bounded). • Asymptotically e ffi cient update (optimal). In practice, very low update throughput (20x slower than prior work).

  19. Diane π π π π ... ST 0 ST 1 ST 2 ... ST c π -1 π -1 π -1 π -1 H H H H ks 0 UT 1 ks 1 UT 2 ks 2 UT 0 UT c ks c

  20. Diane R w ... H H H H ST 0 ST 1 ST 2 ST m ... H H H H ks 0 UT 1 ks 1 UT 2 ks 2 UT 0 UT m ks m

  21. Diane R w ... ST 0 ST 1 ST 2 ST m ... ks 0 UT 1 ks 1 UT 2 ks 2 UT 0 UT m ks m ‣ Update ( w , i ): send (UT c , i ⊕ ks c ). ‣ Search ( w ): send covering set of ST 0 , ..., ST c .

  22. Diane R w e.g. k=0... ... ST 0 ST 1 ST 2 ST m ... ks 0 UT 1 ks 1 UT 2 ks 2 UT 0 UT m ks m ‣ Update ( w , i ): send (UT c , i ⊕ ks c ). ‣ Search ( w ): send covering set of ST 0 , ..., ST c .

  23. Diane R w e.g. k=1... ... ST 0 ST 1 ST 2 ST m ... ks 0 UT 1 ks 1 UT 2 ks 2 UT 0 UT m ks m ‣ Update ( w , i ): send (UT c , i ⊕ ks c ). ‣ Search ( w ): send covering set of ST 0 , ..., ST c .

  24. Diane R w e.g. k=3... ... ST 0 ST 1 ST 2 ST m ... ks 0 UT 1 ks 1 UT 2 ks 2 UT 0 UT m ks m ‣ Update ( w , i ): send (UT c , i ⊕ ks c ). ‣ Search ( w ): send covering set of ST 0 , ..., ST c . The size of the covering set is logarithmic in c.

  25. Tweaking the Tree The tree does not have to be balanced. ▻ e.g. if most keywords have ≤ 5 matches: R w ... ... UT m ks m UT 4 ks 4 UT 5 ks 5 UT 3 ks 3 UT 2 ks 2 ...the first 5 covering sets have size 1. UT 0 ks 0 UT 1 ks 1

  26. Tweaking the Tree The tree does not have to be balanced. ▻ e.g. if most keywords have ≤ 5 matches: R w ... ... UT m ks m UT 4 ks 4 UT 5 ks 5 UT 3 ks 3 UT 2 ks 2 ...the first 5 covering sets have size 1. UT 0 ks 0 UT 1 ks 1

  27. Tweaking the Tree The tree does not have to be balanced. ▻ e.g. if most keywords have ≤ 5 matches: R w ... ... UT m ks m UT 4 ks 4 UT 5 ks 5 UT 3 ks 3 UT 2 ks 2 ...the first 5 covering sets have size 1. UT 0 ks 0 UT 1 ks 1

  28. Tweaking the Tree The tree does not have to be balanced. ▻ e.g. if most keywords have ≤ 5 matches: R w ... ... UT m ks m UT 4 ks 4 UT 5 ks 5 UT 3 ks 3 UT 2 ks 2 ...the first 5 covering sets have size 1. UT 0 ks 0 UT 1 ks 1

  29. Tweaking the Tree The tree does not have to be balanced. ▻ e.g. if most keywords have ≤ 5 matches: R w ... ... UT m ks m UT 4 ks 4 UT 5 ks 5 UT 3 ks 3 UT 2 ks 2 ...the first 5 covering sets have size 1. UT 0 ks 0 UT 1 ks 1

  30. Tweaking the Tree The tree does not have to be balanced. ▻ e.g. if most keywords have ≤ 5 matches: R w ... ... UT m ks m UT 4 ks 4 UT 5 ks 5 UT 3 ks 3 UT 2 ks 2 ...the first 5 covering sets have size 1. UT 0 ks 0 UT 1 ks 1 The tree also does not have to be finite (no last leaf).

  31. Communication Complexity O(1) Sophos Search : O(c w ) O(log c w ) Diane Search : O(c w ) However... O(1) for Sophos is 2000+ bits (RSA). O(log c w ) for Diane is 128 log c w bits.

  32. Computational Complexity Computation Communication Client FS Storage Update Search Update Search O (1) O (c w ) O (1) O (c w ) O (Wlog(D)) ✓ Sophos O (1) O (c w ) O (1) O (c w ) O (Wlog(D)) ✓ Diane Asymptotically equivalent to Sophos. Practically much faster: removes RSA bottleneck. Overall, "crypto" overhead is negligible: IO and memory accesses dominate.

  33. Security model Security is parametrized by a leakage function. Search ( w ) leaks L Search ( w ). Update ( w , i ) leaks L Update ( w , i ). Intuition: the adversary should learn no more than this leakage.

  34. Simulation-based security Adversary Server Client (challenger) The adversary can: ‣ adaptively trigger Search ( w ) and Update ( w , i ) queries. ‣ observe all tra ffi c and server storage. The adversary attempts to distinguish a real and ideal world.

  35. Simulation-based security REAL Adversary ✓ Actual Client Server In the real world, the server receives the actual queries and implements the actual scheme.

  36. Simulation-based security Ideal Adversary L Client Simulator simulated output In the ideal world, the server receives only the leakage of queries and attempts to mimick a real server. L - security: there exists a simulator s.t. no adversary can distinguish the two worlds with significant probability.

  37. Random oracle Assume the adversary triggers: Update ( w 0 , 0 ) Update ( w 1 , 1 ) Update ( w' , 2 ) Search ( w' ) Depending on w' = w 0 or w' = w 1 , di ff erent tree, UT's for w' will have to be in a tree with either w 0 or w 1 . ...but the simulator has to commit before knowing. ▻ ROM required.

Recommend


More recommend