O Android 7.0 e versões mais recentes têm suporte Criptografia baseada em arquivos (FBE, na sigla em inglês). AQ permite que arquivos diferentes sejam criptografados com chaves diferentes que podem ser desbloqueadas de forma independente. Essas chaves são usadas para criptografar o conteúdo e os nomes dos arquivos. Quando ela é usada, 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 criptografados. Coletivamente, essa outra informação é conhecida como metadados do sistema de arquivos.
O Android 9 introduziu suporte à criptografia de metadados. Com a criptografia de metadados, uma única chave presente na inicialização criptografa o conteúdo não é criptografado pela FBE. Essa chave é protegida pelo Keymaster, que, por sua vez é protegida pela Inicialização verificada.
A criptografia de metadados sempre será ativada no armazenamento adotável sempre que a FBE estiver ativada. A criptografia de metadados também pode ser ativada no armazenamento interno. Dispositivos lançados com o Android 11 ou versões mais recentes precisam ter criptografia de metadados ativado no armazenamento interno.
Implementação no armazenamento interno
Para configurar a criptografia de metadados no armazenamento interno de novos dispositivos, faça o seguinte:
configurar o sistema de arquivos metadata, mudar a sequência init 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 é a primeira formatado. Como resultado, esse recurso é apenas para dispositivos novos. isso não é algo que uma OTA deveria mudar.
A criptografia de metadados exige que o módulo dm-default-key seja
ativado em seu kernel. No Android 11 e versões mais recentes,
dm-default-key tem suporte dos kernels comuns do Android, versão
4.14 e superior. Esta versão do dm-default-key usa um hardware e
um framework de criptografia independente de fornecedor chamado blk-crypto.
Para ativar dm-default-key, use:
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y CONFIG_DM_DEFAULT_KEY=y
O dm-default-key usa hardware de criptografia inline (hardware que
criptografa/descriptografa dados enquanto estão a caminho do dispositivo de armazenamento) quando
disponíveis. Se você não vai usar hardware de criptografia inline, é
também é necessário para ativar um substituto para a API de criptografia do kernel:
CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
Quando não usar hardware de criptografia inline, você também deve ativar todos os Aceleração baseada em CPU, conforme recomendado na documentação da FBE.
No Android 10 e versões anteriores, dm-default-key
não tinha suporte do kernel comum do Android. Portanto, dependiam dos fornecedores
para implementar dm-default-key.
Configurar o sistema de arquivos de metadados
Como nada na partição de dados do usuário pode ser lido até que os metadados chave de criptografia estiver presente, a tabela de partições deve reservar uma chamada "partição de metadados" para armazenar os blobs keymaster que proteger essa chave. A partição de metadados precisa ter 16 MB.
fstab.hardware precisa incluir uma entrada para o sistema de arquivos de metadados
que reside nessa partição e a monta em /metadata, incluindo
a flag formattable para garantir que ela seja formatada no momento da inicialização. A
O sistema de arquivos f2fs não funciona em partições menores. recomendamos usar ext4
como alternativa. 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 linha a seguir
para BoardConfig-common.mk:
BOARD_USES_METADATA_PARTITION := true
Mudanças na sequência de inicialização
Quando a criptografia de metadados é usada, o vold precisa estar em execução antes de
/data foi montado. Para garantir que ela comece cedo o suficiente, adicione
a seguinte estrofe em init.hardware.rc:
# We need vold early for metadata encryption on early-fs start vold
O Keymaster precisa estar em execução e pronto antes que o init tente fazer a ativação
/data:
init.hardware.rc já precisa conter um mount_all
que monta /data na estrofe on
late-fs. Antes desta linha, adicione a diretiva para executar a
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
Como ativar a criptografia de metadados
Por fim, adicione keydirectory=/metadata/vold/metadata_encryption ao
coluna fs_mgr_flags da entrada fstab para
userdata. Por exemplo, uma linha fstab completa pode ter esta aparência:
/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 pela configuração
a opção metadata_encryption, também na
coluna fs_mgr_flags:
- Em dispositivos que não têm aceleração AES, a criptografia Adiantum pode ser
ativado pela configuração
metadata_encryption=adiantum. - Em dispositivos compatíveis com chaves encapsuladas por hardware:
a chave de criptografia de metadados pode ser encapsulada por hardware ao definir
metadata_encryption=aes-256-xts:wrappedkey_v0(ou equivalente,metadata_encryption=:wrappedkey_v0, conformeaes-256-xtsé o algoritmo padrão).
Como a interface do kernel para dm-default-key mudou no Android
11, você também precisa definir o
valor correto para PRODUCT_SHIPPING_API_LEVEL em
device.mk Por exemplo, se o dispositivo for iniciado com o Android
11 (nível 30 da API), o device.mk precisa
contêm:
PRODUCT_SHIPPING_API_LEVEL := 30
Você também pode definir a seguinte propriedade do sistema para forçar o uso do novo
API dm-default-key, independentemente do nível da API de frete:
PRODUCT_PROPERTY_OVERRIDES += \
ro.crypto.dm_default_key.options_format.version=2
Validação
Para verificar se a criptografia de metadados está ativada e funcionando corretamente, execute o descritos abaixo. Esteja atento também aos comuns problemas descritos abaixo.
Testes
Comece executando o seguinte comando para verificar se a criptografia de metadados está ativado no armazenamento interno:
adb rootadb shell dmctl table userdata
A resposta precisa ser semelhante a esta:
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ê tiver substituído as configurações de criptografia padrão ao definir a
metadata_encryption no fstab do dispositivo. Em seguida,
a saída será um pouco diferente do mostrado acima. Por exemplo, se você ativou a criptografia Adiantum, a terceira
será xchacha12,aes-adiantum-plain64 em vez de
aes-xts-plain64.
Em seguida, execute vts_kernel_encryption_test para verificar a exatidão da criptografia de metadados e da 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 objeto criptografado pelos metadados
/data, init executa a ferramenta vdc. VDC
ferramenta se conecta a vold por binder para configurar o
e ativar a partição. Durante o período de
chamada, init é bloqueado e tenta ler ou definir
As propriedades de init serão bloqueadas até que mount_all seja concluída.
Se, nesta fase, qualquer parte do trabalho de vold for de forma direta ou
bloqueado indiretamente na leitura ou definição de uma propriedade, ocorrerá um impasse. É
é importante garantir que vold possa concluir o trabalho de leitura do
chaves, interagir com o Keymaster e ativar o diretório de dados sem
interagir mais com init.
Se o Keymaster não for totalmente iniciado quando o mount_all for executado, ele não
responder a vold até que ele tenha lido determinadas propriedades de
init, resultando no impasse descrito exatamente. Colocando
exec_start wait_for_keymaster acima do valor relevante
a invocação de mount_all, conforme estabelecido, garante que o Keymaster seja totalmente
em execução com antecedência
e evita esse impasse.
Configuração no armazenamento adotável
Desde o Android 9, uma forma de criptografia de metadados é sempre ativado no armazenamento adotável sempre que a FBE estiver ativada, mesmo quando a criptografia de metadados não estiver ativada armazenamento interno.
No AOSP, há duas implementações de criptografia de metadados em camadas
armazenamento: um descontinuado com base em dm-crypt e um mais recente baseado em
em dm-default-key. Para garantir que a implementação correta seja
selecionado para seu dispositivo, verifique se você definiu o valor correto para
PRODUCT_SHIPPING_API_LEVEL em device.mk. Por exemplo:
se o dispositivo for lançado com o Android 11 (nível 30 da API),
device.mk precisa 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 da API de frete:
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 o Android 11 ou mais recente,
a criptografia de metadados no armazenamento adotável usa o dm-default-key
módulo do kernel, assim como no armazenamento interno. Consulte os pré-requisitos acima para saber qual configuração do kernel
opções para ativar. Observe que o hardware de criptografia em linha que funciona
o 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 criptográficos de 4.096 bytes. A
algoritmo pode ser substituído pela configuração
ro.crypto.volume.metadata.encryption. Isso
o valor da propriedade tem a mesma sintaxe que a metadata_encryption
a opção fstab descrita acima. Por exemplo, em dispositivos que não têm o AES
aceleração, criptografia Adiantum
podem ser ativadas definindo
ro.crypto.volume.metadata.encryption=adiantum
Método legado
Em dispositivos lançados com o Android 10 ou versões anteriores, os metadados
a criptografia no armazenamento adotável usa o módulo do kernel dm-crypt.
em 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 com uma chave FBE e outra com
a chave de criptografia de metadados. Essa criptografia dupla reduz o desempenho e
para atingir as metas de segurança da criptografia de metadados, já que o Android
garante que as chaves FBE sejam pelo menos tão difíceis de comprometer quanto os metadados
chave de criptografia de dados. Os fornecedores podem personalizar o kernel para evitar a duplicação
a criptografia, especialmente com a implementação
Opção allow_encrypt_override que o Android vai transmitir
dm-crypt quando a propriedade do sistema
ro.crypto.allow_encrypt_override está definido como true.
Essas personalizações não têm suporte do 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
podem ser substituídas pela configuração das seguintes propriedades do sistema (que também são
usados para FDE):
ro.crypto.fde_algorithmseleciona a criptografia dos metadados algoritmo. As opções sãoaes-128-cbceadiantum. Adiantum só poderá ser usado se o dispositivo não tem aceleração AES.ro.crypto.fde_sector_sizeseleciona o tamanho do setor criptográfico. As opções são 512, 1024, 2048 e 4096. Para criptografia Adiantum, use 4096.