Los usuarios canadienses representan el 25 % de las pérdidas causadas por el exploit de Coldcard

Distribución geográfica de las pérdidas

Los titulares de bitcoins canadienses se han convertido en el grupo demográfico más afectado por el actual ataque a la cartera de hardware Coldcard, absorbiendo el 25 % de todas las pérdidas atribuibles. Los analistas señalan que esta fuerte concentración regional coincide con la sólida presencia local de la empresa matriz de Coldcard, Coinkite, cuya sede se encuentra en Toronto.

Según el seguimiento visual de Chainalysis, Australia ocupa el segundo lugar entre los países más afectados, con un porcentaje de entre el 15 % y el 20 % del total de los daños. Por su parte, Estados Unidos y Tailandia les siguen de cerca, con pérdidas que oscilan entre el 10 % y el 15 %. Aunque la brecha de seguridad afectó con mayor dureza a las jurisdicciones de habla inglesa y a las que adoptaron el bitcoin desde el principio, los datos ponen de relieve unas repercusiones globales generalizadas en Europa Occidental, América Latina y centros clave de las criptomonedas en África, como Nigeria y Sudáfrica.

El total de activos robados a raíz del incidente ha alcanzado los 116 millones de dólares. En un análisis de la brecha de seguridad, Galaxy Research identificó una actualización de firmware de marzo de 2021 —concretamente, la implementación de un nuevo generador de números aleatorios— como el único punto de fallo que permitió el ataque.

«El problema fue que se configuró incorrectamente y, por defecto, se utilizó uno más débil. Falló de forma silenciosa, sin previo aviso. Nadie sabía que sus claves privadas se estaban generando con baja entropía», afirmó Galaxy Research. «Cinco años después, un atacante se llevó 70 millones de dólares de 1 200 carteras en 41 minutos».

Al explicar cómo los controles estándar pasaron por alto el fallo durante más de cinco años, Natalie Newson, investigadora sénior de blockchain en CertiK, reveló que la causa principal se debía a un error de configuración específico: MICROPY_HW_ENABLE_RNG estaba establecido en cero.

«Para una instrucción de seguridad estática que comprueba #ifndef, una macro establecida en 0 sigue estando definida», explicó Newson. «La comprobación de seguridad evaluó el valor como verdadero, suprimiendo la instrucción de seguridad #error y permitiendo que el sistema de compilación continuara como si todo estuviera configurado correctamente».

Protocolos de respuesta ante incidentes y corrección de emergencias

Para evitar recurrencias silenciosas similares a la pseudoaleatoriedad del software, Newson instó a los fabricantes a revisar a fondo sus estándares arquitectónicos. «La medida de control más eficaz consiste en eliminar el recurso de reserva de la producción y contar con un único proveedor de RNG homologado», subrayó, señalando que todo el proceso, desde la adquisición de entropía hasta la generación de la semilla, debe situarse estrictamente dentro de los límites de validación definidos por la norma NIST FIPS 140-3.

A la hora de gestionar el riesgo operativo que supone lanzar parches de emergencia a toda prisa mientras se llevan a cabo análisis automatizados activos, Newson subrayó que la respuesta ante incidentes debe dar prioridad a la comunicación con los usuarios, junto con las pruebas técnicas.

«La prioridad debe ser comunicar inmediatamente el alcance de la vulnerabilidad, identificar a los usuarios afectados y proporcionar directrices claras de mitigación, al tiempo que se valida exhaustivamente cualquier corrección antes de su lanzamiento», afirmó Newson, añadiendo que la transparencia es tan fundamental como el propio parche.

Para los usuarios sin conocimientos técnicos que posean frases semilla comprometidas y teman que sus dispositivos queden inutilizables durante las actualizaciones de firmware de emergencia, Newson recomendó un protocolo de corrección estricto: en primer lugar, los usuarios deben adquirir un monedero de hardware de confianza, generar una nueva frase semilla sin conexión y verificar la configuración con una pequeña transacción de prueba. A continuación, deben transferir todos los fondos restantes a la configuración recién verificada antes de intentar realizar cualquier actualización de firmware en el dispositivo original. Newson también instó a los usuarios a evitar crear un único punto de fallo utilizando monederos de hardware de diferentes fabricantes para repartir el riesgo entre varias cuentas.

Un punto de inflexión para los argumentos a favor de la autocustodia

El incidente ha dejado al sector de la autocustodia y a sus defensores enfrentándose a cuestiones fundamentales sobre los modelos de seguridad estándar. Los críticos señalan la repentina pérdida de activos inactivos a largo plazo como prueba de que la ejecución fuera de línea por sí sola no garantiza una protección absoluta.

Nanak Nihal Khalsa, cofundador de Human.tech, argumentó que el incidente pone de relieve la realidad persistente del riesgo de terceros dentro de los ecosistemas de hardware. «La frase “Si no son tus claves, no son tus monedas” pasa por alto un hecho importante: siempre estás externalizando la confianza, incluso con la autocustodia. Esto no hace más que añadir otra prueba más de que la autocustodia no cambia ese hecho», observó Khalsa, advirtiendo de que los vectores de amenaza emergentes, como los ataques asistidos por IA, probablemente agravarán estos riesgos.

Newson, de CertiK, se hizo eco de las preocupaciones relativas a las configuraciones de firma única, señalando que la adopción generalizada requiere sistemas diseñados con una degradación gradual, en los que un solo error —ya sea del usuario o del proveedor— no acabe con los ahorros de toda una vida del usuario.

«La autocustodia con firma única no ofrece ningún margen de error», afirmó Newson. «Los usuarios que dependen de un único dispositivo confían en el hardware físico, el código y todas sus dependencias, así como en los controles de control de calidad para detectar cualquier problema».

En consecuencia, el consenso del sector se está desplazando hacia configuraciones con múltiples proveedores, multifirma o de firma por umbral (MPC) como requisito básico imprescindible. «Sí, debería ser el estándar por defecto», concluyó Newson. «El objetivo es pasar de “confiar en un único dispositivo” a garantizar que ningún componente o agente comprometido pueda mover los fondos. En la práctica, las claves de firma o las cuotas de umbral deben abarcar ámbitos independientes de fallo organizativo y tecnológico, de modo que ningún proveedor pueda reconstruir la clave ni autorizar una transacción por sí solo».