Resumo

  • RFC 3185 permitiu que uma CEK usada em MSG1 derivasse a KEK de mensagens posteriores, economizando operações assimétricas e exigindo retenção de estado.
  • Se MSG1 entregasse a CEK ao conjunto S1, todos os membros de S1 poderiam abrir MSG2 mesmo que o novo objeto declarasse apenas um subconjunto; nem a lista nem CEKMaxDecrypts provavam revogação.

Publicado em outubro de 2001 no Standards Track e listado como Proposed Standard, Reuse of CMS Content Encryption Keys partia de uma vantagem concreta. Um cliente podia cifrar vários campos numa transação; servidores podiam trocar objetos continuamente. Repetir estabelecimento assimétrico custava mais do que reaproveitar material simétrico existente.

O RFC não oferecia protocolo completo nem gestão geral de grupos. O contexto externo precisava definir perda da chave, retenção e erros. A API deveria permitir transformar o material, e os algoritmos de conteúdo e envoltório precisavam de formatos e forças compatíveis.

MSG1 trazia CEKReference em atributos não protegidos. MSG2 reutilizava o valor como KEKIdentifier. A referência localizava a CEK guardada; não era a própria chave. A partir da CEK anterior derivava-se a KEK que desembrulhava uma nova CEK.

Com formatos compatíveis, invertiam-se os bytes; quando diferentes, havia opção PBKDF2. A inversão respondia a um ataque específico de texto conhecido. Os parâmetros de 2001 são história normativa, não recomendação atual nem prova de implantação.

O efeito sobre destinatários era explícito. Se S1 recebeu MSG1, enviar MSG2 apenas a parte de S1 não impedia os demais de derivar a KEK. O envelope atual descrevia intenção; a entrega anterior determinava capacidade. Remover um nome sem mudar a linhagem não revogava acesso.

CEKMaxDecrypts informava o número máximo de reutilizações planejadas. O originador tinha de respeitá-lo; o receptor o tratava como pista. Ausente, equivalia a um. O receptor podia eliminar estado por limite local, inclusive para evitar consumo de memória provocado por valor enorme ou mensagens prometidas que nunca chegavam.

Nada disso certificava apagamento. Receptores podiam observar quantidades diferentes, ficar offline ou manter cópias fora do contador. O valor representava intenção de uso, não um ato verificável em cada armazenamento.

RFC 3185 também dizia que criptografia não autentica. Conhecer a referência não provava o remetente; referência correta não impedia replay ou inserção. Decriptação bem-sucedida não provava frescor, autorização, exclusão de antigos membros, custódia segura do texto claro ou sucesso da aplicação.

Uma cadeia podia rolar de CEK em CEK. Era necessário registrar origem, destino e independência do novo material, evitando derivação circular que fixasse uma chave. Também era preciso distinguir referência ausente, estado expirado, algoritmo incompatível, função não suportada e parâmetro alterado, em vez de um único erro.

A lição é temporal: a lista pertence ao objeto presente; o poder pertence à história de distribuição. Saber quem podia ler MSG2 exige evidência de MSG1, retenção, derivação e uso, não apenas o cabeçalho mais recente.