TEE Engineer License cheat sheet

TEE threat model assumes a powerful adversary controlling the rich OS, hypervisor, and physical memory bus; it does not protect against microarchitectural side channels unless explicitly mitigated.

TEE security objectives: confidentiality and integrity of code/data in use, remote attestation of the initial state, and sealed storage bound to the TEE identity.

Trust boundary: TEE trusted computing base (TCB) includes hardware, firmware, TEE OS, and the trusted application; everything else (REE OS, apps, peripherals) is untrusted.

Attack surface categories: enclave interface (ECALL/OCALL), shared memory, interrupt/exception handling, power management, and debug interfaces.

Confidentiality vs. integrity: encryption alone does not prevent replay or rollback; integrity protection (hashing, version counters) is required for sealed data.

Side-channel classes: cache-timing, branch-predictor, speculative execution, power/EM, and page-fault oracles; mitigations include constant-time code, cache partitioning, and TEE-aware scheduling.

Formal threat modeling: identify assets (keys, measurements, user data), entry points, trust boundaries, and attacker capabilities; map to STRIDE or LINDDUN as appropriate.

TEE does not eliminate the need for secure coding: TOCTOU, double-fetch, and unvalidated shared-memory pointers are common enclave vulnerabilities.

Residual risk acceptance: physical attacks (cold boot, bus probing) and supply-chain compromise are often out of scope for a given TEE deployment but must be documented.

Arm TrustZone: normal world (REE) and secure world (TEE) separated by the secure monitor (EL3); memory isolation via TZASC and TrustZone Address Space Controller.

Arm CCA: adds Realm world (EL3) with Realm Management Extension (RME) and Granule Protection Table (GPT) for dynamic memory assignment; realms isolated from both normal and secure worlds.

Intel SGX: enclaves in user-space; Enclave Page Cache (EPC) protected by Memory Encryption Engine (MEE); SGX2 adds dynamic memory and thread support.

Intel TDX: confidential VMs (TDs) isolated by a Secure Arbitration Mode (SEAM) module; trust boundary includes TDX module and CPU, not the VMM.

AMD SEV-SNP: encrypted VMs with reverse map table (RMP) for integrity and nested page fault prevention; vTPM and attestation report signed by AMD.

RISC-V Keystone: open-source TEE using PMP (Physical Memory Protection) and a security monitor; enclave memory isolated via PMP regions.

Platform isolation primitives: IOMMU/SMMU for DMA remapping, interrupt remapping, and memory encryption engines (AES-XTS) for DRAM confidentiality.

TEE OS examples: OP-TEE (Arm), Trusty (Google), SierraTEE, and seL4-based microkernels; each defines its own TA lifecycle and IPC model.

Isolation strength depends on firmware and microcode: SMM, ME/CSME, and PSP are part of the root of trust and must be patched and measured.

Root of trust: immutable ROM (boot ROM) verifies the first mutable code; chain of trust extends through firmware, bootloader, TEE OS, and TAs.

Measured boot: each stage extends a PCR (TPM) or measurement register with a hash; attestation quotes the PCR values signed by an Attestation Key (AK).

Secure boot vs. measured boot: secure boot enforces signature verification before execution; measured boot records what ran without necessarily blocking.

Remote attestation flow: challenge (nonce) → TEE generates report → sign with device key → verifier checks signature, measurement, and freshness.

Key hierarchy: Hardware Unique Key (HUK) → per-device keys → per-TA keys; sealed storage encrypts keys bound to TA identity and device.

Key sealing: encrypt data with a key derived from HUK and bound to TA UUID, version, and security state; unsealing fails if binding changes.

Attestation key protection: keys stored in TEE-protected storage or hardware security module; never exportable in plaintext.

Rollback protection: use monotonic counters or version numbers stored in secure non-volatile memory to prevent loading older, vulnerable firmware.

Key lifecycle: generation, activation, rotation, revocation, and destruction; revocation must propagate to attestation verifiers.

TA lifecycle: load → initialize → open session → invoke commands → close session → unload; each transition has defined security checks.

GlobalPlatform TEE Internal Core API: defines TA entry points (TA_CreateEntryPoint, TA_OpenSessionEntryPoint, TA_InvokeCommandEntryPoint) and trusted storage APIs.

Shared memory: REE passes buffers via registered shared memory; TA must validate length, alignment, and direction (in/out/inout) before use.

ECALL/OCALL boundary: minimize OCALLs; each OCALL is an attack surface and may leak timing or data to the REE.

Enclave entry/exit: SGX uses EENTER/EEXIT and asynchronous exits (AEX) for interrupts; state must be saved/restored securely.

Secure IPC: use message queues with capability-based access; avoid global mutable state shared between sessions.

Trusted storage: data encrypted and integrity-protected; TA must handle storage full, corruption, and rollback errors gracefully.

Debug and logging: disable debug interfaces in production; logs must not contain secrets and should be rate-limited to avoid side channels.

Testing: use TEE emulators (QEMU with OP-TEE) and fuzzing of TA command handlers; validate error paths and resource exhaustion.

Assessment scope: TEE OS, TAs, firmware, boot chain, attestation service, and key provisioning; include interfaces between worlds.

Common vulnerability classes: unvalidated shared-memory pointers, integer overflows in command parsing, TOCTOU, and missing access control on TA commands.

Side-channel testing: cache occupancy, Prime+Probe, Flush+Reload, and page-fault attacks; use tools like CacheQuery and custom microbenchmarks.

Fuzzing: harness TA command handlers with malformed inputs; coverage-guided fuzzing of the TEE OS syscall interface.

Static analysis: review for double-fetch, uninitialized memory, and improper error handling; use compiler sanitizers where supported.

Known attack families: SGX spectre variants (SgxPectre), Plundervolt (voltage faulting), VoltPillager, and TrustZone exploits (e.g., Qualcomm QTEE vulnerabilities).

Penetration testing: attempt to load unsigned TAs, bypass attestation, extract sealed keys, and escalate from REE to TEE.

Remediation validation: confirm patches via re-testing, check version counters, and verify attestation reports reflect the fixed measurement.

Reporting: map findings to CWE/CVE, provide proof-of-concept, and assess impact on confidentiality, integrity, and availability.

Confidential computing protects data in use; combines with encryption at rest and in transit for end-to-end data protection.

Confidential VMs: Intel TDX, AMD SEV-SNP, and Arm CCA Realms provide VM-level isolation from the hypervisor and host OS.

Deployment models: lift-and-shift confidential VMs, enclave-based microservices, and confidential containers (e.g., Kata Containers with TEE).

Attestation in deployment: verifier service checks TEE quote against policy (measurements, TCB version) before releasing secrets or admitting the workload.

Key management integration: KMS releases disk encryption keys only after successful attestation; use sealed secrets or key broker services.

Performance overhead: memory encryption and context switches add cost; measure with representative workloads and consider I/O passthrough trade-offs.

Orchestration: Kubernetes device plugins and confidential containers runtime (e.g., confidential-containers project) manage TEE resources.

Migration and live migration: confidential VMs often restrict or require special protocols for live migration to preserve confidentiality.

Compliance alignment: confidential computing supports data residency, GDPR, HIPAA, and financial regulations by limiting host access.

GlobalPlatform: TEE System Architecture, TEE Internal Core API, TEE Client API, and TEE Protection Profile (PP) for security certification.

Common Criteria: TEE products evaluated against Protection Profiles (e.g., GP TEE PP); EAL levels indicate assurance depth.

ISO/IEC 11889 (TPM 2.0): defines TPM interfaces, structures, and commands; relevant for measured boot and attestation.

NIST SP 800-193: Platform Firmware Resiliency Guidelines; covers protection, detection, and recovery of firmware.

Confidential Computing Consortium (CCC): publishes whitepapers, threat models, and open-source projects; not a certification body.

FIPS 140-3: cryptographic module validation; TEE crypto implementations may seek validation for government deployments.

GDPR/CCPA: TEEs can support data minimization and pseudonymization by keeping personal data inaccessible to the host.

Export controls: strong cryptography in TEEs may be subject to export regulations (e.g., Wassenaar Arrangement).

Governance: define roles for TEE provisioning, attestation policy ownership, vulnerability disclosure, and patch management.