Software-Defined Everything doesn't mean Software-Only Security

By Lawrence Liu, PUFsecurity

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 secure container in 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 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 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.

Click to learn more about how HRoT solves chip’s fundamental security issue

Present day companies have already begun to see the importance of basing security in hardware, particularly using a HRoT. ARM’s recently announced confidential compute architecture (CCA) in their latest V9 architecture requires a “platform root-of-trust” for maximum security, in addition to specifying that a portion of it must be “immutable”, which can only be implemented in hardware, again due to the much more malleable nature of software. In addition, the database giant Oracle has specified the use of an HRoT to ensure the security of firmware updates in their Oracle Cloud Infrastructure Security Architecture.

So what happens when we know that security is a must for the future, but a company doesn’t have the dedicated security resources like ARM or Oracle to develop their own solutions? This is where security IP vendors such as PUFsecurity can come into play. With a dedicated team of security experts focused solely on developing robust and easy to integrate IPs, PUFsecurity brings designs that can be dropped into existing designs, increasing security and upgrading systems to current standards. From the essential PUFrt HRoT to the cryptographic co-processor PUFcc, PUFsecurity can provide customers with off-the-shelf PUF-based security solutions, or tailor an existing one to exactly fit each customer’s individual needs.

To sum up, we see that even as more and more tasks that have traditionally been shouldered by hardware are now moving towards software, the fundamental security of a system should still be placed in hardware. SDx, V2x, cloud storage, Metaverse, and all the other amazing future applications yet to come will heavily rely on software, but it won’t change the fundamental nature of system security, in that it will always need to be rooted in a hardware basis of trust, in particular an HRoT.