Rambus adds production security layer to Caliptra

Rambus has introduced a production-oriented CryptoManager Root of Trust implementation for system-on-chips using the open Caliptra security framework, adding hardware, software, lifecycle management, and security orchestration intended to carry a common root-of-trust architecture into commercial data-centre and AI silicon.

The subsystem operates alongside the Caliptra core rather than replacing it. Rambus combines a secure RISC-V processor, protected memory, secure key and data storage, cryptographic accelerators, and secure interfaces with drivers, APIs, firmware, system-level applications, and integration support. The aim is to address the engineering work that begins after a semiconductor team has adopted the underlying Caliptra specification.

Caliptra originated through the Open Compute Project and is now developed within the CHIPS Alliance. It provides a common silicon root-of-trust architecture for device identity, measured boot, and attestation across CPUs, GPUs, AI accelerators, DPUs, networking devices, and other infrastructure components. Common behaviour is particularly useful in heterogeneous servers where equipment from several semiconductor suppliers may need to establish trust within one platform.

A reference root of trust, however, is only part of a production security architecture. A commercial SoC also needs protected key provisioning, firmware update processes, lifecycle controls, policy enforcement, cryptographic services, software interfaces, manufacturing integration, and mechanisms for responding to new threats after deployment. Qualification and certification add another layer when devices are intended for infrastructure handling commercially or nationally sensitive data.

Rambus is addressing that gap by retaining the unmodified Caliptra core while placing a broader security subsystem alongside it. Dedicated drivers and security applications extend visibility into the rest of the SoC, allowing policies and lifecycle functions to operate beyond the root-of-trust boundary rather than treating Caliptra as an isolated block.

Supported functions include secure boot, firmware authentication and update, device identity, attestation, key provisioning, secure communications, and general cryptographic services. Sensitive assets remain within the trusted subsystem, while hardware-enforced isolation is intended to prevent other parts of the chip from directly accessing keys, credentials, or security operations.

Cryptographic agility is another part of the design. Rambus supports conventional algorithms alongside post-quantum and regional cryptographic schemes, giving semiconductor developers a route to change or extend algorithm support over a product lifecycle. That is becoming increasingly relevant for infrastructure silicon expected to remain deployed for many years while cryptographic requirements change around it.

Physical attack resistance is equally important once a security block moves from specification into hardware. Rambus includes countermeasures against side-channel analysis and fault injection, where an attacker attempts to recover secrets or alter execution by observing electrical behaviour or deliberately disturbing voltage, timing, or other physical operating conditions.

The problem grows with semiconductor heterogeneity. A contemporary AI accelerator or data-centre SoC can contain general-purpose processors, specialised compute engines, networking interfaces, memory controllers, chiplet links, service processors, firmware stores, and several externally managed interfaces. Each block introduces additional paths through which configuration, firmware state, device identity, or cryptographic material may become security-sensitive.

Recent Caliptra implementation work has also addressed physical primitives beneath the open framework, including device-unique secrets and protected key storage. Rambus is approaching the deployment problem at subsystem level, adding a programmable security processor and orchestration layer around the common Caliptra foundation.

Certification readiness is part of that positioning. Rambus identifies FIPS 140-3 and SESIP among the security frameworks relevant to the architecture, although suitable IP does not automatically confer certification on the finished semiconductor. Integration, firmware, configuration, verification evidence, manufacturing processes, and the complete device implementation remain part of the assessment.

The practical question for SoC teams is therefore how much engineering the supplied framework removes. Caliptra can provide common device identity, measurement, and attestation behaviour, but a production programme still has to connect those functions to manufacturing provisioning, boot architecture, host software, field-update systems, fleet management, and incident response.

Providing those layers through one supported subsystem could shorten the deployment route for semiconductor companies without a large internal hardware-security organisation. It can also reduce the risk of each Caliptra adopter building a different set of proprietary interfaces around what was intended to be an interoperable security foundation.

Rambus is targeting CPUs, GPUs, AI accelerators, DPUs, networking devices, and other infrastructure silicon. As Caliptra moves deeper into production hardware, the differentiating work will increasingly sit beyond the presence of the root of trust itself: how securely it is provisioned, how widely it can enforce policy, how readily cryptography can change, and how well the complete device withstands both software and physical attack throughout its operational life.