Re: Unforgeable Blinded Credentials
bear wrote: On Sat, 8 Apr 2006, Ben Laurie wrote: Well the other kind of disincentive was a credit card number. My suggestion was to use a large denomination ecash coin to have anonymous disincentives :) ie you get fined, but you are not identified. The problem with that disincentive is that I need to sink the money for each certificate I have. Clearly this doesn't scale at all well. Um, if it's anonymous and unlinkable, how many certificates do you need? I should think the answer would be one. If they represent cash, then lots. The more the better. -- http://www.links.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
Adam Back wrote: On Sat, Apr 08, 2006 at 07:53:37PM +0100, Ben Laurie wrote: Adam Back wrote: [about Brands credentials] I think they shows are linkable, but if you show more than allowed times, all of the attributes are leaked, including the credential secret key and potentially some identifying information like your credit card number, your address etc. I could be wrong, but I'm pretty sure they're unlinkable - that's part of the point of Brands' certificates. No they are definitely mutually linkable (pseudonymous), tho obviously not linkable to the real identity at the issuer. Christian Paquin wrote: In Brands' system, multiple uses of a n-show credential are not linkable to the issuing (i.e. they are untraceable), but they are indeed linkable if presented to the same party: the verifier will recognize the credential when re-used. This is useful for limited pseudonymous access to accounts or resources. If you want showing unlinkability, better get n one-show credentials (simpler and more efficient). That's only true if the credential contains any unblinded unique data, surely? No. It arises because the credential public key is necessarily shown during a show. (The credential public key is blinded during credential issue so its not linkable to issue). So you can link across shows simply by comparing the credential public key. Its hard to blind the public key also. I thought thats what you were talking about in a previous mail where you were saying about what could be done to make things unlinkable. (Or maybe trying to find the same property you thought Brands had ie unlinkable multi-show, for Chaums credentials.) This is what I was talking about. Note with Brands credentials you can choose: unlimited show, 1-show or n-show. To do 1-show or n-show you make some formula for initial witness that is fair and verifiable by the verifier, so there are only n allowed IWs, and consequently if you reuse one it leaks two shows with the same IW which allows the credential private key to be recovered. ie its just a trick to define a limited number of allowed (and verifier verified) IWs -- IW is a sort of commitment by the credential owner in the show protocol. So there is something compact that the verifier can send somewhere and it can then collate them and notice when a show is n shows (presuming there are multiple verifiers and you want to impose n shows across all of them). Adam Back wrote: Well the other kind of disincentive was a credit card number. My suggestion was to use a large denomination ecash coin to have anonymous disincentives :) ie you get fined, but you are not identified. The problem with that disincentive is that I need to sink the money for each certificate I have. Clearly this doesn't scale at all well. No I mean put the same high value ecash coin in all of your offline limited show credentials / offline ecash coins. eg say you can choose to hand over $100 and retain your anonymity even in event of double-spending offline ecash coins, or over-using limited-show credentials. If you use the same coin then at some point it becomes worth losing it so you can then double-spend everything secured with it. I was curious about the Chameleon credential as they claim to work with Brands credentials, I wrote to one of the authors to see if I could get an electronic copy, but no reply so far. Note also about your earlier comments on lending deterrence, ultimately I think you can always do online lending. Yes, I think this is true, the question is how unattractive it can be made... Cheers, Ben. -- http://www.links.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
Adam Back wrote: On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote: This illustrates a problem with multi-show credentials, that the holder could share his credential freely, and in some cases even publish it, and this would allow non-authorized parties to use it. To avoid this, more complicated techniques are needed that provide for the ability to revoke a credential or blacklist a credential holder, even in an environment of unlinkability. Camenisch and Lysyanskaya have done quite a bit of work along these lines, for example in http://www.zurich.ibm.com/%7Ejca/papers/camlys02b.pdf . So, for the record, has Brands. I agree that, in general, this is a problem with multi-show credentials (though I have to say that using a completely different system to illustrate it seems to me to be cheating somewhat). Brands actually has a neat solution to this where the credential is unlinkable for n shows, but on the (n+1)th show reveals some secret information (n is usually set to 1 but doesn't have to be). I think they shows are linkable, but if you show more than allowed times, all of the attributes are leaked, including the credential secret key and potentially some identifying information like your credit card number, your address etc. I could be wrong, but I'm pretty sure they're unlinkable - that's part of the point of Brands' certificates. The main use I think is to have 1-show, where if you show more than 1 time your identity is leaked -- for offline electronic cash with fraud tracing. But as you say the mechanism generalizes to multiple show. This obviously gives a disincentive against sharing if the secret information is well chosen (such as here's where to go to arrest the guy). Well the other kind of disincentive was a credit card number. My suggestion was to use a large denomination ecash coin to have anonymous disincentives :) ie you get fined, but you are not identified. The problem with that disincentive is that I need to sink the money for each certificate I have. Clearly this doesn't scale at all well. Cheers, Ben. -- http://www.links.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
Christian Paquin wrote: Adam Back wrote: On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote: Brands actually has a neat solution to this where the credential is unlinkable for n shows, but on the (n+1)th show reveals some secret information (n is usually set to 1 but doesn't have to be). I think they shows are linkable, but if you show more than allowed times, all of the attributes are leaked, including the credential secret key and potentially some identifying information like your credit card number, your address etc. In Brands' system, multiple uses of a n-show credential are not linkable to the issuing (i.e. they are untraceable), but they are indeed linkable if presented to the same party: the verifier will recognize the credential when re-used. This is useful for limited pseudonymous access to accounts or resources. If you want showing unlinkability, better get n one-show credentials (simpler and more efficient). That's only true if the credential contains any unblinded unique data, surely? Cheers, Ben. -- http://www.links.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
On Sat, Apr 08, 2006 at 07:53:37PM +0100, Ben Laurie wrote: Adam Back wrote: [about Brands credentials] I think they shows are linkable, but if you show more than allowed times, all of the attributes are leaked, including the credential secret key and potentially some identifying information like your credit card number, your address etc. I could be wrong, but I'm pretty sure they're unlinkable - that's part of the point of Brands' certificates. No they are definitely mutually linkable (pseudonymous), tho obviously not linkable to the real identity at the issuer. Christian Paquin wrote: In Brands' system, multiple uses of a n-show credential are not linkable to the issuing (i.e. they are untraceable), but they are indeed linkable if presented to the same party: the verifier will recognize the credential when re-used. This is useful for limited pseudonymous access to accounts or resources. If you want showing unlinkability, better get n one-show credentials (simpler and more efficient). That's only true if the credential contains any unblinded unique data, surely? No. It arises because the credential public key is necessarily shown during a show. (The credential public key is blinded during credential issue so its not linkable to issue). So you can link across shows simply by comparing the credential public key. Its hard to blind the public key also. I thought thats what you were talking about in a previous mail where you were saying about what could be done to make things unlinkable. (Or maybe trying to find the same property you thought Brands had ie unlinkable multi-show, for Chaums credentials.) Note with Brands credentials you can choose: unlimited show, 1-show or n-show. To do 1-show or n-show you make some formula for initial witness that is fair and verifiable by the verifier, so there are only n allowed IWs, and consequently if you reuse one it leaks two shows with the same IW which allows the credential private key to be recovered. ie its just a trick to define a limited number of allowed (and verifier verified) IWs -- IW is a sort of commitment by the credential owner in the show protocol. So there is something compact that the verifier can send somewhere and it can then collate them and notice when a show is n shows (presuming there are multiple verifiers and you want to impose n shows across all of them). Adam Back wrote: Well the other kind of disincentive was a credit card number. My suggestion was to use a large denomination ecash coin to have anonymous disincentives :) ie you get fined, but you are not identified. The problem with that disincentive is that I need to sink the money for each certificate I have. Clearly this doesn't scale at all well. No I mean put the same high value ecash coin in all of your offline limited show credentials / offline ecash coins. eg say you can choose to hand over $100 and retain your anonymity even in event of double-spending offline ecash coins, or over-using limited-show credentials. I was curious about the Chameleon credential as they claim to work with Brands credentials, I wrote to one of the authors to see if I could get an electronic copy, but no reply so far. Note also about your earlier comments on lending deterrence, ultimately I think you can always do online lending. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
Hal Finney wrote in part: ... Attempts to embed sensitive secrets in credentials don't work because there are no sensitive secrets today. You could use credit card numbers or government ID numbers (like US SSN) but in practice such numbers are widely available to the black hat community. The phrase there are no sensitive secrets today sounds very strange by itself, and doesn't sound much better in context. I assume the intended meaning was more along the lines of: == The set of things you want to keep secret has zero overlap with == the set of things you might want to use as an identifier. Let me just remark that there's nothing new about this. The notion of a secret identifier is very widespread, but if you think about it, it is completely absurd, and always has been. For a fuller discussion, see: http://www.av8n.com/vpn/id-theft.htm which begins as follows: ]] I am reminded of a passage from /Buffy the Vampire Slayer/, in the episode Lie to Me: ]] ]] BILLY FORDHAM: I know who you are! ]] SPIKE: I know who I am, too. So what? ]] ]] My point here is that it shouldn’t matter if somebody knows who I am. Suppose somebody can ]] describe me -- so what? Suppose somebody knows my date of birth, social security number, and ]] great-great-grandmother’s maiden name -- so what? ]] ]] It’s only a problem if somebody uses that identifying information to spoof the _authorization_ ]] for some transaction. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
John Denker wrote: The phrase there are no sensitive secrets today sounds very strange by itself, and doesn't sound much better in context. I assume the intended meaning was more along the lines of: == The set of things you want to keep secret has zero overlap with == the set of things you might want to use as an identifier. this is sort of the track of the x9a10 working group activity on x9.59 ... which had been given the requirement to preserve the integrity of the financial infrastructure for ALL retail payments. the analysis was that the account number had become grossly overloaded. one hand it was mainstay of normal business process required to be widely available and divulged for large number of different business processes. on the other hand, it was also effectively being used for authentication; aka knowing the account number was frequently sufficient for authenticating the transaction. the severely conflicting requirement for account number use ... on one hand being widely available and divulged for large number of different business processes ... and on the other hand needing to be kept private and confidential for authentications purposes ... created opportunity for numerous compromises. this also somewhat has led to my periodic observation that the planet could be buried under miles of cryptography (for hiding account numbers) and it still wouldn't be sufficient to prevent account numbers from leaking. this is further aggravated by the long term findings that the majority of fraud have involved insiders who have legitimate access to the information. it is even further aggravated by account number being static data and therefor vulnerable (as an authentication mechanism) to skimming and replay attacks. x9.59 called for dynamic data on the actual transaction for authentication (as countermeasure to both replay attacks and mitm attacks). x9.59 also called for account numbers used in x9.59 transactions would not be honored when used in non-authenticated transactions (countermeasure to skimming, security breaches, and data breaches). the combination of specifications in the x9.59 standard drastically reduced the sensitive nature of account numbers. the crooks could have all the skimming, security breaches and data breaches involving account number sources and it would be insufficient to execute fraudulent transaction. a few recent posts mentioning x9.59 drastically reducing sensitive nature of account numbers. http://www.garlic.com/~lynn/2006c.html#34 X.509 and ssh http://www.garlic.com/~lynn/2006d.html#26 Caller ID spoofing http://www.garlic.com/~lynn/2006f.html#16 trusted repositories and trusted transactions http://www.garlic.com/~lynn/aadsm22.htm#1 GP4.3 - Growth and Fraud - Case #3 - Phishing http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you and my old long time standby of security proportional to risk ... with regard to the possible large discrepancy involving the value of skimmed account number data to the crooks (in the current infrastructure) vis-a-vis the worth of account number data to retail merchants (the crooks can possibly afford to mount a massive attack that merchants can't reasonably be expected to afford to defend against) http://www.garlic.com/~lynn/2001h.html#61 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
Adam Back wrote: On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote: Brands actually has a neat solution to this where the credential is unlinkable for n shows, but on the (n+1)th show reveals some secret information (n is usually set to 1 but doesn't have to be). I think they shows are linkable, but if you show more than allowed times, all of the attributes are leaked, including the credential secret key and potentially some identifying information like your credit card number, your address etc. In Brands' system, multiple uses of a n-show credential are not linkable to the issuing (i.e. they are untraceable), but they are indeed linkable if presented to the same party: the verifier will recognize the credential when re-used. This is useful for limited pseudonymous access to accounts or resources. If you want showing unlinkability, better get n one-show credentials (simpler and more efficient). The protection you get, as pointed out by Adam, is that when a n-show credential is presented n+1 times (to the same or different verifiers, as long as the audit data is collected centrally) all attributes drop out (*). In cases where you had to authenticate to get those credentials (paid by credit card to get e-coins, had a gold account to get discount coupons, etc.), the issuer usually embeds an invisible and always hidden identifier into the credential so it can recognize you and take application-specific measures against the fraud (revoke your account (**), charge money on your credit card, etc.) Cheers, - Christian (*) For those who wonder how this works, imagine the credential private key and attributes being the (secret) slope of a line. At every showing, the verifier challenges the user to disclose one (random) point on the line. For a one-use credential, re-using it reveals two points which is all you need to compute the slope. If it's only used once, it's infeasible for the verifier (even in collusion with the issuer) to figure out on which line the point belongs to (and therefore break the untraceability property). (**) Note that there is also a nice revocation technique where an issuer publishes a blacklist containing the revoked user's secret identifiers. When a multi-use fraud is detected and that the malicious user's identity drops out, it can be added to the blacklist. Users can prove that the identifier in their credential is not equal to any blacklisted values without revealing it. This can be used, e.g., to effectively revoked a bunch of anonymous and unlinkable e-coins (containing the same secret id) if the owner double-spend any one of them. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
I am aware of, Direct Anonymous Attestation proposed for the Trusted Computing group, http://www.zurich.ibm.com/security/daa/ . DAA provides optionally unlinkable credential showing and relies on blacklisting to counter credential sharing. Hmm, why doesn't this blacklisting get mentioned in IBM's DAA page? What sort of blacklist would this be? What actions would being listed on it trigger? John - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
John Gilmore writes: I am aware of, Direct Anonymous Attestation proposed for the Trusted Computing group, http://www.zurich.ibm.com/security/daa/ . DAA provides optionally unlinkable credential showing and relies on blacklisting to counter credential sharing. Hmm, why doesn't this blacklisting get mentioned in IBM's DAA page? They don't use that term, rather they refer to rogue TPMs. This means TPM keys which have been compromised in some way. The implication is that such keys would, once identified, be shut out from the system, and presumably this would be done by a blacklist. What sort of blacklist would this be? What actions would being listed on it trigger? I don't think the operational details of this are worked out, but I don't follow this area closely. No doubt this is part of why none of these systems have been fielded. (Computers do get sold with TPMs in them but the enormous infrastructure envisioned by the Trusted Computing group is not in place.) In principle, if your TPM's key got put on this blacklist, it would prevent you from access to whatever resources require a valid TPM. What resources those might be would depend on how and where this technology is used, if it ever is. But having a blacklisted TPM would be like not having a TPM at all, in terms of access to network resources. It may be a little more complex than this, because the DAA protocol has a couple of different modes in which it may be used. Rather than a global blacklist, each TPM-requiring service might maintain its own local blacklist of rogue TPM identifiers. Actually I would expect there to be both kinds of blacklists: a global one based on TPM private keys which have been scraped and published; and a local one based on TPM public identifiers (zeta^f values where f is the TPM private key and zeta is a unique per-site constant) that the site decides are being used suspiciously often, suggesting that they are being shared by a group. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
Hal Finney wrote: Ben Laurie writes: It is possible to use blind signatures to produce anonymity-preserving credentials It seems to me quite obvious that someone must have thought of this before - the question is who? Is it IP free? David Chaum did a great deal of work in this area in the 80s and 90s. He pretty much invented the idea of anonymous credentials. Stefan Brands used slightly different techniques a few years later to create improved versions. More recently, Camenisch and Lysyanskaya have created a number of anonymous credential systems based (roughly) on group signatures. Some work was obstructed by the patent on the Chaum blind signature technique, but that expired last year. I think your basic concept is IP free, but you should review the patents by these researchers to be sure. Obviously this kind of credential could be quite useful in identity management. Note, though, that this scheme doesn't give me unlinkability unless I only show each public/private key pair once. What I really need is a family of unlinkable public/private key pairs that I can somehow get signed with a single family signature (obviously this would need to be unlinkably transformed for each member of the key family). There is an operational difficulty with this goal as stated. To demonstrate it, consider a trivial way of achieving the goal. The credential issuer creates a special public/private key pair that is associated with the credential. To everyone who earns the credential, he reveals the private key (which is the same for everyone who has the credential). To show that he holds the credential, the key holder issues a signature using the private key corresponding to the publicly-known credential public key. Now he can show credential ownership as often as desired, without linkability, because all such demonstrations look the same, for all members. This illustrates a problem with multi-show credentials, that the holder could share his credential freely, and in some cases even publish it, and this would allow non-authorized parties to use it. To avoid this, more complicated techniques are needed that provide for the ability to revoke a credential or blacklist a credential holder, even in an environment of unlinkability. Camenisch and Lysyanskaya have done quite a bit of work along these lines, for example in http://www.zurich.ibm.com/%7Ejca/papers/camlys02b.pdf . So, for the record, has Brands. I agree that, in general, this is a problem with multi-show credentials (though I have to say that using a completely different system to illustrate it seems to me to be cheating somewhat). Brands actually has a neat solution to this where the credential is unlinkable for n shows, but on the (n+1)th show reveals some secret information (n is usually set to 1 but doesn't have to be). This obviously gives a disincentive against sharing if the secret information is well chosen (such as here's where to go to arrest the guy). Hohenberger presented a system (at Eurocrypt 2004? 2005?) where then (n+1)th show makes all the shows linkable, which is even neater, IMO, but is based on rocket science :-) All this goes way beyond the scope of my original question, but I have to confess is necessary to make what I outlined useful. Cheers, Ben. -- http://www.links.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
Apu Kapadia wrote: I came across the same problem a couple of years ago (and indeed iterated through private/public key solutions with a colleague). The problem is that you can still give your private key to somebody else. There's no real deterrent unless that private key is used for many other purposes, thereby discouraging sharing. But if that's the case, there's no real anonymity anymore, since the private key is tied to the person's identity. I found that Chameleon Certificates had nice properties. You have a master certificate that lists all your attributes. For authentication, you generate an unlinkable slave certificate with any subset of attributes. You have to possess the master certificate at time of use to generate the slave certificate, so you can't pass a slave certificate to a friend for later use. Then you just need to ensure that the master certificate includes personal details like credit card number, SSN, etc. to deter sharing of master certificates. Note that the slave certificates won't have this information, so this personal information is safe as long as the master certificate is not leaked. Since sharing an attribute amounts to sharing all your attributes, including personal information, this property serves as a good deterrent. Maybe somebody else can comment on the technical viability + crypto details of the paper. P. Persiano and I. Visconti. An Anonymous Credential System and a Privacy-Aware PKI. In Information Security and Privacy, 8th Australasian Conference, ACISP 2003, volume 2727 of Lecture Notes in Computer Science. Springer Verlag, 2003. http://springerlink.metapress.com/openurl.asp?genre=articleissn=0302-9743volume=2727spage=27 Here's the abstract: In this paper we present a non-transferable anonymous credential system that is based on the concept of a chameleon certificate. A chameleon certificate is a special certificate that enjoys two interesting properties. Firstly, the owner can choose which attributes of the certificate to disclose. Moreover, a chameleon certificate is multi-show in the sense that several uses of the same chameleon certificate by the same user cannot be linked together. We adopt the framework of Brands [2] and our construction improves the results of Camenisch et al. [5] and Verheul [16] since it allows the owner of a certificate to prove general statements on the attributes encoded in the certificate and our certificates enjoy the multi-show property. If I have understood your description correctly it seems to me that this is defeated if, rather than sharing the master certificate, the bad guy allows their friend to proxy to them for whatever proofs are required. That way they never have to give up the precious master cert, but the friend's slave cert's still work. Cheers, Ben. -- http://www.links.org/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
On Tue, Apr 04, 2006 at 06:15:48AM +0100, Ben Laurie wrote: This illustrates a problem with multi-show credentials, that the holder could share his credential freely, and in some cases even publish it, and this would allow non-authorized parties to use it. To avoid this, more complicated techniques are needed that provide for the ability to revoke a credential or blacklist a credential holder, even in an environment of unlinkability. Camenisch and Lysyanskaya have done quite a bit of work along these lines, for example in http://www.zurich.ibm.com/%7Ejca/papers/camlys02b.pdf . So, for the record, has Brands. I agree that, in general, this is a problem with multi-show credentials (though I have to say that using a completely different system to illustrate it seems to me to be cheating somewhat). Brands actually has a neat solution to this where the credential is unlinkable for n shows, but on the (n+1)th show reveals some secret information (n is usually set to 1 but doesn't have to be). I think they shows are linkable, but if you show more than allowed times, all of the attributes are leaked, including the credential secret key and potentially some identifying information like your credit card number, your address etc. The main use I think is to have 1-show, where if you show more than 1 time your identity is leaked -- for offline electronic cash with fraud tracing. But as you say the mechanism generalizes to multiple show. This obviously gives a disincentive against sharing if the secret information is well chosen (such as here's where to go to arrest the guy). Well the other kind of disincentive was a credit card number. My suggestion was to use a large denomination ecash coin to have anonymous disincentives :) ie you get fined, but you are not identified. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
Ben Laurie writes: If I have understood your description correctly it seems to me that this is defeated if, rather than sharing the master certificate, the bad guy allows their friend to proxy to them for whatever proofs are required. That way they never have to give up the precious master cert, but the friend's slave cert's still work. That's a good point, proxies are another way to get around limitations on credential sharing. Attempts to embed sensitive secrets in credentials don't work because there are no sensitive secrets today. You could use credit card numbers or government ID numbers (like US SSN) but in practice such numbers are widely available to the black hat community. Someone getting a credential using a stolen identifier won't be deterred from sharing it, if the only deterrence is fear of the identifier becoming public. Blacklisting seems to me to be the only good solution, and in fact it is the one proposed for the only proposed deployment of this technology I am aware of, Direct Anonymous Attestation proposed for the Trusted Computing group, http://www.zurich.ibm.com/security/daa/ . This is based on the CL signatures I referenced earlier. Trusted Computing systems have a credential which they are supposed to show to prove they are legit. But if these showing instances are linkable it is a privacy violation. (In practice IP address is normally going to provide just as much linkability, so for the most part this is all political posturing IMO, but in principle this would let you authenticate over TOR and retain your privacy.) DAA provides optionally unlinkable credential showing and relies on blacklisting to counter credential sharing. Actually the credentialed keys are supposed to be protected by hardware, so this is a second layer of defense in case someone figures out how to extract them from the chips. I'm skeptical that this will actually go forward; we are all familiar with the arguments against Trusted Computing proposals. But it is still of theoretical interest as a case study for unlinkable credentials which might actually be fielded in the near future. Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
I came across the same problem a couple of years ago (and indeed iterated through private/public key solutions with a colleague). The problem is that you can still give your private key to somebody else. There's no real deterrent unless that private key is used for many other purposes, thereby discouraging sharing. But if that's the case, there's no real anonymity anymore, since the private key is tied to the person's identity. I found that Chameleon Certificates had nice properties. You have a master certificate that lists all your attributes. For authentication, you generate an unlinkable slave certificate with any subset of attributes. You have to possess the master certificate at time of use to generate the slave certificate, so you can't pass a slave certificate to a friend for later use. Then you just need to ensure that the master certificate includes personal details like credit card number, SSN, etc. to deter sharing of master certificates. Note that the slave certificates won't have this information, so this personal information is safe as long as the master certificate is not leaked. Since sharing an attribute amounts to sharing all your attributes, including personal information, this property serves as a good deterrent. Maybe somebody else can comment on the technical viability + crypto details of the paper. P. Persiano and I. Visconti. An Anonymous Credential System and a Privacy-Aware PKI. In Information Security and Privacy, 8th Australasian Conference, ACISP 2003, volume 2727 of Lecture Notes in Computer Science. Springer Verlag, 2003. http://springerlink.metapress.com/openurl.asp? genre=articleissn=0302-9743volume=2727spage=27 Here's the abstract: In this paper we present a non-transferable anonymous credential system that is based on the concept of a chameleon certificate. A chameleon certificate is a special certificate that enjoys two interesting properties. Firstly, the owner can choose which attributes of the certificate to disclose. Moreover, a chameleon certificate is multi-show in the sense that several uses of the same chameleon certificate by the same user cannot be linked together. We adopt the framework of Brands [2] and our construction improves the results of Camenisch et al. [5] and Verheul [16] since it allows the owner of a certificate to prove general statements on the attributes encoded in the certificate and our certificates enjoy the multi-show property. Apu -- Apu Kapadia, Ph.D. Research Fellow, Institute for Security Technology Studies (ISTS) Dartmouth College, Hanover NH 03755, USA http://www.cs.dartmouth.edu/~akapadia/ On Apr 1, 2006, at 6:35 AM, Ben Laurie wrote: It is possible to use blind signatures to produce anonymity-preserving credentials. The general idea is that, say, British Airways want to testify that I am a silver BA Executive Club cardholder. First I create a random number (a nonce), I blind it, then send it to BA. They sign it with their “this guy is a silver member” signing key, I unblind the signature and then I can show the signed nonce to anyone who wants to verify that I am silver. All they need to do is check the signature against BA’s published silver member key. BA cannot link this nonce back to me because they have never seen it, so they cannot distinguish me from any other member. However, anyone I show this proof to can then masquerade as a silver member, using my signed nonce. So, it occurred to me that an easy way to prevent this is to create a private/public key pair and instead of the nonce use the hash of the public key. Then to prove my silver status I have to show that both the hash is signed by BA and that I possess the corresponding private key (by signing a nonce, say). It seems to me quite obvious that someone must have thought of this before - the question is who? Is it IP free? Obviously this kind of credential could be quite useful in identity management. Note, though, that this scheme doesn’t give me unlinkability unless I only show each public/private key pair once. What I really need is a family of unlinkable public/private key pairs that I can somehow get signed with a single “family” signature (obviously this would need to be unlinkably transformed for each member of the key family). Permalink: http://www.links.org/?p=88 Cheers, Ben. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
On Sat, Apr 01, 2006 at 12:35:12PM +0100, Ben Laurie wrote: However, anyone I show this proof to can then masquerade as a silver member, using my signed nonce. So, it occurred to me that an easy way to prevent this is to create a private/public key pair and instead of the nonce use the hash of the public key. Then to prove my silver status I have to show that both the hash is signed by BA and that I possess the corresponding private key (by signing a nonce, say). It seems to me quite obvious that someone must have thought of this before - the question is who? Is it IP free? Well I thought of this a few years ago also. However I suspect you'd find the same idea earlier as a footnote in Stefan Brands book. (Its amazing how much stuff is in there, I thought I found something else interesting -- offline transferable cash, turns out that also was a footnote referring to someone's MSc thesis.) Obviously this kind of credential could be quite useful in identity management. Note, though, that this scheme doesn’t give me unlinkability unless I only show each public/private key pair once. What I really need is a family of unlinkable public/private key pairs that I can somehow get signed with a single “family” signature (obviously this would need to be unlinkably transformed for each member of the key family). This is harder, I thought about this a bit also. I was thinking a way to do this would be to have a self-reblindable signature. Ie you can re-blind the certificate signature such that the signature remains, but it is unlinkable. I didn't so far find a way to do this with any of the schemes. So it would for example be related to the more recent publicly re-encryptable Elgamal based signatures. (Third party can re-encrypt the already encrypted message with out themselves being able to decrypt the message). Brands also has a mechanism to simplify the use each cert once method. He can have the CA reissue you a new cert without having to go through the attribute verification phase. Ie you present an old cert and get it reblinded, and the CA does not even if I recall see what attributes you have. So you just periodically get yourself another batch. Mostly does what you want just with some assistance from the CA. Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Unforgeable Blinded Credentials
It is possible to use blind signatures to produce anonymity-preserving credentials. The general idea is that, say, British Airways want to testify that I am a silver BA Executive Club cardholder. First I create a random number (a nonce), I blind it, then send it to BA. They sign it with their “this guy is a silver member” signing key, I unblind the signature and then I can show the signed nonce to anyone who wants to verify that I am silver. All they need to do is check the signature against BA’s published silver member key. BA cannot link this nonce back to me because they have never seen it, so they cannot distinguish me from any other member. However, anyone I show this proof to can then masquerade as a silver member, using my signed nonce. So, it occurred to me that an easy way to prevent this is to create a private/public key pair and instead of the nonce use the hash of the public key. Then to prove my silver status I have to show that both the hash is signed by BA and that I possess the corresponding private key (by signing a nonce, say). It seems to me quite obvious that someone must have thought of this before - the question is who? Is it IP free? Obviously this kind of credential could be quite useful in identity management. Note, though, that this scheme doesn’t give me unlinkability unless I only show each public/private key pair once. What I really need is a family of unlinkable public/private key pairs that I can somehow get signed with a single “family” signature (obviously this would need to be unlinkably transformed for each member of the key family). Permalink: http://www.links.org/?p=88 Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Unforgeable Blinded Credentials
Ben Laurie writes: It is possible to use blind signatures to produce anonymity-preserving credentials It seems to me quite obvious that someone must have thought of this before - the question is who? Is it IP free? David Chaum did a great deal of work in this area in the 80s and 90s. He pretty much invented the idea of anonymous credentials. Stefan Brands used slightly different techniques a few years later to create improved versions. More recently, Camenisch and Lysyanskaya have created a number of anonymous credential systems based (roughly) on group signatures. Some work was obstructed by the patent on the Chaum blind signature technique, but that expired last year. I think your basic concept is IP free, but you should review the patents by these researchers to be sure. Obviously this kind of credential could be quite useful in identity management. Note, though, that this scheme doesn't give me unlinkability unless I only show each public/private key pair once. What I really need is a family of unlinkable public/private key pairs that I can somehow get signed with a single family signature (obviously this would need to be unlinkably transformed for each member of the key family). There is an operational difficulty with this goal as stated. To demonstrate it, consider a trivial way of achieving the goal. The credential issuer creates a special public/private key pair that is associated with the credential. To everyone who earns the credential, he reveals the private key (which is the same for everyone who has the credential). To show that he holds the credential, the key holder issues a signature using the private key corresponding to the publicly-known credential public key. Now he can show credential ownership as often as desired, without linkability, because all such demonstrations look the same, for all members. This illustrates a problem with multi-show credentials, that the holder could share his credential freely, and in some cases even publish it, and this would allow non-authorized parties to use it. To avoid this, more complicated techniques are needed that provide for the ability to revoke a credential or blacklist a credential holder, even in an environment of unlinkability. Camenisch and Lysyanskaya have done quite a bit of work along these lines, for example in http://www.zurich.ibm.com/%7Ejca/papers/camlys02b.pdf . Hal Finney - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
