El 30 de julio de 2026, entre la 1:10 y la 1:51 de la madrugada UTC, alguien vació 1.082,65 bitcoins de 1.196 carteras distintas. Todo ocurrió en cuarenta y un minutos. Eran unos 70 millones de dólares según el cambio de aquel día.
No hubo phishing, ni malware, ni descuidos por parte de los usuarios. Las víctimas hacían exactamente lo que se supone que hay que hacer: guardar sus bitcoins en una cartera física, un dispositivo dedicado y desconectado de internet. Uno de los afectados contó que el suyo llevaba años guardado en la caja fuerte de un banco.
El problema estaba integrado en el dispositivo desde marzo de 2021 y cabía en una sola línea de código.
Las Coldcard de la empresa canadiense Coinkite llevaban cinco años generando las frases semilla —las doce o veinticuatro palabras de las que se derivan todas tus claves— mediante un generador de números aleatorios de juguete, en lugar de utilizar el chip de hardware destinado a ello. Y un número aleatorio que no es aleatorio de verdad se puede adivinar.
A día de hoy, el robo se ha extendido a tres oleadas confirmadas y a varios episodios menores: cerca de 1.600 bitcoins de unas 7.300 direcciones. Además, se investiga una cuarta oleada que elevaría el total por encima de los 2.000 BTC, unos 130 millones de dólares.
Vamos a analizar exactamente qué falló, por qué es tan grave y qué tiene que hacer quien posea una de estas carteras.
El error: comprobar que una opción existe en vez de si está activada
La causa raíz, documentada por los equipos de ingeniería y seguridad de Block junto a investigadores anónimos, es de las que dan escalofríos por lo pequeña que es.
La Coldcard incorpora un chip STM32 con generador de números aleatorios por hardware, que es el componente que debería emplearse para crear una semilla. Sin embargo, el firmware está desarrollado sobre MicroPython, y este sistema incluye su propio generador por software como recurso de emergencia para placas que carecen de hardware: un algoritmo llamado Yasmarang, diseñado para videojuegos y simulaciones, no para custodiar dinero.
Para decidir cuál utilizar, la biblioteca de criptografía de Coinkite realizaba la comprobación de una opción de compilación de la siguiente manera:
#ifndef MICROPY_HW_ENABLE_RNG
Todo el desastre reside ahí. #ifndef pregunta si la opción existe, no si vale 1 o 0. Y la configuración de la placa de la Coldcard la define con valor cero, precisamente porque el hardware se gestiona aparte, con código propio.
El resultado fue que la opción existía, la comprobación se superó, el firmware compiló sin un solo aviso y se quedó vinculado al generador de emergencia por software. Durante cinco años.
Qué tiene de malo Yasmarang aquí
Que se inicializa con tres elementos que no tienen nada de aleatorios:
- El número de serie del chip, que es fijo de por vida y se puede leer de memoria.
- El contador SysTick, que se reinicia cada milisegundo y solo toma unos 80.000 valores distintos en los modelos antiguos.
- Dos registros del reloj de tiempo real, que además están correlacionados entre sí y con el anterior.
Hay un detalle que remata la faena. El código intentaba reforzarlo mediante un XOR con un segundo generador Yasmarang inicializado con constantes públicas. Como resumió Block en su análisis: “el XOR no crea entropía; si las dos entradas son reproducibles, su XOR es reproducible”.
Qué es la entropía de una semilla, en corto. Una frase semilla de 12 palabras debería tener 128 bits de entropía: 2¹²⁸ combinaciones posibles, un número tan absurdamente grande que probarlas todas es imposible con cualquier ordenador que exista o vaya a existir.
Debido a este fallo, los Mk2 y Mk3 bajaron a un techo de unos 40 bits, mientras que los Mk4, Mk5 y Q descendieron a unos 72. Y estos son los techos optimistas: en el peor caso, si se conocen el número de serie del aparato y el historial de llamadas, la secuencia es completamente determinista.
Pasar de 2¹²⁸ a 2⁴⁰ no es “un poco menos seguro”. Es la diferencia entre algo imposible y una tarde de cálculo.
El parche que tampoco parcheaba
En 2022, Coinkite añadió un resembrado desde el elemento seguro del aparato para los modelos Mk4 y posteriores. Sobre el papel, estaba arreglado. En la práctica, hubo dos fallos encadenados:
- Se calcula un hash SHA-256 doble de 32 bytes… y solo llegan cuatro bytes a la función de resembrado.
- Esa función se limita a sobrescribir una única variable del estado interno del generador, sin reiniciar el resto.
Traducido: como mucho 2³² secuencias distintas, unos 4.300 millones. Suena a mucho, pero no lo es: para cualquiera con una tarjeta gráfica decente, es cuestión de horas.
Cómo se convierte un fallo de entropía en un robo masivo
Lo que hace que este fallo sea tan explotable es que el atacante no necesita tocar el aparato. Ni acercarse. Ni saber quién eres.
El procedimiento es de una eficacia brutal:
- Genera candidatos. Recrea las secuencias posibles del generador defectuoso, recorriendo el espacio reducido de valores iniciales.
- Deriva las direcciones. De cada semilla candidata salen, con las reglas estándar de Bitcoin, todas sus direcciones públicas.
- Pregunta a la cadena de bloques. Aquí está la clave: la blockchain es pública. No hace falta atacar a nadie para comprobar si has acertado — basta con mirar si esa dirección existe y tiene saldo.
- Se lo lleva. Si hay coincidencia, ya tienes la clave privada.
Ese tercer paso es lo que transforma un problema teórico en un robo industrializado: el atacante puede barrer millones de candidatos contra el registro público sin dejar rastro y sin alertar a nadie, y solo aparece cuando ya está firmando las transferencias.
Las oleadas
- 30 de julio: 1.082,65 BTC de 1.196 direcciones, en 41 minutos. Unas 30 horas antes de que Coinkite publicara su primer aviso.
- 31 de julio: 76,16 BTC de 1.478 direcciones.
- 1 de agosto: 207,73 BTC de 1.912 direcciones.
El goteo posterior sugiere que, una vez que el fallo salió a la luz, otros se pusieron a buscar carteras vulnerables por su cuenta. Es el efecto secundario inevitable de hacer una divulgación cuando el problema ya está en explotación activa.
Las carteras de papel son el caso peor. En una cartera normal, la salida del generador pasa por los estándares BIP-39 y BIP-32 antes de convertirse en claves. En una cartera de papel, la salida del generador se usa directamente como clave privada, sin pasos intermedios.
Esto implica que un atacante puede generar claves candidatas, derivar su dirección y compararla con cualquier dirección de cartera de papel conocida. Sin intermediarios y sin margen.
Quién lo encontró
Es conveniente diferenciar los dos roles, ya que en muchas coberturas se están mezclando. El análisis técnico del fallo fue publicado por los equipos de Bitcoin Engineering y Security de Block junto a investigadores anónimos. Por su parte, el rastreo de los movimientos en cadena que permitió identificar el patrón del robo fue realizado por Galaxy Research.
Hay un detalle que ha inquietado al sector: Coinkite ha reconocido que es probable que se usaran herramientas de inteligencia artificial para dar con el fallo. Un error de este tipo —una macro mal comprobada, enterrada en la configuración de una placa— es exactamente el tipo de fallo que una auditoría humana puede pasar por alto durante años y que un análisis automatizado a gran escala sí puede sacar a flote.
La pregunta incómoda que queda es evidente: cuántos fallos parecidos siguen dormidos en el firmware de otros fabricantes, esperando a que alguien utilice la misma herramienta.
Qué modelos están afectados y qué hay que hacer
Lo primero y más importante, ya que mucha gente lo entiende al revés: actualizar el firmware NO arregla tu semilla.
El nuevo firmware genera correctamente las semillas nuevas. Sin embargo, la que ya tienes se creó con el generador roto y sigue siendo igual de adivinable por mucho que actualices. Coinkite lo dice sin rodeos: hay que crear una semilla nueva y mover los fondos.
Atención a este punto: la exposición depende de con qué firmware se generó el secreto, no de la fecha de compra del aparato ni de la cartera que uses actualmente. Si exportaste esa semilla a otra cartera, la semilla sigue comprometida allí también.
| Modelo | Firmware afectado | Entropía real | Versión corregida |
| Mk1 | Ninguno | No afectado | — |
| Mk2 y Mk3 | Hasta la 3.2.2 | No afectado (usaba el hardware) | — |
| Mk2 y Mk3 | De la 4.0.0 a la 4.1.9 | ~40 bits (sin resembrado) | 4.2.0 |
| Mk4 y Mk5 | Desde la 5.0.0 | ~72 bits (resembrado de 32 bits) | 5.6.0 |
| Q | Toda la producción | ~72 bits (resembrado de 32 bits) | 1.5.0Q |
| Mk4 / Mk5 Edge | Versiones previas | ~72 bits | 6.6.0X |
| Q Edge | Versiones previas | ~72 bits | 6.6.0QX |
| Tapsigner / Opendime / Satscard | Ninguno | No afectado (otro código) | — |
El procedimiento, en orden
Coinkite marca una secuencia concreta y el orden importa:
- Actualiza a la versión corregida.
- Genera una semilla nueva en el firmware ya parcheado.
- Verifica la copia de seguridad de esa semilla nueva.
- Prueba con una cantidad pequeña antes de nada.
- Migra el resto de los fondos.
- Conserva la copia antigua hasta que la migración esté completa y confirmada.
Las dos excepciones
No todo el mundo está expuesto. Te salvas si se cumple alguna de estas dos condiciones:
- Añadiste al menos 50 tiradas de dado justas, independientes y privadas al generar la semilla. Coinkite considera que en ese caso la semilla no está en riesgo por este fallo, porque la entropía la pusiste tú y no el generador roto.
- Tienes una frase de contraseña BIP-39 fuerte y única. Aquí matizan: es una barrera independiente que protege los fondos, pero no repara la semilla. Si esa contraseña se filtra alguna vez, vuelves a estar expuesto.
Qué NO está afectado. El resto de productos de Coinkite —Tapsigner, Opendime y Satscard— utilizan bases de código distintas y no presentan este problema.
Tampoco están afectadas las Coldcard Mk1, ni las Mk2 y Mk3 con un firmware anterior a la versión 4.0.0: esos modelos todavía utilizaban el generador por hardware, que es precisamente lo que se rompió más tarde.
Si quieres comprender exactamente qué fue lo que se generó mal y por qué es la pieza fundamental de todo el sistema, lo explicamos en la diferencia entre clave privada y frase de recuperación.
La lección que deja
Este caso desmonta una idea muy extendida: que una cartera física, desconectada y guardada bajo llave, es el final del problema. No es así. Al usar la semilla generada por el propio aparato, estás confiando toda tu seguridad a un único fabricante y a un único generador de números, y no tienes forma de comprobar desde fuera si ese generador hace bien su trabajo.
Por eso, las dos recomendaciones que resultaron útiles en este caso son precisamente las que no dependen del aparato: aportar entropía propia mediante dados y utilizar configuraciones multifirma en las que ninguna llave por sí sola sea suficiente. Ambas parecen paranoia hasta el día en que dejan de parecerlo.
Coinkite, por su parte, ha detenido los envíos y ha declarado que destruirá el material afectado que le quedaba en stock.
Fuentes
