The quest these days for SoC and system designers is for strong security without compromise to meet the demanding security challenges of today. One important part of the security story is providing isolation between different applications. However, the reality is that isolation among applications in some security offerings today provide at best a roll of the dice.
Let’s break this down some more. Ideally, the SoC/system designer wants to isolate different applications from different entities, meaning keeping them separate and protected from any vulnerabilities in other applications. This way each entity along the supply chain path has its own opportunity for security. Those entities are the SoC vendor, device OEM, service provider, end user, or other participant in that device’s ecosystem.
Unfortunately, that’s not the case in some instances where they may all be running in the same secure domain. There’s no isolation between entities running secure operations. If a secure application is run, it’s in that “same secure domain” along with every other application.
It doesn’t take much brain power to realize that problems arise because those different entities may not completely trust each other in the context of security. If one entity experiences a malicious attack, it compromises the security of all the other entities.
Multiple roots of trust in a security processor, on the other hand, give the SoC/system designer a separate security domain for every entity. Those security domains are completely separated from each other using strong hardware security. Security assets like keys and hardware resources associated with one entity are completely isolated from those associated with other entities.
In this security processor architecture, each entity owns its set of signed applications. All the context is flushed from the security processor when it switches from one application to another, and by default no data, keys, or other information persist in that processor. This ensures no context is shared between entities.
Therefore, security assets are completely and securely assigned to specific entities. There is by default no overlap, meaning different entities cannot be allowed to access the same resources. However, overlap is acceptable if desired and assignments are properly made.
A set of keys are assigned to each root in this architecture. This enables applications to be signed differently for each root. Consequently, each root essentially gets its own private set of applications. When the application is loaded into the security processor core, the root is identified, and then the hardware configures itself specifically for that root.
Lastly, what’s important to know about this architecture is that keys associated with a root provide a complete, isolated set of derived keys the root uses. This means that one key can become many keys. Those many keys can then be used for a considerable number of different security operations. But every set of keys is unique per root, and one root has no way to access keys from another root, which is hardware enforced.
Ben Levine is Senior Director of Product Management for the Rambus Cryptography Products Group. Previous roles at Rambus include Technical Director, focusing on hardware security cores, and Director of Engineering, managing hardware and software teams. His technical expertise includes ASIC design, hardware security, system security, computer architecture, and system design. Ben was previously a research faculty member at CMU and an Assistant Professor at the University of Pittsburgh. He has a BS and MS in Electrical Engineering from the University of Tennessee at Knoxville, and a Ph.D. in Electrical and Computer Engineering from CMU.