1. Attila A. Yavuz Oregon State University attila.yavuz@oregonstate.edu
22nd International Conference on Selected Areas in Cryptography
Dynamic Symmetric Searchable Encryption with Minimal Leakage and Efficient Updates on Commodity Hardware
Attila A. Yavuz
Oregon State University
Jorge Guajardo
Robert Bosch LLC – RTC, USA
SAC 2015
Dr. Attila Altay Yavuz
August 13, 2015

2. Challenge: Privacy versus Data Utilization Dilemma
Sensitive information
Storage on the cloud
Client
(encrypted)
Outsource the data
SEARCH?
ANALYZE?
Standard Encryption
CAN’T SEARCH!
CAN’T ANALYZE!
One of the biggest challenges in the domain of cloud computing is privacy versus data utilization dilemma.
Lets give an example of privacy versus data utilization dilemma.
Consider a cloud-based application, in which a client outsource his data to the cloud for financial, maintanence and service benefits. However, sensitive data such as health, financial or personal information cannot be stored on cloud.
Hence, the client encrypts the data before outsourcing it.
The problem begins, when the client wants to retrieve or analyze the encrypted data on the cloud. Because, the standard encryption techniques do not permit search or analysis of data.
This is just an example privacy versus data utilization dilemma, wherein we either encrypt and protect the privacy but sacrifice search/analysis, or don’t encrypt and lose privacy. Notice that it is such a fundamental challenge, it appears everywhere, such as healtcare system where you want keep medical data encrypted against breaches, you want privacy-preserving data mining, and similarly for financial applications.
Therefore, practical solutions for this challenge will create a significant impact ion the society in general and science at large
IMPACT

3. Searchable Representation
Searchable Encryption (Generic Framework) f1 fn
Client
Cloud
Data
Structure t1 tn
Searchable Representation c1 cn
Extract keywords w1 wn
Trapdoors tn t1 c1
Towards addressing this research challenge, I developed and currently execute the search program, “Efficient Privacy …..” as a Co-PI, which is funded by Bosch Research Center.
In this research program, my focus will be developing efficient and practical searchable encryption methods.
Search keyword: w1  t1 t1
f1
Update file: fi  (zi,V)
(zi,V)

4. How to Evaluate a DSSE?
No single DSSE is better than all others for all aspects
Security/Performance Trade-off:
Choice of data structure
Operations on it
Performance
Search and update execution times
Client storage (auxiliary info)
Server storage (encrypted data structure)
Communication overhead
# rounds  network latency
Security
Information leakage due to updates

5. Prior Work on Searchable Encryption (Milestones)
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)
Wang et. al. [TPDS 2012], Cao et. al. [Infocom 2011], Sedghi [SCN 10], …

6. 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 only

7. Contribution: A New Dynamic Symmetric SE Scheme
(+) 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

8. Our Scheme: Searchable Representation
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
Files f1 f fn
Keywords w1 w2 . wm
(i,j) 1 2 . n m

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
(i,j) 1 2
. . .
128
256 … n . m TW
1,t55
2, t300 .
m, t2

10. Our Scheme: Encrypt Searchable Representation (basics)
Derive row key
Encrypt each row i with ri (b=1, or AES b=128 CTR mode)
(i,j) 1
. . .
128
256 n . m r1 . rm
Achieving Dynamic Keywords:
Static schemes: Derived keys from keywords
Break static relation between keys and keywords
Derive keys from a row number and link it to any keyword via HT

11. Our Scheme: Search on Encrypted Representation (only basics)
Cloud
Client
Search keyword w on I’ :
Decrypt i’th row of I’[i,*] with ri  I[i,*] I’ 1
. . .
128 n . i m
I[i,j]=1 then ciphertext cj contains tw I 1 .. 55
253
254 n i
Decrypt with k4
Get f1,f55,…,fn
c c c cn

12. Our Scheme: Update on Encrypted Representation (b=1)
Cloud
Client
Add a new file f to I’ :
Replace new column
with j’th column of I’ I’ 1
. . . j n . m … 1 … 1
E(.)

13. Our Scheme: Update on Encrypted Representation (b=128)
Cloud
Client
Add a new file f to I’ :
Overrides on b-1 regions!  Inconsistency I’ 1
. . . j n . m … 1 ? … ? … … 1 ? … ? …
E(.)
b=128

14. Our Scheme: Update on Encrypted Representation (b=128)
Cloud
Client
Add a new file f to I’ :
One round of interaction and key renewal I’ 1
. . . j n . m … 1 … 1
D(B_j)
Renew keys
2) E(B_j’)
b=128

15. Search-Update Coordination for High Privacy
Various regions, various distinct keys!
F_j, Update 100
F_n, Update 1000 I 1
. . . j n
K_1
K_3
K_5 .
K_x
K_2
K_4 m K
# of search on row i
# update on column j
Sequence of operations
w=“ ”,
searched 100
w=“EU-CMA”,
searched 1
Update
Exposed
Re-encrypt
Search
Search gc
TF[j].st, state bit
No expose
Re-encrypt
Update
Update
Key update
encrypt
Search
Update
TW[i].st

16. Security Analysis of Our DSSE (Very Brief)
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. Implementation Details of Our DSSE
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

19. Implementation ( Benchmarking Results )
Operation
Avg time (msec)
#keyword : 1,000,000
#file : 5,000
#keyword : 200,000
#file : 50,000
#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
Enron dataset, Ubuntu 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
Neden add file daha pahali: Cunku her bir row icin ayri key ile AES invocation yapiliyor, search de ise ayni keyle invoke ediliyor

20. Conclusion A new DSSE with various desirable properties
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)
91 submission, 26 long paper, 3 short papers
6:30 pm, Building 22, Purdy Crawford for Arts

21. Thank You!