Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Stepan,

> This topic appeared in the list a few times so I would like to discuss it in more detail and maybe push forward to standardization.
>
> We have to accept that any hardware wallet or an air-gapped computer we use to sign transactions can be compromised. It may happen via a supply chain attack or malicious firmware update.
>
> If the signer is isolated (faraday cage, airgap and so on), it still can leak private keys to the outside world by choosing nonces for signatures in a funny way such that the attacker can calculate our private keys. Back in the days, I wrote a small post [1] and a proof-of-concept demo [2] of this attack.
>
> Deterministic nonce generation can be verified only if we have private keys somewhere else. It doubles the attack surface - now we need to maintain two independent signers from different vendors that use the same private key and the same deterministic algorithm for a nonce generation. In addition to that, as Pieter mentioned in the Schnorr-BIP, deterministic nonces are vulnerable to glitch attacks [3].
>
> A simple way to fix it is by forcing the signer to use additional entropy from the host. This protocol takes away the privilege of picking nonce from the signer and doesn't require any secret material outside the signer.
>
> I suggest the following implementation of the protocol for signing a message `m`:
>
> 1. Host picks a random number `n` and sends its hash together with the message `m` to the signer.
> 2. Signer computes a nonce `k` it wants to use for signing. It can be either a deterministic scheme or using RNG. Signer commits to the chosen nonce by sending the corresponding point `R=kG` to the host.

I think it would be unsafe to use a deterministic scheme, that takes as input the message m and the privkey only.

Let us consider the case where the hardware signer has its power supply coming from USB and the communication channel is over USB as well.
Thus, the host can selectively turn on/off the hardware signer (e.g. a hacker with physical access can just unplug it).

With R determined from m and the privkey, then the host knows the R that the signer will use, and can arrange an n that cancels that R and adds a specific R it wants to target.
It could, for example, arrange to have two different `m` signed with the same `R'`.

What would have to be done would be derive `k` from the message `m` plus the `sha256(n)` and the privkey.
Perhaps you considered this already, but it may be useful to have it explicitly stated that this has to be mixed as well, i.e. if `k` is generated deterministically it has to be `k = f(sha256(n), m, privkey)` where `f()` is some suitable hashing function.

Otherwise a completely-random `k` would be much better, but the signer might not have enough resources to gather sufficient entropy.

Regards,
ZmnSCPxj