Transcript App Security - Duke Computer Science

Application Security
Lecture 27
Aditya Akella
Why is this important?
https://blog.cloudsecurityalliance.org/2011/01/27/moving-to-the-cloud-take-your-application-security-with-you/
• Web Applications are the primary attack
target
• Common approach: attack web site; steal
data; abuse it
– E.g., Sony Playstation Network, impacted 77
million personal information profiles
– “…an attacker used SQL injection to steal credit
/debit card numbers that were then used to steal
more than $1 million from ATMs worldwide.”
Before the Cloud
• “Fence your network”
– Narrows down to insider attacks
• Not possible any more!
– Organizations’ security teams don’t have enough
visibility/control into network actions/configuration
• Can’t observe attack in progress
– IPS/IDS in the provider’s hands, especially for
SaaS systems
• Key: push security into the app!
CryptDB Focus

Protect against confidential data leaks from
databases
Threat 2: any attacks on all servers
Threat 1: passive DB
server attacks
User 1
User 2
Application
User 3
Hackers
SQL
DB Server
System
administrator
CryptDB in a nutshell

Goal: protect confidentiality of data
Threat 2: any attacks on all servers
Threat 1: passive DB
server attacks
User 1
User 2
Application
SQL
DB Server
on encrypted data
User 3
1.
2.
Process SQL queries on encrypted data
Use fine-grained keys; chain these keys to user
passwords based on access control
Contributions
1.
First practical DBMS to process most SQL queries
on encrypted data
Hide DB from sys. admins., outsource DB
2.
Protects data of users logged out during attack,
even when all servers are compromised
Limit leakage from compromised applications
3.
Modest overhead: 26% throughput loss for TPC-C
4.
No changes to DBMS (e.g., Postgres, MySQL)
Threat 1: Passive attacks to DB Server
Trusted
Application
plain query
decrypted results
Under attack
Proxy
transformed query
encrypted results
Stores schema, master key
 No data storage
 No query execution
DB Server
Encrypted DB


Process queries completely
at the DBMS, on encrypted
database

Process SQL queries on encrypted data
Application
Deterministic
Randomized
encryption
SELECT * FROM emp
WHERE salary = 100
table1/emp
Proxy
SELECT * FROM table1
WHERE col3 = x5a8c34
col1/rank col2/name col3/salary
x934bc1
x4be219
60
x5a8c34
x95c623
100
x5a8c34
?
x84a21c
x2ea887
800
x5a8c34
x5a8c34
x17cea7
100
Application
Deterministic
OPE (order)
encryption
SELECT * FROM emp
WHERE salary ≥ 100
Proxy
table1 (emp)
SELECT * FROM table1
WHERE col3 ≥ x638e54
x638e5
4
x922eb4
x638e5
4
col1/rank col2/name col3/salary
x934bc1
x1eab8
1
x5a8c34
x638e5
4
x84a21c
x922eb4
100
x638e5
x5a8c34
4
100
60
800
Two techniques
1. Use SQL-aware set of encryption schemes
Most SQL uses a limited set of operations
2. Adjust encryption of database based on
queries
Encryption schemes
Highest
Scheme
Construction
Function
RND
AES in CBC
none
HOM
Paillier
+, *
SEARCH
Song et al.,‘00 word search
Security
DET
JOIN
OPE
AES in CMC
new scheme
Boldyreva et al.’09
equality
e.g., sum
restricted ILIKE
e.g., =, !=, IN, COUNT,
GROUP BY, DISTINCT
join
order
e.g., >, <, ORDER BY,
SORT, MAX, MIN
How to encrypt each data item?
 Encryption schemes needed depend on queries
 May not know queries ahead of time
col1RND
rank
‘CEO’
col1HOM
col1SEARCH
col1DET
col1JOIN
col1OPE
ALL?
‘worker’
Leaks order!
Onions of encryptions
SEARCH
text value
each
value
RND
DET
JOIN
RND
OPE
OPE-JOIN
value
value
Onion Search
OR
HOM
int value
Onion Equality
Onion Order
Onion Add
 Same key for all items in a column for same onion layer
 Start out the database with the most secure encryption
scheme
Adjust encryption
Strip off layers of the onions
 Proxy gives keys to server using a SQL UDF
(“user-defined function”)
 Proxy remembers onion layer for columns
 Do not put back onion layer

emp:
Example:
rank
name
salary
‘CEO’
‘worker’
table 1:
RND
DET
JOIN
col1OnionEq
‘CEO’
col1OnionOrder
col1OnionSearch
col2OnionEq
RND
RND
SEARCH
RND
RND
RND
SEARCH
RND
Onion Equality
SELECT * FROM emp WHERE rank = ‘CEO’;
…
…
…
Example (cont’d)
table 1
RND
DET
JOIN
‘CEO’
col1OnionEq
col1col1OnionOrder OnionSearch
col2OnionEq
RND
DET
RND
SEARCH
RND
RND
DET
RND
SEARCH
RND
…
…
…
Onion Equality
SELECT * FROM emp WHERE rank = ‘CEO’;
UPDATE table1 SET col1-OnionEq =
Decrypt_RND(key, col1-OnionEq);
SELECT * FROM table1 WHERE col1-OnionEq = xda5c0407;
Confidentiality level
amount of
Queries encryption scheme exposed
leakage
 Encryption schemes exposed for each column are the most
secure enabling queries
• equality predicate on a column
DET
repeats
• aggregation on a column
HOM
nothing
• no filter on a column
RND
common in practice
•
Never reveals plaintext
nothing
Application protection
Arbitrary attacks on any servers
User 1
User 2
Application
Proxy
SQL
Passive attacks
DB Server
User 3


User password gives access to data allowed to user by
access control policy
Protects data of logged out users during attack
Challenge: data sharing
msg_id
SPEAKS_FOR
msg_id
sender
5
Alice
Km5
1.
Alice-pass
SPEAKS_FOR
msg_id
receiver
msg_id
Bob
Km5
5
ENC_FOR msg_id
message
“secret message”
Km5
Bob-pass
How to enforce access control cryptographically?
Key chains from user passwords
2.
Capture read access policy of application at SQL level?
Annotations
3.
Process queries on encrypted data
Implementation
SQL Interface
query
Application
results
Server
transformed query
CryptDB
Proxy
encrypted results
Unmodified
DBMS
CryptDB
SQL UDFs
(user-defined
functions)




No change to the DBMS
Portable: from Postgres to MySQL with 86 lines
One-key: no change to applications
Multi-user keys: annotations and login/logout
Queries not supported


More complex operators, e.g., trigonometry
Operations that require combining incompatible
encryption schemes

e.g., T1.a + T1.b > T2.c
Extensions: split queries, precompute
columns, or add new encryption schemes
Real queries/applications
Application
phpBB
Multi-user
HotCRP
keys
grad-apply
One-key TPC-C
sql.mit.edu
Total
columns
Encrypted
columns
# cols not
supported
Annotations + lines
of code changed
563
23
0
38
204
22
0
31
706
103
0
113
92
92
0
0
128,840
128,840
1,094
0
SELECT 1/log(series_no+1.2) …
… WHERE sin(latitude + PI()) …
Resulting confidentiality
Application
Total
columns
Encrypted
columns
Min level Min level Min level
is RND
is OPE
is DET
phpBB
Multi-user
HotCRP
keys
grad-apply
563
23
21
1
1
204
22
18
1
2
706
103
95
6
2
One-key TPC-C
sql.mit.edu
92
92
65
19
8
128,840
128,840
80,053
34,212
13,131
Most columns at RND
Most columns at
OPE analyzed were
less sensitive
Performance
DB server throughput
MySQL:
Application 1
Plain database
Application 2
Latency
CryptDB:
Application 1
Application 2

CryptDB
Proxy
Encrypted
database
CryptDB
Proxy
Hardware: 2.4 GHz Intel Xeon E5620 – 8 cores, 12 GB RAM
TPC-C microbenchmarks
Homomorphic
addition
No cryptography at the DB server in the steady state!
Encrypted DBMS is practical
CryptDB Critique?
• Cryptanalysis?
• How much does get leaked in steady state?
Across columns?
• What about storing sensitive columns completely
encrypted (using RND) and others in plaintext?
– Is this strictly weaker in terms of sensitive information
leaked?
– Do sensitive items routinely get used in computations
that encrypting is not a good idea?