1. CryptDB: A Practical Encrypted Relational DBMS Raluca Ada Popa, Nickolai Zeldovich, and Hari Balakrishnan MIT CSAIL New England Database Summit 2011

2.  Hackers  Curious DB administrators  Physical attacks  Both on public clouds and private data centers  Regulatory laws

3. Perform SQL query processing on encrypted data Approach Client frontend Database server user queries  Trusted  Stores schema, master key  No query execution  Stores the database and processes SQL queries  Not trusted to keep data private 1. Support standard SQL queries on encrypted data 2. Process queries completely at the DB server 3. No change to existing DBMS

4. ? Example ranknamesalary emp SELECT * FROM emp WHERE salary = 100 x5a8c34 x934bc1 x5a8c34 x84a21c x5a8c34 ≥ x638e5 4 x922eb4 x1eab8 1 SELECT * FROM table1 WHERE col1 = x5a8c34 ≥ Frontend 60 100 800 100 ? x5a8c34 x638e5 4 x922eb4 x638e5 4 x4be219 x95c623 x2ea887 x17cea7 x638e54

5. 1.SQL-aware encryption strategy – Different encryption schemes provide different functionality 2.Adjustable query-based encryption – Adapt encryption of data based on user queries Two techniques

6. 1. SQL-aware encryption Privacy e.g., =, !=, GROUP BY, IN, COUNT, DISTINCT Highest SchemeOperationDetails RNDNone AES in UFE HOM+, * AES in CTR DETequality e.g., Paillier SEARCH joinnew JOIN ILIKE Song et al.’00 OPEorder Boldyreva et al. ’09 e.g., >, <, ORDER BY, SORT, MAX, MIN first practical implementation

7. Any value JOIN SEARCH DET RND Any value OPE-JOIN OPE RND int value HOM  Each column has the same key in a given layer of an onion Onion 1Onion 2Onion 3 Onions of encryptions

8. 2. Adjustable query-based encryption  Start out the database with the most secure encryption scheme  Adjust encryption dynamically  Strip off levels of the onions: frontend gives key to server using a UDF

9. Example SELECT * FROM emp WHERE salary = 100000 UPDATE table1 SET col3onion1 = DecryptRND(key, col3onion1) Any value JOIN SEARCH DET RND SELECT * FROM table1 WHERE col3onion1 = x 5a8c34 DET emp: ranknamesalary

10. JOIN needs new crypto  Challenge: do not know which columns will be joined Col2Col1 Client Frontend Join key Col1-Col2  Data items not revealed, cannot join without join key =-

11. Further components  Inserts, updates, deletes, nested queries  Indexes  Transactions, auto-increments  Optimizations to speed up performance  Not supported: A.a + A.b > B.c

12. Security converges…  … to maximum privacy for query mix  Onion levels stripped only when new operations needed Steady State: no decryptions at server Practical: typical SQL processing on enlarged tuples

13. aggregation on salary nothing no filter on a column nothing order predicate on name order Privacy Guarantees emp: ranknamesalary If query has equality predicate on name repeats Never reveal plaintext Server cannot compute unrequested queries requiring new relationships  Formal privacy definition and proof  Implications:

14. Privacy (cont’d)  DB owner can specify minimum security level for some fields CREATE TABLE emp (SSN text ≥ DET, name text, …)

15. Implementation Frontend Unmodified DBMS CryptDB PK tables CryptDB UDFs ( user-defined functions) Server Query Results Encrypted Query Encrypted Results SQL Interface  No change to the DBMS  Should work on most SQL DBMS

16. Portability  Ported CryptDB from Postgres to MySQL with 86 lines of code  No change to MySQL  Code changed was to connect to server, UDF declarations

17. Low overhead on TPC-C Throughput loss 27% Supports all queries in TPC-C without change

18. Microbenchmarks from TPC-C

19. Adjustable encryption  Steady state of columns for TPC-C: 71% of columns remain encrypted with RND Importance of adjustable query-based encryption to privacy  In practice, we expect most sensitive fields to remain at RND or DET (e.g., credit cards)

20.  Theoretical approaches [Gennaro et al., ’10] – Inefficient  Search on encrypted data (e.g., [Chang, Mitzenmacher ‘05], [Evdokimov, Guenther ’07]) – Restricted set of queries, inefficient  Systems proposals (e.g., [Hacigumus et al., ’02]) – Lower degree of security, rewrite the DBMS, client-side processing Related work

21. Conclusions  CryptDB is the first practical DBMS for running most standard queries on encrypted data – Runs queries completely at server – Provides provable privacy guarantees – Modest overhead – Does not change the DBMS or client applications Thanks!