Use vehicle bound file encryption

This page describes how to enable vehicle-based binding encryption seed features.

Overview

The primary goal of the vehicle binding seed feature is to further protect the user's privacy by guarding data on the In-Vehicle Infotainment (IVI) system against removal from the vehicle. This is done by binding storage encryption keys to some other Electronic Control Unit (ECU) such that if the IVI is removed and placed in another vehicle (or run on a test bench), encrypted user data on the IVI can't be decrypted.

To bind file encryption keys, Vold mixes in a vehicle-specific seed with key encryption key derivation so the keys are unique and bound physically to the vehicle. The seed is a byte array, exposed as a new Vehicle Hardware Abstraction Layer (VHAL) property by the OEM, STORAGE_ENCRYPTION_BINDING_SEED. This property's permissions are restricted such that it can only be queried by privileged system daemons.

Architecture diagram

This figure illustrates the architecture of vehicle bound integration:

Figure 1. Vehicle bound architecture.

Enable vehicle-based binding

Binding of storage encryption to the vehicle must be explicitly enabled and can't be turned on or off without performing a factory reset. This means that an Over-the-Air (OTA) update can't enable the feature without also wiping the device. An OEM could choose to enable the feature upon upgrade if they also factory reset the device. For example, on a service visit.

This feature is enabled by supporting the STORAGE_ENCRYPTION_BINDING_SEED property in the vendor-supplied vehicle HAL. This property holds a byte string 16 bytes in length and is expected to be persisted on an ECU separate from the IVI. The property is initially set by the Android Automotive OS (AAOS), which generates it using a Cryptographically Secure Random Number Generator (CSRNG). AAOS then reads the property on subsequent boots.

How the VHAL stores the value of STORAGE_ENCRYPTION_BINDING_SEED is vendor-specific. We have general recommendations for protecting the seed:

  1. (Recommended) Seed is stored by an ECU in the vehicle that is physically well-protected. If not, it's trivial for both the IVI and the ECU to be pulled from the vehicle.
  2. (Recommended) IVI and ECU should mutually authenticate to exchange the seed to prevent spoofing requests for the seed from the ECU.
  3. (Recommended) Seed should be transmitted using a secure channel to guard against CAN bus sniffing.

In addition, add the following to ensure vendor init.target.rc on late-fs before mount_all --late:

# feed vehicle binding seed to vold
exec_start vold_seed_binding

The vehicle HAL should be started in early_hal instead of hal now. Any persist.* system property can't be accessed in early-hal because the /data partition isn't yet mounted.

Configure vehicle-based binding

If the ECU seed doesn't match, the device reboots into recovery and prompts the user to erase the /data partition or retry.

Prompt and wipe data behavior can be changed in builtins.cpp:

  1. Change prompt_and_wipe_data to wipe_data. The device wipes and then reboots without a prompt.
  2. The prompt message is contained in recovery.cpp.

    Figure 2. Prompt message.

Test vehicle-based binding

Mock testing

A mock test is provided in packages/services/Car/cpp/security/vehicle_binding_util/tests.

To run this mock test:

attest libvehicle_binding_util_test

Integration testing

An atest test is provided in packages/services/Car/cpp/security/vehicle_binding_util/tests.

To run this integration test:

atest vehicle_binding_integration_test