This content describes how to enable vehicle-based binding encryption seed features.
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 cannot 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.
This figure illustrates the architecture of vehicle bound integration:
Figure 1. Vehicle bound architecture
Enabling vehicle-based binding
Binding of storage encryption to the vehicle must be explicitly enabled and cannot be turned on or off without performing a factory reset. This means that an Over-the-Air (OTA) update cannot 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
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:
- (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.
- (Recommended) IVI and ECU should mutually authenticate to exchange the seed to prevent spoofing requests for the seed from the ECU.
- (Recommended) Seed should be transmitted using a secure channel to guard against CAN bus sniffing.
In addition, add the following to ensure vendor
# feed vehicle binding seed to vold exec_start vold_seed_binding
The vehicle HAL should be started in
early_hal instead of
persist.* system property cannot be accessed in
early-hal since the
/data partition is not yet mounted.
Configuring vehicle-based binding
If the ECU seed does not match, the device reboots into recovery and prompts the user to erase
/data partition or retry.
Prompt and wipe data behavior can be changed in builtins.cpp:
wipe_data. The device wipes and then reboots without a prompt.
- The prompt message is contained in
Figure 2. Prompt message
Testing vehicle-based binding
A mock test is provided in
To run this mock test:
An atest test is provided in
To run this integration test: