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

4. Challenge Response 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 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. 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 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 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:

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