Vehicle System Isolation

To ensure car system integrity, Android Automotive protects incoming data at these levels:

EVS System components

Figure 1. System Service Architecture

  • Applications. System verifies an application has permission to talk to Car subsystems.
  • Well-Defined APIs. Generic APIs do not accept arbitrary data blobs (APIs must be well defined).
  • Car Service. Updates allowed only via OTA (or USB), with full-disk encryption and verified boot. Cannot be sideloaded.
  • Vehicle HAL. Verifies specific messages are allowed.

Applications and APIs

Android Automotive is built on Android and interacts directly with numerous safety-critical subsystems. In addition, different vehicles may have different interfaces with different functionalities exposed to Android. To make these functionalities safe and streamlined, they are isolated in an abstraction layer, separate from the rest of Android. Only well-defined APIs with strict formatting on messages sent through in-vehicle networks can communicate with the Vehicle HAL. This provides a predictable interface for Android developers and provides a secure interaction with the rest of the vehicle.

Vehicle HAL messages are filtered at two levels:

  • Application level. Non-system applications can access vehicle HAL through car service with proper permissions.
  • Vehicle HAL level. Allows for an additional layer of protection and assurance that messages sent to vehicle subsystems originate from a legitimate source. Can also be used to rate limit messages, preventing malicious applications from flooding the CAN bus and potentially interfering with vehicle subsystems.

Vehicle HAL

Vehicle HAL is a lower layer that interacts with the vehicle, communicating with in-vehicle networks and other vehicular hardware through driver input/output control (ioctl) calls.

The vehicle HAL is the only component in Android Automotive connected to the IVI system, either via direct Application Processor/MicroController connection or gated through a VMCU. Access to the Vehicle HAL should be restricted to system applications using SELinux rules and proper permissions on kernel interfaces.

SELinux Policies

Android Automotive extends SELinux to filter driver access including open, close, read, write, and ioctl calls. Using ioctl filtering (along with other SELinux functionality) limits the type of CAN messages allowed and accepted by the Vehicle HAL, drastically reducing the attack surface. For details on SELinux, see  Security-Enhanced Linux in Android.

Additionally, automotive use cases include new types of sensitive data that should be isolated and controlled. Sensitive data has separate permissions; other capabilities such as HVAC controls and window adjustment should be given only to system applications. Example of an Automotive-specific SELinux policy:

<permission-group
 android:name=”android.support.car.permission.CAR_MONITORING />

<permission
 android:name=”android.support.car.permission.CAR_MILEAGE”
 android:protectionLevel=”signature|privileged” />
<permission
 android:name=”android.support.car.permission.CAR_SPEED”
 android:permissionGroup=”android.permission-group.LOCATION”
 android:protectionLevel=”dangerous” />
<permission
 android:name=”android.support.car.permission.CAR_VENDOR_EXTENSION”
 android:permissionGroup=”android.support.car.permission.CAR_INFORMATION”
 android:protectionLevel=”signature|privileged” />

The CAR_MONITORING permission group was created for automotive-related permissions. Current speed can be regarded as sensitive information. Therefore, CAR_SPEED permissions were created with a protection level of dangerous. This level means the information is private and sensitive. The permission CAR_VENDOR_EXTENSION was created with the system- or signature-level permission, which is used for system apps or signed apps that are explicitly granted this permission.

Application and Activity Blocking

To reduce distracted driving, Android Automotive provides additional controls (a whitelist) to ensure sideloaded applications cannot be used when the vehicle is in motion. These apps can still run when a vehicle is parked or stopped.

The whitelist specifies applications that can be used when the vehicle is moving. Only trusted system apps can update the whitelist. While updates can occur over the network, updates should not be considered reliable.