Dynamic Searchable Encryption with Small Client Storage Ioannis - PowerPoint PPT Presentation

Dynamic Searchable Encryption with Small Client Storage Ioannis Demertzis Javad Ghareh Chamani University of Maryland HKUST and Sharif University of Technology jgc@cse.ust.hk yannis@umd.edu Dimitrios Papadopoulos Charalampos Papamathou HKUST University of Maryland dipapado@cse.ust.hk cpap@umd.edu

What is Dynamic Searchable Encryption (DSE)? Untrusted ! "#$%& leakage: total leakage ! '%#() leakage---Search ? Cloud Client prior to query execution pattern: whether a search e.g. size of each encrypted file , query is repeated size of the encrypted index search query: keyword ! '%#() leakage---Access + pattern : encrypted document ids and files that satisfy the search query ! *&+,$# leakage : update query: keyword leakage during update execution Security (informal): The adversary does not learn anything beyond the above leakages!

Update Leakage --- Forward Privacy Untrusted ? Cloud Client High-level idea: The server should not be able to relate an update with a previous operation! Time Add (F1, w1 ) 1 Query ( w1 ) + 2 Add (F2, w1 ) 3 Server should not learn that update in timestamp 3 is for the same keyword! • Definition: A DSE scheme is forward private if the update does not reveal any information • about the involved keyword, i.e., ! "#$%&' (w) = ! (op, id)

Update Leakage --- Backward Privacy Untrusted High-level idea: The server should reveal controlled ? Cloud Client information about deleted files during search Time Add (F1, w1 ) 1 Add (F2, w1 ) 2 + Del (F1, w1 ) 3 Query ( w1 ) 4 !"#$%&(()) = { (,-, -) } !"#$%&(:) = {;iles @ABBCDEFG containing w and when they were stored} /0123$4 () ={ ), -, 5 } /0123$4 : = { timestamp of each update for w} %$67"43 : = {exactly which deletion cancels which addition } %$67"43(()) = {(), 5)}

Update Leakage --- Backward Privacy Untrusted High-level idea: The server should reveal controlled ? Cloud Client information about deleted files during search Time Add (F1, w1 ) 1 Add (F2, w1 ) 2 + Del (F1, w1 ) 3 Query ( w1 ) 4 More Leakage ℒ 345678 w = ℒ(,)<.=! w ) !"#$%"&' (&)*"#+ ,+-. − 0: !"#$%"&' (&)*"#+ ,+-. − 00: ℒ ?45678 w = ℒ(,)<.=! w , A-'"B.C(w)) !"#$%"&' (&)*"#+ ,+-. − 000: ℒ 3DEFGH w = ℒ(,)<.=! w , A-'"B.C w , =.IJ)CB(w))

Issues with Prior Forward & Backward DSE schemes Untrusted ? Cloud Client Require: The client to store an operation counter for each unique keyword !!! O(|W|) can be up to O(N) , Keyword Counter where N is the total DB size w1 3 + w2 2 O(|W|), where |W| w3 4 is the dictionary size … Synchronization issues: wM 5 if the client wants to access the encrypted DB from multiple devices

Issues with Prior Forward & Backward DSE schemes Untrusted ? Cloud Client Outsourcing the operational counters to the server requires the use of Oblivious Indexes ~ extra O(log 2 N) overhead and O(logN) rounds of interaction! Keyword Counter E.g., an Oblivious w1 3 Hash Map ( OMAP ) + w2 2 w3 4 … wM 5

Prior state-of-the-art Works & Our Contributions Search Update Search RT BP-Type ! ! Moneta O (a w logN + log 3 N) O (log 2 N) 2 Type-I O(a w + log 2 N) O(log 2 N) O(logN) Type-II OMAP + Mitra x SDa O(a w + logN) O(logN) (am.) 1 Type-II SDd O(a w + logN) O(log 3 N) 1 Type-II ORION O(n w log 2 N) O(log 2 N) O(logN) Type-I HORUS O(n w logd w logN + log 2 N) O(log 2 N) O(logN) Type-III QOS O(n w logi w + log 2 N) O(log 3 N) O(logN) Type-III N : total number of (file, keyword) pairs, a w : #updates for keyword w n w : #files currently containing keyword w , i w : #inserts for keyword w

Prior state-of-the-art Works & Our Contributions Search Update Search RT BP-Type ! ! Moneta O (a w logN + log 3 N) O (log 2 N) 2 Type-I O(a w + log 2 N) O(log 2 N) O(logN) Type-II OMAP + Mitra SDa O(a w + logN) O(logN) (am.) 1 Type-II SDd O(a w + logN) O(log 3 N) 1 Type-II ORION O(n w log 2 N) O(log 2 N) O(logN) Type-I HORUS O(n w logd w logN + log 2 N) O(log 2 N) O(logN) Type-III QOS O(n w logi w + log 2 N) O(log 3 N) O(logN) Type-III SDa and SDd have 20x-85x faster search time than MITRA QOS has 14x-16531x faster search time than HORUS

Prior state-of-the-art Works & Our Contributions Search Update Search RT BP-Type ! ! Moneta O (a w logN + log 3 N) O (log 2 N) 2 Type-I O(a w + log 2 N) O(log 2 N) O(logN) Type-II OMAP + Mitra SDa O(a w + logN) O(logN) (am.) 1 Type-II SDd O(a w + logN) O(log 3 N) 1 Type-II ORION O(n w log 2 N) O(log 2 N) O(logN) Type-I HORUS O(n w logd w logN + log 2 N) O(log 2 N) O(logN) Type-III QOS O(n w logi w + log 2 N) O(log 3 N) O(logN) Type-III QOS has better search time for deletion ratios between 40%-80%

SDa scheme Untrusted ? Cloud Client High-level idea: Organize N updates in a collection of at most log 2 N independent encrypted indexes Add (F1, w1) 4 1

SDa scheme Untrusted ? Cloud Client High-level idea: Organize N updates in a collection of at most log 2 N independent encrypted indexes Add (F4, w1) 4 1 1

SDa scheme Untrusted ? Cloud Client High-level idea: Organize N updates in a collection of at most log 2 N independent encrypted indexes If we keep adding the Add (F4, w1) number of encrypted indexes will be O(N) 4 1 1

SDa scheme Untrusted ? Cloud Client High-level idea: Organize N updates in a collection of at most log 2 N independent encrypted indexes Whenever two indexes of the same size exist, download them and merge them in a new index 4 1 1 2

*Assuming that N is a power of 2 SDa scheme Untrusted ? Cloud Client High-level idea: Organize N updates in a collection of at most log 2 N independent encrypted indexes After N-1 updates … N/2 N/4 1 Update cost = O(log 2 N) (amortized) O(log 2 N ) encrypted indexes

*Assuming that N is a power of 2 SDa scheme Untrusted ? Cloud Client High-level idea: Organize N updates in a collection of at most log 2 N independent encrypted indexes search query: keyword 1 Search cost = O(log 2 N + a w ) keyword search query: keyword 2 … N/2 N/4 1 … search query: keyword logN O(log 2 N ) encrypted indexes Intuition Forward/Backward privacy: Every index is built with a fresh key and the used static SE is response hiding!!!

SDa --- Amortized Update Cost Expensive Updates O(N) Cheap Updates O(1)

SDd scheme Untrusted ? Cloud Client High-level idea: Let’s de-amortize the SDa construction Add (F1, w1) … 4 2 1 O(log 2 N ) encrypted indexes

SDd scheme Untrusted ? Cloud Client OLDEST 1 OLDEST 2 OLDEST 4 OLDER 2 OLDER 4 OLDER 1 … OLD 1 OLD 4 OLD 2 NEW 2 NEW 4 NEW 1 1 2 4

SDd scheme Untrusted ? Cloud Client OLDEST 1 OLDEST 2 OLDEST 4 OLDER 2 OLDER 4 OLDER 1 … OLD 1 OLD 4 OLD 2 Add (F1, w1) NEW 2 NEW 4 NEW 1 1 2 4 If NEW is full move it to the first empty OLDEST, OLDER or OLD index

SDd scheme Untrusted ? Cloud Client OLDEST 1 OLDEST 2 OLDEST 4 OLDER 2 OLDER 4 OLDER 1 … OLD 1 OLD 4 OLD 2 Add (F2, w1) NEW 2 NEW 4 NEW 1 1 2 4

SDd scheme Untrusted ? Cloud Client If OLDEST i and OLDER i are full start moving the updates to the NEW i+1 index OLDEST 1 OLDEST 2 OLDEST 4 OLDER 2 OLDER 4 OLDER 1 … OLD 1 OLD 4 OLD 2 NEW 2 NEW 4 NEW 1 1 2 4

SDd scheme Untrusted ? Cloud Client For achieving Forward Privacy we need to use Oblivious MAPs (OMAP) OLDEST 1 OLDEST 2 OLDEST 4 OLDER 2 OLDER 4 OLDER 1 … OLD 1 OLD 4 OLD 2 NEW 2 NEW 4 NEW 1 1 2 4 OMAP 1 OMAP 2

SDd scheme Untrusted ? Cloud Client Search cost = O(3*log 2 N + a w ) OLDEST 1 OLDEST 2 OLDEST 4 OLDER 2 OLDER 4 OLDER 1 … OLD 1 OLD 4 OLD 2 Query(w1) NEW 2 NEW 4 NEW 1 1 2 4 OMAP cost = O(log 2 N) OMAP 1 OMAP 2 Update cost = O(log 3 N)

Prior state-of-the-art Works & Our Contributions Search Update Search RT BP-Type ! ! Moneta O (a w logN + log 3 N) O (log 2 N) 2 Type-I O(a w + log 2 N) O(log 2 N) O(logN) Type-II OMAP + Mitra SDa O(a w + logN) O(logN) (am.) 1 Type-II SDd O(a w + logN) O(log 3 N) 1 Type-II ORION O(n w log 2 N) O(log 2 N) O(logN) Type-I HORUS O(n w logd w logN + log 2 N) O(log 2 N) O(logN) Type-III QOS O(n w logi w + log 2 N) O(log 3 N) O(logN) Type-III Definition: A DSE scheme has optimal (resp. quasi-optimal) search time, if the asymptotic • complexity of Search is O(n w ) (resp. O(n w polylog(N) ).

Motivation for Optimal/Quasi-optimal Search Untrusted SDd search cost ? Cloud Client Add (F1, w1 ) = O(log 2 N + a w ) Add (F2, w1 ) … + Add (FN, w1 ) Del (F1, w1 ) … w1 is contained only in Del (F N-1 , w1 ) File N , but the result has size O(a w ) ~= O(N) Query( w1 )

QOS --- Main Idea Untrusted ? Cloud Client Idea: For each keyword w create a data structure that helps us avoid the deleted regions Next empty Add (F1, w1 ) leaf for w1 Add (F2, w1 ) Add (F5, w1 ) OMAP 1 2 3 4 5 Add (F10, w1 ) Add (F35, w1 ) Tree for keyword w1 (N=8)

QOS --- Main Idea Untrusted ? Cloud Client Idea: For each keyword w create a data structure that helps us avoid the deleted regions Returns the leaf Del (F1, w1 ) that contains F1, w1 OMAP 1 2 3 4 5 Tree for keyword w1 (N=8)

QOS --- Main Idea Untrusted ? Cloud Client Idea: For each keyword w create a data structure that helps us avoid the deleted regions Returns the leaf Del (F1, w1 ) that contains F2, w2 Del (F2, w1 ) OMAP 1 2 3 4 5 Tree for keyword w1 (N=8)