Enclave SDK

The SDK includes a modified compiler toolchain (e.g., a patched GCC or LLVM) that understands the memory layout and instruction set of the target TEE. It handles the critical task of splitting the application into a trusted component (which runs inside the enclave) and an untrusted component (which runs outside). The build process automatically generates the necessary boilerplate for enclave entry points (ECALLs) and exit points (OCALLs), and produces a final signed enclave binary package.

This is a minimal, hardened standard C/C++ library compiled to run inside the enclave. It provides a subset of libc/libcxx functionality but is explicitly designed to avoid system calls that would force an enclave exit. Key features include:

• Memory allocators that operate only on enclave-private memory.
• Cryptographic primitives (RNG, hashing) that leverage hardware-backed secrets.
• Stub or emulated functions for operations that must be proxied to the untrusted host OS via OCALLs. Using this library prevents accidental linkage to the full, untrusted host OS libraries.

These libraries provide the APIs for the two foundational cryptographic operations of a TEE:

• Local Attestation: Generate a cryptographically signed report that proves the enclave's identity and integrity to another enclave on the same platform.
• Remote Attestation: Generate a verifiable quote, often via a hardware-rooted service like Intel's Attestation Service, that allows a remote verifier to confirm the enclave is genuine and running approved code.
• Sealed Storage: Encrypt data using a key derived from the enclave's identity and platform hardware, so it can only be decrypted by the same enclave (or a descendant) on the same secure platform.

The Enclave Definition Language is a proprietary interface definition language used to explicitly declare the functions that cross the trust boundary. An EDL file specifies which functions are ECALLs (entry calls into the enclave) and which are OCALLs (out calls from the enclave to the untrusted host). The SDK's bridge generator parses the EDL file and auto-generates the proxy and marshaling code for both sides (trusted/untrusted), ensuring secure parameter passing and preventing manual coding errors at this critical interface.

Developing for a black-box environment like an enclave requires specialized tooling. The SDK provides:

• Enclave Debuggers: Modified versions of GDB that can attach to a running enclave in debug mode, allowing inspection of trusted memory and registers.
• Performance Counters: Tools to profile ECALL/OCALL latency and enclave memory usage, as transitions across the trust boundary are computationally expensive.
• Memory Analysis Tools: Utilities to check for common pitfalls like uncontrolled enclave page cache (EPC) swapping, which can create side-channel vulnerabilities.

Before an enclave can be launched, its binary must be cryptographically signed. The SDK includes a signing tool that:

• Takes the built enclave binary and a developer's private signing key.
• Produces a signature that is embedded into the final enclave package.
• This signature is validated by the CPU during enclave initialization. The tool often integrates with Hardware Security Modules (HSMs) for production key storage and supports creating different signatures for debug (which allows introspection) vs. release modes.

Isolated Execution is the core security property provided by a TEE, where a software component runs in a protected environment with strict boundaries that prevent other system components, including the OS kernel and hypervisor, from observing or tampering with its internal state, code, or data.

• Contrasts with sandboxing, which is typically enforced by software (e.g., an OS kernel).
• Enforced at the hardware memory controller level via access control checks.
• The enclave's memory pages are encrypted when outside the CPU package.