Secure, Searchable and Efficient Cloud Storage

CryptDB: Confidentiality for Database Applications with Encrypted Query ProcessingRaluca Ada Popa, Catherine Redfield, Nickolai Zeldovich, and Hari BalakrishnanMIT CSAILBerkeley Cloud Computing Seminar, 2011

1Problem: Confidential Data LeaksApplicationDB Server

curious DB administrators

hackers curious cloud/employees physical attacks

Both on private clouds and public cloudsRegulatory lawsSQLUser 1User 2User 32CryptDBGoal: protect confidentiality of data

ApplicationDB Server

SQLThreat 1: passive attacks on DB serverThreat 2: active/passive attacks on all servers

User 1User 2User 3

Proxy

Process SQL queries on encrypted data

Capture and enforce cryptographically access control in SQL: chain keys from user passwords to data item

user password3Threat ModelConsider attacks on any part of the servers

We do not consider integrity attacksCan affect data integrity, but not confidentiality

4Threat 1: Passive attacks to DB ServerDB Server

SQLTrustedPerform SQL query processing on encrypted dataProxyapplication queries unencrypted

Stores schema, master key Decrypts results No query execution

Under attack Support standard SQL queries on encrypted data Process queries completely at the DB server No change to existing DBMS5?Examplecol1/rankcol2/nametable1 (emp)SELECT * FROM emp WHERE salary = 100

x5a8c34x934bc1x5a8c34x5a8c34x84a21cx5a8c34x638e54x638e54x922eb4x1eab81

SELECT * FROM table1 WHERE col3 = x5a8c34Proxy60100800100?x5a8c34x5a8c34x5a8c34x638e54x922eb4x638e54x4be219x95c623x2ea887x17cea7x638e54col3/salaryApplicationSQL-aware encryption strategyObs.: set of SQL operators is limitedDifferent encryption schemes provide different functionality

Adjustable query-based encryptionAdapt encryption of data based on user queries

Two techniques71. SQL-aware encryptione.g., =, !=, GROUP BY, IN, COUNT, DISTINCT HighestSchemeOperationDetails RNDNoneAES in UFE HOM+, *AES in CTR DETequalitye.g., Paillier SEARCHjoinnew JOINILIKEAmanatidis et al.07OPEorderBoldyreva et al.09e.g., >, B.cSecurity convergesOnion levels stripped only when new operations needed

Steady State: no decryptions at server

Practical: typical SQL processing on enlarged tuples aggregation on salary nothing no filter on a column nothing order predicate on name order

Confidentiality Guaranteesemp:ranknamesalaryIf query has equality predicate on name repeatsNever reveal plaintextServer cannot compute queries requiring unrequested relationships

Formal security definition and proofImplications:15Picture so far

DB Server

SQLProxy

ApplicationUser 1User 2User 3

Under attackUnder attackEach user password gives access to data allowed by access control policy of applicationThreat 2: arbitrary confidentiality attacks on any servers

16Problem: data sharingHow to capture read access policy of application at SQL granularity?

How to enforce access control cryptographically?

How to execute queries?Process on encrypted data as before!Annotations: app. policy SQL policyKey chaining from password to data item in DB17Key chaining to user passwords Enforce access control graph cryptographically

Username: AlicePassword: amplab

Username: BobPassword: clouduserid 1userid 2msgid 5SKu1 SKu2SKm5 SKm5 SKa = psswd SKb = psswdESKa[SKu1]ESKb[SKu2]ESKu1[SKm5]ESKu2[SKm5]secret message

PrincipalsAll key chaining operations done at proxy, keys stored encrypted at DB server Also use public key pair18AnnotationsObservation: Each row in certain tables naturally specifies permission flow between principalshow data should be encrypted

msgidsenderidprivmsgs_to:5196recipientid62msgidmsgtext5secret message6privmsgs:hello world19Annotations1. PrincipalsCREATE TABLE privmsgs ( msgid int, subject varchar(255)msgtext text);CREATE TABLE privmsgs_to ( msgid int, rcpt id int, sender id int,

);CREATE TABLE users ( userid int,username varchar(255),

);Securing phpBB private messages: 3. HAS_ACCESS_TO2. ENCRYPT_FORENCRYPT_FOR PRINC msgid TYPE msg, ENCRYPT_FOR PRINC msgid TYPE msg PRINC TYPES physical_user EXTERNAL; PRINC TYPES user, msg;

PRINC sender_id TYPE user HAS_ACCESS_TO PRINC msgid TYPE msg, PRINC rcpt_id TYPE user HAS_ACCESS_TO PRINC msgid TYPE msg

PRINC username TYPE physical_user HAS_ACCESS_TO PRINC userid TYPE user

20SecurityProtects data readable only by users not logged in at the moment/for the duration of an attackLeaking logged-in users data seems unavoidable because applications may perform arbitrary computations on itExample: protection even when adversary changes annotations recorded at proxy21ImplementationCryptDB ProxyUnmodified DBMS

CryptDB PK tablesCryptDB UDFs (user-defined functions)ServerQueryResultsEncrypted QueryEncrypted ResultsSQL InterfaceNo change to the DBMSPortable: from Postgres to MySQL with 86 lines

ApplicationOne-key: no change to applicationsMulti-user keys: annotations and login/logoutEvaluationMulti-key CryptDB:phpBBhotCRPMIT grad admissionsEncrypted sensitive fields

One-key CryptDB: TPC-CEncrypted all fields Supports all queries on sensitive fields Annotations can express read access control Supports all queries on all data23Application changes

400,000 lines of code24Confidentiality in the DB

All the most sensitive fields remained at RNDFields at OPE were either semi-sensitive or not sensitiveImportance of adjustable query-based encryption to confidentiality

25

Low overheadThroughput loss 27%TPC-CphpBB: throughput loss of 13%Encrypted DBMS is practical

26Theoretical approaches ([Gentry10], [Gennaro et al., 10])InefficientSearch on encrypted data (e.g., [Song et al., 00])Restricted set of queries, inefficientSystems proposals (e.g., [Hacigumus et al., 02])Lower degree of security, rewrite the DBMS, client-side processingSoftware checks (e.g., PQL, UrFlow, Resin) No protection against adversaries with complete access to servers

Related workConclusionsThe first practical DBMS for running most standard queries on encrypted dataSecures the DB server against attacks to any partOne-key solution is standaloneThanks!Protects data of logged out users even when all servers are compromisedModest overhead and minimal app. changesCryptDB:28