Zero Trust, Zero TEE: Porting Android 16 to a Device Whose Security Stack Doesn't Exist Yet

Android's security model is a chain of promises. Bootloader trusts TrustZone. TrustZone backs HWKM. HWKM feeds Keystore2. Keystore2 trusts VINTF manifests. Every security writeup, every hardening guide, every architecture diagram assumes this chain is intact and working.

Bring-up doesn't get that luxury. Bring-up starts from nothing. This talk is about porting YAAP (Android 16/17) to the Motorola Vienna (MT6878, Dimensity 6300) and watching Android's security stack fail to assemble itself - in three specific, revealing ways.

Failure 1 - The Silent Boot Loop

• inlinecrypt in fstab tells the kernel to use inline hardware encryption

• The key lives inside a Trustonic TA inside TrustZone - which isn't initialized yet during early bring-up

• The kernel just waits. No panic. No log entry. Absolute silence.

• What this exposes: the kernel-TEE dependency is far tighter than anything in the framework-level docs suggests

Failure 2 - The VINTF Lie

• The vendor blob dump shipped with Thales StrongBox VINTF declarations intact

• StrongBox wasn't actually there. The manifest said it was.

• Keystore2 believed the manifest. Watchdog crashes started firing.

• What this exposes: VINTF is a contract, and when the vendor side of that contract is wrong, the framework has no graceful fallback - it just breaks

Failure 3 - The Upstream Bug

• A casing inconsistency in libwifi_hal/Android.bp in AOSP 17 silently killed the WiFi HAL

• Not a vendor issue. A bug in mainline AOSP itself.

• Debug path: logcat -> VINTF resolution failure -> build system trace -> the single wrong-case character in Android.bp

The security angle most bring-up talks never touch:

• When Keystore2 is running without hardware backing, what actually happens to credential-backed keys?

• When a VINTF manifest lies about StrongBox, which guarantees does the framework silently drop?

• Three concrete observations on what a device in mid-bring-up state actually exposes

The failure modes during bring-up aren't random. They map directly to architectural decisions. Bring-up is the only context where you get to watch those decisions matter in real time - layer by layer, from nothing.

Why inlinecrypt can produce a silent boot hang and what that reveals about kernel-TEE coupling
How VINTF manifests can actively mislead Android's security stack
What a device in mid-bring-up state actually exposes from a security standpoint
debugging across fstab, VINTF, HAL layers and logcat for AOSP bring-up issues