Achieving Security Goals With A Hardware Root Of Trust

In an environment of growing threats, meeting a fundamental set of security goals is imperative for safeguarding devices and data from attack. The most robust means of meeting these goals is a root of trust anchored in hardware.

In Microsoft’s “The Seven Properties of Highly Secured Devices” white paper, property #1 is implementation of a hardware root of trust. As Microsoft explains: “Unlike software, hardware has two important properties that may be used to establish device security. First, single-purpose hardware is immune to reuse by an attacker for unintended actions. Second, hardware can detect and mitigate against physical attacks.”

The goals that need to be met for robust security include unique identification, security lifecycle management, attestation, secure boot, secure update, anti-rollback, isolation, interaction, secure storage, and cryptographic/trusted services. Let’s explore how some of these can be met with a hardware root of trust.

Unique identification

A device gets its “cryptographic identity” from a private key that is stored confidentially and immutably inside the device. The device’s public key, corresponding to the private key, is typically signed by the device manufacturer or a third-party certificate authority, providing trust that the public key is indeed associated with this device.

When a device’s identity key material is leaked, the device can be a victim of identity theft and impersonation. In this case, an attacker can use the device’s identity key material to (falsely) authenticate itself as a trusted device to any services and organizations that trust the device to handle their data or that need to trust data provided by the device.

A hardware root of trust allows a device to securely store and use the private key material such that it is never exposed to the host processor – even in secure mode. All key material remains inside the hardware-enforced security boundary, with no reasonable way for an attacker to copy and distribute the private key material to other devices, not even if these other devices also include a similar instance of the hardware root of trust. In this way, a hardware root of trust prevents the attacker from “scaling up” the effects of his attack.

Security lifecycle

The security lifecycle of a device is all about making sure that the right level of access and functionality in a device is available at the right time in the device lifecycle. An example of lifecycle-related access restrictions is access to the device test, debug, and provisioning ports. A device in production must allow access to these ports. As these ports could provide access to sensitive data and state on the device, access must be closed, and must remain closed, while the device is in the field. When a device malfunctions and is returned to the manufacturer for root cause analysis/RMA, the device manufacturer may need to regain access to these security sensitive functions again, while not compromising the security of sensitive data that the owner of the device may have stored.

It must be possible to store the device’s lifecycle “state” (in the device) in a way that survives power cycles, and at the same time prevents the state from being rolled back or modified; especially if this would lead to a state that would allow an attacker to re-open access to security sensitive functions and through these, sensitive data. Cryptographic authentication may be used to securely re-enable such functionality, but this in turn requires the device to immutably store a (device manufacturer) public key, and to implement the functionality to use the key in an authentication exchange and unlock (re-enable) access to security sensitive functions.

Obviously, this control over the “unlock functionality” must be strongly protected – as well as the execution of the authentication process. When a device is in the field, it must be impossible for an attacker to circumvent the authentication process and access the test port unlock functionality directly. A hardware root of trust provides this protection, as it autonomously executes the authentication operation without requiring any security from the host processor. All that is needed is a communication channel to directly exchange the authentication messages with the hardware root of trust, and the appropriate public key material stored in the OTP that it directly manages. Upon successful authentication, the hardware root of trust re-enables access to the specific security sensitive function or interface, until the next device restart.

Secure boot

Secure boot is the process of validating the authenticity and integrity of the code that the device plans to execute, prior to execution. Secure boot implements a chain of trust that is anchored in the immutable ROM code that the application processor starts from immediately after reset. This ROM code uses an immutable public key (sometimes referred to as the root of trust for boot) to validate the signature over the code for the next boot stage. In many cases, the ROM code also uses a special secret key to decrypt the firmware image.

A hardware root of trust assists and secures the host secure boot process by offering a secure storage location for the key material used by the secure boot process. It can offer a simple interface for performance of the image decryption and signature verification operation. This ensures that the key material never needs to be handled on the host processor. It also offloads the host processor and accelerates the boot process. Lastly, it unburdens the boot code programmer from having to implement the complex cipher algorithms in his boot ROM nor in the code of the subsequent boot stages.

Root of trust options

Providing a hardware-based foundation for security, Rambus offers a broad portfolio of robust root of trust solutions, ranging from richly featured defense-grade co-processors to highly compact state machines suitable for IoT devices. These solutions provide robust security capabilities including unique identification, security lifecycle management, attestation, secure boot, secure update, anti-rollback, isolation, interaction, secure storage, and cryptographic/trusted services. With a breadth of solutions applicable from the data center to endpoint devices, Rambus has a root of trust solution for almost every application.

Additional 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