building(systemsthatcompute(on encrypteddata( mylar(iot.stanford.edu/seminar/sitp-w15-racula.pdf ·...

Building systems that compute on encrypted data Raluca Ada Popa

? xe891a1X32e1dcxdd0135x63ab12

xd51db5X9ce568xab2356x453a32

Based on joint works with: Catherine Redfield, Nickolai Zeldovich, Hari Balakrishan, Steven Valdez, Jonas Helfer, Frans M. Kaashoek, Andrew Blumberg, Frank H. Li, Shafi Goldwasser, Yael Kalai, Vinod Vaikuntanathan, Raphael Bost, JusMne Sherry, Sylvia Ratnasamy, Chang Lan, Ion Stoica, WenMng Li, Rachit Agarwal

Mylar

Compromise of confiden<al data is prevalent

Problem setup

server clients

Secret Secret Secret

no computaMon computaMon storage databases, web applicaMons, mobile

applicaMons, machine learning, etc.

encrypMon ??

Current systems strategy

Prevent aRackers from breaking into servers

server

clients

Secret Secret

Lots of exisMng techniques

Ø  Checks at the operaMng-‐system level

Ø  Checks at the network level

Ø  Language-‐based enforcement of a security policy

Ø  StaMc or dynamic analysis of applicaMon code

Ø  Trusted hardware

…

Data still leaks even with these mechanisms

a>ackers eventually break in!

because

accessed private data according to

hackers

cloud employees insiders: legi<mate server access!

government

increasingly many companies store data on external clouds

Reason they succeed: ARacker

soXware is complex

e.g., physical access

ARacker examples

My work: Systems that protect confidenMality even against

aRackers with access to all server data

server

client

New way of building systems

Servers store, process and compute on encrypted data

?? Result

Secret Secret

Secret Secret

in a prac/cal way

Strawman: Result

CompuMng on encrypted data in cryptography

Fully homomorphic encrypMon (FHE) [Gentry’09]

prohibi<vely slow, e.g., slowdown

My work: prac<cal systems

[Rivest-‐Adleman-‐Dertouzos’78]

X 1,000,000,000

real-‐world performance

large class of real

applicaMons

meaningful security

+ +

prac<cal systems

one generic scheme (FHE)

strawman:

Combine systems and cryptography 1. idenMfy core operaMons needed

2. mul<ple specialized encrypMon schemes

systems crypto 3. Design and build system

New schemes: Ø  comparison, join for CryptDB Ø  mulM-‐key search for Mylar

What systems can we build with this approach?

A lot of systems!

CryptDB [SOSP’11][CACM’12][Oakland’13]

Mylar [NSDI’14]

PrivStats [CCS’11] [Usenix Security’09] VPriv

Func<onal encryp<on

databases

web applicaMons

mobile applicaMons

System Project name

Coming up…

BlindBox

[NDSS’15]

Func<onal encryp<on

machine learning classificaMon

network middleboxes PrivMB

deep packet inspecMon

compressed & encrypted key-‐value store

A lot of systems!


Mylar [NSDI’14]

PrivStats [CCS’11] [Usenix Security’09] VPriv

Func<onal encryp<on

databases

web applicaMons

mobile applicaMons

System Project name

A web framework that protects confidenMality against fully compromised servers

Mylar [R. A. Popa, E. Stark, J. Helfer, S. Valdez, N. Zeldovich, M. F. Kaashoek, H. Balakrishnan -‐ NDSI’14]

Servers store data encrypted

web server

Secret

browser

Secret

Plaintext data exists only in browsers

Secret Secret

Secret

Related work

•  File systems: CFS, NCrypos, SiRiUS, Plutus

•  Encrypted databases: CryptDB, Monomi

•  Browser encrypMon: Christodorescu’08, Cryptocat

Far from sufficient for real web apps

Challenges

•  Enabling funcMonality with encrypMon: – data sharing – computaMon

•  AcMve adversaries (e.g., corrupt webpage)

Mylar

•  Enabling funcMonality with encrypMon: – data sharing – computaMon

•  AcMve adversaries (e.g., corrupt webpage)

webpage code verificaMon principal graph & cerMficaMon

client-‐side web framework new encrypMon scheme: mulM-‐key search

Example: Chat applicaMon Alice Bob Eve

Server cannot see messages

Format messages, generate html page

Users share chat rooms securely

Search

TODO:

WORK PARTY

How to organize a web applicaMon framework for encrypMon?

Start: common web framework

web server user browser

webpage

e.g., Django, Ruby on Rails

current user

code

Secret

Add encrypMon

web server

webpage

Secret

code

•  server’s computaMon is restricted by encrypMon •  easy to tamper with webpage

JS

user browser

Secret

current user

Secret

Secret

Client-‐side web framework


current user code

web-‐ page

Secret

Generate webpage at client, compute in browser

e.g., AJAX programming, Meteor

data

staMc code

Data and code separate

Secret

Mylar

web-‐ page

Secret Secret


cerMfy code

current user

encrypteddata

staMc code

CerMfy code (trusted developer)

Intercept and encrypt/decrypt data

data

Chat applicaMon




Search

Data sharing

ALIGN THINGS on next slide as well Make lock images consistent Add principal in the annotaMon Lock should not have a hole

Developer specifies access control via the principal graph

Alice

Bob

Eve

PARTY

WORK

‘SSN is 32..’

‘7pm on Saturday’ ‘at my place’

function create_chat(chattitle): chat_princ = princ_create(chattitle, princ_current()); function invite_user(username): chat_princ.add_access( princ_lookup(username));

function send_message(msg): Messages.insert({message: msg, chat: cur_chat.id, chatprinc: chat_princ});

In Alice’s browser:

message chat chatprinc

‘SSN is 32..’ WORK WORK princ

Server database:

Messages.encrypted( {"message”: chatprinc});

Enforce access with key chains

‘SSN is 32..’

‘7pm on Saturday’

‘at my place’

Server stores:

WORK

PARTY PARTY

WORK

‘SSN is 32..’

‘at my place’ ‘7pm on Saturday’

Alice

Bob

Eve

Get access to shared data She encrypts smth else Align these

‘SSN is 32..’

‘SSN is 32..’

Server stores: Bob

‘SSN is 32..’

WORK

PARTY


‘at my place’

Eve

She encrypts smth else Align these Fix color of the lock

Bob

Problem: aRacker gives incorrect key

Encrypt message for WORK

Want key ‘SSN is 32..’

Server stores:

WORK

PARTY

Receive key

Eve

Has access to !!!


‘at my place’

SoluMon: CerMficaMon graph IDP or

sta<c princs

Alice

Bob

Eve

‘SSN is 32..’

‘at my place’ ‘7pm on Saturday’

signAlice(WORK, ) signIDP( Alice, )

IDP: invoked once per user account creaMon

PARTY

WORK UI enables the user to choose in a human friendly way the path

How does Bob’s browser know 1. that it needs to check a signature from Alice? 2. Alice’s PK?

Choosing the cerMficaMon path 1.  Principals have human meaningful names

No other change to user experience!

with Mylar without Mylar

2.  Developer displays enMre path 3.  User chooses path

Chat applicaMon




Search

Challenge: mulM-‐key

‘SSN is 32..’


‘at my place’

Server:

Bob WORK

PARTY

Strawman: use single-‐key search scheme

‘SSN is 32..’


‘at my place’

Server:

WORK

PARTY ‘place’ ‘place’

Fix lock colors Smth wrong with this purple Make green also move there movement

‘place’ ‘place’

Match!

Slow: pay overhead for each key

[Kamara et al.’12]

Bob

‘place’

New cryptosystem: mulM-‐key search

Server adjusts encrypMon from one key to another Adjustabilityy Need API for search?

API: Ø  Setup Ø  Keygen Ø  Encrypt Ø  Token Ø  Delta Ø  Adjust Ø  Match

Based on ellipMc curves

Delta

In Bob’s browser:

WORK:

PARTY:

Delta( , )

Delta( , )

Adjust

‘SSN is 32..’


‘at my place’

Server:

Bob WORK

PARTY

‘place’

‘place’ ‘place’

‘place’

Adjust

Adjust ‘place’

Match!

Chat applicaMon

FuncMonality: •  users share chats •  computaMon:

–  format messages, generate html page, etc – search

Security: messages in a chat can only be read by chat creator or invitees




Search

ConfidenMality guarantees

Protects user A’s data confidenMality against •  full server compromise •  compromise of any user machine, except for users with legiMmate access to user A’s data

Does not protect against side channels or access paRerns, and does not hide metadata

assuming •  developer’s client-‐side code does not leak data

ImplementaMon

•  On top of Meteor, but design is not limited to Meteor

•  9000 LoC: Javascript and C++

EvaluaMon

•  How much developer effort does porMng apps

require?

•  What is the performance overhead?

ApplicaMons Applica<ons Fields secured LoC added LoC total Existed

before

kChat chat messages 45 793 Yes

endometriosis medical fields 28 3659 Yes

class submit grades, homework, feedback

40 8410 Yes

photo sharing photos, thumbnails, .. 32 610 No forum post body, Mtle, .. 39 912 No

calendar event body, Mtle, … 30 798 No

Make this slide appear slowly

≈36 LoC

Experimental setup

web server client

Intel Xeon 2.8 GHz, 4 GB of RAM

eight 10-‐core Intel Xeon E7-‐8870, 2.4 GHz, 256 GB of RAM

5 Mbit/s, 20 msec round-‐trip

0 100 200 300 400 500 600 700

transmit

join room

searchinvite

Tim

e (m

sec)

kChatkChat+Mylar

Figure 9: End-to-end latency of four operations in kChat. Trans-mit includes the time from when one user sends a message towhen another user receives it.

End-to-end latency. Figure 9 shows the end-to-end la-tency Mylar introduces for four main operations in kChat:transmitting a message, joining a room, searching for aword in all rooms, and inviting a user to a room. Formessage transmission, we measured the time from thesender clicking “send” until the message renders in therecipient’s browser. This is the most frequent operationin kChat, and Mylar adds only 50 msec of latency to it.This difference is mostly due to searchable encryption,which takes 43 msec. The highest overhead is for invit-ing a user, due to principal operations: looking up andverifying a user principal (218 msec) and wrapping thekey (167 msec). Overall, we believe the resulting latencyis acceptable for many applications, and subjectively theapplication still feels responsive.

We also measured the latency of initially loading apage. The original kChat application loads in 291 msec.The Mylar version of kChat, without the code verificationextension, loads in 356 msec, owing to Mylar’s additionalcode. Enabling the code verification extension increasesthe load time to 1109 msec, owing to slow signature veri-fication in the Javascript-based extension. Using nativecode for signature verification, as we did for bilinearpairings, would reduce this overhead. Note that users ex-perience the page load latency only when first navigatingto the application; subsequent clicks are handled by theapplication without reloading the page.

We also measured the end-to-end latency of the mostcommon operations in the endometriosis application(completing a medical survey and reading such a sur-vey), and the submit application (a student uploading anassignment, and a staff member reading such a submis-sion); the results are shown in Figure 11. For the submitapplication, we used real data from 122 students whoused this application during the fall of 2013 in MIT’s6.858 class. Submit’s latency is higher than that of otherapplications because the amount of data (student submis-sions) is larger, so encryption with search takes longer.

Figure 10: Server throughput for kChat.

For comparison, we also show the latency of submit whensearch is turned off. The search encryption can happenasynchronously so the user does not have to wait for it.

Throughput. To measure Mylar’s impact on serverthroughput, we used kChat, and we set up many pairsof browsers—a sender and a receiver—where the sendercontinuously sends new messages. Receivers count thetotal number of messages received during a fixed interval.Figure 10 shows the results, as a function of the total num-ber of clients (each pair of browsers counts as 2 clients).Mylar decreases the maximum server throughput by 17%.Since the server does not perform any cryptographic oper-ations, Mylar’s overhead is due to the increase in messagesize caused by encryption, and the encrypted search indexthat is added to every message to make it searchable.

Figure 11 also shows the server throughput of the en-dometriosis and class submit application when clientsperform representative operations.

Search. To evaluate the importance of Mylar’s multi-key search, we compare it to two alternative approachesfor secure search. The first alternative is single-key server-side search, in which the client generates a token for everykey by directly computing the adjusted token from ourmulti-key search. This alternative is similar to prior workon encrypted keyword search. In this case, the clientlooks up the principal for every room, computes a tokenfor each, and the server uses one token per room. Thesecond alternative is to perform the search entirely at theclient, by downloading all messages. In this case, theclient still needs to look up the principal for each room sothat it can decrypt the data.

Figure 12 shows the time taken to search for a wordin kChat for a fixed number of total messages spreadover a varying number of rooms, using multi-key searchand the two alternatives described above. We can seethat multi-key search is much faster than either of thetwo alternatives, even with a small number of rooms.The performance of the two alternatives is dominated by

13

kChat performance Latency:

Throughput: 17% reducMon

Mylar

•  A web plaoorm that protects confidenMality against full server compromise –  Secures real applicaMons with few LoC – Modest overhead

hRp://css.csail.mit.edu/mylar/

webpage code verificaMon principal graph & cerMficaMon new encrypMon scheme: mulM-‐key search

Systems that compute on encrypted data


Mylar [NSDI’14]

PrivStats [CCS’11]

[Usenix Security’09] VPriv

databases

web applicaMons

mobile applicaMons

System Project name

Ø  network middleboxes Ø  intrusion detecMon, firewall, NAT over encrypted

traffic!

Coming up CryptDB [SOSP’11][CACM’12][Oakland’13]

BlindBox & PrivMB

Ø  machine learning classificaMon over encrypted data [NDSS’15]

Ø  big data analyMcs over encrypted data Ø  support complex computaMons Ø  compress encrypted data!

Next challenge: Securing Internet-‐of-‐things

building(systemsthatcompute(on encrypteddata( mylar(iot.stanford.edu/seminar/sitp-w15-racula.pdf ·...

Documents