Resumo

  • Para o RFC 5275, retirar alguém de uma lista fechada ou gerenciada não encerra o acesso por si só: sem nova chave, o ex-membro ainda pode decifrar mensagens que conseguir obter.
  • O encerramento defensável exige uma cadeia de evidências que separe lista efetiva, geração de chaves, entrega, ativação, retirada das chaves antigas e exposição residual.

Uma organização pode preparar a continuidade do próximo ano em uma única tarde. Basta entregar agora várias chaves com datas futuras. Também pode criar, nessa mesma tarde, anos de autoridade que uma decisão posterior não conseguirá recolher. Essa é a assimetria silenciosa no centro do RFC 5275.

O documento, publicado pela IETF em 2008 no Standards Track, especifica gestão e distribuição de chaves simétricas com CMS. Seu alerta mais importante não depende da idade dos algoritmos. Em uma lista fechada ou gerenciada, a remoção de um membro precisa ser acompanhada por uma troca de chaves. Caso contrário, o membro removido mantém a chave compartilhada e continua capaz de decifrar as mensagens protegidas que alcançar.

A lista decide pertencimento; a chave materializa poder

O Group List Owner, GLO, cria a lista, escolhe seu regime e governa membros e política de troca. O Group List Agent, GLA, executa as funções de gestão da lista e das chaves e assina as mensagens glKey usadas para entregar KEKs compartilhadas.

A separação é útil, mas não transforma o agente em árbitro da realidade. O próprio RFC observa que um GLA corrompido sempre pode causar estragos. Uma autorização identifica quem pode agir; não comprova que o efeito pretendido apareceu em todos os pontos do sistema.

glDeleteMember registra uma solicitação assinada. Ela pode vir do proprietário ou, conforme a modalidade da lista, do membro que pede a própria saída. Para listas fechadas e gerenciadas, o procedimento combina a exclusão com glRekey. O proprietário também precisa verificar se a pessoa não aparece duas vezes: apagar um registro e deixar um alias ativo mantém a entrega das chaves.

O verbo “concluir” esconde estados diferentes

A nova glKey informa nome do grupo, identificador, KEK encapsulada, algoritmo e janela de validade. Quando os participantes não podem saber quem mais pertence ao grupo, o GLA envia uma mensagem separada a cada um. Se glRekeyAllGLKeys for verdadeiro, todas as KEKs pendentes devem ser reemitidas.

Essas regras impedem um relatório sério de condensar tudo em “rekey concluído”. Primeiro, a exclusão deve ser aceita. Depois, uma geração de membros sem todas as identidades do sujeito precisa entrar em vigor. Em seguida vêm geração e entrega das novas chaves. Então remetentes e destinatários precisam cruzar um ponto de ativação. Por fim, as chaves antigas e futuras já distribuídas devem deixar de valer onde isso pode ser imposto.

Uma mensagem enviada não garante recebimento. Recebimento não garante ativação. Um retorno de sucesso assinado pelo agente atesta a visão do agente, não a memória de cada endpoint. E nenhuma dessas evidências comprova que um dispositivo fora do controle do grupo destruiu a cópia anterior.

A multiplicação que alonga o ataque

generationCounter controla quantas chaves são distribuídas ou permanecem disponíveis; duration controla por quanto tempo cada uma vale. O padrão exige pelo menos duas chaves na distribuição inicial para que a lista não pare na mudança de período.

O RFC oferece um exemplo que funciona como teste de realidade: quatorze chaves, cada uma válida por um ano, deixam a última exposta a pelo menos treze anos de tentativa de ataque. Quanto maior o estoque de gerações futuras, mais distante fica o limite da autoridade já entregue.

Isso muda o cálculo de uma saída. Não basta trocar a chave usada hoje. É preciso descobrir todas as chaves atuais e futuras que o ex-membro recebeu. O escopo de revogação acompanha o que a pessoa consegue alcançar, não apenas o que o painel diz estar “ativo”.

Há também herança entre chaves. Uma KEK pode encapsular outra, que protege uma terceira. Se uma chave dessa cadeia for comprometida, o RFC 5275 determina que todas as seguintes sejam consideradas comprometidas. A investigação precisa percorrer os descendentes, mesmo que ainda não tenham chegado à data de uso.

Origem sem contexto é insuficiente

Quem armazena uma KEK deve vinculá-la ao nome do GLA que a distribuiu, para verificar se as trocas posteriores vieram da mesma entidade. A assinatura prova o signatário; o vínculo armazenado prova se esse signatário pertence à continuidade esperada do grupo.

O mesmo vale para nonce e signingTime. Eles só defendem contra repetição quando as partes guardam estado suficiente para comparar mensagens. Relógios podem divergir, a política local define tolerância e mensagens com data futura precisam ser tratadas. Sem memória, um horário assinado continua sendo apenas um campo.

A fronteira nova não apaga a antiga

Depois do corte, a chave anterior pode deixar de proteger tráfego novo. Mas mensagens já copiadas em caixas postais, repositórios ou backups permanecem onde estavam. Chaves exportadas e textos já decifrados também não retornam.

A exposição residual é a interseção entre o ciphertext ainda acessível e o material de chave ainda retido. Essa formulação separa contenção futura de recuperação histórica. É possível fechar muito bem o futuro sem afirmar que o passado foi apagado.

Um recibo que respeite cada camada

RFC 5275 não define um ledger moderno de transparência nem uma prova universal de eliminação. Ainda assim, suas transições permitem desenhar um recibo operacional estreito. Ele deve ligar a ordem assinada ao grupo e ao sujeito; identificar a geração efetiva da lista; enumerar chaves atuais, futuras e dependentes; preservar cada resultado de entrega; marcar a ativação; registrar onde a chave antiga deixou de ser usada; e declarar as cópias ou mensagens fora de alcance.

Falhas não devem ser suavizadas por uma taxa agregada. Um destinatário remanescente sem chave nova exige uma decisão de disponibilidade. Uma identidade duplicada deixa a lista aberta. Uma chave futura derivada de uma KEK comprometida deixa o estado criptográfico aberto.

O princípio é simples: o registro diz quem deveria ter autoridade; o sistema em execução mostra quem ainda a exerce. O encerramento só é real quando as duas camadas voltam a coincidir.