Using Near-Field Communication for Remote Identity Proofing

This is the last of a four-part series of posts presenting results of a project sponsored by an SBIR Phase I grant from the US Department of Homeland Security. These posts do not necessarily reflect the position or the policy of the US Government.

We have just published a paper presenting the last three of the five solutions that we have identified in the research project on remote identity proofing that we are now finalizing. Solutions 3–5 use Near-Field Communication (NFC) technology for remote identity proofing. Each of the solutions uses a preexisting NFC-enabled hardware token designed for some other purpose as a credential in remote identity proofing. A native app running on an NFC-enabled mobile device serves as a relay between the NFC token and the remote verifier.

In Solution 3 the token is a contactless EMV payment card. In Solution 4, the token is a medical identification smart card containing a private key and a certificate that binds the associated public key to attributes and a facial image. In Solution 5, the token is an e-Passport with an embedded RFID chip that contains signed data comprising biographic data and a facial image.

In solutions 4 and 5 a native app submits to the verifier an audio-visual stream of the subject reading prompted text. The verifier matches the face in the video to the facial image in the NFC token, uses speech recognition technology to verify that the subject is reading the text that was prompted, and verifies that the audio and video channels of the stream are in synchrony by matching distinguishable visemes in the video channel to phonemes in the audio channel.

See also:

Revocable Biometrics Discussion at the Internet Identity Workshop

One thing I like about the Internet Identity Workshop (IIW) is its unconference format, which allows for impromptu sessions. A discussion during one session can raise an issue that deserves its own session, and an impromptu session can be called the same day or the following day to discuss it. A good example of this happened at the last IIW (IIW XXII), which was held on April 26-28, 2016 at the Computer History Museum in Mountain View, California.

During the second day of the workshop, a participant in a session drew attention to one of the dangers of using biometrics for authentication, viz. the fact that biometrics are not revocable. This is true in the sense that you cannot change at will the biometric features of the human body, and it is a strong reason for using biometrics sparingly; but I pointed out that there is something called “revocable biometrics”. Continue reading “Revocable Biometrics Discussion at the Internet Identity Workshop”

Biometrics and Derived Credentials

This is Part 4 of a series discussing the public comments on Draft NIST SP 800-157, Guidelines for Derived Personal Identity Verification (PIV) Credentials and the final version of the publication. Links to all the posts in the series can be found here.

As reviewed in Part 3, a PIV card carries two fingerprint templates for off-card comparison, and may also carry one or two additional fingerprint templates for on-card comparison, one or two iris images, and an electronic facial image. These biometrics may be used in a variety of ways, by themselves or in combination with cryptographic credentials, for authentication to a Physical Access Control System (PACS) or a local workstation. The fingerprint templates for on-card comparison can also be used to activate private keys used for authentication, email signing, and email decryption.

By contrast, neither the draft version nor the final version of SP 800-157 consider the use of any biometrics analogous to those carried in a PIV card for activation or authentication. Actually, they “implicitly forbid” the storage of such biometrics by the Derived PIV Application that manages the Derived PIV Credential, according to NIST’s response to comment 30 by Precise Biometrics.

But several comments requested or suggested the use of biometrics by the Derived PIV Application. In this post I review those comments, and other comments expressing concern for biometric privacy. Then I draw attention to privacy-preserving biometric techniques that should be considered for possible use in activating derived credentials.
Continue reading “Biometrics and Derived Credentials”

Biometrics in PIV Cards

This is Part 3 of a series discussing the public comments on Draft NIST SP 800-157, Guidelines for Derived Personal Identity Verification (PIV) Credentials and the final version of the publication. Links to all the posts in the series can be found here.

After Part 1 and Part 2, in this Part 3 I intended to discuss comments received by NIST regarding possible uses of biometrics in connection with derived credentials. But that requires explaining the use of biometrics in PIV cards, and as I delved into the details, I realized that this deserves a blog post of its own, which may be of interest in its own right. So in this post I will begin by reviewing the security and privacy issues raised by the use of biometrics, then I will recap the biometrics carried in a PIV card and how they are used.

Biometric security

When used for user authentication, biometrics are sometimes characterized as “something you are“, while a password or PIN is “something you know” and a private key stored in a smart card or computing device is “something you have“, “you” being the cardholder. However this is only an accurate characterization when a biometric sample is known to come from the cardholder or device user, which in practice requires the sample to be taken by, or at least in the presence of, a human attendant. How easy it was to dupe the fingerprint sensors in Apple’s iPhone (as demonstrated in this video) and Samsung’s Galaxy S5 (as demonstrated in this video) with a spoofed fingerprint shows how difficult it is to verify that a biometric sample is live, Continue reading “Biometrics in PIV Cards”

Strong Authentication with a Low-Entropy Biometric Key

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:

  1. 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.
  2. 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.)
  3. 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.
  4. 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:

  1. The auxiliary data is not public. An adversary must capture the user’s device to obtain it.
  2. 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.

New Research on Mobile Authentication

This is the first of a series of posts discussing the paper A Comprehensive Approach to Cryptographic and Biometric Authentication from a Mobile Perspective

In the next few posts I will be reporting on research that we have been doing over the last six months related to cryptographic and biometric authentication, focused on mobile devices. I have held off from writing while we were doing the research but now I have a lot to say, so stay tuned.

By the way, in the last six months we have also moved from San Diego to San Jose. I used to work in Silicon Valley, so it’s nice to be back here and renew old friendships. If you are interested in cryptographic and/or biometric authentication and you are based in Silicon Valley or passing by, let me know; I would be happy to meet for coffee and chat.

The starting point of the this latest research was the work we presented at the NIST Cryptographic Key Management workshop last September (Key Management Challenges of Derived Credentials and Techniques for Addressing Them) and at the Internet Identity Workshop last October (New Authentication Method for Mobile Devices), and wrote up in the paper Strong and Convenient Multi-Factor Authentication on Mobile Devices.

In that early work we devised a mobile authentication architecture where the user authenticates with an uncertified key pair, and a method for regenerating an RSA key pair from a PIN and/or a biometric key. The architecture facilitates implementation by encapsulating the complexities of cryptography and biometrics in a Prover Black Box located in the device and Verifier Black Box located in the cloud, while the key pair regeneration method protects the credential against an adversary who captures the user’s mobile device, by preventing an offline attack against the PIN and/or the biometric key. The architecture was primarily intended for mobile devices but could be adapted for use in traditional PCs by means of browser extensions.

The early work left three questions open:

  1. Can the key pair regeneration method be adapted to cryptosystems other than RSA? This question is practically important because RSA can be used for encryption, and is therefore subject to export controls. The export restrictions have been relaxed a lot since the nineties, but they are so complex that consultation with a lawyer may be required to figure out whether and to what extent they are applicable to a particular product.
  2. Can the mobile authentication architecture accomodate credentials other than uncertified key pairs, including public key certificates and privacy-enhancing credentials such as U-Prove tokens and Idemix anonymous credentials? Uncertified key pairs are ideal for returning-user authentication, but they cannot be used to provide evidence that the user is entitled to attributes asserted by authoritative third parties.
  3. Does the architecture support single sign-on (SSO)? SSO is an essential usability feature when multiple frequently used applications require multifactor authentication.

I am happy to report that we have found good answers to all three questions. First, we have found efficient regeneration methods for DSA and ECDSA key pairs; since DSA and ECDSA can only be used for digital signature, they are not subject to export restrictions. Second, we have found a way of extending the architecture to accomodate a variety of credentials, including public key certificates and privacy-enhancing credentials, without giving up on the strong security properties of the original architecture. Third, we found have found two different ways of providing SSO, one of them well suited for web-wide consumer SSO, the other for enterprise SSO; and both applicable to a mix of web-based apps and apps with native front-ends.

An unanticipated result of the research was the discovery of a defense against an adversary who has succeeded in spoofing a TLS server certificate. Spoofing a certificate is difficult, but not unheard of. The defense, which relies on a form of mutual cryptographic authentication, prevents a man-in-the-middle attack and helps the user detect that a server controlled by the adversary is masquerading as a legitimate server using the spoofed certificate.

We have written all this up in a technical whitepaper,

The paper is quite long, because we thought it was important to describe everything in one place, showing how it all fits together. It would be difficult to discuss the entire paper at once, but in the next few posts I will go one by one over some of the topics in the paper; hopefully that will make it easier to discuss each topic. Watch for the next post in a few days.

Techniques for Implementing Derived Credentials on Mobile Devices

Update (April 3, 2013). There is a more recent blog post with important new information on the topic of derived credentials.

Update (September 25, 2012). We made a presentation on this topic at the Cryptographic Key Management Workshop that was held on September 10-11 at NIST.

We live in the Age of Mobile, and US Federal agencies, like all enterprises, want their employees to use smart phones and tablets. But they face a serious obstacle: how to authenticate users on mobile devices securely.

As I noted in the previous post, ordinary passwords are even less secure on mobile devices than on desktops and laptops, and one-time passwords provide only limited security because they can be intercepted or observed and they remain valid for several minutes. Authentication of federal employees requires the much stronger cryptographic and biometric security provided by Personal Identity Verification (PIV) smartcards in civilian agencies and Common Access Cards (CAC) in the Department of Defense.

It is difficult to use a smartcard to authenticate a user who is accessing an application on a mobile device. A contactless card could communicate with the device via Near Field Communication (NFC), but some mobile devices, including the iPhone, are not equipped with NFC today. A card reader could communicate with the mobile device via Bluetooth or WiFi, but that requires the user to carry three pieces of equipment: the card, the phone and the card reader.

NIST is working on a better authentication solution: derived credentials, which would provide the same security strength as PIV credentials but would be stored in the mobile device rather than in a separate smartcard. The Electronic Authentication Guideline defines a derived credential as a credential issued based on proof of possession and control of a token associated with a previously issued credential, so as not to duplicate the identity proofing process.

Derived credentials are a very good idea, but they present several challenges. One challenge is the cost of verifying a client certificate chain, in terms of bandwidth, latency and battery life. Another challenge is the lack of tamper resistant storage for credentials and biometric data in mobile devices. Yet another challenge is the complexity of cryptographic and biometric technology, which most app developers are not familiar with.

I believe that these challenges can be addressed using three techniques used in the mobile authentication methods that we described in the white paper

which I summarized in the previous post. We have written another white paper,

that describes each technique separately.

The first technique eliminates the costs associated with verifying client certificate chains by using public key cryptography without certificates. The device demonstrates knowledge of a private key, and the application verifies that the hash of the associated public key matches a field of a device record stored in an enterprise directory. The device record, in turn, contains a reference to a user record, identifying the user as the owner of the device.

The second technique obviates the need for tamper-resistant storage. Tamper-resistant storage is usually needed when a PIN and/or a biometric sample is used to enable the use of a key pair, so that an attacker cannot extract the key pair and use it without providing the PIN and/or the biometric, or extract the biometric template, or mount an offline attack against the PIN. We avoid the need for tamper resistance by regerenating the key pair from the PIN or from a biometric key derived from a biometric sample and an auxiliary string. An attacker who tampers with the device gains no advantage because the only way to know if a regenerated key is the correct one is by using it for online authentication.

The third technique shields app developers from the complexities of cryptography and biometrics by encapsulating the cryptographic and biometric computations in a Prover Black Box, which can be provided as a separate native app on the mobile device, and a Verifier Black Box, which can implemented as a server appliance. The application, which may interact with the user via a browser or via a native front-end, outsources authentication to the black boxes using interapp communication facilities available at least in iOS and Android.

The white paper has figures and more details.

Convenient One-, Two- and Three-factor Authentication for Mobile Devices

Authentication methods used today on mobile devices are both inconvenient and insecure.

Ordinary passwords are difficult to type on small touch-screen displays that require switching keyboards for entering digits or punctuation. They provide even less security on mobile devices than on desktops or laptops. Due to the difficulty of typing on mobile keyboards, each character is prominently displayed after it is typed, circumventing the security provided by password input boxes that displays dots in lieu of characters. And users are motivated to choose shorter and simpler passwords, which have less entropy.

One-time passwords are often used on mobile devices due to the lack of security of ordinary passwords. Authenticating with a one-time password requires entering a PIN, obtaining the one-time password from a hard token, a soft token, a text message, or an email message, and entering the one-time password. This is a very cumbersome procedure. A one-time password is a two-factor authentication method, and is thus more secure than an ordinary password. But they have limited entropy, and they can be replayed within a time-window of several minutes. An attacker who observes or intercepts a one-time password has several minutes during which he or she can use it to log in as the legitimate user.

Social login avoids some of the inconvenience of ordinary and one-time passwords by outsourcing authentication to a social network. If the user is already logged in to the social network, he or she does not have to enter a password again. Current standards for social login are a mess, as I said in the previous post, and as confirmed by the recent resignation of the editor of the OAuth protocol. In the previous post I linked to a white paper where we propose a better social login protocol, SAAAM, well suited for mobile devices.

But while social login is useful in some cases, it is not always appropriate. There is no reason why applications should always rely on social networks to authenticate their users, or why a user should have to surrender his or her privacy to a social network in order to authenticate to an unrelated application. Also, social login does not completely solve the authentication problem, since the user still has to authenticate to the social network.

So there is a need for good authentication methods on mobile devices that do not rely on a third party. We have just written a white paper proposing one-, two- and three-factor authentication methods for mobile devices that provide strong security and are more convenient to use than ordinary or one-time passwords. They are particularly well suited for enterprise use, but are suitable for consumer use as well.

The proposed authentication methods are based on public key cryptography, but they are easy to implement and deploy. They are easy to implement because all cryptography is encapsulated in black boxes, so that developers do not have to program any cryptographic operations. They are easy to deploy because they avoid the use of certificates and do not require a public-key infrastructure.

In our one-factor authentication method the user does not have to provide any input. The device authenticates by demonstrating knowledge of a private key. A hash of the associated public key is stored in a device record, which is linked to a user record in an enterprise directory or user database.

In our two-factor authentication method, the user provides a PIN, which is used to regenerate the key pair. Because any PIN results in a well-formed key pair, the user’s PIN is not exposed to an exhaustive offline guessing attack by an attacker who steals the mobile device, opens it, and reads its persistent memory.

In our three-factor authentication method, the user provides a PIN and a biometric such as an iris scan. No biometric template is stored in the mobile device. Instead, the device contains an auxiliary string that is used in conjunction with the biometric to provide a biometric key. The biometric key is used to regenerate the key pair. The auxiliary string is encrypted by the PIN for additional security.