Ab 2026 werden wir den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen, um unser trunk-stable-Entwicklungsmodell zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten. Für die Entwicklung und das Beitragen zu AOSP empfehlen wir die Verwendung von android-latest-release anstelle von aosp-main. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

SDV-Profil für DICE

Das SDV-Profil für die Device Identifier Composition Engine (DICE) ist eine Erweiterung des Android-Profils für DICE. Bei SDV verwendet eine VM zwei parallele DICE-Ketten:

DICE-Kette für sichere Welt
DICE-Kette für Android SDV

Die folgenden Felder aus dem Konfigurationsdeskriptor des Android-Profils für DICE sind für die einzelnen Ketten relevant:

Name	Schlüssel	Typ	Beschreibung
Komponentenname	`-70002`	`tstr`	Empfohlen für jede CDI-Ebene: Der Komponentenname identifiziert die Phase eindeutig unter allen DICE-Ketten der Hardware, auf der Android SDV-VMs auf einem Fahrzeug oder einer Fahrzeugplattform ausgeführt werden.
Sicherheitsversion	`-70005`	`uint`	In jeder CDI-Phase erforderlich. Ermöglicht die Definition einer DICE-Richtlinie, die verhindert, dass unsichere Remote-VM-Versionen dem sicheren SDV-Mesh beitreten.
Name der Komponenteninstanz <0x0A	`-70007`	`tstr`	Erforderlich für die erste VM-spezifische CDI-Ebene. Zum Beispiel nach dem Hypervisor für die Android SDV-DICE-Kette. Name der SDV-Instanz. Wenn mehrere CDI-Ebenen den Namen der Komponenteninstanz enthalten, muss jede Ebene denselben Wert haben.

DICE-Kette für sichere Welt

Die Secure World-DICE-Kette ist dieselbe, die der Remote Key Provisioning-Server (RKP) von Android-Geräten empfängt. Die IRemotelyProvisionedComponent-HAL generateCertificateRequestV2() stellt diese DICE-Kette für Android bereit.

In dieser Tabelle wird eine Beispiel-DICE-Kette für die Secure World dargestellt:

Bootphase	DICE-CDI-Layer	Ausgestellt von
Primärer Bootloader	`CDI[0]`	UDS
Sekundärer Bootloader	`CDI[1]`	Primärer Bootloader
TEE-Boot	`CDI[2]`	Sekundärer Bootloader
KeyMint TA-Boot	`CDI[3]` (Leaf)	TEE

Verwenden Sie eine der folgenden Optionen, um die KeyMint-TA zu implementieren:

Eine KeyMint-Instanz für alle SDV-VMs:Sie MÜSSEN eine einzelne CDI für alle VMs festlegen.

oder

Eine KeyMint-Instanz für jede SDV-VM:Sie MÜSSEN für jede VM einen anderen CDI-Wert festlegen. Einzelne CDI-Werte MÜSSEN einen Component Instance Name enthalten, der dem Component Instance Name der VM entspricht.

DICE-Kette für Android SDV

Die Android SDV-DICE-Kette zertifiziert die Software, die auf dem Bootpfad ausgeführt wird, der über den Hypervisor zum Android-HLOS (High-Level Operating System) führt, das auf den SDV-VMs ausgeführt wird.

In dieser Tabelle wird eine Beispielkette für Android SDV DICE dargestellt:

Bootphase	DICE-CDI-Layer	Ausgestellt von
Primärer Bootloader	`CDI[0]`	UDS
Sekundärer Bootloader	`CDI[1]`	Primärer Bootloader
Hypervisor	`CDI[2]`	Sekundärer Bootloader
Android-HLOS	`CDI[3]` (Leaf)	(Android-Ladeprogramm im) Hypervisor¹

¹ Der Hypervisor zertifiziert den Android-Bootloader im Gast als Ebene. Der Android-Bootloader zertifiziert das Android-HLOS.

Android HLOS CDI-Zertifikat

Der Android-Bootloader (oder der Hypervisor, wenn es keinen Android-Bootloader, sondern nur ein Android-„Loader“-Programm gibt, das die VM im Hypervisor lädt) signiert das CDI-Zertifikat für das Android-HLOS und deckt das Android-HLOS ab. Dazu gehört beispielsweise der gesamte Code, den der Android-Bootloader gemäß Android Verified Boot (AVB) überprüft.

Das CDI-Zertifikat für Android-HLOS muss SDV-spezifische Werte des Android-Betriebssystems enthalten, die Sicherheitslücken schließen. So kann beispielsweise ein potenzielles Offenlegen von vertraulichen Informationen verhindert werden, indem VMs mit bekannten Sicherheitslücken aus dem SDV Secure Mesh ausgeschlossen werden. Die AVB-Bestätigung liefert die meisten dieser Werte.

Sie werden auch an KeyMint im TEE übergeben, wo das Zertifikat vom Leaf-CDI der SecureWorld-DICE-Kette signiert und an Android im DeviceInfo übergeben wird, um Funktionen wie die Schlüssel- und ID-Attestierung in Core-Android zu aktivieren.

Felder für Codeeingabe und codeHash-Zertifikat

Der VBMeta-Digest (eine Ausgabe des Android-Bootloaders für die AVB-Überprüfung) umfasst die Software des Android-HLOS. Daher dient es als android-dice-input-values zum Ableiten der CDI-Secrets und wird in das Feld dice-cert-fields des CDI-Zertifikats eingefügt.

Der empfohlene Hash-Algorithmus für AVB ist SHA-256, der zu einem 32 Byte langen VBMeta-Digest führt. Im Gegensatz zum Open Profile for DICE ist im Android Profile for DICE android-dice-hash-algos mit 32 Byte langen android-dice-input-values für den DICE-Ablauf zulässig. Außerdem kann derselbe 32 Byte lange Wert als „codeHash“ im DICE-Zertifikat platziert werden.

Konfigurationsdeskriptor: Felder im Android-Profil für DICE

Zusätzlich zu den für alle CDI-Ebenen beschriebenen Aspekten gelten die folgenden Besonderheiten für die Felder des Konfigurationsdeskriptors aus dem Android-Profil für DICE:

Name	Schlüssel	Typ	Beschreibung
Komponentenversion	`-70003`	`int`	Die Betriebssystemversion des Systems aus AVB `version-info-avb`. Sie ist auch mit `android.os.Build.VERSION.release` identisch.
Sicherheitsversion	`-70005`	`uint`	Das Sicherheitspatch-Level der Partition `system` im Format `YYYYMMDD`.
RKP-VM-Markierung	`-70006`	`null`	Die RKP-VM-Markierung verhindert, dass die Remote Key Provisioning-Funktion Zertifikate für die Android SDV-DICE-Kette ausstellt.

Die RKP-VM-Markierung muss im ersten CDI-Zertifikat der Android SDV-DICE-Kette erscheinen, das nicht mit der Secure World-DICE-Kette übereinstimmt. Sie dürfen auch nicht in weiteren CDI-Zertifikaten enthalten sein, damit der RKP-Server rkp-avf-support die DICE-Kette nicht als von einer RKP-VM stammend betrachtet.

Konfigurationsdeskriptor: Neue Felder

Der Konfigurationsdeskriptor des Android HLOS CDI-Zertifikats muss SDV-spezifische Werte enthalten, die über die im Android-Profil für DICE beschriebenen Werte hinausgehen. Das SDV-Profil für DICE reserviert den Schlüsselwertbereich [-71000, -71999] für diesen Zweck. Sie können implementierungsspezifische Felder mit Schlüsselwerten außerhalb des reservierten Bereichs hinzufügen. Die SDV-spezifischen Werte sind:

Name	Schlüssel	Typ	Beschreibung
Status des verifizierten Bootmodus	`-71000`	`tstr`	Entweder `green`, `yellow` oder `orange`.
Build-Fingerprint	`-71001`	`tstr`	Für Menschen lesbarer String, der diesen Build eindeutig identifiziert, genau wie `ro.build.fingerprint`. Das Android CDD, 3.2.2 Build Parameters, `cdd-3-2-2` definiert dies. VBMeta speichert dies als Attribut mit dem Namen `com.android.build.system.fingerprint`.
`system_ext` Sicherheitspatch-Level	`-71002`	`uint`	Sicherheitspatch-Level der Partition `system_ext` im Format `YYYYMMDD`.
`product` Sicherheitspatch-Level	`-71003`	`uint`	Sicherheitspatch-Level der Partition `product` im Format `YYYYMMDD`.
`vendor` Sicherheitspatch-Level	`-71004`	`uint`	Sicherheitspatch-Level der Partition `vendor` im Format `YYYYMMDD`.
`boot` Sicherheitspatch-Level	`-71005`	`uint`	Sicherheitspatch-Level der Partition `boot` (mit dem Linux-Kernel) im Format `YYYYMMDD`.
SDV-Bootmodus	`-71006`	`tstr`	`locked` oder `unlocked` Weitere Informationen finden Sie unter Mesh-Status und Bereitstellung.

Auswahl des Eingabewerts für den Modus von Android HLOS CDI

Die android-dice-mode des Android HLOS CDI-Zertifikats verwendet die folgende Definition:

	AVB UNLOCKED	AVB LOCKED
SDV-Bootmodus ENTSPERRT	Fehler beheben	Fehler beheben
SDV-Bootmodus GESPERRT	Nicht konfiguriert (ungültig)	Normal

Funktion zur Schlüsselableitung

Die android-dice-kdf, die das öffentlich-private Schlüsselpaar aus dem CDI_Attest-Secret für das Android-HLOS-CDI ableitet, muss HKDF mit SHA512 als Hash-Funktion sein.