The recent revelations of the Meltdown and Spectre attacks on hardware CPUs brings us back to something that The Attributer has addressed in previous articles: emergent properties of complex systems. (See IB2 in 2016: the attribute Emergent). For those readers who might have missed that article, highly complex systems exhibit unexpected and unwanted behaviours that are the result of component interactions in the system. All the system components are working exactly as designed, but what emerges is a behaviour pattern that was unforeseen by the designers. In this case ‘the system’ is the hardware CPU.
Since the mid-90s CPU architecture has been designed to optimise performance. The exact way that these performance enhancement techniques work leads to possible ‘covert channels’ (sometimes called side-channels) for data leakage. It is beyond the scope of this article to describe the details of these vulnerabilities. What concerns us here is the impact of these revelations on the future of security architecture. They are of major landmark significance. They are not ‘run of the mill’ discoveries.
Looking back to November 1983, at Lehigh University, Bethlehem, PA, USA, a researcher called Fred Cohen demonstrated the possibility of creating self-replicating code that could ‘infect’ other code and penetrate the system to the highest root privilege level. He had invented the computer virus.
Fred Cohen’s computer virus was a pivotal moment in the development of computer security and malicious attacks on computer systems. It would change the game forever. In the opinion of The Attributer we have just witnessed, in the disclosure of Meltdown and Spectre, another development of equally pivotal significance – another game changer.
We must now abandon all previous assumptions about hardware security that have underpinned the previous twenty years of computer security thinking. In the future we can expect many more hardware vulnerabilities to be discovered. Almost by definition any hardware is vulnerable to ‘covert channel’ data leakage. This is because when a hardware component operates it can be observed to be doing something, and with enough context information an observer can guess what it might be doing, even if the operation itself is hidden by privilege protection.
This was the basis of Paul Kocher’s attack on smart cards, to be able to read out the bits of a private RSA key. When a transistor operates it demands a tiny amount of extra power. If you can measure those increments of power consumption you can analyse patterns and interpret what the hardware is doing. Differential power analysis (DPA) does exactly that, and since the smart card is powered from an external source, the differentials are exposed as a covert channel that can be monitored.
So what should we do? Yes, of course, apply the patches for the recent vulnerabilities – but these only hide the problem, they do not solve the fundamental flaw in the hardware design. The word ‘patch’ is appropriate because that’s all it is – a sticking plaster to cover the wound – it does nothing to heal the wound.
We must remind ourselves that security architecture is a holistic thing. SABSA addresses the totality of the systems that are subject to the architecture. It must not make assumptions about the secure independence of one application system from another when they share the same hardware platform. If you do not have a trusted execution platform, you cannot fix the problem at the higher layers of the software architecture.
In order to ensure that hardware covert channels (whether or not we have yet discovered them) cannot be used to subvert highly sensitive systems, we must reconsider the architecture of shared hardware platforms, multi-user systems, cloud services on shared servers and the possible escape from the control of the operating system or the hypervisor. The industry hasn’t spotted it yet, but those are seismic changes to the way we architect modern systems. Once the patch frenzy is over, there will be some serious debate about the suitability of shared hardware platform architectures, including those for web services and cloud services.