Artículo escrito por Liam 'Akiba' Wright
Compilado por Saoirse, Foresight News
Antes de que los monederos de hardware se conectaran a la red, la línea de defensa de seguridad del monedero ya podría haberse visto comprometida. Un monedero de hardware aislado podría mantener las claves privadas alejadas de Internet durante años, pero el riesgo ya se ha sembrado desde el momento en que se genera la semilla de recuperación.
La vulnerabilidad de números aleatorios recientemente revelada por Coldcard confirma perfectamente este riesgo de seguridad. Las billeteras afectadas pueden generar una frase de recuperación de 12 o 24 palabras que parece completamente normal; los usuarios pueden almacenar adecuadamente esta frase y firmar transacciones sin conexión. Sin embargo, el rango del generador de números aleatorios subyacente se reduce drásticamente. Los atacantes pueden realizar una búsqueda exhaustiva de todas las combinaciones posibles de semillas en otros dispositivos, recuperar las semillas candidatas y luego compararlas con el libro mayor público de Bitcoin para identificar las semillas válidas que coincidan con las direcciones reales.
En mi opinión, el destino de seguridad de la billetera está sellado en el momento en que se crea la semilla. Antes de que medidas de protección como el PIN, la placa de respaldo en acero, las bolsas selladas anti-tampering y la aislamiento de aire entren en juego, la semilla debe generarse primero a partir de una fuente aleatoria verdaderamente confiable.
Un generador de números aleatorios moderno de alta calidad puede producir suficiente entropía. Sin embargo, si un atacante conoce la lógica de funcionamiento del generador de números aleatorios, podría invertir el proceso completo de generación.
Lanzar dados manualmente proporciona a los usuarios una fuente de aleatoriedad que es intuitiva y controlable, y que es independiente del código escrito por el fabricante.
Puntos débiles ocultos en la seguridad de las billeteras de Bitcoin
La generación de semillas de Coldcard presenta vulnerabilidades de seguridad ocultas. Los atacantes pueden generar semillas candidatas externamente al dispositivo, convertirlas en direcciones de clave pública y compararlas con registros de transacciones en el libro mayor público de Bitcoin para llevar a cabo ataques.
La raíz técnica de la vulnerabilidad es tan minúscula que resulta aterradora. Un cambio de código el 1 de marzo de 2021 migró la función de generación de semillas de Coldcard a una nueva base de código. En los firmwares de producción, la opción de configuración MICROPY_HW_ENABLE_RNG se estableció en 0, lo que indica que el generador aleatorio hardware fue deshabilitado; sin embargo, la lógica de integración del código solo verificaba si esta opción existía, sin leer su valor numérico. Siempre que esta opción existiera, el sistema abandonaba el generador aleatorio hardware y activaba en su lugar el algoritmo determinista Yasmarang de MicroPython como solución de respaldo. Según el informe conjunto de análisis de Block, esta lógica defectuosa se lanzó oficialmente al público el 17 de marzo con la versión del firmware 4.0.0.
La frase generada parece normal, pero el espacio de búsqueda exhaustivo detrás de ella se ha reducido drásticamente. Según cálculos iniciales de Coinkite, el espacio de búsqueda efectivo para las semillas de los modelos Mk2 y Mk3 afectados es de aproximadamente 40 bits; para los modelos Mk4, Mk5 y la serie Q afectados, es de aproximadamente 72 bits.
El equipo de Block establece condiciones específicas para modelos futuros: cuando el estado del algoritmo de respaldo y el historial de llamadas están fijos, solo existen 2^32 flujos aleatorios distinguibles. Los datos proporcionados por Coinkite estiman el rango de búsqueda efectivo que un atacante podría recorrer.
Ambos informes de análisis confirman que todos los modelos posteriores antes de la reparación del firmware se encontraban dentro del rango de riesgo. El aviso de seguridad de Coinkite indica que los firmwares Mk4 y Mk5 anteriores a la versión estándar 5.6.0 y a la versión Edge 6.6.0X, así como los firmwares de la serie Q anteriores a la versión estándar 1.5.0Q y a la versión Edge 6.6.0QX, están afectados. Para Mk2 y Mk3, Coinkite especifica que las versiones con riesgo son la 4.0.1 a la 4.1.9, mientras que el equipo Block considera que la vulnerabilidad ya existía desde la versión 4.0.0. Para este límite de versión controvertido, se recomienda a los usuarios adoptar un enfoque conservador.
Este incidente demuestra claramente: instalar solo la nueva versión del firmware no corrige las vulnerabilidades de seguridad de los billeteras existentes. Actualizar a la versión reparada solo garantiza la seguridad de las semillas generadas posteriormente; todas las semillas antiguas ya generadas conservarán únicamente el valor de entropía obtenido en el momento de su creación, y todas las direcciones derivadas de dicha semilla comparten la misma clave subyacente.
Todos los usuarios que utilicen versiones de firmware con riesgos deben consultar el aviso de seguridad oficial. A menos que puedas confirmar que la semilla fue generada completamente mediante dados manuales, debes utilizar el firmware reparado, generar una nueva semilla mediante una fuente aleatoria confiable y transferir tus fondos a una nueva billetera. Si simplemente generas nuevas direcciones con la antigua frase de recuperación, la vulnerabilidad de seguridad original se mantendrá intacta.
Bitcoin Optech publicó datos estimados el 31 de julio, indicando que el valor de los activos amenazados superaba los 1.000 BTC. Al 2 de agosto, Galaxy Research estimó que aproximadamente 1.367 BTC estaban en riesgo en un total de 4.585 direcciones. Un usuario de X con el nombre de usuario Graham_Quantum afirmó que el 29 de julio ya se habían transferido 18.25245043 BTC desde billeteras relacionadas.
Tras la filtración del mensaje, numerosos usuarios transfirieron sus activos con fines de protección, generando un flujo de fondos aún más amplio. Tras la divulgación del mensaje sobre la vulnerabilidad, 77,402 BTC se transfirieron desde el pool de salidas de transacciones no gastadas (UTXO) antiguas.
Se deben distinguir dos tipos de datos:
Este incidente de seguridad generó dos impactos simultáneos: primero, el robo de activos por parte de hackers; segundo, una ola mucho más grande de usuarios que migraron activamente sus fondos para protegerse.
La vulnerabilidad de la billetera Coldcard, que implicó aproximadamente 89 millones de dólares, provocó la transferencia en cadena de bitcoins más grande desde el colapso de FTX y alteró gravemente la interpretación de las señales del mercado. Decenas de miles de usuarios transfirieron urgentemente sus bitcoins de billeteras antiguas, lo que dificultó distinguir la autenticidad de las señales bajistas emitidas por los indicadores clave en la cadena.
¿Qué cambios puede traer lanzar los dados manualmente?
Cálculo basado en la documentación oficial de Coldcard sobre dados: un dado justo de seis caras genera aproximadamente 2.585 bits de entropía por lanzamiento independiente. 50 lanzamientos producen aproximadamente 129.25 bits de entropía cruda, cumpliendo con el estándar de seguridad común de 128 bits; 99 lanzamientos generan aproximadamente 255.91 bits de entropía cruda, alcanzando casi el estándar de seguridad de 256 bits (esta cifra aún no ha sido procesada por el algoritmo de conversión integrado en la billetera).
Estos valores coinciden con el estándar BIP-39 ampliamente utilizado: una frase mnemonic de 12 palabras codifica 128 bits de entropía más 4 bits de suma de verificación; una frase mnemonic de 24 palabras codifica 256 bits de entropía más 8 bits de suma de verificación.
El mecanismo de aislamiento fuera de línea de los monederos de hardware solo protege la frase semilla una vez generada, pero no puede corregir las vulnerabilidades de aleatoriedad débil durante el proceso de generación; para generar una frase BIP-39 segura, se requiere obtener entropía independiente mediante el lanzamiento privado de dados.
La suma de verificación solo sirve para identificar errores al copiar la frase mnemonic. Lo que realmente determina la seguridad son los datos aleatorios subyacentes originales. Las operaciones de hash y la formato normalizado pueden mejorar entradas de baja entropía, pero el espacio total de todas las posibilidades de la clave no se amplía. Esos 12 palabras que parecen tranquilizadoras podrían provenir de un conjunto aleatorio extremadamente pequeño.
Condición previa para que el lanzamiento manual de dados proporcione protección: el flujo interno del monedero debe aceptar correctamente los datos aleatorios generados por los dados. Los dados en sí deben ser válidos, cada lanzamiento debe ser auténtico e independiente, y la secuencia de lanzamientos debe mantenerse completamente confidencial. Reutilizar patrones de lanzamiento, grabar imágenes, almacenar secuencias en la nube o ingresar resultados en una computadora conectada a internet, destruirá la independencia y la confidencialidad de la aleatoriedad.
En relación con este incidente de seguridad de Coldcard, Coinkite declaró: solo los usuarios que puedan confirmar que se realizaron al menos 50 lanzamientos de dados justos, independientes y confidenciales durante la generación final de la semilla pueden omitir la migración de activos; en cualquier caso de incertidumbre, se recomienda oficialmente migrar los fondos.
Para mí, el valor central del dado manual radica en: depender del generador de números aleatorios integrado en el dispositivo significa que debes confiar incondicionalmente en toda la cadena, desde el hardware hasta el firmware, el proceso de compilación y el código integrado.
El proceso estandarizado de ingreso de dados puede introducir entropía independiente de esta cadena de confianza, controlada directamente por el usuario. Aproximadamente 50 lanzamientos justos de dados equivalen a un nivel de seguridad de 128 bits, y 99 lanzamientos equivalen a un nivel de seguridad de 256 bits. Sin embargo, el usuario debe seguir estrictamente el procedimiento oficial del dispositivo y no diseñar sus propios esquemas de conversión de números aleatorios.
Configure una contraseña BIP-39 de alta intensidad y única, lo que eleva el umbral de ataque a otro nivel. La contraseña actúa como una clave independiente; incluso si un atacante obtiene la frase de recuperación, aún debe descifrar la contraseña para acceder a los activos. Nota: el valor de entropía de la frase de recuperación no aumenta al agregar una contraseña. Cualquier contraseña (incluso si se ingresa un solo carácter incorrecto) generará un conjunto válido de direcciones de billetera; si se pierde la contraseña, los activos quedarán bloqueados permanentemente. El PIN de la billetera de hardware tiene un propósito completamente distinto al de la contraseña.
Habilitar la contraseña de acceso implica un equilibrio: si puedes almacenarla adecuadamente y reproducirla con precisión, actuará como una sólida segunda línea de defensa; pero si tu método de respaldo no es adecuado, esta función podría impedirte por completo el acceso a tus activos.
La vulnerabilidad de la aleatoriedad débil aparece repetidamente
La vulnerabilidad de Coldcard vuelve a advertir a todos: la base de seguridad de una billetera de Bitcoin es la suficiente aleatoriedad fuerte en el momento de la generación de la semilla. Defectos subyacentes similares han surgido consecutivamente en múltiples productos de billeteras diferentes.
En 2023, Ledger Donjon reveló que ciertas versiones de la extensión de navegador Trust Wallet utilizaban, en la ruta de ejecución de WebAssembly, un algoritmo de rotación de梅森 basado en 32 bits para generar semillas aleatorias. Estas palabras de recuperación, que parecían normales, provenían todas de aproximadamente 4 mil millones de valores iniciales. El alcance del riesgo está claramente definido: las extensiones de navegador desde la versión 0.0.172 hasta la 0.0.182 que incorporan Trust Wallet Core anterior a la versión 3.1.1. La Base de Datos Nacional de Vulnerabilidades de Estados Unidos registra que esta vulnerabilidad fue explotada en diciembre de 2022 y marzo de 2023.
El evento del «vulnerabilidad de Milk Sad» ilustra de forma directa este tipo de riesgo. El comando bx seed de Libbitcoin Explorer 3.x utiliza un algoritmo Mersenne Twister de 32 bits sembrado con la hora del sistema; bajo condiciones de reloj idénticas, el software podría generar exactamente la misma frase de recuperación. Un atacante que tenga una estimación aproximada del momento en que se creó la semilla tendrá un rango de fuerza bruta mucho menor que el espacio sugerido aparentemente por la frase de recuperación.
Los investigadores encontraron más de 2,600 billeteras de Bitcoin aún activas dentro del rango de riesgo; según la cotización de agosto de 2023, los activos relacionados robados en múltiples cadenas públicas superan los 900,000 dólares estadounidenses. Más de 2,550 de estas billeteras muestran características de operaciones automatizadas, lo que sugiere con alta probabilidad que pertenecen al mismo titular. Los investigadores también señalaron que algunos incidentes de robo de activos podrían haberse visto agravados por otras vulnerabilidades de seguridad.
Estas vulnerabilidades siempre aparecen con un disfraz diferente: Coldcard activa accidentalmente el algoritmo de respaldo de aleatoriedad del firmware; Trust Wallet y la herramienta de línea de comandos Libbitcoin generan números aleatorios débiles debido a su dependencia del reloj del sistema. Las claves de billetera generadas finalmente parecen impecables, pero el tamaño del conjunto de claves accesibles es tan pequeño que supone un riesgo fatal.
La mayoría de las recomendaciones de almacenamiento de bitcoins en el mercado se enfocan después de la generación de la semilla: guardar offline la frase de recuperación, usar soportes de respaldo duraderos, aislar permisos y probar el proceso de recuperación. Estas medidas siguen siendo valiosas. Pero el incidente de Coldcard nos recuerda que las líneas de defensa de seguridad deben avanzar un paso más adelante.
El aislamiento de aire solo protege las claves que ya hayas ingresado en el dispositivo. Por eso, la seguridad de una billetera de Bitcoin debe comenzar con una fuente aleatoria confiable.