12 September 2002
Mark Corner talks about: Zero-Interaction Authentication http://mobility.eecs.umich.edu/ This is a research project, not a product, so there are some aspects that are not complete. USER-CENTRIC AUTHENTICATION How does a device know who is typing? typically something you know: password something you have: smartcards something you are: biometrics all of these are done once and assumed to hold forever This is acceptable for PCs: have relatively high physical security when someone is in my office, I know it Doesn't work for mobile devices: relatively low physical security Seattle-Tacoma airport found 330 laptops in three months physical possession does not equal authentication So what? If device is lost, an imposter [... missed the rest of this one ...] ZIA: ZERO-INTERACTION AUTHENTICATION protect data by constantly authenticating user keep usable by having something answer for the user Authentication token: provides this ability worn by user for increased physical security enough computational power for small cryptographic tasks communication via short-range wireless network Restores parity between physical possession and authentication DESIGN Threat model how is the machine protected? how does the machine depend on the token? how do we improve performance Implementation Linux prototype system with iPAQ handheld token Evaluation what is the cost of protection what overhead does ZIA add how fast can the machine be secured and recovered? 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 remote exploits trojan horses trusted, but malicious, users DESIGN GUIDELINES Protect file system data from physical possession attacks all data on disk must be encrypted ensure user is present from each use of data user retains long-term authority to decrypt Can't contact token on every instance of use adds latency to otherwise sort operations Take advantage of caching already used in file systems on-disk information is kept encrypted for safety cached information is unencrypted MOVING DATA FROM DISK TO CACHE Tokens cannot decrypt file contents directly small, battery-powered: limited computation connected to laptop via wireless link latency comparable to disk, bandwidth much less Instead, store file encryption key on disk, itself encrypted key-encrypting key never leaves token HANDLE KEYS EFFICIENTLY Key acquisition time can be expensive one network round trip + processing time this requires milliseconds can't add this to every disk operation! Two mechanisms mitigate this problem overlap key acquisition with disk reads (similar magnitudes) cache decrypted keys so they are available during writes Neither mechanism helps new file creation is an asynchronous write: nothing with which to cache nothing you read beforehand: caching cannot save you ASSIGN KEYS PER DIRECTORY What is the right granularity for file keys? large size compromises more data in case of key exposure small grain limits opportunity for overlapping/caching We chose per-directory keys leverage access patterns files in same directory tend to be used together acquisition time amortized across a directory simplifies key management keys are stored in hidden file inside directory access rights are on a per-directory basis admits per-directory sharing, similar to AFS MAINTAIN PERFORMANCE, ENSURE SECURITY Optimizations reduce laptop/token interactions high locality, low creation rate: never decrypt a key! Add periodic polling to refresh authentication cryptographic challenge-response protocol need not be frequent, since people are slow When token does not answer assume user is absent, protect all data on machine must be fast enough to foil theft When user comes back into range restore machine to "pre-departure" state must appear as if machine never changed: no faulting in! [... okay, where were we? ...] MAKE PROTECTION FAST AND INVISIBLE Key question: what to do with cached data on departure? One alternative: flush data on departure, read in on arrival flush stop is fast: write dirty pages, bzero cache recovery is too slow: read entire file cache back IMPLEMENTATION Linux kernel using a stackable file system [data storage abstraction] Rijndael (AES) used for encryption User-space daemon for authentication, key requests EVALUATION OVERVIEW Whated to answer a few questions what overhead does ZIA impose? how long does it take to secure the cache? how long does it take to restore the cache Prototype System client system: IBM Thinkpad 57- PII 366Mhz token system: Compaq iPAQ 3650 Strongarm 200Mhz connected by 802.11 network in 1 Mb/s mode Average cost of key acquisition: 13.9 ms similar to the average seek time of drives EVALUATION: ANDREW BENCHMARK Testing typical system operation Used a Modified Andrew Benchmark short version: copy and compile a source tree we use the Apache source code for a larger benchmark source code is 7.4 MB, compiled version is 9.7 MB Compared ZIA to two file systems ext2fs: underlying physical file system cryptfs: FiST's cryptographic file system (+Rijndael) Careful to start with cold file cache report mean, standard deviation for 20 trials ANDREW BENCHMARK RESULTS File System Time (sec.) Overhead (vs. ext2fs) ------------- ------------ --------------------- ext2fs 52.63 (0.30) -- Cryptfs 57.52 (0.18) 9.28% ZIA 57.64 (0.20) 9.32% ZIA is statistically identical to simple encryption. [... more nifty graphs I won't attempt to reproduce ...] RELATED WORK Many examples of cryptographic file systems CFS (Matt Blaze), Cryptfs (Erez Zadok), EFS (Win2K) all suffer from the problem of "implied consent" once you log in, the file system can forevermore decrypt Win2k can ask you to authenticate more frequently inconvenient: anecdotally, it is often disabled Can use a smart card to hold keys (Blaze) rather than in-kernel smart card left in machine still has "implied consent" FiST (Zadok) has been very useful in fast prototyping we [Mark, et al] recommend it despite a few sharp corners CONCLUSIONS Usually, your machine has the long-term authority to act as you Zero-Interaction Authentication user retains long-term authority to decrypt sensitive data laptop holds only transient authority defends against physically lowing a laptop Does not change user behaviour only user-visible action at (infrequently) login time Does not noticeably impact performance < 10% overhead above raw file system Protects and restores machine quickly encrypts buffer cache within five seconds