Remover alguém de um grupo encriptado deve impedi-lo de receber os segredos necessários para futuras mensagens protegidas. Alterar apenas a lista de membros não consegue isso se os restantes remetentes continuarem a usar material de chave que o antigo membro já conhece.
A transição também não é instantânea numa rede pouco fiável. Um desenho seguro de grupos deve definir a que estado de participação pertence uma mensagem e o que um remetente faz antes de ter processado uma remoção.
Mensagens passadas e futuras são problemas diferentes
Um antigo membro pode conservar mensagens, ficheiros e chaves recebidos enquanto estava autorizado. A remoção não pode fazê-lo esquecer o histórico nem apagar as suas capturas de ecrã.
O objetivo alcançável é excluí-lo do novo estado criptográfico depois de a remoção entrar em vigor. Da mesma forma, adicionar alguém levanta uma questão separada: se recebe acesso ao histórico antigo. Produtos e protocolos usam termos como forward secrecy em contextos diferentes, pelo que uma descrição simples da regra de acesso pretendida costuma ser mais clara do que uma designação ambígua.
Por que grupos com chaves de remetente precisam de estado novo
Num desenho com chaves de remetente, cada participante pode encriptar mensagens normais do grupo com uma cadeia partilhada com os destinatários permitidos. Isto pode evitar encriptar todo o conteúdo separadamente para cada destinatário em cada envio.
Após uma remoção, o antigo membro pode ainda possuir a cadeia anterior. Os restantes remetentes precisam, por isso, de estado substituto que não seja distribuído ao membro excluído, e os clientes precisam de um contexto de participação acordado para o utilizar. A rotação deve abranger os remetentes e dispositivos relevantes; alterar um único sinalizador no servidor não basta.
O protocolo exato importa. O MLS, especificado no RFC 9420, trata a remoção através de uma mudança de época confirmada que fornece nova entropia aos membros restantes. Este é um exemplo de transição de estado definida, não uma afirmação de que a Livara implementa MLS.
O que a Livara documenta para LGS1
A página de segurança da Livara descreve uma cadeia de remetente assinada por remetente, com chaves de remetente distribuídas através de sessões LVR1 entre pares. Afirma que são criadas e distribuídas novas chaves de remetente quando a composição do grupo muda.
Isso sustenta uma afirmação sobre o desenho publicado de renovação de chaves. Não estabelece um tempo medido de “revogação instantânea” nem prova que todas as condições de corrida, cenários de dispositivos offline e novas tentativas sejam tratados corretamente. Isso exige análise da implementação e testes.
Os controlos de participação no servidor e a exclusão criptográfica também têm funções diferentes. O serviço pode negar entrega ou acesso, enquanto a encriptação deve impedir que uma parte excluída com uma cópia de texto cifrado posterior o abra sem os novos segredos.
Um plano útil para testar a remoção
Num grupo de teste autorizado, verifique estes cenários com mensagens não sensíveis:
| Cenário | Questão a esclarecer |
|---|---|
| Membro removido enquanto todos estão online | Qual é a primeira mensagem sob o novo estado de participação? |
| Um remetente restante está offline | Tem de atualizar a participação e as chaves antes de voltar a enviar? |
| O membro removido volta a ligar-se mais tarde | Pode obter novas distribuições de chaves de remetente ou apenas conteúdo antigo autorizado? |
| Vários membros mudam ao mesmo tempo | Todos os dispositivos restantes convergem para o mesmo estado? |
| É repetido o envio de uma mensagem antiga | A sua época original é preservada, em vez de ser incorretamente identificada como conteúdo novo? |
Um teste apenas da interface pode confirmar o comportamento visível, mas não pode, por si só, provar a exclusão criptográfica. Uma avaliação rigorosa deve inspecionar que chaves e texto cifrado um dispositivo de teste excluído consegue obter.
O que os administradores devem recordar
Remova participantes desnecessários, reveja os membros restantes e evite enviar novos materiais sensíveis até a aplicação processar a alteração. Se um participante atual reencaminhar deliberadamente conteúdo, a renovação de chaves do grupo não pode impedir essa divulgação.
Para utilizações altamente sensíveis, peça ao fornecedor a semântica de remoção, o comportamento de revogação de dispositivos e provas de testes. A promessa importante é um limite bem definido para mensagens futuras, não uma afirmação sem fundamento de que um botão de remoção destrói todas as cópias passadas.
