Bitcoin Core hat eine Schutzmaßnahme gegen das Signieren von Transaktionen hinzugefügt, die die Mittel möglicherweise nicht kryptografisch an das vom Nutzer genehmigte Zahlungsziel binden. Die Änderung, die am 25. September in den Master-Entwicklungsbranch des Projekts gemerged wurde, zielt auf eine enge Schwachstelle bei teilweise signierten Bitcoin-Transaktionen, sogenannten PSBTs, ab, die eine gültige Signatur erzeugen könnte, ohne den vorgesehenen Output zu schützen. Bitcoin Optech hob die Aktualisierung am 2. Oktober hervor.

Das Problem legt den privaten Schlüssel eines Nutzers nicht offen. Stattdessen entsteht ein anderes Risiko: Unter bestimmten Bedingungen kann eine Signatur auch dann gültig bleiben, nachdem der Empfänger einer Transaktion geändert wurde.

Wie die SIGHASH_SINGLE-Schwachstelle funktioniert

Jede Bitcoin-Signatur trägt ein Sighash-Flag, das festlegt, auf welche Teile einer Transaktion sich die Signatur bezieht. SIGHASH_SINGLE ist einer dieser Signiermodi, der einen Input an den Output an der entsprechenden Position in einer Transaktion binden soll. Wenn an dieser Position kein Output existiert, versagt der Schutz in Abhängigkeit von der Art des ausgegebenen Bitcoins auf unterschiedliche Weise.

Bei Legacy-Inputs kann der fehlende-Output-Fall zu einer Signatur über einen festen Hashwert führen. Bitcoin-Core-Entwickler erklärten, dass eine solche Signatur dann gegen andere Unspent Outputs desselben Schlüssels wiederverwendet werden könnte, wenn dieselben strukturellen Bedingungen vorliegen.

SegWit-v0-Transaktionen behalten stärkere Schutzmechanismen, da sich die Signatur weiterhin auf den spezifischen ausgegebenen Coin und dessen Betrag bezieht. Der Ziel-Output kann jedoch ungebunden bleiben. Das schafft ein Autorisierungsproblem für Wallets und Signiergeräte: Software könnte dem Nutzer eine Zahlung anzeigen, während sie eine Signatur erzeugt, die nicht kryptografisch garantiert, dass der genehmigte Empfänger unverändert bleibt.

Bitcoin Core blockiert die riskante Signieranfrage

Bitcoin Core wies den Grenzfall bereits über seine Raw-Transaction-Signierschnittstelle zurück, doch sein PSBT-Pfad — einschließlich des Befehls walletprocesspsbt — konnte ihn weiterhin signieren. Der neue Code verlagert die Prüfung in die gemeinsame Signaturerstellungslogik von Bitcoin Core, sodass dieselbe Zurückweisung nun über alle Signierpfade von Bitcoin Core hinweg gilt. Das verhindert das Signieren betroffener Legacy- und SegWit-v0-Inputs, während andere gültige Inputs in derselben PSBT fortfahren.

PSBTs werden häufig verwendet, um Transaktionen zwischen Software-Wallets, Hardware-Geräten und Offline-Signern zu koordinieren. Sie ermöglichen es Transaktionserstellern, Informationen an einen separaten Signer zu übergeben, ohne diesem System die Kontrolle über die privaten Schlüssel zu geben. Der Fix stärkt daher eine Grenze, die Wallet-Entwickler unabhängig von der Schlüsselsicherheit durchsetzen müssen: Eine gültige kryptografische Signatur muss sich auf die Transaktionsdetails beziehen, die der Nutzer tatsächlich autorisiert hat.

Bitcoin Improvement Proposal 174, das PSBTs definiert, weist Signer bereits an, unzulässige Signiermodi zurückzuweisen, und empfiehlt SIGHASH_ALL, wenn keine Alternative angegeben ist. Die Bitcoin-Core-Änderung verhindert ausdrücklich, dass diese Konfiguration mit fehlendem Output die Signierstufe erreicht.

Noch keine Produktionsversion mit dem Fix

Nutzern liegt bisher keine bestätigte Produktionsversion mit der Schutzmaßnahme vor. Die Änderung vom 25. September wurde in den Entwicklungsbranch von Bitcoin Core gemerged, und die veröffentlichten Release-Listen des Projekts hatten bis zum 4. Oktober weder eine korrigierte Version identifiziert noch einen Backport bestätigt. Ein Backport würde dieselbe Schutzmaßnahme in eine bereits veröffentlichte Version übertragen; bis eine in den Listen erscheint, existiert der Schutz nur im Entwicklungscodebase.

Das lässt Wallet-Anbieter und Hardware-Signing-Integrationen mit einer unmittelbaren Entscheidung zurück: ihre eigene Behandlung von SIGHASH_SINGLE-Anfragen zu überprüfen, anstatt auf eine Bitcoin-Core-Version zu warten, die denselben Schutz nachgelagert durchsetzt.

Der Originalbericht wurde auf CryptoSlate veröffentlicht.