TEE Security Assessment and Vulnerability Analysis
This domain tests how to find and classify weaknesses in a TEE implementation: what to review, how to test the boundary, and how to judge impact. Expect questions about vulnerability classes and evidence, not tool brand names.
Method
- Start with architecture and data-flow review: identify every untrusted-to-trusted crossing, the TCB, and the attestation and key-release path. Then review the TA command dispatcher, shared-memory handling, and persistent storage.
- Dynamic testing: fuzz command IDs, lengths, and state sequences through the client API; use fault injection (voltage and clock glitches) on boot and secure storage; test debug and lifecycle states; measure cache and branch behavior for side channels.
- Verify attestation end-to-end: does the verifier check the signature chain, nonce, measurements, TCB level, and revocation?
Vulnerability classes
- Parameter validation bugs and integer overflows in memref handling; TOCTOU when a shared buffer is re-read after validation; use-after-free across sessions; rollback of sealed state; missing anti-rollback on firmware.
- Microarchitectural leaks (cache, speculative execution, port contention), power and EM side channels, and fault attacks. Published examples include Foreshadow/L1TF against SGX, Plundervolt fault injection via undervolting, and various TrustZone vulnerabilities in vendor TEEs.
Worked example
A TA command takes a memref and length, checks len <= 64, then copies into a 64-byte stack buffer with memcpy. The length field is a 32-bit unsigned value supplied by the REE; the check passes for 64, but a length of 0 with a null pointer causes a null dereference, and a length that changes between the check and copy (TOCTOU on registered shared memory) can overflow. The reviewer rates this high because the TA handles a device key; the fix is copy-in first, then validate the copied length, and reject null.
Traps
- Passing functional tests and calling it a security assessment.
- Testing only the happy path through the client API.
- Ignoring error paths and session teardown.
- Assuming attestation proves the absence of vulnerabilities.