Secure Remote
Authentication Using
Biometrics
Portions of this work done with
Xavier Boyen, Yevgeniy Dodis,
Rafail Ostrovsky, Adam Smith
Jonathan Katz
*
*
Work supported by NSF Trusted Computing grant #0310751
Motivation
“Humans are incapable of securely storing high

quality cryptographic secrets, and they have
unacceptable speed and accuracy…. (They are also
large [and] expensive to maintain…. But they are
sufficiently pervasive that we must design our
protocols around their limitations.)”
From: “
Network Security: Private Communication in a
Public World
,” by Kaufman, Perlman, and Speciner
Possible solutions?
•
(Short) passwords?
•
(Hardware) tokens?
•
Biometrics
–
Storage of high

entropy data “for free”
Problems with biometrics
•
At least two important issues:
–
Biometrics are not
uniformly random
–
Biometrics are not
exactly reproducible
•
Outside the scope of this talk
–
Are biometrics private?
–
Sufficiently

high entropy?
–
Revocation?
Previous work I
•
Davida

Frankel

Matt ’98; Monrose

Reiter

(Li)

Wetzel ’99, ’01
•
Juels

Wattenberg ’99; Frykholm

Juels ’01; Juels

Sudan ’02
Previous work II
•
Dodis

Reyzin

Smith ’04
–
Their framework and terminology
adopted here
•
Boyen ’04
–
Two main results
–
One result information

theoretic;
second in RO model
Question:
•
Can we use biometric data (coupled
with these techniques…) for
remote
user authentication?
–
E.g., authentication over an
insecure,
adversarially

controlled
network?
•
Without
requiring users to remember
additional info, or the use of
hardware tokens?
Does previous work, work?
•
[DRS04]
No!
–
Assume “secure channel” btw/ user and server
–
Security vs. passive eavesdropping only
•
[Boyen04]
–
Focus is on
general solutions
to
different
problems
–
In general, techniques only seem to achieve
unidirectional
authentication
–
By focusing on the
specific
problem of interest,
can we do better?
Main results
•
Short answer:
Yes!
–
By focusing specifically on remote
authentication, we
can
do better
–
Two solutions…
•
Compared to [Boyen04]:
–
Solution in
standard model
–
Solutions tolerating
more general errors
–
Achieve
mutual authentication
–
Improved bounds
on the entropy loss
First solution
•
Generic,
“plug

in”
solution whenever
data from server may be tampered
–
In particular, applies to remote
authentication
–
Proven secure in RO model…
–
Tolerates
more general class of errors
than [Boyen04]
–
Mutual authentication
Second solution
•
Specific
to the case of remote
authentication/key exchange
–
Provably secure in
standard model
–
Lower entropy loss compared to
[Boyen04] and previous solution
•
Can potentially be used for lower

entropy
biometrics and/or secrets (passwords?)
–
Still tolerates
more general errors
and
allows
mutual authentication
(as before)
Some background…
Security model I
•
Standard model for (key exchange) +
mutual authentication [BR93]
–
Parties have associated set of
instances
–
Adversary can
passively eavesdrop
on
protocol executions
–
Adversary can
actively interfere
with
messages sent between parties; can also
initiate messages
of its own
Security model II
•
Notion of “partnering”
–
Informally, two instances are
partnered
if they execute the protocol with no
interference from the adversary
–
More formally (but omitting some
details), instances are partnered if they
have identical transcripts
Security model III
•
(Mutual) authentication
–
Instances
accept
if they are satisfied
they are speaking to the corresponding
partner (determined by the protocol)
–
Adversary
succeeds
if there is an
accepting instance which is not
partnered with any other instance
Security model IV
•
Quantify adversary’s success in terms
of its resources
–
E.g., as a function of the number of
sessions initiated by the adversary
–
“On

line” vs. “off

line” attacks
•
This can give a measure of the
“effective key

length”
of a solution
Recap of [DRS04]
•
Use Hamming distance for simplicity…
•
(m, m’, t)

secure sketch (SS, Rec):
–
For all w, w’ with d(w,w’)
t:
Rec(w’, SS(w)) = w
(I.e., “recovery from error”)
–
If W has min

entropy
m, the average
min

entropy of WSS(W) is
m’
(I.e., “w still hard to guess”)
Recap of [DRS04]
•
(m, l, t,
)

fuzzy extractor (Ext, Rec):
–
Ext(w)

> (R, P) s.t.
1.
SD
((R, P), (U
l
,P))
(I.e., R is “close to uniform”)
2. For all w’ s.t. d(w,w’)
t, Rec(w’, P) = R
(I.e., “recovery from error”)
Applications…
•
[DRS04] assumes that P is reliably
transmitted to the user
–
E.g., “in

person” authentication to your
laptop computer
•
No guarantees
if P is corrupted
[Boyen04]
•
Main focus is
reusability
of biometric
data (e.g., with multiple servers)
–
Somewhat tangential to our concern here
•
Also defines a notion of security for
fuzzy extractors when P may be
corrupted…
[Boyen04]
•
(Ignoring reusability aspect…)
•
w
*
chosen; (R, P) = Ext(
(
w
*
)) for
some
; adversary gets P
•
Adversary submits P
1
, …
P and
1
, …;
gets back R
1
= Rec(
1
(w
*
), P
1
), …
•
“Secure” if adv.
can’t distinguish R
from random (except w/ small prob.)
Error model
•
We assume here that d(w
*
,
i
(w
*
))
t
–
I.e., errors occurring in practice are
always at most the error

correcting
capability of the scheme
•
Under this assumption, [Boyen04]
disallows P
i
= P in adversary’s queries
Construction
•
Construction in [Boyen04] achieves
security assuming errors are “data

independent”
–
I.e., constant shifts
•
Construction analyzed in RO model
Application to remote
authentication
Essentially as suggested in [Boyen04]:
User
Server
(R,P) = Ext(w
*
)
R

> (SK, PK)
(w)
(P, PK)
P, nonce
R = Rec(P, w)
R

> (SK, PK)
= Sign
SK
(nonce)
Verify…
Security?
•
Intuition:
–
If adversary forwards P, then user is
signing using his “real” secret key
•
Using a secure signature scheme
–
If adversary forwards P’
P:
•
User computes some R’ and a signature w.r.t.
(key derived from) R’
•
But even R’ itself would not help adversary
learn R!
But…
•
Unidirectional
authentication only
–
No authentication of server to user
•
The definition of [Boyen04]
(seemingly) cannot be used to achieve
mutual authentication
–
Nothing in the definition guarantees
that adversary can’t send some P’ and
thereby guess R’
New constructions
Construction I
•
Modular replacement for
any
protocol
based on fuzzy extractors, when P may be
corrupted
•
Idea
: ensure that for any P’
P, the user
will reject
–
Adversary “forced” to forward real P
•
Sealed
(fuzzy) extractor
–
Allow Rec to return “reject”
Error model
•
Defined by a sequence of random
variables (W
0
, W
1
, …) over some
probability space
such that for all
, i we have d(W
0
(
), W
i
(
))
t
•
More general model than [Boyen04]
–
Allows
data

dependent
errors
•
May be too strong…
Security definition
•
User has w
0
; computes (R,P)<

Ext(w
0
);
adversary given P
•
Adversary submits P
1
, …, P
n
P
•
Adversary succeeds if
i s.t.
Rec(w
i
, P
i
)
“reject”
Application to remote
authentication
User
Server
(R,P) = Ext(w
*
)
(w)
(P, R)
P, n
1
R = Rec(P, w)
c
1
= F
R
(n
1
)
c
1
, n
2
Verify…
c
2
= F
R
(n
2
)
c
2
(Or run authenticated Diffie

Hellman)
Security?
•
If adversary forwards P’
P, user
simply rejects
•
If adversary forwards P, then user
and server are simply running auth.
protocol of [BR93]
Constructing sealed
extractor
•
First construct secure sketch
–
Definition similar to that of sealed
extractor
–
Construction is in the RO model
•
Then apply standard extractors (as in
[DRS04])
–
This conversion is unconditional
Constructing sealed
sketch
•
Let (SS’, Rec’) be any secure sketch
•
Define (SS, Rec) as follows:
SS(w)
s’<

SS’(w)
h = H(w,s’)
output (s’,h)
Rec(w’,(s’,h))
w<

Rec’(w,s’)
if (h=H(w,s’) and
d(w,w’)
t)
output w
else “reject”
Intuition?
•
h
“certifies”
the recovered value w
–
But because of the RO model, it does not
leak (much) information about w
–
Also, because of RO model, impossible to
generate “forged” h without making
(explicitly) a certain query to the RO
•
Adversary doesn’t make this query (except
with small probability) since min

entropy of
recovered w is still “high enough”
Performance?
•
“Entropy loss” of w occurs in
essentially three ways
–
From
public part
s’ of underlying sketch,
and
application of (standard) extractor
•
Bounded in [DRS04]
–
Due to the
error model
itself
•
Inherent if we are using this strong model
–
From the
sealed extractor construction
•
Roughly a loss of (log
Vol
t,n
) bits
Construction II
•
Specific to remote authentication
•
Idea
: “bootstrap” using auth. protocol
that can handle non

uniform shared
secrets
–
“Problem” of non

uniformity goes away
–
All we are left with is the issue of error

correction
Specifics…
•
Use a
password

only authentication
(and key exchange) protocol
(PAK)!
•
These were designed for use with
“short” passwords…
•
…But no reason to limit their use to
this application
Brief introduction/review
•
Problem:
–
Two parties share a password from a
(constant

size) dictionary D
–
If D is “small” (or has low min

entropy),
an adversary can always use an on

line
attack to “break” the protocol
–
Can we construct a protocol where this
is the best an adversary can do?
Introduction/review
•
Specifically, let Q denote the number
of “on

line” attacks
–
Arbitrarily

many “off

line” attacks are
allowed
•
Then adversary’s probability of
success should be at most Q/D
–
Or Q/2
min

entropy(D)
Introduction/review
•
Can view PAK protocols in the
following, intuitive way:
–
Each on

line attack by the adversary
represents a
single “guess”
of the actual
password
–
This is the
best
an adversary can do!
Constructions?
•
[Bellovin

Merrit]…
•
[BPR,BMP]
–
definitions, constructions
in random oracle/ideal cipher models
•
[GL]
–
construction in standard model
•
[KOY]
–
efficient
construction in
standard model, assuming public
parameters
Application to remote
authentication
User
Server
s = SS(w
*
)
(w)
(s, w
*
)
s
w
*
= Rec(s, w)
Run PAK using
“password” (s,w
*
)
Intuition
•
Even if adversary changes s, the value
w’ recovered by the user still has
“high enough” min

entropy
•
By security of PAK protocol,
adversary reduced to guessing this w’
Performance?
•
Using a secure sketch is enough
–
Do not need fuzzy extractor
•
PAK protocol doesn’t need uniform secrets!
–
Save 2log(1/
) bits of entropy
•
This approach works even when
residual min

entropy is small
–
Can potentially apply even to mis

typed
passwords
Summary
•
Two approaches for using biometric data
for remote authentication
–
“Drop

in” solution in RO model
–
Solution specific to remote authentication in
standard model
•
Compared to previous work:
–
Solutions tolerating
more general errors
–
Achieve
mutual authentication
–
Improved bounds
on the entropy loss
–
Solution in
standard model
Comments 0
Log in to post a comment