backward secure dynamic searchable symmetric encryption ...€¦ · backward secure dynamic...
TRANSCRIPT
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