O Android 7.0 e versões mais recentes oferecem suporte à criptografia baseada em arquivos (FBE, na sigla em inglês). Com a criptografia baseada em arquivos, diferentes arquivos podem ser criptografados com chaves diferentes que podem ser desbloqueadas de modo independente.
Este artigo descreve como ativar a criptografia baseada em arquivos em novos dispositivos e como os aplicativos do sistema podem usar as APIs de inicialização direta para oferecer a melhor e mais segura experiência possível.
Todos os dispositivos lançados com o Android 10 e versões mais recentes para usar a criptografia baseada em arquivos.
Inicialização direta
A criptografia baseada em arquivos ativa um novo recurso introduzido no Android 7.0 chamado Direct Inicialização. A inicialização direta permite que dispositivos criptografados sejam inicializados diretamente para o bloqueio tela. Antes, em dispositivos criptografados que usavam full-disk criptografia (FDE), os usuários precisavam fornecer credenciais antes que os dados pudessem ser acessado, impedindo que o telefone execute todos, exceto o mais básico as operações. Por exemplo, os alarmes não podiam funcionar, os serviços de acessibilidade foram indisponíveis e os telefones não recebiam chamadas, mas eram limitados a chamadas básicas as operações de emergência do discador.
Com a introdução da criptografia baseada em arquivos (FBE) e novas APIs para tornar aplicativos cientes da criptografia, é possível que esses aplicativos operem dentro de um contexto limitado. Isso pode acontecer antes que os usuários forneçam credenciais enquanto protege as informações privadas dos usuários.
Em um dispositivo compatível com FBE, cada usuário tem dois locais de armazenamento disponíveis para aplicativos:
- Armazenamento criptografado por credencial (CE), que é o local de armazenamento padrão e só fica disponível depois que o usuário desbloqueia o dispositivo.
- O armazenamento criptografado do dispositivo (DE), que é um local de armazenamento disponível tanto durante o modo de inicialização direta e depois que o usuário desbloqueia o dispositivo.
Essa separação aumenta a segurança dos perfis de trabalho porque permite que mais de um mais protegido no momento, já que a criptografia não é mais baseada apenas a senha do tempo de inicialização.
A API Direct Boot permite que aplicativos com reconhecimento de criptografia acessem cada um desses áreas Há mudanças no ciclo de vida do aplicativo para acomodar a necessidade notificar os aplicativos quando o armazenamento CE de um usuário é desbloqueado em resposta a primeiro inserindo as credenciais na tela de bloqueio ou, no caso do perfil de trabalho, fornecendo uma trabalho desafio. Dispositivos que executam o Android 7.0 devem oferecer suporte a essas novas APIs e independentemente de terem implementado ou não a FBE. Embora, sem Os armazenamentos FBE, DE e CE sempre estarão no estado desbloqueado.
Uma implementação completa de criptografia baseada em arquivos nos arquivos Ext4 e F2FS são fornecidos no Android Open Source Project (AOSP) e só precisam ser ativado nos dispositivos que atendem aos requisitos. Fabricantes que escolhem usar a FBE pode querer explorar formas de otimizar o recurso com base no system on chip (SoC).
Todos os pacotes necessários no AOSP foram atualizados para oferecer reconhecimento de inicialização direta. No entanto, quando os fabricantes de dispositivos usam versões personalizadas desses apps, eles deve garantir, no mínimo, que haja pacotes com reconhecimento de inicialização direta fornecendo 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 de criptografia baseada em arquivos, na qual vold (system/vold) oferece a funcionalidade de gerenciar dispositivos de armazenamento e volumes no Android. A adição da FBE fornece ao vold vários novos comandos para oferecer suporte ao gerenciamento de chaves CE e DE de vários usuários. Além disso, às principais mudanças para usar a configuração baseada em arquivos de criptografia no kernel, muitos pacotes do sistema, incluindo o a tela de bloqueio e a SystemUI foram modificadas para oferecer suporte à FBE e ao Direct Recursos de inicialização. São eles:
- Discador do AOSP (pacotes/apps/discador)
- Relógio de mesa (pacotes/apps/DeskClock)
- LatinIME (pacotes/inputmethods/latinoIME)*
- App Configurações (pacotes/apps/configurações)*
- SystemUI (frameworks/base/packages/SystemUI)*
* Aplicativos do sistema que usam o defaultToDeviceProtectedStorage
atributo do manifesto
Mais exemplos de aplicativos e serviços com reconhecimento de criptografia podem ser
ao executar o comando mangrep directBootAware
na
diretório de frameworks ou pacotes do AOSP
árvore de origem.
Dependências
Para usar a implementação da FBE no AOSP com segurança, um dispositivo precisa atender aos dependências:
- Suporte do kernel para criptografia Ext4 ou F2FS.
- Mestre das chaves Suporte à versão 1.0 ou mais recente da HAL. Não há suporte para Keymaster 0.3 porque não fornece os recursos necessários nem garante segurança suficiente para chaves de criptografia.
- Keymaster/Keystore e O assistente precisa ser implementado em uma execução confiável Environment (TEE) para fornecer proteção às chaves DE de modo que uma não autorizado (SO personalizado instalado no dispositivo) não pode simplesmente solicitar o DE.
- Raiz de confiança de hardware e Inicialização verificada vinculada à inicialização do Keymaster é necessária para garantir que as chaves DE não sejam podem ser acessados por um sistema operacional não autorizado.
Implementação
Primeiro, apps como despertadores, smartphones e recursos de acessibilidade deve ser definido como android:directBootAware de acordo com a Definição Inicializar a documentação do desenvolvedor.
Suporte do kernel
O suporte do kernel para criptografia Ext4 e F2FS está disponível no console do Android, kernels versão 3.18 e mais recentes. Para ativá-lo em um kernel versão 5.1 ou superior, use:
CONFIG_FS_ENCRYPTION=y
Para kernels mais antigos, use CONFIG_EXT4_ENCRYPTION=y
se a interface
O sistema de arquivos userdata
é Ext4 ou use
CONFIG_F2FS_FS_ENCRYPTION=y
se o dispositivo for userdata
do sistema de arquivos é F2FS.
Caso seu dispositivo seja compatível com os recursos armazenamento ou vão usar metadados criptografia 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 dispositivos os fabricantes também devem habilitar a aceleração criptográfica e criptografia baseada em arquivos e melhorar a experiência do usuário. Por exemplo, em Em dispositivos baseados em ARM64, a aceleração de ARMv8 CE (Extensões de criptografia) pode ser ativado 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 uso de energia, os fabricantes de dispositivos podem considere também implementar um hardware de criptografia inline, que criptografa/descriptografa os dados enquanto estão a caminho do dispositivo de armazenamento. Os kernels comuns do Android (versão 4.14 e mais recentes) contêm um framework que permite que a criptografia em linha seja usada quando o suporte ao hardware e ao driver do fornecedor for disponíveis. O framework de criptografia em linha pode ser ativado ao definir a seguintes opções de configuração do kernel:
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
Caso seu dispositivo use o armazenamento baseado em UFS, ative também:
CONFIG_SCSI_UFS_CRYPTO=y
Caso seu dispositivo use armazenamento baseado em eMMC, ative também:
CONFIG_MMC_CRYPTO=y
Como ativar a criptografia baseada em arquivos
Para ativar a FBE em um dispositivo, ela precisa ser ativada no armazenamento interno
(userdata
). Isso também ativa automaticamente a FBE em modelos
armazenamento No entanto, o formato de criptografia no armazenamento adotá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
. Esta opção define o formato de criptografia nos dados
armazenamento. Ele contém até três parâmetros separados por dois-pontos:
- O parâmetro
contents_encryption_mode
define qual um algoritmo criptográfico é usado para criptografar o conteúdo do arquivo. Podem seraes-256-xts
ouadiantum
. Desde o Android 11 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 um algoritmo criptográfico é usado para criptografar nomes de arquivos. Podem 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
ou paraadiantum
secontents_encryption_mode
éadiantum
. - O parâmetro
flags
, novo no Android 11, é uma lista de sinalizações separadas pelo+
caractere. As sinalizações a seguir são compatíveis:- A flag
v1
seleciona as políticas de criptografia da versão 1. as A sinalizaçãov2
seleciona as políticas de criptografia da versão 2. Versão Duas políticas de criptografia usam uma função de derivação de chaves mais segura e flexível. O padrão é v2 se do dispositivo iniciado no Android 11 ou mais recente (conforme determinado porro.product.first_api_level
), ou v1 se no dispositivo iniciado no Android 10 ou mais baixo. - A flag
inlinecrypt_optimized
seleciona uma criptografia otimizado para hardware de criptografia inline que não a lidar com grandes números de chaves com eficiência. Ele faz isso ao derivar apenas uma chave de criptografia de conteúdo de arquivo por chave CE ou DE, em vez de uma por arquivo. A geração de IVs (vetores de inicialização) é e ajustadas de acordo. - A sinalização
emmc_optimized
é semelhante ainlinecrypt_optimized
, mas também seleciona um IV que limita os IVs a 32 bits. Essa sinalização só deve ser usada em hardware de criptografia em linha que esteja em conformidade com a com a especificação JEDEC eMMC v5.2. Portanto, é compatível apenas com 32 bits IVs Em outros hardwares de criptografia inline, useinlinecrypt_optimized
. Essa sinalização nunca deve ser usados em armazenamentos baseados em UFS; a especificação UFS permite o uso de IVs de 64 bits. - Em dispositivos com suporte a encapsulamento de hardware
chaves, a sinalização
wrappedkey_v0
permite o uso de encapsuladas por hardware para FBE. Essa opção só pode ser usada em combinação com a opção de montageminlinecrypt
, além dasinlinecrypt_optimized
ouemmc_optimized
. - A flag
dusize_4k
força o tamanho da unidade de dados de criptografia seja de 4096 bytes, mesmo quando o tamanho do bloco do sistema de arquivos não for 4096 bytes. O tamanho da unidade de dados de criptografia é a granularidade do arquivo criptografia de conteúdo. Essa flag está disponível desde o Android 15 (AOSP experimental). Essa sinalização só deve ser usada para ativar o uso de hardware de criptografia em linha incompatível unidades maiores que 4.096 bytes em um dispositivo que usa um tamanho de página maior do que 4096 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
dispositivos é fileencryption=aes-256-xts
. Se você usa inline
de hardware de criptografia.
A configuração recomendada para a maioria dos
fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized
(ou equivalente a fileencryption=::inlinecrypt_optimized
). Ativado
dispositivos sem qualquer forma de aceleração de AES, a Adiantum pode ser usada em vez do AES ao
definindo fileencryption=adiantum
.
No Android 14 e mais recentes, o AES-HCTR2 é o modo preferido de criptografia de nomes de arquivo
para dispositivos com instruções de criptografia acelerada. No entanto, apenas kernels Android mais recentes oferecem suporte
AES-HCTR2 Em uma versão futura do Android, planeja-se tornar-se o modo padrão para nomes de arquivos
criptografia. Caso seu kernel tenha suporte a AES-HCTR2, ele pode 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 ou versões anteriores,
fileencryption=ice
também é aceito para especificar o uso do
Modo de criptografia do conteúdo do arquivo FSCRYPT_MODE_PRIVATE
. Este modo é
não implementado pelos kernels comuns do Android, mas poderia ser implementado
fornecedores que usam patches de kernel personalizados. O formato no disco produzido por este modo
era específico do fornecedor. Em dispositivos lançados com o Android
11 ou superior, esse modo não é mais permitido, e uma
use o formato de criptografia padrão.
Por padrão, a criptografia do conteúdo do arquivo é feita usando o
API de criptografia. Se você quiser usar hardware de criptografia inline, também
adicione a opção de montagem inlinecrypt
. Por exemplo, um
A linha fstab
poderá 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, a FBE e o armazenamento adotável podem ser usados juntos.
Especificar a opção fstab fileencryption
para
O userdata
também ativa automaticamente a FBE e a criptografia de metadados em APIs
armazenamento. No entanto, é possível substituir a FBE e/ou os formatos de criptografia de metadados nas
o armazenamento adotável definindo propriedades em
PRODUCT_PROPERTY_OVERRIDES
:
Em dispositivos lançados com o Android 11 ou mais recente, use as seguintes propriedades:
ro.crypto.volume.options
(novo no Android) 11) seleciona o formato de criptografia FBE; o armazenamento adotável. Ele tem a mesma sintaxe que o argumento para ofileencryption
, e ela usa os mesmos padrões. Confira acima as recomendações defileencryption
sobre o que usar aqui.ro.crypto.volume.metadata.encryption
seleciona os metadados de criptografia de dados no armazenamento adotável. Consulte os metadados de criptografia de dados.
Em dispositivos lançados com o Android 10 ou versões anteriores, use as seguintes propriedades:
ro.crypto.volume.contents_mode
seleciona o conteúdo modo de criptografia. Isso é equivalente ao primeiro campo separado por dois-pontos dero.crypto.volume.options
:ro.crypto.volume.filenames_mode
seleciona os nomes dos arquivos modo de criptografia. Isso é equivalente ao segundo campo separado por dois-pontos dero.crypto.volume.options
, exceto pelo fato de que o padrão em dispositivos lançados com o Android 10 ou versões anterioresaes-256-heh
. Na maioria dos dispositivos, isso precisa ser substituído poraes-256-cts
.ro.crypto.fde_algorithm
ero.crypto.fde_sector_size
selecione a criptografia dos metadados em armazenamento adotável. Consulte os metadados de criptografia de dados.
Integrar com o Keymaster
A HAL do Keymaster precisa ser iniciada como parte da classe early_hal
.
Isso ocorre porque a FBE exige que o Keymaster esteja pronto para processar solicitações do
A fase de inicialização post-fs-data
, que é quando o vold
configura
as chaves iniciais.
Exclusão de diretórios
init
aplica a chave DE do sistema às
todos os diretórios de nível superior de /data
, exceto os diretórios
precisa ser descriptografado, como o diretório que contém a chave DE do sistema
e diretórios que contêm os diretórios CE ou DE do usuário. Chaves de criptografia
são aplicadas recursivamente e não podem ser substituídas por subdiretórios.
No Android 11 e versões mais recentes, a chave
init
se aplica a diretórios que podem ser controlados pelo
Argumento encryption=<action>
para o mkdir
em scripts init. Os valores possíveis de <action>
são
documentadas no
README para a linguagem init do Android.
No Android 10, as ações de criptografia init
foram fixados no código no seguinte local:
/system/extras/libfscrypt/fscrypt_init_extensions.cpp
No Android 9 e 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 sem criptografia. Se forem feitas modificações desse tipo, o dispositivo fabricante deve incluir Políticas de SELinux que concedem acesso apenas ao que precisam usar o diretório não criptografado. Isso excluirá todos aplicativos não confiáveis.
O único caso de uso aceitável conhecido para isso é o suporte a atualizações OTA legadas recursos.
Suporte à inicialização direta em aplicativos do sistema
Como fazer com que os aplicativos 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 aplicativo. A
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 aplicativo é uma forma abreviada de marcar
todos os componentes do app como tendo reconhecimento de criptografia.
O atributo defaultToDeviceProtectedStorage
redireciona o
local de armazenamento do app para apontar para o armazenamento DE em vez de apontar para o armazenamento CE.
Os apps do sistema que usam essa sinalização precisam auditar cuidadosamente todos os dados armazenados no
local e mudar os caminhos dos dados sensíveis para usar o armazenamento CE. Dispositivo
fabricantes que usam essa opção devem inspecionar cuidadosamente os dados
armazenando para garantir que ele não contenha informações pessoais.
Nesse modo, as seguintes APIs do sistema são disponível para gerenciar explicitamente um contexto com suporte do armazenamento CE quando necessário, são equivalentes aos dispositivos com proteção por dispositivo.
Context.createCredentialProtectedStorageContext()
Context.isCredentialProtectedStorage()
Suporte a vários usuários
Cada usuário em um ambiente multiusuário recebe uma chave de criptografia separada. Todos os usuários recebe duas chaves: uma DE e uma CE. O usuário 0 precisa fazer login no dispositivo primeiro, como está um usuário especial. Isso é pertinente para dispositivos Administration.
Os aplicativos com reconhecimento de criptografia interagem entre os usuários desta maneira:
INTERACT_ACROSS_USERS
e INTERACT_ACROSS_USERS_FULL
permitem que um aplicativo aja para todos os usuários do dispositivo. No entanto, essas
só poderão acessar diretórios criptografados por CE para usuários com
já está desbloqueado.
Um aplicativo pode interagir livremente entre as áreas de DE, mas um usuário desbloqueado não significa que todos os usuários do dispositivo também estejam. A aplicativo deve verificar esse status antes de tentar acessar essas áreas.
Cada ID do usuário do perfil de trabalho também recebe duas chaves: DE e CE. Quando o desafio do trabalho for atendido, o usuário do perfil será desbloqueado e o Keymaster (no TEE) poderá fornecer a chave TEE do perfil.
Gerenciar atualizações
A partição de recuperação não consegue acessar o armazenamento protegido por DE no "userdata". É altamente recomendável que os dispositivos que implementam a FBE ofereçam suporte OTA usando atualizações do sistema A/B. Conforme para que o OTA possa ser aplicado durante a operação normal, não é necessário fazer a recuperação para acessar os dados no drive criptografado.
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
) nouserdata
. - Configure esse diretório de nível superior para que seja descriptografado. Consulte Como excluir diretórios.
- Crie um diretório dentro do de nível superior para armazenar pacotes OTA.
- Adicione uma regra SELinux e contextos de arquivo para controlar o acesso a esse diretório e o conteúdo dele. Somente o processo ou os aplicativos que recebem atualizações OTA devem ser ler e gravar nesse diretório. Nenhum outro aplicativo ou processo deve ter acesso a esse diretório.
Validação
Para garantir que a versão implementada do recurso funcione conforme o esperado, primeiro execute vários testes de criptografia CTS, como DirectBootHostTest (em inglês) e EncryptionTest.
Se o dispositivo estiver executando o Android 11 ou 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 testes manuais a seguir. Em um dispositivo com FBE ativado:
- 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 CE está bloqueado antes que o dispositivo seja
desbloqueado pela primeira vez desde a inicialização. Para fazer isso, use um método
userdebug
ou eng
, defina um PIN, padrão ou
senha no usuário principal e reinicializar o dispositivo. Antes de desbloquear o dispositivo,
Execute o seguinte comando para verificar o armazenamento CE do usuário principal. Se o
dispositivo usa sistema headless
Modo de usuário (a maioria dos dispositivos automotivos), que tem como usuário principal o 10. Por isso, execute este comando:
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, executar:
adb root; adb shell ls /data/user/0
Verifique se os nomes de arquivo listados estão codificados em Base64, indicando que os os nomes de arquivo são criptografados e a chave para descriptografá-los ainda não está disponível. Se os nomes dos arquivos estiverem listados em texto simples, algo está errado.
Os fabricantes de dispositivos também são incentivados a executar testes upstream do Linux para fscrypt nos seus dispositivos ou grãos Esses testes fazem parte do pacote de testes do sistema de arquivos xfstests. No entanto, esses testes upstream não têm suporte oficial do Android.
Detalhes de implementação do AOSP
Esta seção fornece detalhes sobre a implementação do AOSP e descreve como a criptografia baseada em arquivos. Não é necessário para fabricantes de dispositivos para fazer mudanças aqui para usar a FBE e a inicialização direta nos dispositivos.
criptografia fscrypt
A implementação do AOSP usa "fscrypt" Criptografia (compatível com ext4 e f2fs) no kernel e normalmente é configurado para:
- Criptografar conteúdo de arquivos com AES-256 no modo XTS
- Criptografar nomes de arquivos com AES-256 no modo CBC-CTS
A criptografia Adiantum também é suporte. Quando a criptografia Adiantum está ativada, o conteúdo e os nomes dos arquivos são criptografados com Adiantum.
O fscrypt é compatível com duas versões das políticas de criptografia: versão 1 e versão 2. A versão 1 foi descontinuada, e os requisitos do CDD para dispositivos lançados com O Android 11 e as 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 (link em inglês). 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 detalhe:
Classe de armazenamento | Descrição | Diretórios |
---|---|---|
Não criptografada | Diretórios em /data que não podem ou não precisam ser
protegidas pela FBE. Em dispositivos que usam metadados
criptografia, esses diretórios não são de fato descriptografados,
são protegidas pela chave de criptografia de metadados,
System DE. |
|
System DE | Dados criptografados pelo dispositivo nã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 credencial por usuário no armazenamento interno |
|
Usuário DE (interno) | Dados criptografados do dispositivo por usuário no armazenamento interno |
|
CE do usuário (adotável) | Dados criptografados por credencial por usuário no armazenamento adotável |
|
Usuário DE (adotável) | Dados criptografados por dispositivo por usuário no armazenamento adotável |
|
Armazenamento e proteção de chaves
Todas as chaves FBE são gerenciadas por vold
e armazenadas criptografadas no disco,
exceto pela chave por inicialização, que não é armazenada. A tabela a seguir
lista os locais em que as várias chaves FBE estã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 CE (internas) do usuário | /data/misc/vold/user_keys/ce/${user_id} |
System DE |
Chaves de usuário DE (internas) | /data/misc/vold/user_keys/de/${user_id} |
System DE |
Chaves CE (adotáveis) do usuário | /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} |
CE do usuário (interno) |
Chaves do usuário DE (adotáveis) | /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} |
Usuário DE (interno) |
Como mostrado na tabela anterior, a maioria das chaves FBE é armazenada em diretórios que são criptografados por outra chave FBE. As chaves não podem ser desbloqueadas até que o armazenamento que os contém foi desbloqueada.
O vold
também aplica uma camada de criptografia a todas as chaves FBE. Todas as chaves
além das chaves CE para armazenamento interno, é criptografada com AES-256-GCM utilizando a própria
Keystore que não é
exposto fora do TEE. Isso garante que as chaves FBE não possam ser desbloqueadas, a menos que um
sistema operacional confiável seja inicializado, conforme aplicado pela Inicialização verificada. Reverter
resistência também é solicitada na chave Keystore, o que permite que chaves FBE
excluídas com segurança nos dispositivos em que o Keymaster é compatível com resistência a reversão. Conforme
um substituto de melhor esforço para quando a resistência à reversão não está disponível, o SHA-512
hash de 16.384 bytes aleatórios no arquivo secdiscardable
armazenado
ao lado da chave é usada como o ID do aplicativo
tag da chave do Keystore. Todos esses bytes precisam ser recuperados para recuperar uma
Tecla FBE.
As chaves CE para armazenamento interno recebem um nível mais alto de proteção, que garante eles não podem ser desbloqueados sem conhecer a tela de bloqueio fator de conhecimento (LSKF, na sigla em inglês) (PIN, padrão ou senha), uma chave de segurança token de redefinição de senha ou as chaves do lado do cliente e do servidor para uma Operação Retomar na reinicialização. Os tokens de redefinição de senha só podem ser criados para perfis de trabalho e totalmente dispositivos gerenciados.
Para fazer 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 de alta entropia imutável que é
geradas aleatoriamente para cada usuário. LockSettingsService
pol.
system_server
gerencia a senha sintética e as maneiras pelas quais
quando ele está protegido.
Para proteger a senha sintética com o LSKF,
Primeiro, o LockSettingsService
estende o LSKF ao transmiti-lo
scrypt
, segmentando um tempo de cerca de 25ms e um
de cerca de 2 MiB. Como os LSKFs geralmente são curtos, essa etapa geralmente
não oferece muita segurança. A camada principal de segurança é a camada de
Elemento (SE) ou a limitação de taxa aplicada por TEE descrita abaixo.
Se o dispositivo tiver um Elemento de segurança (SE), então LockSettingsService
mapeia o LSKF estendido para um secret aleatório de alta entropia armazenado no SE usando
a HAL do Weaver. Depois, LockSettingsService
criptografa
a senha sintética duas vezes: primeiro com uma chave de software derivada da
o LSKF esticado e o segredo do Weaver, e o segundo com um keystore não vinculado à autenticação
de dados. Isso fornece a limitação de taxa aplicada pelo SE para suposições de LSKF.
Se o dispositivo não tiver um SE, então LockSettingsService
usa o LSKF esticado como Gatekeeper
senha. Em seguida, LockSettingsService
criptografa a senha sintética.
duas vezes: primeiro com uma chave de software derivada do LSKF estendido e o hash de
um arquivo pode ser separado, e o segundo com uma chave de keystore vinculada à autenticação
Inscrição na recepção Isso fornece a limitação de taxa aplicada por TEE para suposições de LSKF.
Quando o LSKF é alterado, o LockSettingsService
exclui todos
informações associadas à vinculação da senha sintética à senha antiga
LSKF. Em dispositivos com suporte ao Weaver ou a chaves resistentes a reversão de um keystore,
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.