Intel SGX

SGX protects data-in-use by encrypting enclave memory at the hardware level. The Memory Encryption Engine (MEE) automatically encrypts and integrity-protects cache lines as they move between the processor and DRAM. This prevents cold-boot attacks, DMA attacks, and memory bus snooping. Even privileged software like the OS or hypervisor cannot read plaintext enclave memory.

The Enclave Page Cache is a dedicated, encrypted region of DRAM reserved for SGX enclave code and data. The processor enforces strict access controls: non-enclave accesses to EPC pages are blocked at the hardware level. The EPC is managed by the SGX driver and paging is handled transparently, though paging encrypted pages to unprotected storage requires cryptographic sealing.

Enclaves are ephemeral and lose state on process exit. Sealing allows an enclave to encrypt data for persistent storage, binding it to a specific enclave or platform identity:

• Sealing to MRENCLAVE: Data can only be decrypted by the exact same enclave code on any platform
• Sealing to MRSIGNER: Data can be decrypted by any enclave signed by the same authority, enabling version migration This ensures data-at-rest remains confidential and tamper-evident.

SGX dramatically reduces the Trusted Computing Base (TCB) for sensitive workloads. In a traditional stack, the TCB includes the OS, hypervisor, firmware, and all privileged software. With SGX, the TCB shrinks to just the enclave code and the processor package itself. The OS and VMM are excluded from the trust boundary, eliminating entire classes of privilege-escalation and insider-threat attacks.

Intel SGX provides Flexible Launch Control (FLC), allowing data center operators to define their own enclave launch policies rather than relying solely on Intel's licensing. With FLC, platform owners can:

• Approve which enclave signers are authorized to launch
• Integrate with enterprise key management and policy engines
• Maintain full sovereignty over which code executes in enclaves on their hardware

A cryptographic hash representing the initial state of an enclave's code, data, stack, and heap. It serves as a unique identity fingerprint generated during the build process. During remote attestation, a challenger verifies this measurement against a known-good whitelist to ensure no malicious code or outdated logic has been loaded. Any modification to the source binary results in a completely different hash, providing strong integrity guarantees.

A mechanism for encrypting data for persistent storage outside the enclave's volatile memory. Data is cryptographically bound to the enclave's identity, ensuring only the exact same application on the same platform can unseal it later. Two policies exist: Sealing to the Enclave Identity (MRENCLAVE) allows decryption only by the same version of the enclave, while Sealing to the Signing Identity (MRSIGNER) permits data migration across version updates signed by the same authority.

The protocol by which an enclave proves its genuineness and integrity to a remote party before receiving secrets. The process involves the enclave generating a cryptographically signed Quote containing its measurement and platform TCB status. This Quote is verified by the Intel Data Center Attestation Service (DCAS) or a third-party attestation service, establishing a trusted channel for provisioning sensitive data like model weights or decryption keys.

Defensive techniques mitigating attacks that infer secrets by observing physical side effects of computation rather than breaking cryptographic primitives. Intel SGX incorporates hardware protections against specific vectors, but software developers must also apply countermeasures. Key strategies include: Data-oblivious algorithms that eliminate secret-dependent memory access patterns, constant-time programming to prevent timing leaks, and avoiding speculative execution side-channels like L1 Terminal Fault (L1TF) through proper microcode updates and compiler flags.

The aggregate of all hardware, firmware, and software components critical to the enclave's security. A smaller TCB reduces the attack surface and simplifies formal verification. In the SGX model, the TCB includes the CPU package boundary, the enclave code itself, and the quoting enclave. Critically, the host operating system, hypervisor, and BIOS are excluded from the TCB, meaning a compromised kernel cannot read enclave memory—a fundamental shift from traditional software security models.