Now I understand external authentication, with symmetric keys, we can turn to designing the first of two contemplated changes : (1) require external auth, merely to gain access to a particular cardedge method,
Hi, it seems I'm missing something about your discussion: CardEdge already has an access control model which allows to specify, for each on-board resource (key or object) and for each operation on them, what authentications are needed in order to allow that operation. Authentication methods are PIN code verification and challenge-response cryptographic authentication (symmetric or asymmetric). In ReTiS, we have a third fingerprint-verification mechanism, too. Each operation on each key or object is associated a set of authentication methods which must all have been successfully run in order to allow the operation.
So far, this scheme might be expanded by: 1 increasing the number of operations protected by different Access Control Words on each object (e.g. reducing granularity in AC decisions); any examples on how this might help in increasing application security ? 2 adding alternatives, which are not supported at the moment: if you want a key to be usable by either authenticating in a way, or in another way, then the only possibility (so far) is duplicating the resource and specifying different ACL, but this only works with read-only or use-only resources, and is not so good for applications (there is no means for establishing that two keys are the same key, before using that key).
(2) integrate symmetric-key based ext auth with GP's init_update().
Could you please provide more information on this acronym (GP) you're referring to, here ?
One way to address (1) could be to enable any _method_, that MIGHT be configured to _require_ *prioir* ext auth, to have an additional keyno field, in the method call (and wire format). If said keyno value is not default, the read acl associated with Key[keyno] would be evaluated. Said acl could require that the same key (now as principal) be currently logged in, in order to read the key. The acl for the key would be managed as today. Keys used in this manner (to provide method-level role-based access control) might be specified in the constructor, or in the format command.
Are you proposing here some kind of alternative-based access control ?
Design-stage comments?
I had an lazy/unprofessional notion also - to use the presence of the keyno in the 'other' acl associated with Key[keyno] as a configuration signal - requiring that any method subject to read-time controls now protect the method's results, using said key (using some process).
Hmmm... protecting a method's output. Is this you're talking about ? This would go beyond the CardEdge model, in that you're proposing to give to CardEdge a kind of security-awareness on the data it manages. As far as CardEdge is used just to store application data and crypto keys, the current AC model already makes this, in that it checks the ACL of an object before allowing reading its contents, and it checks a key ACL before allowing to decrypt anything with it. Of course, it is not aware of what is being decrypted or for what purposes. Maybe what you're thinking would be useful if the storage facility of the device were expanded to a more complex one, rather than the simple object-based service we have now.
I thinking also of requiring that the keys in Key[] are ordered - checked with manufacturing/format time controls - with all ext.auth keys being earlier in the array than any type of Key instance.
As said early, I must have lost the point.
My only qualm with these minimialist-style changes is that we are really not upgrading for the entire range of the real problem being addressed : 2 and n-factor authentication requirements, to acess a method (or object). For example, a host driver might be required to complete ext-auth, the CO might be required to bio-authentication, and the user shall be required to present the old pin, during user pin update.
This relates to the "alternatives" issue: so you're supposing these three entities all need to access the same on-card resource, but each one authenticating in a potentially different way. Could you provide a real-life example on how this would help in realizing a secure application/service ?
Bye,
Tommaso.
--
,------------------------------------------------.
| Tommaso Cucinotta <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
