Peter Williams wrote:
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.

I guess you'll have to embed some tricks at instantiation time for
allowing creation of the additional "indherited" authentication methods
(e.g. you'll have to specify PIN parameters, or key blobs, or key
parameters at instantiation time so that, after format, the card may
enforce the new policy).

(1) I have to implement these inherited acls. Perhaps these are better known as the "default" or "upon-creation" acls, whose top 8 bits are masked with the acl supplied by the user consuming the createPin, createKey, createObject methods

Why are you tied to the top 8 bits of the ACL ? There is no reason, to me, for limiting such a mechanism to allow only ExtAuth inheritance. Just allow PIN inheritance, Bio inheritance, User-defined inheritance as well. Is there ?

(2) I need to add an acl type, add a fourth default "upon-creation" value for all pin acls, and add an associated acl check to the unblockPin() method, so the access control model can also control access to this method.

PINs have no associated ACLs, so far (only an ACW for creation, which is global for all PINs). So you're proposing an unblock ACW, what else ?

GP = Global Platform, by the way. i.e. ISO 71816 secure messaging functions for TPDU transfer. using the GP-specified scheme of wrapping elements of the the TPDUs' commands and/or responses, in various types of security envelope(s).

Did you develop a secure messaging extension in CardEdge ?

        T.

--
,----------------------------------------------------.
|  Tommaso Cucinotta PhD <t.cucinotta >at< sssup.it> |
>----------------------------------------------------<
!       Scuola Superiore di Studi Universitari       !
!              e Perfezionamento S.Anna              !
!    Pisa                                   Italy    !
`----------------------------------------------------'
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle

Reply via email to