diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-02-28 13:31:29 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-02-28 13:31:42 +0000 |
| commit | 2762d502a3c8531bf9ef1fd31097c735879d8199 (patch) | |
| tree | f905a23ab9bd248f3722a91d62a0dc63928d9900 | |
| parent | ee5ec1b11da097fd470f43802f5772e29b7a765d (diff) | |
| download | pi-bitcoindev-2762d502a3c8531bf9ef1fd31097c735879d8199.tar.gz pi-bitcoindev-2762d502a3c8531bf9ef1fd31097c735879d8199.zip | |
Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers
| -rw-r--r-- | ed/1ed1e67b9dbb1cc70bf94155aa8fb013c8e403 | 117 |
1 files changed, 117 insertions, 0 deletions
diff --git a/ed/1ed1e67b9dbb1cc70bf94155aa8fb013c8e403 b/ed/1ed1e67b9dbb1cc70bf94155aa8fb013c8e403 new file mode 100644 index 000000000..a003e1d45 --- /dev/null +++ b/ed/1ed1e67b9dbb1cc70bf94155aa8fb013c8e403 @@ -0,0 +1,117 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 7C9D1C0177 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Feb 2020 13:31:42 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by silver.osuosl.org (Postfix) with ESMTP id 6355520471 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Feb 2020 13:31:42 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from silver.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id cJ6E7otPJXhG + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Feb 2020 13:31:40 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) + by silver.osuosl.org (Postfix) with ESMTPS id 2D55C203F9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 28 Feb 2020 13:31:40 +0000 (UTC) +Date: Fri, 28 Feb 2020 13:31:29 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=default; t=1582896697; + bh=1kMuwud+oDmiZydpOmzdUHMZuV31Tq7w0sbBNZHydxU=; + h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: + From; + b=p7GFVEM2DTB4ApZp4d1HwaUiTHM6OE12LtVaqS5k66Sx1meA/T+F3t6hvLydm5c5r + xb0Gv5L1+W+9/mBcXQ8lqmgnu5qbfg7Vg9oAp1SMNF8IqZLn1EzCjo7G5vjbst2+YZ + F0aRO4ry44TcbSiMAzuMq7suVzBEc0uH44Dc/+to= +To: Stepan Snigirev <snigirev.stepan@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <Uq2NsrNplL04Cy7WTEEE7Yumjd2l2hqzYlbC31GnRajh8218N-1zeHvFZ6oxdYa-gDpbGHUGH6FvKbkZokzQygz_jRkIKt3sZe0HC2WmqT4=@protonmail.com> +In-Reply-To: <CACL8y1vNEOfATJvkYTOV3pZQA5uac3hbTe9Onfz-38zJUzL_Ug@mail.gmail.com> +References: <CACL8y1vNEOfATJvkYTOV3pZQA5uac3hbTe9Onfz-38zJUzL_Ug@mail.gmail.com> +Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +Subject: Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and + airgapped signers +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 28 Feb 2020 13:31:42 -0000 + +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 u= +se to sign transactions can be compromised. It may happen via a supply chai= +n 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 ke= +ys somewhere else. It doubles the attack surface - now we need to maintain = +two independent signers from different vendors that use the same private ke= +y and the same deterministic algorithm for a nonce generation. In addition = +to that, as Pieter mentioned in the Schnorr-BIP, deterministic nonces are v= +ulnerable 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 fro= +m the signer and doesn't require any secret material outside the signer. +> +> I suggest the following implementation of the protocol for signing a mess= +age `m`: +> +> 1. Host picks a random number `n` and sends its hash together with the me= +ssage `m` to the signer. +> 2. Signer computes a nonce `k` it wants to use for signing. It can be eit= +her a deterministic scheme or using RNG. Signer commits to the chosen nonce= + by sending the corresponding point `R=3DkG` to the host. + +I think it would be unsafe to use a deterministic scheme, that takes as inp= +ut the message m and the privkey only. + +Let us consider the case where the hardware signer has its power supply com= +ing 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 hack= +er with physical access can just unplug it). + +With R determined from m and the privkey, then the host knows the R that th= +e signer will use, and can arrange an n that cancels that R and adds a spec= +ific R it wants to target. +It could, for example, arrange to have two different `m` signed with the sa= +me `R'`. + +What would have to be done would be derive `k` from the message `m` plus th= +e `sha256(n)` and the privkey. +Perhaps you considered this already, but it may be useful to have it explic= +itly stated that this has to be mixed as well, i.e. if `k` is generated det= +erministically it has to be `k =3D f(sha256(n), m, privkey)` where `f()` is= + some suitable hashing function. + +Otherwise a completely-random `k` would be much better, but the signer migh= +t not have enough resources to gather sufficient entropy. + +Regards, +ZmnSCPxj + |