Protecting Applications with Transient Authentication

Mark Corner and Brian Noble

University of Michigan - EECS Department

http://mobility.eecs.umich.edu

M O B I L I T Y

Scenario: Losing Your Laptop

Imagine rushing to a talk and leaving your laptop in a taxi cab

A finder may be malicious, may not be

What do you do in the interim?buy a new machine---not really a big dealjust like credit cards you should cancel all your

passwordswhat about your web cache?what about your account numbers?

M O B I L I T Y

Tension in Proving IdentityThe device can ask for proof once and never ask again

finder assumes the full rights of the user

The device can continuously askusers would not tolerate such a system

A compromise is to ask periodically

Current authentication methods do not resolve this tensionhedge on the side of less security and more usability

Need something to provide constant proof without user burden

More SecureLess Usable

More UsableLess Secure

Frequency ofProof

M O B I L I T Y

Solution: Constant but Invisible AuthenticationTransient Authentication

protect data by constantly authenticating userkeep usable by having something answer for the user

Authentication token: provides this abilityworn by user to prove proximityenough computational power for small cryptographic

taskscommunication via short-range wireless network

Challenge

Response

M O B I L I T Y

Outline

Trust and Threat Model

Principles of Transient AuthenticationTie capabilities to usersDo no harmSecure faster than attackersEnsure explicit consent

Transient Authentication for ApplicationsApplication-Transparent protectionApplication-Aware protection

Related work and Conclusions

M O B I L I T Y

Trust and Threat Model

Focus on foiling physical possession or proximityinspection and removal of disk, probing physical

memoryexploitation of wireless link

eavesdropping, modification, insertion

Cannot protect against certain kinds of attackstrojan horses denial of servicetrusted, but malicious, users

Do not protect against these, yet defenses existwormhole attacksresidual charge attacks

M O B I L I T Y

Tie Capabilities to Token

Require token to decrypt device’s datadevice alone is useless, regardless of physical

attacks

Tokens have limited computation, (slow) wireless linktokens cannot decrypt data directlynever expose root capability, key-encrypting keys only transmit data key

M O B I L I T Y

Tie Capabilities to Token

Require token to decrypt device’s datadevice alone is useless, regardless of physical

attacks

Tokens have limited computation, (slow) wireless linktokens cannot decrypt data directlynever expose root capability, key-encrypting keys only transmit data key

Key-EncryptingKey

Laptop Token

Key-EncryptingKey

Data Key

M O B I L I T Y

Tie Capabilities to Token

Require token to decrypt device’s datadevice alone is useless, regardless of physical

attacks

Tokens have limited computation, (slow) wireless linktokens cannot decrypt data directlynever expose root capability, key-encrypting keys only transmit data key

Key-EncryptingKey

Laptop Token

Key-EncryptingKey

Data KeyKey-Encrypting

Key

Data Key

M O B I L I T Y

Tie Capabilities to Token

Require token to decrypt device’s datadevice alone is useless, regardless of physical

attacks

Tokens have limited computation, (slow) wireless linktokens cannot decrypt data directlynever expose root capability, key-encrypting keys only transmit data key

Key-EncryptingKey

Laptop Token

Key-EncryptingKey

Data Key

Data Key

Key-EncryptingKey

Data Key

M O B I L I T Y

Tie Capabilities to Token

Require token to decrypt device’s datadevice alone is useless, regardless of physical

attacks

Tokens have limited computation, (slow) wireless linktokens cannot decrypt data directlynever expose root capability, key-encrypting keys only transmit data key

Key-EncryptingKey

Laptop Token

Key-EncryptingKey

Data Key

Data Key

Key-EncryptingKey

Data Key

SessionEncryption

M O B I L I T Y

Zeroed Data

Just Faster than Attackers

When token does not answerassume user is absent, protect all keys/data

Protection doesn’t have to be instantaneousjust faster than attackers, people are slow

TA has two alternatives: flush vs. encrypt flush is faster than encrypt on departurefilling data is potentially slow or require user

interventionencrypt is slower to protect, but faster on return

SecretUser

Departs

M O B I L I T Y

Do No Harm

Key acquisition costly (~10ms)too expensive to pay on every use of dataoverhead would be prohibitive without optimization

Some techniques hide/avoid costcache data keyspre-fetch fresh keys

Optimizations reduce laptop/token interactionsloss of interaction -> user has leftadd periodic polling to refresh authentication

M O B I L I T Y

Ensure Explicit Consent

Could keep users entirely out of the loopcomplete transparency == complete loss of control

Consider the “tailgater” attackthief steals my advisor’s laptopthief sits behind meadvisor’s laptop asks for key-encrypting keymy token transparently responds

Solution: provide explicit binding between tokens/devicesthis user means to use that laptopcan be infrequent, e.g. once a day

M O B I L I T Y

Application Protection

Protections for file systems exist: ZIA (Mobicom ‘02)

Protecting file systems is not enoughdata read from file system into address space(and read from network, and typed by user, and …)

Mobile devices are typically always on or suspendedephemeral state always vulnerable

Possible attacks on memory spaceOS interfacesprobing memory bus

M O B I L I T Y

Application-Transparent Protection

Simple solution: encrypt entire memory spacesuspend processes & encrypt in-memory state on

departuredecrypt state & resume processes on returnencrypt and decrypt 216MB state in <10s

Brute-force approach may be overkillnot all applications are sensitivenot all application state is sensitiveapplication might know the differencecould perform useful, non-secure work

M O B I L I T Y

Application-Aware Protection

Through an API give applications ability tocontinue to executemanage their own secretsgain information about user proximity

Services provided to applicationregister departure/return callbacksrequest decryption/encryption of buffer with master

keyobtain fresh keys

Application/designer responsible foridentifying sensitive state/operationstying capabilities to token

M O B I L I T Y

Modified Applications

Three examples: PGP Email, SSH suite and

Mozillamost difficult application: many secrets, large code

basesecrets: passwords, cookies, SSL keys, memory

cache

M O B I L I T Y

Mozilla Modifications

Minimal code modifications (4200 line patch file)a month of “Mozilla novice” effort

SSL Session Keys and Memory Cachestored in memoryencrypted if user leaves and decrypted when user

returns

Cookies, Cached Passwordsstored encrypted on diskencryption key forgotten by laptop, retrieved using

token

M O B I L I T Y

Evaluation Overview: Mozilla

Wanted to answer a few questionswhat overhead does TA impose? how long does it take to secure/restore secrets?

Prototype Systemclient system: IBM Thinkpad X24 PIII 1.1GHz, 256MBtoken system: Compaq iPAQ 3870 Strongarm

200MHz connected by Bluetooth

M O B I L I T Y

Evaluation: Protecting Mozilla

Typical page load overhead <150ms, can be further optimized

Protect/Restore Times:

Protect, sec Restore, sec

Memory Cache

0.222 (0.002) 0.222 (0.004)

SSL Keys 0.003 (0.000) 0.074 (0.006)

Passwords + Cookies

N/A 0.066 (0.005)

M O B I L I T Y

Application-Aware Limitations

Applications must be modified

Application designers must identify all the secrets

Leaked memory may contain secrets

Freed memory may contain secretsOS can scrub free pagesfree/delete can be intercepted to scrub

Secrets may be passed to other applicationsMyers and Liskov language support may hold

promise

M O B I L I T Y

Related work

Proximity DetectionLandwehr locks input based on proximity beacon

Provos encrypted virtual memoryfocuses on swap using short term keys

Secure coprocessors, smart cards, XOM processorall use physical security to protect secretsdo not solve authentication questionperformance/cost implications

M O B I L I T Y

Conclusions

Usually, your machine has the long-term authority to act as you

Transient Authenticationuser retains long-term authority to decrypt sensitive

datalaptop holds only transient authoritydefends against physically losing a laptop

Does not change user behavioronly user-visible action at (infrequent) login time

Protects and restores machine quicklyCan protect application’s secrets in milliseconds

M O B I L I T Y

Lost Laptops

Bad and getting worse1.36 million lost in 2000, of those 387,000 stolen591,000 stolen in 2001Seattle-Tacoma Airport found 204 laptops in three

months

Several high profile casesIrwin Jacobs lost a laptop containing 2 years of

financialsMI6 agent left a laptop in a taxi containing field

methodsDepartment of State laptop with nuclear proliferation

secretsall were insecure

M O B I L I T Y

Mozilla Modifications

Laptop

Mozilla Master Key (K_MOZ)

SDR Passw ord (K_sdr)

SDR Passw ord (K_sdr)

Cookies

Token

Mozilla Master Key (K_MOZ)

SSL Submaster (K_ssl)

SSL Submaster (K_ssl)

MemoryCache

K_MOZ

K_ssl

Passw ords SSL Keys

K_MOZ

K_sdr K_sdr K_ssl