Uma cópia do disco, o controlo em tempo real do servidor e o acesso ao telefone são três cenários diferentes; uma garantia geral não basta para os três.
Se um servidor de mensagens for tomado, a resposta exata a “o que será revelado?” depende dos dados armazenados, da localização das chaves e do tipo de acesso do atacante. Obter uma cópia do disco não é o mesmo que controlar o serviço em tempo real e o canal de distribuição da aplicação.
Este artigo analisa um cenário hipotético com base na documentação pública da Livara. Não faz afirmações sobre a localização dos centros de dados da Livara, a ocorrência de uma apreensão ou a garantia de funcionamento do serviço durante uma interrupção da internet. Cifragem de conteúdo, disponibilidade da rede e segurança da infraestrutura são questões distintas.
Primeiro, identificar o tipo de acesso
Cópia armazenada do servidor: o atacante acede aos ficheiros, à base de dados ou às cópias de segurança presentes nessa cópia. Se o conteúdo privado tiver sido corretamente cifrado no dispositivo e o servidor não possuir a chave para o decifrar, ter apenas essa cópia não revela o texto da conversa.
Controlo ativo do serviço: além de ler os dados existentes, o atacante pode bloquear certos pedidos, devolver dados antigos ou alterar o comportamento dos componentes controlados. Verificar a identidade do interlocutor, controlar versões e assegurar a integridade do cliente torna-se mais importante neste cenário.
Acesso simultâneo ao dispositivo: um telefone desbloqueado, malware ou uma cópia legível em poder de um participante pode revelar o conteúdo por uma via totalmente diferente. O modelo de ameaças da Livara também não garante a proteção de um dispositivo desbloqueado ou infetado.
Que dados são visíveis no servidor segundo a documentação da Livara?
A página de segurança da Livara, identificada como versão 0.1.68, separa o conteúdo das conversas diretas sob LVR1 e dos grupos privados compatíveis sob LGS1 das informações operacionais. A mesma página declara expressamente que os grupos antigos incompatíveis ficam fora de E2EE; por isso, é necessário verificar o estado da conversa em causa.
| Categoria de dados | Limite documentado e possível consequência |
|---|---|
| Texto e anexos de uma conversa protegida | O servidor guarda a cópia cifrada; a leitura exige a chave adequada |
| Metadados de comunicação | O serviço tem acesso a informações como participantes, horário, tamanho e estado de entrega |
| Participação em grupos | Faz parte das informações e dos poderes operacionais do servidor |
| Canal público | O conteúdo é público e legível pelo servidor |
| Pacote de recuperação de identidade v7 | É cifrado antes do envio e requer um segredo de recuperação separado |
| Modo opcional de gravação no servidor | A indicação REC distingue-o do modo E2EE; não se deve presumir privacidade ponta a ponta |
A documentação menciona código LSS1 para proteger metadados, mas este não está ligado ao envio normal de mensagens. A presença do nome de um protocolo no projeto não prova que esteja ativo em todas as comunicações.
Esta tabela descreve alegações do produto, não os resultados de um teste de apreensão real nem de uma auditoria independente de todas as cópias da base de dados.
Qual pode ser a importância dos metadados?
Informações sobre contactos entre pessoas, horários e participação em grupos podem ser sensíveis mesmo sem o texto das mensagens. Porém, afirmar que “todo o grafo de comunicação será revelado para sempre” é impreciso sem conhecer os prazos de retenção, a cobertura dos registos e a cópia de dados obtida.
Uma avaliação real deve perguntar quais campos foram recolhidos, durante quanto tempo foram conservados e quais cópias de segurança estão acessíveis. A cifragem do conteúdo, por si só, não determina a política de retenção de dados. Também não se pode concluir, a partir da arquitetura de um serviço de mensagens, que todos os serviços guardam necessariamente os mesmos metadados.
Que risco representa o controlo do servidor para mensagens futuras?
Uma análise de segurança deve testar separadamente a manipulação da lista de membros, o fornecimento de uma chave de identidade diferente, o bloqueio de atualizações e a entrega de um cliente malicioso. O efeito de cada ação depende da validação no cliente, da apresentação das alterações e da verificação de identidade.
Sem testar a implementação, não se pode dizer que qualquer servidor tomado consegue necessariamente adicionar um membro oculto; tal como não se pode dizer que o controlo ativo do servidor não tem qualquer efeito. Numa conversa sensível, devem ser investigadas mudanças inesperadas de identidade ou de membros. Comparar a impressão digital da chave com o interlocutor por uma via independente e de confiança oferece mais informação do que confiar apenas no nome apresentado.
Se o atacante alterar o código executado no dispositivo, poderá ver o texto antes da cifragem. Por isso, a segurança da distribuição e das atualizações da aplicação faz parte deste cenário, não é uma questão externa à criptografia.
O que acrescenta a proteção pós-quântica?
A norma NIST FIPS 203 para ML-KEM ajuda a estabelecer um segredo partilhado. O seu uso correto numa combinação híbrida pode reduzir o risco de certos ataques futuros à troca de chaves. Esta característica não substitui a segurança do dispositivo, a retenção limitada de metadados nem o controlo de acesso ao servidor.
O Proof Lab também demonstra apenas algumas operações locais de P-256, HKDF e AES-GCM e exclui desse teste a combinação completa LVR1/LGS1. Um resultado bem-sucedido não garante a resistência de todo o produto à tomada da infraestrutura.
O que fazer numa avaliação ou num incidente real?
- Registe o tipo de acesso e as informações confirmadas; não confunda um rumor de interrupção com um incidente de segurança confirmado.
- Verifique a versão da aplicação e o estado de cifragem da conversa em causa.
- Verifique alterações de identidade, membros do grupo e sessões desconhecidas pelos canais oficiais.
- Não entregue a desconhecidos o segredo de recuperação, a palavra-passe ou conteúdo privado para uma “verificação de segurança”.
- Perante um risco grave ou uma questão jurídica, recorra ao especialista adequado e não tome medidas irreversíveis com base num artigo.
Uma conclusão fiável deve indicar quais dados estão protegidos, em que versão e contra que acesso. A frase “mesmo que o servidor seja apreendido, nada acontece” não substitui essa resposta.
