Transcript CryptDB: Protecting Confidentiality with Encrypted Query Processing Raluca Ada Popa, Catherine M.

CryptDB: Protecting Confidentiality with
Encrypted Query Processing
Raluca Ada Popa, Catherine M. S. Redfield,
Nickolai Zeldovich, and Hari Balakrishnan
MIT CSAIL
Problem

Confidential data leaks from databases

E.g., Sony Playstation Network, impacted 77 million
personal information profiles
Threat 2: any attacks on all servers
Threat 1: passive
DB server attacks
User 1
User 2
Application
User 3
SQL
DB Server
System
administrator
Hackers
CryptDB in a nutshell

Goal: protect confidentiality of data
Threat 2: any attacks on all servers
Threat 1: passive DB
server attacks
User 1
User 2
Application
SQL
DB Server
on encrypted data
User 3
1.
2.
Process SQL queries on encrypted data
Use fine-grained keys; chain these keys to user
passwords based on access control
Contributions
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
4.
No changes to DBMS (e.g., Postgres, MySQL)
Threat 1: Passive attacks to DB Server
Trusted
plain query
Application
decrypted results
Under attack
Proxy
transformed query
DB Server
encrypted results Encrypted DB
Stores schema, master key
 No data storage
 No query execution


Process queries
completely at the DBMS,
on encrypted database

Process SQL queries on encrypted data
Application
Deterministic
Randomized
encryption
SELECT * FROM emp
WHERE salary = 100
table1/emp
Proxy
SELECT * FROM table1
WHERE col3 = x5a8c34
col1/rank col2/name col3/salary
x934bc1
x4be219
60
x5a8c34
x95c623
100
x5a8c34
?
x84a21c
x2ea887
800
x5a8c34
x5a8c34
x17cea7
100
Application
Deterministic
OPE (order)
encryption
SELECT * FROM emp
WHERE salary ≥ 100
table1 (emp)
Proxy
SELECT * FROM table1
WHERE col3 ≥ x638e54
x638e5
4
x922eb4
x638e5
4
col1/rank col2/name col3/salary
x934bc1
x1eab8
1
x5a8c34
x638e5
4
x84a21c
x922eb4
100
x638e5
x5a8c34
4
100
60
800
Two techniques
1. Use SQL-aware set of encryption schemes
Most SQL uses a limited set of operations
2. Adjust encryption of database based on
queries
Encryption schemes
Highest
Scheme
Construction
Function
RND
AES in CBC
none
HOM
Paillier
+, *
SEARCH
Song et al.,‘00 word search
Security
DET
AES in CMC
equality
JOIN
our new scheme
join
OPE
Boldyreva et al.’09
order
e.g., sum
restricted ILIKE
e.g., =, !=, IN,
COUNT, GROUP
BY, DISTINCT
see paper
e.g., >, <, ORDER
BY, SORT, MAX,
MIN
first implementation
How to encrypt each data item?
 Encryption schemes needed depend on queries
 May not know queries ahead of time
col1RND
rank
‘CEO’
col1HOM
col1col1SEARCH DET
col1JOIN
col1OPE
ALL?
‘worker’
Leaks order!
Onions of encryptions
SEARCH
text value
each
value
RND
DET
JOIN
RND
OPE
OPE-JOIN
value
value
Onion Search
OR
HOM
int value
Onion Equality
Onion Order
Onion Add
 Same key for all items in a column for same onion layer
 Start out the database with the most secure encryption
scheme
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:
emp:
rank
name
salary
‘CEO’
‘worker’
table 1:
RND
DET
JOIN
‘CEO’
col1col1col1col2OnionEq OnionOrder OnionSearch OnionEq
RND
RND
SEARCH
RND
RND
RND
SEARCH
RND
Onion Equality
SELECT * FROM emp WHERE rank = ‘CEO’;
…
…
…
Example (cont’d)
table 1
RND
DET
JOIN
‘CEO’
col1col1col1col2OnionEq OnionOrder OnionSearch OnionEq
RND
DET
RND
SEARCH
RND
RND
DET
RND
SEARCH
RND
…
…
…
Onion Equality
SELECT * FROM emp WHERE rank = ‘CEO’;
UPDATE table1 SET col1-OnionEq =
Decrypt_RND(key, col1-OnionEq);
SELECT * FROM table1 WHERE col1-OnionEq = xda5c0407;
Confidentiality level
amount of
Queries
encryption scheme exposed
leakage
 Encryption schemes exposed for each column are the
most secure enabling queries
• equality predicate on a column
DET
repeats
• aggregation on a column
HOM
nothing
• no filter on a column
RND
nothing
common in practice
•
Never reveals plaintext
Application protection
Arbitrary attacks on any servers
User 1
User 2
Application
Proxy
SQL
Passive attacks
DB Server
User 3


User password gives access to data allowed to user by
access control policy
Protects data of logged out users during attack
Challenge: data sharing
msg_id
5
SPEAKS_FOR SPEAKS_FOR
msg_id
msg_id
sender
receiver
Alice
Km5
5
“secret message”
Km5
Km5
Alice-pass
1.
Bob
msg_id
ENC_FOR msg_id
message
Bob-pass
How to enforce access control cryptographically?
Key chains from user passwords
2.
Capture read access policy of application at SQL level?
Annotations
3.
Process queries on encrypted data
Implementation
SQL Interface
Server
query
Application
results
transformed query
CryptDB
Proxy
encrypted results
Unmodified
DBMS
CryptDB
SQL UDFs
(user-defined
functions)




No change to the DBMS
Portable: from Postgres to MySQL with 86 lines
One-key: no change to applications
Multi-user keys: annotations and login/logout
Evaluation
1.
2.
3.
Does it support real queries/applications?
What is the resulting confidentiality?
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
phpBB
Multi-user
HotCRP
keys
grad-apply
One-key TPC-C
sql.mit.edu
Total
columns
Encrypted
columns
# cols not
supported
Annotations + lines
of code changed
563
23
0
38
204
22
0
31
706
103
0
113
92
92
0
0
128,840
128,840
1,094
0
SELECT 1/log(series_no+1.2) …
… WHERE sin(latitude + PI()) …
Resulting confidentiality
Application
Total
columns
Encrypted
columns
Min level Min level Min level
is RND
is OPE
is DET
phpBB
Multi-user
HotCRP
keys
grad-apply
563
23
21
1
1
204
22
18
1
2
706
103
95
6
2
One-key TPC-C
sql.mit.edu
92
92
65
19
8
128,840
128,840
80,053
34,212
13,131
Most columns at RND Most columns at
OPE analyzed
were less sensitive
Performance
DB server throughput
MySQL:
Application 1
Plain
database
Application 2
Latency
CryptDB:
Application 1
Application 2

CryptDB
Proxy
Encrypted
database
CryptDB
Proxy
Hardware: 2.4 GHz Intel Xeon E5620 – 8 cores, 12 GB RAM
TPC-C performance

Latency (ms/query): 0.10 MySQL vs. 0.72 CryptDB
Throughput
loss 26%
TPC-C microbenchmarks
Homomorphic
addition
No cryptography at the DB server in the steady state!
Encrypted DBMS is practical
Related work

Cryptography proposals



Systems proposals (e.g., [Hacigumus et al.,’02])


Fully homomorphic encryption (starting with [Gentry’10])
Search on encrypted data (e.g., [Song et al.,’00])
Lower degree of security, rewrite the DBMS, client-side
processing
Query integrity (e.g., [Nguyen et al.,’07], [Sion’05])
Conclusions
CryptDB:
1.
2.
3.
The first practical DBMS for running most standard
queries on encrypted data
Protects data of users logged out during attack even
when all servers are compromised
Modest overhead and no changes to DBMS
Website: http://css.csail.mit.edu/cryptdb/
Demo at poster session!
Thanks!