Criptografia de disco: o bom e o lento

Saiba mais sobre a adoção da criptografia completa de disco em dispositivos Android, onde ela teve sucesso e onde falhou!

Num mundo onde as informações pessoais são não é tão pessoal, contas bancárias inteiras estão ligadas aos nossos smartphones e a vigilância e o crime cibernético estão em alta, a segurança é um dos aspectos majoritários da esfera tecnológica.

Bloqueios de tela simples na forma de PINs e padrões já existem há muito tempo, mas só recentemente, com o lançamento do Android Honeycomb, a criptografia completa de disco apareceu no Android. Criptografar e descriptografar dados do usuário em tempo real, ou seja, durante operações de leitura e gravação, aumentou consideravelmente a segurança do dispositivo, com base em uma chave mestra do dispositivo.

Antes do Android Lollipop, a chave mestra mencionada era baseada apenas na senha do usuário, expondo-o a uma série de vulnerabilidades por meio de ferramentas externas como o ADB. No entanto, o Lollipop realiza criptografia completa do disco no nível do kernel, usando uma chave AES de 128 bits gerada inicialmente boot, que funciona em conjunto com autenticação baseada em hardware como TrustZone, livrando-o do ADB vulnerabilidade.

Criptografia de hardware versus software

A criptografia de disco pode ser feita em dois níveis diferentes, nomeadamente, ao nível do software ou ao nível do hardware. A criptografia de software usa a CPU para criptografar e descriptografar dados, seja usando uma chave aleatória desbloqueada pela senha do usuário ou usando a própria senha para autenticar as operações. Por outro lado, a criptografia de hardware utiliza um módulo de processamento dedicado para gerar a chave de criptografia, descarregando a carga da CPU e mantendo as chaves críticas e os parâmetros de segurança mais protegidos contra força bruta e inicialização a frio ataques.

Apesar dos SoCs Qualcomm mais recentes oferecerem suporte à criptografia de hardware, o Google optou pela criptografia baseada em CPU no Android, o que força os dados criptografia e descriptografia durante a E/S do disco, ocupando vários ciclos de CPU, com o desempenho do dispositivo sofrendo um sério impacto resultado. Com a criptografia obrigatória de disco completo do Lollipop, o Nexus 6 foi o primeiro dispositivo a suportar o impacto desse tipo de criptografia. Pouco depois de seu lançamento vários benchmarks mostraram resultados de um Nexus 6 normal versus um Nexus 6 com criptografia desativada usando imagens de inicialização modificadas e os resultados não foram bonitos, mostrando o dispositivo criptografado muito mais lento que o outro. Em nítido contraste, os dispositivos Apple suportam criptografia de hardware desde o iPhone 3GS, com o iPhone 5S passará a oferecer suporte à aceleração de hardware para criptografia AES e SHA1 apoiada por seu armv8 A7 de 64 bits chipset.

Criptografia e a linha Nexus

O Motorola Nexus 6 do ano passado foi o primeiro dispositivo Nexus a forçar a criptografia de software aos usuários, e o impacto que teve nas operações de leitura/gravação de armazenamento - tornando-as extremamente lentas - foi amplamente criticado. No entanto, em um Reddit AMA logo após o lançamento do Nexus 5X e do Nexus 6P, o vice-presidente de engenharia do Google, Dave Burke, afirmou que desta vez também, a criptografia foi baseada em software, citando os SoCs armv8 de 64 bits, enquanto prometia resultados mais rápidos que o hardware criptografia. Infelizmente, um revisão por AnandTech mostrou que, apesar de uma melhoria significativa em relação ao Nexus 6, o Nexus 5X teve um desempenho cerca de 30% pior do que o LG G4 em uma comparação direta, apesar de uma folha de especificações semelhante e do uso do eMMC 5.0 em ambos dispositivos.

Impacto na experiência do usuário

Apesar do Nexus 6, e aparentemente do Nexus 5X, sofrerem de problemas de E/S de disco devido à criptografia, as otimizações de software no Lollipop foram feitas em o departamento de desempenho, que tornou o Nexus 6 no Lollipop com criptografia completa de disco, sem dúvida mais rápido do que um Nexus 6 teórico rodando KitKat. No entanto, os usuários finais com visão de águia podem ocasionalmente notar uma leve falha ao abrir aplicativos que consomem muito disco, como a galeria, ou ao transmitir conteúdo local em 2K ou 4K. Por outro lado, a criptografia protege significativamente seus dados pessoais e protege você de programas como vigilância governamental, com a leve gagueira sendo a única compensação, então se isso é algo com o qual você pode conviver, a criptografia é definitivamente a maneira de ir.

OEMs e criptografia

Apesar da criptografia de dispositivos ser um mecanismo amplamente benevolente para os usuários finais, alguns OEMs esporadicamente a veem de uma forma menos favorável, sendo a mais notória entre eles a Samsung. O smartwatch Gear S2 do OEM sul-coreano e sua solução de pagamentos móveis, Samsung Pay, são incompatíveis com dispositivos Samsung criptografados... com o ex recusando-se a trabalhar e a último proibindo os usuários de adicionar cartões, informando aos usuários que a descriptografia completa do dispositivo é necessária para seu funcionamento. Dado que a criptografia aumenta muito a segurança do dispositivo, impedir que os usuários adicionem cartões é uma movimento aparentemente bizarro, com a segurança sendo um fator decisivo importante na adoção do pagamento móvel soluções.

É realmente necessário?

Para a maioria dos usuários, especialmente o grupo que exclui os usuários avançados, a criptografia é algo que eles provavelmente não encontrarão, muito menos permitirão de boa vontade. O FDE certamente protege os dados do dispositivo e os protege de programas de vigilância, embora com uma pequena compensação de desempenho. Embora o Gerenciador de dispositivos Android faça um trabalho decente ao limpar dados de dispositivos que caíram em mãos erradas, a criptografia leva a segurança barreira um passo à frente, portanto, se você deseja comprometer o desempenho, o FDE sem dúvida mantém seus dados fora de situações erradas. mãos.

O que você acha da criptografia de dispositivos? Você acha que o Google deveria seguir o caminho da criptografia de hardware? Você tem criptografia ativada e, em caso afirmativo, está enfrentando algum problema de desempenho? Compartilhe seus pensamentos na seção de comentários abaixo!