Resumen

  • RFC 9708 define cómo representar claves y firmas HSS/LMS en X.509, PKIX y CMS. LM-OTS permite una sola firma por clave privada, de modo que el firmante debe recordar de forma duradera qué hojas ya consumió.
  • Verificar una firma concreta no demuestra que la historia del firmante siga siendo única. Una escritura fallida, la restauración de una máquina virtual o un clon pueden reutilizar una hoja que el exterior ya vio.
  • La defensa depende del orden: comprometer el siguiente estado antes de entregar la firma, limitar la autoridad a un escritor efectivo y reconciliar cada salida con una reserva que nunca pueda volver al inventario.

Un sistema de copias de seguridad puede declarar victoria exactamente en el momento en que la criptografía pierde su promesa. La máquina vuelve a arrancar, el servicio responde y las firmas nuevas se verifican. En apariencia, la recuperación fue impecable. Sin embargo, la copia restaurada contiene un contador anterior al de algunas firmas que ya circularon. El mismo secreto de un solo uso puede gastarse por segunda vez.

RFC 9708 coloca esa posibilidad en el centro de la operación, aunque su labor formal sea describir el uso del Hierarchical Signature System y Leighton–Micali Signature en certificados y en Cryptographic Message Syntax. Publicado como estándar propuesto en enero de 2025, sustituye a RFC 8708, ajusta codificaciones, resuelve erratas conocidas y añade conjuntos de parámetros. Nada de ello convierte HSS/LMS en un algoritmo sin estado.

La base está en RFC 8554. La clave privada conserva el índice de la próxima clave LM-OTS. Firmar entrega dos resultados conceptuales: la firma y el estado privado sucesor. El árbol ofrece un número fijo de operaciones; agotarlo significa que ya no existe un estado siguiente. Si se emplea dos veces el mismo estado secreto, el documento deja de ofrecer garantías criptográficas y una falsificación puede resultar viable.

Por eso el activo no es solamente material secreto. También es una contabilidad exacta e irreversible de las posiciones ya gastadas.

La verificación mira un objeto; la unicidad mira toda la historia

LM-OTS es una construcción de una sola firma. LMS agrupa muchas claves de ese tipo bajo una raíz de Merkle, y HSS puede organizar árboles en niveles. El resultado permite un volumen práctico de firmas con una clave pública estable, aunque ese volumen sea finito. Cada firma identifica su posición y un verificador puede comprobar el camino y la relación matemática con la raíz.

Lo que no puede deducir de una sola muestra es si otra instancia firmó con la misma posición. El duplicado puede vivir en otro centro de datos, en una imagen congelada o en una respuesta que el primer servicio entregó antes de fallar. Conviene separar la escalera de recibos:

Recibo Alcance real
clave pública aceptada una política admite esa identidad criptográfica
identificador reconocido el formato y los parámetros son interpretables
firma válida el objeto supera el algoritmo de verificación
índice leído se observa una hoja determinada
hoja reservada un escritor asignó esa posición
avance persistido el almacenamiento durable ya no la ofrece
firma exportada el resultado salió del límite de seguridad
conciliación completa ninguna otra salida comparte la posición
efecto observado un consumidor actuó sobre el contenido

Una fila no sustituye a las demás. RFC 9708 exige que la implementación lleve cuenta de las hojas usadas y advierte que perder la integridad de ese seguimiento puede provocar la reutilización de una clave de un solo uso. Cita expresamente escrituras persistentes fallidas, instantáneas de máquinas virtuales y clonación. Son tareas normales de infraestructura capaces de romper una propiedad criptográfica excepcional.

La persistencia debe ganar la carrera a la respuesta

Imaginemos que el firmante calcula el resultado, responde al cliente y después guarda el contador incrementado. Un corte entre la respuesta y la escritura permite que el reinicio seleccione la misma hoja. Incluso una llamada de escritura aparentemente correcta puede quedarse en una caché volátil y desaparecer con el fallo. El mundo conserva la firma; la máquina pierde el recuerdo de haberla creado.

La guía NIST SP 800-208 trata la gestión del estado como la dificultad principal de estas firmas. En el perfil que define, el módulo debe incrementar el identificador de hoja y persistirlo en memoria no volátil antes de exportar la firma o aceptar la solicitud siguiente. La transacción segura reserva una posición, marca su consumo de forma durable, genera o finaliza el resultado y solo entonces lo libera.

Si el proceso cae después de persistir y antes de exportar, quizá se pierda una hoja sin firma pública. Esa pérdida reduce capacidad, pero conserva la seguridad. El caso contrario ahorra capacidad y arriesga reutilización. Ante un resultado incierto, quemar la posición es más seguro que devolverla al conjunto libre.

Esta lógica deshace varias intuiciones de la nube. Reintentar no es necesariamente idempotente. Restaurar no es necesariamente retroceder a un punto seguro. Clonar una instancia no es añadir un trabajador equivalente. La continuidad correcta es monotónica: el conocimiento de lo ya gastado solo puede avanzar.

Disponibilidad y exclusividad pueden entrar en conflicto

La réplica activa parece una defensa contra fallos, pero dos firmantes con el mismo estado son dos autoridades capaces de asignar la misma hoja. Una base compartida no basta si cualquiera puede publicar una firma antes de que el bloqueo y el incremento sean durables. Tampoco basta que las claves estén en hardware si el estado se copió a varios módulos sin dividir los subárboles.

El diseño puede serializar todo en un único módulo, asignar subárboles sin solapamiento, usar un contador monotónico que delate el retroceso o cercar al escritor viejo antes de habilitar el relevo. Lo importante es formular la propiedad exacta. Un módulo resistente no prueba por sí mismo que no haya otro. Una arquitectura de alta disponibilidad no prueba que la autoridad de escritura siga siendo singular.

El perfil del NIST limita parámetros y exige que la generación de claves y firmas ocurra dentro de módulos criptográficos físicos sin exportar la clave secreta. Es una disciplina fuerte para los sistemas que afirman conformidad con ese perfil. No debe atribuirse automáticamente a toda implementación que reconozca RFC 9708. La norma prueba que existe una especificación; la evidencia de ejecución debe demostrar el comportamiento del sistema concreto.

El contenedor protege bytes, no el pasado del firmante

RFC 9708 define el identificador de objeto y establece que los parámetros de AlgorithmIdentifier estén ausentes. La clave pública HSS/LMS viaja sin una envoltura ASN.1 adicional. En X.509, las extensiones de uso de clave deben corresponder a firma, no a cifrado o acuerdo de claves. Esa convención encaja con la infraestructura de RFC 5280 y las definiciones ASN.1 de RFC 5912.

En CMS, especificado por RFC 5652, el objeto firmado cambia según haya atributos firmados. Sin ellos, se firma el contenido. Con ellos, se calcula el resumen del contenido y se firma la codificación DER de SignedAttributes, donde aparecen el tipo de contenido y el resumen del mensaje. Contenedores como los empleados para firmware en RFC 4108 pueden incorporar así HSS/LMS sin inventar otra envoltura.

El certificado vincula una clave pública y un sujeto bajo una política. No enumera las copias antiguas de la clave privada. CMS permite verificar exactamente qué octetos quedaron protegidos. No permite observar una escritura que se perdió dentro del dispositivo firmante. Cuanto mayor sea el número de consumidores, más importantes son los recibos internos que el formato público no transporta.

El número de hojas es una decisión institucional

Una organización necesita pronosticar tasa de firmas, tamaño y niveles de árbol, vida útil, reserva operativa y tiempo de migración. El agotamiento no es un error que deba envolverse a cero. Restaurar un índice bajo tampoco amplía el presupuesto; hace que el registro mienta. Un aumento súbito puede ser abuso, una publicación legítima o un sensor defectuoso, pero obliga a revisar la capacidad restante.

El registro LMS de IANA enumera los códigos normalizados. La ficha del RFC Editor, las ediciones de texto y XML, el historial del IETF y las erratas documentan la norma y su evolución. Ninguna de esas fuentes demuestra cuántas hojas conserva una instalación ni cómo se recupera tras una caída.

La prueba de código en funcionamiento de Heng Lu dirige la atención al paso ejecutable: ¿el servicio consumió estado antes de publicar el resultado? La especificación inicial mínima sostiene la interoperabilidad común sin decidir por cada operador su aislamiento o recuperación. Y la disciplina de las capas de realidad evita fundir tres hechos distintos: existe un estándar, una firma verifica y la historia del firmante es íntegra.

HSS/LMS cambia la naturaleza de la obligación. La confianza en ciertos problemas matemáticos cede parte del terreno a una responsabilidad concreta sobre almacenamiento, exclusividad y tiempo. La máquina debe conservar no solo el secreto que permite firmar, sino la prueba de que nunca volverá a ofrecer el mismo futuro.

Fuentes