In original written answers to LDS, Berardino Carnevale explains what hardware attestation can establish, who must act on its results, and which questions AI teams should ask their cloud providers.
A cloud provider says its AI servers use secure boot. That leaves several practical questions unanswered: which components were checked, who evaluated the evidence, and what happens if a check fails?
In written answers to Lets Data Science, Berardino Carnevale, director of product management at Rambus, explains why those details matter to teams running sensitive AI workloads. His advice reaches beyond the chip itself: the operator must know which components were measured, check the evidence and decide what the machine may do.
The interview follows Rambus's September 14 announcement of CryptoManager Root of Trust supporting the Caliptra specification. The offering is aimed at semiconductor designers building security into data-center and AI chips. For a team renting cloud GPUs, the immediate value of the discussion is knowing what to request from the provider that controls the underlying platform.
Start with a changed piece of firmware
LDS asked Carnevale to explain a realistic security problem involving an AI server. He described an accelerator whose first firmware loaded after reset has been modified, either before deployment or through a compromised update process. Firmware is the low-level software that helps hardware operate.
His example illustrates the architecture; the answers did not identify it as a tested attack demonstration.
In the architecture he described, trusted code that cannot be changed starts a sequence of firmware measurements. Those measurements act as fingerprints of the code being loaded. They can be included in attestation evidence tied to the device's hardware-rooted identity. A verification service can compare them with approved reference values and identify an unexpected image.
Three terms describe different parts of that process. Measured boot records what is loaded. Secure boot enforces rules about which code may run. Attestation provides evidence that another party can evaluate. Measuring unexpected firmware does not, by itself, establish that the platform blocked it or prevented access to a workload.
Carnevale told LDS: "As with any measured-boot architecture, protection is limited to components included in the measurement and verification process."
That limit is important for an AI team. A check of accelerator firmware cannot establish the safety of an application or model that was never part of the check. Carnevale places responsibility for application behavior and runtime monitoring with higher software layers and system policies.
Where Rambus fits alongside Caliptra
Caliptra is an open-source hardware and firmware project for establishing device identity, measured boot and attestation inside data-center chips. A root of trust is the foundation on which those checks depend.
Carnevale describes CryptoManager as a commercial security subsystem that works alongside Caliptra, rather than a modified or redistributed version of the project. He says the Rambus subsystem can authenticate and measure firmware under its own control and provide relevant measurements to the broader attestation framework.
Rambus's product documentation and architecture diagram show the two as distinct components. CryptoManager combines a security processor, protected memory, key storage and cryptographic functions with interfaces to the rest of the chip. The diagram describes that chip-level arrangement; it does not depict the external verification service or a complete cloud workload policy.
Carnevale says the offering is available as design IP, including hardware-design code, firmware, an SDK, reference designs and integration guidance. Those are materials a chip designer integrates into a platform. They are not evidence that a particular cloud GPU instance exposes these capabilities to its customers.
LDS also asked which Caliptra core and firmware versions the offering supports and whether it has been validated in customer silicon. The answers did not identify exact versions or a named deployed implementation. Caliptra publishes a version matrix for its components, so compatibility needs to be checked for the particular combination being adopted.
The evidence needs a decision behind it
Carnevale's most useful distinction concerns what happens after a device produces an attestation report.
Carnevale told LDS: "Generating attestation evidence alone is not sufficient."
He describes verification infrastructure operated by a cloud provider, platform owner, administrator or another trusted service. Depending on the deployment, the result can influence whether a device receives sensitive keys, joins an approved pool or runs a workload. Those decisions require the operator to maintain reference measurements, policies and a response when checks fail.
The IETF's remote-attestation architecture separates two roles: a verifier evaluates the evidence, and a relying party uses the result to make its access decision. One service can perform both roles. Keeping the roles clear helps a customer ask who actually prevents an unacceptable device from receiving a key or workload.
Freshness also matters. Carnevale describes a challenge-response exchange in which a verifier sends a nonce, a value for that exchange, that the device includes in its signed response. Correctly checking the response helps detect reuse of an old report. It does not guarantee that the machine remains unchanged after the measurement.
For example, a policy could require an acceptable attestation result before releasing a workload's decryption key. That is an illustration of how a result could control access, not a customer deployment demonstrated in the interview. The useful question for a provider is whether such a rule is actually enforced, including when verification fails or the service is unavailable.
Certification and post-quantum claims need a defined scope
LDS asked for publishable security tests, comparative deployment results, certifications and implementation costs. Carnevale described certification objectives and integration support, but the answers did not supply comparative test results, a certificate identifier or a specific certified hardware-and-firmware configuration. He said power, area and performance figures are not publicly available.
Carnevale said: "Publicly available certification claims should therefore be limited to certifications that have been formally achieved for a specific hardware and firmware configuration."
Rambus's product page describes support and readiness for certification. That wording should not be read as proof that every implementation using the IP has already been certified. Likewise, the supplied material does not establish a measured deployment-time improvement or a comparative security advantage over another implementation.
The same care applies to post-quantum cryptography. Carnevale names algorithms including ML-DSA and ML-KEM among the configuration-dependent capabilities. Such algorithms serve particular functions, including signatures or key establishment; their presence does not establish that every part of an AI service is protected against a future quantum-capable attacker.
His answers divide maintenance responsibilities among Rambus, the chip designer and the system operator. Rambus supplies mechanisms for secure updates, key management and rollback protection. The chip designer integrates them, while operators set policies for trusted software versions, accepted algorithms and recovery. For an adopter, the follow-on question is who owns each step when a key or firmware version must be retired.
Three questions for an AI team's cloud provider
Carnevale offered three questions for readers who use accelerators rather than design them. They form a practical starting point for a provider conversation:
- •Can the platform provide hardware-backed attestation before my workload runs? Ask which components are measured, which root of trust produces the evidence and whether accelerator firmware is included. Request documentation and evidence for the actual service being purchased.
- •Who verifies that evidence, and what changes when a check fails? Ask how the result affects workload placement, key release or access. Evidence that is collected but never used in a decision provides a different assurance from an enforced admission policy.
- •What is outside the measured and verified boundary? Establish whether the checks cover firmware, the operating system, the virtualization layer, containers and the AI framework. Do not assume that checking one layer establishes the condition of every layer above it.
Carnevale says customers can often review documentation and request evidence where it is available. Verification services, workload admission, key-release policies and automated remediation generally depend on the provider's infrastructure. Extending measurements to more components may require platform changes or new silicon.
For an AI team, the interview turns a broad hardware-security claim into a more concrete purchasing discussion. The provider should be able to identify what it checks, explain what the result permits, and state which parts of the workload remain outside that assurance.
Reporting note
This LDS Exclusive is based on six written answers supplied directly to Lets Data Science by Berardino Carnevale through Rambus's communications representative. Rambus's announcement and product documentation provide company background; the Caliptra project and IETF documentation provide technical context. The firmware scenario is illustrative. LDS did not independently test the hardware or verify a customer deployment, and the supplied answers did not include comparative benchmarks or product-specific certification evidence.
Key Points #
- 1Carnevale says hardware attestation covers the components that are measured and verified; it does not establish the safety of every application or AI model.
- 2Cloud operators must verify the evidence and enforce policies for workload admission, key release and access. Generating a report alone is insufficient.
- 3Rambus supplied an architectural explanation and provider checklist, but no comparative benchmarks or product-specific certification evidence.
Scoring Rationale #
Original written answers from Berardino Carnevale explain the scope of hardware attestation, operator responsibilities and practical questions for AI teams evaluating cloud infrastructure.
Sources #
Original reporting, with the public references used alongside it.
LDS Exclusive
Reporting based on written answers given directly to Let's Data Science by Berardino Carnevale, Director of Product Management, Rambus.
Practice with real Telecom & ISP data
90 SQL & Python problems · 15 industry datasets
[Active Residential CustomersEasy](https://letsdatascience.com/problems/sql/active-residential-customers)
[Unlimited Fiber Plans 500Mbps+Medium](https://letsdatascience.com/problems/sql/unlimited-fiber-plans-above-500mbps)
[Customer Churn Risk AssessmentHard](https://letsdatascience.com/problems/sql/customer-churn-risk-assessment)
250 free problems · No credit card
See all Telecom & ISP problems