Links

Ben Laurie blathering


CardSpace Cannot Provide Privacy

Kim Cameron writes about “token independence” and how SAML doesn’t have it. As far as I can see, token independence is yet another word for unlinkability – that is, if I present a token twice, the two presentations should not be linkable. Of course, MS have a new word for this, too – they call it “non-auditing”.

However, Kim continues to be in denial about the impossibility of achieving this with traditional crypto. As I point out at every opportunity I get, a signed assertion using any traditional method is inherently linkable, because the signature itself is invariant. Scott Cantor points this out in a comment on Kim’s blog

I don’t think it’s enough to remove a couple of XML attributes to avoid the correlation attack you’re talking about. I think it requires non-traditional cryptography to present a signed claim of anything from a third party in such a way that the whole bag of bits can’t be used as a correlatable handle

Kim tries to wriggle out of this by saying

You don’t need special cryptography as long as you are willing to employ “bearer tokens” to convey non-unique assertions. You do need blind signatures once you want to associate tokens with proof keys.

I think by “bearer tokens” he means self-asserted tokens. This is surely a completely incorrect use of the term, but I assume its what he meant, since he seems to be saying the other possibility is a token signed by a “proof key” – whatever that is; presumably a key the relying party trusts in some way. Assuming all my guesses at his terminology are correct, then this argument is self-defeating – if the tokens are self-asserted, then they can be constructed on the fly each time they are needed, and so SAML will work just as well as any other way of expressing tokens, since the correlating fields can be changed each time.

If Microsoft are really serious about providing “non-audit” (i.e. unlinkable) modes for CardSpace, then they need to get with the program and stop trying to pretend that they can do this with RSA signatures. Its a shame that they’re going to such lengths to make CardSpace good but can’t quite seem to go the last mile and make their claims actually true. Perhaps they don’t want to?

3 Comments

  1. Hi Ben, some clarification on the bearer/”proof key” thing. A bearer token is not cryptographically bound to the subject; in other words, whoever presents it (the ‘bearer’) is considered to be the subject (or, at least, acting on behalf of the subject). Bearer tokens MUST be protected in transit by transport layer security such as SSL/TLS. A ‘holder-of-key’ token, on the other hand, contains a public key, so the token is cryptographically bound to the holder of the private key – this is the proof key to which Kim refers – you can use it to prove that you are the subject of the token. Typically, you would present the token in a message signed by the proof key. If an attacker intercepts a ‘holder-of-key’ token in transit, it’s worthless without the associated proof key. Hope this clarifies!

    Comment by Pat Patterson — 20 Feb 2007 @ 22:49

  2. […] Following up on Ben Laurie’s excellent introduction to selective disclosure, Kim Cameron and Ben have been blogging on the properties of unlinkability and selective disclosure. See here, here, here, and here, as well as this older post of Ben’s. […]

    Pingback by The Identity Corner » On Identity Claims, Unlinkability, and Selective Disclosure (part 1) — 9 Aug 2007 @ 20:44

  3. […] for two different websites that appear independent. (My colleague Ben from Google security team disputes even that weak guarantee, arguing that only assertions that can not be linked even with help from the identity provider […]

    Pingback by Unlinkable identifiers on the web: rearanging deck chairs (2/3) « Random Oracle — 29 Sep 2009 @ 14:29

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress