Resumen

  • RFC 3185 propuso reutilizar la clave de contenido de un primer objeto CMS para derivar la clave de envoltura de objetos posteriores, optimizando transacciones y comunicaciones frecuentes.
  • La optimización conservaba autoridad histórica: si S1 recibió la primera CEK, todos sus miembros podían descifrar un mensaje posterior aunque el nuevo objeto declarara solo un subconjunto de S1.

La memoria era el precio oculto. El receptor guardaba una CEKReference, la clave de cifrado de contenido correspondiente y una expectativa sobre futuros mensajes. Sin ese estado, la optimización no funcionaba. Con él, el receptor conservaba una capacidad que el encabezado de un mensaje posterior no podía retirar por sí solo.

RFC 3185, Reuse of CMS Content Encryption Keys, apareció en octubre de 2001 en la vía de estándares y figura como Proposed Standard. Buscaba escenarios concretos: varios campos cifrados por separado en una transacción o servidores que se comunicaban con frecuencia. Como establecer claves mediante criptografía asimétrica podía ser costoso, una clave simétrica ya establecida podía alimentar el siguiente intercambio.

El documento no era gestión general de grupos ni un protocolo completo. Exigía que otra especificación definiera qué hacer si se perdía la clave referenciada. La API tenía que permitir la transformación del material; los algoritmos debían tener tamaños, formatos y fuerzas compatibles.

MSG1 incluía en unprotectedAttrs un identificador CEKReference. MSG2 repetía ese valor como KEKIdentifier. El identificador permitía localizar la CEK anterior, no la revelaba. A partir de ella se derivaba la KEK que desenvolvía la nueva CEK.

Para claves compatibles, la derivación invertía los bytes. La finalidad era evitar un ataque específico en el que texto claro y cifrado conocidos pudieran reutilizarse directamente como clave cifrada. Cuando los formatos diferían, una opción aplicaba PBKDF2 a la CEK anterior. El uso histórico de HMAC-SHA-1 y ejemplos DES no debe presentarse como recomendación actual; documentos posteriores son contexto, no prueba de despliegue.

La consecuencia de control era inequívoca. Si MSG1 llegaba al conjunto S1 y MSG2 se dirigía solo a una parte, todos los miembros de S1 conservaban la CEK necesaria para derivar la KEK de MSG2. La lista nueva describía la intención declarada. La distribución anterior describía la capacidad efectiva. Reducir una no reducía automáticamente la otra.

CEKMaxDecrypts anunciaba cuántos mensajes posteriores usarían la referencia. El emisor debía respetarlo; para el receptor era una pista. Sin atributo se asumía una reutilización. El receptor podía retener estado hasta completar el número o alcanzar un límite temporal local. Un valor desmesurado, o mensajes que nunca llegaban, podía consumir memoria.

Por eso el contador no era revocación ni borrado verificable. No demostraba recepción, uso exitoso, eliminación de copias ni olvido por un miembro desconectado. Cada receptor controlaba su propio almacenamiento. La realidad de custodia no se deducía del entero enviado por el originador.

La referencia tampoco autenticaba. RFC 3185 advertía que cualquiera podía construir EnvelopedData con un valor conocido. Reconocerlo no probaba al remitente. Usar la clave correcta tampoco impedía inserción o repetición. Identidad, autorización, integridad, orden y frescura necesitaban mecanismos distintos.

El éxito de descifrado solo decía que cierto estado y ciertos parámetros produjeron texto claro bajo las comprobaciones realizadas. No demostraba que el mensaje fuera nuevo, que antiguos receptores hubieran perdido acceso, que el texto se tratara de forma segura ni que la aplicación aceptara la operación.

La cadena podía rodar: una CEK fresca de MSG[n] se convertía en referencia para MSG[n+1]. RFC 3185 advertía contra derivar circularmente la CEK del propio KEK, porque podía fijarse una clave sin querer. El sistema debía registrar cuál secreto anterior produjo qué autoridad nueva y si la CEK siguiente era realmente independiente.

También importaba el motivo de fallo. Referencia desconocida, estado expulsado, derivación no soportada, parámetros modificados, algoritmo incompatible o clave errónea no son equivalentes. Un único mensaje «no se pudo descifrar» borra la diferencia entre política local, incompatibilidad y manipulación.

La historia de RFC 3185 enseña que la eficiencia mueve el costo, no lo elimina. El cómputo ahorrado reaparece como retención, sincronización, revocación y prueba. Para conocer quién podía leer el segundo objeto, el sobre visible era menos decisivo que el historial del primero.