Firma de firmware: una guía práctica

La firma de firmware consiste en adjuntar una firma criptográfica al firmware para que un dispositivo pueda verificar, tanto al arrancar como al actualizar, que el firmware proviene de una fuente confiable y no ha sido alterado. Es la base del arranque seguro y la raíz de la confianza para los sistemas IoT, embebidos y automotrices.

La firma de firmware permite que un dispositivo verifique criptográficamente que el código de bajo nivel que ejecuta sea auténtico y no haya sido modificado antes de su ejecución. El dispositivo posee una clave pública de confianza, a menudo integrada en el hardware, y verifica la firma del firmware con ella. Si la firma no coincide, el dispositivo rechaza la ejecución del firmware. Esto impide que los atacantes instalen firmware malicioso y constituye la base de toda cadena de arranque seguro.

Puntos Clave

• La firma digital del firmware adjunta una firma digital al firmware para que un dispositivo pueda verificar su autenticidad e integridad antes de ejecutarlo, lo que constituye la raíz de confianza para el arranque seguro.
• El ancla de confianza es una clave pública integrada en un hardware programable una sola vez (OTP) y leída por una ROM inmutable cada vez que se enciende el dispositivo, por lo que la cadena de confianza no se puede reemplazar en el campo.
• Las claves de firma deben residir en un Módulo de Seguridad de Hardware (HSM). Una clave de firma de firmware robada permite a un atacante firmar firmware malicioso en el que los dispositivos confiarán, lo que constituye una de las brechas más dañinas posibles en la cadena de suministro.
• El firmware suele tener una vida útil mayor que su criptografía: los dispositivos implementados hoy en día podrían funcionar hasta la década de 2040. Su larga vida útil convierte la preparación para la era post-cuántica en un requisito de adquisición, no en una preocupación futura.
• CNSA 2.0 considera la firma de firmware como el caso de uso de máxima prioridad para la transición post-cuántica. Las opciones implementables seguras para computación cuántica en la actualidad son los esquemas basados ​​en hash con estado LMS y XMSS (NIST SP 800-208), con SLH-DSA (FIPS 205) como una alternativa sin estado.

¿Por qué la firma de firmware es diferente de la firma de código ordinaria?

La firma de firmware es similar a la firma de código , pero con limitaciones que la hacen particularmente exigente. El firmware se ejecuta en el nivel más bajo del dispositivo, antes del sistema operativo, por lo que una vulnerabilidad en este nivel está fuera del alcance de la mayoría de las herramientas de seguridad. Además, a diferencia de una aplicación que se puede actualizar semanalmente, el firmware suele estar integrado en el hardware o se actualiza con poca frecuencia, a veces nunca, durante la vida útil del dispositivo, que se mide en décadas.

El desafío se define por tres características. El firmware es el primer código en ejecutarse, por lo que constituye la base de confianza para todo lo demás. Se ejecuta en hardware con recursos limitados, por lo que la verificación de la firma debe ser rápida y sencilla. Además, tiene una larga vida útil, por lo que las decisiones criptográficas tomadas durante la fabricación deben mantenerse válidas durante toda la vida útil del dispositivo. Un automóvil, un controlador industrial o un dispositivo médico firmado en 2026 podrían necesitar verificar su firmware en 2041.

Cómo funcionan la firma de firmware y el arranque seguro.

La firma digital del firmware es solo una parte de la historia. Su verdadero valor reside en el arranque seguro, el proceso de ejecución en el que cada etapa de la cadena de arranque verifica la siguiente antes de ceder el control.

• Raíz de confianza del hardware: Durante la fabricación del silicio, se integra una clave pública en una memoria programable una sola vez (OTP). Una ROM inmutable lee esta clave cada vez que se enciende el dispositivo, y no se puede reemplazar fuera de él. Este es el elemento fundamental de toda la cadena.
• Firma cada imagen de firmware: El fabricante aplica un hash a cada imagen de firmware (ROM, gestores de arranque, aplicación) y la firma con la clave privada correspondiente, que se guarda de forma segura en un HSM, nunca en el dispositivo.
• Verificar etapa por etapa: Al arrancar, la ROM verifica la firma del gestor de arranque de primera etapa con la clave pública fusionada. Ese gestor de arranque verifica la siguiente etapa, que a su vez verifica la siguiente, formando así una cadena de confianza ininterrumpida desde el hardware hasta la aplicación.
• Rechazar en caso de fallo: Si alguna firma no coincide, el arranque verificado se detiene y el dispositivo se niega a ejecutar la imagen no verificada. El firmware manipulado o no autorizado nunca se ejecuta.

Dado que la clave raíz reside en un hardware inmutable y cada etapa controla la siguiente, un atacante no puede insertar firmware malicioso en ningún punto de la cadena sin poseer la clave de firma privada. Por eso, proteger la clave de firma es fundamental.

Por qué la llave de firma es la joya de la corona

Si un atacante roba una clave de firma de firmware, puede firmar firmware malicioso que todos los dispositivos que confíen en esa clave aceptarán como auténtico. Dado que la clave de verificación suele estar integrada en el hardware y no se puede modificar en el campo, una clave de firma de firmware comprometida puede ser irrecuperable: es posible que no haya forma de revocarla en los dispositivos que ya están en funcionamiento. Este es el peor escenario posible para la cadena de suministro, y por eso las claves de firma de firmware deben protegerse con mayor cuidado que casi cualquier otra clave que posea una organización.

El requisito práctico es fundamental: las claves privadas para la firma del firmware deben generarse y almacenarse en un Módulo de Seguridad de Hardware (HSM), nunca exportarse a un servidor de compilación ni a una máquina de desarrollo, y las operaciones de firma deben estar autenticadas, con control de acceso y registradas. El firmware pasa por muchas manos (fabricante de semiconductores, fabricante de equipos originales, proveedor de primer nivel, fabricante por contrato), y cada transferencia representa un punto donde la cadena podría verse comprometida, por lo que un control de claves centralizado y auditado es esencial.

Buenas prácticas para la firma de firmware

• Siga firmando las claves en un HSM: Generar y almacenar claves de firma de firmware en un FIP 140-2 HSM de nivel 2 o superior. Nunca permita que la clave privada entre en contacto con un servidor de compilación, un ejecutor de CI o un ordenador portátil de desarrollador.
• Generar confianza en el hardware: Fusiona la clave pública raíz con la contraseña de un solo uso (OTP) y verifícala desde una ROM inmutable, de modo que el ancla de confianza no pueda ser manipulada en el campo.
• Firma cada etapa de la cadena de arranque: Firma las extensiones de la ROM, los gestores de arranque y el firmware de las aplicaciones, y verifica cada etapa con respecto a la anterior, para que no haya ningún espacio sin firmar.
• Utilice algoritmos robustos y actuales: Utilice SHA-384 o un algoritmo de hash más robusto y claves del tamaño adecuado. Prevea la implementación de firmas post-cuánticas dada la larga vida útil de los dispositivos.
• Controlar y auditar quién puede firmar: Exija autenticación y autorización para cada operación de firma, y ​​registre quién firmó qué y cuándo, en todos los proveedores de la cadena.
• Diseño para la criptoagilidad: Siempre que el hardware lo permita, habilite las actualizaciones del algoritmo de firma para que los dispositivos no queden bloqueados a un algoritmo que pueda debilitarse con el tiempo.

Firma de firmware y la transición post-cuántica

La firma de firmware es el caso de uso más urgente de la firma de código en la transición a la criptografía postcuántica , y la razón es estructural. En muchos dispositivos, el algoritmo de verificación del firmware está predefinido desde su implementación, integrado en el hardware inmutable o en el código de arranque. Si dicho algoritmo es RSA o ECDSA , un futuro ordenador cuántico que ejecute el algoritmo de Shor podría falsificar firmas, y es posible que no haya forma de actualizar el algoritmo en los dispositivos ya comercializados.

Por eso, la guía CNSA 2.0 de la NSA identifica la firma de firmware como el caso de uso de firma de mayor prioridad para la transición cuántica, y por eso apunta a firmas basadas en hash que están estandarizadas y se pueden implementar hoy en día, en lugar de esperar a esquemas más nuevos. Las opciones:

• LMS y XMSS (NIST SP 800-208): Firmas basadas en hash con estado, estandarizadas en 2019 y aprobadas bajo CNSA 2.0 para la firma de firmware y software. Ya se pueden implementar y se basan en una seguridad de función hash bien conocida, adecuada para firmware de larga duración.
• SLH-DSA (FIPS 205): Se finalizó en agosto de 2024 una firma basada en hash sin estado. Evita la carga de gestión de estado de LMS y XMSS a costa de firmas más grandes, y comparte su base de seguridad conservadora.
• ML-DSA (FIPS 204): La firma de propósito general basada en retículos. Es la candidata a largo plazo para un uso generalizado, aunque para las raíces más conservadoras y duraderas muchas organizaciones prefieren los esquemas basados ​​en funciones hash.

La gestión estatal de la captura con LMS y XMSS
LMS y XMSS son sistemas con estado: cada clave privada solo puede generar un número fijo de firmas, y el firmante debe controlar qué claves de un solo uso se han utilizado, ya que reutilizarlas compromete la seguridad. Esto los hace poco prácticos para firmas de alta frecuencia, pero muy adecuados para la firma de firmware, que es poco frecuente y controlada. Es importante destacar que el estado lo gestiona el firmante (en su infraestructura de firma), no el dispositivo, por lo que no añade complejidad al hardware implementado. Una plataforma de firma eficiente gestiona este seguimiento del estado automáticamente.

El cronograma de CNSA 2.0 para la firma de software y firmware prevé dar preferencia a los algoritmos de seguridad cuántica para 2025 y utilizarlos exclusivamente para 2030, la categoría más ambiciosa de todo el conjunto, precisamente porque el firmware es muy difícil de modificar después de su implementación.

Firma de firmware en IoT, sistemas embebidos y automoción

La firma digital del firmware cobra especial importancia cuando los dispositivos son numerosos, de larga duración y de difícil acceso. En el Internet de las Cosas, las actualizaciones de firmware sin firmar constituyen un vector de ataque fundamental para la creación de botnets y la obtención de persistencia.

En el sector automotriz, normativas como la UNECE R155 y estándares como la ISO/SAE 21434 exigen que se mitiguen las amenazas de modificación del firmware, y los vehículos fabricados hoy seguirán circulando hasta la década de 2040. En los dispositivos industriales y médicos, una vulnerabilidad en el firmware puede tener consecuencias para la seguridad, no solo para la protección de datos.

Lo que comparten estos ámbitos es la combinación que hace que la firma de firmware sea indispensable: hardware con recursos limitados que debe verificar las firmas de manera eficiente, una vida útil muy prolongada que supera las suposiciones criptográficas y una cadena de suministro que involucra a múltiples organizaciones antes de que un dispositivo llegue al mercado. Lograr una correcta firma de firmware y una gestión de claves adecuada es la base sobre la que se sustenta todo lo demás en la seguridad de los dispositivos.

Cómo ayuda la consultoría de cifrado

CodeSign Secure de Encryption Consulting está diseñado precisamente para este problema. Mantiene las claves de firma del firmware en un HSM (Módulo de Seguridad de Hardware) con certificación FIPS 140-2 Nivel 2, de modo que la clave privada nunca sale del hardware, controla quién está autorizado a firmar y registra cada operación de firma para su auditoría en todos sus proveedores y sistemas de compilación.

Integra la firma digital en los flujos de CI/CD, de modo que el firmware se firma automáticamente con claves protegidas por hardware. Además, admite los esquemas de firma basados ​​en hash y post-cuánticos que la firma de firmware requiere cada vez más, incluyendo la gestión de estado que exigen LMS y XMSS. El resultado es un proceso de firma único y controlado para el firmware, las cadenas de arranque seguro y el resto de la firma de código. Cuenta con el respaldo de las prácticas certificadas ISO/IEC 27001:2022 y SOC 2.

Preguntas frecuentes

¿Qué es la firma de firmware?

La firma de firmware consiste en añadir una firma criptográfica al firmware para que un dispositivo pueda verificar, antes de ejecutarlo, que proviene de una fuente confiable y que no ha sido alterado. El dispositivo posee una clave pública de confianza, generalmente integrada en el hardware, y compara la firma del firmware con ella. Si la firma no coincide, el dispositivo rechaza la ejecución del firmware, lo que impide que los atacantes instalen código malicioso en el nivel más bajo del sistema.

¿Cuál es la diferencia entre la firma de firmware y el arranque seguro?

La firma digital del firmware consiste en generar la firma; el arranque seguro es el proceso de ejecución que la verifica. Al compilar el firmware, se firma con una clave privada. Al encender el dispositivo, el arranque seguro comprueba cada etapa de la cadena de arranque con una clave pública de confianza antes de ejecutarla, partiendo de una raíz de hardware inmutable. La firma digital del firmware proporciona las firmas y el arranque seguro las aplica, por lo que ambos trabajan conjuntamente para impedir la ejecución de firmware no autorizado.

¿Por qué es necesario almacenar las claves de firma del firmware en un HSM?

El robo de una clave de firma de firmware es catastrófico y, a menudo, irrecuperable. Un atacante con la clave puede firmar firmware malicioso que todos los dispositivos que confíen en ella aceptarán. Dado que la clave de verificación suele estar integrada en el hardware, puede resultar imposible revocarla en los dispositivos ya implementados. Almacenar la clave privada en un módulo de seguridad de hardware garantiza que nunca abandone el hardware protegido contra manipulaciones, por lo que ni siquiera un sistema de compilación totalmente comprometido puede extraerla.

¿Qué algoritmos debo usar para la firma de firmware post-cuántico?

Para la firma de firmware segura frente a ataques cuánticos, las opciones disponibles actualmente son los esquemas basados ​​en hash con estado LMS y XMSS, estandarizados en NIST SP 800-208 y aprobados bajo CNSA 2.0. SLH-DSA (FIPS 205) es una alternativa sin estado basada en hash, finalizada en agosto de 2024. Los esquemas basados ​​en hash suelen preferirse para raíces de firmware de larga duración, ya que su seguridad se basa únicamente en funciones hash bien conocidas. ML-DSA (FIPS 204) es la opción de propósito general basada en retículos para un uso más amplio.

¿Por qué la firma de firmware es la máxima prioridad en la transición post-cuántica?

Porque el firmware es lo más difícil de modificar después de su implementación. En muchos dispositivos, el algoritmo de verificación de firmas está integrado en hardware o código de arranque inmutable, por lo que si utiliza RSA o ECDSA, una futura computadora cuántica podría falsificar firmas de firmware sin posibilidad de actualizar el algoritmo en los dispositivos ya en funcionamiento. La guía CNSA 2.0 de la NSA considera la firma de firmware como el caso de uso de firma de máxima prioridad y establece el cronograma más ambicioso: uso exclusivo seguro frente a ataques cuánticos para 2030.

¿Cuáles son las preocupaciones en materia de gestión del estado con LMS y XMSS?

LMS y XMSS son firmas basadas en hash con estado: cada clave privada solo puede generar un número fijo de firmas, y el firmante debe controlar qué claves de un solo uso se han utilizado, ya que reutilizarlas compromete la seguridad. Esto las hace inadecuadas para firmas de alta frecuencia, pero idóneas para firmas de firmware controladas y poco frecuentes. El estado lo gestiona la infraestructura de firma, no el dispositivo, por lo que no añade complejidad al hardware implementado. Una plataforma de firma adecuada realiza un seguimiento automático de este estado.

Firma el firmware contra claves protegidas por hardware.

La seguridad de la firma de firmware depende de la protección de sus claves, y lo que está en juego es mayor que en cualquier otro caso de uso de firma. Descubra CodeSign Secure para firmar firmware e imágenes de arranque seguro con claves protegidas por HSM, con soporte para algoritmos post-cuánticos y auditoría completa en toda su cadena de suministro.