Acabei de instalar o Marshmallow em um Nexus 5 por meio de uma atualização por push. Estou confuso sobre o funcionamento da criptografia. Eu tenho um bom conhecimento técnico de criptografia em computadores. Gostaria de obter conhecimento semelhante sobre o Android 6.

A seguir, o que fiz e como fiquei confuso. Após uma redefinição de fábrica, configurei um PIN e criptografou o dispositivo. Na inicialização, ele solicitou meu PIN, o que era esperado. Em seguida, removi o PIN e reiniciei o dispositivo. Ele não solicitou nenhum PIN na inicialização, mas o dispositivo ainda se relatou como criptografado no menu de configuração. O último é o que me confunde, pois esperava que o PIN desbloqueie a chave de descriptografia.

Questões:

• No caso de criptografia sem PIN, de onde vem a chave de descriptografia? Presumo que ele esteja armazenado em um chip semelhante a um TPM, isso está correto? Em caso afirmativo, o que impede um hacker de solicitar essa chave do chip? Verifica o hash do firmware? Algo mais? Detalhes técnicos seriam muito apreciados.
• No caso de criptografia com um PIN, o PIN é usado como um token extra para acessar a chave de descriptografia? Ou o processo de descriptografia funciona exatamente como se não houvesse PIN.

Resposta TL; DL:

A chave de descriptografia é desbloqueada com todos os seguintes itens:

• O PIN (ou senha, etc.) ou uma senha padrão, se não houver
• Um TEE (um gerador de assinaturas suportado por hardware que usa chaves que não podem ser extraídas)
• Um sal (prontamente disponível, mas impedindo ataques de tabelas do arco-íris)

Estou citando o Manual do Android aqui , mas:

NOTA:

A fonte que usei não é diretamente relevante para o Marshmallow, mas é relevante para o Lollipop e superior.

TL: DR

Vou abordar as perguntas do OP agora. Detalhes técnicos seguirão.

1. A chave de criptografia padrão vem de uma fonte de hardware (um chip semelhante a um TPM) e a senha padrão do AOSP definida como default_passwordno cryptfs.carquivo de origem, veja abaixo.

2. Sim, não apenas o padrão, mas qualquer senha é transformada em uma chave e armazenada em um chip semelhante ao TPM, chamado TEE (abreviação de "Trusted Execution Environment", veja abaixo para obter mais detalhes).

3. Um hacker com acesso UART / JTAG aos chips no SoC do dispositivo pode tecnicamente obter acesso à chave TEE, ou um kernel personalizado pode vazar essas informações para um hacker. Algumas agências de três letras em teorias da conspiração podem, possivelmente, formar uma parceria com o OEM para obter esses núcleos inseguros usados ​​em dispositivos de produção, mas eu não colocaria muitas lojas nele. Mais uma vez, consulte a última seção desta resposta para obter mais detalhes.

A única coisa que impede um hacker de acessar a chave é a enorme quantidade de esforço necessária para isso.

4. A verificação do hash do (checksumming) do firmware (chamado "Inicialização Verificada" do Google) é feita de fato no Lollipop e acima dele por padrão (e está disponível no JellyBean 4.3 em diante), por um módulo do kernel chamado dm-verity. No entanto, isso é independente do status de criptografia.

Fonte: Guia de segurança AOSP aqui .

5. Sobre o processo envolvido na descriptografia do sistema com uma senha personalizada, veja abaixo. Vou apenas dizer aqui que a senha do usuário está envolvida na criação e no uso da chave de criptografia.

Visão geral

Na primeira inicialização, o dispositivo cria uma chave mestra de 128 bits gerada aleatoriamente e a hash com uma senha padrão e sal armazenado. A senha padrão é: "default_password" No entanto, o hash resultante também é assinado por meio de um TEE (como o TrustZone), que usa um hash da assinatura para criptografar a chave mestra.

Você pode encontrar a senha padrão definida no arquivo cryptfs.c do Android Open Source Project .

Quando o usuário define o PIN / senha ou senha no dispositivo, apenas a chave de 128 bits é criptografada e armazenada novamente. (ou seja, alterações de PIN / senha / padrão do usuário NÃO causam re-criptografia da partição de dados do usuário.)

Iniciando um dispositivo criptografado com criptografia padrão

É o que acontece quando você inicializa um dispositivo criptografado sem senha. Como os dispositivos Android 5.0 são criptografados na primeira inicialização, não deve haver senha definida e, portanto, este é o estado de criptografia padrão.

1. Detectar dados criptografados / sem senha

Detecte que o dispositivo Android está criptografado porque / data não pode ser montado e um dos sinalizadores encryptableou forceencryptestá definido.

volddefine vold.decryptcomo trigger_default_encryption, que inicia o defaultcryptoserviço. trigger_default_encryptionverifica o tipo de criptografia para ver se / data está criptografado com ou sem uma senha.

2. Descriptografar / dados

Cria o dm-cryptdispositivo sobre o dispositivo de bloco para que ele esteja pronto para uso.

3. Montagem / dados

voldmonta a partição real / de dados descriptografada e prepara a nova partição. Ele define a propriedade vold.post_fs_data_donecomo 0e, em seguida, define vold.decryptcomo trigger_post_fs_data. Isso faz init.rccom que seus post-fs-datacomandos sejam executados . Eles criarão os diretórios ou links necessários e depois serão definidos vold.post_fs_data_donecomo 1.

Uma vez que voldvê a 1 em que a propriedade, ele define a propriedade vold.decryptde: trigger_restart_framework. Isso faz init.rccom que iniciar serviços na classe mainnovamente e também iniciar serviços na classe late_start pela primeira vez desde a inicialização.

4. Iniciar estrutura

Agora, a estrutura inicializa todos os seus serviços usando os dados descriptografados / e o sistema está pronto para uso.

Iniciando um dispositivo criptografado sem criptografia padrão

É o que acontece quando você inicializa um dispositivo criptografado com uma senha definida. A senha do dispositivo pode ser um alfinete, padrão ou senha.

1. Detectar dispositivo criptografado com uma senha

Detecte que o dispositivo Android está criptografado porque o sinalizador ro.crypto.state = "encrypted"

voldconjuntos vold.decryptpara trigger_restart_min_frameworkporque os dados / é criptografado com uma senha.

2. Mount tmpfs

initdefine cinco propriedades para salvar as opções de montagem inicial fornecidas para / data com parâmetros passados ​​de init.rc. voldusa essas propriedades para configurar o mapeamento criptográfico:

ro.crypto.fs_type

ro.crypto.fs_real_blkdev

ro.crypto.fs_mnt_point

ro.crypto.fs_options

ro.crypto.fs_flags (Número hexadecimal ASCII de 8 dígitos, precedido por 0x)

3. Iniciar estrutura para solicitar senha

A estrutura inicia e vê que vold.decryptestá definido como trigger_restart_min_framework. Isso informa à estrutura que ele está inicializando em um tmpfs /datadisco e precisa obter a senha do usuário.

Primeiro, no entanto, ele precisa garantir que o disco esteja criptografado corretamente. Ele envia o comando cryptfs cryptocompletepara vold. voldretorna 0 se a criptografia foi concluída com êxito, -1 em erro interno ou -2 se a criptografia não foi concluída com êxito. volddetermina isso procurando nos metadados criptográficos do CRYPTO_ENCRYPTION_IN_PROGRESSsinalizador. Se estiver definido, o processo de criptografia foi interrompido e não há dados utilizáveis ​​no dispositivo.

Se voldretornar um erro, a interface do usuário deverá exibir uma mensagem para o usuário reiniciar e redefinir o dispositivo de fábrica e dar ao usuário um botão para pressionar.

4. Descriptografar dados com senha

Uma vez cryptfs cryptocompletebem-sucedido, a estrutura exibe uma interface do usuário solicitando a senha do disco. A interface do usuário verifica a senha enviando o comando cryptfs checkpwpara vold. Se a senha estiver correta (que é determinada montando com êxito o descriptografado /dataem um local temporário e desmontando-o), o vold salva o nome do dispositivo de bloco descriptografado na propriedade ro.crypto.fs_crypto_blkdeve retorna o status 0 para a interface do usuário. Se a senha estiver incorreta, ela retornará -1 à interface do usuário.

5. Parar estrutura

Os puts UI até um gráfico de boot de criptografia e depois chama vold com o comando cryptfs restart. volddefine a propriedade vold.decryptcomo trigger_reset_main, o que causa init.rcisso class_reset main. Isso interrompe todos os serviços da mainclasse, o que permite tmpfs /dataque seja desmontado.

6. Montagem / dados

volddepois monta a /datapartição real descriptografada e prepara a nova partição (que talvez nunca tenha sido preparada se foi criptografada com a opção de limpeza, que não é suportada no primeiro release). Ele define a propriedade vold.post_fs_data_donecomo 0e, em seguida, define vold.decryptcomo trigger_post_fs_data. Isso faz init.rccom que seja executado post-fs-data commands. Eles criarão os diretórios ou links necessários e depois serão definidos vold.post_fs_data_donecomo 1. Depois de voldver o 1nessa propriedade, ele define a propriedade vold.decryptcomo trigger_restart_framework. Isso faz init.rccom que os serviços em classe sejam iniciados mainnovamente e também os serviços em classe late_startpela primeira vez desde a inicialização.

7. Iniciar estrutura completa

Agora, a estrutura inicializa todos os seus serviços usando o sistema de arquivos descriptografado / de dados e o sistema está pronto para uso.

Armazenando a chave criptografada

A chave criptografada é armazenada nos metadados de criptografia. O suporte de hardware é implementado usando o recurso de assinatura do Trusted Execution Environment (TEE). Anteriormente, criptografávamos a chave mestra com uma chave gerada aplicando scrypta senha do usuário e o sal armazenado.

Para tornar a chave resiliente contra ataques externos, estendemos esse algoritmo assinando a chave resultante com uma chave TEE armazenada. A assinatura resultante é então transformada em uma chave de tamanho apropriada por mais uma aplicação de scrypt. Essa chave é usada para criptografar e descriptografar a chave mestra. Para armazenar esta chave:

1. Gere chave de criptografia de disco (DEK) aleatória de 16 bytes e sal de 16 bytes.
2. Aplique scryptà senha do usuário e ao salt para produzir a chave intermediária 1 de 32 bytes (IK1).
3. Almofada IK1 com zero bytes para o tamanho da chave privada ligada ao hardware (HBK). Especificamente, preenchemos como: 00 || IK1 || 00..00; um byte zero, 32 bytes IK1, 223 bytes zero.
4. Assine IK1 acolchoado com HBK para produzir IK2 de 256 bytes.
5. Aplique scryptno IK2 e no sal (o mesmo sal que na etapa 2) para produzir IK3 de 32 bytes.
6. Use os primeiros 16 bytes de IK3 como KEK e os últimos 16 bytes como IV.
7. Criptografe DEK com AES_CBC, com chave KEK e vetor de inicialização IV.