A partire dal 27 marzo 2025, ti consigliamo di utilizzare android-latest-release anziché aosp-main per compilare e contribuire ad AOSP. Per ulteriori informazioni, vedi Modifiche ad AOSP.
Motore di composizione dell'identificatore del dispositivo
Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Device Identifier Composition Engine (DICE) è una
specifica del Trusted Computing Group (TCG)
che è stata adottata in Android.
Crea un insieme di identità crittografiche sicure e immutabili per ogni componente del firmware caricato durante la sequenza di avvio. Queste identità consentono la verifica da remoto della situazione di sicurezza di un dispositivo, che può essere aggirata solo compromettendo la ROM.
Procedura di derivazione di DICE
Figura 1. Procedura di derivazione DICE semplificata.
Il processo di derivazione DICE garantisce che qualsiasi modifica all'immagine del firmware generi un nuovo identificativo unico per quella fase e per tutte le fasi successive. Questo perché ogni fase del firmware caricata misura e certifica la successiva, generando identità univoche e chiavi associate che impediscono il aggiramento o la manomissione. La memoria di sola lettura (ROM) elabora la misurazione, la configurazione e il segreto del dispositivo univoco (UDS) con una funzione di derivazione della chiave (KDF) per ricavare il segreto da caricare nella fase successiva. Questo segreto è chiamato
identificatore dispositivo composto (CDI).
Fase 0: inizializzazione
Il processo DICE inizia con il caricamento della ROM del chipset dell'UDS da una banca di dati immutabili, tipicamente fusi. Questo UDS viene eseguito il provisioning in modo sicuro con un valore crittograficamente casuale durante il processo di produzione del chip. Dopo aver letto l'UDS, la ROM utilizza un meccanismo di blocco hardware dipendente dal fornitore, ad esempio un fermo, per bloccare l'accesso all'UDS fino al riavvio successivo.
Fase 1: derivazione iniziale della chiave
La ROM utilizza l'UDS come input per una funzione di derivazione delle chiavi (KDF)
per generare la coppia di chiavi asimmetriche permanente che identifica in modo univoco il dispositivo. Misura la fase successiva del firmware, inclusi i metadati sull'ambiente di avvio, ad esempio se l'avvio protetto è abilitato. La ROM combina quindi i dati UDS, di misurazione del firmware e di configurazione nel KDF per ricavare il primo CDI, che viene passato alla fase successiva come segreto.
Fase 2-n: derivazione ricorsiva della chiave
La procedura viene ripetuta. In tutte le fasi successive, il CDI della fase precedente funge da input per un nuovo KDF. Questo KDF utilizza il CDI e l'hash dell'immagine del firmware successiva per produrre un nuovo CDI derivato. Ogni fase genera la propria coppia di chiavi e la utilizza per firmare un certificato contenente misurazioni specifiche della fase e altri metadati associati.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Mancano le informazioni di cui ho bisogno","missingTheInformationINeed","thumb-down"],["Troppo complicato/troppi passaggi","tooComplicatedTooManySteps","thumb-down"],["Obsoleti","outOfDate","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Problema relativo a esempi/codice","samplesCodeIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
