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 laptop’s 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

tokenInfrequent

authenticationfrequent

authenticationPIN

user laptop

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 ke

y, 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 requests…What is the countermeasure to this? => 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 a

uthentication 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 requi

red 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 laptop’s 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 token’s 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 kernel’s 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 decr

yption after a read and encryption before a write.

22

Related Work• Encryption file system

– CFS– FiST– Cryptfs– EFS

• Proximity-based hardware tokens– Landwehr’s proposal– XyLoc

• Biometric authentication, etc.

23

Conclusion• Protection of laptop against physical attacks

– Without degrading of user’s usability by using token-laptop interaction

– Without degrading of system’s 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.