This is the fourth of a series of posts discussing the paper A Comprehensive Approach to Cryptographic and Biometric Authentication from a Mobile Perspective.
Biometrics are a strong form of authentication when there is assurance of liveness, i.e. assurance that the biometric sample submitted for authentication belongs to the individual seeking authentication. Assurance of liveness may be relatively easy to achieve when a biometric sample is submitted to a reader in the presence of human operator, if the reader and the operator are trusted by the party to which the user is authenticating; but it is practically impossible to achieve for remote authentication with a reader controlled by the authenticating user. When there is no assurance of liveness, security must rely on the relative secrecy of biometric features, which is never absolute, and may be non-existent. Fingerprints, in particular, cannot be considered a secret, since you leave fingerprints on most surfaces you touch. Using a fingerprint as a login password would mean leaving sticky notes with your password everywhere you go.
In addition to these security caveats, biometric authentication raises acute privacy concerns. Online transactions authenticated with biometric features would be linkable not only to other online transactions, but also to offline activities of the user. And both online and offline transactions would become linked to the user’s identity if a biometric sample or template pertaining to the user became public knowledge or were acquired by an adversary.
Yet, in Section 3, the paper proposes a method of using biometrics for user authentication on a mobile device to an application back-end. The method addresses the above security and privacy concerns as follows:
- First, biometrics is not used by itself, but rather as one factor in multifactor authentication, another required factor being possession of a protocredential stored in the user’s device, and another optional factor being knowledge of a passcode such as a PIN.
- Second, the paper suggests using an iris scan, which provides more secrecy than fingerprints. (The scan could be taken by a camera on the user’s mobile device. The paper cites the work of Hao, Anderson, and Daugman at the University of Cambridge, which achieved good results with iris scans using a near-infrared camera. I have just been told that phone cameras filter our near-infrared light, so a special camera may be needed. The Wikipedia article on iris recognition discusses the use of near-infrared vs. visible light for iris scanning.)
- Third, no biometric-related data is sent by the user’s device to the application back-end, neither at authentication time nor at enrollment time. The biometric sample is used to regenerate a key pair on the device, and the key pair is used to authenticate the device to the back-end.
- Fourth, neither a biometric sample nor a biometric template are stored in the user’s device. Instead, the paper proposes to use one of several methods described in the literature, cited in Section 3.2, for consistently producing a biometric key from auxiliary data and genuine but varying biometric samples. Only the auxiliary data is stored in the device, and it is deemed unfeasible to recover any biometric information from the auxiliary data.
The resulting security and privacy posture is discussed in Section 4.4 of the paper.
As shown in Figure 3 (in page 22 of the paper), we combine the biometric key generation process with the key pair regeneration process of our protocredential-based authentication method. The biometric sample (the iris image in the figure) is a non-stored secret (the only one in this case), and the auxiliary data is kept in the protocredential as a non-stored-secret related parameter. The auxiliary data and the biometric sample are combined to produce the biometric key. A randomized hash of the biometric key is computed using a salt which is also kept in the protocredential, as a second non-stored-secret related parameter. The randomized hash of the biometric key is used to regenerate the key pair, in conjunction with the key-pair related parameters. The key pair regeneration process produces a DSA, ECDSA or RSA key pair as described in sections 2.6.2, 2.6.3 and 2.6.4 respectively. The public key is sent to the application back-end, and the private key is used to demonstrate possession of the credential by signing a challenge. Figure 4 (in page 23 of the paper) adds a PIN as a second non-stored secret for three-factor authentication; in that case the auxiliary data is kept encrypted in the protocredential, and decrypted by x-oring the ciphertext with a randomized hash of the PIN.
The combination of biometric key generation with our protocredential-based authentication method represents a significant improvement on biometric authentication methodology. There is an intrinsic trade-off between the consistency of a biometric key across genuine biometric samples and the entropy of the key, because the need to accommodate large enough variations among genuine biometric samples reduces the entropy of the key. In the above mentioned paper by Hao et al., the authors are apologetic about the fact that their biometric key has only 44 bits of entropy when the auxiliary data is known. But this is not a problem in our authentication framework, for two reasons:
- The auxiliary data is not public. An adversary must capture the user’s device to obtain it.
- An adversary who captures the user’s device and obtains the auxiliary data cannot mount an offline guessing attack against the biometric key. All biometric keys produce well-formed DSA or ECDSA key pairs, and most biometric keys produce well-formed RSA key pairs. To determine if a guessed biometric key is valid, the adversary must therefore use it to generate a key pair, and use the key pair to authenticate online against the application back-end, which will limit the number of guesses to a small number. Forty-four bits of entropy is plenty if the adversary can only make, say, 10 guesses.
Therefore our authentication method makes it possible to use low-entropy biometric keys without compromising security. This may enable the use of biometric modalities or techniques that otherwise would not provide sufficient security.
Nevertheless we do not advocate the routine use of biometrics for authentication. As pointed out in Section 10, while malware running on the user’s device after an adversary has captured it cannot obtain biometric data, malware running on the device while the user is using it could obtain a biometric sample by prompting the user for the sample. A biometric authentication factor should only be used when exceptional security requirements demand it and exceptional security precautions are in place to protect the confidentiality of the user’s biometric features.