Esquema de assinatura de APK v3

O Android 9 oferece suporte à rotação de chaves de APK , o que dá aos aplicativos a capacidade de alterar sua chave de assinatura como parte de uma atualização de APK. Para tornar a rotação prática, os APKs devem indicar níveis de confiança entre a chave de assinatura nova e a antiga. Para oferecer suporte à rotação de chaves, atualizamos o esquema de assinatura do APK de v2 para v3 para permitir o uso de chaves novas e antigas. V3 adiciona informações sobre as versões do SDK suportadas e uma estrutura de prova de rotação ao bloco de assinatura do APK.

Observação : a rotação de chaves APK não é recomendada antes do lançamento do Android 11. Os desenvolvedores têm a opção de usar a atualização de chaves do Google Play para novas instalações. Os desenvolvedores inscritos no Play App Signing podem solicitar uma atualização por meio do Play Console.

Bloco de assinatura de APK

Para manter a compatibilidade retroativa com o formato APK v1, as assinaturas APK v2 e v3 são armazenadas dentro de um bloco de assinatura APK, localizado imediatamente antes do diretório central ZIP.

O formato do bloco de assinatura do APK v3 é igual ao v2 . A assinatura v3 do APK é armazenada como um par de valores de ID com ID 0xf05368c0.

Bloco do esquema de assinatura APK v3

O esquema v3 foi projetado para ser muito semelhante ao esquema v2 . Ele tem o mesmo formato geral e suporta os mesmos IDs de algoritmo de assinatura , tamanhos de chave e curvas EC.

No entanto, o esquema v3 adiciona informações sobre as versões do SDK suportadas e a estrutura de prova de rotação.

Formatar

O bloco APK Signature Scheme v3 é armazenado dentro do bloco de assinatura APK sob o ID 0xf05368c0 .

O formato do bloco APK Signature Scheme v3 segue o da v2:

• sequência com prefixo de comprimento signer com prefixo de comprimento:
  • signed data com prefixo de comprimento:
    • sequência com prefixo de comprimento de digests com prefixo de comprimento:
      • signature algorithm ID (4 bytes)
      • digest (com prefixo de comprimento)
    • sequência de certificates X.509 com prefixo de comprimento:
      • certificate X.509 com prefixo de comprimento (formulário ASN.1 DER)
    • minSDK (uint32) – este signatário deve ser ignorado se a versão da plataforma estiver abaixo deste número.
    • maxSDK (uint32) – este signatário deve ser ignorado se a versão da plataforma estiver acima deste número.
    • sequência com prefixo de comprimento de additional attributes com prefixo de comprimento:
      • ID (uint32)
      • value (comprimento variável: comprimento do atributo adicional - 4 bytes)
      • ID - 0x3ba06f8c
      • value - estrutura de prova de rotação
  • minSDK (uint32) - duplicata do valor minSDK na seção de dados assinados - usada para ignorar a verificação desta assinatura se a plataforma atual não estiver dentro do alcance. Deve corresponder ao valor dos dados assinados.
  • maxSDK (uint32) - duplicata do valor maxSDK na seção de dados assinados - usada para ignorar a verificação desta assinatura se a plataforma atual não estiver dentro do alcance. Deve corresponder ao valor dos dados assinados.
  • sequência com prefixo de comprimento de signatures com prefixo de comprimento:
    • signature algorithm ID (uint32)
    • signature com prefixo de comprimento sobre signed data
  • public key com prefixo de comprimento (SubjectPublicKeyInfo, formulário ASN.1 DER)

Estruturas de prova de rotação e certificados antigos autoconfiáveis

A estrutura de prova de rotação permite que os aplicativos alternem seu certificado de assinatura sem serem bloqueados em outros aplicativos com os quais se comunicam. Para conseguir isso, as assinaturas de aplicativos contêm dois novos dados:

• afirmação para terceiros de que o certificado de assinatura do aplicativo é confiável onde quer que seus antecessores sejam confiáveis
• certificados de assinatura mais antigos do aplicativo nos quais o próprio aplicativo ainda confia

O atributo de prova de rotação na seção de dados assinados consiste em uma lista vinculada individualmente, com cada nó contendo um certificado de assinatura usado para assinar versões anteriores do aplicativo. Este atributo destina-se a conter as estruturas de dados conceituais de prova de rotação e certificados antigos autoconfiáveis. A lista é ordenada por versão com o certificado de assinatura mais antigo correspondente ao nó raiz. A estrutura de dados de prova de rotação é construída fazendo com que o certificado em cada nó assine o próximo na lista e, assim, imbuindo cada nova chave com evidências de que ela deve ser tão confiável quanto a(s) chave(s) mais antiga(s).

A estrutura de dados de certificados antigos autoconfiáveis ​​é construída adicionando sinalizadores a cada nó indicando sua associação e propriedades no conjunto. Por exemplo, um sinalizador pode estar presente indicando que o certificado de assinatura em um determinado nó é confiável para obter permissões de assinatura do Android. Este sinalizador permite que outros aplicativos assinados pelo certificado mais antigo ainda recebam uma permissão de assinatura definida por um aplicativo assinado com o novo certificado de assinatura. Como todo o atributo de prova de rotação reside na seção de dados assinados do campo signer v3, ele é protegido pela chave usada para assinar o apk que o contém.

Este formato impede múltiplas chaves de assinatura e convergência de diferentes certificados de assinatura de ancestrais para um (vários nós iniciais para um coletor comum).

Formatar

A prova de rotação é armazenada dentro do bloco APK Signature Scheme v3 sob ID 0x3ba06f8c . Seu formato é:

• sequência com prefixo de comprimento de levels com prefixo de comprimento:
  • signed data com prefixo de comprimento (por certificado anterior - se existir)
    • certificate X.509 com prefixo de comprimento (formulário ASN.1 DER)
    • signature algorithm ID (uint32) - algoritmo usado pelo certificado no nível anterior
  • flags (uint32) - sinalizadores que indicam se este certificado deve ou não estar na estrutura de certificados antigos autoconfiáveis ​​e para quais operações.
  • signature algorithm ID (uint32) - deve corresponder ao da seção de dados assinados no próximo nível.
  • signature com prefixo de comprimento sobre os signed data acima

Vários certificados

Atualmente, o Android trata um APK assinado com vários certificados como tendo uma identidade de assinatura exclusiva separada dos certificados incluídos. Assim, o atributo de prova de rotação na seção de dados assinados forma um gráfico acíclico direcionado, que poderia ser melhor visto como uma lista encadeada individualmente, com cada conjunto de signatários para uma determinada versão representando um nó. Isso adiciona complexidade extra à estrutura de prova de rotação (versão com vários signatários abaixo). Em particular, a encomenda torna-se uma preocupação. Além do mais, não é mais possível assinar APKs de forma independente, porque a estrutura de prova de rotação deve ter os certificados de assinatura antigos assinando o novo conjunto de certificados, em vez de assiná-los um por um. Por exemplo, um APK assinado pela chave A que deseja ser assinado por duas novas chaves B e C não poderia fazer com que o signatário B incluísse apenas uma assinatura de A ou B, porque essa é uma identidade de assinatura diferente de B e C. Isso seria significa que os signatários devem coordenar antes de construir tal estrutura.

Atributo de prova de rotação de vários signatários

• sequência com prefixo de comprimento de sets com prefixo de comprimento:
  • signed data (por conjunto anterior - se existir)
    • sequência de certificates com prefixo de comprimento
      • certificate X.509 com prefixo de comprimento (formulário ASN.1 DER)
    • Sequência de signature algorithm IDs (uint32) - um para cada certificado do conjunto anterior, na mesma ordem.
  • flags (uint32) - sinalizadores que indicam se este conjunto de certificados deve ou não estar na estrutura de certificados antigos autoconfiáveis ​​e para quais operações.
  • sequência com prefixo de comprimento de signatures com prefixo de comprimento:
    • signature algorithm ID (uint32) - deve corresponder ao da seção de dados assinados
    • signature com prefixo de comprimento sobre os signed data acima

Vários ancestrais na estrutura de prova de rotação

O esquema v3 também não lida com duas chaves diferentes girando para a mesma chave de assinatura para o mesmo aplicativo. Isso difere do caso de uma aquisição, em que a empresa adquirente gostaria de mover o aplicativo adquirido para usar sua chave de assinatura para compartilhar permissões. A aquisição é vista como um caso de uso compatível porque o novo aplicativo seria diferenciado pelo nome do pacote e poderia conter sua própria estrutura de prova de rotação. O caso não suportado, de o mesmo aplicativo ter dois caminhos diferentes para chegar ao mesmo certificado, quebra muitas das suposições feitas no design de rotação de chaves.

Verificação

No Android 9 e superior, os APKs podem ser verificados de acordo com o esquema de assinatura do APK v3, esquema v2 ou esquema v1. As plataformas mais antigas ignoram as assinaturas v3 e tentam verificar as assinaturas v2, depois a v1.

Figura 1. Processo de verificação de assinatura APK

Verificação do esquema de assinatura APK v3

1. Localize o bloco de assinatura do APK e verifique se:
   1. Dois campos de tamanho do Bloco de assinatura de APK contêm o mesmo valor.
   2. O ZIP Central Directory é imediatamente seguido pelo registro ZIP End of Central Directory.
   3. ZIP O final do Diretório Central não é seguido por mais dados.
2. Localize o primeiro bloco APK Signature Scheme v3 dentro do bloco de assinatura APK. Se o bloco v3 estiver presente, prossiga para a etapa 3. Caso contrário, volte para a verificação do APK usando o esquema v2 .
3. Para cada signer no bloco APK Signature Scheme v3 com uma versão mínima e máxima do SDK que esteja ao alcance da plataforma atual:
   1. Escolha o signature algorithm ID com suporte mais forte signatures . A ordem de força depende de cada versão de implementação/plataforma.
   2. Verifique a signature correspondente das signatures em relação signed data usando public key . (Agora é seguro analisar signed data .)
   3. Verifique se as versões mínima e máxima do SDK nos dados assinados correspondem às especificadas para o signer .
   4. Verifique se a lista ordenada de IDs de algoritmos de assinatura em digests e signatures é idêntica. (Isso evita a remoção/adição de assinaturas.)
   5. Calcule o resumo do conteúdo do APK usando o mesmo algoritmo de resumo usado pelo algoritmo de assinatura.
   6. Verifique se o resumo calculado é idêntico ao digest correspondente de digests .
   7. Verifique se o SubjectPublicKeyInfo do primeiro certificate de certificates é idêntico à public key .
   8. Se o atributo de prova de rotação existir para o signer , verifique se a estrutura é válida e se esse signer é o último certificado da lista.
4. A verificação será bem-sucedida se exatamente um signer for encontrado no alcance da plataforma atual e a etapa 3 for bem-sucedida para esse signer .

Cuidado : o APK não deve ser verificado usando o esquema v1 ou v2 se ocorrer uma falha na etapa 3 ou 4.

Validação

Para testar se seu dispositivo suporta v3 corretamente, execute os testes PkgInstallSignatureVerificationTest.java CTS em cts/hostsidetests/appsecurity/src/android/appsecurity/cts/ .