2.1.2 Hardware Identity and Attestation

Allow approximately 20 minutes for the assigned excerpts, 15 minutes for this section, and 10 minutes for the exercise and answer review. Read each excerpt where its card appears; there is no need to read all four before starting.

The Direction of Trust

Section 2.1.1 separated authenticity, correctness, and completeness. This section examines a deployed mechanism that helps establish the first and supports selected checks of the second: remote attestation.

NVIDIA's H100 engineers state an important assumption explicitly: "Since the host or hypervisor is not trusted in CC mode". They explain that registers capable of compromising the guest's confidentiality or integrity must be protected from that host.

The central inversion for verification is this: the deployed confidentiality system protects a tenant from the owner or operator of the machine; a verification regime needs evidence that protects an outside authority from false claims by that operator.

This is an institutional inversion, not an entirely new technical adversary: the untrusted host is already part of NVIDIA's model. But the two uses demand different outcomes. A tenant can respond to failed attestation by withholding its model or data. A regulator must also determine whether every covered machine reported, whether the operator concealed devices, and what follows from silence or failure.

Attestation supplies part of that system. It does not supply the inventory, the duty to answer, or the sanction.

What Hardware Identity Establishes

Imagine a report with these claims:

I am device 4471. Secure boot is enabled, debug mode is disabled, my measured firmware has hash H, and this report answers challenge N.

This is an illustrative report, not a reproduction of an NVIDIA token.

The device signs the report using a key rooted in hardware. A certificate chain connects the signing key to a recognized issuer. A valid signature supports the claim that the report was produced by an entity holding the corresponding private key and that the signed contents have not been altered.

Calling that entity a particular physical device requires further trust: in manufacturing and certification, protection of the private key, and the binding between the key and the device. Believing the reported state additionally requires trust in the measurement and reporting components. A signature authenticates a report; it does not independently establish that its measurements are accurate or complete.

A root of trust is a component or function whose correct operation the system takes as a starting assumption. Different roots may measure the next boot stage, protect keys and measurements, or report evidence. A chain of trust extends that starting point to additional components. "Hardware-rooted" locates an initial trust assumption; it does not eliminate trust.

Secure Boot, Measured Boot, and Reference Values

Secure boot enforces a boot policy. Measured boot records what loaded. A system can use both: reject unauthorized components and record measurements of the components that actually loaded. Remote attestation conveys selected evidence about the system to another party for appraisal.

Microsoft, "Secure the Windows boot process", Microsoft Learn.

Reference values and legal approval are separate. A manufacturer-signed reference integrity manifest can associate a measurement with a recognized software release. The regulator must still decide whether that release is permitted for the regulated activity.

From Device Evidence to Regulatory Response

The device signs a report containing its identifier, boot state, and software measurements. Two separate judgments follow. First, the Verifier checks the evidence’s authenticity and freshness and evaluates the reported state against reference values and an appraisal policy. Second, the Relying Party uses that assessment to decide whether to release a key, permit an operation, or take another action. The measurements alone determine neither what counts as an acceptable state nor what should happen next. RFC 9334 distinguishes these roles from the Attester, which produces the evidence, even when one organization performs several roles.

RFC 9334, §§4.1 and 6.

For a verification regime, this distinction also helps locate failures: the device may report an incorrect measurement, the verifier may apply an unsuitable policy, or the decision-maker may draw an unsupported conclusion from a valid assessment.

The fifth stage shown here—regulatory review and response—is an addition made by the verification regime, not a separate role defined in RATS. An attestation result informs that process; it does not automatically establish a legal violation. Making that determination requires the applicable legal rule, sufficient evidence, and the authority to decide.

In the passport model, the Attester obtains an Attestation Result and presents it to the Relying Party. In the background-check model, the Relying Party forwards Evidence to a Verifier and receives the result. Either can support regulation; neither establishes that every covered device supplied Evidence.

Who Controls the Chain

For a deployment using NVIDIA's attestation infrastructure, control is distributed approximately as follows:

NVIDIA's SDK collects Evidence; a remote or local verifier appraises it; a RIM service supplies signed reference measurements; and certificate-status services support revocation checks. and RIM service.

NVIDIA’s attestation architecture

The adversary matters. A hostile application, a host administrator, and an owner with physical access have different capabilities. A compromised manufacturer, reference-value signer, or verifier attacks a different link again. An architecture that distrusts the operator may still depend on the manufacturer and the verifier.

An agreement must therefore allocate authority to issue and revoke credentials, publish reference values, approve software, change appraisal policy, and review disputed results. A software update changes the device's state. A new reference manifest describes a recognized state. Revocation changes whether a credential is acceptable. A regulatory decision changes which states are legally permitted. These actions need not occur together.

What Current GPU Attestation Can Show

NVIDIA's attestation claims can cover device identity, secure-boot state, debug configuration, firmware or VBIOS measurements, certificate checks, reference-value comparisons, and nonce matching. The claims actually present depend on the device, software, and workflow.

NVIDIA’s attestation claims schema

The assigned Blackwell example independently attests each GPU detected by the SDK and returns per-GPU entries. That example explicitly supplies no topology or switch attestation. This is a limit of the specific example, not a claim that no NVIDIA workflow can ever attest switches or topology.

A successful result can therefore support a bounded claim:

In response to this challenge, these eight identified GPUs supplied fresh Evidence whose selected measured states satisfied the verifier's policy.

It does not by itself establish that the eight GPUs were connected in the declared topology, that no additional GPU was concealed, that they performed training rather than inference, that they participated in one job, or that the accepted state persisted throughout the reporting period.

The confidentiality purpose can also constrain observation. NVIDIA's H100 CC-On mode disables performance counters to prevent their use in side-channel attacks. This illustrates a potential tension: protecting a tenant's workload from observation can remove signals that a compute-use verifier would want. A verification design that depends on those counters would need an additional measurement mechanism; a valid attestation report cannot substitute for missing telemetry.

Threat-Model Boundaries: Battering RAM

Battering RAM used a low-cost DDR4 interposer that behaved normally during startup and changed memory-address mappings later. Against AMD SEV-SNP, the researchers demonstrated how a manipulated virtual machine could present an expected launch measurement and attest as genuine.

The project discusses attackers such as a rogue cloud employee, an infrastructure provider with physical access, or someone tampering with the supply chain. These capabilities matter: an attacker who can alter hardware connections is not equivalent to an attacker confined to software interfaces.

The report can remain cryptographically authentic: a genuine attestation component signed it. The failure concerns the connection between the measured state and the execution the relying party intended to trust.

The demonstrated attacks concern CPU confidential-computing systems, including Intel SGX and AMD SEV-SNP, using DDR4. They are not a demonstrated attack on NVIDIA GPUs. The lesson is to examine the measurement assumptions and physical-access threat model before interpreting a valid report.

Exercise — Appraise the Result

The following is a hypothetical regulation and simplified evidence summary, not an actual NVIDIA token or existing law.

Every accelerator installed at Site A must be declared. No cluster may contain more than eight GPUs. Each operating GPU must use regulator-approved stack F and run monitoring component M.

At 09:00 on Monday, the operator sends the National Compute Inspectorate an Attestation Result produced by NVIDIA Remote Attestation Service. It contains eight GPU entries with distinct device identifiers. For each entry, certificate and revocation checks pass, the nonce matches, secure boot is enabled, debug mode is disabled, and the measured VBIOS and driver match NVIDIA reference values associated with stack F.

Those entries are the whole of the Attestation Result.

The operator states:

This proves that Site A contained exactly eight GPUs in the approved topology and complied with the regulation throughout Monday.

Write short answers before opening the answer key.