Securing Android-based Software-Defined Vehicles

Securing Android-based Software-Defined Vehicles

Google has detailed the security architecture of Android Automotive OS for Software-Defined Vehicles (AAOS SDV). The architecture builds on established Android security mechanisms and extends them with virtualization and hardware-rooted trust between vehicle components.

A software-defined vehicle is a vehicle whose core functions, controls, and capabilities are primarily defined and enhanced through software rather than hardware alone.

— One of the key principles is domain isolation. As manufacturers consolidate the functions of multiple electronic control units onto a single computing platform, previously separate systems are brought closer together at the hardware level. Google addresses this by using virtual machines to isolate logical domains. For example, the instrument cluster and infotainment system can run independently, with data sharing between them explicitly authorized rather than enabled by default.

Within each environment, AAOS SDV follows the established Android security model. Services run in dedicated processes with unique user IDs, privileges are restricted using POSIX capabilities and SELinux, and access follows a deny-by-default approach. Rust is the primary language for new AAOS SDV components, helping reduce common classes of memory safety vulnerabilities.

— Software integrity is another major focus. System partitions validate signatures on every boot, while services can be distributed as APEX packages. Their code is stored on read-only file systems, with per-block cryptographic integrity verified through dm-verity. If an update fails or appears malicious, the system can automatically roll back to the previous version.

— Another important element is establishing trust between virtual machines. Google uses DICE-based authentication and attestation together with TLS for VM-to-VM communication. A component’s cryptographic identity is bound to the code and configuration it is actually running. This allows another component to verify not only who it is communicating with, but also whether the software is in the expected state. Changes to firmware or configuration alter the derived cryptographic identity and can therefore be detected during verification.

Access control operates at two levels: service-level permissions define which resources individual services can access or expose, while VM-level permissions define communication boundaries between virtual machines. For security-sensitive vehicle signals, these restrictions must be hard-coded into each VM.