Confidential Computing and Hardware Attestation

2.1 Enclave Architecture and Isolation Mechanics

Data has three states. At rest it sits in storage. In transit it moves over a network. In use it sits in memory, in registers, and in caches, where it is plaintext by necessity, because a processor cannot compute on ciphertext.

Everything with privilege can read data in use. The hypervisor can read guest memory. The host operating system can read process memory. An administrator with root can attach a debugger. A cold-boot attack can read DRAM after a power cut. A malicious co-tenant who escapes isolation reads whatever is nearby.

Confidential computing removes that access. A trusted execution environment, or TEE, is a region of memory that the processor encrypts and integrity-protects, with a hardware-enforced boundary that privileged software cannot cross. The trusted computing base shrinks from "the hypervisor, the host kernel, the firmware, and the operator" to "the processor and the code inside the enclave".

Two granularities

The first generation put the boundary around a process. Intel SGX creates an enclave inside an application's address space, with its own encrypted pages in a reserved region of physical memory. Code inside the enclave is entered through defined call gates and cannot make system calls directly.

That model gives the smallest trusted computing base, because the operating system is outside it. It also gives the hardest programming model. The application must be split into trusted and untrusted halves, and every crossing must be defined with its arguments copied and checked. Anything that needs a system call must exit, be served by untrusted code, and re-enter with a result that the enclave cannot assume is honest.

The second generation put the boundary around a virtual machine. Intel TDX creates a Trust Domain, and AMD SEV-SNP creates an encrypted guest. The whole guest, including its kernel, runs inside the boundary, and the hypervisor is outside it.

That model gives a much larger trusted computing base, because the guest kernel is now trusted. It also gives an unmodified programming model: an existing workload lifts into a confidential virtual machine with no code change. That trade is why the VM-level model won, and why SEV-SNP and TDX are production defaults across mainstream server parts and every major cloud in 2026.

  PROCESS-LEVEL (Intel SGX)          VM-LEVEL (Intel TDX, AMD SEV-SNP)
  +---------------------------+      +----------------------------------+
  | application               |      |  guest application               |
  |  +---------------------+  |      |  guest libraries                 |
  |  | ENCLAVE             |  |      |  GUEST KERNEL                    |
  |  |  secrets, key code  |  |      |  guest firmware                  |
  |  +---------------------+  |      |            all inside the TEE    |
  +---------------------------+      +----------------------------------+
  | libraries, runtime        |      +==================================+
  +---------------------------+      | TDX Module / SEV firmware        |
  | OPERATING SYSTEM  untrusted|     +----------------------------------+
  +---------------------------+      | HYPERVISOR        untrusted      |
  | HYPERVISOR        untrusted|     +----------------------------------+
  +---------------------------+      | HOST KERNEL       untrusted      |
  | CPU + memory encryption   |      | CPU + memory encryption          |
  +---------------------------+      +----------------------------------+

  Smallest TCB, hardest to program.   Larger TCB, lifts existing workloads.
  The guest kernel inside the boundary is the whole trade.

Memory encryption and the integrity problem

Every design encrypts memory with a key that the processor generates at boot and never exports. Encryption alone stops a passive reader: a cold-boot attack or a memory bus probe returns ciphertext.

Encryption alone does not stop an active attacker with hypervisor privilege, and the three attacks are worth naming because they are what the second generation of each design exists to prevent.

A replay attack records an old ciphertext block and writes it back later, so the guest sees stale data that decrypts correctly. A remapping attack changes the mapping so that a guest physical page points at different memory. An aliasing attack maps one physical page into two guest pages, so a write through one appears through the other.

AMD SEV-SNP answers all three with the Reverse Map Table. It is a hardware structure with one entry per physical page, recording which guest owns it and which guest physical address it is mapped at. Every nested page walk checks the table, and a mismatch faults. That single structure is what "SNP", secure nested paging, names, and it is the difference between SEV-SNP and the earlier SEV generations.

Intel TDX answers them with a Secure Extended Page Table that the TDX Module owns rather than the hypervisor, plus per-page metadata and cryptographic integrity on memory. The TDX Module itself runs in a special processor mode called SEAM, which the hypervisor cannot enter or inspect, and it mediates every transition into and out of a Trust Domain.

The two designs differ in emphasis. SEV-SNP optimizes for density and throughput and reports overhead under about 5 percent, with a privilege level mechanism inside the guest that lets a paravisor run at a higher level than the guest kernel. TDX isolates processor state as well as memory, which gives deeper separation from the platform operator's scheduling and interrupt handling, and which suits a provider that must demonstrate isolation to a regulator.

Arm has an equivalent in its Confidential Compute Architecture, which introduces Realms as a fourth security world alongside the existing secure and non-secure ones.

The side channels that remain

A TEE protects memory contents. It does not hide every observable effect of computation, and that limitation is structural rather than a bug to be fixed.

The processor still shares caches, branch predictors, and memory controllers with untrusted code. An attacker who controls a co-resident workload measures timing and infers what the enclave did. Page-fault side channels are specific to the process-level model, because the untrusted operating system still handles the enclave's page faults and therefore learns its access pattern at page granularity.

Three responses are practical. Write the sensitive inner loops in constant time, with no secret-dependent branches and no secret-dependent memory addresses, which is the same discipline that cryptographic implementations already follow. Reduce co-residency by dedicating hardware where the threat model justifies the cost. And treat the TEE as one layer among several rather than as a complete answer.

The honest summary is that confidential computing raises the cost of attack from "have privilege" to "mount a sophisticated micro-architectural attack". That is a very large improvement and it is not a proof.

2.2 Remote Attestation and Identity Bootstrapping

An enclave that nobody can inspect is also an enclave that nobody can trust. If you cannot see inside it, you cannot know it is running your code rather than a modified version that exports the secrets.

Remote attestation solves that. The hardware produces a signed statement describing what is running, and a remote party checks the signature and the contents before trusting the environment with anything.

The chain of trust

The chain starts in the silicon. Each processor holds a unique key that the manufacturer provisioned at fabrication and that never leaves the chip. From that root, the hardware derives a signing key bound to the current firmware version and configuration. The manufacturer publishes a certificate chain that ties the derived key back to the manufacturer's root.

A verifier who receives a signed attestation establishes three things. It came from genuine hardware of the claimed type. The hardware is at a known firmware level. And the measurements inside it describe a specific software state.

  MANUFACTURER ROOT (offline, in the manufacturer's HSM)
      | signs
      v
  PROVISIONING / ENDORSEMENT CERT          published per chip family
      | derives, bound to firmware TCB version
      v
  ATTESTATION SIGNING KEY                  inside the package, never exported
      | signs
      v
  +-----------------------------------------------------------+
  |  ATTESTATION REPORT (the "quote")                         |
  |    measurement of the launched image                      |
  |    measurement of the configuration and boot policy       |
  |    firmware / TCB version and security-relevant flags     |
  |    debug-enabled and migration-allowed flags              |
  |    64 bytes of caller-supplied data  <-- nonce, or a       |
  |                                          public key hash  |
  +-----------------------------------------------------------+
      | sent to
      v
  VERIFIER                                 checks, in this order:
      1. signature chains to a trusted manufacturer root
      2. the chip is not revoked and the TCB version is current
      3. debug is disabled and the policy flags are acceptable
      4. the measurement equals an expected value
      5. the caller-supplied data matches the nonce this session sent
      | on success
      v
  RELEASE A SECRET, or open an authenticated channel

Step five is the one that implementations get wrong. Without binding the attestation to the current session, a valid quote captured from an honest enclave can be replayed by an attacker who has no enclave at all. The binding comes from putting a fresh nonce, or a hash of the ephemeral public key used for the channel, into the report's user data field. The hardware signs it along with the measurements, so the report cannot be reused.

Measurement, and what it means

A measurement is a cryptographic hash of what was loaded. For a confidential virtual machine, it covers the initial memory image: the firmware, the kernel, the initial ramdisk, and the boot parameters. For a process enclave, it covers the enclave binary and its configuration.

The measurement is a fixed value for a given image, which is the property that makes it useful and also the property that makes it operationally demanding. Any change to any component changes the measurement, so an expected-value list must be regenerated for every build, and the build must be reproducible or the value cannot be predicted at all. Section 3.2 covers reproducible builds, and this is one of the places where they stop being an ideal and become a requirement.

A TPM takes a different approach with Platform Configuration Registers. A PCR cannot be set directly. It can only be extended, where the new value is the hash of the old value concatenated with the new measurement. The chain is therefore append-only and order-dependent, and a component that measures itself before handing control onward builds a record that later software cannot forge.

TPM 2.0 provides 24 PCRs with conventional assignments: firmware code and configuration in the low registers, option ROMs and boot loader in the middle, and operating system and application measurements above. A TPM Quote signs a selected set of PCRs together with a nonce, using an attestation key derived from the TPM's endorsement key.

The event log is the companion. PCR values alone are opaque hashes that say nothing about what was measured. The event log records each measurement and what it represented, and a verifier replays the log to recompute the PCR value. If the replay matches, the log is honest, and the verifier can now reason about individual components rather than about one hash.

Verification as a service, and the policy problem

Checking an attestation properly means parsing a hardware-specific structure, fetching and checking certificate chains, consulting revocation data, applying the manufacturer's advisories about known-vulnerable firmware versions, and then evaluating a policy. Every one of those is a place to get it wrong.

Attestation verification services exist for this reason. Intel, cloud providers, and independent vendors all offer one. The service does the hardware-specific work and issues a token, typically a signed JWT, containing the validated claims. The relying party checks one signature against one key set and reads structured claims.

That is a real simplification and it introduces a dependency worth stating plainly: the verification service becomes part of the trust base, and its availability becomes part of the availability of anything that depends on attestation.

Policy is the harder half, and it is where the engineering judgment lives. A policy that pins an exact measurement is the most precise and it breaks on every build. A policy that accepts a signer identity and a minimum version is operationally practical and accepts anything that signer produces. A policy that accepts any genuine hardware proves the hardware and nothing about the software, which is almost always insufficient.

The workable middle records an allowlist of measurements produced by a trusted build pipeline, keyed to a signed provenance statement, and refreshes it automatically as releases are promoted. That connects this chapter directly to Chapter 3: attestation policy is only as good as the build system that produces the expected values.

2.3 Zero-Trust Data Processing in Flight

The reason to run a workload in a TEE is almost always that someone else owns the infrastructure, and the guarantee needed is that owning the infrastructure is not enough to see the data.

The patterns that justify the cost

Multi-party computation on shared data is the clearest case. Two organizations want a result computed over the union of their data and neither will send its data to the other. A TEE gives a neutral place: both parties attest the enclave, both release their data to it under that attestation, the enclave computes, and only the agreed result comes out. Fraud consortia, clinical research collaborations, and advertising measurement all use this shape.

Regulated workloads in a public cloud are the second case. A regulator or a contract requires that the cloud provider cannot access the data. Encryption at rest and in transit do not satisfy that requirement, because the provider operates the hypervisor. A TEE does, and the attestation is the evidence.

Confidential AI inference is the third and it is growing fastest. A model owner will not ship weights to a customer, and a customer will not send prompts to the model owner. A TEE holds both: the weights are decrypted only inside it, the prompts arrive encrypted to it, and neither side sees the other's asset. This requires the accelerator to be inside the boundary too, which is what confidential GPU modes provide, with encrypted device memory and an authenticated link between the processor TEE and the accelerator.

Key management and signing services are the fourth. An enclave that holds signing keys and releases them to nothing gives much of the property of a hardware security module, on ordinary server hardware and at a fraction of the cost. Attestation is the control that a module's physical tamper resistance provides instead.

Designing the boundary

Three rules decide whether a confidential deployment actually delivers its guarantee.

Keep the enclave small and stable. Every line inside the boundary is trusted, and every dependency pulled in enlarges the attack surface and changes the measurement. An enclave that holds a decryption routine and a scoring function is auditable. One that holds a full application framework is not, and its measurement changes weekly.

Treat everything outside as hostile, including the operating system. Data arriving at the enclave must be authenticated and integrity-protected, not merely received. Results leaving must be encrypted to a key the recipient holds. The untrusted side schedules the enclave, delivers its I/O, and can withhold or reorder anything, so the enclave must tolerate all of that without losing confidentiality.

Encrypt to the attestation, not to the host. The pattern in Section 2.4 makes this concrete: data is encrypted such that only an enclave whose measurement matches a policy can obtain the decryption key.

The pattern in that table is consistent and it must shape the design. Pure computation is nearly free. Crossing the boundary is expensive. A confidential workload therefore wants large batches and few crossings, which is the same advice that Volume I gives for system call cost, applied to a different boundary.

2.4 Secure Key Release Protocols

Attestation proves what is running. On its own it changes nothing, because proof without consequence is a log entry. Secure key release is the mechanism that gives the proof teeth: a key management service releases a key only to an environment whose attestation satisfies a policy.

The protocol

The exchange has six steps, and the ordering matters.

1. The enclave starts and generates an ephemeral key pair in memory that never leaves the boundary.
2. The enclave requests an attestation report from the hardware, placing a hash of its ephemeral public key in the report's user data field.
3. The enclave sends the report and the public key to the key management service.
4. The service validates the report: signature chain, chip revocation status, firmware version, policy flags, and the measurement against its allowlist.
5. The service checks that the user data field matches the hash of the supplied public key, which binds the key to this attested environment.
6. The service wraps the requested key to the ephemeral public key and returns it. Only the attested enclave can unwrap it.

# Inside the enclave. Nothing here ever touches untrusted memory
# in plaintext, and the private key never leaves the boundary.

def obtain_data_key(kms, key_id: str) -> bytes:
    # 1. Ephemeral key pair, generated inside the enclave.
    eph_priv, eph_pub = x25519_generate()

    # 2. Bind the public key into the hardware-signed report.
    #    The nonce from the service defends against replay.
    nonce = kms.get_nonce()
    user_data = sha512(eph_pub + nonce)          # 64 bytes
    report = tee.get_attestation_report(user_data=user_data)

    # 3-5. The service does the checking. It refuses if the
    #      measurement is not on its allowlist, if debug is enabled,
    #      if the firmware is below the minimum, or if user_data
    #      does not match what it was sent.
    wrapped = kms.release_key(key_id=key_id,
                              attestation=report,
                              public_key=eph_pub,
                              nonce=nonce)

    # 6. Only this enclave holds eph_priv, so only this enclave unwraps.
    return hpke_unwrap(eph_priv, wrapped)

The policy on the service side is where the security actually lives, and it is configuration rather than code.

# A release policy. Every clause corresponds to an attack it prevents.
policy:
  key: "kms://prod/patient-index-dek"
  allow_when:
    platform:            "AMD-SEV-SNP"      # or Intel-TDX
    chip_not_revoked:    true               # revoked chip: refuse
    min_tcb_version:     "0.0.22"           # known-vulnerable firmware: refuse
    debug_enabled:       false              # debuggable enclave: refuse
    migration_allowed:   false              # migratable guest: refuse
    measurement_in:                         # unknown image: refuse
      - "b1e0...a47c"   # release 2026.03.1, signed provenance attached
      - "9f2d...0e31"   # release 2026.03.2
    report_data_binds_public_key: true      # replayed report: refuse
    max_report_age_seconds: 300             # stale report: refuse

Where key release fits in a lifecycle

Two placements are common and they differ in blast radius.

Releasing a data encryption key per object, on demand, gives the smallest exposure: the enclave holds one object's key for as long as it processes that object. It costs a service round trip per object, which is fine at low rates and prohibitive at high ones.

Releasing a key encryption key once at start-up gives one round trip per enclave lifetime, and the enclave then unwraps object keys locally. That is the usual choice, and it means the enclave holds a key that decrypts everything for as long as it lives. Bound the exposure with a short enclave lifetime and a lease that must be renewed against a fresh attestation.

The second placement is what makes a confidential storage mount work. The enclave attests, receives the volume key, and mounts the encrypted volume inside the boundary. The host sees an encrypted block device and never the plaintext, and a host that reboots into different software fails attestation and never receives the key.

Operating it

Three operational realities decide whether this works beyond a demonstration.

Measurement churn is the first. Every build produces a new measurement, so the allowlist must update automatically as releases are promoted, driven by the same pipeline that produces the provenance attestation in Section 3.2. A manual allowlist becomes a deployment blocker within weeks, and the workaround that teams reach for is a permissive policy.

Firmware updates are the second. A platform firmware update changes the trusted computing base version and can change derived keys. The provider applies it on its own schedule, and workloads that pinned a version stop attesting. Track the minimum acceptable version as a moving floor rather than an exact match, and treat a provider firmware advisory as an operational event.

Recovery is the third, and it is the one that causes data loss. Data encrypted under a key that only an attested enclave can obtain is unreadable if the enclave image is lost, if the policy is corrupted, or if the platform is retired. Keep a documented, tested break-glass path: a second wrapping of the key under a separately controlled offline key, with its own approval process and its own audit trail. A confidential system with no recovery path is not a secure system, it is a data loss event with a delay.

Sources and further reading

The Confidential Computing Consortium's technical analyses and its definitions. The Intel TDX and SGX developer documentation, including the attestation architecture. The AMD SEV-SNP white paper, particularly the Reverse Map Table and the VM privilege level mechanism. The Arm Confidential Compute Architecture specifications. The TCG TPM 2.0 library specification and the PC Client Platform Firmware Profile for PCR assignments. RFC 9334, the Remote Attestation Procedures architecture, for the verifier and relying party roles. The AWS Nitro Enclaves documentation for attestation-based key policies, and the equivalent confidential computing documentation from the other major providers.