Hoje em dia, carregamos grande parte de nossas vidas em nossos celulares: fotos pessoais, conversas privadas, documentos de trabalho, senhas salvas, aplicativos bancários… Perder o celular ou tê-lo roubado sem que seus dados estejam protegidos. Isso pode se transformar em um verdadeiro desastre, tanto pessoal quanto profissionalmente, por isso é importante saber como tomar medidas para... fortalecer a segurança.
Para minimizar esse risco, o Android incorpora há anos diversos mecanismos de criptografia que vão muito além de um simples PIN ou padrão de desbloqueio. Criptografia de disco e criptografia baseada em arquivos, juntamente com inicialização verificada e chaves protegidas por hardware.Eles formam um ecossistema complexo projetado de forma que, mesmo que alguém tenha o dispositivo em mãos, não consiga ler as informações sem as credenciais adequadas. Se precisar fazer isso, consulte Como criptografar seu celular.
O que é criptografia de dados no Android e por que ela é tão importante?
Quando falamos em criptografar um dispositivo Android, estamos nos referindo ao processo de transformar todos os dados armazenados em informações ilegíveis Se você não tiver a chave correta. Em termos práticos, é como colocar todo o conteúdo do seu telefone dentro de um cofre digital que só pode ser aberto com seu PIN, padrão, senha ou fator biométrico.
Essa criptografia protege tanto dados pessoais (fotos, vídeos, mensagens, arquivos baixados) quanto dados corporativos. Em ambientes empresariais, é um elemento fundamental para o cumprimento de regulamentações como o GDPR europeu ou o HIPAA nos EUA.Isso reduz significativamente o risco de vazamento de dados caso um terminal contendo informações de clientes, registros médicos, documentos legais ou credenciais de acesso VPN internas seja perdido ou roubado. Além disso, a manutenção apoio Isso impede que a perda do dispositivo resulte na perda total das informações.
Vale ressaltar que apenas o bloqueio de tela não é suficiente. Um PIN sem criptografia apenas impede que alguém use a interface do telefone, mas Se o armazenamento não estiver criptografado, um invasor poderá extrair fisicamente os dados. Copiar o conteúdo da memória usando ferramentas forenses ou vulnerabilidades do bootloader. Além disso, usar um Aplicativo de segurança Prey Pode ajudar a localizar e gerenciar um dispositivo perdido ou roubado, complementando a criptografia.
Com a criptografia ativada, os dados armazenados são salvos em um formato matematicamente incompreensível sem a chave. Mesmo que alguém copie a partição de dados byte a byte ou inicialize um sistema modificadoO que você vai obter são apenas blocos de dados criptografados sem sentido.
Da criptografia de disco completo à criptografia baseada em arquivos.
Historicamente, o Android passou por duas abordagens principais para a criptografia de dispositivos: Criptografia de disco completo (FDE) e criptografia baseada em arquivos (FBE)Entender a diferença ajuda muito a compreender o que está sendo protegido em determinado momento e por que certas funções continuam funcionando mesmo quando o telefone está "bloqueado".
A criptografia de disco completo foi introduzida no Android 4.4 (API 19) e ganhou força real com o Android 5.0 (API 21). Nesse modelo, Toda a partição de dados do usuário é protegida com uma única chave.Essa chave é derivada das credenciais do usuário, portanto o sistema não pode acessar nada em /data até que você insira seu PIN, padrão ou senha na inicialização.
Essa abordagem é muito robusta do ponto de vista da privacidade, mas tem uma desvantagem clara: Praticamente todo o sistema permanece inoperante até ser desbloqueado pela primeira vez após a inicialização.Não há acesso a alarmes, muitos serviços não iniciam e o telefone sequer consegue receber chamadas normais, apenas de emergência, porque a camada telefônica ainda não tem acesso aos seus dados.
Para resolver esse problema, o Google redesenhou todo o esquema de criptografia no Android 7.0 Nougat (API 24), introduzindo a criptografia baseada em arquivos (FBE). Nesse modelo, Cada arquivo pode ser protegido com uma chave diferente.Isso permite que diferentes partes do sistema sejam desbloqueadas independentemente, dependendo da credencial fornecida.
A FBE também traz o chamado modo de Inicialização diretaIsso permite que o dispositivo inicialize diretamente na tela de bloqueio e possibilita que alguns aplicativos funcionem em um contexto limitado antes que o usuário insira seu PIN ou senha.
Como funcionam o modo de partida direta e a separação CE/DE
A principal mudança conceitual no FBE é que, em um dispositivo de criptografia baseado em arquivos, Cada usuário do sistema possui duas áreas de armazenamento separadas.com chaves diferentes e tempos de desbloqueio diferentes.
O primeiro é o Armazenamento criptografado de credenciais (CE)Este é o local de armazenamento padrão para dados de usuários e aplicativos, e só é desbloqueado após o usuário inserir suas credenciais na inicialização. É aqui que todos os dados realmente sensíveis devem ser armazenados: bancos de dados de aplicativos, documentos pessoais, backups locais de e-mails, etc.
O segundo é o Armazenamento criptografado no dispositivo (DE)Esta área está disponível tanto no modo de inicialização direta (antes do usuário fazer login) quanto depois, e é criptografada com uma chave vinculada ao dispositivo, que fica disponível assim que o sistema é iniciado com sucesso. É a área destinada a dados que precisam estar acessíveis mesmo antes do primeiro desbloqueio: notificações básicas, serviços do telefone, alguns recursos de acessibilidade, aplicativos de alarme ou o método de login da tela de bloqueio.
Idealmente, Se um aplicativo precisar funcionar antes que o usuário desbloqueie o dispositivo (por exemplo, um despertador ou um discador de telefone), armazene em DE apenas o que for estritamente necessário para essa função básica e mantenha qualquer informação pessoal ou crítica em CE.
Na verdade, a recomendação do Google é clara: Sempre que possível, os arquivos devem residir no CE.O armazenamento DE destina-se a configurações mínimas e dados efêmeros, não a conteúdo sensível como listas de contatos completas, históricos de bate-papo ou documentos da empresa.
Requisitos técnicos e a obrigatoriedade da criptografia no Android moderno
O Android 7.0 permite a restauração de sistemas baseados em arquivos (FBE), e a partir do Android 10 o Google a exige. Todos os dispositivos lançados com essa versão ou posterior usarão criptografia baseada em arquivos.Em telefones sem aceleração de criptografia AES por hardware, o algoritmo Adiantum é usado para manter um bom desempenho.
Para implementar corretamente o FBE, o fabricante deve atender a vários requisitos de baixo nível. Por um lado, O kernel Linux do dispositivo deve suportar a camada de criptografia do sistema de arquivos fscrypt. Para ext4 ou F2FS (as duas opções comuns para /data no Android). Em kernels modernos, basta habilitar opções como CONFIG_FS_ENCRYPTION e, se desejar aproveitar a criptografia embutida, CONFIG_FS_ENCRYPTION_INLINE_CRYPT.
Também é necessário ter KeyMint ou pelo menos Keymaster 1.0E com o Gatekeeper, executado em um Ambiente de Execução Confiável (TEE). Dessa forma, as chaves de criptografia vinculadas ao dispositivo e ao usuário ficam protegidas contra sistemas operacionais não autorizados e kernels modificados que tentam inicializar com o bootloader desbloqueado.
O dispositivo também deve ter um raiz de confiança de hardware e inicialização verificada Isso está relacionado ao processo de inicialização do KeyMint, que impede o acesso não autorizado às chaves de criptografia (DE) do dispositivo. Em outras palavras, mesmo que um firmware modificado seja instalado, o hardware de segurança se recusa a liberar as chaves se a cadeia de inicialização não for legítima.
No nível de configuração, a criptografia FBE é habilitada editando o arquivo fstab do dispositivo para a partição de dados do usuário. Uma opção é especificada nesse arquivo. criptografia de arquivo=… que define o algoritmo de criptografia de conteúdo (geralmente aes-256-xts ou Adiantum), o algoritmo de nomenclatura de arquivos (aes-256-cts, aes-256-heh, aes-256-hctr2 ou adiantum) e uma série de flags opcionais (v1/v2, inlinecrypt_optimized, emmc_optimized, wrappedkey_v0, dusize_4k).
Quais partes do sistema são criptografadas e como as chaves são organizadas?
Em um sistema Android com FBE configurado corretamente, /data é organizado em diferentes “classes de armazenamento” dependendo da chave que os protege e do momento em que se tornam acessíveis.
Existem diretórios que não são criptografados com FBE (embora em muitos casos sejam criptografados com criptografia de metadados), como por exemplo: /data/apex (exceto alguns subdiretórios), /data/lost+found, /data/preloads ou /data/unencrypted. Esses são caminhos onde componentes ou estruturas do sistema que não precisam ser vinculados a credenciais de usuário são armazenados.
Depois, há a classe de Sistema deEsta categoria agrupa dados criptografados por dispositivo que não pertencem a um usuário específico: /data/app, /data/misc, /data/system, /data/vendor e outros subdiretórios de /data. Há também uma classe "per_boot" (/data/per_boot) para arquivos efêmeros que não precisam persistir após reinicializações.
Rotas específicas para CE e DE são criadas para cada usuário: /data/user/${user_id}, /data/system_ce/${user_id}, /data/misc_ce/${user_id}, /data/vendor_ce/${user_id} Para CE interno; e /data/user_de/${user_id}, /data/system_de/${user_id}, /data/misc_de/${user_id}, /data/vendor_de/${user_id} para DE interno. Se houver armazenamento adaptável (cartão SD transformado em uma extensão da memória interna), estruturas semelhantes são replicadas em /mnt/expand/${volume_uuid}/.
O gerenciamento de chaves é feito pelo vold, o daemon de volume do Android. Vold gerencia as chaves FBE e as armazena criptografadas em disco. (exceto pela chave "na inicialização", que é derivada a cada vez e nunca é salva). Por exemplo, as chaves internas do usuário CE e DE são armazenadas em /data/misc/vold/user_keys/ce/${user_id} e /data/misc/vold/user_keys/de/${user_id}, respectivamente, protegidas por chaves armazenadas no Keystore dentro do TEE.
Com exceção das chaves CE de armazenamento interno, as demais chaves FBE são criptografadas com AES-256-GCM usando chaves Keystore que não saem do ambiente seguro. Além disso, são utilizadas técnicas como resistência ao rollback e arquivos "secdiscardable". para garantir que a exclusão de uma chave seja verdadeiramente permanente, mesmo contra tentativas de restaurar estados anteriores do sistema.
Relação entre bloqueio de tela, senha sintética e chaves CE
As chaves CE de armazenamento interno possuem um nível adicional de proteção, pois são elas que efetivamente impedem que um invasor, mesmo com controle do sistema, descriptografe seus dados sem sua senha. O Android introduz aqui o conceito de senhas sintéticas.: um segredo de alta entropia, gerado aleatoriamente pelo sistema para cada usuário, que nunca é inserido diretamente, mas é protegido com um PIN, padrão ou senha de bloqueio (LSKF).
O serviço LockSettingsService, no servidor system_server, gerencia essa senha sintética. Ao configurar ou alterar seu PIN ou senha de telaO sistema pega esse LSKF, passa-o pelo scrypt (para reforçá-lo um pouco) e o usa para interagir com o Weaver ou o Gatekeeper, dependendo do hardware do dispositivo.
Em dispositivos com Weaver habilitado, a LSKF reforçada é associada a um segredo aleatório de alta entropia armazenado em um elemento seguro (SE) ou no TEE. A senha sintética é então criptografada duas vezes: primeiro com uma chave derivada da LSKF e do segredo Weaver e, em seguida, com uma chave do keystore. Isso introduz um limite de taxa de tentativas imposto por hardware para adivinhar a senha, evitando ataques rápidos de força bruta.
Em dispositivos sem o Weaver, o LSKF reforçado é usado com o Gatekeeper e, novamente, a senha sintética é criptografada primeiro com uma chave derivada do LSKF e um arquivo descartável e, em seguida, com uma chave do Keystore vinculada à autenticação no Gatekeeper. O resultado é que as chaves CE não podem ser desbloqueadas sem superar essas proteções.mesmo que seja feita uma tentativa com um sistema modificado ou uma inicialização alternativa.
Ao alterar seu PIN ou senha de cadeado, o serviço LockSettingsService Isso remove a ligação anterior entre LSKF e senha sintética.Em dispositivos com suporte à reversão de inversão de polaridade, isso impede a reutilização de associações antigas, reforçando ainda mais o modelo de segurança.
A criptografia ainda está protegida com um bootloader desbloqueado ou com acesso root?
Isso nos leva a um dos pontos que gera mais debate entre os usuários avançados. Em teoria, um sistema de criptografia "bem projetado" não deveria ser quebrado apenas porque o bootloader foi desbloqueado. ou porque você obtém um shell ADB com privilégios de root: contanto que você não tenha a chave derivada da senha do usuário, os dados devem permanecer ilegíveis.
Na prática, o modelo Android moderno busca duas coisas: por um lado, que As chaves CE não podem ser obtidas sem o LSKF.Isso se deve ao uso combinado de TEE/SE, Gatekeeper/Weaver e Keystore; e também porque a inicialização verificada bloqueia o acesso às chaves do ambiente de desktop se um sistema não confiável for detectado. No entanto, existem nuances importantes.
Uma delas é que, em dispositivos com FBE, Parte do conteúdo em /data pode estar disponível em alemão (DE) mesmo antes de inserir o PIN.Isso inclui estruturas internas, arquivos auxiliares e até mesmo certos diretórios em /data/misc, /data/system ou locais semelhantes que, embora criptografados no disco, são descriptografados após a inicialização, pois a chave DE está disponível sem interação do usuário.
Em alguns experimentos práticos, observou-se, por exemplo, que em um Moto X4 com LineageOS 16 (Android 9), FBE ativo e cartão SD habilitado, /data já aparece montado quando você chega à tela de bloqueio.A partir de um shell root ADB, alguns arquivos específicos podem ser extraídos sem a necessidade de inserir a senha. Outros, no entanto, falham ou parecem inacessíveis, indicando que estão corretamente vinculados ao CE.
Mais grave ainda é que, se as licenças e as políticas não forem devidamente ajustadas, É possível ler determinadas chaves associadas a volumes adaptáveis em /data/misc/vold, como o cartão SD criptografado. Com essa chave, é possível acessar e descriptografar o volume fora do telefone, tornando a criptografia do cartão inútil.
Esses tipos de situações não são tanto uma falha no projeto do FBE em si, mas erros de implementação ou configurações inseguras Em ROMs personalizadas, recuperações modificadas ou dispositivos onde o fabricante não seguiu todas as recomendações (por exemplo, não isolar corretamente quem pode acessar /data/misc/vold, não aplicar o SELinux no modo estrito ou não separar corretamente os dados que devem ir para o CE), revise e ajuste o configurações de segurança ajuda a reduzir esses riscos.
Por que o Spotify, o YouTube ou as notificações ainda funcionam quando meu telefone está bloqueado?
Uma pergunta muito comum entre os usuários é: se “tudo fica criptografado” quando eu bloqueio meu telefone, Como é que as notificações ainda estão sendo enviadas, o Spotify ainda está funcionando ou as mensagens ainda estão sendo recebidas? Com a tela desligada e o dispositivo aparentemente protegido?
A chave está no modelo FBE e na distinção entre o estado de bloqueio de tela e o estado de desbloqueio de armazenamento. Após o primeiro desbloqueio após a inicialização, a maioria das chaves CE permanece disponível enquanto o dispositivo não for reiniciado.Bloquear a tela não criptografa tudo novamente do zero; simplesmente fecha o acesso lógico à interface e a certas APIs, mas o sistema ainda mantém as chaves na memória para poder funcionar.
Além disso, grande parte dos dados necessários para aplicativos como Spotify, YouTube ou serviços de notificação push são armazenados ou replicados em zonas DE, ou os aplicativos são marcados como “directBootAware” para Para poder funcionar com um subconjunto limitado de dados enquanto o usuário ainda não tiver inserido o PIN. após uma reinicialização. É por isso que você pode, por exemplo, receber uma chamada ou ouvir um alarme mesmo que o telefone tenha acabado de ser ligado e você ainda esteja na tela de bloqueio inicial.
A descriptografia não leva literalmente "1 segundo"; o que acontece é que O trabalho mais pesado já foi feito durante a inicialização e o primeiro desbloqueio.A partir daí, o sistema mantém as teclas ativas (até a próxima reinicialização) para não ter que recalcular tudo continuamente, o que tornaria a experiência do usuário insuportável.
Isso significa que, se um invasor obtiver privilégios elevados depois que o dispositivo já tiver sido desbloqueado após a inicialização (por exemplo, por meio de malware de root ou uma exploração do kernel), Ele poderia acessar muito mais informações do que se tentasse fazer isso logo após ligar o dispositivo, antes que alguém digitasse o PIN.Por isso é tão importante. forçar reinicialização Desbloqueie o dispositivo antes de entregá-lo aos controles de fronteira, técnicos de reparo ou em outras situações sensíveis e não o desbloqueie novamente.
O que os aplicativos do sistema podem e não podem fazer com a Inicialização Direta (Direct Boot).
Com a chegada do FBE, o Android introduziu novas APIs e atributos de manifesto para que os aplicativos saibam Em que estado de criptografia o dispositivo se encontra? e qual o espaço de armazenamento disponível em determinado momento.
No manifesto de um aplicativo, dois atributos relevantes podem ser declarados: android:directBootAware e android:defaultToDeviceProtectedStorage. O primeiro indica que todos os componentes do aplicativo estão cientes da criptografia e podem funcionar durante o modo de inicialização direta; o segundo faz com que o aplicativo, por padrão, use o armazenamento DE em vez do CE para seus dados.
Os aplicativos do sistema marcados com defaultToDeviceProtectedStorage devem Analise cuidadosamente as informações armazenadas nesse local. e transferir quaisquer dados que possam ser considerados pessoais ou sensíveis para a CE. Os fabricantes são responsáveis por não transferir históricos extensos, listas de contatos ou dados do usuário para a DE, mas sim por se limitarem às configurações mínimas necessárias para que o dispositivo funcione antes do primeiro desbloqueio.
Para lidar melhor com esses contextos, o Android fornece métodos como: Context.createCredentialProtectedStorageContext() e Context.isCredentialProtectedStorage(), que permitem que os aplicativos escolham explicitamente onde armazenar ou ler seus dados com base no status de criptografia e nas necessidades de privacidade.
Em dispositivos multiusuário com perfis de trabalho, a situação fica ainda mais complicada: Cada usuário e cada perfil de trabalho possui suas próprias chaves CE e DE.. Permissões de aplicativo Funcionalidades como INTERACT_ACROSS_USERS ou INTERACT_ACROSS_USERS_FULL permitem que certos aplicativos do sistema interajam entre usuários, mas só podem acessar o CE daqueles que já estão desbloqueados, adicionando mais uma camada de isolamento.
Criptografia de cartão SD e armazenamento expansível: pontos fortes e fracos
Ao usar um cartão SD como armazenamento expansível, o Android o trata como uma extensão criptografada da memória interna. O cartão é criptografado com uma chave que, em princípio, somente o próprio dispositivo deveria ser capaz de usar.e essa chave é armazenada criptografada junto com outras chaves de volume em caminhos como /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} ou /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}.
Desde o Android 9, o FBE (Future Business Enterprise) e o armazenamento adaptável são totalmente suportados e, a partir do Android 11, a forma de definir os formatos de criptografia de conteúdo e metadados é unificada por meio de propriedades do sistema, como... ro.crypto.volume.options ou ro.crypto.volume.metadata.encryption. Em versões anteriores, propriedades separadas eram usadas para modos de conteúdo e nomes de arquivos, e em muitos dispositivos o valor padrão para nomes em volumes adaptáveis não era recomendado, então ele precisava ser ajustado explicitamente.
Num mundo ideal, mesmo que alguém remova o cartão SD, Os dados devem permanecer inacessíveis sem a chave armazenada no telefone.Mas, novamente, se essa chave puder ser extraída de /data/misc/vold com um shell root devido a uma configuração incorreta do dispositivo, o modelo entra em colapso. Isso demonstra por que simplesmente "habilitar a criptografia" em teoria não é suficiente: é preciso acompanhá-la com políticas SELinux sólidas e um projeto de permissões cuidadoso.
Para cartões SD usados como armazenamento externo tradicional (não adaptável), muitos fabricantes oferecem uma opção de "criptografar cartão SD" em Configurações > Segurança. Normalmente, essa criptografia garante que apenas aquele dispositivo específico possa ler o conteúdo do cartão.O processo pode levar mais ou menos tempo dependendo do tamanho e da velocidade do cartão SD, mas, uma vez concluído, se você inserir o cartão em outro telefone ou computador, o conteúdo ficará ilegível. Além disso, também é recomendável manter backups na nuvem para garantir que as informações não sejam perdidas caso o cartão apresente falha.
Mesmo assim, se a abordagem principal não estiver devidamente definida, Extrair a chave do cartão SD do próprio telefone pode permitir que ela seja descriptografada externamente.Portanto, em contextos de alta segurança, muitas empresas recomendam não usar SD adaptável ou limitar seu uso apenas a dados não críticos.
Criptografia, desempenho e possíveis desvantagens
A criptografia tem um custo computacional: ler ou escrever dados criptografados envolve operar com algoritmos como AES-256-XTS ou Adiantum. Em dispositivos modernos com aceleração criptográfica por hardware (por exemplo, extensões ARMv8 CE em ARM64), o impacto no desempenho e no consumo de energia é muito pequeno e quase imperceptível.
Para maximizar o desempenho, os kernels comuns do Android incluem uma estrutura de criptografia em linhaIsso permite que certos controladores de armazenamento (UFS, eMMC) criptografem e descriptografem dados "em trânsito". Habilitar opções como CONFIG_BLK_INLINE_ENCRYPTION, CONFIG_SCSI_UFS_CRYPTO ou CONFIG_MMC_CRYPTO, juntamente com sinalizadores como inlinecrypt_optimized ou emmc_optimized, ajuda a minimizar a sobrecarga e prolongar a duração da bateria.
Em dispositivos mais antigos ou sem suporte para AES acelerado, a penalidade pode ser mais perceptível; portanto O Google vai projetar o Adiantum.Este é um esquema projetado para oferecer alta segurança em hardware modesto. Mesmo assim, alguns usuários podem experimentar uma leve queda no desempenho, especialmente se a criptografia for ativada manualmente em um dispositivo de baixo custo.
Outro ponto a ter em mente é que, Uma vez que o armazenamento é criptografado, geralmente não há como reverter sem uma restauração de fábrica.O formato de criptografia do disco é definido por opções como `fileencryption` no arquivo `fstab` e não pode ser alterado com uma simples atualização over-the-air (OTA). Se você deseja desativar a criptografia, a solução típica é excluir a partição de dados e começar do zero.
Em versões mais antigas do Android, algumas atualizações OTA tradicionais exigiam acesso da partição de recuperação aos dados localizados em /data, o que não é possível se essa área estiver protegida pelo ambiente de desktop. Nesses casos, alguns fabricantes optaram por... deixar um diretório de nível superior sem criptografia (por exemplo, /data/misc_ne) exclusivamente para armazenar pacotes de atualização, controlando com SELinux que somente o processo de atualização possa acessá-los.
Além dessas considerações técnicas, para o usuário médio, a principal "desvantagem" da criptografia é que, Se você esquecer seu PIN ou senha e não houver mecanismos de recuperação, as informações serão perdidas para sempre.Não existe uma porta dos fundos oficial: sem o LSKF e sem a possibilidade de derivar a senha sintética, as chaves CE não podem ser recuperadas.
Em última análise, toda essa estrutura torna a criptografia de disco e a proteção de dados sensíveis no Android muito mais sofisticadas do que parecem à primeira vista. Entre FDE e FBE, os espaços CE e DE, o TEE, KeyMint, Gatekeeper, fscrypt, criptografia de metadados e inicialização verificada.O sistema foi projetado de forma que um invasor não autorizado, mesmo que tenha o dispositivo em mãos e tente inicializar um software modificado ou usar o ADB com acesso root, encontrará extrema dificuldade em ler qualquer informação útil sem a senha do usuário, desde que o fabricante tenha seguido as recomendações e o usuário complemente isso com uma senha forte, atualizações em dia e bom senso ao instalar aplicativos.
