Aditya Akella Why is this important Web Applications are the primary attack target Common approach attack web site steal data abuse it Eg Sony Playstation Network impacted 77 million personal information profiles ID: 756273
Download Presentation The PPT/PDF document "Application Security Lecture 27" 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.
Slide1
Application Security
Lecture 27
Aditya AkellaSlide2
Why is this important?
Web Applications are the
primary attack target
Common approach: attack web site; steal data; abuse itE.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.”
https://blog.cloudsecurityalliance.org/2011/01/27/moving-to-the-cloud-take-your-application-security-with-you/Slide3
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/configurationCan’t observe attack in progressIPS/IDS in the provider’s hands, especially for SaaS systemsKey: push security into the app!Slide4
Application
DB Server
SQL
User 1
User 2
User 3
Protect against confidential
data leaks from databases
CryptDB
Focus
System administrator
Threat 1:
passive DB server attacks
Threat 2:
any attacks on all servers
HackersSlide5
CryptDB in a nutshell
Goal:
protect confidentiality of data
Process SQL queries on encrypted data
Use fine-grained keys; chain these keys to user passwords based on access control
Application
DB Server
SQL
Threat 1: passive DB server attacks
Threat 2: any attacks on all servers
on encrypted data
User 1
User 2
User 3Slide6
First practical DBMS to process most SQL queries on encrypted data
Hide DB from sys.
admins
., outsource DB
Protects data of users logged out during attack, even when all servers are compromised
Limit leakage from compromised applications
Modest overhead: 26% throughput loss for TPC-C
Contributions
No changes to DBMS (e.g.,
Postgres
,
MySQL
)Slide7
Threat 1: Passive attacks to DB Server
DB Server
transformed query
Proxy
plain query
Stores schema, master key
No data storage
No query execution
Under attack
Application
decrypted results
encrypted results
Trusted
Process queries completely at the DBMS, on encrypted database
Process SQL queries on encrypted data
Encrypted DBSlide8
col1/rank
col2/name
table1/emp
SELECT * FROM
emp
WHERE salary = 100
x934bc1
x5a8c34
x5a8c34
x84a21c
SELECT * FROM table1 WHERE col3 = x5a8c34
Proxy
?
x5a8c34
x5a8c34
?
x5a8c34
x5a8c34
x4be219
x95c623
x2ea887
x17cea7
col3/salary
Application
60
100
800
100
Randomized encryption
Deterministic encryptionSlide9
col1/rank
col2/name
table1 (
emp)
x934bc1
x5a8c34
x5a8c34
x84a21c
x638e54
x638e54
x922eb4
x1eab81
SELECT * FROM table1 WHERE col3
≥
x638e54
Proxy
x638e54
x922eb4
x638e54
col3/salary
Application
60
100
800
100
Deterministic encryption
SELECT * FROM
emp
WHERE salary
≥
100
OPE (order)
encryptionSlide10
Use SQL-aware set of encryption schemes
Two techniques
Most SQL uses a limited set of operations
Adjust encryption of database based on queriesSlide11
Encryption schemes
e.g., =
, !=,
IN, COUNT, GROUP
BY
, DISTINCT
Scheme
RND
HOM
DET
SEARCH
JOIN
OPE
Function
none
+, *
equality
join
word search
order
Construction
AES in CBC
AES in CMC
Paillier
new
scheme
Song et al.,‘00
Boldyreva
et al.’09
e.g., >
, <, ORDER BY, SORT, MAX,
MIN
restricted ILIKE
Highest
Security
e.g., sumSlide12
How to encrypt each data item?
Encryption schemes needed depend on queries
May not know queries ahead of time
Leaks order!
rank
ALL?
col1-RND
col1-HOM
col1-SEARCH
col1-DET
col1-JOIN
col1-OPE
‘CEO’
‘worker’Slide13
int value
HOM
Onion
Add
Onions of encryptions
value
JOIN
DET
RND
Onion
Equality
Onion
Search
Same key for all items in a column for same onion layer
Start out the database with the most secure encryption scheme
OR
each value
value
OPE-JOIN
OPE
RND
Onion
Order
text
value
SEARCHSlide14
Adjust
e
ncryption
Strip off layers of the onions
P
roxy
gives keys to server using a SQL UDF (
“
user-defined function”)
Proxy remembers onion layer for columns
Do not put back onion layerSlide15
Example:
SELECT * FROM
emp
WHERE rank = ‘CEO’;emp:
rank
name
salary
‘CEO’
‘worker’
‘CEO’
JOIN
DET
RND
Onion Equality
col1-OnionEq
col1-OnionOrder
col1-OnionSearch
col2-OnionEq
table 1:
…
…
…
RND
RND
SEARCH
RND
SEARCH
RND
RND
RNDSlide16
Example (cont’d)
UPDATE
table1
SET
col1-OnionEq
=
Decrypt_RND
(key
, col1-OnionEq);
‘CEO’
JOIN
DET
RND
SELECT * FROM
table1 WHERE col1-OnionEq = x
da5c0407;
DET
Onion Equality
RND
RND
SELECT * FROM
emp
WHERE
rank =
‘CEO’;
DET
DET
col1-OnionEq
col1-OnionOrder
col1-OnionSearch
col2-OnionEq
table 1…
…
…
RND
RND
SEARCHRND
SEARCHRNDSlide17
aggregation on a column HOM nothing
Confidentiality level
equality predicate on a column DET
repeats
Never reveals plaintext
Queries encryption scheme exposed
common in practice
no filter on a column RND nothing
amount of leakage
Encryption schemes exposed for each column are the most secure enabling queriesSlide18
Application protection
DB Server
SQL
Proxy
Application
User 1
User 2
User 3
Arbitrary attacks on any servers
Passive attacks
User password gives access to data allowed to user by access control policy
Protects data of logged out users during attackSlide19
Challenge:
data sharing
Process queries on encrypted data
msg_id
sender
receiver
msg_id
message
5
“secret message”
5
Alice
Bob
SPEAKS_FOR
msg_id
SPEAKS_FOR
msg_id
ENC_FOR
msg_id
Capture read access policy of application at SQL
level?
Annotations
Key chains from user passwords
Km5
Km5
Km5
How to enforce access control cryptographically?
Alice-pass
Bob-passSlide20
Implementation
CryptDB
Proxy
Unmodified DBMS
CryptDB
SQL
UDFs
(
user-defined functions)
Server
q
uery
r
esults
transformed query
e
ncrypted results
SQL Interface
No change to the DBMS
Portable:
from
Postgres
to
MySQL
with 86 lines
Application
One-key: no change to applications
Multi-user keys: annotations and login/logoutSlide21
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 schemesSlide22
Real queries/applications
Application
Total columns
Encrypted columns
phpBB
563
23
HotCRP
204
22
grad-apply
706
103
TPC-C
92
92
sql.mit.edu
128,840
128,840
Annotations +
lines of code
changed
38
31
113
0
0
Multi-user
keys
One-key
# cols not
supported
0
0
0
0
1,094
SELECT 1/log(series_no+1.2) …
… WHERE
sin(latitude
+ PI()) … Slide23
Resulting confidentiality
Application
Total columns
Encrypted columns
phpBB
563
23
HotCRP
204
22
grad-apply
706
103
TPC-C
92
92
sql.mit.edu
128,840
128,840
One-key
Min level
is RND
21
18
95
65
80,053
Min
level is DET
1
1
6
19
34,212
Min level is OPE
1
2
2
8
13,131
Most columns at RND
Most columns at OPE analyzed were less sensitive
Multi-user
keysSlide24
Performance
DB server throughput
CryptDB
Proxy
Encrypted database
Application 1
CryptDB
:
Plain database
Application 1
MySQL
:
CryptDB
Proxy
Application 2
Application 2
Latency
Hardware:
2.4 GHz Intel Xeon E5620 – 8 cores, 12 GB RAMSlide25
TPC-C
m
icrobenchmarks
Encrypted DBMS is practical
No cryptography at the DB server in the steady state!
Homomorphic
additionSlide26
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?