We know a classical GP handshake has the form
1. host-nonce -> card -> card side session state, during INITIAL-UPDATE req
2. card-nonce -> host -> host-side session state, during INITIAL_UPDATE resp
3. mutual key agreement occurs, upon receipt of GP_EXTERNAL_AUTHENTICATE resp
We also know that, under this flow, the initial SCP security level requirements are stated, and the required SCP protocol support can be signaled back to the host, by the card. This latter field allows the security domain to indicate that it can (or can not) do R_MAC, R_ENC, perhaps per SCP 02 support.
What's interesting is the role<->function mapping tables, for each of the different applets, in the ActiveCard suite. Let's concentrate on the GC applet's table, Table 3, pg.10. Here we have 2 forms of external-authenticate, 'EXTERNAL_AUTHENTICATE, and "GC"_EXTERNAL_AUTHENTICATE', with only the AO being able to use the latter. Lets assume GC_EXTERNAL_AUTHENTICATE corresponds to musclecard's external-authentication APDU, available in the CVS version of the applet (only).
Perhaps the secure handshake to the musclecard applet (emulating a GC) goes like this:
1. host-nonce (from a call to applet's public GET-CHALLENGE) -> card side session state, during INITIAL-UPDATE req, creating GP session key derivations on the card
2. card-nonce -> host -> host-side session state, during INITIAL_UPDATE resp
..two sides both have two card-generated nonces, and some GP session key derivation data....
3. we perform "GC"_EXTERNAL_AUTHENTICATE: i.e. "This APDU communicates the cryptogram obtained by TDES encryption of a card challenge with the TDES key associated to the service protected by XAUT". ... which is hard to parse.
Perhaps 3 means: the result stream generated in 2 is now a field in "GC"_EXTERNAL_AUTHENTICATE' req, and said field is encrypted using an XAUT key pertinent to the particular cardedge method which the AO is seeking to invoke.
If this is the meaning, then we know that the applet's method (which presumably can decrypt the payload using its XAUT) now has a cleartext copy of the card's own card-cryptogram. it can thus compute the GP session derivation keys, and engage in R_MAC, R-ENC etc with the AO process.
Now this is very cute! As one obtains per-method, per TDEA key, access control granularity, via the session-setup process.
Now, as I've constructed the description of such a process from hints, rather than read a process description, do we thing that its (a) reasonable, (b) valuable, (c) something we would want to apply?
Peter.
----- Original Message ----- From: "Peter Williams" <[EMAIL PROTECTED]>
To: "MUSCLE" <[email protected]>
Sent: Friday, March 11, 2005 11:32 AM
Subject: Re: [Muscle] muscle getChallenge, versus GP 2 way authentication
Now, why bother will all this (if its even correct), is my final question. What did it buy them, and what would it buy us, if we adopted the practice in the PKCS#11 and opensc drivers?
Peter. _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
