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
As I noted in
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
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:
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
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
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.
paper has figures and more details.