Mesh status and provisioning

A new concept called SDV Boot Mode, which can be either Locked or Unlocked, defines how the SDV Service Discovery agent in an SDV VM behaves when attempting to connect to other Service Discovery agents (running in other SDV VMs) to establish a secure mesh. It is similar to the existing Device State concept from Android Verified Boot.

The SDV Boot Mode is leveraged when provisioning the Vehicle VM Trust Store or when updating it.

SDV Secure Mesh Behavior

The Service Discovery Mesh may be in one of the following states depending on boot values it receives: Normal, Warning, or Fatal.

A car gets into the hands of its owner only when its mesh is in "Normal" state. It is impossible for the mesh to get from "Normal" to "Warning" state without diagnostics intervention. "Warning", in a production environment (for example, not development/debugging), takes place only during provisioning.

"Fatal" is a fundamental failure, similar to a system_ext image failing signature verification in the Android bootloader. If the SDV Mesh transitioned from "Normal" to "Fatal" solely due to an Over The Air (OTA) update, that update would be considered bad and you would fall back to the original "Normal" version.

The following sections describes those states in more detail.

check Normal

• System boot is SECURE from Service Discovery's perspective.
• Service Discovery only connects with peers it believes to have booted securely and, as a consequence, it believes the SDV Secure Mesh it's a part of is secure.

warning Warning

• System boot may have been compromised as some verifications are disabled.
• Service Discovery only connects with peers who also have the same disabled verifications. It's thus part of a SDV Secure Mesh with the same security properties as itself.
• Peer Boot may have completed successfully or unsuccessfully - cannot be verified due to local failures / disables.
• Outside of a development environment or situation, this has the following implications:
  • User data must not be available. Ie, it must neither be transmitted nor affected by communication over the SDV Secure.
  • Only services needed for provisioning flows should be available when the mesh is in this state.

error Fatal

• Critical error in System Boot stages.
• There's at least one fundamental failure or error which prevents the Service Discovery agent from establishing a mesh. It is not possible for local services to talk to remote services.
• System boot is UNSECURE from Service Discovery's perspective.

SDV Boot Mode

The SDV Boot Mode has two possible values: UNLOCKED and LOCKED. With regards to Service Discovery mesh establishment, the LOCKED mode means that verification errors are fatal whereas in the UNLOCKED mode they are not.

Note that SDV Boot Mode is different from Android's Device State (aka AVB Mode). SDV Boot Mode guides SDV Secure Mesh's behavior and whether mesh connection errors are FATAL. AVB Mode dictates whether verifications done by the Android bootloader are fatal.

Local SDV & AVB Mode Match

The following table shows how the AVB Mode and the SDV Boot Mode affect the SDV Secure Mesh Behavior. The colors are as defined in the Android Specific Integration section of the AVB documentation.

Device Mode Value

In a DICE Chain, every CDI certificate has a Mode Value. It's used to describe the security state of that layer based on its configuration input. In order to express the security stance of all software on the device, a Device Mode Value is defined, which is derived from the Mode Value of all CDI stages of the DICE Chains relevant to a given SDV VM (ie., Android HLOS and Secure World) and is defined as follows:

enum DeviceMode {
  NotConfigured = 0,
  Recovery = 1,
  Debug = 2,
  Normal = 3,
}

Algorithm

1. Let deviceMode be DeviceMode::Normal
2. Let diceChainList be the list of DICE Chains relevant to a SDV VM
3. For each diceChain in diceChainList:
   1. Let cdiList be the list of CDI certificates in diceChain:
   2. For each cdiCert in cdiList:
      1. Let cdiDeviceMode be the DeviceMode corresponding to cdiCert.mode.
      2. Set deviceMode to min(deviceMode, cdiDeviceMode).
4. Return deviceMode.

Remote Device Mode value comparison

A Service Discovery Agent will only ever connect with other Agents that have the same Device Mode Value as itself.

The Device Mode value ensures that a mesh cannot have members with different security properties. Therefore the resulting mesh has a uniform security stance between all of its members.

Factory Provisioning Flow

This is the provisioning flow at the vehicle assembly line, where public key infrastructure is assumed to not be available.

This flow depends on a 32-bytes value stored in one-time-programmable (OTP) memory called VVMFactoryTrust. This value, when set, is passed to the kernel as a parameter named androidboot.sdv.vvmfactorytrust.

All VMs in an ECU must have the same SDV Boot Mode and VVMFactoryTrust.

Initial State

All ECUs are initially SDV Boot Mode unlocked, with blank VVMFactoryTrust and VVMTrustStore, other than possibly any uds_certs present on the VVMTrustStore.

Figure 1 depicts an example where there are three SDV VMs (VM-A, VM-B and VM-C) distributed in two separate ECUs (ECU-0 and ECU-1).

Step 1: Run sdv_provisioning_tool

Boot up all VMs from all ECUs.

On each VM:

• Run sdv_provisioning_tool

  • The tool communicates with the local Service Discovery agent and waits for it to signal that the SDV Secure Mesh is complete, and the agent has written the list of UDS public keys to /vvmtruststore/uds_pubs.
  • When this occurs, the tool gets the hash of the just-written /vvmtruststore/uds_pubs and outputs it.

Step 2: Write VVMFactoryTrust

On one VM of each ECU:

• Write the hash of /vvmtruststore/uds_pubs that was output by the sdv_provisioning_tool in the previous step into the VVMFactoryTrust. How this writing is performed is OEM/vendor specific and thus out of scope of this specification.

Step 3: Reboot in SDV Boot Mode Locked

Reboot all VMs in all ECUs in SDV Boot Mode Locked.

The Service Discovery agent trusts VMs in ECUs with the UDS public keys listed in uds_pubs as the hash of this file matches the VVMFactoryTrust.

As the ECUs were provisioned together, they are permanently bound together and can thus effectively be considered as a single piece of hardware from a DICE chain verification perspective.

Parts replacement flow

This is the provisioning flow at an authorized car repair workshop or garage, where a faulty ECU has to be replaced with a new, unprovisioned, one.

This flow depends on UDS certificates issued either directly by the root authority stated in the vvmconfig or indirectly, through some chain of intermediate authorities.

Initial State

All VMs are already factory-provisioned and are running with SDV Boot Mode locked.

Figure 5 depicts an example where ECU-0 is malfunctional and thus needs to be
replaced.

Step 1: Install the new ECU

Install the new ECU, which will be in a blank, unprovisioned, state.

In Figure 6, when ECU-2 (the replacement ECU) is powered up, there are two disjoint SDV Secure Meshes: one in warning state and another in normal state. Both SDV Secure Meshes are incomplete.

Step 2: Reboot in SDV Boot Mode unlocked

Reboot all VMs of all ECUs in SDV Boot Mode unlocked.

In Figure 7, VM-B and VM-C then join the warning SDV Secure Mesh, which is now complete.

Step 3: Run sdv_provisioning_tool

On each VM, run sdv_provisioning_tool.

The tool communicates with the local Service Discovery agent and waits for it to signal that the SDV Secure Mesh is complete, and the agent has written the list of UDS public keys to /vvmtruststore/uds_pubs.

When this occurs, the tool gets the hash of the just-written /vvmtruststore/uds_pubs and outputs it, but this hash isn't used in this flow.

Step 4: Install UDS certificates

• Extract /vvmtruststore/uds_pubs from an arbitrary SDV VM. It doesn't matter which one since it will be the same for all VMs in the same SDV Secure Mesh.
• Retrieve provisioning certificates for all the UDS public keys listed in that /vvmtruststore/uds_pubs.
  • This usually means sending this to a remote server that either has the certificates already stored or will generate them by checking the received public keys against a database of known UDS public keys. This database would have been built from the UDS public keys extracted during ECU manufacturing.
• Write the /vvmtruststore/uds_certs of each SDV VM.

Step 5: Reboot in SDV Boot Mode locked

Reboot all VMs with SDV Boot Mode locked.

If for some reason the SDV Secure Mesh is incomplete, go back to Step 2.