A fundamental step in the authentication process of a peer Android SDV VM is determining whether that peer VM is running on ar Trusted device. Only VMs running verified software on trusted devices can join the SDV secure mesh. For details on the peer software verification process see the SDV Profile for DICE.
For device trust, Android SDV defines two distinct authorities with different powers:
Assign device trust: only the OEm has this authority.
Define the set of devices whose VMs constitute SDV secure mesh of a vehicle. The OEM must assign and control access; personnel that replace parts have this authority.
The following sections describe the details of mesh device membership and device trust.
uds_pubs file
Devices are unambiguously identified by their respective unique device secret (UDS) public keys.
When an Android SDV VM joins the SDV secure mesh, we conceptually say that the device where that VM is running has joined the SDV secure mesh.
The uds_pubs file contains the UDS public keys of all devices that are
eligible to join the SDV secure mesh. This file is created in the
factory provisioning flow and updated in the parts replacement flow.
This file is located in the vvmtruststore partition.
Inclusion in this list doesn't imply trust. For a device to join the SDV secure mesh, two conditions must be met:
- UDS public key (or keys) must be in
uds_pubs. - Must be a trusted device.
Device trust methods
For an Android SDV VM to trust a device where a peer Android SDV VM is running, there are two methods:
- Device carries UDS certificates. This is the preferred method.
- Devices are permanently bound to each other during the factory provisioning flow. This is expressed by the VVMFactoryTrust. This is the alternative method that OEMs can use when it isn't technically feasible to provide UDS certificates to devices at (or before) the vehicle assembly line.
UDS certificates
The peer Android SDV VM can present a UDS certificate for its UDS public key.
The public key of the UDS root provisioning authority, which serves as the
ultimate trust anchor for device authentication, is defined in the
vvmconfig file.
The VM's own UDS certificates are stored in the uds_certs file in the
vvmtruststore partition.
Support for this device trust method is mandatory.
Bind devices together with the VVMFactoryTrust
Devices provisioned together can be permanently bound, creating a trusted group that doesn't rely on UDS certificates. This removes the need for the associated public-key infrastructure to generate those certificates. This inherent trust is specific to that group. Therefore, if any device within this bound group is replaced, the established trust for the entire group is revoked.
This permanent binding is achieved with the VVMFactoryTrust, which is a hash of
the uds_pubs file stored in one-time-programmable (OTP) memory.
More specifically, it's a 32-byte value storing the SHA256 of uds_pubs as it
was during provisioning. That value is passed to Android SDV as a [kernel
parameter]vvmfactorytrust kernel parameter. If the stored VVMFactoryTrust
matches the hash of uds_pubs, the devices identified by those UDS public keys
are trusted.
To ensure that those authorized to perform only parts replacement also don't gain the authority to assign device trust, they should receive only devices with a VVMFactoryTrust that can't be written. Without this precaution, a workshop technician could mix authentic and nonauthentic devices during a full vehicle device replacement.
Support for this hardware trust method is optional and should only be implemented if provisioning UDS certificates at (or before) the vehicle assembly line isn't feasible.