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 Secure Less Usable More Usable Less Secure Frequency of Proof

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 Challenge Response

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 device’s 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 device’s 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 device’s 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 device’s 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 device’s 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. Zeroed Data Just Faster than Attackers When token does not answer assume user is absent, protect all keys/data Protection doesn’t 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 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 advisor’s laptop thief sits behind me advisor’s 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 <10s 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 <150ms, can be further optimized Protect/Restore Times: Protect, secRestore, sec Memory Cache0.222 (0.002) 0.222 (0.004) SSL Keys0.003 (0.000) 0.074 (0.006) Passwords + Cookies N/A0.066 (0.005)

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 application’s 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