The Backdoor Fallacy: explaining it slowly for governments

… I literally don’t know a single person with modicum of technical understanding who thinks this is a good idea …

I should probably avoid this one, because a) everyone will be writing about it; and b) it makes me really, really cross; but I just can’t*.  I’m also going to restate the standard disclaimer that the opinions expressed here are mine, and may not represent those of my employer, Red Hat, Inc. (although I hope that they do).

Amber Rudd, UK Home Secretary, has embraced what I’m going to call the Backdoor Fallacy.  This is basically a security-by-obscurity belief that it’s necessary for encryption providers to provide the police and security services with a “hidden” method by which they can read all encrypted communications**.  The Home Secretary’s espousal of this popular position is a predictable reaction to the terrorist attack in London last week, but it won’t help.  I literally don’t know a single person with modicum of technical understanding who thinks this is a good idea.  Or remotely practicable.  Obviously, therefore, I’m not the only person who’s going to writing about this, but I thought it would be an interesting exercise to collect some of the reasons that this is monumentally bad idea in one short article, so let’s examine this fallacy from a few angles.

  • It always fails – because a backdoor isn’t just a backdoor for authorised users: it’s a backdoor for anyone who can find it.  And keeping these sort of things hidden is difficult, because:
    • academic researchers look for them
    • criminals look for them
    • “unfriendly state actors” (governments we don’t like at the moment) look for them
    • previously friendly state actors (governments we used to like, but we don’t like so much anymore) look for them
    • police and security services mess up and leak them by accident
    • insiders within police and security services decide to leak them
    • source code gets leaked, giving clues to how they’re implemented -for those apps which aren’t Open Source in the first place
    • the people writing them don’t always get it right, and you end up with more holes than you expected***
    • techniques that seem safe now often seem laughably insecure in a few years’ time.

There is just no safe way to protect these backdoors.

  • You can’t identify all the providers – today it’s Whatsapp.  And Facebook, and Twitter, and Instagram, and Tumblr, and …  But if I’d asked you for a list a year, or five years ago, what would that list have looked like?  And can you tell me what should be on the list for next week, or next year?  No, you can’t.  And I suspect you (as a learned reader of this blog) are a lot more clued up than the UK Home Office.
  • You can’t convince all the providers – and that’s assuming that all of the providers are interested or can be convinced to care adequately to sign up anyway.
  • You can’t hit all channels – even if you could identify all the providers, what about online gaming?  And email.  And ssh.  I mean, really.
  • The obviousness issue – presumably, in order to make this work, governments need to publish a list of approved applications.  I suspect, just suspect that the sort of bad people who want to get around this will choose to use different apps, or different channels to the approved ones … but so will people who aren’t “bad people”, but just have legitimate reasons for encrypting their communications.
  • The business problem – there are legitimate uses for encryption.  Many, many of them.  And they far outnumber the illegitimate uses.  So, if you’re a government, you have two options:
    1. you can convince all legitimate business, including banks, foreign corporations and human rights organisations and everyone who communicates with them to use your compromised, “backdoor-enhanced”***** encryption scheme.  Good luck with this: it’s not going to work.
    2. you can institute a simple, fast, unabuseable red-tape free process by which you hand out exemptions to “legitimate” businesses who you can trust to use non-compromised, backdoor-unenhanced encryption schemes.******

I’m guessing that we don’t expect either of these to fly.

  • The “nothing to hide” sub-fallacy – “But if you have nothing to hide, then you have nothing to fear” argument.  Well, I may have nothing to hide from the current government.  But what about future governments?  Have the past 100 years of world history taught us nothing?  Hitler, Franco, Stalin, Perón, … the list goes on and on.  From “previously friendly state actors”?  And from the criminals who are the main reason most of us use encryption in the first place?  Puh-lease.
  • The who-do-you-trust question – this leads on from the “police and security services mess up” sub-bullet above.  The fewer people to whom you give the backdoor details, the more hard work and expense there is in using that backdoor for your purposes.  So there’s an obvious move to reduce costs by spreading knowledge of the backdoor.  And governments tend towards any policy which reduces costs, so…  And, of course, the more spread the knowledge, the more likely it is it leak.
  • Once it’s gone, it’s gone – and once it’s leaked, it’s leaked, whether by accident or intention (Chelsea Manning, Julian Assange, Edward Snowden, …).  You can’t put this genie back in the bottle.  The cost and complication of re-keying a communications channel for which the key has leaked is phenomenal.  I’m assuming that this is just a re-keying exercise, but if it’s a recoding exercise, it’s even harder.  And how do you enforce that only the new version is used, anyway?
  • The jurisdiction issue – do all governments agree on the same key?  No?  Well, then I have to have different versions of all apps I might use, and choose the correct one for each country I travel in?  And ensure that neither I nor any businesses ever communicate across jurisdictional boundaries.  Or we could have multiple backdoors, each for a different jurisdiction?  Let’s introduce the phrase “combinatorial explosion” here, shall we?

Let’s work as an industry to disabuse governments of the idea that this is ever a good idea. And we also need to work them to come up with other techniques to help them catch criminals and stop terrorist attacks: let’s do that, too.

*believe me: I tried.  Not that hard, but I tried.

**they probably want all “at-rest” keys as well as all transport keys.  This is even more stupid.

***don’t get me wrong: this is going to happen anyway, but why add to the problem?

****inverted commas for irony, which I hope is obvious by this state in the proceedings

*****”I can’t even”, to borrow from popular parlance.  This is the UK government, after all.

Ignorance as a virtue: being proud to say “I don’t know”

“I am the wisest man alive, for I know one thing, and that is that I know nothing.” Socrates

In order to be considered an expert in any field, you have to spend a lot of time learning things.  In fact, I’d argue that one of the distinguishing traits of someone who is – or could become – an expert is their willingness and enthusiasm to learn, and keep learning.  The ability to communicate that knowledge is another of those traits: you can’t really be an expert if you have no way to communicate that knowledge.  Though that doesn’t mean that you need to be a great speaker, or even a great writer: by “communicate” I’m thinking of something much broader.  In the field of security and IT, that communication may be by architecture diagram, by code writing, by firewall rule instantiation, or by GUI, database or kernel module design, to name just a few examples.  These are all ways by which expertise can be communicated, instantiated or realised: the key is that the knowledge that has been gained is not contained, but can be externalised.

There’s another trait that, for me, betrays a true expert, and that’s the ability to say “I don’t know”.  And it’s difficult.  We enjoy and cultivate our expert status and other’s recognition of it: it’s part of our career progression, and it hits the “esteem” block in Maslow’s Hierarchy of Needs[1].  We like people asking our opinion, and we like being able to enlighten them: we take pride in our expertise, and why wouldn’t we?  We’ve earned it, after all, with all that hard graft and studying.  What’s more, we’ve all seen what happens when people get asked a question to which they don’t know the answer to something – they can become flustered, embarrassed, and they can be labelled stupid.*  Why would we want that for ourselves?

The problem, and very particularly in the security field, is that you’ll always get found out if you fake it.  In my experience, you’ll go into a customer meeting, for instance, and there’s either the sandal-wearing grey-beard, the recently-graduated genius or just the subject matter expert who’s been there for fifteen years and knows this specific topic better than … well, possibly anybody else on the planet, but certainly better than you.  They may not be there in the first meeting, but you can bet your bottom dollar*** that they’ll be in the second meeting, or the third – and you’ll get busted.  And when that happens, everything else you’ve said is called into question.  That may not seem fair, but that’s the way it goes.  Your credibility is dented, possibly irreparably.

The alternative to faking it is to accept that awkward question and simply to say, “I don’t know”.  You may want to give the question a moment’s thought – there have been times when I’ve plunged into an response and then stopped myself to admit that I just can’t give a full or knowledgeable answer, and when I could have saved myself bother by just pausing and considering it for a few seconds.  And you may want to follow up that initial acknowledgement of ignorance by saying that you know somebody else who does (if that happens to be true), or “I can find out” (if you think you can) or even “do you have any experts who might be able to help with that?”

This may not impress people who think you should know, but they’re generally either asking because they don’t (in which case they need a real answer) or because they’re trying to trip you up (in which case you don’t want to oblige them).  But it will impress those who are experts, because they know that nobody knows everything, and it’s much better to have that level of self-awareness than to dig yourself an enormous hole from which it’s difficult to recover.  But they’ll also understand, from your follow-up, that you want to find out: you want to learn.  And that is how one expert recognises another.

* it’s always annoyed me when people mock Donald Rumsfeld for pointing out that there are “unknown unknowns”: it’s probably one of the wisest soundbites in recent history**, for my money.

** and for an equivalently wise soundbite in ancient history, how about “I am the wisest man alive, for I know one thing, and that is that I know nothing”, by Socrates
*** other currencies and systems of exchange are available

Systems security – why it matters

… to understand how things will work together, you have to consider them as a system…

“A system is a set of interacting or interdependent component parts forming a complex or intricate whole.  Every system is delineated by its spatial and temporal boundaries, surrounded and influenced by its environment, described by its structure and purpose and expressed in its functioning.” (Wikipedia: system)

I’ve been involved with various types of security over the years, from features within products to storage, network and other communications security, and including stand-alone application security, cryptographic protocol design and other weird and wonderful issues like why you shouldn’t lose too much weight on holiday.*  That’s a subject for another post.  But what I keep coming back to is systems security.

And that’s because you can design all the security into a particular component that you like, you take as much care in coding it as you like, you can ensure that you compile is safely, you can test it to within an inch of its life, and ensure that it is deployed where and how you like – but if it’s part of a system, and that system has other holes, than you might as well not bother.  We** often talk about “the weakest link in the chain” as a way of pointing out that if you have a single problem in a set of components, that’s what will break.  That’s too simplistic an analogy***, though, as different components interact in different ways with each other, dependent on a variety of factors.

In order to understand how things will work together, you have to consider them as a system, to define what their behaviour as a system will be, and to architect the system with an understanding of the risks, threats and likely attackers that it will have to deal with in its lifetime.

Much of the content this blog may discuss components, but I hope that I’ll manage to explain their place in systems, and how they work together.  Join me: it should be fun****.

*that’s a subject for another post – it’ll be fun

**by which I mean the nebulous “security community”

***don’t start me on analogies

****another disclaimer – I think that security is fun.  Not everybody agrees.  I’m presuming that the fact that you’ve made it this far means that you are at least open to the suggestion.