Entropía de billetera: lo que el incidente de Coldcard enseña sobre la aleatoriedad

A las 01:31 UTC del 31 de julio de 2026, los bitcoins empezaron a salir de billeteras cuyos dueños no habían hecho absolutamente nada. Para las 01:56 —veinticinco minutos después—, aproximadamente 594 BTC, unos 38 millones de dólares, habían sido barridos de alrededor de 500 billeteras de firma única. Análisis posteriores de Galaxy Research y la cobertura de Chainalysis vincularon hasta aproximadamente 1.083 BTC repartidos en unas 1.196 direcciones. Nadie sufrió phishing. Nadie instaló malware. Nadie aprobó una transacción. El único rasgo que compartían las víctimas era la fecha en que se creó su billetera, porque lo que falló fue la entropía de la billetera: la aleatoriedad de la que se construye una frase semilla, fijada en el primer segundo de vida de una billetera.

Las billeteras se habían generado en dispositivos de hardware Coldcard, y el fallo que había detrás llevaba más de cinco años presente en firmware ya distribuido. Este artículo explica qué ocurrió, por qué esta clase de bug permanece invisible, qué dice y qué no dice sobre las billeteras de hardware, y qué preguntar sobre la aleatoriedad de cualquier billetera, incluida la nuestra.

Un fallo de 2021, cobrado en 2026

Según el aviso de seguridad de Coinkite, un error de firmware debilitó la generación de semillas en los Coldcard Mk2 y Mk3 con firmware 4.0.1 a 4.1.9 —un rango que empezó con la 4.0.1 en marzo de 2021— y en los Mk4, Mk5 y Q con versiones anteriores a las corregidas. La página de estado de seguridad de Coldcard describe la corrección como la eliminación de un mecanismo de respaldo por software en la ruta de números aleatorios. Una frase semilla BIP39 debería codificar 128 bits de entropía: 2¹²⁸ semillas posibles, un espacio que ningún atacante puede recorrer. El aviso sitúa las semillas afectadas de los Mk4, Mk5 y Q en unos 72 bits y dice que el impacto en los Mk2/Mk3, más antiguos, fue más grave; no da una cifra de bits para esos modelos, así que los unos 40 bits que este artículo usa para las semillas afectadas de los Mk3 son una estimación, no un dato del aviso. 2⁴⁰ son alrededor de 1,1 billones de candidatos: una cifra enorme para un humano, totalmente explorable para una máquina. Esa es la vulnerabilidad de Coldcard explicada en una sola frase: la generación de semillas perdió en silencio la mayor parte de su aleatoriedad, y nada visible lo delató.

Dos grupos estuvieron mucho menos expuestos. Una passphrase BIP39 fuerte y única añade una barrera independiente: según el aviso, la entropía reducida de la semilla no basta por sí sola para llegar a una billetera con passphrase. Pero una passphrase corta, común, con patrones o reutilizada puede adivinarse, y ninguna passphrase repara la semilla débil que hay debajo, así que Coinkite recomienda que quienes usan passphrase también migren en cuanto sea posible. Las semillas creadas con al menos 50 tiradas de dados justas, independientes y privadas no corren riesgo por este problema por sí solo; con menos tiradas o registros dudosos, el fabricante indica migrar. Coinkite divulgó el problema y publicó firmware corregido: 4.2.0 para los Mk2 y Mk3; en la rama estándar, 5.6.0 para los Mk4 y Mk5 y 1.5.0Q para el Q; en la rama Edge, 6.6.0X y 6.6.0QX. En los cinco años intermedios, las billeteras afectadas funcionaron a la perfección y lucían idénticas a las seguras. Quien ejecutó el barrido nunca necesitó tocar a una víctima: enumerar el espacio de claves débil, derivar direcciones, cotejarlas con la cadena y moverlo todo en una única ventana de 25 minutos.

Degradación silenciosa de la entropía: por qué las semillas parecían aleatorias

Lo inquietante es que nada en las semillas afectadas pareció nunca estar mal. Una semilla construida a partir de 40 bits de entrada predecible sale igualmente como doce palabras BIP39 perfectamente normales con un checksum válido. La billetera la acepta, deriva direcciones, firma transacciones; cada pantalla muestra exactamente lo que mostraría una billetera fuerte.

Las pruebas estadísticas tampoco sirven de ayuda: un generador determinista sembrado con datos predecibles sigue produciendo una salida que supera los tests de aleatoriedad —los bits están bien distribuidos, solo que extraídos de un conjunto catastróficamente pequeño de secuencias posibles—. La debilidad vive en una propiedad que ninguna salida puede revelar: cuántas otras semillas podrían haberse generado en su lugar. Solo el código de generación tiene esa respuesta.

Una semilla débil no parece débil. La diferencia entre 2¹²⁸ y 2⁴⁰ existe solo en el código que produjo las palabras.

Por eso esta clase de bug persiste durante años, y por eso el incidente de Coldcard pertenece a una familia. Milk Sad en la herramienta bx de Libbitcoin, el generador MT19937 de la extensión de navegador de Trust Wallet, Cake Wallet, la herramienta de direcciones personalizadas Profanity y Randstorm en las primeras billeteras de navegador comparten una misma forma: un CSPRNG sustituido silenciosamente por una fuente predecible — sin error, sin aviso, sin diferencia visible, hasta que alguien enumera el espacio de claves.

La lección incómoda

«Billetera de hardware» nombra un formato físico, no una garantía. Las billeteras barridas el 31 de julio se crearon en hardware de firma construido específicamente para ese fin, y esa no fue la capa que falló. Lo que decidió la supervivencia fue una propiedad fijada años antes: cómo se generó la semilla el día en que se creó la billetera. Todo lo que viene después —almacenamiento en frío, firma con air gap, verificación cuidadosa— protege una clave de ser robada. Nada de eso ayuda si la clave puede regenerarse.

Importa igualmente que Coinkite divulgó el fallo y publicó firmware corregido con prontitud. Esta no es la historia de un proveedor descuidado; es un modo de fallo que el sector no deja de redescubrir, tanto en hardware como en software. Cualquier billetera —la nuestra incluida— está a un fallback silencioso de distancia de la misma clase de bug. La pregunta honesta no es «¿qué proveedor es inmune?», sino «¿cómo fallaría esta billetera, y lo notaría alguien?».

Cinco preguntas que hacerle a cualquier billetera sobre su aleatoriedad

No hace falta ser criptógrafo para subir el listón. Cinco preguntas distinguen billeteras de manera significativa:

1. ¿Cuál es la fuente de entropía? Una semilla debe salir de un CSPRNG, no de marcas de tiempo, identificadores del dispositivo ni nada que un tercero pudiera reconstruir.
2. ¿Qué ocurre si esa fuente falla? La respuesta aceptable es un error rotundo que detiene la creación de la billetera. La inaceptable es un sustituto discreto: el fallback silencioso es el rasgo definitorio de esta clase de bug.
3. ¿La ruta de generación es de código abierto y verificable? La entropía débil es invisible en las salidas, así que la revisión del código es el único lugar donde puede detectarse.
4. ¿La billetera admite una passphrase BIP39? Una passphrase añade material secreto que el generador del dispositivo nunca tocó. En los Coldcard afectados, una passphrase fuerte y única hizo que la semilla debilitada no bastara por sí sola para llegar a los fondos; pero una passphrase débil o reutilizada puede adivinarse, y ninguna passphrase repara una semilla débil.
5. En una MultiSig, ¿las claves se generan en dispositivos independientes? Dispositivos independientes significan aleatoriedad independiente: un generador defectuoso compromete una clave, no el quórum.

Cómo genera Ownbit la entropía

Preguntas como estas merecen respuestas concretas sobre nuestro propio producto. La generación de mnemónicos de Ownbit tiene dos capas. En la capa de la aplicación, generateMnemonicRandom(entropy, langIndex) llama a generateMnemonic de la librería estándar bip39: 128 bits de entropía por defecto, con ocho listas de palabras BIP39 admitidas: inglés, chino simplificado y tradicional, japonés, francés, italiano, coreano y español. En la capa de la librería, randomBytes de bip39 extrae de crypto.getRandomValues, el CSPRNG de la plataforma.

Lo que importa aquí es qué ocurre cuando esa fuente no está disponible: la librería lanza un error. No consulta un reloj, ni un identificador del chip, ni ninguna fuente secundaria — no existe ruta de fallback en el código. El modo de fallo es un error sonoro en el momento de la creación, nunca una semilla silenciosamente más débil. Esa propiedad —fallar de forma ruidosa, nunca recurrir a un fallback— es exactamente la inversa del fallo detrás del incidente de Coldcard, Milk Sad y Randstorm, donde la generación continuó discretamente a partir de una fuente predecible.

No vamos a afirmar que esto haga a Ownbit inmune a los bugs; ningún proveedor honesto puede hacerlo. Lo que elimina, por construcción, es esta forma de fallo: no existe ninguna ruta de código por la que una billetera Ownbit genere discretamente una semilla débil. El resto del modelo está detallado en nuestra página de seguridad.

Por qué las claves generadas de forma independiente sobreviven a esta clase de bug

El barrido del 31 de julio golpeó billeteras de firma única: una semilla, una firma, fondos perdidos — el caso de manual de una frase semilla como único punto de fallo. La MultiSig cambia la aritmética. En una billetera MultiSig de Ownbit, cada clave es su propia frase semilla BIP39 estándar, generada en el dispositivo del propio participante. Supongamos que un dispositivo llevara exactamente esta clase de fallo. En una billetera 2-of-3, un atacante que enumere el espacio de claves débil posee una clave: por debajo del umbral. Nada se mueve. Una clave débil se convierte en una tarea de mantenimiento —rotarla— en lugar de una pérdida.

La protección viene de la independencia, no de la palabra «multifirma». Tres claves cofirmantes generadas en el mismo modelo de dispositivo defectuoso fallarían juntas. Tres claves nacidas en dispositivos genuinamente distintos —tu teléfono de uso diario, un teléfono de repuesto mantenido sin conexión como billetera fría de firma por QR, el dispositivo de un familiar— no dependen del generador de un mismo dispositivo, así que un generador defectuoso debilita una clave, no las tres. Esa independencia no es absoluta: dispositivos que ejecutan el mismo software de billetera o la misma biblioteca pueden compartir un modo de fallo, y por eso el código de generación importa tanto como el hardware. La misma lógica explica por qué una passphrase BIP39 fuerte y única protegió a los usuarios de Coldcard afectados: la passphrase es material secreto que el RNG del dispositivo nunca produjo, de modo que enumerar las semillas debilitadas no bastaba por sí solo para gastar. Esa protección es tan fuerte como la passphrase, y la semilla de debajo sigue siendo débil; por eso el fabricante sigue recomendando migrar.

Si tienes un Coldcard afectado

Tres acciones. El aviso de Coinkite sigue siendo la fuente de referencia y se actualiza a medida que avanza la investigación:

1. Actualiza el firmware y comprueba tu modelo y rama de versiones. Las versiones corregidas mínimas que nombra el aviso de Coinkite son la 4.2.0 para los Mk2 y Mk3 (la última para esos modelos), la 5.6.0 para los Mk4 y Mk5 y la 1.5.0Q para el Q en la rama estándar, y la 6.6.0X y la 6.6.0QX en la rama Edge. Son mínimos, no necesariamente las versiones recomendadas actuales; la página de estado de seguridad de COLDCARD mantiene la tabla vigente. No generes una semilla nueva en un modelo afectado hasta haber instalado la actualización.
2. Mueve los fondos a una semilla nueva generada con el firmware corregido. Actualizar protege las semillas futuras; no puede fortalecer una existente. Una semilla nacida con unos 40 bits sigue siendo enumerable para siempre: retírala por completo, nunca la reutilices y nunca envíes fondos de vuelta a sus direcciones. Esto también vale para las billeteras con passphrase: Coinkite recomienda a quienes la usan migrar en cuanto sea posible. Sigue la guía oficial de migración sin prisas: verifica la nueva copia de seguridad y una dirección de recepción, envía una transacción de prueba pequeña, mueve luego el resto y conserva la copia antigua hasta confirmar la migración.
3. Nunca escribas una frase semilla existente en ningún sitio web que ofrezca «comprobar» si es vulnerable. Introducir una semilla en cualquier cosa que esté en línea es la manera en que se llevan los fondos restantes; los sitios «verificadores» son un patrón de phishing recurrente después de incidentes como este.

Preguntas frecuentes