Crypto dongles to secure online transactions

Anne & Lynn Wheeler lynn at garlic.com
Mon Nov 9 22:01:06 EST 2009


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 majordomo at metzdowd.com



More information about the cryptography mailing list