Zero-Interaction Authentication

dashingincestuousΑσφάλεια

22 Φεβ 2014 (πριν από 3 χρόνια και 5 μήνες)

57 εμφανίσεις

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

token

Infrequent

authentication

frequent

authentication

PIN

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 K
u
,
to each user; a group key Kg to each group; a
world key K
w

to each machine.


Each laptop encrypts data under some
symmetric key, K
e
.


K
e

is stored on each machine as K
u
(K
e
)
encrypted under some key
-
encrypting key, K
u
.


If a file is accessible by members of its owning
group, K
g
(K
e
) is also stored.


K
w
(K
e
) 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 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
prefetch
es 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 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
decryption 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.