Hackeo de Coldcard: Lo que los usuarios de Bitcoin deben saber

El hackeo de Coldcard afecta a la generación vulnerable de semillas en ciertos firmwares de monederos hardware, no a un compromiso de Bitcoin. La falla ocurrió mientras algunos dispositivos Coldcard creaban el secreto del cual se derivan las claves del monedero. El protocolo, la cadena de bloques y el sistema de firmas de Bitcoin continuaron funcionando con normalidad.

Pérdidas estimadas de Coldcard en 4 oleadas de ataque. Según Galaxy Research y CoinDesk. 

El análisis de cadena de bloques disponible al 4 de agosto vinculó 4 oleadas sospechosas de vaciado con aproximadamente 1.815,75 BTC procedentes de 5.294 direcciones potenciales. Con un precio de Bitcoin cercano a los 63.789 $ durante la verificación final, esa cantidad tenía un valor de unos 115,8 millones de dólares. La estimación es provisional: no representa un total oficial de pérdidas, y las 5.294 direcciones no equivalen a 5.294 víctimas confirmadas.

El incidente es inusual porque la explicación técnica principal no requiere que el atacante robe un dispositivo, obtenga una frase de recuperación, infecte el ordenador del usuario ni acceda a los servidores de Coinkite. Según informes, una aleatoriedad débil redujo suficientemente el número de semillas plausibles como para que los atacantes pudieran calcular candidatos sin conexión, derivar sus direcciones y buscar coincidencias en el libro mayor público de Bitcoin.

Ese mecanismo plantea una difícil pregunta sobre la autogestión de Bitcoin. Los monederos hardware siguen siendo valiosos para aislar claves y aprobar transacciones, pero esas protecciones dependen de que el secreto sea impredecible en el momento de su creación. Por tanto, el incidente pone a prueba cuánta confianza depositan aún los usuarios en el firmware, los sistemas de compilación, la revisión de código y un único fabricante de monederos.

Resumen del incidente

• Primer ataque observado: 30 de julio de 2026, aproximadamente entre las 01:10:20 y las 01:51:26 UTC.

• Última pérdida estimada: Aproximadamente 1.815,75 BTC procedentes de 5.294 direcciones potenciales, según la última estimación de cuatro oleadas disponible el 4 de agosto.

• Productos afectados: Semillas generadas en los firmwares especificados Mk2, Mk3, Mk4, Mk5 y Q, sujetas a las condiciones de dados y contraseña indicadas en el aviso de Coinkite.

• Falla técnica principal: La generación de la semilla utilizó una alternativa determinista de números aleatorios por software en lugar de la ruta prevista del generador de números aleatorios (RNG) por hardware.

• Acción inmediata para el usuario: Instalar el firmware corregido antes de crear una semilla completamente nueva, verificar el monedero de reemplazo y migrar los fondos con precaución.

• Principal incertidumbre: Los patrones en la cadena de bloques no pueden confirmar que todas las direcciones señaladas provengan de Coldcard ni mostrar cuántas personas únicas resultaron afectadas.

¿Qué ocurrió en el hackeo de Coldcard?

La primera gran extracción se desarrolló en aproximadamente 41 minutos el 30 de julio. Galaxy Research identificó 1,196 direcciones de origen que transfirieron un total combinado de 1,082.65 BTC durante esa ventana. Una cifra anterior de alrededor de 594.5 BTC proveniente de unas 500 direcciones representaba únicamente una visión parcial del mismo evento inicial, no una cantidad adicional independiente.

Pérdidas acumuladas de Bitcoin vinculadas al incidente de Coldcard por nivel de evidencia a fecha del 3 de agosto de 2026. De Galaxy Research.

 Las transacciones llamaron la atención porque muchas direcciones de origen compartían características coherentes con el patrón de monederos vulnerables. Los fondos se transfirieron rápida y sistemáticamente, lo que sugiere que las claves candidatas y las direcciones financiadas ya habían sido identificadas antes del inicio de la extracción. La cadena de bloques muestra las transferencias y su estructura, pero por sí sola no puede revelar cómo se obtuvo cada clave privada.

Aparecieron agrupaciones adicionales tras la primera divulgación. La estimación acumulada aumentó a unos 1,158.7 BTC procedentes de 2,673 direcciones potenciales tras una segunda oleada sospechosa, y luego a 1,367.05 BTC desde 4,585 direcciones tras una tercera. Una cuarta oleada sospechosa el 3 de agosto añadió aproximadamente 448.7 BTC provenientes de 709 direcciones potenciales, lo que arroja la estimación aritmética actual de 1,815.75 BTC y 5,294 direcciones si los grupos no se superponen.

La secuencia principal fue:

• Marzo de 2021: Un cambio en la integración del firmware introdujo la vía vulnerable para la generación de semillas.

• 30 de julio de 2026: Se produjo la primera gran extracción, y Coinkite publicó un aviso y una explicación técnica.

• 31 de julio – 2 de agosto: El firmware corregido estuvo disponible, el alcance afectado se amplió y se identificaron nuevas oleadas sospechosas.

• 3 de agosto: Una cuarta oleada coincidente con el patrón elevó la estimación observada por encima de los 1,800 BTC.

• 4 de agosto: No se había confirmado ninguna quinta oleada verificada, ni el número final de víctimas, ni un programa de compensación, ni un anuncio sobre fondos recuperados.

El incidente se convirtió en un problema de seguridad de monederos físicos porque los robos sospechosos se originaron en monederos cuyas claves debían permanecer desconectadas. El límite de seguridad no se vulneró mediante extracción remota convencional. En cambio, las pruebas apuntan a una debilidad en una etapa anterior: la creación del secreto que el dispositivo físico estaba diseñado para proteger.

Cómo funcionaba la vulnerabilidad de Coldcard

Una semilla de monedero Bitcoin debe comenzar con entropía suficiente, es decir, información impredecible utilizada para crear las palabras de recuperación y las claves derivadas de ellas. Una semilla BIP-39 correctamente generada de 12 palabras normalmente apunta a 128 bits de entropía. Ese espacio de búsqueda es tan grande que adivinar la semilla mediante fuerza bruta no constituye un ataque práctico.

El diseño previsto del Coldcard obtenía aleatoriedad de fuentes hardware. Sin embargo, durante una integración en 2021 que involucró libNgU, la generación del monedero pasó de ckcc.rng_bytes() a ngu.random.bytes(). Esa ruta terminó en una alternativa determinista dentro de MicroPython en lugar de la implementación hardware específica de números aleatorios esperada por el código del monedero.

El error persistió porque ambas implementaciones RNG exponían una firma de función compatible. La implementación hardware prevista también estaba presente en el binario del firmware, lo que hizo que una revisión limitada pareciera tranquilizadora. Lo que no se verificó fue la ruta completa desde la función de generación del monedero hasta la implementación RNG que realmente proporcionaba su salida.

Una comprobación relacionada en la compilación falló por una razón sutil. La macro relevante se definió con un valor de cero, mientras que la protección verificaba si la macro existía en lugar de si estaba habilitada. Por lo tanto, la compilación finalizó en lugar de detenerse cuando se incluyó el objeto incorrecto.

El análisis preliminar de Coinkite estima un espacio de búsqueda efectivo de aproximadamente 40 bits para Mk2 y Mk3. Los modelos Mk4, Mk5 y Q incorporaron valores adicionales provenientes de sus elementos seguros, aumentando la estimación de la empresa a unos 72 bits, aún por debajo del objetivo previsto de 128 bits. Análisis independientes han examinado límites estructurales más estrictos en la construcción de los modelos posteriores, pero esos hallazgos no deben simplificarse en una afirmación universal de que cada semilla de modelo posterior tuvo exactamente 32 bits de seguridad total.

De la entropía débil a una transacción no autorizada

La cadena técnica puede explicarse sin reproducir un método de ataque:

1. El firmware seleccionó un generador de software determinista en lugar de la ruta prevista del RNG hardware.

2. La semilla resultante provino de un conjunto mucho más pequeño de posibilidades efectivas.

3. Un atacante que comprendiera y restringiera suficientemente el proceso defectuoso podría calcular semillas y claves candidatas fuera de línea.

4. Las direcciones públicas derivadas de esos candidatos podrían compararse con direcciones financiadas visibles en la cadena de bloques de Bitcoin.

5. Un candidato coincidente proporcionaría la clave necesaria para firmar una transacción desde esa dirección.

En ese modelo no se requiere acceso físico porque el atacante no extrae una clave de la billetera. El atacante llega independientemente a la misma clave. La red Bitcoin no puede distinguir la firma del propietario legítimo de otra firma válida creada con una clave privada derivada idénticamente.

Esta explicación está sólidamente respaldada por el historial del firmware, el informe técnico de Coinkite, análisis independientes y los patrones observados en las transacciones. Sigue sujeta a revisión si un análisis posterior modifica la causa raíz, pruebas independientes rechazan las estimaciones de entropía o investigaciones forenses demuestran que una parte significativa de las direcciones sospechosas tuvo un origen no relacionado.

¿Qué dispositivos Coldcard y semillas están afectados?

La exposición se determina principalmente por dónde y cómo se generó la semilla actual, no simplemente por el modelo que un usuario posee hoy. Un dispositivo con firmware corregido aún podría contener una semilla antigua vulnerable. Un dispositivo que alguna vez ejecutó firmware afectado podría contener una semilla segura importada desde otra fuente confiable.

Standard y Edge son ramas de firmware separadas. Una versión anterior de Edge no es segura solo porque su número de versión parezca mayor que una versión de Standard. Los usuarios necesitan la versión corregida correspondiente al modelo y rama que realmente utilizan.

Una semilla vulnerable sigue siendo vulnerable si se restaura en un Coldcard corregido, se importa a otra billetera de hardware o se introduce en software de billetera compatible. Ninguna de esas acciones añade aleatoriedad a las palabras originales. Por el contrario, una semilla generada de forma segura en otro lugar no se debilita simplemente porque luego se haya importado a un Coldcard afectado; esa conclusión se deriva del hecho de que la falla ocurrió durante el proceso de generación de semillas del Coldcard.

Coinkite afirma que TAPSIGNER, OPENDIME y SATSCARD no se ven afectados porque utilizan bases de código distintas. Esa es una declaración específica de producto, no evidencia de que todas las funciones o propiedades de seguridad de esos productos hayan recibido una auditoría independiente.

¿Cuánto Bitcoin fue robado?

 

Eventos conocidos y sospechosos de robo de Bitcoin vinculados a Coldcard por tamaño, fecha y nivel de evidencia a 3 de agosto de 2026. De Galaxy Research. 

La respuesta actual más defendible es una estimación, no un total definitivo. Al 4 de agosto, el cálculo más reciente de 4 oleadas era aproximadamente 1.815,75 BTC, con un valor de unos 115,8 millones de dólares a un precio contemporáneo del Bitcoin cercano a los 63.789 $. La cifra combina las primeras 3 oleadas sospechosas con la estimación de la cuarta oleada y asume que el conjunto más reciente de direcciones no se superpone con los grupos anteriores.

Las cifras cambiaron porque la investigación siguió encontrando actividad adicional. Los informes iniciales capturaron solo parte del primer barrido, mientras que actualizaciones posteriores añadieron nuevas oleadas y refinaron los filtros de direcciones. Los valores en dólares también variaron porque el Bitcoin cotizó entre aproximadamente 62.000 $ y 65.000 $ durante el período de informe.

Una dirección no es lo mismo que una billetera ni que una persona. Un usuario puede controlar muchas direcciones, una semilla puede derivar muchas direcciones y un grupo forense puede incluir falsos positivos. Los patrones en la cadena de bloques pueden mostrar sincronización coordinada, estructura de transacciones, historial de origen y comportamiento del destino, pero no pueden demostrar de forma independiente que cada clave de origen provenga de un Coldcard vulnerable.

Por lo tanto, el número de direcciones debería describirse como direcciones fuente potenciales, no como víctimas confirmadas. No se había publicado ninguna cifra oficial sobre el total de víctimas únicas, dispositivos, semillas o usuarios antes de la fecha límite. Los informes individuales de víctimas pueden respaldar la realidad del incidente, pero no establecen su magnitud completa.

El total podría aumentar sin que haya otra oleada de ataques si los investigadores identifican transacciones antiguas o reciben confirmaciones adicionales de víctimas. También podría disminuir si un conjunto de direcciones se superpone con otro grupo o si análisis posteriores eliminan falsos positivos. Un titular más llamativo y ampliamente difundido no debería reemplazar la estimación actual a menos que se pueda verificar su metodología, la fecha límite utilizada en la cadena de bloques y su conexión con Coldcard.

Por qué actualizar el firmware no es suficiente

El firmware controla lo que hace un dispositivo ahora. Una semilla registra el resultado de lo que hizo el dispositivo cuando se creó esa cartera. Una vez que una aleatoriedad insuficiente ha producido una semilla, una actualización posterior del software no puede ampliar retroactivamente el conjunto del cual provino dicha semilla.

El firmware corregido soluciona la generación futura al excluir la alternativa no intencionada por software y añadir comprobaciones en tiempo de compilación en torno al símbolo RNG. No modifica las palabras de recuperación ya anotadas, ni cambia las claves ya derivadas de ellas, ni hace que un atacante olvide un candidato capaz de reproducirlas.

Mover las mismas palabras a otro dispositivo cambia la ubicación del almacenamiento, no el secreto. Comprar otra cartera y restaurar la semilla afectada produce la misma cartera y las mismas claves. Por lo tanto, el principio oficial de migración es: el parche repara el generador, mientras que la semilla afectada debe sustituirse.

Una nueva semilla creada con el firmware corregido genera una cartera diferente. Los fondos quedan protegidos por el nuevo secreto solo después de haber verificado la dirección receptora y haber transferido allí los bitcoins. Las transacciones no autorizadas confirmadas no pueden revertirse cambiando el firmware ni restaurando una copia de seguridad.

Qué deben hacer ahora los usuarios afectados de Coldcard

La respuesta adecuada depende del origen de la semilla, del firmware utilizado al crearla y de cualquier entropía independiente o protección mediante contraseña adicional. Los usuarios deben basarse en el aviso de seguridad vigente de Coldcard para procedimientos específicos del dispositivo y evitar improvisar bajo presión.

Una secuencia general cuidadosa es:

1. Confirmar el modelo y el historial del firmware. La versión actual no basta; hay que determinar qué firmware generó la semilla con fondos.

2. Establecer el origen de la semilla. Identifique si fue generado en el Coldcard, restaurado desde otro Coldcard afectado o importado desde una fuente independiente.

3. Instale firmware corregido verificado. Use el canal oficial y la versión Standard o Edge correcta para el dispositivo antes de generar un reemplazo.

4. Genere una semilla completamente nueva. No reutilice, modifique ligeramente ni vuelva a importar las palabras de recuperación antiguas como reemplazo.

5. Registre y verifique la nueva copia de seguridad. Revise cuidadosamente las palabras y la información de recuperación antes de enviar fondos.

6. Verifique la huella digital de la billetera y la dirección de recepción. Confirme ambos elementos en la pantalla del dispositivo de confianza, no solo en una computadora o teléfono conectado.

7. Envíe una transacción de prueba pequeña. Use una cantidad suficiente para confirmar el proceso sin mover todo el saldo de inmediato.

8. Confirme la recepción y el control. Verifique que la nueva billetera muestre el pago de prueba y pueda restaurarse o accederse según lo previsto.

9. Mueva el saldo restante. Transfiera solo después de haber verificado el destino y el resultado de la prueba.

10. Conserve la copia de seguridad anterior hasta completar la migración. Retírela solo después de que todo el saldo haya llegado y se haya confirmado la migración.

Los usuarios que ya instalaron el firmware corregido pero conservaron la semilla antigua solo han completado la primera parte. Los usuarios que compraron una billetera nueva y restauraron las mismas palabras no han eliminado la debilidad. El factor decisivo es si los fondos están ahora bajo el control de una semilla nueva generada mediante un proceso corregido o independiente.

El período de migración también crea un riesgo adicional de ingeniería social. Los atacantes pueden aprovechar la urgencia incluso cuando no pueden calcular la semilla de un usuario.

• No use enlaces de firmware no solicitados, herramientas de migración ni servicios de recuperación.

• Nunca introduzca palabras semilla, claves privadas, frases de paso, secuencias de dados ni códigos PIN en un sitio web.

• Rechace cuentas de soporte que soliciten secretos o pidan a los usuarios firmar una transacción no verificada.

• Compruebe si hay sustitución del portapapeles, envenenamiento de direcciones y cambios mínimos en la dirección de destino.

• Verifique la dirección en la pantalla de la billetera física y evite mover todo el saldo antes de que una prueba tenga éxito.

Coinkite también advierte contra tener prisa. Un usuario que pierda la nueva copia de seguridad, seleccione la herramienta de red incorrecta, envíe a una dirección no verificada o maneje mal una frase de paso puede sufrir una pérdida más inmediata que la vulnerabilidad que se intenta solucionar.

¿Fallaron el aislamiento aéreo y los elementos seguros?

El aislamiento físico (air-gapping) y los elementos seguros no impidieron este incidente porque abordan partes distintas del modelo de seguridad. Un air gap está diseñado para reducir la comunicación entre un dispositivo de firma y sistemas conectados a la red. Puede limitar la extracción remota y ayudar a mantener el proceso de firma de transacciones aislado, pero no evalúa la calidad de la aleatoriedad utilizada al crear la billetera.

Un elemento seguro protege el material secreto almacenado contra ciertas técnicas físicas y electrónicas de extracción. Puede custodiar fielmente una clave que, aun así, resulte demasiado predecible. Si otra parte deriva independientemente la misma clave privada, no es necesario sortear el chip ni extraer datos del dispositivo.

Los modelos posteriores de Coldcard sí mezclaron valores adicionales provenientes de 2 elementos seguros en el estado del software. Coinkite afirma que esto elevó el espacio efectivo estimado de búsqueda desde aproximadamente 40 bits en los modelos Mk2/Mk3 hasta unos 72 bits en los modelos Mk4, Mk5 y Q. Esta entrada adicional redujo la gravedad del problema, pero no restableció el objetivo previsto de 128 bits.

La falla ocurrió antes del almacenamiento y la firma. La función de generación de semilla accedió a una fuente incorrecta de aleatoriedad, tras lo cual el dispositivo protegió y utilizó la clave resultante según lo diseñado. El almacenamiento sin conexión no puede corregir un secreto débil, del mismo modo que el aislamiento físico no puede modificar cómo se calculó originalmente dicho secreto.

Esta distinción preserva el valor de la seguridad por capas al tiempo que identifica sus límites. El aislamiento físico, los elementos seguros, la verificación del firmware, las copias de seguridad y la revisión de transacciones resuelven problemas diferentes. Ninguna capa individual puede compensar automáticamente un defecto en la etapa fundamental de generación de claves.

Lo que el incidente revela sobre la generación de semillas

La entropía de la semilla no es una característica secundaria. Es el control que hace significativas todas las protecciones posteriores de la billetera hardware. Una clave privada bien protegida sigue siendo vulnerable si el secreto original proviene de un conjunto lo suficientemente pequeño como para que otra parte pueda buscarlo.

El error en la generación de semillas de Coldcard también muestra por qué la revisión de software criptográfico implica más que leer la función RNG prevista. Los revisores deben confirmar la configuración compilada, los submódulos importados, la resolución de símbolos, la accesibilidad de las llamadas, la mezcla de entropía, el comportamiento ante fallos y el binario final. En este caso, la implementación esperada en hardware existía, pero aparentemente la ruta de generación de billeteras alcanzó una implementación diferente con la misma interfaz.

La transparencia del código fuente sigue teniendo valor porque permite a investigadores independientes inspeccionar los cambios y cuestionar las conclusiones de un proveedor. No demuestra que el código importante haya sido revisado, que el código revisado coincida con cada compilación o que los revisores hayan probado exactamente la ruta ejecutada en un dispositivo en producción. La visibilidad crea la posibilidad de verificación; no proporciona verificación por sí misma.

Por lo tanto, los fabricantes siguen formando parte del modelo de confianza. Los usuarios dependen de ellos para diseñar la ruta de entropía, configurar la compilación, probar las versiones, revelar fallos, firmar el firmware y mantener instrucciones precisas de corrección. Incluso los usuarios técnicamente avanzados rara vez reproducen cada compilación ni auditan una pila criptográfica embebida antes de generar una cartera.

La lección práctica es reducir las consecuencias de un único fallo oculto. Entropía independiente, políticas de firma multi-proveedor, monitoreo en modo solo lectura, recuperación probada y procedencia clara del firmware pueden distribuir el riesgo. Cada medida también añade trabajo y posibles errores, por lo que la arquitectura de seguridad debe ajustarse a la capacidad del usuario para mantenerla de forma fiable.

¿Significa el hackeo del Coldcard que la autogestión es insegura?

El incidente no demuestra que la autogestión de Bitcoin sea criptográficamente inviable. La red de Bitcoin no fue comprometida, las claves generadas correctamente siguen siendo seguras bajo los supuestos actuales y la vulnerabilidad estaba vinculada a una implementación específica y al historial del firmware. La autogestión sigue permitiendo a los usuarios poseer y transferir Bitcoin sin otorgar a un intermediario financiero control unilateral.

Sí muestra, sin embargo, que la autogestión no está libre de confianza. Un usuario de una cartera hardware puede controlar las claves finales y aun así depender de componentes del dispositivo, firmware, bibliotecas, configuraciones de compilación, revisiones de seguridad, documentación y canales de actualización. La frase «verifica, no confíes» describe un objetivo, pero la mayoría de los usuarios no pueden verificar personalmente cada capa necesaria para alcanzarlo.

La crítica más contundente es, por tanto, práctica más que filosófica. Una persona puede seguir el proceso normal de configuración, mantener la cartera desconectada, proteger la copia de seguridad y aun así sufrir un defecto de generación a nivel del fabricante. Considerar ese resultado como un error del usuario ignoraría que la generación segura predeterminada de la semilla es una responsabilidad fundamental del producto.

La defensa más sólida de la autocustodia es que el modelo puede hacerse resistente a fallos individuales de componentes. Una clave creada mediante entropía independiente y sólida no se vio debilitada por este error específico de Coldcard. Una cartera multifirma que requiere una segunda clave independiente podría permanecer segura incluso si una de las firmas era predecible.

Los distintos modelos de custodia distribuyen el riesgo de forma diferente:

• Autocustodia con firma única concentra el riesgo de generación, respaldo y autorización en una sola clave.

• Multifirma con múltiples proveedores reduce el riesgo asociado a un solo dispositivo, pero añade complejidad en la configuración, descriptores, herencia y recuperación.

• Custodia colaborativa puede añadir controles de recuperación y políticas, pero introduce dependencia del proveedor y consideraciones de privacidad.

• Custodia institucional o en exchanges elimina la gestión personal de la semilla, pero añade riesgos de contraparte, acceso, legales y de retiro.

• Fondos cotizados de Bitcoin ofrecen exposición regulada al precio, pero no otorgan posesión directa en cadena ni control sobre las transferencias.

La vulnerabilidad de Coldcard no demuestra que un exchange o fondo sea más seguro para todos los usuarios. Sí aporta evidencia de que las decisiones de autocustodia deben tener en cuenta riesgos de implementación y operativos, no solo el hacking remoto o el robo físico.

Multifirma, frases de paso y entropía generada con dados

Controles adicionales podrían haber cambiado el resultado para algunas carteras, pero ninguno carece de coste. La pregunta relevante es si un control añade una barrera independiente o simplemente repite la misma dependencia vulnerable.

Multifirma con múltiples proveedores puede reducir el riesgo de dispositivos correlacionados. En una configuración 2-de-3, reconstruir una clave generada por Coldcard no basta si la segunda clave requerida se generó de forma independiente y sigue segura. Una configuración en la que suficientes claves del quórum provengan de la misma ruta de generación vulnerable podría seguir estando expuesta.

Una frase de paso BIP-39 deriva una cartera separada a partir de la combinación de la semilla y la frase de paso. Por tanto, una frase de paso fuerte, única y secreta puede añadir una barrera independiente: recuperar únicamente la semilla base débil no revela la cartera protegida por la frase de paso. Coinkite sigue recomendando a los usuarios afectados que usaron frases de paso que migren, ya que la semilla base sigue siendo débil, y una frase de paso corta, con patrones, reutilizada, citada, expuesta o incierta podría ser adivinable.

El PIN de Coldcard no es una frase de paso BIP-39. Un PIN controla el acceso local al dispositivo físico y puede activar comportamientos de seguridad específicos del dispositivo. No modifica la cartera criptográfica derivada de la semilla, por lo que no puede detener a un atacante que calcule la clave en otro lugar.

La orientación actual de Coinkite sobre dados se aplica específicamente a este problema de RNG:

• 50 a 98 tiradas justas, independientes y privadas añadidas durante la creación original de la semilla aportaron al menos 128 bits mediante la entrada de dados, según el cálculo de la advertencia.

• 99 o más tiradas de este tipo aportaron aproximadamente 256 bits.

• Menos de 50 tiradas, recuentos olvidados, secuencias expuestas o procedimientos inciertos no cumplen con la excepción.

Las tiradas deben haberse incorporado mediante el flujo de trabajo original correspondiente, y la semilla financiada final debe ser la generada tras añadir los dados. Los usuarios no deben asumir protección si no pueden verificar esas condiciones. La secuencia de dados también constituye material secreto y no debe fotografiarse, digitalizarse ni introducirse en ningún servicio conectado a una red.

A partir del firmware 4.2.0 para Mk2/Mk3, Coinkite documenta una ruta opcional de reemplazo exclusivamente con dados que requiere al menos 99 tiradas. Esto difiere de la excepción de 50 tiradas para una semilla antigua creada con la función “Añadir tiradas de dados”. La generación normal de semillas en firmware corregido se considera suficiente; los dados manuales son opcionales y añaden sus propios riesgos relacionados con el conteo, la transcripción, la copia de seguridad y la privacidad.

El uso de multifirma, frases de contraseña y entropía independiente puede reducir un modo de fallo, aunque incrementa la carga operativa. La pérdida de una frase de contraseña, un descriptor de multifirma incompleto, un firmante inaccesible o una semilla manual registrada incorrectamente pueden bloquear permanentemente la recuperación. Más controles solo resultan útiles cuando el usuario puede documentarlos, probarlos y mantenerlos.

Cómo afectó el incidente a los mercados de Bitcoin y criptomonedas

La reacción del mercado fue visible, pero difícil de aislar. Bitcoin bajó hasta unos 62.800 dólares el 3 de agosto conforme aumentaban los informes sobre las pérdidas en Coldcard, y luego cotizó cerca de los 63.789 dólares durante la verificación del 4 de agosto. Un movimiento de esa magnitud puede reflejar preocupaciones de seguridad, pero no constituye evidencia de que el incidente por sí solo determinara el precio.

Durante ese mismo periodo, hubo comunicados de la Reserva Federal, cambios en los rendimientos de los bonos del Tesoro, acontecimientos geopolíticos, mayor participación generalizada en criptoactivos y noticias específicas de empresas relacionadas con Bitcoin. Esos factores pueden alterar el valor del dólar, las expectativas de liquidez y el apetito por el riesgo independientemente de los titulares sobre monederos físicos.

Los flujos de los ETF estadounidenses de Bitcoin al contado también fueron mixtos en lugar de uniformemente defensivos. Los productos registraron aproximadamente 233,1 millones de dólares de entradas netas el 30 de julio, 265,4 millones de dólares de salidas netas el 31 de julio y 170,1 millones de dólares de entradas netas el 3 de agosto. Esa secuencia no respalda la afirmación simplista de que los usuarios de Coldcard abandonaran colectivamente la autocustodia a favor de los ETF.

Es probable que las migraciones urgentes hayan aumentado algo la actividad en cadena, pero una transacción que abandona una billetera antigua no constituye automáticamente una venta. Podría estar trasladándose a una nueva dirección de autocustodia, a un custodio colaborativo o a un exchange. Sin etiquetas fiables del destino ni datos posteriores de negociación, el volumen de migración no puede convertirse directamente en presión vendedora.

No se verificó evidencia específica y clara del incidente respecto a entradas agregadas en exchanges, liquidaciones de derivados ni un cambio sostenido en el financiamiento y el interés abierto. El impacto más directo en el mercado fue sobre la confianza en la implementación de billeteras físicas y en el debate sobre la custodia. La economía de red y las reglas monetarias de Bitcoin permanecieron sin cambios.

Una reacción a corto plazo podría revertirse si no aparecen nuevas oleadas, los usuarios completan sus migraciones y la estimación de pérdidas se estabiliza. Podría intensificarse si se confirma un nuevo grupo afectado o si el alcance técnico final se amplía. En cualquier caso, la liquidez macroeconómica y la posición general del mercado podrían seguir siendo factores determinantes del precio más influyentes que el incidente con la billetera.

¿Podría recuperarse el Bitcoin robado?

El libro mayor público de Bitcoin permite a los investigadores rastrear las transacciones posteriores a un robo. Los analistas pueden monitorear direcciones de destino conocidas, identificar patrones de consolidación y señalar depósitos que lleguen a un servicio con registros de clientes o capacidades de control de activos. Esa transparencia puede generar pistas investigativas que no existirían en un sistema de pagos completamente opaco.

Rastrear no es lo mismo que recuperar. Una transacción confirmada de Bitcoin es irreversible a nivel de protocolo, y un analista no puede mover monedas simplemente etiquetando una dirección. La recuperación normalmente requiere que los fondos lleguen a un intermediario cooperativo, una orden judicial contra una parte identificable, el control de las claves relevantes o la devolución voluntaria.

La velocidad y la jurisdicción complican ese proceso. Los fondos pueden dividirse entre múltiples direcciones, transferirse a través de varios servicios o moverse a entidades en países donde la coordinación legal es lenta. Incluso un servicio conocido podría no poder congelar activos que ya han salido de su control.

Coinkite ha pedido a los usuarios afectados que conserven sus dispositivos y señaló que su equipo legal coordinará con las autoridades policiales en distintas jurisdicciones según sea necesario. Esa declaración indica preparación para una posible investigación; no confirma un caso público específico ni garantiza la recuperación de activos.

Hasta el 4 de agosto, ningún anuncio verificado estableció que los bitcoins vinculados a Coldcard hubieran sido incautados, bloqueados, devueltos o recuperados. Los usuarios también deben tener cuidado con estafadores que prometen acceso a fondos robados a cambio de un pago por adelantado o información secreta de la billetera.

La respuesta de Coinkite y las posibles consecuencias legales

Coinkite publicó su primer aviso de seguridad y explicación técnica sobre Coldcard el 30 de julio. Para la revisión del 1 de agosto, ya estaba disponible un firmware corregido para todos los modelos afectados, tanto en las versiones Standard como Edge. La empresa también aclaró las condiciones relacionadas con el lanzamiento de dados y las frases de paso, advirtió que las semillas antiguas siguen expuestas y proporcionó orientación para la migración.

La empresa suspendió los envíos al confirmar la vulnerabilidad y declaró que destruyó el inventario restante con firmware vulnerable. Trabajó directamente con los usuarios, se disculpó públicamente y prometió un análisis técnico post mortem formal. La información actual en su tienda indica que los modelos afectados recién adquiridos se enviarán con el firmware corregido, aunque los dispositivos anteriores aún requieren verificación y actualización por parte del usuario.

Varias preguntas importantes siguen sin responder:

• Coinkite no ha publicado un total oficial de pérdidas ni el número de víctimas únicas.

• No se había anunciado ningún programa de reembolso, compensación, seguro o reclamaciones formales hasta la fecha límite.

• El análisis técnico post mortem completo prometido aún no se había publicado.

• No se había confirmado ninguna investigación policial específica ni número de caso público.

• No se había anunciado ninguna atribución verificada del atacante ni recuperación completada.

Las posibles demandas legales podrían involucrar negligencia, defectos del producto, garantías, información engañosa, omisión de advertencia o normas de protección al consumidor. Una vulnerabilidad en el firmware por sí sola no demuestra que haya causado la pérdida de un usuario en particular. La causalidad podría depender del modelo, del firmware usado para generar la semilla, del uso de dados, de la fortaleza de la frase de paso, de la estructura multisig, del historial de copias de seguridad y de si la semilla fue expuesta por otra vía.

Los términos de Coinkite incluyen exclusiones de garantía, limitaciones sobre daños, disposiciones de arbitraje en Ontario, un plazo de un año para iniciar acciones legales, una renuncia a demandas colectivas y cláusulas que establecen la legislación de Ontario como ley aplicable. Esas cláusulas pueden crear obstáculos significativos, pero su validez puede variar según la jurisdicción, el canal de compra, la legislación de protección al consumidor y el tipo de reclamación presentada.

Abogados estaban evaluando posibles acciones y recopilando información de usuarios afectados, pero no se verificó ninguna demanda presentada ni resolución judicial al 4 de agosto. La formulación precisa es que Coinkite enfrenta reclamaciones legales potenciales, no que se haya establecido responsabilidad ni que exista una demanda colectiva activa.

Lecciones para usuarios de monederos físicos

El incidente respalda una lista de verificación de seguridad más precisa en lugar de una única recomendación universal sobre custodia:

• Verifique la procedencia y versión del firmware antes de generar un nuevo monedero, no solo después de que lleguen fondos.

• Comprenda el origen de la semilla y registre qué dispositivo y versión la crearon.

• Pruebe la recuperación antes de asignar un saldo significativo a una nueva configuración.

• Considere entropía independiente solo si el método puede realizarse y documentarse de forma segura.

• Evalúe multisig con múltiples proveedores para saldos elevados cuando la complejidad operativa sea manejable.

• Use monitoreo de solo lectura para detectar transacciones inesperadas sin exponer las claves de firma.

• Guarde copias de seguridad de las semillas y frases de contraseña por separado e incluya necesidades de herencia y recuperación en el diseño.

• Trate los mensajes urgentes de migración como posibles intentos de phishing, incluso cuando el incidente subyacente sea real.

Estas prácticas abordan distintos riesgos. No hacen que un monedero sea inmune a todo fallo de implementación, cadena de suministro, respaldo, físico o humano. El objetivo es reducir los puntos únicos de falla sin crear una configuración demasiado compleja para que el propietario pueda recuperarla de forma fiable.

Qué vigilar a continuación

Los próximos avances confirmados determinarán si el incidente sigue siendo principalmente una historia de migración de emergencia o si evoluciona hacia responsabilidades y recuperación.

• Una quinta oleada de ataques o un grupo revisado de cuatro oleadas con superposiciones eliminadas.

• Nuevos movimientos desde direcciones destino identificadas o entrada en un servicio identificado.

• Un bloqueo, incautación, devolución voluntaria u otra recuperación verificada.

• La revisión técnica formal de Coinkite y cualquier cambio en el alcance afectado.

• Anuncios de compensación, seguro, reclamaciones, reembolsos o sustitución de dispositivos.

• Una acción policial identificada o atribución del atacante.

• Una demanda presentada, arbitraje, procedimiento regulatorio u orden judicial.

• Más correcciones de firmware o revelaciones que involucren otros secretos generados o productos.

Cada cifra de pérdidas debe conservar una marca de tiempo. Un mayor número de direcciones no necesariamente representa una nueva oleada de robos, y un nuevo monto en dólares puede reflejar únicamente un cambio en el precio del Bitcoin.

Lectura final

El hackeo del Coldcard fue un fallo en la generación de semillas en el firmware afectado. Según informes, el uso incorrecto de la fuente de aleatoriedad redujo el espacio efectivo de semillas, permitiendo a los atacantes reconstruir claves candidatas sin poseer los dispositivos de los usuarios ni sus frases de recuperación. El propio Bitcoin no fue hackeado, y no hay evidencia de que los servidores de Coinkite o los elementos seguros del Coldcard hayan sido vulnerados directamente.

La acción más urgente para un usuario afectado o inseguro es consultar el aviso oficial en vivo, instalar el firmware corregido adecuado, generar una semilla completamente nueva, verificar la billetera de reemplazo y migrar con cuidado. Solo actualizar no puede reparar una semilla débil existente, y restaurar las mismas palabras en otro lugar conserva la exposición.

La autogestión sigue siendo técnicamente viable, pero este incidente muestra que depende de una generación correcta de claves, implementaciones confiables, calidad de las revisiones y un diseño operativo manejable. Las preguntas sin resolver más importantes son cuántas de las 5.294 direcciones potenciales estaban realmente vinculadas a Coldcard, cuántas personas únicas se vieron afectadas, si surgirán más oleadas y si se podrá recuperar algún Bitcoin robado.

Este artículo tiene únicamente fines informativos y educativos. No constituye asesoramiento financiero, de inversión, legal, de ciberseguridad ni comercial. El almacenamiento de criptomonedas implica riesgos de custodia, software, operativos y de seguridad. Verifique siempre las instrucciones específicas del dispositivo a través de los canales oficiales del fabricante y busque asistencia calificada cuando sea necesario.