O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

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.

Inicialização direta

Criptografia baseada em arquivo permite que um novo recurso introduzido no Android 7.0 chamado direto de inicialização . 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 necessários para fornecer credenciais antes de quaisquer dados podem ser acessados, impedindo o telefone de executar todos, mas o mais básico de operações. 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á alterações no ciclo de vida do aplicativo para acomodar a necessidade de notificar aplicações quando o armazenamento CE de um usuário é desbloqueado em resposta às primeiras credenciais de efectuarem a tela de bloqueio, ou no caso do perfil de trabalho proporcionando um desafio 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

Android proporciona uma implementação de referência de criptografia baseado em arquivo, em que vold ( sistema / vold ) proporciona a funcionalidade para gerir os dispositivos de armazenamento e volumes em 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 do núcleo muda de usar os de criptografia baseados em arquivos capacidades no kernel, muitos pacotes do sistema, incluindo o lockscreen eo SystemUI foram modificados para suportar o FBE e Direct Bota apresenta. 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) *

* Aplicações do sistema que usam o defaultToDeviceProtectedStorage atributo manifesto

Mais exemplos de aplicações e serviços que são criptografia ciente pode ser encontrado executando o comando mangrep directBootAware nos quadros ou pacotes diretório da árvore fonte AOSP.

Dependências

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

  • Suporte Kernel para criptografia Ext4 ou criptografia F2FS.
  • Suporte Keymaster com um HAL versão 1.0 ou 2.0. Não há suporte para Keymaster 0.3, pois ele não fornece os recursos necessários ou garante proteção suficiente para chaves de criptografia.
  • Keymaster / Keystore e Gatekeeper deve ser implementado em um Trusted Execution Environment (TEE) para fornecer proteção para as chaves DE modo que um sistema operacional não autorizado (personalizado OS brilhou no dispositivo) não pode simplesmente pedir as chaves DE.
  • Root Hardware of Trust and Verified Bota vinculado à inicialização keymaster é necessária para garantir que as credenciais de criptografia de dispositivos não são acessíveis para um sistema operacional não autorizado.

Nota: As políticas de armazenamento são aplicadas a uma pasta e 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, recursos de acessibilidade deve ser feita android: directBootAware acordo com direto Bota documentação do desenvolvedor.

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 dispositivo irá apoiar armazenamento adoptáveis ou usará criptografia metadados no armazenamento interno, também permitem que as opções de configuração do kernel necessários para criptografia de metadados conforme descrito na documentação de criptografia 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 consumo de energia, fabricantes de dispositivos também pode considerar a implementação de hardware de criptografia em linha, que criptografa / descriptografa os dados enquanto ele está a 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

Permitindo FBE num dispositivo requer permitindo-o na memória interna ( 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

FBE é activada através da adição da opção fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] para a coluna fs_mgr_flags do fstab linha 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:

  • Os contents_encryption_mode define parâmetros que algoritmo de criptografia é usado para criptografar o conteúdo do arquivo. Ela pode ser tanto aes-256-xts ou adiantum . Desde Android 11 também pode ser deixado vazio para especificar o algoritmo padrão, que é aes-256-xts .
  • Os filenames_encryption_mode define parâmetros que algoritmo de criptografia é usada para nomes de arquivos criptografados. Ela pode ser tanto aes-256-cts , aes-256-heh , ou adiantum . Se não for especificado, o padrão é aes-256-cts se contents_encryption_mode é aes-256-xts , ou para adiantum se contents_encryption_mode é adiantum .
  • O flags de parâmetros, de novo no Android 11, é uma lista de sinalizadores separados pelo + personagem. Os seguintes sinalizadores são suportados:
    • O v1 políticas versão 1 de criptografia bandeira seleciona; o v2 versão 2 políticas de criptografia bandeira seleciona. Versão 2 políticas de criptografia usar um mais seguro e flexível função de derivação de chaves . O padrão é v2 se o dispositivo lançado em Android 11 ou superior (conforme determinado pelo ro.product.first_api_level ), ou v1 se o dispositivo lançado em Android 10 ou inferior.
    • O inlinecrypt_optimized bandeira seleciona um formato de criptografia que é otimizado para hardware de criptografia embutida que não lidar com um grande número de chaves de forma eficiente. 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 emmc_optimized bandeira é semelhante ao inlinecrypt_optimized , mas também selecciona um método de geração de IV que limita IVs para 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 em linha, use inlinecrypt_optimized vez. 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 suportam chaves envolto em hardware , o wrappedkey_v0 bandeira permite o uso de chaves-embrulhado hardware para FBE. Isso só pode ser usado em combinação com o inlinecrypt opção de montagem, e quer o inlinecrypt_optimized ou emmc_optimized bandeira.

Se você não estiver usando criptografia de hardware in-line a configuração recomendada para a maioria dos dispositivos é fileencryption=aes-256-xts . Se você estiver usando criptografia de hardware in-line 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 AES, Adiantum pode ser utilizado em vez da AES, definindo fileencryption=adiantum .

Em dispositivos que lançaram com Android 10 ou inferior, fileencryption=ice também é aceito para especificar o uso do FSCRYPT_MODE_PRIVATE modo de criptografia conteúdo do arquivo. 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.

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 em linha em vez disso, também adicionar o inlinecrypt opção de montagem. Por exemplo, uma completa fstab linha pode parecer:

/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 Android 9, FBE e armazenamento adoptáveis 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 o FBE e / ou formatos de codificação de metadados no armazenamento adoptáveis 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) Selecciona o formato de criptografia FBE no armazenamento adoptáveis. Ele tem a mesma sintaxe que o argumento para o fileencryption opção fstab, e ele usa os mesmos padrões. Veja as recomendações para fileencryption acima para o que usar aqui.
  • ro.crypto.volume.metadata.encryption seleciona o formato de criptografia de metadados no armazenamento adoptáveis. Veja a documentação criptografia metadados .

Em dispositivos iniciados com Android 10 ou inferior, use as seguintes propriedades:

  • ro.crypto.volume.contents_mode selecciona o modo de criptografia de conteúdos. Isto é equivalente ao primeiro campo separados por dois pontos de ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode selecciona o modo de criptografia de nomes de ficheiros. Isto é equivalente ao segundo campo separados por dois pontos de ro.crypto.volume.options , excepto que a padrão em dispositivos que lançado com Android 10 ou inferior é aes-256-heh . Na maioria dos dispositivos, isso precisa ser explicitamente substituído para aes-256-cts .
  • ro.crypto.fde_algorithm e ro.crypto.fde_sector_size selecionar o formato de criptografia de metadados no armazenamento adoptáveis. Veja a documentação criptografia metadados .

Integrando com Keymaster

A geração de chaves e gestão do chaveiro do kernel é tratado 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. Até o momento o on-post-fs fase de init for concluída, o Keymaster deve estar pronto para lidar com as solicitações. Em dispositivos de pixel, isto é tratado por ter um bloco de script assegurar Keymaster é iniciado antes /data está montado.

Política de criptografia

A criptografia baseada em arquivo aplica a política de criptografia no nível do diretório. Quando de um dispositivo userdata partição é criada pela primeira vez, as estruturas e políticas básicas são aplicadas pelos init scripts. 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.

Em Android 11 e superior, a política de criptografia não é mais codificado em um local centralizado, mas é definida por argumentos para os mkdir comandos nos scripts de inicialização. Directórios criptografados com o sistema de utilização chave DE encryption=Require , enquanto directórios não encriptada (ou directórios cuja subdirectórios são cifradas com chaves por utilizador) uso 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 as modificações desse tipo são feitas, em seguida, o fabricante do dispositivo deve incluir políticas do SELinux que só concedem acesso aos aplicativos que precisam usar o diretório não encriptado. 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 defaultToDeviceProtectedStorage atributo está disponível apenas para aplicativos do sistema. O directBootAware atributo está disponível para todos.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

O directBootAware atributo no nível do aplicativo é um atalho para a marcação de todos os componentes do aplicativo como sendo criptografia conscientes.

O defaultToDeviceProtectedStorage atributo redireciona o local de armazenamento aplicativo padrão para apontar para 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. Este é pertinente para a administração de dispositivos usos.

Aplicações Crypto-aware interagir entre os usuários desta maneira: INTERACT_ACROSS_USERS e INTERACT_ACROSS_USERS_FULL permitir que um aplicativo para atuar em todos os usuários do 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 ser capaz de interagir livremente nas áreas de DE, mas um usuário desbloqueado não significa que todos os usuários no 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 execução FBE são fortemente recomendados para apoio OTA usando atualizações do 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 legado, que exige a recuperação para acessar o arquivo OTA na userdata partição:

  1. Crie um diretório de nível superior (por exemplo misc_ne ) na userdata partição.
  2. Adicionar este diretório de nível superior para a exceção política de criptografia (ver política Encryption acima).
  3. Crie um diretório dentro do diretório de nível superior para conter os pacotes OTA.
  4. 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 a versão implementada do recurso funciona como pretendido, primeiro executar muitos testes de criptografia CTS, como DirectBootHostTest e EncryptionTest .

Se o dispositivo está rodando o Android 11 ou superior, também executar 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 existe
    • Garantir ro.crypto.state é criptografada
  • Verifique se ro.crypto.type existe
    • Garantir ro.crypto.type está definido para file

Além disso, os testadores podem arrancar um userdebug exemplo com um conjunto lockscreen sobre o usuário principal. Então adb shell no dispositivo e uso su para se tornar root. Certifique-se de /data/data contém nomes de arquivos criptografados; se não, algo está errado.

Fabricantes de dispositivos também são incentivados a explorar executando os testes de Linux a montante 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

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

Para 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 auth token é uma cryptographically autenticado sinal gerado pelo Gatekeeper quando um usuário fizer logon com êxito. O TEE irá se recusar a usar a chave a menos que o token de autenticação correto é fornecido. Se o usuário não tiver credencial, nenhum token de autenticação será usado nem necessário.

A credencial é esticada a credencial utilizador após salga e de alongamento com o scrypt algoritmo. A credencial é realmente hash vez em serviço o bloqueio configurações antes de ser passado para vold para passar para scrypt . Esta é criptograficamente vinculado a uma 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 hash de um arquivo de 16 KB aleatória armazenado ao lado de outras informações utilizadas para reconstruir a chave, tais como a semente de 512 bits. 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. Esta é criptograficamente vinculado a uma chave no TEE com todas as garantias que se aplicam a KM_TAG_APPLICATION_ID .

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.