On 11/08/2009 02:07 AM, John Levine wrote:
At a meeting a few weeks ago I was talking to a guy from BITS, the
e-commerce part of the Financial Services Roundtable, about the way
that malware infected PCs break all banks' fancy multi-password logins
since no matter how complex the login process, a botted PC can wait
until you login, then send fake transactions during your legitimate
session. This is apparently a big problem in Europe.
I told him about an approach to use a security dongle that puts the
display and confirmation outside the range of the malware, and
although I thought it was fairly obvious, he'd apparently never heard
it before. When I said I'd been thinking about it for a while, he
asked if I could write it up so we could discuss it further.
So before I send it off, if people have a moment could you look at it
and tell me if I'm missing something egregiously obvious? Tnx.
I've made it an entry in my blog at
http://weblog.johnlevine.com/Money/securetrans.html
Ignore the 2008 date, a temporary fake to keep it from showing up on
the home page and RSS feed.
R's,
John
deja vu 1999 .... this should be covered in enormous detail in the EU finread
standards documents from the late 90s.
note that the EU finread standard from late 90s (over decade ago) was
countermeasure to most every kind of PC compromise that you can think of.
Basically it moved the end point out to independent hardware device with its
own display and pin-pad. The transaction was still composed on the PC ... but
had to be sent to the hardware finread device for approval/authentication.
transaction to be approved/executed would be displayed on finread device for
approval. It then required physical PIN entry to execute the approval process
... typically assumed to be a digital signature ... which was returned to the
PC.
compromised PC could still do a denial of service ... but the independent finread
device effectively moved the end-point from the PC out to the finread. the
independent display & pin-pad ... was countermeasures to various kinds of
exploits ... including
* keylogging ... trojan horse or other could execute transactions w/o users
actual knowledge
* is the transaction that the user sees the actual transaction being executed
bad design might have used the finread for session authentication in lieu of
separately authentication/approval for every transaction (which would allow
trojans on compromised pcs to execute fraudulent transactions within the
boundaries of the session.
infrastructure would still be vulnerable to various kinds of social engineering
... convincing end-user to execute valid transactions for the benefit of the
attacker.
There was some conjecture (again more than decade ago) that if finread
deployment eliminated all the other kinds of compromises ... that user
education programs could purely concentrate on social engineering exploits
(sort of like the stuff for little kids to have nothing to do with strangers).
EU finread program got caught up in the disastrous deployment of serial-port
card acceptor device at the start of the decade (many versions had the
appearance of card acceptor device with its own independent display and pin-pad
... slightly akin to small POS terminals that might appear at point-of-sale).
The disastrous serial-port acceptor device deployment resulted in rapidly
spreading opinion in the financial industry that smartcards and card readers
weren't practical in the consumer market ... resulting in nearly all such
programs quickly evaporating w/o hardly a trace.
As i've mentioned before ... it wasn't actually a problem with smartcards
and/or card readers .... but with the serial-port interface. In the 1995
time-frame there were a number of presentations about moving the dial-up home
banking programs to the internet ... in large part motivated by the significant
customer support costs associated with supporting serial-port modems (one such
bank program claimed to have a library of over 60 serial port modem software
drivers to try and cover some reasonable set of their customers. Problems with
the whole serial-port gorp was also big motivator behind development of USB.
In any case, i've commented before about the financial industry institutional
knowledge and experience apparently rapidly evaporated between the migration of
dial-up home banking (migration to the internet) and 2000. A partial/possible
explanation might be that the vendor, knowing that everything was moving to
USB, saw a really great chance to unload their stock of obsolete serial-port
devices on a client that didn't really know what they were doing.
lots of past EU finread standard posts:
http://www.garlic.com/~lynn/subintegrity.html#finread
random trivia ... i was at an eu finread standard meeting in brussels not long
before the whole thing with serial-port resulted in all such programs imploding
(even those not using serial-port ... radiation from the event seemed to catch
everything)
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
