----- Original Message ----- From: "Peter Williams" <[EMAIL PROTECTED]>
To: "MUSCLE" <[email protected]>
Sent: Friday, March 11, 2005 11:00 AM
Subject: Re: [Muscle] muscle getChallenge, versus GP 2 way authentication
(3 comment) Perhaps we should try and determine why that distinction was made: i.e. why one role present on the host computer can access data files, but the cardholder cannot so access their contents, by policy formulation. What's in those files? one naturally asks.
Well, I suspect the answer was simple:
ActiveCard applets have an access control decision function that is not present in the javacard musclecard implementation. It allows the card's policy to specify "authentication strength" on a per-method basis: e.g. the host driver must first complete XAUT strong authentication, and only then can one invoke the verify pin method, or access the read bio template method , prioir to requesting the match-on-board method, for examples.
Im wondering now if MSCKeyInfo's keyInfo.keyPolicy class could be extended to allow a MSCGetKeyAttributes() consumer to interact with such a card function, and determine what the strength requirements are, in the driver?
(3 discussion) We know that the files subject to the policy comment (3 comment) distinguish the TL and the V of BER-encoder TLVs. I.e. the tags and lengths of the PDV stream are in one file, under one TDEA key obligation, and the Vs are in another, under a distinct TDEA presentment obligation. We also know, that there can be multiple[le instances of the file manager applet, each with different TDEA key presentment(s), requirements. This suggests that there can be more than instance of the AO, surely? We should investigate the background to this, to apply to musclecards, if appropriate.
Again the answer seems simple.
There are both AO-read, and AO-write keys.
And, there are indeed different instances of the AO role class - accessing methods in the GC applet for cert management, and accessing bio template information, populating sensitive match parameters on the fingerbio applet.
In the musclecard applet's LoginStrongIdentity() private method, for JavaCards, we would have to maintain an indication in the array of symmetric keys which are used/available for external authentication to the ACE, then add support for the CM_DES_ECB_NOPAD cipher mode to allow for XAUT-based RBAC, over SCP 01.
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
