A medida que las organizaciones se preparan para emitir sus primeros certificados post-cuánticos, surge una pregunta práctica y sorprendente: ¿ los certificados PQC requieren un módulo de seguridad de hardware especial "a prueba de computación cuántica", o los HSM que ya están en producción los gestionarán sin problemas?
Es una pregunta pertinente, y la respuesta es más interesante que un simple sí o no. El término «HSM cuántico seguro» aparece con frecuencia en el marketing de los proveedores, las listas de verificación de compras y los debates sobre arquitectura, a menudo sin una definición clara de su significado. Algunas organizaciones asumen que sus HSM actuales quedan obsoletos en cuanto incorporan un certificado PQC. Otras asumen lo contrario: que un HSM es simplemente un dispositivo seguro y que los algoritmos del certificado no le conciernen en absoluto. Ambas suposiciones son erróneas, y esto nos enseña algunas lecciones.
Este blog explica en detalle qué hace realmente un HSM, qué significa "seguro frente a la computación cuántica" cuando se aplica a uno, por qué es importante esta distinción para proteger los certificados PQC y qué se debe verificar antes de dar por sentado que el hardware está listo.
¿Qué protege realmente un HSM?
Para generar, almacenar y utilizar las claves privadas de los certificados PQC con las mismas garantías de seguridad que se esperan para las claves clásicas, se necesita un HSM que admita de forma nativa los algoritmos post-cuánticos implicados, principalmente ML-DSA (FIPS 204) para firmas y ML-KEM (FIPS 203) para el establecimiento de claves. Un HSM que no admita estos algoritmos no puede realizar operaciones con claves PQC dentro de su entorno seguro, lo que anula por completo el propósito de utilizar un HSM.
Pero la expresión «HSM a prueba de ataques cuánticos» implica muchas funciones implícitas, y ahí radica la confusión. Un HSM no se vuelve «a prueba de ataques cuánticos» de la misma manera que un algoritmo se vuelve resistente a la computación cuántica. El hardware en sí no es vulnerable a los ataques cuánticos. Lo que importa es si el firmware y la biblioteca criptográfica del HSM pueden realizar operaciones de algoritmos post-cuánticos de forma nativa, dentro del hardware, de modo que la clave privada nunca salga del hardware protegido.
Al firmar un certificado o un programa con un HSM, el proceso funciona de la siguiente manera: los datos que se van a firmar, o más comúnmente su hash, se envían al HSM. El HSM realiza la firma internamente utilizando la clave privada que contiene y devuelve únicamente la firma. La clave privada nunca sale del hardware. Esta es la principal ventaja de un HSM. Significa que, incluso si todos los demás sistemas de su entorno se ven comprometidos, la clave privada permanece protegida.
El cambio de FIPS 140-3
FIPS 140 es el estándar del gobierno estadounidense para la validación de módulos criptográficos, incluidos los HSM. La validación confirma que un módulo implementa correctamente los algoritmos aprobados y cumple con los requisitos de seguridad física y lógica definidos. Durante décadas, FIPS 140-2 fue la versión relevante. Se introdujo hace aproximadamente 25 años y se dejó de utilizar oficialmente para nuevas validaciones en 2021. Desde entonces, todas las validaciones se han realizado conforme a FIPS 140-3.
Esta sincronización genera una consecuencia directa e importante para la criptografía postcuántica: todas las validaciones FIPS de PQC son validaciones FIPS 140-3, no FIPS 140-2. Los algoritmos postcuánticos fueron estandarizados por el NIST en agosto de 2024, mucho después de que FIPS 140-2 dejara de aceptar nuevas validaciones. El CMVP actualizó sus estándares y herramientas para que ML-KEM, ML-DSA y SLH-DSA puedan incluirse en nuevas presentaciones FIPS 140-3. No existe una vía para que un algoritmo PQC reciba una validación FIPS 140-2, ya que ese programa ya no acepta nuevas presentaciones.
Además, existe una fecha límite que acentúa la urgencia: el NIST reclasificará todos los certificados FIPS 140-2 como históricos en septiembre de 2026. Es posible que los módulos incluidos en la lista histórica ya no sean adecuados para nuevas adquisiciones en muchos contextos federales y regulados.
La conclusión práctica es que una organización que se tome en serio la emisión de certificados PQC debería buscar específicamente HSM con validación FIPS 140-3 que incluya los algoritmos PQC pertinentes, o con una hoja de ruta clara y definida para dicha validación. Varios proveedores ya han alcanzado hitos en este sentido. A finales de 2025 y durante 2026, proveedores como Crypto4A, Entrust, Idemia, Kryptus, Marvell, Securosys y Utimaco obtuvieron la certificación de algoritmo CAVP para ML-KEM, ML-DSA y SLH-DSA, y HSM como Entrust nShield 5, Marvell LiquidSecurity 2 y Thales Luna G7 y K7 han estado avanzando en la validación FIPS 140-3 con soporte para PQC.
Desafíos técnicos de las claves PQC en hardware
Implementar la compatibilidad con PQC en los HSM no es una simple actualización de firmware, y comprender los desafíos técnicos que esto implica explica por qué el soporte del proveedor se ha implementado gradualmente en lugar de hacerlo de una sola vez.
Los tamaños de clave y firma más grandes ponen a prueba las limitaciones del hardware.
Las claves PQC son considerablemente más grandes que sus equivalentes clásicas. Una clave privada ML-DSA puede variar entre 1.6 KB y 4 KB, según el conjunto de parámetros, en comparación con los cientos de bytes de ECDSA . Los HSM operan con presupuestos fijos de memoria y almacenamiento, y algunos módulos con recursos limitados tienen dificultades para manejar el material de clave PQC, que es más grande. Esta es una limitación de hardware, no un fallo, pero ilustra por qué no todos los modelos de HSM manejan PQC con la misma eficacia.
La generación de claves basada en semillas introduce una disyuntiva.
ML-DSA y SLH-DSA permiten generar claves a partir de una semilla compacta, a veces de tan solo 32 a 64 bytes, en lugar de almacenar la clave privada expandida completa. Esto mitiga el problema de almacenamiento al mantener solo la semilla pequeña en el HSM. La desventaja es computacional: la clave privada completa debe derivarse de la semilla bajo demanda cada vez que se necesite, lo que aumenta la sobrecarga de procesamiento de cada operación. El IETF ha estado analizando las implicaciones de este formato de clave dual, donde una clave puede representarse como una semilla compacta o como una clave expandida más grande, ya que complica el manejo de archivos PKCS#12, la integración con HSM y la interoperabilidad entre sistemas que esperan formatos diferentes.
La sobrecarga de rendimiento es real.
Los algoritmos post-cuánticos requieren más recursos computacionales que sus equivalentes clásicos. La generación de claves ML-KEM utiliza aproximadamente tres veces más ciclos que ECDH, y la firma ML-DSA requiere aproximadamente cinco veces más ciclos que ECDSA en hardware equivalente. Los HSM con presupuestos computacionales fijos pueden experimentar una reducción en el rendimiento tras la migración a PQC. Para operaciones de firma o establecimiento de claves de alto volumen, este impacto en el rendimiento debe evaluarse y planificarse, en lugar de ignorarse.
Las cargas útiles de gran tamaño alcanzan los límites de la red.
Al firmar objetos de gran tamaño, como listas de revocación de certificados extensas, la cantidad de datos que se pueden enviar a un HSM a través de la red suele ser limitada. Por ello, el hash del lado del cliente, que consiste en enviar solo el hash de los datos al HSM en lugar de la carga útil completa, es el método recomendado para la firma PQC. Esto mantiene la cantidad de datos que cruzan el límite del HSM reducida, independientemente del tamaño del artefacto que se firma.
La estandarización aún se está consolidando.
PKCS#11 , la interfaz estándar para operaciones de HSM, aún está en desarrollo. LMS y HSS se estandarizaron en la versión 3.1 de PKCS#11, mientras que ML-DSA, SLH-DSA y ML-KEM se están estandarizando en la versión 3.2. Varios HSM basados en REST ya admiten estos algoritmos antes de la estandarización completa de PKCS#11, pero en la práctica, la compatibilidad con PQC varía significativamente entre proveedores e incluso entre versiones de firmware del mismo producto.
Mejores prácticas para la protección de claves de PQC
Estas son las prácticas que distinguen sistemáticamente a las implementaciones de certificados PQC bien diseñadas.
Mantenga las claves privadas de PQC en hardware, junto con las claves clásicas.
El principio fundamental es la coherencia. El estándar de protección de hardware que se aplica a las claves de certificados clásicas debe aplicarse igualmente a las claves PQC. Esto requiere módulos de seguridad de hardware (HSM) compatibles con PQC, no porque el hardware fuera vulnerable, sino porque la protección de hardware requiere compatibilidad con algoritmos nativos del hardware.
Estandarizar el uso de hardware validado según FIPS 140-3.
Dado que la norma FIPS 140-2 ha pasado a tener estatus histórico y todas las validaciones de PQC cumplen con la norma FIPS 140-3, alinear la adquisición de HSM con la norma FIPS 140-3, con el soporte del algoritmo PQC, posiciona correctamente a la organización tanto para las operaciones actuales como para las expectativas regulatorias.
Utilice el hash del lado del cliente para las operaciones de firma.
El envío de hashes únicamente al HSM, en lugar de cargas útiles completas, mantiene la cantidad de datos que cruzan el límite reducida, lo cual es más importante con PQC dadas las firmas más grandes y las limitaciones de la red en la comunicación con el HSM.
Adopte certificados híbridos durante la transición.
La vía de transición recomendada es la híbrida. Asegúrese de que el HSM proteja tanto la parte clásica como la post-cuántica, de modo que el enfoque híbrido no introduzca una clave almacenada en el software.
Realizar pruebas a escala de producción antes de comprometerse.
Dado que la compatibilidad con PQC varía según el proveedor y la versión del firmware, y que el tamaño de las claves y las características de rendimiento difieren significativamente de los algoritmos clásicos, es fundamental realizar pruebas tempranas a escala de producción. Valide que operaciones como la firma de listas de revocación de certificados (CRL) de gran tamaño funcionen dentro de las limitaciones de su módulo de seguridad de hardware (HSM) antes de depender de ellas.
Diseñado para la criptoagilidad
Diseñe la infraestructura de certificados y firmas de forma que los algoritmos puedan cambiar sin necesidad de reconstruir todo el sistema. La transición a PQC no será el último cambio criptográfico que deberá gestionar, y una infraestructura diseñada para la agilidad permite absorber futuros cambios a un coste mucho menor.
Cómo puede ayudar la consultoría de cifrado
La cuestión de si los certificados PQC requieren módulos de seguridad de hardware (HSM) compatibles con la computación cuántica se sitúa en la intersección de la arquitectura criptográfica, la adquisición de hardware y la gobernanza de la infraestructura de clave pública (PKI), que es precisamente donde operan la cartera de productos y los servicios de asesoramiento de Encryption Consulting.
Con nuestra plataforma CodeSign Secure , basada en el principio que hemos comentado (que las claves privadas PQC merecen la misma protección de hardware que las claves clásicas), puede realizar operaciones de firma ML-DSA y SLH-DSA dentro de HSM validados por FIPS de Thales, Entrust, Utimaco y Securosys, sin que la clave privada salga del perímetro del hardware. Admite LMS para la firma de firmware y utiliza el hash del lado del cliente para que solo los hashes, y no los artefactos completos, atraviesen el perímetro del HSM. Para las organizaciones que emiten o utilizan certificados PQC para la firma de código y firmware, CodeSign Secure proporciona la cadena de confianza alineada con el hardware, desde la generación de claves hasta la firma.
CertSecure Manager es otra plataforma que le ayuda a gestionar el ciclo de vida de los certificados durante la transición a PQC, incluyendo la emisión y gestión de certificados post-cuánticos. Su criptoagilidad permite ejecutar algoritmos clásicos y post-cuánticos en paralelo durante la fase de implementación híbrida, y su gobernanza centralizada garantiza que los certificados PQC se controlen, renueven y gestionen con el mismo rigor que los clásicos.
Nuestros servicios de asesoramiento criptográfico post-cuántico ayudan a las organizaciones a responder exactamente al tipo de preguntas sobre arquitectura y adquisición que hemos tratado en este blog: qué HSM de su entorno son compatibles con PQC, cuáles necesitan actualizaciones de firmware o reemplazo, cómo estructurar una implementación de certificados híbridos y cómo alinear su hoja de ruta de hardware con la transición a FIPS 140-3 y la fecha límite de septiembre de 2026 para el estado histórico de FIPS 140-2.
Conclusión
Entonces, ¿los certificados PQC requieren HSM con protección cuántica? La respuesta más precisa es la siguiente: los certificados PQC requieren HSM que admitan de forma nativa algoritmos post-cuánticos, si se desea que las claves privadas asociadas a dichos certificados cuenten con protección de hardware. La denominación "HSM con protección cuántica" se refiere a un HSM cuyo firmware puede realizar ML-DSA, ML-KEM y operaciones relacionadas dentro de su entorno seguro.
El hardware del HSM nunca fue vulnerable a la computación cuántica. Lo que cambió es que proteger la clave privada de un certificado resistente a la computación cuántica en el hardware requiere que este comprenda el algoritmo de dicha clave. Un HSM que no puede realizar operaciones ML-DSA no puede proteger una clave ML-DSA, y un certificado resistente a la computación cuántica cuya clave privada se encuentra desprotegida en el software presenta un punto débil que anula por completo el propósito de la migración.
En Encryption Consulting, nuestros productos y servicios de asesoramiento están diseñados para ayudarle a tomar estas decisiones correctamente, desde el descubrimiento de su inventario criptográfico hasta la emisión de certificados PQC respaldados por claves protegidas por hardware.
