* Anne & Lynn Wheeler:

> Florian Weimer wrote:
>> If you've deployed two-factor authentication (like German banks did in
>> the late 80s/early 90s), the relevant attacks do involve compromised
>> customer PCs. 8-( Just because you can't solve it with your technology
>> doesn't mean you can pretend the attacks don't happen.
> EU finread terminal was countermeasure to (widely held impression
> that) PCs are extremely vulnerable to compromise.

You say that as if that assumption were unrealistic.
Transaction-rewriting malware is out in the wild. 8-(

FINREAD is really interesting.  I've finally managed to browse the
specs, and it looks as if this platform can be used to build something
that is secure against compromised hosts.  However, I fear that the
support costs are too high, and that's why it hasn't caught on in
retail online banking.

> card authentication required pin entry to work ... and finread
> terminal had its own PIN-pad distinct the vulnerable PC
> keyboard. orientation was towards transaction authentication ... with
> the finread terminal also having its own display of what was being
> authentication.

The interesting part is that it's possible to create an application
that runs exclusively on the trustworthy component and presents the
actual transaction data to the user before it is signed.

Previous card readers/smart card combinations relied on host software
to provide the display contents, without any way to check that it
matches the blob that was to be signed.  Of course, it's still
possible to develop a FINREAD application that behaves that way,
perhaps in order to cut down development costs.  As usual, just
because it's FINREAD, it's not automatically secure (and a
"transparent mode" exists as well).

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to