[Android Software Development] pndwal:
Several aspects mentioned below...

See paragraph *

Nb. Reward for remote code execution exploits in TEE, up to $250,000. In Pixel Titan M secure element (chip) specifically, up to $1000,000.

Just to be clear, although we (and even John Wu, Momo app etc) are speaking of broken / breaking TEE, really this means only it's security implementation, ie embedded keymaster/keystore responsible for hardware based attestation to the integrity of the TEE OS itself, Verified boot, etc etc...

TEE itself is NOT actually broken even in OnePlus, Asus etc... It needs to be working properly for a number of functions including the oemcrypto module, an HDCP Encryption-Decryption Engine for securely rendering HD content (ie. to run Widevine content decryption module) etc, used by YouTube, Netflix, Hulu, Amazon etc, and these work fine on OnePlus etc...

Technical:

Essential Trusted Applications (TA's), software running in a secure context in TrustZone or other, include Keymaster TA which provides all of the secure Keystore operations including those mentioned above, has access to the raw key material, validates all of the access control conditions on keys, etc, Gatekeeper TA which is responsible for authenticating user passwords and generating authentication tokens used to prove to the Keymaster TA that an authentication was done, and Fingerprint TA which is responsible for authenticating user fingerprints and generating authentication tokens used to prove to the Keymaster TA that an authentication was done.

Verified Boot (and the augmented AVB since Android 8) strives to ensure all executed code comes from a trusted source (usually device OEMs), rather than from an attacker or corruption. It establishes a full chain of trust, starting from a hardware-protected root of trust to the bootloader, to the boot partition and other verified partitions including system, vendor, and optionally oem partitions. During device boot up, each stage verifies the integrity and authenticity of the next stage before handing over execution.

In addition to ensuring that devices are running a safe version of Android, Verified Boot checks for the correct version of Android with rollback protection. Rollback protection helps to prevent a possible exploit from becoming persistent by ensuring devices only update to newer versions of Android.

In addition to verifying the OS, Verified Boot also allows Android devices to communicate their state of integrity to the user.

A Trusted Execution Environment (TEE) is an environment in a system on a chip (SoC) for executing code, in which those executing the code can have high levels of trust unlike the Rich Operating System Execution Environment (REE) that is Android.

So TEE includes a Trusted OS that runs on the same processor as the Android OS, but is isolated from the rest of the system by both hardware and software using ARM’s Trustzone or Intel’s Virtualization Technology to virtualize the main processor and create a secure trusted execution environment.

The TEE OS and Android run parallel to each other. TEE OS has access to the full power of a device’s main processor and memory but is completely isolated, protecting it from malicious apps installed by the user and potential vulnerabilities...

Google recommends their own Trusty TEE/OS consisting of a small OS kernel derived from Little Kernel, a Linux kernel driver to transfer data between the secure environment and Android, and an Android userspace library to communicate with trusted applications (TA's) via the kernel driver.

Nb. Since Android supports various TEE implementations OEMs are not restricted to using Trusty. Other party's TEE OSs have their own unique way of deploying trusted applications, but I believe most use Google's Trusty OS for its cost and stability benefits.

*Incidentally, a TEE also incorporates it's own Trusted OS Bootloader for Secure start-up of the Trusted OS (ie. EVERYTHING is signature checked, immutable, or held in isolation).

A Hardware-backed Keystore became practical since Android 7.0 (w/ Keymaster 2) added support for key attestation and version binding. Key attestation provides public key certificates that contain a detailed description of the key and its access controls, to make the key's existence in secure hardware and its configuration remotely verifiable. Android 8.0 extended the attestation feature in Keymaster 3 to support ID attestation, providing a mechanism for strongly attesting to hardware identifiers, such as device serial number, product name, and phone ID (IMEI / MEID), and it seems this is the level required by Google for Hardware evaluation type / STRONG _INTEGRITY verdicts using HKA.

👀 PW