Tenzro
Whitepaper — Security

TEE Security on Tenzro

Tenzro Network supports five TEE vendors with real attestation chains verified — Intel TDX, AMD SEV-SNP, AWS Nitro, NVIDIA GPU CC, and Intel Tiber Trust Authority. Confidential compute, sealed custody, attested execution. AES-256-GCM enclave encryption with HKDF-SHA256 key derivation. PQ-hybrid signing for post-quantum custody.
Crate
tenzro-tee
Vendors
5 (TDX, SEV-SNP, Nitro, NVIDIA, Tiber)
Symmetric
AES-256-GCM
Asymmetric
X25519 + ML-KEM hybrid
01

Why TEEs

ZK proofs verify what was computed but reveal nothing about privacy beyond what the circuit exposes. TEEs verify where computation happened and seal inputs and intermediate state from the host. Tenzro uses both: ZK proves the arithmetic; TEEs protect the data and keys.

For AI inference over confidential prompts, custody of user keys, sealed datasets in training, and verifiable sensor capture — TEEs are not optional. Tenzro treats them as first-class infrastructure with real attestation chains, not promises.

02

Five vendors, real attestation

Intel TDX — IntelTdxProvider with real /dev/tdx-guest ioctl, TDREPORT → Quote pipeline, Intel PCS certificate chain verification, QE P-256 ECDSA signature verification over Quote[0..632].

AMD SEV-SNP — AmdSevSnpProvider with real /dev/sev-guest ioctl, SNP_GET_REPORT, AMD KDS VCEK certificate fetching, ARK → ASK → VCEK chain verification.

AWS Nitro — AwsNitroProvider with real /dev/nsm device, CBOR attestation documents, AWS Nitro root CA chain validation, COSE_Sign1 ES384 signature verification per RFC 8152.

NVIDIA GPU CC — NvidiaGpuProvider with NVIDIA NRAS HTTP attestation, GPU evidence collection, JWT token verification, SPDM-based measurements.

Intel Tiber Trust Authority — IntelTiberClient for the GET /appraisal/v2/nonce → POST /appraisal/v2/attest → JWT flow against Intel's regional endpoints (US / EU). JWT verification via PS384/RS256 against ITA's JWKS, with TiberJwksPin::AllowedHosts locking the jku header.

03

Enclave encryption

Shared AES-256-GCM module used across all five providers. Key derivation via HKDF-SHA256 with domain separation by vendor tag. Wire format: nonce(12) || ciphertext || tag(16). In production, keys are sealed by hardware (MKTME / VMSA / KMS / CC memory); in simulation, derived from key UUID.

04

Post-quantum hybrid signing

For long-lived custody and attestation signatures, Tenzro supports composite Ed25519 + ML-DSA-65 hybrid keys. Signing-pubkey wire format dispatches on a leading tag byte: 0x00/0x01 for classical, 0x02 for hybrid (composite Ed25519 + ML-DSA-65 vk). Verification requires both legs to validate.

Used in ERC-7579 SocialRecoveryValidator (N-of-M guardian quorum with composite signatures) and in TEE-bound ZK proof signatures via sign_tee_zk_proof_hybrid.

05

X.509 chain verification

Shared verify_certificate_chain() with pinned vendor root CAs (Intel, AMD, AWS, NVIDIA). Validity period checks. Key usage extension validation. ECDSA P-256 / P-384 raw-public-key signature verification helpers shared across TDX QE and Nitro COSE paths.

06

Runtime detection and simulation

detect_tee() probes hardware and falls back to simulation via TENZRO_SIMULATE_* env vars. Simulation is for local development only; on the live testnet TENZRO_SIMULATE_*=0 is enforced. Real /dev/sev-guest on SNP nodes; real /dev/tdx-guest on TDX nodes. "On SEV node" is not the same as "doing attestation" — the network requires actual attestation evidence pinned to the provider DID.

Related