Nonce blinding protocol for hardware wallets and airgapped signers [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2020-03-02T20:01:51+00:00


Summary:

Stepan Snigirev has proposed a protocol for signing messages using an air-gapped computer or hardware wallet in the Bitcoin development mailing list. This comes in response to the acknowledgment that these devices can be compromised through supply chain attacks or malicious firmware updates. The proposed protocol aims to reduce the attack surface by involving additional entropy from the host. The protocol requires the host to pick a random number `n` and send its hash along with the message `m` to the signer. The signer calculates a nonce `k` and sends the corresponding point `R=kG` to the host, committing to the chosen nonce. The preimage `n` is then sent to the signer, who tweaks the nonce by this number and signs the message. The signed message is sent back to the host, who verifies that the public point in the signature is tweaked by `n`.Extensions to the protocol are also suggested by Snigirev. One extension involves the use of multiple hosts, where all hosts don't trust each other and the signer. In this case, hosts can concatenate hashes and preimages to add external entropy to the nonce. Another extension involves the use of a stateless random signer. If the signer wants to generate a nonce non-deterministically but doesn't have the ability to store it, they can send back meta-information to the host that would help regenerate the same nonce later.The proposed protocol can be implemented for PSBT using key-value pairs added to BIP-174. These include keys such as {PSBT_IN_EXT_NONCE_HASH}|{pubkey} for sha256(n1)|sha256(n2)|..., {PSBT_IN_NONCE_COMMITMENT}|{pubkey} for the 33-byte R point, {PSBT_IN_NONCE_SIGNER_METADATA}|{pubkey} for any value, and {PSBT_IN_EXT_NONCE_PREIMAGE}|{pubkey} for n1|n2|....Marko expresses gratitude for the implementation of a protocol for PSBT anti-nonce covert channel and backports the scheme to ECDSA in the secp256k1 library. He suggests using the generalized sign-to-contract scheme in PSBT, where the final nonce is computed as `k' = k + H(k*G, n)` instead of `k'=k+n`. Proprietary fields or key-value pairs can be added to BIP-174 depending on the interest of others. Careful verification against the state stored by the host for the PSBT is necessary to avoid implementation mistakes and private key leakage.The writer appreciates the initiative of implementing and releasing a protocol inspired by a blog post. The protocol was implemented in the secp256k1 library for Schnorr sigs and backported to ECDSA for current transactions. Proof of concepts were made to verify its effectiveness. The generalized sign-to-contract scheme was used in these implementations, with the final nonce computed as `k' = k + H(k*G, n)`. However, caution is advised when implementing the protocol with an air-gapped signer, as wrong implementation could lead to private key leaks. Guidelines and best practices to avoid pitfalls are requested.When generating a digital signature, it is unsafe to use only the message and private key. Instead, all data from the host should be used to create a nonce. Multiple blinding factors can also be used. If completely random nonces cannot be gathered due to insufficient entropy, any available source of entropy can be mixed into the nonce generation function. Glitch attacks, where two identical messages produce different signatures due to a flipped bit in the message, can be prevented by including a monotonic counter in the nonce generation function. The Yubikey had a problem with RNG initialization that caused private key leakage, so it's recommended to avoid pure RNG-generated nonces.The compromise of hardware wallets and air-gapped computers is discussed, highlighting the risks of supply chain attacks and malicious firmware updates. The proposed protocol aims to address these concerns by involving additional entropy from the host in the signing process. It is noted that using a deterministic scheme with only the message and privkey would be unsafe in certain scenarios. To prevent targeted attacks, it's recommended to derive the nonce from the message, `sha256(n)`, and the privkey mixed together using a suitable hashing function. While completely random nonces are ideal, resource limitations may prevent their use.Stepan Snigirev proposes a protocol to prevent the compromise of hardware wallets or air-gapped computers used for signing transactions. The protocol involves the host picking a random number and sending its hash along with the message to the signer, who computes a nonce and commits to it by sending the corresponding point to the host. The preimage is then sent back to the signer, who tweaks the nonce and signs the message. The host verifies that the public point in the signature is tweaked by the same amount.


Updated on: 2023-08-02T01:53:12.423124+00:00