Do multiple roots of trust offer the absolute security?
Why do we need them after all?
Let’s see.
In this article:
-
- Why to use multiple Roots of Trust?
- What if I don’t have multiple roots of trust?
- What is a secure master root?
- What is signed software?
- How do keys support multiple roots of trust?
- Example – How do multiple roots of trust benefit smart buildings?
- Example – How do multiple roots of trust benefit the automotive sector?
- Rambus: Presenting Multiple Roots of Trust Across the World
Want to read first more details about a hardware root of trust?
Go here for our primer on Hardware root of trust: Everything you need to know »
Why to use multiple Roots of Trust?
A secure co-processor that supports multiple roots of trust enables various entities – such as chip vendors, OEMs and service providers – to manage their own virtual security cores.
A multiple root of trust paradigm allows each entity to manage unique roots and derived keys, as well as limit access to features and resources such as OTP, debug and control bits.
Moreover, a multiple root of trust paradigm allows the security core to assign or delegate permissions to various entities at any point in the device lifecycle, while isolating – in hardware – unique signed apps that are siloed away from other programs.
Put simply, these multiple roots of trust effectively create a hierarchical and secure execution environment in which mutually distrusting entities can safely execute on the same CPU.
What if I don’t have multiple roots of trust?
Without multiple roots of trust, disparate applications managed by multiple entities are run without any effective method of separation. Although this is currently standard industry practice, executing multiple applications without silos ignores the real-world risks posed by rogue applications to legitimate applications residing or executing within the same domain.
For example, a rogue application can infect legitimate programs with malware, steal data and expose sensitive information like passwords and banking credentials.
Essentially, a single malicious application can compromise the security of all other legitimate applications residing or executing within the same domain. This is precisely why the implementation of multiple virtual roots of trust is critical; as each entity securely runs applications within its own virtual security domain.
Moreover, when the processor switches applications, all content is flushed. This technique ensures that data, keys and other information are not shared – and does not persist between different applications.
What is a secure master root?
Multiple roots of trust are managed by a secure master root that sets the permissions and privileges of each sub-root of trust. Each individual entity, along with its secure processes and applications, is assigned its own dedicated root of trust that is controlled by the master root.
When an application is loaded into the hardware-based root of trust, the (virtual) root is identified and confirmed, while the hardware is authorized to configure itself for that specific root.
A chip manufacturer is typically assigned the master root, thereby enabling it to easily create new roots for additional entities. Master roots are considered unique because they grant permissions required for the creation of new master roots of trust or new sub-roots.
Additional master roots can be generated for device or system OEMs that require master security rights to all operations on its devices, even if a subset is granted to other entities. If necessary, secondary master roots can also deactivate previous master roots, rendering them unusable.
This means device OEMs can create a master root and subsequently (permanently) remove the manufacturers’ master root. In real-world terms, this means the chip manufacturer can no longer run applications on the device.
What is signed software?
Multiple roots of trust are implemented using signed software. A security processor only allows authorized software – signed by a key which is known to the root of trust – to run.
Each multiple root of trust is associated with a key used for signing. When a signed application runs, it receives the keys and permissions of the root it is associated with (the root that signed the application).
This procedure ensures a tight binding of keys and permissions for the entity that created the application. Preventing software signed by one root from accessing data and keys associated with another root is enforced on a hardware level.
Indeed, enforcement of access rights to hardware, permissions and keys should all be enforced in hardware. When software is loaded, the root is checked and validated, thereby authorizing the hardware to load security permissions and access policies.
How do keys support multiple roots of trust?
Keys play an important role in supporting multiple roots of trust. Specifically, the base key associated with each root and entity drives (creates) new keys, allowing a single key to securely multiply.
These derived keys can be used to support or execute various security operations; while also ensuring disparate keys remain isolated and are not shared between different functions. The process, enforced in hardware, starts with a single root key that subsequently derives new keys.
As we noted earlier, it is critical for each set of derived keys to remain unique per root, with each root blocked from deriving or accessing the keys of another root.
Moreover, a secure derivation function should be used to derive keys on the fly. In real world-terms, this means derived keys are ephemeral, existing only when they are used and subsequently cleared.
This technique helps stymie an attacker as the keys only exist for a short period. A malicious actor has a brief window of opportunity to attack the target: when the key is present in the root of trust itself. Even at this vulnerable stage, there are multiple hardware-based security techniques that can be leveraged to keep an attacker at bay.
How do multiple roots of trust benefit smart buildings?
With a multiple root of trust paradigm, OEMs can match specific roots with specific functions.
For example, a root can be assigned to the company or entity managing the HVAC system. Meaning, permissions are granted for functions related only to HVAC systems – but not smart lighting, for example.
Although there may be another root associated with lighting, it remains isolated with access limited to the entity responsible for managing the lighting systems. Similarly, the smart lighting system is blocked from accessing HVAC infrastructure.
Indeed, the secure processes associated with HVAC and lighting are strictly limited to their own roots. Even if the HVAC application is rife with unanticipated security vulnerabilities, the multiple root of trust paradigm limits potential damage by preventing the compromised application from adversely affecting the security of other systems.
How do multiple roots of trust benefit the automotive sector?
With a multiple root of trust paradigm, the original chip master root can be eliminated and replaced by new master roots created for multiple OEMs.
This enables OEMs to use all the features of the root of trust, as well as create new roots of trust for service centers and remove any previous master root(s) owned by another entity.
Essentially, OEMs control all uses of the root of trust, manage vehicle software and determine access to security resources.
OEMs can also create sub-roots and limited roots for service centers to support a limited set of permissions. Indeed, OEMs may want to restrict the ability of service centers to install new firmware until it is reviewed and authorized.
However, OEMs may also want service centers to access certain test and debug capabilities in the interim. With multiple roots of trust, OEMs can pick and choose which permissions the service center and other downstream entities are permitted to access.
Presenting Multiple Roots of Trust Across the World
Our friends at SiFive have been hosting a worldwide series of technical seminars, and Rambus has joined them for a number of these to present our CryptoManager Root of Trust secure co-processor. We highlight how our Root of Trust forms the anchor of hardware-based security, and specifically how we enable multiple roots of trust.
Having the ability for a master root (typically a chip maker or the device OEM) to assign specific, independent security permissions to applications (sub roots) running within the secure boundary of our secure co-processor, differentiates us from other security solutions.
Other competing solutions offer a secure area, but all apps in that secure area are given the same level of trust and permissions.
This is risky – what if one of those apps has been compromised?
The CryptoManager Root of Trust (CMRT) eliminates this risk; all apps within the secure area are assigned a very limited, specific set of unique permissions that only allow it to perform and access designated processes.
Any attempt to reach beyond those permissions is met with anything from immediate notifications to the master root, all the way to a complete shut down of the device.
A bit on CryptoManager Root of Trust
Designed to support a multiple root of trust paradigm, the Rambus CryptoManager Root of Trust (CMRT) is a programmable hardware-based secure co-processor that operates on the principle of siloed execution.
The CMRT is built around a custom RISC-V CPU specifically designed for hardened security. It is compatible with any primary CPU(s) and provides a separate processing domain for sensitive security functions. In addition to supporting multiple roots of trust, key features include:
• Self-contained secure boot mechanism
• Private SRAM and isolated CPU bus
• Three crypto engines (one for public key algorithms, elliptic curve and RSA; a hash engine; and an AES engine)
• Crypto accelerators
• Anti-tamper logic protection
• Side-channel countermeasures
• Glitch and fault injection attack protection
• OTP management core
• True random number generator
• DMA controller
• Key transport core
• Multiple bus fabrics
At the SiFive seminars, we demonstrate our ability to support multiple roots of trust through mimicking a smart home deployment.
In the demo, we show a Smart Hub OEM as the master root, with 2 sub-roots.
The first sub root enables a lighting app to control lights embedded within the demo, and the second enabling a HVAC app to control an attached fan. The demonstration allows attendees shows how permissions are granted and allows them to interact with the root of trust thru turning on and off functions within both master and sub roots.
Included in this is the ability to attempt to violate sub root permissions
(spoiler alert…can’t be done)
We’ve presented in Munich, Germany and Tokyo, Japan events, where our local sales and engineering staff hosted a talk and demonstration to well over 90 attendees.
We usually continue our tours with stops in South Korea, China, and finishing just down the road in Palo Alto.
If you’re interested in hearing more about how RISC-V can benefit your designs, and specifically how the CryptoManager Root of Trust can enable true hardware based security in your designs, please keep a close eye in our upcoming events or contact us directly.
