Developing A Security Framework For Chiplet-Based Systems

In a previous blog, From Monolithic SoCs to Chiplets: A New Hardware Security Paradigm, 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 SoC, device identity is often anchored in a single root of trust that owns key material and policy. In a chiplet platform, every security-relevant chiplet must have an identity, and the system must be able to validate it consistently.

Two provisioning patterns are common, and a robust platform often supports both depending on the chiplet class and supplier model.

Provisioning pattern A: Externally provisioned identity (certificate-based)

In this approach, each subordinate chiplet is provisioned with device-unique key material (or a keypair) in a controlled manufacturing environment, then issued a certificate that chains to a vendor root.

What matters is not only the mechanics of injection but the resulting property: the chiplet can present an identity credential that the platform can validate through a chain of trust. This enables multi-vendor operation, because the Main Security Chiplet can be configured with one or more vendor trust anchors (public keys, roots, or intermediates) and evaluate chiplet credentials against platform policy (allowed vendors, product IDs, security versions, lifecycle state, revocation status, etc.).

This pattern is operationally attractive when suppliers already operate a Public Key Infrastructure (PKI)-backed provisioning service or when the platform requires strong traceability and explicit certificate lifecycle management.

Provisioning pattern B: Silicon-derived identity (PUF-based or self-generated key derivation)

In this approach, the chiplet self-generates root key material from sensing its own silicon characteristics (for example, using a PUF-based mechanism) and then derives operational keys from that root. With sufficient cryptographic capability, the chiplet can further generate associated public key and request certification (or platform enrollment) without ever exporting the underlying root secret.

The platform still needs a trust chain: either the chiplet vendor provides a certification flow for the derived identity, or the platform performs a “local enrollment” where the Main Security Chiplet validates the chiplet via an authenticated onboarding step and binds that identity into its platform trust database. This approach reduces reliance on key injection logistics and can simplify supply-chain handling for certain chiplet classes, while still yielding a platform-usable identity.

The real requirement: Identity must be policy-bound

Regardless of the provisioning approach, the platform must ensure that “has an identity” is not the same as “is trusted.” Trust is a policy decision made by the platform authority. The system must be able to verify not only that the chiplet is genuine but also acceptable (correct vendor, model, not revoked, debug state allowed, most recent security version, etc.). That is why chiplet identity must connect to a platform-controlled trust chain and revocation mechanism.

Boot authentication across the chiplet system

Chiplets turn boot integrity into a distributed problem. If one chiplet runs untrusted firmware, it can become a covert channel, a DMA attacker, or a protocol manipulator, even if the rest of the platform boots securely.

A scalable model requires orchestrated secure boot:

1. The Main Security Chiplet establishes the platform boot policy. This includes what chiplets must be present, acceptable identity roots, allowed firmware images/versions, rollback constraints, and debug state constraints.
2. Each subordinate chiplet performs local secure boot anchored in its own Root of Trust. The subordinate chiplet must be able to verify its boot images, enforce anti-rollback, and lock down debug according to policy. The key point is that verification happens locally, because the subordinate chiplet must not depend on an unauthenticated external environment to become secure.
3. The platform collects evidence and makes a system decision. Each chiplet produces boot measurements and attestation evidence. The Main Security Chiplet evaluates this evidence against platform policy and either allows the platform to proceed, degrades capabilities, or blocks operation.

This is the difference between a secure chiplet and a secure chiplet platform. The multi-die chip (i.e., the system of chiplets) must be able to produce a coherent statement of integrity that represents the whole chiplet set, not just the main die.

Trust-chain infrastructure: Enabling multi-vendor platforms

A chiplet ecosystem requires a trust model that works when different dies originate from different suppliers. That implies a pragmatic trust-chain infrastructure:

• Multiple trust anchors: The platform may accept chiplets from multiple approved vendors, each with their own PKI root/intermediates.
• Policy mapping: Certificates and identity claims must map into platform policy (allowed SKUs, required security versions, lifecycle state, debug constraints, etc.).
• Revocation and update: The platform must support revocation (e.g., known-bad batches, compromised keys) and secure policy updates across product lifetime.
• Auditability: Especially in regulated markets, the platform needs evidence that the trust decision is consistent and enforceable.

Securing die-to-die communication: Identity-bound secure sessions

Protecting the interconnect is not just about encryption; it is also about binding communication sessions to authenticated chiplet identities and enforcing platform policy on which chiplets are authorized to communicate with each other.

A robust model requires:

• Mutual authentication between endpoints using chiplet identities validated against platform policy
• Session establishment using fresh ephemeral keys, with replay protection
• Confidentiality and integrity for data-in-motion across the package fabric
• Granular authorization (which chiplets may talk, which services may be invoked, under what lifecycle state)

In other words: Secure links should be the consequence of trust decisions, not a substitute for them.

Lifecycle security: Provisioning, debug, updates, and revocation

Chiplet systems increase operational complexity: multiple dies, potentially multiple firmware domains, and multiple vendors. The platform requires centralized lifecycle governance or it could quickly drift into inconsistent states that are difficult to secure and impossible to reason.

Key lifecycle controls include:

• Secure onboarding: Controlled acceptance of chiplets and enrollment into the platform trust database
• Debug policy enforcement: Debug must be explicitly governed
• Secure update: Updates must be authenticated and rollback-resistant per chiplet, yet coordinated at the platform level
• Revocation: The platform must be able to reject known-bad chiplets or identities, even after deployment
• RMA/decommissioning: Controlled teardown so field-handling does not leak secrets or weaken fleet integrity

These controls are not optional in markets like cloud infrastructure, automotive, and high-value AI accelerators, where the lifecycle is long and the incentive to attack is high.

Related links

• Rambus Root of Trust Solutions
• Rambus CryptoManager RT-6xx Root of Trust Family