Independent Assessment of Cache Timing and Fault-Injection Bypass in a Smart-Home TEE

Cache timing on AES-GCM. Prerequisites: code execution on the hub in the normal world, co-resident with the TEE, and enough chosen encryptions. The leak is four bits per 10,000 encryptions, so key recovery is not immediate but is plausible over a long-running service with attacker-controlled inputs. Impact: compromise of Wi-Fi credentials or cloud tokens, and possibly door-lock codes if they are encrypted under the same key. Voltage-glitch secure-boot bypass. Prerequisites: physical access and a glitch setup; success is about 1 in 5,000 boots. Impact: an unsigned image runs while the API reports secure boot enabled, so the attacker gains persistent code execution and the management service is deceived. For a hub in customers’ homes, physical access is realistic. The fault finding is more serious because it breaks the root of trust and the integrity reporting that the entire service depends on; the timing leak is serious but requires a local software foothold. Both contradict the marketing claim, which says physical attacks are in scope. The fault also creates a false attestation signal, which is worse than a plain compromise.

Timing: replace the AES-GCM implementation with a constant-time implementation, preferably using hardware AES or a bitsliced, table-free design; avoid data-dependent cache access and S-box tables. If shared caches are inherent, isolate the crypto service or add noise, but do not rely on noise alone. Validate with TVLA-style leakage tests, repeated key-recovery attempts, and a co-resident attacker benchmark; require the leak to be below the detection threshold. Fault: add voltage and clock glitch detectors, redundant signature verification with independent checks, and a hardware-backed secure-boot status that cannot be overridden by software. The boot ROM should verify the next stage twice from separate buffers and fail closed on mismatch. Add a monotonic boot counter and log anomalies. Validate with a fault-injection campaign across voltage and temperature, targeting the signature check; require no successful bypass in a statistically meaningful sample. Also fix the API so “secure boot enabled” is read from the hardware state, not a software flag. Retest after any ROM change.

Do not procure the device for door-lock codes on the current firmware. The vendor’s threat model excludes physical attacks, but the product claim does not; that is a governance defect, not just a technical one. Require the vendor to either fix the fault and timing issues or formally withdraw the physical-resistance claim and re-scope the product. For disclosure, follow coordinated disclosure: give the vendor a 90-day window, provide a reproducible test case, and agree on a customer advisory. The managed-service operator should notify its own customers if deployed devices are affected. Residual risk could be accepted only for lower-value uses, with compensating controls: no storage of door-lock codes, network segmentation, tamper detection, and a contractual right to audit. For door-lock codes, accept only after a successful retest of the fixed ROM and a revised threat model. Add a contractual clause that security claims must match the evaluated threat model, and require SBOM and update commitments.