Is Android Killing TEE?

The Android operating system inherits its security controls from Linux. While these controls are sufficient for most apps, there are use cases where apps require stringent security environment to execute code. E.g. Your banking app needs to transfer funds securely. Google answered this question by providing TEE. TEE stands for Trusted execution environment. This component can either be implemented in software or hardware. The latter is physically & logically separate from the main operating system. The isolated nature of the TEE prevents security compromises in the main operating system from affecting it. This ensures the confidentiality and integrity of data and computations processed within the TEE.

Today TEEs help Android secure a limited number of use cases

1. Keymint - stores cryptographic keys securely. This involves limiting private key access to apps that requested the. E.g. App1's private key is not extractable and not visible to App2's private key
2. Widevine - protects copyrighted video content. This helps apps stream DRM-protected media securely
3. Biometrics - Helps apps authenticate  
4. Isolated Compilation - protects the integrity of run-time compiled code

However, as you can imagine, there are many cases an app developer would want to use TEE for its sensitive operation. This was not possible with TEEs. TEEs are tightly integrated with the main operating system. Communication between the secure and un-secure world is tightly controlled. Furthermore, TEE is implemented as SOC-specific firmware running in ARM TrustZone. Android does not put any requirement on this implementation making it hard for OEMs to align hardware and software incompatibilities.

This is where  Android virtualization framework (AVF) comes in.

Android Virtualization Framework (AVF) provides secure and private execution environment for executing code. AVF is hypervisor technology used and deployed to isolate workloads and operating systems from each other. It enables efficient scaling of infrastructure, environments, legacy software compatibility, creating virtual desktops, and more. Similar to how Android utilizes Linux processes but instead of processes you now have an entire VM.  

Basically, an Android app can spawn a VM that is isolated from the main operating system. Broadly there can be two types of VMs

1. One-way isolation - The host (Android OS) can control and inspect the VM
2. Two-say isolation - The host & VM are isolated except for explicitly agreed-upon communication channels. Even if Android is compromised (including the host kernel), the isolated VM remains uncompromised.

With the rise of private/on-device AI, it's important to have an isolated, portable, and flexible environment where apps & services process prompts and sensitive PII data. AVF fulfills this requirement.

I will delve into the technical details of AVF here. Stay tuned

That's it for this week.

Cheers