Explicação canônica da criptografia e vulnerabilidades do Android

Nota: Bem, a recompensa expirou e um possível motivo pode ser o esforço necessário para resolver, conforme eu recolho os comentários. Vendo o número de votos positivos, parece ser de interesse de outras pessoas também. Eu ainda gostaria de receber uma resposta, então aqui está o que proponho: uma boa resposta em um mês receberá um bônus de 50. Espero que isso dê tempo e incentivo adequados

Estou tentando entender o processo de criptografia do Android e suas vulnerabilidades há um tempo

Existem muitas perguntas abordando partes deste tópico neste site e também no site irmão. Para mostrar meu ponto de vista, essas perguntas tratam de partes e não o todo (remanescente de " cegos e um elefante ?") :)

• O que a criptografia Marshmallow está protegendo?
• A criptografia de dispositivo completo protege meus dados do Google e do governo?
• /android/137334/if-we-encrypt-our-device-can-user-connecting-to-adb-get-it
• Perguntas relacionadas à criptografia do cartão SD
• criptografia do Android quando o telefone está ligado
• android-cyanogenmod-encryption-vs-gnu
• existe material criptográfico em um telefone para cartões sim que pode ser usado com a rsa
• criptografia do dispositivo android

Meu entendimento (ou mal-entendido?)

1. A senha de criptografia é gerada a partir de uma combinação de PIN da tela de bloqueio do usuário e algoritmo de criptografia (nela existe uma fraqueza inerente devido ao tamanho limitado do PIN)
2. É salgado e armazenado no local raiz, não acessível aos usuários
3. Isso é usado para gerar a senha real para criptografar / descriptografar e a senha real é armazenada na RAM
4. Isso foi reforçado ao vincular a Etapa 1 ao SoC do dispositivo ( qual versão do Android? Qual é o elemento de hardware que identifica exclusivamente o dispositivo? Isso pode ser substituído por falso? )
5. Portanto, não é possível descriptografar dados sem chave e dispositivo de criptografia (também é válido para SD externo)
6. Possíveis métodos de recuperação - força bruta, captura de informações de RAM (etapa 3) para obter a chave
7. Dispositivos enraizados parecem ser mais suscetíveis a acessar os dados da etapa 2 por meio de recuperação personalizada / possivelmente ROM e kernel piscando? ( se for verdade, por que isso não é considerado um grande risco? )
8. Mesmo que essas informações sejam obtidas, acho que não é um esforço trivial gerar a senha real
9. O marshmallow pode tratar o SD externo como "armazenamento interno" ou "armazenamento portátil". Logicamente, não deve fazer diferença, mas não tenho certeza

Existem lacunas no meu entendimento, provavelmente perdendo outros aspectos importantes também.

Então, estou procurando uma explicação canônica para entender da perspectiva do usuário

• Processo de criptografia inteiro (incluindo SD externo)

• Variação de implementação nas versões do Android - do KitKat ao Marshmallow (incluindo opções duplas para SD externo no Marshmallow)

• Vulnerabilidades no nível do usuário

Nota

• Estou ciente do risco de a questão ser considerada muito ampla, mas a IMO garante um tratamento abrangente

• Tendo alguma experiência em segurança de comunicação, compreendo o desafio de traduzir conceitos criptográficos para o nível de usuário. Eu preferiria a resposta para resolver isso, com dicas explicativas para uma compreensão mais profunda. Exemplos do processo não precisam ser criptograficamente corretos em um sentido rigoroso, mas devem transmitir a essência

• Uma possível vantagem poderia ser "enganar" questões futuras sobre aspectos relacionados

• À custa da repetição, as respostas devem estar principalmente no nível do usuário , mas com explicações adequadas para um entendimento mais profundo. Dividir a resposta em duas partes pode ser uma maneira adequada.

• Eu faria questão de votar em respostas triviais / casuais / de trabalho de patch para incentivar respostas abrangentes

Eu imagino que funcione assim:

• O armazenamento é criptografado usando chave aleatória síncrona.
• Quando o usuário escolhe ou altera uma senha que se baseia em qualquer entrada, seja uma senha composta de letras e números e caracteres, seja um código PIN, furto de padrão, impressão digital ou qualquer outra entrada, uma criptografia assíncrona O algoritmo é usado para criptografar a chave mestra, de forma que a identificação correta acabe descriptografando a entrada, resultando na chave mestra, o que, por sua vez, torna possível criptografar e descriptografar o armazenamento.
• No momento em que o usuário efetua logout, a memória segurando a tecla principal é substituída

O grande truque aqui é a criptografia assíncrona da chave mestra. Depois que o Android tiver a chave mestra, ele poderá trocar dados com o armazenamento. Somente quando o usuário está conectado, essa chave mestra é conhecida. Criptografia assíncrona é o que é chamado de criptografia de chave pública. O que acontece é que uma chave pública criptografa dados (a chave mestra neste caso) e uma chave privada descriptografa os dados. Não deve ser confundido com a criptografia de armazenamento aqui. O armazenamento é apenas criptografia síncrona. Lá, a mesma chave é usada para criptografar e descriptografar. Mas a descoberta / recuperação dessa chave "mestra" é o mais importante. Isso significa que, se em um momento você tiver um método de login fraco, como na intenção "1234" como código PIN, e mudar de idéia, altere o código PIN para "5364", o que é mais difícil de adivinhar, a menos que "1234" " foi roubado, espionado, a qualquer momento, a segurança acaba de melhorar. O mesmo acordo ao alterar o método de login para uma senha completa impossível de adivinhar ou atacar no dicionário. O armazenamento em si não precisa ser criptografado novamente. É tudo sobre como esconder essa chave mestra - internamente. O usuário nunca vê essa chave mestra, porque provavelmente é apenas um tipo de código hash aleatório - nada jamais "encontrará" ou "adivinhar" esse código hash. Nem mesmo a NSA ou qualquer outro órgão de segurança do planeta conseguiu encontrar uma chave correspondente assim. O único vetor de ataque está esperando uma fraqueza por parte do usuário. Talvez o usuário tenha escolhido um login com código PIN. Se tiver 4 dígitos, é um máximo de 10000 códigos possíveis. O sistema operacional pode "bloquear" o dispositivo depois de experimentar alguns em pouco tempo. A solução é então "hackear" o sistema operacional, para que seja possível tentar todos os códigos possíveis sem o sistema operacional intervir e bloquear o dispositivo. Acredito que foi assim que o FBI finalmente conseguiu acesso ao telefone de um criminoso. Uma empresa terceirizada (alguma empresa israelense, pelo que me lembro) fez o hack para o FBI, eu acho. Eles ultrapassaram o limite de código PIN-try. Se o login for uma senha completa, e se o usuário tiver escolhido uma senha forte, e você estiver sol. Não em uma vida com todo o poder da CPU no planeta cortará isso em um milhão de anos. Eu não estou comprando nenhum dos NSA pode decifrar qualquer coisa rumores. Eu acho que essas pessoas assistiram muitos filmes homens de preto. Tudo o que você precisa fazer é examinar os documentos científicos sobre os vários algoritmos de criptografia (por exemplo, AES) e você saberá que o hacking simplesmente não acontecerá, exceto nos velhos tempos, quando havia chaves de 40 bits. Esses dias se foram há muito tempo. Acho que o AES128 já é infalível, e se alguém estiver preocupado, pular para o AES256 o torna mais seguro em uma magnitude do tamanho do universo. Talvez um dia os computadores quânticos possam decifrá-lo, mas sou cético. Não tenho certeza se é possível ter um sistema de probabilidade, basta destacar a solução. Veremos sobre isso, eventualmente. Talvez esteja a algumas vidas de qualquer maneira. Nada para se preocupar agora.

Portanto, no final do dia, a limitação de segurança está inteiramente no método de login usado. Pode-se alterar o método sem precisar criptografar novamente o armazenamento. Tudo isso por causa da criptografia de chave pública assíncrona da chave mestra.

Como as atualizações são frequentes, a maneira como a criptografia no telefone (sistema operacional Android) é manipulada pode mudar de uma versão para a seguinte. Portanto, a principal preocupação não é com a criptografia em si, mas com o processo em execução. E se essa plataforma tiver vulnerabilidades, a força do algoritmo de criptografia se torna de pouca ou nenhuma importância.

Basicamente, uma vez que seu dispositivo descriptografa arquivos, eles podem ser acessados ​​diretamente por um processo com privilégios de superusuário. Esse processo pode obter acesso ao seu dispositivo, explorando uma fraqueza na própria ROM (sistema operacional Android). (Isso foi notícia recentemente, pois algumas falhas foram expostas pelo WikiLeaks)

Dispositivos enraizados parecem ser mais suscetíveis a acessar os dados da etapa 2 por meio de recuperação personalizada / possivelmente ROM e kernel piscando? (se for verdade, por que isso não é considerado um grande risco?)

Antes da raiz : para fazer a raiz de um dispositivo, é necessário usar ferramentas externas, todas com acesso profundo à estrutura interna do dispositivo. Algumas dessas ferramentas são pré-compiladas e não são de código aberto. Eles têm sites "oficiais", mas quem são essas pessoas? (twrp.me, supersu.com por exemplo, mas existem outros como o KingoRoot) Podemos realmente confiar neles? Confio em alguns mais que nos outros. Por exemplo, o KingoRoot instalou um programa no meu PC que se comportava de maneira semelhante a um vírus (tinha que usar o dual-boot para removê-lo).

Depois de fazer o root : conceder um acesso compacto a um programa compilado (APK) significa que ele pode fazer o que quiser sem restrições ou declarar qual intenção usará. (A intenção é que os APKs acessem coisas como Wi-Fi, câmera etc.). Assim, um "aplicativo bem confiável", após um acesso root, pode acessar facilmente qualquer tipo de informação e enviá-lo de volta ao servidor.

A criptografia de dispositivo completo protege meus dados do Google e do governo?

Google - sim. Não possui a chave para desbloquear.

Governo (ou hacker) - não. porque o governo ou o hacker podem essencialmente usar uma exploração que interceptará o (s) arquivo (s) como mencionei acima.

As complexidades dos procedimentos / algoritmos de segurança são de pouca utilidade se puderem ser interceptadas e contornadas.

Editar: vale a pena mencionar que o Google realmente tem a capacidade de baixar e instalar / atualizar aplicativos no seu dispositivo Android sem pedir sua permissão ou até notificá-lo de que a atualização ocorreu. E mesmo em dispositivos com raiz, parece não haver uma maneira de bloquear isso sem perder as funções principais (Play Store, Mapas, Sincronização, etc.)