So the cutest demo Ive seen with GP technology - on your/CESG's
characterization of the core issue - is this:
user uses cap-sensor finger reader on card, to bind human to card.
Controlling Authority of a given GP security domain downloads parameters to
the security domain, each augmentment critical info with several https URL
links, and the control info allow local reliance on said server's https
cert.
User logs into website, doing e-e auth using GP securitiy domain keying,
based on SCP-0205. User arms/authorized card to engagned in particular URL
link (i.e. do https, afterwards) using buttons/leds on card; Seucrity Domain
controls whether PC capi can verify particular http's site cert (or use CAPI
for card-enhanced client auth) based on button (aka/ URL) status. Card
display show one-time code, synced with website logon page.
All pretty complex (and just a demo...), but exploiting trusted UI/user-auth
on the card, bascially, versus any new protocols. Just an application
context, bundling several enforcing protocols.
From: Peter Tomlinson <[EMAIL PROTECTED]>
Reply-To: MUSCLE <[email protected]>
To: MUSCLE <[email protected]>
Subject: Re: [Muscle] SCARD_SCOPE_USER [ Was Restricting reader/card
accessby user account]
Date: Mon, 27 Mar 2006 15:55:33 +0100
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
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
