Shawn Willden wrote:
I need the card to be restricted to a user, not an application. It
seems to me that the same scenario will arise with pretty much any
multi-application card.
As we were reminded by a man from CESG [1] at a conference that I
attended last week, the card doesn't identify anyone: it is the binding
between card holder and card that does that as long as the interaction
between card and system is also strong. Thus you need a method to create
a persistent authenticated state for the card holder (could be PIN,
physical biometric, etc, to establish it, but how do you make it
persist?) in order to do what you want to do, an authenticated state
that the remote server (and I think in some of your cases the PC, but
beware: its not secure so it has to be protected) are forced to respect.
This is where thinking is moving at last towards having not a simple
card reader but a low cost secure sub-terminal (looks like a PIN pad,
but needs to be more secure than that) and somewhat different algorithms
in the card - see FINREAD [2], talk to the Wave Systems people, maybe
even talk to GlobalPlatform people (their new Technical Director was not
very positive in his presentation last week but better one on one). If a
transaction needs to be secure it has to be authorised by the card, and
that may mean getting the sub-terminal to ask the card holder if the
transaction can go ahead.
Peter
[2] UK electronic security service for the civil (i.e. visible) part of
govt ICT
[2] But don't be fooled by FINREAD's complexity (reject all the stuff
about downloadable updates and just look at the basic concept of a
router: system can only talk to card; card talks to system and
sub-terminal peripherals (I/O devices)).
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
