Para aumentar aún más la confianza en el SO Android, nos comprometemos a incluir en nuestro registro de transparencia todos los módulos del SO Android (llamados Mainline) que se ofrecen como actualizaciones a través de Google Play. Publicamos el registro de transparencia para verificar las afirmaciones que hacemos sobre estos módulos. Los módulos preinstalados no se enumeran de forma explícita, ya que ya están cubiertos por la Transparencia de binarios de Pixel.
Modelo de amenazas
Los sistemas de transparencia se pueden usar para detectar y, por lo tanto, disuadir los ataques a la cadena de suministro. Ilustramos con algunos ejemplos.
Supongamos que un atacante modifica de forma maliciosa un módulo de Mainline (que podría ser un archivo APEX o APK) y hasta logra firmarlo con la clave de firma que se usa para la distribución a través de Google Play. Cualquier persona que reciba un módulo cuestionable puede consultar el registro de transparencia binaria para verificar la autenticidad del módulo. Descubrirán que Google no agregó los metadatos del módulo correspondientes al registro y sabrán que no deben confiar en el módulo del SO vulnerado.
Dado que la publicación en el registro es un proceso independiente del proceso de lanzamiento con firma, esto eleva el nivel de exigencia para el atacante más allá de solo comprometer la clave.
Si bien planeamos integrar este registro en una red pública de testigos con un protocolo de testigos estándar, alentamos a las partes externas independientes a supervisar la integridad de este registro disponible públicamente. Estas partes pueden certificar la propiedad de solo agregar del registro y denunciar cualquier manipulación.
La existencia de un sistema de transparencia de este tipo y la capacidad de descubrir ataques adicionales desalientan la actividad maliciosa. Si se vulnera un módulo del SO, pero los usuarios solo confían en los que están en el registro, el módulo vulnerado debería exponerse públicamente. Esto aumenta la probabilidad de descubrir que existen módulos vulnerados y se pueden tomar medidas para detener su distribución.
Modelo de solicitante
El Modelo de Solicitante es un framework que se usa para definir roles y artefactos en un sistema verificable. En el caso de la transparencia de los módulos de Mainline de Android, la afirmación que hacemos es que el hash de un archivo de módulo registrado en este registro representa una versión específica de un módulo oficial de Android destinado al consumo público.
- Reclamo deMainlineModule: (Yo, Google, afirmo que
$hashModulees para$mainlineModule), donde:
Cualquier persona que tenga una copia de $mainlineModule puede verificar esta afirmación.
En la página de verificación, se proporcionan instrucciones detalladas para este proceso.
Estos pasos se aplican tanto a los APKs normales como a los módulos de Mainline (que pueden ser archivos APK o APEX).
Contenido del registro
Cuando Google lanza una versión nueva de un módulo de Mainline, agrega una entrada correspondiente al Registro de transparencia de los módulos de Mainline.
Cada entrada de este registro contiene cuatro elementos de metadatos:
- Es el hash del APK o APEX de un módulo de Android Mainline firmado. Es una cadena hexadecimal del resumen SHA256 de todo el archivo.
- Es la descripción del tipo de hash anterior. Es una cadena.
- Es el nombre del paquete del módulo. Es una cadena.
- Es el número de versión (versionCode) del módulo. Es un número entero distinto de cero.
El formato de una entrada de registro es la concatenación de los cuatro fragmentos de información con un carácter de nueva línea (\n), como se ilustra a continuación:
hash\nhash_description\npackage_name\npackage_version\n
Dado que un módulo de mainline puede ser un archivo APK o APEX, la descripción del hash puede ser SHA256(APK) o SHA256(APEX).