OrangeSurf on Nostr: What is the nonce key exfiltration attack? When signing a bitcoin transaction a ...

What is the nonce key exfiltration attack?

When signing a bitcoin transaction a number is used to generate the signature, this number is used once, and is therefore called the nonce.

This should be a cryptographically secure random number, which is never reused.

Suppose an attacker compromises your signing device, and can get it to use a particular nonce, rather than a random number.
If they use part of your private key as the nonce, they can leak part of your private key out of your signing device with each transaction you sign and broadcast.

If you make enough transactions, they can reconstruct your whole private key, and steal your bitcoin, just by watching the bitcoin transactions being made and decoding each part of the private key.

They don't need to compromise your computer, or physically access your device, and all the while your signing device appears to be working correctly, up until all your bitcoin is stolen.

There have recently been two new papers expanding on this attack.
- Dark Skippy by Lloyd Fournier, Nick Farrow of FrostsnapTech and Robin Linus of ZeroSync and BitVM.
- Engineering a backdoored bitcoin wallet by Adam Scott and Sean Andersen at block

I think it's great that these researchers have raised attention to this previously known attack vector.

Now, there are two types of reaction in my x feed on this issue, panic and ambivalence.

⚠️ Reaction 1 - Panicked
Nonce key exfil would enable theft at a distance, on all devices that update to malicious firmware & make 12 transactions. The attack doesn't require compromising the online device the signer talks to. The attack is not mitigated on most signing devices, and therefore large amounts of bitcoin are potentially vulnerable. The attack would be undetectable until the thieving begins

🤷‍♂️ Reaction 2 - Ambivalent
This attack requires getting malicious firmware onto a device. Competent signing device firmware devs secure firmware signing key(s) appropriately. Provided the firmware signing keys are not compromised this attack is mitigated because most signing devices check new firmware signatures before upgrading. Malicious firmware would enable many other attacks like generation of compromised wallets or exfiltration of keys in other ways (via screen, microSD or USB).

I think both Panic and Ambivalence are extreme.

❌ Panicked - Most hardware wallets verify firmware signatures so this attack requires either malicious firmware or a compromised firmware signing key / build pipeline and for many transactions to be signed with that firmware. Anti-klepto requires the online wallet to participate and adoption is limited. Creating panic leads uninformed users to rush to move their bitcoin to a new setup and this is when mistakes happen.

❌ Ambivalent - This attack is particularly nefarious because it can be done at a distance without needing to compromise any other user devices which makes it very scalable. If any firmware release is compromised all devices that run that version will be compromised. How secure is your signing key? How secure is your build pipeline? If anti-klepto was widely supported you would probably use it, so let's get it widely supported.

💡 Constructive - Focus effort into adding anti-klepto to a new version of PSBT instead of taking shots at each other or dismissing concerns.