Transparência dos módulos principais do Android

Para aumentar ainda mais a confiança no SO Android, nos comprometemos a listar todos os módulos do SO Android (chamados de Mainline) oferecidos como uma atualização pelo Google Play no nosso registro de transparência. Publicamos o registro de transparência para verificar as declarações que fazemos sobre esses módulos. Os módulos pré-instalados não são listados explicitamente, porque já estão cobertos por transparência binária do Pixel.

Modelo de ameaça

Os sistemas de transparência podem ser usados para detectar e, assim, impedir ataques à cadeia de suprimentos. Ilustramos com alguns exemplos.

Suponha que um invasor modifique maliciosamente um módulo Mainline (que pode ser um arquivo APEX ou APK) e até consiga assiná-lo com a chave de assinatura usada para distribuição pelo Google Play. Qualquer pessoa que receber um módulo questionável poderá consultar o registro de transparência binária para verificar a autenticidade do módulo. Ela vai descobrir que o Google não adicionou os metadados do módulo correspondente ao registro e saberá que não deve confiar no módulo do SO comprometido.

Como a publicação no registro é um processo separado do processo de lançamento com assinatura, isso aumenta a dificuldade para o invasor, que não precisa apenas comprometer a chave.

Embora também planejemos integrar esse registro a uma rede pública de testemunhas usando um protocolo de testemunha, incentivamos partes externas e independentes a monitorar a integridade desse registro disponível publicamente. Essas partes podem atestar a propriedade de anexação do registro e informar qualquer adulteração.

A existência de um sistema de transparência e a capacidade de descoberta adicional de ataques desencorajam atividades maliciosas. Se um módulo do SO for comprometido, mas os usuários confiarem apenas nos que estão no registro, o módulo comprometido precisará ser exposto publicamente. Isso aumenta a probabilidade de descobrir que os módulos comprometidos existem, e ações podem ser tomadas para remover a distribuição deles.

Modelo de reclamante

O modelo de reclamante é um framework usado para definir papéis e artefatos em um sistema verificável. No caso da transparência de módulos Mainline do Android, a declaração que fazemos é que o hash de um arquivo de módulo registrado nesse registro representa uma versão específica de um módulo oficial do Android destinado ao consumo público.

  • ClaimMainlineModule: (eu, Google, declaro que $hashModule é para $mainlineModule), em que:
    • $hashModule é um hash criptográfico (por exemplo, SHA256) do arquivo de módulo do SO de uma versão específica de $mainlineModule.
    • $mainlineModule é um pacote APEX ou Android (APK) que compõe um módulo do SO que o Google cria, assina e distribui.

Qualquer pessoa com uma cópia de $mainlineModule pode verificar essa declaração. A página de verificação fornece instruções detalhadas para esse processo. Essas etapas se aplicam a APKs normais e módulos Mainline (que podem ser arquivos APK ou APEX).

Conteúdo do registro

Quando o Google lança uma nova versão de um módulo Mainline, ele adiciona uma entrada correspondente ao registro de transparência de módulos Mainline.

Cada entrada nesse registro contém quatro partes de metadados:

  1. O hash do APK ou APEX de um módulo Mainline do Android assinado. Essa é uma string hexadecimal do resumo SHA256 de todo o arquivo.
  2. A descrição do tipo de hash acima. Essa é uma string.
  3. O nome do pacote do módulo. Essa é uma string.
  4. O número da versão (versionCode) do módulo. Esse é um número inteiro diferente de zero.

O formato de uma entrada de registro é a concatenação das quatro informações com um caractere de nova linha (\n), conforme ilustrado abaixo:

hash\nhash_description\npackage_name\npackage_version\n

Como um módulo Mainline pode ser um arquivo APK ou APEX, a descrição do hash pode ser SHA256(APK) ou SHA256(APEX).