Transcript CryptDB: Protecting Confidentiality with Encrypted Query Processing

CryptDB: Protecting
Confidentiality with
Encrypted Query Processing
Raluca Ada Popa, Catherine M. S. Redfield, Nickolai Zeldovich,
and Hari Balakrishnan
MIT CSAIL
Presenter Kecong Tang
DBA story

Rules
– Should never read the data.
– If you have to, FORGET them TOTALY
after you’re done!

Some Jobs need to read the data
– “hey we get data conflicted ”
– “we need you to recover some data”
– “we need a special data collection”
Problems


Online applications are vulnerable to
theft of sensitive information.
Who?
– Curious & Malicious DBA
– Attackers gain Admin or DBA level access

What?
– Confidentiality
Solutions:

CryptDB

Encrypted Query Processing
Introducing CryptDB

Encrypted database
– Nothing is pain text
– By different keys and encryptions
for different columns and users’ data
Three key ideas:

SQL-aware encryption

Adjustable query-based encryption

Chain encryption keys to user
passwords

SQL-aware encryption
– Different columns different Ops
different Encryptions
Ops: Sum, >,=,Order,Group,like…
 Data still encrypted but Operational


Adjustable query-based encryption
Type Date usually for “order by”
What if I search “2012-04-01”?
Re-encryption to the required format.

Chain encryption keys to user passwords
– Data is only availably when user login
– Different users’ data different encryption keys
This can deal with SQL injection
 Hacker will get encrypted data without keys

CryptDB’s architecture

Application server
– Normal front web page
– User login
– Key setup to Database poxy

CryptDB proxy server
– Active keys
– Annotate schema

DBMS server
– Normal DBMS with encrypted data
– User defined functions to encrypt
– Encrypted Key table

Threat 1:
DBMS server Compromise
full access DBA or attacker
usually read data
Server cannot compute the (encrypted) results

Threat 2:
All servers are compromised
Different user different key
Inactive users’ key are not available
Only logged-in users’ key can be decrypted
Case Studies



phpBB is a widely used open source
forum with a rich set of access control
settings.
HotCRP is a popular conference review
application
grad-apply is a graduate admissions
system used by MIT EECS

Limitations
Both computation and comparison
on same column
– WHERE salary > age*2+10.

Multi-principal can not encrypted to different
format
– order by date
– where date=“2012-04-01”
Contribution


Definitely improve Data Security
Prevent data leaking even the server
totally compromise
Weakness

Performance
– Frequently Re-write
Time,update 1 column in an-over-100k-lines MYSQL
table will take ???? minutes.
Harddrive life: frequently Harddrive writting

Data repair and Offical Investigate
– It takes time even they can decrypt.
Improvement

Should we open a Back Door?
– “One button to decrypt all data”…
Thanks

Questions?