CryptDB : Processing Queries on an Encrypted Database

1. CryptDB: Processing Queries on an Encrypted Database Raluca Ada Popa, Catherine M. S. Redfield, NickolaiZeldovich, and HariBalakrishnan MIT CSAIL

2. Problem • Confidential data leaks from databases • 8M medical records compromised 2009-2011 [Homeland Sec. News Wire,’11] • Sony Playstation Network, accessed 77 million user profiles Threat 2:any attacks on all servers Threat 1:passive DB server attacks User 1 DB Server SQL Application User 2 System administrator User 3 Hackers

3. CryptDB in a nutshell • Goal: protect confidentiality of data Threat 2: any attacks on all servers Threat 1: passive DB server attacks User 1 DB Server SQL Application User 2 on encrypted data User 3 • Process SQL queries on encrypted data • Use fine-grained keys; chain these keys to user passwords based on access control

4. Contributions • First practical DBMS to process most SQL queries on encrypted data • Hide DB from sys. admins., outsource DB to the cloud • Protects data of users logged out during attack, even when all servers are compromised • Modest overhead: 26% throughput loss for TPC-C • No changes to DBMS (e.g., Postgres, MySQL) and for threat 1, no changes to applications

5. Threat 1: Passive attacks to DB Server Trusted Under passive attack DB Server Proxy plain query transformed query Application Encrypted DB decrypted results encrypted results • 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

6. index • Most SQL uses a limited set of operations salary x4be2 • Security: Reveal only relations among data that are required by classes of queries issued x95c6 query ? x2ea8 x4be2 x98aa = x17ce … x17ce x2ea8 Unencrypted databases CryptDB FHE fast high degree of security [Gentry’09], [BV’11,12][GHS’12],.. salary index salary 60 100 query xa32601 ? circuit C x8199f3 800 query input x24ab1c 100 = 60 x62d03b 100 … xcef3f7 … 100 800 fast output insecure slow strong security

7. index salary x4be2 x95c6 query ? x2ea8 x4be2 x98aa = x17ce Other work: weaker security, functionality, and/or efficiency: • Search on encrypted data (e.g., [Song et al.,’00]) • Systems proposals (e.g., [Hacigumus et al.,’02]) • Rewrite the DBMS, significant client-side processing … x17ce x2ea8 Unencrypted databases CryptDB FHE fast fast high degree of security slow insecure strong security

8. Application Deterministic encryption Randomized encryption SELECT * FROM emp WHERE salary = 100 table1/emp SELECT * FROM table1 WHERE col3 = x5a8c34 col1/rank col2/name col3/salary Proxy x934bc1 x4be219 60 x5a8c34 100 x95c623 x84a21c x2ea887 x5a8c34 ? ? x5a8c34 800 x5a8c34 x5a8c34 x17cea7 100 x5a8c34

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

10. Two techniques • Use SQL-aware set of encryption schemes • Adjust encryption of database based on queries

11. Encryption schemes Function Construction Scheme Highest none RND AES in CBC Paillier + HOM e.g., sum word search restricted ILIKE SEARCH Song et al.,‘00 e.g., =, !=, IN, COUNT, GROUP BY, DISTINCT Security DET equality AES in CMC join JOIN our new scheme e.g., >, <, ORDER BY, SORT, MAX, MIN Boldyreva et al.’09 order OPE + our new scheme

12. JOIN • Do not know columns to be joined a priori! • Correctness: adjustment yields correct join relations coli colj Join key coli – colj Proxy • Encrypt (SK, m, coli): Cmi(with ) - deterministic • KeyGen(sec. param): SK • Token (SK, coli, colj): (ti, tj) • Adjust (ti,Cmi): Cm (with )

13. JOIN (cont’d) coli colj Join key coli – colj Proxy • Security: do not learn join relations without token • Implementation: • 192 bits long, 0.52 ms encrypt, 0.56 ms adjust

14. OPE • Only leaking order infeasible [Boldyreva et al.’09] without knowing a priori the plaintexts • Proposed weaker security, leaks half the bits • Achieve ideal-security with proxy-server interaction • Encryption: O(log N) roundtrips for N elements • Implementation: order of magnitude faster • Security: IND-OCPA

15. Encryption schemes Function Construction Scheme Highest RND none AES in CBC Paillier +, * HOM word search SEARCH Song et al.,‘00 Functionality Security DET equality AES in CMC join JOIN our new scheme Boldyreva et al.’09 order OPE + our new scheme

16. How to encrypt each data item? • Encryption schemes needed depend on queries • May not know queries ahead of time col1-RND col1-HOM col1-SEARCH col1-DET col1-JOIN col1-OPE rank ALL? ‘CEO’ ‘worker’ Leaks order!

17. Onions of encryptions SEARCH text value RND RND Onion Search each value DET OPE OR JOIN OPE-JOIN value value 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

18. 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

19. emp: Example: rank name salary ‘CEO’ ‘worker’ SELECT * FROM emp WHERE rank = ‘CEO’; table 1: … RND col1-OnionEq col1-OnionOrder col1-OnionSearch col2-OnionEq DET … JOIN RND RND SEARCH RND … ‘CEO’ RND RND SEARCH RND Onion Equality

20. Example (cont’d) table 1 … SELECT * FROM emp WHERE rank = ‘CEO’; RND col1-OnionEq col1-OnionOrder col1-OnionSearch col2-OnionEq DET DET … JOIN RND SEARCH RND RND DET … ‘CEO’ RND SEARCH RND RND DET Onion Equality UPDATE table1 SET col1-OnionEq = Decrypt_RND(key, col1-OnionEq); SELECT * FROM table1 WHERE col1-OnionEq = xda5c0407;

21. Confidentiality level • Queries encryption scheme exposed • Encryption schemes exposed for each column are the most secure enabling queries amount of leakage • 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

22. Hint about application protection Arbitrary attacks on any servers • User password gives access to data allowed to user by access control policy User 1 Passive attacks DB Server Proxy User 2 Application SQL User 3 • Protects data of logged out users during attack • Challenge: data sharing

23. Implementation SQL Interface Server • No change to the DBMS • Portable: from Postgres to MySQL with 86 lines Unmodified DBMS transformed query CryptDB SQL UDFs (user-defined functions) query CryptDB Proxy Application results encrypted results • Threat 1 solution: no change to applications

24. Evaluation • Does it support real queries/applications? • What is the resulting confidentiality? • What is the performance overhead?

25. Queries not supported • More complex operators, e.g., trigonometry • Operations that require combining encryption schemes • e.g., T1.a + T1.b > T2.c • Extensions: split queries, precompute columns, use FHE or other encryption schemes

26. Real queries/applications SELECT 1/log(series_no+1.2) … … WHERE sin(latitude + PI()) …

27. Resulting confidentiality Most columns at RND Most columns at OPE analyzed were less sensitive

28. Performance DB server throughput MySQL: Application 1 Plain database Application 2 Latency CryptDB: CryptDB Proxy Application 1 Encrypted database CryptDB Proxy Application 2 • Hardware:2.4 GHz Intel Xeon E5620 – 8 cores, 12 GB RAM

29. TPC-C performance • Latency (ms/query): 0.10MySQL vs.0.72 CryptDB Throughput loss 26%

30. TPC-C microbenchmarks Homomorphic addition No cryptography at the DB server in the steady state! Encrypted DBMS is practical

31. Conclusions • The first practical DBMS for running most standard queries on encrypted data CryptDB: • Modest overhead and no changes to DBMS Website: http://css.csail.mit.edu/cryptdb/ Thanks!