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 alguien que había comprado una billetera de hardware precisamente para evitar este escenario.
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 no han venido tanto de exploits sofisticados, sino de algo más básico: aleatoriedad que no era suficientemente aleatoria.
¿Qué hay detrás de la clave privada?
Las billeteras de criptomonedas, ya sea en una app, extensión de navegador o dispositivo de hardware, dependen de una tarea crítica: 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 expande una pequeña cantidad de entropía “real” hasta lo necesario, pero solo si la semilla inicial es realmente impredecible.
El software que corre en una pestaña del navegador o en un teléfono recién encendido suele iniciar en una especie de cámara de privación sensorial. Para generar un número verdaderamente aleatorio, un programa necesita “ruido”: entradas impredecibles del mundo externo. Esto puede venir de variaciones de tiempo en el procesador, movimientos del mouse o componentes de hardware especializados.
En los primeros milisegundos tras encender un dispositivo, esos “pools” de ruido pueden estar vacíos o apenas inicializados. Si una librería criptográfica llama al generador de números aleatorios demasiado pronto, puede estar extrayendo de un pozo poco profundo, produciendo números que son técnicamente aleatorios, pero provenientes de un espacio tan pequeño que se puede buscar de forma exhaustiva.
Los navegadores añaden sus propias limitaciones. Math.random() de JavaScript nunca fue diseñado para seguridad, y hasta el más seguro crypto.getRandomValues() depende del “pool” de entropía del sistema operativo. Si ese “pool” es débil, como puede ocurrir en entornos móviles, máquinas virtuales o dispositivos IoT limitados, la aleatoriedad se compromete 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 que necesita para resolver 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 igual para dos mensajes distintos, las ecuaciones se alinean y cualquiera que vea ambas firmas puede calcular k. Una vez conocido k, d —la clave privada— se obtiene con un par de multiplicaciones y un inverso modular.
En 2013, un fallo en Android’s SecureRandom 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 programación, no puedes detectar una aleatoriedad de baja calidad solo leyendo el código fuente. Las llamadas a funciones pueden parecer correctas, pero a menos que midas los bits reales producidos y ejecutes pruebas estadísticas para verificar su imprevisibilidad, una debilidad fatal puede esconderse a simple vista durante meses o años, esperando a alguien lo suficientemente paciente para explotarla.
La razón por la que la entropía sigue siendo una vulnerabilidad persistente se puede resumir así:
Startup entropy drought: los dispositivos recién encendidos pueden no haber acumulado suficiente ruido ambiental para sembrar los PRNG.
Browser limitations: Math.random() de JavaScript no es seguro; incluso crypto.getRandomValues() depende del “pool” de entropía del entorno anfitrión.
Unsafe tooling: generadores de direcciones vanity, scripts offline o librerías mal mantenidas suelen sacrificar aleatoriedad por velocidad o reproducibilidad.
Human input: “Brainwallets” y frases elegidas por el usuario han sido vulneradas simplemente adivinando desde diccionarios.
Los criptógrafos han preferido durante mucho tiempo los hardware random number generators (HRNG), también llamados true RNG. Estos convierten fenómenos físicos como el jitter electrónico, el ruido térmico y la desintegración radiactiva en bits aleatorios, y pueden autoprobarse continuamente para detectar fallos o sesgos.
Cómo el hardware soluciona esto
En sistemas de alta seguridad, la solución es directa: generar las claves dentro de un chip que contenga un HRNG certificado y nunca permitir 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 hardware random number generator que obtiene su imprevisibilidad del ruido físico, como fluctuaciones térmicas o jitter de oscilador, en lugar de depender solo de algoritmos matemáticos.
Estos HRNG no son dispositivos de “una sola vez”. Bajo estándares como NIST SP 800-90B, deben realizar pruebas de salud continuas, revisando 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 la aleatoriedad directamente al proceso de generación de claves dentro del propio chip.
No todo el “hardware” es igual
El término billetera de hardware abarca un amplio espectro de diseños, y no todos 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 sembrado desde el estado interno del dispositivo, en lugar de un HRNG plenamente certificado y probado según los estándares requeridos. En estos diseños, la generación de claves puede ocurrir en el firmware, con la clave privada resultante almacenada temporalmente en RAM o memoria flash. Eso significa que un fallo en el firmware, un ataque de canal lateral exitoso o una manipulación física pueden exponer la clave.
Por el contrario, las billeteras basadas en secure element colocan 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 aplica un control de acceso estricto: las operaciones criptográficas (firmado, 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í.
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 internas de salud para monitorear continuamente la fuente en busca de sesgos o fallas.
Un dispositivo compatible no genera números aleatorios una sola 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 pasa 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í puede cuestionar dónde y cómo se generaron sus claves. Si se crearon “en una página web” o “en una app de Android antigua”, especialmente antes de mediados de la década de 2010, esas claves probablemente sean débiles. El enfoque más seguro es generar una nueva billetera en un dispositivo de hardware que use aleatoriedad certificada y documentada, y luego transferir allí tus fondos.
Cronología de ataques por entropía
La entropía débil elimina la necesidad de trabajar hacia atrás. 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—The IOTA seed generator scam: a los usuarios se les indicó crear las semillas de sus billeteras usando un sitio web. El operador del sitio guardó una copia de esas semillas y drenó los fondos después, robando unos US$ 4 millones. Aquí la aleatoriedad era nula: 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 estuvo vigilando esas direcciones durante años, drenando unos 45,000 ETH en cuanto aparecían fondos.
2022—Profanity’s vanity address catastrophe: la herramienta open-source Profanity generaba direcciones personalizadas de Ethereum a partir de semillas con solo 32 bits de entropía, unas cuatro mil millones de posibilidades. Una GPU moderna puede recorrer ese espacio en horas. Wintermute, un market maker de Londres, perdió unos US$ 160 millones de esta forma.
2023—Trust Wallet browser extension flaw: una divulgación del equipo de seguridad de Ledger reveló que la extensión de navegador generaba semillas de billetera con solo 32 bits de entropía. El fallo se corrigió rápido y Trust Wallet reembolsó a algunos usuarios, pero durante meses cualquiera que generara una billetera ahí estaba en riesgo.
2025—The LuBian allegation:La denuncia de Arkham aún no se ha verificado, pero si la pérdida de 127,426 BTC realmente se debe a generación de claves predecibles, 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 fue de unos 40 bits en el hardware Mk3, y de unos 72 bits en modelos posteriores que mezclaron datos del secure element. Ambas cifras 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 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 dejar COLDCARD?
Tangem genera tu clave dentro de un chip secure element certificado usando un hardware random number generator.
Si ya estás cansado de preocuparte por las frases semilla, nuestro sistema sin semilla significa que no hay frases de 12 o 24 palabras que anotar, fotografiar o perder; justo el problema al que han vuelto la mayoría de los hacks de billeteras.
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.
Pregunta a la IA si Tangem se adapta a tus necesidades
Investiga la cartera Tangem con IA para saber si nuestra seguridad y facilidad de uso se adaptan a tus casos de uso únicos
