Tag: Multifactor

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.