Privacy – Pomcor

Biometrics and Derived Credentials

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

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

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

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

Biometrics in PIV Cards

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

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

Biometric security

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

Surveillance and Internet Identity

Last week I attended IIW 17, the 17th meeting of the Internet Identity Workshop, which is held twice a year in Mountain View, California. As usual it was a great opportunity to exchange ideas and meet people, with its unconference format, its many sessions, its rotating demos, its wide space for discussions, and its two free dinners with free drinks.

For me, however, it was tinged with sadness, because of what has happened since the first IIW I attended, IIW 12, in May 2011. IIW 12 was the first IIW after the launch of NSTIC. IIW 17 was the first IIW after Snowden.

The NSTIC Strategy Document, released in April 2011 with a preface signed by President Obama, repeatedly emphasized the goal of enhancing privacy as a key element of the “vision” and “guiding principles” of NSTIC. The document explicitly stated that the Identity Ecosystem will use privacy-enhancing technology and policies to inhibit the ability of service providers to link an individual’s transactions, thus ensuring that no one service provider can gain a complete picture of an individual’s life in cyberspace. At the time, Facebook Connect was threatening to inject Facebook as a middleman in all or most Internet activities, and I was happy to see that the US Government seemingly wanted to prevent such a massive invasion of privacy; I even convened a session at IIW 12 proposing a technique for achieving the privacy goals of NSTIC in the short term. Little did I know that the government was busy building a massive surveillance apparatus that would give the government a complete picture of an individual’s life in cyberspace, by means including bulk collection of data from service providers.

The Internet, given to the world by the US Department of Defense, was a world-wide forum for free-flowing, spontaneous exchange of ideas. Now the NSA, part of the same Department of Defense, has taken that away. People know that they are being tracked and identified when they post an anonymous comment. People know that their conversations are being recorded. Therefore people must think twice about they say.

I don’t know if Congress will be able to rein in the NSA. It should be clear that spying on US citizens is unconstitutional, but some politicians think that it is the NSA’s job to spy on everybody else in the planet. They don’t seem to consider or care that, if the US Government insists on a God-given right to spy on everybody else, other countries or regions may develop their own national or regional networks, separated from the US Internet by an air gap.

Fortunately, the technical community has reacted strongly against the NSA’s attacks on Internet privacy. And thanks to Snowden’s revelations, many of the attack techniques are known. It may therefore be possible to protect Internet privacy by technical means.

Coming back to the subject of the workshop, Internet Identity, I would argue that the first thing to do to protect Internet privacy is to get rid of the pernicious technology variously known as third-party login, social login or federated login. To be precise, I am referring to authentication techniques where the user authenticates to a third-party identity provider, which then provides identity and/or attribute information to a relying party, using a protocol such as OAuth or OpenID Connect. (These are the techniques in Group 2 of the taxonomy proposed in the paper Privacy Postures of Authentication Technologies.)

The only intrinsic advantage of federated login is that it allows the identity provider to collect vast amounts of information about the user, since the identity provider learns not only the user’s identity and/or attributes, but also what relying parties the user logs in to. The identity provider uses the information to sell ads that target the user accurately. We now know that the information is also shared with the government, which makes it available to thousands of analysts and IT personnel who use it for legal or illegal government or personal purposes.

There are no other intrinsic advantages to federated login.

The government and the identity providers argue that federated login is more secure than direct authentication to the relying party with username and password, but the opposite is true.

Security is supposedly increased because federated login reduces password reuse. But password reuse will not be substantially reduced unless a large majority of world-wide web sites force their users to use federated login with one of a small number of global identity providers such as Google or Facebook, something that will hopefully not come to pass.

Security is also supposedly increased because a large identity provider supposedly does a better job of protecting the user’s password. But I don’t know why a large identity provider would provide better protection against hackers, since large companies are not known to provide great security. And I do know that a password entrusted to a large identity provider may become available to thousands of employees of the government, of government contractors, and of the identity provider.. And the capture of a password used at an identity provider, which provides access to multiple web sites, is more damaging to the user than the capture of a password used at a single web site.

There is an alternative to authenticating to a web site with username and password that provides both security and privacy: namely, authentication with a cryptographic key pair automatically generated on the user’s machine when the user registers with the site. The site stores the hash of the public key component of the key pair in its database, and uses it to locate the user’s account when the user visits the site again and demonstrates knowledge of the private key component.

Another claimed advantage of federated login is that the user can register at a new site with a single click if logged in to the identity provider, any personal data required by the site being provided by the identity provider. This is a real advantage, but not an intrinsic one. The same benefit could be easily obtained by storing the personal data in the browser, and specifying a protocol by which the browser would supply selected personal data items to a web site upon demand by the site and approval by the user. Such a protocol would be much simpler than any of the federated login protocols and would provide more security and more privacy.

Yet another claimed advantage of federated login is that the identity provider could provide the relying party with a user’s identity and/or attributes verified by an identity proofing procedure; however, such verified identity and/or attributes could equally well be provided by a certificate authority using a public key certificate (or by multiple authorities providing a combination of a certificate binding a public key to an identity and one or more certificates binding the identity to various attributes), without the certificate authority having to be informed of what relying parties the certificate is submitted to.

It is sometimes argued (cf. the NSTIC 101 session at last week’s IIW) that using public key cryptography for authentication would be expensive and would require the user to carry a separate dongle or smartcard for every credential. This is not true. There is no need for special hardware to store a cryptographic credential, and if special hardware is desired for some reason, there is no need to use different pieces of hardware for different credentials.

Two sessions at IIW 17 gave me hope that Internet privacy is not a lost cause.

One of them was convened by Tim Bray of Google to report on the comments he received in response to a blog post arguing to developers that they should use federated login rather than login with username and password. The comments, which he referred to as a “bloodbath,” showed that neither developers nor end-users like federated login. I hope that such pushback will eventually force companies like Google to give up on federated login.

The other one was convened by Kazue Sako of NEC to discuss anonymous credentials and their possible uses. The room was overflowing and the level of engagement of the audience was high, showing that technical people are interested in privacy-enhancing authentication technologies even if large companies are not.

Feedback on the Paper on Privacy Postures of Authentication Technologies

Many thanks to every one who provided feedback on the paper on privacy postures of authentication technologies which was announced in the previous blog post. The paper was discussed on the Identity Commons mailing list and we also received feedback at the ID360 conference, where we presented the paper, and at IIW 16, where we showed a poster summarizing the paper. In this post I will recap the feedback that we have received and the revisions that we have made to the paper based on that feedback.

Steven Carmody pointed out that SWITCH, the Swiss InCommon federation, has developed an extension of Shibboleth called uApprove that allows the identity or attribute provider to ask the user for consent before disclosing attributes to the relying party. Ken Klingestein told us that the Scalable Privacy NSTIC pilot is developing a privacy manager that will let the user choose what attributes will be disclosed to the the relying party by the Shibboleth identity provider. We have added references to these Shibboleth extensions to Section 4.2 of the paper.

The original paper explained that, although a U-Prove token does not provide multishow unlinkability, the user may obtain multiple tokens from the issuer, and present different tokens to different relying parties. Christian Paquin said that a U-Prove credential is defined as a batch of such tokens, created simultaneously by an efficient parallel procedure. We have added this definition of a U-Prove credential to Section 4.3.

Christian Paquin also pointed out that a U-Prove token is a mathematical concept that can be embodied in a variety of technologies. He sent me a link to the WS-Trust embodiment, which was used in CardSpace. We have explained this and included the link in Section 4.3.

Tom Jones said that what we call anonymity is called pseudonymity by others. In fact, column 9, labeled “Anonymity”, covers both pseudonymity, as provided, e.g., by an Idemix pseudonym or an uncertified key pair or a combination of a user ID and a password when the user ID is freely chosen by the user, and full anonymity, as provided when a relying party learns only attributes that do not uniquely identify the user. I think it is not unreasonable to view anonymity (the service provider does not learn the user’s “name”) as encompassing pseudonymity (the service provider learns a pseudonym instead of the “real name”).

Nat Sakimura provided a lot of feedback, for which we are grateful. He said that Google and Yahoo implemented OpenID Pairwise Pseudonymous Identifiers (PPID), i.e. different identifiers for the same user provided to different relying parties, before ICAM specified its OpenID profile. We have noted this in Section 4.2 of the revised paper and changed the label of row 8 to “OpenID (without PPID)”.

He also said that OpenID Connect supports an ephemeral identifier, which provides anonymity. I was able to find a discussion of an ephemeral identifier in the archives of the OpenID Connect mailing list, but no mention of it in any of the OpenID Connect specifications; so ephemeral identifiers may be added in the future, but they are not there yet.

Nat also argued that OpenID Connect provides multishow unlinkability by different parties and by the same party. I disagree, however. The Subject Identifier in the ID Token makes OpenID Connect authentication events linkable. Furthermore, OpenID is built on top of OAuth, whose purpose is to provide the relying party with access to resources owned by the user by means of an access token. In a typical use case the relying party gets access to the user’s account at a social network such as Facebook, Twitter or Google+. It is unlikely that two relying parties who share information cannot determine that they are both accessing the same account, or that a relying party cannot determine that it has accessed the same account in two different occasions.

Nat said that OpenID Connect can be used for two-party authentication using a “Self-Issued OpenID Provider”. We have added a checkmark to row 11, column 1 of the table to indicate this, and an explanation to Section 4.2.

He also said that OpenID Connect provides group 4 functionality by allowing the relying party to obtain attributes from “distributed attribute providers”. We have mentioned this in Section 4.4 of the revised version of the paper.

Finally, Nat said:

Just by reading the paper, I was not very clear what is the requirement for Issue-show unlinkability. By issuance, I imagine it means the credential issuance. I suppose then it means that the credential verifier (in ISO 29115 | ITU-T X.1254 sense) cannot tell which credential was used though it can attest that the user has a valid credential. Is that correct? If so, much of the technology in group 2 should have n/a in the column because they are independent of the actual authentication itself. They could very well use anonymous authentication or partially anonymous authentication (ISO 29191).

The technologies in group 2 are recursive authentication technologies. The relying party directs the browser to the identity or attribute provider, which recursively authenticates the user and provides a bearer credential to the relying party based on the result of the inner authentication. In all generality there may be multiple inner authentications, as the identity or attribute provider may require multiple credentials. So the authentication process may consist of a tree of nested authentications, with internal nodes of the tree involving group 2 technologies, and leaf nodes other technologies. However, rows 5-11 (group 2) are only concerned with the usual case where the user authenticates to the identity or attribute provider as a returning user with a user ID and a password or some other form of two-party authentication; we have now made that clear in Section 4.2 of the revised paper. In that case there is no issue-show unlinkability.

We have also made a couple of other improvements to the paper, motivated in part by the feedback:

We have replaced the word possession with the word ownership in the definition of closed-loop authentication (Section 2), so that it now reads: authentication is closed-loop when the credential authority that issues or registers a credential is later responsible for verifying ownership of the credential at authentication time. The motivation for this change is that, in group 2, the credential is the information that the identity or attribute provider has about the user, and is thus kept by the identity or attribute provider rather than by the user.
We have added a distinction between two forms of multishow unlinkability, a strong form that holds even if the credential authority colludes and shares information with the relying parties, and a weak form that holds only if there is no such collusion. The technologies in group 2 that provide multishow unlinkability provide the weak form, whereas Idemix anonymous credentials provide the strong form.

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.

OpenID Providers Invited to Join in an NSTIC Pilot Proposal

NSTIC has announced funding for pilot projects. Preliminary proposals are due by March 7 and full proposals by April 23. There will be a proposer’s conference on February 15, which will be webcast live.

We are planning to submit a proposal and are inviting OpenID identity providers to join us. The proposed pilot will demonstrate a completely password-free method of user authentication where the relying party is an ordinary OpenID relying party. The identity provider will issue a public key certificate to the user, and later use it to authenticate the user upon redirection from the relying party. The relying party will not see the certificate. Since the certificate will be verified by the same party that issued it, there will be no need for certificate revocation lists. Certificate issuance will be automatic, using an extension of the HTML5 keygen mechanism that Pomcor will implement on an extension of the open source Firefox browser.

There will be two privacy features:

The identity provider will supply different identifiers to different relying parties, as in the ICAM OpenID 2.0 Profile.
Before authenticating the user, the identity provider will inform the user of the value of the DNT (Do Not Track) header sent by the browser, and will not track the user if the value of the header is 1.

The identity provider will:

Implement a facility for issuing certificates to users, taking advantage of the keygen element of HTML5. The identity provider will obtain a public key from keygen, create a certificate that binds the public key to the user’s local identity, and download the certificate in an ad-hoc HTTP header. Pomcor will supply a Firefox extension that will import the certificate automatically.
Use the certificate to authenticate the user upon redirection from the relying party. The browser will submit the certificate as a TLS client certificate. The mod_ssl module of Apache supports the use of a client certificate and makes data from the certificate available to high-level server-side programming environments such as PHP via environment variables.

For additional information you may write to us using the contact page of this site.

After CardSpace, Microsoft Calls for Research on Passwords

In February 2011 Microsoft discontinued CardSpace, a Windows application for federated login that was the deployment vehicle for the U-Prove privacy-enhancing Web authentication technology, which itself is said to have inspired the NSTIC initiative. Cormac Herley, a Microsoft researcher, and Paul van Oorshot, a professor at Carleton University, have written a paper entitled A Research Agenda Acknowledging the Persistence of Passwords that mentions the CardSpace failure and calls for research on traditional password authentication.

The paper makes two points:

It blames the failure of attempts at replacing passwords on a lack of research on identifying and prioritizing the requirements to be met by alternative authentication methods.
It argues that passwords have many virtues, will persist for some time, and may be the best fit in many scenarios; and it calls for research on how to better support them.

I disagree with the first point but agree with the second.

The problem with the first point is that it does not take into account the non-technical obstacles faced by alternative authentication methods. Microsoft Passport was the first attempt at Web single sign-on. It was launched when Microsoft was in the process of annihilating the Netscape browser and acquiring a monopoly in Web browsing; it originally had an outrageous privacy policy, which was later modified; and if successful it would have made Microsoft a middleman for all Web commerce. No wonder it failed.

Other single sign-on initiatives had obvious non-technical obstacles. OpenID required people to use a URL as their identity, something that could only appeal to the tiny fraction of users who understand or care about the technical underpinnings of the Web. CardSpace was a Microsoft product; that by itself must have provided motivation for all Microsoft competitors to oppose it; furthermore it only ran on Windows; and in order to support CardSpace relying party developers had to install and learn to use a complex toolkit. Again, no wonder CardSpace failed.

The non-technical obstacles faced by Passport, OpenID and CardSpace were due to lack of maturity of the Web industry. Such obstacles will slowly go away as the industry matures. Signs of maturity are appearing: there are now five major browsers that seem to understand the need for common standards; the World Wide Web consortium (W3C) has shown that it can bring them together to develop standards such as HTML5 and has already engaged them in identity work through the Identity in the Browser workshop and the identity mailing list that was set up after the workshop; and OpenID 2.0 no longer insists on users using URLs as their identities. Industries can take decades to mature, so it’s not surprising that progress is slow.

As for passwords, I agree that they have virtues, will persist, and deserve research. There is actually research on passwords going on.

Password managers are an active area of research and development by browser providers and others.

There was a session on passwords at the last Internet Identity Workshop (IIW), called by Jay Unger, where Alan Karp described his site password tool, which can be viewed as an alternative to a password manager, where passwords for different sites are computed rather than retrieved from storage. The tool computes a high entropy password for a Web site from a master password and an easy-to-remember name for the site.

I have myself been recently granted two patents on password security, which were also discussed at the IIW session on passwords:

One of them describes a countermeasure against online password guessing that places a hard limit on the total number of guesses that an attacker can make against a password. Besides the traditional counter of consecutive bad guesses the countermeasure uses an additional counter of total bad guesses, not necessarily consecutive. The user is asked to change her password if and when this second counter reaches a threshold, rather than at arbitrary intervals.
The other describes a technique for password distribution, that allows an administrator to send a temporary password to a user, e.g. after a password reset, over an unprotected channel such as ordinary email. The administrator puts a hold on the user’s account that allows no further access beyond changing the temporary password into a password chosen by the user. The administrator removes the hold only after being notified by the legitimate user that she has successfully changed the password, e.g. over the phone. In abstract terms, instead of relying on a confidential channel to send the password, the administrator relies on a channel with data-origin authentication to receive the user’s notification.

Microsoft or anybody else who wants to increase password security can license either of these patents. You may use the contact form of this site to inquire about licensing.

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/.

Trip Report: Meeting on Privacy-Enhancing Cryptography at NIST

Last week I participated in the Meeting on Privacy-Enhancing Cryptography at NIST. The meeting was organized by Rene Peralta, who brought together a diverse international group of cryptographers and privacy stakeholders. The agenda is online with links to the workshop presentations.

The presentations covered many applications of privacy-enhancing cryptography, including auctions with encrypted bids, database search and data stream filtering with hidden queries, smart metering, encryption-based access control to medical records, format-preserving encryption of credit card data, and of course authentication. There was a talk on U-Prove by Christian Paquin, and a talk on Idemix by Gregory Neven. There were also talks on several techniques besides anonymous credentials that could be used to implement privacy-friendly authentication: group signatures, direct anonymous attestation, and EPID (Enhanced Privacy ID). Kazue Sako’s talk described several possible applications of group signatures, including a method of paying anonymously with a credit card.

A striking demonstration of the practical benefits of privacy-enhancing cryptography was the presentation on the Danish auctions of sugar beets contracts by Thomas Toft. A contract gives a farmer the right to grow a certain quantity of beets for delivery to Danisco, the only Danish sugar producer. A yearly auction allows farmers to sell and buy contracts. Each farmer submits a binding bid, consisting of a supply curve or a demand curve. The curves are aggregated into a market supply curve and a market demand curve, whose intersection determines the market clearing price at which transactions take place. What’s remarkable is that farmers submit encrypted bids, and bids are never decrypted. The market clearing price is obtained by computations on encrypted data, using secure multiparty computation techniques. Auctions have been successfully held every year since 2008.

I was asked to participate in the panel on Privacy in the Identification Domain and to start the discussion by presenting a few slides summarizing my series of blog posts on privacy-enhancing technologies and NSTIC. In response to my slides, Gregory Neven of IBM reported that a credential presentation takes less than one second on his laptop, and Brian La Macchia of Microsoft pointed out that deployment is difficult for public key certificates as well as for privacy-friendly credentials. There were discussions with Gregory Neven on revocation and with Anna Lysyanskaya on how to avoid the sharing of anonymous credentials; these are big topics that deserve their own blog posts, which I plan to write soon, so I won’t say any more here. Jeremy Grant brought the audience up to date about NSTIC, which has received funding and is getting ready to launch pilots. Then there was a wide ranging discussion.

Do-Not-Track and Third-Party Login

Recently the World Wide Web Consortium (W3C) launched a Tracking Protection Working Group, following several recent proposals for Do-Not-Track mechanisms, and more specifically in response to a W3C-member submission by Microsoft. A useful list of links to proposals and discussions related to Do-Not-Track can be found in the working group’s home page.

The Microsoft submission was concerned with tracking by third-party content embedded in a Web page via cookies and other means of providing information to the third party. It proposed a Do-Not-Track setting in the browser, to be sent to Web sites in an HTTP header and made available to Javascript code as a DOM property. It also proposed a mechanism allowing the user to specify a white list of third party content that the browser would allow in a Web page and/or a black list of third party content that the browser would block. The browser would filter the requests made by a Web page for downloading third-party content, allowing some and rejecting others.

(The specific filtering mechanism proposed by Microsoft would allow third-party content that is neither in the white list nor in the black list. This would be ineffective, since the third party could periodically change the domain name it uses to avoid being blacklisted. I trust that the W3C working group will come up with a more effective filtering mechanism.)

A Do-Not-Track setting and a filtering mechanism are good ideas, but they only deal with the traditional way of tracking a user. Today there is another way of tracking a user, which can be used whenever the user logs in to a Web site with authentication provided by a third party, such as Facebook, Google or Yahoo.

Third-party login uses a double-redirection protocol. When the user wants to log in to a Web site, the user’s browser is redirected to a third party, which plays the role of “identity provider.” The identity provider authenticates the user and redirect the browser back to the Web site, which plays the role of “relying party.” The identity provider is told who each relying party is, and can therefore can track the user without any need for cookies. The identity provider can link the user’s logins to relying parties to the information in the user’s account at the identity provider, which in the case of Facebook includes the user’s real name and much other real identity information.

Privacy-enhancing technologies, which I discussed in a recent series of blog posts (starting with the one on U-Prove), may eventually make it possible to log in with a third party credential without the identity provider being able to track the user; but in the meantime, means must be found of providing protection against tracking via third-party login. The W3C Tracking Protection working group could provide such protection by broadening the scope of the Do-Not-Track setting so that it would apply to both the traditional method of tracking via embedded content and the new method of tracking via third-party login. An identity provider who receives a Do-Not-Track header while participating in a double-redirection protocol would be required to forget the transaction after authenticating the user.

The scope of the filtering mechanism could also be broadened so that it would apply to redirection requests in addition to third-party content embedding. This could mitigate a security weakness that affects third-party login protocols such as OpenID and OAuth. Such protocols are highly vulnerable to a phishing attack that captures the user’s password for an identity provider: the attacker sets up a malicious relying party that redirects the browser to a site masquerading as the identity provider. A filtering mechanism that would block redirection by default could prevent the attack based on the fact that the site masquerading as the identity provider would not be whitelisted (while the legitimate identity provider would be).