Verification Checklist
| Check | What It Proves | How to Verify |
|---|---|---|
| Nonce matches | Attestation is fresh, not replayed | Compare returned nonce with your generated nonce |
| GPU report is valid | Machine has genuine NVIDIA GPU in TEE mode | Verify report against NVIDIA’s root certificates |
| CPU report is valid | Machine’s CPU is in confidential compute mode | Verify report against AMD/Intel attestation services |
image_digest matches | Running container hasn’t been tampered with | Compare with expected digest from official release |
signing_address matches | Responses come from attested machine | Compare header with attestation report |
| Signature verifies | Response wasn’t modified in transit | Cryptographic signature verification |
Understanding the Attestation Report
Nonce Verification
The nonce prevents replay attacks. Always:- Generate a unique, random nonce for each attestation request
- Verify the returned nonce starts with what you sent (it gets padded to 64 hex characters)
- Never reuse nonces
GPU Attestation Report
Thegpu field contains NVIDIA’s hardware attestation:
- 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
- NVIDIA Multi-GPU Attestation API
- Submit the
evidence_listfrom the attestation response - The API validates the certificate chain and returns verification status
CPU Attestation Report
Thecpu field (when present) contains CPU-level attestation:
- 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
- t16z Proof Verifier
- Submit the
cpu.quotefrom the attestation response - The verifier validates the quote against Intel TDX attestation
Image Digest
Theimage_digest field contains the SHA256 hash of the container image running in the TEE:
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
Thesigning_address is the Ethereum-style public address the attested machine will use to sign inference responses:
- 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:| Header | Description |
|---|---|
text | The content that was signed (typically the response body) |
signature | Cryptographic signature over text |
signing_address | Public key that created the signature |
signing_algo | Signing algorithm (e.g., ecdsa) |
image_digest | SHA256 hash of the container image running in the TEE |
Verification Steps
- Verify signing address matches attestation
- Verify the cryptographic signature
ecdsa signatures (Ethereum-style):
- Verify content integrity
text matches the response you received:
Complete Verification Flow
Security Guarantees Summary
| Verification | Threat Mitigated |
|---|---|
| Nonce verification | Replay attacks - attacker cannot reuse old attestation reports |
| GPU attestation | Fake hardware - proves response came from genuine NVIDIA GPU in TEE |
| CPU attestation | Host compromise - proves VM memory is encrypted and isolated |
| Image digest match | Code tampering - proves container hasn’t been modified |
| Signing address match | Man-in-the-middle - proves response came from attested machine |
| Signature verification | Tampering - proves response wasn’t modified in transit |
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 send87ebbef3ceb69d2d6d7edc1b05c42ad9, 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
- Ensure you’re using the correct signing algorithm from the header
- Verify the
textheader encoding matches what you’re verifying - Check for any proxy or middleware that might modify responses
Signing Address Mismatch
Symptom: Responsesigning_address doesn’t match attestation.
Possible Causes:
- Attestation expired and machine rotated keys
- Request was routed to a different machine
What’s Next
- Quick Start API - For developers building integrations
- Confidential Chat - Use the web interface for private conversations