Criptografia baseada em arquivo

O Android 7.0 e superior oferece suporte à criptografia baseada em arquivo (FBE). A criptografia baseada em arquivo permite que diferentes arquivos sejam criptografados com diferentes chaves que podem ser desbloqueadas independentemente.

Este artigo descreve como habilitar a criptografia baseada em arquivo em novos dispositivos e como os aplicativos 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 Android 10 e superior precisam usar criptografia baseada em arquivo.

Inicialização Direta

A criptografia baseada em arquivo habilita um novo recurso introduzido no Android 7.0 chamado Direct Boot . A inicialização direta permite que dispositivos criptografados inicializem diretamente na tela de bloqueio. Anteriormente, em dispositivos criptografados usando criptografia de disco completo (FDE), os usuários precisavam fornecer credenciais antes que qualquer dado pudesse ser acessado, impedindo que o telefone executasse todas as operações, exceto as mais básicas. Por exemplo, os alarmes não podiam operar, os serviços de acessibilidade não estavam disponíveis e os telefones não podiam receber chamadas, mas eram limitados apenas a operações básicas de discagem de emergência.

Com a introdução da criptografia baseada em arquivo (FBE) e novas APIs para tornar os aplicativos cientes da criptografia, é possível que esses aplicativos operem em um contexto limitado. Isso pode acontecer antes que os usuários forneçam suas credenciais enquanto ainda protegem as informações privadas do usuário.

Em um dispositivo habilitado para FBE, cada usuário do dispositivo tem dois locais de armazenamento disponíveis para aplicativos:

• Armazenamento Credential Encrypted (CE), que é o local de armazenamento padrão e está disponível somente depois que o usuário desbloqueou o dispositivo.
• Armazenamento criptografado por dispositivo (DE), que é um local de armazenamento disponível durante o modo de inicialização direta e depois que o usuário desbloqueou o dispositivo.

Essa separação torna os perfis de trabalho mais seguros porque permite que mais de um usuário seja protegido por vez, pois a criptografia não é mais baseada apenas em uma senha de inicialização.

A API de inicialização direta permite que aplicativos com reconhecimento de criptografia acessem cada uma dessas áreas. Há mudanças no ciclo de vida do aplicativo para acomodar a necessidade de notificar os aplicativos quando o armazenamento CE de um usuário é desbloqueado em resposta à primeira inserção de credenciais na tela de bloqueio ou no caso de perfil de trabalho fornecendo um desafio de trabalho . Os dispositivos que executam o Android 7.0 devem oferecer suporte a essas novas APIs e ciclos de vida, independentemente de implementarem ou não o FBE. Embora, sem FBE, o armazenamento DE e CE sempre estará no estado desbloqueado.

Uma implementação completa de criptografia baseada em arquivo nos sistemas de arquivos Ext4 e F2FS é fornecida no Android Open Source Project (AOSP) e só precisa ser habilitada em dispositivos que atendam aos requisitos. Os fabricantes que optam por usar o FBE podem querer explorar formas de otimizar o recurso com base no sistema no chip (SoC) usado.

Todos os pacotes necessários no AOSP foram atualizados para serem compatíveis com inicialização direta. No entanto, onde os fabricantes de dispositivos usam versões personalizadas desses aplicativos, eles devem garantir, no mínimo, que haja pacotes de inicialização direta que forneçam os seguintes serviços:

• Serviços de telefonia e discador
• Método de entrada para inserir senhas na tela de bloqueio

Exemplos e fonte

O Android fornece uma implementação de referência de criptografia baseada em arquivo, na qual vold ( system/vold ) fornece a funcionalidade para gerenciar dispositivos de armazenamento e volumes no Android. A adição do FBE fornece ao vold vários novos comandos para oferecer suporte ao gerenciamento de chaves para as chaves CE e DE de vários usuários. Além das principais alterações para usar os recursos de criptografia baseados em arquivo no kernel , muitos pacotes do sistema, incluindo a tela de bloqueio e o SystemUI, foram modificados para oferecer suporte aos recursos FBE e inicialização direta. Esses incluem:

• AOSP Dialer (pacotes/apps/Dialer)
• Relógio de mesa (pacotes/aplicativos/DeskClock)
• LatinIME (pacotes/métodos de entrada/LatinIME)*
• Aplicativo de configurações (pacotes/aplicativos/configurações)*
• SystemUI (frameworks/base/packages/SystemUI)*

* Aplicativos do sistema que usam o atributo de manifesto defaultToDeviceProtectedStorage

Mais exemplos de aplicativos e serviços com reconhecimento de criptografia podem ser encontrados executando o comando mangrep directBootAware no diretório de estruturas ou pacotes da árvore de origem AOSP.

Dependências

Para usar a implementação AOSP do FBE com segurança, um dispositivo precisa atender às seguintes dependências:

• Suporte de kernel para criptografia Ext4 ou criptografia F2FS.
• Suporte Keymaster com HAL versão 1.0 ou superior. Não há suporte para Keymaster 0.3, pois não fornece os recursos necessários ou garante proteção suficiente para chaves de criptografia.
• Keymaster/ Keystore e Gatekeeper devem ser implementados em um ambiente de execução confiável (TEE) para fornecer proteção para as chaves DE de forma que um sistema operacional não autorizado (SO personalizado instalado no dispositivo) não possa simplesmente solicitar as chaves DE.
• Hardware Root of Trust e Verified Boot vinculados à inicialização do Keymaster são necessários para garantir que as chaves DE não sejam acessíveis por um sistema operacional não autorizado.

Implementação

Em primeiro lugar, aplicativos como despertadores, telefone e recursos de acessibilidade devem ser feitos android:directBootAware de acordo com a documentação do desenvolvedor do Direct Boot .

Suporte de kernel

O suporte de kernel para criptografia Ext4 e F2FS está disponível nos kernels comuns do Android, versão 3.18 e superior. Para ativá-lo em um kernel com versão 5.1 ou superior, use:

CONFIG_FS_ENCRYPTION=y

Para kernels mais antigos, use CONFIG_EXT4_ENCRYPTION=y se o sistema de arquivos userdata do seu dispositivo for Ext4 ou use CONFIG_F2FS_FS_ENCRYPTION=y se o sistema de arquivos userdata do seu dispositivo for F2FS.

Se o seu dispositivo suportar armazenamento adotável ou usar criptografia de metadados no armazenamento interno, habilite também as opções de configuração do kernel necessárias para criptografia de metadados conforme descrito na documentação de criptografia de metadados .

Além do suporte funcional para criptografia Ext4 ou F2FS, os fabricantes de dispositivos também devem habilitar a aceleração criptográfica para acelerar a criptografia baseada em arquivo e melhorar a experiência do usuário. Por exemplo, em dispositivos baseados em ARM64, a aceleração ARMv8 CE (Cryptography Extensions) pode ser habilitada 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 também podem considerar a implementação de hardware de criptografia em linha , que criptografa/descriptografa os dados enquanto eles estão no caminho de/para o dispositivo de armazenamento. Os kernels comuns do Android (versão 4.14 e superior) contêm uma estrutura que permite que a criptografia em linha seja usada quando o hardware e o suporte do driver do fornecedor estiverem disponíveis. A estrutura de criptografia em linha pode ser habilitada 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 seu dispositivo usa armazenamento baseado em UFS, habilite também:

CONFIG_SCSI_UFS_CRYPTO=y

Se o seu dispositivo usa armazenamento baseado em eMMC, habilite também:

CONFIG_MMC_CRYPTO=y

Ativando a criptografia baseada em arquivo

Habilitar o FBE em um dispositivo requer habilitá-lo no armazenamento interno ( userdata ). Isso também ativa automaticamente o FBE no armazenamento adotável; no entanto, o formato de criptografia no armazenamento adotável pode ser substituído, se necessário.

Armazenamento interno

O FBE é ativado adicionando 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 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 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 algoritmo criptográfico é usado para criptografar nomes de arquivo. Pode 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 adiantum se contents_encryption_mode for adiantum .
• O parâmetro flags , novidade no Android 11, é uma lista de flags separados pelo caractere + . As seguintes sinalizações são suportadas:
  • O sinalizador v1 seleciona as políticas de criptografia da versão 1; o sinalizador v2 seleciona as 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 iniciado no Android 11 ou superior (conforme determinado por ro.product.first_api_level ) ou v1 se o dispositivo foi iniciado no Android 10 ou inferior.
  • O sinalizador inlinecrypt_optimized seleciona um formato de criptografia otimizado para hardware de criptografia em linha que não lida com um grande número de chaves com eficiência. Ele faz isso derivando 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) é ajustada de acordo.
  • O sinalizador emmc_optimized é semelhante ao inlinecrypt_optimized , mas também seleciona um método de geração de IV que limita os IVs a 32 bits. Este sinalizador deve ser usado apenas em hardware de criptografia em linha compatível com a especificação JEDEC eMMC v5.2 e, portanto, suporta apenas IVs de 32 bits. Em outro hardware de criptografia em linha, use inlinecrypt_optimized . Este sinalizador nunca deve ser usado 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 por hardware , o sinalizador wrappedkey_v0 permite o uso de chaves encapsuladas por hardware para FBE. Isso só pode ser usado em combinação com a opção de montagem inlinecrypt e o sinalizador inlinecrypt_optimized ou emmc_optimized .

Se você não estiver usando hardware de criptografia em linha, a configuração recomendada para a maioria dos dispositivos é fileencryption=aes-256-xts . Se você estiver usando hardware de criptografia em linha, a configuração recomendada para a maioria dos dispositivos é fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (ou de forma equivalente fileencryption=::inlinecrypt_optimized ). Em dispositivos sem qualquer forma de aceleração AES, Adiantum pode ser usado em vez de AES definindo fileencryption=adiantum .

Desde o Android 14 (AOSP experimental), 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 Android mais recentes suportam AES-HCTR2. Em uma versão futura do Android, está planejado para se tornar o modo padrão para criptografia de nomes de arquivos. Se o seu kernel tiver suporte para AES-HCTR2, ele poderá ser habilitado para criptografia de nomes de arquivo 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 iniciados com Android 10 ou inferior, fileencryption=ice também é aceito para especificar o uso do modo de criptografia de conteúdo de arquivo FSCRYPT_MODE_PRIVATE . Este modo não é implementado pelos kernels comuns do Android, mas pode ser implementado por fornecedores usando patches de kernel personalizados. O formato em disco produzido por este modo era específico do fornecedor. Em dispositivos lançados com Android 11 ou superior, esse modo não é mais permitido e um formato de criptografia padrão deve 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 fstab completa pode se parecer com:

/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 adotável podem ser usados ​​juntos.

A especificação da opção fileencryption fstab para userdata também ativa automaticamente a criptografia FBE e de metadados no armazenamento adotável. No entanto, você pode substituir o FBE e/ou os formatos de criptografia de metadados no armazenamento adotável definindo as propriedades em PRODUCT_PROPERTY_OVERRIDES .

Em dispositivos lançados com Android 11 ou superior, 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 para a opção fileencryption fstab e usa os mesmos padrões. Consulte as recomendações para fileencryption acima para saber o que usar aqui.
• ro.crypto.volume.metadata.encryption seleciona o formato de criptografia de metadados no armazenamento adotável. Consulte a documentação de criptografia de metadados .

Em dispositivos lançados com Android 10 ou inferior, use as seguintes propriedades:

• ro.crypto.volume.contents_mode seleciona o modo de criptografia de conteúdo. Isso é equivalente ao primeiro campo separado por dois pontos de ro.crypto.volume.options .
• ro.crypto.volume.filenames_mode seleciona o modo de criptografia de nomes de arquivo. Isso é equivalente ao segundo campo separado por dois-pontos de ro.crypto.volume.options , exceto que o padrão em dispositivos iniciados com Android 10 ou inferior é aes-256-heh . Na maioria dos dispositivos, isso precisa ser substituído explicitamente por aes-256-cts .
• ro.crypto.fde_algorithm e ro.crypto.fde_sector_size selecionam o formato de criptografia de metadados no armazenamento adotável. Consulte a documentação de criptografia de metadados .

Integração com o Keymaster

O Keymaster HAL deve ser iniciado como parte da classe early_hal . Isso ocorre porque o FBE exige que o Keymaster esteja pronto para lidar com solicitações na fase de inicialização post-fs-data , que é quando vold configura as chaves iniciais.

Excluindo diretórios

init aplica a chave DE do sistema a todos os diretórios de nível superior de /data , exceto os diretórios que devem ser descriptografados: o diretório que contém a própria chave DE do sistema e os diretórios que contêm os diretórios CE ou DE do usuário. As chaves de criptografia se aplicam recursivamente e não podem ser substituídas por subdiretórios.

No Android 11 e superior, a chave que init aplica aos diretórios pode ser controlada pelo encryption=<action> para o comando mkdir nos scripts init. Os possíveis valores de <action> estão documentados no README para a linguagem de inicialização do Android .

No Android 10, as ações de criptografia init foram codificadas no seguinte local:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

No Android 9 e anteriores, o local era:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

É possível adicionar exceções para impedir que certos diretórios sejam criptografados. Se forem feitas modificações desse tipo, o fabricante do dispositivo deve incluir políticas do SELinux que concedam acesso apenas aos aplicativos que precisam usar o diretório não criptografado. Isso deve excluir todos os aplicativos não confiáveis.

O único caso de uso aceitável conhecido para isso é o suporte a recursos legados de OTA.

Compatível com inicialização direta em aplicativos do sistema

Tornar os aplicativos cientes do Direct Boot

Para facilitar a migração rápida de aplicativos do sistema, há dois novos atributos que podem ser definidos no nível do aplicativo. O atributo defaultToDeviceProtectedStorage está disponível apenas para aplicativos 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 abreviação para marcar todos os componentes no aplicativo como tendo reconhecimento de criptografia.

O atributo defaultToDeviceProtectedStorage redireciona o local de armazenamento do aplicativo padrão para apontar para o armazenamento DE em vez de apontar para o armazenamento CE. Os aplicativos do sistema que usam esse sinalizador devem auditar cuidadosamente todos os dados armazenados no local padrão e alterar os caminhos dos dados confidenciais para usar o armazenamento CE. Os fabricantes de dispositivos que usam essa opção devem inspecionar cuidadosamente os dados que estão armazenando para garantir que não contenham informações pessoais.

Ao executar neste modo, as seguintes APIs do sistema estão disponíveis para gerenciar explicitamente um contexto apoiado pelo armazenamento CE quando necessário, que são equivalentes às suas contrapartes protegidas por dispositivo.

• Context.createCredentialProtectedStorageContext()
• Context.isCredentialProtectedStorage()

Suporte a vários usuários

Cada usuário em um ambiente multiusuário obtém uma chave de criptografia separada. Cada usuário recebe duas chaves: uma chave DE e uma chave CE. O usuário 0 deve fazer login no dispositivo primeiro, pois é um usuário especial. Isso é pertinente para usos de administração de dispositivos .

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 atue em todos os usuários no dispositivo. No entanto, esses aplicativos poderão acessar apenas diretórios criptografados pela CE para usuários que já estão desbloqueados.

Um aplicativo pode interagir livremente entre as áreas DE, mas um usuário desbloqueado não significa que todos os usuários do dispositivo estejam desbloqueados. O aplicativo deve verificar esse status antes de tentar acessar essas áreas.

Cada ID do usuário do perfil de trabalho também obtém duas chaves: DE e CE. Quando o desafio de trabalho é cumprido, o usuário do perfil é desbloqueado e o Keymaster (em TEE) pode fornecer a chave TEE do perfil.

Manipulando 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. Os dispositivos que implementam o FBE são altamente recomendados para oferecer suporte a OTA usando atualizações do sistema A/B . Como o OTA pode ser aplicado durante a operação normal, não há necessidade de recuperação para acessar os dados na unidade criptografada.

Ao usar uma solução OTA herdada, que requer recuperação para acessar o arquivo OTA na partição userdata :

1. Crie um diretório de nível superior (por exemplo misc_ne ) na partição userdata .
2. Configure esse diretório de nível superior para não ser criptografado (consulte Excluindo diretórios ).
3. Crie um diretório dentro do diretório de nível superior para manter os pacotes OTA.
4. Adicione uma regra SELinux e contextos de arquivo para controlar o acesso a este diretório e seu conteúdo. Somente o processo ou aplicativos que recebem atualizações OTA devem ser capazes de ler e gravar neste 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 pretendido, primeiro execute os muitos testes de criptografia CTS, como DirectBootHostTest e EncryptionTest .

Se o dispositivo estiver executando o Android 11 ou superior, 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 FBE ativado:

• Verifique se ro.crypto.state existe
  • Verifique se 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 inicializar uma instância userdebug com uma tela de bloqueio definida no usuário principal. Em seguida, adb shell no dispositivo e use su para se tornar root. Certifique-se de /data/data contenha nomes de arquivos criptografados; se não, algo está errado.

Os fabricantes de dispositivos também são encorajados a explorar a execução dos testes upstream do Linux para fscrypt em seus 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 suportados pelo Android.

Detalhes da implementação do AOSP

Esta seção fornece detalhes sobre a implementação do AOSP e descreve como funciona a criptografia baseada em arquivo. Não deve ser necessário que os fabricantes de dispositivos façam alterações aqui para usar o FBE e o Direct Boot em seus dispositivos.

criptografia fscrypt

A implementação AOSP usa criptografia "fscrypt" (suportada por ext4 e f2fs) no kernel e normalmente é configurada para:

• Criptografe o conteúdo do arquivo com AES-256 no modo XTS
• Criptografe nomes de arquivos com AES-256 no modo CBC-CTS

A criptografia Adiantum também é suportada. Quando a criptografia Adiantum está habilitada, o conteúdo e os nomes dos arquivos são criptografados com Adiantum.

fscrypt oferece suporte a duas versões de políticas de criptografia: versão 1 e versão 2. A versão 1 está obsoleta e os requisitos de CDD para dispositivos iniciados com Android 11 e superior são compatíveis apenas com a versão 2. As políticas de criptografia da versão 2 usam HKDF-SHA512 para derivar o real chaves de criptografia das chaves fornecidas pelo espaço do usuário.

Para obter mais informações sobre 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 com mais detalhes:

Armazenamento e proteção de chaves

Todas as chaves FBE são gerenciadas por vold e armazenadas criptografadas em disco, exceto a chave por inicialização que não é armazenada. A tabela a seguir lista os locais nos quais as várias chaves FBE são armazenadas:

Conforme mostrado na tabela anterior, a maioria das chaves FBE são armazenadas em diretórios criptografados por outra chave FBE. As chaves não podem ser desbloqueadas até que a classe de armazenamento que as contém seja desbloqueada.

vold também aplica uma camada de criptografia a todas as chaves FBE. Todas as chaves além das chaves CE para armazenamento interno são criptografadas com AES-256-GCM usando sua própria chave 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 seja inicializado, conforme aplicado pelo Verified Boot . A resistência à reversão também é solicitada na chave Keystore, o que permite que as chaves FBE sejam excluídas com segurança em dispositivos nos quais o Keymaster oferece suporte à resistência à reversão. Como um fallback de melhor esforço para quando a resistência à reversão não estiver disponível, o hash SHA-512 de 16384 bytes aleatórios armazenados no arquivo secdiscardable armazenado junto com a chave é usado como a marca de ID do aplicativo da chave Keystore. Todos esses bytes precisam ser recuperados para recuperar uma chave FBE.

As chaves CE para armazenamento interno recebem um nível mais forte de proteção que garante que elas não possam ser desbloqueadas sem conhecer o fator de conhecimento da tela de bloqueio (LSKF) (PIN, padrão ou senha) do usuário, um token de redefinição de senha segura ou ambos do lado do cliente e chaves do lado do servidor para uma operação Resume-on-Reboot . Tokens de redefinição de senha só podem ser criados para perfis de trabalho e dispositivos totalmente gerenciados .

Para conseguir isso, 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 segredo criptográfico imutável de alta entropia gerado aleatoriamente para cada usuário. LockSettingsService em system_server gerencia a senha sintética e as formas pelas quais ela é protegida.

Para proteger a senha sintética com o LSKF, LockSettingsService primeiro estende o LSKF passando-o por scrypt , visando um tempo de cerca de 25 ms e um uso de memória de cerca de 2 MiB. Como os LSKFs geralmente são curtos, essa etapa geralmente não oferece muita segurança. A principal camada de segurança é o Secure Element (SE) ou limitação de taxa aplicada por TEE descrita abaixo.

Se o dispositivo tiver um Secure Element (SE), o LockSettingsService mapeia o LSKF estendido para um segredo aleatório de alta entropia armazenado no SE usando o Weaver HAL . LockSettingsService então criptografa a senha sintética duas vezes: primeiro com uma chave de software derivada do LSKF estendido e do segredo do Weaver e, segundo, com uma chave Keystore não vinculada à autenticação. Isso fornece limitação de taxa aplicada por SE de estimativas de LSKF.

Se o dispositivo não tiver um SE, o LockSettingsService usará o LSKF estendido como uma senha do Gatekeeper . LockSettingsService então criptografa a senha sintética duas vezes: primeiro com uma chave de software derivada do LSKF estendido e o hash de um arquivo secdescartável e, segundo, com uma chave Keystore vinculada à inscrição do Gatekeeper. Isso fornece limitação de taxa aplicada por TEE de estimativas de LSKF.

Quando o LSKF é alterado, LockSettingsService exclui todas as informações associadas à vinculação da senha sintética ao antigo LSKF. Em dispositivos que suportam Weaver ou chaves Keystore resistentes à reversão, isso garante a exclusão segura da ligação antiga. Por esse motivo, as proteções descritas aqui são aplicadas mesmo quando o usuário não possui um LSKF.