On Friday 21 September 2007 01:10:38 pm Douglas E. Engert wrote:
> Shawn Willden wrote:
> > In general, though, I think it also doesn't matter that much. Any
> > reasonable secure smart card API (I'm talking about the APDU-level API)
> > must assume that an attacker can get between the card and the reader, or
> > the reader and the application.
>
> Not the ones I have seen. The assumption is the user of the card has
> physical control over the reader, and is using the machine in front of him.
I should also mention that even for user authentication, the protocol must be
designed so that an attacker who has control of the communication channel
between application and card, but doesn't control either end, is unable to
subvert or replay authentications. Of course, such an attacker can deny
service.
So, the key assumptions for authentication are that (1) the authenticating
user controls the card and that (2) the application has some way to assure
that the user at the keyboard is the same as the one with the card.
Requiring that the reader and the UI (screen/keyboard) be the ones connected
to the same physical box is one means of achieving (2), though it's easy to
come up with ways to violate that assurance, unless another authentication
factor is used.
Assuming those two assumptions can be made, remote authentication also doesn't
require encryption or an additional authentication layer.
Shawn.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
