Cuando falla la aleatoriedad: el fallo de entropía de Coldcard y lo que cambian dos dispositivos

A finales de julio de 2026, unos atacantes empezaron a vaciar bitcoin de miles de hardware wallets que no habían hecho nada mal. Sus dueños habían seguido los consejos. Habían comprado un dispositivo dedicado a firmar, habían mantenido la semilla fuera de línea, nunca la habían tecleado en una web. Nada de eso importó, porque la semilla que aquellos dispositivos generaban nunca había sido tan aleatoria como parecía.

Unos 1.816 BTC salieron de más de 5.200 direcciones en cuatro oleadas. Se convirtió en el mayor exploit de hardware wallets del año.

Este artículo no es una vuelta de honor. El fallo implicado es de los que podrían haberle ocurrido a casi cualquier wallet, incluida la nuestra, y la pregunta interesante no es quién lo publicó, sino qué hace la arquitectura de una wallet cuando ocurre.

Qué salió mal exactamente

Un único commit, en marzo de 2021.

El diseño de Coldcard exigía que las semillas se generaran a partir de un generador de números aleatorios por hardware: un chip dedicado que produce entropía a partir de procesos físicos. Esa es la manera correcta de hacerlo. Pero un cambio en el firmware 4.0.1 hizo que la generación de semillas pasara en su lugar por un generador pseudoaleatorio por software sembrado con constantes públicas y fijadas en el código.

Un PRNG es determinista por definición. Dado el mismo valor de partida, produce siempre la misma secuencia. Así que una semilla generada de este modo no es un número que nadie pueda adivinar: es un número extraído de un conjunto lo bastante pequeño como para recorrerlo, usando constantes que llevaban todo el tiempo en el firmware publicado.

Los dispositivos siguieron comportándose con normalidad. Mostraban veinticuatro palabras, se anotaban, derivaban direcciones correctas, firmaban transacciones válidas. No hay pantalla en ninguna wallet que te muestre cuánta entropía entró en tu semilla. Cada usuario afectado tenía un dispositivo que parecía y se comportaba exactamente igual que uno que funciona, durante hasta cinco años.

La ventana va desde el firmware 4.0.1 de marzo de 2021 hasta el 4.1.9 de julio de 2026. Actualizar el firmware arreglaba la generación de ahí en adelante y no hacía absolutamente nada por las semillas ya creadas: esas claves ya eran débiles, y ninguna actualización puede añadir retroactivamente aleatoriedad a un número que ya está escrito en una tarjeta dentro de la caja fuerte de alguien. Los usuarios afectados tuvieron que generar una semilla nueva y mover sus monedas.

Por qué la aleatoriedad débil es una pérdida total y silenciosa

Vale la pena ser preciso sobre por qué esta clase de fallo es tan grave, porque no resulta intuitivo.

Una semilla BIP-39 de 24 palabras representa 256 bits de entropía. Adivinar una no es meramente difícil, es inimaginable: no existe ordenador, presente ni futuro, que recorra ese espacio por fuerza bruta. Este es el cimiento sobre el que descansa todo el modelo de autocustodia: tu clave está a salvo porque es una entre un número incomprensiblemente grande de posibilidades.

Esa garantía no es una propiedad de las palabras. Es una propiedad del proceso que las eligió. Veinticuatro palabras extraídas de un generador débil son idénticas a veinticuatro palabras extraídas de uno fuerte. Pasan todas las sumas de verificación, producen direcciones válidas y se restauran perfectamente en cualquier wallet. La única diferencia es que otra persona también puede llegar a ellas.

Así que el fallo es invisible desde dentro, y es completo. No es «un atacante podría robarte si cometes un error»: no hay error que evitar, ni enlace de phishing que rechazar, ni diálogo de confirmación que leer con cuidado. El dinero es tomable cuando al atacante le venga bien, y la primera señal de que algo iba mal es que ya no está.

Qué cambian dos dispositivos

Esta es la parte que importa arquitectónicamente, y quiero enunciarla con precisión en vez de con términos de marketing.

SSP es un multifirma 2 de 2. Los fondos viven en una dirección controlada por dos claves independientes, generadas en dos dispositivos independientes —una en la extensión del navegador, otra en la app móvil SSP Key— y una transacción exige ambas firmas. El esquema de dos de dos es la base entera de la wallet.

Ahora aplica el escenario de Coldcard a esa estructura. Supón que la generación de semillas de la extensión tuviera el mismo fallo y que un atacante pueda derivar por completo tu clave del navegador.

Aun así no puede gastar nada. Tiene una de las dos firmas requeridas. La dirección no libera fondos por una sola clave, sea de quien sea y como quiera que la haya obtenido. Para mover tus monedas necesitaría romper además, de forma independiente y simultánea, la clave de tu teléfono: otra aplicación, otro sistema operativo, otra fuente de entropía, generada en otro momento.

Esa es la diferencia estructural. En una wallet de clave única, una semilla débil es una pérdida total. En un 2 de 2, una semilla débil es un problema serio que no es, por sí solo, una pérdida.

La salvedad, dicha claramente

Sería fácil parar aquí y dejarte concluir que SSP es inmune a esto. No lo es, y fingir lo contrario durante el incidente de otro sería justo el peor momento para hacerlo.

Ambas aplicaciones de SSP usan la misma implementación de BIP-39 —@scure/bip39, fijada a la misma versión en las dos—. Un fallo en esa biblioteca afectaría a ambas claves. La independencia que te da SSP es real pero específica: dos semillas separadas, generadas en momentos distintos en dispositivos distintos, que toman entropía de fuentes distintas del sistema operativo —la Web Crypto del navegador por un lado, el CSPRNG de la plataforma móvil por el otro—. No es la independencia de dos bases de código completamente ajenas.

Lo que eso compra es protección frente al modo de fallo que de hecho ocurrió en Coldcard: un error de implementación específico de un dispositivo en cómo un producto generaba sus semillas. No protegería frente a un defecto en la primitiva criptográfica compartida por debajo de ambas.

Esa es una afirmación bastante más débil que «esto no puede pasarnos», y es la verdadera. Quien te diga que su wallet es categóricamente inmune a un fallo de entropía te está hablando de su marketing, no de su arquitectura.

Qué llevarse de todo esto

Si tienes una Coldcard de esa ventana de firmware, la única suposición segura es que la semilla está comprometida, se hayan movido fondos o no. Genera una nueva con firmware parcheado y migra. Un dispositivo que aún no ha sido vaciado no es un dispositivo seguro.

Si usas cualquier wallet de clave única, este es el riesgo que llevas encima, y conviene ser consciente de él más que angustiarse. Las hardware wallets siguen siendo enormemente mejores que las alternativas para la mayoría de la gente. La lección no es que sean malas; es que una sola clave es un único punto de fallo, y cada parte de la historia de esa clave —incluido el momento en que nació, hace años, en un firmware que no leíste— forma parte de tu modelo de amenazas.

Y en general, prefiere arquitecturas donde que una cosa salga mal no sea suficiente. Ese principio es la razón de que SSP exija dos dispositivos, de que algunas operaciones exijan volver a firmar aunque ya estés autenticado, y de que qué detiene realmente una transacción sea una pregunta que vale la pena hacerle a cualquier wallet en la que confíes. La respuesta nunca debería ser «un secreto, y la esperanza de que se generara bien».

Para una comparación más amplia de las opciones y de lo que cada una protege de verdad, comparar opciones de autocustodia cubre los compromisos.