Por qué el firmware inmutable es una función de seguridad

AI summary

El firmware es el software fundamental integrado en el chip de una billetera de hardware. Gobierna cada operación crítica: cómo se generan, almacenan y utilizan las  claves privadas para firmar transacciones. Dado que el firmware opera en el nivel más profundo del dispositivo, con acceso directo al elemento seguro donde residen las claves privadas, su integridad es esencial. Si el firmware se ve comprometido, las consecuencias son graves y a menudo irreversibles.

Este artículo ofrece un análisis exhaustivo de los dos enfoques en competencia sobre el firmware en las billeteras de hardware: actualizable e inactualizable (inmutable). Explora vulnerabilidades documentadas, analiza métodos de ataque emergentes y responde directamente a afirmaciones recientes de la industria sobre las limitaciones del firmware inmutable.

¿Qué es el firmware en las billeteras de hardware?

El firmware es el software especializado de bajo nivel integrado directamente en el chip de una billetera de hardware. Funciona como el sistema operativo del dispositivo, aunque está mucho más limitado en alcance que el software que corre en una computadora o smartphone. El firmware controla cada función crítica de seguridad: generación de claves privadas, almacenamiento de claves, firma de transacciones y comunicación con aplicaciones complementarias.

A diferencia de las aplicaciones regulares, el firmware corre directamente sobre el hardware, dándole acceso inmediato al elemento seguro, el chip resistente a manipulaciones donde se guardan las claves privadas. Esta posición especial subraya la importancia de la integridad del firmware. Si se ve comprometido, un atacante podría acceder a la información más sensible de la billetera.

Los fabricantes de billeteras de hardware han adoptado dos enfoques distintos para la gestión del firmware:

• Firmware actualizable: El fabricante puede lanzar nuevas versiones de firmware que los usuarios descargan e instalan en sus dispositivos. Este modelo es utilizado por billeteras como Ledger, Trezor y la mayoría de los principales fabricantes.

• Firmware inmutable (inactualizable): El firmware se escribe en el chip una sola vez durante la fabricación y no puede ser alterado posteriormente por el fabricante, actores externos ni por ningún otro medio. Este es el modelo utilizado por Tangem.

A primera vista, el firmware actualizable ofrece ventajas claras: la capacidad de parchear vulnerabilidades, introducir nuevas funciones y adaptarse a las amenazas. Sin embargo, el mecanismo de actualización en sí mismo introduce riesgos de seguridad sustanciales que superan sus ventajas.

Contra qué está diseñado para proteger el firmware inmutable

Toda arquitectura de seguridad comienza con un modelo de amenazas: una evaluación formal de qué ataques el sistema está diseñado para prevenir, qué riesgos acepta y dónde se distribuye la responsabilidad entre las distintas capas.
 

El firmware actualizable crea un canal persistente para entregar código a un dispositivo después de que ha sido vendido. Si bien este canal está destinado a mejoras legítimas, también representa una superficie de ataque que permanece accesible para actores maliciosos durante toda la vida útil del dispositivo.

El firmware inactualizable es el único enfoque comúnmente aceptado para dispositivos seguros operados por usuarios finales. NO existen tarjetas bancarias ni pasaportes electrónicos que permitan actualizaciones de firmware por aire en el campo. YubiKey, una llave de seguridad de hardware que proporciona autenticación de dos factores y multifactor, también tiene firmware inmutable. Esto se debe a que los riesgos de seguridad siempre son demasiado altos.

Analicemos estas amenazas:

1. Amenazas internas

Cualquier organización capaz de implementar actualizaciones de firmware necesariamente emplea personas que pueden modificar el código que controla las claves privadas de los usuarios. Un empleado malicioso, ya sea motivado por ganancias financieras, razones ideológicas o coerción externa, podría insertar una puerta trasera o vulnerabilidad en una actualización.

La industria de ciberseguridad en general ha documentado un aumento constante en los incidentes impulsados por personas internas durante la última década. En las billeteras de hardware, donde un solo camino de código comprometido podría afectar millones de dólares en fondos de usuarios, este riesgo es particularmente grave.

2. Ingeniería social

La existencia de una cadena de actualización de firmware crea un objetivo de alto valor para los ataques de ingeniería social. Los adversarios pueden intentar manipular a los empleados para que modifiquen código, compartan credenciales de acceso o aprueben cambios maliciosos a través de phishing, suplantación de identidad o escenarios de emergencia fabricados.

La amenaza se ha intensificado considerablemente: los ataques de vishing con deepfake de voz aumentaron más del 1,600% en el primer trimestre de 2025. Cualquier empresa que mantenga un mecanismo de actualización debe defenderse continuamente contra estas tácticas en evolución.

3. Coerción gubernamental y presión regulatoria

En ciertas jurisdicciones, la legislación permite a los organismos gubernamentales obligar a las empresas tecnológicas a implementar capacidades de acceso remoto o vigilancia.

Si una billetera de hardware admite actualizaciones de firmware, un gobierno podría exigir al fabricante que distribuya una actualización que otorgue acceso de puerta trasera a los fondos de los usuarios.

Los empleados también pueden enfrentar presión directa de actores estatales, organizaciones criminales o cuerpos regulatorios. El mecanismo de actualización es el vector habilitador para dicha coerción. Sin él, la demanda no puede cumplirse.

4. Control de calidad insuficiente

No todas las vulnerabilidades de firmware se introducen de forma maliciosa. Los ciclos de desarrollo apresurados, las revisiones de código incompletas y las pruebas inadecuadas pueden resultar en actualizaciones que inadvertidamente introducen nuevas fallas de seguridad.

Cuando un fabricante lanza actualizaciones con frecuencia, ya sea para parches menores, adición de funciones o cambios de interfaz, la probabilidad de introducir una vulnerabilidad no intencionada aumenta con cada lanzamiento.

5. Brechas de auditoría

Una auditoría de firmware es una revisión exhaustiva del código fuente, la arquitectura y las prácticas de desarrollo llevada a cabo por una firma de seguridad independiente de terceros. Su propósito es verificar la ausencia de puertas traseras, evaluar la calidad de las implementaciones criptográficas y verificar el cumplimiento de los estándares de seguridad de la industria.

Las auditorías exhaustivas son costosas y demandan mucho tiempo, a menudo cuestan cientos de miles de dólares y requieren varios meses para completarse. Realizar una auditoría independiente para cada versión de firmware es económica y logísticamente impracticable para la mayoría de los fabricantes.

6. Exposición de la cadena de suministro

El proceso de actualización de firmware constituye una cadena de suministro compleja: el código se escribe, revisa, compila, firma criptográficamente, distribuye a través de servidores y se instala en el dispositivo del usuario.

Cada etapa representa un punto potencial de compromiso. Los atacantes pueden apuntar al entorno de compilación, interceptar el canal de distribución o comprometer las claves de firma utilizadas para validar la autenticidad de las actualizaciones. Con la participación de un interno, un atacante podría modificar la actualización durante el tránsito, entregando firmware comprometido que supera todas las verificaciones estándar.

7. Presión sobre los usuarios

Los fabricantes de billeteras actualizables suelen requerir actualizaciones para mantener la compatibilidad con el software complementario. Los usuarios que rechazan pueden experimentar funcionalidad degradada o pérdida de acceso a ciertas características.

Esta dinámica obliga a los usuarios a aceptar actualizaciones por confianza, independientemente de si han sido verificadas de forma independiente. El firmware inmutable elimina esta dependencia. El dispositivo opera tal como fue entregado durante toda su vida útil, sin depender de cambios de código futuros.

Cómo los mecanismos de actualización crean una superficie de ataque

El mecanismo que permite parchear problemas de firmware es en sí mismo una superficie de ataque que persiste durante toda la vida útil del dispositivo.

Para aceptar una actualización de firmware, un dispositivo debe: 

• Recibir código externo a través de un canal de comunicación (USB, Bluetooth),
   
• Validar la autenticidad del código usando firmas criptográficas;
   
• Escribir el nuevo código en la memoria del elemento seguro y sobrescribir o reemplazar el firmware existente. 

Si el protocolo de actualización es deficiente, el canal de comunicación entre la aplicación complementaria y el cargador de arranque del dispositivo podría ser interceptado o suplantado mediante ataques de intermediario en la capa de transporte USB o Bluetooth.

La verificación de firmas puede eludirse si las claves de firma son exfiltradas o si la rutina de verificación es eludida mediante inyección de fallos, como el glitching de voltaje, durante la verificación. 

La operación de escritura en sí es vulnerable a ataques de tiempo entre verificación y uso (TOCTOU), en los que el firmware validado se reemplaza con código malicioso entre el paso de verificación y la escritura real en la memoria flash.

Un dispositivo que carece de estas capacidades no presenta tales superficies de ataque.  

Riesgos documentados del firmware actualizable

Varios incidentes bien documentados han demostrado cómo las vulnerabilidades del firmware pueden comprometer las billeteras de hardware.

1. Vulnerabilidad de reemplazo de firmware MCU del Ledger Nano S (2018). 
   El investigador de seguridad Saleem Rashid demostró que un atacante podría  reemplazar el firmware del Ledger Nano S con una versión maliciosa que exfiltraría claves privadas. Logró subir firmware modificado a la billetera, que revelaría las claves privadas del usuario la próxima vez que se usara el dispositivo. 
   También afirmó que era posible subir el firmware de forma remota instalando malware en la computadora de la víctima que la incitaría a actualizar el firmware "defectuoso" de su billetera. Ledger lanzó la actualización de firmware 1.4.1 para mitigar el problema.
    
2. Controversia de Ledger Recover (2023). 
   La versión de firmware 2.2.1 de Ledger introdujo una nueva función de recuperación que le permitía extraer datos de la frase semilla del Elemento Seguro y transmitirlos a terceros. El lanzamiento del servicio reveló que el firmware de Ledger tiene la capacidad técnica de extraer y transmitir material de la frase semilla. 
   
   Esta capacidad existe en cada dispositivo que ejecuta el firmware actualizado, independientemente de si el usuario está suscrito al servicio. Los usuarios señalaron que esto contradecía directamente la declaración previa de Ledger de que las actualizaciones de firmware no pueden extraer claves privadas del Elemento Seguro.
    
3. Campaña de phishing de firmware de Blockstream Jade (2025). 
   Blockstream emitió una alerta de seguridad urgente advirtiendo sobre una campaña de phishing dirigida a propietarios de billeteras de hardware Jade a través de correos electrónicos falsos de actualización de firmware. Los correos electrónicos fraudulentos se hacían pasar por comunicaciones legítimas de Blockstream, indicando a los usuarios que descargaran actualizaciones de firmware haciendo clic en enlaces maliciosos. El firmware falso probablemente redirigía fondos a direcciones controladas por el atacante una vez instalado.
    
4. Ataques a la cadena de suministro contra billeteras Ledger Nano X. 
   Kraken Security Labs identificó ataques que podrían permitir a actores maliciosos tomar control de computadoras conectadas a las billeteras Ledger Nano X e instalar malware, resultando potencialmente en la pérdida o robo de fondos almacenados. En este escenario, el firmware del procesador no seguro se modifica usando un protocolo de depuración para actuar como un dispositivo de entrada, como un teclado, que puede enviar pulsaciones de teclas maliciosas a la computadora host del usuario. 
   
   El Ledger Nano X se entrega con la funcionalidad de depuración habilitada en su procesador no seguro, una característica que se deshabilita tan pronto como se instala la primera "aplicación", como la app de Bitcoin, en el dispositivo. Sin embargo, antes de que se instale cualquier aplicación, el dispositivo puede ser reprogramado con firmware malicioso 
   que puede comprometer la computadora host, similar a los ataques "BadUSB" y "Rubber Ducky".

Dark Skippy: un caso de estudio en ataques basados en firmware

Divulgado en agosto de 2024, el ataque Dark Skippy representa una de las amenazas basadas en firmware más técnicamente sofisticadas identificadas hasta la fecha. Demuestra la gravedad del riesgo que plantea el firmware comprometido para los usuarios de billeteras de hardware.

Descripción técnica

Dark Skippy apunta al proceso de generación de nonce utilizado durante la firma criptográfica de transacciones. En funcionamiento normal, una billetera de hardware genera un número aleatorio (nonce) cada vez que firma una transacción. Esta aleatoriedad es esencial para la seguridad del esquema de firma. El ataque se desarrolla en cuatro etapas:

1. Compromiso del firmware: Se instala firmware malicioso en la billetera de hardware a través de una actualización manipulada, un ataque a la cadena de suministro o acceso físico.

2. Manipulación de nonce: En lugar de generar nonces aleatorios, el firmware comprometido produce nonces débiles y deterministas derivados de partes de la frase semilla del usuario.

3. Exfiltración de datos: Cuando el usuario firma una transacción, fragmentos de la frase semilla se incrustan dentro de la firma de la transacción y se transmiten a la blockchain.

4. Reconstrucción de la semilla: El atacante monitorea la blockchain en busca de firmas afectadas y aplica el algoritmo Canguro de Pollard para calcular la frase semilla original a partir de los datos públicos de nonce.

Implicaciones

Las variantes anteriores de ataques de exfiltración basados en nonce requerían docenas de transacciones firmadas para extraer datos suficientes. Dark Skippy puede extraer la frase semilla completa a partir de tan solo 2 transacciones. Un solo uso de un dispositivo comprometido es suficiente para vaciar completamente la billetera.
 

El ataque también es excepcionalmente difícil de detectar. Las firmas comprometidas son indistinguibles de las legítimas para el usuario. Sin mensajes de error, sin anomalías visuales y sin indicadores de comportamiento que alerten al usuario sobre la brecha. La extracción ocurre en silencio, y las víctimas pueden no descubrir el compromiso hasta que sus fondos hayan sido transferidos.
 

Los investigadores responsables de la divulgación (Lloyd Fournier y Nick Farrow de Frostsnap, y Robin Linus de ZeroSync) notificaron de forma privada a más de 15 proveedores de billeteras de hardware en marzo de 2024 antes de publicar sus hallazgos. Al momento de escribir este artículo, Dark Skippy no ha sido observado en la práctica, pero el proof-of-concept es completamente funcional y el código de demostración ha sido puesto a disposición del público.

El argumento contra el firmware de código abierto

La divulgación de código abierto hace que el código fuente esté disponible públicamente, permitiendo que más personas encuentren errores. Esto ha generado beneficios de seguridad en sistemas operativos, bibliotecas criptográficas y protocolos de red.

Sin embargo, la revisión de código abierto es voluntaria, no estructurada y no ofrece cobertura garantizada. No existe ningún requisito de que un revisor específico examine un camino de código específico. 
 

Proyectos de código abierto de alto perfil han albergado vulnerabilidades críticas durante años (Heartbleed en OpenSSL persistió por más de dos años en código ampliamente revisado). La mera disponibilidad del código fuente no garantiza que haya sido revisado de manera competente, ni que los revisores tengan la experiencia especializada requerida para el firmware de elementos seguros.

Adicionalmente, publicar el código fuente del firmware de billeteras de hardware introduce sus propios riesgos. Proporciona a los adversarios un mapa detallado de los componentes internos del sistema, lo que potencialmente habilita ataques dirigidos contra comportamientos específicos de la implementación. 

Por eso Tangem emplea un enfoque de seguridad por profundidad: el firmware es de código cerrado pero evaluado formalmente por expertos acreditados, mientras que la aplicación complementaria y el SDK son completamente de código abierto en GitHub.

La arquitectura de firmware inmutable de Tangem

Con Tangem, el firmware se carga en el elemento seguro durante la fabricación y no puede ser modificado ni reemplazado posteriormente. No existe ningún mecanismo de actualización, ninguna interfaz USB para flashear firmware y ningún canal inalámbrico para actualizaciones por aire. El elemento seguro está arquitectónicamente diseñado para rechazar cualquier intento de escribir código nuevo después de la instalación inicial.

Respuesta a las afirmaciones de Ledger

Ledger ha comentado públicamente sobre Tangem varias veces, y su propio equipo de investigación de seguridad ha realizado investigaciones exhaustivas sobre nosotros. Ese contexto vale la pena tenerlo en cuenta mientras abordamos las afirmaciones que circulan sobre Tangem.
 

Afirmación: "Congelar el sistema no protege a los usuarios, protege al atacante."

Esta declaración sugiere que la inmutabilidad es meramente inacción, haciendo parecer que un sistema estático podría ser menos seguro; de hecho, es el enfoque común. Como mencionamos antes, las tarjetas de crédito, los pasaportes y los YubiKeys llevan todos firmware inmutable. Un sistema inmutable corta la herramienta remota más poderosa del atacante: inyectar código malicioso a través de actualizaciones. 

El enfoque de Ledger es bastante poco común y riesgoso; cada actualización de firmware emitida le proporciona al atacante una nueva oportunidad.
 

Afirmación: "Las brechas de auditoría de Tangem dejan períodos de varios años sin escrutinio externo."

Ledger argumentó que las dos auditorías de Tangem (2018 por Kudelski y 2023 por Riscure) dejan brechas donde la supervisión externa está ausente. Este argumento de brecha de auditoría tiene menos fuerza contra el firmware inmutable que contra el firmware actualizable. Cuando el firmware cambia entre auditorías, el período no auditado implica ejecutar código nuevo y no revisado. Cuando el firmware es inmutable, el período no auditado implica ejecutar el mismo código que fue revisado anteriormente.
 

Afirmación: "Tangem no puede adaptarse a nuevas curvas criptográficas o protocolos blockchain."

Anteriormente, Ledger ha argumentado que el firmware inmutable no puede admitir nuevas curvas criptográficas, lo que podría llevar a la obsolescencia. Sin embargo, esto confunde dos capas arquitectónicas.

El firmware de Tangem implementa primitivas criptográficas fundamentales (ECDSA y EdDSA) utilizadas por la gran mayoría de las redes blockchain. 

El soporte para nuevas blockchains, estándares de tokens y protocolos se implementa en la aplicación complementaria en la capa de aplicación, no en el firmware. Tangem actualmente admite más de 85 blockchains y más de 16,000 tokens, y continúa agregando nuevas redes a través de actualizaciones de la aplicación sin modificar el firmware de la tarjeta. 

Afirmación: "Cualquier problema encontrado en el Firmware de Tangem no puede corregirse."

El riesgo que plantea una vulnerabilidad sin parchear en el firmware inmutable debe sopesarse contra los riesgos introducidos por el propio mecanismo de actualización. Como se ha demostrado a lo largo de este artículo, la cadena de actualización introduce amenazas persistentes.
La pregunta relevante no es si el firmware inmutable está libre de compromisos, sino si la posición de seguridad neta es superior. La evidencia respalda firmemente esa conclusión.

Cronología de auditorías independientes

La transparencia sobre la evaluación de seguridad es esencial para la confianza de los usuarios. El historial completo de auditorías independientes de Tangem prueba nuestro compromiso con evaluaciones futuras.
 

Preguntas frecuentes

¿Qué ocurre si se descubre una vulnerabilidad en el firmware inmutable de Tangem?

Es un escenario muy poco probable. El firmware de Tangem ha sido auditado de forma independiente por dos firmas de seguridad líderes (Kudelski Security y Riscure), lo que reduce significativamente la probabilidad de una falla crítica no detectada.

¿Puede un atacante instalar firmware malicioso en una tarjeta Tangem?

No. El chip del elemento seguro está arquitectónicamente diseñado para rechazar cualquier operación de escritura de firmware después de la instalación inicial en fábrica. No existe ninguna interfaz ni mecanismo para entregar código nuevo. Incluso con posesión física de la tarjeta, un atacante no puede modificar el firmware.

¿Qué es Dark Skippy y afecta a Tangem?

Dark Skippy es un método de ataque basado en firmware divulgado en 2024 que puede extraer la frase semilla completa de una billetera a partir de tan solo dos transacciones firmadas. Funciona reemplazando los nonces aleatorios en el proceso de firma con valores deterministas derivados de la semilla.
Dark Skippy requiere que haya firmware malicioso presente en el dispositivo. El firmware de Tangem es inmutable y no puede ser alterado después de la fabricación, por lo que este vector de ataque no aplica.

¿El firmware inmutable es simplemente una forma de evitar la complejidad de las actualizaciones?

No. Es una decisión deliberada de arquitectura de seguridad que elimina categorías enteras de riesgo: amenazas internas, ingeniería social, coerción regulatoria, ataques a la cadena de suministro y la brecha de auditoría inherente a los lanzamientos frecuentes de firmware.

¿Existen limitaciones en el firmware inmutable?

El principal compromiso es que no se puede agregar nueva funcionalidad al firmware después de la producción. Sin embargo, la mayoría de las mejoras de funciones, el soporte para nuevas blockchains y las mejoras en la experiencia del usuario se entregan a través de la aplicación móvil complementaria de Tangem, que se actualiza regularmente y es completamente de código abierto.

¿Qué significa la certificación EAL6+?

EAL6+ (Nivel de Garantía de Evaluación 6, aumentado) es una de las certificaciones de seguridad más altas disponibles bajo el estándar internacional Common Criteria (ISO/IEC 15408). 
Significa que el chip ha sido verificado de manera semiformal y rigurosamente probado contra ataques físicos y de canal lateral sofisticados. El mismo nivel de certificación es requerido para pasaportes internacionales, documentos de identidad nacionales y sistemas de pago gubernamentales de alta seguridad. Una descripción detallada de la arquitectura de seguridad de Tangem está disponible en la  documentación de características de seguridad.

¿Por qué el firmware de Tangem es de código cerrado si la aplicación es de código abierto?

El firmware corre dentro de un elemento seguro certificado y realiza un conjunto reducido de operaciones criptográficas. La aplicación complementaria, que maneja la funcionalidad orientada al usuario e interactúa con las blockchains, se beneficia de un amplio escrutinio de la comunidad y es completamente de código abierto en GitHub. Este enfoque por capas adapta el método de verificación al perfil de riesgo de cada componente.

Referencias

• Divulgación oficial de Dark Skippy — El artículo de investigación original y las preguntas frecuentes técnicas de los investigadores de seguridad que identificaron el ataque. darkskippy.com
   
• Merkle Science: Análisis de amenazas de Dark Skippy — Análisis técnico detallado del vector de ataque Dark Skippy y sus implicaciones para la seguridad de las billeteras de hardware. www.merklescience.com
   
• Portal Common Criteria (ISO/IEC 15408) — El estándar internacional que rige la certificación de seguridad EAL para componentes de hardware, incluidos los elementos seguros. www.commoncriteriaportal.org
   
• Cointelegraph: El riesgo oculto del firmware actualizable — Reportaje de la industria sobre las implicaciones de seguridad de los mecanismos de actualización de firmware en las billeteras de hardware. cointelegraph.com
   
• CryptoSlate: Cobertura técnica de Dark Skippy — Reportaje técnico sobre el proof-of-concept de Dark Skippy y su cronología de divulgación. cryptoslate.com
   
• Saleem Rashid: Rompiendo el modelo de seguridad de Ledger — Investigación original de 2018 que demuestra el reemplazo de firmware MCU en el Ledger Nano S. saleemrashid.com