Criptografia baseada em arquivos

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 ser aes-256-xts ou adiantum. 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 ser aes-256-cts, aes-256-heh. adiantum ou aes-256-hctr2. Se não for especificado, o padrão será aes-256-cts se contents_encryption_mode for aes-256-xts ou para adiantum se contents_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ção v2 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 por ro.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 a inlinecrypt_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, use inlinecrypt_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 montagem inlinecrypt, além das inlinecrypt_optimized ou emmc_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.

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 o fileencryption, e ela usa os mesmos padrões. Confira acima as recomendações de fileencryption 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 de ro.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 de ro.crypto.volume.options, exceto pelo fato de que o padrão em dispositivos lançados com o Android 10 ou versões anteriores aes-256-heh. Na maioria dos dispositivos, isso precisa ser substituído por aes-256-cts.
• ro.crypto.fde_algorithm e ro.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:

1. Crie um diretório de nível superior (por exemplo, misc_ne) no userdata.
2. Configure esse diretório de nível superior para que seja descriptografado. Consulte Como excluir diretórios.
3. Crie um diretório dentro do de nível superior para armazenar pacotes OTA.
4. 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 ro.crypto.type existe
  • Verifique se ro.crypto.type está definido como file

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:

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:

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.