I’ve been meaning to summon the energy to write about OAuth WRAP. It’s hard to do, because like OpenID, OAuth WRAP is just so obviously a bad idea, it’s difficult to know where to start. So I was pleased to see that Ben Adida saved me the trouble.

I understand. Security is hard. Getting those timestamps and nonces right, making sure you’ve got the right HMAC algorithm… it’s non-trivial, and it slows down development. But those things are there for a reason. The timestamp and nonce prevent replay attacks. The signature prevents repurposing the request for something else entirely. That we would introduce a token-as-password web security protocol in 2010 is somewhat mind-boggling.

Exactly. The idea that security protocols should be so simple than anyone can implement them is attractive, but as we’ve seen, wrong. But does the difficulty of implementing them mean they can’t be used? Of course not – SSL is fantastically hard to implement. But it is also fantastically widely deployed. Why? Because there are several open source libraries that do everything for you. Likewise every crypto algorithm under the sun is hard to implement, but there’s no shortage of libraries for them, either.

Clearly the way forward for OAuth is not to dumb it down to the point where any moron can implement it, the way forward is to write libraries that implement a properly secure version, and have everyone use them.

If the amount of effort that has been wasted on OAuth WRAP (and OpenID) had instead been put instead into writing code for the various platforms then we would probably now have pretty much universal support for OAuth and no-one would be whining that it’s too hard to implement.

Instead, we will spend the next decade or two clearing up the mess that we seem to be intent on creating. It makes me tired.

Share This

A while back, I had a bash at formal methods. Reasonably enough, some people had a bash back. I feel I should respond.

Michael asked “what about Tokeneer?”

The description on that page makes some great points for me. Firstly, and I think most importantly

At each stage in the process verification activities were undertaken to ensure that no errors had been introduced. These activities included review and semi-formal verification techniques applicable to the entities being developed.

In other words: “we can’t actually apply formal methods to the entire process, so we did some ad hoc stuff, too”. Core to this problem is that you have to somehow describe what it is you are trying to do. In order to disguise the problem, formal methods folk like to call this a specification – but when you get down to it, it’s a program. Which can have bugs in it. Which you can only diagnose by thinking about it and testing.

Next, from the overview, section 5

Since release 7.4, SPARK has included an “accept” annotation that can be used to justify expected warnings and errors. These annotations have been added as appropriate.

In other words, verification fails, but these failures are “justified”. Hmmm.

Again from the overview (section 5.3) even after formal verification a bug was found, which was an elementary integer overflow bug. I would hope any competent programmer would have spotted this as they were writing the code, but apparently it was beyond all this expensive and painful infrastructure.

Finally (there’s more, but I have other things to write about, so I’ll stop here), again from the summary

# lines of code: 9939
# total effort (days): 260

Wow. That’s a lot of days for not very much code.

Toby asked “how would you feel about a proposal that asked for a range of standard software modules whose design had been subjected to formal analysis, at some semi-useful and reasonable level of abstraction, of some of its key functional/security properties?”

I guess I feel about this rather as Gandhi felt about Western civilisation: it would be a good idea.

More positively, I imagine there are actually some modules that are sufficiently small in scope that one could convince oneself that the specification was actually correct, and maybe even prove that the implementation matched the specification. For example, things like arrays, sets and maps might be implementable correctly. Where it all falls apart, in my view, is when you try to make a system that actually does something useful: then you get into the realm where debugging the specification is the hard problem.

Ian Brown asked “do you think a formally verified microkernel that enforces security controls within an OS is achievable/desirable?”

I think this actually might be achievable, and perhaps even desirable. But I’m not so sure it would be truly useful. A microkernel architecture inherently punts on all the interesting security questions and simply enforces whatever incorrect decisions you have made outside the kernel. So, you are still left with all the real-world security problems, but at least you have a place to stand when you claim you are enforcing whatever security properties you think your code implements (that is, you can discount the microkernel as a source of problems and only have to worry about the other 99% of the code).

I also strongly suspect that a team of skilled engineers could carefully write a secure microkernel that was just as robust without any need for formal verification. More quickly and with less swearing.

Finally, Anil Madhavapeddy writes “Modern type systems spring from a solid formal footing, and mainstream languages are adopting functional features”.

This is a great point, and I actually agree. I’m a big fan of type safety, as anyone who’s seen some of the hoops I jumped through in both the Apache module system and more recently in OpenSSL will know. I really like things to break at compile-time rather than run-time if at all possible, and type safety is one way to achieve this (this is one reason I prefer C++ to C, despite its many defects). I guess functional languages also have interesting properties from that point of view but I feel like I understand them less. I really must learn Erlang (or Haskell, I suppose, but I’ve tried and failed a few times already – it seems there are no good tutorials out there).

Anil also says “Even for C, static analysis is increasingly used to track down bugs (with products like Coverity which are very effective these days)”.

Sorry, but no. I thought for quite a while that there was a future in static analysis. But the more I am exposed to it, the less I think it is true. The false positive rate is still fantastically high, even in Coverity, which is probably the best system I’ve played with, and even correct hits tend to be on the “academically correct but not actually useful” side.

I do continue to suspect that static analysis combined with annotation might be useful, though (e.g. as in Deputy). But really, this is just trying to bolt on strong typing to weakly typed languages and isn’t truly static analysis is we hoped it might be.

Finally, he says “If things continue like they have been, then we’ll continue to cherry pick the practical developments from the formal methods community into mainstream languages, and reap the benefits.”

I certainly hope so, and I don’t want to discourage further research into formal methods. I just object to the notion that they are practical to the extent that we should be trying to use them wholesale to build real systems. They really aren’t.

I was intending to also talk a bit about things I think actually are useful for security, but I think I’ll leave that for a later post.

Share This

I know this is ancient history now, but I was busy, OK?

A while back, Schneier said something that really annoyed me

Commenting on Google’s claim that Chrome was designed to be virus-free, I said:

Bruce Schneier, the chief security technology officer at BT, scoffed at Google’s promise. “It’s an idiotic claim,” Schneier wrote in an e-mail. “It was mathematically proved decades ago that it is impossible — not an engineering impossibility, not technologically impossible, but the 2+2=3 kind of impossible — to create an operating system that is immune to viruses.”

What I was referring to, although I couldn’t think of his name at the time, was Fred Cohen’s 1986 Ph.D. thesis where he proved that it was impossible to create a virus-checking program that was perfect. That is, it is always possible to write a virus that any virus-checking program will not detect.

Now, if what you’re interested in is PR, then it seems you can get away with these kinds of statements; certainly I have not seen a single public challenge. But if you care about rigour, you have to do rather better, since Schneier’s claim is demonstrably wrong. Why? Well, here goes … Cohen’s proof relies on computer science’s only trick: diagonalisation[1]. Basically, I assume that I have some perfect virus detector, V. If I give V a program, p, it returns true or false, depending on whether p is a virus or not. Let’s be charitable and assume that we can define what a virus is well enough to allow such a program to exist. Let’s also define what is meant by “perfect” – by that we mean that any program that exhibits virus behaviour will be classified as a virus and any that does not will be classified as not a virus.

Then Cohen says: fine, write a program, c like this:

if(V(c))
  do_nothing();
else
  be_evil();

Now, if V(c) returns true (i.e. c is a virus), then c does nothing, and therefore V is wrong. Similarly, if it returns false, then c behaves evilly, and once more V is wrong. QED, no perfect virus checker is possible. So far, we are in agreement.

Can we go from this to “it is always possible to write a virus that any virus-checking program will not detect”. No, because the proof only talks about perfect virus-checking programs. If the virus checker is allowed to be wrong sometimes, then the proof no longer works. In particular, if the virus checker can return false positives (i.e. claim that innocent programs are viruses) but is not allowed to return false negatives, then we can, indeed, have a virus checker that would keep our system free of viruses. Why? Because the virus checker will always detect a virus, by definition, but the diagonalisation proof no longer works – in particular, the case where V(c) is true no longer leads to a contradiction.

If we want to go a little further and show that such a program can, in fact, exist, we can actually do that quite easily. For example, consider the program V that always returns true: this would prevent any programs at all from running, so our OS wouldn’t be all that useful, but it would be virus-free. Less frivolously, we could have a list of non-virus programs, and V could return false for any program in the list and true for all others. Even less frivolously, it is possible to imagine an analysis that’s thorough enough for some restricted set of cases to permit reasonably general programs to pass the test without allowing any viruses (obviously we would also disallow many perfectly innocent programs, too), but at this point we’d have to define “virus” to drill down into what that analysis might be – but it could, for example, require that the program be written in some restricted, easily-analyzed language, and avoid constructs that are hard to deal with.

So, sorrry, Schneier. It has not been shown that it is impossible, in the 2 + 2 = 3 sense, to write a virus-free OS. Indeed, it has been shown that it is, in fact, possible – though I would certainly agree that it is an open question how hard it would be to create an OS that’s both useful and virus-free.

[1] Don’t get me wrong; it’s a good trick.

Share This

The W3C recently announced their spec for signing widgets. Signing things is a good idea, if you’d like to be assured that they come from where you think they come from, or you want to detect tampering. But I would have hoped we were way past statements like this

Widget authors and distributors can digitally sign widgets as a trust and quality assurance mechanism.

If trust and quality were assured by signatures then our lives would be so much easier – but sadly it is not so. Indeed, it is so much not so that CAs, in an amazing piece of marketing, have managed to persuade us that, since they work so poorly for trust, what we should do is pay them even more money to get more robust signatures (a.k.a. EV certificates)!

Anyway, I was sufficiently irritated by this stupidity that I felt it necessary to remark on it. Which prompted this absolutely brilliant response from my friend Peter Gutmann

From the report:

Of signed detected files, severity of the threats tended to be high or severe, with low and moderate threats comprising a much smaller number of files:

Severe 50819
High 73677
Moderate 42308
Low 1099

So there you go, signing definitely does provide a “trust and quality assurance mechanism”. If it’s a CA-certified signed rootkit or worm, you know you’ve been infected by the good stuff.

“the report”, by the way, is a large scale study by Microsoft which makes for some interesting reading. In particular, they also acknowledge that even the promise that signatures would at least let you track down the evil bastard that wrote the code has proven empty

Though also intended to identify the signing parties, Microsoft has been unable to identify any authors of signed malware in cooperation with CAs because the malware authors exploit gaps in issuing practices and obtain certificates with fraudulent identities.

Share This

Not content with destroying the world’s economies, the banking industry is also bent on ruining us individually, it seems. Take a look at Verified By Visa. Allegedly this protects cardholders – by training them to expect a process in which there’s absolutely no way to know whether you are being phished or not. Even more astonishing is that this is seen as a benefit!

Frame inline displays the VbV authentication page in
the merchant’s main window with the merchant’s
header. Therefore, VbV is seen as a natural part of the
purchase process. It is recommended that the top
frame include the merchant’s standard branding in a
short and concise manner and keep the cardholder
within the same look and feel of the checkout process.

Or, in other words

Please ensure that there is absolutely no way for your customer to know whether we are showing the form or you are. In fact, please train your customer to give their “Verified by Visa” password to anyone who asks for it.

Craziness. But it gets better – obviously not everyone is pre-enrolled in this stupid scheme, so they also allow for enrolment using the same inline flow. Now the phishers have the opportunity to also get information that will allow them to identify themselves to the bank as you. Yes, Visa have provided a very nicely tailored and packaged identity theft scheme. But, best of all, rather like Chip and PIN, they push all blame for their failures on to the customer

Verified by Visa helps protect you from fraudulent claims from cardholders – that they didn’t take part in, or authorise, a payment. Once you are up and running with Verified by Visa, you are no longer liable for chargebacks of this nature.

In other words, if the phisher uses your Verified by Visa password, then it’s going to be your fault – obviously the only way they could know it is if you told them! If you claim it was not you, then you are guilty of fraud; it says so, right there.

Share This

The New York Times have an article about the Stanford Clean Slate project. It concludes

Proving identity is likely to remain remarkably difficult in a world where it is trivial to take over someone’s computer from half a world away and operate it as your own. As long as that remains true, building a completely trustable system will remain virtually impossible.

As far as I can tell, Clean Slate itself doesn’t make this stupid claim, the NYT decided to add it for themselves. But why do they think identification is relevant? Possibly because we are surrounded by the same spurious claim. For example…

• We need ID cards because they will prevent terrorism.
• We shouldn’t run software on our Windows box that isn’t signed because that’ll prevent malware.
• We should only connect to web servers that have certificates from well-known CAs because only they can be trusted.

But…

• The guys who crashed the planes were all carrying ID. Didn’t help.
• The guys who blew up the train in Spain were all carrying ID. Didn’t help.
• People get hacked via their browser all the time. Did signing it help?
• What does it take to sign code? A certificate, issued by a CA…
• What does it take to get a certificate? Not much … proof that you own a domain, in fact. So, I can trust the server because the guy that owns it can afford to pay Joker $10? And I can trust the code he signed? Why?

Nope. Security is not about knowing who gave you the code that ate your lunch – security is about having a system that is robust against code that you don’t trust. The identity of the author of that code should be irrelevant.

Share This

From time to time I bemoan the fact that much of good practice in cryptography is craft knowledge that is not written down anywhere, so it was with interest that I read a post by Michael Roe about hidden assumptions in crypto. Of particular interest is this

When we specify abstract protocols, it’s generally understood that the concrete encoding that gets signed or MAC’d contains enough information to unambigously identify the field boundaries: it contains length fields, a closing XML tag, or whatever. A signed message {Payee, Amount} K_A should not allow a payment of $3 to Bob12 to be mutated by the attacker into a payment of $23 to Bob1. But ISO 9798 (and a bunch of others) don’t say that. There’s nothing that says a conforming implementation can’t send the length field without authentication.

No of course, an implementor probably wouldn’t do that. But they might.

Actually, in my extensive experience of reviewing security-critical code, this particular error is extremely common. Why does Michael assume that they probably wouldn’t? Because he is steeped in the craft knowledge around crypto. But most developers aren’t. Most developers don’t even have the right mindset for secure coding, let alone correct cryptographic coding. So, why on Earth do we expect them to follow our unwritten rules, many of which are far from obvious even if you understand the crypto?

Share This

I just accidentally went through the whole booking process on United’s US site. There were many seats in Economy Plus. But I couldn’t book because I don’t have a US address. So, I went through it all again on the UK site. Guess what? Economy Plus is allegedly booked solid. Bastards.

Share This

I started looking at the LLVM project today, which is a replacement for the widely used gcc compiler for C and C++. My interest in this was prompted by thinking once more about static analysis, which it is pretty much impossible to use gcc for, and is likely to remain so, because Stallman opposes features which would enable it.

Anyway, being an optimist, I thought perhaps the interest in LLVM and clang (the C/C++ front end) were prompted by a sudden surge of interest in open source static analysis, but asking around, it seems it is not so.

The primary motivator appears to be GPLv3. Why? Well, here’s a few facts.

• GPLv3 is not compatible with GPLv2. Don’t take my word for it, believe Richard.
• Linux is, of course, famously GPLv2 without the upgrade clause, and hence GPLv3 incompatible.
• FreeBSD, for example, are unlikely to accept software into the core that is GPLv3. No new licence can be used without core team approval and I am told this has not been given for GPLv3 and is not likely to be.
• Commercial users of open source have always been a bit twitchy about GPLv2, but they’re very twitchy indeed about GPLv3. And don’t tell me commercial users are not important: these days they are the ones financing the development of open source software.

GCC is, apparently, going to move to GPLv3 – it says here that GCC 4.2.1 would be the last version released under GPLv2 (which is a bit rum, because I just checked GCC 4.4 and it is GPLv2. What gives?).

So, pretty clearly, there’s a need for a C/C++ compiler that is not GPLv3, and this, it would seem, is the real driver for LLVM.

Obviously this issue is not confined to GCC. As more software moves to GPLv3, what will the outcome be? Will the friction between GPL and other licences finally start persuading projects that free != GPL, and that BSD-style licences better suit their needs? Or will it just be that GPLv3 fails to make headway? We can only hope for the former outcome.

Share This

Late last year the Google Security Team found a bug in OpenSSL that’s been there, well, forever. That is, nearly 10 years in OpenSSL and, I should think, for as long as SSLeay existed, too. This bug means that anyone can trivially fake DSA and ECDSA signatures, which is pretty damn serious. What’s even worse, numerous other packages copied (or independently invented) the same bug.

I’m not sure what to say about this, except to reiterate that it seems people just aren’t very good at writing or reviewing security-sensitive code. It seems to me that we need better static analysis tools to catch this kind of obvious error – and so I should bemoan, once more, that there’s really no-one working seriously on static analysis in the open source world, which is a great shame. I’ve even offered to pay real money to anyone (credible) that wants to work in this area, and still, nothing. The closed source tools aren’t that great, either – OpenSSL is using Coverity’s free-for-open-source service, and it gets a lot of false positives. And didn’t find this rather obvious (and, obviously staticly analysable) bug.

Oh, I should also say that we (that is, the OpenSSL Team) worked with oCERT for the first time on coordinating a response with other affected packages. It was a very easy and pleasant experience, I recommend them highly.

Share This

I’m in two minds whether to even talk about this, but I guess it’ll be all over the ‘net soon.

A rather lovely attack on X.509 certificates exploiting the weakness of MD5 was released today. Read the (very well written) paper for all the gory details, but the short version is you construct a pair of certificates with colliding MD5 hashes. One of these you send off to get signed, and the other you carefully arrange to have the “CA” bit set. This means the second certificate can now be used to sign any other certificate: in effect you have become a CA, using what is known as a chained CA certificate.

So why are they morons? Because they chose to 0day this attack. Why? Users could have been protected from this exploit quite easily – only browsers and CAs had to be notified, which is easily achievable without premature public disclosure. I have no idea why they chose not to do this, but they’ve certainly destroyed any trust I had in them – which is a shame, at least some of them were people I respected.

Ironically, their attack is rendered somewhat pointless right now, as it has been recently shown that Comodo will issue a certificate for any website to anyone at all, without verification.

Share This

Paul Madsen wants to continue to beat this dead horse. OK.

unphishable : impossible to phish, see phish.
.
.
phish: a fraudulent attempt to acquire sensitive information such as usernames, passwords, and credit card details by masquerading as a trustworthy entity in an electronic communication

…

This more inclusive definition does not guarantee (for some mechanisms, this would be the case) that there will be nothing on the authentication server that could be used by a insider to impersonate the user elsewhere. And so, this type of unphishable does not inevitably mean that it is appropriate to use the same credential everywhere.

It seems the plan here is to define certain ways of stealing your password as something other than phishing, and because I want to defend against them, I am therefore wrong. What a pointless argument!

OK, let’s call them unstealable instead of unphishable. Happy now?

Share This

Don’t worry, if we put all our data into central government databases, it’ll all be fine. Except when it isn’t. Our esteemed Prime Minister says

“It is important to recognise we cannot promise that every single item of information will always be safe because mistakes are made by human beings. Mistakes are made in the transportation, if you like in the communication, of information.”

in the aftermath of yet another ridiculous data breach: this time, people’s passwords to the Government Gateway on a memory stick dropped in the road.

Perhaps it is uncouth to point this out, but … if the system had been designed by people with any security clue whatsoever there would have been no passwords to put on a memory stick in the first place.

I notice that Gordon thinks the contractors in this case (Atos Origin) are responsible and action should be taken against them (though how he squares this with his statement that such events are inevitable only a politician can tell you). Well, sure. But why is he not taking action against the morons that designed and approved a system that made it possible for Atos Origin to have the passwords in the first place?

My theory? Policy makers think that it is beneath them to actually understand the technologies they make policy about, or to consult anyone who does. So, it has not occurred to Brown or any of his advisers that this is actually an avoidable error.

Share This

Unless you are Red Hat, the answer is: about as much as eating lunch has to do with business models.

Whatever business you are in, you need your lunch, or you’re going to die. Likewise, but perhaps not quite so urgently, you need software. Open source is about getting the software you want for the minimum investment. It is cheaper and more efficient for those who need particular functionality to group together and provide it for themselves than it is to pay five different companies to not quite provide it in five different ways.

That’s all there is. End of.

So, when you read something like this: “Report: Pure Open Source No Longer a Viable Business Model”, what you are supposed to do is hit the keyboard violently and scream, “It never was, you morons! Get with the program!”

Selling support for software is a business model. Whether it is open source or not. That’s the business Red Hat is in. Not the “open source business”. There isn’t one.

Share This

In their latest attempt to answer the question “how can we get everyone with a domain name to pay for it again?” ICANN are apparently enthused about this stupid idea.

But wait … I have it … why don’t we create a TLD for every service? We obviously need .www, .smtp, .dhcp and so forth, or how will people know what service you are offering?

Share This

Back when I used to serve on Nominet’s Policy Advisory Board, I used to find myself regularly arguing against the creation of new subdomains under .uk. Why? Because the only point I can actually see for creating a new subdomain is so that the registrars can make a huge pile of money while everyone scrambles to register in the new domain in order to protect their brand names.

Does anyone else benefit in any way? No. The registrants do not benefit: they already had domain names, they didn’t need any more. The public do not benefit: one domain name is quite sufficient for any Internet service.

So, given the complete pointlessness of doing this, I am not in the slightest surprised to hear that that most pointless of organisations, ICANN, has decided to allow approximately a zillion new TLDs.

In their usual egotistical style, they bill this piece of stupidity as…

Biggest Expansion to Internet in Forty Years Approved for Implementation

The only thing this expands is the wallets of registrars and, presumably, ICANN’s coffers. The Internet itself is not expanded one iota by this dumb move.

I guess the interesting thing to watch here is who manages to figure out the best TLDs to persuade people they need to register to protect themselves. “.trademark” sounds promising to me. “.name” would also be good. I invite your suggestions – perhaps we should form a consortium to register them, too.

Think I can get .ben? That would be cool.

Share This

… and they won’t take sensible security decisions, so we have to dumb everything down for them. Or at least, that’s what we whine. So, I have to ask, WTF is this all about?

How is anyone supposed to figure out what to do now? Surely we know which of those three errors it was? So why are we giving the user such appallingly crap feeback?

And I can totally imagine how the conversation with Majestic’s webmaster is going to go…

Me: Hey, I got this error. Apparently you’re either using a CA that’s not in a list I’m not going to give to you, or you screwed up your server config so your certificate is incomplete, or you are a phisher and I’ve just given you my password, or you aren’t a phisher but your cert and website don’t match. Please fix it.

Webmaster: O RLY? Well, I’ve got this email that says your wine order is either in the post, not in the post, cancelled or coming to me instead. Laugh it up, big boy.

Share This

I’m having a bit of a run-in with TomTom at the moment. The details are boring, but the short version is I bought a second device, for the car, registered it at their site, and as a result de-registered my existing GPS and associated the add-ons I’d bought for it with the new one. This would be OK except that they are now refusing to let me change it back!

If I want to escalate my complaint about this, here’s what I have to do. What you have to love about this is

TomTom wants to do the following:

• Make it easy for you to raise your feedback

…

If you are not satisfied with any aspect of our service or products, tell us about your concerns by writing us a letter.

Our address is:

TomTom Sales BV
Customer Support – Customer Relations Department
Rembrandtplein 35
1017 CT Amsterdam
The Netherlands

Isn’t that awesome? We want to make it easy, so schlep down to your post office and figure out international postage – that’s so much better than this new-fangled email thing.

Of course, they don’t really want to make it easy – then they might have to investigate some minor complaints, and that would be a waste of their fine minds. They want me to be seriously pissed off before I bother them. And I am, but, thanks to the blogosphere, I can take my complaint to the people that matter: their customers.

Share This

EU Justice and Security Commissioner Franco Frattini joins the ranks of the terminally deluded

I do intend to carry out a clear exploring exercise with the private sector … on how it is possible to use technology to prevent people from using or searching dangerous words like bomb, kill, genocide or terrorism

Do you, indeed? Of course, this is going to make a huge difference: Hitler would never have killed all those Jews if we’d managed to stop him Googling for “genocide”, after all, so I can totally see your reasoning here.

I really like that he wants to stop us even using these words. When will they be struck out of dictionaries? And all the books they appear in?

Hmm, if we can’t say “genocide” does that mean that we’ll all be forced to deny the Holocaust? Isn’t that actually a crime in some EU countries?

Share This

OpenSSL fixed yet another side-channel attack recently. For those of you not in the know, a side-channel attack is one where process A figures out some aspect of what process B is doing by observing some change in the behaviour of process A. A trivial example of this would be to guess whether process B is running or idle by checking what percentage of the CPU process A is getting.

More advanced versions exploit various tricks CPUs to make things go faster, such as caches and branch prediction. Somewhat surprisingly, these attacks can provide enough information to leak information like RSA keys. This, of course, causes people who are trying to make a name for themselves to get quite excited – if they can claim to be able to steal secret keys, then that is news.

However, this all seems rather silly to me. In order to mount most of these attacks the attacker must be local – that is, they have to be able to run code on the same machine as the machine using the secret key. Now, every good security person knows that if your attacker has the ability to run stuff on your machine, it is game over, so why are we even caring about these attacks? This is security theatre of exactly the type that we geeks like to accuse the TSA of on a regular basis – isn’t it time we started making fun of ourselves, too?

Why don’t we? Presumably for exactly the reasons that governments like security theatre. Its good for business. We make people feel loved and protected. We keep people like CERT in jobs. Security companies can issue updates to products. Staff can spend lots of lovely overtime hours doing QA for the emergency rollout of a security update. The economy benefits!

Isn’t it time we stopped fixing these attacks? It isn’t as if the fixes come for free – they almost always make the crypto slower. And, as I said above, until we have platforms that are actually robust in the face of hostile users that can run code on them, there is absolutely no point in avoiding these attacks.

By the way, OpenSSL is far from being the only crypto library that’s vulnerable to this attack, but the advisory will only be about OpenSSL. Why? Diminishing returns, that’s why – OpenSSL is the most widely used crypto library. Once you’ve broken that, the theatrical value of the others is minimal, so why bother? Because you care about security, you say? I rest my case.

Share This