Harness: Transparent and Lightweight Protection of Vehicle Control on Untrusted Android Automotive Operating System

Harness: Transparent and Lightweight Protection of Vehicle Control on Untrusted Android Automotive Operating System

Speakers: Haochen Gong, Z University

Conference: USENIX Security

YouTube: https://www.youtube.com/watch?v=jLZuwRk6XfQ

Overview

Modern vehicles increasingly integrate sophisticated infotainment systems, with Android Automotive OS (AOS) emerging as a prominent platform due to its rich functionality, including touchscreen interfaces, voice assistance, diverse connectivity options, and support for third-party applications. Crucially, these systems are also often connected to critical electronic control units (ECUs) via the in-vehicle network, enabling direct vehicle control functions such as operating door locks, windows, seats, gear shifts, and even parking brakes. While these features enhance user experience, they simultaneously introduce significant security vulnerabilities. The inherent complexity and extensive functionality of Android expand the attack surface and enlarge the Trusted Computing Base (TCB), making the system susceptible to compromise.

The central problem addressed by this talk is the severe risk posed by a compromised Android Automotive IVI (In-Vehicle Infotainment) system. Should an attacker successfully exploit vulnerabilities within the IVI, they could gain full, unauthorized control over critical vehicle functions, leading to potential property damage, physical harm, and even life-threatening situations. The talk introduces "Harness," a novel solution designed to provide transparent and lightweight protection for vehicle control mechanisms operating on an untrusted Android Automotive operating system.

Harness aims to secure these vital vehicle control pathways by isolating trusted car components, protecting their inter-process and in-vehicle network communications, and restricting external access to their interfaces. The significance of this work lies in its potential to dramatically enhance automotive cybersecurity, ensuring that even if the feature-rich, complex Android environment is compromised, the fundamental safety and operational integrity of the vehicle remain firmly under the driver's control. It offers a practical and deployable architecture for safeguarding critical automotive functions against a growing landscape of digital threats.

Background

▶ Watch: Introduction: Security risks of Android Automotive OS (0:00)

The implementation of vehicle control within Android Automotive OS follows a multi-stage process, creating a substantial software stack and, consequently, a large attack surface. This process typically involves three stages:

1. HMI (Human-Machine Interface) Stage: Users interact with car applications via the touchscreen and other input methods.
2. Processing Stage: Car applications invoke car APIs exposed by the Car Service.
3. Output Stage: The Vehicle Hardware Abstraction Layer (VHAL or VEH) communicates with various ECUs through the in-vehicle network to execute specific vehicle control commands.

This intricate architecture, spanning from user interaction to hardware actuation, presents numerous points of vulnerability. The researchers identified 13 possible attacks across these stages, all of which could be exploited to seize control of the vehicle.

To address these challenges, the Harness project operates under a clearly defined threat model. It considers the entire Android Automotive OS, including its kernel, assistant services, and all third-party applications, as untrusted. Conversely, fundamental hardware components, the hypervisor, and specific system car components are assumed to be trusted. The model further assumes that the hypervisor can effectively prevent DMA (Direct Memory Access) attacks and that the AOS can enhance overall system security. To scope the work, Harness does not consider attacks against AI components, remote control functionalities, physical side-channel attacks, or denial-of-service (DoS) attacks.

A key observation underpinning the Harness design is that AOS explicitly defines security-critical car interfaces using a protection level attribute within its permission system. These interfaces are only accessible to trusted system components, such as system car applications and services. This explicit definition provides a clear and actionable secure boundary for isolation. Based on this, Harness's core idea is to isolate these trusted car components, protect their inter-process communication (IPC) and in-vehicle network (IVN) communications, and strictly limit external access to their interfaces.

The design goals for Harness were articulated across three critical dimensions:

• Security: The paramount goal is to ensure that an attacker, even with full compromise of the untrusted AOS, cannot gain vehicle control through any software residing outside the isolation domain. Only the trusted components within this domain should be capable of controlling the car.
• Efficiency: The solution must be lightweight, exhibiting acceptable performance overhead for protected operations and negligible impact on unprotected software.
• Usability: Harness must be transparent to both user-space software developers and end-users, requiring no complex adaptations for deployment and ensuring a seamless user experience.

Key Findings

▶ Watch: Defining the threat model for Harness (2:00)

Harness presents a comprehensive security architecture that provides a four-chain protection mechanism, extending from the Human-Machine Interface (HMI) through user-space car components and ultimately to the in-vehicle network. This multi-layered defense is built upon the core principle of isolating trusted components and securing their communications and interfaces.

The primary method for achieving isolation is through hardware virtualization, which is leveraged to create enclaves at a process granularity. Specifically designed for the ARM platform, Harness utilizes Stage 2 paging to realize robust memory isolation from the untrusted Android Automotive OS. Each enclave is assigned its own intermediate physical address space, and all enclaves share a protected and customized exception vector table. This shared vector table is crucial as it allows Harness to intercept critical system events.

The central component of Harness is the low visor, a specialized hypervisor module responsible for managing and protecting these enclaves. When an enclave executes and an exception occurs (such as a page fault or a syscall), it traps through the custom exception vector table, triggering a hypercall that directs control to the low visor. The low visor can handle certain exceptions directly or forward others to the guest kernel, subsequently checking the kernel's result before returning control to the enclave. To facilitate runtime support for enclaves, Harness introduces a dedicated kernel module that bridges the communication gap between enclaves and the kernel, alongside a library that enables unmodified Android components to execute within enclaves, thereby ensuring transparency for developers.

The researchers meticulously identified a minimal protection domain based on the security-critical interfaces defined by AOS. This domain includes essential components such as system car applications, the Car Service, the Vehicle Hardware Abstraction Layer (VEH), and the Hardware Composer (HWC) for secure display. A new zygote process is created to fork these new enclaves. The integrity of this protection domain is maintained through a whitelist and signature-based authentication to verify component identities. For interface protection, Harness employs encrypted channels to secure in-vehicle network (IVN) communications between the VEH and ECUs, and it also extends protection to the API and HMI of the encrypted components.

Harness effectively addresses three significant technical challenges inherent to securing Android Automotive:

1. Shared Memory: Android components heavily rely on shared memory, which conflicts with isolation models. Harness differentiates between implicit (non-writable/copy-on-write) and explicit (intentional) sharing. For explicit sharing, a sharing-aware memory monitor within the low visor tracks memory management syscalls. Ownership-based access control is then implemented, where tokens are assigned to resources, and only enclaves holding the corresponding token are granted access. Metadata for each isolated physical page prevents malicious remapping.
2. Binder IPC: Android's Binder IPC is complex and performance-sensitive. Harness uses the low visor to track and mediate Binder transactions between mutually trusted enclaves, bypassing the kernel for safe data copying and pointer adjustments. For communication between enclaves and untrusted components (e.g., system server), AIDL-based lightweight authentication is introduced, where sensitive interfaces are marked, and call gates signal the low visor to verify sender identity.
3. HMI Protection: To protect the GUI, Harness implements graphic buffer isolation by managing the shared buffer between the HWC and car apps within the isolation domain. It also uses virtio device binding (e.g., binding the Vertile GPU to the HWC) to specific enclaves, isolating I/O buffers and blocking malicious I/O control. For touch input, a validation-based method is employed: the low visor records raw hardware touch data for enclave-targeted inputs, and when an app receives input messages, they are reversibly traced back and compared against the recorded data to prevent malicious injection.

The prototype implementation of Harness on a Raspberry Pi 5, utilizing Google Cutfish to launch a virtual machine, comprises approximately 9,300 lines of code. Security analysis confirmed its theoretical effectiveness against the 13 identified attacks, and it was shown to mitigate 26 CVEs and 3 attack paths from prior studies. Simulated attack tests further validated its defensive capabilities. Performance evaluation revealed acceptable overheads: a 3.7x slowdown in LM bench (primarily from context switching and page faults), around 20% latency for app launch and touch input, and less than 4% increase in memory usage. Binder communication between enclaves showed about 60% additional latency, but this was 4.5 times faster than encryption-based methods. Car API call latency was around 22%, and Geekbench scores inside enclaves showed 3.35% (single-core) and 6.09% (multi-core) overheads. Crucially, the performance overhead for unprotected software was consistently negligible.

Technical Deep Dive

▶ Watch: Harness overall approach: four-chain protection (3:50)

Harness's technical foundation lies in its innovative use of hardware virtualization to establish a secure execution environment for critical vehicle control components within an otherwise untrusted Android Automotive OS.

Isolation and the Low Visor:

At its core, Harness leverages ARM platform virtualization features, specifically Stage 2 paging, to achieve memory isolation. This creates distinct, isolated memory regions for enclaves, each with its own intermediate physical address space (IPA), effectively compartmentalizing critical components from the broader AOS. All enclaves share a custom, protected exception vector table. This table is the gateway through which Harness intercepts system events.

The low visor acts as a lightweight hypervisor module. When an enclave triggers an exception (e.g., a page fault, a system call), control is redirected to the low visor via a hypercall. The low visor intelligently handles these exceptions; it can resolve some directly or forward them to the guest kernel for processing. Crucially, after the kernel handles an exception, the low visor re-intercepts control to validate the result before returning execution to the enclave, ensuring integrity.

To bridge the operational gap, a kernel module is introduced within the guest OS, enabling secure interaction between enclaves and the kernel. Furthermore, a library is provided that allows existing, unmodified Android components to execute seamlessly within these enclaves, preserving transparency for developers.

Defining the Protection Domain:

The protection domain in Harness is meticulously defined to be minimal yet comprehensive. Based on the protectionLevel attribute of security-critical car interfaces in AOS, the domain encompasses:

• System car applications: Those with direct access to sensitive car APIs.
• Car Service: The central Android service exposing car APIs.
• Vehicle Hardware Abstraction Layer (VEH/VHAL): The interface to vehicle hardware.
• Hardware Composer (HWC): Essential for secure display rendering.

This domain is managed via a whitelist, and the identity of components within it is verified using signature-based authentication. A specialized zygote process is employed to fork new enclaves, ensuring that protected components are instantiated within the secure environment.

Addressing Shared Memory Challenges:

Android's heavy reliance on shared memory presents a direct conflict with the isolation model. Harness categorizes shared memory into two types:

1. Implicit Sharing: Refers to non-writable or copy-on-write (CoW) memory (e.g., shared libraries). For these, the low visor enforces write protection and manages CoW mechanisms.
2. Explicit Sharing: Occurs when processes intentionally share memory via system calls and IPC (e.g., content providers, graphic buffers). To manage this securely, Harness introduces a sharing-aware memory monitor as a low visor module. This monitor intercepts and logs enclave syscalls related to memory management, recording intents for memory mapping and sharing (e.g., resource attributes, file descriptors, virtual addresses, permissions).

To enable secure explicit sharing, Harness implements ownership-based access control. Each shared resource (e.g., a buffer, a file) is assigned a unique token. When an owner enclave creates or opens a resource, Harness allocates a token to it. If the owner attempts to share this resource via IPC, the low visor securely passes the token to the target enclave, granting it access. Additionally, Harness maintains metadata for each isolated physical page to track its associated resource, preventing attackers from maliciously remapping physical memory regions.

Securing Binder IPC:

Binder IPC in Android is notoriously complex, involving a user-space library and a kernel driver responsible for data copying and pointer adjustments across process address spaces. This complexity, combined with the untrusted nature of the kernel, makes traditional end-to-end encryption unsuitable.

Harness addresses Binder IPC in two ways:

• Inter-enclave Communication: For Binder transactions between mutually trusted enclaves, the low visor directly tracks and mediates the process. It maintains three critical data structures: a global service list (recording services registered by enclaves), a binder reference map (tracking acquired services per enclave), and a work list (monitoring ongoing transactions). Using these, the low visor determines correct IPC flow and, crucially, bypasses the untrusted kernel to safely copy data and adjust pointers between enclaves, ensuring both content and flow integrity.
• Enclave-to-Untrusted Communication (AIDL-based Authentication): To allow enclaves to communicate with necessary external components (like the system server) while mitigating attack risks, Harness introduces AIDL-based lightweight authentication. The AIDL compiler is modified to allow developers to mark sensitive interfaces. This generates a call gate for these interfaces. When an enclave initiates a protected communication, its call gate signals the low visor with a "protection flag." Before data reception, the low visor verifies the sender's identity. If trusted, it signals the receiver via the flag, and the receiver's call gate decides whether to proceed with the function call. This prevents untrusted components from invoking sensitive interfaces or forging trusted services.

Transparent HMI Protection:

Protecting the HMI without compromising transparency or expanding the TCB is another significant challenge. Harness tackles this from two angles:

• GUI Protection:
• Graphic Buffer Isolation: In Android, apps render their GUI into a graphic buffer, which the HWC then displays. Harness isolates the HWC and car apps, managing the shared graphic buffers entirely within the secure isolation domain, preventing untrusted software from tampering with rendered output.
• Virtio Device Binding: To prevent malicious I/O control, Harness binds virtio devices to specific enclaves and isolates their I/O buffers. For example, the Vertile GPU is bound exclusively to the HWC, ensuring that the GPU only displays graphic buffers originating from the trusted HWC.
• Touch Input Protection:
• Validation-based Method: Android's touch input process is multi-staged and reversible. Raw hardware data (coordinates, touch state) is processed by the Linux input subsystem, converted to input events, and then consolidated by the Input Manager Service (IMS) into input messages for apps. Harness leverages this reversibility. The low visor records the original hardware data of touch inputs targeting enclave applications. When an enclave app receives input messages from the IMS, Harness reverses these messages back to their original hardware data and compares them against the recorded data. This consistency check effectively prevents malicious touch input injection from untrusted parts of the OS.

Demo / Proof of Concept

▶ Watch: Achieving isolation with hardware virtualization and enclaves (4:10)

The researchers implemented a fully functional prototype of Harness to demonstrate its capabilities and evaluate its performance and security. The prototype was deployed and tested on a Raspberry Pi 5, a common development platform for embedded systems, particularly suitable for demonstrating Android Automotive OS. To simulate a realistic environment, they utilized Google Cutfish to launch a virtual machine running Android Automotive OS.

The Harness prototype itself consists of approximately 9,300 lines of code, indicating a substantial but manageable codebase for a system of this complexity.

For security evaluation, Harness underwent rigorous analysis:

• Threat Model Coverage: It was specifically designed to address and defend against the 13 distinct attacks identified by the researchers earlier in the talk, ensuring comprehensive protection across the vehicle control stack.
• Real-World Threat Mitigation: The system was analyzed against 26 known CVEs (Common Vulnerabilities and Exposures) and 3 specific attack paths derived from prior security studies in the automotive domain. The findings confirmed that Harness could effectively mitigate these real-world threats.
• Simulated Attack Tests: To further validate its defensive posture, the researchers conducted simulated attack tests based on various strategies. These tests empirically confirmed that Harness successfully defended against the simulated compromises, preventing unauthorized vehicle control.

Performance evaluation was conducted across various benchmarks to quantify the overhead introduced by Harness:

• Microbenchmarks (LM bench): Harness exhibited a 3.7x slowdown in LM bench tests. The primary contributors to this overhead were identified as context switching, page faults, and the creation of new enclaves, which are inherent to hardware virtualization.
• App Launch and Touch Input Latency: For user-facing operations like application launch and touch input responsiveness, the overhead was around 20%. While noticeable, this is generally considered acceptable for security-critical functions.
• Memory Usage: The memory footprint increased by less than 4%, demonstrating its lightweight nature.
• Impact on Unprotected Software: Crucially, the performance overhead for software running outside the protected enclaves was consistently negligible, fulfilling a key usability goal.
• Binder Latency: Binder IPC between enclaves showed approximately 60% additional latency. However, this was still 4.5 times faster than commonly used encryption-based methods, highlighting Harness's efficiency in securing this complex communication channel.
• Car API Call Latency: More representative of real-world vehicle control scenarios, the latency for car API calls showed an acceptable overhead of about 22%.
• Geekbench Scores: Inside the enclaves, single-core Geekbench tests showed a 3.35% overhead, while multi-core tests had a 6.09% overhead. Outside the enclaves, the overhead remained negligible.

These evaluation results collectively demonstrate that Harness achieves robust security for critical vehicle control functions on Android Automotive OS while maintaining acceptable performance characteristics and ensuring transparency for both developers and users.

Defensive Implications

▶ Watch: Solution: Ownership-based access control for shared memory (6:50)

The Harness project offers profound defensive implications for the automotive industry, particularly as vehicles become more software-defined and interconnected. Its architectural approach provides a blueprint for securing critical vehicle functions against the increasing attack surface presented by complex infotainment systems.

1. Hardware-Backed Isolation for Critical Functions: The most significant implication is the demonstration of how hardware virtualization can effectively isolate safety-critical vehicle control components from the potentially compromised infotainment environment. Defenders should advocate for and integrate similar hardware-backed isolation mechanisms into future automotive architectures, ensuring that the integrity of functions like braking, steering, and powertrain control is decoupled from the security posture of the user-facing OS.

1. Minimal Trusted Computing Base (TCB): Harness's strategy of identifying and isolating a "minimal protection domain" for vehicle control is crucial. This approach minimizes the TCB for critical functions, meaning that even if the vast majority of the Android Automotive OS is untrusted and compromised, only a small, tightly controlled set of components can influence vehicle behavior. This principle should guide the design of all safety-critical automotive systems.

1. Secure Inter-Process Communication (IPC): The challenges addressed by Harness regarding Binder IPC highlight a pervasive vulnerability in complex operating systems. Automotive designers must prioritize robust and authenticated IPC mechanisms, especially when communication crosses trust boundaries. Solutions akin to Harness's AIDL-based lightweight authentication are vital to prevent malicious components from invoking sensitive interfaces or impersonating trusted services.

1. Comprehensive HMI Protection: The detailed approach to securing both GUI output (graphic buffer isolation, virtio device binding) and touch input (validation-based method) is a critical lesson. As vehicles increasingly rely on touchscreens and digital interfaces for control, ensuring the authenticity of displayed information and the integrity of user input is paramount to preventing spoofing or injection attacks that could lead to unauthorized actions. Defenders must ensure that the entire HMI pipeline for critical functions is secured from end-to-end.

1. Transparency and Deployability: Harness's design goal of transparency—requiring no intrusive modifications to user-space components and ensuring a seamless user experience—is vital for practical adoption. Security solutions that impose heavy development burdens or degrade user experience often face significant resistance. This underscores the need for security mechanisms to be integrated early in the design cycle and to be as non-intrusive as possible.

1. Mitigation of Known Vulnerabilities: The fact that Harness can mitigate numerous CVEs and known attack paths from prior studies provides strong evidence of its effectiveness against real-world threats. This suggests that similar architectural patterns can be highly effective in addressing existing and emerging vulnerabilities in automotive software.

In summary, Harness provides a strong argument for re-architecting automotive operating systems with security-first principles, leveraging hardware-assisted isolation to build robust defenses around critical vehicle control functions, even in the presence of an otherwise untrusted and feature-rich environment. Car manufacturers and Tier 1 suppliers should consider integrating such architectural patterns to enhance the resilience and trustworthiness of their vehicles against sophisticated cyberattacks.

Key Takeaways

• Android Automotive OS, while feature-rich, introduces a large attack surface that can allow a compromised IVI system to gain full control of a vehicle, posing significant safety risks.
• Harness utilizes hardware virtualization (ARM Stage 2 paging) to create isolated enclaves for security-critical car components (system car apps, Car Service, VEH, HWC), establishing a minimal trusted computing base.
• The solution provides "four-chain protection" from the HMI to user-space car components and the in-vehicle network, securing communications and interfaces at each stage.
• Harness effectively addresses complex Android-specific challenges, including secure shared memory management (ownership-based access control), robust Binder IPC between enclaves (low visor mediation), and transparent HMI protection (graphic buffer isolation, virtio device binding, and validation-based touch input).
• Despite offering comprehensive security, Harness introduces minimal performance and resource overhead (e.g., <4% memory increase, ~20% app launch/touch latency, ~22% car API latency, negligible impact on unprotected software), making it practical for deployment.
• The system is designed for transparency, requiring no intrusive modifications to user-space components, which simplifies deployment and ensures a seamless user experience.

About the Speaker(s)

The talk was presented by Haochen Gong, who is affiliated with Z University. No further biographical details were provided in the transcript or metadata.