Entropía débil en el firmware de Coldcard: análisis de causa raíz y reconciliación de pérdidas on-chain

Resumen. Entre el 30 de julio y el 7 de agosto de 2026 se barrieron al menos 1.719 BTC (unos 111 millones de dólares) de direcciones de Bitcoin cuyas semillas se habían generado en carteras de hardware Coldcard. No se robó ningún dispositivo, no se adivinó ningún PIN y no hubo phishing. La causa fue un error de configuración de compilación publicado en el firmware 4.0.1 de Coldcard el 17 de marzo de 2021, que vinculó silenciosamente la generación de semillas al PRNG determinista Yasmarang de MicroPython en lugar del generador de números aleatorios por hardware del STM32, reduciendo la entropía efectiva de los 128 bits de diseño a unos 40 bits en Mk2/Mk3 y unos 72 bits en Mk4, Mk5 y Q. Este informe reconstruye la causa raíz a partir de las divulgaciones del fabricante y de terceros, reconcilia las estimaciones de pérdidas divergentes publicadas por Galaxy Research, TRM Labs y la prensa especializada, cuantifica la superficie de exposición y sitúa el incidente dentro de un patrón de quince años de fallos de entropía en software de criptomonedas. Dos conclusiones son estructurales: los totales publicados difieren en torno a un 30 % y ninguna cifra aislada es defendible por sí sola; y el incidente no está cerrado — la explotación continuaba en el momento de redactar este texto, y ninguna actualización de firmware puede reparar una semilla que ya existe.

Conclusiones principales

1. La causa raíz es un error de configuración de compilación, no una ruptura de la criptografía de Bitcoin. BIP-39, secp256k1 y el elemento seguro del dispositivo funcionaron exactamente como estaba diseñado. El defecto estaba una capa por debajo: en qué generador de números aleatorios acabó enlazado en el binario.
2. La entropía efectiva de la semilla cayó a unos 40 bits (Mk2/Mk3) y 72 bits (Mk4/Mk5/Q) frente a un objetivo de diseño de 128 bits. El análisis de Block situó los techos por debajo de 2^40,7 y 2^73,3 respectivamente.
3. Las estimaciones de pérdidas publicadas difieren en torno a un 30 %, entre 1.596 y 2.055 BTC. La cifra confirmada por Galaxy Research el 7 de agosto era de 1.719 BTC (~111 M$); TRM Labs la situó en 1.816 BTC (~116 M$). Lo defendible es un rango, no un titular.
4. La ventana de exposición es de cinco años y cuatro meses — del 17 de marzo de 2021 al 31 de julio de 2026. Cualquier semilla generada con firmware afectado en esa ventana sin al menos 50 tiradas de dado privadas debe considerarse comprometida.
5. Parchear no remedia. La corrección solo protege la generación futura de semillas. Migrar los fondos a una semilla nueva es el único remedio, y es una acción manual, usuario por usuario.
6. La explotación precedió a la divulgación en unas 30 horas y sigue activa. Galaxy Research atribuye ahora el patrón a varios actores independientes y no a un único operador, lo que cambia el perfil de riesgo de cualquier cartera aún sin migrar.
7. Es el cuarto fallo masivo de entropía documentado públicamente en quince años. SecureRandom de Android (2013), Profanity (2022), Randstorm y Milk Sad (2023) y ahora Coldcard comparten firma. La clase es sistémica, no propia de un fabricante.

1. Contexto: por qué la entropía lo es todo

Una cartera de Bitcoin es un número. Una semilla BIP-39 de 12 palabras codifica 128 bits de aleatoriedad, y todas las claves privadas, claves públicas y direcciones de la cartera se derivan de ella de forma determinista. No hay ningún otro secreto. El PIN, el elemento seguro, el aislamiento físico y la bolsa antimanipulación protegen la semilla después de que exista; ninguno protege el momento en que se crea. Si ese momento produce un número que un atacante puede adivinar, el resto de defensas son decorativas.

La entropía es simplemente la cantidad de números que el atacante debe probar. Con 128 bits el espacio de búsqueda es 2¹²⁸ — una cifra de 39 dígitos, fuera del alcance de cualquier máquina imaginable. Con 40 bits es 2⁴⁰, unos 1,1 billones de candidatos. No es una reducción teórica: es el trabajo de un fin de semana.

El ataque en sí es vergonzosamente paralelizable y no requiere interacción con la víctima. El atacante enumera el espacio de semillas reducido, deriva las rutas de direcciones estándar BIP-32/44/49/84 para cada candidata y compara las direcciones resultantes con el conjunto de direcciones con fondos del UTXO set — un conjunto público, descargable y de apenas unos cientos de millones de entradas. Cada candidata cuesta un puñado de operaciones de hash y de curva elíptica. En GPU alquiladas, un barrido de 2⁴⁰ se ejecuta en minutos u horas por unos pocos miles de dólares. Lo decisivo es que el atacante nunca toca el dispositivo, la red ni al usuario: lo primero que sabe la víctima es un gasto que no autorizó.

Un espacio de 2⁷² es unos cuatro mil millones de veces mayor y no es forzable de forma casual. Si el nivel de 72 bits fue realmente roto, o si las pérdidas provienen abrumadoramente del nivel de 40 bits, es una de las preguntas abiertas relevantes de este incidente (§8).

2. Causa raíz

2.1 Una macro, dos funciones, ningún error

El firmware de Coldcard se ejecuta sobre MicroPython. Había dos funciones disponibles para producir bytes aleatorios con la misma firma: la implementación respaldada por hardware que Coinkite mantiene en su librería criptográfica libngu, que lee el generador de números aleatorios verdaderos del STM32, y el propio recurso por software de MicroPython.

La configuración de compilación de Coinkite fijaba la macro MICROPY_HW_ENABLE_RNG a 0 con la intención de desactivar por completo la vía por software. La guarda alrededor de esa vía comprobaba si la macro estaba definida (#ifndef) en lugar de cuál era su valor. Una macro definida como cero sigue estando definida, de modo que la guarda pasó y el generador por software se compiló igualmente. Como ambas funciones compartían firma, el enlazador vinculó la débil. No hubo error de compilación, ni aviso, ni excepción en tiempo de ejecución, ni nada observable en el comportamiento del dispositivo.

2.2 Qué era realmente ese recurso alternativo

El recurso alternativo es el generador pseudoaleatorio Yasmarang de MicroPython. Su debilidad aquí no es el algoritmo sino su inicialización: se sembró una única vez a partir del identificador único del chip y del estado de los registros del temporizador, y no recogió entropía fresca después. El ID del dispositivo es fijo por unidad y en parte estructurado; el estado del temporizador en el arranque tiene mucha menos variabilidad de la que aparenta. El generador producía después un flujo largo y estadísticamente correcto a partir de un secreto inicial minúsculo.

La consecuencia, en bits:

2.3 Por qué cinco años de revisión no lo detectaron

Tres propiedades hicieron este defecto inusualmente duradero, y se generalizan más allá de Coldcard.

• Es invisible en la revisión del código fuente. El código de generación de semillas se lee correctamente: llama a una función que se supone que es el RNG por hardware. La sustitución ocurre en el preprocesador y en el enlazador, para una configuración de compilación concreta. Leer el repositorio — algo que cualquiera podía hacer, el firmware es de código disponible — no lo revela.
• Sobrevive a las pruebas estadísticas. Yasmarang produce una salida que supera las baterías estándar de tests de aleatoriedad. Probar el flujo de bytes del dispositivo como caja negra no mostraría nada anómalo, porque el defecto está en el tamaño del espacio de semillas, no en la distribución de la salida. No se puede detectar una semilla de baja entropía muestreando su salida.
• No tiene ningún síntoma visible para el usuario. Una semilla débil produce palabras válidas, direcciones válidas, firmas válidas y una copia de seguridad que restaura correctamente. La única diferencia observable frente a una semilla fuerte es que otra persona también puede gastar desde ella, y eso solo se ve cuando lo hace.

El consejero delegado de Coinkite ha afirmado que el atacante encontró el fallo mediante revisión asistida por IA del firmware de código disponible, y que la propia revisión interna con IA de la empresa no lo detectó. Diversos investigadores de seguridad han cuestionado públicamente ese relato. Tratamos tanto la atribución como la réplica como afirmaciones no verificadas (§8).

3. Cronología de la explotación

El primer barrido comenzó hacia las 01:10 UTC del 30 de julio de 2026 y duró 41 minutos. Las informaciones publicadas mientras aún estaba en curso registraron 594 BTC de unas 500 direcciones a los 25 minutos; ese mismo barrido terminó en 1.082,65 BTC repartidos en 1.196 direcciones. Varios relatos posteriores tratan los 594 BTC y los 488 BTC siguientes como oleadas separadas. Reproducimos ambas lecturas en lugar de elegir entre ellas, porque la distinción afecta materialmente a la atribución oleada por oleada.

Galaxy Research describió después más de 25 patrones de ataque distintos en las oleadas 1 a 3, y afirmó haber recibido más de 250 comunicaciones de víctimas, de las cuales solo se añadieron a sus recuentos los casos verificados con alta confianza. El 5 de agosto, alrededor del 90 % del bitcoin robado seguía sin moverse — algo inusual en un robo de esta magnitud y coherente con un actor sin presión para blanquear rápido. Galaxy ha reportado unas 600 direcciones que considera bajo control del atacante a investigadores federales y a firmas de cumplimiento del sector, y ha indicado que unas tasas de barrido superiores a un drenaje por bloque señalan que la explotación sigue activa.

Coinkite publicó su aviso el 30 de julio, unas 30 horas después del inicio del primer barrido, y distribuyó firmware de emergencia el 31 de julio. También detuvo los envíos y destruyó los dispositivos de sus instalaciones que llevaban firmware afectado. El 6 de agosto suspendió su política de borrado automático de datos de clientes para conservar registros ante los litigios previstos, tras las críticas por haber enviado correos a los clientes afectados mientras afirmaba borrar los datos a los 90 días; la empresa aclaró que la legislación canadiense exige conservarlos ocho años.

4. Reconciliación de las estimaciones de pérdidas

Los titulares de la primera semana de agosto citaron 38, 70, 85, 89, 100, 111, 116 y 130 millones de dólares. No son correcciones unos de otros. Son mediciones distintas, tomadas en días distintos, bajo reglas de confirmación distintas. Ponerlas una junto a otra es la única forma honesta de leerlas.

Cuatro factores explican la dispersión, y ninguno consiste en que alguien haya hecho mal las cuentas.

• Los umbrales de confirmación difieren. Galaxy Research contabiliza una pérdida solo cuando un informe de víctima o un patrón on-chain supera un listón de alta confianza. TRM Labs hace su propio clustering. La prensa especializada agrega ambos más sus propias fuentes. Que la cifra confirmada de Galaxy bajara respecto a un agregado anterior y volviera a subir refleja reclasificación, no monedas recuperadas.
• Las direcciones no son carteras. Una víctima puede tener muchas direcciones; las cifras de ~7.300 y >5.200 direcciones no son comparables entre sí ni con un recuento de víctimas, y ninguna se traduce limpiamente en totales de BTC.
• Las cifras en dólares no son comparables entre fechas. El precio de bitcoin se movió durante la ventana de medición, de modo que un titular en dólares al alza no significa necesariamente que se robaran más monedas. BTC es aquí la única unidad estable.
• La atribución está en disputa. A medida que el patrón se fragmentó entre varios actores, decidir qué drenajes pertenecen a esta explotación y no a robos ajenos se convirtió en un juicio de valor.

Nuestra posición: lo defendible a 8 de agosto de 2026 es aproximadamente entre 1.600 y 2.100 BTC, con 1.719 BTC confirmados. Cualquier cifra aislada es una instantánea de una metodología en una fecha, y debe citarse con ambas.

5. Superficie de exposición

El aviso de Coinkite del 30 de julio (actualizado el 1 de agosto) define las compilaciones afectadas. Conviene señalar que Mk2 y Mk3 sufren la forma grave del defecto; Mk4, Mk5 y Q sufren una forma más leve.

5.1 Quién no está expuesto

• Tiradas de dado. Las semillas creadas con al menos 50 tiradas de dado justas y privadas no quedan expuestas por este fallo: la entropía aportada por el usuario se procesó correctamente, y 50 tiradas por sí solas aportan aleatoriedad suficiente. Coinkite indica que 99 o más tiradas producen unos 256 bits. Es el único control del lado del usuario que funcionó empíricamente.
• Frase de contraseña BIP-39 fuerte. Una passphrase fuerte y única crea una cartera separada que no se alcanza solo con las palabras de la semilla. Es una barrera real, pero no repara la semilla subyacente, y su fortaleza es ahora lo único que separa al atacante de los fondos.
• Multifirma. Protege solo si el quórum no está construido íntegramente con dispositivos afectados. Un 2-de-3 formado por tres Coldcard vulnerables no está protegido.
• Semillas importadas. Una semilla generada en otro lugar e importada a un Coldcard no está afectada; el defecto está en la generación en el dispositivo.

5.2 Lo que un parche no puede hacer

Este es el punto que más fácilmente se pasa por alto y más caro sale pasar por alto. Actualizar el firmware no repara una semilla que ya existe. Una clave derivada de entropía débil es débil para siempre. El firmware corregido protege la siguiente semilla que generes, y nada más. La remediación, por tanto, no es un despliegue de software: son millones de dólares en migraciones manuales de fondos, usuario por usuario, ejecutadas por personas que tal vez nunca vean el aviso. Esa brecha estructural es la razón por la que los incidentes de entropía siguen produciendo pérdidas durante años tras la divulgación.

6. Precedentes: el mismo fallo, cinco veces

El defecto de Coldcard no es novedoso. Es la instancia más reciente de una clase de fallo con una firma constante: la aleatoriedad segura se sustituye silenciosamente por algo más débil, la sustitución no produce ningún síntoma visible y el daño se descubre solo cuando los fondos se mueven.

Randstorm es el análogo más cercano y el más instructivo. En noviembre de 2023 la firma de recuperación Unciphered divulgó que SecureRandom() en la librería JSBN — usada por BitcoinJS, que alimentaba la generación de carteras en navegador en Blockchain.info y decenas de servicios derivados entre 2011 y 2015 — caía silenciosamente del generador criptográfico del navegador a Math.random(), típicamente un generador congruencial lineal de 48 bits sembrado con el reloj. Unciphered estimó que se generaron alrededor de 1,4 millones de carteras en la ventana vulnerable y situó entre 1.200 y 2.100 millones de dólares en riesgo. La debilidad ya se había señalado públicamente en la lista bitcoin-dev en 2018, cinco años antes de la divulgación coordinada. Esas carteras siguen expuestas hoy, porque el problema de remediación es el mismo al que se enfrenta ahora Coldcard: no se puede parchear una clave que ya ha sido generada.

La diferencia que hace que el caso Coldcard duela más es la categoría de producto. Randstorm golpeó carteras calientes improvisadas en navegadores durante la etapa amateur de Bitcoin. Coldcard es un dispositivo diseñado a propósito, aislado y auditado, vendido precisamente a los usuarios que se toman la custodia más en serio. Los fallos de entropía no respetan categorías de producto, ni precios, ni reputaciones.

7. Discusión

7.1 El modelo de amenazas tenía un agujero con la forma del instante cero

La seguridad de las carteras de hardware se argumenta convencionalmente en términos de extracción de claves: elementos seguros, protección por PIN, evidencia de manipulación, aislamiento, integridad de la cadena de suministro. Todas esas defensas presuponen que ya existe una clave fuerte. La generación de la semilla es un evento único, irrepetible e inobservable al principio de la vida del dispositivo, y es el único punto del sistema en el que un defecto no puede mitigarse a posteriori. En este incidente fue también el menos escrutado.

7.2 El código disponible fue necesario, pero no suficiente

El firmware de Coldcard es de código disponible y lleva años siendo revisado. El defecto sobrevivió igualmente, porque no vive en el código fuente: vive en la relación entre una macro de compilación, una directiva de preprocesador y un enlazador. Auditar eso exige razonar sobre condicionales de compilación y vinculación de símbolos para la compilación exacta que se distribuye, que es una disciplina distinta de leer código. El análisis estático asistido por IA posterior al incidente, que según se ha informado detectó 85 hallazgos de severidad crítica en otras implementaciones de carteras — vinculaciones alternativas incorrectas, resembrado insuficiente, rutas débiles dependientes de la configuración — sugiere que este espacio ha estado poco examinado, más que que estos errores sean raros. La divulgación coordinada con los fabricantes sobre esos hallazgos seguía en curso al redactar este texto, por lo que deben considerarse no confirmados.

7.3 La asimetría del defensor

El atacante necesitaba un solo barrido de un espacio de semillas precalculado. Los defensores necesitaban que cada usuario afectado se enterara del aviso, entendiera que actualizar no basta, generara una semilla nueva y moviera los fondos — antes de ese barrido. El primer barrido precedió al aviso en unas 30 horas, y los usuarios que estaban de viaje, desconectados o simplemente no siguen los canales de seguridad de Bitcoin no tuvieron ninguna oportunidad. En los fallos de generación de claves, el momento de la divulgación es casi irrelevante para el resultado; lo que importa es si el usuario aportó su propia entropía años antes.

7.4 Qué funcionó realmente

Exactamente un control del lado del usuario separó a los afectados de los no afectados: las tiradas de dado. Los usuarios que añadieron 50 o más tiradas privadas al crear la semilla no están expuestos, sea cual sea la versión de firmware. Ese es un resultado empírico de un incidente real, no una preferencia teórica, y es el argumento más sólido disponible para usar entropía aportada por el usuario siempre que un dispositivo lo permita.

8. Limitaciones y preguntas abiertas

• Sin verificación independiente. No realizamos análisis on-chain. Todos los totales aquí son de segunda mano y están atribuidos. Quien necesite una cifra defendible debe acudir al rastreador primario y citar su fecha.
• No está resuelto qué nivel de entropía se rompió realmente. Un espacio de 2⁴⁰ es trivialmente rastreable; 2⁷² es unas cuatro mil millones de veces más difícil y exigiría cómputo serio y sostenido. Ninguna fuente pública establece si las pérdidas provienen abrumadoramente de semillas Mk2/Mk3 o si el nivel de 72 bits fue realmente roto. Esto cambia materialmente el riesgo de los poseedores de Mk4/Mk5/Q y es, en nuestra opinión, la pregunta sin responder más importante del incidente.
• Las estimaciones de entropía no se han reproducido de forma independiente. Las cifras de 40 y 72 bits proceden de Coinkite, con Block publicando techos que las corroboran. No nos consta que un tercero haya publicado una metodología reproducible derivada del binario del firmware distribuido.
• La atribución de las oleadas está en disputa, igual que si la operación fue de un actor que después se fragmentó o de varios desde el principio.
• Se desconoce la exposición no materializada. No existe una estimación pública de cuánto bitcoin sigue asentado sobre semillas Coldcard débiles. La pérdida materializada es una cota inferior del problema, no una medida de él.
• Las afirmaciones sobre IA de ambas partes no están verificadas — ni la de Coinkite de que el atacante usó IA para encontrar el fallo, ni la réplica de los investigadores.
• No hemos podido localizar un identificador CVE asignado al defecto de Coldcard al redactar este texto, lo que complica su seguimiento en las bases de datos de vulnerabilidades estándar.
• Las cifras en dólares dependen de la fecha y no deben compararse a lo largo de la ventana de medición.

9. Recomendaciones

9.1 Si tienes un Coldcard

1. Asume exposición primero, verifica después. Si la semilla se generó en el dispositivo con firmware afectado y sin más de 50 tiradas de dado, considera los fondos en riesgo ahora mismo. Comprueba la versión de firmware después de actuar, no antes.
2. Actualiza, genera una semilla nueva y migra. Los tres pasos. Un dispositivo actualizado con una semilla antigua sigue siendo una cartera comprometida.
3. Verifica la nueva copia de seguridad antes de que custodie valor. Confirma que la copia restaura, envía una cantidad pequeña de prueba, confírmala y mueve después el resto.
4. No restaures nunca la semilla antigua en ningún sitio. Ni en un dispositivo nuevo, ni en software, ni «para comprobar». Es conocimiento público en todo salvo en el nombre.
5. Espera phishing. A los incidentes de este perfil les siguen herramientas de migración falsas, soporte falso y avisos falsos. Coinkite nunca te pedirá las palabras de tu semilla.

9.2 Para el ecosistema

1. Usa entropía aportada por el usuario siempre que el dispositivo lo permita. Las tiradas de dado fueron la diferencia entre perderlo todo y no perder nada en este incidente.
2. Diversifica el quórum. La multifirma entre fabricantes convierte el defecto catastrófico de un fabricante en un incidente superable. La multifirma dentro de un solo fabricante, no.
3. Audita la compilación, no solo el código. Compilaciones reproducibles, revisión del mapa de enlazado y tests explícitos que comprueben qué símbolo de RNG queda vinculado habrían detectado este defecto en 2021.
4. No confíes en los tests estadísticos de aleatoriedad para validar la generación de semillas. No pueden ver un espacio de semillas pequeño detrás de un PRNG bien construido.
5. Trata las carteras antiguas como riesgo vivo. Si tienes monedas generadas en un navegador entre 2011 y 2015, o con bx seed de Libbitcoin, esas claves están expuestas hoy. Muévelas.

Preguntas frecuentes

Metodología y fuentes de datos

Este informe es una síntesis de la divulgación primaria del fabricante y de la información on-chain secundaria, compilada entre el 2 y el 8 de agosto de 2026. Las afirmaciones técnicas sobre el defecto del firmware proceden del aviso de seguridad de Coinkite y de análisis técnicos de terceros sobre el parche; no compilamos, desensamblamos ni probamos el firmware. Las cifras de pérdidas se reproducen tal como las publicaron las organizaciones que las generaron, con la fecha de medición adjunta, y nunca se combinan en un agregado único. Cuando los relatos entran en conflicto, se presentan ambos (§3, §4). Las afirmaciones que no pudimos corroborar se marcan como no verificadas (§8). Los datos están actualizados a 8 de agosto de 2026; este documento se revisará conforme evolucione el incidente, y cada revisión queda registrada abajo.

Referencias

1. Coinkite — Coldcard Security Advisory (30 jul 2026, actualizado el 1 ago 2026) — https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/
2. TRM Labs — The Largest Hardware Wallet Exploit of 2026: Inside the US$116 Million Coldcard Hack — https://www.trmlabs.com/resources/blog/the-largest-hardware-wallet-exploit-of-2026-inside-the-usd-116-million-coldcard-hack
3. The Crypto Times — Galaxy Research Confirms $111M Stolen Funds in Coldcard Exploit (8 ago 2026) — https://www.cryptotimes.io/2026/08/08/galaxy-research-confirms-111m-stolen-funds-in-coldcard-exploit/
4. The Crypto Times — Coldcard Hack Losses Hit $100M With 1,596 BTC Stolen (4 ago 2026) — https://www.cryptotimes.io/2026/08/04/coldcard-hack-losses-hit-100m-with-1596-btc-stolen/
5. crypto.news — Coldcard hack: how a build flag drained $116M in bitcoin — https://crypto.news/coldcard-hack-bitcoin-self-custody-entropy/
6. crypto.news — Coldcard's RNG flaw is still draining wallets, and an AI audit just found 85 more critical bugs — https://crypto.news/coldcard-rng-flaw-bitcoin-wallet-ai-audit/
7. The Hacker News — Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft in 41 Minutes — https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
8. Privacy Guides — Nearly 1,400 Bitcoin Hacked from Coldcard Wallets (3 ago 2026) — https://www.privacyguides.org/news/2026/08/03/nearly-1400-bitcoin-hacked-from-coldcard-wallets/
9. Decrypt — Coldcard Bitcoin Exploit Explained: Entropy, How Keys Are Generated, and Why Bits Matter — https://decrypt.co/374916/coldcard-bitcoin-exploit-explained-entropy-keys-bits
10. Galaxy Research (@glxyresearch) — seguimiento on-chain continuo de la explotación — https://x.com/glxyresearch
11. Unciphered — Randstorm: You Can't Patch a House of Cards (nov 2023) — https://www.unciphered.com/disclosure-of-vulnerable-bitcoin-wallet-library-2/
12. Milk Sad — CVE-2023-39910, divulgación de Libbitcoin Explorer bx seed — https://milksad.info/disclosure.html

Historial de revisiones

Aviso. Esta investigación se publica con fines informativos y educativos. No es asesoramiento financiero, legal ni de seguridad, y no sustituye a las indicaciones del fabricante. Si tienes un Coldcard, sigue las instrucciones oficiales de Coinkite.