NVIDIA Opaque Data Format#

Opaque data is vendor-defined data an NVIDIA GPU returns in its SPDM measurement response. This document specifies its binary layout and the value-type system that describes each entry. For how a RIM references these values, see Opaque Data RIM Attributes.

Required Verifier Version#

NVIDIA drivers released with CUDA 13.5 and later will emit versioned opaque data. Older verifiers cannot process this format. Use one of the following:

attestation-sdk >= 2.0.0
NRAS attest endpoint v4 with claims version 4.0

Older verifiers and NRAS endpoints will fail to process evidence with versioned opaque data.

Users of the deprecated Python SDK in nvtrust must upgrade to the attestation-sdk.

Blob layout#

A verifier selects the layout by checking the first six bytes for the magic value.

Versioned format (new)#

The blob begins with a 12-byte header, followed by packed entries.

                                  Major
                                  |   Minor
                                  |   |   Patch
                                  |   |   |   Padding
+---+---+---+---+---+---+---+---+---+---+---+---+
|'N'|'V'|'D'|'A'|'O'|'D'| 0 | 0 | 2 | 0 | 0 | 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+
 \_______ Magic _______/ Profile \__ Version __/

Offset	Size	Field	Value
0	6	Magic	ASCII `NVDAOD`.
6	2	Profile	`u16`, MUST be `0`.
8	4	Version	Four bytes: Major, Minor, Patch, Padding (one byte each).

The example bytes above encode profile 0 and version 2.0.0.

Note: The four version bytes are serialized in the order shown (Major first) regardless of platform endianness. All fields after the header are little-endian.

Legacy format (no magic)#

A blob whose first six bytes are not NVDAOD has no header. Its version comes from the OPAQUE_DATA_VERSION entry (see below): that value is the MAJOR version. There is no MINOR or PATCH component on the legacy path.

Entry format#

Entries are packed back-to-back until the blob’s declared length is consumed. Multi-byte fields are little-endian.

Versioned entry#

+----------+---------------+----------+--------------------------+
| dataType | dataValueType | dataSize | payload (dataSize bytes) |
|  u16 LE  |    u16 LE     |  u16 LE  |                          |
+----------+---------------+----------+--------------------------+
    2 B          2 B           2 B            dataSize B

Legacy entry#

+----------+----------+--------------------------+
| dataType | dataSize | payload (dataSize bytes) |
|  u16 LE  |  u16 LE  |                          |
+----------+----------+--------------------------+
    2 B        2 B            dataSize B

`dataType` (data ID)#

dataType is a u16 that labels the entry. It is the same identifier a RIM encodes as index − 0x1000 (see Opaque Data RIM Attributes), so it is the key a verifier uses to pair a RIM reference value with the matching runtime entry.

The identifier space is an NVIDIA registry. This document commits to the following values:

ID (hex)	ID (dec)	Name	Notes
`0x03`	3	`DRIVER_VERSION`	Driver version string (`char[16]`). Value type `0x86`.
`0x06`	6	`VBIOS_VERSION`	Two little-endian `u32`s (major, minor). Value type `0x86`.
`0x22`	34	`OPAQUE_DATA_VERSION`	`u16`. On the legacy path its value is the MAJOR version (no MINOR or PATCH).
`0x25`	37	`FSP_UCODE_MIN_SVN`	FSP microcode minimum SVN. Value type `0x87`.
`0xFF`	255	`INVALID`	Reserved sentinel; a verifier treats it as an unexpected field.

Some identifiers carry a structured payload the value type does not describe, so a verifier parses them by identifier rather than by dataValueType. DRIVER_VERSION and VBIOS_VERSION above are examples; another is SWITCH_IDS, an array of switch identifiers.

`dataValueType` (value type)#

dataValueType describes how to interpret the payload. It follows the DMTF SPDM measurement value-type encoding:

Bits	Meaning
7	`1` = raw value, `0` = digest.
6:0	Category (below).

Category	Meaning
`0x00`	Immutable ROM
`0x01`	Mutable Firmware
`0x02`	Hardware Configuration
`0x03`	Firmware Configuration
`0x04`	Measurement Manifest
`0x05`	Device Mode
`0x06`	Version-like (NVIDIA extension)
`0x07`	SVN (NVIDIA extension)

This document commits to one code:

minSvn = 0x87: bit 7 set (raw value) plus category 0x07 (SVN).

Version semantics#

A verifier MUST fail if the evidence’s Major version exceeds the maximum version it supports. Minor and Patch changes are backward-compatible and MUST NOT cause a supported Major version to be rejected.

Verifier algorithm#

Parsing#

If the first six bytes are NVDAOD, take the versioned path: read the profile and version from the header, then parse entries with the three-field header (dataType, dataValueType, dataSize).
Otherwise take the legacy path: parse entries with the two-field header (dataType, dataSize), and read the MAJOR version from the OPAQUE_DATA_VERSION entry (no MINOR or PATCH).
For every entry, retain both dataType and dataValueType. Do not eagerly validate the value type at parse time; deferring this preserves forward compatibility with types added later.
Compare the Major version against the maximum supported version and fail if it is higher.

Comparison#

For each opaque reference value the RIM declares:

Find the evidence entry whose dataType matches. If none exists, record a mismatch.
Check the value type. minSvn is the only type supported today: the entry’s dataValueType must be 0x87, otherwise record a mismatch.
Evaluate the predicate. For minSvn, the reported value must be greater than or equal to the RIM floor (evidence >= RIM minSvn), otherwise record a mismatch.

Attestation result claims#

The attestation result carries two claims for opaque data. For the full claim set, see the GPU Claims guide.

`x-nvidia-attester-claims`#

A JSON object of the key/value pairs for each opaque value whose RIM record has includeInResult="True". The value comes from the evidence and is emitted whether or not it matches the RIM, so a relying party can build policy around the reported number.

"x-nvidia-attester-claims": {
  "EXAMPLE_SVN": 4
}

`x-nvidia-mismatch-opaque-data-records`#

A JSON array describing mismatched opaque-data entries. Each object has:

Key	Type	Meaning
`id`	Integer	`dataType` of the mismatched entry.
`name`	String	The name as referenced in the RIM.
`goldenType`	String enum	Reference value type. `MIN_SVN` is the only supported value.
`goldenValue`	Integer or string	Reference value from the RIM.
`runtimeType`	String enum	Same domain as `goldenType`, derived from the runtime evidence. Unset if the entry is missing from evidence.
`runtimeValue`	Integer or string	Same domain as `goldenValue`, derived from the runtime evidence. Unset if the entry is missing from evidence.

When the evidence lacks the value entirely, only the golden fields are present:

"x-nvidia-attester-claims": {},
"x-nvidia-mismatch-opaque-data-records": [
  {
    "id": 100,
    "name": "EXAMPLE_SVN",
    "goldenType": "MIN_SVN",
    "goldenValue": 5
  }
]

When the evidence reports a value below the RIM floor, the runtime fields are populated and the value is also emitted as an attester claim:

"x-nvidia-attester-claims": {
  "EXAMPLE_SVN": 4
},
"x-nvidia-mismatch-opaque-data-records": [
  {
    "id": 100,
    "name": "EXAMPLE_SVN",
    "goldenType": "MIN_SVN",
    "goldenValue": 5,
    "runtimeType": "MIN_SVN",
    "runtimeValue": 4
  }
]