Bitcoin Análisis

La falla de Coldcard comenzó al crear la clave

Coldcard aislaba la clave de internet, pero algunas seeds nacieron predecibles. Los usuarios expuestos deben crear una billetera nueva y mover los fondos.

Una billetera física negra abierta sobre piedra oscura, con una fila de llaves metálicas idénticas saliendo del dispositivo, junto al texto Clave predecible.
Ilustración editorial sobre la falla que volvió predecible la generación de claves en algunas versiones de Coldcard.

En 30 segundos

  • Una falla hizo que algunos dispositivos Coldcard crearan seeds predecibles. Los investigadores estiman hasta 1.816 BTC retirados de más de 5.200 direcciones desde el 30 de julio.
  • Coldcard es una billetera física de Bitcoin, pero aislarla de internet no protege una clave que ya nació predecible.
  • Los usuarios expuestos deben actualizar el firmware, crear una seed nueva, probar la dirección y migrar los fondos. Actualizar sin cambiar la seed no resuelve el problema.

Una falla en el software de Coldcard hizo que algunos dispositivos crearan claves predecibles. La estimación llega a 1.816 BTC retirados de más de 5.200 direcciones desde el 30 de julio, cerca de US$ 114 millones. La cuarta ola fue atribuida solo por patrones on-chain, sin relatos directos de víctimas al corte, por lo que el total sigue siendo provisional. El 4 de agosto, Coldcard afirmó que la amenaza seguía activa.

Coldcard es una hardware wallet, o billetera física, fabricada por Coinkite para guardar y mover bitcoin. El saldo continúa registrado en la red Bitcoin. El dispositivo protege la clave privada y firma transferencias sin exponer ese secreto a la computadora o a internet.

El ataque explotó una falla anterior: la creación de la clave. Un error hizo que el dispositivo usara números predecibles para generar la frase semilla, o seed. Esa lista de palabras da origen a las claves y direcciones. En algunos casos, la poca aleatoriedad reducía el trabajo para recuperar la clave fuera del dispositivo.

La seed era el punto de falla

Autocustodia significa que el usuario, y no un exchange o banco, controla las claves. La seed funciona como el respaldo maestro. Las palabras, junto con una eventual passphrase, permiten reconstruir la billetera en otro dispositivo y mover los fondos. La passphrase es una contraseña adicional opcional. Por eso, estos secretos deben mantenerse fuera de servicios digitales y lejos de terceros.

Según el análisis técnico de Block, el firmware usó un generador de software en lugar del generador físico de números aleatorios del chip. El resultado parecía aleatorio, pero tenía menos posibilidades.

En los Mk2 y Mk3 afectados, el proceso no agregaba entropía criptográfica, la imprevisibilidad necesaria para crear una clave segura. En Mk4, Q y Mk5, Coinkite estima preliminarmente un espacio efectivo de búsqueda de 72 bits, por debajo del objetivo de 128 bits. Block afirma que apenas 32 bits de material seguro reiniciaban el generador; el estado de los temporizadores todavía dificultaba reproducir el proceso. Un espacio menor exige menos intentos.

Aun así, una dirección pública sola no bastaba. Según Block, el atacante necesitaba acotar la identidad del dispositivo, el estado de sus temporizadores y el historial de llamadas al generador. Después, una dirección o una clave pública extendida, llamada xpub, permitía validar candidatos. Si encontraba la clave correcta, esta autorizaba la transferencia. Block no publicó un benchmark integral del proceso.

Quién debe actuar

La exposición depende de la versión instalada cuando se creó la seed. Actualizar el dispositivo después no cambia las palabras antiguas. Transferir la misma seed a otra hardware wallet también arrastra el problema.

Modelo Seed potencialmente afectada Versión corregida antes de generar una seed nueva
Mk2 o Mk3 Coinkite: 4.0.1 a 4.1.9; Block incluye 4.0.0 4.2.0 o posterior
Mk4 o Mk5 standard anterior a 5.6.0 5.6.0 o posterior
Mk4 o Mk5 Edge anterior a 6.6.0X 6.6.0X o posterior
Q standard anterior a 1.5.0Q 1.5.0Q o posterior
Q Edge anterior a 6.6.0QX 6.6.0QX o posterior

Fuentes: alerta oficial de Coinkite y análisis de Block. Ante dudas sobre la versión 4.0.0 o el firmware utilizado al crear la seed, la conducta conservadora es migrar.

Block sitúa al Mk1 y los firmwares Mk2/Mk3 hasta 3.2.2 fuera de la regresión. Coinkite afirma que Opendime, Tapsigner y Satscard no fueron afectados. El generador débil también alcanzó billeteras de papel, claves sueltas, máscaras de seed y algunas contraseñas; quien haya usado estas funciones debe consultar la alerta completa.

Según Coinkite, dos medidas redujeron la exposición. Quien agregó al menos 50 lanzamientos de un dado físico equilibrado, independientes y privados, mediante la función Add Dice Rolls conservó al menos 128 bits de entropía aportada por los dados para este problema específico. Una passphrase BIP-39 fuerte y exclusiva también creó una barrera adicional. No es el PIN del dispositivo. Incluso con passphrase, el fabricante recomienda migrar; la excepción de 50 lanzamientos válidos no exige migración por esta falla.

Ninguna de las tres primeras olas observadas alcanzó billeteras multisig, que exigen más de una firma. Esto no demuestra que todo esquema multisig esté protegido. Si hay suficientes claves vulnerables para alcanzar el umbral de firmas, el atacante todavía puede formar el quórum. Para esta falla, debe haber menos claves vulnerables que el umbral necesario para gastar.

La corrección exige una billetera nueva

La guía oficial debe seguirse con calma. Una migración apresurada puede crear otro error, como enviar el saldo a una dirección incorrecta o perder el nuevo respaldo.

  1. Confirme el modelo e instale la versión corregida correspondiente. Standard y Edge son líneas diferentes.
  2. Genere una seed totalmente nueva después de actualizar. No reutilice las palabras antiguas.
  3. Anote y verifique el respaldo en un entorno privado. Nunca fotografíe la seed, la guarde en la nube ni la escriba en un sitio que prometa verificar la billetera.
  4. Verifique en la pantalla de la propia Coldcard la dirección de recepción de la billetera nueva.
  5. Envíe primero un monto pequeño y confirme que llegó al destino correcto.
  6. Solo entonces transfiera el resto y espere las confirmaciones en la red.
  7. Conserve el respaldo antiguo únicamente hasta comprobar que la migración terminó.

Según Coinkite, el firmware corregido ya puede generar una seed nueva mediante el flujo normal, sin lanzamientos de dado. Usar un dado físico es una opción avanzada y no es necesario para corregir este problema; improvisar el procedimiento puede crear riesgo operativo. La prioridad es usar la versión correcta y confirmar cada paso.

Cómo comparar las formas de custodia

Elegir una forma de custodia exige comparar puntos de falla. Una hardware wallet reduce la exposición a virus en la computadora, pero todavía depende de la calidad del generador de claves, las actualizaciones y la disciplina de respaldo.

Modelo Ventaja Principal riesgo
Una hardware wallet mantiene una sola clave privada fuera de la computadora una clave, un fabricante y la disciplina del usuario se convierten en puntos de falla
Multisig con claves y dispositivos independientes reduce la dependencia de una sola clave; solo reduce la dependencia de una sola marca cuando usa fabricantes distintos la configuración, el respaldo y la recuperación son más complejos

Fuentes: Bitcoin.org y análisis de Block.

La elección depende del modelo de amenaza y de la capacidad para mantener respaldos, actualizaciones y recuperación, no solo del monto. Una hardware wallet actualizada puede servir para un proceso simple y bien probado. Un multisig puede reducir la dependencia de una sola clave cuando hay menos claves vulnerables que el umbral de gasto y las claves seguras fueron generadas y guardadas de forma independiente.

Para seguir el caso, importan tres señales: la revisión de la estimación de 1.816 BTC, la publicación de un post-mortem técnico de Coinkite y nuevas salidas de fondos desde direcciones vinculadas con las seeds vulnerables. El escenario base es que la exposición permanezca concentrada en las versiones y funciones ya identificadas. La evidencia de otros firmwares afectados invalidaría esta lectura.

Para quienes usan Coldcard, la decisión inmediata depende del firmware que generó la seed, no de la versión instalada hoy. Para los demás inversionistas, el caso muestra el límite de la hardware wallet: mantener la clave fuera de línea reduce un tipo de ataque, pero la seguridad también depende de cómo se creó, guardó y sustituyó la clave.

Análisis completo
LATAM ALPHA

Reciba el Resumen semanal

Una lectura útil por semana. Gratis y sin spam.