CryptDB : Protecting Confidentiality with Encrypted Query Processing

1. CryptDB: Protecting Confidentiality with Encrypted Query Processing Raluca Ada Popa, Catherine M. S. Redfield, NickolaiZeldovich, and HariBalakrishnan MIT CSAIL

2. 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 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 • Protects data of users logged out during attack, even when all servers are compromised • Limit leakage from compromised applications • Modest overhead: 26% throughput loss for TPC-C • No changes to DBMS (e.g., Postgres, MySQL)

5. Threat 1: Passive attacks to DB Server Trusted Under 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. 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

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

8. Two techniques • Use SQL-aware set of encryption schemes • Adjust encryption of database based on queries • Most SQL uses a limited set of operations

9. Encryption schemes Function Construction Scheme Highest RND none 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 see paper our new scheme e.g., >, <, ORDER BY, SORT, MAX, MIN order Boldyreva et al.’09 OPE first implementation

10. 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!

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

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

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

14. 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;

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

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

17. Challenge: data sharing SPEAKS_FOR msg_id SPEAKS_FOR msg_id • Process queries on encrypted data ENC_FOR msg_id sender msg_id message msg_id receiver Alice Bob “secret message” 5 5 Km5 Km5 Km5 • How to enforce access control cryptographically? Alice-pass Bob-pass • Capture read access policy of application at SQL level? Key chains from user passwords Annotations

18. 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 • One-key: no change to applications • Multi-user keys: annotations and login/logout

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

20. 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 newencryption schemes

21. Real queries/applications Multi-user keys One-key SELECT 1/log(series_no+1.2) … … WHERE sin(latitude + PI()) …

22. Resulting confidentiality Multi-user keys One-key Most columns at RND Most columns at OPE analyzed were less sensitive

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

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

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

26. Related work • 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])

27. Conclusions CryptDB: • 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!