From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Stepan Snigirev <snigirev.stepan@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers
Date: Fri, 28 Feb 2020 13:31:29 +0000 [thread overview]
Message-ID: <Uq2NsrNplL04Cy7WTEEE7Yumjd2l2hqzYlbC31GnRajh8218N-1zeHvFZ6oxdYa-gDpbGHUGH6FvKbkZokzQygz_jRkIKt3sZe0HC2WmqT4=@protonmail.com> (raw)
In-Reply-To: <CACL8y1vNEOfATJvkYTOV3pZQA5uac3hbTe9Onfz-38zJUzL_Ug@mail.gmail.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
next prev parent reply other threads:[~2020-02-28 13:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 2:59 Stepan Snigirev
2020-02-28 13:31 ` ZmnSCPxj [this message]
2020-02-28 14:40 ` Stepan Snigirev
2020-02-28 17:42 ` Marko
2020-03-02 19:45 ` Dustin Dettmer
2020-03-02 20:01 ` Dustin Dettmer
2020-02-27 3:26 freedom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='Uq2NsrNplL04Cy7WTEEE7Yumjd2l2hqzYlbC31GnRajh8218N-1zeHvFZ6oxdYa-gDpbGHUGH6FvKbkZokzQygz_jRkIKt3sZe0HC2WmqT4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=snigirev.stepan@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox