1 / 21

CryptDB : A Practical Encrypted Relational DBMS

CryptDB : A Practical Encrypted Relational DBMS. Raluca Ada Popa , Nickolai Zeldovich , and Hari Balakrishnan MIT CSAIL. New England Database Summit 2011. Problem: data leaks from DBs. Hackers Curious DB administrators Physical attacks Both on public clouds and private data centers

sarai
Télécharger la présentation

CryptDB : A Practical Encrypted Relational DBMS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CryptDB: A Practical Encrypted Relational DBMS RalucaAdaPopa, NickolaiZeldovich, and HariBalakrishnan MIT CSAIL New England Database Summit 2011

  2. Problem: data leaks from DBs • Hackers • Curious DB administrators • Physical attacks • Both on public clouds and private data centers • Regulatory laws

  3. Approach Perform SQL query processing on encrypted data Database server user queries Client frontend • Trusted • Stores schema, master key • No query execution • Stores the database and processes SQL queries • Not trusted to keep data private Support standard SQL queries on encrypted data Process queriescompletely at the DB server No change to existing DBMS

  4. Example 60 100 800 100 SELECT * FROM emp WHERE salary = 100 ≥ emp SELECT * FROM table1 WHERE col1 = x5a8c34 rank name salary ≥ x638e54 Frontend x934bc1 x1eab81 x4be219 x5a8c34 x638e54 x95c623 x922eb4 x5a8c34 ? x84a21c x2ea887 x638e54 x5a8c34 x17cea7 x5a8c34 x5a8c34 x638e54 ? x5a8c34 x922eb4 x5a8c34 x638e54

  5. Two techniques • SQL-aware encryption strategy • Different encryption schemes provide different functionality • Adjustable query-based encryption • Adapt encryption of data based on user queries

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

  7. Onions of encryptions RND DET RND SEARCH OPE JOIN OPE-JOIN HOM Any value Any value int value Onion 1 Onion 2 Onion 3 • Each column has the same key in a given layer of an onion

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

  9. Example RND DET DET emp: SELECT * FROM emp WHERE salary = 100000 SEARCH rank name salary JOIN Any value UPDATE table1 SET col3onion1 = DecryptRND(key, col3onion1) SELECT * FROM table1 WHERE col3onion1 = x5a8c34

  10. JOIN needsnew crypto • Challenge: do not know which columns will be joined • Data items not revealed, cannot join without join key Col1 Col2 Join key Col1-Col2 Client Frontend = -

  11. Further components • Inserts, updates, deletes, nested queries • Indexes • Transactions, auto-increments • Optimizations to speed up performance • Not supported: A.a + A.b > B.c

  12. Security converges… • … to maximum privacy for query mix • Onion levels stripped only when new operations needed Steady State: no decryptions at server Practical: typical SQL processing on enlarged tuples

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

  14. Privacy (cont’d) • DB owner can specify minimum security level for some fields CREATE TABLE emp (SSN text ≥DET, name text, …)

  15. Implementation SQL Interface Server • No change to the DBMS • Should work on most SQL DBMS CryptDB PK tables Unmodified DBMS Query Encrypted Query Frontend CryptDB UDFs (user-defined functions) Encrypted Results Results

  16. Portability • Ported CryptDB from Postgres to MySQL with 86 lines of code • No change to MySQL • Code changed was to connect to server, UDF declarations

  17. Low overhead on TPC-C • Supports all queries in TPC-C without change Throughput loss 27%

  18. Microbenchmarks from TPC-C

  19. Adjustable encryption • Steady state of columns for TPC-C: 71% of columns remain encrypted with RND Importance of adjustable query-based encryption to privacy • In practice, we expect most sensitive fields to remain at RND or DET (e.g., credit cards)

  20. Related work • Theoretical approaches [Gennaro et al., ’10] • Inefficient • Search on encrypted data(e.g., [Chang, Mitzenmacher ‘05], [Evdokimov, Guenther ’07]) • Restricted set of queries, inefficient • Systems proposals(e.g., [Hacigumus et al., ’02]) • Lower degree of security, rewrite the DBMS, client-side processing

  21. Conclusions • CryptDB is the first practical DBMS for running most standard queries on encrypted data • Runs queries completely at server • Provides provable privacy guarantees • Modest overhead • Does not change the DBMS or client applications Thanks!

More Related