1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
Return-Path: <crypto@timruffing.de>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2355AC0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 22 Mar 2020 09:43:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 0D1E88768D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 22 Mar 2020 09:43:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id OEdfZ1xvD-7G
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 22 Mar 2020 09:43:20 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152])
by whitealder.osuosl.org (Postfix) with ESMTPS id 29CC487657
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 22 Mar 2020 09:43:19 +0000 (UTC)
Received: from smtp2.mailbox.org (smtp2.mailbox.org [80.241.60.241])
(using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits))
(No client certificate requested)
by mout-p-102.mailbox.org (Postfix) with ESMTPS id 48lXd124hyzKmWR;
Sun, 22 Mar 2020 10:43:17 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp2.mailbox.org ([80.241.60.241])
by gerste.heinlein-support.de (gerste.heinlein-support.de [91.198.250.173])
(amavisd-new, port 10030)
with ESMTP id LP0JSAhm4SpZ; Sun, 22 Mar 2020 10:43:13 +0100 (CET)
Message-ID: <c14db3d600c0c60bbf06ea832fc438a5c9fd97da.camel@timruffing.de>
From: Tim Ruffing <crypto@timruffing.de>
To: Marko Bencun <mbencun@gmail.com>, Russell O'Connor
<roconnor@blockstream.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 22 Mar 2020 10:43:12 +0100
In-Reply-To: <CAMZUoKk6uFAfZkUQUbDY_Kw=3bc5LUb2ihDUT9Wqh0zrO64Erw@mail.gmail.com>
References: <VZTbLR9RlkkyNg6mOOIxedh7H0g8NGlaCmgBfCVXZ4RNfW3axefgoTqZGXjAQZFEuekujVGjRMv8SifDIodZ6tRGaaXQ_R63rFa03SGS6rg=@wuille.net>
<de7bd393327015a5b97ffff0d15a7c90d2d2196a.camel@timruffing.de>
<CAMZUoKk6uFAfZkUQUbDY_Kw=3bc5LUb2ihDUT9Wqh0zrO64Erw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 22 Mar 2020 12:22:22 +0000
Subject: Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques
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: Sun, 22 Mar 2020 09:43:22 -0000
On Sat, 2020-03-21 at 12:59 -0400, Russell O'Connor wrote:
> Public keys are deterministic and can be spot checked. In fact,
> AFAIU if hardened HD key derivations are not used, then spot checking
> is very easy.
>
> While spot checking isn't ideal, my original concern with the
> synthetic none standard proposal was that it is inherently non-
> deterministic and cannot ever be spot checked. This is why anti-
> covert signing protocols are so important if we are going to use
> synthetic nonces.
If spot checking means checking a few instances, then I think this is a
pretty weak defense. What if the device starts to behave differently
after a year?
On Sat, 2020-03-21 at 21:29 +0100, Marko Bencun wrote:
> Practically speaking, most hardware wallets allow you to import your
> own BIP39 seed, so you can work around key generation attacks today,
> with a one time inconvenience at the start. However, with the signing
> nonce attacks, a user today has no protection.
>
How do you know that the device really uses your seed? This can only be
done by comparing the public keys output by the HW with a second
computation. Even if you use only non-hardened derivation, you need to
check the master (root) public key and that means you need compute the
master root public key once from the seed. You can't do this manually
on a sheet of paper after you rolled a few dice to generate your seed.
So you need to store the seed on a second device (if only for a short
time). And I think this defeats the purpose of a HW wallet.
And even if assume that spot checking and importing the seed works, the
problem is not solved. We still need a clearly specified full protocol
that we can analyze.
Best,
Tim
|
