Understanding Secure Boot, Trusted Boot, Intel SGX, and ARM TrustZone

We first clarify industry‑wide definitions: Secure Boot verifies each component’s digital signature during startup and aborts on failure, preventing malicious tampering; Trusted Boot measures (hashes) each component, stores the measurements (e.g., in TPM PCRs), and later validates them against a trusted whitelist to ensure a trustworthy version.

Both mechanisms protect system‑level security for devices such as phones, STBs, routers, and servers, but they face challenges when applied to general‑purpose computers because runtime modifications can invalidate earlier checks.

To achieve stronger protection, runtime verification or secure storage of measurement data is required, which is feasible mainly on closed, customizable embedded systems.

For general computing devices, global protection becomes impractical due to open‑source ecosystems and user‑controlled OS/app versions. Consequently, protection scopes shrink to application fragments, leading to technologies like Intel SGX and ARM TrustZone.

Intel SGX workflow (illustrated in the image below):

1. Application design separates trusted (sensitive) and untrusted parts.

2. Trusted code is written in Enclave Definition Language (EDL) and runs inside an enclave.

3. Untrusted code calls enclave functions via drivers; calls are marshalled into the enclave.

4. Enclave data is invisible to external code, even privileged OS code.

5. After processing, results are returned while data remains inside the enclave.

6. The untrusted part continues execution with the returned result.

ARM TrustZone (standard TEE) workflow:

1. A secure OS must be present and trusted on the device.

2. Sensitive processing is implemented in a Trusted Application (TA) separate from the normal app.

3. The normal app sends messages to the TA via standard TEE interfaces.

4. Messages are transferred to the secure world through kernel drivers.

5. The TA executes the requested logic in the secure world.

6. Results are returned to the normal app, while intermediate data stays in the TEE.

Both SGX and TrustZone rely on developers to keep sensitive data and processing inside the secure domain; otherwise, the security guarantees are weakened. SGX typically requires only code changes, whereas TrustZone needs a separate TA deployment, which can be more complex but offers comparable isolation.

In media‑DRM scenarios, encrypted streams are decrypted inside the secure domain (SGX or TrustZone) and consumed directly by secure drivers, preventing plaintext exposure on the normal side.

Overall, SGX and TrustZone are not competing layers but complementary hardware‑based isolation techniques; SGX is more akin to AMD SEV, while TrustZone implements a full Trusted Execution Environment.