Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

1/26/2018
10:30 AM
Bill Horne
Bill Horne
Commentary
Connect Directly
LinkedIn
RSS
E-Mail vvv
100%
0%

Hardware Security: Why Fixing Meltdown & Spectre Is So Tough

Hardware-based security is very difficult to break but, once broken, catastrophically difficult to fix. Software-based security is easier to break but also much easier to fix. Now what?

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:

Bill Horne leads Intertrust's Secure Systems group. He has authored over 50 peer-reviewed publications in the areas of security and machine learning, and holds 33 granted patents and 44 patents pending. Horne holds a B.S. in electrical engineering from the University of ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/2/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9498
PUBLISHED: 2020-07-02
Apache Guacamole 1.1.0 and older may mishandle pointers involved inprocessing data received via RDP static virtual channels. If a userconnects to a malicious or compromised RDP server, a series ofspecially-crafted PDUs could result in memory corruption, possiblyallowing arbitrary code to be executed...
CVE-2020-3282
PUBLISHED: 2020-07-02
A vulnerability in the web-based management interface of Cisco Unified Communications Manager, Cisco Unified Communications Manager Session Management Edition, Cisco Unified Communications Manager IM & Presence Service, and Cisco Unity Connection could allow an unauthenticated, remote attack...
CVE-2020-5909
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, when users run the command displayed in NGINX Controller user interface (UI) to fetch the agent installer, the server TLS certificate is not verified.
CVE-2020-5910
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the Neural Autonomic Transport System (NATS) messaging services in use by the NGINX Controller do not require any form of authentication, so any successful connection would be authorized.
CVE-2020-5911
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the NGINX Controller installer starts the download of Kubernetes packages from an HTTP URL On Debian/Ubuntu system.