A security model where every chiplet can prove identity, boot correctly, and communicate securely without becoming the weak link.
In previous blogs, From Monolithic SoCs to Chiplets: A New Hardware Security Paradigm, and Developing a Security Framework for Chiplet-based Systems, we discussed why chiplets change the game from a security perspective, and why security must be addressed at a platform-level in a chiplet-based system.
In a monolithic device, trust is often implicitly bounded by the die itself: sensitive assets, boot flow, firmware integrity, debug policy, and key management all sit inside one silicon boundary. In a chiplet system, that assumption breaks. Security can no longer be a property of “the SoC.” It must become an explicit property of the chiplet fleet and of the trust relationships between its parts, because the attack surface now includes chiplet substitution, weak-chiplet compromise, and exploitation of package-level die-to-die links.
That is why the security model described in the previous blogs converges on a specific architectural shape: the platform needs a single authority that makes consistent trust decisions (across vendors, versions, and lifecycle states), and it needs pervasive enforcement so that every chiplet can prove identity, boot correctly, and communicate securely without becoming the weak link.
An architecture that achieves these goals has trust anchored in a Main Security Chiplet (MSC) with a full-featured hardware root of trust. Each subordinate chiplet can then be secured with lighter weight hardware root of trust solutions. We’ll more fully describe the role of these two root of trust types in the sections that follow.
At the center of the platform, an MSC integrates a full-featured root of trust. This root of trust is the platform’s security control pivot: it is where system-wide trust becomes concrete and manageable. This directly addresses the key “distributed trust with centralized authority” requirement discussed earlier, as without a single policy authority, a multi-chiplet platform fragments into inconsistent rules and exploitable gaps between dies.
In practice, the MSC root of trust closes the loop on the four key system security goals by acting as the platform’s trust decision-maker and orchestrator. For authenticity, it evaluates chiplet identities against platform policy, supporting multi-vendor ecosystems by anchoring trust in approved trust roots (and intermediates) and enforcing revocation and allow/deny rules consistently. For boot integrity, it sets the system boot expectations and validates that the platform only enters privileged states when the required chiplets have booted into approved, non-rolled-back configurations. For protected communication, it establishes the principle that secure links are not just encrypted pipes but identity-bound sessions, meaning the right chiplets are talking to each other under the right lifecycle constraints. For lifecycle security, it becomes the policy authority for onboarding, debug enablement, update rules, and decommissioning, ensuring these controls remain coherent across the fleet rather than collapsing to whatever the weakest chiplet happens to allow.
This is also what connects the MSC root of trust to the trust-chain infrastructure described in previous blogs: in a multi-vendor world, “having an identity” is not the same as “being trusted.” The MSC root of trust is where identity claims, certificates, lifecycle states, and revocation information turn into a platform decision that is enforceable and auditable.
Across the remaining chiplets, the platform integrates root of trust solutions that are intentionally lighter and designed to be replicated broadly, making it suitable for subordinate chiplets that are area- and power-constrained but still security-relevant (I/O, accelerators, connectivity, memory controllers, etc.). This is the architectural response to the “weak chiplet problem”: instead of assuming that non-central chiplets are benign, the platform ensures each one has a minimum security foundation so that compromise of a peripheral die does not automatically become a compromise of the entire system.
This lighter-weight root of trust is best understood as the platform’s security subordinate: it gives each chiplet the local capabilities needed to participate safely in the platform trust pipeline. It anchors protected secrets and a device identity on the chiplet, supports local secure boot enforcement appropriate to the chiplet’s role, and enables secure session establishment for die-to-die messaging so that traffic that used to be “internal” now gains confidentiality, integrity, and replay resistance across package links. Importantly, this does not require the root of trust to be “customer programmable” in the traditional sense: in many integrations it operates as a host-controlled security block, where the subordinate chiplet’s main processor (or a platform security manager) enables and configures the required services through a defined command/response (mailbox) interface and associated drivers/firmware. In addition, the lightweight root of trust enables each chiplet to produce measurements or evidence that can be consumed by the platform authority, so platform attestation can reflect the integrity of the whole assembly rather than only the main die. Additionally, the root of trust enables each chiplet to produce measurements or evidence that can be consumed by the platform authority, so platform attestation can reflect the integrity of the whole assembly rather than only the main die.
This is also where the provisioning requirement becomes operational. Different chiplets and supplier models will favor different ways to realize identity, and lightweight root of trust can sit cleanly in all of them. If a subordinate chiplet self-generates an identity value (e.g., via a PUF-based approach), the root of trust provides the secure boundary that consumes that root material safely, derives operational keys, and prevents secrets from leaking into the rest of the SoC logic. If the chiplet needs a subordinate TRNG to generate keys locally, the root of trust provides random number generation, protected storage and controlled usage of those keys, binding them to lifecycle state. If the ecosystem requires externally provisioned keys or certificates, the root of trust provides the secure import/handling path and ensures the injected material is used only under enforced policy. In all cases, the outcome matches the earlier requirement: the chiplet gains an identity that is real, hardware-backed, and usable for mutual authentication and secure session setup, while the central MSC root of trust remains the component that decides whether that identity is acceptable for this platform.
Rambus offers two root of trust families that ideally fit the bill for the roles of MSC root of trust and a lightweight root of trust for subordinate chiplets: the CryptoManager RT-6xx Root of Trust family for the former, and the RT-1xx family for the latter.
RT-6xx provides the single authority that keeps the platform consistent: one policy, one trust decision, one lifecycle governance model, one system-level attestation story. In principle, RT-6xx could also be instantiated in subordinate chiplets. However, most subordinate chiplets do not require the full policy and orchestration capabilities of the main security controller. RT-1xx provides a lightweight, area-efficient local root of trust that enables each chiplet to authenticate itself, boot correctly, establish protected sessions, and produce evidence, without replicating the entire system authority stack.
Together, this model ensures that security is not concentrated in the main chiplet alone (which would invite weak-chiplet attacks) and not fragmented across independent policies (which would invite inconsistency and certification/operations failure). The result is a security architecture that matches chiplet economics and modularity while preserving the end-to-end security properties required in high-value deployments.
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply