Bitcoin Core modifica su política de seguridad: la IA detecta fallos más fácil

Bitcoin Core cambia de estrategia a medida que la IA se vuelve más inteligente

En un mensaje del 22 de octubre dirigido a la lista de correo de desarrollo de Bitcoin, el desarrollador de Bitcoin Core Antoine Poinsot anunció cambios en la política de divulgación de vulnerabilidades del proyecto, citando un número creciente de informes de seguridad relacionados con errores que pueden descubrirse o redescubrirse con un esfuerzo mínimo.

«Recientemente hemos experimentado un aumento en el número de informes sobre vulnerabilidades de seguridad que pueden (re)descubrirse fácilmente», escribió Poinsot. «Esto se debe en gran medida a que los modelos de lenguaje a gran escala (LLM) reducen drásticamente el umbral para encontrar ciertas clases de problemas o identificar correcciones ocultas».

Los modelos de lenguaje a gran escala, o LLM, son la tecnología en la que se basan los asistentes de IA como ChatGPT. Su creciente capacidad para analizar código de software supone un reto para los desarrolladores que intentan encontrar el equilibrio entre la transparencia y la necesidad de proteger a los usuarios frente a los ataques.

Históricamente, Bitcoin Core —el software que sustenta la red descentralizada de la principal criptomoneda— ha favorecido los largos embargos de divulgación, lo que da tiempo a los usuarios a actualizar su software antes de que el público se entere de las vulnerabilidades. Este enfoque refleja la naturaleza descentralizada de Bitcoin y una cultura de actualización relativamente lenta entre los operadores de nodos.

Sin embargo, esos embargos también han complicado los esfuerzos por proporcionar parches de seguridad a los usuarios que utilizan versiones antiguas de Bitcoin Core. «Para estos problemas que son fáciles de detectar, esta es una compensación errónea», afirmó Poinsot. «El periodo de embargo aporta poco, pero retrasa la disponibilidad de una versión corregida».

En virtud de la política revisada, los desarrolladores de Bitcoin Core ahora pueden clasificar las vulnerabilidades como «fácilmente detectables» durante su evaluación inicial. Esta designación incluye fallos que pueden descubrirse con una simple consulta de IA, aunque no se limita a las vulnerabilidades detectadas mediante inteligencia artificial.

En lugar de retener las correcciones hasta la próxima versión principal del software, los desarrolladores retroaplicarán los parches a todas las versiones principales que se mantengan activamente y publicarán las actualizaciones lo antes posible. Las versiones parcheadas irán acompañadas de un aviso de seguridad público, sin esperar a los habituales periodos de embargo.

Los cambios se formalizaron en una solicitud de incorporación de cambios (pull request) de GitHub presentada por Poinsot el 16 de octubre y fusionada el 22 de octubre. Además de crear la nueva clasificación de vulnerabilidades, la revisión modifica la redacción que exigía un preaviso de dos semanas antes de la divulgación pública, aclarando que dicho requisito se aplica a las vulnerabilidades que aún están sujetas a un embargo.

El debate que acompañó a esta decisión también puso de relieve posibles compensaciones. Poinsot reconoció que acelerar las versiones de seguridad podría reducir el tiempo disponible para probar las correcciones en las ramas de desarrollo, al tiempo que argumentó que los parches sencillos y fáciles de verificar pueden ser preferibles a los intentos de ocultar vulnerabilidades que las herramientas de IA podrían descubrir de todos modos.

Otros desarrolladores debatieron si los usuarios deberían recibir en ocasiones avisos antes de que las correcciones estén disponibles, aunque la política adoptada exige publicar avisos junto con las versiones parcheadas.

Cómo cambia esta medida la divulgación de información de seguridad

Los cambios suponen un cambio significativo con respecto al enfoque anterior de Bitcoin Core, que generalmente vinculaba la divulgación de vulnerabilidades a la gravedad de un fallo y al ciclo de vida de las versiones de software afectadas.

Bajo el marco actual basado en la gravedad, las vulnerabilidades de baja gravedad se divulgan públicamente dos semanas después de una versión principal que contenga una corrección. Las vulnerabilidades de gravedad media y alta se enfrentan a embargos considerablemente más largos, y su divulgación tiene lugar dos semanas después de que la última versión afectada alcance el estado de fin de vida útil, normalmente aproximadamente un año después de la corrección inicial.

Esos plazos se mantienen para las vulnerabilidades que no se consideran fácilmente detectables. Los fallos críticos que amenazan la seguridad fundamental de Bitcoin, incluidos los errores capaces de crear monedas no autorizadas o de provocar divisiones permanentes de la cadena en toda la red, siguen requiriendo un tratamiento especial al margen de la política estándar.

La revisión podría tener implicaciones inmediatas para los usuarios que ejecutan versiones antiguas del software Bitcoin Core, ya que todas las versiones principales en mantenimiento activo podrían optar a parches acelerados según las nuevas normas. El cambio de política no indica que la criptografía de Bitcoin se haya visto comprometida ni que se haya descubierto un nuevo exploit específico. Más bien, refleja un entorno de seguridad cambiante en el que los desarrolladores ya no pueden dar por sentado que ocultar los detalles de las vulnerabilidades impedirá que los atacantes identifiquen de forma independiente esas mismas debilidades. En el caso de Bitcoin Core, la aparición de herramientas de IA cada vez más potentes está inclinando la balanza hacia la disponibilidad más temprana del software parcheado, en lugar de confiar en el secretismo para proteger a los usuarios.

A principios de este año, los desarrolladores de la red de criptomonedas Zcash afirmaron que se había utilizado IA para descubrir una vulnerabilidad que permitía acuñar monedas de forma ilimitada, y el diseño del «shielded pool» de la red, centrado en la privacidad, hizo imposible en aquel momento demostrar que no se hubiera explotado. El precio del ZEC se desplomó en aquel momento debido a la preocupación por la posible falsificación de monedas.

En julio, los desarrolladores actualizaron Zcash para sustituir el «shielded pool» por uno nuevo y más seguro, y añadieron una verificación independiente para garantizar que la oferta de ZEC no se hubiera inflado. Desde entonces, el precio de Zcash se ha más que duplicado.