----- Original Message ----- From: "Tommaso Cucinotta" <[EMAIL PROTECTED]>
To: "MUSCLE" <[email protected]>
Sent: Wednesday, March 23, 2005 1:22 PM
Subject: Re: [Muscle] muscle getChallenge, versus GP 2 way authentication
Peter Williams wrote:Role based access control in the FIPS 140-1 sense for cryptomodules exists to allow the module designer to show how only the CO can perform certain management duties, and thus have proper access to caredegd methods. The RBAC is extensible, in that it then also allows other roles, such as Applciation Admin, to perform another set of duties, with associated access rights for another set of available methods. In the windows world, this is just RBAC on access to particular COM interfaces exported by a given class.Given your discussion, what I need to do, I suspect, is invent 3 new inheritance acls, inherit-pin, inherit-key, inherit-object. Their values are initialized in format(). Whenever an authorized principal creates such an object/key/pin, the inherited-acl value is or'ed with the acl supplied by the cardedge method parameter. Thus, at personalization time, one can require mandate that all acls on (all) keys/objects/pins bear one or other ext-auth id#8+n bit.
Ignoring the pin methods, all methods require one to gain permission to access either an object or a key, all of which will now bear the ext-auth requirement, by a card-wide policy setup at personalization time.
I see. So, within the proposed model, once an Applet is instantiated and initialized, every new resource which is created is forced to have a set of minimum prefixed requirements on its new ACL. What about rewriting a resource ? I guess you'll enforce the same mechanism with ACLs specified at time of (e.g.) key-overwrite.
You know, the original model was thought for allowing multiple possibly independent uses of a card device. This new model, instead, ties a card (actually an Applet instance) to a pre-fixed set of authentication methods, so usages outside of the context are not allowed anymore.
If we proceed in the design ork, we we see that perhaps rwo independent design issues are perhaps under discussion:
(A) extending the role-based access control model of the muscle cardedge, so that acls can mandate n-factor logins for all access to a cardedge method. In particular, one can mandate XAUT-grade principal login, and login as different strong id is equivalent to login as a particular role (e.g. CO, AO, etc.)
(B) add biometric user authentication, as substitute for pin-based CHV. In particular, allow an acl to mandate that the CHV uses a particular _strength_ of user authentication.
Lets address only (A) for now, - though clearly the two issues are related in the design of the access control and privilege model. And, lets also add some context, for the muscle cardedge's getChallenge and External Authenticate.
In the GSC-IS document (http://csrc.nist.gov/publications/nistir/nistir-6887.pdf 3.2.2) , the US is advocating that a trusted host driver (probably in the TPM stack) shall be able to learn from the cardedge API (and possibly the card) whether or not XAUT-strength principal login is a necessary pre-condition - for a subsequent call to a given method (aka "service") being granted access permission(s).
"A typical BSI sequence of calls for an External Authentication:
- Establish a logical connection with the card through a call to gscBsiUtilConnect().
- Retrieve the ACRs for a desired card service provider through a call to either gscBsiGcGetContainerProperties() or gscBsiGetCryptoProperties(). These interface methods return the ACRs for all services available from the smart card (Section 4.6.3 or Section 4.7.5 respectively). If External Authentication is required for a particular service (e.g., gscBsiGcReadValue() or gscBsiPkiCompute()), the ACR returned in the GCacr or CRYPTOacr structure for this service must be BSI_ACR_XAUTH.
"
(Other steps in the muscle-style getChallenge and ExternalAuthenticate are then specified.)
We know, in the muscle world, that we can retrieve the (public) acls for each class of resource (object/key) via the cardedge; and that the driver can learn, thereby, which strongly identified principals are required. By implication, this identifies the role the principal (i.e. the driver) shall necessarily perform, when accessing said resource, and the particular XAUT key said party shall necessarily possess.
So, now, should the driver be programmed to always retrieve the acl of a _given muscle object_ when preparing to invoke a given method, the particular object's public acls can be viewed as a surrogate for the method-level requirement specification (the "ACR" in US goverment parlance)
One way to construct such a set of "specification objects" in the muscle world would surely be to have several sets of IN/OUT objects, each with unique acls, where the method checks the acl on the particular IN/OUT set to determine whether requirements for the associated _method_ have been satisfied. Only then would the method be actually implemented, in which the acls of particular resource would also then be enforced.
In this way, we might ensure that the semantics of the GSC-IS are provided for - in which it's the method ("service") -level policy specification that can mandate the requirement for XAUT login - regardless of which application-centered object/key is the subject of the transaction.
If, now, the constructor of the acl always masks the "upon-creation acl mask" for that type of acl into its value, we satisfy two requirements surely:
(a) When the IN/OUT object is allocated for a given method, the method's "upon-creation policy" is assigned - according to personalization time requirements
(b) By inspecting the IN/OUT acls, the driver can learn what credentials it WOULD be required to present, before access would subsequently be granted to that method.
Neither (a) nor (b) are the cleanest way of achieving the goal, but they have minimal impact on the applet source, whilst satisfying most if not all of the need (A).
Peter. _______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
