Skip to main content

Verification Checklist

Understanding the Attestation Report

Nonce Verification

The nonce prevents replay attacks. Always:
  1. Generate a unique, random nonce for each attestation request
  2. Verify the returned nonce starts with what you sent (it gets padded to 64 hex characters)
  3. Never reuse nonces

GPU Attestation Report

The gpu field contains NVIDIA’s hardware attestation:
This proves:
  • The GPU is a genuine NVIDIA device (architecture identified, e.g., “HOPPER”)
  • The GPU is running in Confidential Computing mode
  • The GPU’s firmware and configuration are in a known-good state
  • Multiple GPUs may have multiple evidence entries in evidence_list
Verification: Use NVIDIA’s attestation API to verify the GPU evidence list:
  • NVIDIA Multi-GPU Attestation API
  • Submit the evidence_list from the attestation response
  • The API validates the certificate chain and returns verification status

CPU Attestation Report

The cpu field (when present) contains CPU-level attestation:
This proves:
  • The CPU is running in a Trusted Execution Environment (AMD SEV-SNP or Intel TDX)
  • The VM’s memory is encrypted and isolated from the host
Verification: Use the proof verifier to verify the CPU attestation quote:
  • t16z Proof Verifier
  • Submit the cpu.quote from the attestation response
  • The verifier validates the quote against Intel TDX attestation

Image Digest

The image_digest field contains the SHA256 hash of the container image running in the TEE:
This allows you to verify that the expected code is running inside the TEE. Verification: Compare the image_digest with the expected digest published in the latest official release. If the digests match, you can be confident the running container hasn’t been tampered with.

Signing Address

The signing_address is the Ethereum-style public address the attested machine will use to sign inference responses:
This key is generated inside the TEE and its binding to the attestation report proves that:
  • Only the attested machine holds the private key
  • Responses signed with this key came from the attested hardware

Verifying Response Signatures

Every confidential inference response includes signature headers:

Verification Steps

  1. Verify signing address matches attestation
  1. Verify the cryptographic signature
For ecdsa signatures (Ethereum-style):
  1. Verify content integrity
Ensure the signed text matches the response you received:

Complete Verification Flow

Security Guarantees Summary

Troubleshooting

Nonce Mismatch

Symptom: Returned nonce doesn’t start with the one you sent. Cause: Possible replay attack, caching issue, or request routing error. Note: The returned nonce is padded with zeros to 64 hex characters. For example, if you send 87ebbef3ceb69d2d6d7edc1b05c42ad9, you’ll receive 87ebbef3ceb69d2d6d7edc1b05c42ad900000000000000000000000000000000. Solution: Use startswith() for comparison instead of exact match. Generate a new nonce and retry if verification fails. If persistent, contact support.

Signature Verification Fails

Symptom: Cryptographic signature doesn’t verify. Possible Causes:
  • Response was modified in transit
  • Encoding mismatch in signed text
  • Wrong signing algorithm used for verification
Solution:
  1. Ensure you’re using the correct signing algorithm from the header
  2. Verify the text header encoding matches what you’re verifying
  3. Check for any proxy or middleware that might modify responses

Signing Address Mismatch

Symptom: Response signing_address doesn’t match attestation. Possible Causes:
  • Attestation expired and machine rotated keys
  • Request was routed to a different machine
Solution: Re-request attestation before inference. Attestation should be refreshed periodically.

What’s Next