Choosing The Right Hardware Root Of Trust

A Root of Trust is broadly defined as the security foundation for a semiconductor or electronic system. Any secure function performed by the device or system relies in whole or in part on that Root of Trust. The Root of Trust typically handles chip and device identities, cryptographic functions, stores and manages cryptographic keys, and handles one or more secure processes that provides the foundation for the device chain of trust such as secure boot, attestation and authentication, firmware updates, and others.

The choice of what Root of Trust to employ should be among the most important considerations chip designers and security architects face. However, there is a belief that all roots of trust offer similar functionality and security protections — nothing could not be farther from the truth. Let’s first explore a few ways in which roots of trust differ.

• Design and security protections: The broad definition of Root of Trust allows many differing implementations of what are deemed “roots of trust.” However, the actual design and security protections vary wildly depending on the provider. Some Roots of Trusts are custom designed specifically for the purpose of being a security vehicle, whereas others are simply repurposed hardware. Case in point: high-end hardware roots of trust are often integrated into silicon as separate, custom-designed security co-processors, protected by multiple layers of hardware and software security, offering separate security domains for all processes within them. At the other end of the spectrum, some roots of trust are simply a software domain on a shared CPU that are offered as part of a package.
• Extensibility and programmability: Some roots of trust are fixed function, and cannot extend a security boundary beyond the pre-determined functions. However, other roots of trust are programmable, allowing a security boundary to be extended to applications and processes of the chipmaker’s choice.
• Crypto algorithm (cipher) support: Not all roots of trust support all crypto algorithms, especially when localized algorithms are considered. Some can be modified or upgraded to support emerging or alternative ciphers, whereas others contain a small number of preset ciphers which cannot be modified.
• Anti-tamper and side channel protection: Some roots of trust are designed with anti-tamper and side channel protections built in, whereas others offer no protection against these attacks.
• Speed, size and power consumption: As the speed, functionality and security of a Root of Trust increases, generally the size (gate count) and power consumption will increase.

With all of these differences, it is imperative that chip designers and security architects examine their unique security and implementation needs before choosing a Root of Trust. The following is only a short list of questions that engineers should consider before choosing a Root of Trust.

• Protection: Who are you protecting against – state-funded adversaries or chip counterfeiters? What is the threat model? What needs to be protected on chip? Design engineers need to consider the threat profile their devices (and their customers) will face, and design against that appropriately. A chip being designed for the defense market needs to support a level of protection that likely may not be needed for industrial IoT devices. Many roots of trust are included within standard licensing packages from IP providers – are those really secure enough for your requirements?
• Risks: What is the risk of a compromised device? In the most extreme cases, are there national security risks? If your device’s security is compromised, is there risk to human life, such as in self-driving cars or aerospace? Is there is a financial risk, such as for chips meant for securing financial data on mobile phones or IoT devices? What is the risk to your company’s brand reputation if your chip is compromised? Are there regulatory risks? What about the risks of IP, content, service or resource theft? And, how much of this is your company’s risk versus your customer’s?
• Design freedom and reuse: Are you comfortable with a Root of Trust that locks you into a processor ecosystem? How much of this generation’s work will be transferable to your next chip design?
• Requirements: Will you need to consider third-party certifications or adherence to standards? What certifications are applicable for the SoC or required for the Root of Trust?
• Security manager: Is the expectation that the Root of Trust will take on security functions beyond its boundary, or will the Root of Trust manage a standard set of processes? Does the Root of Trust need to manage the system? Will the Root of Trust augment existing security architectures, or be the primary hardware security mechanism?
• Cost vs. performance: Where does device security vs. cost (silicon area) vs. performance rank in the priority of the design?

In summary, there is no such thing as a standard root of trust. Running the gamut from small, limited security implementations to larger, high security anchors, the choice of a root of trust is best tied to the unique technical and business needs of the chipmaker and its customers.

Other resources:
White Paper: Implementing Security by Design
Blog: Rambus CryptoManager Root of Trust Cores Certified ASIL-B/D Ready for Enhanced Security in Automotive Applications
Website: Rambus Root of Trust Solutions
Website: Rambus CryptoManager Root of Trust