Managed Card Portability

I’ve decided that there is no better way than to learn the ins and outs of a technology than to publicly assert your understanding — as long as your ego can take it, you learn very quickly where all the gaps and flaws in your logic lie :)

It turns out that all this time that I’ve been working with information cards, I’ve misunderstood the nature of .crd files and managed card portability. In my talk at RSA, I stated that managed cards had a different portability model than self-issued cards, because a user could download a .crd file from an Identity Provider at any time, import it into a new selector, and use it to get to all of their sites where they had previously associated a card from that account at the Identity Provider.

This isn’t the way that .crd files work, as it turns out. A .crd file is not an information card – it is an information card *template*. When you download a .crd file, the master key for the card is not part of the file, it is generated upon import — thus if you import a .crd file into two different selectors, each card will have two different master keys. Different master keys mean different privatepersonalidentifiers being sent to the Relying Party, who will most likely object. This means that even if somebody out there compromises my identity provider, they may be able to download a card that points to my identity, but it is highly likely that they won’t be able to use that card anywhere that matters (unless the Relying Party isn’t asking for ppid, that is). This revelation has opened the door for me to cook new hare-brained schemes around how cards might be used for what I like to call “user-centric forensics” –I see two possibilities for intrusion detection here:

1. If my card is an auditing card, I hope that in the future, Identity Providers will prominently feature any unsuccessful card use attempts, giving me a cue that something is wrong, and giving me data that I could use to find my attacker.

2. Depending on what the Relying Party keeps about a given card, it should theoretically be possible to detect a token submission where both the claims and the issuer are identical to a valid cardholder, but where the ppid differs (or perhaps where the submission comes from an IP address in a different country or a combination of this kind of thing). Whether such a thing is desirable or not is a different question — the RP would have to store a *lot* of data, and the resulting privacy tradeoffs might not be worth it. The PamelaWare plugins couldn’t do this kind of tracking, as we store a hash of the issuer and ppid rather than the values themselves (this is the closest thing to an RP best practice that I know).

If managed card portability is needed in the way that I originally understood it, I think it could still be done – a claim other than privatepersonalidentifier could be used to pass an identifier not tied to the master key of the card — but all in doing so, you lose one of the qualities that in my mind makes information cards unique, you would essentially revert to a two-party system, with the selector merely passing things around instead of being an essential participant. No matter what, I think this concept of card templates could be used to do some very imaginative things – now that I understand the difference, I can’t wait to go and play!

Many thanks to Vittorio for attending my RSA session and giving me such valuable feedback – I am very happy to be just a little less clueless in at least one tangible way :-D

3 thoughts on “Managed Card Portability

  1. Remember it’s up to the STS to generate a PPID, assuming they want to support it.

    Right now we’re all lazy *grin* We simply reflect back the suggested one that comes down as part of the ClientPseudonym in the RST. This is generally a bad idea, not just for the reason you give, but because that PPID is not immutable, it may change with the RP SSL certificate (I’ve moaned about this before; )

    Having said that the PPID itself should be constant with the same card, imported into different selectors. It’s the signing key that will vary, and as you point out this needs to be combined with the PPID to make something unique. Thinking about it, it’s worse than you think. If the key is per selector then even exporting a self issued card and importing on a new machine means a new signing cert, and authentication fails if an RP is following best practice.

    Now yes, in a non-auditing STS there’s no other way to provide a PPID (and I am not convinced you actually need to offer on), but once you slip into auditing mode, where you know the identity of the RP there’s a whole world of possibilities; including say “Sod off” to the ClientPseudonym and doing it yourself; which, to my mind, is the right thing to do. Well, it would be, if there was an easy way to work out if the RP has an EV certificate rather than have a master table of EV OIDs.

  2. I’m glad you pointed to that entry – I hadn’t read it yet and it brings up yet again more interesting points, for example I didn’t know that the FQDN was not used in creating the ppid!

    Personally, I would think that an STS would have to think long and hard before implementing something that changes the outwards behavior of the black-box system that is supposed to be a managed card.

    I’ll have to do some impromtu testing on whether signing key changes for managed cards when imported between browsers – I don’t know if I’ve ever done such a thing in my PamelaWare testing…

  3. Here is what the XMLDAP STS does:
    In English:
    If the id selector presented a PPID in the RST then just use that.
    If the id selector provided the RP certificate then take the certs’ encoded bytes and concatenet with the STS PPID and then compute a SHA1 hash of the result. This hash is the returned ppid in the token.
    Else if I don’t know the RP cert but I have a value for “restrictedTo” then concatenate this with the STS PPID, hash the concatenated bytes as before and return the result.
    Else if neither of the above is known then just return the STS ppid associated with the card which makes this ppic linkable.

    As you can see in the comments in the code using the whole encoded bytes of the cert was never considered a good idea. But alternatives are not really easy to find as each variant has its own drawbacks. Comments and suggestions are very wellcome.

Comments are closed.