New Constructions for Forward and Backward Private Symmetric Searchable Encryption

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