backward secure dynamic searchable symmetric encryption ...€¦ · backward secure dynamic...

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. Background: Previous Results for Forward/Backward DSSE

3. Our Construction

4. Conclusion & Future Works

1

Introduction

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

Server Server

Database

server

An encrypted database D

V A1 A2 · · · Aτ

· · ·v a1 a2 · · · aτ

· · · Client

Store D

Query Q/Q

a result set R/R

(Fully) Homomorphic encryption may resolve this problem, but it is not practicalyet:

I 1.5 ms for equality test of two encrypted 64-bit integers in amortized time

I 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

Dynamic Searchable Symmetric Encryption

A dynamic searchable symmetric encryption (DSSE) is an encryption scheme that

I allows data updates (addition/deletion),

I supports comparisons between an encrypted keyword and a tag.

Consist of the following algorithms

I Setup(1λ) → (ST,msk; EDB)

I Addition(msk, ST, f ; EDB) → (ST′; EDB′)

I Deletion(msk, ST, f ; EDB) → (ST′; EDB′)

I Search(msk, ST,w ; EDB) → (ST′; I )

3

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

Background: Previous Results for

Forward/Backward DSSE

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 STi+1 = πSK (STi ) to

add a new data

2. Give STc as a token for keyword search

Realized a trapdoor permutation using RSA, but it is too expensive.

5

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

I Assume there is a forward secure DSSE and a secure puncturable encryption (PE).

I Operate two databases EDBadd and EDBdel for addition and deletion, respectively

I Tag: an output of a function evaluating at index and keyword

I Store a ciphertext (ct, t) = Enc(pk, ind , t) for PE at EDBadd

I Store a punctured key at the tag t at EDBdel

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

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)

I KG(1λ, d): Choose a random key sk0 and set msk = (sk0, d).

I Enc(msk,m, t):

1. Compute ski = H(ski−1, i) for all 1 ≤ i ≤ d .

2. Compute k = ⊕di=0F (ski , t) and ct = SE.Enc(k,m).

3. Output (ct, t).

I Punc(SKi−1, t′i ):

1. Compute pski = F.Punc(ski−1, t′i ) and ski = H(ski−1, i).

2. Set mski = (ski , d).

3. Output SKi = (mski , psk1, · · · , pski ).

I Dec(SKi , ct, t):

1. If i < d , compute sk` = H(sk`−1, `) for i ≤ ` ≤ d .

2. Evaluate k′ = ⊕is=1F.Eval(psks , t)⊕

d`=i F (sk`, t).

3. Recover m′ = SE.Dec(k′, ct).

7

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).

id1 w1 w3 w5 · · ·id2 w1 w2 w3 · · ·id3 w3 w7 w8 · · ·...

...

〈 Forward index 〉

I Pros: Addition/Deletion

I Cons: Keyword search

w1 id2 id2 · · ·w2 id1 · · ·w3 id1 id2 id3 · · ·...

...

〈 Inverted index 〉

I Pros: Keyword search

I Cons: Addition/Deletion

Label 1 Label 2 Value

H(Tid1 , 1) H(Tw1 , 1) Enc(Tw1 , id1)...

H(Tid3 , 1) H(Tw7 , 1) Enc(Tw7 , id3)...

〈 Dual dictionary〉 8

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

Our Construction

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

I Dual dictionary structure

I Puncturable encryption (PE)

How to achieve forward/backward security

I Forward security: Update an encryption key for PE after search queries

I Backward security: Use a puncturable encryption

10

Concrete Description I: Setup

Algorithm 1 Setup(1λ)→ (ST; EDB)

Notation. F ,G ,H: PRFs with key kF , k′F , kG , kH

PE := (KG,Enc,Dec,Punc): puncturable encryption

Idx : {0, 1}∗ → I for an index set I1: EDB← ∅ /* encrypted DB */

2: ST← ∅ /* private state */

3: msk← (kF , kG , kH) /* 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

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 kid ← F (kF , id)

2: cntid ← 0,D← ∅3: W ← {w |w ∈ f } = {w1, . . . ,wn}4: while W 6= ∅ do

5: w$←− W and kw ← F (k′F ,w)

6: W ← W\{w}7: if ST[w ].Kwd = ⊥ then

8: (EKw , SK(0)w )← PE.KG(1λ, d)

9: ucntw ← 0

10: ST← (w ,EKw , ucntw , (SK(0)w , t0))

11: else

12: (EKw , ucntw )← ST[w ].(Ekey,Ucnt)

13: cntid ← cntid + 1, ucntw ← ucntw + 1

14: labelid ← H(kid, cntid), labelw ← H(kw , ucntw )

15: tw,id ← G(kG ,w ‖ id), pval(id)w ← PE.Enc(EKw , id, tw,id)

16: D← D ∪ {(labelid, labelw , pval(id)w )}17: ST[w ].Ucnt← ucntw

18: Send D to the server

Dual dictionary: Labelid Labelw pval

12

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 (labelid, labelw , pval(id)w ) ∈ D do

3: EDB′ ← (labelid, labelw , pval(id)w )

13

Concrete Description III-1: Deletion @Client

Algorithm 4 Deletion(msk, ST, f ; EDB)→ (ST′; EDB′) @Client

Require: msk, f , ST

Ensure: kid,ST′

1: id← Idx(f ) and kid ← F (kF , id)

2: Send kid to the server

3: W ← {w |w ∈ f } = {w1, . . . ,wn}4: for each w ∈W do

5: tw,id ← G(kG ,w ‖ id)

6: SK(i−1)w ← ST[w ].Psk, SK

(i)w ← PE.Punc(SK

(i−1)w , tw,id)

7: ST[w ].Psk← SK(i)w ,ST[w ].Tag← ST[w ].Tag ∪ {tw,id}

14

Concrete Description III-2: Deletion @Server

Algorithm 5 Deletion(msk, ST, f ; EDB)→ (ST′; EDB′) @Server

Require: kid,EDB

Ensure: EDB′

1: cntid ← 1

2: while true do

3: labelid ← H(kid, cntid)

4: if EDB[labelid] 6= ⊥ then

5: EDB← EDB\{EDB[labelid]}6: cntid ← cntid + 1

7: else return EDB

8: EDB′ ← EDB

Labelid Labelw Pval

...

H(kid3 , 1) H(kw7 , 1) PE.Enc(· · · )...

〈 When deleting id3 〉15

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: kw ← F (k ′F ,w)

3: (ucntw , (SKw ,Tw ))← ST[w ].(Ucnt,Psk,Tag)

4: τw ← (SKw ,Tw , kw , ucntw )

5: Send τw to the server

6: (EK′w , (SKw′, t′0))← PE.KG(1λ, d)

7: ucntw ← 0

8: ST← (w ,EK′w , ucntw , (SK′w , t′0))

16

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 ≤ ucntw do

3: labelw ← H(kw , i)

4: if EDB[labelw ] 6= ⊥ then

5: pvalw = (ctw , tw )← EDB[labelw ].Pval

6: id← PE.Dec(SKw , ctw , tw )

7: NewR← NewR ∪ {(id, tw )}8: i ← i + 1

9: OldR← EDBcache [kw ]

10: OldR← OldR \ {(id, tw )|(id, tw ) ∈ OldR ∧ tw ∈ Tw}11: Res← NewR ∪ OldR

12: EDBcache [kw ]← Res

13: Send Res to the client

Labelid Labelw Pval

H(kid1 , 1) H(kw1 , 1) PE.Enc(· · · )...

17

Comparison

Computational complexity

Janus++ Ours

Search O(aw ) PE.Dec O(aw − dw ) PE.Dec

Add O(N) PE.Enc O(N) PE.Enc

Delete O(did) PE.Punc O(did) PE.Punc

aw : the number of added documents that include keyword w

dw : the number of deleted documents that include keyword w

N: the total number of document/keyword pairs

did : the number of keywords in the document to be deleted

Storage

Janus++ Ours

Client O(W ) O(W )

Server O(Σw (aw + dw )) O(Σw (aw − dw ))

W : the total number of keywords in DB

18

Conclusion & Future Works

Conclusion & Future Works

We provided a new backward secure DSSE under the dual dictionary structure by

adjusting Janus/Janus++.

In terms of theoretical efficiency analysis, the search time/the storage of ours are

faster/smaller than those of the original Janus++, respectively, but the advantage

is incremental.

Need implementations for our proposed construction to compare more accurate

efficiency in practice

The maximum number of punctured points is restricted in Sun et al.’s SPE.

Can we remove this limitation?

19

Thanks for your attention!

&

Question?

20