1 / 27

CryptDB : Protecting Confidentiality with Encrypted Query Processing

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

dneal
Download Presentation

CryptDB : Protecting Confidentiality with Encrypted Query Processing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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!

More Related