Resumo

  • O RFC 3537 formava LENGTH || KEY || PAD, com um octeto de tamanho e preenchimento aleatório, para colocar uma chave HMAC variável em wrap 3DES ou AES.
  • O unwrap recuperava os bytes e verificava integridade, mas não vinculava algoritmo HMAC, finalidade, principal ou origem; qualquer detentor da KEK podia criar um envelope aceito.

Imagine um cofre que libera uma fita do comprimento exato. O lacre passou, mas falta a ordem que diz em qual máquina a fita pode entrar. Medida e missão são fatos diferentes. O RFC 3537 tornou a primeira interoperável e manteve a segunda fora do formato.

O Proposed Standard de maio de 2003 tratava de um encaixe difícil. O RFC 3217 trabalhava com chaves 3DES sujeitas a paridade; o RFC 3394 recebia blocos de 64 bits. Chaves HMAC podiam ter outros tamanhos. A solução foi um registro interno, não uma nova primitiva.

O primeiro octeto era LENGTH, seguido por KEY e pelo mínimo PAD aleatório para fechar múltiplo de oito. No unwrap, o receptor recortava a chave e rejeitava preenchimento restante maior que sete. “Tamanho arbitrário” removia tamanhos fixos, mas não tornava infinito um campo de um octeto; essa é uma limitação observável da representação.

No 3DES, checksum de oito octetos protegia comprimento, chave e PAD. Um IV novo iniciava CBC; depois o IV era prefixado, a sequência invertida e cifrada de novo com 4adda22c79e82105. No AES, o registro seguia para o RFC 3394 e só era interpretado após sua integridade. O mecanismo do registro A pertence ao artigo RFC 3394; aqui importa o tipo que não veio junto.

Não há algoritmo HMAC, protocolo, tenant, principal, ID, data, expiração ou operação permitida dentro do registro. PAD está coberto pela integridade, mas não significa finalidade. LENGTH marca o fim dos bytes, não o fim da autoridade.

Os OIDs HMAC-with-3DES-wrap e HMAC-with-AES-wrap exigem parâmetro NULL. Eles nomeiam o modo de embrulhar, não o HMAC que usará a chave. Inferir HMAC-SHA-2 ou uma permissão de serviço a partir de “AES wrap” acrescenta política não registrada.

O conselho do RFC 2104 recomenda tamanho ao menos igual à saída do hash e limita o benefício de chaves muito maiores que o bloco. Porém o unwrap não escolhe o hash nem executa mínimo específico. Recuperação estrutural não é aprovação de força.

A seção de segurança diz que wrap oferece confidencialidade e integridade, não necessariamente autenticação de origem. Qualquer pessoa com a KEK fabrica uma mensagem válida. É preciso autenticar a distribuição da KEK ou usar assinatura. O sucesso aponta para o domínio da KEK, não para um criador dentro dele.

Uma KEK comprometida revela chaves antigas e permite inserir novas. Quando a organização trata KEK compartilhada como identidade, cada fluxo que confia nela amplia o poder do invasor. Custódia e escopo precisam de registro separado.

IV 3DES deve ser novo em cada chamada e PAD é aleatório. Essa aleatoriedade serve ao envelope; não é tag de algoritmo ou nonce da operação HMAC futura.

A única errata Verified troca o PAD do vetor de 38be62 para be62fe, coerente com a concatenação. É Editorial, sem mudar o procedimento.

RFC 5652, RFC 6031, RFC 4868, RFC 5649 e NIST SP 800-38F dão estruturas externas, identificadores ou contexto moderno. Nenhum injeta finalidade retroativa em LENGTH || KEY || PAD.

A cadeia deve guardar OID, KEK e permissão, integridade, comprimento e bytes, HMAC autenticado, ID, finalidade, principal, validade, execução, verificação e resultado. O RFC 3537 resolveu a recuperação, não autorizou o restante.

Fontes