Post on 18-Dec-2015
transcript
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!