Resumen

  • RFC 5275 advierte que un miembro retirado de una lista cerrada o administrada conserva la posibilidad de descifrar mensajes accesibles si el grupo no cambia sus claves.
  • El cierre verificable exige probar la generación de membresía, el alcance de todas las claves afectadas, la entrega a quienes permanecen, el cambio de uso y el riesgo residual.

Hay bajas que sólo existen en el plano del registro. El nombre desaparece, el informe mensual cuenta una persona menos y el sistema devuelve éxito. Pero si la persona conserva el secreto con el que se protege la comunicación, el hecho operativo más importante no ha cambiado.

RFC 5275 nació para gestionar y distribuir claves simétricas con CMS. Su arquitectura es antigua en fecha, pero extremadamente actual en la distinción que impone. Una lista cerrada o administrada debe renovarse cuando se elimina un miembro. Si no se renueva, dice el estándar, el miembro sigue poseyendo la clave del grupo y puede descifrar todo mensaje protegido que consiga obtener.

Tres decisiones que parecen una

El propietario de la lista, GLO, decide su régimen y administra pertenencia y política. El agente de la lista, GLA, concentra las funciones de gestión del grupo y de las claves. Puede haber separación interna entre ambas, pero el RFC deja esa relación fuera de alcance y reconoce que un agente corrupto puede causar daño.

En ese diseño se esconden tres decisiones distintas. La primera es normativa: quién debe seguir perteneciendo. La segunda es distributiva: qué miembros reciben la nueva clave. La tercera es operativa: desde qué instante los emisores y receptores dejan de aceptar la generación anterior.

glDeleteMember expresa la primera. Puede estar firmado por el propietario o, cuando el modelo lo permite, por el miembro que pide su propia salida. glRekey inicia la segunda y sólo puede ser promovido por el propietario o el agente según la política configurada. glKey, firmado por el agente, transporta la clave envuelta, su identificador y el intervalo de validez. Ningún mensaje, aislado, demuestra las tres decisiones.

La identidad duplicada rompe la baja perfecta

El estándar señala una cuestión que los directorios suelen ocultar: antes de confiar en la eliminación, el propietario de una lista administrada o cerrada debe comprobar que la misma persona no está incorporada dos veces. Una baja puede eliminar el nombre visible y conservar un segundo registro que seguirá recibiendo renovaciones.

Por eso la unidad de prueba no es la fila eliminada. Es una generación concreta de membresía, con reglas explícitas para resolver equivalencias de identidad. Sólo después de cerrar ese conjunto tiene sentido crear las claves de la siguiente generación.

Para los grupos en los que los miembros no deben conocerse entre sí, el agente envía un glKey distinto a cada destinatario. Esa privacidad es valiosa, pero transforma un acto colectivo en una colección de resultados individuales. Una entrega fallida no puede quedar absorbida por el mensaje “renovación completada”.

La clave de mañana ya puede estar fuera

RFC 5275 permite preparar continuidad mediante varias claves por adelantado. generationCounter indica cuántas se distribuyen o mantienen pendientes y duration cuánto tiempo será válida cada una. El mínimo inicial es dos: cuando vence la primera, la segunda ya está disponible.

El precio de esa comodidad es una superficie temporal. El propio RFC usa catorce generaciones de un año para mostrar que la última ofrece al menos trece años de oportunidad de ataque. Ese ejemplo no es una recomendación de parámetros; es una advertencia sobre autoridad anticipada.

Si un miembro recibe hoy la clave de mañana, una baja posterior no recupera esa copia. Renovar únicamente la clave activa tampoco cierra el futuro. Hay que identificar todas las generaciones ya entregadas y, cuando corresponda, obligar a reemitir todas las claves pendientes mediante glRekeyAllGLKeys.

La dependencia puede prolongarse aún más. Una KEK puede envolver otra, y ésta una tercera. RFC 5275 exige considerar comprometidas todas las claves posteriores cuando alguna de la cadena se compromete. La revocación correcta sigue la descendencia criptográfica, aunque cada descendiente tenga otro identificador y otra fecha.

La procedencia requiere relación, no sólo firma

Los miembros que almacenan KEK deben registrar también el nombre del agente que las distribuyó. Así pueden comprobar que las renovaciones posteriores provienen de la misma entidad. La firma contesta quién firmó. La relación almacenada contesta si ese firmante es quien debe continuar esta historia de claves.

Los controles de repetición presentan una exigencia parecida. El nonce y signingTime sólo sirven si cada parte retiene información suficiente de intercambios anteriores. Sin memoria, no hay comparación. Además, los relojes derivan y un mensaje fechado en el futuro debe recibir tratamiento explícito. La frescura no nace del formato temporal, sino de una verificación con estado.

El cambio de generación no reescribe el pasado

Al activar una clave nueva, el grupo puede impedir que la antigua proteja tráfico futuro. No puede borrar el correo cifrado ya archivado, la copia en un repositorio, una copia de seguridad o el secreto exportado por el antiguo miembro. Tampoco puede demostrar de manera universal que toda copia fue destruida.

La exposición residual debe formularse con honestidad: qué cifrados siguen al alcance de la parte saliente y qué claves conserva. Esta formulación permite separar dos objetivos. La contención prospectiva puede ser excelente aunque la confidencialidad histórica no pueda recuperarse. Confundirlas sólo genera promesas falsas.

Del acuse de recibo a la prueba de cierre

El estándar no define un registro de transparencia moderno ni una prueba remota de borrado. Sin embargo, sus estados permiten diseñar un recibo estrecho y útil. El recibo debe unir la instrucción firmada con la lista y el sujeto exactos; identificar la generación de membresía efectiva; enumerar las claves actuales, futuras y encadenadas; registrar cada entrega y cada error; fijar el momento de activación; constatar dónde dejó de usarse la clave anterior; y mantener abiertas las incógnitas.

El valor está precisamente en no convertir una fase en otra. “Aceptado” no significa “distribuido”. “Distribuido” no significa “activado”. “Activado” no significa “borrado”. Cada verbo tiene un responsable, una evidencia y una excepción.

Esta es la diferencia entre el plano simbólico y el plano de ejecución. La lista declara una pertenencia. El código que cifra, entrega y descifra materializa una capacidad. Una institución puede cambiar la declaración al instante; sólo una cadena completa de transiciones puede cambiar la capacidad.