O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Criptografia de disco completo

A criptografia de disco completo é o processo de codificação de todos os dados do usuário em um dispositivo Android usando uma chave criptografada. Depois que um dispositivo é criptografado, todos os dados criados pelo usuário são criptografados automaticamente antes de serem enviados ao disco e todas as leituras descriptografam os dados automaticamente antes de devolvê-los ao processo de chamada.

A criptografia de disco completo foi introduzida no Android 4.4, mas o Android 5.0 introduziu estes novos recursos:

  • Criou criptografia rápida, que criptografa apenas blocos usados ​​na partição de dados para evitar que a primeira inicialização demore muito. Atualmente, apenas os sistemas de arquivos ext4 e f2fs suportam criptografia rápida.
  • Adicionado a forceencrypt bandeira fstab para criptografar na primeira inicialização.
  • Adicionado suporte para padrões e criptografia sem uma senha.
  • Adicionado armazenamento suportado por hardware da chave de criptografia usando o recurso de assinatura do Trusted Execution Environment (TEE) (como em um TrustZone). Veja Armazenar a chave criptografada para mais detalhes.

Cuidado: Dispositivos atualizado para o Android 5.0 e, em seguida, criptografados pode ser devolvido a um estado sem criptografia de redefinição de dados de fábrica. Os novos dispositivos Android 5.0 criptografados na primeira inicialização não podem retornar a um estado não criptografado.

Como funciona a criptografia de disco completo do Android

Criptografia de disco completo Android é baseado em dm-crypt , que é uma característica do kernel que funciona na camada de dispositivo de bloco. Devido a isso, funciona a criptografia com MultiMediaCard incorporado (eMMC) e dispositivos flash semelhantes que se apresentam para o núcleo como os dispositivos de bloco. A criptografia não é possível com YAFFS, que se comunica diretamente com um chip flash NAND bruto.

O algoritmo de criptografia é 128 Advanced Encryption Standard (AES) com encadeamento de blocos de criptografia (CBC) e ESSIV: SHA256. A chave mestra é criptografada com AES de 128 bits por meio de chamadas para a biblioteca OpenSSL. Você deve usar 128 bits ou mais para a chave (com 256 sendo opcional).

Nota: Os fabricantes podem usar 128 bits ou superior para encriptar a chave mestra.

Na versão Android 5.0, existem quatro tipos de estados de criptografia:

  • predefinição
  • ALFINETE
  • senha
  • padronizar

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

Você pode encontrar a senha padrão definido no Android Open Source Project cryptfs.cpp arquivo.

Quando o usuário define o PIN / senha ou senha no dispositivo, apenas a chave de 128 bits é criptografada novamente e armazenada. (ie. usuários pin / passagem / mudanças no padrão não causa re-criptografia de userdata.) Note-se que dispositivo gerenciado pode estar sujeito a restrições PIN, padrão ou senha.

Criptografia é gerido pela init e vold . init chama vold , e vold conjuntos de propriedades para eventos de disparo em init. Outras partes do sistema também examinam as propriedades para realizar tarefas como relatar o status, solicitar uma senha ou solicitar a redefinição de fábrica no caso de um erro fatal. Para invocar recursos de criptografia em vold , o sistema usa a ferramenta de linha de comando vdc 's cryptfs comandos: checkpw , restart , enablecrypto , changepw , cryptocomplete , verifypw , setfield , getfield , mountdefaultencrypted , getpwtype , getpw e clearpw .

A fim de cifrar, decifração ou limpe /data , /data não deve ser montada. No entanto, a fim de mostrar qualquer interface de usuário (UI), o quadro deve começar eo quadro requer /data para executar. Para resolver esse dilema, um sistema de arquivos temporário é montado em /data . Isso permite que o Android solicite senhas, mostre o progresso ou sugira uma limpeza de dados conforme necessário. Ele impõe a limitação de que, a fim de chave do sistema de arquivos temporário para o verdadeiro /data do sistema de arquivos, o sistema deve parar todos os processos com arquivos abertos no sistema de arquivos temporários e reiniciar os processos sobre o real /data do sistema de arquivos. Para fazer isso, todos os serviços devem estar em um dos três grupos: core , main , e late_start .

  • core : Nunca desligar após a partida.
  • main : desligado e, em seguida, reiniciar após a senha de disco é inserido.
  • late_start : não começa até após a /data foi decifrada e montado.

Para acionar essas ações, o vold.decrypt propriedade é definida como várias cordas . Para matar e serviços reinício, o init comandos são:

  • class_reset : Pára um serviço, mas permite que ele seja reiniciado com class_start.
  • class_start : reinicia um serviço.
  • class_stop : Pára um serviço e adiciona um SVC_DISABLED bandeira. Serviços interrompidos não respondem a class_start .

Fluxos

Existem quatro fluxos para um dispositivo criptografado. Um dispositivo é criptografado apenas uma vez e, em seguida, segue um fluxo de inicialização normal.

  • Criptografe um dispositivo não criptografado anteriormente:
    • Criptografar um novo dispositivo com forceencrypt : criptografia obrigatória no primeiro boot (a partir de Android L).
    • Criptografar um dispositivo existente: criptografia iniciada pelo usuário (Android K e anterior).
  • Inicialize um dispositivo criptografado:
    • Iniciando um dispositivo criptografado sem senha: Inicializando um dispositivo criptografado sem senha definida (relevante para dispositivos que executam Android 5.0 e posterior).
    • Iniciando um dispositivo criptografado com uma senha: Inicializando um dispositivo criptografado que possui uma senha definida.

Em adição a estes fluxos, o dispositivo também pode falhar para cifrar /data . Cada um dos fluxos é explicado em detalhes abaixo.

Criptografar um novo dispositivo com forceencrypt

Esta é a primeira inicialização normal para um dispositivo Android 5.0.

  1. Detectar sistema de arquivos sem criptografia com forceencrypt bandeira

    /data não são criptografados, mas precisa ser porque forceencrypt mandatos. Desmontar /data .

  2. Iniciar Criptografia /data

    vold.decrypt = "trigger_encryption" gatilhos init.rc , o que fará com vold para criptografar /data sem senha. (Nenhum está definido porque este deve ser um novo dispositivo.)

  3. Monte tmpfs

    vold monta um tmpfs /data (usando as tmpfs Opções de ro.crypto.tmpfs_options ) e define a propriedade vold.encrypt_progress a 0. vold prepepares os tmpfs /data para iniciar um sistema criptografado e define a propriedade vold.decrypt para: trigger_restart_min_framework

  4. Traga uma estrutura para mostrar o progresso

    Como o dispositivo virtualmente não tem dados para criptografar, a barra de progresso geralmente não aparece porque a criptografia acontece muito rapidamente. Veja Criptografar um dispositivo existente para mais detalhes sobre a interface do usuário de progresso.

  5. Quando /data é criptografada, derrubar o quadro

    vold conjuntos vold.decrypt para trigger_default_encryption que inicia o defaultcrypto serviço. (Isso inicia o fluxo abaixo para montar um userdata criptografada padrão.) trigger_default_encryption verifica o tipo de criptografia para ver se /data é criptografada com ou sem uma senha. Como os dispositivos Android 5.0 são criptografados na primeira inicialização, não deve haver nenhuma senha definida; portanto, descriptografar e montar /data .

  6. Montagem /data

    init , em seguida, monta /data em um tmpfs RAMDisk utilizando parâmetros que ele pega de ro.crypto.tmpfs_options , que é definido em init.rc .

  7. Iniciar estrutura

    Set vold para trigger_restart_framework , que continua o processo de inicialização normal.

Criptografar um dispositivo existente

Isso é o que acontece quando você criptografa um dispositivo Android K ou anterior não criptografado que foi migrado para L.

Este processo é iniciado pelo usuário e é referido como “criptografia local” no código. Quando um usuário opta por criptografar um dispositivo, a IU garante que a bateria esteja totalmente carregada e o adaptador CA esteja conectado para que haja energia suficiente para concluir o processo de criptografia.

Aviso: Se o dispositivo ficar sem energia e desliga antes que ele tenha criptografia acabado, dados do arquivo é deixado em um estado parcialmente criptografado. O dispositivo deve ser redefinido para os padrões de fábrica e todos os dados são perdidos.

Para ativar a criptografia inplace, vold começa um loop para ler cada setor do dispositivo de bloco real e, em seguida, escrevê-lo para o dispositivo de bloco de criptografia. vold verifica se um setor está em uso antes de ler e escrever, o que torna a criptografia muito mais rápido em um novo dispositivo que tem pouco ou nenhum dados.

Estado do dispositivo: Set ro.crypto.state = "unencrypted" e executar o on nonencrypted init gatilho para continuar a inicialização.

  1. Verifique a senha

    A interface do usuário chama vold com o comando cryptfs enablecrypto inplace onde passwd é a senha da tela de bloqueio do usuário.

  2. Remova a estrutura

    vold verifica erros, retorna -1 se ele não pode criptografar e imprime uma razão no log. Se ele pode criptografar, ele define a propriedade vold.decrypt para trigger_shutdown_framework . Este causas init.rc para parar serviços nas classes late_start e main .

  3. Crie um rodapé criptográfico
  4. Crie um arquivo breadcrumb
  5. Reinício
  6. Detectar arquivo breadcrumb
  7. Iniciar Criptografia /data

    vold em seguida, define-se o mapeamento de criptografia, o que cria um dispositivo de bloco de criptografia virtual que mapas para o dispositivo de bloco real, mas criptografa cada setor, como está escrito, e decifra cada setor, uma vez que é lido. vold , em seguida, cria e grava os metadados de criptografia.

  8. Enquanto estiver criptografando, monte o tmpfs

    vold monta um tmpfs /data (usando as tmpfs Opções de ro.crypto.tmpfs_options ) e define a propriedade vold.encrypt_progress a 0. vold prepara os tmpfs /data para iniciar um sistema criptografado e define a propriedade vold.decrypt para: trigger_restart_min_framework

  9. Traga uma estrutura para mostrar o progresso

    trigger_restart_min_framework provoca init.rc para iniciar a main classe de serviços. Quando o quadro vê que vold.encrypt_progress é definido como 0, ele traz a barra de progresso UI, que questiona que a propriedade a cada cinco segundos e atualiza uma barra de progresso. As atualizações de loop criptografia vold.encrypt_progress cada vez que criptografa outro por cento da partição.

  10. Quando /data é criptografada, atualizar o rodapé cripto

    Quando /data é criptografada com sucesso, vold limpa o sinalizador ENCRYPTION_IN_PROGRESS nos metadados.

    Quando o dispositivo é desbloqueado com êxito, a senha é usada para criptografar a chave mestra e o rodapé criptográfico é atualizado.

    Se a reinicialização falhar por algum motivo, vold define a propriedade vold.encrypt_progress para error_reboot_failed ea interface do usuário deve exibir uma mensagem pedindo que o usuário pressione um botão para reiniciar. Não é esperado que isso aconteça.

Iniciando um dispositivo criptografado com criptografia padrão

Isso é 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 nenhuma senha definida e, portanto, este é o estado de criptografia padrão.

  1. Detectar criptografados /data sem senha

    Detectar que o dispositivo Android é criptografada porque /data não pode ser montado e uma das bandeiras encryptable ou forceencrypt está definido.

    vold conjuntos vold.decrypt para trigger_default_encryption , que inicia o defaultcrypto serviço. trigger_default_encryption verifica o tipo de criptografia para ver se /data é criptografada com ou sem uma senha.

  2. Descriptografar / dados

    Cria a dm-crypt dispositivo sobre o dispositivo de bloqueio de modo que o dispositivo está pronto para uso.

  3. Monte / dados

    vold , em seguida, monta o descriptografado reais /data de partição e, em seguida, prepara a nova partição. Ele define a propriedade vold.post_fs_data_done a 0 e em seguida, define vold.decrypt para trigger_post_fs_data . Este causas init.rc para executar suas post-fs-data comandos. Eles vão criar quaisquer diretórios necessários ou links e, em seguida, conjunto vold.post_fs_data_done a 1.

    Uma vez vold vê a 1 em que a propriedade, ele define a propriedade vold.decrypt para: trigger_restart_framework. Este causas init.rc para começar serviços da classe main novamente e também iniciar serviços da classe late_start pela primeira vez desde a inicialização.

  4. Iniciar estrutura

    Agora as botas quadro todos os seus serviços usando os decifrados /data , eo sistema está pronto para uso.

Iniciando um dispositivo criptografado sem criptografia padrão

Isso é o que acontece quando você inicializa um dispositivo criptografado que possui uma senha definida. A senha do dispositivo pode ser um pino, padrão ou senha.

  1. Detectar dispositivo criptografado com uma senha

    Detectar que o dispositivo Android é criptografada porque a bandeira ro.crypto.state = "encrypted"

    vold conjuntos vold.decrypt para trigger_restart_min_framework porque /data é criptografado com uma senha.

  2. Monte tmpfs

    init conjuntos de cinco propriedades para salvar o Monte iniciais opções dadas para /data com parâmetros passados a partir init.rc . vold utiliza estas propriedades para criar o mapeamento cripto:

    1. ro.crypto.fs_type
    2. ro.crypto.fs_real_blkdev
    3. ro.crypto.fs_mnt_point
    4. ro.crypto.fs_options
    5. ro.crypto.fs_flags (ASCII número hexadecimal de 8 dígitos precedido por 0x)
  3. Inicie o framework para solicitar a senha

    O quadro inicia-se e vê que vold.decrypt está definido para trigger_restart_min_framework . Isso diz ao quadro que está sendo inicializado em um tmpfs /data em disco e ele precisa obter a senha do usuário.

    Primeiro, no entanto, ele precisa ter certeza de que o disco foi criptografado corretamente. Ele envia o comando cryptfs cryptocomplete para vold . vold retorna 0 se criptografia foi completada com êxito, -1 em caso de erro interna, ou -2 se criptografia não foi completada com êxito. vold determina isso olhando nos metadados de criptografia para o CRYPTO_ENCRYPTION_IN_PROGRESS bandeira. Se estiver definido, o processo de criptografia foi interrompido e não há dados utilizáveis ​​no dispositivo. Se vold retorna um erro, a interface do usuário deve exibir uma mensagem ao usuário a reinicialização e fábrica redefinir o dispositivo, e dar ao usuário um botão para pressionar a fazê-lo.

  4. Descriptografar dados com senha

    Uma vez cryptfs cryptocomplete for bem sucedida, o quadro apresenta uma interface de usuário pedindo a senha de disco. As verificações de interface do usuário a senha enviando o comando cryptfs checkpw para vold . Se a senha estiver correta (que é determinado pela montagem com sucesso os decifrados /data em um local temporário, em seguida, desmontar-lo), vold salva o nome do dispositivo de bloco descriptografado na propriedade ro.crypto.fs_crypto_blkdev e retorna o status 0 para a interface do usuário . Se a senha estiver incorreta, ele retornará -1 para a IU.

  5. Parar estrutura

    Os puts UI até um gráfico de boot de criptografia e depois chama vold com o comando cryptfs restart . vold define a propriedade vold.decrypt para trigger_reset_main , o que provoca init.rc fazer class_reset main . Isso interrompe todos os serviços na classe principal, que permite que os tmpfs /data a ser desmontado.

  6. Montagem /data

    vold , em seguida, monta o descriptografado reais /data partição e prepara a nova partição (que nunca pode ter sido preparado, se ele foi criptografado com a opção, que não é suportado no primeiro lançamento wipe). Ele define a propriedade vold.post_fs_data_done a 0 e em seguida, define vold.decrypt para trigger_post_fs_data . Este causas init.rc para executar suas post-fs-data comandos. Eles vão criar quaisquer diretórios necessários ou links e, em seguida, conjunto vold.post_fs_data_done a 1. Uma vez vold vê a 1 em que a propriedade, ele define a propriedade vold.decrypt para trigger_restart_framework . Este causas init.rc para começar serviços da classe main novamente e também iniciar serviços da classe late_start pela primeira vez desde a inicialização.

  7. Inicie o framework completo

    Agora as botas quadro todos os seus serviços usando o descriptografado /data do sistema de arquivos, eo sistema está pronto para uso.

Fracasso

Um dispositivo que não consegue descriptografar pode ser incorreto por alguns motivos. O dispositivo começa com a série normal de etapas para inicializar:

  1. Detectar dispositivo criptografado com uma senha
  2. Monte tmpfs
  3. Inicie o framework para solicitar a senha

Mas depois que a estrutura é aberta, o dispositivo pode encontrar alguns erros:

  • A senha corresponde, mas não pode descriptografar os dados
  • O usuário digita a senha errada 30 vezes

Se esses erros não são resolvidos, solicitar ao usuário fábrica de limpar:

Se vold detectar um erro durante o processo de criptografia, e se nenhum dado foi ainda destruída eo quadro é para cima, vold define a propriedade vold.encrypt_progress para error_not_encrypted . A IU solicita que o usuário reinicie e alerta que o processo de criptografia nunca foi iniciado. Se o erro ocorrer após o quadro foi demolida, mas antes da barra de progresso UI é para cima, vold irá reiniciar o sistema. Se a reinicialização falhar, ele define vold.encrypt_progress para error_shutting_down e retorna-1; mas não haverá nada para detectar o erro. Não é esperado que isso aconteça.

Se vold detectar um erro durante o processo de criptografia, ele define vold.encrypt_progress para error_partially_encrypted retornos e -1. A IU deve exibir uma mensagem dizendo que a criptografia falhou e fornecer um botão para o usuário redefinir o dispositivo para os padrões de fábrica.

Armazenando a chave criptografada

A chave criptografada é armazenada nos metadados criptográficos. 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 pela aplicação de scrypt à senha do usuário e ao 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 comprimento apropriado por mais uma aplicação de scrypt. Essa chave é então usada para criptografar e descriptografar a chave mestra. Para armazenar esta chave:

  1. Gere chave de criptografia de disco (DEK) de 16 bytes aleatória 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. Ajuste IK1 com zero bytes para o tamanho da chave privada associada ao hardware (HBK). Especificamente, preenchemos como: 00 || IK1 || 00..00; um byte zero, 32 bytes IK1, 223 bytes zero.
  4. Assine IK1 preenchido com HBK para produzir IK2 de 256 bytes.
  5. Aplique scrypt a IK2 e sal (o mesmo sal da 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 a DEK com AES_CBC, com a chave KEK e vetor de inicialização IV.

Mudando a senha

Quando um usuário optar por alterar ou remover a senha em configurações, a interface do usuário envia o comando cryptfs changepw para vold , e vold re-criptografa a chave mestra em disco com a nova senha.

Propriedades de criptografia

vold e init comunicar uns com os outros, definindo propriedades. Aqui está uma lista de propriedades disponíveis para criptografia.

Propriedades Vold

Propriedade Descrição
vold.decrypt trigger_encryption Criptografe a unidade sem senha.
vold.decrypt trigger_default_encryption Verifique a unidade para ver se ela está criptografada sem senha. Se for, descriptografar e montá-la, conjunto outra vold.decrypt para trigger_restart_min_framework.
vold.decrypt trigger_reset_main Definido por vold para desligar a IU solicitando a senha do disco.
vold.decrypt trigger_post_fs_data Definido por vold para prep /data com listas necessárias, et al.
vold.decrypt trigger_restart_framework Definido por Vold para iniciar a estrutura real e todos os serviços.
vold.decrypt trigger_shutdown_framework Definido por vold para encerrar a estrutura completa para iniciar a criptografia.
vold.decrypt trigger_restart_min_framework Definido pela vold para iniciar a UI barra de progresso para criptografia ou pedir a senha, dependendo do valor de ro.crypto.state .
vold.encrypt_progress Quando a estrutura é inicializada, se esta propriedade estiver definida, entre no modo de interface do usuário da barra de progresso.
vold.encrypt_progress 0 to 100 A interface do usuário da barra de progresso deve exibir o valor percentual definido.
vold.encrypt_progress error_partially_encrypted A IU da barra de progresso deve exibir uma mensagem de que a criptografia falhou e dar ao usuário a opção de redefinir o dispositivo para os padrões de fábrica.
vold.encrypt_progress error_reboot_failed A IU da barra de progresso deve exibir uma mensagem dizendo que a criptografia foi concluída e fornecer ao usuário um botão para reinicializar o dispositivo. Não é esperado que esse erro aconteça.
vold.encrypt_progress error_not_encrypted A IU da barra de progresso deve exibir uma mensagem informando que ocorreu um erro, nenhum dado foi criptografado ou perdido e fornecer ao usuário um botão para reinicializar o sistema.
vold.encrypt_progress error_shutting_down A IU da barra de progresso não está em execução, por isso não está claro quem responderá a esse erro. E isso nunca deveria acontecer de qualquer maneira.
vold.post_fs_data_done 0 Definido pela vold apenas antes de definir vold.decrypt para trigger_post_fs_data .
vold.post_fs_data_done 1 Definir por init.rc ou init.rc apenas depois de terminar a tarefa post-fs-data .

propriedades init

Propriedade Descrição
ro.crypto.fs_crypto_blkdev Definido pela vold comando checkpw para uso posterior pelo vold comando restart .
ro.crypto.state unencrypted Conjunto pela init para dizer este sistema está sendo executado com um sem criptografia /data ro.crypto.state encrypted . Definido pela init para dizer este sistema está sendo executado com um criptografados /data .

ro.crypto.fs_type
ro.crypto.fs_real_blkdev
ro.crypto.fs_mnt_point
ro.crypto.fs_options
ro.crypto.fs_flags

Estes cinco propriedades são definidas por init quando se tenta montar /data com parâmetros passados proveniente init.rc . vold utiliza para configurar o mapeamento de criptografia.
ro.crypto.tmpfs_options Definir por init.rc com as opções de inicialização deve usar quando montar o tmpfs /data do sistema de arquivos.

Ações de inicialização

on post-fs-data
on nonencrypted
on property:vold.decrypt=trigger_reset_main
on property:vold.decrypt=trigger_post_fs_data
on property:vold.decrypt=trigger_restart_min_framework
on property:vold.decrypt=trigger_restart_framework
on property:vold.decrypt=trigger_shutdown_framework
on property:vold.decrypt=trigger_encryption
on property:vold.decrypt=trigger_default_encryption