É razoavelmente seguro usar o código PIN para criptografia?

19

No Android 4.0 (Samsung Galaxy Nexus), existe a possibilidade de criptografar o telefone. Eu descobri isso sobre a criptografia no Android 3.0. Os mesmos algoritmos usados ​​no Android 4? http://source.android.com/tech/encryption/android_crypto_implementation.html

Minha principal pergunta diz respeito ao uso de um código PIN para descriptografar seu telefone. Por que sou forçado a usar a mesma senha para desbloquear minha tela e descriptografar meu telefone? Essa restrição só me permitirá usar uma senha de baixa complexidade (como um número PIN), pois seria muito difícil escrever em 17 caracteres para desbloquear meu telefone para uma simples ligação.

Tentativas de força bruta contra o desbloqueio da tela podem ser evitadas, ou seja, com uma reinicialização da força a cada 5 tentativas. Portanto, não há necessidade de uma senha muito forte, um PIN pode ser bom o suficiente.
Esse tipo de proteção não pode ser usado no disco, portanto, há uma necessidade maior de senhas mais fortes aqui. (Não ajuda muito o aumento da entrada de senhas, pois haverá muito poucos usuários com uma senha complexa; portanto, um invasor pode simplesmente tentar a maioria das senhas com baixa complexidade). Qual é o motivo para ser forçado a usar a mesma senha para os dois recursos?

security encryption Christopher Käck
fonte
3
Sim, mas se eu usar a senha, eu precisaria usá-la para desbloquear minha tela. Não é muito útil digitar 17 caracteres para fazer uma ligação rápida. Assim, a maioria dos usuários fará o devido com os números PIN e essa seria a primeira coisa que um invasor tentaria. Uma abordagem melhor talvez seja permitir senhas para a criptografia de disco e permitir números PIN simples na tela de bloqueio. Para evitar tentativas de força bruta na tela de bloqueio, pode haver uma reinicialização forçada após três tentativas com falha, resultando em uma solicitação de senha.
Christopher Käck
1
Infelizmente, não sei se alguém que não seja o Google poderia lhe explicar o motivo. Você pode tentar o rastreador de erros do Android para registrar uma solicitação de recurso, provavelmente. Parece uma coisa sensata arquivar lá.
Eldarerathis
2
Sim, contra a tentativa de login na tela de desbloqueio, mas não contra a descriptografia do disco rígido. É isso que estou tentando dizer: o desbloqueio da tela não precisa ser tão longo quanto a criptografia do disco rígido (que precisa ser muito maior que 4 números) e, portanto, não se deve ser forçado a usar o mesmo para ambos.
Christopher Käck
1
+1, estou totalmente com você @ ChristopherKäck Essa decisão não faz sentido, os engenheiros do Google deveriam saber melhor, espero que resolvam isso em breve.
João Portela
1
@ Christopher: mas você está baseando sua decisão em premissa incorreta, a criptografia em disco era AES de 128 bits, não o PIN de 4 dígitos. Determinar se esse esquema é seguro ou inerentemente defeituoso não é o conhecimento do Android.SE.
Lie Ryan

Respostas:

4

Eu acho que encontrei a solução. Verifique este link . É um hack e requer que o telefone seja rooteado, mas permite que você use uma senha alfanumérica para criptografia e um PIN para desbloquear a tela.

Oscar_6
fonte
1

Ao usar uma senha / frase ou um pino de quatro dígitos, você aumenta a segurança do seu dispositivo. O truque é que, mesmo tendo uma senha de quatro caracteres, você acaba de aumentar sua segurança por dois motivos:

  • Você aumentou os caracteres disponíveis.
  • Você retirou o conhecimento do atacante do seu comprimento de jogo.

Se um invasor souber que sua senha tem 14 caracteres, é mais segura que uma senha de quatro ou oito caracteres, mas as estatísticas típicas usam intervalos (1-4, 1-8, 1-14) e não a realidade (o que seria simplesmente calcular combinações disponíveis de um comprimento).

Atualmente, é simplesmente MUITO FÁCIL acessar os dados do seu telefone. Sua avó tem a capacidade de fazê-lo (sem ofensa para você ou sua família: P). Portanto, enquanto você estiver certo de que há limitações dessa criptografia, a versão "quebrada" funciona MUITO melhor do que os dados não criptografados atualmente praticados.

Cabe a você julgar quão confidenciais e confidenciais são os seus dados, bem como o quanto você é um alvo para que esses dados sejam roubados. A escolha de uma senha apropriada é de sua responsabilidade depois de avaliar esses riscos.

earthmeLon
fonte
2
Sim, mas acho que seria uma solução simples para o problema ter senhas diferentes para desbloquear a tela e descriptografar o dispositivo (como mencionei aqui android.stackexchange.com/questions/17086/… ), pois elas são usadas em diferentes senarios e precisa ter atributos diferentes.
Christopher Käck
1

Se você está tentando decifrar a criptografia de disco, independentemente do restante do dispositivo em um cenário em que possui um dispositivo desligado ou apenas os chips de memória, esse é um vetor de ataque diferente daquele usado em um dispositivo ligado protegido por senha, onde a chave de descriptografia pode estar na memória (causando vulnerabilidades usadas por ladrões de chaves de criptografia Firewire prevalecentes em PCs que usam software de criptografia FDE mais antigo e não um módulo do tipo TPM), ou a tela de desbloqueio pode ser brutal. forçado (ou tem suas próprias vulnerabilidades).

Se você está atacando o disco diretamente, nesse caso, não está atacando o PIN ou a senha de usuário de quatro dígitos que está criptografando o dispositivo, o que está atacando é a chave AES de 128 bits:

A chave mestra é um número de 128 bits criado pela leitura de / dev / urandom. Ele é criptografado com um hash da senha do usuário criada com a função PBKDF2 da biblioteca SSL. O rodapé também contém um salt aleatório (também lido em / dev / urandom) usado para adicionar entropia ao hash do PBKDF2 e impedir ataques de tabela arco-íris na senha.

No ponto 4, em " Habilitando a criptografia no dispositivo ", nas Notas sobre a implementação da criptografia no Android 3.0 a que você vinculou.

(ia ser um comentário, mas acabou por muito tempo)

GAThrawn
fonte
1
Obrigado por este belo comentário! Uma coisa, porém; não estou procurando a senha do usuário (que provavelmente será um pino de 4 dígitos, porque você é forçado a compartilhar a chave com o desbloqueio da tela e qualquer outra coisa será um incômodo de digitar para fazer uma ligação) para descriptografar os 128 bits Chave AES? (em vez de procurar a chave diretamente). Se eu misturar todos os 10000 pinos com a função PBKDF2 + salt, não há apenas 10000 tentativas de descriptografia para eu tentar?
Christopher Käck
@Melpomene O " ataque da tabela do arco-íris " sobre o qual eles falam é onde você pré-criptografa todas as 10.000 combinações para ver como elas são criptografadas e depois compara o que está no disco com o que está na sua tabela do arco-íris. O " sal aleatório " é o que é usado para ajudar a evitar isso, criando muito mais de 10.000 combinações que você precisará adivinhar (a menos que você consiga descobrir o "sal" primeiro).
precisa
1
Um arco-íris é uma maneira inteligente de armazenar senhas criptografadas sim. E se um sal for usado, provavelmente precisará ser especialmente construído apenas para quebrar senhas com esse sal. Esta não é uma operação muito difícil quando há apenas 10.000 senhas para escolher. Observe que o Salt é sempre considerado conhecido pelo invasor (uma vez que parece ser lido em / dev / urandom nos documentos, é mais provável que seja armazenado em texto não criptografado ou criptografado com a senha do usuário). De qualquer maneira, a senha do usuário é o elo fraco.
Christopher Käck 24/02
Mas eu nem precisaria construir uma tabela de arco-íris, pois armazenar (ou calcular) 10.000 hashes não é tão difícil para minha memória (processador).
Christopher Käck 24/02
Usar uma função de derivação de chave como PBKDF2 parece uma boa notícia, mas um pino de 4 dígitos típico ainda é apenas 10000 combinações possíveis.
João Portela
1

Uma solução possível para isso é usar o whispercore , mas requer que você faça root no seu dispositivo.

Também preenchi uma solicitação de recurso na página do projeto Android .

João Portela
fonte
0

Se você tiver a limpeza remota ativada (supondo que ainda funcione com o dispositivo criptografado), o PIN pode não proteger seu dispositivo para sempre, mas pode ser suficiente para permitir tempo para limpar o dispositivo.

Chance
fonte
2
O problema é que um PIN curto só pode proteger o dispositivo quando está ligado. Portanto, desligar um dispositivo roubado impede que ele seja apagado e, além disso, o PIN pode ser quebrado em um ataque de força bruta offline. Portanto, um PIN curto não ajuda nessa situação.
Robert
@ Robert, não estou muito familiarizado com o funcionamento da limpeza remota. Se for feito via Exchange, o telefone precisa estar no mesmo momento em que o comando de limpeza remota é emitido? Meu pensamento é que, se eu puder fazer uma limpeza remota em cerca de 30 minutos ou perder o telefone, isso é o suficiente para mim, mas não tenho dados financeiros, minha principal preocupação é o e-mail comercial do GMail.
Chance
2
O telefone precisa estar ligado e on-line algum tempo após a emissão do comando de limpeza remota. Se o telefone foi desligado (e permanece desligado), o comando wipe é inútil.
Robert