Peter Williams ha scritto:
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()?
I meant the first solution. Internal authentication is completely specular w.r.t. external authentication, in that roles of host and card are
exchanged, thus the ExtAuthenticate(...) method in the Applet would hardly be useful for InternalAuth too.
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
