While at a recent industry event I heard a senior military leader note their preference for hardware-based security because “software is hackable”. The idea of hardware as an uncrackable vault was rocked by this month’s announcement of two major cybersecurity flaws in Intel chips, Meltdown and Spectre. Meltdown and Spectre caused widespread panic and raised questions about the security of Intel chips and the last 20 years of processor design. Jumping into action Intel was quick to release patches but the impact of these flaws will be felt for years to come.
While it is easy to say that Meltdown and Spectre prove that hardware is just as risky as software, I believe we should instead focus on how we got here. I believe there is a lesson rooted in our approach to technological innovation as highlighted by Marc Andreessen’s seminal article Why Software Is Eating the World.
Software Defined Everything has become the rallying cry of organizations. In a drive to reduce cost and speed up innovation we have started to treat hardware as a commodity and focus on software as the solution. But there is a problem. What if our hardware cannot keep up with our software? Are we asking too much of our hardware?
Moore’s law states that processor speeds double every two years (or eighteen months according to Intel). In technology two years is an eternity so engineers have devised ground breaking methods to speed up processors. One such method, called speculative execution, allows a processor to perform a function before it knows whether the function is required. If the function is not required then it is discarded but the act of completing it, just in case, allows the processor to perform operations more quickly.
Click to Subscribe
While designed as an optimization technique, Meltdown and Spectre proved that a cache timing attack could take advantage of speculative execution to expose secure kernel memory. As described by The Register, “To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes’ virtual memory address spaces, although it is invisible to these programs…It seems it may be possible to craft software in such a way that the processor starts executing an instruction that would normally be blocked – such as reading kernel memory from user mode – and completes that instruction before the privilege level check occurs.”
Another example of the desire to use software to solve the limitations of hardware is the deployment of Virtual Machines (VMs). VMs have truly changed the world, creating the cloud and allowing organizations to dramatically reduce cost. VM technology allows collocated, software-based operating systems to share expensive hardware resources. VM security is based on hardware Trusted Platform Module (TPM) storing secure information and software hypervisors scheduling access to hardware resources.
Despite these barriers, side channel attacks can still be used to cross the boundary between collocated VMs and steal private information. These attacks involve an attacker VM alternating execution with a target VM to observe behavior of the underlying hardware. They take advantage of the fact that, in order to conserve memory and speed up processing, VMs often share caches and libraries (i.e., memory page deduplication). While difficult, multiple researchers have shown a side channel attack’s ability to retrieve secure information including private keys. Other researchers have shown the ability to perform Denial of Service (DoS) attacks by using the VM scheduler to monopolize hardware resources at the expense of collocated VMs.
With the advent of Software Defined Networking (SDN) will the next attack be listening to other people’s traffic on bare metal switches?
If we are asking too much of our hardware what can we do to correct it? Should we accept slower processors, which has been the result of Intel’s patches? Should we no longer allow collocation of VMs or demand completely separate data centers for our servers?
I am sure we will not start accepting slower speeds or higher costs so the next best option seems to be education. Developers need to understand how hardware and software interoperates in order to prevent future cybersecurity attacks. For instance, in addition to a six week course on Python, developers should also invest in a six week course on machine language. Perhaps if they understood how hardware resources are actually used by software they will know when to push hardware and when not to.
Eric Sharret is Vice President of Business Development at TELEGRID. TELEGRID has unique expertise in secure embedded systems, secure authentication, PKI, and Multi-Factor Authentication (MFA).
Click to Subscribe
Disclaimer: The opinions expressed here do not represent those of TELEGRID Technologies, Inc. The Company will not be held liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.