Los propietarios canadienses de Bitcoin resultaron ser el grupo más numeroso afectado por el ataque continuo a la billetera de hardware Coldcard, representando el 25% de todas las pérdidas relacionadas. Los analistas señalan que esta alta concentración regional de pérdidas coincide con la fuerte presencia local de la empresa matriz de Coldcard, Coinkite, cuya sede central se encuentra en Toronto.
Según un análisis visual de Chainalysis, Australia ocupa el segundo lugar entre los países más afectados por el ataque, representando entre el 15% y el 20% del daño total. Mientras tanto, Estados Unidos y Tailandia le siguen con pérdidas en el rango del 10% al 15%. Aunque la brecha golpeó con más fuerza a los países de habla inglesa y jurisdicciones que adoptaron Bitcoin temprano, los datos sugieren amplias consecuencias globales en Europa Occidental, América Latina y centros cripto clave de África, como Nigeria y Sudáfrica.
El valor total de activos robados en el incidente alcanzó los 116 millones de dólares. Al analizar el incidente, Galaxy Research identificó la actualización de firmware publicada en marzo de 2021—específicamente la implementación de un nuevo generador de números aleatorios—como el único punto de falla que hizo posible el ataque.
"El problema fue que estaba conectado incorrectamente y, por defecto, utilizaba un generador más débil. La falla ocurrió inadvertida, sin ninguna advertencia. Nadie sabía que sus claves privadas se estaban generando con baja entropía", declaró Galaxy Research. "Cinco años después, un atacante robó 70 millones de dólares de 1200 billeteras en 41 minutos".
Explicando por qué las verificaciones estándar no detectaron este error durante más de cinco años, Natalie Newsom, investigadora sénior de blockchain en CertiK, indicó que la causa raíz fue un error de configuración específico: la variable MICROPY_HW_ENABLE_RNG estaba establecida en cero.
"Para una verificación estática #ifndef, un macro establecido en 0 todavía se considera definido", aclaró Newsom. "La verificación de seguridad devolvía verdadero, suprimiendo la protección #error y permitiendo que el sistema de compilación continuara como si todo estuviera configurado correctamente".
Protocolos de respuesta ante incidentes y reparaciones de emergencia
Para prevenir transiciones inadvertidas similares hacia la pseudoaleatoriedad de software, Newsom instó a los fabricantes a revisar sus estándares arquitectónicos. "La forma más robusta de control es eliminar el mecanismo de respaldo del entorno de producción y tener exactamente un proveedor de RNG aprobado", enfatizó, señalando que toda la ruta, desde la obtención de entropía hasta la generación de la semilla, debe adherirse estrictamente a los límites de validación definidos por el estándar NIST FIPS 140-3.
Al hablar sobre la gestión del riesgo operativo asociado con el lanzamiento apresurado de parches de emergencia durante revisiones automatizadas activas, Newsom destacó que la respuesta a incidentes debe priorizar tanto informar a los usuarios como las pruebas técnicas.
"La prioridad debe ser informar inmediatamente sobre el alcance de la vulnerabilidad, identificar a los usuarios afectados y proporcionar instrucciones claras de mitigación de riesgos, mientras se verifica minuciosamente cualquier parche antes de su lanzamiento", declaró Newsom, añadiendo que la transparencia es tan crucial como el propio parche.
Para usuarios no técnicos que posean frases semilla comprometidas y teman inutilizar sus dispositivos durante actualizaciones de firmware de emergencia, Newsom recomendó un protocolo estricto de remediación: primero, los usuarios deben adquirir una billetera de hardware confiable, generar una nueva frase semilla en un entorno sin conexión y verificar la configuración con una pequeña transacción de prueba. Luego, deben transferir todos los fondos restantes a la configuración recién verificada, antes de intentar actualizar el firmware en el dispositivo original.
Newsom también instó a los usuarios a evitar crear un "punto único de falla" utilizando billeteras de hardware de diferentes fabricantes para distribuir el riesgo entre múltiples cuentas.
Un punto de inflexión para la autocustodia
Este incidente ha llevado a la industria de la autocustodia y sus defensores a enfrentarse a preguntas fundamentales sobre sus modelos de seguridad estándar. Los críticos señalan la desaparición repentina de activos inactivos a largo plazo como prueba de que la ejecución sin conexión por sí sola no garantiza una protección absoluta.
Nanak Nihal Khalsa, cofundador de Human.tech, declaró que este incidente subraya la realidad inalterable de los riesgos relacionados con la participación de terceros en los ecosistemas de billeteras de hardware.
"En el lema 'No son tus monedas si no son tus claves' se pasa por alto un hecho importante: siempre estás transfiriendo confianza a terceros, incluso en la autocustodia. Esto solo añade otra evidencia de que la autocustodia no cambia este hecho", comentó Khalsa, advirtiendo que los vectores de amenaza emergentes, como exploits de IA, probablemente exacerbarán estos riesgos.
Newsom de CertiK respaldó las preocupaciones sobre las configuraciones de firma única, señalando que para la adopción masiva se necesitan sistemas construidos con capacidad de degradación elegante, donde un solo error—ya sea del usuario o del proveedor—no resulte en la pérdida de los ahorros de toda una vida del usuario.
"La autocustodia con firma única no deja margen para el error", dijo Newsom. "Los usuarios que dependen de un solo dispositivo están confiando en el hardware físico, el código y todas sus dependencias, así como en las verificaciones de control de calidad diseñadas para detectar cualquier problema".
En consecuencia, el consenso en la industria se está desplazando hacia configuraciones con múltiples proveedores, utilizando firmas múltiples o firmas de umbral (MPC) como estándar base obligatorio.
"Sí, este debería ser el estándar base por defecto", concluyó Newsom. "El objetivo es pasar de 'confiar en un solo dispositivo' a asegurar que ningún componente o parte comprometida pueda mover fondos por sí solo. En la práctica, las claves de firma o las participaciones en la firma de umbral deben abarcar dominios independientes de fallos organizacionales y tecnológicos, de modo que ningún proveedor pueda restaurar una clave o autorizar una transacción de forma independiente".
