Intel SGX Overview and Remote Attestation

← Back to Main Page

• 1. Introduction
• 2. Intel SGX Fundamentals
  • 2.1 What is an Enclave?
  • 2.2 Inside vs. Outside the Enclave
  • 2.3 SGX EDL Files
• 3. Open Enclave Attestation API
• 4. Remote Attestation Deep-Dive
  • 4.1 Parties Involved
  • 4.2 Intel SGX Quote
  • 4.3 IETF “Evidence”
• 5. Rethinking Containerization with SGX
• 6. Parameter Boundary Explanation
• 7. Generating Evidence vs. Report
• 8. Key Classes in Implementation
  • 8.1 Attestation Class (Enclave-side)
  • 8.2 Crypto Class (Enclave-side)
  • 8.3 Dispatcher (Enclave-side)
• 9. Runtime Flow Summary
• 10. Typical SGX Attestation Workflow
• 11. Memory Protection
• 12. Execution Lifecycle

1. Introduction

Intel Software Guard Extensions (SGX) provide hardware-based security functionalities that allow developers to create enclaves—trusted execution environments that protect data even in the presence of privileged (root-level) threats. SGX enables new paradigms for securely running sensitive code and handling critical secrets.

2. Intel SGX Fundamentals

2.1 What is an Enclave?

• Enclave: A secure memory region within a process, encrypted in RAM.
• Hardware Enforcement: The CPU ensures only enclave code can access enclave data.
• Security: Even root-level attackers can only view encrypted data in enclave memory.

2.2 Inside vs. Outside the Enclave

• Enclave Calls (ECalls): Function calls from untrusted application code into the enclave.
• Outside Calls (OCalls): Function calls from enclave code out to untrusted application code.
  These should be minimized to reduce information leakage.
• Data Marshaling: Explicit directives ([in], [out], [in, out]) specify which data is passed and how it’s copied between untrusted and trusted memory.

2.3 SGX EDL Files

• Purpose: Define all trusted (ECalls) and untrusted (OCalls) interfaces between the host application and enclave.
• Security Benefit: Makes data flow explicit and reduces the potential attack surface.

3. Open Enclave Attestation API

The Open Enclave (OE) SDK provides standardized APIs for attestation. Below are the core functions relevant to generating and verifying attestation artifacts:

4. Remote Attestation Deep-Dive

4.1 Parties Involved

• Attester: The enclave proving its integrity.
• Verifier: Entity validating attestation evidence or enclave report.
• Challenger (Relying Party): Consumes the verifier’s result and makes trust decisions.

4.2 Intel SGX Quote

• Generated By: The Intel Quoting Enclave (using ECDSA or EPID signatures).
• Custom Data: Up to 32 bytes placed in report_data.
• APIs: oe_get_report() / oe_verify_report().

4.3 IETF “Evidence”

• Format: SGX quote embedded in an IETF RATS (RFC 9334) structure.
• Claims: Can carry arbitrary key/value pairs (JSON, CBOR, JWT, X.509 extensions).
• APIs: oe_get_evidence() / oe_verify_evidence().

5. Rethinking Containerization with SGX

• Library OS Approaches: Tools like Graphene-SGX, Occlum, and SCONE wrap existing applications in enclaves by intercepting system calls.
• Trade-offs:
  • Complexity: These frameworks must handle syscalls differently, which can cause non-deterministic behaviors.
  • Suitability: SGX is often best for tightly scoped, security-critical applications (e.g., key managers, HSM-like services). Legacy apps may be cumbersome to adapt.

6. Parameter Boundary Explanation

• [in]: Copies data from the untrusted host application into the enclave (read-only within the enclave).
• [out]: Enclave allocates or writes data back to untrusted memory, returning results to the host.

7. Generating Evidence vs. Report

8. Key Classes in Implementation

8.1 Attestation Class (Enclave-side)

• Manages report and evidence creation (via oe_get_report() and oe_get_evidence()).
• Incorporates cryptographic hashing (e.g., Crypto::Sha256) to ensure claims integrity.

8.2 Crypto Class (Enclave-side)

• Handles all cryptographic operations, including:
  • Key generation
  • Hashing
  • RSA/ECDSA signing/verification
• Internally wraps mbedTLS or similar libraries.

8.3 Dispatcher (Enclave-side)

• Routes incoming ECalls to the appropriate enclave modules (Attestation, Crypto, etc.).

9. Runtime Flow Summary

1. AESM Active
   Ensure the Intel Architectural Enclave Service Manager (AESM) is running (e.g., sudo service aesmd status).

2. Enclave Creation
   The host application initializes the enclave (e.g., using OE SDK calls like oe_create_*_enclave()).

3. Key Generation
   The enclave generates an internal key pair for cryptographic operations.

4. Attestation
   • Host requests evidence or a report by invoking an ECall.
   • Enclave uses the OE SDK to create attestation artifacts (oe_get_report(), oe_get_evidence()).
5. Verification
   • The host or a remote verifier validates the returned quote/evidence (e.g., oe_verify_evidence()).
   • If the verification succeeds, trust is established.
6. Secure Operations
   The enclave can now exchange secrets securely (e.g., the host can send encrypted data the enclave can decrypt).

10. Typical SGX Attestation Workflow

1. Start AESM
   Verify aesmd is running (sudo service aesmd status).

2. Host Creates Enclave

   oe_result_t result = oe_create_myenclave_enclave(
       "myenclave.signed",
       OE_ENCLAVE_TYPE_AUTO,
       OE_ENCLAVE_FLAGS_DEBUG,
       NULL,
       0,
       &enclave);
   

3. Generate a Key Pair (Enclave-Side) Via a dispatcher ECall that calls enclave crypto APIs.

4. Produce Attestation Artifacts

    // In host application
    get_report_or_evidence(enclave, ...);
   

   Inside enclave:

    oe_get_report(OE_REPORT_FLAGS_REMOTE_ATTESTATION, ...);
   

   or

    oe_get_evidence(&format_id, &format_settings, ...);
   

5. Quote/Evidence Generation The Quoting Enclave signs the report.

6. Verification by Host or Remote Verifier

    oe_verify_report(report, report_size, ...);
    // or
    oe_verify_evidence(evidence, evidence_size, ...);
   

7. Secure Communication If attestation succeeds, the enclave can safely receive secrets or engage in secure protocols.

11. Memory Protection

Intel SGX protects confidential data by encrypting a specific region of memory, called Protected Reserved Memory (PRM), at the hardware level. A key structure within the PRM is the Enclave Page Cache (EPC), where all enclave code and data reside.

• EPC (Enclave Page Cache)
  • A separate region in physical memory that holds enclave pages.
  • Each EPC page belongs to exactly one enclave.
  • The CPU maintains the Enclave Page Cache Map (EPCM) to track each page’s owner and attributes.
• Hardware Enforced
  • EPC pages are encrypted before writing to main memory and decrypted upon loading into the processor.
  • The OS or hypervisor cannot read the EPC contents directly, even with root privileges.
• Access Checks
  • Page table entries for enclave code and data are protected.
  • Attempts by non-enclave code (including other enclaves) to access an enclave’s EPC pages are blocked by hardware checks.
  • Side-channel attacks are out of scope in the standard SGX threat model ([24]).

12. Execution Lifecycle

An SGX enclave goes through well-defined stages from creation to teardown:

1. Loading Stage
   • Performed by untrusted code in the host application.
   • Code and data are copied into EPC pages.
   • Each page addition operation updates an enclave’s measurement hash (a cryptographic SHA-256 digest representing the enclave’s initial state).
2. Initialization
   • Once all required code/data is loaded, the enclave is initialized (sealed).
   • The final measurement hash is computed and stored.
   • The initialization finalizes the enclave so that modifications to code pages are no longer permitted.
3. Enclave Mode
   • The CPU runs enclave code with specialized SGX instructions that enter/exit enclaves (e.g., EENTER, EEXIT).
   • From the software perspective, calling into the enclave is akin to switching from “user mode” to “secure enclave mode.”
4. Handling Interrupts & Exceptions
   • Even if an interrupt or page fault occurs, SGX ensures that the CPU exits the enclave safely.
   • All register states and sensitive data remain protected from inspection by the untrusted OS exception handlers.
5. Teardown
   • The enclave is destroyed, freeing EPC pages.
   • No residual secrets remain in unencrypted memory after teardown.