I’m happy to report that we have found a way of bypassing the Firefox POST redirection bug discussed in the previous post, obviating the need for code changes to cope with the redirection replay by Firefox when the user clicks the back button. While waiting for the bug to be fixed, this will simplify the implementation of web apps that rely on POST redirection, including apps that use cryptographic authencation or federated login. We have revised again the sample web app demoed at the last IIW, this time to simplify it by taking advantage of the bug bypass.Continue reading “A Bypass of the Firefox POST Redirection Bug”
Updated as shown below.
At the last Internet Identity Workshop (IIW) we gave a demo of a sample web app that featured cryptographic authentication, and argued that implementing cryptographic authentication is easy. Later, in the blog post Easy, Password-Free, Cryptographic Authentication for Web Applications I discussed the code of the sample web app and said that cryptographic authentication provides a “simple alternative” to authentication with a password. The issues discussed in the post, however, were not simple! Since then we have had to revise the code of the demo several times to fix bugs and, in the process, we have come to realize that cryptographic authentication is not that easy after all. It does not take much code, but it requires a lot of attention to detail to avoid a variety of pitfalls.Continue reading “Cryptographic Authentication Is Not That Easy After All”
The demo code mentioned below has been updated to
If you find any additional bugs please report them
or by posting to the
PJCL forum. (The PJCL user forum has been discontinued as of May 27, 2018.)
The date of the latest update will be shown in the
Please see also the blog post
Authentication Is Not That Easy After All.
For years there has been consensus that passwords have to go. To the many reasons for not using password authentication, the European GDPR will add, when it goes into effect on May 25, stringent requirements to notify users and regulators when passwords are compromised, backed by substantial fines. And yet, passwords are still the dominant authentication technology for web applications. This is because the alternatives that have been proposed and tried so far are complicated and expensive to implement. But there is a simple alternative that you can implement yourself, if you are a web application developer: cryptographic authentication with a digital-signature key pair stored in the browser.
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.
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.
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.
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.
In comments on the previous post at the Identity Commons mailing list and comments at the session on deployment and usability of cryptographic credentials at the Internet Identity Workshop, people have questioned the advantages of running cryptographic protocols for issuing and presenting credentials inside TLS, and argued in favor of running them instead over HTTP. I believe running such protocols inside TLS removes several obstacles that have hindered the deployment of cryptographic credentials. So in this post I will try to answer those comments.
Here are three advantages of running issuance and presentation protocols inside TLS over running them outside TLS:
- TLS is ubiquitous. It is implemented by all browsers and all server middleware. If issuance and presentation protocols were implemented inside TLS, then users could use cryptographic credentials without having to install any applications or browser plugins, and developers of RPs and IdPs would not have to install and learn additional SDKs.
- The PRF facility of TLS is very useful for implementing cryptographic protocols. For example, in the U-Prove presentation protocol , when U-Prove is used for user authentication, the verifier must send a nonce to the prover; if the protocol were run inside TLS, that step could be avoided because the nonce could be independently generated by the prover and the verifier using the PRF. The PRF can also be used to provide common pseudo-random material for protocols based on the common reference string (CRS) model . (Older cryptosystems such as U-Prove  and Idemix  rely on the Fiat-Shamir heuristic  to eliminate interactions, but more recent cryptosystems based on Groth-Sahai proofs  rely instead on the CRS model, which is more secure in some sense .)
- Inside TLS, an interactive cryptographic protocol can be run in a separate TLS layer, allowing the underlying TLS record layer to interleave protocol messages with application data (and possibly with messages of other protocol runs), thus mitigating the latency impact of protocol interactions.
And here are two advantages of running protocols either inside or directly on top of TLS, over running them on top of HTTP:
- Simplicity. Running a protocol over HTTP would require specifying how protocol messages are encapsulated inside HTTP requests and responses, i.e. it would require defining an HTTP-level protocol.
- Performance. Running a protocol over HTTP would add the overhead of sending HTTP headers, and, possibly, of establishing different TLS connections for different HTTP messages if TLS connections cannot be kept alive for some reason.
As always, comments are welcome.
Christian Paquin. U-Prove Cryptographic Specification V1.1 Draft
Revision 1, February 2011.
M. Blum, P. Feldman and S. Micali. Non-Interactive Zero-Knowledge
and Its Applications (Extended Abstract). In Proceedings of the
Twentieth Annual ACM Symposium on Theory of Computing (STOC 1988).
Jan Camenisch et al. Specification of the Identity Mixer
Cryptographic Library, Version 2.3.1. December 2010. Available at
A. Fiat and A. Shamir. How to Prove Yourself: Practical Solutions
to Identification and Signature Problems. In Proceedings on Advances
in Cryptology (CRYPTO 86), Springer-Verlag.
J. Groth and A. Sahai. Efficient Non-Interactive Proof Systems
for Bilinear Groups. In Theory and Applications of Cryptographic
Techniques (EUROCRYPT 08), Springer-Verlag.
R. Canetti, O. Goldreich and S. Halevi. The Random Oracle
Methodology, Revisited. Journal of the ACM, vol. 51, no. 4, 2004.
This is the fourth and last of a series of posts on the prospects for using privacy-enhancing technologies in the NSTIC Identity Ecosystem.
Experience has shown that it is difficult to deploy cryptographic credentials on the Web and have them adopted by users, relying parties and credential issuers. This is true for privacy-friendly credentials as well as for ordinary public-key certificates, both of which have a place in the NSTIC Identity Ecosystem, as I argued in the previous post.
I believe that this difficulty can be overcome by putting the browser in charge of managing and presenting credentials, by supporting cryptographic credentials in the core Web protocols, viz. HTTP and TLS, and by providing a simple and automated process for issuing credentials.
Browsers should manage and present credentials
For credentials to be widely adopted, users must not be required to install additional software, let alone proprietary software that only runs on one operating system, such as Windows Cardspace. Therefore credentials must be managed and presented by the browser.
The browser should allow users to set up multiple personas or profiles and associate particular credentials with particular personas. Many users, for example, have a personal email address and a business email address, which could be associated with a personal profile and a business profile respectively. The user could declare one profile to be the “currently active persona” in a particular browser window or tab, and thus facilitate the selection of appropriate credentials when visiting sites in that window or tab.
People who use multiple browsers in multiple computing devices (including desktop or laptop computers, smart phones and tablets) must have access to the same credentials on all those devices. Credentials can be synced between browsers through a Web service without having to trust the service by equipping each browser with a key pair for encryption and a key pair for signature (in the same way as email can be sent with end-to-end confidentiality and origin authentication using S/MIME or PGP). Credentials can be backed up to an untrusted Web service similarly.
Cryptographic credentials should be supported by HTTP and TLS
HTTP should provide a way for the relying party to ask for particular credentials or attributes, and TLS should provide a way for the browser to present one or multiple credentials. Within TLS, the mechanism for presenting credentials should be separate from and subsequent to, the handshake, to benefit from the confidentiality and integrity offered by the TLS connection after it has been secured.
Credentials should be issued automatically to the browser, through TLS
Privacy-friendly credentials have cryptographically complex interactive issuance protocols. Paradoxically, this suggests a way of simplifying the issuance process, for both PKI certificates and privacy-friendly credentials.
Since the process is interactive, it should be run directly on a transport layer connection, to avoid HTTP and application overhead. That connection should be secure to protect the confidentiality of the attributes being certified. To reduce the latency due to the cryptographic computations, the protocol interactions should be interleaved with the transmission of other data. And the cryptographic similarity of issuance and presentation protocols suggests that they should be run over the same kind of connection.
All this leads to the idea of running issuance protocols, like presentation protocols, directly over a TLS connection. TLS has a record layer specification that could be extended to define two new kinds of records, one for issuance protocol messages, the other for presentation protocol messages. TLS would then automatically interleave protocol interactions with transmission of other data. (Another benefit of TLS is that its PRF facility could be readily used to generate the common reference string used by some cryptographic protocols.)
Since TLS is universally supported by server middleware, implementing issuance protocols directly over TLS would make allow servers to issue credentials automatically without installing additional software. In particular, it would make it easy for any Web site to issue a PKI certificate as a result of the user registration process, for use in subsequent logins.
Once credentials are handled by browsers and directly supported by the core protocols of the Web, smooth and painless user experiences become possible.
For example, a user can open a bank account online as follows. The user accepts terms and conditions and clicks on an account creation button button. The bank asks the browser for a social security credential and a driver’s license credential. The browser presents the credentials to the bank after asking the user for permission. The bank checks the user’s credit ratings and automatically creates an account and issues a PKI certificate binding the account number to the public key component of a new key pair generated by the browser on the fly. On a return visit, the user clicks on a login button and the bank asks the browser for the certificate. The user may allow the browser to present the certificate without asking for permission each time. Double factor authentication can be achieved, for example, by keeping the private key and certificate in a password-proctected smart card.
As a second example, suppose a user visits a site to sign up for receiving coupons by email. The user accepts terms and conditions and clicks on a sign-up button. The site asks the browser for a verified email-address certificate (issued by an email service provider) and a number of self-asserted attributes, such as zip code, gender, age group, and set of shopping preferences. The browser finds in its certificate store (or in a connected smart card) an email address certificate and a personal-data credential associated with the currently active persona. The personal-data credential is a privacy-friendly credential featuring unlinkability and selective disclosure. The browser presents simultaneously the email certificate and the personal-data credential, disclosing only the personal-data attributes requested by the site. The browser may or may not ask the user for permission to present the credentials, depending on user preferences that may be persona-dependent.
In this series of posts I have argued that new privacy-enhancing technologies should be developed to fill the gaps in currently implemented systems and to take advantage of new techniques developed by cryptographers over the last 10 or 15 years. I have also argued that the NSTIC Identity Ecosystem should accomodate both privacy-friendly credentials and ordinary PKI certificates, because different use cases call for different kinds of credentials. Finally I have sketched above two examples of user experiences that can be provided if credentials are handled by browsers and directly supported by the core protocols of the Web.
Of course this requires major changes to the Web infrastructure, including: extensions to HTTP; a revamp of TLS to allow for the presentation of privacy-friendly credentials, the simultaneous presentation of multiple credentials, and the issuance of credentials; support of the protocol changes in browsers and server middleware; and implementation of browser facilities for managing credentials.
These changes may seem daunting. The private sector by itself could not carry them out, especially given the current reliance of technology companies on business models based on advertising, which benefit from reduced user privacy. But I hope NSTIC will make them possible.
This is the third of a series of posts on the prospects for using privacy-enhancing technologies in the NSTIC Identity Ecosystem.
In the first two posts we’ve looked at two, or rather three, privacy-enhancing authentication technologies: U-Prove, Idemix, and the Idemix Java card. The credentials provided by these technologies have some or all of the privacy features called for by NSTIC, but they have various practical drawbacks, the most serious of which is that they are not revocable by the credential issuer.
Given these drawbacks, it is natural to ask the question: are privacy-friendly credentials really necessary for NSTIC? My answer is: they are not needed in many important use cases, and they are useful but not indispensable in other important cases; but they are essential in cases that are key to the success of NSTIC.
Use Cases Where Privacy-Enhancing Technologies Are Not Needed
The most common use case of Web authentication is the case where a user registers anonymously with a Web site and later logs in as a returning user. Traditionally, the user registers a username and a password with the site and later uses them as credentials to log in. Today, third-party login is becoming popular as a way of mitigating the proliferation or reuse of passwords: the user logs in with username and password to a third-party identity provider, and is then redirected to the Web site, which plays the role of relying party. But there is a way of avoiding passwords altogether: the Web site can issue a cryptographic credential to the user upon registration, which the user can submit back to the Web site upon login. In that case there is no third party involvement and no privacy issues. The cryptographic credential can therefore be an ordinary PKI certificate. No privacy-enhancing technologies are needed.
Update. The PKI certificate binds the newly created user account to the public key component of a key pair that the browser generates on the fly.
Other cases where privacy-enhancing technologies are not needed are those where a credential demonstrates that the user possesses an attribute whose value uniquely identifies the user, and the relying party needs to know the value of that attribute. (One example of such an attribute is an email address.) Privacy-enhancing technologies are not useful in such cases because a uniquely-identifying attribute communicated to relying parties can be used to track the user no matter what type of credential is used to communicate the attribute.
Use Cases Where Privacy-Enhancing Technologies Are Useful but not Essential
Privacy-enhancing technologies are useful but not essential when the attributes certified by a credential do not uniquely identify the user, and the user has a choice of credential issuers. They are useful in such cases because they prevent the issuer from tracking the user’s activities by sharing data with the relying parties. They are not essential, however, because the user may be able to choose a credential issuer that she trusts. (Most privacy-enhancing technologies also prevent relying parties from collectively tracking the user by sharing their login information, without involvement of the credential issuer, but the risk of this happening may be more remote.)
Examples of non-identifying attributes are demographic attributes (city of residence, gender, age group), shopping interests, hobby interests, etc.; such attributes are usually self-asserted, but they can be supplied by an identity provider, chosen by the user, as a matter of convenience, so that the user does not have to reenter them and maintain them uptodate at each relying party. Examples of sites that may ask for such attributes are dating sites, shopping deal sites, hobbyist sites, etc.
Of course, a credential that contains non-identifying attributes will not by itself allow a user to log in to a site. But it can be used in addition to a PKI certificate issued by the site itself to recognize repeat visitors.
Use Cases Where Privacy-Enhancing Technologies Are Necessary
Privacy-enhancing technologies are necessary when the relying party does not require uniquely identifying information, and there is only one credential issuer. That one credential issuer could be the government. Non-uniquely-identifying information provided by government-issued credentials could include assertions that the user is old enough to buy wine, or is a resident of a particular state, or is licensed to practice some profession in some state, or is a US citizen, or has the right to work in the US.
I find it difficult to find examples where people would have a reasonable fear of being tracked through their use of government-issued credentials. But the right to privacy is a human right that is held dear in the United States, and has been found to be implicitly protected by the US constitution. Government-issued credentials will only be acceptable if they incorporate all available privacy protections. That makes the use of privacy-enhancing technologies essential to the success of NSTIC.
Wanted: Efficiently-Revocable Privacy-Friendly Credentials
So: privacy-friendly credentials are necessary; but, in my opinion, the drawbacks of existing privacy-enhancing technologies make them impractical. Therefore we need new privacy-enhancing technologies. Those new technologies should have issue-show and multi-show unlinkability; they should provide partial information disclosure, including proofs of inequality relations involving numeric attributes; and they should be efficiently revocable.
Fortunately, that’s not too much to ask. U-Prove and Idemix have been pioneering technologies, but they are now dated. U-Prove is based on research carried out in the mid-nineties, and the core cryptographic scheme later used in Idemix was described in a paper written in 2001. A lot of research has been done in cryptography since then, and several new cryptographic schemes have been proposed that could be used to provide privacy-friendly credentials.
I don’t think a scheme meeting all the requirements, including efficient revocation, has been designed yet. (I would love to be corrected if I’m wrong!) But possible ingredients for such a system have been proposed, including methods for proving non-revocation in time proportional to the square root of the number of revoked credentials  or even in practically constant time .
Update. Stefan Brands has told me that the cryptosystem described in  is considered part of the U-Prove technology, and that the revocation technique of  could be integrated into the existing U-Prove implementation to provide issuer-driven revocation. If that were done and the resulting system proved to be suitably efficient, the only ingredient missing from that system would be multi-show unlinkability.
Once a scheme with all the ingredients has been designed and mathematically verified, it still needs to be implemented. Cryptographic implementations are few and far between, but that does not mean that they are difficult. Recently, for example, three different systems of privacy-friendly credentials were implemented just for the purpose of comparing their performance .
Next and Last: Usability and Deployment
To conclude the series, in the next post I’ll try to respond to a comment made by Anthony Nadalin on the Identity Commons mailing list: “if it’s not useable or deployable who cares?”.
Stefan Brands, Liesje Demuynck and Bart De Decker.
A practical system for globally revoking the unlinkable pseudonyms of unknown users.
In Proceedings of the 12th Australasian Conference on Information Security and Privacy, ACISP’07.
Preconference technical report available at http://www.cs.kuleuven.be/publicaties/rapporten/cw/CW472.pdf.
T. Nakanishi, H. Fujii, Y. Hira and N. Funabiki.
Revocable Group Signature Schemes with Constant Costs for Signing and Verifying.
In IEICE Transactions,
J. Lapon, M. Kohlweiss, B. De Decker and V. Naessens.
Performance Analysis of Accumulator-Based Revocation Mechanisms.
In Proceedings of the 25th International Conference on Information Security (SEC 2010).