O alcance da exposição depende do tipo de chave e da duração do acesso do atacante; o ratchet não garante que apenas uma mensagem esteja em risco.
Uma encriptação forte também exige uma execução correta no dispositivo. Uma vulnerabilidade no sistema operativo, na implementação criptográfica ou no hardware pode abrir caminho a dados sensíveis; mas a existência de investigação sobre ataques a processadores não permite concluir que qualquer telemóvel ou aplicação de mensagens seja vulnerável ao mesmo método.
As perguntas úteis são: que acesso tem o atacante, que chave ou texto consegue ver e se o seu acesso é temporário ou contínuo? As respostas são mais importantes do que o nome do algoritmo.
Qual é a diferença entre um canal lateral e a leitura de memória?
Na leitura direta de memória, o atacante pode conseguir ler partes do espaço de memória do processo ou do dispositivo. Num ataque de canal lateral, inferem-se informações a partir de sinais como o tempo de execução de operações ou o comportamento da cache. Os dois métodos não têm necessariamente os mesmos requisitos ou resultados.
A investigação original sobre FLUSH+RELOAD estudou o comportamento da cache e páginas de memória partilhadas num ambiente de teste específico e demonstrou a extração de uma chave de uma versão do GnuPG. Esse resultado não é um teste de segurança do Livara nem prova de vulnerabilidade de todos os processadores de telemóveis.
| Tipo de acesso | Pergunta necessária para avaliar |
|---|---|
| Executar uma aplicação normal no mesmo dispositivo | O isolamento dos processos e os requisitos do ataque permitem a observação? |
| Acesso de alto privilégio ao sistema operativo | Que dados ou operações com chaves ficam ao alcance do atacante? |
| Acesso físico ou laboratorial | Qual é o estado de bloqueio, o modelo do hardware e a proteção da chave? |
| Acesso contínuo à aplicação | O atacante consegue voltar a recolher novos textos ou chaves? |
A expressão genérica «hackear a RAM», sem estes detalhes, não é uma explicação técnica suficiente.
Como ajudam o Keystore e o hardware seguro?
O Android Keystore pode restringir a utilização de uma chave e, em dispositivos adequados, executar operações com suporte de hardware. Neste modelo, uma chave não extraível não é o mesmo que uma chave inutilizável pelo atacante: em certas condições, uma aplicação comprometida pode abusar de operações autorizadas com a chave mesmo sem extrair os seus bytes. Consulte o guia do Android Keystore.
Nem todas as chaves e algoritmos ficam automaticamente em hardware seguro. É preciso identificar o tipo de chave, o suporte do dispositivo e a forma como a aplicação a utiliza. Dizer que «a chave está no dispositivo» não prova, por si só, a sua localização ou o nível de proteção.
Uma chave exposta revela apenas uma mensagem?
Por vezes, a exposição de uma chave de mensagem independente tem um alcance limitado. Mas, se o atacante obtiver uma chave de cadeia, o estado da sessão, uma chave de identidade, um histórico legível ou vários buffers, o resultado é diferente. Assim, sem identificar os dados expostos, não se pode afirmar que está em risco «no máximo uma mensagem».
Mudar de chave em cada mensagem também não corta necessariamente o acesso do atacante. Se as chaves seguintes forem derivadas de um estado que ele possui, ou se continuar presente no dispositivo, poderá alcançar também as mensagens seguintes. Proteger o passado e recuperar a segurança futura são duas propriedades distintas, com pressupostos específicos.
Quais são os limites do ratchet e da limpeza da memória?
Um ratchet pode fazer evoluir as chaves ao longo da conversa. A recuperação após uma exposição exige a introdução de informação nova a que o atacante não tenha acesso; o simples envio de uma mensagem não prova essa condição. A especificação Double Ratchet explica, além da recuperação, os riscos de acesso persistente e de recuperação de dados eliminados.
Reduzir a duração dos dados sensíveis e limpar buffers é útil, mas daí não resulta uma garantia geral de eliminação de todas as cópias na RAM. É necessário examinar as bibliotecas, a linguagem de programação e os percursos de apresentação dos dados.
O que se pode dizer sobre o Livara?
A página de segurança do Livara descreve a construção híbrida e a evolução das chaves no LVR1. Este artigo não constitui um teste de canais laterais, uma auditoria à memória nem uma confirmação de que todas as chaves utilizam o Keystore. Em particular, a documentação pública do modelo de ameaças não garante a proteção de um dispositivo infetado.
Por isso, não se devem atribuir ao produto promessas de «neutralizar uma intrusão no hardware com a mensagem seguinte» ou de «expor no máximo uma mensagem», salvo se existirem provas específicas para essa versão e cenário.
Decisão prática para o utilizador
Mantenha o sistema operativo e a aplicação atualizados, escolha um dispositivo com suporte de segurança ativo, evite instalações não fiáveis e acessos desnecessários e use um bloqueio adequado. Se houver suspeita de uma intrusão grave, mudar de aplicação de mensagens ou enviar uma mensagem nova não substitui a investigação e limpeza do dispositivo.
Ao ler uma alegação de segurança, peça quatro elementos: a versão testada, o acesso do atacante, os dados expostos e os limites do resultado. O nome de um processador ou de uma norma criptográfica, por si só, não responde a estas quatro perguntas.
