----- Original Message ----- From: "Tommaso Cucinotta" <[EMAIL PROTECTED]>
To: "MUSCLE" <[email protected]>
Sent: Wednesday, March 16, 2005 1:36 PM
Subject: Re: [Muscle] muscle getChallenge, versus GP 2 way authentication
Yep. You discovered a misbehaviour on the DECRYPT case, due to the SendData(..) statement that *is not needed*. Just delete that line (a check on the plugin would be needed, too). That caused what you told, return of data to application. Please, note that such data is exactly the original random challenge, in case of successful auth, instead it is the decrypted cryptogram provided by the application using the on-card key in other cases, leading to known ciphertext attacks on the key (possibly meaningful for symmetric keys, for asymmetric that would be the public key anycase). Maybe I added that line at somepoint during development for testing purposes, then I forgot it there. AFAICR, I used to work with RSA authentication using the VERIFY mode, I guess this other case was not tested.
Lets think more about this issue, for the TDEA case of XAUT.
We know the cardedge supports the getChallenge/Ext-Authentication sequence, in which the return value is intended to be a OK/NOTOK signal.
But what about the getChallenge/Internal-Authentication sequence - in which the return value WOULD be the challenge, as encrypted by the card?
Were you intended that internal-authentication be implemented by the driver as a call to the ComputeCrypt() method, or would the same code as in external-authentication() would be "repurposed" - one day, perhaps - for a VMcard's internal-authentication()?
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.
Peter. _______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
