El fallo de entropía de Coldcard y casi 90 millones de dólares en pérdidas: una seria advertencia sobre un hardware considerado «absolutamente seguro»

El 30 de julio apareció en la cadena de Bitcoin una serie de transferencias muy poco habituales.

La primera ronda de vaciado que llamó la atención duró solo 41 minutos. Durante ese periodo se movieron 1.082,65 BTC desde 1.196 direcciones. Posteriormente, Galaxy Research identificó otras dos rondas de actividad aparentemente relacionada. Para el 2 de agosto, las tres rondas sumaban aproximadamente 1.367,05 BTC, valorados en cerca de 88,6 millones de dólares al precio de ese momento, y afectaban a 4.585 direcciones.

Estas cifras pueden contrastarse con las actualizaciones públicas de Galaxy Research, el seguimiento on-chain de CoinDesk y el análisis técnico publicado por The Hacker News.

Las carteras compartían un elemento importante: se considera que sus semillas habían sido generadas por carteras de hardware Coldcard de Coinkite.

Muchos de los dispositivos afectados llevaban años sin conectarse a Internet y sus frases de recuperación nunca habían sido subidas a la nube. El problema se produjo mucho antes. Cuando se crearon esas carteras, los dispositivos no utilizaron el generador de números aleatorios verdaderos por hardware como estaba previsto. El atacante no necesitaba robar la frase semilla: le bastaba con calcular las frases que podían haberse generado y buscar después en la blockchain las direcciones correspondientes.

Este tipo de fallo es uno de los más difíciles de mitigar en una cartera de hardware. El dispositivo puede permanecer guardado en un cajón y la clave privada puede no haber salido nunca de él. Pero si la clave privada no tuvo suficiente aleatoriedad desde el principio, protecciones posteriores como el aislamiento físico, los elementos seguros o los mecanismos antimanipulación dejan de ser eficaces.

Límites de las fuentes y de las conclusiones

Fuentes primarias de verificación: COLDCARD Mk3 Seed Generation Warning; Version History; BIP-0039: Mnemonic code for generating deterministic keys.

Los hechos verificables de este artículo sobre el fallo de baja entropía de COLDCARD, el firmware afectado y la migración segura se basan en las fuentes oficiales o regulatorias citadas. El estado real del servicio, las tarifas, los requisitos de elegibilidad y la disponibilidad regional deben confirmarse en las páginas vigentes del emisor o de la plataforma al momento de solicitar el producto.

Toda migración de activos debe realizarse en un dispositivo de confianza y verificando directamente la dirección de destino. Cualquier cifra de pérdidas debe distinguir entre confirmaciones oficiales y análisis de terceros. Las experiencias de usuario, tasas de éxito, comparaciones de costes o conclusiones sobre tendencias que no hayan sido divulgadas directamente en las fuentes primarias anteriores son análisis o inferencias, y no han sido confirmadas oficialmente para casos concretos por las entidades implicadas.

Qué se ha confirmado hasta ahora

Coinkite, desarrollador de Coldcard, ha reconocido que parte del firmware publicado entre 2021 y julio de 2026 presentaba un problema de baja entropía. La empresa pidió a los usuarios afectados que generaran nuevas semillas y trasladaran los fondos a nuevas direcciones. Las versiones corregidas indicadas en el aviso de seguridad de Coinkite incluyen Mk2/Mk3 4.2.0, Mk4/Mk5 estándar 5.6.0, Q estándar 1.5.0Q y las versiones de la rama Edge 6.6.0X y 6.6.0QX.

El equipo de ingeniería y seguridad de Bitcoin de Block también realizó un análisis independiente. Su informe técnico situó el problema en la cadena de llamadas del generador aleatorio. Al generar una semilla, la cartera debía utilizar el generador de números aleatorios por hardware del chip STM32, pero en realidad terminaba utilizando Yasmarang, un generador pseudoaleatorio por software incluido en MicroPython.

Tanto el fallo del firmware como los vaciados on-chain existen realmente, pero la atribución entre ambos todavía no está completamente cerrada. Galaxy identificó las transacciones relacionadas basándose en patrones de comisiones, manejo del cambio, estructuras de transferencias por lotes y rutas de derivación. Hasta ahora no se ha publicado un informe que muestre de principio a fin la reconstrucción de la semilla débil de una víctima concreta y su correspondencia exacta con una dirección vaciada.

Por tanto, la formulación más precisa es la siguiente: los investigadores detectaron un fallo de firmware de Coldcard capaz de reducir la generación de claves privadas a un espacio suficientemente pequeño como para ser enumerado offline y, al mismo tiempo, observaron varias rondas de vaciado de fondos altamente sospechosas, muy alineadas temporalmente y en su comportamiento. Afirmar directamente que los 1.367,05 BTC fueron «robados de forma confirmada mediante este fallo» va más allá de lo que permiten las pruebas actuales.

El bug estaba oculto en la cadena de llamadas del generador aleatorio

Coldcard disponía originalmente de código que leía directamente el RNG por hardware del STM32. La interfaz Python correspondiente era ckcc.rng_bytes().

En 2021, al migrar código relacionado con curvas elípticas e introducir libNgU, Coldcard cambió la interfaz de aleatoriedad usada al crear nuevas carteras por ngu.random.bytes(). Ahí entró el problema en el firmware.

En la configuración de producción, MICROPY_HW_ENABLE_RNG estaba definido como 0. Los desarrolladores lo hicieron porque Coldcard ya disponía de su propio envoltorio para el RNG por hardware y no necesitaba otro proporcionado por MicroPython. Sin embargo, la comprobación de libNgU utilizaba #ifndef: solo verificaba si la macro estaba definida, no si su valor era distinto de cero.

El código compilaba y el dispositivo arrancaba con normalidad. Sin embargo, durante el enlace final, rng_get() no resolvía hacia la implementación por hardware esperada por Coldcard, sino hacia la rutina de respaldo Yasmarang de MicroPython. El código y los commits correspondientes pueden consultarse en el repositorio del firmware de Coldcard, mientras que el informe de Block reconstruye la cadena completa de llamadas.

Yasmarang genera números que pueden parecer desordenados, pero no es un generador de números aleatorios criptográficamente seguro diseñado para claves maestras de cartera. Su estado inicial se deriva principalmente de los 32 bits inferiores del UID del chip, el temporizador SysTick y los registros de tiempo RTC.

El UID del chip es simplemente un identificador del dispositivo, no un secreto. El estado del temporizador tampoco equivale a ruido físico, y además estas entradas pueden estar correlacionadas. Una vez inicializado, el generador no sigue incorporando nueva aleatoriedad. Si se consigue acotar el estado del dispositivo, la hora de arranque y el número de llamadas anteriores, las salidas posteriores pueden reproducirse en otro ordenador.

El firmware aplica posteriormente un hash al resultado, pero eso no soluciona el problema. Diez mil entradas posibles siguen produciendo solo diez mil salidas posibles después de SHA-256. El resultado puede parecer más uniforme, pero el espacio de búsqueda no se amplía. La suma de comprobación de BIP-39 solo valida el formato; no aumenta la entropía real de la frase semilla.

40 bits frente a 72 bits: ¿qué diferencia hay?

La especificación BIP-39 exige una entropía inicial de entre 128 y 256 bits. Una frase habitual de 12 palabras corresponde a 128 bits, mientras que una de 24 palabras corresponde a 256 bits.

La estimación preliminar de Coinkite para el firmware antiguo sitúa el espacio efectivo de búsqueda de las semillas de Mk2/Mk3 en unos 40 bits, y el de Mk4/Mk5/Q en unos 72 bits.

Un espacio de 40 bits contiene aproximadamente 1,1 billones de candidatos. Puede parecer mucho, pero no está ni de lejos en la misma escala que 128 bits. La diferencia entre ambos espacios es de aproximadamente 2^88. Si el atacante puede reducir aún más el rango utilizando el modelo del dispositivo, el UID del chip, el momento de arranque o rutas de derivación habituales, la enumeración offline deja de ser una cuestión puramente teórica.

Los modelos posteriores incorporaban una capa adicional. Al arrancar, Mk4 mezcla un valor aleatorio proporcionado por el elemento seguro. Sin embargo, después de aplicar hash al resultado, el código conserva solo 4 bytes y utiliza esos 32 bits para sustituir una palabra de estado de Yasmarang. Block concluyó que, si el resto del estado y el historial de llamadas son conocidos, el elemento seguro distingue como máximo 2^32 flujos de salida. Incluso aplicando un límite superior generoso al estado desconocido del temporizador, el espacio de candidatos queda por debajo de 2^73.3.

No sería correcto resumir esto simplemente como «Mk4 tiene 72 bits de seguridad». El propio Block advierte que 2^73.3 es un límite superior relativamente amplio del espacio de candidatos, no 73 bits de seguridad criptográfica en sentido estricto. El coste real de ataque depende de la información disponible sobre el UID, el momento de arranque, el número de llamadas anteriores, la derivación de direcciones y la velocidad de verificación. Actualmente no existe un benchmark público y completo de cracking.

Lo que sí puede afirmarse es que los modelos posteriores están en mejor situación que Mk2/Mk3, pero aun así no alcanzan el objetivo original de 128 bits de Coldcard. Por ese motivo, Coinkite también exige a esos usuarios reemplazar sus semillas.

Lo afectado es la semilla, no solo el dispositivo

El error más común al revisar el riesgo es fijarse únicamente en el firmware que tiene instalado el dispositivo en este momento.

Lo que realmente determina el riesgo es qué versión generó originalmente la frase semilla. Actualizar hoy un Mk3 a 4.2.0 no añade retroactivamente aleatoriedad a una frase creada hace cinco años. Importar esa misma frase en Ledger, Trezor o una cartera de software tampoco sirve: la debilidad ya está incorporada en la propia semilla.

Hay además un detalle importante de versionado. Las versiones estándar y Edge pertenecen a ramas de publicación diferentes. No puede asumirse que una versión antigua de Edge esté corregida solo porque su número sea superior a 5.6.0. El alcance exacto debe comprobarse en el último aviso de Coinkite y en el historial oficial de versiones.

Coinkite afirma que TAPSIGNER, OPENDIME y SATSCARD utilizan bases de código distintas y no se ven afectados por este fallo.

Si la cartera nunca estuvo conectada, ¿cómo pudo el atacante mover los fondos?

Una cartera de hardware almacena las claves privadas y firma las transacciones. Si la aleatoriedad es correcta, obtener remotamente la clave privada es realmente muy difícil.

Esta vía de ataque evitó por completo el dispositivo. El atacante podía enumerar estados aleatorios posibles en su propio ordenador, generar frases semilla candidatas, derivar las claves públicas extendidas y las direcciones habituales, y después consultar la blockchain pública de Bitcoin para comprobar si esas direcciones tenían saldo.

Una vez encontrada una coincidencia, la clave privada calculada por el atacante es idéntica a la de la cartera. Puede firmar y difundir una transacción por su cuenta, sin conectar el dispositivo original y sin conocer el PIN. Por eso, afirmar que «el dispositivo nunca estuvo conectado» no descarta este tipo de ataque: la búsqueda de claves candidatas puede realizarse completamente offline.

Las monedas que llevan mucho tiempo sin moverse tampoco son seguras por ese motivo. El riesgo de una semilla débil no desaparece con el tiempo. A medida que la investigación se hace pública y disminuye el coste de cálculo, una búsqueda antes poco rentable puede convertirse en una oportunidad económica. Las direcciones inactivas con saldos elevados pueden incluso resultar más atractivas para un atacante.

Cómo interpretar las 4.585 direcciones observadas on-chain

Los principales datos recopilados por Galaxy Research hasta el 2 de agosto son los siguientes:

Las dos primeras rondas utilizaron patrones de comisiones fijas y procesamiento por lotes similares. Podrían proceder del mismo operador o simplemente haber utilizado las mismas herramientas. La tercera ronda cambió las direcciones de consolidación y la estructura de las salidas. Galaxy no atribuyó las tres rondas al mismo atacante porque la información on-chain no permite sostener esa conclusión.

El número de direcciones tampoco puede convertirse directamente en número de víctimas. Una persona puede controlar varias direcciones, y una misma frase semilla puede derivar numerosas direcciones de recepción. A la inversa, si los investigadores solo rastrearon rutas de derivación predeterminadas, podrían haber pasado por alto otros fondos de la misma cartera.

La atribución on-chain tiene además una limitación natural: cuando el propietario de la cartera mueve voluntariamente sus fondos, el patrón de transacción puede parecerse a un vaciado realizado por un atacante. El modelo de Galaxy se basa en huellas de transacción, rutas de derivación y reportes de víctimas; no existe una etiqueta de «robo» que pueda leerse directamente en la blockchain. Por ello, es más preciso describir los 1.367,05 BTC como «volumen observado aparentemente relacionado».

El código llevaba cinco años abierto: ¿por qué nadie lo detectó?

El firmware de Coldcard siempre ha sido público y la implementación del generador aleatorio por hardware estaba efectivamente presente. Las auditorías anteriores podían ver el código TRNG, pero no confirmaron que la creación de nuevas carteras terminara utilizando realmente esa implementación.

El bug atravesaba varias capas: la función de generación de cartera cambió de interfaz, la comprobación de macros de compilación en libNgU era incompleta y MicroPython proporcionaba un fallback por software con una función equivalente. Cada pieza, vista por separado, parecía poco llamativa. El programa compilaba, el dispositivo funcionaba con normalidad y la salida no se repetía de forma evidente. El problema solo aparece al seguir la resolución de símbolos y la ruta de llamada final en la compilación real.

Las pruebas aleatorias convencionales tampoco necesariamente lo habrían detectado. Un PRNG no criptográfico puede generar datos con una distribución uniforme y sin repeticiones visibles entre valores consecutivos. El problema no es que «parezca poco aleatorio», sino que su estado interno puede deducirse.

El hotfix de Coinkite añadió una comprobación de símbolos RNG durante la compilación. Si la implementación incorrecta vuelve a entrar en el firmware, la compilación falla directamente. El análisis técnico oficial también reconoce que las revisiones anteriores verificaban que el TRNG esperado existiera, pero no confirmaban a qué implementación resolvía finalmente la ruta usada para generar carteras.

El código abierto sigue siendo útil. La razón por la que el fallo pudo localizarse rápidamente y los commits históricos pudieron revisarse fue precisamente que el código estaba disponible. Pero «cualquiera puede auditarlo» no equivale a «alguien ya ha auditado todas las rutas críticas de seguridad». En una cartera de hardware, las compilaciones reproducibles son solo el punto de partida. Las cadenas de llamadas relacionadas con semillas, firmas y copias de seguridad también requieren validación de extremo a extremo.

La multifirma puede reducir el riesgo, pero depende de cómo se generaron las claves

En una configuración multifirma 2-de-3, recuperar una única clave privada débil no basta para mover los fondos. El atacante necesita todavía una segunda clave de firma. Si las otras claves fueron generadas por fabricantes distintos, bases de código diferentes y fuentes de aleatoriedad independientes, la multifirma puede proteger frente a un fallo sistémico de un único proveedor.

Pero agrupar tres Coldcard afectadas en una configuración multifirma no resuelve automáticamente el problema. Si el atacante puede recuperar suficientes claves débiles para alcanzar el umbral de firma, los fondos siguen siendo vulnerables. El informe de Block lo expresa de forma clara: debe haber suficientes dispositivos seguros dentro del conjunto que forma el umbral de firma.

Para un usuario normal, una configuración multifirma más compleja tampoco es necesariamente mejor. La pérdida de descriptores, rutas de derivación, huellas de dispositivos o copias de seguridad puede hacer fracasar la recuperación. Si nunca se ha realizado un ensayo completo de recuperación y simplemente se han conectado varios dispositivos siguiendo un tutorial, el riesgo operativo puede no ser menor que en una cartera de firma única.

Cómo migrar ahora

Si tu semilla fue generada con una de las versiones de firmware indicadas en la tabla anterior y en ese momento no añadiste suficiente entropía independiente mediante dados ni utilizaste una passphrase BIP-39 fuerte y única, debes considerarla una semilla antigua con riesgo.

Descarga primero desde la página oficial de Coldcard el firmware corregido correspondiente a tu modelo y rama de publicación y verifica la versión en la pantalla del dispositivo. Después genera una frase semilla completamente nueva y anota y verifica cuidadosamente la copia de seguridad, la huella de la cartera y la dirección de recepción.

No muevas todo el saldo de inmediato. Envía primero una pequeña cantidad, confirma que llega a la nueva cartera, vuelve a verificar la huella y la dirección y, solo entonces, mueve el resto. Conserva la copia antigua hasta que todo el saldo haya llegado correctamente. Una vez completada la migración, deja de utilizar las direcciones antiguas para recibir fondos.

Coinkite establece una excepción relacionada con la entropía generada mediante dados. Si, al crear la semilla, utilizaste la función “Add Dice Rolls” de Coldcard e introdujiste al menos 50 tiradas de un dado de seis caras que fueran justas, independientes y completamente privadas, los propios dados aportaron al menos 128 bits de entropía; con 99 tiradas o más, aproximadamente 256 bits. Si no recuerdas cuántas tiradas hiciste o si los resultados se fotografiaron o registraron en un dispositivo conectado a Internet, no dependas de esta excepción.

Una passphrase BIP-39 también puede añadir un secreto independiente, pero palabras cortas, citas, variaciones habituales o contraseñas reutilizadas pueden seguir siendo adivinables. El PIN del dispositivo no es una passphrase BIP-39. Incluso con una passphrase fuerte, Coinkite sigue recomendando reemplazar la semilla porque la frase original débil no ha sido corregida.

Durante la migración, hay que extremar la precaución ante avisos falsos, falsos agentes de soporte y páginas que prometan «comprobar la seguridad de la semilla». Cualquiera que pida introducir una frase semilla en una página web, ventana de chat o software de asistencia remota no debe considerarse de confianza.

Qué enseñanzas deja este incidente

El aislamiento físico, las compilaciones reproducibles y las protecciones físicas de Coldcard siguen teniendo valor. Simplemente no pueden proteger una clave privada que ya era débil en el momento de generarse. Una cartera de hardware no es una caja fuerte aislada, sino un proceso completo: generación aleatoria, compilación del firmware, almacenamiento de claves privadas, firma, copia de seguridad y recuperación. Un fallo en cualquiera de esas etapas puede comprometer todo el sistema.

Los usuarios no pueden revisar personalmente cada línea de código de una cartera de hardware, pero sí pueden reducir los puntos únicos de fallo. Los activos de gran valor no deberían depender indefinidamente de un único fabricante y de un único método de generación de semillas. Conviene registrar qué dispositivo generó cada frase semilla, junto con la versión del firmware y la fecha; revisar periódicamente los avisos de seguridad del fabricante; y, cuando el fallo afecta a la propia semilla, no asumir que basta con actualizar el firmware.

Lo que realmente debe sustituirse en este caso son las claves. Mientras la semilla antigua siga controlando fondos, el riesgo continúa.

Referencias

Fuentes oficiales de empresa y firmware

• Sitio web oficial de Coldcard

• Sitio web oficial de Coinkite

• Aviso oficial de seguridad de Coldcard / Coinkite

• Análisis técnico oficial de Coinkite

• Código fuente y avisos de seguridad del firmware oficial de Coldcard

• Historial oficial de versiones del firmware de Coldcard

• Página oficial de descargas de firmware de Coldcard

Fuentes técnicas independientes y estándares

• Block Engineering: Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware

• Bitcoin BIPs: especificación BIP-39

• Commit de Coldcard de 2021 que introdujo libNgU

Seguimiento on-chain y verificación periodística

• Galaxy Research: seguimiento de la tercera ronda y totales de las tres rondas

• CoinDesk: las tres rondas se ampliaron a 4.585 direcciones y unos 1.367 BTC

• The Hacker News: ruta de la vulnerabilidad, versiones afectadas y actualización de datos de Galaxy