El motor de composición de identificadores de dispositivos (DICE) es una especificación de Trusted Computing Group (TCG) que se adoptó en Android. Crea un conjunto de identidades criptográficas sólidas e inmutables para cada fragmento 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 evitar si se compromete la ROM.
Proceso de derivación del DICE
Figura 1: Se simplificó el proceso de derivación del 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 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 la omisión o la manipulación. La memoria de solo lectura (ROM) procesa la medición, la configuración y el secreto único del dispositivo (UDS) con una función de derivación de claves (KDF) para derivar el secreto que se cargará en la siguiente etapa. Este secreto se conoce como identificador de dispositivo compuesto (CDI).
Etapa 0: Inicialización
El proceso de DICE comienza con la carga de la UDS desde un banco de datos inmutables, por lo general, fusibles, en la ROM del chipset. Este UDS se aprovisiona de forma segura con un valor aleatorio criptográfico durante el proceso de producción del chip. Después de leer el UDS, la ROM usa un mecanismo de bloqueo de hardware dependiente del proveedor, como un pestillo, para bloquear el acceso al UDS hasta el próximo inicio.
Etapa 1: Derivación de la clave inicial
La ROM usa el UDS como entrada para una función de derivación de claves (KDF) para generar el par de claves asimétricas permanentes que identifica de forma única ese dispositivo. Mide la siguiente etapa del firmware, incluidos los metadatos sobre el entorno de arranque, como si el arranque seguro está habilitado. Luego, la ROM combina los datos de UDS, la medición de firmware y la configuración en la KDF para derivar el primer CDI, que se pasa a la siguiente etapa como secreto.
Etapas 2 a n: Derivación recursiva de claves
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 CDI derivado nuevo. 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.