À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Moteur de composition des identifiants d'appareil
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Le Device Identifier Composition Engine (DICE) est une spécification du TCG (Trusted Computing Group) qui a été adoptée dans Android.
Il crée un ensemble d'identités cryptographiques robustes et immuables pour chaque micrologiciel chargé lors de la séquence de démarrage. Ces identités permettent de vérifier à distance la stratégie de sécurité d'un appareil, qui ne peut être contournée qu'en compromettant la ROM.
Processus de dérivation DICE
Figure 1. Processus simplifié de dérivation du DICE.
Le processus de dérivation DICE garantit que toute modification apportée à une image de micrologiciel génère un nouvel identifiant unique pour cette étape et pour toutes les étapes suivantes. En effet, chaque étape du micrologiciel chargé mesure et certifie la suivante, générant des identités uniques et des clés associées qui empêchent le contournement ou la falsification. La mémoire morte (ROM) traite la mesure, la configuration et le secret de l'appareil unique (UDS) à l'aide d'une fonction de dérivation de clé (KDF) pour dériver le secret à charger pour l'étape suivante. Ce secret est appelé identifiant d'appareil composé (CDI).
Étape 0: Initialisation
Le processus DICE commence par le chargement de l'UDS à partir d'une banque de données immuables (généralement des fusibles) par la ROM du chipset. Cette UDS est provisionnée de manière sécurisée avec une valeur aléatoire cryptographiquement lors du processus de production de la puce. Après avoir lu la table UDS, la ROM utilise un mécanisme de verrouillage matériel dépendant du fournisseur, tel qu'un loquet, pour verrouiller l'accès à la table UDS jusqu'au prochain démarrage.
Étape 1: Dérivation de clé initiale
La ROM utilise l'UDS comme entrée d'une fonction de dérivation de clé (KDF) pour générer la paire de clés asymétriques permanente qui identifie de manière unique cet appareil. Il mesure l'étape suivante du micrologiciel, y compris les métadonnées sur l'environnement de démarrage, par exemple si le démarrage sécurisé est activé. La ROM combine ensuite l'UDS, la mesure du micrologiciel et les données de configuration dans le KDF pour dériver le premier CDI, qui est transmis à l'étape suivante en tant que secret.
Étapes 2 à n: dérivation de clé récursive
Le processus se répète ensuite. À toutes les étapes suivantes, le CDI de l'étape précédente sert d'entrée pour un nouveau KDF. Ce KDF utilise le CDI et le hachage de l'image du micrologiciel suivant pour générer un nouveau CDI dérivé. Chaque étape génère sa propre paire de clés et l'utilise pour signer un certificat contenant des mesures spécifiques à l'étape et d'autres métadonnées associées.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Device Identifier Composition Engine\n\nThe Device Identifier Composition Engine (DICE) is a\n[Trusted Computing Group (TCG) specification](https://trustedcomputinggroup.org/what-is-a-device-identifier-composition-engine-dice/)\nthat has been [adopted into Android](https://pigweed.googlesource.com/open-dice/+/refs/heads/android16-release/docs/android.md).\nIt creates a set of strong, immutable cryptographic identities for each piece of firmware loaded\nduring the boot sequence. These identities enable remote verification of a device's security\nposture, which can only be evaded by compromising the ROM.\n\nDICE derivation process\n-----------------------\n\n***Figure 1.** Simplified DICE derivation process.*\n\n\nThe DICE derivation process ensures that any change to any firmware image results in a new unique\nidentifier for that stage and every stage thereafter. This is because each loaded firmware stage\nmeasures and certifies the next, generating unique identities and associated keys that prevent\nbypassing or tampering. The [read-only memory (ROM)](https://en.wikipedia.org/wiki/Read-only_memory)\nprocesses the measurement, configuration, and unique device secret (UDS) with a key derivation\nfunction (KDF) to derive the secret for the next stage to be loaded. This secret is referred to as\na compound device identifier (CDI).\n\n### Stage 0: Initialization\n\n\nThe DICE process begins with the chipset's ROM loading the UDS from a bank of immutable data,\ntypically fuses. This UDS is securely provisioned with a cryptographically random value during the\nchip production process. After reading the UDS, the ROM uses a vendor-dependent hardware-locking\nmechanism such as a latch to lock UDS access until the next boot.\n\n### Stage 1: Initial key derivation\n\n\nThe ROM uses the UDS as input to a [key derivation function (KDF)](https://en.wikipedia.org/wiki/Key_derivation_function)\nto generate the permanent asymmetric key pair that uniquely identifies that device. It measures\nthe next firmware stage, including metadata about the boot environment such as whether secure boot\nis enabled. The ROM then combines the UDS, firmware measurement, and configuration data in the KDF\nto derive the first CDI, which is passed to the next stage as a secret.\n\n### Stage 2 to n: Recursive key derivation\n\n\nThe process then repeats. In all subsequent stages, the CDI from the previous stage serves as the\ninput for a new KDF. This KDF uses the CDI and the hash of the next firmware image to produce a\nnew derived CDI. Each stage generates its own key pair and uses it to sign a certificate\ncontaining stage-specific measurements and other associated metadata."]]
