PQC para la firma de código: protección de software y firmware de larga duración.

Respuesta rápida: La firma de código conlleva un riesgo a largo plazo que la mayoría de los planes de PQC subestiman: un instalador, una imagen de firmware o un paquete de actualización firmados permanecen en circulación durante años o décadas después de la firma, por lo que una firma clásica aplicada hoy queda expuesta durante toda la vida útil del artefacto, no solo hasta que llegue una computadora cuántica. Protegerse de este riesgo implica hacer bien cinco cosas: elegir el algoritmo adecuado, añadir una marca de tiempo a cada firma para que sobreviva a la expiración del certificado, confirmar que su HSM y la autoridad de marca de tiempo realmente admiten operaciones post-cuánticas, asegurarse de que el ecosistema de verificación que consume sus firmas pueda comprobarlas y ejecutar un programa piloto de firma en paralelo antes de cualquier transición a producción. Esta guía cubre los cinco.

Nuestra guía de arquitectura de firma de código PQC abarca en profundidad la selección de algoritmos y la planificación de la migración por fases. Esta guía se centra en lo que sucede después de elegir un algoritmo: mantener la verificabilidad de la firma mientras el artefacto que protege permanezca en uso, durante la expiración del certificado, las brechas de compatibilidad con TSA y HSM, y una eventual transición de algoritmo.

Puntos Clave

• El software y el firmware firmados permanecen en circulación durante años o décadas, por lo que el período de riesgo para una firma clásica abarca toda la vida útil del artefacto, no solo el tiempo que transcurre hasta que exista una computadora cuántica.
• Una marca de tiempo RFC 3161 demuestra que una firma se creó en un momento específico, lo que permite que la verificación siga siendo exitosa incluso después de que el certificado de firma haya expirado.
• La mayoría de las autoridades públicas de sellado de tiempo aún no han implementado la compatibilidad con la firma post-cuántica, y la mayoría de los HSM FIPS 140-2 heredados carecen de compatibilidad con algoritmos PQC nativos; dos deficiencias de preparación distintas que deben verificarse antes de que un proyecto piloto se considere totalmente post-cuántico.
• El firmware con ciclos de vida de implementación de más de una década se enfrenta a un problema particular: no se puede volver a firmar después de la implementación, por lo que la firma aplicada en el momento de la compilación debe seguir siendo verificable durante toda la vida útil del dispositivo.
• Un programa piloto de firma paralela, que aplica una firma clásica y una post-cuántica al mismo artefacto, permite a una organización validar las herramientas post-cuánticas sin interrumpir la verificación de los sistemas que aún no son compatibles con la tecnología post-cuántica.

El riesgo de firma de larga duración

La mayoría de los debates sobre riesgos cuánticos se centran en la estrategia de "capturar ahora, descifrar después", donde un atacante captura el tráfico cifrado hoy para descifrarlo una vez que exista una computadora cuántica. La firma de código conlleva un riesgo similar, pero distinto: un atacante que pueda falsificar firmas clásicas, una vez que exista una computadora cuántica criptográficamente relevante, puede producir retroactivamente artefactos maliciosos que parezcan indistinguibles del software legítimo firmado históricamente. Un instalador, una imagen de firmware o un paquete de actualización firmados que permanezcan en circulación durante años implica que la ventana de exposición no es el momento en que aparece una computadora cuántica, sino toda la vida útil restante de cada artefacto firmado clásicamente que siga activo en ese momento. Por eso, la planificación de la migración a la firma de código debe tener en cuenta específicamente la vida útil de los artefactos, y no solo una fecha límite general para la migración.

¿Qué hace realmente el sellado de tiempo?

Un certificado de firma de código tiene un período de validez, generalmente de 460 días según los requisitos actuales del CA/Browser Forum. Sin una marca de tiempo, la verificación de una firma depende de compararla con un certificado que aún debe estar dentro de ese período de validez en el momento de la verificación, lo cual se convierte en un problema en el momento en que el certificado caduca, ya que de lo contrario fallaría la verificación del software firmado hace años.

Una autoridad de sellado de tiempo RFC 3161 resuelve este problema vinculando criptográficamente un hash de la firma a un punto en el tiempo confiable y verificable de forma independiente, utilizando su propia clave de firma almacenada en un HSM. Un verificador que comprueba una firma con sellado de tiempo después de la expiración del certificado se plantea una pregunta diferente: ¿era válido el certificado en el momento en que el sellado de tiempo demuestra que se creó la firma?, en lugar de si el certificado es válido en este momento. Por eso, el sellado de tiempo en cada operación de firma de código en producción se considera una práctica obligatoria, no una opción adicional.

Autoridad de marca de tiempo Preparación post-cuántica

Esta es la brecha que la mayoría de los planes de firma de código PQC pasan por alto. Un token de marca de tiempo es en sí mismo una firma digital, generada por la clave de la TSA, y esa clave debe ser compatible con la computación post-cuántica para que la marca de tiempo resista futuros criptoanálisis. Al momento de la publicación de esta guía, la compatibilidad con la marca de tiempo post-cuántica aún está en desarrollo en el ecosistema de la TSA, en lugar de estar ampliamente disponible. Esto significa que una organización que implemente la firma de código ML-DSA hoy en día podría descubrir que sus marcas de tiempo aún se emiten con una clave TSA RSA o ECDSA clásica.

Esa brecha es especialmente importante para los artefactos de larga duración. Un artefacto de software firmado con ML-DSA pero con marca de tiempo mediante una clave clásica hereda un punto débil: la marca de tiempo que prueba cuándo se creó la firma postcuántica es vulnerable al mismo riesgo criptoanalítico futuro que la firma postcuántica pretendía evitar. Confirme la hoja de ruta postcuántica específica de su TSA y la compatibilidad con algoritmos antes de considerar un proyecto piloto de firma de código como completamente postcuántico de extremo a extremo, y vuelva a marcar con una marca de tiempo los artefactos críticos de larga duración una vez que su proveedor ofrezca la función de marcado de tiempo postcuántico.

Soporte de HSM: La otra brecha de preparación

La preparación para la autoridad de marca de tiempo es solo una parte de la cuestión de la infraestructura; el HSM que contiene sus claves de firma reales es la otra parte, y los requisitos del CA/Browser Forum exigen que las claves privadas de firma de código residan en hardware validado por FIPS, no en software. La mayoría de los HSM heredados con certificación FIPS 140-2 se fabricaron antes de que el NIST finalizara ML-DSA y SLH-DSA y carecen de soporte nativo para ninguno de ellos. Las organizaciones que utilizan firmware HSM antiguo deben actualizar a un firmware compatible con FIPS 140-3 con soporte post-cuántico o implementar un enfoque de pila dual deliberado, donde la firma clásica continúe en el hardware existente mientras que la firma post-cuántica se ejecute en HSM actualizados o recién adquiridos, durante el período de transición.

Antes de implementar una canalización de firma de producción en su HSM, verifique que el modelo y la versión de firmware específicos coincidan con la compatibilidad real con PQC proporcionada por el fabricante, no con un anuncio en su hoja de ruta. La certificación FIPS 140-3 para el firmware de HSM compatible con PQC ha avanzado entre los principales fabricantes, pero la compatibilidad incluida varía según el modelo y la versión del firmware. La diferencia entre "el fabricante anunció la compatibilidad con PQC" y "nuestro hardware implementado tiene un firmware PQC validado" es precisamente donde se estancan las canalizaciones de firma.

Validación a largo plazo: Más allá de una única marca de tiempo.

La validación a largo plazo (LTV) amplía aún más la verificabilidad de la firma al incorporar evidencia del estado de revocación, como una respuesta OCSP o una CRL, recopilada en el momento de la firma o cerca de él, junto con la marca de tiempo. En conjunto, una fuente de tiempo confiable y la prueba de que el certificado de firma no fue revocado en ese momento permiten que una firma permanezca verificable durante períodos prolongados, a veces citados hasta veinte años para casos de uso de firma de documentos, sin que el verificador tenga que contactar a un servicio de revocación activo que podría ya no existir para cuando se realice la verificación.

Para artefactos con requisitos de verificación especialmente largos, se puede aplicar una segunda marca de tiempo antes de que la confianza depositada en la primera se vea comprometida, lo que permite extender la validez de la firma a un futuro más lejano. Este enfoque por capas, y no una sola marca de tiempo, es fundamental para una validez de firma verdaderamente duradera.

Firmware: Un problema de firma distintiva y de larga duración

El firmware presenta una versión del problema de la firma persistente que las actualizaciones de software generalmente no tienen: una vez implementado en un dispositivo, con frecuencia no se puede volver a firmar ni reemplazar, especialmente en hardware integrado o industrial con una vida útil de varias décadas. La firma aplicada durante la compilación es la única que tendrá ese artefacto, lo que convierte la elección del algoritmo de firma, así como la estrategia de validación a largo plazo y de sellado de tiempo que lo respalda, en una decisión con consecuencias que se extienden a toda la vida útil operativa del dispositivo, no solo a su período de implementación inicial.

Esta es también la razón por la que los esquemas de firma basados ​​en hash, como LMS y XMSS, junto con ML-DSA, despiertan un interés particular en la firma de firmware: su seguridad se basa en las propiedades de la función hash en lugar de en las suposiciones más recientes de la red, una elección conservadora que importa más para un artefacto que no se puede volver a firmar que para uno que se puede volver a emitir en un ciclo de actualización normal.

Ecosistemas de verificación: El problema de la sincronización plurianual

Una firma solo es útil si los sistemas que la verifican pueden validarla correctamente, y cada sistema operativo, navegador, herramienta de seguridad y plataforma de instalación que verifica los artefactos firmados necesita reconocer los algoritmos post-cuánticos antes de poder validar una firma correctamente. Este es un desafío de sincronización del ecosistema que requiere varios años, no una actualización puntual: una organización que comience a firmar con ML-DSA hoy producirá artefactos que no se validarán en ningún sistema de verificación que aún no se haya actualizado para reconocer ese algoritmo, que es precisamente el riesgo de compatibilidad que un programa piloto de firma paralela está diseñado para gestionar.

Antes del lanzamiento, diseñe su ecosistema de verificación real, no solo el de firma: qué versiones de sistemas operativos, herramientas de seguridad e instaladores utilizan sus clientes o usuarios internos, y cuáles de ellos ya reconocen firmas post-cuánticas. Un sistema de firma técnicamente listo no es lo mismo que un despliegue que valide correctamente para su base de usuarios real.

Ejecución de un programa piloto de firmas paralelas

La forma práctica de validar las herramientas de firma de código post-cuántico sin poner en riesgo la verificación en producción consiste en aplicar tanto una firma clásica como una post-cuántica al mismo artefacto, un patrón de doble firma independiente en lugar de una única firma híbrida. Los sistemas que ya validan la firma clásica siguen funcionando sin cambios; los sistemas actualizados para comprobar la firma post-cuántica pueden verificarla de forma independiente. Esto permite a una organización probar su infraestructura de firma ML-DSA, la compatibilidad con HSM, el sellado de tiempo y la integración CI/CD en condiciones de producción, mientras que cada verificador existente sigue funcionando exactamente igual que antes del inicio del programa piloto.

Lo que realmente recomendamos

Confirme la compatibilidad con algoritmos post-cuánticos específicos tanto de su autoridad de marca de tiempo como de su HSM antes de considerar cualquier prueba piloto de firma ML-DSA como totalmente resistente a la computación cuántica de extremo a extremo; la firma, la marca de tiempo y el hardware subyacente deben ser post-cuánticos para que el artefacto esté realmente protegido. Ejecute firmas clásicas y post-cuánticas en paralelo en artefactos de producción ahora, en lugar de esperar a una transición completa, para validar las herramientas con condiciones de producción reales y sin riesgo de verificación. Para el firmware y otros artefactos que no se pueden volver a firmar después de la implementación, considere el algoritmo de firma y la estrategia de marca de tiempo como una decisión con consecuencias que duran toda la vida útil del dispositivo, y pondere esa decisión en consecuencia. Mapee su ecosistema de verificación en paralelo con su infraestructura de firma, ya que una canalización de firma técnicamente completa aún falla en producción si los sistemas que verifican esas firmas no se han actualizado.

Cómo puede ayudar la consultoría de cifrado

CodeSign Secure , la plataforma de firma de código empresarial de Encryption Consulting, está diseñada específicamente para el riesgo que describe esta guía: admite la firma ML-DSA y SLH-DSA con firmas separables, almacena las claves dentro de HSM validados por FIPS y aplica el sellado de tiempo RFC 3161 como un paso controlado por políticas en cada flujo de trabajo de firma, de modo que las deficiencias de sellado de tiempo y preparación de HSM mencionadas anteriormente se abordan a nivel de plataforma en lugar de dejarse a la configuración de cada canalización individual. La firma de firmware e IoT es compatible mediante LMS (NIST SP 800-208), el esquema basado en hash que esta guía señala para los artefactos que no se pueden volver a firmar después de la implementación.

Nuestros servicios de asesoramiento de PQC integran la evaluación de la preparación de la TSA, el mapeo del ecosistema de verificación y el programa piloto de firma paralela que se describen en esta guía en un plan de migración estructurado, secuenciado según la hoja de ruta de arquitectura más amplia que se encuentra en nuestra guía complementaria.

La firma es tan fuerte como su eslabón más débil.

Proteger un artefacto firmado de larga duración requiere más que elegir un algoritmo post-cuántico. La marca de tiempo que prueba cuándo se firmó, el HSM que contiene la clave con la que se firmó y el ecosistema de verificación que lo comprueba años después deben estar preparados para la era post-cuántica, ya que una deficiencia en cualquiera de ellos socava la protección que se pretendía brindar con el algoritmo elegido. Confirmar explícitamente la preparación de TSA y HSM, añadir evidencia de validación a largo plazo, considerar la restricción de que el firmware no se puede volver a firmar como un requisito de diseño fundamental y mapear el ecosistema de verificación junto con el proceso de firma son los factores que realmente determinan si una firma aplicada hoy seguirá siendo válida dentro de veinte años.

Preguntas frecuentes

¿Por qué cobra mayor importancia el marcado de tiempo durante una transición post-cuántica?

El sellado de tiempo demuestra que una firma se creó en un momento específico, que es precisamente la evidencia necesaria para probar que una firma se realizó antes de que un algoritmo clásico quedara obsoleto, protegiéndola contra reclamaciones de falsificación retroactivas una vez que las computadoras cuánticas puedan romper ese algoritmo.

¿Están las autoridades de sellado de tiempo y los HSM preparados para la era post-cuántica hoy en día?

El soporte aún está en desarrollo en ambos ecosistemas, en lugar de estar ampliamente disponible. La mayoría de los HSM FIPS 140-2 heredados carecen de soporte nativo para ML-DSA o SLH-DSA, y la mayoría de los TSA públicos tampoco han implementado la firma post-cuántica. Confirme el soporte implementado (no anunciado) de su proveedor específico antes de considerar un proyecto piloto como totalmente post-cuántico.

¿Por qué la firma de firmware es diferente de la firma de software habitual para fines de PQC?

El firmware, sobre todo en hardware integrado e industrial, a menudo no se puede volver a firmar una vez implementado. La firma aplicada durante la compilación debe permanecer verificable durante toda la vida útil del dispositivo, que puede abarcar décadas, lo que hace que la decisión inicial sobre el algoritmo y la marca de tiempo sea mucho más importante que en el caso del software que recibe actualizaciones periódicas.

¿Qué es un programa piloto de firma paralela?

Aplicar una firma clásica y una postcuántica al mismo artefacto como dos firmas separadas e independientes. Los verificadores existentes siguen validando la firma clásica sin cambios, mientras que los verificadores actualizados pueden comprobar la firma postcuántica de forma independiente, lo que permite a una organización probar la infraestructura de firma postcuántica sin riesgo alguno para la verificación actual.

¿Durante cuánto tiempo puede permanecer verificable una firma con la fecha y hora correctas?

Con la validación a largo plazo que combina una marca de tiempo y evidencia de estado de revocación integrada, se citan períodos de verificación de hasta veinte años para casos de uso de firma de documentos. Volver a marcar la fecha y hora antes de que el ancla de confianza de la marca de tiempo original se vuelva cuestionable puede extender aún más ese período para artefactos especialmente longevos.