La biblioteca "externa" que rompió las claves de Coldcard la firmaba la llave personal del jefe técnico de Coinkite, y el aviso que la señalaba llegó catorce meses antes del primer robo

La biblioteca que generaba el azar de los monederos Coldcard se presentaba como una dependencia externa: repositorio ajeno, licencia MIT, un mantenedor pseudónimo llamado switck y un puñado de estrellas en GitHub. Desde el 30 de julio, cuando empezaron los barridos que ya han vaciado más de 5.200 direcciones, esa biblioteca es el centro del mayor robo de autocustodia de la historia de Bitcoin.

Y desde el 4 de agosto hay una prueba criptográfica de que el mantenedor pseudónimo firmaba con la llave personal del cofundador y jefe técnico de Coinkite, la empresa que fabrica los Coldcard. El censo lo publicó el desarrollador James O'Beirne y lo reprodujo el analista Dylan LeClair en un gist con guion ejecutable que no concluye nada y solo imprime hechos: 129 commits verificados uno a uno contra la clave que GitHub publica en la cuenta abierta de Peter D. Gray.

Una cuenta creada dos meses antes y un permiso concedido en ocho minutos

El detalle que más incomoda no está en la criptografía, sino en el registro de conversaciones. El 21 de octubre de 2020, a las 14:20:04 UTC, la cuenta doc-hex abrió la incidencia número 7 del repositorio switck/libngu para preguntar si aceptarían código de Coldcard. A las 14:28:02, ocho minutos después, switck respondió "not an issue" y cerró el hilo. Cuarenta y tres segundos más tarde volvió para matizar: "JK. just depends on PR". La cuenta pseudónima se había creado dos meses antes y sus únicos repositorios giraban alrededor de Coldcard.

La llave caducó en mayo de 2023, así que git log la marca como expirada, pero eso no invalida las firmas: una se hizo en marzo de 2024, y producirla exige tener la clave privada delante. El gist descarta las coartadas: rebasar destruye la firma, el identificador de la llave es personal y precede en siete años a la cuenta switck, y falsificarla exigiría otra vez la privada.

La línea que debía impedir esto y no lo impidió

El commit f19de05, del 28 de enero de 2021, con el mensaje "x", añadió el pegamento entre la biblioteca y el generador de azar del chip STM32. Incluía una guarda que sobre el papel hacía imposible el desastre: si el hardware no tenía generador verdadero, el compilador debía abortar con el error "get a HW TRNG plz". La guarda usaba #ifndef MICROPY_HW_ENABLE_RNG, y en C #ifndef comprueba si una macro está definida, no si vale verdadero. La placa de Coldcard la definía con valor 0 precisamente para desactivar el generador de MicroPython y usar el envoltorio propio. Como 0 sigue estando definido, la guarda pasó y la compilación salió limpia.

La función a prueba de fallos de la placa es estática, así que el extern rng_get() del pegamento no la encontró y resolvió al símbolo de MicroPython, que con la macro a 0 es Yasmarang, un generador determinista sembrado con el identificador del chip y unos temporizadores. La entropía efectiva quedó en unos 40 bits en los Mk2 y Mk3 y unos 72 en Mk4, Mk5 y Q, frente a los 128 que se le suponen a una semilla BIP-39 de doce palabras. Las dos cifras caben en lo que un atacante con recursos recorre a fuerza bruta sin tocar el dispositivo.

De siete consumidores de azar, solo se movieron los dos de la semilla

Un mes después, el commit b18723dd del firmware de Coldcard, titulado "First pass w/ libNgU" y firmado a cara descubierta como Peter D. Gray, cambió 120 ficheros y apuntó la generación de semillas a ese código. La migración no fue general: de los ficheros que usaban la interfaz de hardware, que falla en cerrado si no puede dar entropía buena, exactamente dos cambiaron, y son la semilla del monedero y el módulo que la alimenta.

Eso descarta las coartadas más cómodas: esos dos ficheros no importaban la biblioteca vieja que el resto del commit estaba abandonando, y la división sigue igual cinco años después. El fallo llegó a los usuarios con la versión 4.0.0 del firmware, en marzo de 2021.

Tampoco lo cazaron las pruebas. Tanto la batería de la propia biblioteca como el dieharder que el firmware ejecutaba sobre la salida miden la distribución de los bits, no su imprevisibilidad, y un generador determinista aprueba los dos exámenes sin sudar.

El aviso de mayo de 2025 y la respuesta que lo cerró

La parte más difícil de justificar no es técnica. En mayo de 2025, catorce meses antes del primer barrido, O'Beirne auditó el firmware por su cuenta, siguió el rastro del azar hasta esa biblioteca y lo comunicó a Coinkite. La describió como una dependencia de un solo mantenedor, con pocas estrellas y constantes escritas a mano, y recomendó arrancarla y enlazar directamente contra libsecp256k1.

Según su relato, le contestaron que si algo estuviera mal la empresa ya lo sabría, y que en las placas reales todo estaba bien configurado. La biblioteca se quedó. El 30 de julio de 2026 la primera oleada movió unos 594 BTC de alrededor de 500 direcciones en menos de una hora. Galaxy Research confirma 1.719 BTC robados, unos 111 millones de dólares, y los recuentos que suman la cuarta oleada apuntan a 130 millones y hasta quince atacantes distintos trabajando el mismo fallo.

La otra cara: una firma dice quién, no dice por qué

Conviene ser preciso con lo que esto demuestra. Las firmas establecen quién tenía la clave privada, y los diffs el orden de los hechos: quien tenía esa clave escribió el pegamento defectuoso como switck en enero, y la cuenta abierta conectó la semilla a ese código en marzo. Ninguna de las dos cosas establece intención, y el propio gist lo dice con todas las letras.

Hay además un argumento contra la lectura conspirativa. Escribir #ifndef donde se quería #if es uno de los errores más vulgares de C, y el mismo autor usó la forma correcta en el rng.c del firmware. Eso corta en las dos direcciones: conocía la construcción buena, y era capaz de equivocarse escribiendo la mala. Lo que queda en pie sin suponer nada es un problema de gobernanza: una pieza crítica de criptografía se mantuvo bajo una identidad que se presentaba como colaborador externo.

Coinkite ha reconocido el fallo, ha publicado un informe técnico y ha sacado firmware de emergencia para todos los modelos afectados, pero no ha respondido en público al vínculo entre las dos identidades. Actualizar el firmware no repara una semilla ya generada. Se salvaron quienes usaron suficientes tiradas de dado, quienes añadieron una frase de paso BIP-39 fuerte y única, y quienes montaron multifirma con el Coldcard como uno de varios firmantes.

A qué estar atento

Primero, si Coinkite responde por escrito a las preguntas que le han quedado sobre la mesa: por qué una biblioteca crítica se mantenía bajo una cuenta pseudónima ligada a la llave del jefe técnico, y por qué el informe externo de mayo de 2025 no escaló a una revisión del build.

Segundo, el frente legal. El despacho 117 Partners explora dos vías en paralelo, una demanda por producto defectuoso en Canadá y la recuperación de activos a los atacantes por tribunales estadounidenses. La evidencia de las firmas cambia el tono de la primera: ya no se discute solo un fallo de software, sino qué sabía la empresa de la procedencia de su propio código.

Tercero, el ecosistema. La biblioteca sigue siendo una dependencia directa del firmware en producción y la mayor parte del bitcoin robado permanece sin mover. Si otros fabricantes empiezan a publicar de quién es la llave que firma cada dependencia criptográfica que enlazan, la semana habrá servido para algo.

Datos: gist de verificación de Dylan LeClair (GitHub), censo de James O'Beirne, informes de Wizardsardine y del equipo de ingeniería de Bitcoin de Block, Galaxy Research, CryptoSlate, The Crypto Times, avisos de seguridad de Coinkite.