Threat Modeling a TEE License Vault on a Rooted Set-Top Box
Your company ships 12 million set-top boxes. Each box runs a TrustZone-based TEE: the secure world holds content-decryption keys and a license counter, while the normal world runs a Linux stack that any owner can root. The marketing team wants to claim that “content keys cannot be extracted, even from a rooted device.” A recent forum post shows a script that runs as root, reads a license token from normal-world memory, and replays it to a second device profile, enabling unlimited offline playback. No key was extracted. Engineering proposes binding each license token to a TEE monotonic counter, but the counter storage is rated for 10,000 writes and the device writes on every play. The secure-world firmware is also shared across three SoC variants; the oldest variant lacks hardware key-derivation support, so the team plans a software fallback for it. The launch is in six weeks and the claim is already in a draft press release.
1. Identify the assets, trust boundaries, and attacker capabilities, and assess whether the marketing claim is defensible. What should the claim say instead?
Read the worked answer
Assets: content-decryption keys, license tokens and counter, device identity key, and the integrity of the playback policy. Trust boundaries: normal world vs. secure world; device vs. license backend; and the shared firmware across three SoC variants, which is also a supply-chain boundary. Attacker capabilities: root in the normal world, physical possession, eMMC read/write, UART access; no decapping or high-end fault injection. Under that model, the claim “keys cannot be extracted even from a rooted device” is too narrow to be useful and is misleading. The demonstrated attack does not extract a key; it abuses a valid token, so the confidentiality control worked while the authorization control failed. The claim also ignores rollback of the eMMC and the software fallback on the oldest SoC. A defensible claim would be scoped: “Content keys are isolated in a hardware TEE against software attackers with root; license replay is prevented by TEE-bound, anti-rollback tokens.” It should state exclusions: no claim against physical fault injection, and no claim for the oldest variant if it uses software key derivation. Marketing needs legal review because “cannot be extracted” is an absolute.
2. Evaluate the monotonic-counter proposal. What are its failure modes, and what design would you recommend for offline playback?
Read the worked answer
At 10 plays/day, 10,000 writes lasts under three years; at heavier use it fails in months. Wear-out also creates a denial of service and can push the device into a fallback that may weaken enforcement. A per-play counter in one hot location is the wrong granularity. Recommend:
- Derive a per-license key inside the TEE from a device key, content ID, and license window; make the token a MAC over those fields rather than a raw counter.
- Keep a coarse rollback epoch in RPMB or secure flash, written only when the license is refreshed or every N plays; batch writes.
- For offline use, enforce a signed license window and maximum plays per window; use the backend to issue a fresh nonce when online.
- Protect against eMMC rollback with an authenticated, log-structured counter, not a single cell; reserve OTP only for rare irreversible events.
- Test power loss during counter update and ensure atomic commit. The counter can be part of the design, but only as a coarse anti-rollback mechanism; it cannot carry per-play state.
3. The oldest SoC cannot do hardware key derivation. How should that affect the shared firmware strategy and the launch decision?
Read the worked answer
Sharing one secure-world image across three SoCs means one memory-safety or logic bug is fleet-wide; that is a concentration risk, not an efficiency win. The oldest variant with software key derivation is a different assurance class: keys may be derivable from normal-world-readable material or from a weaker root, so it should not carry the same content or the same marketing claim. Options: (a) build per-SoC images from common source with per-variant keys and compile-time hardening; (b) drop the oldest variant from the premium content service or give it a secure element; (c) if neither is possible, isolate it with a separate key hierarchy and lower-value content, and document the reduced assurance. For the six-week launch, do not ship the same claim across all variants. Ship the claim only for the two variants with hardware key derivation, and treat the oldest as a separate product with a clear limitation. Also require a firmware update path that can revoke a variant if a vulnerability is found.