El fin de la era del código cerrado está cerca: la oscuridad nunca fue seguridad
Puntos clave
- •Un error de preprocesador en los monederos de hardware Coldcard redujo la entropía de la seed a aproximadamente 40 bits, lo que permitió a los atacantes enumerar semillas posibles con hardware de consumo y robar casi $90 millones en unas 4,585 direcciones.
- •La vulnerabilidad se introdujo en marzo de 2021 y permaneció presente en firmware de lectura pública durante más de cinco años sin ser detectada por revisión humana.
- •Los investigadores han demostrado que varios modelos de IA de frontera pueden identificar el mismo fallo de entropía en minutos a partir de un solo prompt, lo que subraya la creciente capacidad de la IA para analizar vulnerabilidades de código.
- •El autor sostiene que el software de código cerrado y los secretos comerciales en productos distribuidos ofrecen una protección cada vez menor a medida que la ingeniería inversa impulsada por IA se vuelve más rápida y accesible.
- •Los defensores conservan una ventaja estructural de tiempo frente a los atacantes y deberían aplicar modelos de frontera a su propio código antes del lanzamiento, implementar compilaciones reproducibles y distribuir claves entre implementaciones independientes.

Bitcoin Magazine El fin de la era del código cerrado está cerca: la oscuridad nunca fue seguridad
En los últimos días, personas que trataban de hacer todo bien perdieron su Bitcoin. Compraron un respetado firmante de hardware, generaron una seed sin conexión usando ese dispositivo y confiaron en que el dispositivo haría la única tarea que existe para cumplir un firmante: producir un número que nadie más pueda adivinar. Coldcard no lo hizo. Un guard de preprocesador que comprobaba la condición equivocada había redirigido en silencio la generación de la seed hacia un débil PRNG (generador seudorrandom) de software, Yasmarang de MicroPython, en lugar de la fuente de entropía del hardware. En algunos modelos, la entropía efectiva cayó a alrededor de 40 bits . El fallo se publicó en marzo de 2021 y permaneció en firmware de lectura pública durante más de cinco años. Los atacantes barrían 500 direcciones antes de que alguien entendiera por qué; en pocos días, el conteo de Galaxy Research llegó a 4,585 direcciones y casi $90 millones; el ataque seguía activo a la fecha de este artículo.
La hipótesis de trabajo de Coinkite, ampliamente compartida en X, es que alguien usó IA para revisar el firmware disponible públicamente y encontrar el bug. Haya sido así o no como este atacante lo encontró, el siguiente lo hará. Aunque semanas antes del robo se realizó una auditoría asistida por IA, no encontró nada (posiblemente por las capacidades del modelo, posiblemente por la construcción específica de la búsqueda ). Desde que comenzó el ataque, investigadores han demostrado que varios modelos de frontera localizan el mismo fallo en minutos a partir de un solo prompt . El código estuvo abierto a revisión humana durante cinco años y ningún humano lo detectó.
Coinkite había trasladado su firmware de una licencia de software libre a términos con código disponible, MIT con una Commons Clause , después de que Foundation Devices utilizara el código en un producto competidor . Se podía leer el código fuente, pero no construir un negocio sobre él. No cambió nada. El bug vivía en código que una máquina podía leer independientemente de lo que permitiera la licencia; de hecho, entró en el árbol en la misma reescritura que eliminó los últimos restos de código GPL . El cambio de licencia no aumentó la protección; solo modificó la economía de encontrar el fallo.
En la era de la IA altamente capaz, todo lo que se distribuye es legible, o pronto lo será. Quitar los símbolos de un binario y pasarlo por un decompilador produce el pseudo-C que recibe cualquiera que haya abierto Ghidra: variables sin nombre, flujo de control aplanado, funciones etiquetadas FUN_00401a20. Incomprensible para la mayoría de las personas. Esa alta barrera para la comprensión humana era toda la prima de seguridad del “código cerrado”.
Un programa compilado no tiene opción más que decir la verdad. El código que permanece cifrado no puede ejecutarse. En el momento de la ejecución, el procesador debe recibir las instrucciones reales, así que, haga lo que haga el programa, entrega a la máquina un relato completo y exacto de cómo hacerlo. La información está toda ahí en el código máquina. La ofuscación no la elimina, ni puede hacerlo.
Si leer un binario parece demasiado difícil para que una máquina lo domine pronto, compárelo con lo que las máquinas ya hacen en problemas mucho más difíciles. Leer un binario es análisis: todos los hechos que necesitas están delante de ti, y el trabajo es extraerlos. La invención matemática es otro orden de dificultad, porque exige un objeto que nadie ha visto antes. A las 02:19 UTC del 20 de julio, Levent Alpöge, un matemático que trabaja con Claude Fable 5 de Anthropic, publicó un contraejemplo a la conjetura jacobiana de Keller , un problema abierto desde 1939 y lo bastante difícil como para figurar en la lista de retos de Stephen Smale para el siglo XXI. Generaciones lo habían intentado. La refutación son tres polinomios en tres variables. Lean la verificó en cuestión de horas , y es lo bastante corta para que cualquiera la confirme en un sistema de álgebra computacional en aproximadamente un minuto .
La jacobiana cayó en una tarde, mientras quien formuló la pregunta aparentemente veía la final de la FIFA World Cup. En mayo, un modelo de OpenAI derribó la conjetura de distancia unitaria de Erdős , una cuestión abierta desde 1946; a finales de julio, una conjetura de teoría de grafos de 30 años cayó tras cuatro prompts ; entre ambos hechos llegaron la refutación de la jacobiana y una serie de otros resultados que habían resistido durante décadas .
Ponga ese ritmo junto a la tarea modesta de leer código máquina ya disponible en Internet. Hoy los modelos manejan mejor el código fuente y la salida del decompilador que los bytes en bruto, así que un binario totalmente cerrado conserva apenas un margen estrecho. Ese margen es un obstáculo de coste, y se está erosionando a la misma velocidad que se ve en todas partes. Apostar la seguridad a cuánto dure significa apostar contra un reloj que solo acelera.
La misma capacidad que encuentra tu bug de entropía lee tu método propietario. Esta es la víctima menos visible, y afecta a empresas que nunca se pensaron expuestas a nada de código abierto. El secreto industrial en software distribuido siempre fue solo oscuridad con traje. La ley lo ha dicho así desde que existe la legislación sobre secretos comerciales : hacer ingeniería inversa de un producto que posees legalmente es juego limpio , y por tanto un secreto solo sobrevive mientras esa ingeniería inversa siga siendo costosa. Cuando el coste de extracción cae al nivel de una suscripción y un prompt, el secreto incorporado en el código que entregas a tus clientes deja de serlo. Tu algoritmo ingenioso, tu formato no documentado, tu ventaja en el binario: legibles para cualquiera que quiera mirar, en un plazo que cada vez se mide en minutos.
Nada de esto hace que el código abierto sea necesariamente seguro. Heartbleed se escondió en la biblioteca TLS más desplegada del mundo durante dos años, porque la visibilidad sin atención financiada no encuentra nada. La puerta trasera de xz mostró que el propio modelo de contribución abierta es una superficie de ataque, por la que un adversario paciente puede pasar con una cara amable y dos años de buenos commits. Aunque la apertura antes era un escudo, ya no lo es. Lo que sí ofrece son revisores autorizados a mirar, compilaciones que pueden reproducirse y verificarse de forma independiente, una salida cuando un proveedor muere o cambia de rumbo, y el reconocimiento de que todo esto ocurrirá te guste o no.
Ahora debemos asumir que cada línea enviada será leída por alguien que desea hacer daño, porque lo será. El defensor conserva una ventaja estructural que el atacante nunca tendrá: tiempo. Puedes aplicar los mismos modelos de frontera a tu propio código antes del lanzamiento, en el espacio entre el commit y el envío, mientras el atacante espera un binario que aún no existe. Haz que tus compilaciones sean reproducibles , para que se enlacen de nuevo al código fuente y el código fuente pueda verificarse. Diseña para fallar cerrado, y mantén el núcleo de confianza lo bastante pequeño como para que un solo bug no pueda llevárselo todo. Para el negocio específico de mantener Bitcoin, aprende la lección que Coldcard está enseñando en tiempo real: controla la entropía que no puedes permitirte que sea adivinada, mantén el elemento seguro mínimo y detrás de una interfaz publicada, y distribuye tus claves entre implementaciones independientes, de modo que ningún dispositivo, y ningún error de un solo proveedor, sea todo tu riesgo.
Para Bitcoin, lo que está en juego es implacable de una manera que no lo es en otros ámbitos, ya que el mero conocimiento de las claves privadas otorga posesión. El bug de entropía ha dejado cicatrices permanentes. Corregir el generador no hace nada por las semillas que ya produjo; un espacio de claves débil sigue siendo barrible para siempre, y la divulgación entrega al atacante la receta. Ya hemos visto esto antes. La vulnerabilidad Milk Sad en la herramienta bx del explorador de libbitcoin sembraba claves privadas a partir de un valor de 32 bits , y los atacantes estaban vaciando los monederos que generaba antes de que el fallo se hiciera público. Los atacantes siguen su propio calendario, invitados o no. Para dinero que no puede recuperarse una vez gastado, “localizable eventualmente” es sinónimo de “perdido eventualmente”.
Bitcoin nunca confió en la oscuridad. El protocolo es abierto, sus reglas pueden ser verificadas por cualquiera, y su seguridad no descansa en secretos, sino en matemáticas e incentivos que se sostienen a la vista de todos. El hardware y el software que construimos a su alrededor merecen el mismo estándar, porque la alternativa ya no está sobre la mesa. La elección nunca fue abierta o cerrada. Fue disciplinada o expuesta.
La lección más amplia de esta situación con Coldcard es que tener software de código cerrado es como tener una seed generada por un Coldcard defectuoso; parece bien, pero está construida sobre arena. Todos pueden leer el código — la única pregunta que queda es si reconoces ese hecho, o si tú y tus usuarios lo aprenden como lo hicieron los usuarios de Coldcard, una dirección vaciada a la vez.
Este es un artículo invitado de Colin Crossman, productor de contenido en Fedi. Las opiniones expresadas son exclusivamente suyas y no reflejan necesariamente las de BTC Inc o Bitcoin Magazine. Esta publicación El fin de la era del código cerrado está cerca: la oscuridad nunca fue seguridad apareció por primera vez en Bitcoin Magazine y fue escrita por Colin Crossman .