Software-Defined Everything doesn’t mean Software-Only Security
Computing power has reached the point where once “hardware-only” functions can now be handled by the software layer running on top of the hardware, with negligible performance difference for users. Applications once only seen in science fiction are becoming present-day science reality, such as the rise of the Metaverse and smart cars that approach the ultimate goal of level 4 autonomous driving. Increased software control over the underlying hardware resources has also recently been responsible for the software-defined everything (SDx) revolution, allowing for agile and flexible repurposing of the traditional IT pillars of compute, network and storage (including the secure container in the cloud).
Given the relative ease to reconfigure software code compared with modifying hardware, the “software-defined” trend continues to gain momentum as computing speed increases can cover most of the penalties as we move away from hardware-specific configurations and accelerators. In fact, the projected size of software-defined and virtualized network functions infrastructure market in 2023 is expected to be at $4.7 billion, according to a 2019 report from IDC.
However, even as systems start relying more upon the software for hardware configuration such as virtual machines for SDx, on top of implementing the application layer, it becomes even more important that the basis of system security remains at the hardware layer. Those same easily changeable characteristics that make software appealing for software-defined configuration/applications are a double-edged sword since the software is more easily hacked than hardware. In addition, more reliance on software means more attack surfaces for hackers to probe for system weaknesses. To take the advantage of software’s flexibility and address the security concerns, software must be developed with an immutable secure anchor, in which can only be achieved by hardware design. For these reasons, a well-designed, secure system must implement a hardware root-of-trust (HRoT) at its lowest, most basic hardware layer.
To establish trust in a system, there needs to be a most basic unit that is implicitly trusted; that is, this “root” of trust is the point from which system authentication can take place – the system uses this root-of-trust to attest that the rest of the system is genuine and trustworthy, including the other hardware components of the system as well as the firmware and software that runs upon said hardware. Beyond attestation, a root-of-trust may also offer the ability to store, or better yet, even generate a unique ID or hardware unique key (HUK) for the system that can only be created by that one individually implemented RoT. Every system may have its own RoT, but each RoT will instantiate its own HUK through TRNG key injection or be derived from an internal PUF that creates its own unique code based on an inherently random physical process. A unique ID (a.k.a. silicon “fingerprint”) is particularly useful, especially in an entirely virtual world, such as the Metaverse, where one’s unclonable ID is the only way to differentiate between users, or when the day comes when the majority of data is stored in the cloud in secure containers, or when all of our vehicles can be fully connected and networked (V2x) – it is vitally important that Michael Smith knows his car is still parked in his garage, and isn’t confused with Michael Brown’s car currently getting off of the freeway.