¿Las carteras frías son seguras? El pánico desatado tras el hackeo a los dispositivos de Coinkite ha puesto en jaque la máxima sagrada del sector cripto: no tus llaves, no tus monedas. Con más de 1.500 BTC liquidados en tres oleadas de ataques silenciosos, la comunidad descubre por la vía rápida que un hardware wallet es tan seguro como el código que ejecuta su firmware. Analizamos qué ha fallado realmente en Coldcard y qué lecciones deja este fallo histórico para el futuro de la autocustodia.
El pasado 30 de julio de 2026, un atacante vació carteras de bitcoin por valor de unos 70 millones de dólares en 41 minutos, y todo ello sin tocar un solo dispositivo. En los días siguientes la cifra no paró de crecer: tres oleadas confirmadas y catorce incidentes menores han arrebatado 1.596 BTC, equivalente a más de 100 millones de dólares, de unas 7.300 direcciones vinculadas a Coldcard, el hardware wallet de la canadiense Coinkite, y una cuarta oleada aun sin confirmar, elevaría el total a unos 2.055 BTC, cerca de 130 millones.
La causa de todo este desastre no fue un ataque a la red de bitcoin, ni una puerta trasera: fue un error de integración de más de cinco años en el generador de números aleatorios del firmware. La criptografía es así de frágil. Los algoritmos son matemáticas sólidas, pero como ese algoritmo esté mal escrito, por mínimo que sea el fallo, entonces el desastre está servido.
La fortaleza de una cadena se mide por su eslabón más débil
Para entender el incidente de Coldcard y otros graves que le anteceden en el sector, como el de Heartbleed en 2014, y el de OpenSSL en Debian en 2008, hay que separar dos niveles que a menudo se confunden.
El primero es el de las matemáticas. Las funciones hash, los cifrados y las firmas digitales que conforman, por ejemplo, el estándar BIP-39 que usan las carteras de Bitcoin. Ese nivel es muy difícil de romper; después de décadas de ataques, los criptógrafos confían en él. El segundo nivel es la implementación. El código concreto que convierte esas matemáticas en software. Es ahí donde ocurren casi todos los desastres.
Pongamos por ejemplo, una seed de 12 palabras de una cartera Bitcoin estándar, la cual representa 128 bits de entropía. Esto significa que hay 2^128 combinaciones posibles, un número tan grande que resulta inabordable incluso para toda la potencia de cómputo del planeta. Se tardarían billones de años en calcular todos los valores.
Pero ese nivel de seguridad SOLO EXISTE si el número aleatorio que da origen a la semilla es realmente impredecible. Si el generador de aleatoriedad (Random Number Generator o RNG) falla, todo lo demás, el cifrado, la verificación de direcciones, la firma, es teatro y del malo. Es un punto tan conocido que tiene su propio axioma: la criptografía no se rompe (generalmente) en las matemáticas, se rompe en el generador de números aleatorios y en los errores de integración que nadie mira dos veces.
El ataque a Coldcard sigue activo y las pérdidas podrían alcanzar los 130 millones de dólares
Coldcard, los dados trucados que funcionaron durante cinco años
Veamos esto con el incidente más reciente: el de Coldcard. El problema nació en marzo de 2021, cuando la compañía migró la generación de seeds de su cartera a una librería llamada libngu, construida sobre MicroPython. El equipo quería usar el generador de aleatoriedad por hardware (RNG) del chip STM32 de sus dispositivos, pero en el proceso, desactivaron una macro de compilación de MicroPython, MICROPY_HW_ENABLE_RNG, fijándola a cero.
Una línea, un error de una línea, está costando a día de hoy, más de 100 millones de dólares. Y todo porque en la configuración de producción (usada en los dispositivos de usuario final), esa macro no desactivaba el generador por software de MicroPython: la seleccionaba.
Y el código de libngu que debía detectar el problema estaba mal escrito: comprobaba solo si la macro estaba definida, y lo estaba, tenía un valor cero, lo que no estaba era habilitada para usar el RNG del STM32. El resultado es que la generación de seeds, el momento más delicado de toda la seguridad de la cartera, se conectó silenciosamente al sustituto determinista que MicroPython usa para placas sin RNG de hardware: un pequeño algoritmo llamado Yasmarang.
Reduciendo la entropía: cuando la falta de caos es inseguridad
Coinkite estima que los dispositivos Mk2 y Mk3 afectados quedaron con una entropía efectiva de unos 40 bits. El generador se sembraba con el número de serie del chip y los registros del reloj, ninguno de los cuales es secreto: el atacante podía reproducir el estado de la máquina con un dispositivo propio.
Un espacio de búsqueda de 2^40 (alrededor de un billón de posibilidades) es enumerable con una GPU moderna y algo de tiempo. Los modelos Mk4, Mk5 y Q añadían entropía de su elemento seguro, pero el propio Coinkite reconoció que la reducción de un re-sembrado de 32 bits dejaba esos seeds en unos 72 bits, todavía muy por debajo de los 128 bits del estándar.
Durante más de cinco años, esos dados trucados parecieron normales. Cada seed generada se veía igual de aleatorio que uno correcto; ningún usuario notó nada. La comprobación clave no se detectó con pruebas ni con auditorías: la descubrieron los atacantes.
El 30 de julio de 2026, Galaxy Research detectó una primera oleada de retiradas: 1.082,65 BTC, unos 70,2 millones de dólares, sacados de 1.196 direcciones en 41 minutos. Chainalysis calcula que en los primeros diez minutos ya se habían movido unos 30 millones de dólares, y que una sola víctima perdió 1,8 millones. Coinkite afirma que al menos quince atacantes distintos se lanzaron a explotar el mismo agujero.
Novedades Windows 11 26H2: la lista completa de cambios
El error que nadie vio ejecutar
La parte más incómoda de esta historia es que el código era de código abierto, auditable y auditable de verdad. Coldcard construyó su reputación precisamente sobre eso: firmware inspeccionable, builds reproducibles y aire entre los fondos y la red. El RNG por hardware que se suponía que debía usarse estaba presente en el binario todo el tiempo; solo era, por accidente, el que la ruta de generación de seeds no invocaba.
Los equipos de ingeniería de bitcoin de Block, que publicaron su análisis el 30 de julio de 2026, lo resumieron con crudeza: las revisiones de seguridad confirmaron que el código correcto existía en el firmware, pero ninguna verificó qué implementación alcanzaba realmente la ruta de generación de seeds entre los dos submódulos.
La lección va más allá de Coldcard: en criptografía, auditar el código que está escrito no basta. Hay que verificar el código que se ejecuta, con la configuración real con la que se compila. Un guard mal escrito (#ifndef en lugar de una comprobación de habilitación) no genera ningún error de compilación, no peta en las pruebas y produce una salida perfectamente aleatoria en apariencia. Solo falla en la única propiedad que importa: la imprevisibilidad.
Respuesta rápida, pero lo perdido, perdido está
La respuesta de Coinkite fue rápida y poco habitual en el sector. El consejero delegado, Rodolfo Novak, pidió públicamente a los usuarios que “muevan sus fondos ahora”, dijo que la empresa estaba “desolada” y asumió “toda la responsabilidad”. Publicó un documento técnico inusualmente transparente en el que reconocía que “la mayor parte de la aleatoriedad de Coldcard venía de un PRNG que ni siquiera sabía que estaba en el código”.
Destruyó el inventario pendiente de enviar con el firmware vulnerable. Y repitió un mensaje que no gusta a nadie: actualizar el firmware no repara las seeds ya generadas. La exposición viaja con la semilla, no con el dispositivo; cualquiera que creara una seed con el firmware afectado tiene que generar una nueva y migrar los fondos. Quienes añadieron al menos 50 tiradas de dados privadas al crear su seed, que aportan más de 128 bits de entropía ajena al generador, se consideran a salvo de este fallo concreto; el resto, no.
La alarma provocó una de las mayores migraciones de bitcoin pequeño desde el colapso de FTX en noviembre de 2022: según el analista de CryptoQuant, Julio Moreno, en un solo día se movieron 39.600 BTC en transferencias de menos de un bitcoin, el mayor volumen de esa categoría en casi cuatro años. Alrededor del 90% del botín, sin embargo, sigue intacto en las direcciones de los atacantes. En bitcoin no hay reverso: si el dinero llega a un servicio regulado, los investigadores pueden intentar congelarlo; si no, desaparece.
MCP, A2A y los micropagos: la infraestructura del comercio autónomo entre agentes de IA
Heartbleed, cuando dos tercios de la Web son el blanco
Pero lo de Coldcard, es solo el último capítulo de una historia que lleva décadas repitiéndose. Hace doce años, en abril de 2014, el bug más célebre de la criptografía moderna mostró que el problema no era exclusivo de los proyectos pequeños ni de las monedas nuevas.
Heartbleed (CVE-2014-0160) fue un fallo en la librería OpenSSL, el software que protegía y sigue protegiendo la mayoría de las conexiones TLS de Internet. El error estaba en la extensión heartbeat del protocolo TLS, diseñada para comprobar que el interlocutor de una conexión sigue vivo. La implementación de OpenSSL leía la longitud declarada del mensaje, pero no comprobaba si el contenido real coincidía con ella: así un atacante podía declarar que enviaba 64 kilobytes y adjuntar apenas unos bytes, y el servidor le devolvía 64 kilobytes de su propia memoria. En esos 64 KB podían estar las claves privadas, contraseñas, tokens de sesión o el contenido cifrado de las comunicaciones. Y podía repetirse tantas veces como quisiera, sin dejar rastro: los heartbeats no se registran en los logs.
Dos años explotable
El bug se introdujo en diciembre de 2011 y llegó al mundo con OpenSSL 1.0.1 en marzo de 2012. Permaneció explotable dos años. Fue descubierto de forma independiente por el equipo finlandés de Codenomicon y por Neel Mehta, de Google Security, que lo notificó a OpenSSL; el parche, publicado el 7 de abril de 2014, era un arreglo de dos líneas: comprobar la longitud antes de copiar. La ironía es que la corrección era trivialmente simple, pero el coste no: los operadores de servidores tuvieron que revocar y reemitir certificados y claves de toda la web, porque cualquiera que hubiera interceptado tráfico durante dos años podía haber estado descifrándolo en retrospectiva. Los secretos filtrados no se pueden “des-filtrar”.
Heartbleed también reveló algo estructural: la infraestructura criptográfica más crítica del mundo la mantenía un puñado de voluntarios con financiación mínima. Un fallo de una línea en una librería sin dinero y sin equipo suficiente derribó la confianza de dos tercios de internet. No fue un error matemático; fue un bug de implementación perfectamente normal, con consecuencias de escala planetaria por el simple hecho de estar en la base de todo.
La lección de Debian: jamás silencies Valgrind
Hay un tercer caso que resume mejor que ningún otro lo frágil que es el oficio: el bug de OpenSSL en Debian, divulgado en mayo de 2008 (CVE-2008-0166, DSA-1571-1). En 2006, un desarrollador de Debian intentaba silenciar las advertencias de Valgrind, una herramienta de análisis de memoria, en el generador de números aleatorios de OpenSSL.
Para ello comentó dos líneas de la función MD_Update en md_rand.c, que mezclaban datos en el pool de entropía. Consultó el cambio en la lista de correo de OpenSSL, recibió un visto bueno que interpretó con excesiva confianza, y lo publicó. Para que se entienda un poco más sencillo: este desarrollador silencio una herramienta de desarrollo que le decía que había fallos en el generador de números aleatorio o RNG de OpenSSL. Muy mala idea.
El resultado: durante unos veinte meses, las claves generadas en Debian y Ubuntu se creaban con una fuente de aleatoriedad prácticamente vacía. En el caso más sonado, ssh-keygen solo podía generar 32.767 claves SSH distintas de cada tipo y tamaño, una por cada valor de ID de proceso, lo que significaba que miles de personas compartían la misma clave.
No se trataba de un error teórico: cualquier atacante podía reconstruir el espacio de claves en segundos. Millones de claves SSH, OpenVPN, DNSSEC y de certificados tuvieron que regenerarse. El bug lo encontró Luciano Bello y se corrigió en mayo de 2008, pero la lección es idéntica a la de Coldcard: un cambio que en apariencia mejora el ecosistema, en este caso limpiar la salida de una herramienta de depuración (nuevamente, una muy, pero muy mala idea), aplicado sobre el eslabón equivocado, destruyó la seguridad criptográfica de toda una distribución.
Distribuciones Linux Inmutables: Guía completa de distribuciones atómicas 2026
¿Por qué la criptografía es tan difícil de desarrollar?
Reunidos, estos tres casos apuntan a un mismo diagnóstico. El problema no es que las matemáticas sean débiles; es que la criptografía tiene propiedades que la hacen singularmente difícil de implementar bien.
En primer lugar, los fallos son silenciosos por naturaleza. Un bug de criptografía no crashea, no produce errores ni muestras datos corruptos. Produce una salida que parece correcta en todos los aspectos excepto en el único que importa: la imprevisibilidad. No existe una prueba de “este número es aleatorio” que funcione sobre una muestra finita; por eso el error de Coldcard sobrevivió cinco años y a múltiples auditorías, y por eso el de Debian sobrevivió veinte meses con miles de usuarios generando claves.
En segundo lugar, los errores no viven donde se busca. La criptografía se rompe en la integración: en una macro mal configurada, en una comprobación que verifica lo incorrecto, en dos líneas borradas por razones de herramienta. Los auditores buscan fallos en los algoritmos y en las rutinas criptográficas, y rara vez verifican qué código se ejecuta realmente en la ruta crítica con la configuración de producción. En los tres casos, la revisión del código existía; lo que falló fue la verificación de la ejecución.
Una pesadilla asimétrica
En tercer lugar, la asimetría del esfuerzo es brutal. El defensor tiene que ser correcto el 100% de las veces, en todas las configuraciones, durante toda la vida del producto; el atacante solo necesita tener razón una vez, y tiene todo el tiempo y todo el cómputo que quiera. Un único agujero de 40 bits convirtió un dispositivo cuyo marketing entero descansa en ser “imposible de piratear”, en un cajón abierto para quince ataques en una semana.
Y en cuarto lugar, la corrección no es lo mismo que la reparación. En la mayoría del software, un bug se arregla y se acabó. En criptografía, un fallo en la generación de secretos no se repara: el secreto comprometido es irrecuperable, y el remedio, revocar claves, reemitir certificados, regenerar seeds, migrar fondos, lo paga el usuario final. Heartbleed obligó a revocar claves de media Internet; Coldcard obliga a cada titular afectado a reconstruir su cartera desde cero y a confiar en que la nueva sí sea aleatoria.
Protegerla, a toda costa
Y esto deja en claro porque debemos proteger la criptografía a toda costa. Toda la seguridad digital moderna descansa sobre esta capa. HTTPS, banca, mensajería cifrada, firmas electrónicas, elecciones, identidad y, por supuesto, la autocustodia de criptoactivos: cuando la criptografía de base falla, falla todo lo que está construido encima, y no de forma parcial. La confianza criptográfica es binaria. Un certificado que pudo ser descifrado no es un certificado “un poco menos seguro”; un seed predecible no es una cartera “un poco más débil”; es una cartera que, en algún momento, alguien más posee.
De allí que cosas como; la política de sembrar puestas traseras o debilitar intencionalmente el cifrado para «no permitir que los malos se salgan con la suya», no es un arma de doble filo, es directamente la sentencia de muerte para la seguridad digital. Es algo por lo que siempre se debe ir en contra, a cualquier precio.
Ciberseguridad en la Era de la IA: Cómo los equipos Red, Blue y Green protegen tu empresa
Más que una tarea de nicho
Por eso proteger la criptografía, el código, los generadores, los protocolos, la cadena de suministro que los entrega, no es una tarea de nicho. Es la infraestructura crítica sobre la que se sostiene todo lo demás, y su mantenimiento ha demostrado ser sistemáticamente infrafinanciado: OpenSSL protegía dos tercios de la web con un equipo mínimo en 2014, y el firmware de Coldcard, uno de los productos más auditados de su categoría, llevaba el error en el código sin que nadie se diera cuenta durante cinco años.
El incidente de Coldcard añade, además, una capa de ironía difícil de ignorar. El producto se vendía precisamente como la solución al problema de la confianza: aire aislado, código abierto, sin dependencias. Y aun así, el fallo no estaba en el hardware ni en la red, sino en un error de configuración que convirtió la aleatoriedad, en una fuente determinista. Lo mismo que en Heartbleed y en Debian. Después de todo, la criptografía no se rompe donde se sospecha, se rompe donde nadie estaba mirando.