CryptDB: Processing Queries on an Encrypted Database Raluca Ada - - PowerPoint PPT Presentation

CryptDB: Processing Queries on an Encrypted Database

Raluca Ada Popa, Catherine M. S. Redfield, Nickolai Zeldovich, and Hari Balakrishnan MIT CSAIL

Application DB Server

SQL User 1 User 2 User 3 } Confidential data leaks from databases (DB)

} 2012: hackers extracted 6.5 million hashed passwords

from the DB of LinkedIn

Problem ¡

System administrator Threat: passive DB server attacks Hackers

} Process SQL queries on encrypted data

• 1. First practical DBMS to process most SQL queries on

encrypted data

Hide DB from sys. admins., outsource DB to the cloud

2.

Modest overhead: 26% throughput loss for TPC-C

Contribu.ons ¡

3.

No changes to DBMS (e.g., Postgres, MySQL) and no changes to applications

salary 60 100 800 100 100 = query ?

index

60

Unencrypted databases fast insecure FHE [Gentry’09], [GHS’12],..

… 100 800 salary xa32601 x8199f3 x62d03b xcef3f7 …

circuit C

• utput

slow strong security

salary x4be2 x95c6 x2ea8 x17ce x98aa = query ?

index

x4be2 … x17ce x2ea8

CryptDB fast high degree

• f security

query input x24ab1c

Most SQL uses a limited set of operations Security: Reveal only relations among data that are required by queries at column granularity

Unencrypted databases fast insecure FHE slow strong security

salary x4be2 x95c6 x2ea8 x17ce x98aa = query ?

index

x4be2 … x17ce x2ea8

CryptDB fast high degree

• f security

Other ¡work: ¡weaker ¡security, ¡func.onality, ¡and/or ¡efficiency: ¡

Ø

Search ¡on ¡encrypted ¡data ¡(e.g., ¡[Song ¡et ¡al.,’00]) ¡

Ø

Systems ¡proposals ¡(e.g., ¡[Hacigumus ¡et ¡al.,’02]) ¡

Ø

Require ¡significant ¡client-­‑side ¡processing ¡

¡

System ¡Setup ¡

DB Server

transformed query

Proxy

plain query

Ø Stores schema, master key Ø No data storage Ø No query execution

Under passive attack

Application decrypted results encrypted results

Trusted

Ø Process queries

completely at the DBMS,

• n encrypted database

Encrypted DB

col1/rank col2/name table1/emp SELECT * FROM emp WHERE salary = 100 x934bc1 x5a8c34 x5a8c34 x84a21c SELECT * FROM table1 WHERE col3 = x5a8c34 Proxy

?

x5a8c34 x5a8c34

?

x5a8c34 x5a8c34 x4be219 x95c623 x2ea887 x17cea7 col3/salary Application 60 100 800 100

Randomized encryption Deterministic encryption

col1/rank col2/name table1 (emp) x934bc1 x5a8c34 x5a8c34 x84a21c x638e54 x638e54 x922eb4 x1eab81 SELECT * FROM table1 WHERE col3 ≥ x638e54 Proxy x638e54 x922eb4 x638e54 col3/salary Application 60 100 800 100

Deterministic encryption

SELECT * FROM emp WHERE salary ≥ 100

OPE (order) encryption

• 1. Use SQL-aware set of encryption schemes

¡ ¡

Two techniques

¡

• 2. Adjust encryption of database based on

queries

¡

Encryp.on ¡schemes ¡

e.g., =, !=, IN, COUNT, GROUP BY, DISTINCT Scheme RND HOM DET SEARCH JOIN OPE Function none + equality join word search

• rder

Construction AES in CBC AES in CMC Paillier

• ur new scheme

Song et al.,‘00

BCLO’09

e.g., >, <, ORDER BY, SORT, MAX, MIN, GREATEST restricted ILIKE

Highest Security

e.g., sum + our new scheme

} Adjust (ti,Cm i): Cm (with ) } Encrypt (SK, m, col i): Cm i (with ) - deterministic

JOIN

} Do not know columns to be joined a priori! col j col i Proxy Join key col i – col j

} KeyGen (sec. param): SK } Token (SK, col i, col j): (ti, tj)

JOIN (cont’d)

¡

} Security: do not learn join relations without token } Implementation: } 192 bits long, 0.52 ms encrypt, 0.56 ms adjust

col j col i Proxy Join key col i – col j

Encryp.on ¡schemes ¡

Scheme RND HOM DET SEARCH JOIN OPE Function none +, * equality join word search

• rder

Construction AES in CBC AES in CMC Paillier

• ur new scheme

Song et al.,‘00

Boldyreva et al.’09

Highest Security

+ our new scheme

Functionality

How to to encrypt t each data ta ite tem?

Ø ¡Encryption schemes needed depend on queries

Ø May not know queries ahead of time

Leaks order!

rank

ALL?

col1- RND col1- HOM col1- SEARCH col1- DET col1- JOIN col1- OPE ‘CEO’ ‘worker’

int value

HOM Onion Add

Onions of encrypti tions

value

JOIN DET RND Onion Equality Onion Search

Ø ¡Same ¡key ¡for ¡all ¡items ¡in ¡a ¡column ¡for ¡same ¡onion ¡layer ¡ Ø ¡Start ¡out ¡the ¡database ¡with ¡the ¡most ¡secure ¡encryp.on ¡ scheme ¡

OR each value

value

OPE-JOIN OPE RND Onion Order

text value

SEARCH

Adjust ¡encryp.on ¡

Ø Strip off layers of the onions Ø Proxy gives keys to server using a SQL UDF

(“user-defined function”)

Ø Proxy remembers onion layer for columns Ø Do not put back onion layer

¡

Example: ¡

SELECT ¡* ¡FROM ¡emp ¡WHERE ¡rank ¡= ¡‘CEO’; ¡

emp: rank name salary ‘CEO’ ‘worker’

‘CEO’

JOIN DET RND Onion Equality col1- OnionEq col1- OnionOrder col1- OnionSearch col2- OnionEq table 1:

… … …

RND RND SEARCH RND SEARCH RND RND RND

Example ¡(cont’d) ¡

UPDATE table1 SET col1-OnionEq = Decrypt_RND(key, col1-OnionEq);

‘CEO’

JOIN DET RND

SELECT * FROM table1 WHERE col1-OnionEq = xda5c0407;

DET Onion Equality RND RND

SELECT ¡* ¡FROM ¡emp ¡WHERE ¡rank ¡= ¡‘CEO’; ¡

DET DET col1- OnionEq col1- OnionOrder col1- OnionSearch col2- OnionEq table 1

… … …

RND RND SEARCH RND SEARCH RND

Ø Encryption schemes exposed for each column are the

most secure enabling queries Ø Overall: Reveal only data relations needed for query type, at column granularity

• aggregation on a column HOM nothing

Security ¡guarantees ¡

• equality predicate on a column DET repeats
• Never reveals plaintext

Queries encryption schemes leakage

common in practice

• no filter on a column RND nothing

Security ¡threshold ¡

RND HOM SEARCH DET DETJOIN OPE OPEJOIN virtually nothing Plaintext repeats

• rder

everything Leakage:

SSN column Threshold

Most sensitive columns naturally stay above threshold.

≥ repeats

Implementa.on ¡

CryptDB Proxy

Unmodified DBMS CryptDB SQL UDFs (user-defined

functions)

Server

query results transformed query encrypted results

SQL Interface

Ø No ¡change ¡to ¡the ¡DBMS ¡ Ø Portable: ¡from ¡Postgres ¡to ¡MySQL ¡with ¡86 ¡lines ¡

Application

Ø No ¡change ¡to ¡applica.ons ¡

Evalua.on ¡

¡

1.

Does ¡it ¡support ¡real ¡queries/applica.ons? ¡ ¡

2.

What ¡is ¡the ¡resul.ng ¡confiden.ality? ¡

3.

What ¡is ¡the ¡performance ¡overhead? ¡

Queries ¡not ¡supported ¡

¡

Ø More ¡complex ¡operators, ¡e.g., ¡trigonometry ¡ Ø ¡Opera.ons ¡that ¡require ¡combining ¡encryp.on ¡

schemes ¡

Ø e.g., ¡T1.a ¡+ ¡T1.b ¡> ¡T2.c ¡

¡

¡

¡ ¡ ¡ ¡Extensions: ¡split ¡queries, ¡precompute ¡ columns, ¡use ¡FHE ¡or ¡other ¡encryp.on ¡ schemes ¡

Real ¡queries/applica.ons ¡

Applica.on ¡ Total ¡ columns ¡ Encrypted ¡ columns ¡ phpBB ¡ 563 ¡ 23 ¡ HotCRP ¡ 204 ¡ 22 ¡ grad-­‑apply ¡ 706 ¡ 103 ¡ TPC-­‑C ¡ 92 ¡ 92 ¡ sql.mit.edu ¡ 128,840 ¡ 128,840 ¡ # ¡cols ¡not ¡ supported ¡ 0 ¡ 0 ¡ 0 ¡ 0 ¡ 1,094 ¡

SELECT ¡1/log(series_no+1.2) ¡… ¡ ¡ … ¡WHERE ¡sin(la.tude ¡+ ¡PI()) ¡… ¡ ¡

Resul.ng ¡confiden.ality ¡

Applica.on ¡ Total ¡ columns ¡ Encrypted ¡ columns ¡ phpBB ¡ 563 ¡ 23 ¡ HotCRP ¡ 204 ¡ 22 ¡ grad-­‑apply ¡ 706 ¡ 103 ¡ TPC-­‑C ¡ 92 ¡ 92 ¡ sql.mit.edu ¡ 128,840 ¡ 128,840 ¡ Min ¡level ¡ is ¡RND ¡ 21 ¡ 18 ¡ 95 ¡ 65 ¡ 80,053 ¡ Min ¡level ¡ is ¡DET ¡ 1 ¡ 1 ¡ 6 ¡ 19 ¡ 34,212 ¡ Min ¡level ¡ is ¡OPE ¡ 1 ¡ 2 ¡ 2 ¡ 8 ¡ 13,131 ¡ Most columns at RND Most columns at OPE analyzed were less sensitive

Performance ¡

DB server throughput

CryptDB Proxy Encrypted database Application 1

CryptDB:

Plain database Application 1

MySQL:

CryptDB Proxy Application 2 Application 2

Latency

Ø Hardware: ¡2.4 ¡GHz ¡Intel ¡Xeon ¡E5620 ¡– ¡8 ¡cores, ¡12 ¡GB ¡RAM ¡

10000 20000 30000 40000 50000 1 2 3 4 5 6 7 8 Queries / sec Number of server cores MySQL CryptDB

TPC-­‑C ¡performance ¡

Throughput loss 26%

Ø Latency ¡(ms/query): ¡0.10 ¡MySQL ¡vs. ¡0.72 ¡CryptDB ¡

TPC-­‑C ¡microbenchmarks ¡

CryptDB is practical

2000 4000 6000 8000 10000 12000 14000 E q u a l i t y J

• i

n R a n g e D e l e t e I n s e r t U p d . s e t U p d . i n c S u m Queries / sec MySQL CryptDB

No cryptography at the DB server in the steady state! Homomorphic addition

Demo ¡

Conclusions ¡

1.

The ¡first ¡prac.cal ¡DBMS ¡for ¡running ¡most ¡standard ¡ queries ¡on ¡encrypted ¡data ¡

Thanks!

2.

Modest ¡overhead ¡and ¡no ¡changes ¡to ¡DBMS ¡

CryptDB:

Website: http://css.csail.mit.edu/cryptdb/