The State of Cryptography in 2014, Part 2: Hardware, Black Swans, and What To Do Now
We continue our look into the state of cryptography in 2014; Part 1 was posted earlier this week.
Is Hardware Security Any Better?
We closed the first post by asking: is hardware any more trustworthy? One would think that it is… but it’s not. Recently, chip vendors have been incorporating cryptography into their CPUs or chipsets. Usually, this is an implementation of a “standard” cipher (like AES) or a pseudorandom number generator (PRNG).
Despite all the revelations from Edward Snowden about the NSA subverting various cryptographic algorithms (in particular, the Dual_EC_DRBG PRNG that NIST published in 2006), we think that AES does not have any backdoors or exploitable flaws. However, what if AES was compromised? Now you have encryption hardware that can’t be used. If the raw implementation turns out to be faulty, it can’t be fixed but some libraries will use it anyway because it’s there.
Whether a given algorithm is flawed or badly implemented is besides the point, however. If it’s baked in hardware, it can’t be fixed or disabled after the fact. Intel, AMD and ARM (and probably others) implemented the entire AES algorithm as a discrete instruction. Wouldn’t it have been wiser to implement common cryptographic primitives that could be used to implement any algorithm of choice, with each primitive being thoroughly tested? Food for thought.
This isn’t a theoretical problem anymore. FreeBSD, OpenBSD’s cousin project, has decided that the pseudo-random number generators in Intel and VIA chipsets cannot be trusted, and are not using them without other augmentation. Whether their doubts are founded isn’t clear, but this should be a wake-up call to scrutinize hardware more thoroughly.
Another way that hardware gives you deceptive cryptographic security is in key and algorithm secrecy. The GSM consortium thought it could keep the A5/1 and A5/2 algorithms secret by implementing in licensed chips. (A5/1 and A5/2 are algorithms used to encrypt voice traffic in GSM celleular networks.)
In 1994, a researcher showed that reversing chips wasn’t all that difficult. In 2003, the algorithms were found to be faulty (and note that A5/2 was, by design, weaker than A5/1.)
Meanwhile, hackers have made it a hobby to extract keys from firmware that was not designed to be read from outside and have made chip reversing a sport. It’s pretty ugly out there.
If you consider intelligence agencies to be your adversary, then even the rumors that don’t involve weakening cryptography will worry you. The fact that they collect immense amounts of data, seem to have unheard-of levels of computational power, and employ much of the cryptographic brain power is, frankly, scary. There is a good chance that, given enough reason to do so, they can break most of the commonly used cryptography we currently use. Here, the best defense is to keep evolving; keep getting better at it.
Even if you are not worried (or just resigned) to threats from such well-funded adversaries, there is another worry: Quantum computing, should it ever grow out of the lab, is capable of performing all of the computation needed to break most cryptography at once. This is not an incremental change. This is the Black Swan of computer security. Luckily, the current crop of adiabatic quantum computers that can be bought are both very expensive and not proper quantum computers. So, these are not a threat. Yet.
But – won’t quantum cryptography come to the rescue? Perhaps. It’s more limited in scope than traditional cryptography, so it wont replace everything, but it might add a few new features. It’s also closer to being real. In the early 2000s, researchers in Switzerland set up a fiber optic link between Geneva and Lausanne and carried out a successful quantum key distribution (QKD). There are still many problems with the technology, but it seems closer to the horizon.
This shouldn’t distract us from smaller Black Swans that can appear any time in the form of faults in commonly used algorithms or their implementations. Such events will happen – when you least expect them.
We rely on cryptography for our privacy and integrity in nearly everything we do nowadays. There is no boundary between the Internet and our everyday lives any more and the only thing keeping us safe is often some cryptographic protocol or algorithm. However, we need to stop thinking of cryptography as a product that you drop in and – presto! – I’m secure. It’s a process that doesn’t stop. We constantly need to be vigilant and be prepared to replace outdated, insecure algorithms and protocols at a moment’s notice. This may entail migrating data from one cipher to another and updating a large number of keys.
It’s not easy and mistakes will be made, but perhaps the most positive aspect of Heartbleed is that most of the most prominent websites were able to update within a very short time. For many of us, our Web experience was only insecure for a relatively short period of time.
However, many sites and services in the long tail of the Internet are still vulnerable. This shows that not everyone has good security practices in place. Worse yet, the devices that surround us often incorporate the same sorts of technologies. Who is keeping the Internet of Everything updated? Is there even a processes for it? Will hackers be able to turn my home against me by abusing some vulnerability in one of my devices just because the vendor doesn’t care or doesn’t know how to fix it?
Most cryptography is sound, in principle, and in this moment. However, the threats to it evolve, and so does cryptography itself evolve in response. The users of cryptography must continuously adapt.