----- Original Message ----- From: "Peter Williams" <[EMAIL PROTECTED]>
To: "MUSCLE" <[email protected]>
Sent: Saturday, March 12, 2005 9:07 AM
Subject: Re: [Muscle] muscle getChallenge, versus GP 2 way authentication
(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.
We can go further in our gaining understanding - and thus identify muscle requirements (for the javacard VM version of the applet) - by studying 5.3.3.4 and 5.3.3.5 in http://csrc.nist.gov/publications/nistir/nistir-6887.pdf. Then, we can also study the GC applet instances' methods, from the host's perspective, in 5.3.4. Comparing the muscle applet ability to implement the spec, with the specification descriptions, we can potentially comprehend the meaning of all the spec's generalized models and CAC-specific terminology. Only then can we really build firmware and drivers that are correct and complete, for the security model built into the muscle applet.
----------
5.3.3.5. Get ACRs. Here the access control rules for a given "provider" may be retrieved - using an CLA=0x80 class PDU. In the GSC model, this method is presumably implemented by the JavaCard libraries or GP libraries, rather than the applet itself. This could suggest that the applet is not responsible for managing the store of data, but rather the data store is managed by the card manager, is store in the applet registry, or equivalent. This could mean that the rights to read/write this meta-store are also controlled by a custom GSC-IS Card Manager, which might have its own data store of ACRs.
In any case, however its implemented, the data is queried by aid, by oid, and by other classes of object type. Its seems clear that the muscle applet could not satisfy this method: how could it respond to ACR about the applet itself, or other applet instances, given javacard APIs provides no access to such information to a selected applet. It seems likely that a card manager or supporting security domain shall implement this method.
Anyways, its clear there is a well-through discovery process there, related to host->card controls, via ACRs. I'm not sure we have anything so general to offer, in the muscle applet world.
----
5.3.3.4 Get Properties. A related discovery process to Get ACRs, operating more at the level of what applet instances are present, how many. etc. The interesting thing is the property object also stores key information. Who implements this property object is unclear, may be an extended OPEN, or a control applet, or an enhanced registry.
We can presume the property object is responsibly for configuring AO-read, and AO-write keys however. Thus, it is partly responsible for orchestrating the Role based access control model, given its function in managing the keys for roles.
We can note that in Ext-Authenticate using an AO-read key for example, the capabilities are inherently limited to SCP 01 Global Platform Cards. Only C-MAC can be signaled through a suitably masked algid byte. See. 5.3.5.2. Still no clear clue on how to orchestrate R-MAC, in the GSC world.
----
5.3.4 Read/Update buffer.
This maps nicely onto the muscle object manager package. The only real difference is the extra parameters which switches which of two named object get the TLs or the Vs of the TLV stream being stored. In muscle we could presumably add this switch to the methods, and require all object id have the last byte = 0, so the method could read/write the correct one of two files: adding a discriminator in the last byte of the object's oid name, itself.
----- _______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
