Tag: Cryptography

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.
April 12, 2013
Defense in Depth of Cryptographic Credentials on a Mobile Device
This is the third of a series of posts discussing the paper

A Comprehensive Approach to Cryptographic and Biometric Authentication
from a Mobile Perspective.

Credentials based on public key cryptography provide much stronger
security than ordinary passwords or one-time passwords. But a mobile
device can be lost or stolen. How can a credential kept in a mobile
device be protected if the user’s device is captured by an adversary?
Two methods are traditionally used:
1. Private key encryption. The private key is encoded as
  specified by
  PKCS #8,
  together with cryptographic parameters that typically include the
  public key or a public key certificate, and the resulting encoded
  string is encrypted under a symmetric data-encryption key derived
  from a passcode. This method is used, for example to protect SSH
  credentials used to manage cloud-hosted virtual servers. But as
  explained in Section 4.3.1 of the
  paper
  this method requires a high-entropy password, which is exceedingly
  difficult to type on the touchscreen keyboard of a smart phone.
2. Tamper resistance. This is relied upon, for example to
  protect credentials in smart cards such as
  PIV
  or
  CAC
  cards. But few mobile devices have tamper resistant modules.
On an iPhone or an iPad one could think of relying on the data
protection method introduced in iOS 4, which encrypts data in a locked
device under a key derived from the passcode that the user enters to
unlock the device and a key embedded in a hardware encryption chip.
But, as explained in section 5.1 of the paper, that method has not
proved to be effective.

Instead, Section 2 of the paper proposes a method for using an
uncertified key pair for multifactor closed-loop authentication that
makes it possible to protect the key pair without relying on any
special hardware. The method is generally applicable, but is
particularly useful for authentication on a mobile device. The idea
is to store in the device cryptographic parameters obtained during
initial credential generation, at least one of them being a secret,
and later, at authentication time, to regenerate the credential
from the stored cryptographic parameters and non-stored secrets
supplied by the user such as a PIN and/or a biometric sample. (The
non-stored secrets could be supplied by a physical uncloneable
function, a PUF, in the case of an autonomous device; but the paper is
not concerned with autonomous devices.) We refer to the stored
parameters as a protocredential. Possession of the
protocredential counts as one authentication factor, while the
non-stored secrets play the role of additional authentication factors.

The paper distinguishes between parameters related to the key pair and
parameters related to the non-stored secrets. In the case where a PIN
is the only non-stored secret, illustrated in Figure 2, there is one
non-stored-secret related parameter, a salt used to compute a
randomized hash of the PIN. (Two-factor authentication with a
biometric sample and three-factor authentication with a PIN and a
biometric sample are discussed in Figures 3 and 4. I will discuss
biometric authentication in the next blog post.) The key-pair related
parameters depend on the public key cryptosystem being used. In the
case of DSA and ECDSA, the key-pair related parameters are
the domain parameters specified in the
Digital
Signature Standard. In the case of RSA, there is one key-pair
related parameter, the least common multiple &#x03BB of p-1
and q-1, where p and q are the prime factors of
the modulus. The key pair regeneration procedures for DSA, ECDSA
and RSA are described in sections 2.6.2, 2.6.3 and 2.6.4
respectively.

In a mobile device, once the key pair has been regenerated, it is used
by the device to authenticate to a mobile application with which the
device has been previously registered. The application may have a
native front-end or use a web browser as its front-end. The
application back-end has a database that contains a record for the
device, identified by a device record handle (a database primary key).
To authenticate, the device sends the device record handle and the
public key to the application back-end and demonstrates knowledge of
the private key by signing a challenge. The back-end verifies the
signature, uses the device record handle to locate the device record,
computes a cryptographic hash of the public key, and verifies that the
hash coincides with a hash stored in the device record. (A mobile
authentication architecture that allows application developers to
implement the authentication process without using a cryptographic API
is described in Section 7; I will discuss it in another post later in
this series.)

An adversary who captures the device and is able to read the
protocredential needs the non-stored secrets to be able to regenerate
the credential and authenticate. The adversary can try to guess the
non-stored secrets. If a PIN is the only non-stored secret and the
user chooses a 4-digit PIN, the adversary only has to try 10,000 PINs.
If the adversary can test each PIN offline, it is trivial to go
through all 10,000 PINs. But all PINs (in the case of DSA and ECDSA)
or most PINs (in the case of RSA) produce well-formed key pairs. If
the adversary does not know the public key (nor a hash of the public
key), the only way to test a PIN is to try to use the key pair that it
produces to authenticate online against the application back-end; and
the back-end can limit the number of guesses to a very small number,
such as 3 or 5 or 10. A 4-digit PIN can then be deemed to provide
sufficient security, just as 4-digit PIN is usually considered secure
enough for withdrawing cash from an ATM, which also limits the number
of PIN guesses.

To ensure that the adversary does not know the public key, the public
key should be treated as a shared secret between the device and the
application back-end. Treating a public key as a secret is an
unconventional and paradoxical use of public key cryptography.
Section 4.1 explains that a shared symmetric secret could be used
instead of a key pair but would result in a weaker security posture.

To prevent a man-in-the-middle attack, the device connects to the
back-end using TLS (or some other kind of secure connection).
Furthermore, the challenge signed by the device to demonstrate
knowledge of the private key includes the TLS server certificate
of the application back-end. Section 2.1 explains how this prevents a
man-in-the-middle attack even if the adversary is able to spoof the
TLS server certificate of the back-end.

All this results in a very strong defense-in-depth security posture.
As discussed in Section 4.2 and summarized in Table 1, authentication
is secure even against an adversary who is able to:
1. Capture the user’s device and read the protocredential from the
  device storage; or
2. Breach the security of the database back-end and obtain the hash
  of the public key. The adversary cannot mount an offline attack
  against a PIN used as single non-stored secret because the adversary
  does not have the protocredential, which contains at least one
  secret parameter. Compare this to the effect of a breach of
  database security when the database contains hashes of passwords,
  all of which become vulnerable to offline dictionary attacks; or
3. Breach network security and read the traffic from the device to
  the back-end (e.g. after the TLS connection has been terminated at a
  reverse proxy, in a misconfigured infrastructure-as-a-service
  cloud). Again, the adversary cannot mount an offline attack against
  the PIN; or
4. Spoof the TLS server certificate of the application back-end, as
  discussed above.
Also, in use cases demanding exceptionally high security, by using a
high-entropy set of non-stored secrets, it is possible to achieve
security even against an adversary who breaches database or
communication security and then captures the device and obtains the
protocredential.

We have seen how to protect an uncertified key pair used for
closed-loop authentication. How about other types of credentials?
Section 5 shows how the multifactor closed-loop authentication method
discussed above can be used to provide effective protection for data
stored in a mobile device, and in particular to provide protection for
any kind of credentials, including credentials used for open-loop
authentication, such as such as public key certificates, U-Prove
tokens or Idemix anonymous credentials.

In the next post I will discuss the use of a biometric sample as a
non-stored secret, and explain how it can achieve strong security
without putting at risk the confidentiality of the user’s biometric
features.
April 8, 2013
Closed-Loop vs. Open-Loop Authentication
This is the second of a series of posts discussing the paper

A Comprehensive Approach to Cryptographic and Biometric Authentication
from a Mobile Perspective.

In this post I want to take the time to explain and emphasize the
distinction made in the paper between closed-loop
authentication and open-loop authentication. This may seem
an unimportant matter of vocabulary, but the distinction is essential
for two reasons: first, because it helps understand the privacy
posture of authentication technologies; second, because it leads to
what we think is the best choice of cryptographic authentication
technologies for mobile devices.

The concepts of closed-loop and open-loop authentication are defined
in the introduction, and examples are given. In open-loop
authentication, a party such as a certificate authority or, more
generally a credential authority, issues a cryptographic credential to
the user’s device, and then is “out of the loop” when the device
presents the credential to a relying party. Credentials used in
open-loop authentication are typically public key certificates, but
could also be U-Prove tokens or Idemix anonymous credentials. In
closed-loop authentication, on the other hand, the credential
authority is involved in the authentication process, taking care of
verifying possession of the credential by the device. In third-party
closed-loop authentication, the credential authority is an identity or
attribute provider, which communicates user attributes to a relying
party after verifying that the device possesses the credential. In
two-party authentication, there is only one party besides the user’s
device, so two-party authentication can only be closed-loop
authentication.

The distinction between closed-loop and open-loop authentication
makes it possible to make two observations.

The first observation is that closed-loop authentication can rely on
an uncertified key pair, i.e. a key pair that is not bound to any
attributes by a certificate. (As a matter of vocabulary, we say that
an uncertified key pair is registered by the device with the
credential authority, rather than issued by the credential authority
to the device, because the credential authority plays no role in
generating the key pair; the paper refers to the credential authority
as “the party that issues or registers the credential”.) An
uncertified key pair can be used because the credential authority can
store user attributes in its internal storage and retrieve them at
authentication time. Therefore the attributes need not be included in
the credential.

The second observation is that, in third-party closed-loop
authentication, the credential authority, i.e. the identity or
attribute provider, is informed of the authentication transaction and,
typically, is told what relying party the user is authenticating to.
This impinges on the user’s privacy, especially if the user has no
choice of identity or attribute provider and does not trust the
provider. This is not just a theoretical consideration. The identity
providers most commonly used today have track records of privacy
violations, and users are wary of being spied upon.

Some time ago, before being concerned with mobile authentication, we
wrote a
white paper proposing
to eliminate this privacy drawback by using the browser to hide the
identity of the relying party. However, this would require
substantial modifications of core browser functionality. More
recently, in an
ICAM blog post, Anil
John has proposed hiding the identity of the relying party behind a
proxy. But that complicates authentication and serves only to shift
the trust issue from the identity provider to the proxy.

Open-loop authentication, on the other hand, does not suffer from this
privacy drawback.

These observations led us to the following choice of technologies for
cryptographic authentication on mobile devices:
- For the sake of simplicity, an uncertified key pair should be used
  for two-party authentication.
- For the sake of privacy, open-loop authentication should be used
  when attributes are asserted by a third party, except in special
  cases. Credentials used in open-loop authentication could be public
  key certificates, U-Prove tokens, or Idemix anonymous credentials,
  depending on the privacy requirements, as explained in section 6.1.
There are two special cases where it makes sense to use third-party
closed-loop authentication. One is social login, where an application
is granted limited access to the user’s account at a social network
such as Facebook or Twitter and authenticates the user as side-effect,
by obtaining user attributes from the user’s profile. In social
login, the social network is necessarily involved in the
authentication transaction. The other is third-party login using as
identity provider a personal data repository service that emphasizes
privacy and is freely chosen and trusted by the user. A company
participating in the
Personal Data Ecosystem
Consortium (PDEC), for example, could play the role of identity
provider.

However, this choice of technologies posed the problem of how to
protect the credentials used in open-loop authentication against an
adversary who captures the user’s mobile device, because the key pair
regeneration method, which I mentioned in the previous post and will
discuss in more detail in the next post, does not work for open-loop
authentication.

We were happy to find a simple solution to that problem. As described
in Section 5, key pair regeneration can be used to implement effective
data protection against an adversary who captures the device, by
encrypting the data under a data-encryption key, entrusting the key to
a key storage service (or splitting it cryptographically across
multiple services), and authenticating to the service(s) with a
regenerated key pair to retrieve the key. A credential used in
open-loop authentication can be protected as data in this way, thus
benefiting indirectly from the security provided by the key pair regeneration technique.

In the next post I will finally get into the technical details of the paper.
April 3, 2013
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,
- A Comprehensive Approach to Cryptographic and Biometric Authentication
  from a Mobile Perspective.
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.
March 29, 2013

Consistent Results from Inconsistent Data

This post is a continuation of my
report on the NIST
Cryptographic Key Management Workshop. In the previous post I
said I had more to say about Rene Struik’s presentation [1] because there are multiple connections between his
talk and our own presentation [2].

Dr. Struik proposed to use a physical uncloneable function (PUF) to
generate a cryptographic key when the device is turned on. A PUF is a
function implemented by a physical device that is difficult to predict
and difficult to duplicate in a different device. One way of
implementing a PUF is by applying stimuli to a device such as a chip,
and reading responses that are not determined by the design of the
chip, but depend instead on small random variations of the
fabrication process within the tolerances of the process
specification. For key generation, one stimulus is applied to the
device, viz. power, and one response is produced, an uncloneable key.

One problem with this key generation method is that the response
of the chip will be slightly different each time the device is turned
on. Struik proposed an elegant method of removing these differences
in order to obtain the same key consistently, and using these same
differences as an entropy source for true random number
generation.

I saw an interesting connection between Struick’s uncloneable key
and the hardware key used by Apple for data protection in iOS, which I
discussed during my talk.

Both keys are intended to be difficult to extract from the device
where they are used. The hardware key is built into the silicon of a
hardware encryption chip, whose interface does not allow the key to be
exported from the chip; but no claims are made as to the chip being
tamper resistant, so a well-equipped attacker may be able to read the
key by probing the silicon. By contrast, the uncloneable key is not
present in the device when the device is turned off and thus cannot be
extracted by probing the silicon; but custom code running on the
device could obtain the key when the device is turned on.

The two methods could be combined. For example, a device could
contain an encryption chip that would generate an uncloneable key when
power is applied, and the interface of the chip could prevent the key
from being exported. However, custom code running on the device could
still make use of the key, just like forensic tools are able to use
the hardware key in the iPhone in brute-force attacks to crack the user’s passcode [3] [4].

Another connection between the two presentations is that they
both proposed regenerating keys instead of storing them. In Struik’s
presentation a symmetric key was regenerated from the physical
properties of the device. In our presentation an RSA key pair was
regenerated from user input (a PIN and/or a biometric sample). Our
regeneration method is not applicable if there is no user, while
Struik’s is; on the other hand, when used in a user-controlled mobile
device, our method has the advantage that the key pair caonnot be
obtained by custom code running on a device that has been lost or
stolen.

But the most interesting connection, for me, was between Struik’s
method for consistently producing the same uncloneable key from a
succession of slightly different physical responses to power-on, and
the method of Hao, Anderson and Daugman [5] for
producing a consistent biometric key from a succession of genuine but
slightly different iris image samples. (In our presentation, we
proposed to use the method of Hao et al. in two- and/or three-factor
authentication.) Both methods are based on the same ingenious
adaptation of the error correction paradigm for producing consistent
results from inconsistent data (which was pioneered by Juels and
Wattenberg [6] for implementing fuzzy
commitments as explained below).

Error correction techniques were originally intended, and are most
often used, for correcting errors caused by the transmission of data
over a noisy channel. Redundancy added to the data at the source
makes it possible to correct a small number of errors at the
destination. (A unit of data to which redundancy has been added is
called a codeword.)

The small variations that occur between successive biometric
samples or between successive samples of an uncloneable key are similar
to errors produced by channel noise, but there is no correct source
data to which redundancy could be added to eliminate errors. If fact,
no errors are involved because, although one particular sample may
serve as a reference, no sample is more correct than any other
sample.

To remove data variations, error correction is used as follows:

A random codeword c is generated by adding redundancy to a
random string. The random codeword is of same length as a data
sample, but is otherwise unrelated to any data sample.
The random codeword c is bitwise x-ored with a reference
sample r to produce helper data h:

h = c ⊕ r.
When a new sample s is obtained, it is bitwise x-ored with
the helper data to produce

(c ⊕ r) ⊕ s.

Since x-or is associative, this is the same as

c ⊕ (r ⊕ s)

and since r and s are similar, i.e. differ only in a few
bits, the bit-string

d = r ⊕ s

consists mostly of zeros. Bitwise x-oring c with d
flips a few bits in c, thus having the same effect that could be
produced by transmitting c over a noisy channel.
Error correction is applied to recover the random codeword c from c ⊕
d. If desired, c can then be bitwise x-ored with h = c
⊕ r to obtain r.

What this accomplishes is that the same result is consistently
produced from the variable sample s, as long as s in not
too different from r. Either c or r can be used
as the consistent result. Struik uses r, but I believe he
could equivalently use c. Hao et al. use c, as their
biometric key. In biometric applications, it is important to use
c rather than r to avoid revealing the user’s biometric
sample r, which could be a privacy violation. The codeword
c contains no biometric information.

Juels and Wattenberg [6] used the same technique
for implementing fuzzy commitments; as far as I can tell, they were
the original inventors of the technique. In a cryptographic
commitment scheme, a sender commits to a value by combining it with a
witness to produce a blob, and sends the blob to a
receiver. The sender can later reveal the value by providing the
witness, which the receiver uses to compute the blob and verify that
it coincides with the one received earlier. The receiver cannot
derive the committed value from the blob without the witness, and only
one value, the original committed value, can be successfully revealed
by the sender. Juels and Wattenberg used the above technique to
devise a fuzzy commitment scheme that tolerates small variations in
the witness. With the above notations (different from their own), the
committed value is the codeword c, the witness is r, and
the blob is an ordered pair consisting of a conventional cryptographic
hash of c and the helper data h. When the sender
provides s to decommit the value, the receiver computes
c as above and verifies that the hash of the computed c
coincides with the hash in the blob received from the sender.

In their paper [6], Juels and Wattenberg made the
connection with biometric authentication, but not with physical
uncloneable functions.

References

[1]	Rene Struik. Secure Key Storage and True Random Number Generation – An Overview. NIST Cryptographic Key Management Workshop, September 2012.
[2]	Francisco Corella and Karen Lewison. Key Management Challenges of Derived Credentials and Techniques for Addressing Them. NIST Cryptographic Key Management Workshop, September 2012.
[3]	Andrey Belenko. Overcoming iOS Data Protection to Re-enable iPhone Forensics. Black Hat USA, July-August 2011.
[4]	Jean-Baptiste Bedrune and Jean Sigwald. iPhone data protection in depth. HITB Security Conference, May 2011.
[5]	Feng Hao, Ross Anderson and John Daugman. Combining Cryptography with Biometrics Effectively. IEEE Transactions on Computers, volume 5, number 9, pages 1081 – 1088, 2006. Available as a Cambridge Computer Laboratory technical report.
[6]	Ari Juels and Martin Wattenberg. A Fuzzy Commitment Scheme. ACM Conference on Computer and Communications Security, 1999.

October 7, 2012

Report on the NIST Cryptographic Key Management Workshop

This is a belated report on the Cryptographic
Key Management Workshop that was held by NIST on September 10-11.
Karen Lewison and I went to Washington DC for the workshop, where we
presented a talk on techniques for addressing the key management
challenges of derived credentials.

Cryptographic key management may seem to be a dry topic, but the workshop
was quite interesting, especially the second day, which looked at the
future. It was attended by about 50 cryptographers, and was webcast.
It began with a fascinating keynote address by Whitfield Diffie on the
history of cryptographic key management. His presentation
is online, but slides cannot do justice to the wealth of stories and
anecdotes that he narrated.

A Framework for Designing Cryptographic Key Management Systems

The main purpose of the workshop was to discuss the current drafts of
NIST
Special Publication 800-130, and NIST
Special Publication 800-152 and solicit comments on them.
(Instructions for sending comments on draft NIST publications can be
found at http://csrc.nist.gov/publications/PubsDrafts.html.)
SP 800-130 is a comprehensive framework of topics that should be
considered by anybody who has to specify a Cryptographic Key Management
System (CKMS); since key management is an essential aspect of
cryptography, the framework should be invaluable to anybody designing
a system that incorporates cryptographic functionality. SP 800-152
profiles the framework for cryptographic key management systems that
will be used in US Federal agencies, but goes beyond the systems
themselves to cover their procurement, installation, management, and
operation.

The two publications were discussed during the first day of the
workshop. I cannot possibly go over the very detailed discussions
that took place, so I will limit myself to repeating one comment I
made regarding Section 4.7 of SP 800-130, “Anonymity, Unlinkability
and Unobservability”, and expanding upon it.

Anonymity, unlinkability and unobservability are privacy features
that may not be directly relevant to the authentication of Federal
employees in the course of their work, but they are very relevant to
the authentication of both consumers on the Web at large, and citizens
who access Federal information systems. Traditional authentication by
username and password provides these three privacy features; but
passwords have well-known security and usability drawbacks, one of
them being the difficulty of remembering many different passwords.
One way of reducing the number of passwords to be remembered is to
rely on a third-party identity provider (IdP), so that one password
(presented to the IdP) can be used to authenticate to any number of
relying parties. The Federal Government allows citizens to access
government web sites through redirection to several Approved
Identity Providers.

But third party login has privacy drawbacks. In usual
implementations, anonymity is lost because the relying party learns
the user’s identity at the IdP, unlinkability is lost by the use of
that identity at multiple relying parties, and unobservability is lost
because the IdP is informed of the user’s logins. Profiles
of third-party login protocols approved for citizen login to
government sites mitigate some of these drawbacks by asking the
identity provider to provide different identities for the same user to
different relying parties. This mitigates the loss of anonymity, and
the loss of unlinkability to a certain extent. (Relying parties by
themselves cannot track the user, but they can track the user in
collusion with the IdP.) But the loss of unobservability is not
mitigated, because the IdP is still informed of the user’s activities.

I believe that the Government should work to develop and promote
authentication methods that eliminate passwords while preserving
anonymity, unlinkability and unobservability. Cryptographic
authentication with a key pair, using different key pairs for
different relying parties, can be a basis for such methods.

A Look at the Future

The second day of the workshop featured presentations on capabilities
of future cryptographic key management systems, ranging from
innovative to futuristic. (Both days’ presentations can be found in
the workshop
web page.)

Tim Polk, manager of the Cryptographic Technology Group at NIST,
motivated
the talks that followed by going over challenges identified during
the development of the CKMS framework, related to interoperability
across security domains, algorithmic agility, constrained devices,
privacy, and scalability. He also stressed the need to develop CKMSs
that are resilient to quantum computing attacks before it is too late.

Dennis Branstad of NIST discussed security
policies, stating as a goal their automated specification,
negotiation and enforcement.

Anna Lysyanskaya of Brown University discussed her
work on anonymous credentials. She mentioned a new technique for
revocation of anonymous credentials that was presented at Crypto 2012
by Libert, Peters and Yung, and said she thought it deserved the best
paper award. I believe a full version of the conference paper can be
found at http://eprint.iacr.org/2012/442.
I haven’t read the paper yet. Revocation of privacy-enhancing
credentials is practically difficult; I have discussed the topic in
several earlier posts.

Paul Lambert of Marvell Semiconductors discussed authentication
and privilege management for devices connected by wireless area
networks. I was glad to hear him propose the use of a raw key
pair as a credential. I later proposed the same thing in the talk on
derived credentials.

Lily Chen of NIST discussed the difficult key management problem of handing
over a secure link as a smart phone travels from one network to
another, when the networks use technologies that may be as different
as UMTS and WiFi.

Sarbari Gupta of Electrosoft discussed key
management in a cloud environment. She argued that the Federal
Risk and Authorization Management Program (FedRAMP) does not have
sufficient requirements for secure key management, and advocated the
establishment of a Federal Profile for Cloud Key Management.

Elaine Barker of NIST went over the intricacies and subtleties of random
bit generation, and solicited comments on Draft
Special Publication 800-90B (entropy sources) and
Draft Special Publication 800-90C (RBG Constructions, DRBGs and
NRBGs). Comments are due December 3rd.

Rene Struik discussed a method of secure
key storage and true random number generation using physical
unclonable functions (PUFs). The idea is to use accidental properties
of a device to generate a unique key when the device is turned on.
(So I would say that his technique is closer to key generation than
key storage.) Error correction is used to remove minor differences in
subsequent key generations. As an additional benefit, those
differences are used for random number generation. This very interesting
work is related in multiple ways to our own work on mobile
authentication and derived credentials; I plan to discuss it in more
detail in the next blog post.

Mary Theofanos of NIST went over two case studies of usability
of key management procedures: a PKI deployment, and a PIV pilot.
My personal getaways: the designer of a key management system must
know the users and their mental models of security; must provide
multiple authentication methods, e.g. by retaining username-password
as a backup for a cryptographic credential; and must not require
frequent PIN changes.

The usability talk was followed by a panel that presented three
use cases of cross-domain interactions. Bob Griffin of RSA
discussed key management in the cloud. Saikat Saha of SafeNet
discussed virtualized hardware security modules. John Leiseboer of
Quintessencelabs discussed quantum key distribution; this was the
first presentation I’ve attended related to quantum cryptography, and
it motivated me to find out more about this futuristic topic.

Derived Credentials

Finally, I gave a presentation on mobile
authentication and derived credentials, co-authored with Karen
Lewison. Even though this was the last presentation at the end of a
long day of talks, I was gratified that, as far as I know, nobody
snuck out early to the Dogfish Head brewery across the street from the
NIST campus 🙂 . Derived credentials is a NIST
concept referring to credentials that, in the future, will be
installed in a mobile device after the user of the device
authenticates with a PIV card. Our presentation went over three
techniques for implementing derived credentials that we proposed
earlier in a blog
post and a white
paper, viz. public key cryptography without certificates, key pair
regeneration as an alternative to tamper resistance, and encapsulation
of cryptographic and biometric processing in a “prover black box” and
a “verifier black box” to insulate app developers from the
complexities of cryptography and biometrics.

But we also went beyond derived credentials, in response to a request
made by Elaine Barker on behalf of Dennis Branstad before the
workshop. We discussed extensions of our techniques, for
authentication across security domains, for social login without
passwords, and for data protection at rest without tamper resistance.
Since then we have put online a whitepaper on
the data protection work. We have not yet written whitepapers on
authentication across security domain or social login without
passwords.

Wrap-up

Tim Polk wrapped up the workshop by encouraging everybody to send
comments. Although there is an official comment period for each draft
publication, NIST welcomes comments at any time.

Like the workshop on privacy-enhancing technology I attended last
year, this workshop was both enjoyable and very useful. I’m glad to
be on the email distribution list, and I’m looking forward to the next
cryptography workshop at NIST.

September 25, 2012

Effective Data Protection for Mobile Devices

With iOS 4 Apple introduced a new method for protecting the data
stored in an iPhone, an iPad or an iPod when the device is lost or
stolen and the user has locked the device with a passcode (usually a
4-digit PIN) [1]. Different categories of data are
encrypted under different keys, which are arranged in a key hierarchy.
Some of the keys in the hierarchy are derived from the user’s
passcode. However, every key that is derived from the passcode is
also derived from a hardware key, which is hardwired into the
silicon of a “hardware encryption chip” and cannot be extracted from
the device by a casual attacker. This means that an attacker who
steals a mobile device, opens it, and extracts data encrypted under
the passcode cannot mount an offline attack against the passcode.
That is, the attacker cannot try passcodes at high speed to find the
one that decrypts the data, because trying passcodes requires the
hardware key.

But the protection provided by the hardware encryption key, at least
in iOS 4 and 5, has been defeated
[2]
[3]
[4].
An attacker who steals an iPhone does not need to open it. The
attacker can exploit an OS vulnerability or a firmware vulnerability
to run custom code on the device. The custom code can read the
encrypted data and, although it cannot extract the hardware key, it
can use it to mount an “offline” attack on the device itself. The
practical effect of the hardware key is only to force the attacker to
run the attack on the CPU of the device, which is relatively slow.
But it only takes 40 minutes to try all 4-digit PINs
[2].

Would the hardware encryption key provide effective protection if
Apple succeeded in eliminating all vulnerabilities that make it
possible to run custom code? (It does not seem to have eliminated
them in iOS 6, used in the recently released iPhone 5
[5].) An attack would be more difficult, but probably
still possible. The attacker would have to open the phone to read the
contents of the flash memory. The attacker might be able to not just
read but also modify the contents of the flash memory, and thus run
custom code, which could then use the hardware key to mount an offline
attack against the passcode. The attacker might even be able to probe
the silicon of the hardware encryption chip and extract the hardware
key. Nobody has claimed to have done any of these fancy attacks, but
that’s because exploiting vulnerabilities is much easier.

In the white paper

Effective Data
Protection for Mobile Devices.

we have proposed a data protection method for mobile devices that
does not require a hardware key, or any tamper resistance, and is
effective even if the attacker is able to run custom code on the
device. The data is encrypted under a (symmetric) data encryption key
that is entrusted to an online server provided by the mobile network
operator, or by the mobile device manufacturer, or by the provider of
the mobile operating system, or by an independent data protection
service provider trusted by the user. (The key can also be split
using Shamir’s secret sharing technique into n “portions”
entrusted to n different servers, so that k portions are
needed to reconstruct the key. For example, with n = 5 and
k = 3, portions of the key can be distributed to 5 different
servers, and any 3 of those portions can be used to reconstruct the
key.)

The key, or the portions of a split key, are retrieved when the
user authenticates to unlock the phone, with a PIN, an iris image
taken by a camera carried by the device, or both. User authentication
regenerates an RSA key pair which the device uses to authenticate to
the server(s). When a PIN is used, it is not vulnerable to an offline
attack by an attacker who tampers with the phone; and when an iris
image is used, no biometric sample or template is stored anywhere.

References

[1]	Apple. iOS: Understanding data protection. October 28, 2011.
[2]	Vladimir Katalov. ElcomSoft Breaks iPhone Encryption, Offers Forensic Access to FileSystem Dumps. March 23, 2011.
[3]	Andrey Belenko. Overcoming iOS Data Protection to Re-enable iPhone Forensics. 2011.
[4]	Jean-Baptiste Bedrune and Jean Sigwald. iPhone data protection in depth.
[5]	Emil Protalinski, The Next Web. The Apple iPhone 5 has reportedly been jailbroken. September 22, 2012.

September 23, 2012

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.

July 30, 2012
NSTIC Is Not Low-Hanging Fruit
In a
recent
tweet, Ian Glazer quoted Patrick Gallagher, director of NIST,
saying at a
recent
White House meeting on NSTIC that the “current suite of
technologies we rely on are insufficient”.

The identity technologies used today both in federal agencies and on
the Web at large are indeed insufficient:
- SSL client certificates have failed to displace passwords for
  Web authentication since they were introduced 17 years ago.
- Credentials in PIV cards have failed to displace passwords in federal
  agencies eight years after HSPD 12; a
  GAO
  report does a good job of documenting the many obstacles faced by
  agencies in implementing the directive, ranging from the fact that
  some categories of agency employees do not have PIV cards, to the
  desire by employees to use Apple MAC computers and mobile devices that
  lack card readers. I’m glad that we don’t live in the Soviet Union
  and heads of agencies are not sent to the Gulag when they ignore
  unreasonable orders.
- Third-party login solutions such as OpenID, as currently used on the
  Web, not only do not eliminate passwords, they make the password
  security problem worse, by facilitating phishing attacks. They also
  impinge on the user’s privacy, because the identity provider is told
  what relying parties the user logs in to.
- Social login solutions based on OAuth, e.g. “login with Facebook”,
  worsen the privacy drawback of third party login by limiting the
  user’s choice of identity providers to those that the relying party
  has registered with, and by broadcasting the user’s activities to the
  user’s social graph. Eric Sachs of Google said at the last Internet
  Identity Workshop that users participating in usability testing were
  afraid of logging in via Facebook or Google+ because “their friends
  would be spammed”.
But some proponents of NSTIC do not seem to realize that. In a
recent
interview, Howard Schmidt went so far as to say that NSTIC is
“low-hanging fruit”, because “the technology is there”. What
technology would that be? In a
blog
post that he wrote last year shortly after the launch of NSTIC, it
was clear that the technology he was considering for NSTIC was
privacy-enhancing cryptography, used by Microsoft in
U-Prove and by IBM in
Idemix. He
used the words “privacy-enhancing” in the interview, so he may have
been referring to that technology in the interview as well.

(Credentials based on privacy-enhancing cryptography provide selective
disclosure and unlinkability. Selective disclosure refers to the
ability to combine multiple attributes in a credential but disclose
only some of them when presenting the credential. Unlinkability, in
the case of U-Prove, refers to the impossibility of linking the use of
a credential to its issuance; Idemix also makes it impossible to link
multiple uses of the same credential.)

But Idemix has never been deployed commercially, and an attempt at
deploying U-Prove within the Information Cards framework failed when
Microsoft
discontinued CardSpace, two months before the launch of NSTIC.

Credentials based on privacy-enhancing cryptography, sometimes called
anonymous credentials, have inherent drawbacks. One of them is that
unlinkability makes revocation of such credentials harder than
revocation of public key certificates, as I pointed out in a
blog post on U-Prove and another
blog
post on Idemix. The difficulty of revoking credentials based on
privacy-enhancing cryptography has led ABC4Trust, which can be viewed
as the European counterpart of NSTIC, to propose arresting
users for the purpose of revoking their credentials! See page 23,
end of last paragraph, of the ABC4Trust document
Architecture
for Attribute-based Credential Technologies.

Another inherent drawback is that it is difficult to keep the owner
of an anonymous credential from
making
it available for use online by others who are not entitled to it.
For example, it would be difficult to prevent the owner of a
proof-of-drinking-age anonymous credential (a use case often cited by
proponents of anonymous credentials) from letting minors use it for
a fee.

The mistaken belief that “the technology is there” explains why the
NSTIC NPO has made little effort to improve on existing technology.
Instead of requesting funding for research, it requested funding for
pilots; a pilot is usually intended to demonstrate the usability of a
newly developed technology; it assumes that the technology already
exists. After the launch of NSTIC, the NPO announced three workshops,
on governance, privacy and technology. The first two were held, but
the workshop on technology, which was supposed to take place in
September of last year, was postponed by six months and merged with
the yearly
NIST
IDtrust workshop, which took place in March of this year. The
IDtrust workshop usually includes a call for papers. But this year
there was none: new ideas were not solicited.

The NSTIC NPO has been trying to “bring relying parties to the
table”.
Ian Glazer dubbed the recent White House meeting the
NSTIC Relying Party Event.
The meeting was about
getting a bigger table according to the NPO blog post on the event, and about “getting people
to volunteer” according the Senator Mikulski as quoted by
the blog post.
Earlier, Jim Sheire of the NPO convened a session entitled
NSTIC
How do we bring relying parties to the table? at the last Internet
Identity Workshop.

One idea mentioned in the report on the IIW session for bringing
relying parties to the table is to target 100 “top relying parties” in
the hope of creating a snowball effect. But it’s not clear what it
would mean for those 100 relying parties and any additional ones
caught in the snowball, to “come to the table”. What would they do at
the table? What technology would they use? OpenID? OAuth? Smart
cards? Information cards? Anonymous credentials? NSTIC has not
proposed any specific technology. Or would they come to the table
just to talk?

There are many millions of Web sites that use passwords for user
authentication. The goal should be to get all those sites to adopt an
identity solution that eliminates the security risk of passwords. Web
site developers will do that of their own initiative once a solution
is available that is more secure and as easy to deploy as password
authentication.

While the technology is not there, various technology ingredients are
there, and missing ingredients could be developed. It is not
difficult to conceive a roadmap that could lead to one or more good
identity solutions. But success would require a concerted effort by
many different parties: not only relying parties and identity and
attribute providers, but also standards bodies, browser vendors,
vendors of desktop and mobile operating systems, vendors of smart
cards and other hardware tokens, perhaps biometric vendors, and the
providers of the middleware, software libraries, and software
development tools used on the Web. When I first heard of NSTIC I
hoped that it would provide the impetus and the forum needed for such
a concerted effort. But that has yet to happen.
May 27, 2012

Credential Sharing: A Pitfall of Anonymous Credentials

There is an inherent problem with anonymous credentials such as those
provided by Idemix or U-Prove: if it is not possible to tell who is
presenting a credential, the legitimate owner of a credential may be
willing to lend it to somebody else who is not entitled to it. For
example, somebody could sell a proof-of-drinking-age credential to a
minor, as noted by Jaap-Henk Hoepman in a recent blog
post [1].

This problem is known in cryptography as the credential sharing or
credential transferability problem, and various countermeasures have
been proposed. In this post I will briefly discuss some of these
countermeasures, then I will describe a new method of sharing
credentials that is resistant to most of them.

A traditional countermeasure proposed by cryptographers, mentioned for
example in [2], is to deter the sharing of an
anonymous credential by linking it to one or more additional
credentials that the user would not want to share, such as a
credential that gives access to a bank account, in such a way that the
sharing of the anonymous credential would imply the sharing of the
additional credential(s). I shall refer to this countermeasure as
the “credential linking countermeasure”. I find this countermeasure
unrealistic, because few people would escrow their bank account for
the privilege of using an anonymous credential.

In her presentation [3] at the recent NIST
Meeting on Privacy-Enhancing Cryptography [4],
Anna Lysyanskaya said that it is a misconception to think that “if all
transactions are private, you can’t detect and prevent identity
fraud”. But the countermeasure that she proposes for preventing
identity fraud is to limit how many times a credential is used and to
disclose the user’s identity if the limit is exceeded. However this
can only be done in cases where a credential only allows the
legitimate user to access a resource a limited number of times, and I
can think of few such cases in the realm of Web authentication.
Lysyanskaya gives as an example a subscription to an online newspaper,
but such subscriptions typically provide unlimited access for a
monthly fee. I shall refer to this countermeasure as the “limited use
countermeasure”.

Lysyanskaya’s presentation also mentions identity escrow as useful for
conducting an investigation if “something goes very, very wrong”.

At the panel on Privacy in the Identification Domain at the
same meeting Lysyanskaya also proposed binding an anonymous credential
to a biometric. The relying party would check the biometric and then
forget it to keep the presentation anonymous. But if the relying
party can be trusted to forget the biometric, it may as well be
trusted to forget the entire credential presentation, in which case an
anonymous credential is not necessary.

An interesting approach to binding a biometric to a credential while
keeping the user anonymous can be found in [5]. The
biometric is checked by a tamper-proof smartcard trusted by the
relying party, but a so-called warden trusted by the user is
placed between the smartcard and the relying party, and mediates the
presentation protocol to ensure that no information that could be used
to identify or track the user is communicated by the smart card to the
relying party.

However, if what we are looking for is an authentication solution that
will replace passwords on the Web at large, biometric-based
countermeasures are not good candidates because of their cost.

Update.
In a response to this post on the
Identity Commons mailing list Terry Boult has pointed out that cameras and microphones are pretty ubiquitous and said that, in volume, fingerprint sensors are cheaper than smartcard readers.

In his blog post [1], Hoepman suggested that, to
prevent the sharing of an anonymous credential, the credential could
be stored in the owner’s identity card, presumably referring to the
national identity card that citizens carry in the Netherlands and
other European countries. This is a good idea because lending the
card would put the owner at risk of impersonation by the borrower. I
shall refer to this as the “identity card countermeasure”.

Rather than storing a proof of age credential as an additional
credential in a national identity card, anonymous proof of age could
be accomplished by proving in zero knowledge that a birthdate
attribute of a national identity credential (or, in the United
States, of a driver’s license credential) lies in an open interval
ending 21 years before the present time; Idemix implements such
proofs. The identity credential could be stored in a smartcard or
perhaps in a tamper-proof module within a smart phone or a personal
computer. I’ll refer to this countermeasure as the “selective
disclosure countermeasure”. As in the simpler identity card
countermeasure, the legitimate user of the credential would be
deterred from sharing the credential with another person because of
the risk of impersonation.

But this countermeasure, like most of the above ones, does not help
with the following method of sharing credentials.

A Countermeasure-Resistant Method of Sharing Credentials

An owner of a credential can make the credential available for use by
another person without giving a copy of the credential to that
other person. Instead, the owner can allow that other person to act
as a proxy, or man-in-the-middle, between the owner and a relying
party in a credential presentation. (Note that this is not a
man-in-the-middle attack because the man in the middle cooperates with
the owner.)

For example, somebody of drinking age could install his or her
national identity credential or driver’s license credential on a Web
server, either by copying the credential to the server or, if the
credential is contained in a tamper-proof device, by connecting the
device to the server. The credential owner could then allow minors to
buy liquor by proxying a proof of drinking age based on the birthdate
attribute in the credential. (Minors would need a special user agent
to do the proxying, but the owner could make such user agent available
for download from the same server where the credential is installed.)
The owner could find a surreptitious way of charging a fee for the
service.

This method of sharing a credential, which could be called
proxy-based sharing, defeats most of the countermeasures
mentioned above. Biometric-based countermeasures don’t work because
the owner of the credential can input the biometric. Credential
linking countermeasures don’t work because the secret of the
credential is not shared. The identity card countermeasure and the
selective disclosure countermeasure don’t work because the owner is in
control of what proofs are proxied and can refuse to proxy proofs that
could allow impersonation. The limited use countermeasure could work
but, as I said above, I can think of few Web authentication cases
where it would be applicable.

Are there any other countermeasures that would prevent or inhibit this
kind of sharing? If a minor were trying to buy liquor using an
identity credential and a payment credential, the merchant could
require the minor to prove in zero-knowledge that the secret keys
underlying both credentials are the same. That would defeat the
sharing scheme by making the owner of the identity credential for pay
for the purchase. However there are proof-of-age cases that do not
require a purchase. For example, an adult site may be required to ask
for proof of age without or before asking for payment.

The only generally applicable countermeasure that I can think of to
defeat proxy-based sharing is the identity escrow scheme that
Lysyanskaya referred to in her talk [3]. Using
provable encryption, as available in Idemix, a liquor merchant could
ask the user agent to provide the identity of the owner of the
credential as an encrypted attribute that could be decrypted, say, by
a judge. (The encrypted attribute would be randomized for
unlinkability.) The user agent would include the encrypted attribute
in the presentation proof after asking the user for permission to do
so.

Unfortunately this requires the user to trust the government. This
may not be a problem for most people in many countries. But it
undermines one of the motivations for using privacy-enhancing
technologies that I discussed in a previous blog [6].

References

[1]	Jaap-Henk Hoepman. On using identity cards to store anonymous credentials. November 16, 2011. Blog post, at http://blog.xot.nl/2011/11/16/on-using-identity-cards-to-store-anonymous-credentials/.
[2]	Jan Camenisch and Anna Lysyanskaya. An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation. In Proceedings of the International Conference on the Theory and Application of Cryptographic Techniques: Advances in Cryptology (EUROCRYPT 01). 2001. Research report available from http://www.zurich.ibm.com/security/privacy/.
[3]	Anna Lysyanskaya. Conditional And Revocable Anonymity. Presentation at the NIST Meeting on Privacy-Enhancing Cryptography. December 8-9, 2011. Slides available at http://csrc.nist.gov/groups/ST/PEC2011/presentations2011/lysyanskaya.pdf.
[4]	NIST Meeting on Privacy-Enhancing Cryptography. December 8-9, 2011. At NIST Meeting on Privacy-Enhancing Cryptography.
[5]	Russell Impagliazzo and Sara Miner More. Anonymous Credentials with Biometrically-Enforced Non-Transferability. In Proceedings of the 2003 ACM workshop on Privacy in the electronic society (WPES 03).
[6]	Francisco Corella. Are Privacy-Enhancing Technologies Really Needed for NSTIC? October 13, 2011. Blog post, at http://pomcor.com/2011/10/13/are-privacy-enhancing-technologies-really-needed-for-nstic/.

December 19, 2011

Tag: Cryptography

References

A Framework for Designing Cryptographic Key Management Systems

A Look at the Future

Derived Credentials

Wrap-up

References

A Countermeasure-Resistant Method of Sharing Credentials

References