TEE Fundamentals and Threat Modeling
This domain tests whether you can define a TEE precisely, draw its trust boundary, and build a defensible threat model. Expect questions that distinguish assets, adversaries, and assumptions rather than asking for product names.
Definitions and boundaries
- A TEE is an execution environment whose code and data are isolated from a richer operating environment (the REE) and from privileged software such as a hypervisor, using hardware-enforced separation. Isolation covers confidentiality and integrity; it usually does not cover availability.
- The trusted computing base (TCB) is everything that must be correct for the security claim: hardware, boot ROM, TEE OS, the trusted application (TA), and any monitored dependencies. Anything outside the TCB is untrusted by definition.
- A threat model names assets (keys, biometric templates, policy), adversary capabilities (REE app, hypervisor, physical probing, fault injection, side channel), and explicit non-goals. The trust boundary is where data crosses from untrusted to trusted; every crossing needs validation.
Core rules
- Never treat REE-supplied pointers, lengths, or time as trustworthy. Copy shared buffers into TEE memory and revalidate before use.
- A TEE is not a secure element. A secure element is tamper-resistant hardware with its own CPU and memory; a TEE shares an SoC and is generally not resistant to invasive physical attacks.
- Availability is out of scope: a malicious host can usually refuse to schedule a TA or cut power.
Worked example
Model a fingerprint-unlock feature. Asset: template and match decision. Adversaries: a malicious Android app, a compromised REE kernel, and a thief with the locked device. TCB: boot ROM, TrustZone monitor, TEE OS, fingerprint TA, and the sensor-to-TEE path. Assumption: the fingerprint sensor bus is protected; if it is not, the template can be replayed, so either add bus protection or declare it a residual risk. The match result must be signed or returned through a secure channel, not as a plain boolean the REE can forge. The model also records that a host can deny service but not learn the template.
Traps
- Claiming a TEE resists all physical attacks.
- Putting the REE in the TCB because it loads the TA.
- Confusing the TCB with the whole product software stack.
- Forgetting that the TEE OS itself is attack surface.