verifier: add local NVIDIA Blackwell GPU attestation

[chalabi2]

Why

Trustee routes Blackwell GPU evidence to NRAS but rejects it in the local
verifier. That makes Blackwell attestation depend on a licensed NVIDIA service
and per-attestation network access.

What changed

• accept Hopper and Blackwell in the local NVIDIA verifier
• parse Blackwell TCG DICE DiceTcbInfo and bind fwids[0] to the report
• preserve the existing Hopper FWID path and public Hopper APIs
• reject unconsumed report, opaque-data, and DICE bytes
• keep NVIDIA policy lookup on the existing gpu, switch, and ppcie
  classes while emitting architecture-specific EAR submodule labels
• add fail-closed local Blackwell rules to default_gpu, backed by five RVPS
  reference values
• add real RTX PRO 6000 report, certificate-chain, claims, and
  signed-RIM-backed fixtures
• document reference-value requirements, combination semantics, and fixture
  provenance

Validation

• real RTX PRO 6000 Blackwell Server Edition evidence
• nvtrust 2026.06.04.001 returned a successful local attestation
• NVIDIA Attestation SDK with NVAT 1.2.2 returned result code 0
• Trustee FWID and all 64 measurements match both NVIDIA implementations
• all 41 active driver and VBIOS signed-RIM measurements match Trustee claims
• all 17 opaque field IDs in the captured report are known to Trustee
• valid, root-only, and missing-intermediate Blackwell certificate-chain cases
• malformed DICE, opaque-data, and report-suffix regression cases
• missing, null, empty, wrong-type, and mismatched cases for all five Blackwell
  RVPS reference values
• broker-level proof that custom_gpu is selected while the EAR key is
  nvidia-blackwell
• verifier: 34 passed, 2 NRAS network tests ignored
• attestation-service: 28 passed
• Clippy passes with warnings denied for both affected crates
• existing Hopper claims, certificate-chain, and CoCo evidence tests pass

Compatibility

The original public Hopper constructor, certificate verifier, and FWID helper
retain their original signatures. New architecture-aware APIs are additive.

Policy lookup remains default_gpu, default_switch, and default_ppcie, or
the corresponding operator-selected *_gpu, *_switch, and *_ppcie
policies. Architecture-specific names such as nvidia-blackwell are EAR
appraisal labels only, so an existing hardened GPU policy is not bypassed.

Remaining hardware validation

• deploy the immutable image to an isolated canary and run the complete guest
  to AS to KBS flow, including test secret and test-volume DEK release
• prove that a changed RVPS measurement denies release
• validate B200 or B300 evidence before claiming those models are tested
• validate multi-pGPU configurations separately
• capture the CC-mode off/on transition only during an approved maintenance
  window because NVIDIA nvtrust issue 150 can require a host reboot to recover

The public certificate fixture contains persistent device-certificate serials
and can be correlated with the captured physical GPU. It contains no private
key, workload secret, DEK, host name, or captured device UUID, and cannot
satisfy a fresh nonce challenge. The hardware owner should approve retaining
those persistent identifiers in public repository history.

[chalabi2]

Review and canary-image update:

• Follow-up review fixes are in signed commit 366d571786f80df8714ea3481308a5cf1317f1b3.
• Public amd64 test image: docker.io/josephchalabi/trustee-blackwell-pr1:366d571
• Immutable image: docker.io/josephchalabi/trustee-blackwell-pr1@sha256:effe7a55553d569e0f68eb78355438c9916b8121bd191b3a6bebda353311b450
• Features: grpc-bin,snp-verifier,nvidia-verifier
• The public digest was pulled anonymously and grpc-as --help completed successfully. The OCI index includes SPDX SBOM and SLSA provenance attestations.

This remains an experimental canary image. It is not ready for production promotion until the isolated RTX PRO 6000 guest-to-AS-to-KBS secret and storage-DEK flow, including a negative RVPS policy test, passes on hardware.