Resumen

  • RFC 3537 antepuso un octeto de longitud a la clave HMAC y añadió relleno aleatorio para llevar el registro a un envoltorio 3DES o AES.
  • Superar la integridad permitía recuperar los bytes declarados, no vinculaba algoritmo HMAC, propósito, principal u origen; cualquier poseedor de la KEK podía crear un sobre aceptable.

Pensemos en una caja fuerte que entrega una tira de material de la medida exacta. El contador funciona y el precinto está intacto, pero no hay orden de trabajo. La medida resuelve cómo extraer el contenido, no qué acción autoriza. Esa fue la frontera incorporada por RFC 3537.

El Proposed Standard de mayo de 2003 respondió a una incompatibilidad práctica. RFC 3217 envolvía claves de contenido 3DES con restricciones de paridad; RFC 3394 trabajaba con bloques de 64 bits. Una clave HMAC podía tener otra longitud y no tenía paridad DES. En vez de cambiar las primitivas, RFC 3537 creó un registro interior adaptable.

Su forma era LENGTH || KEY || PAD: un octeto de longitud, ese número de octetos de clave y el mínimo relleno aleatorio para alcanzar un múltiplo de ocho. Al desenvolver, se leía LENGTH, se recortaba KEY y se rechazaba un PAD superior a siete octetos.

«Longitud arbitraria» eliminaba tamaños fijos, pero el campo de un octeto no representa infinito. Esa limitación se infiere del formato, no de una cifra máxima escrita por el RFC. Aun así, la implementación debe obedecer el campo y no convertir la introducción en una garantía sin límite.

La vía 3DES calculaba un checksum de ocho octetos sobre longitud, clave y relleno; añadía un IV aleatorio, cifraba en CBC, anteponía el IV, invertía los octetos y cifraba otra vez con 4adda22c79e82105. La vía AES entregaba el mismo registro a RFC 3394 y solo interpretaba LENGTH después de la integridad interna. El registro A de RFC 3394 ya pertenece a otra historia; aquí importa lo que la puerta libera sin tipar.

Dentro no hay identificador del HMAC que consumirá la clave, protocolo, inquilino, principal, ID, fecha, caducidad ni clase de mensaje. PAD está protegido, pero no significa una finalidad. LENGTH marca el final de la clave, no el final de su autoridad.

Los OID HMAC-with-3DES-wrap y HMAC-with-AES-wrap, con parámetro obligatorio NULL, nombran el método del sobre. No nombran HMAC-SHA-1, HMAC-SHA-2 ni un servicio. Inferir esas decisiones a partir de «AES wrap» mezcla la técnica de transporte con la política de uso.

La guía de RFC 2104 recomienda una clave de al menos la salida del hash y explica que exceder mucho el bloque suele no aportar seguridad. Pero el desenvoltorio no selecciona hash ni aplica un mínimo específico. Una clave recuperada correctamente puede seguir siendo inadecuada para el trabajo asignado.

La sección de seguridad niega una promoción aún más peligrosa. El wrap ofrece confidencialidad e integridad, no necesariamente autenticación de origen. Todo poseedor de la KEK puede construir un mensaje que pase. La distribución de KEK debe autenticar el origen, o hay que usar una firma. Abrir el sobre identifica un dominio de KEK, no al autor dentro de él.

Comprometer la KEK permite leer todas las claves envueltas y fabricar otras nuevas. Si la KEK compartida funciona como identidad, la intrusión obtiene autoridad sobre cada flujo que confíe en ella. Custodia, destinatarios y separación de dominios deben conservarse fuera del ciphertext.

El IV 3DES debe ser nuevo en cada invocación y el relleno es aleatorio. Esa aleatoriedad modela el sobre; no se convierte en etiqueta de algoritmo ni nonce de la futura operación HMAC.

La única errata Verified cambia el PAD del vector de 38be62 a be62fe, valor coherente con la concatenación mostrada. Es Editorial y no modifica el procedimiento.

CMS en RFC 5652, los paquetes de RFC 6031, los identificadores HMAC-SHA-2 de RFC 4868 y los marcos de RFC 5649 y NIST SP 800-38F pueden añadir contexto exterior. Ninguno inserta retrospectivamente finalidad en LENGTH || KEY || PAD.

La evidencia completa registra OID, KEK y permiso, integridad, longitud y bytes, algoritmo HMAC autenticado, ID, propósito, principal, vigencia, ejecución, verificación y resultado de aplicación. RFC 3537 hizo interoperable la recuperación; no convirtió esa recepción en autorización universal.

Fuentes