Si firma software o firmware, transición post-cuántica Te llega antes que a casi nadie y te obliga a tomar una decisión que el resto de la conversación sobre computación cuántica física suele pasar por alto. La mayor parte de la atención se centra en TLS y los certificados, que se pueden volver a emitir en cuestión de horas cuando es necesario realizar algún cambio. La firma de firmware es el caso opuesto. La firma en una imagen de firmware debe permanecer verificable durante diez o quince años, en dispositivos que quizás nunca vuelvas a tocar físicamente, frente a un atacante que podría tener ya una computadora cuántica para cuando esos dispositivos queden obsoletos.
Si esa firma se basa en RSA o ECDSA, una computadora cuántica puede falsificarlo, y el firmware falsificado es el firmware en el que el dispositivo confiará y ejecutará. Cuando la raíz de confianza se graba en el hardware, generalmente no hay un parche que lo corrija posteriormente. Esto hace que los dispositivos que se lancen este año sean los más vulnerables y los más difíciles de reparar una vez que estén en funcionamiento. Esta es la parte de la migración post-cuántica que no puede esperar, y es la razón por la que la firma del firmware tiene la fecha límite más temprana en toda la transición.
La presión es real, pero las respuestas no están en duda. Los algoritmos de firma cuántica segura para este trabajo, SLH-DSALMS y XMSS se basan en funciones hash, están estandarizados y se fundamentan en criptografía estudiada durante décadas. Por lo tanto, la pregunta que se plantean los equipos de firma en 2026 no es si existe una solución, sino cuál utilizar, y la verdad es que esta decisión es más compleja de lo que parece. Este artículo analiza las diferencias entre estos algoritmos, la disyuntiva entre sistemas con y sin estado que constituye el eje central de la elección, y la normativa que suele ser determinante para tomar la decisión.
¿Por qué firmas basadas en hash y por qué ahora?
La firma de código y firmware tiene una propiedad que la mayoría criptografía No: la firma tiene que sobrevivir a casi todo lo que la rodea. Firmas una imagen de firmware una sola vez, y eso firma Es posible que se requiera una verificación correcta durante toda la vida útil del hardware, mucho después de que la infraestructura de firma haya cambiado. Si el algoritmo subyacente falla durante ese período, un atacante puede falsificar una firma e instalar firmware malicioso que los dispositivos aceptarán sin reservas. En el caso de una raíz de confianza integrada en el hardware, puede que no haya forma de corregirla en el campo.
Ese largo horizonte es precisamente la razón por la que la resistencia cuántica ocupa el primer lugar en importancia. También es la razón por la que las firmas basadas en hash son la herramienta elegida. A diferencia de RSA y ECDSAMientras que las firmas basadas en funciones hash se basan en problemas de teoría de números que una computadora cuántica puede resolver, las firmas basadas en hash se basan únicamente en la seguridad de una función hash como SHA-256. Las funciones hash no se ven amenazadas de manera significativa por las computadoras cuánticas, más allá de una reducción manejable en su robustez que las salidas más grandes absorben. Son antiguas, se comprenden bien y estaban listas mucho antes de que los esquemas basados en retículos maduraran. Para algo que debe mantenerse seguro durante quince años, ese historial es muy valioso.
SLH-DSA, LMS y XMSS se basan en funciones hash y comparten la misma estructura subyacente: múltiples firmas de un solo uso combinadas en una única clave pública mediante un árbol Merkle. La decisión se basa en las diferencias entre ellas.
La verdadera división: con estado o sin estado.
La diferencia más importante no es el rendimiento ni el tamaño de la firma. Es el estado.
LMS XMSS y otros sistemas de seguridad con estado. Cada clave privada solo puede generar un número fijo de firmas, y el firmante debe llevar un registro exacto de cuáles se han utilizado. Este registro es fundamental. Si el estado se gestiona incorrectamente, si un componente de un solo uso se utiliza dos veces porque una clave se restauró a partir de una copia de seguridad, se copió a un segundo servidor o se ejecutó en paralelo, un atacante que vea ambas firmas puede falsificar otras nuevas. La seguridad de estos sistemas depende por completo de no reutilizar nunca un componente de un solo uso. Si el estado se gestiona mal, la seguridad se pierde silenciosamente.
SLH-DSA no tiene estado. Fue diseñado específicamente para eliminar este riesgo. En lugar de rastrear las firmas usadas, realiza selecciones aleatorias y se basa en la probabilidad de que la colisión sea insignificante. No hay estado que corromper, ni contador que perder, ni riesgo derivado de una copia de seguridad restaurada. Esta decisión de diseño tiene importantes consecuencias operativas, que es el siguiente aspecto a considerar.
Lo que se sacrifica y lo que se gana en cada sentido.
Las firmas con estado (LMS y XMSS) son eficientes y compactas en comparación con las firmas sin estado, y cuentan con una larga trayectoria en la firma de firmware. El inconveniente radica en la disciplina operativa. Dado que el firmante debe mantener el estado de forma impecable, la firma está vinculada a una única instancia controlada de la clave. No es posible ejecutar la firma en paralelo en varias máquinas, ya que esto implicaría la reutilización del estado.
En un proceso de firma de firmware donde el volumen de firmas es conocido y limitado, esta restricción suele ser aceptable, y es por eso que estos esquemas se adaptan tan bien al caso del firmware. Sin embargo, se recomienda encarecidamente mantener la clave y la gestión de su estado dentro del hardware, un HSM, para evitar que el estado se duplique o revierta accidentalmente.
Entre las dos opciones con estado, LMS es la más sencilla y rápida por defecto. Utiliza menos ciclos de reloj para la generación, firma y verificación de claves, y consume menos memoria. XMSS añade una construcción de máscara de bits que algunos equipos prefieren por sus mayores garantías de seguridad, aunque a costa de un mayor número de operaciones de hash y un mayor consumo de memoria. Para la mayoría de las operaciones de firma, la diferencia práctica es mínima, y LMS es el punto de partida razonable a menos que se necesiten específicamente las funcionalidades de XMSS.
Las firmas sin estado (SLH-DSA) sacrifican tamaño a cambio de seguridad. SLH-DSA Las firmas son más grandes, lo que puede ser importante para dispositivos con ancho de banda limitado o mecanismos de actualización con almacenamiento restringido, y la firma requiere mayor capacidad de cálculo. A cambio, se obtiene una total independencia del estado. Dado que no hay nada que corromper, SLH-DSA se puede paralelizar y ejecutar en un sistema de firma distribuido sin el riesgo de reutilización que limita a LMS y XMSS. Para una operación de firma distribuida o de alto volumen, donde la coordinación del estado entre máquinas sería frágil, esta independencia compensa el mayor tamaño de las firmas.
El factor decisivo: CNSA 2.0
Aquí es donde se rompe la clara comparación a tres bandas, y es el detalle que la mayoría de los resúmenes ocultan. Si su firma afecta a los Sistemas de Seguridad Nacional, o si sus clientes les venden, la NSA CNSA 2.0 La suite rige su elección, y CNSA 2.0 no aprueba SLH-DSA.
Para la firma de software y firmware, CNSA 2.0 aprueba los esquemas con estado, LMS y XMSS, derivados de NIST SP 800-208, con LMS utilizando SHA-256/192 como conjunto de parámetros preferido. SLH-DSA es un esquema final estándar NIST Conforme a FIPS 205, es perfectamente legítimo para la firma comercial, pero no forma parte de CNSA 2.0 ni está aprobado para NSS. ML-DSA, el estándar de firma sin estado basado en retículos, también está aprobado por CNSA 2.0 y es la opción más sensata cuando el volumen de firmas supera la capacidad de una única clave con estado, o cuando se necesita una firma distribuida.
Así pues, la decisión se divide claramente en una sola línea. Si su empresa está sujeta a la normativa CNSA 2.0, su opción sin estado es, en la práctica, ML-DSA, no SLH-DSA, y probablemente se basará en LMS o XMSS con gestión de estado respaldada por hardware. Si firma para el sector comercial, dispone de todas las opciones, y la disyuntiva entre sistemas con y sin estado mencionada anteriormente es una decisión de ingeniería genuina, más que una restricción de cumplimiento.
La presión del tiempo es real en ambos casos. La firma de firmware tiene el plazo más temprano en toda la transición poscuántica, porque las raíces de confianza del firmware son las más difíciles de cambiar una vez implementadas. Bajo CNSA 2.0, se esperaba que se comenzaran a adoptar estas firmas ya, y la adquisición de la firma de software y firmware se produjo mucho antes del cambio general de 2035. Independientemente de si CNSA 2.0 es vinculante o no, la lógica subyacente se mantiene: cuanto más tiempo deban permanecer válidas sus firmas, menos tiempo tendrá para realizar el cambio.
Cómo puede ayudar Encryption Consulting
Elegir entre la firma con estado y la firma sin estado, y luego operarla de forma segura, es una combinación de estrategia y detalles de implementación complejos. Ese es nuestro trabajo.
CodeSign seguroNuestra solución de firma de código está diseñada para proteger las claves de firma y garantizar flujos de trabajo de firma controlados, justo lo que exigen los sistemas de seguridad cuántica. Ofrece un proceso de firma controlado para software, firmware y otros artefactos, con los controles de políticas y la protección de claves más importantes al migrar a LMS, XMSS o un algoritmo sin estado. En los sistemas con estado, donde un solo fallo de estado puede anular todo el modelo de seguridad, la firma mediante un sistema centralizado y disciplinado, en lugar de scripts improvisados, impide que una clave de un solo uso se reutilice.
Debido a que los esquemas con estado requieren efectivamente una gestión de claves y estado respaldada por hardware, HSM como servicio es la base natural que los sustenta. Mantiene las claves de firma aisladas en un módulo de seguridad de hardware, de modo que el estado del que dependen LMS y XMSS no se puede copiar, restaurar desde una copia de seguridad ni ejecutar en paralelo, modos de fallo que convierten una firma con estado en una falsificable.
Decidir qué algoritmo se adapta mejor a sus dispositivos, su volumen de firmas y sus obligaciones de cumplimiento es donde entra en juego nuestra Servicios de asesoramiento criptográfico postcuántico Adelante. Le ayudamos a sopesar las ventajas y desventajas de las soluciones con y sin estado, teniendo en cuenta sus limitaciones reales, considerando la normativa CNSA 2.0 si le corresponde, y elaborando un plan de migración para su infraestructura de firma que se ajuste al cronograma con el que cuenta.
Si está diseñando una firma segura cuántica para sus productos o tratando de decidir entre LMS, XMSS y un esquema sin estado antes de comprometerse, Póngase en contacto Podemos ayudarte a tomar la decisión y a establecer la infraestructura necesaria para respaldarla.
Conclusión
La transición a la firma de código y firmware resistente a la computación cuántica es uno de los pocos aspectos de la transición a la computación cuántica física (PQC) donde los algoritmos están definidos y la fecha límite está cerca. SLH-DSA, LMS y XMSS son algoritmos sólidos, basados en funciones hash y resistentes a la computación cuántica. La elección entre ellos depende de si se puede gestionar el estado de forma segura y si existen factores que impulsen la adopción de un diseño sin estado.
Para la mayoría de los equipos, los factores decisivos son el cumplimiento normativo y las operaciones. Si se aplica CNSA 2.0, ML-DSA es la solución sin estado por excelencia, y las opciones basadas en hash son LMS y XMSS con estado respaldado por hardware. Si no se aplica, SLH-DSA es una forma legítima de evitar por completo la gestión del estado, aunque a costa de firmas más grandes. Ambas opciones funcionan, pero solo si las claves de firma están protegidas y el proceso es lo suficientemente riguroso como para que una clave de un solo uso nunca se utilice dos veces.
El firmware que firmes este año podría seguir funcionando y necesitar verificación mucho después de la llegada de las computadoras cuánticas. Por eso, esta decisión no puede esperar y vale la pena acertar a la primera.
