Networked Systems Practicum Lecture 12 – Privacy 1

Outline TaintDroid ZIA/Transient Authentication CleanOS 2

TaintDroid 3

Taint Analysis 4

Design 5

6

Taint Propagation 7

Native Methods 8

Msgs and Files 9

Performance 10

Taint Sources 11

Findings 12

Findings 13

Outline TaintDroid ZIA/Transient Authentication CleanOS 14

ZIA: 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?

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

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

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

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

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

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

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

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

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

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

Foil tailgaters How do I prevent my token from responding to your laptop? called the tailgater attack Leverage the login process users already are familiar with suppose mcorner logs into weir.eecs weir.eecs sends a challenge to mcorner’s token user gives response to the token could be simple (a tap) or complicated (one-time pass) token then bound: only bound tokens respond unless I bind my token to your laptop, you lose Provides assurance that this user means to use that laptop user plays the role of trusted third party in binding

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

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

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

Outline TaintDroid ZIA/Transient Authentication CleanOS 30

CleanOS 31

Threats 32

Problems with State-of-Art 33

Key Observations 34

Design 35

Design 36

Design 37

SDOs 38

SDO example 39

Garbage Collector 40

WiFi Performance 41

3G Performance 42