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 inicio 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.