Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [higgins-dev] PPID generation

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


Back to the top