With Brands digital credentials (or Chaums credentials) another approach is to make the endorsement key pair and certificate the anonymous credential. That way you can use the endorsement key and certificate directly rather than having to obtain (blinded) identity certificates from a privacy CA and trust the privacy CA not to issue identity certificates without seeing a corresponding endorsement credential. However the idea with the identity certificates is that you can use them once only and keep fetching new ones to get unlinkable anonymity, or you can re-use them a bit to get pseudonymity where you might use a different psuedonym for a different service where you are anyway otherwise linkable to a given service. With Brands credentials the smart card setting allows you to have more compact and computationally cheap control of the credential from within a smart card which you could apply to the TPM/SCP. So you can fit more (unnamed) pseudonym credentials on the TPM to start with. You could perhaps more simply rely on Brands credential lending discouraging feature (ability to encode arbitrary values in the credential private key) to prevent break once virtualize anywhere. For discarding pseudonyms and when you want to use lots of pseudonyms (one-use unlinkable) you need to refresh the certificates you could use the refresh protocol which allows you to exchange a credential for a new one without trusting the privacy CA for your privacy. Unfortunately I think you again are forced to trust the privacy CA not to create fresh virtualized credentials. Perhaps there would be someway to have the privacy CA be a different CA to the endorsement CA and for the privacy CA to only be able to refresh existing credentials issued by the endorsement CA, but not to create fresh ones. Or perhaps some restriction could be placed on what the privacy CA could do of the form if the privacy CA issued new certificates it would reveal it's private key. "Also relevant is An Efficient System for Non-transferable Anonymous Credentials with Optional Anonymity Revocation", Jan Camenisch and Anna Lysyanskaya, Eurocrypt 01 http://eprint.iacr.org/2001/019/ These credentials allow the user to do unlinkable multi-show without involving a CA. They are somewhat less efficient than Chaum or Brands credentials though. But for this application does this removes the need to trusting a CA, or even have a CA: the endorsement key and credential can be inserted by the manufacturer, can be used indefinitely many times, and are not linkable.
A secondary requirement is for some kind of revocation in the case of misuse.
As you point out unlinkable anonymity tends to complicate revocation. I think Camenisch's optional anonymity revocation has similar properties in allowing a designated entity to link credentials. Another less "TTP-based" approach to unlinkable but revocable credentials is Stubblebine's, Syverson and Goldschlag, "Unlinkable Serial Transactions", ACM Trans on Info Systems, 1999: http://www.stubblebine.com/99tissec-ust.pdf (It's quite simple you just have to present and relinquish a previous pseudonym credential to get a new credential; if the credential is due to be revoked you will not get a fresh credential.) I think I would define away the problem of local breaks. I mean the end-user does own their own hardware, and if they do break it you can't detect it anyway. If it's anything like playstation mod-chips some proportion of the population would in fact would do this. May be 1-5% or whatever. I think it makes sense to just live with this, and of course not make it illegal. Credentials which are shared are easier to revoke -- knowledge of the private keys typically will render most schemes linkable and revocable. This leaves only online lending which is anyway harder to prevent. Adam On Fri, Aug 16, 2002 at 03:56:09PM -0700, AARG!Anonymous wrote:
Here are some more thoughts on how cryptography could be used to enhance user privacy in a system like TCPA. Even if the TCPA group is not receptive to these proposals, it would be useful to have an understanding of the security issues. And the same issues arise in many other kinds of systems which use certificates with some degree of anonymity, so the discussion is relevant even beyond TCPA.
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com