What is Attestation?
Attestation is a cryptographic proof that code executed inside a genuine Trusted Execution Environment (TEE). It provides verifiable evidence that: ✅ Your request ran in real TEE hardware (not simulated) ✅ The exact code that executed matches expected version ✅ No unauthorized modifications were made ✅ Hardware security features were activeThink of attestation as a “digital notary” - cryptographic proof that can be independently verified.
How Attestation Works
1. TEE Measurements
When code runs in TEE, the hardware measures:- Code hash - SHA-256 of the executable
- Data hash - Initial state of memory
- Platform configuration - CPU model, firmware version
- Security attributes - TEE mode, encryption status
2. Cryptographic Signature
TEE hardware signs the measurements with a private key that:- Never leaves the TEE
- Is unique to the TEE instance
- Chains to the CPU vendor’s root certificate
3. Verification
You can verify the attestation independently:- Check signature validity
- Verify certificate chain to Intel/AMD/NVIDIA
- Compare code hash to expected value
- Confirm hardware is genuine TEE
Getting Attestation Reports
For Phala Models
For Gateway (All Models)
Attestation Report Fields
Field | Description |
---|---|
type | TEE technology (Intel SGX, AMD SEV, NVIDIA H100) |
measurements.code_hash | SHA-256 hash of executed code |
measurements.data_hash | Hash of initial data/memory state |
measurements.platform | Hardware identifier |
measurements.firmware | TEE firmware version |
signature.algorithm | Signature algorithm (ECDSA, RSA) |
signature.value | Cryptographic signature |
signature.cert_chain | X.509 certificate chain |
timestamp | When attestation was generated |
nonce | Random value to prevent replay attacks |
verified | RedPill’s verification result |
Verification Process
Automatic Verification
RedPill automatically verifies attestations and returnsverified: true/false
. However, for maximum security, you should verify independently.
Manual Verification Steps
1
Verify Certificate Chain
Ensure certificates chain to CPU vendor’s root:
2
Check Signature
Verify the attestation signature:
3
Verify Code Hash
Compare code hash to expected value:
4
Check Timestamp
Verify attestation is recent:
Code Example: Full Verification
Expected Code Hashes
Current code hashes for Phala models (updated Jan 2025):Model | Code Hash (SHA-256) |
---|---|
phala/deepseek-chat-v3-0324 | b8g4c3d2e5f6g7h8... |
phala/gpt-oss-120b | c9h5d4e3f6g7h8i9... |
phala/gpt-oss-20b | d0i6e5f4g7h8i9j0... |
phala/qwen2.5-vl-72b-instruct | e1j7f6g5h8i9j0k1... |
phala/qwen-2.5-7b-instruct | a7f3b2c1d4e5f6g7... |
phala/gemma-3-27b-it | f2k8g7h6i9j0k1l2... |
Code hashes change when models are updated. Check the latest hashes via the API or GitHub.
TEE Technologies
NVIDIA H100 TEE (GPU)
Used for Phala confidential models:- Technology: NVIDIA Confidential Computing
- Hardware: H100 80GB with TEE support
- Attestation: GPU-based remote attestation
- Performance: 99% of native speed
Intel SGX (CPU)
Used for gateway TEE:- Technology: Software Guard Extensions
- Hardware: Intel Xeon Scalable (Ice Lake+)
- Attestation: DCAP (Data Center Attestation Primitives)
- Enclave Size: Up to 256GB
AMD SEV (CPU)
Alternative gateway TEE:- Technology: Secure Encrypted Virtualization
- Hardware: AMD EPYC processors
- Attestation: SEV-SNP attestation
- Memory: Full VM memory encryption
Compliance & Auditing
Regulatory Use
Attestation reports can serve as compliance evidence:- HIPAA: Prove data processed in secure environment
- GDPR: Demonstrate technical security measures
- SOC 2: Provide audit trail of security controls
- ISO 27001: Evidence of security implementation
Audit Trail
Maintain attestation records:Troubleshooting
Verification fails with 'Invalid certificate chain'
Verification fails with 'Invalid certificate chain'
Cause: Certificate chain doesn’t link to vendor rootSolution:
- Ensure you have latest root certificates
- Check certificate expiration dates
- Verify network allows access to certificate CRLs
Code hash doesn't match
Code hash doesn't match
Cause: Model was updated or you have outdated expected hashSolution:
- Check latest hashes on GitHub
- Verify you’re using correct model version
- Contact support if hash is unexpectedly different
Attestation timestamp too old
Attestation timestamp too old
Cause: Attestation report is staleSolution:
- Request fresh attestation
- Check system clock synchronization
- Reduce max age parameter if needed
'verified: false' in response
'verified: false' in response
Cause: RedPill’s automatic verification failedSolution:
- Check error details in response
- Verify manually to understand issue
- Contact support with request details
Best Practices
1
Always Verify Independently
Don’t rely solely on RedPill’s
verified
field. Implement your own verification.2
Check Freshness
Reject attestations older than 10 minutes to prevent replay attacks.
3
Pin Expected Hashes
Hardcode expected code hashes in your application and alert on mismatches.
4
Maintain Audit Logs
Save attestation reports for compliance and debugging.
5
Monitor Hash Changes
Subscribe to updates when model code changes affect hashes.
FAQs
Do I need to verify attestation for every request?
Do I need to verify attestation for every request?
No. Verify periodically (e.g., once per hour) or when deploying to production. Continuous verification adds overhead.
Can attestation be faked?
Can attestation be faked?
No, if properly verified. The signature requires the TEE’s private key which never leaves secure hardware.
What if code hash changes?
What if code hash changes?
RedPill publishes hash updates when models are upgraded. Subscribe to notifications or check GitHub releases.
Is attestation available for all models?
Is attestation available for all models?
- Phala models: Full attestation (gateway + model inference)
- Other models: Gateway attestation only
How often should I verify attestation?
How often should I verify attestation?
- Development: Once during integration
- Production: Periodically (hourly/daily)
- High-security: Every request or session