CryptDB: Protecting Confidentiality with Encrypted Query Processing - PowerPoint PPT Presentation

CS573 Data Privacy and Security CryptDB: Protecting Confidentiality with Encrypted Query Processing Li Xiong Slides credit: Raluca Ada Popa, Catherine M. S. Redfield, Nickolai Zeldovich, and Hari Balakrishnan MIT CSAIL

Problem  Confidential data leaks from databases  8M medical records compromised 2009-2011 [Homeland Sec. News Wire,’11]  2012: hackers extracted 6.5 million hashed passwords from the DB of LinkedIn  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 User 3 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 DB Server SQL Application User 2 on encrypted data User 3 Process SQL queries on encrypted data 1. Use fine-grained keys; chain these keys to user 2. 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 Modest overhead: 26% throughput loss for TPC-C 2. No changes to DBMS (e.g., Postgres, MySQL) 3. and no changes to applications

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

index salary x4be2 x95c6 query ? x2ea8 x4be2 x98aa = x17ce … x17ce x2ea8 Unencrypted FHE databases CryptDB fast fast slow high degree insecure strong security of security 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 

System Setup Trusted Under attack DB Server Proxy plain query transformed query Application Encrypted DB decrypted results encrypted results  Stores schema, master key  Process queries  No data storage completely at the DBMS,  No query execution on encrypted database  Process SQL queries on encrypted data

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

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

Two techniques 1. Use SQL-aware set of encryption schemes Most SQL uses a limited set of operations Having encryption schemes that covers most common SQL operations 2. Adjust encryption of database based on queries • Different queries required that data to be encrypted with different encryption schemes

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

JOIN  Equality checks between two columns  Do not know columns to be joined a priori! col i col j Join key col i – col j Proxy  KeyGen (sec. param): SK i (with ) - deterministic  Encrypt (SK, m, col i): C m  Token (SK, col i, col j): (t i, t j ) i ): C m (with )  Adjust (t i ,C m  Correctness: adjustment yields correct join relations

JOIN (cont’d) col i col j Join key col i – col j Proxy  Security: do not learn join relations without token  Implementation:  192 bits long, 0.52 ms encrypt, 0.56 ms adjust

OPE  Preserve the order of ciphertext to remain as they were in plaintext .  For example, for any secret key 𝐿 , if 𝑦 < 𝑧 , then 𝑃𝑄𝐹 𝐿 (𝑦) < 𝑃𝑄𝐹 𝐿 (𝑧).  if a column is encrypted with 𝑃𝑄𝐹 , the server can perform range queries when given encrypted constants 𝑃𝑄𝐹 𝐿 (𝑑 1 ) and 𝑃𝑄𝐹 𝐿 (𝑑 2 ) corresponding to the range [𝑑 1 , 𝑑 2 ].  OPE is a weaker encryption scheme than DET because it reveals order

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

Ho How to e o enc ncryp rypt t each ch da data a item? m?  Encryption schemes needed depend on queries  May not know queries ahead of time col1- col1- col1- col1- col1- col1- rank RND HOM SEARCH DET JOIN OPE ALL? ‘CEO’ ‘worker’ Leaks order!

Oni nions ons of of enc ncryp ryptions tions SEARCH text value RND RND Onion Search each DET OPE OR value JOIN OPE-JOIN value value HOM int value Onion Equality Onion Order Onion Add Idea: To stack encryption schemes into onion of encryption  Same key for all items in a column for same onion layer  Start out the database with the most secure encryption scheme

On Onio ions ns of of enc encrypti ryptions ons • Novel way to compactly store multiple ciphertexts within each other in the database and avoid expensive re-encryptions • Each value is dressed in layers of increasingly stronger encryption • Each layer of each onion enables certain kinds of functionality • For each layer of each onion, the proxy uses the same key for encrypting values in the same column and • Different keys across tables, columns, onions, and onion layers

Adjust encryption  Dynamically adjusts the layer of encryption on the DBMS server  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

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

Example (cont’d) table 1 … RND col1- col1- col1- col2- DET DET OnionEq OnionOrder OnionSearch OnionEq … JOIN DET RND RND SEARCH RND … ‘CEO’ 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

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

Evaluation Does it support real queries/applications? 1. What is the resulting confidentiality? 2. What is the performance overhead? 3.

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 Total Encrypted # cols not columns columns supported phpBB 563 23 0 0 HotCRP 204 22 0 grad-apply 706 103 0 TPC-C 92 92 1,094 sql.mit.edu 128,840 128,840 SELECT 1/log(series_no+1.2) … … WHERE sin(latitude + PI()) …

Resulting confidentiality Application Total Encrypted Min level Min level Min level columns columns is RND is DET is OPE phpBB 563 23 21 1 1 HotCRP 204 22 18 1 2 95 6 2 grad-apply 706 103 65 19 8 TPC-C 92 92 80,053 34,212 13,131 sql.mit.edu 128,840 128,840 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: CryptDB Application 1 Proxy Encrypted database CryptDB Application 2 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 ms CryptDB Max. Throughput loss 26%