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