A encriptação ponta a ponta não exige que um serviço de mensagens evite o armazenamento central. Um servidor pode guardar mensagens encriptadas para sincronização sem deter os segredos necessários para ler o seu conteúdo.
A parte difícil das mensagens em vários dispositivos é decidir quais dispositivos estão autorizados, que chaves recebem e se podem aceder ao histórico antigo. Estas decisões são mais importantes do que a utilização de uma base de dados pelo sistema.
Quatro operações distintas frequentemente chamadas «sincronização»
| Operação | O que precisa de assegurar |
|---|---|
| Entrega de novas mensagens | Fazer chegar conteúdo protegido aos dispositivos atualmente autorizados |
| Associação de um novo dispositivo | Estabelecer que o titular da conta aprova o novo ponto terminal |
| Transferência do histórico | Dar ao novo dispositivo acesso a conteúdo anterior selecionado e ao material necessário para o desencriptar |
| Recuperação da identidade | Restaurar ou substituir chaves de identidade sem necessariamente restaurar o histórico de mensagens |
Um produto pode suportar uma operação sem suportar as quatro. Iniciar sessão com êxito não prova que o histórico antigo de conversas seja recuperável.
Como a entrega encriptada pode suportar vários dispositivos
Uma abordagem mantém sessões separadas para cada dispositivo. A especificação Sesame do Signal descreve a gestão de sessões num ambiente assíncrono com vários dispositivos, incluindo a adição ou remoção de dispositivos e a chegada de mensagens fora de ordem.
É um exemplo documentado de conceção, não um requisito universal. Outros sistemas podem encriptar o conteúdo uma vez e distribuir chaves de conteúdo protegidas, usar mecanismos de grupo ou combinar abordagens. «A E2EE exige uma cópia integral da carga útil por dispositivo» é uma afirmação demasiado abrangente.
Qualquer que seja a conceção escolhida, adicionar um dispositivo capaz de desencriptar adiciona um ponto terminal que precisa de proteção. Um portátil negligenciado pode expor o texto em claro que recebe, mesmo que o servidor nunca veja esse texto.
O texto cifrado armazenado continua a ter implicações de privacidade e retenção
Armazenamento encriptado não significa ausência de armazenamento. Os fornecedores podem reter informações de entrega, registos de dispositivos, carimbos de data e hora, pertença a grupos ou histórico encriptado de mensagens. Os detalhes variam e devem ser explicitados.
A documentação de segurança do Livara diz que o seu retransmissor guarda texto cifrado e dados operacionais para sincronização e recuperação após a ligação ser restabelecida. Descreve encaminhamento, pertença a grupos, carimbos de data e hora, estado de entrega e outros registos. Isto não deve ser caracterizado como uma fila transitória não documentada que necessariamente desaparece assim que todos os dispositivos recebem uma mensagem.
A confidencialidade do conteúdo e a retenção de metadados exigem, por isso, perguntas separadas. Pergunte o que é retido, durante quanto tempo e o que muda com a eliminação de dados ou da conta; não invente um prazo de retenção quando nenhum foi verificado.
O que a recuperação v7 do Livara realmente restaura
O Livara descreve a v7 como uma cópia de segurança encriptada da identidade, selada antes do envio com uma chave de recuperação aleatória de 256 bits. A carga útil documentada inclui material de chaves de identidade, e o formato autentica o conjunto criptográfico, a época da identidade e a geração.
A mesma página afirma que restaura a identidade, não o histórico de conversas. Uma frase de recuperação não deve, portanto, ser apresentada como garantia de que um novo dispositivo consegue mostrar todas as conversas antigas.
Antes de substituir ou apagar um dispositivo, verifique as opções atuais de transferência de histórico e cópia de segurança efetivamente disponíveis. Mantenha privado todo o material de recuperação. Não envie uma frase de recuperação para uma conta de apoio nem a cole num site não verificado.
O sigilo futuro não apaga a caixa de entrada de um dispositivo autorizado
Um mecanismo de catraca pode limitar o que um comprometimento posterior de chaves revela sobre tráfego encriptado anterior, quando os seus pressupostos se verificam e os segredos obsoletos são eliminados. Não pode ocultar texto em claro que um ponto terminal já guardou nem impedir malware que continua ativo de ler novas mensagens.
Da mesma forma, a segurança pós-comprometimento exige uma atualização nova e adequada depois de o atacante perder o acesso. Não é uma promessa de que qualquer tablet antigo se torna inofensivo sempre que um contador de mensagens avança.
Lista de verificação para uma mudança de dispositivo mais segura
- Faça um inventário dos dispositivos associados antes de adicionar outro.
- Use o processo documentado de associação e verificação da aplicação, não um código QR enviado por um desconhecido.
- Verifique que histórico o novo dispositivo recebe através de uma conversa de teste sem conteúdo sensível.
- Confirme o material de recuperação e qualquer cópia de segurança separada do histórico antes de apagar o dispositivo antigo.
- Revogue os dispositivos que já não controla e verifique se os interlocutores recebem um aviso de alteração de identidade.
- Reveja as transferências locais, as notificações e as cópias de segurança do sistema operativo em cada ponto terminal.
O modelo de ameaças do Livara inclui explicitamente as limitações dos pontos terminais e dos destinatários. Essas limitações continuam relevantes em todos os ecrãs. Uma promessa útil de utilização em vários dispositivos explica separadamente a autorização dos dispositivos, os dados armazenados e o âmbito da recuperação.
