CryptDB: Protecting Confidentiality with Encrypted Query Processing

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

MIT CSAIL

ApplicationDB ServerSQL

User 1

User 2

User 3

Confidential data leaks from databases E.g., Sony Playstation Network, impacted 77 million

personal information profiles

Problem

System administrator

Threat 1: passive DB server attacks

Threat 2: any attacks on all servers

Hackers

CryptDB in a nutshell Goal: protect confidentiality of data

1. Process SQL queries on encrypted data

2. Use fine-grained keys; chain these keys to user passwords based on access control

ApplicationDB ServerSQL

Threat 1: passive DB server attacks

Threat 2: any attacks on all servers

on encrypted data

User 1

User 2

User 3

1. First practical DBMS to process most SQL queries on encrypted data

Hide DB from sys. admins., outsource DB

2. Protects data of users logged out during attack, even when all servers are compromised

Limit leakage from compromised applications

3. Modest overhead: 26% throughput loss for TPC-C

Contributions

4. No changes to DBMS (e.g., Postgres, MySQL)

Threat 1: Passive attacks to DB Server

DB Servertransformed queryProxyplain query

Stores schema, master key No data storage No query execution

Under attack

Applicationdecrypted results encrypted results

Trusted

Process queries completely at the DBMS, on encrypted database

Process SQL queries on encrypted data

Encrypted DB

col1/rank col2/name

table1/emp

SELECT * FROM emp WHERE salary = 100

x934bc1x5a8c34

x5a8c34

x84a21c

SELECT * FROM table1 WHERE col3 = x5a8c34

Proxy

?x5a8c34x5a8c34

?x5a8c34x5a8c34

x4be219

x95c623

x2ea887

x17cea7

col3/salary

Application

60

100

800

100

Randomized encryption

Deterministic encryption

col1/rank col2/name

table1 (emp)

x934bc1x5a8c34

x5a8c34

x84a21cx638e54

x638e54x922eb4

x1eab81

SELECT * FROM table1

WHERE col3 ≥ x638e54Proxy

x638e54x922eb4x638e54

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

Most SQL uses a limited set of operations

2. Adjust encryption of database based on queries

Encryption schemes

e.g., =, !=, IN, COUNT, GROUP BY, DISTINCT

Scheme

RND

HOM

DET

SEARCH

JOIN

OPE

Function

none

+, *

equality

join

word search

order

Construction

AES in CBC

AES in CMC

Paillier

our new scheme

Song et al.,‘00

Boldyreva et al.’09

first implementation

e.g., >, <, ORDER BY, SORT, MAX, MIN

restricted ILIKE

Highest

Security

see paper

e.g., sum

How to encrypt each data item? 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 valueHOM

Onion Add

Onions of encryptions

value JOIN

DETRND

Onion Equality

Onion Search

Same key for all items in a column for same onion layer Start out the database with the most secure encryption

scheme

OReach value

value OPE-JOIN

OPERND

Onion Order

text valueSEARCH

Adjust encryption

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’

JOINDETRND

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’

JOINDETRND

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

• aggregation on a column HOM nothing

Confidentiality level

• equality predicate on a column DET repeats

• Never reveals plaintext

Queries encryption scheme exposed

common in practice

• no filter on a column RND nothing

amount of leakage

Encryption schemes exposed for each column are the most secure enabling queries

Application protection

DB ServerSQLProxyApplication

User 1

User 2

User 3

Arbitrary attacks on any servers

Passive attacks

User password gives access to data allowed to user by access control policy

Protects data of logged out users during attack

Challenge: data sharing

3. Process queries on encrypted data

msg_id sender receiver msg_id message

5 “secret message”5 Alice Bob

SPEAKS_FOR msg_id

SPEAKS_FOR msg_id ENC_FOR msg_id

2. Capture read access policy of application at SQL level?Annotations

Key chains from user passwords

Km5Km5 Km5

1. How to enforce access control cryptographically?

Alice-pass Bob-pass

Implementation

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

One-key: no change to applications Multi-user keys: annotations and login/logout

Evaluation

1. Does it support real queries/applications? 2. What is the resulting confidentiality?3. What is the performance overhead?

Queries not supported

More complex operators, e.g., trigonometry Operations that require combining incompatible

encryption schemes e.g., T1.a + T1.b > T2.c

Extensions: split queries, precompute columns, or add new encryption schemes

Real queries/applications

Application Total columns

Encrypted columns

phpBB 563 23HotCRP 204 22grad-apply 706 103TPC-C 92 92sql.mit.edu 128,840 128,840

Annotations + lines of code changed

3831

11300

Multi-userkeys

One-key

# cols not supported

0

0

0

0

1,094

SELECT 1/log(series_no+1.2) … … WHERE sin(latitude + PI()) …

Resulting confidentiality

Application Total columns

Encrypted columns

phpBB 563 23HotCRP 204 22grad-apply 706 103TPC-C 92 92sql.mit.edu 128,840 128,840One-key

Min levelis 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

Multi-userkeys

PerformanceDB 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

TPC-C performance

Throughput loss 26%

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

TPC-C microbenchmarks

Encrypted DBMS is practical

No cryptography at the DB server in the steady state!

Homomorphic addition

Cryptography proposals Fully homomorphic encryption (starting with [Gentry’10]) Search on encrypted data (e.g., [Song et al.,’00])

Systems proposals (e.g., [Hacigumus et al.,’02]) Lower degree of security, rewrite the DBMS, client-side

processing

Query integrity (e.g., [Nguyen et al.,’07], [Sion’05])

Related work

Conclusions

1. The first practical DBMS for running most standard queries on encrypted data

Thanks!

2. Protects data of users logged out during attack even when all servers are compromised

3. Modest overhead and no changes to DBMS

CryptDB:

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

Demo at poster session!