From: Peter Williams (home_pwmsn.com)
Date: Fri Mar 11 2005 - 14:37:06 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

If we go further into the mysteries of the ActiveCard applet suite, we see
some interesting properties, that we can leverage, re XAUT, the distinction
between CO and AO roles, and setting up SCP 02 R_MAC R_ENCs based on
combing GP and applet-specific processing of the core GP handshake. (This
initial summary was hard to write well, as the process is hard to describe
well...)

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" <home_pwmsn.com>
To: "MUSCLE" <musclelists.musclecard.com>
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
> Musclelists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>
_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]