How did you intend the API to be used to generate an ISO session key,
following on from an ext-auth. and int-auth. exchange between offline
terminal (T) and card (C):
Lets assume musclecard is post-personalized (ie after format()) with one set
of diversified keys by a cryptographic officer, and
Key.session = f(key.t, key.c, obj.T.challenge, obj.OUT)
Lets define key.t and key.c as musclecard TDES keys, in the key array. Lets
define key.a and key.b as two read-only, TDES "sssionkey-function" keys.
Assume obj.T.Challenge has a well defined objectid, for the security domain,
and the OUT object has the fresh result of getChallenge().
And lets assume that a sessionkey-function f = F1 o F2, where perhaps
F1 is mixing function for the parameters of f (perhaps blockwise xor)
F2 uses TDEAECB|key.a(F1) bitwiseor TDEAECB.key.b( inv(F1) )
Does the cardedge API already have a use mode for calculating some function
f?
Did the security architecture intend, for example, that the terminal compute
f, and use a third read-only long-term key (TDEA.kek) to load that session
key into the card, perhaps?
What was the design intent, here? Ideally, I want to use the API in
accordance with the intended security architecture, rather than hack the
code to impose key management functions that are not consistent with the
security model for key loading, key usage, etc.
Thanks!
Peter.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:muscle-
> [EMAIL PROTECTED] On Behalf Of Tommaso Cucinotta
> Sent: Saturday, March 26, 2005 12:44 AM
> To: MUSCLE
> Subject: Re: [Muscle] muscle getChallenge, versus GP 2 way authentication
>
> Peter Williams ha scritto:
> > if we read the US government's opinion on the context for
> > internal-authentication(), the step of internal-authentication should
> > always be preceded by a successful VerifyPin() operation, whose state
> > either a repurposed external-authentication() or computeCrypt function
> > should verify (somehow). One assumes that a particular pin shall be
> > verified as being logged in, and there is some way of configuring
> > which pin is required, prior to internal-authentication() being
> > available for one or more roles.
>
> Well, CardEdge is not that different: strong, cryptography based,
> internal-authentication is performed with ComputeCrypt(..), which
> requires use
> of a key. Such key has an associated ACL (the "use" ACWord) in which a
> prior PIN verification *may* be required. This decision is left to the
> creator of the key to be used for internal authentication, who decides
> if that key use is protected by a PIN code or another means of external
> authentication (another key or biometrics).
>
>
> Tommaso.
>
>
> _______________________________________________
> Muscle mailing list
> [email protected]
> http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
