¿Fue la IA la responsable de descubrir la vulnerabilidad de seguridad de Coldcard?

Una operación coordinada vacía cientos de carteras

El incidente se hizo público después de que, el 30 de julio, se transfirieran aproximadamente 594 BTC —valorados en cerca de 38 millones de dólares en ese momento— desde unas 500 direcciones de bitcoin de firma única. Cuando se dio a conocer la noticia, Bitcoin.com News señaló que las transferencias se produjeron en unos 25 minutos y parecían tener como objetivo carteras con una vulnerabilidad técnica común.

Posteriores análisis de la cadena de bloques ampliaron la posible magnitud del robo. Los investigadores estimaron que entre 1.082 y 1.196 direcciones podrían haber resultado afectadas durante un periodo de unos 41 minutos. Posteriormente, un panel de control personalizado llamado Coldcard Sweep Watch situó el total en 1 128,4717 BTC, con un valor aproximado de 71,1 millones de dólares cuando el bitcoin cotizaba en torno a los 63 044 dólares.

La mayor parte de los fondos se consolidaron en una dirección que albergaba cientos de bitcoins, donde una gran parte permaneció prácticamente inmóvil. Las direcciones afectadas tenían en común un detalle importante: sus semillas de recuperación se habían creado en carteras de hardware Coldcard fabricadas por la empresa canadiense Coinkite.

Una frase de recuperación es una lista de palabras que controla el acceso a una cartera de criptomonedas. Cualquiera que pueda reconstruir u obtener esa frase suele poder mover los fondos de la cartera sin necesidad de poseer el dispositivo físico.

Coldcard detecta un fallo en el sistema de aleatoriedad

Coinkite emitió un aviso urgente en el que advertía de que ciertas semillas generadas en dispositivos Coldcard podrían ser vulnerables. Los dispositivos Mk3 que ejecutaban la versión 4.0.1 del firmware, lanzada alrededor de marzo de 2021, y las versiones posteriores se encontraban entre los que corrían mayor riesgo.

Un análisis más detallado amplió la preocupación a las semillas creadas en algunos dispositivos Mk4, Mk5 y Q antes de que Coinkite lanzara parches de firmware de emergencia. Según se informó, los productos de Tapsigner, Opendime y Satscard no se vieron afectados, ya que utilizan un software diferente.

La vulnerabilidad afectaba al proceso utilizado para generar datos aleatorios. Las carteras seguras dependen de una aleatoriedad de alta calidad para que sus semillas de recuperación no puedan ser adivinadas. En los dispositivos Mk3 más gravemente afectados, los investigadores estimaron que la semilla podría haber contenido solo unos 40 bits de aleatoriedad efectiva, en lugar de los 128 bits previstos.

Esa diferencia es crucial. Se considera prácticamente imposible adivinar mediante fuerza bruta una semilla de 128 bits generada correctamente. Una semilla de 40 bits ofrece un número de posibilidades drásticamente menor, lo que permite a un atacante con suficiente potencia de cálculo probar posibles semillas sin conexión y comparar las direcciones resultantes con la cadena de bloques pública de Bitcoin.

Es posible que algunos dispositivos más recientes hayan proporcionado aproximadamente 72 bits de aleatoriedad efectiva, ya que el hardware seguro añadía otra capa de datos impredecibles. Eso haría que las semillas fueran más difíciles de reconstruir, aunque seguirían siendo mucho más débiles de lo previsto.

Un error de configuración que perduró durante 5 años

El problema comenzó con un error de configuración durante la compilación que afectaba a dos funciones de software que realizaban tareas similares. Una función utilizaba el generador de números aleatorios verdaderos basado en el hardware del dispositivo, mientras que la otra se basaba en un proceso de software más débil heredado de MicroPython.

Coinkite tenía la intención de desactivar la opción de MicroPython. Sin embargo, una comprobación del software solo verificaba si se había definido una etiqueta de configuración, en lugar de si su valor se había establecido en cero. Como resultado, el firmware final podía seleccionar silenciosamente la función más débil.

Dado que las dos funciones tenían formatos coincidentes, el software continuó compilándose y ejecutándose sin producir ningún error evidente. El error se introdujo en el código en torno a una migración de software realizada en 2021 y permaneció en el firmware disponible públicamente durante más de cinco años.

Actualizar el dispositivo ahora no refuerza una semilla que se generó con el software defectuoso. Los usuarios afectados deben crear una semilla completamente nueva utilizando el firmware corregido u otro dispositivo seguro, y luego transferir sus fondos a direcciones controladas por esa nueva semilla.

Los usuarios que añadieron al menos 50 tiradas de dados independientes al crear su semilla pueden haber aportado suficiente aleatoriedad adicional como para evitar esta vulnerabilidad. Una contraseña BIP-39 sólida también podría haber dificultado la reconstrucción, mientras que las carteras que requieren firmas de varios dispositivos independientes podrían haber impedido que una semilla comprometida moviera fondos por sí sola.

Coinkite apunta a la IA, pero aún faltan pruebas

El director ejecutivo de Coinkite, Rodolfo Novak, se disculpó públicamente y afirmó que la empresa asumía toda la responsabilidad por el fallo del firmware. Indicó que el equipo estaba trabajando en una versión corregida del software, en informes técnicos y en la asistencia a los usuarios afectados.

Coinkite y Novak también plantearon una teoría llamativa sobre cómo se descubrió el fallo. Dado que su firmware llevaba años disponible públicamente, la empresa afirmó que creía que alguien podría haber utilizado la IA para examinar versiones anteriores del código y localizar la ruta de aleatoriedad débil. «A todos los demás desarrolladores: creemos que esta es una cruda realidad del nuevo paradigma de la IA. La revisión de código asistida por IA ahora puede detectar errores latentes a una velocidad que supera incluso a la de los expertos más experimentados del sector», escribió Novak en su publicación de disculpa publicada en X. «Si tu firmware es de código abierto o ha estado alguna vez a la vista del público, da por hecho que ya lo están analizando tanto los atacantes como los defensores».

Los modernos sistemas de codificación con IA actuales pueden procesar grandes repositorios de software e identificar relaciones sospechosas entre ajustes de configuración, funciones y supuestos de seguridad. Un atacante podría pedir a un sistema de este tipo que buscara específicamente generadores de números aleatorios débiles, funciones de reserva o errores que afecten a las claves criptográficas.

Posteriormente, investigadores independientes informaron de que habían utilizado modelos de IA para localizar o explicar el problema una vez que se conoció el problema de aleatoriedad subyacente. Esto demostró lo accesible que se ha vuelto el análisis de código asistido por IA, pero no demostró que el atacante original utilizara IA.

Coinkite reconoció que su propia revisión, realizada con un modelo de IA líder, no logró detectar el fallo antes del robo. Este resultado demuestra que los sistemas de IA no detectan automáticamente todos los defectos graves. Su rendimiento puede depender de las instrucciones que reciban, de la cantidad de código proporcionado y de si un revisor humano comprende las señales de alerta.

Los críticos afirman que el error humano fue lo primero

Algunos especialistas en seguridad sostienen que centrarse en exceso en la inteligencia artificial (IA) conlleva el riesgo de desviar la atención de un fallo básico de ingeniería. Muchos creen que el error de configuración era un tipo conocido de error de software, y que las revisiones de código convencionales, los procedimientos de prueba o las auditorías centradas en la generación de semillas podrían haberlo detectado años antes.

Las opiniones opuestas no son necesariamente incompatibles. Un error humano creó la vulnerabilidad y permitió que persistiera, mientras que la IA podría haber reducido el coste de encontrarla, comprenderla o explotarla. Los defensores deben identificar todas las debilidades peligrosas, mientras que un atacante solo necesita localizar una.

El incidente también pone en tela de juicio las suposiciones sobre la seguridad del código abierto. El código público permite a expertos independientes inspeccionar el software, pero la mera disponibilidad no garantiza que alguien revise la sección correcta, reconozca un defecto sutil y lo notifique antes de que un atacante actúe.

Para los usuarios de Coldcard, la prioridad inmediata es determinar cuándo y cómo se creó su semilla. Cualquier persona con una semilla afectada debe verificar las instrucciones a través de los canales oficiales de Coinkite, instalar el firmware corregido, crear una nueva semilla y transferir los fondos con cuidado, estando atento a los intentos de phishing y a los mensajes falsos de asistencia técnica.

Las cuestiones a más largo plazo se centrarán en cuánto bitcoin se sustrajo, si los investigadores pueden identificar al atacante y si la IA desempeñó algún papel decisivo en la detección de la vulnerabilidad. Las empresas de carteras de hardware también se verán presionadas para reforzar las pruebas de entropía, auditar las configuraciones de compilación y examinar continuamente el código antiguo tanto con expertos humanos como con herramientas de IA adversaria.