Hardware Security: Why Fixing Meltdown & Spectre Is So Tough

The security world has been rocked by Meltdown and Spectre, two critical hardware security exploits affecting every device from smartphones to desktops to cloud servers. One lesson to learn here is that hardware security alone is not a panacea.

Memory isolation is arguably the most important security feature in modern computer architecture. For example, a malware-infested game should not be able to get access to your banking app's login and password. These exploits demonstrate that isolation is now fundamentally broken.

Meltdown and Spectre did not come out of thin air. They are based on a long line of research on micro-architectural attacks that have been going on for over 15 years. There have been dozens of researchers doing work in this space that have led to this result. But, unless you were a part of that community, or paying very close attention, you probably had no idea that something like this was even possible.

How do these attacks work? Modern CPUs are designed to run faster using a technique called speculative execution. In this technique, the CPU looks a few steps ahead to predict what memory it might need to access and grabs that memory ahead of time, so that it is ready to go when a downstream instruction finally executes. Meltdown and Spectre effectively allow one program to read the contents of another program's memory.

The problem is that the only direct fix for these vulnerabilities is replacing the CPU. Not only would that be exorbitantly expensive, but almost every modern CPU has this flaw, so it's not even a viable option. We may have to wait for completely redesigned CPU architectures before we have systems fundamentally secure against Meltdown and Spectre.

The good news is that there is a workaround to patch the operating system to compensate for this hardware vulnerability, but don't breathe a sigh of relief quite yet. First, it's been reported that these workarounds can result in as much as a 30% impact on performance depending on the program. Second, this affects pretty much every computer and many smartphones and tablets out there, so companies are scrambling to understand their risk exposure, which of their systems are most vulnerable, and how to feasibly deploy patches in any reasonable amount of time.

The Case for Software Security
Most of us take for granted that the safest design principle is to put the most important security functionality under the control of hardware. This includes relying on the OS kernel to be isolated from user programs, relying on hardware roots of trust to bootstrap the security of your system, or pushing cryptographic keys into hardware, where they are hidden from normal programs.

What Meltdown and Spectre have shown us is that hardware-based security is no panacea. Hardware is vulnerable. It can fail. And when it does, the results are ugly and painful.

But then, you might ask, what is the option? Do everything in software? Isn't software fundamentally easy to break? The answer is that everything is relative.

While attacking software does not require as much effort, it is certainly not an easy task either. It's hard enough for a hacker to understand well-documented and designed software, much less software with sophisticated anti-reverse engineering and tamper resistance shields. It can still take thousands of hours to find exploitable software vulnerabilities in such programs, even by the most talented hackers.

Hardware-based security and software-based security sit on two ends of a spectrum. On one end, hardware-based security, is very difficult to break, but once broken, it is catastrophically difficult to fix. On the other end, software-based security, is easier to break, but also much easier to fix.

Not a Binary Choice
This makes for an interesting choice. Is it better to deal with software patches on a regular basis, or put all your chips on hardware and hope there won't be an expensive catastrophic incident down the road? In the case of Meltdown/Spectre, the solution was to roll out a software fix to a hardware failure. In some sense, we are lucky that that option was available.

The choice need not be binary. From a risk management perspective, software security can be an effective hedge against hardware security failures to cushion disasters like Meltdown and Spectre. This is just another way of applying the age-old security maxim of defense in depth.

Consider the issue of protecting cryptographic keys. The hardware solution is to put keys in secure elements, Trusted Platform Modules or Trusted Execution Environments. We've already seen that this kind of hardware can be hacked. An alternative software solution is white-box cryptography, which protects sensitive cryptographic keys by mathematically embedding them within the implementations. Even if a hacker gets to access the code during execution, security properties of white-box cryptography ensure that the keys will still be hidden from the hacker. While it is possible to attack these techniques, it is difficult to achieve. Attackers have had to resort to sophisticated side-channel attacks to be successful. But the security industry has responded with successful countermeasures to defeat these attacks.  

The last thing we want in the security world is to come across a devastating bug and only have partial solutions with potentially substantial performance costs. We need to stop thinking about hardware security as completely impenetrable. Decision makers should seriously consider using software security mechanisms to hedge against catastrophic hardware failures.

Related Content: