Bitcoin Core modifie sa sécurité, l’IA aidant à détecter les failles

Bitcoin Core change de stratégie à mesure que l’IA gagne en intelligence

Dans un message adressé le 22 octobre à la liste de diffusion des développeurs de Bitcoin, Antoine Poinsot, développeur de Bitcoin Core, a annoncé des modifications de la politique de divulgation des vulnérabilités du projet, invoquant un nombre croissant de rapports de sécurité concernant des bogues pouvant être découverts ou redécouverts avec un minimum d’effort.

« Nous avons récemment constaté une augmentation du nombre de rapports concernant des failles de sécurité pouvant être facilement (re)découvertes », a écrit M. Poinsot. « Cela est en grande partie dû au fait que les LLM abaissent considérablement le seuil nécessaire pour détecter certaines catégories de problèmes ou identifier des correctifs dissimulés. »

Les grands modèles linguistiques, ou LLM, constituent la technologie sous-jacente aux assistants IA tels que ChatGPT. Leur capacité croissante à analyser le code logiciel représente un défi pour les développeurs qui tentent de trouver un équilibre entre la transparence et la nécessité de protéger les utilisateurs contre les attaques.

Historiquement, Bitcoin Core — le logiciel qui sous-tend le réseau décentralisé de la principale cryptomonnaie — a privilégié de longs délais d’embargo sur la divulgation, laissant aux utilisateurs le temps de mettre à jour leur logiciel avant que le public n’ait connaissance des vulnérabilités. Cette approche reflète la nature décentralisée de Bitcoin et une culture de mise à jour relativement lente parmi les opérateurs de nœuds.

Cependant, ces délais de non-divulgation ont également compliqué les efforts visant à fournir des correctifs de sécurité aux utilisateurs exécutant d’anciennes versions de Bitcoin Core. « Pour ces problèmes faciles à détecter, ce n’est pas le bon compromis », a déclaré M. Poinsot. « La période de non-divulgation n’apporte pas grand-chose, si ce n’est retarder la mise à disposition d’une version corrigée. »

Dans le cadre de la politique révisée, les développeurs de Bitcoin Core peuvent désormais classer les vulnérabilités comme « facilement détectables » lors de leur évaluation initiale. Cette désignation inclut les failles pouvant être mises au jour à l’aide d’une simple requête d’IA, bien qu’elle ne se limite pas aux vulnérabilités détectées à l’aide de l’intelligence artificielle.

Plutôt que de retenir les correctifs jusqu’à la prochaine version majeure du logiciel, les développeurs appliqueront les correctifs à toutes les versions majeures activement maintenues et publieront les mises à jour aussi rapidement que possible. Un avis de sécurité public accompagnera les versions corrigées, contournant ainsi les périodes d’embargo habituelles.

Ces changements ont été officialisés dans une pull request GitHub soumise par Poinsot le 16 octobre et fusionnée le 22 octobre. Outre la création de cette nouvelle classification des vulnérabilités, la révision modifie la formulation exigeant un préavis de deux semaines avant la divulgation publique, en précisant que cette exigence s’applique aux vulnérabilités encore soumises à un embargo.

La discussion qui a suivi a également mis en évidence des compromis potentiels. Poinsot a reconnu que l’accélération des publications de sécurité pourrait réduire le temps disponible pour tester les correctifs dans les branches de développement, tout en faisant valoir que des correctifs simples et facilement vérifiables pourraient être préférables aux tentatives de dissimulation de vulnérabilités que les outils d’IA pourraient de toute façon découvrir.

D'autres développeurs ont débattu de la question de savoir si les utilisateurs devraient parfois recevoir des avertissements avant que les correctifs ne soient disponibles, bien que la politique adoptée prévoie la publication d'avis de sécurité parallèlement aux versions corrigées.

Comment cette évolution modifie les divulgations de sécurité

Ces changements marquent une rupture significative par rapport à l’approche précédente de Bitcoin Core, qui liait généralement la divulgation des vulnérabilités à la gravité d’une faille et au cycle de vie des versions logicielles concernées.

Dans le cadre actuel basé sur la gravité, les vulnérabilités de faible gravité sont divulguées publiquement deux semaines après la sortie d’une version majeure contenant un correctif. Les vulnérabilités de gravité moyenne et élevée sont soumises à des délais de non-divulgation considérablement plus longs, la divulgation ayant lieu deux semaines après que la dernière version concernée a atteint le statut de fin de vie, généralement environ un an après le correctif initial.

Ces délais restent en vigueur pour les vulnérabilités qui ne sont pas considérées comme facilement détectables. Les failles critiques qui menacent la sécurité fondamentale de Bitcoin, notamment les bogues capables de créer des pièces non autorisées ou de provoquer des scissions permanentes de la chaîne à l’échelle du réseau, continuent de nécessiter un traitement spécial en dehors de la politique standard.

Cette révision pourrait avoir des implications immédiates pour les utilisateurs exécutant d’anciennes versions du logiciel Bitcoin Core, car toutes les versions majeures faisant l’objet d’une maintenance active seraient éligibles à des correctifs accélérés en vertu des nouvelles règles. Ce changement de politique n’indique pas que la cryptographie de Bitcoin ait été compromise ni qu’une nouvelle faille spécifique ait été découverte. Elle reflète plutôt un environnement de sécurité en mutation, dans lequel les développeurs ne peuvent plus partir du principe que le fait de ne pas divulguer les détails d’une vulnérabilité empêchera les attaquants d’identifier de leur propre chef ces mêmes faiblesses. Pour Bitcoin Core, l’émergence d’outils d’IA de plus en plus performants fait pencher la balance vers une mise à disposition plus rapide des logiciels corrigés, plutôt que de s’appuyer sur le secret pour protéger les utilisateurs.

Plus tôt cette année, les développeurs du réseau cryptographique Zcash ont déclaré que l’IA avait été utilisée pour découvrir une vulnérabilité permettant de créer un nombre illimité de pièces, et que la conception du « shielded pool » du réseau, axée sur la confidentialité, rendait alors impossible de prouver que cette vulnérabilité n’avait pas été exploitée. Le cours du ZEC avait alors chuté en raison des craintes liées à d’éventuelles cryptomonnaies contrefaites.

En juillet, les développeurs ont mis à jour Zcash afin de remplacer le « shielded pool » par un nouveau système renforcé, et ont mis en place une vérification indépendante pour s’assurer que l’offre de ZEC n’avait pas été gonflée. Depuis, le cours du Zcash a plus que doublé.