O Google começou a introduzir a FDE (Full Disk Encryption) padrão com o Android 5.0 Lollipop. Inicialmente, quando a criptografia foi implementada nos dispositivos Nexus 6, muitos usuários reclamaram da degradação do desempenho ao ler e gravar dados na unidade, mas a partir da versão do Android 6.0, esse problema parece estar resolvido.A criptografia completa do disco protege todas as informações do telefone, mesmo que o dispositivo caia nas mãos da polícia ou de outros invasores.Quando a criptografia está ativada, qualquer informação no telefone é automaticamente criptografada em tempo real com a chave AES antes de gravar na mídia. E vice-versa, ao ler as informações, elas são descriptografadas automaticamente com essa chave.Nos dispositivos iOS 9, essa chave é um derivado da senha do usuário e de uma chave de hardware exclusiva de 256 bits conectada ao smartphone na fábrica. Mesmo o FBI não pode quebrar esse nível de criptografia usando força bruta, como é conhecido na história recente com o smartphone do atirador de San Bernardino, pelo qual o FBI e a Apple chegaram a tribunal . Como resultado, o FBI ainda conseguiu quebrar o telefone usando uma vulnerabilidade desconhecida de 0 dias. Como pode ser entendido pelas palavras do chefe da estrutura do estado, os hackers tiveram que pagar mais de um milhão de dólares para burlar a proteção do FBI .
Criptografia completa de disco no iOSAssim, a força bruta do FDE é possível apenas usando um dispositivo de hardware específico. Isso complica muito o ataque. No caso usual, você pode criar um milhão de cópias e paralelizar a força bruta no serviço em nuvem, o que permite encontrar rapidamente 99% das senhas reais. Mas, neste caso, precisamos nos limitar ao único dispositivo no qual a Apple adiciona interferência adicional - atrasos entre tentativas de senha, limite no número máximo de tentativas etc. É por isso que é extremamente importante que serviços especiais encontrem uma maneira de recuperar o UID do hardware, para que a senha de força bruta se torne uma tarefa técnica banal.A criptografia completa do disco no Android 5.0+ é implementada de maneira um pouco diferente do iOS 9 e é descrita em detalhes emBlog de Nikolay Elenkov e documentação oficial do Android .Aqui, a chave de criptografia também é um derivado da senha de usuário geralmente fraca , mas também da chave mestre de 128 bits gerada aleatoriamente (Device Encryption Key - DEK) e do sal de 128 bits gerado aleatoriamente. O campo de geração do DEK é protegido usando um esquema cuidadosamente planejado que utiliza os valores inseridos pelo usuário - código PIN / senha / padrão (chave gráfica) para entrada. Em seguida, o DEK criptografado é colocado em um armazenamento criptografado especial chamado rodapé de criptografia . Todos esses níveis de criptografia devem ser superados antes de descriptografar o DEK e, em seguida, qualquer informação gravada na unidade.
Como no caso do iOS 9, o sistema operacional Android implementa a ligação do esquema de criptografia a hardware específico para evitar força bruta nas cópias do sistema operacional. A função de ligação de hardware é executada por um armazenamento de hardware especial - KeyMaster, que opera em um Trusted Execution Environment (TEE) especial, que é completamente independente do sistema operacional Android. A segurança das chaves no ambiente KeyMaster é crítica. Somente isso protege o sistema de criptografia de disco completo de conduzir força bruta efetiva em fluxos paralelos nas cópias do sistema operacional.Em dispositivos Android, um ambiente isolado nunca emite sua própria chave em um ambiente "inseguro". Pelo contrário, o módulo KeyMaster recebe um "blob de chaves" de um ambiente inseguro, descriptografa a chave armazenada lá e a devolve. Em outras palavras, a operação do sistema de criptografia é possível apenas diretamente no dispositivo de hardware, mas não em um ambiente virtual em outro computador.Em geral, todo o processo pode ser esquematicamente representado nesse diagrama, que Nikolai Elenkov fornece .
A proteção do ambiente KeyMaster e a execução de comandos em um processador seguro dedicado são garantidas pelo ambiente protegido fornecido pelo fabricante do equipamento. No caso da Qualcomm, esse é o QSEE (Qualcomm Secure Execution Environment). Ele permite que apenas pequenos aplicativos separados chamados trustlets sejam executados em um processador dedicado. Um desses trustlets é o KeyMaster. O código fonte do Android tem instruções para acessar o aplicativo KeyMaster. De fato, o trustlet suporta apenas quatro instruções: * Commands supported
*/
enum keymaster_cmd_t {
KEYMASTER_GENERATE_KEYPAIR = 0x00000001,
KEYMASTER_IMPORT_KEYPAIR = 0x00000002,
KEYMASTER_SIGN_DATA = 0x00000003,
KEYMASTER_VERIFY_DATA = 0x00000004,
};
O KeyMaster funciona exatamente como descrito acima: ele recebe o blob de chaves, calcula a assinatura e a coloca no buffer.E agora chegamos exatamente ao estágio em que a nova exploração está em operação, que apareceu em domínio público em 30 de junho ( repositório no Github ). A exploração explora as vulnerabilidades descobertas recentemente CVE-2015-6639 e CVE-2016-2431 .O autor da exploração, o especialista em segurança Gal Beniamini, escreveu uma versão falsa do aplicativo QSEE e, usando as vulnerabilidades acima mencionadas, conseguiu carregá-lo em um ambiente seguro, aumentando assim os privilégios e quebrando a proteção do ambiente QSEE, envolvido no processo de geração de uma chave para criptografar o disco.Assim, um atacante hipotético pode "falsificar" o componente de hardware da chave de criptografia e implementar a força bruta dos componentes restantes, ignorando a proteção do Android pelo número de tentativas. Resta apenas selecionar o PIN / senha do usuário por força bruta.A propósito, para o raro caso em que o usuário define uma senha realmente complexa com alta entropia para criptografia e não pode ser captada com força bruta por um tempo aceitável, existe um plano de backup. Se a quebra da criptografia for realmente necessária, você poderá encontrar exatamente o mesmo telefone, do mesmo modelo, com os mesmos riscos e uma capa protetora - e programá-lo para enviar uma senha assim que a vítima entrar. Este dispositivo falso é anexado à vítima em vez do original. Para evitar a divulgação e, ao mesmo tempo, eliminar o risco de a vítima digitar a senha errada na primeira tentativa, o telefone deve ser programado para não aceitar nenhuma senha como a correta.Mas este é um caso extremo, é claro. Na verdade, é muito fácil escolher códigos PIN e senhas comuns, se não houver restrições de hardware à força bruta.Há um ponto interessante. O ambiente seguro em dispositivos móveis não é definido pela própria Qualcomm, mas pelos OEMs. Eles podem cooperar com as autoridades policiais do país em cuja jurisdição eles estão localizados e cumprir os requisitos de solicitações judiciais. Por conseguinte, se esse esquema criptográfico for implementado por um fabricante russo, as informações no smartphone serão desclassificadas a pedido do tribunal russo.E mais um momento interessante. Apesar de Gal Benyamini discutir essas vulnerabilidades com a Qualcomm e o Google há vários meses, corrigi-las não é tão fácil - não há atualização de software suficiente (para duas vulnerabilidades, os patches para Android foram lançados em janeiro e maio ) e pode ser necessária uma atualização de hardware. O fato é que, se um invasor recebe um dispositivo, teoricamente ele pode reverter uma atualização de software, retornar o dispositivo a uma versão vulnerável e realizar um ataque.Como mencionado acima, o código de exploração é publicado no Github . Aqui está um diagrama de seu trabalho.
Gal Benyamini escreveu vários scripts Python que simplificam o bruteforce depois que uma exploração é acionada. Nos comentários na postagem do blog de seu colegaexpressou o desejo de ajudar a portar o script para a plataforma bruteforce hashcat / oclHashcat mais poderosa .Benjamini sugere que o Google, juntamente com os fabricantes de OEM, desenvolva um novo esquema de criptografia de hardware e software absolutamente confiável, que teoricamente não pode ser quebrado.Vamos torcer para que esse esquema seja implementado em uma nova geração de dispositivos Android.