Bitcoin Core intègre un correctif pour une faille de signature pouvant rediriger des fonds sans exposer les clés
Points clés
- •Bitcoin Core a fusionné le 25 septembre un correctif empêchant la signature de PSBT dans les cas où le scénario limite SIGHASH_SINGLE de sortie manquante pourrait laisser une signature valide après modification du destinataire.
- •La faille n'expose pas les clés privées, mais pour les entrées legacy, une signature sur une valeur de hachage fixe pourrait potentiellement être réutilisée contre d'autres sorties non dépensées contrôlées par la même clé dans des conditions structurelles similaires.
- •Les signatures SegWit v0 s'engagent toujours sur la pièce spécifique dépensée et son montant, mais la sortie de destination peut rester non liée, créant un problème d'autorisation pour les portefeuilles et les dispositifs de signature.
- •La nouvelle vérification a été déplacée dans la logique partagée de création de signatures de Bitcoin Core, étendant le rejet existant des transactions brutes à la voie PSBT, y compris la commande walletprocesspsbt, tout en permettant aux entrées valides de la même PSBT de procéder.
- •Au 4 octobre, aucune version de production ni rétroportage confirmé ne contenait la protection, incitant les fournisseurs de portefeuilles et les intégrations de signature matérielle à revoir leur propre gestion des demandes SIGHASH_SINGLE plutôt que d'attendre une version de Bitcoin Core.

Bitcoin Core a ajouté une protection contre la signature de transactions qui peuvent ne pas lier cryptographiquement les fonds à la destination de paiement approuvée par l'utilisateur. La modification, fusionnée dans la branche de développement master du projet le 25 septembre, cible une faille étroite dans les transactions Bitcoin partiellement signées, ou PSBT, qui pouvait produire une signature valide sans protéger la sortie prévue. Bitcoin Optech a mis en évidence cette mise à jour le 2 octobre.
Le problème n'expose pas la clé privée de l'utilisateur. Il crée en revanche un risque différent : dans des conditions spécifiques, une signature peut rester valide même après modification du destinataire de la transaction.
Comment fonctionne la faiblesse SIGHASH_SINGLE
Chaque signature Bitcoin porte un indicateur sighash qui définit les parties de la transaction auxquelles la signature s'engage. SIGHASH_SINGLE est l'un de ces modes de signature, conçu pour engager une entrée à la sortie occupant la position correspondante dans une transaction. Lorsqu'aucune sortie n'existe à cette position, la protection se dégrade différemment selon le type de bitcoin dépensé.
Pour les entrées legacy, le cas de sortie manquante peut produire une signature sur une valeur de hachage fixe. Les développeurs de Bitcoin Core ont indiqué qu'une telle signature peut alors être réutilisable contre d'autres sorties non dépensées contrôlées par la même clé lorsque les mêmes conditions structurelles sont réunies.
Les transactions SegWit v0 conservent des protections plus fortes, car la signature s'engage toujours sur la pièce spécifique dépensée et son montant. La sortie de destination, however, peut rester non liée. Cela crée un problème d'autorisation pour les portefeuilles et les dispositifs de signature : un logiciel pourrait présenter un paiement à l'utilisateur tout en produisant une signature qui ne garantit pas cryptographiquement que le destinataire approuvé reste inchangé.
Bitcoin Core bloque la demande de signature à risque
Bitcoin Core rejetait déjà le cas limite via son interface de signature de transactions brutes, mais sa voie PSBT — y compris la commande walletprocesspsbt — pouvait encore la signer. Le nouveau code déplace la vérification dans la logique partagée de création de signatures de Bitcoin Core, de sorte que le même rejet s'applique désormais à l'ensemble des voies de signature de Bitcoin Core, empêchant la signature des entrées legacy et SegWit v0 affectées tout en permettant aux autres entrées valides de la même PSBT de procéder.
Les PSBT sont couramment utilisées pour coordonner les transactions entre portefeuilles logiciels, dispositifs matériels et signataires hors ligne. Elles permettent aux créateurs de transactions de transmettre des informations à un signataire distinct sans donner à ce système le contrôle des clés privées. Le correctif renforce donc une frontière que les développeurs de portefeuilles doivent faire respecter indépendamment de la sécurité des clés : une signature cryptographique valide doit s'engager sur les détails de la transaction que l'utilisateur a réellement autorisés.
Le Bitcoin Improvement Proposal 174, qui définit les PSBT, demande déjà aux signataires de rejeter les modes de signature inacceptables et recommande SIGHASH_ALL lorsqu'aucune alternative n'est spécifiée. La modification de Bitcoin Core empêche explicitement cette configuration de sortie manquante d'atteindre l'étape de signature.
Aucune version de production contenant le correctif pour l'instant
Les utilisateurs ne disposent pas encore d'une version de production confirmée contenant cette protection. La modification du 25 septembre a été fusionnée dans la branche de développement de Bitcoin Core, et les listes de versions publiées du projet n'avaient identifié ni version corrigée ni rétroportage confirmé au 4 octobre. Un rétroportage apporterait la même protection à une version déjà publiée ; tant qu'il n'apparaît pas dans les listes, la protection n'existe que dans la base de code de développement.
Cela laisse aux fournisseurs de portefeuilles et aux intégrations de signature matérielle une décision plus immédiate : revoir leur propre gestion des demandes SIGHASH_SINGLE plutôt que d'attendre qu'une version de Bitcoin Core applique la même protection en aval.
Le rapport original a été publié sur CryptoSlate.