O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Criptografia de Metadados

O Android 7.0 e superior oferece suporte à criptografia baseada em arquivo (FBE). O FBE permite que arquivos diferentes sejam criptografados com chaves diferentes que podem ser desbloqueadas independentemente. Essas chaves são usadas para criptografar o conteúdo e os nomes dos arquivos. Quando o FBE é usado, outras informações, como layouts de diretório, tamanhos de arquivo, permissões e horários de criação / modificação, não são criptografadas. Coletivamente, essas outras informações são conhecidas como metadados do sistema de arquivos.

O Android 9 introduziu suporte para criptografia de metadados. Com a criptografia de metadados, uma única chave presente no momento da inicialização criptografa qualquer conteúdo não criptografado pelo FBE. Esta chave é protegida pelo Keymaster, que por sua vez é protegido pela inicialização verificada.

A criptografia de metadados está sempre ativada no armazenamento adotável sempre que o FBE está ativado. A criptografia de metadados também pode ser ativada no armazenamento interno.

Implementação em armazenamento interno

Você pode configurar a criptografia de metadados no armazenamento interno de novos dispositivos configurando o sistema de arquivos de metadata , alterando a sequência init e habilitando a criptografia de metadados no arquivo fstab do dispositivo.

Pré-requisitos

A criptografia de metadados só pode ser configurada quando a partição de dados é formatada pela primeira vez. Como resultado, esse recurso é apenas para novos dispositivos; isso não é algo que uma OTA deva mudar.

A criptografia de metadados requer que o módulo dm-default-key seja habilitado em seu kernel. No Android 11 e superior, dm-default-key é compatível com os kernels comuns do Android, versão 4.14 e superior. Esta versão do dm-default-key usa um hardware e uma estrutura de criptografia independente do fornecedor chamada blk-crypto .

Para habilitar dm-default-key , use:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
CONFIG_DM_DEFAULT_KEY=y

dm-default-key usa hardware de criptografia embutida (hardware que criptografa / descriptografa dados enquanto está a caminho de / para o dispositivo de armazenamento) quando disponível. Se você não for usar hardware de criptografia inline, também é necessário habilitar um fallback para a API de criptografia do kernel:

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

Quando não estiver usando hardware de criptografia em linha, você também deve habilitar qualquer aceleração baseada em CPU disponível, conforme recomendado na documentação do FBE .

No Android 10 e inferior, dm-default-key não era compatível com o kernel comum do Android. Portanto, cabia aos fornecedores implementar dm-default-key .

Configurar sistema de arquivos de metadados

Como nada na partição de dados do usuário pode ser lido até que a chave de criptografia de metadados esteja presente, a tabela de partição deve separar uma partição separada chamada "partição de metadados" para armazenar os blobs do mestre de chaves que protegem essa chave. A partição de metadados deve ter 16 MB.

fstab.hardware deve incluir uma entrada para o sistema de arquivos de metadados que reside nessa partição montando-o em /metadata , incluindo o sinalizador formattable para garantir que seja formatado no momento da inicialização. O sistema de arquivos f2fs não funciona em partições menores; recomendamos o uso do ext4. Por exemplo:

/dev/block/bootdevice/by-name/metadata              /metadata          ext4        noatime,nosuid,nodev,discard                          wait,check,formattable

Para garantir que o ponto de montagem /metadata exista, adicione a seguinte linha a BoardConfig-common.mk :

BOARD_USES_METADATA_PARTITION := true

Mudanças na sequência de inicialização

Quando a criptografia de metadados é usada, vold deve estar em execução antes que /data seja montado. Para garantir que ele seja iniciado cedo o suficiente, adicione a seguinte estrofe ao init.hardware.rc :

# We need vold early for metadata encryption
on early-fs
    start vold

O Keymaster deve estar rodando e pronto antes que o init tente montar /data .

init.hardware.rc já deve conter uma instrução mount_all que monta /data si mesma na estrofe on late-fs . Antes desta linha, adicione a diretiva para executar o serviço wait_for_keymaster :

on late-fs
   … 
    # Wait for keymaster
    exec_start wait_for_keymaster

    # Mount RW partitions which need run fsck
    mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late

Ativando a criptografia de metadados

Finalmente, adicione keydirectory=/metadata/vold/metadata_encryption à coluna fs_mgr_flags da entrada fstab para userdata . Por exemplo, uma linha fstab completa pode ser semelhante a:

/dev/block/bootdevice/by-name/userdata              /data              f2fs        noatime,nosuid,nodev,discard,inlinecrypt latemount,wait,check,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized,keydirectory=/metadata/vold/metadata_encryption,quota,formattable

Por padrão, o algoritmo de criptografia de metadados no armazenamento interno é AES-256-XTS. Isso pode ser substituído definindo a opção metadata_encryption , também na coluna fs_mgr_flags :

  • Em dispositivos sem aceleração AES, a criptografia Adiantum pode ser habilitada configurando metadata_encryption=adiantum .
  • Em dispositivos que oferecem suporte a chaves empacotadas por hardware que são provisionadas diretamente ao hardware de criptografia embutida, a chave de criptografia de metadados pode ser transformada por hardware configurando metadata_encryption=aes-256-xts:wrappedkey_v0 . Consulte a documentação do FBE para obter mais informações sobre chaves incorporadas por hardware e seus pré-requisitos.

Como a interface do kernel para dm-default-key mudou no Android 11, você também precisa se certificar de que definiu o valor correto para PRODUCT_SHIPPING_API_LEVEL em device.mk . Por exemplo, se o seu dispositivo iniciar com Android 11 (API de nível 30), device.mk deve conter:

PRODUCT_SHIPPING_API_LEVEL := 30

Você também pode definir a seguinte propriedade do sistema para forçar o uso da nova API dm-default-key independentemente do nível de envio da API:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.crypto.dm_default_key.options_format.version=2

Validação

Para verificar se a criptografia de metadados está habilitada e funcionando corretamente, execute os testes descritos a seguir. Também esteja atento aos problemas comuns descritos abaixo.

Testes

Comece executando o seguinte comando para verificar se a criptografia de metadados está ativada no armazenamento interno:

adb root
adb shell dmctl table userdata

A saída deve ser semelhante a:

Targets in the device-mapper table for userdata:
0-4194304: default-key, aes-xts-plain64 - 0 252:2 0 3 allow_discards sector_size:4096 iv_large_sectors

Se você substituir as configurações de criptografia padrão definindo a opção metadata_encryption no fstab do dispositivo, a saída será ligeiramente diferente da anterior. Por exemplo, se você habilitou a criptografia Adiantum , o terceiro campo será xchacha12,aes-adiantum-plain64 vez de aes-xts-plain64 .

Em seguida, execute vts_kernel_encryption_test para verificar a exatidão da criptografia de metadados e FBE:

atest vts_kernel_encryption_test

ou:

vts-tradefed run vts -m vts_kernel_encryption_test

Problemas comuns

Durante a chamada para mount_all , que monta a partição criptografada por metadados /data , o init executa a ferramenta vdc. A ferramenta vdc se conecta ao vold over binder para configurar o dispositivo criptografado por metadados e montar a partição. Durante esta chamada, o init é bloqueado e as tentativas de ler ou definir as propriedades do init serão bloqueadas até que o mount_all termine. Se, neste estágio, qualquer parte do trabalho de vold for bloqueada direta ou indiretamente na leitura ou definição de uma propriedade, ocorrerá um impasse. É importante garantir que vold possa completar o trabalho de leitura das chaves, interagir com o Keymaster e montar o diretório de dados sem interagir mais com o init .

Se o Keymaster não for totalmente iniciado quando o mount_all executado, ele não responderá a vold até que tenha lido certas propriedades do init , resultando exatamente no deadlock descrito. Colocar exec_start wait_for_keymaster acima da chamada mount_all relevante, conforme estabelecido, garante que o Keymaster esteja totalmente em execução antecipadamente e, portanto, evita esse impasse.

Configuração no armazenamento adotável

Desde o Android 9, uma forma de criptografia de metadados está sempre ativada no armazenamento adotável sempre que o FBE está ativado, mesmo quando a criptografia de metadados não está ativada no armazenamento interno.

No AOSP, há duas implementações de criptografia de metadados no armazenamento adotável: uma obsoleta baseada em dm-crypt e uma mais recente baseada em dm-default-key . Para garantir que a implementação correta seja selecionada para seu dispositivo, certifique-se de ter definido o valor correto para PRODUCT_SHIPPING_API_LEVEL em device.mk . Por exemplo, se o seu dispositivo iniciar com Android 11 (API de nível 30), device.mk deve conter:

PRODUCT_SHIPPING_API_LEVEL := 30

Você também pode definir as seguintes propriedades do sistema para forçar o uso do novo método de criptografia de metadados de volume (e a nova versão da política FBE padrão), independentemente do nível de envio da API:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.crypto.volume.metadata.method=dm-default-key \
    ro.crypto.dm_default_key.options_format.version=2 \
    ro.crypto.volume.options=::v2

Método atual

Em dispositivos lançados com Android 11 ou superior, a criptografia de metadados no armazenamento adotável usa o módulo kernel dm-default-key , assim como no armazenamento interno. Veja os pré - requisitos acima para quais opções de configuração do kernel habilitar. Observe que o hardware de criptografia em linha que funciona no armazenamento interno do dispositivo pode não estar disponível no armazenamento adotável e, portanto, CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y pode ser necessário.

Por padrão, o método de criptografia de metadados de volume dm-default-key usa o algoritmo de criptografia AES-256-XTS com setores de criptografia de 4096 bytes. O algoritmo pode ser substituído definindo a propriedade de sistema ro.crypto.volume.metadata.encryption . O valor desta propriedade tem a mesma sintaxe da opção metadata_encryption fstab descrita acima. Por exemplo, em dispositivos sem aceleração AES, a criptografia Adiantum pode ser habilitada configurando ro.crypto.volume.metadata.encryption=adiantum .

Método legado

Em dispositivos lançados com Android 10 ou inferior, a criptografia de metadados no armazenamento adotável usa o módulo de kernel dm-crypt vez de dm-default-key :

CONFIG_DM_CRYPT=y

Ao contrário do método dm-default-key , o método dm-crypt faz com que o conteúdo do arquivo seja criptografado duas vezes: uma vez com uma chave FBE e outra com a chave de criptografia de metadados. Essa criptografia dupla reduz o desempenho e não é necessária para atingir os objetivos de segurança da criptografia de metadados, uma vez que o Android garante que as chaves FBE sejam pelo menos tão difíceis de comprometer quanto a chave de criptografia de metadados. Os fornecedores podem fazer personalizações de kernel para evitar a criptografia dupla, em particular implementando a opção allow_encrypt_override que o Android passará para dm-crypt quando a propriedade do sistema ro.crypto.allow_encrypt_override for definida como true . Essas personalizações não são suportadas pelo kernel comum do Android.

Por padrão, o método de criptografia de metadados de volume dm-crypt usa o algoritmo de criptografia AES-128-CBC com ESSIV e setores de criptografia de 512 bytes. Isso pode ser substituído definindo as seguintes propriedades do sistema (que também são usadas para FDE):

  • ro.crypto.fde_algorithm seleciona o algoritmo de criptografia de metadados. As opções são aes-128-cbc e adiantum . Adiantum pode ser usado apenas se o dispositivo não tiver aceleração AES.
  • ro.crypto.fde_sector_size seleciona o tamanho do setor de criptografia. As opções são 512, 1024, 2048 e 4096. Para criptografia Adiantum, use 4096.