Resumo

  • Um AuthEnvelopedData pode indicar AES-GCM corretamente, trazer parâmetros válidos e passar na verificação da tag sem provar que o par chave/nonce nunca apareceu em outro objeto.
  • A RFC 5084 exige gestão automatizada de chaves e apresenta uma CEK nova por conteúdo como construção segura; suporte ao algoritmo não comprova a disciplina de ciclo de vida.

Quatro workers cifram documentos com a mesma chave de conteúdo. Cada um possui um contador local que parece monotônico. A plataforma cresce, um quinto worker nasce de uma imagem antiga e o próximo número volta a aparecer. O envelope produzido não tem um campo malformado. O erro está na autoridade distribuída para alocar o nonce.

A RFC 5084 especifica AES-CCM e AES-GCM no AuthEnvelopedData do CMS. Ela atribui identificadores para cada tamanho de chave AES, exige parâmetros, determina comprimentos de ICV e usa os atributos autenticados do CMS como dados autenticados adicionais.

Para os dois modos, a unicidade é definida dentro do escopo de uma chave. O conjunto de nonces usado com a mesma chave não pode conter duplicatas. Repetir a combinação em mensagens diferentes destrói as propriedades de segurança. O objeto atual informa um nonce, mas não conhece todos os workers, regiões, backups e operações anteriores que compartilharam a CEK.

Isso explica por que tamanho correto não é prova histórica. Doze octetos são recomendados para o nonce GCM e favorecem eficiência, mas um clone também produz doze octetos corretos. Aleatoriedade aparente não exclui a repetição causada por estado de PRNG duplicado.

A resposta normativa é gestão automatizada de chaves. A RFC descreve transporte e acordo de chaves, chaves simétricas que cifram outras chaves e chaves derivadas de senha. Essas técnicas atendem ao requisito quando uma nova chave de cifração autenticada de conteúdo, a CEK, é criada para cada conteúdo.

Uma CEK nova reduz a necessidade de um contador global durável. Nonces iguais sob CEKs realmente distintas não formam o par proibido. Se a empresa prefere uma CEK de vida longa, assume um serviço de alocação atômico que precisa sobreviver a escalonamento, restauração e troca de região sem voltar no tempo.

Os parâmetros dentro do objeto continuam essenciais. GCMParameters leva nonce e ICV de doze a dezesseis octetos; doze é padrão e recomendação, e deve coincidir com o campo mac. Em CCM, o nonce tem sete a treze octetos e o ICV usa valores pares de quatro a dezesseis, com doze recomendado. Há ainda um compromisso entre o nonce CCM e o espaço reservado ao comprimento do conteúdo.

Um parser deve rejeitar ausência, valor impossível ou divergência de comprimento. Aprovar esses testes comprova a codificação daquele objeto. Não comprova a origem aleatória da CEK, a aceitação pela política local ou a ausência de outro emissor com o mesmo estado.

A RFC 5083 define o contêiner. Na RFC 5084, os atributos autenticados compõem o AAD: ficam protegidos, mas visíveis. O MAC cobre esses atributos e o conteúdo cifrado. Atributos não autenticados permanecem sem essa proteção, mesmo dentro do mesmo envelope.

Logo, uma tag válida não transforma metadado desprotegido em ordem autorizada. Ela demonstra coerência criptográfica das entradas protegidas com a chave de verificação. Identidade humana, legitimidade do documento, poder do destinatário para agir e resultado do processamento pertencem a recibos diferentes.

A interface da RFC 5116 recebe chave, nonce, texto e dados associados. O algoritmo não consulta o histórico externo que não lhe foi fornecido. A NIST SP 800-38D também trata a unicidade do IV como condição operacional crítica do GCM.

O registro auditável deve identificar a chave sem revelá-la. Para cada operação, associe uma época não secreta de CEK, o namespace do alocador, o evento atômico que entregou o nonce, os atributos autenticados exatos, o hash do cifrado, o tamanho da tag, o resultado da verificação e a versão do emissor.

Não basta procurar números repetidos. Dois conteúdos com CEKs novas diferentes podem usar os mesmos bytes de nonce com segurança. Um monitor que agrupa apenas por um apelido genérico fabrica um incidente. O vínculo com a época real da chave define tanto o alcance da detecção quanto o limite da resposta.

Uma cadeia reconstruível separa os bytes CMS; OID e parâmetros; época da CEK ou geração de chave nova; alocação do nonce; AAD exato; cifrado e tag; destinatário e método de gestão de chave; resultados de parse, abertura e verificação; consulta histórica; política de liberação do texto; autorização e resultado do aplicativo.

Essa lista é recomendação operacional, não sintaxe inventada para a RFC 5084. Pela disciplina de camadas de realidade de Heng Lu, nome do algoritmo, objeto, tag, unicidade histórica e decisão de negócio são registros adjacentes, não intercambiáveis.

Fontes