Las tarjetas "cold" ahora requieren la introducción manual de la clave 65 veces después de una vulnerabilidad relacionada con las "seeds"... Es obligatorio migrar las carteras existentes

La empresa CoinKite, fabricante de billeteras de hardware para Bitcoin, anunció el 20 de agosto el lanzamiento de un nuevo firmware estándar para Coldcard. Esta actualización se centra en obligar a los usuarios a introducir manualmente la aleatoriedad física durante el proceso de generación de la semilla. Los usuarios deben realizar obligatoriamente una de las siguientes acciones: introducir al menos 65 caracteres de una clave con intervalos impredecibles, lanzar un dado de seis caras 50 veces, o lanzar una moneda 128 veces. Este requisito tiene como objetivo reducir el riesgo de depender únicamente del generador de números aleatorios (RNG) de la billetera. Las versiones a las que se aplica esta recomendación son muy variadas. Para los modelos Mk2 y Mk3, se recomienda el firmware desde la versión 4.0.1 hasta la 4.1.9. Para los modelos Mk4 y Mk5, se recomienda el firmware estándar inferior a la versión 5.6.0 y el firmware "Edge" inferior a la versión 6.6.0X. Para los dispositivos "Q", se recomienda el firmware estándar inferior a la versión 1.5.0Q y el firmware "Edge" inferior a la versión 6.6.0QX. Un análisis técnico independiente realizado por Block reveló que las recomendaciones deberían extenderse incluso a la versión 4.0.0 de los modelos Mk2 y Mk3, y advirtió que no se puede confiar únicamente en los estándares de seguridad proporcionados por el fabricante. La causa fundamental de esta vulnerabilidad reside en el código de respaldo (fallback) de MicroPython. Según el análisis de Block, una función definida como "0" se interpretó como "existente", lo que permitió que las solicitudes de generación de números aleatorios se redirigieran a un mecanismo de respaldo determinista. Esto provocó una importante vulnerabilidad de seguridad, ya que, en casos donde se generaba una semilla sin suficiente entropía externa, la seguridad se veía comprometida. La imposición de entradas físicas tiene como objetivo limitar el daño, incluso si la generación de números aleatorios del dispositivo falla en el futuro, pero no puede aplicarse retroactivamente a las semillas ya generadas. Esta actualización incluye, además de la generación de semillas, varias mejoras de seguridad. Se ha vinculado la revisión de USB a la suma de comprobación PSBT paso a paso, se vuelve a verificar el tamaño de los bytes de la transacción antes de la firma, y se bloquea el modo SIGHASH_SINGLE de forma predeterminada. La descarga de USB se limita ahora a los resultados de la sesión encriptada actual, y se han añadido funciones para verificar la longitud de los archivos de firmware, detener las fallas persistentes del generador de números aleatorios (RNG) y verificar la conexión del hardware RNG al inicio. La obligación de migración tiene una excepción. Los usuarios que estaban utilizando un firmware vulnerable y que hayan lanzado la moneda al menos 50 veces en condiciones justas, independientes y confidenciales, están exentos de la migración. Sin embargo, si el número de lanzamientos es insuficiente o no se tiene certeza sobre el cumplimiento de las condiciones, es obligatorio generar una nueva semilla y transferir los fondos. La guía oficial de CoinKite recomienda seguir los siguientes pasos para generar una nueva semilla: realizar una copia de seguridad, verificar la huella digital de la billetera, confirmar la dirección de recepción en el dispositivo, realizar una pequeña transferencia de prueba y, posteriormente, transferir el saldo completo. La clonación o restauración de una billetera no se considera como la generación de una nueva semilla. Coinstrike ha declarado que algunos clientes han sufrido graves pérdidas y que las autoridades están investigando el caso. Sin embargo, no ha revelado el número exacto de víctimas ni el importe total de las pérdidas. Además, ha aclarado que los elementos de verificación actualmente disponibles (revisión del código fuente, pruebas del camino del generador de números aleatorios en dispositivos reales, compilaciones reproducibles y seguimiento del camino de los dados) no constituyen una auditoría completa de todo el código modificado.