A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Motor de composición de identificadores de dispositivos
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Device Identifier Composition Engine (DICE) es una especificación del Trusted Computing Group (TCG) que se adoptó en Android.
Crea un conjunto de identidades criptográficas sólidas e inmutables para cada elemento de firmware cargado durante la secuencia de inicio. Estas identidades permiten la verificación remota de la postura de seguridad de un dispositivo, que solo se puede eludir si se vulnera la ROM.
Proceso de derivación de DICE
Figura 1: Proceso simplificado de derivación de DICE.
El proceso de derivación de DICE garantiza que cualquier cambio en cualquier imagen de firmware genere un nuevo identificador único para esa etapa y para todas las etapas posteriores. Esto se debe a que cada etapa del firmware cargado mide y certifica la siguiente, lo que genera identidades únicas y claves asociadas que impiden el bypass o la manipulación. La memoria de solo lectura (ROM)
procesa la medición, la configuración y el secreto del dispositivo único (UDS) con una función de derivación de claves (KDF) para derivar el secreto para que se cargue la siguiente etapa. Este secreto se conoce como identificador de dispositivo compuesto (CDI).
Etapa 0: Inicialización
El proceso de DICE comienza con la ROM del chipset que carga la UDS desde un banco de datos inmutables, que suelen ser fusibles. Esta UDS se aprovisiona de forma segura con un valor aleatorio criptográfico durante el proceso de producción de chips. Después de leer la UDS, la ROM usa un mecanismo de bloqueo de hardware dependiente del proveedor, como un seguro, para bloquear el acceso a la UDS hasta el próximo inicio.
Etapa 1: Derivación de claves inicial
La ROM usa el UDS como entrada a una función de derivación de claves (KDF) para generar el par de claves asimétricas permanente que identifica de forma inequívoca ese dispositivo. Mide la siguiente etapa del firmware, incluidos los metadatos sobre el entorno de inicio, como si el arranque seguro está habilitado. Luego, la ROM combina la UDS, la medición del firmware y los datos de configuración en el KDF para derivar el primer CDI, que se pasa a la siguiente etapa como un secreto.
Etapa 2 a n: Derivación de claves recursiva
Luego, se repite el proceso. En todas las etapas posteriores, el CDI de la etapa anterior sirve como entrada para un nuevo KDF. Este KDF usa el CDI y el hash de la siguiente imagen de firmware para producir un nuevo CDI derivado. Cada etapa genera su propio par de claves y lo usa para firmar un certificado que contiene mediciones específicas de la etapa y otros metadatos asociados.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
