Protecting Applications with Transient Authentication

1
Protecting Applications with Transient
Authentication

• Mark Corner and Brian Noble
• University of Michigan - EECS Department
• http//mobility.eecs.umich.edu

2
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 deal
• just like credit cards you should cancel all your
  passwords
• what about your web cache?
• what about your account numbers?

3
Tension in Proving Identity

• The device can ask for proof once and never ask
  again
• finder assumes the full rights of the user
• The device can continuously ask
• users would not tolerate such a system
• A compromise is to ask periodically
• Current authentication methods do not resolve
  this tension
• hedge on the side of less security and more
  usability
• Need something to provide constant proof without
  user burden

More Usable Less Secure
Frequency ofProof
More Secure Less Usable
4
Solution Constant but Invisible Authentication

• Transient Authentication
• protect data by constantly authenticating user
• keep usable by having something answer for the
  user
• Authentication token provides this ability
• worn by user to prove proximity
• enough computational power for small
  cryptographic tasks
• communication via short-range wireless network

5
Outline

• Trust and Threat Model
• Principles of Transient Authentication
• Tie capabilities to users
• Do no harm
• Secure faster than attackers
• Ensure explicit consent
• Transient Authentication for Applications
• Application-Transparent protection
• Application-Aware protection
• Related work and Conclusions

6
Trust and Threat Model

• Focus on foiling physical possession or proximity
• inspection and removal of disk, probing physical
  memory
• exploitation of wireless link
• eavesdropping, modification, insertion
• Cannot protect against certain kinds of attacks
• trojan horses
• denial of service
• trusted, but malicious, users
• Do not protect against these, yet defenses exist
• wormhole attacks
• residual charge attacks

7
Tie Capabilities to Token

• Require token to decrypt devices data
• device alone is useless, regardless of physical
  attacks
• Tokens have limited computation, (slow) wireless
  link
• tokens cannot decrypt data directly
• never expose root capability, key-encrypting keys
  
• only transmit data key

8
Tie Capabilities to Token

• Require token to decrypt devices data
• device alone is useless, regardless of physical
  attacks
• Tokens have limited computation, (slow) wireless
  link
• tokens cannot decrypt data directly
• never expose root capability, key-encrypting keys
  
• only transmit data key

9
Tie Capabilities to Token

• Require token to decrypt devices data
• device alone is useless, regardless of physical
  attacks
• Tokens have limited computation, (slow) wireless
  link
• tokens cannot decrypt data directly
• never expose root capability, key-encrypting keys
  
• only transmit data key

10
Tie Capabilities to Token

• Require token to decrypt devices data
• device alone is useless, regardless of physical
  attacks
• Tokens have limited computation, (slow) wireless
  link
• tokens cannot decrypt data directly
• never expose root capability, key-encrypting keys
  
• only transmit data key

11
Tie Capabilities to Token

• Require token to decrypt devices data
• device alone is useless, regardless of physical
  attacks
• Tokens have limited computation, (slow) wireless
  link
• tokens cannot decrypt data directly
• never expose root capability, key-encrypting keys
  
• only transmit data key

12
Just Faster than Attackers

• When token does not answer
• assume user is absent, protect all keys/data
• Protection doesnt have to be instantaneous
• just faster than attackers, people are slow
• TA has two alternatives flush vs. encrypt
• flush is faster than encrypt on departure
• filling data is potentially slow or require user
  intervention
• encrypt is slower to protect, but faster on
  return

Secret
Zeroed Data
User Departs
13
Do No Harm

• Key acquisition costly (10ms)
• too expensive to pay on every use of data
• overhead would be prohibitive without
  optimization
• Some techniques hide/avoid cost
• cache data keys
• pre-fetch fresh keys
• Optimizations reduce laptop/token interactions
• loss of interaction - user has left
• add periodic polling to refresh authentication

14
Ensure Explicit Consent

• Could keep users entirely out of the loop
• complete transparency complete loss of control
• Consider the tailgater attack
• thief steals my advisors laptop
• thief sits behind me
• advisors laptop asks for key-encrypting key
• my token transparently responds
• Solution provide explicit binding between
  tokens/devices
• this user means to use that laptop
• can be infrequent, e.g. once a day

15
Application Protection

• Protections for file systems exist ZIA (Mobicom
  02)
• Protecting file systems is not enough
• data read from file system into address space
• (and read from network, and typed by user, and )
• Mobile devices are typically always on or
  suspended
• ephemeral state always vulnerable
• Possible attacks on memory space
• OS interfaces
• probing memory bus

16
Application-Transparent Protection

• Simple solution encrypt entire memory space
• suspend processes encrypt in-memory state on
  departure
• decrypt state resume processes on return
• encrypt and decrypt 216MB state in
• Brute-force approach may be overkill
• not all applications are sensitive
• not all application state is sensitive
• application might know the difference
• could perform useful, non-secure work

17
Application-Aware Protection

• Through an API give applications ability to
• continue to execute
• manage their own secrets
• gain information about user proximity
• Services provided to application
• register departure/return callbacks
• request decryption/encryption of buffer with
  master key
• obtain fresh keys
• Application/designer responsible for
• identifying sensitive state/operations
• tying capabilities to token

18
Modified Applications

• Three examples PGP Email, SSH suite and
• Mozilla
• most difficult application many secrets, large
  code base
• secrets passwords, cookies, SSL keys, memory
  cache

19
Mozilla Modifications

• Minimal code modifications (4200 line patch file)
• a month of Mozilla novice effort
• SSL Session Keys and Memory Cache
• stored in memory
• encrypted if user leaves and decrypted when user
  returns
• Cookies, Cached Passwords
• stored encrypted on disk
• encryption key forgotten by laptop, retrieved
  using token

20
Evaluation Overview Mozilla

• Wanted to answer a few questions
• what overhead does TA impose?
• how long does it take to secure/restore secrets?
• Prototype System
• client system IBM Thinkpad X24 PIII 1.1GHz,
  256MB
• token system Compaq iPAQ 3870 Strongarm 200MHz
• connected by Bluetooth

21
Evaluation Protecting Mozilla

• Typical page load overhead optimized
• Protect/Restore Times

22
Application-Aware Limitations

• Applications must be modified
• Application designers must identify all the
  secrets
• Leaked memory may contain secrets
• Freed memory may contain secrets
• OS can scrub free pages
• free/delete can be intercepted to scrub
• Secrets may be passed to other applications
• Myers and Liskov language support may hold promise

23
Related work

• Proximity Detection
• Landwehr locks input based on proximity beacon
• Provos encrypted virtual memory
• focuses on swap using short term keys
• Secure coprocessors, smart cards, XOM processor
• all use physical security to protect secrets
• do not solve authentication question
• performance/cost implications

24
Conclusions

• Usually, your machine has the long-term authority
  to act as you
• Transient Authentication
• user retains long-term authority to decrypt
  sensitive data
• laptop holds only transient authority
• defends against physically losing a laptop
• Does not change user behavior
• only user-visible action at (infrequent) login
  time
• Protects and restores machine quickly
• Can protect applications secrets in milliseconds

25
Lost Laptops

• Bad and getting worse
• 1.36 million lost in 2000, of those 387,000
  stolen
• 591,000 stolen in 2001
• Seattle-Tacoma Airport found 204 laptops in three
  months
• Several high profile cases
• Irwin Jacobs lost a laptop containing 2 years of
  financials
• MI6 agent left a laptop in a taxi containing
  field methods
• Department of State laptop with nuclear
  proliferation secrets
• all were insecure

26
Mozilla Modifications