CryptDB: Processing Queries on an Encrypted Database Raluca Ada - PowerPoint PPT Presentation

CryptDB: Processing Queries on an Encrypted Database Raluca Ada Popa, Catherine M. S. Redfield, Nickolai Zeldovich, and Hari Balakrishnan MIT CSAIL

Problem ¡ } Confidential data leaks from databases (DB) } 2012: hackers extracted 6.5 million hashed passwords from the DB of LinkedIn Threat: passive DB server attacks User 1 DB Server SQL Application User 2 User 3 System administrator Hackers } Process SQL queries on encrypted data

Contribu.ons ¡ 1. First practical DBMS to process most SQL queries on encrypted data Hide DB from sys. admins., outsource DB to the cloud Modest overhead: 26% throughput loss for TPC-C 2. No changes to DBMS (e.g., Postgres, MySQL) 3. and no changes to applications

index salary Most SQL uses a limited set of operations x4be2 x95c6 query Security: Reveal only ? x2ea8 x4be2 x98aa = relations among data that x17ce are required by queries at column granularity … x17ce x2ea8 Unencrypted FHE databases CryptDB fast [Gentry’09], [GHS’12],.. 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, ¡func.onality, ¡and/or ¡efficiency: ¡ Search ¡on ¡encrypted ¡data ¡(e.g., ¡[Song ¡et ¡al.,’00]) ¡ Ø Systems ¡proposals ¡(e.g., ¡[Hacigumus ¡et ¡al.,’02]) ¡ Ø Require ¡significant ¡client-­‑side ¡processing ¡ Ø ¡

System ¡Setup ¡ Trusted Under passive 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

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 ? ? x2ea887 x5a8c34 x5a8c34 800 x5a8c34 x17cea7 x5a8c34 100 x5a8c34

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 x1eab81 x934bc1 60 x5a8c34 x638e54 100 x922eb4 x84a21c 800 x638e54 x5a8c34 100 x638e54 x922eb4 x638e54

Two techniques 1. Use SQL-aware set of encryption schemes ¡ ¡ 2. Adjust encryption of database based on ¡ queries ¡

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

JOIN } Do not know columns to be joined a priori! col i col j Join key col i – col j Proxy } KeyGen (sec. param): SK } Encrypt (SK, m, col i): C m i (with ) - deterministic } Token (SK, col i, col j): (t i, t j ) } Adjust (t i ,C m i ): C m (with )

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 ¡

Encryp.on ¡schemes ¡ Construction Function 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

How to to encrypt t each data ta ite tem? Ø ¡ 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!

Onions of encrypti 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 Ø ¡Same ¡key ¡for ¡all ¡items ¡in ¡a ¡column ¡for ¡same ¡onion ¡layer ¡ Ø ¡Start ¡out ¡the ¡database ¡with ¡the ¡most ¡secure ¡encryp.on ¡ scheme ¡

Adjust ¡encryp.on ¡ Ø 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 RND DET RND SEARCH RND … ‘CEO’ DET RND 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;

Security ¡guarantees ¡ Queries encryption schemes leakage Ø Encryption schemes exposed for each column are the most secure enabling queries Ø Overall: Reveal only data relations needed for query type, at column granularity • 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

Security ¡threshold ¡ SSN column ≥ repeats RND Leakage: virtually HOM nothing SEARCH DET repeats DETJOIN Threshold OPE order OPEJOIN Most sensitive columns naturally stay above threshold. everything Plaintext

Implementa.on ¡ 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 ¡applica.ons ¡

Evalua.on ¡ ¡ Does ¡it ¡support ¡real ¡queries/applica.ons? ¡ ¡ 1. What ¡is ¡the ¡resul.ng ¡confiden.ality? ¡ 2. What ¡is ¡the ¡performance ¡overhead? ¡ 3.

Queries ¡not ¡supported ¡ ¡ Ø More ¡complex ¡operators, ¡e.g., ¡trigonometry ¡ Ø ¡Opera.ons ¡that ¡require ¡combining ¡encryp.on ¡ schemes ¡ Ø e.g., ¡T1.a ¡+ ¡T1.b ¡> ¡T2.c ¡ ¡ ¡ ¡ ¡ ¡ ¡Extensions: ¡split ¡queries, ¡precompute ¡ columns, ¡use ¡FHE ¡or ¡other ¡encryp.on ¡ schemes ¡

Real ¡queries/applica.ons ¡ Applica.on ¡ 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(la.tude ¡+ ¡PI()) ¡… ¡ ¡

Resul.ng ¡confiden.ality ¡ Applica.on ¡ Total ¡ Encrypted ¡ Min ¡level ¡ Min ¡level ¡ Min ¡level ¡ columns ¡ columns ¡ is ¡RND ¡ is ¡DET ¡ is ¡OPE ¡ phpBB ¡ 563 ¡ 23 ¡ 21 ¡ 1 ¡ 1 ¡ 18 ¡ 1 ¡ 2 ¡ HotCRP ¡ 204 ¡ 22 ¡ 95 ¡ 6 ¡ 2 ¡ grad-­‑apply ¡ 706 ¡ 103 ¡ 65 ¡ 19 ¡ 8 ¡ TPC-­‑C ¡ 92 ¡ 92 ¡ 80,053 ¡ 13,131 ¡ sql.mit.edu ¡ 128,840 ¡ 128,840 ¡ 34,212 ¡ 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 ¡CryptDB ¡ 50000 40000 Queries / sec Throughput 30000 loss 26% 20000 10000 MySQL CryptDB 0 1 2 3 4 5 6 7 8 Number of server cores

TPC-­‑C ¡microbenchmarks ¡ 14000 MySQL CryptDB 12000 10000 Queries / sec Homomorphic 8000 addition 6000 4000 2000 0 E J R D I U U S o n u q a e p p i s m u n n l e d d e a g r . . t t l e e s i i n t e y c t No cryptography at the DB server in the steady state! CryptDB is practical

Demo ¡