Intel SGX

SGX automatically encrypts enclave memory using the Memory Encryption Engine (MEE), a dedicated hardware unit on the processor die. When enclave data is evicted from the CPU cache to DRAM, it is transparently encrypted and integrity-protected. Any attempt by the OS, hypervisor, or a DMA-capable peripheral to read the encrypted memory region results in unintelligible ciphertext. This protects against cold boot attacks, physical DRAM probing, and bus snooping. The encryption keys are generated at boot time and never exposed to software, residing solely within the processor package.

The Enclave Page Cache is a dedicated, reserved portion of DRAM that stores enclave code and data. The EPC is managed by the processor's memory controller and is strictly partitioned from the rest of system memory. Key characteristics include:

• Fixed Size: Typically 128 MB or 256 MB per socket on Xeon E3/E5, with larger capacities on 3rd Gen Xeon Scalable processors (up to 1 TB per socket).
• Page-Level Access Control: Each EPC page has hardware-level read/write/execute permissions enforced by the CPU.
• Eviction and Paging: When the EPC is full, pages are encrypted and evicted to unprotected memory, then decrypted and integrity-checked upon re-entry.

Sealing is the mechanism by which an enclave encrypts data for persistent storage, binding it to the enclave's unique identity. Two sealing policies exist:

• Sealing to the Enclave Identity (MRENCLAVE): Data can only be decrypted by an enclave with the exact same code measurement. Any code change invalidates access.
• Sealing to the Signing Identity (MRSIGNER): Data can be decrypted by any enclave signed by the same authority, enabling version upgrades. The sealed data is encrypted with a key derived from the CPU's fused sealing key, ensuring it cannot be decrypted on a different physical platform or by a different enclave.

SGX dramatically reduces the Trusted Computing Base by excluding the operating system, hypervisor, BIOS, and device drivers from the security perimeter. The TCB for an SGX application consists solely of:

• The processor package (CPU die and package-level firmware)
• The enclave code itself This means that even a fully compromised OS kernel or a malicious cloud administrator cannot read enclave memory. This is a fundamental shift from traditional security models that assume the OS is trusted. The attack surface is reduced from millions of lines of OS code to the enclave's own codebase.

SGX enables secure aggregation of model updates from multiple data owners without exposing the underlying data. Each participant's gradient updates are decrypted and aggregated exclusively inside an enclave, ensuring that no single party—including the central server operator—can inspect individual contributions.

• Protects proprietary datasets during collaborative model training
• Prevents gradient leakage attacks that can reconstruct training data
• Used in healthcare consortia to train diagnostic models across hospitals without sharing patient records

Smart contracts often require off-chain data, but traditional oracles create a trust bottleneck. SGX provides verifiable off-chain computation where oracle nodes process data inside enclaves, generating cryptographically signed attestations that prove the computation was executed correctly on genuine hardware.

• Eliminates the need to trust oracle node operators
• Enables confidential smart contracts that execute with private inputs
• Powers decentralized finance protocols requiring tamper-proof price feeds

Competing organizations can jointly analyze combined datasets without revealing their individual records. SGX acts as a neutral computation zone where encrypted data from multiple parties is decrypted, analyzed, and the results re-encrypted—all within the enclave boundary.

• Financial institutions collaborate on anti-money laundering detection
• Retailers benchmark performance without exposing sales figures
• Enforces data usage policies through enclave code verification

Model owners can deploy proprietary neural networks to untrusted cloud infrastructure while keeping weights encrypted. Inference requests and responses are decrypted only inside the SGX enclave, protecting both the intellectual property of the model and the privacy of user queries.

• Prevents cloud operators from extracting model architecture
• Satisfies data residency requirements by processing data in-region
• Enables AI-as-a-service without exposing competitive advantage

SGX provides a hardware-backed vault for managing self-sovereign identity credentials. Private keys and verifiable credentials are generated and stored exclusively within enclaves, with biometric matching performed locally to unlock identity assertions.

• Protects against credential exfiltration even on compromised devices
• Enables zero-knowledge proofs of identity attributes
• Deployed in national digital identity programs for citizen services

Cloud KMS offerings use SGX to protect cryptographic material during the brief moments keys are in use. Key operations—signing, encryption, decryption—execute inside enclaves, ensuring that even the cloud provider cannot access plaintext keys.

• Achieves separation of duties between infrastructure and security
• Integrates with remote attestation for key release policies
• Foundation for confidential computing orchestration platforms