Registro de transparencia de los módulos de línea principal de Android

El registro de transparencia de módulos de Mainline de Android usa estructuras de datos verificables para garantizar la integridad de los módulos de Mainline.

La utilidad de los registros de transparencia se demostró en proyectos como Pixel Binary Transparency y Certificado de transparencia.

Los registros de transparencia se basan en árboles de Merkle. En esta página, se supone que tienes conocimientos generales sobre los árboles de Merkle y la transparencia binaria. Consulta Estructuras de datos verificables para obtener una descripción general de los árboles de Merkle y la página principal para obtener una descripción general de los esfuerzos de transparencia binaria en Android.

Implementación de registros

El registro de transparencia de módulos de Mainline de Android se implementa con Tessera y cumple con la especificación tlog-tiles con una altura de mosaico de 8 (cada mosaico o paquete contiene como máximo 28 = 256 elementos).

La raíz del contenido del registro se entrega en: https://gstatic.com/android/binary_transparency/mainline/2026/02/tile/entries/

La raíz del contenido del mosaico se entrega en: https://gstatic.com/android/binary_transparency/mainline/2026/02/tile/

Ten en cuenta que estas URLs no son páginas web estándar. En cambio, se debe acceder a las entradas de registro en sus subdirectorios de forma programática con herramientas como Tessera o la biblioteca Golang SumDB Tlog.

  • Mosaicos de árbol: Los hashes de nodos interiores y hoja del árbol de Merkle se entregan en tile/<level>/<path> (p.ej., tile/0/000, tile/1/000).
  • Paquetes de entrada: Las cargas útiles de hojas de registro se organizan en paquetes de entrada en tile/entries/<path> (p.ej., tile/entries/000, tile/entries/001), y cada paquete contiene hasta 256 entradas concatenadas.

Consulta Contenido del registro para obtener una descripción de lo que contiene cada entrada.

El hash raíz del árbol de Merkle del registro, que se encuentra en un punto de control, se entrega en https://gstatic.com/android/binary_transparency/mainline/2026/02/checkpoint en el formato de punto de control. El origen del punto de control es gstatic.com/android/binary_transparency/mainline/modules/2026/1.

Las firmas de puntos de control se generan con el algoritmo de firma Ed25519. La firma del punto de control se puede verificar con la siguiente clave pública en formato de verificador de notas (como se define en golang.org/x/mod/sumdb/note) o en formato PEM estándar:

  • Formato de verificador de notas (<name>+<key_hash>+<public_key_bytes>):
MainlineModulesLogV2+e490c9dd+AfwnHm59rNQTJICchMd7a2W5PQa7nC5h2gTEfq3fhCEI
  • Formato PEM (SubjectPublicKeyInfo):
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEA/Ccebn2s1BMkgJyEx3trZbk9BrucLmHaBMR+rd+EIQg=
-----END PUBLIC KEY-----

Registro archivado (V1)

Antes de la actualización del tercer trimestre de 2026, el registro operaba con una implementación anterior de la versión 1 que usaba firmas ECDSA (NIST P-256 con SHA-256). El registro de la versión 1 está archivado y es de solo lectura, pero sigue siendo de acceso público para verificar las entradas históricas:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEr6nPds8eKCYU42avidXNM1GDCtQ/
66GjGuIpUcZjqQNngwRFVCFZDpWuvDnqXzhJRxqccL9lbeEVVZGpa4x6pg==
-----END PUBLIC KEY-----

Debido a que los módulos de Mainline son similares a los APK, los métodos de verificación que se describen en la página de verificación de APKs de Google también se aplican aquí. Puedes usar los métodos allí para verificar las declaraciones realizadas en el modelo de reclamante.