Recipe

Secure enclave / TEE workload design

A production pattern for running sensitive computation inside hardware-isolated trusted execution environments — Intel SGX, AMD SEV, or AWS Nitro Enclaves — with attested deployment and sealed storage.

Why enclaves

Standard process isolation cannot protect against a compromised kernel, hypervisor, or cloud operator. TEEs move the trust boundary into silicon — the CPU itself enforces memory encryption and remote attestation. Meridian workloads that handle key material, license state, or user secrets run exclusively inside enclaves so that even the host OS sees only ciphertext.

Architecture

┌──────────────────────────────┐
│  Host (untrusted)            │
│  ┌────────────────────────┐  │
│  │  Enclave (trusted)     │  │
│  │  • Sealed key store    │  │
│  │  • Attestation report  │  │
│  │  • Workload logic      │  │
│  └────────────────────────┘  │
│  • ECALL / OCALL bridge      │
│  • Encrypted memory pages    │
└──────────────────────────────┘

Attestation flow

  1. Enclave produces a hardware-signed quote binding its measurement (MRENCLAVE) and public key.
  2. Quote is sent to the attestation service (IAS / DCAP) for verification.
  3. Meridian backend validates the quote, establishes an attested TLS channel, and provisions secrets only to the verified enclave.

Sealed storage

Data sealed by an enclave is encrypted with a key derived from the CPU's fuse set and the enclave identity. Sealed blobs can only be decrypted by the same enclave on the same physical CPU — or by any enclave signed by the same author when using MRSIGNER-based sealing policies.

Production checklist

  • Minimize the TCB — keep enclave code small and auditable.
  • Never log raw secrets inside the enclave.
  • Rotate sealing keys on every deployment.
  • Pin attestation collateral to a known-good version.
  • Monitor OCALL frequency for side-channel anomalies.
← Back to docs