Attila A. Yavuz

Oregon State University

attila.yavuz@oregonstate.edu

SAC 2015 Dr. Attila Altay Yavuz 1August 13, 2015

22nd International Conference on Selected Areas in Cryptography

Dynamic Symmetric Searchable Encryption with Minimal Leakage and Efficient Updates on Commodity Hardware

Jorge Guajardo

Robert Bosch LLC – RTC, USA

Jorge.GuajardoMerchan@us.bosch.com

Challenge: Privacy versus Data Utilization Dilemma

 

Client

Storage on the cloudSensitive information

Outsource the data

SEARCH? ANALYZE?

(encrypted)

Standard Encryption

CAN’T SEARCH!CAN’T ANALYZE!

2

IMPACT

Searchable Encryption (Generic Framework)

3

f1 fn

Client

Cloud

. .

.c1 cn. .

.Extract keywords

w1 wn. . .

t1

Data Structu

ret1 tn. . .

Searchable Representation

Search keyword: w1 t1

Trapdoors

tn. . .

t1

Update file: fi (zi,V)

(zi,V)

c1

f1

Curtmola et al. (CCS 2006) Single linked list (+) Efficient encrypted searches (-) No update on files (addition/removal not possible)

Variants of CCS 2006 with various properties: Ranked, multi-keyword, wildcard, … (-) No update and inefficient

Kamara et. al. (CCS 2012) Multi-linked list (+) Updates: New files can be added/removed (-) Update leaks information (insecure updates)

Kamara et. al. (FC 2013) Red-black trees (+) Secure updates (-) Searchable words are fixed (cannot add a new keyword later) (-) Extremely large cloud storage (multi TBs, impractical)

5

Prior Work on Searchable Encryption (Milestones)

Stefanov et al. (NDSS 2014) Multi-arrays + Oblivious sort (+) Higher security, efficient searches (-) Larger client storage and transmission, high server storage

Cash et al. (NDSS 2014) Generic dictionaries (+) Conjunctive, boolean queries, balanced and efficient search/update, (+) Tests on very large scale DBMS (-) Database grows linearly with update, client permanent storage, leaks

more than Stefanov et al. (NDSS 2014)

Hann et al. (CCS 2014) (+) Update efficient, secure updates, leaks less than above (-) Client storage, slower search

Naveed et al. (S&P 2015) Blind storage (+) High security, search/update efficiency (-) Single keyword only, interactive (e.g., network delays), cannot update

file content, add/remove them only6

Prior Work on Searchable Encryption (Milestones)

(+) The highest privacy among all compared alternatives

(+) Simple design

(+) Low update communication overhead, one round only

(+) Low server storage 1 bits - per keyword/file pair

No growth with updates, no revocation lists…

(+) Dynamic keywords, parallelism

(-) Linear search w.r.t # of files, O(m/b)/p (-) O(n+m) client storage due to hash tables (e.g., n=m=10^7,

~160 MB) Can store/fetch from cloud Monster Inc 2. game on Iphone ~ 200 MB…

(+) Efficient practicality on commodity hardware

Contribution: A New Dynamic Symmetric SE Scheme

7

Searchable Representation: Binary matrix I Row i, {1,…,m} keyword wi, column j, {1,…,n} file fj

If I[i,j]=1 then keyword wi appears in file fj, otherwise not

Integrates index and inverted index, simple yet efficient Search via row operations inverted index Update via column operations index

(i,j) 1 2 . . . n

1 1 0 1 0 0 0

2 1 0 0 0 0 1

. 0 0 1 0 0 0

. 0 0 0 1 0 1

. 0 0 1 1 0 0

m 0 0 0 0 0 1

8

Our Scheme: Searchable Representation

Files f1 f2 . . . fn Keywords

w1

w2

. . . wm

(i,j) 1 2 . . . 128 . . . 256 … n

1 0 0 . . . 1 . . . 0 . . . 1

2 0 0 . . . 0 . . . 1 . . . 0

. 1 0 . . . 0 . . . 0 . . . 1

m 1 0 . . . 0 . . . 1 . . . 1

9

Our Scheme: Map keyword/file to the matrix Keyword w {1,…, m} and file f {1, … , n} : Dynamic and

efficient Map a keyword to a row i:

Open address hash tables: Collision-free (one-to-one), O(1) access

Map a file to column j:

TF 1, z100

2,z250

. . . 128,zl

… 257,zr

… n,z6

TW

1,t55

2, t300

.

m, t2

and )(1

)TF(zjfMACzidfidkf

}10m{1,..., number bit 160 , )( 6

1 xkx wMACt

)( xtTWi

Derive row key

Encrypt each row i with ri (b=1, or AES b=128 CTR mode)

Our Scheme: Encrypt Searchable Representation (basics)

(i,j)

1 . . . 128

. . .

256

. . .

n

1 0 . . . 1 . . .

0 . . . 1

. 1 . . . 0 . . .

0 . . . 0

. 0 . . . 1 . . .

0 . . . 1

m 1 . . . 0 . . .

1 . . . 1

),*],1[(,*]1['1

stIEI r

),*],[(,*][' stmIEmImr

Achieving Dynamic Keywords: Static schemes: Derived keys from keywords

Break static relation between keys and keywords

)( iki wKDFr

via a tolink ),||(2

TWw rpadiKDFr iki

10

rand. is ),||(2

padpadiKDFr ki

r1

rm

.

.

.

Search keyword w on I’ :

Our Scheme: Search on Encrypted Representation (only basics)

1

2

1. ( ),

2. ,

3. ( || )

w k

w

i k

t MAC w

i TW(t )

r KDF i pad

11

Client

TF)TWI ,,( 'Cloud

Decrypt i’th row of I’[i,*] with ri I[i,*]I’ 1 . . . 12

8 . . .

n

1 0 . . . 1 . . .

1

. 1 . . . 0 . . .

0

i 0 . . . 1 . . .

1

m 1 . . . 0 . . .

1

),*],['(,*][ stiIDiIir

I[i,j]=1 then ciphertext cj contains twI 1 .. 55 .. 25

3 254

.. n

i 1 0 1 0 1 0 0 1

TF)TWkkkk ,,,,,( 4321

c1 c55 c253

cn

Decrypt with k4

Get f1,f55,…,fn

),( iri

Add a new file f to I’ :

Our Scheme: Update on Encrypted Representation (b=1)

l2 ww , , , wf 1

12

Client

TF)TWI ,,( 'Cloud

Replace new column with j’th column of I’

I’ 1 . . . j . . .

n

1 0 . . . 1 . . .

1

. 1 . . . 0 . . .

0

. 0 . . . 1 . . .

1

m 1 . . . 0 . . .

1

)(MACk .1

1t 2t lt...

(.)TW

1a 2ala...

)||1(21 padKDFr k

)||(2

padmKDFr km

0

…

1

1

0

1

…

0

1a

2a

)(

)(

zTFj

fMACz1k

la

0

…

1

1

0

1

…

0

E(.)

Add a new file f to I’ :

Our Scheme: Update on Encrypted Representation (b=128)

l2 ww , , , wf 1

13

Client

TF)TWI ,,( 'Cloud

Overrides on b-1 regions! Inconsistency

I’ 1 . . . j . . . n

1 0 . . . 1 . . . 1

. 1 . . . 0 . . . 0

. 0 . . . 1 . . . 1

m 1 . . . 0 . . . 1

)(MACk .1

1t 2t lt...

(.)TW

1a 2a la...

)||1(21 padKDFr k

)||(2

padmKDFr km

0

…

1

1

0

1

…

0

1a

2a

)(

)(

zTFj

fMACz1k

la

E(.)

b=128

0

…

1

1

0

1

…

0

?

…

?

?

?

?

…

?

?

…

?

?

?

?

…

?

?

…

?

?

?

?

…

?

?

…

?

?

?

?

…

?

Add a new file f to I’ :

Our Scheme: Update on Encrypted Representation (b=128)

l2 ww , , , wf 1

14

Client

TF)TWI ,,( 'Cloud

One round of interaction and key renewal

I’ 1 . . . j . . . n

1 0 . . . 1 . . . 1

. 1 . . . 0 . . . 0

. 0 . . . 1 . . . 1

m 1 . . . 0 . . . 1

)(MACk .1

1t 2t lt...

(.)TW

1a 2a la...

)||1(21 padKDFr k

)||(2

padmKDFr km

0

…

1

1

0

1

…

0

1a

2a

)(

)(

zTFj

fMACz1k

la

1) D(B_j)

Renew keys

2) E(B_j’)

b=128

0

…

1

1

0

1

…

0

Search-Update Coordination for High Privacy

15

I 1 . . . j . . . n

1 0 K_1 K_3 . . . K_5

. 1 . . . 0 K_x 0

K_2 K_3 K_4

. 0 . . . 1 . . . 1

m 1 K 0 . . . 1

w=“email”, searched

100

w=“EU-CMA”,

searched 1

F_j, Update 100

F_n, Update 1000

Various regions, various distinct keys!

1) # of search on row i

2) # update on column j

3) Sequence of operations

Update

SearchSearch

Update

ExposedRe-encrypt

UpdateNo expose Re-encrypt

Search UpdateKey updateencrypt

gc

TW[i].st

TF[j].st, state bit

2(i || )i kr KDF st

Security Analysis of Our DSSE (Very Brief)

16

Confidentiality focus (integrity/auth can be added)

Access Pattern: File identifiers that satisfy a search query (search results)

Search Pattern: History of searches (whether a search token used at past)

IND-CKA2 (Adaptive Chosen Keyword Attacks): Given {I’, c0,..,cn, z0, …,zn, t0,…,tm}, no adversary can learn any information about f0,…,fn and w0,…,wm other than the access and search pattern, even if queries are adaptive.

Leakage Functions are critical for updates Theorem 1: Our DSSE scheme (L1,L2)-secure in ROM based on

IND-CKA2, where L1 and L2 leak access and search pattern, respectively.

Real and simulated views are indistinguishable due to PRF and IND-CPA cipher.

17

 High-Level Comparison

/ 3

18

 

C/C++

Own Lines of code : 10528

Tomcrypt API Symmetric Key Encryption: AES-CTR 128-bit MAC: CMAC-128 Key Derivation Function : CMAC-128 File encryption : CCM (Counter with CBC-MAC)

Intel AESNI sample library For AES implementation using assembly language

instructions. As KDF, we further exploit AES-ASM by using CMAC.

Hash tables, Google open source static C++ data structure

Implementation Details of Our DSSE

19

Operation Avg time (msec)

#keyword : 1,000,000

#file : 5,000

Avg time (msec)

#keyword : 200,000

#file : 50,000

Avg time (msec)

#keyword : 2,000#file :

2,000,000

Build Index 822.6 493 461

Search Keyword

0.01 0.27 10.02

Add File 2772 472 8.83

Delete File 2362 329 8.77

Implementation ( Benchmarking Results )

Enron email dataset, Ubuntu 13.10 OS, 4 GB RAM, Intel i5 processor, 256 GB harddisk

All operations are practical

Search under a msec, and only 10 msec for 2 millions of files

Update various 8 msec to 2 sec

20

 

A new DSSE with various desirable properties

(+) The highest level of privacy (+) Simple yet efficient, compact updates and storage (+) Keyword updates, parallelism, extendable to multiple

keyword queries

(-) Asymptotically linear search and client storage But still quite practical on commodity hardware

TAKEAWAYS: Simplicity wins!

Asymptotic results are not enough to assess the practicality (actual implementation, details, hidden constants)

Practical storage at the client is NOT evil (actually beneficial)

Conclusion

Thank You!

21