ZeroInteraction Authentication

1
Zero-Interaction Authentication

• Mark Corner and Brian Noble
• http//mobility.eecs.umich.edu/
• University of Michigan Software Seminar Series
• September 6, 2002

2
User-Centric Authentication

• How does a device know who is typing?
  Authentication
• typically something you know password
• something you have smartcards
• something you are biometrics
• 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
• Doesnt 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 has the
  rights of the user
• operating system protections can be bypassed

3
Solution constant but invisible authentication

• 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
• Gives the user no reason to turn off protection
• No noticeable impact on performance or usability

4
Outline

• Design
• how are 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?
• Related work

5
Design guidelines

• Protect file system data from physical possession
  attacks
• all data on disk must be encrypted
• ensure user is present for each use of data
• user retains long-term authority to decrypt
• Cant contact token on every instance of use
• adds latency to otherwise-short operations
• Take advantage of caching already used in file
  systems
• on-disk information is kept encrypted for safety
• cached information is kept unencrypted for
  performance
• token provides sole method for decrypting files

6
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 encrypting key on disk,
  itself encrypted
• key encrypting key never leaves token

7
Handle keys efficiently

• Key acquisition time can be expensive
• one network round trip processing time
• this requires milliseconds
• cant 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
  overlap
• nothing you read before hand caching cannot save
  you
• observation you dont need any particular key
• prefetch a stash of file keys to use on create

8
Assign keys per directory

• What is the right granularity for file keys?
• small grain limits damage in the case of key
  exposure
• large grain provides opportunity for overlapping
• 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

9
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 the
  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!

10
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 step is fast write dirty pages, bzero
  cache
• recovery is too slow read entire file cache from
  disk
• Instead, we encrypt the cache on departure,
  decrypt on arrival
• flushing is still fast all in-memory operations
• recovery is much faster no disk operations
  necessary

11
Implementation
Linux kernel using a stackable file
system Rijndael(AES) used for encryption User-spac
e daemon for authentication, key requests
12
Evaluation overview

• Wanted 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 570 PII 366MHz
• token system Compaq iPAQ 3650 Strongarm 200MHz
• connected by 802.11 network in 1Mb/s mode
• Average cost of key acquisition 13.9 ms (0.0015)
• similar to the average seek time of drives

13
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
• Compare ZIA against three file systems
• Ext2fs underlying physical file system
• Cryptfs FiSTs cryptographic file system
  (Rijndael)
• Careful to start with cold file cache
• report mean, standard deviation for 20 trials

14
Andrew Benchmark results
ZIA is statistically identical to simple
encryption!
15
Time to secure/restore the file system

• All data must be encrypted when user leaves
• All data must be decrypted when user returns
• Benchmark
• copy a (variably-sized) tree into ZIA
• disable token, measure time to safety
• enable token, measure time to recovery

16
Time to secure/restore the file system
17
Other Results

• Andrew benchmark obligatory, but not necessarily
  good
• often measures the speed of your compiler
• Micro-benchmarks (details in paper)
• directory creation
• ZIA 6
• scanning directories
• ZIA 91, due to key acquisition
• copying across file system
• ZIA 121 similar to Cryptfs 118

18
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 the machine still has
  implied consent
• FiST (Zadok) has been very useful in fast
  prototyping
• we recommend it despite a few sharp corners

19
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 losing a laptop
• Does not change user behavior
• only user-visible action at (infrequent) login
  time
• Does not noticeably impact performance
• lt10 overhead above raw file system
• Protects and restores machine quickly
• Encrypts buffer cache within five seconds

20
Benefit of optimizations
Turn off prefetching, caching to see how useful
they are for AB

• Not many mkdir operations, but lots of locality
• optimizations are critical

21
Possible Authentication Methods

• Several popular methods
• Passwords require typing, forgotten, written
  down
• Smart Cards swiped swiped and never unswiped
• Smart Cards inserted inserted and left
• Biometrics suffer from a high false negative
  rate, bulky
• Token provides authentication without
  intervention
• User must only be near terminal to authenticate
• Conforms to users expectation It should just
  work.

22
Evaluation Per-Operation Overhead
23
Creating directories

• Directory creations eventually run at key
  acquisition speed
• one key acquisition per K directories
• K determined by size of fresh-key prefetch block

24
Reading directories

• Directory reads with no other activity
• exposes full key acquisition costs
• reading keyfile reduces cost of reading directory
• no overlapping of key acquisition and directory
  reads

25
Copying large trees

• Dominated by memcpy and encryption costs

26
Key-encrypting keys carry permissions

• File encrypted by some key, E
• E is also on disk, encrypted with another key, U
• U is known only to authentication token
• may also choose to escrow U as a matter of policy
• Sharing accommodated by additional encrypted
  versions of E
• UNIX protection model user, group, and world
• E encrypted by a user key U, group key G, maybe
  even W
• each users token holds their U, and all
  applicable Gs
• members of same group share copies of G
• This model requires re-encrypting Es if users
  leave group

27
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 mcorners 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

28
What if I lose my token?

• Master Keys ( U, G, W ) should be escrowed by
  admin
• allows data to be recovered
• Security risks are mitigated by infrequent PIN,
  also need laptop
• Token is worn, so detecting loss is possible
• break contact in clasp, hearbeats, body warmth,
  etc.

29
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
• remote exploits
• trojan horses
• trusted, but malicious, users

30
What about Wormhole attacks?

• Wormhole attacks extend range of token
• nullifies protections based on proximity
• using powerful transmitters/receivers
• forwarding messages through alternate medium
• Detection based on sensitive timing information
• Wormhole detection in Wireless Ad Hoc Networks
• (Yih-Chun Hu, Adrian Perrig, David Johnson)
• would not require token/device time
  synchronization

31
Zero-Interaction Authentication

• Mark Corner and Brian Noble
• http//mobility.eecs.umich.edu/
• Mobicom 2002 Atlanta, GA