Chaves encapsuladas em hardware

Como a maioria dos softwares de criptografia de disco e de arquivos, a criptografia de armazenamento do Android tradicionalmente depende da presença das chaves de criptografia brutas na memória do sistema para que a criptografia possa ser realizada. Mesmo quando a criptografia é realizada por hardware dedicado em vez de software, o software geralmente ainda precisa gerenciar as chaves de criptografia brutas.

Isso não é considerado um problema porque as chaves não estão presentes durante um ataque off-line, que é o principal tipo de ataque que a criptografia de armazenamento pretende proteger. No entanto, há uma vontade de oferecer mais proteção contra outros tipos de ataques, como ataques de inicialização fria e ataques on-line em que um invasor pode vazar a memória do sistema sem comprometer totalmente o dispositivo.

Para resolver esse problema, o Android 11 introduziu suporte para chaves encapsuladas em hardware, quando houver suporte de hardware. Chaves encapsuladas em hardware são chaves de armazenamento conhecidas apenas na forma bruta para hardware dedicado. O software só vê e trabalha com essas chaves na forma encapsulada (criptografada). Esse hardware precisa ser capaz de gerar e importar de armazenamento, encapsulando as chaves de armazenamento de formas efêmeras e de longo prazo, obtendo subchaves, programando diretamente uma subchave em um mecanismo criptográfico em linha e retornando uma subchave separada para o software.

Observação:um mecanismo criptográfico inline (ou inline) de criptografia) refere-se ao hardware que criptografa/descriptografa dados enquanto está a caminho de/para o dispositivo de armazenamento. Geralmente, é um controlador de host UFS ou eMMC que implementa as extensões de criptografia definidas pela especificação JEDEC correspondente.

Design

Esta seção apresenta o design do recurso de chaves encapsuladas por hardware, incluindo: qual suporte de hardware é necessário. Esta discussão se concentra na criptografia baseada em arquivos (FBE, na sigla em inglês), mas a solução também se aplica à criptografia de metadados.

Uma maneira de evitar a necessidade de chaves de criptografia brutas na memória do sistema seria mantê-los apenas nos keyslots de um mecanismo criptográfico em linha. No entanto, essa abordagem tem alguns problemas:

• O número de chaves de criptografia pode exceder o número de slots de chaves.
• Os mecanismos de criptografia inline só podem ser usados para criptografar/descriptografar blocos completos de dados no disco. No entanto, no caso da FBE, o software ainda precisa ser capaz de fazer outros trabalhos criptográficos, como criptografia de nomes de arquivos e extração de identificadores de chaves. O software ainda precisaria de acesso às chaves FBE brutas para para fazer esse outro trabalho.

Para evitar esses problemas, as chaves de armazenamento são transformadas chaves encapsuladas por hardware, que só podem ser desencapsuladas e usadas por hardware dedicado. Isso permite que um número ilimitado de chaves seja aceito. Além disso, a hierarquia de chaves é modificada e parcialmente movida para esse hardware, o que permite que uma subchave seja retornada ao software para tarefas que não podem usar um mecanismo de criptografia inline.

Observação: é tecnicamente possível implementar "chaves conectadas a hardware" em software usando um TEE (ambiente de execução confiável) em execução no mesmo processador, em vez de usar hardware dedicado. No entanto, isso não é recomendado no momento, já que não está claro se isso oferece benefícios de segurança suficientes para justificar o recurso. Isso pode não proteger contra ataques de inicialização a frio.

Uma implementação no firmware pode ser aceitável, desde que o hardware em que o firmware é executado seja suficientemente separado do processador principal.

Hierarquia de chaves

As chaves podem ser derivadas de outras chaves usando uma função de derivação de chaves (KDF, na sigla em inglês) como HKDF (links em inglês), resultando em uma hierarquia de chaves.

O diagrama a seguir mostra uma hierarquia de chaves típica para a FBE quando as chaves encapsuladas por hardware não são usadas:

Figura 1. Hierarquia de chaves do FBE (padrão)

A chave de classe FBE é a chave de criptografia bruta que o Android transmite ao Linux para desbloquear um determinado conjunto de diretórios criptografados, como armazenamento criptografado por credenciais para um usuário Android específico. (No kernel, esse é chamada de chave mestra fscrypt.) A partir dessa chave, o kernel deriva as seguintes subchaves:

• O identificador da chave. Ele não é usado para criptografia, mas é um valor usada para identificar a chave com a qual um determinado arquivo ou diretório protegidas.
• A chave de criptografia do conteúdo do arquivo
• A chave de criptografia dos nomes de arquivos

Observação: o exemplo acima pressupõe o uso de uma das configurações de criptografia otimizada para uso com um mecanismo de criptografia inline (inlinecrypt_optimized ou emmc_optimized). Se uma dessas configurações não for usada, haverá muitos conteúdos de arquivo e chaves de criptografia de nomes de arquivos derivados da chave de classe FBE (uma por arquivo ou diretório), em vez de apenas uma de cada.

Em contraste, o diagrama a seguir mostra a hierarquia de chaves da FBE quando chaves encapsuladas por hardware são usadas:

Figura 2. Hierarquia de chaves de FBE (com chave de hardware)

Em comparação com o caso anterior, um nível adicional foi adicionado à hierarquia de chaves, e a chave de criptografia do conteúdo do arquivo foi realocada. A raiz ainda representa a chave que o Android passa ao Linux para desbloquear um conjunto de em diretórios criptografados. No entanto, agora essa chave está em um formato encapsulado temporário e, para ser usada, ela precisa ser transmitida para hardware dedicado. Esse hardware precisa implementar duas interfaces que usam uma chave encapsulada efêmera:

• Uma interface para derivar inline_encryption_key e criar programá-lo em um keyslot do mecanismo de criptografia inline. Isso permite que o conteúdo do arquivo seja criptografado/descriptografado sem que o software tenha acesso à chave bruta. Nos kernels comuns do Android, essa interface corresponde à operação blk_crypto_ll_ops::keyslot_program, que precisa ser implementada pelo driver de armazenamento.
• Uma interface para derivar e retornar sw_secret, ou seja, segredo" também chamado de "segredo bruto", em alguns lugares), que é a chave O Linux usa para derivar subchaves para tudo, menos o conteúdo do arquivo criptografia. Nos kernels comuns do Android, essa interface corresponde à operação blk_crypto_ll_ops::derive_sw_secret, que precisa ser implementada pelo driver de armazenamento.

Para derivar inline_encryption_key e sw_secret da chave de armazenamento bruta, o hardware precisa usar um KDF com criptografia forte. Esse KDF precisa seguir as práticas recomendadas de criptografia. Ele precisa ter uma força de segurança de pelo menos 256 bits, o suficiente para qualquer algoritmo usado mais tarde. Ele também precisa usar identificador distinto, contexto e informações específicas do app quando derivando cada tipo de subchave para garantir que as subchaves resultantes são criptograficamente isolados, ou seja, o conhecimento de um deles não revela nenhuma entre si. O alongamento de chave não é necessário, porque a chave de armazenamento bruta já é uma chave uniformemente aleatória.

Tecnicamente, qualquer KDF que atenda aos requisitos de segurança pode ser usado. No entanto, para fins de teste, é necessário implementar novamente o mesmo KDF no código de teste. Atualmente, uma KDF foi analisada e implementada. ele pode ser encontrado no código-fonte de vts_kernel_encryption_test. Recomendamos que o hardware use essa KDF, que usa NIST SP 800-108 "KDF em modo de contador" com AES-256-CMAC como PRF. Para ser compatível, todos partes do algoritmo precisam ser idênticas, incluindo a escolha dos contextos de KDF e rótulos para cada subchave.

Encapsulamento de chaves

Para atender aos objetivos de segurança das chaves protegidas por hardware, dois tipos de chaves protegidas são definidos:

• Encapsulamento efêmero: o hardware criptografa a chave bruta usando uma chave. gerado aleatoriamente a cada inicialização e não é exposto diretamente fora do hardware.
• Envolvimento de longo prazo: o hardware criptografa a chave bruta usando uma chave exclusiva e persistente integrada ao hardware que não é diretamente exposta fora dele.

Todas as chaves transmitidas ao kernel do Linux para desbloquear o armazenamento são encapsuladas de forma temporária. Isso garante que, se um invasor for capaz de extrair uma em uso da memória do sistema, ela será inutilizável fora do dispositivo, mas também no dispositivo após a reinicialização.

Ao mesmo tempo, o Android ainda precisa armazenar uma versão criptografada das chaves no disco para que elas possam ser desbloqueadas. O material bruto funcionam para essa finalidade. No entanto, é recomendável que as chaves brutas nunca estejam presentes na memória do sistema para que nunca possam ser extraídas para uso fora do dispositivo, mesmo que sejam extraídas durante a inicialização. Por isso, o conceito de encapsulamento de longo prazo.

Observação:todas as chaves de criptografia de armazenamento armazenadas pelo Android. em disco são protegidas por uma camada separada de encapsulamento de chaves que une as desbloquear a chave para o estado da Inicialização verificada do dispositivo, bem como para o estado Fator de conhecimento da tela de bloqueio (por exemplo, PIN), quando aplicável. Essa camada de chaves é independente do chaveamento de chaves de longo prazo discutido acima. Portanto, quando as chaves encapsuladas em hardware estão em uso, as chaves armazenadas pelo Android no disco é encapsulada duas vezes: uma com a chave de longo prazo do hardware e novamente com o encapsulamento de chaves padrão do Android.

Para oferecer suporte ao gerenciamento de chaves agrupadas de duas maneiras diferentes, o hardware precisa implementar as seguintes interfaces:

• Interfaces para gerar e importar chaves de armazenamento, retornando-as em formato encapsulado de longo prazo. Essas interfaces são acessadas indiretamente pelo KeyMint e correspondem à tag TAG_STORAGE_KEY do KeyMint. A capacidade "gerar" é usada por vold para gerar novas chaves de armazenamento para uso pelo Android, enquanto a capacidade "importar" é usada por vts_kernel_encryption_test para importar chaves de teste.
• Uma interface para converter uma chave de armazenamento encapsulada de longo prazo em uma de armazenamento temporário. Isso corresponde ao método KeyMint convertStorageKeyToEphemeral. Esse método é usado por vold e vts_kernel_encryption_test para para liberar o armazenamento.

O algoritmo de agrupamento de chaves é um detalhe de implementação, mas precisa usar um AEAD forte, como AES-256-GCM com IVs aleatórios.

Mudanças necessárias no software

O AOSP já tem uma estrutura básica para oferecer suporte a chaves encapsuladas em hardware. Isso inclui o suporte em componentes do espaço do usuário, como vold, bem como como o suporte ao kernel do Linux em blk-crypto, fscrypt e dm-default-key.

No entanto, são necessárias algumas mudanças específicas da implementação.

Mudanças no KeyMint

A implementação do KeyMint do dispositivo precisa ser modificada para oferecer suporte a TAG_STORAGE_KEY e implementar o método convertStorageKeyToEphemeral.

No Keymaster, exportKey era usado em vez de convertStorageKeyToEphemeral.

Mudanças no kernel do Linux

O driver do kernel do Linux para o mecanismo de criptografia inline do dispositivo precisa ser modificado para oferecer suporte a chaves envoltas em hardware.

Para kernels android14 e mais recentes, defina BLK_CRYPTO_KEY_TYPE_HW_WRAPPED em blk_crypto_profile::key_types_supported, faça com que blk_crypto_ll_ops::keyslot_program e blk_crypto_ll_ops::keyslot_evict ofereçam suporte à programação/remoção de chaves envoltas em hardware e implemente blk_crypto_ll_ops::derive_sw_secret.

Para kernels android12 e android13, defina BLK_CRYPTO_FEATURE_WRAPPED_KEYS em blk_keyslot_manager::features, faça com que blk_ksm_ll_ops::keyslot_program e blk_ksm_ll_ops::keyslot_evict ofereçam suporte à programação/remoção de chaves envoltas em hardware e implemente blk_ksm_ll_ops::derive_raw_secret.

Para kernels android11, defina BLK_CRYPTO_FEATURE_WRAPPED_KEYS em keyslot_manager::features, faça com que keyslot_mgmt_ll_ops::keyslot_program e keyslot_mgmt_ll_ops::keyslot_evict ofereçam suporte à programação/remoção de chaves envoltas em hardware e implemente keyslot_mgmt_ll_ops::derive_raw_secret.

Teste

Embora a criptografia com chaves encapsuladas em hardware seja mais difícil de testar do que a criptografia com chaves padrão, ainda é possível testar importando uma chave de teste e reimplementando a derivação de chaves feita pelo hardware. Isso foi implementado em vts_kernel_encryption_test. Para executar esse teste, execute:

atest -v vts_kernel_encryption_test

Leia o registro do teste e verifique se os casos de teste de chave encapsulados por hardware (por exemplo, FBEPolicyTest.TestAesInlineCryptOptimizedHwWrappedKeyPolicy e DmDefaultKeyTest.TestHwWrappedKey) não foram ignoradas devido ao suporte para chaves encapsuladas por hardware não serem detectadas, já que os resultados do teste ainda são "aprovado" nesse caso.

Observação:para que esses casos de teste sejam aprovados, a derivação de chave feita pelo hardware precisam corresponder exatamente ao esperado pelo teste. Além disso, o uso de AES-256-XTS pelo mecanismo de criptografia inline precisa ser correto. Ou seja, cada bloco de dados criptografados no disco precisa ser criptografado usando a chave e o IV (vetor de inicialização) esperados, incluindo o uso do endian correto para a chave e o IV, além do valor de incremento correto de um bloco para o próximo.

Se o hardware usar um KDF diferente (não recomendado), altere o teste para dar suporte aos wis do KDF necessários.

Ativar chaves

Quando o suporte à chave de hardware do dispositivo estiver funcionando corretamente, você poderá fazer as seguintes mudanças no arquivo fstab do dispositivo para que o Android o use para criptografia de chaves de hardware e de metadados:

• FBE: adicione a flag wrappedkey_v0 ao parâmetro fileencryption. Por exemplo, use fileencryption=::inlinecrypt_optimized+wrappedkey_v0. Para mais detalhes, consulte a documentação do FBE.
• Criptografia de metadados: adicione a sinalização wrappedkey_v0 ao parâmetro metadata_encryption. Por exemplo, use metadata_encryption=:wrappedkey_v0. Para mais detalhes, consulte a metadados de criptografia de dados.

Observação:as chaves encapsuladas em hardware só podem ser usadas em e não no armazenamento adotável.