O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Criptografia de metadados

Android 7.0 e suportes mais elevados de criptografia baseado em arquivo (FBE). O FBE permite que diferentes arquivos sejam criptografados com diferentes chaves 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. Essa chave é protegida pelo Keymaster, que por sua vez é protegido pela inicialização verificada.

Criptografia de metadados está sempre ativada no armazenamento adoptáveis sempre FBE está habilitado. A criptografia de metadados também pode ser ativada no armazenamento interno. Dispositivos lançados com Android 11 ou superior devem ter a criptografia de metadados ativada no armazenamento interno.

Implementação em armazenamento interno

Você pode configurar a criptografia de metadados no armazenamento interno de novos dispositivos através da criação do metadata do sistema de arquivos, alterar a sequência de inicialização, e ativar 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.

Criptografia metadados exige que o dm-default-key módulo ser ativado em seu kernel. Em Android 11 e superior, dm-default-key é suportada pelos núcleos comuns do Android, versão 4.14 e superior. Esta versão do dm-default-key usa um hardware e estrutura de criptografia independente de fornecedor chamada preto-cripto.

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 usos em linha de hardware de criptografia (hardware que criptografa / descriptografa dados enquanto ele está a caminho de / para o dispositivo de armazenamento) quando disponível. Se você não estiver usando criptografia de hardware in-line, também é necessário para permitir um retorno para API de criptografia do kernel:

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

Quando não estiver usando criptografia de hardware in-line você também deve permitir a qualquer aceleração baseada em CPU disponível como recomendado na documentação FBE .

Em Android 10 e inferior, dm-default-key não foi apoiada pelo kernel comum Android. Foi, portanto, até fornecedores para 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 de "partição de metadados" para armazenar os blobs keymaster 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 vidas nessa partição montá-lo no /metadata , incluindo o formattable bandeira para garantir que ele é 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 a /metadata ponto de montagem existe, adicione a seguinte linha ao BoardConfig-common.mk :

BOARD_USES_METADATA_PARTITION := true

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

Quando a criptografia metadados é usado, vold deve ser executado antes de /data está montado. Para garantir que ele é iniciado cedo o suficiente, adicione o seguinte estrofe para init.hardware.rc :

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

Keymaster deve estar em execução e pronto antes de tentativas de inicialização para montar /data .

init.hardware.rc já deve conter uma mount_all instrução que monta /data se no on late-fs estrofe. Antes desta linha, adicione a directiva para exec o wait_for_keymaster serviço:

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

Por fim, adicione keydirectory=/metadata/vold/metadata_encryption à coluna fs_mgr_flags do fstab entrada 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 o metadata_encryption opção, também na coluna fs_mgr_flags:

  • Nos dispositivos que carecem de aceleração AES, criptografia Adiantum pode ser activado definindo metadata_encryption=adiantum .
  • Em dispositivos que suportam chaves envolto em hardware , a chave de criptografia de metadados pode ser feita ajustando-embrulhado hardware metadata_encryption=aes-256-xts:wrappedkey_v0 (ou equivalentemente metadata_encryption=:wrappedkey_v0 , como aes-256-xts é o algoritmo padrão).

Como a interface do kernel para dm-default-key mudou em Android 11, você também precisa garantir que você tenha definido o valor correto para PRODUCT_SHIPPING_API_LEVEL em device.mk . Por exemplo, se os seus lançamentos de dispositivos com Android 11 (nível API 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 do novo dm-default-key API, independentemente do transporte nível 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 estar ciente dos 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ê cancelou as configurações de criptografia padrão, definindo o metadata_encryption opção no dispositivo fstab , então a saída será um pouco diferente do anterior. Por exemplo, se você ativou a criptografia Adiantum , em seguida, o terceiro campo será xchacha12,aes-adiantum-plain64 vez de aes-xts-plain64 .

Em seguida, execute vts_kernel_encryption_test para verificar a regularidade de 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 o criptografado por metadados /data de partição, init executa a ferramenta VDC. Os Ligações ferramenta VDC para vold sobre binder para configurar o dispositivo encriptado-metadados e montar a partição. Para a duração desta chamada, init é bloqueado, e as tentativas de leitura ou conjunto init propriedades irá bloquear até mount_all acabamentos. Se, nesta fase, qualquer parte do vold trabalho 's está diretamente ou indiretamente bloqueado em lendo ou definir uma propriedade, o impasse vai resultar. É importante assegurar que vold pode completar o trabalho de ler as chaves, interagindo com Keymaster, e montar o diretório de dados sem interagir ainda mais com init .

Se Keymaster não é totalmente começou quando mount_all for executado, ele não responder a vold até que tenha lido certas propriedades de init , resultando em exatamente o impasse descrito. Colocar exec_start wait_for_keymaster acima do relevante mount_all invocação como definidos garante que Keymaster está funcionando plenamente com antecedência e assim evita esse impasse.

Configuração no armazenamento adotável

Desde Android 9, uma forma de criptografia de metadados está sempre ativada no armazenamento adoptáveis sempre FBE está habilitado, mesmo quando a criptografia de metadados não está habilitado no armazenamento interno.

Em AOSP, existem duas implementações de criptografia de metadados no armazenamento adoptáveis: um obsoleto baseado em dm-crypt , e uma mais recente baseado em dm-default-key . Para garantir que a implementação correcta está seleccionada para o dispositivo, verifique se você definiu o valor correto para PRODUCT_SHIPPING_API_LEVEL em device.mk . Por exemplo, se os seus lançamentos de dispositivos com Android 11 (nível API 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 de lançamento com Android 11 ou superior, criptografia de metadados no armazenamento adoptáveis usa o dm-default-key módulo do kernel, assim como no armazenamento interno. Veja os pré-requisitos acima para o qual as opções de configuração do kernel para permitir. Note-se que o hardware de encriptação em linha que funciona em armazenamento interno do dispositivo pode não estar disponível no armazenamento adoptáveis, e assim CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y pode ser necessária.

Por padrão, o dm-default-key método de criptografia metadados do volume usa o algoritmo de criptografia AES-256-XTS com os setores de criptografia de 4096 bytes. O algoritmo pode ser substituída, definindo o ro.crypto.volume.metadata.encryption propriedade do sistema. Valor deste imóvel tem a mesma sintaxe do metadata_encryption opção fstab descrito acima. Por exemplo, em dispositivos que carecem de aceleração AES, criptografia Adiantum pode ser activado definindo ro.crypto.volume.metadata.encryption=adiantum .

Método legado

Em dispositivos de lançamento com Android 10 ou inferior, criptografia de metadados no armazenamento adoptáveis usa o dm-crypt módulo do kernel em vez de dm-default-key :

CONFIG_DM_CRYPT=y

Ao contrário do dm-default-key método, o dm-crypt método faz com que o conteúdo do arquivo a ser criptografada duas vezes: uma vez com uma chave de FBE e uma vez 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. Fornecedores podem fazer personalizações do kernel para evitar a criptografia dupla, em especial implementando o allow_encrypt_override opção que Android vai passar para dm-crypt , quando a propriedade do sistema ro.crypto.allow_encrypt_override está definido como true . Essas personalizações não são suportadas pelo kernel comum do Android.

Por defeito, o dm-crypt método de encriptação metadados do volume usa o algoritmo de criptografia AES-128-CBC com essiv e sectores de cifra 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 só pode ser utilizado se o dispositivo carece de aceleração AES.
  • ro.crypto.fde_sector_size selecciona o tamanho do sector cripto. As opções são 512, 1024, 2048 e 4096. Para criptografia Adiantum, use 4096.