Secure Biometric Authentication for Weak Computational Devices Mikhail Atallah (Purdue),Keith Frikken (Purdue), Michael Goodrich (UC- Irvine), Roberto Tamassia (Brown) March 3, 2005

FC 2005 Introduction Biometric Authentication Biometric Authentication Pros: Provides simple authentication mechanism Pros: Provides simple authentication mechanism Cons: Changing is difficult and privacy concerns Cons: Changing is difficult and privacy concerns Difficulties: Difficulties: Readings vary each measurement Readings vary each measurement Standard techniques such as hashing won’t work Standard techniques such as hashing won’t work

FC 2005 Related Work Many schemes Many schemes [Chaum and Pedersen, 1993] [Chaum and Pedersen, 1993] [Davida et al, 1998] [Davida et al, 1998] [Bleumer, 1998] [Bleumer, 1998] [Davida and Frankel, 1999] [Davida and Frankel, 1999] [Juels and Wattenburg, 1999] [Juels and Wattenburg, 1999] [Davida et al, 1999] [Davida et al, 1999] [Juels and Sudan, 2002] [Juels and Sudan, 2002] [Clancy et al, 2003] [Clancy et al, 2003] [Impagliazzo and More, 2003] [Impagliazzo and More, 2003] [Kershbaum et al, 2004] [Kershbaum et al, 2004] [Dodis, 2004] [Dodis, 2004]

FC 2005 Our Goals Lightweight Authentication Scheme Lightweight Authentication Scheme Nothing more than hash functions Nothing more than hash functions Smartcard based Smartcard based No single point of failure No single point of failure Not smartcard Not smartcard Not server Not server Server compromise should not lead to the ability to impersonate user (even to the server) Server compromise should not lead to the ability to impersonate user (even to the server) Goal is to have a Biometric PIN for banking systems Goal is to have a Biometric PIN for banking systems

FC 2005 Framework Reader: Can be on card or other device, but this is what the user uses to read biometric Reader: Can be on card or other device, but this is what the user uses to read biometric Server: Stores information about clients Server: Stores information about clients Comparison Unit: Makes the comparison between the client’s information and server data and grants access Comparison Unit: Makes the comparison between the client’s information and server data and grants access Two biometrics are “close” if their hamming distance is below some threshold (we generalize this to other distances) Two biometrics are “close” if their hamming distance is below some threshold (we generalize this to other distances)

FC 2005 Adversary Model Adversary is defined by resources Adversary is defined by resources Smartcard Smartcard Uncracked (SCU) Uncracked (SCU) Cracked (SCC) Cracked (SCC) Fingerprint (FP) Fingerprint (FP) Eavesdrop Eavesdrop Communication Channel (ECC) Communication Channel (ECC) Server’s Database (ESD) Server’s Database (ESD) Comparison Unit (ECU) = ESD+ECC+”outcome” Comparison Unit (ECU) = ESD+ECC+”outcome” Malicious Malicious Communication Channel (MCC) Communication Channel (MCC) Things that are outside our model Things that are outside our model Adversaries that crack smartcard and give it back to user Adversaries that crack smartcard and give it back to user Malicious Server’s Database Malicious Server’s Database Malicious Comparison Unit Malicious Comparison Unit

FC 2005 Security Requirements Confidentiality: An adversary should not be able to learn the user’s fingerprint Confidentiality: An adversary should not be able to learn the user’s fingerprint Integrity: An adversary should not be able to impersonate the user to the comparison unit Integrity: An adversary should not be able to impersonate the user to the comparison unit Availability: An adversary should not be able to prevent a user from authenticating Availability: An adversary should not be able to prevent a user from authenticating

FC 2005 Confidentiality Have 3 oracles which are acceptable Have 3 oracles which are acceptable Oracle A: {0,1} |f’| → {0,1} where A(f) returns true if f is a match Oracle A: {0,1} |f’| → {0,1} where A(f) returns true if f is a match Oracle B:  → {0,1} log|f’| where B() returns various distances between readings Oracle B:  → {0,1} log|f’| where B() returns various distances between readings Oracle C: {0,1 } |f’| → {0,1} log|f’| where C(f) returns the distance between f and f’ (this is weakly secure) Oracle C: {0,1 } |f’| → {0,1} log|f’| where C(f) returns the distance between f and f’ (this is weakly secure)

FC 2005 False Starts Suppose f 0 and f 1 are readings of a fingerprint Suppose f 0 and f 1 are readings of a fingerprint How does “bank” determine if f 0 is close to f 1 without revealing private information How does “bank” determine if f 0 is close to f 1 without revealing private information Correctness: The distance should be computed correctly Correctness: The distance should be computed correctly Privacy: Minimal information should be revealed about f 0 and f 1 Privacy: Minimal information should be revealed about f 0 and f 1

FC 2005 False Starts False Start #1: False Start #1: Client sends f 1 to bank which compares to f 0 in the clear Client sends f 1 to bank which compares to f 0 in the clear Correct but not private Correct but not private False Start #2: False Start #2: Client sends H(f 1 ) to bank which compares to H(f 0 ) in the clear Client sends H(f 1 ) to bank which compares to H(f 0 ) in the clear Private but not correct Private but not correct

FC 2005 False Starts (cont.) False Start #3: False Start #3: Client sends f 1  r to server that compares it to f 0  r Client sends f 1  r to server that compares it to f 0  r Correct as dist(f 1  r,f 0  r) = dist(f 1,f 0 ) Correct as dist(f 1  r,f 0  r) = dist(f 1,f 0 ) Kind of private: individual bits are protected, but it leaks locations where things change Kind of private: individual bits are protected, but it leaks locations where things change False Start #4: False Start #4: Client sends Π(f 1  r) to server that compares it to Π(f 0  r) for a permutation Π Client sends Π(f 1  r) to server that compares it to Π(f 0  r) for a permutation Π Correct as dist(Π(f 1  r), Π(f 0  r)) = dist(f 1,f 0 ) Correct as dist(Π(f 1  r), Π(f 0  r)) = dist(f 1,f 0 ) Private if permutation is only used once Private if permutation is only used once If it is reused, then it has similar problems as #3 If it is reused, then it has similar problems as #3

FC 2005 Our Protocol Goal is to be able to update r value and permutation Π between each authentication Goal is to be able to update r value and permutation Π between each authentication Assume H is a keyed hash function Assume H is a keyed hash function Before a round, server has Before a round, server has s i  Π i (f i  r i ),H(s i ),H(s i,H(s i+1 )) s i  Π i (f i  r i ),H(s i ),H(s i,H(s i+1 )) Before a round client(smartcard) has: Before a round client(smartcard) has: Π i, r i, s i, s i+1 Π i, r i, s i, s i+1

FC 2005 Protocol -- Authentication 1. Client obtains f i+1, and generates r i+1, s i+2, and Π i+1 2. It sends to the server Π i (f i+1  r i ), s i, and some transaction information T 3. Server tests if H(s i ) matches previously stored value H(s i ) matches previously stored value s i  Π i (f i+1  r i ) is close to the previously stored s i  Π i (f i  r i ) s i  Π i (f i+1  r i ) is close to the previously stored s i  Π i (f i  r i ) 4. If there is a match, then server temporarily performs T, and it sends H(T) back to the user

FC 2005 Protocol -- Update 1. Client tests if transaction information matches request Yes then continue to 2 Yes then continue to 2 No then abort wipe out this set of key information No then abort wipe out this set of key information 2. Client sends to server s i+1  Π i+1 (f i+1  r i+1 ), H(s i+1 ), and H(s i+1,H(s i+2 )) 3. The server verifies that H(s i,H(s i+1 )) matches the previous value If yes, then it commits transaction and updates values If yes, then it commits transaction and updates values If no, it aborts If no, it aborts

FC 2005 Security Summary Confidentiality: The cases where the adversary learns the fingerprint are : (FP) or (SCC and ESD) or (SCU, ESD, and MCC) or weakly in the case of (SCU and ECU) or any superset of these cases Confidentiality: The cases where the adversary learns the fingerprint are : (FP) or (SCC and ESD) or (SCU, ESD, and MCC) or weakly in the case of (SCU and ECU) or any superset of these cases Integrity: The cases where the adversary can impersonate the user are : (SCU and FP) or (SCC and ESD) or (ESD and MCC) or weakly in the case of (SCU and ECU) or any superset of these cases Integrity: The cases where the adversary can impersonate the user are : (SCU and FP) or (SCC and ESD) or (ESD and MCC) or weakly in the case of (SCU and ECU) or any superset of these cases Availability: The cases where the adversary can deny access to the user are : (SCU) or (MCC) or any superset of these cases Availability: The cases where the adversary can deny access to the user are : (SCU) or (MCC) or any superset of these cases

FC 2005 Security Summary ResourcesConfidentialityIntegrityAvailability FPNoStrongStrong SCC and ESD NoNoNo SCU and FP NoNoNo MCC and ESD StrongNoNo SCU, ESD, MCC NoNoNo MCCStrongStrongNo SCUStrongStrongNo SCU and ECU WeakWeakNo

FC 2005 Extensions Extended to other distances Extended to other distances Storage-Computation Tradeoff: Storage-Computation Tradeoff: Previous scheme requires several values to be stored on smartcard (in case of mismatches) Previous scheme requires several values to be stored on smartcard (in case of mismatches) Can reduce storage by increasing computation (similar to SKEY) Can reduce storage by increasing computation (similar to SKEY)

FC 2005 Summary Have introduced lightweight biometric scheme that uses only hash functions Have introduced lightweight biometric scheme that uses only hash functions No single point of failure No single point of failure Future Work: Future Work: Must update values in our protocol Must update values in our protocol