1 / 16

Optimizing Forward and Backward Private Symmetric Searchable Encryption

This paper introduces new constructions for Dynamic Searchable Encryption (DSE), focusing on Forward Privacy (FP) and Backward Privacy (BP) aspects. It explores efficient DSE schemes that incorporate leakage information, ensuring server privacy during updates and searches. The work delves into ORION, MITRA, and HORUS schemes, highlighting their contributions and optimizations for enhanced efficiency while maintaining privacy. The proposal of a solution using an Oblivious Map (OMAP) to achieve better search time while safeguarding privacy and presenting experimental results on various encryption schemes are discussed.

roesch
Download Presentation

Optimizing Forward and Backward Private Symmetric Searchable Encryption

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. New Constructions for Forward and Backward PrivateSymmetric Searchable Encryption • Javad Ghareh-Chamani • Hong Kong University of Science and Technology • & Sharif University of Technology • Dimitrios Papadopoulos • Hong Kong University of Science and Technology • CharalamposPapamanthou • University of Maryland • RasoolJalili • Sharif University of Technology

  2. What is Dynamic Searchable Encryption (DSE)? DB • DSE = (Setup, Search, Update) Setup EDB EDB Update Search keyword w keyword w Plaintext Result Encrypted Result

  3. DSE Leakage • To achieve efficient DSE schemes we allow the server to learn some additional information called Leakage Update Leakage () : e.g. Type Setup Leakage () : e.g. |DB| Search Leakage () : e.g. Access Pattern & Search Pattern Setup EDB Update Search • Access pattern: The ids of the files that contain the searched keyword • Search pattern:Whether a search query is repeated and when Encrypted Response keyword w keyword w Plaintext Result

  4. Leakage During Update: Forward Privacy(FP) [CM’05][SPS’14] • High level idea: The server should not be able to relate an update with previous operations Time 1 add,F1,w1 2 search w1 All for w1 3 add,F2,w1 • Server should not learn that the update during time 3 is for the same keyword • Definition: 𝐴 D𝑆𝑆𝐸 𝑠𝑐ℎ𝑒𝑚𝑒 𝑖𝑠 𝑓𝑜𝑟𝑤𝑎𝑟𝑑 𝑝𝑟𝑖𝑣𝑎𝑡𝑒 𝑖𝑓 𝑡ℎ𝑒 𝑢𝑝𝑑𝑎𝑡𝑒 𝑞𝑢𝑒𝑟𝑖𝑒𝑠 𝑑𝑜 𝑛𝑜𝑡 𝑟𝑒𝑣𝑒𝑎𝑙 𝑎𝑛𝑦 𝑖𝑛𝑓𝑜𝑟𝑚𝑎𝑡𝑖𝑜𝑛 𝑎𝑏𝑜𝑢𝑡 𝑡ℎ𝑒 𝑖𝑛𝑣𝑜𝑙𝑣𝑒𝑑 𝑘𝑒𝑦𝑤𝑜𝑟𝑑

  5. Leakage After Deletions: Backward Privacy(BP) [BMO’17] • High level idea: Search queries should not reveal any information about indexes of deleted files More Leakage Time 1 add, F1, w1 {(F2,2)} 2 add, F2, w1 3 ={1,2,3} del, F1, w1 4 search w1 and when they were stored} timestamp of each update for w} }

  6. Previous Works & Our Contributions • ORION • the first FP and BP DSE scheme with quasi-optimal search time () • MITRA • very efficient FP and BP-II: 145-253x faster search than Fides (and faster than Janus and Dianadel) • simple and lightweight construction only from PRF • HORUS (details in the paper) • optimized version of ORION: more efficient search and less interaction • but with increased leakage (BP-III) N: total number of (file,keyword) pairs |W|: number of distinct keywords dw: the number of deleted entries for waw: total number of updates nw: the number of files currently containing w

  7. MITRA • Forward Privacy: • During update the server only sees (,) • semantically secure encryption • PRF output (from different inputs) • Backward Privacy Type-II: • During search the server only sees a number of PRF evaluations he has seen before Update(add,w1,F1) Update(del,w1,F1) Update(add,w2,F1) Update(add,w1,F2) Search(w1) K2 K1 F2 EDB(Dictionary) Cnt w1 w2 w1 w1 w3 w2 … w2 w1 1 2 3 0 0 0 1 0 1

  8. ORION (motivation) • Search computation time of currently existing schemes grows with total number of updates for keyword w () • Is it possible to propose a FP & BP scheme with computation time that depends only on the number of existing entries for w? • Known to be possible for FP only [SPS’14] • Yes, ORION and HORUS are the first schemes to achieve that Search for F2 F3 F4 F3 F2 F1 F4

  9. ORION (main idea) • Key Idea: Do some extra works during updates to save time during searches • This destroys forward privacy because during deletion the server accesses the same locations as with previous insertions • How can we resolve this? • Use an Oblivious Map to implement the EDB Dictionary EDB(Dictionary) Cnt=1 Cnt=2 Cnt=3 Cnt W1 3 F1 F2 F3 W2 1 W2 3 W2 2 F1 F4 F3

  10. ORAM Tree Oblivious MAP 6 ….. ….. • We use the Oblivious MAP(OMAP) of [WNL+’14] • OMAP structure is based on AVL tree and hides the type and content of any sequence of operations performed • It uses PathORAM[SDS+’14] for storing the AVL tree nodes • The client only needs to store the position of the AVL root node in PathORAM • accesses to PathORAM to access a node in an AVL tree of N nodes 2 9 7 12 ….. 4 ID, ORAMPos Children IDs, Children ORAMPos 6 6 6 9 9 7 7

  11. ORAM Tree Oblivious MAP (batch access) 6 ….. ….. Problem: During search for w ORION must retrieve nodes rounds of interaction Key Idea: We observe that with the OMAP of [WNL+14] we can retrieve nodes “in batch” • Number of roundtrips: AVL tree height = • For privacy: number of retrieved nodes at level is Min() 2 9 7 12 ….. 4 6 6 AVL Tree 9 6 7 9 4 Retrieve node 2 and 7 2 2 12 2 7 4

  12. Experimental Setup • We implemented MITRA, ORION, HORUS, FIDES[BMO’17], and Dianadel[BMO’17] in C++ • Crypto++ and OpenSSL for cryptographic operations • AES-NI enabled • We measured search time, update time, and communication size • Synthetic dataset of 1K to 10M records • Experiments using AWS machines • single-machine to measure computation time • over WAN to measure impact of communication • setup with database on RAM and on SSD Storage • Our code is available here: https://github.com/jgharehchamani/SSE

  13. Experimental Evaluation (single machine) • MITRA is 145-253x faster than FIDES (BP-II) (e.g. 0.8 ms for 100 result size) • also faster than Dianadel which is BP-III! • MITRA is 86-232x faster than FIDES in update time (e.g. 32 μs for 1 add/del) • MITRA communication size is <1.5x of FIDES Search Computation Time(left) and Communication Size(right) for |DB|=1M |W|=10K After 10% random deletions

  14. Experimental Evaluation (over WAN) • AWS client in Germany and AWS server in Ireland • WAN with 21ms latency • MITRA is 1.3-51x faster than FIDES depending on the result size • All our schemes are fully parallelizable while FIDES is inherently sequential • current experiment runs on a single core

  15. Experimental Evaluation (effect of deletions) • ORION and HORUS search computation time should be unaffected by the number of previous deletions • Performed variable percentages of deletions for a fixed result size • search over a DB with 100K records Result Size=100

  16. Conclusion • MITRA • Fastest existing FP & BP scheme (145-253x faster search than Fides) • Simple and lightweight construction only from PRF • ORION & HORUS • The first FP and BP DSE scheme with quasi-optimal search time Thank you! Questions? https://github.com/jgharehchamani/SSE

More Related