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.

Comments requesting the use of biometrics

Comments 13 by Oberthur Technologies, 233 by Apple and 397 by
CertiPath requested the option of using biometrics for private key
activation. NIST responded that additional activation methods will be
considered in the next version of the document.
Comments 27 and 29 by Precise Biometrics suggested the use of
biometrics for remote issuance of derived credentials, and for remote
reset of the activation PIN or password.

Comment 26 by Precise Biometrics and NIST’s response are hard to
understand, but deserve to be explained.

The comment refers to
FIPS
201-2 which “specifies different authentication mechanisms that
can be used to fulfill LOA 4” and “can be used together as
multiple authentication factors to achieve even higher authentication
confidence at LOA 4“. This no doubt refers to Table 6-1, Table
6-2, Footnote 35, and Table 6-3 of FIPS 201-2. Table 6-1 renames the
four levels of assurance (LOA) of Section 2.1 of
OMB
memorandum M-04-04. Table 6-2 allows the use of the
authentication mechanisms called BIO-A, OCC-AUTH and PKI-AUTH, which I
explained in
Part 3, for
physical access control at LOA 4. Footnote 35 refers to
SP
800-116, which, as I also explained in Part 3, discusses
combinations of biometric and cryptographic authentication mechanisms
for authentication to a PACS. Table 6-3 is concerned with
“authentication for logical access“, i.e. with authentication
to obtain access to an information system rather than to a physical
facility; it allows the use of BIO-A, OCC-AUTH and PKI-AUTH for
authentication to a local workstation, i.e. a computer used by the
cardholder, but not to a remote server. In the “Suggested
Change” column, Precise Biometrics seems to be suggesting that,
although SP 800-157 is not concerned with the biometric authentication
mechanisms, nor with combinations of authentication mechanisms, it
should leave the door open for other documents to do so.

NIST’s response declined the suggested change arguing that SP 800-157
is aligned with FIPS 201-2 and SP 800-63. SP 800-63, the
Electronic
Authentication Guideline, is concerned with “remote authentication
of users (such as employees, contractors, or private individuals)
interacting with government IT systems over open networks“.

Regarding
FIPS
201-2, NIST’s response says that Table 6-3 allows only PKI-AUTH
(authentication with the PIV Authentication private key and
certificate) for “remote access control“, i.e. for logical
access to a remote information system. It is left unsaid
that SP 800-157 assigns derived credentials an extremely narrow scope,
ruling out their use for authentication to a local workstation or
physical access control. As reviewed in
Part 1,
this narrow scope was protested in many comments.

SP 800-63 is quoted as saying that biometric authentication uses
“information that is private rather than secret“, which makes
it unsuitable for remote access control according to SP 800-63. But
the reason why it is unsuitable for remote access control but not for local authentication
is that

In the local authentication case, where the Claimant is observed by an
attendant and uses a capture device controlled by the Verifier,
authentication does not require that biometrics be kept secret.

(SP 800-63, page 2, lines 2-5). So the real issue is not whether
authentication is local or remote, but whether it is attended or
unattended. As I explained in
Part 3, in
agreement with the above quote, when there is no assurance of
liveness, security depends on the relative secrecy of the biometric,
and more precisely on whether an adversary has access to a biometric
sample. If biometric authentication is deemed unsuitable for remote
authentication because it is unattended, it should also be deemed unsuitable
for the unattended biometric authentication methods BIO and OCC-AUTH
of FIPS 201-2 that I described in Part 3, and maybe even for
credential activation, which is also unattended.

I actually agree that biometric authentication, if used by itself
rather than as a means of activating a cryptographic authentication
credential, is unsuitable for remote access control, but for a
different reason. Such authentication would require the person who
wishes to authenticate to surrender his or her biometric privacy by
submitting a biometric sample to that system, exposing it to abuse or
compromise. Possible consequences of biometric abuse or compromise
were briefly discussed in
Part 3.

Comments expressing concern about biometric privacy

Biometric authentication is too often used in the private sector with
complete disregard for the privacy implications that I discussed in
Part 3. So I was
happy to see that some comments expressed concern for biometric
privacy.

SP 800-157 does not call for storing any biometrics in a mobile device
that carries derived credentials, but requires the use of a biometric
sample taken from the user for in-person credential issuance at LOA 4,
and for in-person reset of the activation PIN or password. The
draft
version required the sample used at issuance to be retained for
future reference and to be used for in-person reset. Comment 171 by
the Department of State, and duplicate comment 337 by the Federal
Public Key Infrasctructure Certificate Policy Working Group (FPKI
CPWG), asked for a reference to the Privacy Act on the need to protect
the retained sample. Similarly, comment 284 by Sam Wilke asked for a
reference to authority on retaining biometric information. Comment
243 questioned the need to collect the sample, since “In cases
where the same agency issues the PIV card and the derived credential,
we would already be in possession of the biometric template.”
(Actually, SP800-157 allows the issuer of the PIV card and the issuer
of derived credential to be different, but several comments objected
to this. I reviewed those comments in
Part
1, and argued that NIST is allowing the issuers to be different
for reasons that are not applicable.)

In response to the comments, NIST added a footnote stating that
“The retained biometric shall be protected in a manner that
protects the individual’s privacy“, and allowed the option of
comparing the biometric sample used for in-person reset against a
stored biometric on the PIV Card or biometric data stored in the
“chain-of-trust” (i.e. collected for use in a background check before
issuance of the PIV card) instead of comparing it against the retained
sample. But it declined to remove the request to retain a sample,
arguing that “The requirement is derived from the common policy and
it provides an audit trail for dispute resolution“.

Privacy-preserving biometrics

The use of a biometric sample to activate a cryptographic credential
that can in turn be used for authentication to a remote system avoids
the privacy risk inherent in sending the sample to the remote system.
But other risks remain. In particular, if the sample is compared to a
biometric template that is stored in a mobile device without tamper
protection, the template can be obtained by an adversary who
captures the device. Biometric information in the template can then
be used to construct a biometric sample that matches the template and
can be used to impersonate the user.

Perhaps the best way to avoid biometric privacy risks is to not store
biometrics in mobile devices. So I’m actually sympathetic to the
stance taken by SP 800-157 of not allowing any biometrics to be
carried in mobile devices along with derived credentials. But this is
not a realistic stance. PIV cards use biometrics to perform a variety
of functions, as we saw
in Part 3, and
there is a desire to be able to perform the same functions with a
mobile device, strongly expressed in the comments. Also, the
inclusion of software tokens among the options for implementing
derived credentials in SP 800-157, in spite of the security challenges that I
discussed in
Part 2,
shows that there is a desire to not be constrained by the
unavailability of physical tamper resistance.

So NIST should look for ways of using biometrics without compromising
privacy. There is a class of privacy-preserving biometric
authentication techniques can make that possible. These techniques
use the following general approach. An enrollment biometric sample is
used to compute helper data, which is later combined with an
authentication sample to produce a biometric key. The same
biometric key is produced consistently by varying but genuine samples
with a high probability, whose complement is akin to the false
rejection rate (FRR) of ordinary biometric authentication. A
different key is produced by a non-genuine sample with a high
probability, whose complement is similarly akin to the false
acceptance rate (FAR) of ordinary biometric authentication.

For a technique that follows this approach to be privacy-preserving,
it must be deemed unfeasible to derive significant biometric
information that might be useful to an adversary from the helper data.
This is the case, for example, in a technique originally proposed by Juels and
Wattenberg in their paper entitled
A Fuzzy Commitment
Scheme, and later successfully applied to authentication with an
iris image by Hao, Anderson and Daugman in their paper Combining
cryptography with biometrics effectively (available as a
technical
report). In that technique, the helper data is the exclusive-or
of a random codeword of an error-correction system and a binary
feature vector derived from a biometric sample. The random codeword
is not a random string, since it contains redundancy. But it is not
known how to derive significant biometric information from the fact
that the helper data is the exclusive-or of a feature vector with a
string that contains such redundancy.

In the technique of Juels et al. and Hao et al., the
biometric key is generated at random at enrollment time, and expanded
into the random codeword by adding redundancy. At authentication
time, the random codeword is recovered by x-oring the helper data with
a feature vector derived from the authentication sample, which
produces a string that differs from the codeword where the enrollment
and authentication feature vectors differ, and applying error
correction to the string. The biometric key is then obtained by
removing the redundancy from the codeword.

While this technique is well suited to biometric modalities where a
sample can be readily translated into a binary feature vector, other
privacy-preserving biometric techniques may be better suited to other
modalities. For example, the
Fuzzy
Vault technique of Juels and Sudan may be better suited for
modalities where a sample is more readily translated into a set of
feature points rather than a binary feature vector.

Surveys of privacy-preserving biometric techniques are available
here
and
here.

Using privacy-preserving biometric techniques for credential activation

The simplest way to use privacy-preserving biometric techniques to
activate one or more credentials stored in a mobile device is to store
the helper data and a cryptographic hash of the biometric key in the
device. An activation sample entered by the user is then combined
with the helper data to derive a biometric key. A hash of the derived
key is computed and compared to the stored hash. If they are equal,
the user is allowed to use the credentials.

This simple method protects the privacy of the biometric against an
adversary who captures the mobile device and extracts the helper data
and the hash of the biometric key. But it does not protect the
credentials themselves, which can be extracted by the adversary if
there is no physical tamper protection.

A more elaborate method is to store the helper data and encrypt the
credentials under the biometric key. This would protect the
credentials if the biometric key had sufficient entropy. But
unfortunately it does not. In their paper referenced above, Hao et
al. estimate that their biometric key has 44 bits of entropy. That’s
much more than the 20 bits of entropy of a 6-digit PIN that the
final
version of SP 800-157 allows for activation of credentials in a
software token unprotected by physical tamper resistance (cf. first
paragraph of Section 3.4 and Footnote 12). But it is not nearly
enough against an adversary who extracts the encrypted keys and mounts
a brute force attack against the biometric key using a botnet.

An effective method is to encrypt the credentials under a key that is
entrusted to a key storage service in the cloud, and retrieved from
the cloud using a device-authentication credential to authenticate to
the service. Because it is only used for that particular purpose, the
device-authentication credential can be derived on-demand from a
protocredential stored in the device and a secret not stored in the
device, in a way that deprives an adversary who captures the device
and obtains the protocredential of any information usable for mounting
an offline guessing attack against the non-stored secret (or any
parameter derived from the non-stored secret).

In
our comments
on the draft version of SP 800-157 we sketched a protocredential-based
activation technique that uses the activation passcode (PIN or
password) as the non-stored secret. The protocredential consists of
the domain parameters of a DSA key pair, a salt, and a device record
handle referring to a record in the key storage service. The
device-authentication credential derived from the passcode and the
protocredential consists of the DSA key pair and the device record
handle.

That technique can be easily modified to use a biometric key in lieu
of the passcode, as described in our technical report entitled
A
Comprehensive Approach to Cryptographic and Biometric Authentication
from a Mobile Perspective. In the modified technique, the
non-stored (relative) secret is the biometric sample supplied by the
user, the helper data is part of the protocredential, and the DSA key
pair is regenerated using the biometric key derived from the helper
data and the biometric sample instead of the passcode.

We have recently found an alternative way of deriving a
device-authentication credential from a protocredential and a
non-stored secret, where the non-stored secret may also be either a
passcode or a biometric sample.

If the non-stored secret is a passcode, the protocredential consists
of a device record handle and an uncertified key pair, and the
credential is derived simply by adding the passcode as an additional
component. To authenticate to the key storage service, the device
sends the passcode, the public key component of the key pair, and a
signature on a challenge computed with the private key. The service
verifies the signature, computes a joint hash of the passcode
and the public key, and compares the computed joint hash against a
stored joint hash. An adversary who captures the device may obtain
the key pair, but can only test guesses of the passcode by attempting
to authenticate online to the service, which limits the number of
attempts. An adversary who breaches the security of the key storage
service cannot mount an offline guessing attack against the PIN using
the joint hash without knowing the public key.

If the non-stored secret is a biometric sample, usable in conjunction
with helper data to derive a biometric key, the protocredential
consists of a device record handle, an uncertified key pair, and the
biometric helper data. The device-authentication credential consists
of the device record handle, the uncertified key pair, and the
biometric key derived from the helper data and the biometric sample.
To authenticate to the key storage service, the device sends the
biometric key, the public key component of the key pair, and a
signature on a challenge computed with the private key. The service
verifies the signature, computes a joint hash of the biometric
key and the public key, and compares the computed joint hash against a
stored joint hash. The biometric key is protected against an offline
guessing attack by an adversary who captures the device or breaches
the security of the key storage service.

See also:

• Part 1: NIST Fails to Address Concerns on Derived Credentials
• Part 2: NIST Omits Encryption Requirement for Derived Credentials
• Part 3: Biometrics in PIV Cards
• Part 5: Highlights of the NIST Worshop on PIV-Related Special Publications
• Part 6: NIST Looks at EMV to Speed up Physical Access with PIV Contactless Cards
• Part 7: Has Bluetooth Become Secure?
• Pomcor’s Derived Credentials page