Aster: Fixing the Android TEE Ecosystem with Arm CCA

TL;DR

The AndroidTEE landscape suffers from TrustZone’s overprivilege and insecure interfaces, enabling attacks that compromise Android and security services. The authors propose Aster, a sandboxed service framework that leverages Arm Confidential Computing Architecture to enforce mutual isolation among Android, the Realm World, and Secure World by using two memory views (GPTs) and RMM/Tf coordination. Aster implements SBSs in the Realm World, provides secure interfaces via shared memory and vetted IO, and relies on hardware attestation for SBS validation, achieving containment of compromised SBSes and protected interactions with Android apps. Evaluation on a simulator demonstrates feasibility and compatibility with existing Android services, with acceptable one-time boot overheads and tangible SBS-related costs, suggesting Aster as a practical design space for secure Android TEEs. Overall, Aster reframes the Android TEE security model around sandboxed realm-VM execution with hardware-assisted isolation and attestation, offering a path to stronger, verifiable security for security-sensitive Android services.

Abstract

The Android ecosystem relies on either TrustZone (e.g., OP-TEE, QTEE, Trusty) or trusted hypervisors (pKVM, Gunyah) to isolate security-sensitive services from malicious apps and Android bugs. TrustZone allows any secure world code to access the normal world that runs Android. Similarly, a trusted hypervisor has full access to Android running in one VM and security services in other VMs. In this paper, we motivate the need for mutual isolation, wherein Android, hypervisors, and the secure world are isolated from each other. Then, we propose a sandboxed service abstraction, such that a sandboxed execution cannot access any other sandbox, Android, hypervisor, or secure world memory. We present Aster which achieves these goals while ensuring that sandboxed execution can still communicate with Android to get inputs and provide outputs securely. Our main insight is to leverage the hardware isolation offered by Arm Confidential Computing Architecture (CCA). However, since CCA does not satisfy our sandboxing and mutual isolation requirements, Aster repurposes its hardware enforcement to meet its goals while addressing challenges such as secure interfaces, virtio, and protection against interrupts. We implement Aster to demonstrate its feasibility and assess its compatibility. We take three case studies, including one currently deployed on Android phones and insufficiently secured using a trusted hypervisor, to demonstrate that they can be protected by Aster.

Figures (5)

• Figure 1: Security in TrustZone. Blue: Normal world Orange: secure world. s1, s2 are sandboxes. s3, s4 are secure world TAs (a) no virtualization support (b) virtualization support in the normal world (c) virtualization support in the secure world
• Figure 2: Arm CCA architecture with CCA's trusted software with shaded background. Each core has a Granule Protection Check (GPC) which is programmed with a Granule Protection Table (GPT). Each core also has a $\tt{sec\_state}$ register which indicates which world the core executes in : Root (Rt), Realm (Rl), Normal (N), or Secure (S). The GPT maps physical address to one of the six Physical Address Space (PAS) values. For each memory access, the GPC looks up the GPT and compares the PAS of the physical address to the value in the $\tt{sec\_state}$ register.
• Figure 3: Isolation in different settings where S1 and S2 are two TAs such that: (a) Android executes in the normal-world and S1, S2 in the secure world. (b) Android and S1 are mutually isolated in the normal world. S2 is still overprivileged and can attack Android and S1. (c) Solution 1: move Android to realm world. (d) Solution 2: execute SBSes in the normal world (e) Solution 3: isolate SBSes in the secure world from Android using two-GPTs (f) Aster: executes SBSes in the realm world and ensures mutual isolation between the worlds.
• Figure 4: Enforcing Aster primitives during SBS creation. S1 and S2 are SBSes, PA is physical address, IPA is intermediate physical address (a) a1. Hypervisor delegates PA to realm; a2. RMM calls TF to delegate PA to realm; a3. TF checks and then updates GPT to ensure \ref{['s:iso']}. (b) b1. Hypervisor adds data to SBS S2; b2. RMM checks that the PA is not assigned to any other SBS for \ref{['s:sand']}, then updates S2-tables; b3. then calls the TF to measure the granule \ref{['s:att']}. (c) c1. Hypervisor calls create shared memory for SBS; c2. RMM checks and invokes the TF to update GPT; c3. TF checks then updates GPT for \ref{['s:iso']} and then returns to the RMM; c4: RMM updates the S2-tables to enforce \ref{['s:int']}.
• Figure 5: Changes to the 2 GPTs by the TF from time t$_0$ to t$_3$. Root (in yellow), Realm (RL in green), Normal (N in blue), Not-accessible (NA in grey), and Secure (S in orange). t$_0$: at boot TF marks the normal world memory as not-accessible in GPT$_{rs}$. t$_1$: to delegate granule PA$_{del}$ the TF marks it as realm in both GPTs. t$_2$: to share granule PA$_{share}$ the TF marks it as normal in GPT$_{n}$ and realm in GPT$_{rs}$. t$_3$: to undelegate PA$_{del}$ the TF marks it normal in GPT$_{n}$ and not-accessible in GPT$_{rs}$.