O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

APK Esquema de assinatura v3

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

APK Bloco de assinatura

Para manter a compatibilidade com versões anteriores do 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 do ZIP.

O formato do bloco de assinatura do APK da v3 é o mesmo da v2 . A assinatura v3 do APK é armazenada como um par de valor e ID com o ID 0xf05368c0.

APK Esquema de assinatura v3 Block

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 de EC.

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

Formato

O bloco do esquema de assinatura do APK v3 é armazenado dentro do bloco de assinatura do APK com o ID 0xf05368c0 .

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

  • sequência com prefixo de comprimento do signer prefixo de comprimento:
    • signed data prefixo de comprimento:
      • sequência com prefixo de comprimento dos digests prefixo de comprimento:
        • signature algorithm ID (4 bytes)
        • digest (prefixo do comprimento)
      • sequência prefixada em comprimento dos certificates X.509:
        • certificate X.509 com prefixo de comprimento (formulário ASN.1 DER)
      • minSDK (uint32) - esse assinante deve ser ignorado se a versão da plataforma estiver abaixo desse número.
      • maxSDK (uint32) - esse assinante deve ser ignorado se a versão da plataforma estiver acima desse número.
      • sequência prefixada por comprimento de additional attributes prefixados por comprimento:
        • ID (uint32)
        • value (comprimento variável: comprimento do atributo adicional - 4 bytes)
        • ID - 0x3ba06f8c
        • value - Estrutura da prova de rotação
    • minSDK (uint32) - duplicado do valor minSDK na seção de dados assinados - usado para ignorar a verificação dessa 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 dessa 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 prefixo de comprimento:
      • signature algorithm ID (uint32)
      • signature prefixo de comprimento sobre signed data
    • public key prefixo de comprimento (SubjectPublicKeyInfo, formulário ASN.1 DER)

Estruturas de prova de rotação e certificados antigos com autoconfiança

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

  • afirmação para terceiros de que o certificado de assinatura do aplicativo pode ser confiável onde quer que seus predecessores 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. Esse atributo deve conter as estruturas de dados conceituais de prova de rotação e de dados antigos de confiança própria. 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 é criada com o certificado em cada nó assinando o próximo na lista e, assim, imbuindo cada nova chave com evidência de que ela deve ser tão confiável quanto as chaves mais antigas.

A estrutura de dados auto-confiável-old-certs é 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 a obtenção de permissões de assinatura do Android. Esse 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 da v3, ele é protegido pela chave usada para assinar o apk que contém.

Esse formato impede várias chaves de assinatura e a convergência de diferentes certificados de assinatura de ancestral para um (vários nós iniciais em um coletor comum).

Formato

A prova de rotação é armazenada no bloco Esquema de assinatura do APK v3 sob o ID 0x3ba06f8c . Seu formato é:

  • sequência prefixada em comprimento de levels prefixados em comprimento:
    • signed data 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 por cert no nível anterior
    • flags (uint32) - sinalizadores que indicam se este certificado deve ou não estar na estrutura de autoconfiança dos antigos e para quais operações.
    • signature algorithm ID (uint32) - deve corresponder ao da seção de dados assinados no próximo nível.
    • signature prefixo de comprimento sobre os signed data acima

Certificados múltiplos

Atualmente, o Android trata um APK assinado com vários certificados como tendo uma identidade de assinatura exclusiva separada dos certificados que o compõem. 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 visualizado como uma lista vinculada individualmente, com cada conjunto de assinantes de uma determinada versão representando um nó. Isso adiciona complexidade extra à estrutura de prova de rotação (versão com vários assinantes abaixo). Em particular, o pedido se torna uma preocupação. Além disso, 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 ter o assinante B apenas incluindo uma assinatura de A ou B, porque essa é uma identidade de assinatura diferente de B e C. Isso seria significa que os assinantes devem se coordenar antes de criar essa estrutura.

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

  • sequência prefixada em comprimento de sets prefixados em 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 de signature algorithm IDs (uint32) - uma para cada certificado do conjunto anterior, na mesma ordem.
    • flags (uint32) - sinalizadores que indicam se esse conjunto de certificados deve ou não estar na estrutura de certificados antigos confiáveis ​​e para quais operações.
    • sequência prefixada em comprimento de signatures prefixadas em comprimento:
      • signature algorithm ID (uint32) - deve corresponder ao da seção de dados assinados
      • signature prefixo de comprimento sobre os signed data acima

Vários antepassados ​​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 compradora 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 suportado 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, do mesmo aplicativo com dois caminhos diferentes para chegar ao mesmo certificado, quebra muitas das suposições feitas no design de rotação de teclas.

Verificação

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

Processo de verificação de assinatura do APK

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

Verificação do esquema de assinatura do APK v3

  1. Localize o bloco de assinatura do APK e verifique se:
    1. Dois campos de tamanho do APK Signing Block 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 do APK Signature Scheme v3 dentro do bloco de assinatura do APK. Se o bloco v3 estiver presente, continue na etapa 3. Caso contrário, volte a verificar o APK usando o esquema v2 .
  3. Para cada signer no APK Signature Scheme v3 Block com uma versão mínima e máxima do SDK que está no intervalo da plataforma atual:
    1. Escolha o signature algorithm ID do signature algorithm ID suportado mais forte entre signatures . A ordem de força depende de cada versão de implementação / plataforma.
    2. Verifique a signature correspondente de signatures 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 do algoritmo de assinatura nos digests e signatures é idêntica. (Isso evita a remoção / adição de assinatura.)
    5. Calcule o resumo do conteúdo do APK usando o mesmo algoritmo de resumo que o algoritmo de resumo usado pelo algoritmo de assinatura.
    6. Verifique se o resumo computado é idêntico ao digest correspondente dos digests .
    7. Verifique se SubjectPublicKeyInfo do primeiro certificate de certificates é idêntico à public key .
    8. Se existe o atributo de prova de rotação para o signer verificar se a estrutura é válido e este signer é o último certificado na lista.
  4. A verificação é bem-sucedida se exatamente um signer for encontrado no intervalo da plataforma atual e a etapa 3 for bem-sucedida para esse signer .

Validação

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