Crypt DB Confidentiality for Database Applications with Encrypted

Crypt. DB: Confidentiality for Database Applications with Encrypted Query Processing Raluca Ada Popa, Catherine Redfield, Nickolai Zeldovich, and Hari Balakrishnan MIT CSAIL Berkeley Cloud Computing Seminar, 2011

Problem: Confidential Data Leaks curious DB administrators Ø User 1 User 2 SQL Application DB Server User 3 hackers Ø curious cloud/employees Ø physical attacks Ø Both on private clouds and public clouds Regulatory laws

Crypt. DB Goal: protect confidentiality of data user password Threat 2: active/passive attacks on all servers Threat 1: passive attacks on DB server User 1 User 2 Application Proxy SQL DB Server User 3 1. 2. Process SQL queries on encrypted data Capture and enforce cryptographically access control in SQL: chain keys from user passwords to data item

Threat Model Consider attacks on any part of the servers We do not consider integrity attacks Can affect data integrity, but not confidentiality

Threat 1: Passive attacks to DB Server Trusted application queries unencrypted Proxy Under attack SQL DB Server Stores schema, master key Ø Decrypts results Ø No query execution Ø Perform SQL query processing on encrypted data Support standard SQL queries on encrypted data 2. Process queries completely at the DB server 3. No change to existing DBMS 1.

Example Application SELECT * FROM emp WHERE salary = 100 ≥ Proxy table 1 (emp) SELECT * FROM table 1 WHERE col 3 = x 5 a 8 c 34 x 638 e 54 ≥ x 638 e 5 x 5 a 8 c 3 ? 4 x 5 a 8 c 3 x 922 eb 4 4 x 5 a 8 c 3 x 638 e 5 4 60 100 800 100 col 1/rank col 2/name col 3/salary x 934 bc 1 x 1 eab 8 x 4 be 219 1 x 5 a 8 c 3 x 638 e 5 x 95 c 623 4 x 922 eb 4 x 84 a 21 x 2 ea 887 c x 638 e 5 x 5 a 8 c 3 x 17 cea 7 4

Two techniques 1. SQL-aware encryption strategy – Obs. : set of SQL operators is limited – Different encryption schemes provide different functionality 2. Adjustable query-based encryption – Adapt encryption of data based on user queries

1. SQL-aware encryption Highest Security Scheme Operation Details RND None AES in UFE HOM +, * e. g. , Paillier DET equality AES in CTR JOIN join SEARCH ILIKE OPE order e. g. , =, !=, GROUP BY, IN, COUNT, DISTINCT new Amanatidis et al. ’ 07 e. g. , >, <, ORDER BY, SORT, MAX, MIN Boldyreva et al. ’ 09 first practical implementation

Onions of encryptions Ø Significant confidentiality and space savings RND DET SEARCH JOIN RND OPE-JOIN Any value Onion 1 Onion 2 HOM int value Onion 3 Ø Each column has the same key in a given layer of an onion

2. Adjustable query-based encryption Start out the database with the most secure encryption scheme Ø Adjust encryption dynamically Ø Ø Strip off levels of the onions: proxy gives key to server using a UDF

Example RND DET emp: rank name salary SEARCH JOIN Any value SELECT * FROM emp WHERE salary = 100 UPDATE table 1 SET col 3 onion 1 = Decrypt. RND(key, col 3 onion 1) SELECT * FROM table 1 WHERE col 3 onion 1 = x 5 a 8 c 34

JOIN needs new crypto Ø Challenge: do not know which columns will be joined Col 1 Join key Col 1 -Col 2 Proxy Ø = Col 2 - Data items not revealed, cannot join without join key

Other queries Ø Various others supported: Inserts, updates, deletes, nested queries Ø Indexes Ø Transactions, auto-increments Ø Ø Not supported: A. a + A. b > B. c

Security converges Ø Onion levels stripped only when new operations needed Steady State: no decryptions at server Practical: typical SQL processing on enlarged tuples

Confidentiality Guarantees Ø Formal security definition and proof Ø Implications: emp: rank name • • salary If query has • equality predicate on name repeats • order predicate on name order • aggregation on salary nothing • no filter on a column nothing Never reveal plaintext Server cannot compute queries requiring unrequested relationships

Picture so far Under attack User 1 User 2 Application Proxy SQL Under attack DB Server User 3 Threat 2: arbitrary confidentiality attacks on any servers Ø Each user password gives access to data allowed by access control policy of application

Problem: data sharing 1. How to capture read access policy of application at SQL granularity? Annotations: app. policy 2. SQL policy How to enforce access control cryptographically? Key chaining from password to data item in DB 3. How to execute queries? Process on encrypted data as before!

Key chaining to user passwords Ø Ø Enforce access control graph cryptographically Principals userid 1 All key chaining operations done at proxy, keys stored encrypted at DB server SKu 1 Username: Alice Password: amplab ESKu 1[SKm 5] msgid 5 SKa = psswd ESKa[SKu 1] “secret message” SKm 5 userid 2 Username: Bob Password: cloud SKb = psswd ESKb[SKu 2] SKu 2 ESKu 2[SKm 5] • Also use public key pair

Annotations Ø Observation: Each row in certain tables naturally specifies 1. 2. permission flow between principals how data should be encrypted privmsgs_to: msgid senderid 5 6 1 9 privmsgs: recipientid 2 6 msgid 5 6 msgtext “secret message” “hello world”

Annotations 1. Principals 2. ENCRYPT_FOR 3. HAS_ACCESS_TO Securing php. BB private messages: PRINC TYPES physical_user EXTERNAL; PRINC TYPES user, msg; CREATE TABLE privmsgs ( msgid int, subject varchar(255) ENCRYPT_FOR PRINC msgid TYPE msg, msgtext ENCRYPT_FOR PRINC msgid TYPE msg ); CREATE TABLE privmsgs_to ( msgid int, rcpt id int, sender id int, PRINC sender_id TYPE user HAS_ACCESS_TO PRINC msgid TYPE msg, PRINC rcpt_id TYPE user HAS_ACCESS_TO PRINC msgid TYPE msg ); CREATE TABLE users ( userid int, username varchar(255), PRINC username TYPE physical_user HAS_ACCESS_TO PRINC userid TYPE user );

Security Protects data readable only by users not logged in at the moment/for the duration of an attack Ø Leaking logged-in users’ data seems unavoidable because applications may perform arbitrary computations on it Ø Example: protection even when adversary changes annotations recorded at proxy Ø

Implementation SQL Interface Query Application Crypt. DB Results Proxy Server Encrypted Query Encrypted Results Unmodified DBMS Crypt. DB PK tables Crypt. DB UDFs (user-defined functions) Ø Ø No change to the DBMS Portable: from Postgres to My. SQL with 86 lines One-key: no change to applications Multi-user keys: annotations and login/logout

Evaluation Ø Multi-key Crypt. DB: Ø Ø Ø php. BB hot. CRP MIT grad admissions Encrypted sensitive fields One-key Crypt. DB: Ø Ø TPC-C Encrypted all fields Supports all queries on sensitive fields Ø Annotations can express read access control Ø Ø Supports all queries on all data

Application changes 400, 000 lines of code

Confidentiality in the DB All the most sensitive fields remained at RND Fields at OPE were either semisensitive or not sensitive Importance of adjustable query-based encryption to confidentiality

Low overhead TPC-C Throughput loss 27% Ø php. BB: throughput loss of 13% Encrypted DBMS is practical

Related work Ø Theoretical approaches ([Gentry’ 10], [Gennaro et al. , ’ 10]) – Inefficient Ø Search on encrypted data (e. g. , [Song et al. , ’ 00]) – Restricted set of queries, inefficient Ø Systems proposals (e. g. , [Hacigumus et al. , ’ 02]) – Lower degree of security, rewrite the DBMS, client-side processing Ø Software checks (e. g. , PQL, Ur. Flow, Resin) – No protection against adversaries with complete access to servers

Conclusions Crypt. DB: 1. The first practical DBMS for running most standard queries on encrypted data Secures the DB server against attacks to any part Ø One-key solution is standalone Ø 2. 3. Protects data of logged out users even when all servers are compromised Modest overhead and minimal app. changes Thanks!