AAOS SDV consists of a network of multiple VMs running in a vehicle. The SDV Secure mesh allows OEM services running on the SDV VMs to call other services on remote SDV VMs (but in the same vehicle) the same manner they call local services. This requires establishing trust between SDV VMs. SDV VMs must verify the integrity and authenticity of their peers before allowing them to form an SDV Mesh.
An ECU can run one or more SDV VMs. Each of those ECUs must have a hardware-level Unique Device Secret (UDS) that is used by a Device Identifier Composition Engine (DICE) to derive a Compound Device Identifier (CDI) value and a certificate based on the UDS and a measurement of the first mutable code (i.e., the first stage bootloader).
Further boot stages have corresponding CDI values and certificates created for them where each CDI certificate is issued by the previous boot stage, forming a so-called DICE certificate chain, or, in short, DICE chain. See the Open Profile for DICE for details. AAOS SDV uses DICE chains to establish the identity of peer SDV VMs.
An SDV VM is supplied with two different DICE Chains: a Secure World DICE chain and an Android SDV DICE chain. SDV Profile for DICE describes those chains in detail.
Both DICE chains are rooted at a UDS public key, which identifies the ECU. Device trust describes how trust in a peer ECU (that is, a peer device) is determined. This is the first step in the verification of a peer DICE chain.
The definition of the SDV VMs (including instance names and IP addresses)
that constitute the SDV VM mesh in a vehicle alongside with the information
needed to verify their DICE chains is stored into two new sets of configuration
data in AAOS SDV: vvmconfig and vvmtruststore.
Finally, the mechanisms and concepts involved in the provisioning of the
vvmtruststore are described in Mesh Status and Provisioning.