Multiple Roots Of Trust And Isolation: Key Roles For Absolute Security

Today, there are many different security processors available to the SoC designer. A majority have a commonality, and that is they are based on the same architecture. You can call it a two-domain architecture. One is non-secure; the other is secure with a single bit dividing the secure from the non-secure.

What’s more, different applications from different entities may be running in that one secure domain. These entities may include the SoC vendor, device OEM, service provider, end user or some other participant in the eco-system of that SoC, ASIC, or other chip with that type of embedded security.

But in this embedded security approach, those applications from different entities aren’t isolated from each other. So, the probability is high they can access not only their own keys, but they can access keys from the other applications. Therefore, partitioning is only between the secure and non-secure domains and not between the different entities.

The one bit mentioned above is used by the security processor to create a sandbox for secure applications, and all of them operate in the same sandbox. Here, as can be well imagined, issues arise simply because those different entities may not completely trust one another when it comes to security. Think about it. If one entity is attacked, the security of the other entities is compromised.

On the other hand, there is the hardware security core like Rambus’ CryptoManager Root of Trust. This type of architecture hands the SoC designer many domains or multiple roots of trust. Further, there is a separate security domain for every entity, and security domains are separated from one another with the help of strong hardware security. Also, security assets like keys and hardware resources are isolated.

Security is increasingly important for virtually every device and system being planned today. It’s prudent for designers to keep in mind that there are different uses for security and different entities need different security functionality.

Chipmakers need secure functionality, for example, for their own manufacturing and testing of their chip products. Their OEM customers also need security for their specific applications. Service providers and others may also need security functionality. Therefore, the savvy SoC designer needs to offer security that can be used throughout the lifecycle of the chip by these different entities. However, they want to accomplish that objective without compromising their own security.