Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Entity–attribute–value model wikipedia , lookup
Microsoft Access wikipedia , lookup
Functional Database Model wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Clusterpoint wikipedia , lookup
Relational model wikipedia , lookup
Database model wikipedia , lookup
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 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 User 2 Application User 3 SQL DB Server System administrator Hackers CryptDB in a nutshell Goal: protect confidentiality of data Threat 2: any attacks on all servers Threat 1: passive DB server attacks User 1 User 2 Application SQL DB Server on encrypted data User 3 1. 2. Process SQL queries on encrypted data Use fine-grained keys; chain these keys to user passwords based on access control Contributions 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 4. No changes to DBMS (e.g., Postgres, MySQL) Threat 1: Passive attacks to DB Server Trusted plain query Application decrypted results Under attack Proxy transformed query DB Server encrypted results Encrypted DB 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 Application Deterministic Randomized encryption SELECT * FROM emp WHERE salary = 100 table1/emp Proxy SELECT * FROM table1 WHERE col3 = x5a8c34 col1/rank col2/name col3/salary x934bc1 x4be219 60 x5a8c34 x95c623 100 x5a8c34 ? x84a21c x2ea887 800 x5a8c34 x5a8c34 x17cea7 100 Application Deterministic OPE (order) encryption SELECT * FROM emp WHERE salary ≥ 100 table1 (emp) Proxy SELECT * FROM table1 WHERE col3 ≥ x638e54 x638e5 4 x922eb4 x638e5 4 col1/rank col2/name col3/salary x934bc1 x1eab8 1 x5a8c34 x638e5 4 x84a21c x922eb4 100 x638e5 x5a8c34 4 100 60 800 Two techniques 1. Use SQL-aware set of encryption schemes Most SQL uses a limited set of operations 2. Adjust encryption of database based on queries Encryption schemes Highest Scheme Construction Function RND AES in CBC none HOM Paillier +, * SEARCH Song et al.,‘00 word search Security DET AES in CMC equality JOIN our new scheme join OPE Boldyreva et al.’09 order e.g., sum restricted ILIKE e.g., =, !=, IN, COUNT, GROUP BY, DISTINCT see paper e.g., >, <, ORDER BY, SORT, MAX, MIN first implementation How to encrypt each data item? Encryption schemes needed depend on queries May not know queries ahead of time col1RND rank ‘CEO’ col1HOM col1col1SEARCH DET col1JOIN col1OPE ALL? ‘worker’ Leaks order! Onions of encryptions SEARCH text value each value RND DET JOIN RND OPE OPE-JOIN value value Onion Search OR 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 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: emp: rank name salary ‘CEO’ ‘worker’ table 1: RND DET JOIN ‘CEO’ col1col1col1col2OnionEq OnionOrder OnionSearch OnionEq RND RND SEARCH RND RND RND SEARCH RND Onion Equality SELECT * FROM emp WHERE rank = ‘CEO’; … … … Example (cont’d) table 1 RND DET JOIN ‘CEO’ col1col1col1col2OnionEq OnionOrder OnionSearch OnionEq RND DET RND SEARCH RND RND DET RND SEARCH RND … … … Onion Equality SELECT * FROM emp WHERE rank = ‘CEO’; UPDATE table1 SET col1-OnionEq = Decrypt_RND(key, col1-OnionEq); SELECT * FROM table1 WHERE col1-OnionEq = xda5c0407; Confidentiality level amount of Queries encryption scheme exposed leakage Encryption schemes exposed for each column are the most secure enabling queries • 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 Application protection Arbitrary attacks on any servers User 1 User 2 Application Proxy SQL Passive attacks DB Server User 3 User password gives access to data allowed to user by access control policy Protects data of logged out users during attack Challenge: data sharing msg_id 5 SPEAKS_FOR SPEAKS_FOR msg_id msg_id sender receiver Alice Km5 5 “secret message” Km5 Km5 Alice-pass 1. Bob msg_id ENC_FOR msg_id message Bob-pass How to enforce access control cryptographically? Key chains from user passwords 2. Capture read access policy of application at SQL level? Annotations 3. Process queries on encrypted data Implementation SQL Interface Server query Application results transformed query CryptDB Proxy encrypted results Unmodified DBMS CryptDB SQL UDFs (user-defined functions) No change to the DBMS Portable: from Postgres to MySQL with 86 lines One-key: no change to applications Multi-user keys: annotations and login/logout Evaluation 1. 2. 3. Does it support real queries/applications? What is the resulting confidentiality? 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 phpBB Multi-user HotCRP keys grad-apply One-key TPC-C sql.mit.edu Total columns Encrypted columns # cols not supported Annotations + lines of code changed 563 23 0 38 204 22 0 31 706 103 0 113 92 92 0 0 128,840 128,840 1,094 0 SELECT 1/log(series_no+1.2) … … WHERE sin(latitude + PI()) … Resulting confidentiality Application Total columns Encrypted columns Min level Min level Min level is RND is OPE is DET phpBB Multi-user HotCRP keys grad-apply 563 23 21 1 1 204 22 18 1 2 706 103 95 6 2 One-key TPC-C sql.mit.edu 92 92 65 19 8 128,840 128,840 80,053 34,212 13,131 Most columns at RND Most columns at OPE analyzed were less sensitive Performance DB server throughput MySQL: Application 1 Plain database Application 2 Latency CryptDB: Application 1 Application 2 CryptDB Proxy Encrypted database CryptDB Proxy Hardware: 2.4 GHz Intel Xeon E5620 – 8 cores, 12 GB RAM TPC-C performance Latency (ms/query): 0.10 MySQL vs. 0.72 CryptDB Throughput loss 26% TPC-C microbenchmarks Homomorphic addition No cryptography at the DB server in the steady state! Encrypted DBMS is practical Related work Cryptography proposals Systems proposals (e.g., [Hacigumus et al.,’02]) Fully homomorphic encryption (starting with [Gentry’10]) Search on encrypted data (e.g., [Song et al.,’00]) Lower degree of security, rewrite the DBMS, client-side processing Query integrity (e.g., [Nguyen et al.,’07], [Sion’05]) Conclusions CryptDB: 1. 2. 3. 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!