ZeroInteraction Authentication

1
Zero-Interaction Authentication

• Constant but invisible authentication

2
Introduction

• Motivation Identification of Problems
• Mobile devices (e.g. laptops) are susceptible to
  loss,theft and contain sensitive data.
• For securing data on a laptops disk, decryption
  key supplied at login time is retained by the
  laptop for later use, but still vulnerable.
• Security requires frequent re-authentication, but
  this limits usability and encourage users to
  disable security options.

3
Idea

• How to provide effective file encryption without
  degrading both usability and performance?
• Zero-Interaction Authentication
• Introduction of token carried by users
• For usability, infrequent re-authentication
  between a user and a token
• For performance, encryption and decryption of
  files are made on laptop, not on token. The token
  keeps key-encrypting keys, and the laptop
  contains file keys.

4
Architecture of ZIA
user
laptop
token
Infrequent authentication
frequent authentication
PIN
5
Architecture of ZIA
6
Architecture of ZIA
7
Design Perspectives of ZIA

• Trust and Threat Model
• Protection against attacks involving physical
  possession of a laptop or proximity to it
• Protection against exploitation of the wireless
  link between the laptop and token
• Support of data sharing within a domain
• No protection against a trusted but malicious
  user
• No protection for remote users

8
Design Perspectives of ZIA

• Key-Encrypting Keys by network admin
• Administrative authority assigns a user key Ku,
  to each user a group key Kg to each group a
  world key Kw to each machine.
• Each laptop encrypts data under some symmetric
  key, Ke.
• Ke is stored on each machine as Ku(Ke) encrypted
  under some key-encrypting key, Ku.
• If a file is accessible by members of its owning
  group, Kg(Ke) is also stored.
• Kw(Ke) would be stored for files that are
  world-accessible.

9
Design Perspectives of ZIA

• Token Vulnerabilities
• Since the token is worn by a user, it is more
  physically secure than a laptop.
• In case of token loss, possible extraction of
  key-encrypting keys should be avoided with the
  introduction of PIN-protected tamper-resistant
  hardware.
• In case that a laptop was stolen but not token, a
  tailgating attacker can force the stolen laptop
  to generate key decryption requestsWhat is the
  countermeasure to this? gt bindings between
  tokens and laptops

10
Design Perspectives of ZIA

• Token-Laptop Interaction
• The binding process mutual authentication and
  session key establishment
• Public-key schemes applied
• Use the Station-to-Station protocol to provide
  public-key authentication and Diffie-Hellman key
  exchange

11
Design Perspectives of ZIA

• Assigning File Keys
• What is the right granularity of data under
  encryption/decryption?
• A small grain size reduces the data exposed if a
  file key is revealed, but a larger grain size
  provides more opportunity for key caching and
  re-use.
• File key per file scheme requiring an extra seek
  on each file is not efficient.
• So file key per directory scheme deployed
• Each file in a directory shares the same file key
  
• File key is stored within the associated
  directory.
• Key acquisition costs are amortized across
  intra-directory accesses.

12
Design Perspectives of ZIA

• Handling Keys Efficiently
• To reduce key acquisition time
• Overlap key acquisition with disk operations
  whenever possible
• Cache decrypted keys obtained from the token
• In case that neither overlapping nor caching
  applies to directory creation, which requires a
  fresh key
• ZIA prefetches keys from the token to be used for
  directories created later.
• The initial set of fresh keys is prefetched when
  the user binds a token to a laptop.
• To assure that token is present, a periodic
  challenge/response between the laptop and the
  token.
• The time must be short enough that the time to
  discover an absence plus the time to secure the
  machine is less than that required for a physical
  attack.
• It also must be long enough to impose only a
  light load on the system
• Set the interval to be one second.

13
Design Perspectives of ZIA

• Departure and Return
• When the token does not respond to key requests
  or challenges, the user is declared absent.
• All file system state must be protected and all
  cached file keys flushed.
• Writing dirty pages to disk under encryption and
  zeroing the cache expensive due to decryption of
  pages scattered on the disk that had been
  originally in the cache
• Encrypting all cached pages in place -- deployed
  decryption keys are wired in the cache, not
  evicted.
• When the user returns, ZIA must recover and
  decrypt pages that were in the cache.

14
Design Perspectives of ZIA

• Laptop Vulnerabilities
• When a laptop is stolen or lost
• All file keys and session keys zeroed in memory
• However, the laptops private key remains to
  allow re-authentication, which is vulnerable to
  attacker.
• To defend against this,
• the user must remove the binding between the
  token and the stolen device
• Or use of tamper-resistant hardware in the laptop

15
Implementation of ZIA

• See figure 3
• Kernel encryption module
• Cryptographic I/O
• Management of file keys
• Polling for the tokens presence
• Authentication system
• Keyd Authentication
• Runs on the token
• Responds to key decryption and polling requests
• Keyiod Authentication
• Runs on the laptop
• Handles session establishment and request
  retransmission

16
Implementation of ZIA
17
Evaluation of ZIA

• Key acquisition
• Elapsed time between the kernels request for key
  decryption and the delivery of the key to the
  kernel
• 13.9 milliseconds, similar to typical file access
  time

18
Evaluation of ZIA

• ZIA overhead
• Overhead imposed by ZIA on typical system
  operation
• ZIA imposes less than a 10 penalty over ext2f
  due to encryption/decryption of file pages and
  names, key retrieval, token communication and key
  storage.

19
Evaluation of ZIA

• ZIA overhead
• mkdir must write the keyfile to the disk,
  resulting in an extra file creation to every
  mkdir.

20
Evaluation of ZIA

• Departure and Return
• Encryption time is linear with page cache size.
• Decryption is also linear, though key fetching
  requires a variable amount of time due to the
  unknown number of keys in the cache.

21
Evaluation of ZIA

• Figure 7
• A large overhead for ZIA due to fetch 1000 keys,
  no locality for key caching to exploit
• Figure 8
• Cryptfs, ZIA slow compared to others due to
  synchronous decryption after a read and
  encryption before a write.

22
Related Work

• Encryption file system
• CFS
• FiST
• Cryptfs
• EFS
• Proximity-based hardware tokens
• Landwehrs proposal
• XyLoc
• Biometric authentication, etc.

23
Conclusion

• Protection of laptop against physical attacks
• Without degrading of users usability by using
  token-laptop interaction
• Without degrading of systems performance by use
  of keys prefetch/cache
• an overhead of only 9.3 above the local file
  system, indistinguishable from the costs of
  simple encryption

24
Online summary

• A user wears an authentication token that retains
  the long-term authority to act on his behalf. The
  laptop, connected to the token by a short-range
  wireless link, obtains this authority only when
  it is needed.