El 31 de julio de 2026, un atacante vació unas 500 billeteras de Bitcoin en solo 25 minutos. La operación 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 de una larga lista. En la última década, las mayores pérdidas de criptomonedas no han venido tanto de exploits sofisticados, sino de algo más 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 hecha correctamente: generar números que nadie más pueda adivinar o recrear. Eso es lo que significa entropía en este contexto: la cantidad 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” en tanto como se necesite, pero solo si la semilla inicial es realmente impredecible.
El software que se ejecuta en una pestaña del navegador o en un teléfono recién encendido suele arrancar 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 fuera de la pura computación. Esto puede venir de variaciones de tiempo en el 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, puede estar extrayendo de un pozo poco profundo, produciendo números que son técnicamente aleatorios, pero de un espacio tan pequeño que puede ser buscado exhaustivamente.
Los navegadores añaden 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. 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 al firmar 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 punto clave: si el mismo nonce se usa dos veces con la misma clave privada, las matemáticas le dan al atacante todo lo necesario 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 el mismo para dos mensajes distintos, las ecuaciones se alinean, permitiendo que cualquiera que vea ambas firmas calcule k. Una vez que se conoce k, d—la clave privada—se obtiene con un par de multiplicaciones y una inversa modular.
En 2013, una falla en SecureRandom de Android provocó que las primeras billeteras de Bitcoin en esa plataforma generaran nonces predecibles. Los fondos desaparecieron antes de que la mayoría de los usuarios siquiera supieran que había un problema.
A diferencia de un error típico de programación, no puedes detectar 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 pasar desapercibida durante meses o años, esperando a que alguien lo suficientemente paciente la explote.
Las razones por las que la entropía sigue siendo una vulnerabilidad persistente se pueden 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 personalizadas, scripts offline o librerías mal mantenidas suelen sacrificar aleatoriedad por velocidad o reproducibilidad.
Human input: Las “brainwallets” y frases elegidas por el usuario han sido vulneradas simplemente adivinando desde diccionarios.
Los criptógrafos llevan mucho tiempo prefiriendo los hardware random number generators (HRNG), también llamados true RNGs. 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 autoverificarse continuamente para detectar fallos o sesgos.
Cómo el hardware soluciona esto
En sistemas de alta seguridad, la solución es sencilla: 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 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 simplemente 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 otros fallos 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 gama 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 propósito general, chips diseñados para flexibilidad más que para resistir ataques físicos o de canal lateral. Muchos de estos incluyen un generador básico de números aleatorios.
Aun así, puede tratarse de un generador pseudorrandom sembrado desde el estado interno del dispositivo, en vez de un HRNG completamente certificado y probado bajo 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 pueden exponer la clave.
Por el contrario, 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 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í.
Ya existen estándares
El problema de la aleatoriedad no es una cuestión sin resolver en la ciencia. Los criptógrafos ya han definido cómo debe lucir 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.
Un dispositivo conforme no solo genera números aleatorios una vez y espera lo mejor. Verifica continuamente su propio “pulso”: si el patrón de ruido del HRNG cambia, si un bit se queda “pegado” 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í puedes cuestionar dónde y cómo se generaron tus claves. Si fueron creadas “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 crear una billetera nueva 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 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 podría 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: Se les indicó a los usuarios crear sus semillas de billetera usando un sitio web. El operador del sitio guardó una copia de esas semillas y drenó los fondos después, robando aproximadamente 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 cerca de 45,000 ETH apenas 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 buscar ese espacio en horas. Wintermute, un market maker de Londres, perdió unos US$ 160 millones de esta manera.
2023—Trust Wallet browser extension flaw: Según una divulgación del equipo de seguridad de Ledger, la extensión de navegador generaba semillas 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 generara una billetera allí estaba en riesgo.
2025—The LuBian allegation:La denuncia de Arkham aún no ha sido verificada, pero si la pérdida de 127,426 BTC realmente se debe a una generación de claves predecible, sería el ejemplo definitivo 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 hay unos 40 bits de espacio efectivo de búsqueda en el hardware Mk3, y unos 72 bits en modelos posteriores que mezclan datos del secure element. Ambas cifras están por debajo del objetivo de 128 bits.
Existía una protección para evitar exactamente esto. Probaba si un macro de configuración estaba definido, en vez de si su valor era distinto de cero; el macro estaba en cero, así que la verificación pasó y el error nunca se activó.
¿Pensando en cambiarte de 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; exactamente la causa de la mayoría de los hacks de 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.
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
