Recuperar uma conta, uma identidade e um histórico de conversas são operações diferentes; verifique qual delas o produto realmente suporta.
A recuperação da identidade criptográfica restaura o material de chaves associado à sua identidade no mensageiro. Não é automaticamente o mesmo que voltar a entrar numa conta, restaurar todas as conversas ou provar que um dispositivo de substituição é seguro.
Uma cópia de segurança cifrada das chaves pode permitir que um servidor armazene um pacote recuperável sem possuir o segredo necessário para o abrir. A proteção oferecida por esse modelo depende da geração de chaves, da autenticação, da guarda do segredo de recuperação e de como o cliente trata a identidade recuperada.
Três coisas a que se chama “recuperação”
| Objetivo da recuperação | O que precisa de ser restaurado ou autorizado |
|---|---|
| Acesso à conta | Permissão para iniciar sessão e utilizar o serviço |
| Identidade criptográfica | As chaves privadas adequadas ou uma nova identidade autenticada |
| Histórico de conversas | Os dados das mensagens e as chaves ou estado necessários para os ler |
Um início de sessão bem-sucedido não prova nenhuma das outras duas coisas. Do mesmo modo, uma chave de identidade não recria necessariamente chaves antigas de mensagens que tenham sido apagadas deliberadamente, nem um ficheiro de histórico que já não existe.
Antes de confiar na função de recuperação de um produto, registe qual é o objetivo que ela realmente promete cumprir.
Como pode funcionar uma cópia cifrada da identidade
Um modelo típico gera o material de identidade num dispositivo de confiança, cifra uma cópia com um segredo de recuperação separado e guarda no serviço apenas o pacote protegido. Um dispositivo de substituição obtém o pacote e utiliza o segredo de recuperação localmente.
O servidor ainda pode controlar o acesso ao pacote, observar pedidos, reter dados ou devolver uma versão mais antiga. A cifragem autenticada e a vinculação à versão e à identidade ajudam a lidar com riscos específicos de adulteração; a disponibilidade e o tratamento de reversões exigem um projeto próprio. “Cifrado no servidor” não é uma resposta completa para todos os cenários de comprometimento do servidor.
Uma chave de recuperação aleatória de alta entropia e uma palavra-passe escolhida por uma pessoa também são entradas diferentes. Não descreva o HKDF como um método que transforma qualquer frase-passe fraca num segredo forte. O RFC 5869 discute o papel do HKDF e distingue-o do reforço de palavras-passe por aumento do custo computacional.
O que diz a documentação v7 do Livara
A página de segurança do Livara afirma que as suas chaves P-256 de acordo de chaves e assinatura, bem como a semente ML-KEM, são cifradas no dispositivo com uma chave de recuperação aleatória de 256 bits antes do envio. O formato v7 autentica informações que incluem o conjunto de algoritmos, a época da identidade e a geração.
A mesma página é explícita: restaura a identidade, não o histórico de conversas. Também afirma que uma palavra-passe de início de sessão correta, por si só, não basta para abrir a cópia cifrada das chaves; é necessária a chave de recuperação representada pela frase de recuperação.
São declarações publicadas sobre o produto, não uma nova auditoria ao formato da cópia ou a todos os percursos de recuperação. O modelo de ameaças, mais geral, deve ser lido em conjunto com esta descrição mais específica da recuperação.
Onde se enquadra o SRP
O modelo de autenticação SRP diz respeito ao início de sessão baseado em palavra-passe. Pode evitar a transmissão da própria palavra-passe na troca prevista pelo protocolo, mas não define o conteúdo de uma cópia das chaves nem deriva automaticamente todas as chaves de recuperação.
O seu verificador no servidor continua a precisar de proteção. O RFC 5054, secção 3.3 descreve o risco de adivinhação de palavras-passe após o roubo de um verificador. Não transforme “o servidor não recebe a palavra-passe nesta troca” em “uma invasão do servidor não pode expor nada de útil”.
As sessões da conta, os pacotes de recuperação, os metadados operacionais e o software cliente são ativos separados, com modos de falha distintos.
Lista de preparação para uma recuperação segura
- Confirme exatamente que dados a função restaura e quais não restaura.
- Guarde o segredo de recuperação onde perder o telemóvel não signifique também perder a única cópia.
- Evite colocar o segredo numa mensagem, num pedido de apoio ou numa captura de ecrã pública.
- Proteja o local onde o segredo está guardado; quem o obtiver poderá ganhar capacidades importantes se também obtiver a cópia relevante e o acesso.
- Consulte as instruções oficiais de recuperação antes de apagar ou substituir o único dispositivo funcional.
- Teste apenas através de procedimentos suportados, sem destruir a única cópia de dados importantes.
Depois da recuperação, examine separadamente os dispositivos associados e as sessões. O material de identidade recuperado não revoga automaticamente um dispositivo antigo. Se a identidade criptográfica mudar, os contactos com quem troca informações sensíveis devem verificar a nova chave por uma via de confiança independente.
Se a frase de recuperação se perder
Não presuma que o apoio técnico consegue recriar um segredo que o sistema foi concebido para não guardar. Da mesma forma, não presuma que esquecer a palavra-passe de uma conta significa sempre que todas as mensagens locais já desapareceram. O resultado depende dos dispositivos que restam, das cópias disponíveis e das regras documentadas do produto.
A pergunta útil é concreta: “Que segredo ou cópia está em falta e que objetivo de recuperação continua a ser possível?”. Isso produz uma resposta mais segura do que uma promessa genérica de que a recuperação é fácil ou impossível.
