Wednesday, September 05, 2012

Encryption Is Not the Answer to Security Problems

I just read Cyber Fail: Why can't the government keep hackers out? Because the public is afraid of letting it, an article in the new Foreign Policy National Security channel. I've Tweeted on Mr Arquilla's articles before, but this new one published today offers a solution to security problems that just won't work.

Consider these excerpts:

Back in President Bill Clinton's first term, the "clipper chip" concept was all about improving the security of private communications. Americans were to enjoy the routine ability to send strongly encoded messages to each other that criminals and snoops would not be able to hack, making cyberspace a lot safer.

I see two errors in this section. First, having lived through that time, and having read Steven Levy's excellent book Crypto: How the Code Rebels Beat the Government Saving Privacy in the Digital Age, I disagree with Mr Arquilla's statement. The Clipper Chip was the government's last attempt to keep tight control of encryption, not "improve the security of private communications."

Second, Mr Arquilla implies that encryption = "making cyberspace a lot safer." That fallacy appears later in the article.

Sadly, industry leaders have never emphasized the value of strong crypto sufficiently either. There are many reasons for this neglect -- the most likely being that encouraging ubiquitous use of strong crypto could weaken sales of the firewalls and anti-viral products that form so much of the cybersecurity business model.

Here is my key issue with this article. An enterprise could encrypt every single piece of information at rest or in transit, and intruders would still win.

The fundamental reality of cryptography in the enterprise is that users and applications must be able to access data in unencrypted form in order to use it.

In other words, if a user can access data, so can an intruder.

Cryptography certainly frustrates some bad guys, such as amateurs who eavesdrop on encrypted communications, or thieves who swipe mobile devices, or intruders who remove encrypted files without bothering to obtain the material necessary to decrypt it.

However, cryptography will not stop your Web app from suffering SQL injection, nor will it keep Java from being exploited by a client-side attack.

The article concludes in part by saying:

But ways ahead do exist. There is a regulatory role: to mandate better security from the chip-level out -- something that Sen. Joseph Lieberman's Cybersecurity Act would only have made voluntary.

This sounds like an advertisement for a chip maker. I've heard their lobbyists use the same terms on Capitol Hill. "Mandating security" at the "chip level" would be as effective as FISMA -- a waste of time.

Mr Arquilla does make a few points I agree with, such as:

[W]e should treat cybersecurity as a foreign-policy issue, not just a domestic one. For if countries, and even some networks, can find a way to agree to norms that discourage cyberwar-making against civilian infrastructure -- much as the many countries that can make chemical and biological weapons have signed conventions against doing so -- then it is just possible that the brave new virtual world will be a little less conflict prone.

However, do not be fooled into thinking that encryption is the answer to our security problems.

6 comments:

Brad Cox said...

Why not shed some light by not focusing so tightly on encryption. Yes, encryption only provides confidentiality, a small part of the problem. There's also integrity (hashing), non-repudiation (signing), and others, which are all part of the cryptographic toolkit. Most web security projects don't even require encryption, counting on TLS (SSL; HTTPS) to do that.

Mark_eSecurity said...

While I agree that encryption might not prevent a web app from suffering SQL injection it *CAN* significantly reduce the impact of a SQL injection attack. For example sensitive and rarely accessed columns can be encrypted with only the minimum of applications having access to use well managed decryption keys. Then there's the potential to sign columns to simplify the identification of any malicious database updates. Encryption can be deployed at different points of risk including storage and network but ultimately the broadest coverage is afforded where encryption is implemented at the application layer so data is only exposed in plaintext form on a "need to process" basis.

David Mytton said...

Encryption helps at different levels. Transport encryption (i.e. SSL/HTTPS) secures the communication from the user to the service and protects against things like session hijacking. Encryption of stored data is at the opposite end of this and helps in the event of the database content being stolen or as Mark eSecurity mentioned, if data is accidentally exposed through the web UI.

Of course, the encryption isn't a silver bullet on it's own - you have to design it's usage correctly. For example it can protect a database if the data files are stolen but not if the keys are stored alongside the data!

Branden Spikes said...

Encryption is valuable, but focusing on it is putting the cart before the horse. Most encryption is useless when you've got a botnet or hacker infecting your personal computer, keylogging and seeing anything they want before its even encrypted. Our browsers and emails need immunity from zero-days. Let's kick hackers off our computers, then security gets far more interesting.

Jeff Reava said...

Not to pile on, but there are problems with the economic logic too: "encouraging ubiquitous use of strong crypto could weaken sales of the firewalls and anti-viral products..." Given the 'defense in depth' mantra of our industry, who would recommend substituting layers of security? If anything, the argument (if it made sense) would be to do all of the above.

It seems that for all that is written on Cybersecurity, we've made very little progress helping non-professionals understand the cause-and-effect model of what attackers do and why they're successful.

The belief that "encryption = security" rests on the assumption that attackers are obliged to 'follow the rules' and attack only where we've put our defenses.

But reality is "if a user can access data, so can an intruder" and they will invent/discover unexpected ways to do it.

We need to keep advancing a nontechnical set of simple concepts that describe the form these attacks take.

Gunnar said...

"If you think cryptography is the solution to your problem, then you don't understand cryptography and you don't understand your problem" - Roger Needham and Butler Lampson