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
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Return-Path: <dustinpaystaxes@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6D0D2C0177
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Mar 2020 14:38:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 68A9988012
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Mar 2020 14:38:59 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id rCuShHuni4Xh
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Mar 2020 14:38:58 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f52.google.com (mail-ot1-f52.google.com
[209.85.210.52])
by hemlock.osuosl.org (Postfix) with ESMTPS id C334B87FA4
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Mar 2020 14:38:58 +0000 (UTC)
Received: by mail-ot1-f52.google.com with SMTP id l23so3493805otf.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 23 Mar 2020 07:38:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=E8OaCCpEMlxl5SN0tjz4mTpmM0kwDE5EqtXrc5D322E=;
b=p/fJhcDpzqIoI+lmPqZm0mAFF+AuJsTdH/vM1EYjqPs4pl8qntNwowSyY2uoSDbBGr
miB6X1mobrEWf/4ysQsmhhHz7VrcWp18WIrnmbkj5W0x/aQzFIFJA5/HXJszCMVUm2QU
UhmYd9jRS+DQ6clO4s+6a7l64KMpmVQ0aamDwq5B4/w/2xCEbUVETHzYYuHIg4ez/8MW
NzP2iJGzQX08xX2pFLQ/y/cquqN3ceydFjNWd8CxbvwahhvOihJCnVXe3mbH8WzYet+S
9wch6fyll0ry9GTej4A25HkFzFrPrNAaE3qFQ9QCwTd7Dpjsc+ucCyIhXv3rn0yjivvb
mkKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=E8OaCCpEMlxl5SN0tjz4mTpmM0kwDE5EqtXrc5D322E=;
b=tJP0Pmsq3ogO7r0j3OlncYh/7Z0RFd+EXVgpudd0pxhYbNuRlp3ifIrt5kp30IYjOw
CoOE6bglBxNlkxIl6f1osszWR3l5BDqwvefymwVmx4sw3Vfri3FJe+l82NqfKdoeMedf
xnvYysr1nhHYN2g99rX50wbHY1Ni8IX5HrJ5HEQ2owKWTkZBjW0A5f8HY/BT9IMjEQbV
yi4dm5W2a2Az0u/AvKW39elQd7Aw3z8PJ6VxS0LHNRrVwQIbyd8c+34vmY6SUpjXHEmi
e79ipsB0SpHlElXzQbEKahMZby8LoKvYmTg2n2lzD7drnVm6mJl8r2gyZQrztOX4/ACt
7tVw==
X-Gm-Message-State: ANhLgQ36Yl3jWKUsKpDLjzdxWjSijbQZFNvSZD7iggIFpOTOs4UgCgmx
ZFGt08scPlmX8cuA8V2FAOQuhDA/amjdrnzX7xC3VoNd
X-Google-Smtp-Source: ADFU+vuV7zCbrCIq2FgjDKpmNPQcq6b9wtladb5URruSc4xqvRgd+8LVNuVZQ14sjgxCJvtGsdCyGMETJewXKf56Ysk=
X-Received: by 2002:a05:6830:1d52:: with SMTP id
p18mr18926634oth.204.1584974337468;
Mon, 23 Mar 2020 07:38:57 -0700 (PDT)
MIME-Version: 1.0
References: <VZTbLR9RlkkyNg6mOOIxedh7H0g8NGlaCmgBfCVXZ4RNfW3axefgoTqZGXjAQZFEuekujVGjRMv8SifDIodZ6tRGaaXQ_R63rFa03SGS6rg=@wuille.net>
In-Reply-To: <VZTbLR9RlkkyNg6mOOIxedh7H0g8NGlaCmgBfCVXZ4RNfW3axefgoTqZGXjAQZFEuekujVGjRMv8SifDIodZ6tRGaaXQ_R63rFa03SGS6rg=@wuille.net>
From: Dustin Dettmer <dustinpaystaxes@gmail.com>
Date: Mon, 23 Mar 2020 07:38:45 -0700
Message-ID: <CABLeJxQsse99aw35DxSDOyVTruFCgi0hmZntvgbYtPLSRGQ+xA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Pieter Wuille <bitcoin-dev@wuille.net>
Content-Type: multipart/alternative; boundary="0000000000005cf09105a1869817"
X-Mailman-Approved-At: Mon, 23 Mar 2020 15:06:18 +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: Mon, 23 Mar 2020 14:38:59 -0000
--0000000000005cf09105a1869817
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Excellent write up, thanks for putting it together.
On Tue, Mar 3, 2020 at 1:47 PM Pieter Wuille wrote:
> When both the HW and the SW are compromised, clearly no security is
> possible,
> as all entities are controlled by the same party in that case.
>
While all SW being compromised can=E2=80=99t be stopped, splitting the SW o=
ver two
stages can dramatically increase your security if both HW & SW are
compromised. You can do that by:
1) When you setup your storage solution (whatever it may be), export the
xpub(s) and verify the receiving addresses match xpubs with external
software before receiving.
2) Generate and export withdrawal transactions offline
3) Verify transactions against the same xpub(s) using external software
4) Upload transactions
This mitigates, I believe, all leak vectors besides k/R hacking and
prechosen entropy.
I made an external tool to just that here:
https://github.com/koinkeep/gatekeeper
Would love to add k commitments when (if?) we settle on best practices for
it.
--0000000000005cf09105a1869817
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div><div dir=3D"auto">Excellent write up, thanks for putting it together.<=
/div></div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Tue, Mar 3, 2020 at 1:47 PM Pieter Wuille wrote:</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">When both the HW and the SW are compromised, clearly=
no security is possible,<br>
as all entities are controlled by the same party in that case.<br>
</blockquote></div></div><div dir=3D"auto">While all SW being compromised c=
an=E2=80=99t be stopped, splitting the SW over two stages can dramatically =
increase your security if both HW & SW are compromised. You can do that=
by:</div><div dir=3D"auto"><br></div><div dir=3D"auto">1) When you setup y=
our storage solution (whatever it may be), export the xpub(s) and verify th=
e receiving addresses match xpubs with external software before receiving.<=
/div><div dir=3D"auto">2) Generate and export withdrawal transactions offli=
ne</div><div dir=3D"auto">3) Verify transactions against the same xpub(s) u=
sing external software</div><div dir=3D"auto">4) Upload transactions</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">This mitigates, I believe, all=
leak vectors besides k/R hacking and prechosen entropy.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">I made an external tool to just that here:=
=C2=A0<div><a href=3D"https://github.com/koinkeep/gatekeeper">https://githu=
b.com/koinkeep/gatekeeper</a></div></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">Would love to add k commitments when (if?) we settle on best pr=
actices for it.</div>
--0000000000005cf09105a1869817--
|
