On Sat, 26 Mar 2005 10:59:14 -0800 "Peter Williams" <[EMAIL PROTECTED]> wrote:
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):
Hi, I can't understand here if you're meaning a session key for data transfers between:
a) a host machine and the card itself (i.e. for secure messaging)
b) the local host machine (connected to the card) and a remote one
If you're meaning case a, as I guess, I have to warn you that CardEdge does not have, at the moment, any support for secure messaging. In case b, instead, the card is usually involved only at a ComputeCrypt-level, i.e. the card may encrypt/decrypt cryptograms without caring if the data is key material or application data. This happens because the host is the final user of the session key, in this latter case, not the card device.
Hope this helps,
Tommaso.
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
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
