O caso Apple x FBI chamou a atenção para a questão da privacidade, principalmente no contexto de dispositivos móveis. Após o ataque terrorista de San Bernardino em 2015, o FBI apreendeu um telefone celular pertencente ao atirador, Syed Farook, com a intenção de buscar evidências adicionais ou pistas relacionadas à investigação em andamento. No entanto, apesar de estar em posse do dispositivo, o FBI não conseguiu desbloquear o telefone e acessar seu conteúdo.
Isso pode parecer desconcertante à primeira vista.
"Certamente, se o FBI tivesse acesso ao telefone, eles não poderiam extrair os dados do usuário armazenados nele usando ferramentas forenses?"
Bem, a resposta não é tão simples. Veja, o dispositivo em questão é um iPhone 5c com iOS 9.
Como você sabe, a partir do iOS 8, a Apple ativou automaticamente o Criptografia de disco completo (FDE) usando uma chave de criptografia derivada da senha do usuário. Para acessar os dados no dispositivo, o FBI teria que quebrar essa criptografia. Excluindo quaisquer erros no projeto de criptografia, isso provavelmente teria sido alcançado quebrando a senha do usuário.
"Então, por que não usar força bruta?"
Isso parece uma abordagem muito boa - especialmente porque a maioria dos usuários é notoriamente desajeitada na escolha de senhas fortes, especialmente quando se trata de dispositivos móveis.
No entanto, os engenheiros da Apple não estavam alheios a essa preocupação quando projetaram seu esquema FDE. Para tentar mitigar esse tipo de ataque, eles projetaram o esquema de criptografia de forma que a chave criptográfica gerada fosse vinculada ao hardware do dispositivo.
Em suma, cada dispositivo tem uma chave imutável de 256 bits única chamada UID, que é gerado aleatoriamente e incorporado ao hardware do dispositivo quando é produzido. A chave é armazenada de uma forma que impede completamente o acesso usando software ou firmware (ela só pode ser definida como uma chave para o motor AES), o que significa que nem mesmo a Apple pode retirá-lo do dispositivo, uma vez que tenha sido configurado.
Essa chave específica do dispositivo é então usada em conjunto com a senha fornecida pelo usuário para gerar a chave de criptografia resultante usada para proteger os dados do dispositivo. Isso efetivamente "confunde" a senha e a chave UID.
Vincular a chave de criptografia ao hardware do dispositivo permite que a Apple torne o trabalho muito mais difícil para invasores em potencial. Essencialmente, ele força os invasores a usar o dispositivo para cada tentativa de violação. Isso, por sua vez, permite que a Apple introduza uma série de defesas que tornariam as tentativas de hacking inconvenientes.
Para começar, a função de derivação de chave é projetada de tal forma que levaria uma quantidade significativa de tempo para calculá-la no dispositivo. Especificamente, a Apple escolheu parâmetros de função para que uma única chave de derivação tivesse um atraso de aproximadamente 80 milissegundos. Esse atraso tornaria a invasão de senhas alfanuméricas curtas mais lenta (cerca de 2 semanas para uma senha alfanumérica de 4 caracteres), e a invasão de senhas mais longas seria completamente impraticável.
Para mitigar ainda mais os ataques de força bruta ao próprio dispositivo, a Apple também introduziu um atraso incremental entre as sucessivas tentativas de adivinhação de senha. No iPhone 5c, esse atraso foi completamente amenizado por meio de software. Finalmente, a Apple permitiu a capacidade de apagar completamente todos os dados armazenados no dispositivo após 10 tentativas fracassadas de recuperar a senha. Essa configuração, juntamente com atrasos induzidos por software, tornou a invasão da senha no próprio dispositivo bastante impraticável.
ATRASO ENTRE AS TENTATIVAS
- [1-4]> Nenhum
- [5]> 1 minuto
- [6]> 5 minutos
- [7-8]> 15 minutos
- [9]> 1 hora
Sabendo disso, é muito mais razoável supor que o FBI não foi capaz de quebrar a criptografia do dispositivo.
Se eles tivessem sido capazes de extrair a chave UID, eles poderiam ter usado o hardware necessário (especializado), a fim de encontrar rapidamente muitas senhas, o que provavelmente teria permitido que eles encontrassem a senha correta. No entanto, como a chave UID não pode ser extraída por software ou firmware, esta opção está excluída.
Quanto a hackear a senha no dispositivo, atrasos induzidos por software entre as tentativas de entrada de senha e a capacidade de excluir todos os dados no dispositivo tornaram a opção não muito conveniente. Isso exclui a possibilidade de contornar as proteções de software.
Voltando à questão em questão - podemos ver que a Apple projetou habilmente seu esquema FDE de uma forma que o torna muito difícil de decifrar.
via
