Re: Optimisation Considered Harmful
| A brief altercation this evening with CERT over the recent hyperthread caching | issues has brought something that's been simmering at the back of my brain to | the forefront. | | The recent hyperthread/cache key recovery trick, followed by DJB's related | (IMO) symmetric key recovery, and preceded by the RSA timing attacks (Boneh et | al?) are all examples of attacks on the same thing: optimisation. | | The problem is that if different paths through your code expose different | availability of optimisation, then there's a timing attack available. I | predict, for example, that someone will find a way to attack something using | pipeline breaks on Pentium processors[1]. | | How do we fix this? Well, its easy to say: we make everything equally crap - | we make sure that all operations are as slow as the slowest possible variant | can be. However, on a modern processor, this is _very_ hard to do. | | Could it be that for safe crypto we should be using Z80s? This is an excellent point, as it reveals a deep and significant parallel between cryptography and compiler/hardware optimization. Consider what it means to create an optimizing compiler (or some kind of opti- mization in hardware - the issues are the same, but I'll talk in terms of a compiler for definiteness.) The input is source code; the output is a bunch of instructions. A compiler's transformation is correct if it's semantics- preserving: The source has some meaning, and the object code correctly represents that meaning. There are an infinite number of possible object codes that preserve the input semantics. Some are better than others with respect to some objective function, say size or speed. An optimizing compiler simply chooses a better object code than some reference choice. The big issue in compiler optimization - and even more so in some hardware optimization - is defining exactly what semantics has to be preserved. For example, must computations be done even if the compiler can determine that they cannot affect the output? Can the rules of algebra be used to rearrange expressions (possibly breaking carefully crafted error management strategies, since floating point arithmetic doesn't actually obey the rules of algebra)? Do writes to two variables written in order in the source code have to occur in that order in the object code? If two writes are issued in order to the hardware, do they have to hit memory in that order? An understanding of what semantics has to be preserved, and what semantics is side-effect and can be tossed to gain performance, has gradually emerged in the hardware and software communities. There have been, and continue to be, missteps along the way. Some of the weaker memory consistency models might have helped the hardware guys, but were just too hard for the software guys to deal with. Newbies to multi-threaded programming are caught by the not-so- obvious memory access semantics present even at the language level in all common programming languages. (Java tried to pin this down exactly and got it completely wrong for several tries.) Enter cryptographic algorithms. On their face, these are simple mathematical transformations. You have to really abuse the implementations (e.g., having multiple side-effect-producing operations in one statement) to get into area where a programmer or hardware developer's warning bell would sound watch the semantics. And, in fact, from the point of view of input/output transforma- tions, there really are no semantic issues. The problem is that these side- channel attacks broaden the meaning of the program to something that has never been considered in previous work that I know of. (The closest you are likely to find is in complaints by real-time programmers that modern machines give you no way to determine how long an instruction sequence will really take: You might take a page fault, or a cache miss, or who knows what along the way, and in some real-time code, you have to *know* that that won't happen. Such code really is sometimes run only on machines like Z80's! What can be done? Well, the first thing that's clearly needed is a more complete specification of the semantics of cryptographic algorithms. Just the input/output transformation - which is all we write down in most analyses - is insufficient. We sometimes state things informally, almost in passing - as in the comments on AES that table accesses take constant time. We certainly assume things like the time to add two numbers is independent of the number of carries - which is probably true on machines today, but may actually have been false at one time. Without a way to write down what matters, we have no way to judge whether a particular compilation/hardware approach is safe. There's some work on abstract program interpretation that might help here (though it's mainly aimed in other directions). Ultimately, performance is likely to suffer. Software and hardware optimiza- tions are
Rephrased: Should login pages be protected by SSL - although it won'thelp most users?
Ole Kasper Olsen wrote: ... Amir Herzberg asked the question of should login pages be SSL encrypted. The flurry of discussion can be summerized as Yes... ... 2. Most people believe that a login page *should* be encrypted for web sites carrying important data. (e.g., financial, etc.) And many such sites are not protected, see `Hall of Shame` (link below) Encryption is not the point. Authentication is. A login page will never contain sensitive data anyway and as long as the form is submitted to a secure server, the data is encrypted just fine. A problem arises when a customer is tricked into entering credentials at an a bogus site. Absolutely. SSL/TLS has decent capability for providing authentication, however the sad truth is (as Michael Silk noted) that a vast majority of surfers do not understand nor read certificates. People don't even look at the URL (many (probably very successful) scams just rely on a semi-decent-looking link which points to an IP address). This is correct, given the current security indicators in browsers; I even have some empirical data to support this (but it is also common sense). However, the use of SSL may help _some_ users: -- The few users who carefully check the URL, padlock, certificate -- Users who install browsers/extensions providing improved security/identification indicators such as our TrustBar People in favor of unprotected login pages (mostly people in charge of them?) claim that both users groups above are negligible and do not justify using SSL. I disagree; for example, TrustBar is available thru multiple sites, and I have statistics only from http://addons.mozilla.org, and there I have over 25000 downloads. BTW this site also allows user feedback, which you are encouraged to leave, I read it carefully and I believe our next release will in fact take care of almost all concerns raised by users. And of course there are other improved security indicators solutions such as Netcraft, TrustToolBar (although I don't like their privacy invasion and overhead). This situation is also not helping convince browser folks to add the improved security UI to the browser (so I can get rid of developing TrustBar... have some other research projects to take care of!) -- Best regards, Amir Herzberg Associate Professor Department of Computer Science Bar Ilan University http://AmirHerzberg.com Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Some companies are just asking for it.
My girlfriend just got an (apparently legitimate from what I can tell) HTML email from her credit card company, complete with lots of lovely images and an exhortation to sign up for their new secure online ShopSafe service that apparently generates one time credit card numbers on the fly. Here's the text: Your account has a free benefit that is better than ever! Shop online as you normally would, but with the comfort of knowing that nobody knows your account number. ShopSafeSM protects your real account number by generating a substitute account number. Use ShopSafe just like a regular card for your online purchases. It's free, easy and convenient. Get the security and comfort that comes with knowing every purchase you make is protected. The sales pitch then invites you to click on the link in the email to join. Ironclad credit card purchase protection is right here. Log in to IBS Net Access to make your next purchase a safer one. Clicking on the link, of course, asks you to enter information that you should never, ever, EVER enter after clicking on a link you got in email. So, here is official mail from a credit card company, actively training its users to become future victims of phishing. The irony of being exhorted to do this in the name of getting the ShopSafe service is not a small one, either. I wouldn't be surprised if near identical emails with the exact same pitch started showing up within hours or days, only the site they link to may be a wee bit less benevolent. The security department and management at the firm responsible should be taken out behind the shed and put out down, before they hurt anyone else. The marketing department will, of course, demand to do stupid things, but it is the responsibility of the security department and management to tell them No, we will not train our users to be raped by phishers, no matter how many `click throughs' it generates. Oh, and what companies are involved? The card is Fidelity branded, but it is really an MBNA production, with online marketing and card servicing (like this piece) being done by Individualized BankCard Services. One would think that everyone in question would know better, but sadly they don't. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: massive data theft at MasterCard processor
-- On 22 Jun 2005 at 8:39, Anne Lynn Wheeler wrote: the dual-use attack ... is possibly a person-centric digitally signing token (in contrast to institutional-centric token where each institution might issue a unique token for every use) ... that can be registered for use in multiple places and applications. one of the digial signing scenarios is pure authentication where the server sends out some random data which the end-user signs (effectively a variation on challenge/response as countermeasure against replay attacks). Rather the server should send out some encrypted random data which the end user decrypts. End user should then prove knowledge of that encrypted data. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG mvLPUs8OZQJeGGYzUgIlJCvGBKsPF9FUruhnF3tE 4Krdy9r1LLw/aZSGjrIDNHXOcHkloS7F9MGLCTB6o - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Some companies are just asking for it.
My girlfriend just got an (apparently legitimate from what I can tell) HTML email from her credit card company, complete with lots of lovely images and an exhortation to sign up for their new secure online ShopSafe service that apparently generates one time credit card numbers on the fly. Shopsafe is rather nice. I use it all the time, and it's written in flash which works on my FreeBSD laptop. On the other hand, MBNA's mail practices would be laughable if they weren't entirely in line with every other bank in the country. If you read Dave Farber's IP list, a couple of days ago Bob Frankston sent in an alarmed note saying that some info from his Bank of America account had apparently been stolen and used in a phish, and I wrote to tell him that no, the mail was real, from the service bureau they use which has a name nobody outside the banking industry knows. Aaron Emigh of Radix Labs wrote to tell me about a talk he gave earlier this year at an Anti-Phishing Working Group earlier this year on this topic, which starts with a set of examples of real bank mail each of which looks phishier than the last. This is 30MB due to the voiceover, but if you have a fast web connection, it's worth running. It needs Powerpoint: http://www.radixlabs.com/idtheft/aaron-emigh-education.pps Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I dropped the toothpaste, said Tom, crestfallenly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Some companies are just asking for it.
John Levine [EMAIL PROTECTED] writes: On the other hand, MBNA's mail practices would be laughable if they weren't entirely in line with every other bank in the country. The fact that others do laughable things doesn't make their practices any less laughable. Stupid things remain stupid no matter how widespread the stupidity might be. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Some companies are just asking for it.
John Levine wrote: My girlfriend just got an (apparently legitimate from what I can tell) HTML email from her credit card company, complete with lots of lovely images and an exhortation to sign up for their new secure online ShopSafe service that apparently generates one time credit card numbers on the fly. John, I have some serious samples of Consumer Mis-education as it's been dubbed - I actually provided some of the samples in Aaron's report. Side note, not only are the emails confusing, but every email that I get from a consumer, so far I've gotten (the american express in the powerpoint especially is really screwed) ebay, amex, bank of america all had major vulnerabilities that allow cross-user attacks within them. Not only that, to add to his report, with cross-user attacks (I'm probably preaching to the choir but, it's still interesting) you can foil SSL connections with the lock by using what I call a Mixed-SSL attack, where you have multiple frame control with your valid certs, but the domain url is https://www.americanexpress.com. This in essence only indicates one SSL cert, that being the banks site that you have injected code into and by walking the DOM you essentially use your certs to maintain the secure frame objects. (For a demo of this contact me offline). There was a point - oh yes, with the emails - in most of these cases, there can be what I call a bulk mail replay attack. Assume a phisher has a BofA account, and receives the bulk mailings of the legitimate Financial Institution (FI). This is a safe assumption because in the past we have seen a phisher utilize a real BofA email and just replaced the links with poisoned links that used BofA's site to phish the user. So with some timing, a replay attack can be organized - since we establish that say BofA has some vulnerabilities in XSS (This is just an example, no offense to BofA), the phisher can wait for a commerical legitimate marketing campaign and then mix in his poisoned mass mailing within the same time frame as these are going out. This will not only confuse the customer, but when reported may get underestimated because the FI did in fact send out a mass-mail to their customers*. The poisoned URL with the real domain and real (SSL-MIX) lock at the bottom of the screen belonging to Bank of America (even though the phisher took over the site) could potentially increase ROI by inducing misplaced trust or cause severe lack of confidence within the already troubling concept of online banking. -Lance *Ironically, i did find a vulnerability previously in a certain FI mass mailing campaign that allowed me to arbitrarily subscribe anyone's email address to their campaign list and control settings for whether they get the Solicited Commercial Email. This adds to the effect since phishers can subscribe anyone, not just their customers. Shopsafe is rather nice. I use it all the time, and it's written in flash which works on my FreeBSD laptop. On the other hand, MBNA's mail practices would be laughable if they weren't entirely in line with every other bank in the country. If you read Dave Farber's IP list, a couple of days ago Bob Frankston sent in an alarmed note saying that some info from his Bank of America account had apparently been stolen and used in a phish, and I wrote to tell him that no, the mail was real, from the service bureau they use which has a name nobody outside the banking industry knows. Aaron Emigh of Radix Labs wrote to tell me about a talk he gave earlier this year at an Anti-Phishing Working Group earlier this year on this topic, which starts with a set of examples of real bank mail each of which looks phishier than the last. This is 30MB due to the voiceover, but if you have a fast web connection, it's worth running. It needs Powerpoint: http://www.radixlabs.com/idtheft/aaron-emigh-education.pps Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor I dropped the toothpaste, said Tom, crestfallenly. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://www.securescience.net/amazon/ Find out how malware is affecting your company: Get a DIA account today! https://slam.securescience.com/signup.cgi - it's free! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
