Trusted execution environments

A trusted execution environment (TEE) runs a workload in hardware-isolated memory that the host operator cannot read, and produces signed evidence, called an attestation, of exactly what software is running. Tenzro Network uses TEEs for confidential inference, confidential compute and verifiable execution, and treats their attestations as evidence that anyone can check.

Evidence, not custody

On Tenzro Network, a TEE proves what is running. It does not hold anyone's keys.

• Account, validator and operator keys are rooted in a TPM 2.0, a Secure Enclave or a passkey. See Hardware-rooted keys.
• A TEE attestation is evidence attached to a result: this output came from this code, on this platform, at this security level.
• Consensus weight and leader selection do not depend on TEEs. A validator needs a TPM 2.0 machine, not a TEE.

Keeping the two apart means a weakness found in one TEE platform affects the evidence from that platform, which relying parties can stop accepting, and never exposes funds or identities.

Supported platforms

NVIDIA confidential GPUs extend a CPU TEE; they do not replace one. The trust boundary is the confidential VM created by Intel TDX or AMD SEV-SNP, and the GPU is admitted into it over an authenticated link with its memory protected. A node offers confidential GPU compute only when it has both a CPU TEE and a GPU in confidential-computing mode. Evidence collection fails closed if confidential computing is disabled, the GPU is in a developer or debug mode, or there is no confidential VM to anchor to.

Measured boot is not a TEE. A TPM and Secure Boot prove what was loaded at boot, which is valuable for machine identity. A TEE proves what is running and protects it while it runs. A TPM-only host can validate, hold hardware-rooted keys and attest its boot chain, but it does not satisfy a confidential-compute requirement and cannot take the TEE provider role.

How an attestation is verified

Every attestation is verified in full against its vendor's chain before any part of the network acts on it:

1. Fresh nonce. The verifier issues a random challenge, and the platform must include it in the signed report data. A report that does not carry the verifier's nonce is rejected, so old evidence cannot be replayed.
2. Signature over the report. The report signature is checked with the platform's attestation key.
3. Full certificate chain. That key is checked link by link up to the vendor's pinned root certificate, including validity periods and revocation.
4. Platform security level. The reported firmware and microcode level (TCB) must meet the required minimum, and debug modes must be off.
5. Measurement. The measured software must match a measurement the relying party accepts.

Simulated or self-reported evidence is never accepted. A report either verifies against real vendor hardware or it fails.

Binding a result to the enclave

Verifying that some enclave exists is not enough; you need to know that this output came from it. When a request asks for attestation, the enclave's report data commits to the request id, the operation and the output:

user_data = SHA-256("tenzro/tee/enclave-response" || len-prefixed(request_id, operation, data))

The hardware signs user_data, so a relying party that verifies the report and recomputes the binding learns that this exact output came from an enclave with that exact measurement. Length prefixing stops a response from being lifted from one request and presented as the answer to another. If attestation was requested and the hardware cannot produce it, the call fails rather than returning a result without evidence.

Measurement registers

A report names the software the enclave runs in its measurement registers: on Intel TDX, MRTD and RTMR0 to RTMR3; on AMD SEV-SNP, MEASUREMENT. tenzro_getTeeAttestation returns the report with its registers, and tenzro_verifyTeeAttestation returns the registers it verified, so a relying party compares them with the published measurements of the image it expects the node to run.

A node operator logs the measurement of the build a node runs with tenzro trust publish-tee-measurement. The measurement logged is the report's own, taken from a fresh report bound to a challenge nonce, so a publisher can only log the build it is actually running.

What TEEs are used for

• Confidential inference. Prompts and outputs stay inside protected memory, and the response carries evidence of the model and runtime. Inference verification on Tenzro Network is TEE-first.
• Validation and re-execution. TEE providers can re-run a piece of work and attest the result, for example to answer an ERC-8004 validation request.
• Evidence in contracts. EVM contracts can check attested results through the TEE_VERIFY precompile.

Using the CLI

# What TEE hardware does this machine have?
tenzro tee detect

# Produce an attestation from the node's TEE (the platform is detected)
tenzro tee attest --out report.json

# Verify a report against a fresh challenge
tenzro tee challenge
tenzro tee verify --report <REPORT_HEX> --nonce <NONCE>

# List TEE providers on the network
tenzro tee providers

The matching JSON-RPC methods tenzro_detectTee, tenzro_getTeeAttestation, tenzro_teeAttestationChallenge, tenzro_verifyTeeAttestation and tenzro_listTeeProviders are open methods. A report verifies only against a nonce the verifier issued, so a replayed report fails.

Becoming a TEE provider

Operators with Intel TDX, AMD SEV-SNP, AWS Nitro or confidential NVIDIA GPUs can run the tee role and bond as a security provider. See Operators and roles.

Related

• Security
• Hardware-rooted keys
• Zero-knowledge proofs
• Private AI