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 leituraro.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çãovendor
BOOT_PATCH_LEVEL
: partiçãoboot
OS_PATCH_LEVEL
eOS_VERSION
: partiçãosystem
.OS_VERSION
é removido do cabeçalhoboot.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 dispositivokeyBlobToUpgrade
é a chave que precisa ser atualizada.upgradeParams
são parâmetros necessários para fazer upgrade da chave. Isso incluiTag::APPLICATION_ID
eTag::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.