Mesh-Status und ‑Bereitstellung

SDV-Bootmodus definiert, wie sich der SDV-Service Discovery-Agent in einer SDV-VM verhält, wenn er versucht, eine Verbindung zu anderen Service Discovery-Agents (die in anderen SDV-VMs ausgeführt werden) herzustellen, um ein sicheres Mesh einzurichten. Dies ähnelt dem bestehenden Geräte zustand Konzept von Android Bootmodus mit Verifikation.

Der SDV-Bootmodus wird beim Bereitstellen oder Aktualisieren des Vehicle VM Trust Store (VVM Trust Store, auch als vvmtruststore bezeichnet) verwendet.

Verhalten des sicheren SDV-Mesh

Das Service Discovery-Mesh befindet sich je nach den empfangenen Bootwerten in einem der folgenden Zustände: Normal, Warning oder Fatal.

In Produktionsfahrzeugen, die an Kunden ausgeliefert werden, muss sich das sichere SDV-Mesh im Zustand Normal befinden. Für den Wechsel von Normal zu Warning ist ein Eingriff zur Diagnose erforderlich. In einer Produktionsumgebung (z. B. keine Entwicklung oder Fehlerbehebung) tritt der Zustand Warning nur während der Bereitstellung auf.

Fatal ist ein grundlegender Fehler, ähnlich wie bei einer fehlgeschlagenen Signaturprüfung des system_ext-Images im Android-Bootloader. Wenn das sichere SDV-Mesh ausschließlich aufgrund eines Over-the-Air-Updates (OTA) von Normal zu Fatal wechselt, gilt das Update als fehlerhaft und das Mesh wird auf die ursprüngliche Normal-Version zurückgesetzt.

In den folgenden Abschnitten werden die Zustände genauer beschrieben.

check Normal

• Der Systemstart ist aus Sicht von Service Discovery SECURE.
• Service Discovery stellt nur eine Verbindung zu Peers her, die sicher gestartet wurden. Ein sicher gestarteter Peer bedeutet, dass auch das sichere SDV-Mesh sicher ist.

warning Warning

• Der Systemstart wurde möglicherweise manipuliert, da einige Überprüfungen deaktiviert sind.
• Service Discovery stellt nur eine Verbindung zu Peers her, bei denen genau dieselben Überprüfungen deaktiviert sind. So wird sichergestellt, dass alle Peers im sicheren SDV-Mesh identische Sicherheitseigenschaften haben.
• Der Erfolg eines Peer-Starts kann aufgrund lokaler Fehler oder deaktivierter Funktionen nicht überprüft werden.
• Außerhalb einer Entwicklungsumgebung oder -situation hat dies folgende Auswirkungen:
  • Nutzerdaten dürfen nicht verfügbar sein. Das heißt, sie dürfen weder übertragen werden noch von der Kommunikation über das sichere SDV-Mesh betroffen sein.
  • Wenn sich das Mesh in diesem Zustand befindet, sollten nur die für die Bereitstellung erforderlichen Dienste verfügbar sein.

error Fatal

• Ein kritischer Fehler während der Systemstartphasen.
• Es gibt mindestens einen grundlegenden Fehler, der verhindert, dass der Service Discovery-Agent ein Mesh einrichtet. Lokale Dienste können nicht mit Remote-Diensten kommunizieren.
• Der Systemstart ist aus Sicht von Service Discovery UNSECURE.

SDV-Bootmodus

Der SDV-Bootmodus hat zwei mögliche Werte: LOCKED und UNLOCKED. Für die Einrichtung des Service Discovery-Mesh gibt LOCKED an, dass Überprüfungsfehler schwerwiegend sind, und UNLOCKED bedeutet, dass sie nicht schwerwiegend sind.

Lokaler SDV- und AVB-Modus stimmen überein

In der folgenden Tabelle sehen Sie, wie sich der AVB-Modus und der SDV-Bootmodus auf das Verhalten des sicheren SDV Mesh auswirken. Die Farben sind wie im Android-spezifischen Integrationsabschnitt der AVB-Dokumentation definiert.

Wert des Gerätemodus

In einer DICE-Kette hat jedes CDI-Zertifikat einen Moduswert. Dieser Wert beschreibt den Sicherheitsstatus dieser Ebene basierend auf der Konfigurationseingabe. Um die Sicherheitslage aller Software auf dem Gerät auszudrücken, definiert die SDV-Spezifikation einen Wert für den Gerätemodus. Dieser Wert wird aus dem Moduswert aller CDI-Phasen in den DICE-Ketten abgeleitet, die für eine bestimmte SDV-VM relevant sind (d. h. Android HLOS und Secure World), und verwendet die folgende Aufzählung:

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

Algorithmus

Der Algorithmus zur Berechnung des Werts des Gerätemodus ist wie folgt:

1. Geben Sie deviceMode als DeviceMode::Normal an.
2. Geben Sie diceChainList als Liste der DICE-Ketten an, die für eine SDV-VM relevant sind.
3. Für jede diceChain in diceChainList:
   1. Geben Sie cdiList als Liste der CDI-Zertifikate in diceChain an:
   2. Für jedes cdiCert in cdiList:
      1. Geben Sie cdiDeviceMode als DeviceMode an, der cdiCert.mode entspricht.
      2. Setzen Sie deviceMode auf min(deviceMode, cdiDeviceMode).
4. Geben Sie deviceMode zurück.

Vergleich des Werts des Remote-Gerätemodus

Ein Service Discovery-Agent stellt nur eine Verbindung zu anderen Agents her, die denselben Wert für den Gerätemodus haben.

Der Wert des Gerätemodus sorgt dafür, dass ein Mesh keine Mitglieder mit unterschiedlichen Sicherheitseigenschaften haben kann. Das resultierende Mesh hat eine einheitliche Sicherheitslage zwischen allen Mitgliedern.

Ablauf der Werksbereitstellung

Dies ist der Bereitstellungsablauf am Fahrzeugmontageband, wo keine Public-Key-Infrastruktur verfügbar ist. Dieser Ablauf hängt von einem 32-Byte-Wert ab, der in einem einmal programmierbaren (OTP) Speicher namens Vehicle VM (VVM) Factory Trust oder vvmfactorytrust gespeichert ist. Wenn dieser Wert festgelegt ist, wird er als Parameter namens androidboot.sdv.vvmfactorytrust an den Kernel übergeben.

Alle VMs in einer ECU müssen denselben SDV-Bootmodus und VVM Factory Trust haben.

Ausgangsstatus

Alle ECUs befinden sich anfangs im SDV-Bootmodus UNLOCKED mit leerem VVM Factory Trust und Vehicle VM Trust Store, abgesehen von allen uds_certs, die in vvmtruststore vorhanden sind. Abbildung 1 zeigt ein Beispiel mit drei SDV-VMs (VM-A, VM-B und VM-C), die auf zwei separate ECUs (ECU-0 und ECU-1) verteilt sind:

Abbildung 1 : Werksbereitstellung, Ausgangsstatus.

Schritt 1: `sdv_provisioning_tool` ausführen

Starten Sie alle VMs von allen ECUs.

Führen Sie auf jeder VM sdv_provisioning_tool aus.

1. Das Tool kommuniziert mit dem lokalen Service Discovery-Agent und wartet darauf, dass er signalisiert, dass das sichere SDV-Mesh vollständig ist und der Agent die Liste der öffentlichen UDS-Schlüssel in /vvmtruststore/uds_pubs geschrieben hat.
2. In diesem Fall ruft das Tool den Hash von /vvmtruststore/uds_pubs ab, der gerade geschrieben wurde, und gibt ihn aus.

Abbildung 2 : Werksbereitstellung, Schritt 1.

Schritt 2: VVM Factory Trust schreiben

Auf einer VM jeder ECU:

1. Schreiben Sie den Hash von /vvmtruststore/uds_pubs, der im vorherigen Schritt von sdv_provisioning_tool ausgegeben wurde, in VVM Factory Trust. Wie das Schreiben erfolgt, ist OEM- oder anbieterspezifisch und liegt außerhalb des Umfangs dieser Spezifikation.

Abbildung 3 : Werksbereitstellung, Schritt 2.

Schritt 3: Neustart im gesperrten SDV-Bootmodus

Starten Sie alle VMs in allen ECUs im SDV-Bootmodus im Modus LOCKED neu.

Der Service Discovery-Agent vertraut VMs in ECUs mit den in uds_pubs aufgeführten öffentlichen UDS-Schlüsseln, da der Hash dieser Datei mit VVM Factory Trust übereinstimmt.

Da die ECUs zusammen bereitgestellt wurden, sind sie dauerhaft miteinander verbunden und können aus Sicht der Überprüfung der DICE-Kette effektiv als ein einzelnes Hardwareteil betrachtet werden.

Abbildung 4 : Werksbereitstellung, Schritt 3.

Ablauf für den Austausch von Teilen

Dies ist der Bereitstellungsablauf in einer autorisierten Autowerkstatt, in der eine defekte ECU durch eine neue, nicht bereitgestellte ECU ersetzt werden muss.

Dieser Ablauf hängt von UDS-Zertifikaten ab, die entweder direkt von der in vvmconfig angegebenen Stamm zertifizierungsstelle oder indirekt über eine Kette von Zwischenzertifizierungsstellen ausgestellt werden.

Ausgangsstatus

Alle VMs wurden bereits werksseitig bereitgestellt und werden im SDV-Bootmodus im Modus LOCKED ausgeführt.

Abbildung 5 zeigt ein Beispiel, in dem ECU-0 defekt ist und ersetzt werden muss:

Abbildung 5 : Teileaustausch, Ausgangsstatus.

Schritt 1: Neue ECU installieren

Installieren Sie die neue ECU, die sich in einem leeren, nicht bereitgestellten Zustand befindet.

Wenn in Abbildung 6 ECU-2 (die Ersatz-ECU) eingeschaltet wird, gibt es zwei getrennte sichere SDV-Meshes: eines im Zustand Warning und eines im Zustand Normal. Beide sicheren SDV-Meshes sind unvollständig.

Abbildung 6 : Teileaustausch, Schritt 1.

Schritt 2: Neustart im entsperrten SDV-Bootmodus

Starten Sie alle VMs aller ECUs im SDV-Bootmodus im Modus UNLOCKED neu.

In Abbildung 7 treten VM-B und VM-C dem sicheren SDV-Mesh Warning bei, das vollständig ist.

Abbildung 7 : Teileaustausch, Schritt 2.

Schritt 3: `sdv_provisioning_tool` ausführen

Führen Sie auf jeder VM sdv_provisioning_tool aus.

Das Tool kommuniziert mit dem lokalen Service Discovery-Agent und wartet darauf, dass er signalisiert, dass das sichere SDV-Mesh vollständig ist und der Agent die Liste der öffentlichen UDS-Schlüssel in /vvmtruststore/uds_pubs geschrieben hat.

In diesem Fall ruft das Tool den Hash von /vvmtruststore/uds_pubs ab, der gerade geschrieben wurde, und gibt ihn aus. Dieser Hash wird in diesem Ablauf jedoch nicht verwendet.

Abbildung 8 : Teileaustausch, Schritt 3.

Schritt 4: UDS-Zertifikate installieren

• Extrahieren Sie /vvmtruststore/uds_pubs aus einer beliebigen SDV-VM. Es spielt keine Rolle, welche, da es für alle VMs im selben sicheren SDV-Mesh gleich ist.
• Rufen Sie Bereitstellungszertifikate für alle in /vvmtruststore/uds_pubs aufgeführten öffentlichen UDS-Schlüssel ab.
  • In diesem Schritt werden in der Regel die extrahierten öffentlichen UDS-Schlüssel (oder die Datei /vvmtruststore/uds_pubs) an einen Remote-Bereitstellungsserver gesendet. Der Server ruft entweder bereits vorhandene Zertifikate ab oder generiert neue, indem er die empfangenen öffentlichen Schlüssel mit einer Datenbank bekannter öffentlicher UDS-Schlüssel vergleicht, die während der ECU-Fertigung erstellt wurde.
• Schreiben Sie die /vvmtruststore/uds_certs jeder SDV-VM.

Abbildung 9 : Teileaustausch, Schritt 4.

Schritt 5: Neustart im gesperrten SDV-Bootmodus

Starten Sie alle VMs im SDV-Bootmodus im Modus LOCKED neu.

Wenn das sichere SDV-Mesh unvollständig ist, kehren Sie zu Schritt 2 zurück.

Abbildung 10 : Teileaustausch, Schritt 5.