backward secure dynamic searchable symmetric encryption
play

Backward Secure Dynamic Searchable Symmetric Encryption with - PowerPoint PPT Presentation

Backward Secure Dynamic Searchable Symmetric Encryption with Efficient Updates Hyung Tae Lee Chonbuk National University, Republic of Korea June 14, 2019@ Workshop on Modern Trends in Cryptography Table of contents 1. Introduction 2.


  1. Backward Secure Dynamic Searchable Symmetric Encryption with Efficient Updates Hyung Tae Lee Chonbuk National University, Republic of Korea June 14, 2019@ Workshop on Modern Trends in Cryptography

  2. Table of contents 1. Introduction 2. Background: Previous Results for Forward/Backward DSSE 3. Our Construction 4. Conclusion & Future Works 1

  3. Introduction

  4. Motivations (from the Viewpoint of My Research Direction) Private keyword search on encrypted data is one of key factors for secure cloud computing. Server Server Server Database server Server Server An encrypted database D V A 1 A 2 A τ · · · Store D · · · Query Q / Q a 1 a 2 a τ v · · · Client · · · a result set R / R (Fully) Homomorphic encryption may resolve this problem, but it is not practical yet: ◮ 1.5 ms for equality test of two encrypted 64-bit integers in amortized time ◮ 29 ms for comparison of two encrypted 64-bit integers in amortized time Searchable encryption may be another candidate for providing a practical solution to this problem. (1 − 10 µ s /1 keword search on 1 data) 2

  5. Dynamic Searchable Symmetric Encryption A dynamic searchable symmetric encryption (DSSE) is an encryption scheme that ◮ allows data updates (addition/deletion), ◮ supports comparisons between an encrypted keyword and a tag. Consist of the following algorithms ◮ Setup(1 λ ) → (ST , msk; EDB) ◮ Addition(msk , ST , f ; EDB) → (ST ′ ; EDB ′ ) ◮ Deletion(msk , ST , f ; EDB) → (ST ′ ; EDB ′ ) ◮ Search(msk , ST , w ; EDB) → (ST ′ ; I ) 3

  6. Additional Security Requirements in the Dynamic Setting Forward security: No leak any information about newly added data against an adversary who has information for previous queries Backward security: No leak any information about the data added and deleted between two successive queries on the same keyword 4

  7. Background: Previous Results for Forward/Backward DSSE

  8. Previous Results I: Sophos ( Σ o φ o σ ) Bost presented a DSSE achieving forward security. (ACM CCS 2016) Exploited a trapdoor permutation π to update an encryption key after search queries 1. Compute and use ST i +1 = π SK (ST i ) to add a new data 2. Give ST c as a token for keyword search Realized a trapdoor permutation using RSA, but it is too expensive. 5

  9. Previous Results II: Janus Bost, Minaud and Ohrimenko formalized a backward secure DSSE and presented a generic construction of a backward secure DSSE using a forward secure DSSE. (ACM CCS 2017) Design strategy ◮ Assume there is a forward secure DSSE and a secure puncturable encryption (PE). ◮ Operate two databases EDB add and EDB del for addition and deletion, respectively ◮ Tag: an output of a function evaluating at index and keyword ◮ Store a ciphertext ( ct , t ) = Enc( pk , ind , t ) for PE at EDB add ◮ Store a punctured key at the tag t at EDB del Forward security: Achieved by updating an encryption key for PE Backward security: Achieved by using PE They realized PE by employing the Green and Miers scheme, but it is quite expensive. 6

  10. Previous Results III: Janus++ Sun et al. proposed a new symmetric PE (SPE) from using puncturable PRF. They proposed Janus++, the improved version of Janus, using the proposed SPE. (ACM CCS 2018) The proposed SPE PE = (KG , Enc , Dec , Punc) ◮ KG(1 λ , d ): Choose a random key sk 0 and set msk = ( sk 0 , d ). ◮ Enc(msk , m , t ): 1. Compute sk i = H ( sk i − 1 , i ) for all 1 ≤ i ≤ d . 2. Compute k = ⊕ d i =0 F ( sk i , t ) and ct = SE . Enc( k , m ). 3. Output ( ct , t ). ◮ Punc( SK i − 1 , t ′ i ): 1. Compute psk i = F.Punc( sk i − 1 , t ′ i ) and sk i = H ( sk i − 1 , i ). 2. Set msk i = ( sk i , d ). 3. Output SK i = ( msk i , psk 1 , · · · , psk i ). ◮ Dec( SK i , ct , t ): 1. If i < d , compute sk ℓ = H ( sk ℓ − 1 , ℓ ) for i ≤ ℓ ≤ d . 2. Evaluate k ′ = ⊕ i s =1 F.Eval( psk s , t ) ⊕ d ℓ = i F ( sk ℓ , t ). 3. Recover m ′ = SE . Dec( k ′ , ct ). 7

  11. Previous Results IV: Dual Dictionary and Forward Secure DSSE Kim et al. proposed a new database structure, dual dictionary, which can be seen as a combination of forward and inverted indexes. (ACM CCS 2017). · · · id 1 w 1 w 3 w 5 · · · w 1 id 2 id 2 · · · id 2 w 1 w 2 w 3 · · · w 2 id 1 · · · id 1 id 2 id 3 · · · id 3 w 3 w 7 w 8 w 3 . . . . . . . . . . . . � Forward index � � Inverted index � ◮ Pros: Addition/Deletion ◮ Pros: Keyword search ◮ Cons: Addition/Deletion ◮ Cons: Keyword search Label 1 Label 2 Value H( T id 1 , 1) H( T w 1 , 1) Enc( T w 1 , id 1 ) . . . H( T id 3 , 1) H( T w 7 , 1) Enc( T w 7 , id 3 ) . . . � Dual dictionary � 8

  12. Previous Results IV: Dual Dictionary and Forward Secure DSSE (Cont.) On top of the dual dictionary structure, they presented a new forward secure DSSE by updating an encryption key after search queries. There is no known result about backward secure DSSE using the dual dictionary. A naive application of Janus/Janus++ does not take an advantage of the dual dictionary. 9

  13. Our Construction

  14. Overview of Our Construction Goal: Design a new backward secure DSSE using the dual dictionary structure Conclusion: Achieve the goal by using small modifications of Janus/Janus++ Building blocks ◮ Dual dictionary structure ◮ Puncturable encryption (PE) How to achieve forward/backward security ◮ Forward security: Update an encryption key for PE after search queries ◮ Backward security: Use a puncturable encryption 10

  15. Concrete Description I: Setup Algorithm 1 Setup(1 λ ) → (ST; EDB) Notation. F , G , H : PRFs with key k F , k ′ F , k G , k H PE := (KG , Enc , Dec , Punc): puncturable encryption Idx : { 0 , 1 } ∗ → I for an index set I 1: EDB ← ∅ /* encrypted DB */ 2: ST ← ∅ /* private state */ 3: msk ← ( k F , k G , k H ) /* master key */ F : To generate keys for computing label function H G : To generate a tag of index and keyword for PE H : To compute labels for index and keyword, respectively 11

  16. Concrete Description II-1: Addition @ Client Algorithm 2 Addition(msk , ST , f ; EDB) → (ST ′ ; EDB ′ ) @ Client Require: msk , f , ST Ensure: ST ′ , D 1: id ← Idx( f ) and k id ← F ( k F , id ) 2: cnt id ← 0 , D ← ∅ 3: W ← { w | w ∈ f } = { w 1 , . . . , w n } 4: while W � = ∅ do $ 5: w ← − W and k w ← F ( k ′ F , w ) 6: W ← W \{ w } 7: if ST[ w ] . Kwd = ⊥ then ( EK w , SK (0) w ) ← PE . KG(1 λ , d ) 8: 9: ucnt w ← 0 ST ← ( w , EK w , ucnt w , ( SK (0) 10: w , t 0 )) 11: else 12: ( EK w , ucnt w ) ← ST[ w ] . (Ekey , Ucnt) 13: cnt id ← cnt id + 1 , ucnt w ← ucnt w + 1 14: label id ← H ( k id , cnt id ) , label w ← H ( k w , ucnt w ) t w ,id ← G ( k G , w � id ) , pval ( id ) ← PE . Enc( EK w , id, t w ,id ) 15: w D ← D ∪ { (label id , label w , pval ( id ) 16: ) } w 17: ST[ w ] . Ucnt ← ucnt w 18: Send D to the server Dual dictionary: Label id Label w pval 12

  17. Concrete Description II-2: Addition @ Server Algorithm 3 Addition(msk , ST , f ; EDB) → (ST ′ ; EDB ′ )@Server Require: D , EDB Ensure: EDB ′ 1: EDB ′ ← EDB 2: for each (label id , label w , pval ( id ) ) ∈ D do w EDB ′ ← (label id , label w , pval ( id ) ) 3: w 13

  18. Concrete Description III-1: Deletion @Client Algorithm 4 Deletion(msk , ST , f ; EDB) → (ST ′ ; EDB ′ ) @Client Require: msk , f , ST Ensure: k id , ST ′ 1: id ← Idx( f ) and k id ← F ( k F , id ) 2: Send k id to the server 3: W ← { w | w ∈ f } = { w 1 , . . . , w n } 4: for each w ∈ W do t w ,id ← G ( k G , w � id ) 5: SK ( i − 1) ← ST[ w ] . Psk , SK ( i ) w ← PE . Punc( SK ( i − 1) , t w ,id ) 6: w w ST[ w ] . Psk ← SK ( i ) w , ST[ w ] . Tag ← ST[ w ] . Tag ∪ { t w ,id } 7: 14

  19. Concrete Description III-2: Deletion @Server Algorithm 5 Deletion(msk , ST , f ; EDB) → (ST ′ ; EDB ′ ) @Server Require: k id , EDB Ensure: EDB ′ 1: cnt id ← 1 2: while true do label id ← H ( k id , cnt id ) 3: if EDB[label id ] � = ⊥ then 4: EDB ← EDB \{ EDB[label id ] } 5: cnt id ← cnt id + 1 6: else return EDB 7: 8: EDB ′ ← EDB Label id Label w Pval . . . H( k id 3 , 1) H( k w 7 , 1) PE . Enc( · · · ) . . . � When deleting id 3 � 15

  20. Concrete Description IV-1: Search @Client Algorithm 6 Search(msk , ST , w ; EDB) → (ST ′ ; I ) @ Client Require: msk , w , ST Ensure: ST ′ , τ w 1: if ST[ w ] . Kwd = ⊥ then return ∅ 2: k w ← F ( k ′ F , w ) 3: ( ucnt w , ( SK w , T w )) ← ST[ w ] . (Ucnt , Psk , Tag) 4: τ w ← ( SK w , T w , k w , ucnt w ) 5: Send τ w to the server 0 )) ← PE . KG(1 λ , d ) 6: ( EK ′ w , ( SK w ′ , t ′ 7: ucnt w ← 0 ′ 8: ST ← ( w , EK ′ w , ucnt w , ( SK w , t ′ 0 )) 16

  21. Concrete Description IV-2: Search @Server Algorithm 7 Search(msk , ST , w ; EDB) → (ST ′ ; I ) @Server Require: τ w , EDB Ensure: I ⊂ I , EDB ′ 1: I ← ∅ , i ← 1 2: while i ≤ ucnt w do 3: label w ← H ( k w , i ) if EDB[label w ] � = ⊥ then 4: 5: pval w = ( ct w , t w ) ← EDB[label w ] . Pval 6: id ← PE . Dec( SK w , ct w , t w ) 7: NewR ← NewR ∪ { ( id , t w ) } 8: i ← i + 1 9: OldR ← EDB cache [ k w ] 10: OldR ← OldR \ { ( id , t w ) | ( id , t w ) ∈ OldR ∧ t w ∈ T w } 11: Res ← NewR ∪ OldR 12: EDB cache [ k w ] ← Res 13: Send Res to the client Label id Label w Pval H( k id 1 , 1) H( k w 1 , 1) PE . Enc( · · · ) . . . 17

Recommend


More recommend