> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tinfoil.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# A primer on secure enclaves

> Understand the basics of how confidential computing enabled by secure enclaves provides verifiably private computations in the cloud.

## What is Confidential Computing?

Confidential computing is the process of protecting data **in use** by performing computations inside
a secure enclave (also known as a Trusted Execution Environment, or TEE).
This provides a level of security and verifiability that is impossible to achieve
with traditional cloud computing approaches where data is unencrypted and
fully accessible to the hardware operator.

Unlike encryption at rest (for stored data) or encryption in transit
(for data being transferred over the network), confidential computing focuses
on protecting data while it's actively being processed on the host.
This is achieved by using isolated regions of memory and CPU+GPU resources which form
a secure "enclave" where even the host (such as the cloud provider)
cannot see the internals of the computation or the data being processed.

Secure enclaves prevent access from all privileged software, including the
operating system and hypervisor, while allowing remote verification of the
environment's security through a remote attestation mechanism with a hardware
root of trust.

Think of it as the third layer of encryption. Data at rest is routinely encrypted on
disk. Data in transit is encrypted with HTTPS. But during computation, data has
historically sat in plaintext in server memory, fully visible to anyone with
access to the machine. Confidential computing closes that gap: it keeps data
encrypted during processing and produces cryptographic proof of exactly what
code is handling it, so you can verify both the software and the privacy of your
data without trusting the operator.

You can see how Tinfoil performs this verification automatically by learning
more about our [verification process](/verification/verification-in-tinfoil).
This hardware-backed security model enables sensitive workloads to run in
untrusted environments while maintaining data privacy and integrity,
even if the host is untrusted or compromised by an attacker.

<Note>
  Terminology: We use "secure enclave" as the default term to describe the isolated
  environment where computations are processed. When referring to
  hardware standards, attestation artifacts, or vendor technologies, we use the
  more formal term Trusted Execution Environment (TEE).
</Note>

## Core security properties

Secure enclaves are designed to provide four hardware-backed protections that ordinary cloud infrastructure does not provide on its own:

* **Confidentiality**: Data is encrypted in memory by hardware and decrypted only inside the protected processor boundary. The operator, the hypervisor, and any other process on the machine only see ciphertext.
* **Integrity**: Code loaded into an enclave cannot be altered without detection. Even someone with root on the host cannot patch or replace the running workload.
* **Verifiability**: The hardware measures every piece of software before it runs, producing a cryptographic record of exactly what is executing. A client reads that record and confirms it matches the expected code.
* **Attestation**: The enclave wraps the measurement and the enclave's identity into a report signed by the manufacturer's silicon. That report is unforgeable, so an imposter enclave cannot fake its way through verification.

## Who you trust, and who you don't

Confidential computing draws a clear line between what you trust and what you verify:

* **You trust** the hardware manufacturer (AMD, Intel, or NVIDIA) to correctly implement the silicon root of trust and the cryptographic primitives the enclave relies on.
* **You verify** the application code through measurements, signed releases, and transparency logs before sending data to the enclave.
* **You do not trust** the cloud provider's software stack, the hypervisor, the host operating system, system administrators, or other tenants on the same machine. None of them can see inside the enclave.

This is what makes the model work: the hardware itself enforces isolation, so you no longer need to trust the operator of the machine.

## How a secure enclave is built

A secure enclave is built from three pieces of silicon working together inside the processor:

**The memory encryption engine.** Both AMD and Intel embed an AES encryption engine directly in the memory controller, the component that sits between the CPU cores and RAM. Every time data is written to memory, the engine encrypts it on the way out. Every time data is read back, the engine decrypts it on the way in. This happens transparently in hardware, usually with low overhead, though performance depends on the workload and platform. The encryption keys are held in registers inside the memory controller and are never exposed to software, not even to the hypervisor.

**The secure processor.** A dedicated security processor embedded in the CPU manages the encryption keys. It generates them at boot, assigns a unique key to each enclave, and locks them into the memory controller's registers. No other software on the machine can request or intercept those keys. Both [AMD](https://www.amd.com/en/developer/sev.html) and [Intel](https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html) implement this design.

**The CPU's memory-access checks.** With encryption in place and keys locked away, the final piece is enforcement. The CPU extends its page tables with hardware-enforced metadata that marks every physical page as either secure or regular. On every memory access, the CPU checks this metadata before allowing the read or write to proceed. If the hypervisor tries to map a secure page into a regular VM, the CPU blocks the access in hardware. This is not a policy check. It is a silicon-level gate.

The result is a hardware-isolated region where code and data are encrypted whenever they leave the CPU die. The operating system and hypervisor continue to manage the regular world normally, but neither has any path into the secure region. They cannot read, write, map, or replay those pages. The boundary is enforced by the memory controller and the CPU, not by software.

## Supported hardware

There are several options for instantiating secure enclaves on modern processors.
While traditionally enclaves were restricted to CPU-only workloads,
the latest NVIDIA GPUs now offer the ability to run them by enabling
a special "confidential compute mode."

| Vendor | Platform                                         | Feature                     | Type |
| ------ | ------------------------------------------------ | --------------------------- | ---- |
| AMD    | EPYC 3rd–5th Gen (7003, 8004, 9004, 9005 series) | SEV-SNP                     | CPU  |
| Intel  | Xeon Scalable 5th Gen, Xeon 6                    | TDX                         | CPU  |
| NVIDIA | H100, H200, B200                                 | Confidential Computing Mode | GPU  |

## Understanding Remote Attestation

Enclave verifiability is a critical security feature that allows users to
confirm that code is running in genuine hardware with hardware
security features enabled.
Tinfoil's integrity features ensure that all code and data remain unchanged
and verifiable through cryptographic remote attestation.

### The attestation process

The attestation process establishes a chain of trust from the hardware
level up to the application level.
Each step builds upon the security guarantees of the previous one to create a
chain of trust connecting the hardware to application code it is running.

1. **Hardware Authentication**
   The process begins by verifying the authenticity of the physical
   hardware components. This step ensures the enclave is running on genuine
   chips with proper security features enabled, not on simulated or
   misconfigured CPUs or GPUs.

2. **Configuration Verification**
   Once hardware authenticity is confirmed, the system validates that
   all security-critical settings are properly configured. This ensures the enclave
   environment is set up with the correct parameters and isolation boundaries.

3. **Code Measurement**
   The hardware creates cryptographic measurements of all code and configuration
   loaded into the enclave at launch. Clients can later verify these measurements
   to confirm the enclave is running the expected code.

#### Chain of trust

The attestation chain is established through a series of cryptographic validations:

1. **Hardware Root of Trust**: Hardware manufacturers (Intel, AMD, NVIDIA)
   embed cryptographic keys in their processors at manufacture time
2. **Firmware Validation**: Hardware validates firmware integrity during boot
3. **Initialization**: Firmware initializes the enclave with verified security parameters
4. **Measurement**: The hardware measures the loaded code and records cryptographic evidence
5. **Attestation Report**: A hardware-rooted component signs the measurements using keys chained to the manufacturer's certificate authority
6. **Verification**: Clients verify signatures and measurements against known-good values

<Info>
  On AMD SEV-SNP, the CPU's secure processor (PSP) signs with the VCEK, a per-chip key chained to AMD's root key. On Intel TDX, a Quoting Enclave signs with an attestation key chained to Intel's PCK certificate.
</Info>

## Understanding confidentiality

Secure enclaves provide an isolated execution environment directly at the hardware level.
You can think of it as a "computer within a computer," with its own dedicated memory regions and
processing capabilities that remain completely isolated from the rest of the system and the
hardware operator (e.g., Tinfoil).

When code runs within a secure enclave, it is executed in a protected region where
even privileged system software like the operating system, hypervisor, and
system administrators cannot
access or modify the data being
processed.

In modern secure hardware processors like Intel TDX and AMD SEV-SNP,
all data in memory is automatically encrypted using keys that never leave the processor.
Because memory is always encrypted, data outside the processor is inaccessible
to software-based attackers:

* Memory dumps cannot reveal sensitive information.
* Cold boot attacks are ineffective since memory contents remain encrypted.
* Direct Memory Access (DMA) attacks are blocked.
* Physical memory probing yields only encrypted data.

**Secure key management**:

* Encryption keys are generated within the processor and never leave the processor.
* Keys are automatically destroyed when the enclave terminates.

### Limitations of enclaves in practice

While secure enclaves provide strong guarantees, they are not a silver bullet.

* **Physical attacks**: An attacker with physical access to the hardware can potentially compromise the enclave. For Intel TDX, attestation forgery has been demonstrated; for AMD SEV-SNP, researchers achieved confidentiality breaches through key extraction ([tee.fail](https://tee.fail)). These attacks require significant resources and physical proximity to the machine.

* **Side-channel attacks**: Enclaves can be vulnerable to timing attacks, power analysis, and electromagnetic emissions that leak information about the data being processed.

* **I/O pattern leakage**: The host can observe data access patterns and I/O behavior, which may reveal sensitive metadata even though the data itself remains encrypted.

* **Denial of service**: The cloud provider controls resource allocation and can restrict or terminate access to the enclave at any time.

* **Supply chain attacks**: The hardware, firmware, and software built and shipped into an enclave all depend on a supply chain that could be compromised before deployment, for example through a malicious build pipeline or tampered dependency. Tinfoil hardens its own build and release pipeline against these attacks; see [Supply Chain Security](https://tinfoil.sh/blog/2026-05-01-supply-chain-client).

* **Rollback attacks**: An attacker may try to revert an enclave or its components to an older, vulnerable version. Measured boot detects modified code, but defending against rollback to a previously valid version requires versioned measurements and anti-rollback controls.