RoT: The Foundation of Security
By Lawrence Liu (PUFsecurity, the subsidiary of eMemory)
Introduction
Security is a topic that will only grow more popular in the future. Its importance is tied to how critical it will be to the success of future products, particularly as the rise of the Internet of Things (IoT) will bring about an exponential growth in the number of “things” connected to each other, and to the Web (see Figure 1, below). IoT devices are distributed, unsupervised, and physically exposed. Attackers can physically tamper with IoT devices which makes software-based security insufficient to protect IoT from fraud, tampering and other integrity and DDoS attacks. Computer hardware and firmware are perceived as more dependable and trustworthy than software, because software is susceptible to design and implementation flaws and not impervious to subversion by malicious code, while it is hard to intercept, tamper or break hardware security.
A root of trust (RoT) is a set of functions that is always trusted by a system’s OS such that it’s the trust foundation on which all secure operations of a computing system depend. Containing the keys used for digital signing and verification, along with the cryptographic functions to enable the secure boot process, a RoT is an important security asset indeed. Providing trusted execution environment and embedding a RoT in hardware would provide a firm foundation for electronic systems security. The goal of this white paper is to provide an introductory primer to RoTs, ending with some guidance on choosing the right RoT as the trust anchor for a novel hardware based security architecture.
Definitions
The concept of a root of trust has been around for several years now. So as to build on the previous works of defining a RoT, perhaps it is best to start with how a RoT has already been defined.
The Trusted Computing Group, or TCG, is dedicated to the idea of secure computing. They have put forth the TPM (trusted platform module) standard as their solution to ensure computers operate as expected, and hackers have no way to gain access to secured systems. In their TPM standard [4], the TCG actually requires the inclusion of three RoTs, one each for performing the tasks of measurement (RTM), storage (RTS), and reporting (RTR). The TCG defines a RoT as [2]:
“A Root of Trust (RoT) is a component that performs one or more security-specific functions, such as measurement, storage, reporting, verification, and/or update. A RoT is trusted always to behave in the expected manner, because its misbehavior cannot be detected (such as by measurement) by attestation or observation.”
Of interest in TCG’s definition is the use of the word “component”, because it allows a root of trust to be implemented in software, hardware, or firmware.
Similar in concept, but with a more rigidly defined implementation, the United Extensible Firmware Interface (UEFI) forum defines a root of trust as [3]:
“The root of trust is ideally based on a hardware-validated boot process to ensure the system can only be started using code from an immutable source. Since the anchor for the boot process is in hardware it cannot be updated or modified in any way…. When it starts, the root of trust derives its internal keys from supplied device identity inputs and executes self-tests and code validation for itself. If these tests pass, it can move on to validate the first piece of code in the chain of trust.”...more
