Vinculação de versão

No Keymaster 1, todas as chaves eram vinculadas criptograficamente à raiz de confiança do dispositivo ou à chave de Inicialização verificada. No Keymaster 2 e 3, todas as chaves também são vinculadas ao sistema operacional e ao nível de patch da imagem do sistema. Isso garante que um invasor que descobrir uma falha em uma versão antiga do sistema ou do software TEE não possa reverter um dispositivo para a versão vulnerável e usar chaves criadas com a versão mais recente. Além disso, quando uma chave com uma determinada versão e nível de patch é usada em um dispositivo que foi atualizado para uma versão ou nível de patch mais recente, a chave é atualizada antes de poder ser usada, e a versão anterior da chave é invalidada. Dessa forma, à medida que o dispositivo é atualizado, as chaves *avançam* junto com ele, mas qualquer reversão do dispositivo para uma versão anterior faz com que as chaves fiquem inutilizáveis.

Para ser compatível com a estrutura modular do Treble e romper a vinculação de system.img com boot.img, o Keymaster 4 mudou o modelo de vinculação de versão de chave para ter níveis de patch separados para cada partição. Isso permite que cada partição seja atualizada de maneira independente, fornecendo ainda proteção contra reversão.

Para implementar essa vinculação de versão, o app confiável (TA, na sigla em inglês) do KeyMint precisa de uma maneira de receber com segurança a versão atual do SO e os níveis de patch, além de garantir que as informações recebidas correspondam a todas as informações sobre o sistema em execução.

  • Dispositivos com a Inicialização verificada do Android (AVB) podem colocar todos os níveis de patch e a versão do sistema em vbmeta para que o carregador de inicialização possa fornecê-los ao Keymaster. Para partições encadeadas, as informações de versão da partição estão na vbmeta encadeada. Em geral, as informações de versão precisam estar no vbmeta struct que contém os dados de verificação (hash ou hashtree) de uma determinada partição.
  • Em dispositivos sem AVB:
    • As implementações da Inicialização verificada precisam fornecer um hash dos metadados da versão ao carregador de inicialização, para que ele possa fornecer o hash ao Keymaster.
    • O boot.img pode continuar armazenando o nível do patch no cabeçalho.
    • system.img pode continuar armazenando o nível de patch e a versão do SO em propriedades somente leitura.
    • vendor.img armazena o nível de patch na propriedade somente leitura ro.vendor.build.version.security_patch.
    • O carregador de inicialização pode fornecer um hash de todos os dados validados pela Inicialização verificada ao Keymaster.
  • No Android 9, use as seguintes tags para fornecer informações de versão para as seguintes partições:
    • VENDOR_PATCH_LEVEL: partição vendor
    • BOOT_PATCH_LEVEL: partição boot
    • OS_PATCH_LEVEL e OS_VERSION: partição system. OS_VERSION é removido do cabeçalho boot.img.
  • As implementações do Keymaster precisam tratar todos os níveis de patch de forma independente. As chaves são utilizáveis se todas as informações de versão corresponderem aos valores associados a uma chave, e IKeymaster::upgradeDevice() será atualizado para um nível de patch mais alto, se necessário.

Mudanças na HAL

Para oferecer suporte à vinculação e ao atestado de versão, o Android 7.1 adicionou as tags Tag::OS_VERSION e Tag::OS_PATCHLEVEL e os métodos configure e upgradeKey. As tags de versão são adicionadas automaticamente pelas implementações do Keymaster 2+ a todas as chaves geradas (ou atualizadas) recentemente. Além disso, qualquer tentativa de usar uma chave que não tenha uma versão do SO ou um nível de patch correspondente à versão ou ao nível de patch do sistema atual, respectivamente, será rejeitada com ErrorCode::KEY_REQUIRES_UPGRADE.

Tag::OS_VERSION é um valor UINT que representa as partes principal, secundária e subsecundária de uma versão do sistema Android como MMmmss, em que MM é a versão principal, mm é a versão secundária e ss é a versão subsecundária. Por exemplo, 6.1.2 seria representado como 060102.

Tag::OS_PATCHLEVEL é um valor UINT que representa o ano e o mês da última atualização do sistema como AAAAMM, em que AAAA é o ano de quatro dígitos e MM é o mês de dois dígitos. Por exemplo, março de 2016 seria representado como 201603.

UpgradeKey

Para permitir que as chaves sejam atualizadas para a nova versão do SO e o nível de patch da imagem do sistema, o Android 7.1 adicionou o método upgradeKey à HAL:

Keymaster 3

    upgradeKey(vec keyBlobToUpgrade, vec upgradeParams)
        generates(ErrorCode error, vec upgradedKeyBlob);

Keymaster 2

keymaster_error_t (*upgrade_key)(const struct keymaster2_device* dev,
    const keymaster_key_blob_t* key_to_upgrade,
    const keymaster_key_param_set_t* upgrade_params,
    keymaster_key_blob_t* upgraded_key);
  • dev é a estrutura do dispositivo
  • keyBlobToUpgrade é a chave que precisa ser atualizada.
  • upgradeParams são parâmetros necessários para fazer upgrade da chave. Isso inclui Tag::APPLICATION_ID e Tag::APPLICATION_DATA, que são necessários para descriptografar o blob de chave, se fornecidos durante a geração.
  • upgradedKeyBlob é o parâmetro de saída usado para retornar o novo blob de chave.

Se upgradeKey for chamado com um blob de chave que não pode ser analisado ou é inválido, ele vai retornar ErrorCode::INVALID_KEY_BLOB. Se ele for chamado com uma chave cujo nível de patch seja maior que o valor atual do sistema, ele vai retornar ErrorCode::INVALID_ARGUMENT. Se for chamado com uma chave cuja versão do SO seja maior que o valor do sistema atual, e o valor do sistema não seja zero, ele vai retornar ErrorCode::INVALID_ARGUMENT. É permitido fazer upgrade de versões do SO de um valor diferente de zero para zero. Em caso de erros na comunicação com o mundo seguro, ele retorna um valor de erro apropriado (por exemplo, ErrorCode::SECURE_HW_ACCESS_DENIED, ErrorCode::SECURE_HW_BUSY). Caso contrário, ele retorna ErrorCode::OK e um novo blob de chave em upgradedKeyBlob.

O keyBlobToUpgrade permanece válido após a chamada upgradeKey e pode ser usado novamente se o dispositivo for revertido para uma versão anterior. Na prática, o keystore geralmente chama deleteKey no blob keyBlobToUpgrade logo após a chamada para upgradeKey. Se keyBlobToUpgrade tiver a tag Tag::ROLLBACK_RESISTANT, upgradedKeyBlob também precisará ter essa tag e ser resistente a rollbacks.

Configuração segura

Para implementar a vinculação de versão, a TA do Keymaster precisa de uma maneira de receber com segurança a versão atual do SO e o nível de patch (informações de versão) e garantir que as informações recebidas correspondam às informações sobre o sistema em execução.

Para oferecer suporte à entrega segura de informações de versão à TA, um campo OS_VERSION foi adicionado ao cabeçalho da imagem de inicialização. O script de build da imagem de inicialização preenche esse campo automaticamente. Os OEMs e os implementadores da TA do Keymaster precisam trabalhar juntos para modificar os carregadores de inicialização do dispositivo e extrair as informações de versão da imagem de inicialização, transmitindo-as para a TA antes da inicialização do sistema não seguro. Isso garante que os invasores não possam interferir no provisionamento de informações de versão para o TA.

Também é necessário garantir que a imagem do sistema tenha as mesmas informações de versão da imagem de inicialização. Para isso, o método "configure" foi adicionado à HAL do Keymaster: 

keymaster_error_t (*configure)(const struct keymaster2_device* dev,
  const keymaster_key_param_set_t* params);

O argumento params contém Tag::OS_VERSION e Tag::OS_PATCHLEVEL. Esse método é chamado por clientes do keymaster2 depois de abrir a HAL, mas antes de chamar qualquer outro método. Se qualquer outro método for chamado antes de "configure", a TA vai retornar ErrorCode::KEYMASTER_NOT_CONFIGURED.

Na primeira vez que configure é chamado após a inicialização do dispositivo, ele precisa verificar se as informações de versão fornecidas correspondem às informações fornecidas pelo carregador de inicialização. Se as informações de versão não corresponderem, configure vai retornar ErrorCode::INVALID_ARGUMENT, e todos os outros métodos do Keymaster vão continuar retornando ErrorCode::KEYMASTER_NOT_CONFIGURED. Se as informações corresponderem, o configure vai retornar ErrorCode::OK, e outros métodos do Keymaster vão começar a funcionar normalmente.

As chamadas subsequentes para configure retornam o mesmo valor retornado pela primeira chamada e não mudam o estado do Keymaster.

Como configure é chamado pelo sistema cujo conteúdo ele deve validar, há uma pequena janela de oportunidade para um invasor comprometer a imagem do sistema e forçar o fornecimento de informações de versão que correspondam à imagem de inicialização, mas que não sejam a versão real do sistema. A combinação da verificação da imagem de inicialização, da validação dm-verity do conteúdo da imagem do sistema e do fato de que configure é chamado muito cedo na inicialização do sistema dificulta a exploração dessa janela de oportunidade.