What is Signature Verification?
Signature verification provides cryptographic proof that:- ✅ A specific request was processed in TEE
- ✅ The response hasn’t been tampered with
- ✅ Request and response are cryptographically linked
- ✅ Execution happened at a specific time
How It Works
Signature Generation
- Request enters TEE
- TEE processes request and generates response
- TEE creates signature over:
- Request ID
- Request hash (SHA-256 of your prompt)
- Response hash (SHA-256 of model output)
- Timestamp
- Model used
- Signature is created with TEE’s private key
- Response returned with signature ID
Signature Retrieval
After receiving a response, fetch its signature:Signature API Response
Complete Verification Workflow
To fully verify a signature, you need to:- Verify request/response hashes match
- Recover the signing address from the signature
- Fetch fresh attestation for that signing address
- Verify the complete attestation (proving the signer is genuine TEE)
Verification Process
Step-by-Step Verification
1
Get Signature for Response
After making a request, fetch its signature:
2
Verify Request/Response Hashes
Confirm the signature covers your actual request and response:
3
Recover Signing Address
Critical step: Recover the address that created this signature.For ECDSA signatures (most common):For Ed25519 signatures, use appropriate Ed25519 verification libraries.
4
Generate Nonce for Attestation
Generate a fresh random nonce to fetch attestation:
5
Fetch Attestation for Signing Address
Get fresh attestation proving the signing key belongs to verified TEE:
6
Verify Complete Attestation
Most critical step: Verify the full attestation proving this signing key belongs to genuine TEE.See Attestation Guide for complete verification steps:When all checks pass, you’ve proven end-to-end that your response came from verified TEE hardware.
- Verify Intel TDX quote - Proves genuine Intel CPU with TEE
- Verify report data binding - Proves signing address and nonce are embedded in hardware attestation
- Verify NVIDIA GPU attestation - Proves genuine NVIDIA GPU with nonce
- Verify Docker compose manifest - Proves exact software configuration
- Verify Sigstore provenance - Proves containers built from expected repos
7
Reconstruct Message
Build the message that was signed:
8
Verify Signature
Verify ECDSA signature:
9
Verify Certificate Chain
Ensure public key certificate chains to TEE root:
Complete Code Example
Signature Algorithms
RedPill supports multiple signature algorithms:| Algorithm | Curve/Key Size | Security Level | Use Case |
|---|---|---|---|
ecdsa | secp256k1 | 128-bit | Default, Bitcoin-compatible |
ecdsa-p256 | NIST P-256 | 128-bit | Standards-compliant |
rsa | RSA-2048 | 112-bit | Legacy compatibility |
Use Cases
1. Compliance Auditing
Keep signed records for regulatory compliance:2. Non-Repudiation
Prove a specific response came from RedPill TEE:3. Response Integrity
Detect tampering with responses:4. Dispute Resolution
Resolve disputes with cryptographic proof:Best Practices
1. Verify Every Critical Request
1. Verify Every Critical Request
For high-value or sensitive requests, always verify signatures:
2. Store Signatures for Audit
2. Store Signatures for Audit
Keep signatures for compliance:
3. Check Timestamp Freshness
3. Check Timestamp Freshness
Reject old signatures to prevent replay:
4. Verify Certificate Chain
4. Verify Certificate Chain
Always verify public key chains to TEE root:
5. Use Idempotency Keys
5. Use Idempotency Keys
Prevent duplicate processing:
Troubleshooting
Signature not found for request ID
Signature not found for request ID
Cause: Signatures are generated asynchronouslySolution:
- Wait 1-2 seconds after request
- Retry signature retrieval
- Check request ID is correct
Request hash doesn't match
Request hash doesn't match
Cause: Request content was normalized differentlySolution:
- Ensure consistent JSON serialization (sort keys)
- Remove whitespace
- Use same encoding (UTF-8)
ECDSA verification fails
ECDSA verification fails
Cause: Incorrect public key format or signature parsingSolution:
- Verify you’re using correct curve (secp256k1)
- Check signature is properly hex-decoded
- Ensure public key is uncompressed format
Certificate chain verification fails
Certificate chain verification fails
Cause: Missing root certificates or expired intermediatesSolution:
- Update root certificate bundle
- Check certificate expiration dates
- Verify internet access to CRL endpoints
Signature vs Attestation
| Feature | Signature | Attestation |
|---|---|---|
| Scope | Single request/response | Entire TEE instance |
| Granularity | Per-request | Per-model or gateway |
| Proves | This response is authentic | Code runs in TEE |
| Frequency | Every request | Periodic (hourly/daily) |
| Use Case | Non-repudiation, audit | Trust establishment |
| Performance | Fast (~1ms) | Slower (~100ms) |
FAQs
Are signatures generated for all models?
Are signatures generated for all models?
Yes, but signatures are most useful for Phala models where both gateway and inference are TEE-protected.
How long are signatures stored?
How long are signatures stored?
Signatures are available for 90 days. Download and store if needed longer.
Can signatures be verified offline?
Can signatures be verified offline?
Yes! Once you have the signature and TEE root certificates, verification is fully offline.
What if signature verification fails?
What if signature verification fails?
Either the response was tampered with, or there’s a verification implementation error. Check your code first, then contact support.
Do signatures add latency?
Do signatures add latency?
Signature generation adds ~1ms. Retrieval is a separate API call you control.