O Android 7.0 e versões mais recentes oferecem suporte à criptografia baseada em arquivos (FBE, na sigla em inglês). A criptografia baseada em arquivos permite que arquivos diferentes sejam criptografados com chaves diferentes que podem ser desbloqueadas de forma independente.
Este artigo descreve como ativar a criptografia baseada em arquivos em novos dispositivos e como os apps do sistema podem usar as APIs de inicialização direta para oferecer aos usuários a melhor e mais segura experiência possível.
Todos os dispositivos lançados com o Android 10 e versões mais recentes precisam usar a criptografia baseada em arquivos.
Inicialização direta
A criptografia baseada em arquivos permite um novo recurso introduzido no Android 7.0 chamado Inicialização direta. Com a inicialização direta, os dispositivos criptografados podem inicializar direto na tela de bloqueio. Antes, em dispositivos criptografados usando criptografia de disco completo (FDE, na sigla em inglês), os usuários precisavam fornecer credenciais antes que qualquer dado pudesse ser acessado, impedindo que o smartphone realizasse todas as operações, exceto as mais básicas. Por exemplo, os alarmes não funcionavam, os serviços de acessibilidade estavam indisponíveis, e os smartphones não podiam receber ligações, mas eram limitados apenas a operações básicas de discagem de emergência.
Com a introdução da criptografia baseada em arquivos (FBE) e novas APIs para tornar os apps conscientes da criptografia, é possível que esses apps operem em um contexto limitado. Isso pode acontecer antes que os usuários forneçam as credenciais, mas ainda protegendo as informações privadas.
Em um dispositivo com FBE, cada usuário tem dois locais de armazenamento disponíveis para apps:
- O armazenamento criptografado por credenciais (CE, na sigla em inglês), que é o local de armazenamento padrão e só fica disponível depois que o usuário desbloqueia o dispositivo.
- O armazenamento criptografado pelo dispositivo (DE, na sigla em inglês), que é um local de armazenamento disponível durante o modo de inicialização direta e depois que o usuário desbloqueia o dispositivo.
Essa separação torna os perfis de trabalho mais seguros porque permite que mais de um usuário seja protegido por vez, já que a criptografia não se baseia apenas em uma senha de inicialização.
A API Direct Boot permite que apps com reconhecimento de criptografia acessem cada uma dessas áreas. Há mudanças no ciclo de vida do app para atender à necessidade de notificar os apps quando o armazenamento de CE de um usuário é desbloqueado em resposta à primeira inserção de credenciais na tela de bloqueio ou, no caso do perfil de trabalho, fornecendo um desafio de trabalho. Os dispositivos com Android 7.0 precisam oferecer suporte a essas novas APIs e ciclos de vida, implementem ou não a criptografia baseada em arquivos. No entanto, sem FBE, o armazenamento de DE e CE está sempre no estado desbloqueado.
Uma implementação completa da criptografia baseada em arquivos nos sistemas de arquivos Ext4 e F2FS é fornecida no Android Open Source Project (AOSP) e só precisa ser ativada em dispositivos que atendem aos requisitos. Os fabricantes que optarem por usar a FBE podem explorar maneiras de otimizar o recurso com base no system on a chip (SoC) usado.
Todos os pacotes necessários no AOSP foram atualizados para reconhecer a inicialização direta. No entanto, quando os fabricantes de dispositivos usam versões personalizadas desses apps, eles querem garantir que, no mínimo, haja pacotes compatíveis com inicialização direta que ofereçam os seguintes serviços:
- Serviços de telefonia e discador
- Método de entrada para inserir senhas na tela de bloqueio
Exemplos e origem
O Android oferece uma implementação de referência da criptografia baseada em arquivos, em que o vold (system/vold) fornece a funcionalidade para gerenciar dispositivos e volumes de armazenamento no Android. A adição do FBE fornece ao vold vários comandos novos para oferecer suporte ao gerenciamento de chaves para as chaves CE e DE de vários usuários. Além das mudanças principais para usar os recursos de criptografia baseada em arquivos no kernel, muitos pacotes do sistema, incluindo a tela de bloqueio e a SystemUI, foram modificados para oferecer suporte aos recursos de FBE e inicialização direta. São eles:
- Discador do AOSP (packages/apps/Dialer)
- Relógio de mesa (packages/apps/DeskClock)
- LatinIME (packages/inputmethods/LatinIME)*
- App Configurações (packages/apps/Settings)*
- SystemUI (frameworks/base/packages/SystemUI)*
* Apps do sistema que usam o atributo defaultToDeviceProtectedStorage
do manifesto
Para mais exemplos de apps e serviços compatíveis com criptografia, execute o comando mangrep directBootAware
no diretório de frameworks ou pacotes da árvore de origem do AOSP.
Dependências
Para usar a implementação do FBE no AOSP com segurança, um dispositivo precisa atender às seguintes dependências:
- Suporte do kernel para criptografia Ext4 ou F2FS.
- Suporte do KeyMint (ou Keymaster 1.0 ou mais recente). Não há suporte para Keymaster 0.3, já que ele não oferece os recursos necessários nem garante proteção suficiente para chaves de criptografia.
- O KeyMint/Keymaster e o Gatekeeper precisam ser implementados em um ambiente de execução confiável (TEE) para proteger as chaves de criptografia de dados (DE) para que um SO não autorizado (SO personalizado instalado no dispositivo) não possa simplesmente solicitar as chaves de DE.
- A raiz de confiança de hardware e a Inicialização verificada vinculadas à inicialização do KeyMint são necessárias para garantir que as chaves de criptografia de disco não sejam acessíveis por um sistema operacional não autorizado.
Implementação
Primeiro, apps como despertadores, telefone e recursos de acessibilidade precisam ser android:directBootAware de acordo com a documentação para desenvolvedores do Direct Boot.
Suporte do kernel
O suporte do kernel para criptografia Ext4 e F2FS está disponível nos kernels comuns do Android, versão 3.18 e mais recentes. Para ativar em um kernel da versão 5.1 ou mais recente, use:
CONFIG_FS_ENCRYPTION=y
Para kernels mais antigos, use CONFIG_EXT4_ENCRYPTION=y
se o sistema de arquivos userdata
do dispositivo for Ext4 ou use CONFIG_F2FS_FS_ENCRYPTION=y
se o sistema de arquivos userdata
do dispositivo for F2FS.
Se o dispositivo for compatível com armazenamento adaptável ou usar criptografia de metadados no armazenamento interno, ative também as opções de configuração do kernel necessárias para a criptografia de metadados, conforme descrito na documentação sobre criptografia de metadados.
Além do suporte funcional para criptografia Ext4 ou F2FS, os fabricantes de dispositivos também precisam ativar a aceleração criptográfica para acelerar a criptografia baseada em arquivos e melhorar a experiência do usuário. Por exemplo, em dispositivos baseados em ARM64, a aceleração ARMv8 CE (extensões de criptografia) pode ser ativada definindo as seguintes opções de configuração do kernel:
CONFIG_CRYPTO_AES_ARM64_CE_BLK=y CONFIG_CRYPTO_SHA2_ARM64_CE=y
Para melhorar ainda mais o desempenho e reduzir o consumo de energia, os fabricantes de dispositivos também podem implementar hardware de criptografia inline, que criptografa/descriptografa os dados enquanto eles estão a caminho do/para o dispositivo de armazenamento. Os kernels comuns do Android (versão 4.14 e mais recentes) contêm um framework que permite o uso da criptografia inline quando há suporte de hardware e driver do fornecedor. O framework de criptografia inline pode ser ativado definindo as seguintes opções de configuração do kernel:
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
Se o dispositivo usar armazenamento baseado em UFS, ative também:
CONFIG_SCSI_UFS_CRYPTO=y
Se o dispositivo usar armazenamento baseado em eMMC, ative também:
CONFIG_MMC_CRYPTO=y
Ativar a criptografia baseada em arquivos
Para ativar a FBE em um dispositivo, é necessário ativá-la no armazenamento interno
(userdata
). Isso também ativa automaticamente a FBE no armazenamento
adaptável. No entanto, o formato de criptografia no armazenamento adaptável pode ser substituído
se necessário.
Armazenamento interno
Para ativar a FBE, adicione a opção
fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]]
à coluna fs_mgr_flags da linha fstab
para
userdata
. Essa opção define o formato de criptografia no armazenamento
interno. Ele contém até três parâmetros separados por dois-pontos:
- O parâmetro
contents_encryption_mode
define qual algoritmo criptográfico é usado para criptografar o conteúdo do arquivo. Pode seraes-256-xts
ouadiantum
. Desde o Android 11, ele também pode ser deixado em branco para especificar o algoritmo padrão, que éaes-256-xts
. - O parâmetro
filenames_encryption_mode
define qual algoritmo criptográfico é usado para criptografar nomes de arquivos. Pode seraes-256-cts
,aes-256-heh
,adiantum
ouaes-256-hctr2
. Se não for especificado, o padrão seráaes-256-cts
secontents_encryption_mode
foraes-256-xts
ouadiantum
secontents_encryption_mode
foradiantum
. - O parâmetro
flags
, novo no Android 11, é uma lista de flags separadas pelo caractere+
. As seguintes flags são compatíveis:- A flag
v1
seleciona políticas de criptografia da versão 1, e a flagv2
seleciona políticas de criptografia da versão 2. As políticas de criptografia da versão 2 usam uma função de derivação de chave mais segura e flexível. O padrão é v2 se o dispositivo foi lançado no Android 11 ou mais recente (conforme determinado porro.product.first_api_level
) ou v1 se o dispositivo foi lançado no Android 10 ou anterior. - A flag
inlinecrypt_optimized
seleciona um formato de criptografia otimizado para hardware de criptografia inline que não processa um grande número de chaves com eficiência. Isso é feito derivando apenas uma chave de criptografia de conteúdo de arquivo por chave de CE ou DE, em vez de uma por arquivo. A geração de IVs (vetores de inicialização) é ajustada de acordo. - A flag
emmc_optimized
é semelhante ainlinecrypt_optimized
, mas também seleciona um método de geração de IVs que limita os IVs a 32 bits. Essa flag só deve ser usada em hardware de criptografia inline compatível com a especificação JEDEC eMMC v5.2 e, portanto, compatível apenas com IVs de 32 bits. Em outros hardwares de criptografia inline, useinlinecrypt_optimized
. Essa flag nunca deve ser usada em armazenamento baseado em UFS. A especificação UFS permite o uso de IVs de 64 bits. - Em dispositivos que oferecem suporte a chaves
encapsuladas em hardware, a flag
wrappedkey_v0
permite o uso de chaves encapsuladas em hardware para FBE. Isso só pode ser usado em combinação com a opção de montageminlinecrypt
e a flaginlinecrypt_optimized
ouemmc_optimized
. - A flag
dusize_4k
força o tamanho da unidade de dados de criptografia a ser de 4.096 bytes, mesmo quando o tamanho do bloco do sistema de arquivos não é de 4.096 bytes. O tamanho da unidade de dados de criptografia é a granularidade da criptografia de conteúdo do arquivo. Essa flag está disponível desde o Android 15. Essa flag só deve ser usada para ativar o uso de hardware de criptografia inline que não aceita unidades de dados maiores que 4.096 bytes em um dispositivo que usa um tamanho de página maior que 4.096 bytes e que usa o sistema de arquivos f2fs.
- A flag
Se você não estiver usando hardware de criptografia inline, a configuração recomendada para a maioria dos dispositivos é fileencryption=aes-256-xts
. Se você estiver usando hardware de criptografia inline, a configuração recomendada para a maioria dos dispositivos é fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized
(ou fileencryption=::inlinecrypt_optimized
). Em dispositivos sem qualquer forma de aceleração AES, é possível usar Adiantum em vez de AES definindo fileencryption=adiantum
.
Desde o Android 14, o AES-HCTR2 é o modo preferido de criptografia de nomes de arquivos
para dispositivos com instruções de criptografia acelerada. No entanto, apenas os kernels mais recentes do Android oferecem suporte a AES-HCTR2. Em uma versão futura do Android, esse modo será o padrão para criptografia de nomes de arquivos. Se o kernel tiver suporte para AES-HCTR2, ele poderá ser ativado para criptografia de nomes de arquivos
definindo filenames_encryption_mode
como aes-256-hctr2
. No caso mais simples, isso seria feito com fileencryption=aes-256-xts:aes-256-hctr2
.
Em dispositivos lançados com o Android 10 e versões anteriores, fileencryption=ice
também é aceito para especificar o uso do modo de criptografia de conteúdo de arquivo FSCRYPT_MODE_PRIVATE
. Esse modo não é implementado pelos kernels comuns do Android, mas pode ser implementado por fornecedores usando patches de kernel personalizados. O formato no disco produzido por esse modo
era específico do fornecedor. Em dispositivos lançados com o Android
11 ou versões mais recentes, esse modo não é mais permitido, e um
formato de criptografia padrão precisa ser usado.
Por padrão, a criptografia do conteúdo do arquivo é feita usando a API de criptografia do kernel do Linux. Se você quiser usar hardware de criptografia inline, adicione também a opção de montagem inlinecrypt
. Por exemplo, uma linha completa de fstab
pode ter esta aparência:
/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized
Armazenamento adotável
Desde o Android 9, o FBE e o armazenamento adaptável podem ser usados juntos.
Especificar a opção fileencryption
fstab para
userdata
também ativa automaticamente a FBE e a criptografia de metadados no armazenamento
adotável. No entanto, é possível substituir os formatos de criptografia de metadados ou FBE no
armazenamento adaptável definindo propriedades em
PRODUCT_PROPERTY_OVERRIDES
.
Em dispositivos lançados com o Android 11 ou versões mais recentes, use as seguintes propriedades:
ro.crypto.volume.options
(novo no Android 11) seleciona o formato de criptografia FBE no armazenamento adotável. Ele tem a mesma sintaxe do argumento da opçãofileencryption
fstab e usa os mesmos padrões. Consulte as recomendações parafileencryption
acima para saber o que usar aqui.- O
ro.crypto.volume.metadata.encryption
seleciona o formato de criptografia de metadados no armazenamento adotável. Consulte a documentação sobre criptografia de metadados.
Em dispositivos lançados com o Android 10 e versões anteriores, use as seguintes propriedades:
ro.crypto.volume.contents_mode
seleciona o modo de criptografia de conteúdo. É equivalente ao primeiro campo separado por dois-pontos dero.crypto.volume.options
.ro.crypto.volume.filenames_mode
seleciona o modo de criptografia de nomes de arquivos. Isso é equivalente ao segundo campo separado por dois-pontos dero.crypto.volume.options
, exceto que o padrão em dispositivos lançados com o Android 10 e versões anteriores éaes-256-heh
. Na maioria dos dispositivos, isso precisa ser substituído explicitamente poraes-256-cts
.ro.crypto.fde_algorithm
ero.crypto.fde_sector_size
selecione o formato de criptografia de metadados no armazenamento adotável. Consulte a documentação sobre criptografia de metadados.
Integrar com o KeyMint
A HAL do KeyMint precisa ser iniciada como parte da classe early_hal
.
Isso ocorre porque o FBE exige que o KeyMint esteja pronto para processar solicitações na
fase de inicialização post-fs-data
, que é quando o vold
configura
as chaves iniciais.
Excluir diretórios
O init
aplica a chave DE do sistema a todos os diretórios de nível superior do /data
, exceto aqueles que precisam estar sem criptografia, como o diretório que contém a própria chave DE do sistema e os diretórios que contêm diretórios CE ou DE do usuário. As chaves de criptografia são aplicadas de forma recursiva e não podem ser substituídas por subdiretórios.
No Android 11 e versões mais recentes, a chave que
init
se aplica a diretórios pode ser controlada pelo
argumento encryption=<action>
do comando mkdir
em scripts de inicialização. Os valores possíveis de <action>
estão documentados no README da linguagem de inicialização do Android.
No Android 10, as ações de criptografia init
foram fixadas no seguinte local:
/system/extras/libfscrypt/fscrypt_init_extensions.cpp
No Android 9 e em versões anteriores, o local era:
/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp
É possível adicionar exceções para impedir que determinados diretórios sejam criptografados. Se forem feitas modificações desse tipo, o fabricante do dispositivo precisará incluir políticas do SELinux que concedam acesso apenas aos apps que precisam usar o diretório não criptografado. Isso exclui todos os apps não confiáveis.
O único caso de uso aceitável conhecido é para oferecer suporte a recursos legados de OTA.
Suporte à inicialização direta em apps do sistema
Fazer com que os apps reconheçam a inicialização direta
Para facilitar a migração rápida de apps do sistema, há dois novos atributos que podem ser definidos no nível do app. O atributo
defaultToDeviceProtectedStorage
está disponível apenas para
apps do sistema. O atributo directBootAware
está disponível para todos.
<application android:directBootAware="true" android:defaultToDeviceProtectedStorage="true">
O atributo directBootAware
no nível do app é uma abreviação para marcar
todos os componentes do app como tendo reconhecimento de criptografia.
O atributo defaultToDeviceProtectedStorage
redireciona o local de armazenamento padrão
do app para apontar para o armazenamento DE em vez de CE.
Os apps do sistema que usam essa flag precisam auditar cuidadosamente todos os dados armazenados no local padrão e mudar os caminhos de dados sensíveis para usar o armazenamento CE. Os fabricantes de dispositivos que usam essa opção precisam inspecionar cuidadosamente os dados armazenados para garantir que eles não contenham informações pessoais.
Ao executar nesse modo, as seguintes APIs do sistema ficam disponíveis para gerenciar explicitamente um Context apoiado pelo armazenamento de CE quando necessário, que são equivalentes às contrapartes protegidas por dispositivo.
Context.createCredentialProtectedStorageContext()
Context.isCredentialProtectedStorage()
Suporte para vários usuários
Cada usuário em um ambiente multiusuário recebe uma chave de criptografia separada. Cada usuário recebe duas chaves: uma DE e uma CE. O usuário 0 precisa fazer login primeiro, porque ele é um usuário especial. Isso é pertinente para usos de Administração de dispositivos.
Os apps compatíveis com criptomoedas interagem entre usuários da seguinte maneira:
INTERACT_ACROSS_USERS
e INTERACT_ACROSS_USERS_FULL
permitem que um app funcione para todos os usuários do dispositivo. No entanto, esses
apps só podem acessar diretórios criptografados por CE de usuários que já estão
desbloqueados.
Um app pode interagir livremente em todas as áreas do DE, mas um usuário desbloqueado não significa que todos os usuários no dispositivo estão desbloqueados. O app precisa verificar esse status antes de tentar acessar essas áreas.
Cada ID de usuário do perfil de trabalho também recebe duas chaves: DE e CE. Quando o desafio de trabalho é atendido, o usuário do perfil é desbloqueado e o KeyMint (no TEE) pode fornecer a chave do TEE do perfil.
Processar atualizações
A partição de recuperação não consegue acessar o armazenamento protegido por DE na partição de dados do usuário. Recomendamos que os dispositivos que implementam FBE ofereçam suporte a OTA usando atualizações do sistema A/B. Como a OTA pode ser aplicada durante a operação normal, não é necessário fazer uma recuperação para acessar os dados na unidade criptografada.
Ao usar uma solução OTA legada, que exige recuperação para acessar o arquivo OTA
na partição userdata
:
- Crie um diretório de nível superior (por exemplo,
misc_ne
) na partiçãouserdata
. - Configure esse diretório de nível superior para não ser criptografado (consulte Excluir diretórios).
- Crie um diretório no diretório de nível superior para armazenar pacotes OTA.
- Adicione uma regra do SELinux e contextos de arquivo para controlar o acesso a esse diretório e ao conteúdo dele. Somente o processo ou os apps que recebem atualizações OTA podem ler e gravar nesse diretório. Nenhum outro app ou processo pode ter acesso a esse diretório.
Validação
Para garantir que a versão implementada do recurso funcione conforme o esperado, primeiro execute os vários testes de criptografia do CTS, como DirectBootHostTest e EncryptionTest.
Se o dispositivo estiver executando o Android 11 ou uma versão mais recente, execute também vts_kernel_encryption_test:
atest vts_kernel_encryption_test
ou:
vts-tradefed run vts -m vts_kernel_encryption_test
Além disso, os fabricantes de dispositivos podem realizar os seguintes testes manuais. Em um dispositivo com a FBE ativada:
- Verifique se
ro.crypto.state
existe- Verifique se o
ro.crypto.state
está criptografado
- Verifique se o
- Verifique se
ro.crypto.type
existe- Verifique se
ro.crypto.type
está definido comofile
.
- Verifique se
Além disso, os testadores podem verificar se o armazenamento criptografado por credencial está bloqueado antes que o dispositivo seja desbloqueado pela primeira vez desde a inicialização. Para isso, use uma
versão userdebug
ou eng
, defina um PIN, padrão ou
senha para o usuário principal e reinicie o dispositivo. Antes de desbloquear o dispositivo, execute o comando a seguir para verificar o armazenamento de CE do usuário principal. Se o dispositivo usar o modo de usuário do sistema headless (a maioria dos dispositivos automotivos), o usuário principal será o usuário 10. Portanto, execute:
adb root; adb shell ls /data/user/10
Em outros dispositivos (a maioria dos dispositivos não automotivos), o usuário principal é o usuário 0. Portanto, execute:
adb root; adb shell ls /data/user/0
Verifique se os nomes de arquivo listados estão codificados em Base64, indicando que os nomes de arquivo estão criptografados e que a chave para descriptografá-los ainda não está disponível. Se os nomes de arquivos estiverem listados em texto simples, algo está errado.
Os fabricantes de dispositivos também são incentivados a executar os testes upstream do Linux para fscrypt nos dispositivos ou kernels. Esses testes fazem parte do conjunto de testes do sistema de arquivos xfstests. No entanto, esses testes upstream não são oficialmente compatíveis com o Android.
Detalhes da implementação do AOSP
Esta seção fornece detalhes sobre a implementação do AOSP e descreve como a criptografia baseada em arquivos funciona. Não é necessário que os fabricantes de dispositivos façam mudanças aqui para usar a criptografia baseada em arquivos e a inicialização direta nos dispositivos.
Criptografia fscrypt
A implementação do AOSP usa a criptografia "fscrypt" (compatível com ext4 e f2fs) no kernel e normalmente é configurada para:
- Criptografar o conteúdo do arquivo com AES-256 no modo XTS
- Criptografar nomes de arquivos com AES-256 no modo CBC-CTS
A criptografia Adiantum também é compatível. Quando a criptografia Adiantum está ativada, o conteúdo e os nomes dos arquivos são criptografados com Adiantum.
O fscrypt oferece suporte a duas versões de políticas de criptografia: 1 e 2. A versão 1 foi descontinuada, e os requisitos do CDD para dispositivos lançados com Android 11 e versões mais recentes são compatíveis apenas com a versão 2. As políticas de criptografia da versão 2 usam HKDF-SHA512 para derivar as chaves de criptografia reais das chaves fornecidas pelo espaço do usuário.
Para mais informações sobre o fscrypt, consulte a documentação do kernel upstream.
Classes de armazenamento
A tabela a seguir lista as chaves FBE e os diretórios que elas protegem em mais detalhes:
Classe de armazenamento | Descrição | Diretórios |
---|---|---|
Não criptografada | Diretórios em /data que não podem ou não precisam ser
protegidos pela FBE. Em dispositivos que usam criptografia de metadados, esses diretórios não são realmente não criptografados, mas sim protegidos pela chave de criptografia de metadados, que é equivalente à DE do sistema. |
|
Sistema DE | Dados criptografados no dispositivo que não estão vinculados a um usuário específico |
|
Por inicialização | Arquivos de sistema temporários que não precisam sobreviver a uma reinicialização | /data/per_boot |
CE do usuário (interno) | Dados criptografados por credenciais de cada usuário no armazenamento interno |
|
Usuário DE (interno) | Dados criptografados por dispositivo e por usuário no armazenamento interno |
|
CE do usuário (adotável) | Dados criptografados com credenciais por usuário no armazenamento adaptável |
|
Usuário DE (adotável) | Dados criptografados por dispositivo e por usuário no armazenamento adaptável |
|
Armazenamento e proteção de chaves
Todas as chaves FBE são gerenciadas pelo vold
e armazenadas criptografadas no disco,
exceto a chave por inicialização, que não é armazenada. A tabela a seguir
lista os locais em que as várias chaves do FBE são armazenadas:
Tipo de chave | Local da chave | Classe de armazenamento do local da chave |
---|---|---|
Chave DE do sistema | /data/unencrypted |
Não criptografada |
Chaves de CE do usuário (internas) | /data/misc/vold/user_keys/ce/${user_id} |
Sistema DE |
Chaves de DE do usuário (internas) | /data/misc/vold/user_keys/de/${user_id} |
Sistema DE |
Chaves do User CE (adotáveis) | /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} |
CE do usuário (interno) |
Chaves DE (adotáveis) do usuário | /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} |
Usuário DE (interno) |
Conforme mostrado na tabela anterior, a maioria das chaves FBE é armazenada em diretórios criptografados por outra chave FBE. As chaves só podem ser desbloqueadas quando a classe de armazenamento que as contém também é desbloqueada.
O vold
também aplica uma camada de criptografia a todas as chaves FBE. Todas as chaves, exceto as de CE para armazenamento interno, são criptografadas com AES-256-GCM usando a própria chave do Keystore, que não é exposta fora do TEE. Isso garante que as chaves FBE não possam ser desbloqueadas, a menos que um
sistema operacional confiável tenha sido inicializado, conforme imposto pela inicialização verificada. A resistência a rollbacks também é solicitada na chave do Keystore, o que permite que as chaves FBE sejam excluídas com segurança em dispositivos em que o KeyMint oferece suporte a essa resistência. Como
um substituto de melhor esforço quando a resistência a rollbacks não está disponível, o hash SHA-512
de 16.384 bytes aleatórios armazenados no arquivo secdiscardable
armazenado
junto com a chave é usado como o Tag::APPLICATION_ID
da chave
do Keystore. Todos esses bytes precisam ser recuperados para recuperar uma chave FBE.
As chaves CE para armazenamento interno recebem um nível de proteção mais forte que garante que elas não possam ser desbloqueadas sem o fator de conhecimento da tela de bloqueio (LSKF) (PIN, padrão ou senha) do usuário, um token seguro de redefinição de senha ou as chaves do lado do cliente e do servidor para uma operação de retomada na reinicialização. Só é possível criar tokens de redefinição de senha para perfis de trabalho e dispositivos totalmente gerenciados.
Para isso, o vold
criptografa cada chave CE para armazenamento interno usando uma chave AES-256-GCM derivada da senha sintética do usuário.
A senha sintética é um secret criptográfico imutável de alta entropia gerado aleatoriamente para cada usuário. O LockSettingsService
em
system_server
gerencia a senha sintética e as formas de
proteção dela.
Para proteger a senha sintética com o LSKF,
LockSettingsService
primeiro estica o LSKF transmitindo-o por
scrypt
, visando um tempo de cerca de 25 ms e um
uso de memória de cerca de 2 MiB. Como as LSKFs geralmente são curtas, essa etapa não oferece muita segurança. A principal camada de segurança é o elemento seguro (SE) ou a limitação de taxa imposta pelo TEE descrita abaixo.
Se o dispositivo tiver um elemento seguro (SE), o LockSettingsService
mapeará o LSKF esticado para um segredo aleatório de alta entropia armazenado no SE usando
o Weaver HAL. Em seguida, o LockSettingsService
criptografa
a senha sintética duas vezes: primeiro com uma chave de software derivada do
LSKF esticado e do segredo do Weaver, e segundo com uma chave do Keystore
não vinculada à autenticação. Isso fornece limitação de taxa aplicada por SE de palpites de LSKF.
Se o dispositivo não tiver um SE, o LockSettingsService
usará o LSKF esticado como uma senha do Gatekeeper. Em seguida, o LockSettingsService
criptografa a senha sintética duas vezes: primeiro com uma chave de software derivada do LSKF esticado e do hash de um arquivo secdiscardable, e segundo com uma chave do Keystore vinculada por autenticação ao registro do Gatekeeper. Isso fornece limitação de taxa aplicada por TEE de palpites de LSKF.
Quando a LSKF é alterada, o LockSettingsService
exclui todas as informações associadas à vinculação da senha sintética à LSKF antiga. Em dispositivos que oferecem suporte a chaves do Keystore resistentes a Weaver ou reversão, isso garante a exclusão segura da vinculação antiga. Por isso, as proteções descritas aqui são aplicadas mesmo quando o usuário não tem um LSKF.