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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
|
Return-Path: <hugo@nunchuk.io>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 17679C013A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Feb 2021 09:11:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 03D5386847
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Feb 2021 09:11:25 +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 QoeTXeYiEAcr
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Feb 2021 09:11:22 +0000 (UTC)
X-Greylist: delayed 00:20:57 by SQLgrey-1.7.6
Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com
[209.85.216.42])
by whitealder.osuosl.org (Postfix) with ESMTPS id A2EBA867B7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Feb 2021 09:11:22 +0000 (UTC)
Received: by mail-pj1-f42.google.com with SMTP id nm1so3351549pjb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Feb 2021 01:11:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=nunchuk-io.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=VyLdnWo/PiD7GgqWMF1n1w+WSP7x9T/ce8X75PJPsPA=;
b=NWLPSlFHjY5LNqHabnVIupRooNujkWHH20i8gtNSNOaP4cY7B/Gbc51dISILlmbv8f
6q7vyL/tzD5z+lCxolS0vf4N7wa+yQpHDJYD3T70lv5VX430Lo3hTTbg9r338SfkyW7h
vX6WcYrnZh+y0/+fRQDMT4RmnEYMXM5fswq7N5L6L1LnbiuDtbsp/h43j0rMhJG8NRQU
Y+3uUj2hU2h2I7A9QwdFnv8Sc0GPOSoAE1sN+hrEYuIsUo/Tvyq0e4dmoZghmEy7RY0/
smRoqKfqbMUB87rgh2waf84IA1rwUlHblBDq7Yu5PFiBr6pxnBvnZwbKetWa8YpWKEgZ
0JGA==
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=VyLdnWo/PiD7GgqWMF1n1w+WSP7x9T/ce8X75PJPsPA=;
b=mqEUm6IClRsjlMHTLPV/dbpwqO3gF1xcIGJJuOgDhxxveooMGBY1Tcp4CguJYV2GQR
HvLj6PLKKBOEPWuytZo3ZkrqOzY6lLGdiaMydBovwk9OFC4niWiK+UzjU8dZGJklAyfb
fi31IBMBdkPA2UXXVtBu4aBzA60J1vm7+78B+8Jz+n3u8X9R0kXoxqyslc9ThwNtOLPo
aW+NuMSBG6Ray+0o52W0Uuc+ulY+98qDqYK/MXyHVMOT4ZYszmrPRbrNegVExWDCrEfa
D+EaTmUC0BqmLkXv3ThDd2nL3fjm4uO/BgW3aQNfutLHdwsnm3EGa5+HNHmFmsoxGFrB
di7w==
X-Gm-Message-State: AOAM530H6SyCSrlpXNVWJ3VzJWc2TxBLRLLRU6sV2Tr7oF8ptmA1T1CH
omrKalChx6/b5EAiOfSztu5tBlCFMNeOpF8Kr6KueOtMuKPCr6ZiLNiP7A==
X-Google-Smtp-Source: ABdhPJxg1a6ceatUGwtrqYFYbd6EJ42CNsR7/7HnkTtr+JdALw0ql0yUEFIgjOWUgQmjOisTuIJeAz3i247Sg3hU7PU=
X-Received: by 2002:a1f:b60c:: with SMTP id g12mr7583624vkf.15.1613378670873;
Mon, 15 Feb 2021 00:44:30 -0800 (PST)
MIME-Version: 1.0
References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
In-Reply-To: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
From: Hugo Nguyen <hugo@nunchuk.io>
Date: Mon, 15 Feb 2021 00:44:19 -0800
Message-ID: <CAPKmR9urumKTTdBFtu-xY+RdSptOGomnJGK+sbEVnmDH=ZkBKw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000090de7105bb5bfebe"
X-Mailman-Approved-At: Mon, 15 Feb 2021 09:13:31 +0000
Subject: Re: [bitcoin-dev] Proposal: Bitcoin Secure Multisig Setup
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, 15 Feb 2021 09:11:25 -0000
--00000000000090de7105bb5bfebe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi all,
I have updated the proposal based on further feedback. The new spec is
included at the bottom.
I have also created a public Github PR to make it easier to comment on the
text of the spec itself: https://github.com/nunchuk-io/bips/pull/1 .
Could someone please let me know what else needs to be done before a BIP
number can be assigned?
=3D=3D=3D Quick summary of changes from last update =3D=3D=3D
1. Define encryption modes
# NO_ENCRYPTION: Encryption is disabled.
# STANDARD : the TOKEN is a 64-bit nonce.
# EXTENDED : the TOKEN is a 128-bit nonce.
2. Define signature algorithm
Follow BIP-0322, legacy format allowed.
3. Multiple TOKENs (optional)
Also add an option where the Coordinator can choose to use one common TOKEN
for all Signers, or use one per Signer.
=3D=3D=3D End of summary =3D=3D=3D
Cheers,
Hugo
<pre>
BIP: To be determined
Layer: Applications
Title: Bitcoin Secure Multisig Setup (BSMS)
Author: Hugo Nguyen <hugo at nunchuk.io>, Peter Gray <peter at
coinkite.com>, Marko Bencun <marko at shiftcrypto.ch>, Pavol Rusnak <
stick@satoshilabs.com>, Aaron Chen <aarondongchen at gmail.com>, Rodolfo
Novak <rodolfo at coinkite.com>
Comments-Summary: No comments yet.
Comments-URI:
Status: Proposed
Type: Standards Track
Created: 2020-11-10
License: BSD-2-Clause
</pre>
=3D=3DIntroduction=3D=3D
=3D=3D=3DAbstract=3D=3D=3D
This document proposes a mechanism to set up multisig wallets securely.
=3D=3D=3DCopyright=3D=3D=3D
This BIP is licensed under the 2-clause BSD license.
=3D=3D=3DMotivation=3D=3D=3D
The Bitcoin multisig experience has been greatly streamlined under [
https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174
(Partially Signed Bitcoin Transaction)]. However, what is still missing is
a standardized process for setting up multisig wallets securely across
different vendors.
There are a number of concerns when it comes to setting up a multisig
wallet:
# Whether the multisig configuration, such as Signer membership, script
type, derivation paths and number of signatures required, is correct and
not tampered with.
# Whether Signer persists the multisig configuration in their respective
storage, and under what format.
# Whether Signer's storage is tamper-proof.
# Whether Signer subsequently uses the multisig configuration to generate
and verify receive and change addresses.
An attacker who can modify the multisig configuration can steal or hold
funds to ransom by duping the user into sending funds to the wrong address.
This proposal seeks to address concerns #1 and #2: to mitigate the risk of
tampering during the initial setup phase, and to define an interoperable
multisig configuration format.
Concerns #3 and #4 should be handled by Signers and is out of scope of this
proposal.
=3D=3DSpecification=3D=3D
=3D=3D=3DPrerequisites=3D=3D=3D
This proposal assumes the parties in the multisig support [
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032], [
https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the
descriptor language] and encryption.
=3D=3D=3DRoles=3D=3D=3D
=3D=3D=3D=3DCoordinator=3D=3D=3D=3D
The Coordinator initiates the multisig setup. The Coordinator determines
what type of multisig is used and the exact policy script. If encryption is
enabled, the Coordinator also distributes a shared secret or shared secrets
to the parties involved for secure communication. The Coordinator gathers
information from the Signers to generate a descriptor record. The
Coordinator distributes the descriptor record back to the Signers.
=3D=3D=3D=3DSigner=3D=3D=3D=3D
The Signer is a participating member in the multisig. Its responsibilities
include providing its key record -- which contains an Extended Public Key
(XPUB) -- to the Coordinator, verifying that its XPUB is included in the
descriptor record and persisting the descriptor record in its storage.
=3D=3D=3DSetup Process=3D=3D=3D
=3D=3D=3D=3DRound 1=3D=3D=3D=3D
=3D=3D=3D=3D=3DCoordinator=3D=3D=3D=3D=3D
* The Coordinator creates a multisig wallet creation session. The
Coordinator constructs the multisig script and its policy parameters, such
as the total number of signers and the required number of signatures
(<tt>M</tt> and <tt>N</tt>).
* The session should expire after some time period determined by the
Coordinator, e.g., 24 hours.
* If encryption is enabled, the Coordinator distributes a secret
<tt>TOKEN</tt> to each Signer over a secure channel. The Signer can use the
<tt>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refer to the
Encryption section below for details on the <tt>TOKEN</tt>, the key
derivation function and the encryption scheme. Depending on the use case,
the Coordinator can decide whether to share one common <tt>TOKEN</tt> for
all Signers, or to have one per Signer.
* If encryption is disabled, <tt>TOKEN</tt> is set to <tt>0</tt>, and all
the encryption/decryption steps below can be skipped.
=3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D
* The Signer initiates a new secure multisig setup session by setting the
<tt>TOKEN</tt>. The Signer derives an <tt>ENCRYPTION_KEY</tt> from the
<tt>TOKEN</tt>. The Signer can keep the session open until a different
value for the <tt>TOKEN</tt> is set.
* The Signer generates a key record by prompting the user for a multisig
derivation path and retrieves the XPUB at that derivation path. Optionally,
the Signer can choose a path on behalf of the user. If the Signer chooses
the path, it should try to avoid reusing XPUBs for different wallets.
* The first line in the record must be the <tt>TOKEN</tt>. The second line
must be the <tt>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key origin
information, written in the descriptor-defined format, i.e.: <tt>[{master
key fingerprint}/{derivation path}]{XPUB}</tt>. The third line must be a
<tt>SIG</tt>, whereas <tt>SIG</tt> is the signature generated by using the
private key associated with the XPUB to sign the first two lines. The
signature should follow [
https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki BIP-0322],
legacy format accepted. Finally, the Signer encrypts the entire record with
<tt>ENCRYPTION_KEY</tt>.
=3D=3D=3D=3DRound 2=3D=3D=3D=3D
=3D=3D=3D=3D=3DCoordinator=3D=3D=3D=3D=3D
* The Coordinator gathers key records from all participating Signers. Abort
the setup if the wallet setup session has expired.
* For each key record, the Coordinator decrypts it using
<tt>ENCRYPTION_KEY</tt>. The Coordinator verifies that the included
<tt>SIG</tt> is valid given the <tt>KEY</tt>.
* If all key records look good, the Coordinator fills in all necessary
information to generate a descriptor record, which is simply the descriptor
string plus a <tt>CHECKSUM</tt>, all in one line. The <tt>CHECKSUM</tt> has
[https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksum=
s
BECH32 encoding].
* The Coordinator encrypts this descriptor record with
<tt>ENCRYPTION_KEY</tt>.
* The Coordinator sends the encrypted descriptor record to all
participating Signers.
=3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D
* The Signer imports the descriptor record, decrypts it using the
<tt>ENCRYPTION_KEY</tt> derived from the open session.
* The Signer calculates and verifies the descriptor=E2=80=99s <tt>CHECKSUM<=
/tt>.
Abort the setup if the <tt>CHECKSUM</tt> is incorrect.
* The Signer checks whether one of the <tt>KEY</tt>s in the descriptor
belongs to it, using path and fingerprint information included in the
descriptor. The check must perform an exact match on the <tt>KEY</tt>s, and
not using shortcuts such as matching fingerprints (which is trivial to
spoof). Abort the setup if it doesn=E2=80=99t detect its own <tt>KEY</tt>.
* For confirmation, the Signer must display to the user the
<tt>CHECKSUM</tt>, plus other configurations, such as <tt>M</tt> and
<tt>N</tt>. The total number of Signers, <tt>N</tt>, is important to
prevent a <tt>KEY</tt> insertion attack. All participating Signers should
be able to display the same confirmation.
* If all checks pass, the Signer persists the descriptor record in its
storage.
* The Signer can choose to further restrict post-XPUB derivation paths,
such as to those defined in [
https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP-0044].
* The Signer should subsequently use the descriptor to generate and verify
receive and change addresses.
This completes the setup.
=3D=3D=3DEncryption=3D=3D=3D
=3D=3D=3D=3DThe Token=3D=3D=3D=3D
We define three modes of encryption.
# <tt>NO_ENCRYPTION</tt> : the <tt>TOKEN</tt> is set to <tt>0</tt>.
Encryption is disabled.
# <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-bit nonce.
# <tt>EXTENDED</tt> : the <tt>TOKEN</tt> is a 128-bit nonce.
The <tt>TOKEN</tt> can be converted to one of these formats:
* A mnemonic phrase using [
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki BIP-0039]
word list (6 words in <tt>STANDARD</tt> mode, 12 words in <tt>EXTENDED</tt>
mode)
* A decimal number (20 digits in <tt>STANDARD</tt> mode, 40 digits in
<tt>EXTENDED</tt> mode)
* A QR code
* Other formats
The flexibility in the data format allows each Signer to customize the User
Experience based on its respective capabilities.
=3D=3D=3D=3DKey Derivation=3D=3D=3D=3D
The key derivation function is [https://tools.ietf.org/html/rfc2898
PBKDF2], with PRF =3D SHA512. Specifically:
<tt>DK =3D PBKDF2(PRF, Password, Salt, c, dkLen)</tt>
Whereas:
* PRF =3D <tt>SHA512</tt>
* Password =3D <tt>"No SPOF"</tt>
* Salt =3D <tt>TOKEN</tt>
* c =3D <tt>2048</tt>
* dkLen =3D <tt>256</tt>
* DK =3D Derived <tt>ENCRYPTION_KEY</tt>
=3D=3D=3D=3DEncryption Scheme=3D=3D=3D=3D
The encryption scheme is [https://tools.ietf.org/html/rfc3686 AES, CTR
mode].
=3D=3DQR Codes=3D=3D
For signers that use QR codes to transmit data, key and descriptor records
can be converted to QR codes, following [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-0=
05-ur.md
the BCR standard].
Also refer to [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-0=
15-account.md
UR Type Definition for BIP44 Accounts] and [
https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-0=
10-output-desc.md
UR Type Definition for Bitcoin Output Descriptors] for more details.
=3D=3DSecurity=3D=3D
This proposal introduces two layers of protection. The first one is a
temporary, secret token, used to encrypt the two rounds of communication
between the Signer and the Coordinator. The second one is through the
descriptor checksum and visual inspection of the descriptor itself.
The token is only needed during the setup phase, and can be safely thrown
away afterwards. The token does not guarantee that the Signer membership
set is not modified, since that depends on the overall security of all
parties in the setup, but it can make it significantly harder for an
attacker to do so.
There are three ways an attacker can modify the membership set: by changing
an existing member, by removing an existing member, or by adding a new
member.
For the first two methods, one of the Signers will be able to detect that
its membership has been changed or removed, and reject the final
descriptor. Thus, it is vital that all participating Signers check that
their membership is intact in the descriptor. Even one Signer failing to
check for its membership means that the setup could be compromised.
For the third type of attack, the descriptor checksum and visual inspection
of the descriptor itself are the only way to guard against malicious
members from being inserted into the set.
=3D=3DAcknowledgement=3D=3D
Special thanks to Dmitry Petukhov, Christopher Allen, Craig Raw and others
for their feedback on the specification.
=3D=3DReferences=3D=3D
Original mailing list thread:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/01838=
5.html
--00000000000090de7105bb5bfebe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi all,<br>I have updated the proposal based on furth=
er feedback. The new spec is included at the bottom.</div><div><br></div><d=
iv>I have also created a public Github PR to make it easier to comment on t=
he text of the spec itself:=C2=A0<a href=3D"https://github.com/nunchuk-io/b=
ips/pull/1">https://github.com/nunchuk-io/bips/pull/1</a> .<br><br>Could so=
meone please let me know what else needs to be done before a BIP number can=
be assigned?<br><br><br>=3D=3D=3D Quick summary of changes from last updat=
e =3D=3D=3D<br><br>1. Define encryption modes<br><br># NO_ENCRYPTION: Encry=
ption is disabled.<br># STANDARD : the TOKEN is a 64-bit nonce.<br># EXTEND=
ED : the TOKEN is a 128-bit nonce.<br><br>2. Define signature algorithm<br>=
<br>Follow BIP-0322, legacy format allowed.<br><br>3. Multiple TOKENs (opti=
onal)<br><br>Also add an option where the Coordinator can choose to use one=
common TOKEN for all Signers, or use one per Signer.<br><br>=3D=3D=3D End =
of summary =3D=3D=3D</div><div><br></div><div><br>Cheers,<br>Hugo</div><div=
class=3D"gmail_quote"><div><br><br><pre><br>=C2=A0 BIP: To be determ=
ined<br>=C2=A0 Layer: Applications<br>=C2=A0 Title: Bitcoin Secure Multisig=
Setup (BSMS)<br>=C2=A0 Author: Hugo Nguyen <hugo at <a href=3D"http://n=
unchuk.io">nunchuk.io</a>>, Peter Gray <peter at <a href=3D"http://co=
inkite.com">coinkite.com</a>>, Marko Bencun <marko at <a href=3D"http=
://shiftcrypto.ch">shiftcrypto.ch</a>>, Pavol Rusnak <<a href=3D"mail=
to:stick@satoshilabs.com">stick@satoshilabs.com</a>>, Aaron Chen <aar=
ondongchen at <a href=3D"http://gmail.com">gmail.com</a>>, Rodolfo Novak=
<rodolfo at <a href=3D"http://coinkite.com">coinkite.com</a>><br>=C2=
=A0 Comments-Summary: No comments yet.<br>=C2=A0 Comments-URI:<br>=C2=A0 St=
atus: Proposed<br>=C2=A0 Type: Standards Track<br>=C2=A0 Created: 2020-11-1=
0<br>=C2=A0 License: BSD-2-Clause<br></pre><br><br>=3D=3DIntroduction=
=3D=3D<br><br>=3D=3D=3DAbstract=3D=3D=3D<br><br>This document proposes a me=
chanism to set up multisig wallets securely.<br><br>=3D=3D=3DCopyright=3D=
=3D=3D<br><br>This BIP is licensed under the 2-clause BSD license.<br><br>=
=3D=3D=3DMotivation=3D=3D=3D<br><br>The Bitcoin multisig experience has bee=
n greatly streamlined under [<a href=3D"https://github.com/bitcoin/bips/blo=
b/master/bip-0174.mediawiki">https://github.com/bitcoin/bips/blob/master/bi=
p-0174.mediawiki</a> BIP-0174<br>(Partially Signed Bitcoin Transaction)]. H=
owever, what is still missing is a standardized process for setting up mult=
isig wallets securely across different vendors.<br><br>There are a number o=
f concerns when it comes to setting up a multisig wallet:<br><br># Whether =
the multisig configuration, such as Signer membership, script type, derivat=
ion paths and number of signatures required, is correct and not tampered wi=
th.<br># Whether Signer persists the multisig configuration in their respec=
tive storage, and under what format.<br># Whether Signer's storage is t=
amper-proof.<br># Whether Signer subsequently uses the multisig configurati=
on to generate and verify receive and change addresses.<br><br>An attacker =
who can modify the multisig configuration can steal or hold funds to ransom=
by duping the user into sending funds to the wrong address.<br><br>This pr=
oposal seeks to address concerns #1 and #2: to mitigate the risk of tamperi=
ng during the initial setup phase, and to define an interoperable multisig =
configuration format.<br><br>Concerns #3 and #4 should be handled by Signer=
s and is out of scope of this proposal.<br><br>=3D=3DSpecification=3D=3D<br=
><br>=3D=3D=3DPrerequisites=3D=3D=3D<br>This proposal assumes the parties i=
n the multisig support [<a href=3D"https://github.com/bitcoin/bips/blob/mas=
ter/bip-0032.mediawiki">https://github.com/bitcoin/bips/blob/master/bip-003=
2.mediawiki</a> BIP-0032], [<a href=3D"https://github.com/bitcoin/bitcoin/b=
lob/master/doc/descriptors.md">https://github.com/bitcoin/bitcoin/blob/mast=
er/doc/descriptors.md</a> the descriptor language] and encryption.<br><br>=
=3D=3D=3DRoles=3D=3D=3D<br>=3D=3D=3D=3DCoordinator=3D=3D=3D=3D<br><br>The C=
oordinator initiates the multisig setup. The Coordinator determines what ty=
pe of multisig is used and the exact policy script. If encryption is enable=
d, the Coordinator also distributes a shared secret or shared secrets to th=
e parties involved for secure communication. The Coordinator gathers inform=
ation from the Signers to generate a descriptor record. The Coordinator dis=
tributes the descriptor record back to the Signers.<br><br>=3D=3D=3D=3DSign=
er=3D=3D=3D=3D<br><br>The Signer is a participating member in the multisig.=
Its responsibilities include providing its key record -- which contains an=
Extended Public Key (XPUB) -- to the Coordinator, verifying that its XPUB =
is included in the descriptor record and persisting the descriptor record i=
n its storage.<br><br>=3D=3D=3DSetup Process=3D=3D=3D<br><br>=3D=3D=3D=3DRo=
und 1=3D=3D=3D=3D<br><br>=3D=3D=3D=3D=3DCoordinator=3D=3D=3D=3D=3D<br><br>*=
The Coordinator creates a multisig wallet creation session. The Coordinato=
r constructs the multisig script and its policy parameters, such as the tot=
al number of signers and the required number of signatures (<tt>M<=
/tt> and <tt>N</tt>).<br>* The session should expire after s=
ome time period determined by the Coordinator, e.g., 24 hours.<br>* If encr=
yption is enabled, the Coordinator distributes a secret <tt>TOKEN<=
/tt> to each Signer over a secure channel. The Signer can use the <tt=
>TOKEN</tt> to derive an <tt>ENCRYPTION_KEY</tt>. Refe=
r to the Encryption section below for details on the <tt>TOKEN</tt=
>, the key derivation function and the encryption scheme. Depending on t=
he use case, the Coordinator can decide whether to share one common <tt&=
gt;TOKEN</tt> for all Signers, or to have one per Signer.<br>* If enc=
ryption is disabled, <tt>TOKEN</tt> is set to <tt>0</t=
t>, and all the encryption/decryption steps below can be skipped.<br><br=
>=3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D<br><br>* The Signer initiates a new s=
ecure multisig setup session by setting the <tt>TOKEN</tt>. The=
Signer derives an <tt>ENCRYPTION_KEY</tt> from the <tt>T=
OKEN</tt>. The Signer can keep the session open until a different val=
ue for the <tt>TOKEN</tt> is set.<br>* The Signer generates a k=
ey record by prompting the user for a multisig derivation path and retrieve=
s the XPUB at that derivation path. Optionally, the Signer can choose a pat=
h on behalf of the user. If the Signer chooses the path, it should try to a=
void reusing XPUBs for different wallets.<br>* The first line in the record=
must be the <tt>TOKEN</tt>. The second line must be the <tt=
>KEY</tt>. The <tt>KEY</tt> is an XPUB plus its key or=
igin information, written in the descriptor-defined format, i.e.: <tt>=
;[{master key fingerprint}/{derivation path}]{XPUB}</tt>. The third l=
ine must be a <tt>SIG</tt>, whereas <tt>SIG</tt> is=
the signature generated by using the private key associated with the XPUB =
to sign the first two lines.=C2=A0 The signature should follow [<a href=3D"=
https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki">https://git=
hub.com/bitcoin/bips/blob/master/bip-0322.mediawiki</a> BIP-0322], legacy f=
ormat accepted. Finally, the Signer encrypts the entire record with <tt&=
gt;ENCRYPTION_KEY</tt>.<br><br>=3D=3D=3D=3DRound 2=3D=3D=3D=3D<br><br=
>=3D=3D=3D=3D=3DCoordinator=3D=3D=3D=3D=3D<br><br>* The Coordinator gathers=
key records from all participating Signers. Abort the setup if the wallet =
setup session has expired.<br>* For each key record, the Coordinator decryp=
ts it using <tt>ENCRYPTION_KEY</tt>. The Coordinator verifies t=
hat the included <tt>SIG</tt> is valid given the <tt>KEY&=
lt;/tt>.<br>* If all key records look good, the Coordinator fills in all=
necessary information to generate a descriptor record, which is simply the=
descriptor string plus a <tt>CHECKSUM</tt>, all in one line. T=
he <tt>CHECKSUM</tt> has [<a href=3D"https://github.com/bitcoin=
/bitcoin/blob/master/doc/descriptors.md#checksums">https://github.com/bitco=
in/bitcoin/blob/master/doc/descriptors.md#checksums</a> BECH32 encoding].<b=
r>* The Coordinator encrypts this descriptor record with <tt>ENCRYPTI=
ON_KEY</tt>.<br>* The Coordinator sends the encrypted descriptor reco=
rd to all participating Signers.<br><br>=3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=
=3D<br><br>* The Signer imports the descriptor record, decrypts it using th=
e <tt>ENCRYPTION_KEY</tt> derived from the open session.<br>* T=
he Signer calculates and verifies the descriptor=E2=80=99s <tt>CHECKS=
UM</tt>. Abort the setup if the <tt>CHECKSUM</tt> is inco=
rrect.<br>* The Signer checks whether one of the <tt>KEY</tt>s =
in the descriptor belongs to it, using path and fingerprint information inc=
luded in the descriptor. The check must perform an exact match on the <t=
t>KEY</tt>s, and not using shortcuts such as matching fingerprints=
(which is trivial to spoof). Abort the setup if it doesn=E2=80=99t detect =
its own <tt>KEY</tt>.<br>* For confirmation, the Signer must di=
splay to the user the <tt>CHECKSUM</tt>, plus other configurati=
ons, such as <tt>M</tt> and <tt>N</tt>. The total n=
umber of Signers, <tt>N</tt>, is important to prevent a <tt&=
gt;KEY</tt> insertion attack. All participating Signers should be abl=
e to display the same confirmation.<br>* If all checks pass, the Signer per=
sists the descriptor record in its storage.<br>* The Signer can choose to f=
urther restrict post-XPUB derivation paths, such as to those defined in [<a=
href=3D"https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki">ht=
tps://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki</a> BIP-0044].=
<br>* The Signer should subsequently use the descriptor to generate and ver=
ify receive and change addresses.<br><br>This completes the setup.<br><br>=
=3D=3D=3DEncryption=3D=3D=3D<br><br>=3D=3D=3D=3DThe Token=3D=3D=3D=3D<br>We=
define three modes of encryption.<br><br># <tt>NO_ENCRYPTION</tt&=
gt; : the <tt>TOKEN</tt> is set to <tt>0</tt>. Encr=
yption is disabled.<br># <tt>STANDARD</tt> : the <tt>TOKE=
N</tt> is a 64-bit nonce.<br># <tt>EXTENDED</tt> : the &l=
t;tt>TOKEN</tt> is a 128-bit nonce.<br><br>The <tt>TOKEN<=
/tt> can be converted to one of these formats:<br>* A mnemonic phrase us=
ing [<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0039.mediaw=
iki">https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki</a> BIP=
-0039] word list (6 words in <tt>STANDARD</tt> mode, 12 words i=
n <tt>EXTENDED</tt> mode)<br>* A decimal number (20 digits in &=
lt;tt>STANDARD</tt> mode, 40 digits in <tt>EXTENDED</tt&g=
t; mode)<br>* A QR code<br>* Other formats<br><br>The flexibility in the da=
ta format allows each Signer to customize the User Experience based on its =
respective capabilities.<br><br>=3D=3D=3D=3DKey Derivation=3D=3D=3D=3D<br>T=
he key derivation function is [<a href=3D"https://tools.ietf.org/html/rfc28=
98">https://tools.ietf.org/html/rfc2898</a> PBKDF2], with PRF =3D SHA512. S=
pecifically:<br><br><tt>DK =3D PBKDF2(PRF, Password, Salt, c, dkLen)&=
lt;/tt><br><br>Whereas:<br><br>* PRF =3D <tt>SHA512</tt><br>=
* Password =3D <tt>"No SPOF"</tt><br>* Salt =3D <t=
t>TOKEN</tt><br>* c =3D <tt>2048</tt><br>* dkLen =3D &=
lt;tt>256</tt><br>* DK =3D Derived <tt>ENCRYPTION_KEY</tt=
><br><br>=3D=3D=3D=3DEncryption Scheme=3D=3D=3D=3D<br>The encryption sch=
eme is [<a href=3D"https://tools.ietf.org/html/rfc3686">https://tools.ietf.=
org/html/rfc3686</a> AES, CTR mode].<br><br>=3D=3DQR Codes=3D=3D<br>For sig=
ners that use QR codes to transmit data, key and descriptor records can be =
converted to QR codes, following [<a href=3D"https://github.com/BlockchainC=
ommons/Research/blob/master/papers/bcr-2020-005-ur.md">https://github.com/B=
lockchainCommons/Research/blob/master/papers/bcr-2020-005-ur.md</a> the BCR=
standard].<br><br>Also refer to [<a href=3D"https://github.com/BlockchainC=
ommons/Research/blob/master/papers/bcr-2020-015-account.md">https://github.=
com/BlockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md</=
a> UR Type Definition for BIP44 Accounts] and [<a href=3D"https://github.co=
m/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md=
">https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020=
-010-output-desc.md</a> UR Type Definition for Bitcoin Output Descriptors] =
for more details.<br><br>=3D=3DSecurity=3D=3D<br><br>This proposal introduc=
es two layers of protection. The first one is a temporary, secret token, us=
ed to encrypt the two rounds of communication between the Signer and the Co=
ordinator. The second one is through the descriptor checksum and visual ins=
pection of the descriptor itself.<br><br>The token is only needed during th=
e setup phase, and can be safely thrown away afterwards. The token does not=
guarantee that the Signer membership set is not modified, since that depen=
ds on the overall security of all parties in the setup, but it can make it =
significantly harder for an attacker to do so.<br><br>There are three ways =
an attacker can modify the membership set: by changing an existing member, =
by removing an existing member, or by adding a new member.<br><br>For the f=
irst two methods, one of the Signers will be able to detect that its member=
ship has been changed or removed, and reject the final descriptor. Thus, it=
is vital that all participating Signers check that their membership is int=
act in the descriptor. Even one Signer failing to check for its membership =
means that the setup could be compromised.<br><br>For the third type of att=
ack, the descriptor checksum and visual inspection of the descriptor itself=
are the only way to guard against malicious members from being inserted in=
to the set.<br><br>=3D=3DAcknowledgement=3D=3D<br><br>Special thanks to Dmi=
try Petukhov, Christopher Allen, Craig Raw and others for their feedback on=
the specification.<br><br>=3D=3DReferences=3D=3D<br><br>Original mailing l=
ist thread: <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-=
dev/2021-February/018385.html">https://lists.linuxfoundation.org/pipermail/=
bitcoin-dev/2021-February/018385.html</a><br><br>=C2=A0</div></div></div>
--00000000000090de7105bb5bfebe--
|