Billeteras de hardware de código abierto: por qué importan

Billeteras de hardware de código abierto: por qué importan para la seguridad de Bitcoin

Bitcoin nació del código abierto. Cualquiera puede auditar públicamente el protocolo, su implementación de referencia y las bibliotecas criptográficas de las que depende. En los dispositivos que guardan las claves privadas, las billeteras de hardware, el principio del código abierto no es universal. Algunos fabricantes publican todo, mientras que otros mantienen cerrados componentes críticos. La diferencia importa más de lo que la mayoría de los usuarios cree.

Qué significa «código abierto» en una billetera de hardware

Una billetera de hardware tiene varias capas, y cada una puede ser abierta o cerrada de forma independiente:

Firmware: es el software que se ejecuta en el microcontrolador, en el elemento seguro de la billetera o en ambos. Es la capa más delicada, porque genera claves, guarda la semilla, firma transacciones y controla lo que ves en pantalla. Si el firmware es de código abierto, cualquiera puede leerlo, auditarlo en busca de vulnerabilidades y verificar que el binario que se ejecuta en el dispositivo coincide con el código fuente publicado.

Diseño de hardware: incluye los esquemas, el trazado de la placa de circuito impreso y las especificaciones de los componentes físicos. Si el hardware es abierto, puedes verificar qué chips lleva la placa, cómo se conectan y si el diseño coincide con lo que afirma el fabricante. Con hardware totalmente abierto, un tercero podría fabricar por su cuenta un dispositivo idéntico en teoría.

Aplicaciones complementarias: son el software para computadora o dispositivo móvil con el que manejas la billetera de hardware. Algunos ejemplos son Ledger Wallet, antes Ledger Live, Trezor Suite y la integración con Sparrow Wallet. Estas aplicaciones generan las direcciones que ves, preparan las transacciones y se comunican con la red de Bitcoin. Si son de código abierto, puedes verificar que el software no filtre datos ni sustituya direcciones.

Una billetera puede tener una capa abierta y otra cerrada. Saber qué capas son de código abierto es esencial para evaluar el modelo de confianza real. La lección Cómo funcionan las billeteras de hardware da una visión más amplia de cómo interactúan estas capas.

Niveles de acceso al código y al diseño

Totalmente abierto (firmware y hardware): el código fuente del firmware y los esquemas del hardware son públicos. Cualquiera puede auditar el código del propio dispositivo y el diseño de sus circuitos. Los fabricantes de los chips de la placa, como el elemento seguro, mantienen cerrado el diseño interno de esos chips. Algunos ejemplos son Blockstream Jade, SeedSigner y Passport Core de Foundation, que ya no se vende. Es el máximo nivel de transparencia. En teoría, se puede fabricar el dispositivo a partir de los diseños publicados, lo que elimina la dependencia de un único proveedor.

Publicado con restricciones: el código está publicado y se puede auditar, pero la licencia limita lo que puedes hacer con él. El ejemplo principal es Coldcard. Coinkite publica todo el código fuente del firmware, además de los esquemas y las listas de piezas de la Mk4, la Mk5 y la Q. La licencia MIT con una «Commons Clause» que impide venderlo hace que sea código fuente disponible, aunque no de código abierto en sentido estricto. Cualquiera puede leerlo y compilarlo.

Código cerrado: el fabricante no publica el firmware de los componentes críticos para la seguridad. El ejemplo principal es Ledger, cuyo elemento seguro ejecuta firmware propietario. Los usuarios confían en el fabricante y en certificaciones externas, como las calificaciones Common Criteria EAL5+ o EAL6+ de los chips de Ledger, ya que no pueden comprobar el código por su cuenta.

Por qué el código abierto importa para la seguridad

Auditorías de la comunidad

El firmware de código abierto lo revisan personas que no trabajan para el fabricante. Investigadores de seguridad independientes, desarrolladores de billeteras competidoras y usuarios de Bitcoin muy desconfiados examinan el código. Con revisores tan distintos se detectan problemas que los equipos internos pasan por alto. No es por falta de competencia, sino porque esos equipos parten de las mismas premisas y comparten puntos ciegos. Quienes revisan desde fuera aportan otras perspectivas, otros modelos de amenazas y otras motivaciones.

El núcleo de Linux, OpenSSL y el propio Bitcoin Core se han beneficiado mucho de estas revisiones. Algunos errores que duraron años en software de código cerrado se detectaron enseguida cuando el código se abrió a revisión pública. El firmware de una billetera de hardware es mucho menos complejo que un sistema operativo, así que una revisión exhaustiva por la comunidad es viable.

Sin puertas traseras ocultas

Con firmware de código abierto, cualquier puerta trasera que introduzca el fabricante queda a la vista en el código. Ledger Recover (2023) mostró por qué importa. Es un servicio de pago opcional. Si te registras y lo autorizas en el dispositivo, el servicio cifra tu semilla y la reparte entre tres empresas. Los críticos afirmaron que demostraba que se podía actualizar el firmware de Ledger para exportar una semilla. Ledger respondió que hay que inscribirse y que requiere tu PIN y tu aprobación. En principio, el firmware de cualquier billetera de hardware podría cambiarse para exportar una semilla. Lo que cambia es lo que puedes comprobar. El sistema operativo de Ledger es cerrado, así que la gente de fuera no podía leer cómo funciona la función. Con firmware de código abierto, un cambio así sería visible en el código de cada actualización.

Las billeteras de código abierto siguen expuestas a ataques en la cadena de suministro y a compilaciones manipuladas. Publicar el código permite detectar esos problemas de una forma que el modelo de código cerrado no ofrece.

Compilaciones verificables

El código abierto permite las compilaciones reproducibles. Con ellas, es posible compilar el código publicado y verificar que el binario resultante coincide exactamente con el que entrega el fabricante en el dispositivo. Sin compilaciones reproducibles, el fabricante podría publicar un código fuente limpio y distribuir binarios modificados. Estas compilaciones cierran esa brecha y son un complemento esencial a la publicación del código abierto. Más abajo se trata este punto con más detalle.

El principio «confía, pero verifica» en Bitcoin

La cultura de Bitcoin se apoya en la verificación. Al operar un nodo completo, verificas la blockchain por tu cuenta sin depender de un tercero. Al comprobar las firmas de una transacción, verificas la propiedad sin depender de lo que diga el remitente. El mismo principio se aplica a las billeteras de hardware. Si puedes verificar el código que protege tus claves, hazlo. Si no puedes, dependes de la confianza, con independencia de las certificaciones o la reputación del fabricante.

Las billeteras de código cerrado pueden ser seguras. Su modelo de confianza depende de la integridad del fabricante y de los auditores externos, en lugar de la verificación directa. Si tienes una cantidad importante de bitcoins, es esencial saber qué modelo de confianza se aplica a tu dispositivo. El artículo sobre autocustodia de Bitcoin (en inglés) analiza cómo esas decisiones afectan a la seguridad general.

Panorama actual de las billeteras de hardware de código abierto

Trezor (Safe 3, Safe 5)

Trezor abrió el mercado de billeteras de hardware en 2014 y usa código abierto desde el principio. El firmware de todos sus dispositivos está publicado en GitHub y se ha revisado a fondo. Los diseños y esquemas de hardware también son públicos. Safe 3 y Safe 5 incorporaron un elemento seguro Infineon Optiga Trust M. El chip es cerrado, pero todo el código de Trezor que se comunica con él es abierto, lo que demuestra que se puede integrar un elemento seguro sin cerrar el código de la billetera. Safe 7 incorpora un segundo chip, TROPIC01, que Trezor presenta como un elemento seguro que se puede auditar de forma independiente. Trezor Suite, la aplicación complementaria, también publica su código fuente bajo la licencia de referencia de Trezor, que permite leerlo, pero impide redistribuirlo.

Coldcard Mk5 y Q

La línea Coldcard de Coinkite ejecuta firmware cuyo código fuente completo está publicado en GitHub. Se basa en MicroPython y se ejecuta en un microcontrolador STM32. La licencia MIT con una «Commons Clause» impide vender el código, por lo que es código fuente disponible y no código abierto en sentido estricto. El firmware se encarga de todas las operaciones del usuario, mientras dos elementos seguros de distintos proveedores (Microchip ATECC608 y Maxim DS28C36B) protegen la semilla y aplican el PIN. Coinkite publica en el mismo repositorio los esquemas y las listas de piezas de la Mk4, la Mk5 y la Q. La Mk5 sustituyó a la Mk4 en marzo de 2026, y la Coldcard Q, con teclado QWERTY y pantalla más grande, comparte la misma base de firmware. El código público no evitó el fallo de generación de semillas de julio de 2026 (véase el aviso sobre Coldcard (en inglés)), pero permitió que investigadores externos lo analizaran. La configuración se trata en la guía de configuración de Coldcard (en inglés).

Blockstream Jade y Jade Plus

Tanto el firmware como el hardware de Jade son abiertos. Blockstream publica el firmware con licencias de código abierto y los archivos de diseño del hardware de ambos modelos en GitHub. Jade usa un «elemento seguro virtual». En vez de un chip dedicado, usa un protocolo de oráculo ciego. Al desbloquear con el PIN, el dispositivo contacta con un servidor de Blockstream o con uno que alojes tú, a través de la aplicación complementaria. Ni el dispositivo ni el servidor pueden desbloquear las claves por sí solos. Es una solución creativa que evita los problemas de los acuerdos de confidencialidad de los chips tradicionales, aunque normalmente necesita ese servidor para desbloquear el dispositivo. Los dos modelos tienen cámara para operar aislados de la red mediante códigos QR. Jade Plus (enero de 2025) añade una pantalla más grande y una cámara mejor.

Foundation Passport Core (ya no se vende)

Foundation Devices construyó Passport con un compromiso explícito con la transparencia. El firmware se publica con GPLv3, aunque algunas partes usan MIT u otras licencias compatibles. Los diseños de los circuitos se publican con CERN-OHL-S v2, una licencia de hardware abierto con copyleft que exige compartir los cambios con las mismas condiciones. Passport lleva un elemento seguro Microchip ATECC608. El firmware que se comunica con ese elemento es de código abierto. El dispositivo usa un procesador STM32H7 e incluye una cámara para operar aislado de la red mediante códigos QR. Foundation también publica documentación sobre su modelo de seguridad y su análisis de amenazas. En marzo de 2026, Foundation anunció que había retirado Passport Core y afirma que seguirá recibiendo actualizaciones de seguridad. Ahora vende Passport Prime, que no hemos analizado.

BitBox02

BitBox02, de Shift Crypto, que opera como BitBox, tiene firmware y hardware de código abierto. El firmware está escrito en C y Rust, se publica en GitHub con licencia Apache 2.0 y ha pasado una auditoría independiente. BitBox identifica a Census Labs como auditor. Los esquemas del hardware son públicos. BitBox02 usa un elemento seguro Microchip ATECC608B para la atestación y la derivación de claves adicionales. La aplicación complementaria, BitBoxApp, también es de código abierto. La edición solo para Bitcoin elimina por completo la compatibilidad con altcoins, lo que reduce la superficie de ataque.

SeedSigner

SeedSigner es un proyecto que puedes montar por completo tú mismo. Es un dispositivo de firma de Bitcoin sin estado hecho con componentes comunes: Raspberry Pi Zero, un módulo de cámara y una pantalla LCD. Todo el software es de código abierto. Los usuarios montan el dispositivo por su cuenta a partir de las instrucciones y el código publicados. No hay «fabricante». SeedSigner no guarda claves. En cada sesión, el dispositivo genera o importa las claves y firma las PSBT mediante códigos QR. Es el ejemplo más transparente, porque tú montas el hardware, compilas el software y lo verificas todo. A cambio, es menos fácil de usar y carece de elemento seguro.

Tabla comparativa

Billetera	Firmware de código abierto	Hardware abierto	Compilaciones reproducibles	Auditorías de seguridad independientes
Trezor Safe 3 / Safe 5	Sí	Sí	Sí	Varias, incluida la original de Kudelski
Coldcard Mk5 / Q	Código fuente disponible (MIT + Commons Clause)	Esquemas y listas de piezas	Sí	Revisión de la comunidad y avisos de la NVD
Blockstream Jade / Jade Plus	Sí	Sí	Sí	Revisión de la comunidad e informe de un fallo de DARKNAVY (corregido en 2025)
Foundation Passport Core (ya no se vende)	Sí (GPLv3)	Sí (CERN-OHL-S v2)	Sí	Revisión de la comunidad
BitBox02	Sí	Esquemas y lista de piezas	Sí	Census Labs
SeedSigner	Sí	No aplica (componentes comunes)	Sí	Revisión de la comunidad
Ledger (Nano, Stax, Flex)	No (firmware del elemento seguro)	No	No	Certificación CC EAL5+ / EAL6+ del chip y equipo interno Donjon de Ledger

Ejemplos de código cerrado y en quién tienes que confiar

Ledger es el ejemplo dominante del enfoque de código cerrado. El argumento a favor de cerrar el firmware del elemento seguro es que la seguridad del chip depende en parte de ocultar su funcionamiento interno. Según este argumento, publicar el firmware daría a un atacante un mapa detallado para diseñar ataques de canal lateral o de inyección de fallos.

El argumento tiene cierto fundamento técnico. Los elementos seguros están diseñados para resistir tipos de ataque conocidos. Ocultar cómo se implementan las contramedidas añade dificultad. Aun así, la seguridad por oscuridad solo complementa las defensas principales. Las operaciones criptográficas en sí no se benefician del secreto y la gestión de claves, es decir, cómo se generan, guardan y exportan las semillas, debería poder auditarse en cualquier caso. El debate sobre Ledger Recover mostró por qué. Cuando Ledger anunció un servicio opcional que puede exportar una copia cifrada de la semilla, los usuarios tuvieron que confiar en la explicación de Ledger sobre su funcionamiento, porque no podían leer el código del elemento seguro. Estos ataques se tratan con más detalle en el artículo sobre riesgos de ataques de canal lateral en hardware de criptomonedas (en inglés).

Cómo funcionan las compilaciones reproducibles

El código abierto por sí solo no permite verificarlo todo. El último eslabón son las compilaciones reproducibles, que permiten que cualquiera compile el código fuente y obtenga un binario idéntico, byte a byte, al que distribuye el fabricante.

Sin compilaciones reproducibles, el fabricante podría publicar código fuente impecable en GitHub y entregar los dispositivos con binarios distintos, quizá manipulados. Las compilaciones reproducibles cierran esa brecha para los archivos que distribuye el fabricante. Si un usuario o investigador compila el código y obtiene un binario cuyo hash coincide con el del archivo de firmware oficial, tiene evidencia sólida de que la versión oficial se compiló a partir del código publicado. Saber si el dispositivo que tienes ejecuta esa versión exige una comprobación aparte. El dispositivo verifica la firma y, en algunos modelos, también se puede comprobar el hash del firmware (el proceso se explica más abajo, en las preguntas frecuentes).

Lograr compilaciones reproducibles es complicado. Hay que controlar con precisión los compiladores, los ajustes del enlazador, las versiones de las bibliotecas y el entorno de compilación. Varios proyectos ya lo consiguen:

• Trezor ofrece compilaciones reproducibles mediante contenedores Docker con versiones fijas de las herramientas de compilación.
• BitBox02 publica instrucciones de compilación reproducible y entornos Docker.
• Coldcard automatiza su compilación reproducible con Docker e indica si el resultado coincide byte a byte con la versión oficial.
• Blockstream Jade admite compilaciones reproducibles con entornos de compilación documentados.
• SeedSigner publica imágenes de versiones reproducibles desde la versión 0.7.0.
• Foundation Passport ofrece una compilación con Docker y un comando para comparar el hash del firmware con el publicado.

Si un proyecto de billetera de hardware se presenta como de código abierto, pero carece de compilaciones reproducibles, hay una brecha de verificación. Poder auditar el código fuente tiene valor, pero el vínculo entre ese código y el firmware del dispositivo depende de la confianza. Cómo encajan las compilaciones reproducibles en el proceso de actualización se trata en el artículo sobre actualizaciones de firmware y seguridad (en inglés).

Impacto real: vulnerabilidades detectadas gracias al código abierto

El valor del firmware de código abierto no es teórico. Investigadores de la comunidad han descubierto varias vulnerabilidades importantes porque el código estaba disponible para su revisión:

Vulnerabilidad del microcontrolador de Trezor (divulgada en enero de 2020): investigadores de Kraken Security Labs mostraron un ataque de perturbación de voltaje contra el microcontrolador STM32 de Trezor One y Model T que permitía extraer la semilla cifrada en unos 15 minutos de acceso físico. Primero informaron a Trezor de forma responsable. En los dispositivos existentes, no se podía corregir con software porque la vulnerabilidad del chip era una limitación del hardware, así que Trezor indicó que una passphrase BIP39 mitigaba el problema. Los modelos Safe más recientes protegen el PIN y los secretos con un chip seguro, así que perturbar el chip principal de un dispositivo bloqueado ya no revela la semilla. El chip principal sigue siendo susceptible a esas perturbaciones. En marzo de 2025, Donjon, el equipo de seguridad de Ledger, usó esa técnica para saltarse la comprobación de firmware de Safe 3. Esto importa si alguien manipula el dispositivo antes de que te llegue. Compra en la tienda del fabricante.

Comprobación del cambio multisig de Coldcard (corregida en diciembre de 2019): Dmitry Petukhov, un desarrollador que integraba Coldcard en su propio software, descubrió que el firmware no leía los scripts multisig con suficiente rigor. Un atacante intermediario, como malware en la computadora que prepara la transacción, podía hacer pasar una salida bajo su control por tu propio cambio y quedarse con ella si usabas multisig. Coinkite corrigió el fallo en el firmware 3.0.6, añadió las direcciones de cambio a la pantalla de confirmación como comprobación adicional e informó de que no había indicios de explotación. Cuando los detalles se hicieron públicos en marzo de 2020, el informe de Petukhov citó las líneas exactas del código multisig público que omitían la comprobación.

Implementación de anti-klepto en BitBox02: BitBox02 y, por separado, Blockstream Jade implementaron el protocolo anti-klepto o «anti-exfil» para impedir que el dispositivo filtre material de claves al sesgar la generación de nonces (el tipo de ataque conocido como Dark Skippy (en inglés)). Como la implementación era abierta, los investigadores pudieron verificar que el protocolo estaba bien implementado y que el dispositivo resistía este tipo de filtración mediante nonces.

Estos ejemplos muestran un patrón. Puede haber vulnerabilidades en el código abierto, pero su publicación permite encontrarlas y corregirlas antes de que se exploten. El firmware de código cerrado puede tener vulnerabilidades equivalentes o peores que siguen sin descubrirse porque nadie de fuera de la empresa puede leer el código.

El futuro de las billeteras de hardware de código abierto

El sector avanza hacia un código cada vez más abierto. Varios avances muestran esa dirección:

Elementos seguros compatibles con código abierto: el argumento de que los elementos seguros exigen firmware cerrado pierde fuerza. La integración de Optiga Trust M en Trezor, el elemento seguro virtual de Jade y el uso de código abierto de Foundation para comunicarse con el chip muestran vías viables para proteger el hardware sin ocultar el código. A medida que haya más chips diseñados para integrarse con código abierto, el argumento de los acuerdos de confidencialidad perderá la fuerza que le queda.

Compilaciones reproducibles como norma: hace unos años, las compilaciones reproducibles eran una aspiración. Hoy varios proyectos las consiguen y cada vez más usuarios cuentan con ellas. Las herramientas de compilación reproducible (Docker, Nix, Guix) están madurando, lo que facilita que los proyectos nuevos las adopten.

Dispositivos caseros y comunitarios: proyectos como SeedSigner han demostrado que se puede construir un dispositivo funcional de firma de Bitcoin con hardware corriente y software totalmente abierto. Los dispositivos caseros carecen del acabado y de la protección del elemento seguro de los comerciales, pero demuestran que se puede firmar en Bitcoin sin depender de la confianza en un proveedor. Esto sirve de contrapeso a los fabricantes comerciales. Si se vuelven demasiado opacos, los usuarios tienen alternativas.

Más conocimientos de seguridad en la comunidad de Bitcoin: los usuarios entienden cada vez mejor los riesgos de la cadena de suministro, los modelos de confianza del firmware y los límites del código cerrado. Esa presión del mercado empuja a los fabricantes hacia la transparencia. El anuncio de un plan de Ledger para publicar su código, por lento que avance, fue una respuesta directa a lo que pedía la comunidad tras la polémica de Recover.

Al evaluar tu forma de custodia, que la billetera de hardware que elijas sea de código abierto es un factor entre varios, junto con la seguridad física, la facilidad de uso, la compatibilidad con multisig y el historial del fabricante. Pero conviene darle importancia, porque determina si tu seguridad se basa en verificar o en confiar. Usar hardware de varios proveedores (en inglés) en una configuración multisig puede reducir la dependencia del modelo de confianza de un único fabricante, sea abierto o cerrado.

Preguntas frecuentes

¿El código abierto permite que cualquiera hackee la billetera?

No. Publicar el código fuente no reduce la seguridad del dispositivo. La seguridad criptográfica de una billetera de hardware depende de la solidez de sus algoritmos y de la gestión de claves, al margen del secreto del código. AES, SHA-256 y la criptografía de curva elíptica son públicos y su seguridad procede de sus propiedades matemáticas. Con código abierto, cualquiera puede buscar vulnerabilidades, así que se descubren y corrigen más deprisa. El código cerrado tiene tantos errores como el abierto, pero se tarda más en encontrarlos y puede que los atacantes los descubran antes que los defensores.

¿Un SeedSigner que monte yo es tan seguro como una billetera comercial?

Depende de tu modelo de amenazas. SeedSigner carece de elemento seguro, así que es más vulnerable a ataques de extracción física si alguien accede al dispositivo mientras las claves están cargadas. Aun así, SeedSigner está diseñado para funcionar sin estado. El dispositivo no guarda las claves entre sesiones. Para extraerlas, un atacante necesitaría acceso físico durante el breve intervalo en que el dispositivo está encendido y las claves están cargadas en la RAM. Si priorizas la posibilidad de verificar y afrontas poco riesgo de robo físico, SeedSigner puede formar parte de una configuración segura, sobre todo como una de las claves de una configuración multisig.

¿Por qué algunos fabricantes mantienen cerrado el diseño del hardware aunque abran el firmware?

Abrir el hardware tiene implicaciones económicas distintas de abrir el software. Publicar los esquemas completos y el trazado de la placa de circuito impreso facilita que los competidores, sobre todo los fabricantes de bajo costo, hagan clones. Algunas empresas mantienen parcialmente cerrado el diseño para proteger su negocio y abren el firmware para que se pueda auditar su seguridad. Es un compromiso pragmático. El firmware contiene la lógica más delicada para la seguridad, así que abrirlo aporta la mayor parte del beneficio para la auditoría. Proyectos con hardware totalmente abierto, como Blockstream Jade y Passport Core de Foundation, aceptan el riesgo de que los clonen a cambio de una transparencia total.

¿Cómo verifico que mi billetera de hardware ejecuta el firmware que dice ejecutar?

Si tu billetera ofrece compilaciones reproducibles, descarga el código fuente, prepara el entorno de compilación, que suele ser un contenedor Docker que ofrece el proyecto, compila el código y compara el hash del binario resultante con el del archivo oficial del firmware. Deja aparte la firma del fabricante según las instrucciones del proyecto. Si los hashes coinciden, el firmware oficial corresponde exactamente al código fuente. El dispositivo comprueba la firma del fabricante en cada actualización. Algunos dispositivos también permiten comprobar el firmware que están ejecutando. Trezor Suite comprueba el hash del firmware cada vez que conectas un Trezor con el firmware más reciente, y BitBox02 puede mostrar su hash de firmware al arrancar. Si tu billetera carece de compilaciones reproducibles, dependes de la confianza en la firma del fabricante para la actualización. El proceso para varios dispositivos conocidos se trata en la guía sobre actualizaciones de firmware y prácticas de seguridad (en inglés).