A Criptografia do Android é Vulnerável e o Google Não é o Culpado

O único tópico de crítica que o Android nunca conseguiu superar, apesar dos constantes esforços do Google, tem que ser a segurança e a integridade dos dados do usuário. Ameaças sempre conseguiram invadir o sistema operacional móvel mais popular, impactando, como resultado, a privacidade em uma escala extremamente grande. Seja a Hummingbird instalando aplicativos enganosos em mais de 10 milhões de dispositivos ou o Stagefright relinquindo o controle sobre arquivos pessoais, correções temporárias sempre colapsaram horrivelmente a longo prazo.

Atualmente, existem várias maneiras pelas quais o Google garante que os dispositivos Android permaneçam seguros – patches mensais via OTA e uma política de criptografia de disco completo para OEMs. A implementação, no entanto, para esta última depende do fabricante de hardware. O Google elaborou várias camadas de criptografia para prevenir qualquer tipo de acesso não autorizado, embora os algoritmos não sejam muito robustos devido ao imenso problema de fragmentação e, portanto, até mesmo uma única responsabilidade ou falha pode revelar tudo.

Como Funciona a Criptografia do Android

A criptografia do Android é baseada em um núcleo Linux bem estabelecido (núcleo central de um sistema específico), cujos detalhes não são necessários para entender isso. Em resumo, cada dispositivo específico cria uma chave mestre única e aleatória de 128 bits, que geralmente é chamada de Chave de Criptografia do Dispositivo (DEK) e utilizada para ocultar os dados do usuário. O smartphone também cria um sal adicional de 128 bits que, juntamente com qualquer PIN ou senha habilitada pelo usuário – Chave de Derivação de Chave (KEK), é usado para criptografar a própria DEK. Por fim, a DEK é armazenada em um espaço de memória não criptografado (intitulado “rodapé criptográfico”) no telefone. Para descriptografar o sistema de arquivos para fins de nível administrativo, todo o processo é essencialmente revertido.

No entanto, há um outro campo privado que está vinculado ao hardware de cada dispositivo. A derivação da chave e a descriptografia envolvem o valor mencionado anteriormente assinando a KEK, que mais tarde é usada para decodificar a DEK. Esse processo é realizado por um módulo separado incluído no Android, denominado KeyMaster. O objetivo principal de implementar um módulo dedicado para descriptografia e não entregar as chaves diretamente aos aplicativos é bastante óbvio. Outra coisa que você deve estar ciente é o Ambiente de Execução Confiável – TEE que retém o programa KeyMaster.

Então, Qual é o Problema?

Aprender sobre o processo de criptografia diz algo sobre como o Google tentou fazer sua parte para manter as vulnerabilidades afastadas do Android. Infelizmente, a chave gerada pelo hardware depende de como os OEMs a estruturam. Um pesquisador de segurança recentemente tentou acessar arquivos privados do Android e, surpreendentemente, conseguiu revelar uma grande falha no sistema. Ele afirmou que a função de derivação de chave, que é basicamente usada para assinar a KEK, não é realmente vinculada ao hardware como esperado. Ele foi, de fato, capaz de gerar a chave a partir do software do TrustZone sem quaisquer problemas. Portanto, até mesmo um pequeno buraco no kernel ou no módulo KeyMaster pode levar a um grande erro para o usuário.

O pesquisador encontrou um pequeno pedaço de espaço desprotegido no código do Kernel e, sem quaisquer falhas no sistema, sobrepôs a área com uma função personalizada para vazar chaves do KeyMaster. Isso requer que o sequestrador obtenha fisicamente o dispositivo de uma pessoa, embora seja uma brecha técnica preocupante que precisa de atenção imediata do Google. O problema pode ser parcialmente corrigido com patches de segurança regulares, mas que porcentagem das distribuições realmente acompanha os telefones Nexus do Google?. Além disso, o pesquisador mencionou que essa brecha pode eventualmente ser estendida para acesso sem fio se o usuário visitar um aplicativo ou site inseguro, mesmo que acidentalmente. Como a maior parte da participação de mercado do Android não inclui telefones Nexus, esse tipo de vulnerabilidade impacta um enorme número de usuários.

A única solução que resta aqui é uma reformulação de hardware e a obrigatoriedade para os OEMs de lançar patches atualizados mensalmente. Os telefones topo de linha estão recebendo essas correções atualmente, embora seja uma fração incrivelmente pequena de dispositivos. Dadas algumas ocorrências recentes, os fabricantes definitivamente precisam abordar essas preocupações de privacidade para cada telefone que existe, caso contrário, malwares severos continuarão a impactar todo o espaço Android, o que pode eventualmente levar a sérias violações de integridade de dados. Os clientes também precisam entender as consequências e, na medida do possível, evitar desativar as verificações de segurança nas configurações e smartphones Android que não recebem atualizações.