|
As I understand it, the master key is generated when a managed card is imported into the card store. 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.
>>> "Broberg, Jeffrey C" <Jeffrey.Broberg@xxxxxx> 05/10/07 1:20 PM >>>
s
o if the master key and salt value was known, then you could generate the unique ppid for a rp with a utility pgm, how does the master key and salt value get initially populated, and is it in the card itself, or the card store
Unless the "AppliesTo" element is passed to the STS, the client is required to provide a PPID value in the RST message. The STS can return the PPID unmodified in the RSTR or it can use the PPID as input to a custom PPID function (section 4.3.4).
When the client generates the PPID, the algorithm requires the use of a master key and a salt value. Both of these values are contained within the "information card private data" area of the card store. In order to generate the same unique PPID for a given card and relying party, the master key must be known to the client. It is the relying party's responsibility to verify, for a given user, that the PPID matches a PPID previously used or registered at the RP by the user.
>>> "Broberg, Jeffrey C" <Jeffrey.Broberg@xxxxxx> 05/10/07 12:28 PM >>>
In the MS infocard doco, they talk about how a ppid is generated and made unique for a particular RP
7.5.2. PPID
The PPID MUST be computed as follows using the card identifier (value of the ic:CardId
element in the information card) and the RP identifier (constructed as in Section 160H7.5.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)
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...
CA
Director, Senior Architect
|
