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 #

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 W|SS(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 ) c2c2 (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