Registro de transparência dos módulos principais do Android

O registro de transparência dos módulos Mainline do Android usa estruturas de dados verificáveis para garantir a integridade dos módulos Mainline.

A utilidade dos registros de transparência foi comprovada por projetos como a Transparência binária do Pixel e a Transparência de certificados.

Os registros de transparência são criados em árvores de Merkle. Esta página pressupõe conhecimento geral de árvores de Merkle e transparência binária. Consulte Estruturas de dados verificáveis para uma visão geral das árvores de Merkle e a página principal para uma visão geral dos esforços de transparência binária no Android.

Implementação de registros

O registro de transparência dos módulos Mainline do Android é implementado usando Tessera e segue a especificação tlog-tiles com uma altura de bloco de 8 (cada bloco ou pacote contém no máximo 28 = 256 itens).

A raiz do conteúdo do registro é disponibilizada em: https://gstatic.com/android/binary_transparency/mainline/2026/02/tile/entries/

A raiz do conteúdo do bloco é disponibilizada em: https://gstatic.com/android/binary_transparency/mainline/2026/02/tile/

Observação: esses URLs não são páginas da Web padrão. Em vez disso, as entradas de registro nos subdiretórios precisam ser acessadas de maneira programática usando ferramentas como o Tessera ou a biblioteca Golang SumDB Tlog.

  • Blocos de árvore: os hashes de nós internos e de folha da árvore de Merkle são disponibilizados em tile/<level>/<path> (por exemplo, tile/0/000, tile/1/000).
  • Pacotes de entrada: os payloads de folha de registro são organizados em pacotes de entrada em tile/entries/<path> (por exemplo, tile/entries/000, tile/entries/001), com cada pacote contendo até 256 entradas concatenadas.

Consulte Conteúdo do registro para uma descrição do que cada entrada contém.

O hash de raiz da árvore de Merkle do registro, contido em um checkpoint, é disponibilizado em https://gstatic.com/android/binary_transparency/mainline/2026/02/checkpoint no formato de checkpoint. A origem do checkpoint é gstatic.com/android/binary_transparency/mainline/modules/2026/1.

As assinaturas de checkpoint são geradas usando o algoritmo de assinatura Ed25519. A assinatura do checkpoint pode ser verificada com a seguinte chave pública no formato de verificador de notas (conforme definido em golang.org/x/mod/sumdb/note) ou no formato PEM padrão:

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

Registro arquivado (V1)

Antes da atualização do terceiro trimestre de 2026, o registro operava em uma implementação V1 anterior usando assinaturas ECDSA (NIST P-256 com SHA-256). O registro V1 é arquivado e somente leitura, mas permanece acessível publicamente para verificar entradas históricas:

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

Como os módulos Mainline são semelhantes aos APKs, os métodos de verificação descritos na página de verificação de APKs do Google também se aplicam aqui. Você pode usar os métodos para verificar as declarações feitas no modelo de requerente.