Ofttimes it has been difficult to explain the role of software protection in hardware-protected secure systems, but recently security researchers have helped us out by providing many examples of zero-day exploits where flaws that are baked into hardware or firmware lead to exploitable vulnerabilities in systems. These flaws bypass all perimeter security and/or defeat hardware mechanisms for security, leaving unprotected software at the mercy of the hacker.
In the last year we’ve seen respected, massively deployed protocols and systems fall: GSoap, WiFi WPA Handshake hacks, and BlueTooth compromised by BlueBorne, to name a few. The latest and perhaps most pervasive of all are the Spectre and Meltdown vulnerabilities that affect a wide variety of high performance processors from multiple vendors.
Let’s look at Spectre & Meltdown in some detail and explore how and why software protection could have defused the situation…
Meltdown & Spectre — Speculative Execution Hacks
There has been much written about Meltdown & Spectre. For this post I’ve relied upon an excellent article by Jim Turley, analyst extraordinaire, titled: “Hardware Bugs Afflict Nearly All CPUs”.
All high-performance processors (for twenty years or more) have speculative execution and memory caching. Speculative execution will cause memory to be accessed and cached, even if the memory is in a protected space.
Meltdown (Intel CPUs only, so far) relies upon speculative execution after an exception to access protected memory with a second part that it uses to extract the contents of the memory in a subtle and convoluted way.
Spectre (Intel, AMD and some ARM chips) works similarly but uses a deliberate mispredicted branch instead of an exception, and is harder to patch.
Turley points out: “Both are really more like a new and unusual communications channel between privileged and nonprivileged memory spaces that can be used to sidestep hardware security. They’re subtle and tricky to exploit, but the vulnerability is also very widespread.”
Bottom-line: whatever is stored in memory could potentially be exposed… code, keys and data.
For more technical details on these exploits, including links to the original research papers, I can also recommend the wikipedia entry.
Disclosure of widespread vulnerability is always accompanied by hyperbole, especially in the mainstream media, but somewhat justified in this case.
Since it is a hardware problem, there will not be a hardware fix until the processors have been redesigned, so software patches will need to be applied. For compute intensive tasks there will be a performance impact of a few percent, dependent on the specifics of the chip, OS and memory, but less than initially predicted (20 to 30%). Antivirus programs, for example, won’t be very effective against this since the exploit just relies on normal-looking code.
With respect to Spectre, the Graz University Team writes: “As it is not easy to fix, it will haunt us for quite some time.”
With the architectural features of deep pipelines, speculative execution, and complicated memory caching pervasive in the industry, multiple chipset and operating system vendors are left scrambling to put patches in place before useful exploits are developed.
Software Protection Buys Developers Time
Software protection, selectively applied, will protect code, keys and data against these and other attacks yet to be discovered. Software Protection has the added advantage that it only needs to be applied to items that need protection and doesn’t have a general impact on overall system performance like the system-wide patches for Spectre and Meltdown will have.
The Moral of the Story
We have to face the facts:
- Complicated systems, both hardware and software, will have bugs lurking… sometimes for decades
- Hardware security is a single point of failure that should not be solely relied upon for securing critical assets like code, keys and private data
- Hardware cannot be patched or renewed (generally speaking, FPGA not withstanding) so a complementary software strategy for security is also required
With the above in mind, we can see that software protection could provide fallback protection with renewability and diversity to maintain and improve system security over the product life cycle, even in the face of hardware vulnerabilities.
In fact, system architects and developers should assume that systems will be breached and adopt a dynamic defense structure that continuously changes the security profile. At Irdeto we have a defense model that is used internally and is reflected in even our high-level security products like Secure Environment:
- Prevent Static and Dynamic Analysis (code & data transformations, selective encryption, anti-debug)
- Prevent Tampering and Lifting (integrity verification, whitebox cryptography, secure storage)
- Continuously Change the Security Profile (diversity and renewability)