As Ben explains, in our latest “Secure Silicon IP Webinar Series“, a root of trust is the security foundation for an SoC, other semiconductor device or electronic system. However its meaning differs depending who you ask. For example, the hardware root of trust contains the keys for cryptographic functions and is usually a part of the secure boot process providing the foundation for the software chain of trust.

In this article:

• • What is hardware root of trust?
  • What are the types of a silicon-based hardware root of trust?
  • What are the benefits of a programmable hardware root of trust?
  • What features should a programmable hardware root of trust offer?
  • What is the Rambus CryptoManager Root of Trust?
  • How is the CryptoManager Root of Trust architected for security?
  • Is there a CryptoManager Root of Trust configured for my application?

What is hardware root of trust?

A hardware root of trust is the foundation on which all secure operations of a computing system depend. It contains the keys used for cryptographic functions and enables a secure boot process. It is inherently trusted, and therefore must be secure by design. The most secure implementation of a root of trust is in hardware making it immune from malware attacks. As such, it can be a stand-alone security module or implemented as security module within a processor or system on chip (SoC).

What are the types of a silicon-based hardware root of trust?

A silicon-based hardware root of trust falls into two categories: fixed function and programmable. Essentially, a fixed-function root of trust is a state machine. These are typically quite simple, small and designed to perform a specific set of limited functions like data encryption, certificate validation and basic key management. However, these functions are static as a fixed function hardware root of trust can only do what it is specifically designed to do.

In contrast to its fixed-function counterpart, a hardware-based programmable root of trust is built around a CPU. Performing all the functions of a state machine-based solution, a programmable root of trust can also execute a more complex set of security functions. A programmable root of trust is versatile and upgradable, enabling it to run entirely new cryptographic algorithms and secure applications to meet evolving attack vectors.

What are the benefits of a programmable hardware root of trust?

The cybersecurity threat landscape is dynamic and rapidly evolving. Fortunately, a programmable hardware-based root of trust can be continuously updated to contend with an ever-increasing range of threats. Indeed, attackers are constantly finding new ways to exploit critical vulnerabilities across a wide range of applications and devices. Computers and network equipment are obvious targets for cyberattack, but in the highly interconnected world of the Internet of Things (IoT), devices such as connected door locks, home security systems, smart thermostats, security cameras, baby video monitors and smart appliances are all vulnerable.

Compromised IoT devices can be easily reprogrammed to stealthily violate consumer privacy, while connected appliances controlled by a remote attacker can potentially cause serious property damage. Moreover, compromised devices are susceptible to hijacking by botnets and can be exploited to attack other devices as well as critical internet infrastructure. As such, a programmable hardware-based root of trust should be part of all connected devices to protect from current and future threats.

Keep reading: Learn about the important role a hardware root-of-trust plays in an anti-counterfeiting IC »

What features should a programmable hardware root of trust offer?

A programmable hardware root of trust should be purpose-built; specifically designed from the ground up to provide a robust level of security. Since the root of trust is a logical target for an attacker, it should be made as secure as possible to safeguard it from compromise. Capabilities should include:

• • Siloed Execution:

    Ensures that sensitive security functions are only performed within a dedicated security domain that is physically separated from the general-purpose processor. This paradigm allows the primary CPU to be optimized for architectural complexity and performance – with security functionality safely isolated in a physically separated root of trust.

  • Comprehensive Anti-Tamper and Side-Channel Resistance:

    Protects against multiple fault injection and side-channel attacks.

  • Layered Security:

    Provides multiple layers of robust defense to avoid a single point of failure. Access to cryptographic hardware modules and other sensitive security resources are enforced in hardware, while critical keys are only available to hardware. Software security can be layered on top of a hardware-based root of trust, thereby providing additional flexibility and security.

  • Multiple Roots of Trust:

    Ensures isolation of resources, keys and security assets. In real-world terms, this means each entity – such as a chip vendor, OEM or service provider – has access to its own ‘virtual’ security core and performs secure functions without having to ‘trust’ other entities. This allows individual entities to possess unique root and derived keys, as well as access only to specified features and resources such as OTP, debug and control bits. Moreover, support for multiple roots of trust enables the security core to assign or delegate permissions to other entities at any point in the device life cycle, while isolating (in hardware) unique signed apps that are siloed away from other programs.

    Watch our ‘Secure Silicon IP Webinar Series’ : When One is Not Enough: Multiple Roots of Trust »

What is the Rambus CryptoManager Root of Trust?

The Rambus CryptoManager Root of Trust is a programmable hardware root of trust that operates on the principle of siloed execution. It is a secure co-processor using a custom RISC-V CPU that is specifically designed for hardened security. It is compatible with any primary CPU(s) and provides a separate processing domain for sensitive security functions. Additional features include (separate) secure memory, crypto accelerators, anti-tamper logic protection, multiple roots of trust and side-channel countermeasures. The Rambus CryptoManager Root of Trust is fully programmable and adapts to evolving attack vectors, changing threat environments and new applications.

How is the CryptoManager Root of Trust architected for security?

The Rambus CryptoManager Root of Trust hardware IP core is built around Verilog RTL, which enables the customizable and modular root of trust to be easily integrated in any chip or FPGA design. Perhaps most importantly, the CryptoManager Root of Trust’s layered architecture provides the security of a hardware design with the flexibility of software.

Simplified CryptoManager Root of Trust Block Diagram

The diagram above illustrates the basic architecture of the CryptoManager Root of Trust, including:

• • RISC-V CPU:

    The CPU is a security optimized, configurable and multistage 32-bit RISC-V processor.

  • Multiple Bus Fabrics:

    Connects various hardware modules within the CryptoManager Root of Trust. Note: There is a single bus that is completely dedicated to transporting and protecting sensitive keys from unauthorized software access.

  • Private SRAM:

    Features multiple interfaces and a hardened memory protection unit. The CryptoManager Root of Trust’s SRAM – which stores secure assets in a memory region isolated from the rest of the system – also includes a small amount of read-only memory.

  • Key Transport Core:

    Manages keys that may be used externally.

  • True Random Number Generator:

    Generates true random numbers for multiple cryptographic algorithms and protocols.

  • DMA Controller:

    Moves data in and out of the core.

  • Key Derivation Core:

    Allows multiple keys to be derived for different applications – while keeping keys cryptographically isolated.

  • Cryptographic Engines:

    Includes three (by default) cryptographic engines: one for public key algorithms, elliptic curve and RSA; a hash engine; and an AES engine.

  • OTP Management Core:

    Manages one-time programmable memory that is used for storing keys and other security assets.

  As noted above, the versatile CryptoManager Root of Trust can be easily integrated into a wide range of silicon. Its standard interfaces include AMBA interface buses for communicating with registers (the control plane interface into the core), as well as an AHB bus that interfaces with system memory (data plane access). The CryptoManager Root of Trust also offers easy-to-use test interfaces of key buses for supplying keys to external logic, as well as I/O pins for managing various functions like chip features and alerts (controlling and monitoring external logic).

  Additional key CryptoManager Root of Trust security features and capabilities include:

  • Self-Contained Secure Boot Mechanism:

    Starts with a first-stage boot ROM that is synthesized into gates.

  • Side-Channel Resistance:

    Offers comprehensive protection against various side-channel attacks such as Differential Power Analysis (DPA), Simple Power Analysis (SPA), Simple Electromagnetic Analysis (SEMA), Differential Electromagnetic Analysis (DEMA), Correlation Power Analysis (CPA) and Correlation Electromagnetic Analysis (CEMA). These side-channel countermeasures are present throughout the CryptoManager Root of Trust, including in the execution pipeline of the CPU itself.

  • Glitch and Fault Injection Attack Protection:

    Protects against a full range of glitch and fault injection attacks.

  • Memory Protection Unit:

    Locks at boot time and cannot be altered by malicious code.

  • Private SRAM and Isolated CPU Bus:

    Prevents modification of the call stack and ensures control flow integrity.

  The CryptoManager Root of Trust – which includes a complete firmware stack – also employs a layered security model for software utilizing privilege levels that are part of the RISC-V ISA. Put simply, these privilege levels are enforced on a hardware level, thereby effectively separating data between their respective layers. More specifically, the least privileged (least secure) layer is the user level, which is where user-written secure applications run. These applications can also be referred to as containers.

  The next level is the supervisor level, where a Zephyr-based microkernel customized for security resides and runs. As expected, the highest privilege level is where the most secure code runs, with a security monitor overseeing the microkernel and containers, as well as their interaction with hardware. Although lower levels are more flexible, they are considered less secure. As such, the security monitor is specifically designed to provide a robust level of security protection for the software stack.

  Is there a CryptoManager Root of Trust configured for my application?

  There are seven configurations of the CryptoManager Root of Trust tailored to address the specific security requirements and certification standards of various markets.

  The RT-730 automotive design offers an ISO-26262-2018 ASIL-D-ready implementation, targeting vehicle-to-vehicle and vehicle-to-infrastructure (V2X), advanced driver-assistance systems (ADAS) and infotainment uses.

  For cloud, AI and ML accelerator chips, the RT-630 helps secure valuable training algorithms, along with training and inference data. For government-focused chip designs, the RT-650 design targets FIPS 140-2 Cryptographic Module Validation Program (CMVP) certification with Suite B accelerators.

  Check out all the available CryptoManager Root of Trust configurations.

Researchers from the University of Iasi and the University of Switzerland have published a paper describing a white hat malware attack that targets Intel’s Software Guard Extension (SGX). Essentially, software guard extensions are a set of hardware instructions designed to provide a secure execution environment for user-developed applications.

“To our knowledge, there was no serious attempt yet to overcome the SGX protection by leveraging the software supply chain infrastructure, such as weaknesses in the development, build or signing servers,” the researchers explain. “While SGX protection does not specifically take into consideration such threats, we show that a simple malware attack exploiting a separation between the build and signing processes can have a serious damaging impact, practically nullifying the SGX integrity protection measures.”

According to the paper, the white hat malware attack is similar to any infection of executable files where malicious code is hooked on the execution flow and the injection takes place in the free space within the executable section. However, when targeting SGX, the researchers also analyze the ecall table, test whether pointers belong to trusted or untrusted memory areas and synchronize with untrusted code through spin locks.

“We provided a practical use case for our attack methodology, which is able to successfully extract sensitive data from the secure enclave space,” the paper confirms. “[However], this use case is generic enough to be applied to multiple cases of enclaves.”

In real-world terms, this means that a malicious entity with knowledge of a specific enclave functionality can execute more targeted attacks – such as altering the behavior of an enclave code.

“The flexibility of the attack scenario, which requires essentially just a window of opportunity between the building and the signing of an enclave, makes it quite problematic,” the researchers add.

As the paper notes, attacks that compromise legitimate software packages during their development or distribution phases have increased in recent years. In fact, one of the most common attack vectors is the injection of malicious malware code into legitimate software packages during or between development and distribution phases, such as upon building or signing.

“The most prominent example is an infected installation package of the well-known CCleaner application that included a malware deployed in the vendor’s build server,” the researchers add. “The altered binary file was downloaded by 2.27 million customers, with potentially serious effects ranging from keystrokes recording to stealing secret credentials from users.”

From our perspective, the above-mentioned white hat attack highlights the importance of an independent hardware security co-processor. A security co-processor can offer secure execution of user applications, tamper detection and protection, as well as secure storage and handling of keys and security assets. Although located on the same silicon as the main processor, the secure processing core can be physically separated. This layered security approach enforces access to crypto modules, memory ranges, I/O pins and other sensitive resources. As well, it assures that critical keys are only available through hardware – with no access by software.

An independent hardware security co-processor can also offer true multiple root of trust capabilities, with each individual application assigned its own unique keys. Put simply, this means permissions and access levels are set completely independent of others. Moreover, applications are safely siloed from each other.