Migrar la firma de código a ML-DSA: un plan práctico

La firma de código sigue un calendario distinto al de TLS. El tráfico grabado solo está protegido por el intercambio de claves, y por eso allí se empieza por ML-KEM híbrido (Module-Lattice-Based Key-Encapsulation Mechanism). Una firma solo tiene que resistir la falsificación mientras su ancla de confianza esté vigente, pero el verificador que la comprueba puede permanecer en un gestor de arranque durante una década, y no se puede parchear un verificador con una actualización que ese mismo verificador no es capaz de verificar. Ese plazo de preparación, y no la urgencia de la amenaza, es la razón por la que los calendarios oficiales sitúan pronto la firma de software y firmware: la NSA, en CNSA 2.0 (Commercial National Security Algorithm Suite 2.0), exige el uso exclusivo de ML-DSA-87 o LMS/XMSS para la firma de software y firmware antes de finales de 2030 en los National Security Systems de EE. UU., tres años antes que para navegadores, servidores, servicios en la nube y sistemas operativos.

Por qué los plazos de firma llegan antes que los del intercambio de claves

El escenario «recolectar ahora, descifrar después» no se aplica a las firmas. Nadie puede grabar hoy una firma y falsificar más adelante una nueva a partir de ella. La exposición es otra: un atacante con capacidad cuántica que pueda recuperar una clave privada de firma a partir de su clave pública podría firmar firmware en el que su parque instalado sigue confiando. La mitigación consiste en introducir un verificador poscuántico en ese parque instalado mucho antes de que la clave pueda falsificarse, y los parques instalados evolucionan despacio.

Tres propiedades hacen de la firma el elemento más lento. Primero, los verificadores están en todas partes y a menudo son inmutables: etapas de arranque en ROM, elementos seguros, herramientas de aprovisionamiento aisladas de la red, equipos de clientes, instaladores sin conexión. Segundo, las anclas de confianza están integradas, de modo que cambiar un algoritmo implica distribuir nuevas claves públicas a través de un canal que a su vez está firmado. Tercero, la última actualización que un dispositivo acepta con el algoritmo antiguo es la que debe enseñarle el nuevo, por lo que un dispositivo retirado de su canal de actualizaciones antes de ese momento seguirá siendo clásico para siempre. Planifique esa decisión de fin de vida de forma explícita en lugar de descubrirla en 2030.

Nada de esto requiere predecir cuándo existirá un ordenador cuántico criptográficamente relevante. Las fechas siguientes proceden de políticas y guías publicadas, y son las que su hoja de ruta de ingeniería de versiones debe cumplir.

ML-DSA, SLH-DSA, LMS y XMSS: elegir según el caso de uso

El NIST publicó FIPS 204 (ML-DSA, Module-Lattice-Based Digital Signature Algorithm) y FIPS 205 (SLH-DSA, Stateless Hash-Based Digital Signature Algorithm) como estándares definitivos el 13 de agosto de 2024 (FIPS 204, FIPS 205). Los esquemas basados en hash con estado LMS y XMSS están aprobados en NIST SP 800-208. CNSA 2.0 designa ML-DSA-87 y LMS/XMSS para la firma de software y firmware, con SHA-384 o SHA-512 para el hash.

Para la mayoría de las cadenas de publicación, ML-DSA es la opción por defecto, porque no tiene estado y, por tanto, puede ejecutarse con seguridad en un sistema de CI distribuido con varios firmantes. Los esquemas con estado resultan atractivos para gestores de arranque con recursos limitados, pero la regla operativa no admite errores: el estado del firmante nunca debe duplicarse, lo que excluye las instantáneas ordinarias de máquinas virtuales, los clones en espera activa y la restauración desde copia de seguridad de un servidor de firma. Si no puede garantizarlo en su entorno, elija un esquema sin estado.

El tamaño importa de una forma que no importaba con ECDSA. Las claves públicas y las firmas poscuánticas son considerablemente más grandes, y las firmas SLH-DSA lo son aún más. Consulte las tablas de parámetros de FIPS 204 y FIPS 205 antes de dimensionar un campo de firma en una cabecera de firmware, una partición flash, un esquema de manifiesto o un presupuesto de actualización inalámbrica. Un campo de firma de ancho fijo en un formato de imagen existente es un obstáculo habitual, y se trata de un cambio de formato, no de un cambio criptográfico.

El verificador primero: el orden de actualización que no se puede alterar

La secuencia siguiente es el plan completo. Los pasos 2 y 3 deben completarse en todo el parque antes de que empiece el paso 5.

1. Inventaríe los verificadores, no solo los firmantes. Enumere todos los lugares donde se comprueba una firma: gestores de arranque, elementos seguros, gestores de paquetes, marcos de instalación, agentes de actualización, controladores de admisión, herramientas de aprovisionamiento, scripts de validación de socios. Registre cuáles puede actualizar, por qué canal y cuáles están congelados.
2. Añada la verificación poscuántica sin dejar de aceptar el algoritmo clásico. El nuevo verificador debe ser tolerante: aceptar las firmas antiguas, aceptar las nuevas y registrar cuál ha visto.
3. Distribuya ese verificador por la vía existente firmada de forma clásica y, a continuación, distribuya las nuevas anclas de confianza. Mida la cobertura con telemetría real, por dispositivo y por versión, no por suposición.
4. Registre las claves de firma en hardware y ejecute de extremo a extremo una cadena de firma paralela fuera de producción, incluidas la revocación y el sellado de tiempo.
5. Empiece la doble firma de los artefactos de producción cuando el verificador tolerante sea la amplia mayoría.
6. Exija firmas poscuánticas solo cuando la telemetría muestre que los verificadores antiguos han desaparecido, con una decisión por escrito para los rezagados: soporte ampliado, sustitución en campo o fin de vida documentado.
7. Elimine la firma clásica en último lugar y conserve la capacidad de volver a firmar los artefactos archivados para que las versiones antiguas sigan siendo verificables con el nuevo esquema.

Doble firma: los dos modos y la trampa

La doble firma consiste en adjuntar dos firmas independientes (una clásica y una poscuántica) al mismo artefacto, normalmente en un formato contenedor que admite varias ranuras de firma. Compruebe si el suyo lo admite antes de diseñar nada más: algunos formatos permiten varios firmantes de forma nativa, otros requieren una firma separada fuera de banda o una revisión del formato.

La decisión de diseño que importa es la política de verificación. En modo permisivo, un verificador acepta el artefacto si cualquiera de las dos firmas es válida, lo que mantiene operativos los clientes antiguos pero implica que su seguridad efectiva es la del más débil de los dos algoritmos. En modo estricto, el verificador exige ambas, lo que eleva la seguridad pero crea un riesgo de disponibilidad: un solo error en cualquiera de las dos cadenas bloquea todas las publicaciones. El camino habitual es el modo permisivo durante el despliegue, el estricto cuando el parque está preparado y, después, solo poscuántico. Documente la política por clase de verificador y por tipo de artefacto, y haga explícitas las fechas de transición; este es precisamente el tipo de cambio de algoritmo planificado que la agilidad criptográfica debería convertir en rutina.

Soporte en HSM, PKI y herramientas: qué verificar en lugar de suponer

El soporte de firmas poscuánticas avanza rápidamente en módulos de seguridad hardware, autoridades de certificación y herramientas de firma, y los requisitos de versión difieren entre productos e incluso entre ramas de firmware de un mismo producto. No tome una entrada de blog de un fabricante como un compromiso. Solicite las notas de la versión y el registro de validación, y realice pruebas en preproducción. Los puntos siguientes son las preguntas que conviene plantear por escrito:

• ¿Implementa el firmware del HSM ML-DSA, con qué conjuntos de parámetros, y existe una versión validada FIPS 140-3 o una hoja de ruta con fechas hacia ella? Si CNSA 2.0 le es aplicable, ML-DSA-87 es el conjunto de parámetros pertinente.
• ¿Es accesible a través de la interfaz que utiliza su cadena (mecanismo PKCS#11, tipos de objeto KMIP, API de KMS en la nube, SDK del fabricante), y pueden generarse las claves en hardware sin exportarse nunca?
• Para LMS o XMSS: ¿se realizan la generación de claves y el avance del estado dentro del módulo criptográfico, sin ningún mecanismo que pueda duplicar el estado, como exige SP 800-208?
• ¿Puede su autoridad de certificación emitir certificados con claves de sujeto poscuánticas y firmar datos de revocación que sus verificadores acepten? Las jerarquías pueden necesitar una cadena poscuántica paralela en lugar de un cambio in situ.
• ¿Admite su autoridad de sellado de tiempo el nuevo algoritmo, para que las firmas sigan siendo verificables tras la expiración del certificado?
• ¿Lo admiten sus herramientas de firma de artefactos y de transparencia, sus sistemas de compilación de paquetes y sus bibliotecas de verificación en las versiones exactas que despliega? OpenSSL, por ejemplo, requiere la versión 3.5 o posterior para los grupos TLS de ML-KEM; para el soporte de firmas, consulte las notas de la versión concreta que distribuye, tanto en el entorno de firma como en el de verificación.
• Rendimiento y latencia: las firmas más grandes y las nuevas rutas de código modifican el tiempo de firma por artefacto y el tamaño de descarga. Realice mediciones con su volumen real de publicaciones.

Las fechas de referencia para la planificación

Lo que sigue es información, no asesoramiento jurídico. El estado importa tanto como la fecha: un borrador no es un estándar, y una guía dirigida a los Estados miembros no es una obligación para las empresas.

Fuentes primarias: OMB M-26-15, la hoja de ruta de implementación coordinada de la UE, las preguntas frecuentes PQC de la ANSSI, los calendarios de migración del NCSC del Reino Unido y NIST IR 8547 ipd. Para CNSA 2.0, las fuentes publicadas son el CNSA 2.0 FAQ v2.1 (diciembre de 2024) y el aviso CNSA 2.0 Algorithms (30 de mayo de 2025).

Los fabricantes de productos también deben tener en cuenta que el Cyber Resilience Act (Reglamento de Ciberresiliencia), Regulation (EU) 2024/2847, Anexo I, Parte I (2)(e), exige proteger la confidencialidad mediante mecanismos de vanguardia y no menciona algoritmos poscuánticos; sus obligaciones de notificación se aplican desde el 11 de septiembre de 2026 y se aplica plenamente desde el 11 de diciembre de 2027 (EUR-Lex). Trate la actualización segura y la verificación de firmas como parte de ese argumento de estado de la técnica, y mantenga el inventario de claves de firma en el mismo registro que el resto de su criptografía.

Empiece por lo que puede medir hoy

La migración de la firma es un programa plurianual que afecta a todo el parque, así que empiece por las dos tareas económicas: una lista de todos los verificadores que posee con su canal de actualización, y una cadena de firma en preproducción que genere de extremo a extremo un artefacto con doble firma. En paralelo, confirme que el lado del transporte ya utiliza intercambio de claves híbrido, ya que es allí donde está en juego el tráfico grabado y donde la solución es un cambio de configuración y no un despliegue en todo el parque. Puede analizar su dominio con PQC Status para ver si sus servidores de publicación, actualización y artefactos negocian X25519MLKEM768, qué versiones de TLS y conjuntos de cifrado ofrecen y cómo es su cadena de certificados. El análisis describe únicamente la configuración TLS visible desde el exterior: no es una certificación y no inspecciona su cadena de firma de código, así que combínelo con el inventario de verificadores descrito anteriormente.