Cómo la mala entropía sigue causando pérdidas millonarias en cripto

El 31 de julio de 2026, un atacante vació unas 500 billeteras de Bitcoin en solo 25 minutos. El ataque movió aproximadamente 594 BTC, valorados en unos US$ 38 millones, y cada billetera afectada pertenecía a personas que habían comprado una billetera de hardware precisamente para evitar este tipo de situaciones.
 

Coinkite disclosed that COLDCARD firmware had been generating keys using a software pseudorandom number generator rather than the hardware generator built into the device. Two functions in the codebase shared the same name and signature, so the linker selected the wrong one, and the build produced no warning.
 

Este es el caso más reciente en una larga lista. En la última década, las mayores pérdidas en criptomonedas han ocurrido menos por exploits sofisticados y más por algo básico: aleatoriedad que no era lo suficientemente aleatoria.

¿Qué hay detrás de la clave privada?

Las billeteras de criptomonedas, ya sea en una app, una extensión de navegador o un dispositivo de hardware, dependen de una tarea crucial: generar números que nadie más pueda adivinar o reproducir. Eso es lo que significa entropía en este contexto: el nivel de imprevisibilidad en un número generado.

Entropy is the raw randomness a wallet uses to create a private key, measured in bits. More bits mean a larger space of keys that an attacker must search. It enters a wallet at setup. Every key, address, and signature after that follows fixed mathematical rules, so no new randomness arrives later.

Fuente de entropía

En principio, una billetera puede obtener aleatoriedad de un pseudorandom number generator (PRNG): un algoritmo que amplía una pequeña cantidad de entropía “real” hasta el nivel necesario, pero solo si la semilla inicial es verdaderamente impredecible. 

El software que se ejecuta en una pestaña del navegador o en un teléfono recién encendido suele comenzar en una especie de cámara de privación sensorial. Para generar un número realmente aleatorio, un programa necesita “ruido”: entradas impredecibles del mundo exterior a la computación pura. Esto puede provenir de variaciones en el tiempo del procesador, movimientos del mouse o componentes de hardware especializados.

En los primeros milisegundos después de encender un dispositivo, esos “pools” de ruido pueden estar vacíos o solo parcialmente inicializados. Si una librería criptográfica llama al generador de números aleatorios demasiado pronto, podría estar extrayendo de un pozo poco profundo, generando números técnicamente aleatorios, pero dentro de un espacio tan pequeño que es posible buscarlo por fuerza bruta.

Los navegadores imponen sus propias limitaciones. Math.random() de JavaScript nunca fue diseñado para seguridad, y hasta la opción más segura crypto.getRandomValues() depende del “pool” de entropía del sistema operativo subyacente. Si ese “pool” es débil, como puede suceder en entornos móviles, máquinas virtuales o dispositivos IoT limitados, la aleatoriedad se ve comprometida antes de llegar al código que genera tu clave privada.

La aleatoriedad en la firma de transacciones

Cuando firmas una transacción de Bitcoin o Ethereum, no usas tu clave privada directamente. En su lugar, generas un nonce: un número aleatorio de un solo uso, que se combina con tu clave privada en el algoritmo Elliptic Curve Digital Signature Algorithm (ECDSA) para producir una firma.

Pero aquí está el problema: si el mismo nonce se usa dos veces con la misma clave privada, las matemáticas le dan al atacante todo lo necesario para descubrir esa clave privada.
Las firmas ECDSA son un par de números, (r, s), que cumplen una ecuación específica que involucra:

• la clave privada (d),
• el nonce (k), y
• el mensaje de la transacción hasheado (z).

Si k es el mismo para dos mensajes distintos, las ecuaciones se alinean, permitiendo que cualquiera que vea ambas firmas calcule k. Una vez que k es conocido, d—la clave privada—se obtiene con un par de multiplicaciones y una inversa modular.

En 2013, una falla en el SecureRandom de Android provocó que las primeras billeteras de Bitcoin en la plataforma generaran nonces predecibles. Los fondos desaparecieron de las billeteras antes de que la mayoría de los usuarios supiera que había un problema.

A diferencia de un error típico de código, no puedes detectar una aleatoriedad de baja calidad solo leyendo el código fuente. Las llamadas a funciones pueden verse correctas, pero a menos que midas los bits realmente generados y realices pruebas estadísticas para verificar su imprevisibilidad, una debilidad fatal puede permanecer oculta durante meses o años, esperando a que alguien paciente la explote.

Las razones por las que la entropía sigue siendo una vulnerabilidad persistente se resumen en:

• Falta de entropía al inicio: Los dispositivos recién encendidos pueden no haber recolectado suficiente ruido ambiental para alimentar los PRNG.

• Limitaciones del navegador: Math.random() de JavaScript no es seguro; incluso crypto.getRandomValues() depende del “pool” de entropía del entorno.

• Herramientas inseguras: Generadores de direcciones “vanity”, scripts offline o librerías poco mantenidas suelen sacrificar aleatoriedad por velocidad o facilidad de reproducción.

• Entrada humana: “Brainwallets” y frases elegidas por el usuario han sido vulneradas simplemente adivinando desde diccionarios.

Los criptógrafos siempre han preferido los hardware random number generators (HRNGs), también llamados true RNGs. Estos convierten fenómenos físicos como el jitter electrónico, el ruido térmico o la desintegración radiactiva en bits aleatorios, y pueden autoevaluarse continuamente para detectar fallos o sesgos.

¿Cómo lo soluciona el hardware?

En sistemas de alta seguridad, la solución es simple: genera las claves dentro de un chip que contenga un HRNG certificado y nunca permitas que esas claves se dupliquen.

A secure element is a purpose-built, tamper-resistant microcontroller. It is a fortified chip designed to store secrets and perform cryptographic operations without revealing the underlying keys. They are the same class of component used in passports to prevent cloning, SIM cards to authenticate devices to mobile networks, and contactless payment cards to authorize transactions.

Un secure element puede albergar un generador de números aleatorios por hardware que obtiene su imprevisibilidad de ruido físico, como fluctuaciones térmicas o jitter de oscilador, en lugar de depender solo de algoritmos matemáticos. 

Estos HRNGs no son dispositivos de “una sola vez”. Bajo estándares como  NIST SP 800-90B, deben realizar pruebas de salud continuas, verificando cada flujo de salida en busca de sesgos estadísticos, bits atascados u otras fallas que puedan degradar la aleatoriedad con el tiempo. Si algo parece sospechoso, el chip puede detener la generación de claves de inmediato. En una buena billetera de hardware, el HRNG del secure element alimenta directamente el proceso de generación de claves dentro del propio chip. 

No todo el “hardware” es igual

El término billetera de hardware abarca una amplia variedad de diseños, y no todas ofrecen el mismo nivel de protección para la aleatoriedad y el aislamiento de claves.

En el extremo inferior están los dispositivos basados en microcontroladores de uso general, chips diseñados para flexibilidad más que para resistir ataques físicos o de canal lateral. Muchos de estos incluyen un generador de números aleatorios básico. 

Aun así, puede tratarse de un generador pseudorrandom alimentado por el estado interno del dispositivo, en vez de un HRNG totalmente certificado y probado según los estándares requeridos. En estos diseños, la generación de claves puede ocurrir en el firmware, y la clave privada resultante se almacena temporalmente en RAM o memoria flash. Eso significa que una falla en el firmware, un ataque de canal lateral exitoso o una manipulación física podrían exponer la clave.
 

En cambio, las billeteras basadas en secure element sitúan tanto la fuente de entropía como la lógica de generación de claves dentro de un entorno resistente a manipulaciones. Este modelo también impone un control de acceso estricto: las operaciones criptográficas (firma, derivación) se realizan dentro del chip, y solo la firma final o la clave pública salen de él, nunca el secreto en sí.

Ya existen estándares

El problema de la aleatoriedad no es una cuestión sin resolver. Los criptógrafos ya han definido cómo debe ser una buena entropía. El National Institute of Standards and Technology (NIST) de EE. UU. ha publicado la serie de estándares SP 800-90, que desglosa el problema en partes claras.

SP 800-90B describe cómo evaluar una fuente de entropía; el proceso físico o de software que produce bits impredecibles. Requiere un análisis estadístico riguroso para estimar la verdadera entropía de cada flujo de bits, así como pruebas de salud integradas para monitorear continuamente la fuente en busca de sesgos o fallos.

SP 800-90C explica cómo combinar esa entropía con deterministic random bit generators (DRBGs) para que la salida siga siendo fuerte incluso si una fuente se degrada.

Un dispositivo conforme no solo genera números aleatorios una vez y espera lo mejor. Se revisa continuamente: si el patrón de ruido del HRNG cambia, si un bit se “atasca” o si la salida no supera los umbrales estadísticos, el sistema detiene la generación de claves para evitar crear claves débiles.

¿Cómo saber si estás en riesgo?

La mayoría de los usuarios no puede medir la entropía directamente, pero sí puedes preguntarte dónde y cómo se generaron tus claves. Si se crearon “en una página web” o “en una app antigua de Android”, especialmente antes de mediados de la década de 2010, esas claves probablemente sean débiles. Lo más seguro es generar una nueva billetera en un dispositivo de hardware que use aleatoriedad certificada y documentada, y luego transferir tus fondos allí.

Cronología de ataques por entropía 

La baja entropía elimina la necesidad de retroceder. El atacante enumera el pequeño conjunto de claves que el generador defectuoso pudo haber producido, deriva las direcciones para cada candidato y luego revisa esas direcciones en la blockchain para ver si tienen saldo. Aquí algunos casos históricos:

• 2018—El scam del generador de seeds de IOTA: Se les indicó a los usuarios crear sus seeds de billetera usando un sitio web. El operador del sitio guardó una copia de esas seeds y vació los fondos más tarde, robando cerca de US$ 4 millones. Aquí la aleatoriedad era cero: el atacante ya conocía los números.
   

• 2019—The Blockchain Bandit: Investigadores de seguridad identificaron 732 claves privadas de Ethereum débiles en circulación. Un atacante desconocido monitoreó esas direcciones durante años, drenando cerca de 45,000 ETH apenas se depositaban fondos.
   

• 2022—La catástrofe de direcciones vanity de Profanity: La herramienta open-source Profanity generaba direcciones personalizadas de Ethereum a partir de seeds con solo 32 bits de entropía, unas cuatro mil millones de posibilidades. Una GPU moderna puede buscar ese espacio en horas. Wintermute, un market maker de Londres, perdió unos US$ 160 millones de esta manera.
   

• 2023—Falla en la extensión de Trust Wallet: Según una divulgación del equipo de seguridad de Ledger, la extensión generaba seeds de billetera con unos 32 bits de entropía. Se corrigió rápidamente y Trust Wallet reembolsó a algunos usuarios, pero durante meses cualquiera que creara una billetera ahí estuvo en riesgo.
   

• 2025—La acusación de LuBian: El informe de Arkham aún no está verificado, pero si la pérdida de 127,426 BTC realmente se debe a generación predecible de claves, sería el mayor ejemplo de cómo un solo error al crear una clave puede condenar miles de millones en activos. 
   

• 2026: COLDCARD: Coinkite disclosed that a software pseudorandom generator had replaced the intended hardware generator in shipped firmware. The fallback entered the upstream dependency in May 2018 and reached key generation in March 2021.

  Coinkite estima que el espacio efectivo de búsqueda era de unos 40 bits en el hardware Mk3, y de unos 72 bits en modelos posteriores que mezclaban datos del secure element. Ambos valores están por debajo del objetivo de 128 bits.

  Existía una protección para evitar esto. Probaba si un macro de configuración estaba definido, en vez de verificar si su valor era distinto de cero; el macro se estableció en cero, así que la comprobación pasó y el error nunca se activó.

¿Pensando en cambiar de COLDCARD?

Tangem genera tu clave dentro de un chip secure element certificado usando un generador de números aleatorios por hardware. 

Si ya estás cansado de preocuparte por las frases semilla, nuestro sistema sin seed significa que no hay frases de 12 o 24 palabras que anotar, fotografiar o perder; justo la causa de la mayoría de los hacks a billeteras en el pasado.

Auditado de forma independiente por Cure53, Kudelski y Riscure. Construido para este momento.

Mueve tus monedas donde la aleatoriedad sí es realmente aleatoria. Consigue Tangem Wallet.