Embed Size (px)
Citation preview
ACM CCS - Oct. 18, 2011
Unicorn: Two-‐Factor Attestation for Data Security
M. Mannan Concordia University, Canada
B. Kim, A. Ganjali & D. Lie University of Toronto, Canada
1
Unicorn – target systems
2
q High value data q overkill for casual Facebook profile
q Requires:
q hardware support q PSD: personal security device q custom application package
Goal – malware
3
q Protect entire user session
q Not limited to login & other credentials
Goal – “phishing”
4
q Protect Unicorn credentials q Less reliance on user diligence during authentication
www.bank.com
wwwbank.com
Goal – “automatic” security
5
q Unicorn: access to data depends on system state
q Ideal: functionality tied to system health – avoids the “unmotivated user” problem
Dealing with Phishing
q Use security token q generate one time passwords or do challenge response
q adversary must steal/clone a token q or: hack RSA J
But no protection against malware!
6
Dealing with malware q Use trusted computing hardware to verify
the integrity of a computer (TPM, Intel TXT, AMD SVM) q compute hashes of BIOS, boot loader, OS, … q sign hashes to prove that computer is not
running unwanted code
Notifying the current system state to users isn’t easy [Libonati, NDSS 2011]
7
Combine the two?
8
q Unicorn: security token + trusted computing q Unicorn applications are called uApps q uApp: small OS + one application q User OS: open, uApps: closed
Unicorn design
9
q Token is used to verify attestations q only releases authentication credentials if
system is malware free q verifies: system memory + disk image
q Attacker must q clone or steal the token q physical access to user’s computer q assumption: no vulnerabilities in Unicorn
Unicorn example – setup
10
PCRs, Auth AIK
User diligence is needed
q Security tokens currently not capable of attestation q smartphone as PSD
Unicorn example – steps
11
Verify
Starting a uApp q Suspend, save user OS state
q option 1: reboot into uApp q option 2: use DRTM
q User OS as the bootloader
q Resume: q direct transfer back to user OS
Save state
Hardware Reset
BIOS
Boot loader
uApp OS
12
uApp usage scenarios
q Two example cases q data stored on a remote server q data stored encrypted on local machine
q Token is initialized with a secret key q remote server case: signing/MAC key q local machine: encryption sub-‐key
13
Remote server case
Nonce, PCRs
Quote(Nonce, PCRs)
MAC(Quote(Nonce, PCRs))
14
(MAC key) (TPM keys)
Local machine case
q Encryption key consists of two subkeys: q subkey 1: on smartphone q subkey 2: sealed into computer’s TPM
Nonce, PCRs
Quote(Nonce, PCRs)
Subkey
15
Unicorn prototype
q Extensions to Linux 2.6.34 kernel q one line change in user OS kernel
q Transfer directly to uApp OS via kexec q loads uApp kernel image into memory q saves state & transfer control to uApp loader
q uApp loader based on tboot package q sets up a measured launch environment (MLE) q measures the loaded kernel q kernel measures the disk image during boot
16
uApp images
q uApp image should be small q smaller attack surface & faster verification
q we use a small Linux distro with a space efficient file system (squashfs)
q uApp is network restricted q communicate only with remote server
q help against TPM relaying attacks q SSL cert: only one trusted CA
17
TPM relaying
q Attacker relays attestation requests to legitimate machine q but legitimate uApp will only communicate with
remote server
x x 18
Switching between commodity OS & uApp
Task Time (seconds)
Suspend of user OS 11.16
uApp Loader 3.29
Kernel boot and Xserver startup 7.20
OS hash 3.85
Unicorn Total 25.50
Switching via reboot 47.70
19
q Majority of cost: suspending the user OS and kernel boot q uApp loader is slow because TPM is slow
Conclusion
q Unicorn for two-‐factor data protection q physical access to user PC & compromised token q for users: no passwords to remember or judge the
safety of their computing environment q switching: skip hardware reset and BIOS
q ~45% reduction in switching time vs. previous methods
q Enable “automatic” security
20
