dynamic searchable encryption via - stanford...

Dynamic Searchable Encryption Via !

Blind StorageMuhammad Naveed

University of Illinois at Urbana-Champaign

Joint work with my advisors: Manoj Prabhakaran!

Carl A. Gunter

Please Interrupt!

0

500,000,000,000

1,000,000,000,000

1,500,000,000,000

2,000,000,000,000

2006 2007 2008 2009 2010 2011 Jun 2012 Nov 2012 Apr 2013

What do people think about cloud storage?

Storage Outsourcing

In-premises Storage

In-premises Storage

Write

In-premises Storage

Write Read

In-premises Storage

Write Read Delete

In-premises Storage

Write Read Delete Search

In-premises Storage

Write Read Delete Search

Everything

Storage OutsourcingClient Cloud

Client Cloud

Storage Outsourcing

Naive Encryption?Client Cloud

Naive EncryptionClient Cloud

Search with Naive Encryption?

Client Cloud

Can we do better?

Yes!• property-preserving encryption

• functional encryption

• fully-homomorphic encryption

• secure two-party computation

• oblivious RAMs

• searchable symmetric encryptionTaken from Seny Kamara's blog: http://outsourcedbits.org/

http://outsourcedbits.org/

Searchable Encryption The Functionality

Setup PhaseClient Cloud

Setup Phase

Indexword document listbest! 1, 2

illinois 3microsoft 1, 4, 5america 6, 7, 1

[email protected] 3, 4blue 1

pakistan 8, 9cryptography 10, 11, 12

laptop 13android 3, 4, 14, 15

genomics 3, 4, 16privacy 3, 4, 16, 17security 1, 2, 3, 4, 5, 6,

7, 8

Client Cloud

Setup Phase







7, 8

Client Cloud

using AES

Setup Phase







7, 8

Client Cloud

using AES

using SSE

Setup Phase







7, 8

Client Cloud

using SSE

Setup Phase







7, 8

Client Cloud

Online PhaseClient Cloud

Indexword document listillinois 1, 3best 2

microsoft 1, 4, 5america 6, 7, 1

[email protected] 1, 3, 4, 8blue 1




7, 8








7, 8

Search for the keyword “illinois”








7, 8


illinois








7, 8


illinois

1

3








7, 8


illinois

1 3








7, 8


illinois

1

3








7, 8


illinois








7, 8








7, 8

Add document

100








7, 8

Add document

illinois, blue100








7, 8

Add document

illinois, blue

100


Add document

illinois, blue

Update Indexword document listillinois 1, 3, 100best 2


[email protected] 1, 3, 4, 8blue 1, 100




7, 8

100


Add document

illinois, blue

Update Indexword document listillinois 1, 3, 100best 2


[email protected] 1, 3, 4, 8blue 1, 100




7, 8

100

Same procedure for delete

LeakageAccess Pattern Search Pattern

illinois illinois

blue blueillinois

1

3

t1 t2

t3 t4

Additional Add/Delete Leakage• Hashes of all the keywords in the newly added

document

illinois

blue

Additional Add/Delete Leakage• Hashes of all the keywords in the newly added

document

illinois

blue

illinois

blue

Security Definitions

• Non-adaptive Security!• All queries are generated in a single batch

• Adaptive Security!• Queries can be generated as a function of previous search

results

Previous Work• Schemes supporting single-keyword queries

• Song-Wagner-Perring00, Goh03, Chang-Mitzenmacher05, Curtmola-Garay-Kamara-Ostrovsky2006, Kurosawa-Ohtaki12, Chase-Kamara10, Liesdonk-Sedghi-Doumen-Hartel-Jonker10, Kamara-Papamanthou-Roeder12, Kamara-Papamanthou13, Stefanov-Papamanthou-Shi14, Cash-Jaeger-Jarecki-Jutla-Krawczyk-Rosu-Steiner14

• Schemes supporting conjunctive/boolean queries • Cash-Jarecki-Jutla-Krawczyk-Rosu-Steiner13, Jarecki-Jutla-Krawczyk-Rosu-Steiner13,

• All require computation on the server side

• Some schemes are not parallelizable

• Non-standard leakage or more leakage during updates

Linked-list based Schemes

Node


Node

document ID


Node

document ID Key to decrypt next node


Node


Pointer to next node


Node



1 1 1 1


keyword1

Node



1 1 1 12 2 2 2


keyword1

Node



1 1 1 12 2 2 2

n n n n


keyword1

keywordn

Node



1 1 1 12 2 2 2

n n n n


T

keyword1

keywordn

Node



1 1 1 12 2 2 2

n n n n


T

Element

keyword1

keywordn

Node



1 1 1 12 2 2 2

n n n n


T

ElementKey to decrypt

first node

keyword1

keywordn

Node



1 1 1 12 2 2 2

n n n n


T


first nodePointer to first

node

keyword1

keywordn

Node



1 1 1 12 2 2 2

n n n n


T



node

keyword1

keywordn

PRP(keywordn)

PRP(keyword2)PRP(keyword1)

Node



1

1

1

1

2 2 2 2

n n n n


T



node

keyword1

keywordn

PRP(keywordn)


Node



1

1

1

1

2

2

2

2

n n n n


T



node

keyword1

keywordn

PRP(keywordn)


Node



1

1

1

1

2

2

2

2

n

n

n

n


T



node

keyword1

keywordn

PRP(keywordn)


!

Search in Linked-list based Schemes

!Search for keyword2



PRP(keyword2)



PRP(keyword2)


Node


PRP(keyword2)


NodeKey to decrypt

first node


PRP(keyword2)


NodeKey to decrypt


node


PRP(keyword2)

Nodedocument ID Key to decrypt

next nodePointer to next

node


NodeKey to decrypt


node

Dictionary Based Schemes

• Use dictionary data-structure

• Each (keyword, document) pair is stored in the dictionary

• Optimizations to reduce disk reads

• Highly scalable

Dictionary Based Schemes

• Non-standard leakage

• Complicated delete operation using revocation identifiers • Deletion require more storage • Complicates later addition of deleted keywords

This Work

Supports only Single-Keyword Search

More basic primitive: Blind Storage

Simple and efficient scheme

Computation-free server


StorageProcessing

command/data

response

All other SSE schemes require computation to be done on the server.


Storage

upload

download

Our scheme works with computation-free server

Why is it important?• Bandwidth costs: It is expensive to use computing

and storage from two different cloud providers.

• Latency issues even using same cloud service • e.g., Amazon EC2 and Amazon S3 • cloud services have well-known latency issues • Data from storage nodes need to be transmitted over the datacenter

network

Other features• Supports compression

• Document privacy

• Inherently parallel

• Leaks less. Leakage specified using "ideal functionality”

• Satisfies a fully adaptive security definition

• Security in the standard model

• Zero delete cost

Blind Storage The Functionality

SetupClient Cloud

SetupClient Cloud

BlindStore

SetupClient Cloud

BlindStoreDoes not leak

total number of files and size of individual files

SetupClient Cloud

BlindStoreDoes not leak

total number of files and size of individual files

Leaks pre-determined upper bound on the total amount of data

AccessClient Cloud

BlindStore

AccessClient Cloud

BlindStore

Read

filename

AccessClient Cloud

BlindStore

Read

filename

Leakage!★ Access Pattern ★ File size

AccessClient Cloud

BlindStore

Read

filename

Write

Leakage!★ Access Pattern ★ File size

ScatterStore

Requirements

• Should not leak the total number of files initially indexed

• Should not leak the file sizes of the files initially indexed

Block format

Block formatHeader

Block formatHeader Data

Block formatHeaderhash(fileID) Data

Block formatHeaderhash(fileID) version Data


First block of a file


Header



Header Data



Headerhash(fileID) Data



Headerhash(fileID) version Data



Headerhash(fileID) version Data# Blocks


Headerhash(fil version DataHeaderhash(fil version Data



Headerhash(fil version DataHeaderhash(fileID) version Data




Headerhash(fil version DataHeaderhash(fileID) version Data

Headerhash(fileID) version Data# Blocks

Our Scheme (Setup)BlindStore


filename1


filename1

Seed1 = Hash(filename1)


filename1


filename2


filename1


filename2


With 4X storage blowup, !the probability of NOT finding enough blocks to

store a file is negligible.

AccessBlindStore

Client Cloud

AccessBlindStore

Client Cloud

Access filename2

AccessBlindStore


Client Cloud

Access filename2

Access (with details)BlindStore

Client Cloud


Client Cloud

Access filename2


Client Cloud

Access filename2First round



Client Cloud




Client Cloud


Size = 8 blocks



Client Cloud


Second round

Size = 8 blocks



Client Cloud


Second round

Size = 8 blocks

Retrieve remaining 6 blocks

Access (with details)

• k blocks are accessed in the first round, where k is the security parameter • We set k = 80 for our experiments

• Total communication per access: • 80 blocks for small files (i.e. 20KB for files smaller than 5KB) • 4 times the file’s size (for files larger than 5KB)

Why read more?

BlindStore

Client Cloud

Why read more?

BlindStore

filename1

Client Cloud

Why read more?

BlindStore

filename1


Client Cloud

Why read more?

BlindStore

filename1


filename2

Client Cloud

Why read more?

BlindStore

filename1


filename2


Client Cloud

SSE via Blind Storage

SetupClient Cloud

SetupClient Cloud

Blind Store

SetupClient Cloud

Blind Store

Indexword document list

best! 1, 2

illinois 1, 3

microsoft 1, 4

america 1, 5

[email protected]

1, 6

blue 1

pakistan 8, 9

cryptography 10, 11, 12

laptop 13

android 3, 4, 14, 15

genomics 3, 4, 16

privacy 3, 4, 16, 17

security 1, 2, 3, 4, 5, 6, 7, 8

SetupClient Cloud

Blind Store

Indexword document list

best! 1, 2

illinois 1, 3

microsoft 1, 4

america 1, 5

[email protected]

1, 6

blue 1

pakistan 8, 9

cryptography 10, 11, 12

laptop 13

android 3, 4, 14, 15

genomics 3, 4, 16

privacy 3, 4, 16, 17

security 1, 2, 3, 4, 5, 6, 7, 8

contents: 1,2

SetupClient Cloud

Blind Store

SearchClient Cloud

BlindStore

SearchClient Cloud

BlindStore

search

keyword

SearchClient Cloud

BlindStore

search

keyworddoc ids: 2, 3

SearchClient Cloud

BlindStore

search

keyword

doc ids: 2, 3

SearchClient Cloud

BlindStore

search

keywordUpdate Index (for lazy delete)

doc ids: 2, 3

Addition/Deletion• All existing SSE schemes leak more during updates

• Hashes of all the keywords in the new document are leaked

• Presence of the same keyword in other documents

• Delete leak even more

Addition/Deletion• All existing SSE schemes leak more during updates

• Hashes of all the keywords in the new document are leaked

• Presence of the same keyword in other documents

• Delete leak even more

BlindStorage is not required for the newly added documents

• New files are stored in ClearStore

• Store files unencrypted

• Supports constant time append operation • Requires downloading three blocks and uploading two blocks

ClearStore

ClearStore

AddClient Cloud

BlindStore

ClearStore

AddClient Cloud

BlindStore

add

ClearStore

AddClient Cloud

BlindStore

add

keyword0

ClearStore

AddClient Cloud

BlindStore

add

keyword0

ClearStore

keyword1

AddClient Cloud

BlindStore

add

keyword0

ClearStore

keyword1 keywordt

AddClient Cloud

BlindStore

add

keyword0

ClearStore

keyword1

keywordt

AddClient Cloud

BlindStore

add

keyword0

ClearStore

keyword1

keywordt

These are not the complete index file.

AddClient Cloud

BlindStore

add

keyword0

ClearStore

keyword1

keywordt

AddClient Cloud

BlindStore

add

keyword0

ClearStore

keyword1

keywordtAdd id of the new document

Delete is freeClient Cloud

Blind Virtual Disk

Delete is freeClient Cloud

Blind Virtual Disk

delete

doc ID

Lazy Delete StrategyClient Cloud

BlindStore


BlindStore

search

keyword


BlindStore

search

keyworddoc ids: 2, 3


BlindStore

search

keyword

doc ids: 2, 3


BlindStore

search

keyword

doc ids: 2, 3

File 3 doesn’t exist


BlindStore

search


doc ids: 2, 3



BlindStore

search


doc ids: 2, 3


doc ids: 2

Leakage• Leaks Access and Search Pattern

• Leak nothing when file is deleted, slowly reveal keywords contained in deleted files

• Updates: Leaks strictly less than prior schemes except Stefanov et. al. NDSS 2014 scheme • They have polylograithmic overhead on top of other

schemes (including ours)

We achieve adaptive security through one extra round of interaction.

Performance

4X AES cost to encrypt the index

Evaluation• Datasets

• Emails: Subset of Enron email dataset • Documents: We collected 1GB doc, ppt, xls and pdf

document using Google

• Operations • Setup (Preprocessing) • Search (for the most frequent word “the”)!• Add • Delete

• Laptop machine was used for experiments

Setup cost for 16GB Enron Emails (Extrapolated)

Previous best scheme

Com

puta

tion

time

(hou

rs)

02468

10121416

15

Prior work used Xeon server while we used a laptop

Setup cost for 16GB Enron Emails (Extrapolated)

Our scheme

Com

puta

tion

time

(hou

rs)

02468

10121416

0.68

Prior work used Xeon server while we used a laptop

Evaluation on Enron Email dataset

Setup36s

Search

Search0.5s

Communication Overhead

0.02 0.04 0.09 0.18 0.39 0.77 1.51 3.49 7.03 14.02 28.62

57.19

108.19

218.12

0.00

50.00

100.00

150.00

200.00

250.00

4MB 8MB 16MB 32MB 64MB 128MB 256MB

Dat

a D

ownl

oade

d (M

B)

Subsets of Enron dataset in MBs

Index data (MB)

Document data (MB)

Add0.26s

Evaluation on Documents dataset

Data collection

• We collected 1GB doc, ppt, xls and pdf document using Google

• All documents in the dataset are in English

Setup30s

Search

Search0.008s

Add0.6s

Delete is free Because of our lazy delete strategy

Conclusion• Blind storage primitive

• Can have other applications

• Much simpler, scalable and secure dynamic SSE scheme

• More practical scheme: No server-side computation

• Can be deployed on commercial cloud storage services such as Dropbox

• Several possible extensions (Ongoing work)

Paper and Slides available at www.cryptoonline.com

http://www.cryptoonline.com