android文件加密源代码,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.Cuidado :Para novos dispositivos com Android 10 e superior, a criptografia baseada em arquivo é necessária.

Dispositivos com Android 9 e superior podem usar armazenamento adotável e criptografia baseada em arquivo.

Para dispositivos com Android 7.0–8.1, a criptografia baseada em arquivo não pode ser usada junto com o armazenamento adotável . Se a criptografia baseada em arquivo estiver habilitada nesses dispositivos, uma nova mídia de armazenamento (como um cartão SD) deve ser usada como armazenamento tradicional .

Inicialização direta

A criptografia baseada em arquivo permite um novo recurso introduzido no Android 7.0 chamado Direct Boot . A inicialização direta permite que dispositivos criptografados sejam inicializados 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, evitando que o telefone realizasse todas as operações, exceto as mais básicas. Por exemplo, os alarmes não funcionavam, 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 do discador 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 dentro de um contexto limitado. Isso pode acontecer antes que os usuários forneçam suas credenciais e, ao mesmo tempo, proteja 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 os aplicativos:Armazenamento criptografado por credencial (CE), que é o local de armazenamento padrão e só está disponível após o usuário desbloquear 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 desbloquear 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 Direct Boot 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 que fornece 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 explorar maneiras de otimizar o recurso com base no sistema no chip (SoC) usado.

Todos os pacotes necessários no AOSP foram atualizados para reconhecer a inicialização direta. No entanto, onde os fabricantes de dispositivos usam versões personalizadas desses aplicativos, eles vão querer garantir, no mínimo, que haja pacotes de inicialização direta fornecendo 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, em que 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 mudanças para usar os recursos de criptografia baseada em arquivo no kernel, muitos pacotes de 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 (packages / apps / Dialer)

Desk Clock (pacotes / apps / DeskClock)

LatinIME (packages / inputmethods / LatinIME) *

Aplicativo de configurações (pacotes / aplicativos / Configurações) *

SystemUI (frameworks / base / packages / SystemUI) *

* Aplicativos de sistema que usam o atributo de manifesto

Mais exemplos de aplicativos e serviços que reconhecem criptografia podem ser encontrados executando o comando mangrep directBootAware no diretório de estruturas ou pacotes da árvore de origem do 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.

O Keymaster / Keystore e o Gatekeeper devem ser implementados em um Trusted Execution Environment (TEE) para fornecer proteção para as chaves DE, de forma que um SO não autorizado (SO personalizado instalado no dispositivo) não possa simplesmente solicitar as chaves DE.

A raiz de hardware de confiança e inicialização verificada associada à inicialização do keymaster é necessária para garantir que as credenciais de criptografia do dispositivo não sejam acessíveis por um sistema operacional não autorizado.

Observação : as políticas de armazenamento são aplicadas a uma pasta e a todas as suas subpastas. Os fabricantes devem limitar o conteúdo não criptografado à pasta OTA e à pasta que contém a chave que descriptografa o sistema. A maioria dos conteúdos deve residir em armazenamento criptografado por credencial, em vez de armazenamento criptografado por dispositivo.

Implementação

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

Suporte Kernel

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

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

Se o seu dispositivo for compatível com 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 (Extensões de Criptografia) 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 inline seja usada quando o hardware e o suporte do driver do fornecedor estiverem disponíveis. A estrutura de criptografia inline pode ser ativada 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 criptografia baseada em arquivo

Habilitar o FBE em um dispositivo requer habilitá-lo no armazenamento interno (dados do 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 é habilitado adicionando a opção fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] à coluna fs_mgr_flags da linha fstab para dados do 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 ou adiantum . Se não for especificado, o padrão é aes-256-cts se o contents_encryption_mode for aes-256-xts , ou adiantum se o contents_encryption_mode for adiantum .

O parâmetro flags , novo no Android 11, é uma lista de sinalizadores separados pelo caractere + . Os seguintes sinalizadores são suportados: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 que é otimizado para hardware de criptografia em linha que não manipula 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 IV que limita IVs a 32 bits. Este sinalizador deve ser usado apenas em hardware de criptografia em linha que seja compatível com a especificação JEDEC eMMC v5.2 e, portanto, suporte apenas IVs de 32 bits. Em outro hardware de criptografia inline, 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 wrappedkey_v0 hardware , o sinalizador wrappedkey_v0 permite o uso de chaves wrappedkey_v0 por hardware para FBE. Isso só pode ser usado em combinação com a opção de montagem inlinecrypt e com o 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 embutida, a configuração recomendada para a maioria dos dispositivos é fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (ou equivalentemente fileencryption=::inlinecrypt_optimized ). Em dispositivos sem qualquer forma de aceleração de AES, Adiantum pode ser usado em vez de AES configurando fileencryption=adiantum .

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çando com Android 11 ou superior, este modo não é mais permitido e um formato de criptografia padrão deve ser usado em seu lugar.Cuidado : Como a opção fileencryption define o formato do disco, ela não pode ser alterada por um OTA.

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 ser semelhante a: /dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimizedNota :Os inlinecrypt e fileencryption opções de ir em colunas diferentes, desde inlinecrypt é um sistema de arquivos opção de montagem enquanto fileencryption é uma bandeira para o espaço do usuário Android.

Se o seu hardware de criptografia inline funcionar corretamente e o sinalizador wrappedkey_v0 não estiver definido, a opção de montagem inlinecrypt pode ser adicionada ou removida a qualquer momento sem limpar o dispositivo. Em outras palavras, a menos que as chaves inlinecrypt hardware estejam habilitadas, o inlinecrypt deve afetar apenas a implementação, não o formato do disco. Você deve testar a remoção inlinecrypt durante o desenvolvimento para verificar se o hardware de criptografia em linha está a funcionar correctamente.

Armazenamento adotável

Desde o Android 9, o FBE e o armazenamento adotável podem ser usados ​​juntos.

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

Em dispositivos iniciados 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 que o argumento da opção fstab fileencryption e usa os mesmos padrões. Consulte as recomendações para fileencryption de fileencryption acima para fileencryption 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 iniciados 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 dos 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 explicitamente sobrescrito para 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 .Cuidado : Em dispositivos iniciados com Android 10 ou inferior, o modo de criptografia de nomes de arquivo padrão no armazenamento adotável não era válido na maioria dos dispositivos e era diferente do modo padrão no armazenamento interno. Portanto, em tais dispositivos, deve ser explicitamente substituído, geralmente para aes-256-cts .

Integrando com Keymaster

A geração de chaves e o gerenciamento do chaveiro do kernel são vold por vold . A implementação AOSP de FBE requer que o dispositivo suporte Keymaster HAL versão 1.0 ou posterior. Não há suporte para versões anteriores do Keymaster HAL.

Na primeira inicialização, as chaves do usuário 0 são geradas e instaladas no início do processo de inicialização. No momento on-post-fs fase on-post-fs do init concluída, o Keymaster deve estar pronto para lidar com as solicitações. Em dispositivos Pixel, isso é tratado por um bloco de script que garante que o Keymaster seja iniciado antes que /data seja montado.

Política de criptografia

A criptografia baseada em arquivo aplica a política de criptografia no nível do diretório. Quando a partição de dados do userdata um dispositivo é criada pela primeira vez, as estruturas e políticas básicas são aplicadas pelos scripts de init . Esses scripts irão acionar a criação das chaves CE e DE do primeiro usuário (usuário 0), bem como definir quais diretórios devem ser criptografados com essas chaves. Quando usuários e perfis adicionais são criados, as chaves adicionais necessárias são geradas e armazenadas no armazenamento de chaves; suas credenciais e locais de armazenamento de dispositivos são criados e a política de criptografia vincula essas chaves a esses diretórios.

No Android 11 e superior, a política de criptografia não é mais codificada em um local centralizado, mas sim definida por argumentos para os comandos mkdir nos scripts de inicialização. Os diretórios criptografados com a chave DE do sistema usam encryption=Require , enquanto os diretórios não criptografados (ou diretórios cujos subdiretórios são criptografados com chaves por usuário) usam encryption=None .

No Android 10, a política de criptografia foi codificada neste 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 evitar que certos diretórios sejam criptografados. Se modificações desse tipo forem feitas, o fabricante do dispositivo deve incluir políticas SELinux que apenas concedam acesso 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 é no suporte de recursos OTA legados.

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

Tornando os aplicativos cientes da inicialização direta

Para facilitar a migração rápida de aplicativos do sistema, existem 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.

android:directBootAware="true"

android:defaultToDeviceProtectedStorage="true">

O atributo directBootAware no nível do aplicativo é uma forma abreviada para marcar todos os componentes no aplicativo como sendo compatíveis com 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 este 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 esta 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 .

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 serão capazes de acessar apenas diretórios criptografados com CE para usuários que já estão desbloqueados.

Um aplicativo pode interagir livremente nas áreas de DE, mas um usuário desbloqueado não significa que todos os usuários do dispositivo estão desbloqueados. O aplicativo deve 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 Keymaster (em TEE) pode fornecer a chave TEE do perfil.

Lidando com atualizações

A partição de recuperação não pode acessar o armazenamento protegido por DE na partição de dados do usuário. Dispositivos que implementam FBE são altamente recomendados para oferecer suporte a OTA usando atualizações de sistema A / B. Como a OTA pode ser aplicada 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 legada, que requer recuperação para acessar o arquivo OTA na partição de dados do userdata :Crie um diretório de nível superior (por exemplo, misc_ne ) na partição userdata .

Adicione este diretório de nível superior à exceção da política de criptografia (consulte Política de criptografia acima).

Crie um diretório dentro do diretório de nível superior para conter os pacotes OTA.

Adicione uma regra SELinux e contextos de arquivo para controlar o acesso a esta pasta e seu conteúdo. Apenas o processo ou aplicativos que recebem atualizações OTA devem ser capazes de ler e gravar nesta pasta. Nenhum outro aplicativo ou processo deve ter acesso a esta pasta.

Validação

Para garantir que a versão implementada do recurso funcione conforme o esperado , primeiro execute os diversos 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 habilitado:Verifique se ro.crypto.state existeCertifique-se de que ro.crypto.state esteja criptografado

Verifique se ro.crypto.type existeCertifique-se de que ro.crypto.type esteja definido como file

Além disso, os testadores podem inicializar uma instância de 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 que /data/data contém nomes de arquivos criptografados; se não, algo está errado.

Os fabricantes de dispositivos também são incentivados a explorar a execução de 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 de implementação de 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 FBE e inicialização direta em seus dispositivos.

criptografia fscrypt

A implementação AOSP usa 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 arquivo 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.

Para obter mais informações sobre fscrypt, consulte a documentação do kernel upstream .

Derivação chave

As chaves de criptografia baseadas em arquivo, que são chaves de 512 bits, são armazenadas criptografadas por outra chave (uma chave AES-GCM de 256 bits) mantida no TEE. Para usar esta chave TEE, três requisitos devem ser atendidos:O token de autenticação

A credencial esticada

O “hash secdiscardable”

O token de autenticação é um token autenticado criptograficamente gerado pelo Gatekeeper quando um usuário efetua login com sucesso. O TEE se recusará a usar a chave a menos que o token de autenticação correto seja fornecido. Se o usuário não tiver credencial, nenhum token de autenticação será usado nem necessário.

A credencial esticada é a credencial do usuário após salgar e esticar com o algoritmo scrypt . A credencial é realmente hash uma vez no serviço de configurações de bloqueio antes de ser passada para vold para passar para scrypt . Este é criptograficamente vinculado à chave no TEE com todas as garantias que se aplicam a KM_TAG_APPLICATION_ID . Se o usuário não tiver credencial, nenhuma credencial expandida será usada nem necessária.

O secdiscardable hash é um secdiscardable hash 512 bits de um arquivo aleatório de 16 KB armazenado junto com outras informações usadas para reconstruir a chave, como a semente. Este arquivo é excluído com segurança quando a chave é excluída ou é criptografado de uma nova maneira; essa proteção adicional garante que um invasor deve recuperar cada bit desse arquivo excluído com segurança para recuperar a chave.

Na maioria dos casos, as chaves FBE também passam por uma etapa de derivação de chave adicional no kernel para gerar as subchaves realmente usadas para fazer a criptografia, por exemplo, chaves por arquivo ou por modo. Para as políticas de criptografia da versão 2, HKDF-SHA512 é usado para isso.