TEE Engineer License study materials
TEE Engineer License study resources

TEE Engineer License: Trusted Applications and Enclave Development

TEE Engineer License · Work through your exam, one topic at a time.

All guide sections

Trusted Applications and Enclave Development

This domain tests whether you can write and review trusted code that survives a hostile host. The exam focuses on the boundary (parameter handling, session state, secret lifecycle) more than on API trivia.

TA model

  • GlobalPlatform defines the TEE Internal Core API: a TA is identified by a UUID, has a lifecycle (create, open session, invoke command, close, destroy), and receives parameters as value, temp memref, or registered shared memory. The client API runs in the REE and is untrusted.
  • Enclave SDKs expose ecalls (untrusted to trusted) and ocalls (trusted to untrusted). Every ocall is a trust-boundary crossing and can block, fail, or be re-entered.

Rules for the boundary

  • Validate every parameter: type, length, range, and null. Copy memrefs into TA-private memory before parsing; do not hold a host pointer across a blocking call, which creates TOCTOU risk.
  • Keep secrets in TA memory only; zero buffers before free; never log keys or PINs. Seal persistent secrets and use a monotonic counter for rollback-sensitive state.
  • Do not trust REE time, REE randomness, or REE identity. Use the TEE crypto API and secure time if available; otherwise design for skew.
  • Design for interruption and multiple sessions; avoid global mutable state, and bound loops so a host cannot force a watchdog reset.

Worked example

Design a PIN-verification TA. The REE sends a PIN entry request, but the TA renders the secure UI and reads the PIN directly from the trusted input path. It derives a verifier with Argon2 using a per-user salt, compares in constant time, and increments a sealed retry counter backed by a monotonic counter. After three failures it blocks and seals the lockout state. On success it returns a short-lived authorization token signed by a TA key, not the PIN. Reasoning: the REE never sees the PIN, offline guessing is slowed by the KDF, and rollback of the retry counter is prevented.

Traps

  • Dereferencing a host pointer directly.
  • Using REE time for lockout expiry.
  • Returning an error string containing secret data.
  • Assuming multi-instance means isolation from other instances of the same TA.