/
CryptDB CryptDB

CryptDB - PowerPoint Presentation

tawny-fly
tawny-fly . @tawny-fly
Follow
405 views
Uploaded On 2015-10-14

CryptDB - PPT Presentation

A Practical Encrypted Relational DBMS Raluca Ada Popa Nickolai Zeldovich and Hari Balakrishnan MIT CSAIL New England Database Summit 2011 Hackers Curious DB administrators ID: 160725

x5a8c34 queries query join queries x5a8c34 join query encryption data encrypted dbms sql privacy salary emp key server det

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document "CryptDB" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1

CryptDB

: A Practical Encrypted Relational DBMS

Raluca

Ada

Popa

,

Nickolai

Zeldovich, and Hari BalakrishnanMIT CSAIL

New England Database Summit 2011Slide2

Hackers

Curious DB administratorsPhysical attacksBoth on public clouds and private data centersRegulatory laws

Problem: data leaks from

DBsSlide3

Perform SQL

query processing on encrypted data

Approach

Client

frontend

Database server

user queries

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

queries

completely

at

the DB

server

No change

to existing

DBMSSlide4

?

Example

rank

name

salary

emp

SELECT * FROM

emp

WHERE salary = 100

x5a8c34

x934bc1

x5a8c34

x5a8c34

x84a21c

x5a8c34

x638e54

x638e54

x922eb4

x1eab81

SELECT * FROM table1 WHERE col1 = x5a8c34

Frontend

60

100

800

100

?

x5a8c34

x5a8c34

x5a8c34

x638e54

x922eb4

x638e54

x4be219

x95c623

x2ea887

x17cea7

x638e54Slide5

SQL-aware encryption strategy

Different encryption schemes provide different functionalityAdjustable query-based encryptionAdapt encryption of data based on user queriesTwo techniquesSlide6

1. SQL-aware encryption

Privacy

e.g., =

, !=, GROUP BY, IN, COUNT,

DISTINCT

Highest

Scheme

Operation

Details

RND

None

AES in UFE

HOM

+, *

AES in CTR

DET

equality

e.g.,

Paillier

SEARCH

join

new

JOIN

ILIKE

Song et al.’00

OPE

order

Boldyreva

et al.

’09

e.g., >

, <, ORDER BY, SORT, MAX,

MIN

first practical implementationSlide7

Any value

JOIN

SEARCH

DET

RND

Any value

OPE-JOIN

OPE

RND

int value

HOM

Each column has the same key in a given layer of an onion

Onion 1

Onion 2

Onion 3

Onions of

encryptionsSlide8

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 UDFSlide9

Example

SELECT * FROM emp WHERE salary = 100000

UPDATE

table1

SET col3onion1

=

DecryptRND(key

, col3onion1)

Any value

JOIN

SEARCH

DET

RND

SELECT * FROM

table1

WHERE

col3onion1

=

x

5a8c34

DET

emp

:

rank

name

salarySlide10

JOIN needs

new cryptoChallenge: do not know which columns will be joined

Col2

Col1

Client

Frontend

Join key Col1-Col2

Data items not revealed, cannot join without join key

=

-Slide11

Further components

Inserts, updates, deletes, nested queriesIndexesTransactions, auto-incrementsOptimizations to speed up performance

Not supported: A.a + A.b

> B.cSlide12

Security converges…

… to maximum privacy for query mixOnion levels stripped only when new operations needed

Steady State: no decryptions at server

Practical:

typical SQL processing on enlarged

tuplesSlide13

aggregation on

salary nothing no filter on a column nothing order predicate on name order

Privacy Guarantees

emp

:

rank

name

salary

If query has

equality predicate on name repeatsNever reveal plaintextServer cannot compute unrequested queries requiring new relationships

Formal privacy definition and proof

Implications:Slide14

Privacy (cont’d)

DB owner can specify minimum security level for some fields CREATE TABLE emp (SSN text ≥ DET, name text, …) Slide15

Implementation

Frontend

Unmodified DBMS

CryptDB PK tables

CryptDB UDFs (

user-defined functions)

Server

Query

Results

Encrypted Query

Encrypted Results

SQL Interface

No change to the DBMS

Should work on most SQL DBMSSlide16

Portability

Ported CryptDB from Postgres to MySQL with 86 lines of codeNo change to MySQLCode changed was to connect to server, UDF declarationsSlide17

Low overhead on TPC-C

Throughput loss 27%

Supports all queries in TPC-C without changeSlide18

Microbenchmarks

from TPC-CSlide19

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)Slide20

Theoretical approaches

[Gennaro et al., ’10]InefficientSearch on encrypted data (e.g., [Chang, Mitzenmacher

‘05], [Evdokimov, Guenther ’07])

Restricted set of queries, inefficientSystems proposals

(e.g., [Hacigumus et al., ’02])

Lower degree of security, rewrite the DBMS, client-side processing

Related workSlide21

Conclusions

CryptDB is the first practical DBMS for running most standard queries on encrypted dataRuns queries completely at serverProvides provable privacy guaranteesModest overheadDoes not change the DBMS or client applications

Thanks!