Mesh-Status und ‑Bereitstellung

Ein neues Konzept namens SDV-Bootmodus, das entweder gesperrt oder entsperrt sein kann, definiert, wie sich der SDV-Service Discovery-Agent in einer SDV-VM verhält, wenn er versucht, eine Verbindung zu anderen Service Discovery-Agents herzustellen, die in anderen SDV-VMs ausgeführt werden, um ein sicheres Mesh-Netzwerk einzurichten. Es ähnelt dem bestehenden Konzept des Gerätestatus von Android Bootmodus mit Verifikation.

Der SDV-Bootmodus wird beim Bereitstellen oder Aktualisieren des VVM-Trust Store für Fahrzeuge genutzt.

Verhalten des sicheren SDV-Mesh-Netzwerks

Das Service Discovery-Mesh-Netzwerk kann je nach den empfangenen Bootwerten einen der folgenden Status haben: „Normal“, „Warnung“ oder „Fatal“.

Ein Auto gelangt nur dann in den Besitz des Eigentümers, wenn sich das Mesh-Netzwerk im Status „Normal“ befindet. Ohne diagnostische Maßnahmen ist es nicht möglich, dass das Mesh-Netzwerk vom Status „Normal“ in den Status „Warnung“ wechselt. Der Status „Warnung“ tritt in einer Produktionsumgebung (z. B. nicht in der Entwicklung/Fehlerbehebung) 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 SDV-Mesh-Netzwerk ausschließlich aufgrund eines Over-the-Air-Updates (OTA) von „Normal“ zu „Fatal“ wechselt, gilt dieses Update als fehlerhaft und Sie kehren zur ursprünglichen Version „Normal“ zurück.

In den folgenden Abschnitten werden diese Status genauer beschrieben.

check Normal

• Aus Sicht von Service Discovery ist der Systemstart SECURE.
• Service Discovery stellt nur eine Verbindung zu Peers her, von denen es annimmt, dass sie sicher gestartet wurden. Daher geht es davon aus, dass das sichere SDV-Mesh-Netzwerk, zu dem es gehört, sicher ist.

warning Warnung

• Der Systemstart wurde möglicherweise kompromittiert, da einige Überprüfungen deaktiviert sind.
• Service Discovery stellt nur eine Verbindung zu Peers her, bei denen dieselben Überprüfungen deaktiviert sind. Es ist also Teil eines sicheren SDV-Mesh-Netzwerks mit denselben Sicherheitseigenschaften wie es selbst.
• Der Peer-Bootvorgang wurde möglicherweise erfolgreich oder nicht erfolgreich abgeschlossen. Aufgrund lokaler Fehler / Deaktivierungen kann dies 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 noch durch die Kommunikation über das sichere SDV-Mesh-Netzwerk beeinträchtigt werden.
  • Wenn sich das Mesh-Netzwerk in diesem Status befindet, sollten nur die für die Bereitstellung erforderlichen Dienste verfügbar sein.

error Fatal

• Kritischer Fehler in den Phasen des Systemstarts.
• Es gibt mindestens einen grundlegenden Fehler, der verhindert, dass der Service Discovery-Agent ein Mesh-Netzwerk einrichtet. Lokale Dienste können nicht mit Remote-Diensten kommunizieren.
• Aus Sicht von Service Discovery ist der Systemstart UNSICHER.

SDV-Bootmodus

Der SDV-Bootmodus hat zwei mögliche Werte: FREIGESCHALTET und GESPERRT. In Bezug auf die Einrichtung des Service Discovery-Mesh-Netzwerks bedeutet der Modus „GESPERRT“, dass Überprüfungsfehler fatal sind, während sie im Modus „FREIGESCHALTET“ nicht fatal sind.

Der SDV-Bootmodus unterscheidet sich vom Gerätestatus von Android (auch AVB Modus genannt). Der SDV-Bootmodus bestimmt das Verhalten des sicheren SDV-Mesh-Netzwerks und ob Fehler bei der Mesh-Netzwerkverbindung FATAL sind. Der AVB-Modus bestimmt, ob Überprüfungen, die vom Android-Bootloader durchgeführt werden, fatal 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 SDV sicheren SDV-Mesh-Netzwerks auswirken. Die Farben sind wie im Abschnitt Android-spezifische Integration der AVB-Dokumentation definiert.

Wert des Gerätemodus

In einer DICE-Kette hat jedes CDI-Zertifikat einen Moduswert. Er wird verwendet, um den Sicherheitsstatus dieser Ebene basierend auf der Konfigurationseingabe zu beschreiben. Um den Sicherheitsstatus aller Software auf dem Gerät auszudrücken, wird ein Wert des Gerätemodus definiert, der vom Moduswert aller CDI-Phasen der DICE-Ketten abgeleitet wird, die für eine bestimmte SDV-VM relevant sind (d. h. Android HLOS und Secure World) und wie folgt definiert ist:

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

Algorithmus

1. Setzen Sie deviceMode auf DeviceMode::Normal.
2. Setzen Sie diceChainList auf die Liste der DICE-Ketten, die für eine SDV-VM relevant sind.
3. Für jede diceChain in diceChainList:
   1. Setzen Sie cdiList auf die Liste der CDI-Zertifikate in diceChain:
   2. Für jedes cdiCert in cdiList:
      1. Setzen Sie cdiDeviceMode auf den DeviceMode, 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 den selben Wert des Gerätemodus haben wie er selbst.

Der Wert des Gerätemodus sorgt dafür, dass ein Mesh-Netzwerk keine Mitglieder mit unterschiedlichen Sicherheitseigenschaften haben kann. Daher hat das resultierende Mesh-Netzwerk einen einheitlichen Sicherheitsstatus für alle seine Mitglieder.

Ablauf der Bereitstellung in der Fabrik

Dies ist der Bereitstellungsablauf am Fließband des Fahrzeugs, 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 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 VVMFactoryTrust haben.

Ausgangsstatus

Alle ECUs haben anfangs den SDV-Bootmodus „FREIGESCHALTET“ und leere VVMFactoryTrust- und VVMTrustStore-Werte, abgesehen von möglicherweise vorhandenen uds_certs im VVMTrustStore.

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.

Schritt 1: sdv_provisioning_tool ausführen

Starten Sie alle VMs von allen ECUs.

Auf jeder VM:

• sdv_provisioning_tool ausführen

  • Das Tool kommuniziert mit dem lokalen Service Discovery-Agent und wartet darauf, dass dieser signalisiert, dass das sichere SDV-Mesh-Netzwerk 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.

Schritt 2: VVMFactoryTrust schreiben

Auf einer VM jeder ECU:

• Schreiben Sie den Hash von /vvmtruststore/uds_pubs, der im vorherigen Schritt von sdv_provisioning_tool ausgegeben wurde, in den VVMFactoryTrust. Wie das Schreiben erfolgt, ist OEM-/anbieterspezifisch und daher nicht Teil dieser Spezifikation.

Schritt 3: Im SDV-Bootmodus „GESPERRT“ neu starten

Starten Sie alle VMs in allen ECUs im SDV-Bootmodus „GESPERRT“ neu.

Der Service Discovery-Agent vertraut VMs in ECUs mit den öffentlichen UDS-Schlüsseln, die in uds_pubs aufgeführt sind, da der Hash dieser Datei mit dem VVMFactoryTrust übereinstimmt.

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

Ablauf beim 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 in der Fabrik bereitgestellt und werden im SDV-Bootmodus „GESPERRT“ ausgeführt.

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

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-Mesh-Netzwerke: eines im Status „Warnung“ und eines im Status „Normal“. Beide sicheren SDV-Mesh-Netzwerke sind unvollständig.

Schritt 2: Im SDV-Bootmodus „FREIGESCHALTET“ neu starten

Starten Sie alle VMs aller ECUs im SDV-Bootmodus „FREIGESCHALTET“ neu.

In Abbildung 7 treten VM-B und VM-C dann dem sicheren SDV-Mesh-Netzwerk im Status „Warnung“ bei, das jetzt vollständig ist.

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 dieser signalisiert, dass das sichere SDV-Mesh-Netzwerk 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.

Schritt 4: UDS-Zertifikate installieren

• Extrahieren Sie /vvmtruststore/uds_pubs aus einer beliebigen SDV-VM. Es spielt keine Rolle, welche VM Sie auswählen, da der Wert für alle VMs im selben sicheren SDV-Mesh-Netzwerk gleich ist.
• Rufen Sie Bereitstellungszertifikate für alle öffentlichen UDS-Schlüssel ab, die in /vvmtruststore/uds_pubs aufgeführt sind.
  • In der Regel wird dies an einen Remote-Server gesendet, auf dem die Zertifikate bereits gespeichert sind oder der sie generiert, indem er die empfangenen öffentlichen Schlüssel mit einer Datenbank bekannter öffentlicher UDS-Schlüssel vergleicht. Diese Datenbank wurde aus den öffentlichen UDS-Schlüsseln erstellt, die während der ECU-Fertigung extrahiert wurden.
• Schreiben Sie die /vvmtruststore/uds_certs jeder SDV-VM.

Schritt 5: Im SDV-Bootmodus „GESPERRT“ neu starten

Starten Sie alle VMs im SDV-Bootmodus „GESPERRT“ neu.

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