Re: TLS break
On Sun, Nov 08, 2009 at 01:08:54PM -0500, Perry E. Metzger wrote: I'll point out that in the midst of several current discussions, the news of the TLS protocol bug has gone almost unnoticed, even though it is by far the most interesting news of recent months. Not entirely unnoticed: http://www.porcupine.org/postfix-mirror/wip.html#tls-renegotiation For HTTPS, it has been observed that this is not entirely different from existing CSRF attacks, but it should be noted that with the new attack, checking Referrer headers is no longer effective, so anti-CSRF defenses have to be more sophisticated (they *should* of course be more sophisticated, but they rarely are, if they are present at all). I am looking forward to analyses for other protocols. There is almost certainly a problem for FTP (over TLS), where just banning re-negotiation on the server is perhaps reasonable. -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
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
Re: Crypto dongles to secure online transactions
Jerry Leichter wrote: On Nov 8, 2009, at 2: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. Wow. *That's* scary. http://www.zurich.ibm.com/ztic/ IBM Zone Trusted Information Channel (ZTIC) A multi line display and two buttons (approve/disapprove) http://www.zurich.ibm.com/pdf/csc/ZTIC-Trust-2008-final.pdf More and more attacks to online banking applications target the user's home PC, changing what is displayed to the user, while logging and altering key strokes. ... In order to foil these threats, IBM has introduced the Zone Trusted Information Channel (ZTIC), a hardware device that can counter these attacks in an easy-to-use way. The ZTIC is a USB-attached device containing a display and minimal I/O capabilities that runs the full TLS/SSL protocol, thus entirely bypassing the PC's software for all security functionality. The ZTIC achieves this by registering itself as a USB Mass Storage Device (thus requiring no driver installation) and starting a pass-through proxy configured to connect with pre-configured (banking) Websites. After starting the ZTIC proxy, the user opens a Web browser to establish a connection with the bank's Website via the ZTIC. From that moment on, all data transmitted between browser and server pass through the ZTIC; the SSL session is protected by keys maintained only on the ZTIC and, hence, is inaccessible to malware on the PC (see usage and technical operation animations, which illustrate how the ZTIC works). ... -- There's a video clip. http://www.youtube.com/watch?v=mPZrkeHMDJ8 (HD and low res) It puts the onus on the user for approval of malware driven transactions. http://www.zurich.ibm.com/ztic/operation.html (animated illustration) Our Land Transport New Zealand agency (www.ltsa.govt.nz, like the DMV) uses POLi for making on line transactions. Apparently POLi uses the very same techniques to provide transaction confirmation to a third party, as are used by malware to interject data into transactions or steal information. There should be no reason a ZTIC like device couldn't be used to provide authentication to a third party as well, the idea being your car license renewal etc. transaction isn't confirmed until the bank completes the payment transaction. Browsers compartmentalizing connections in the equivalent of sandboxes like as done by Chrome would while defending against malware attacks make POLi impossible without something like ZTIC. POLi currently has other dependencies on Windows. It strikes me as insecure today, using the same features exploited by malware. http://www.centricom.com/ (POLi, centricom used to do routers and the like) The POLi service now operates in three countries around the world: Australia, New Zealand and the UK. You'd think the solution would be cost sensitive. Internet banking is big here too. As is phone banking and cell phone message based transactions. You have to subscribe (thankfully). We get our share of fake ATM fronts and the like. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Crypto dongles to secure online transactions
On Nov 8, 2009, at 7:45 PM, Thorsten Holz wrote: ...There are several approaches to stop (or at least make it more difficult) this attack vector. A prototype of a system that implements the techniques described in your blog posting was presented by IBM Zurich about a year ago, see http://www-03.ibm.com/press/us/en/pressrelease/25828.wss for details. Bring two threads together: The ZTIC is designed to work with unmodified servers, hence implements SSL/TLS internally. Could the recently discovered SSL injection attack be used against it? (I haven't thought it through and have no idea.) Whether or not it can, it demonstrates the hazards of freezing implementations of crypto protocols into ROM: Imagine a world in which there are a couple of hundred million ZTIC's or similar devices fielded - and a significant vulnerability is found in the protocol they speak. (Since we're talking about a *protocol* vulnerability, having multiple competing implementations doesn't help.) Now, you could make the same argument about the encryption mechanisms - AES, RSA, whatever else is frozen in that silicon - as well. We're reasonably sure of our ability to build strong block and public key ciphers - there have been no significant (publicly known!) breaks in any fielded system in years. The problems with hash functions show that our abilities there aren't as good as we thought. But this recent attack against SSL/TLS, studied by so many people for so many years, should make us really humble about the state of the art in secure protocol development. Not that this should block the use of devices like the ZTIC! They're still much more secure than the alternatives. But it's important to keep in mind the vulnerabilities we engineer *into* systems at the same time we engineer others *out*. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Secret Lock Detecting Lock
On Nov 9, 2009, at 9:25 AM, mhey...@gmail.com mhey...@gmail.com wrote: From http://www.youtube.com/watch?v=zE5PGeh2K9k Unlock your door with a secret knock. Prior to watching the video I said to myself, Great, now I can break into most of the homes on my block with 'Shave and a haircut, 2 bits'. And you thought password creativity was poor... -wps - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: TLS break
Perry E. Metzger wrote: I'll point out that in the midst of several current discussions, the news of the TLS protocol bug has gone almost unnoticed, even though it is by far the most interesting news of recent months. Perhaps because there have been so many false alarms over the years. Usually when I hear about an SSL MITM attack, it's really a browser UI spoofing attack with a bogus cert. This is the first attack against TLS that I consider to be the real deal. To really fix it is going to require a change to all affected clients and servers. Fortunately, Eric Rescorla has a protocol extension that appears to do the job. -- Give a man a fire and he's warm for a day, but set | Tom Weinstein him on fire and he's warm for the rest of his life.| twei...@pacbell.net - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
