[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] PPID generation
|
Thanks all for the thoughtful and insightful responses.
Jeffrey C. Broberg
CA
Director, Senior Architect
Security Systems
Advanced Technology Group
Tel: +1-508-628-8490
Jeffrey.Broberg@xxxxxx
=jeff.broberg
http://jyte.com/widget/claim/cardspace-will-be-a-success
> -----Original Message-----
> From: higgins-dev-bounces@xxxxxxxxxxx
> [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Michael McIntosh
> Sent: Friday, May 11, 2007 8:25 AM
> To: Higgins (Trust Framework) Project developer discussions
> Cc: Higgins (Trust Framework) Project developer discussions;
> higgins-dev-bounces@xxxxxxxxxxx
> Subject: RE: [higgins-dev] PPID generation
> Importance: High
>
> higgins-dev-bounces@xxxxxxxxxxx wrote on 05/10/2007 03:49:47 PM:
>
> > As I understand it, the master key is generated when a
> managed card is
> > imported into the card store.
>
> No. There is no master key associated with a managed card.
> Only personal cards have master keys, for personal cards the
> master key is generated when the car dis created).
>
> > According to section 8.1 of the
> > CardSpace Technical Reference, this is considered "housekeeping"
> > data. For self-issued cards, the master key is generated when the
> > card is created. The master key and hash salt are just random bytes
> > (32 for master and 16 for salt) that are generated using a
> > cryptographically secure random number generator. If
> either type of
> > card is subsequently exported, the housekeeping data, including the
> > master key and hash salt, are exported so that when imported the
> > values will remain consistent. If you know the master key and hash
> > salt it fairly simple to compute the PPID for a given relying party.
>
> According to the CardSpace Tech Ref, this is the algorithm
> for PPID calculation (note the absense of master key, which
> is used for self signing key pair generation):
>
> 7.4.2. PPID
> The PPID is computed as follows using the card identifier in
> the information card (value of the ic:CardId element) and the
> RP identifier (constructed as described in Section 7.4.1):
> ? Encode the value of the ic:CardId element of the
> information card into a sequence of bytes, call it
> CardIdBytes, using Unicode encoding.
> ? Hash CardIdBytes using the SHA256 hash function to obtain
> the canonical card identifier CanonicalCardId.
> CanonicalCardId = SHA256 (CardIdBytes)
> ? Hash the RP identifier with the CanonicalCardId using the
> SHA256 hash function to obtain the PPID.
> PPID = SHA256 (RP identifier + CanonicalCardId) ? Convert
> PPID to a base64 encoded string.
>
> > my question is this, can a rp be tricked by someone trying
> to generate
> > a PPID for someone elses card. Is it all dependent on the unique
> > cardid ? it seems like this algorithem could easily
> replicate a PPID
> > if you know the RP you are going to, and the cardid naming
> scheme used
> > by the users card provider. I must be wrong...
>
> If you have a CardId and an RP SSL Certificate (or RP
> Identifier), you have all that you need to compute the PPID
> for that Card::RP pair.
> So the right questions are:
>
> 1) Can a Client trick an IdP into generating a Token
> containing ANY arbitrary PPID?
> Yes. The Client typically provides the PPID value to the IdP
> and it is calculated from the the CardId which the IdP has
> (since it generated it, and it is also typically sent in the
> RST) and the RP SSL Certificate WHICH IT DOES NOT HAVE.
>
> 2) Can a Client trick an RP into accepting a Token containing
> ANY arbitrary PPID?
> Yes, in many cases. Consider this scenario:
> a) RP asks Client for Token containing a PPID.
> b) Client obtains from its IdP/STS a Token containing a PPID
> calculated via an alternative algorithm (e.g. someone else's
> PPID for this RP).
> c) Client posts the Token (signed by its IdP/STS) to the RP.
> In simplest case:
> d1) RP validates the Token (checks signature, trustworthiness
> of IdP/STS,
> etc.) and uses PPID (only) to look up the Client account information.
> In slightly better case:
> d2) RP validates the Token (checks signature, trustworthiness
> of IdP/STS,
> etc.) and uses PPID and IdP Key to look up the Client account
> information.
> In worst case:
> In step "b", Client could have obtained the Token from same
> IdP/STS as used by the authentic user of the PPID, therefore
> "d2" above will not be adequate.
>
> 3) Can anything be done to solve this obvious problem?
> Yes, in some cases. Alternatives are:
> a) Ensure that IdP/STS generates hard to guess CardIds and
> that IdP/STS, Clients, and RPs protect Cards, CardIds, and
> PPIDs as extremely confidential material (equivalent to Master Keys).
> If a rogue Client cannot access a Card (or CardId, or PPID)
> then it cannot use the value, and this becomes a guessing attack.
> b) Have the IdP/STS issue Cards with "RequireAppliesTo". This is
> *SUPPOSED* to cause the Client to include the RP SSL
> Certificate in the RST.
> This would allow the IdP/STS to generate the correct PPID and
> encrypt the returned Token so it could only be used at the correct RP.
> Note that the reason this is not always done is that it
> allows the IdP/STS to "track" the user.
> Note also that this appears to have a bug in that CardSpace
> is not providing a complete/correct AppliesTo when this is
> turned on (RequireAppliesTo).
>
> In summary, you are correct in being concerned.
>
> Thanks,
> Mike
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>
