* 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]
