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
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
|
Return-Path: <hugo@nunchuk.io>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B415EC013A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Feb 2021 16:45:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 9B9B285535
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Feb 2021 16:45:28 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id j3-Y-pjIl-ES
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Feb 2021 16:45:26 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com
[209.85.222.49])
by fraxinus.osuosl.org (Postfix) with ESMTPS id E546885487
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Feb 2021 16:45:25 +0000 (UTC)
Received: by mail-ua1-f49.google.com with SMTP id n11so1107522uap.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 15 Feb 2021 08:45:25 -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
:cc; bh=1A6EfYvVfHvwF6Ke6IC5s3s3B//GfJvzRWrfXUdzPqg=;
b=u5alGql+AGgRuHomVIVfntxnP+D15HsWC2B5qDan6GssiQLw8aUPqSoTWG6CSWOCbQ
KJlk6X1CENrkNEJIMgBlmrdYlVek4PnQF2TF57qWj0uZwToUfk1RKqE6NDqk9ffiP9lT
NPS1e+r7nsyro5PqxLj4t3NrYsATH2MVVYTSS9HeUipccslwOTS9SkhaxgbE8+9S02DP
CR/MyYT+HpiozmeeaLMF11QJIGg3bt5HwwJ8njCQTMME2kPNv4/SLz7oUOvP+2XgM/wi
kHj1KX+Cq/ZVfxqGfMVr/g/E7nTM3T2/50vNOGnDxu1xLpf6fZcKNS+uxZ6GWueXeNl1
EorA==
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:cc;
bh=1A6EfYvVfHvwF6Ke6IC5s3s3B//GfJvzRWrfXUdzPqg=;
b=sNc0IlwhzimDcmpJY/o2gPOL8iYc3ewQq7UmoP+2NLaGKgCgChAxAzVFCpFgVzNEY1
GfReTDvPAnteTu89yJ8CEBGFdRCAEcgrvkMJTuDc2pG/BXfrfHkbmTdm7VmWpc5yj2eo
6GQ+OFu1ivT9An/lZejjMu+dHm+emg/y1mU/ScyO6VBPsPIUgsRl9RGOFkSDf7DFMb2e
/2J177twdQWgM5WP2dBaQGQReHidcCoY+lHOeQtiC47foDKLJmRUQk4dcY1NpO7ISr05
BwcgO/YdhrbNtG/ihbcDux9cgPXfA62bA0Mxwx1T+qIc99ES9xNabdrNZ34W3MJt1F3R
/txA==
X-Gm-Message-State: AOAM533do8/TdARrQuHsy5FpAePnU6S4i05ygR5SQa/M2KPoOtoETEfc
k5JfJEzUmf0e27yNOStFQ+cVT4o7OS4k9x/PAOPV/w==
X-Google-Smtp-Source: ABdhPJxmwdQoO31y64PxP4Tr/obzc04b/lTy3f9Cj9ZlY/a+fj+/QSVTRFsaiIIDhxaSoHpBXSieD878K+wamSAKoTk=
X-Received: by 2002:ab0:274f:: with SMTP id c15mr9453153uap.12.1613407522353;
Mon, 15 Feb 2021 08:45:22 -0800 (PST)
MIME-Version: 1.0
References: <CAPKmR9uyY70MhmVCh=C9DeyF2Tyxibux1E_bLPo00aW_h+OjLw@mail.gmail.com>
<CAPKmR9urumKTTdBFtu-xY+RdSptOGomnJGK+sbEVnmDH=ZkBKw@mail.gmail.com>
<CAPR5oBPtap5Q7DUbNsjy9JxLOp82nEOnj5WA=amas1OqVot-Ew@mail.gmail.com>
<CAPKmR9uhuC5L9RUK3MsMrzgNezTgmHsZ6MWwaud1bcxRje0=ww@mail.gmail.com>
In-Reply-To: <CAPKmR9uhuC5L9RUK3MsMrzgNezTgmHsZ6MWwaud1bcxRje0=ww@mail.gmail.com>
From: Hugo Nguyen <hugo@nunchuk.io>
Date: Mon, 15 Feb 2021 08:45:10 -0800
Message-ID: <CAPKmR9t1rswnzthbMa-Ja329ZPW1f7wK2exk_worwEGXOguoLA@mail.gmail.com>
To: Craig Raw <craigraw@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000003f820105bb62b6f5"
X-Mailman-Approved-At: Mon, 15 Feb 2021 16:53:57 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 16:45:28 -0000
--0000000000003f820105bb62b6f5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I would also like to add 2 notes for those who are concerned about the
potential complexity that comes with encryption - which is understandable:
1. As mentioned elsewhere in the thread, I've made the encryption aspect
entirely optional. In scenarios where encryption is an overkill -- such as
when you're setting things up under an environment you control 100% -- you
can turn encryption off, and things are unchanged from the way they are
now. The "session" would be unencrypted and XPUBs and descriptor records
are simply shared in plaintext.
2. Multisig setup is a one-time operation! After the multisig wallet has
been set up and registered with the Signers, you don't have to worry about
sharing XPUBs ever again (not even in PSBTs which is an additional benefit
of the stateful registration approach). I believe this one-time cost is
worth it if the amount of funds you are securing are significant, e.g., few
millions of dollars or even billions of dollars. But it's important that we
have this extra level of security if necessary IMHO.
Best,
Hugo
On Mon, Feb 15, 2021 at 6:19 AM Hugo Nguyen <hugo@nunchuk.io> wrote:
> Hi Craig,
> Thanks for the feedback! Sharing my comments inline.
>
> On Mon, Feb 15, 2021 at 5:53 AM Craig Raw <craigraw@gmail.com> wrote:
>
>> Hi all,
>>
>> Hugo and I have discussed off-list, and I have two concerns with this
>> proposal:
>>
>> 1. I believe adding the TOKEN and encryption to the exchange adds
>> complexity to already notoriously complex multisig, without adding much =
in
>> the way of security.
>>
>
> I disagree that this doesn't add security. This proposal was inspired by =
a
> real vulnerability we discovered in the wild while experimenting with HWW=
s,
> and during that process I noticed that there is little in the way of a an
> attacker to pull off a MITM attack, where he/she can intercept and tamper
> with the multisig configuration file, potentially swapping in their own
> XPUBs. This is especially important for remote multisig setups - which is
> not common now but I imagine will be a lot more common in the future.
>
> This is because the shared secret (TOKEN) must still be shared securely,
>> and if you have established an (off-protocol) secure channel to do this,
>> why not just share the actual multisig configuration data directly in th=
at
>> channel?
>
>
> Because multisig is inherently an interactive process. If we can create
> the multisig configuration in one shot for everybody, you're correct that
> this is not necessary! But the fact that multisig is by nature interactiv=
e
> and requires a few rounds of communication (since it needs each Signer to
> voluntarily share its XPUB before a wallet can be created) makes this
> necessary IMO.
>
> If you are able to do so, you retain the advantage of being able to
>> inspect the data directly.
>
>
> Note that some manual inspection is still part of the proposal. But
> instead of exclusively relying on manual inspection (which is error-prone=
,
> and also doesn't scale very well for a large number of signers), we
> strengthen this process by automating some of the checks and making it
> harder to tamper with.
>
>
>>
>> 2. Asking the user to enter the derivation into the Signer also adds (IM=
O
>> unnecessary) complexity to the multisig setup process. A different way o=
f
>> doing it, which is specified in the UR crypto-account format linked to
>> previously, has the Signer provide as many common derivations (along wit=
h
>> their xpubs) as it can support for a given BIP44 account number. This ha=
s
>> the dual advantage of making things simpler for the user (they only have=
to
>> provide an optional account number) and increasing the standardisation o=
n
>> common derivation paths. On receiving these derivation/xpub pairs, the
>> Coordinator can simply pick the appropriate one.
>>
>
> Note that in the updated proposal, I added the option of the Signer
> automatically filling in the derivation paths on behalf of the user (and
> also should take care not to reuse XPUBs). Perhaps this can be made the
> default behavior.
>
> Best,
> Hugo
>
>
>>
>> These concerns noted, I agree it's a good idea to have Signers save the
>> multisig configuration as proposed, and it would be great to have
>> standardisation in hww import and export formats (not just for multisig)=
.
>> On that note, I'd love to see greater adoption of the efficient UR2.0
>> standard and associated formats for airgapped data transmission using QR
>> codes.
>>
>> Craig
>>
>>
>> On Mon, Feb 15, 2021 at 11:13 AM Hugo Nguyen via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> 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 BI=
P
>>> 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 acro=
ss
>>> 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 an=
d
>>> not tampered with.
>>> # Whether Signer persists the multisig configuration in their respectiv=
e
>>> 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 addr=
ess.
>>>
>>> This proposal seeks to address concerns #1 and #2: to mitigate the risk
>>> of tampering during the initial setup phase, and to define an interoper=
able
>>> 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 determine=
s
>>> what type of multisig is used and the exact policy script. If encryptio=
n is
>>> enabled, the Coordinator also distributes a shared secret or shared sec=
rets
>>> to the parties involved for secure communication. The Coordinator gathe=
rs
>>> 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 XP=
UB
>>> is included in the descriptor record and persisting the descriptor reco=
rd
>>> 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, s=
uch
>>> 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 cas=
e,
>>> the Coordinator can decide whether to share one common <tt>TOKEN</tt> f=
or
>>> 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 multisi=
g
>>> derivation path and retrieves the XPUB at that derivation path. Optiona=
lly,
>>> the Signer can choose a path on behalf of the user. If the Signer choos=
es
>>> 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 ent=
ire
>>> 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 descri=
ptor
>>> 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#check=
sums
>>> 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>CHECK=
SUM</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</t=
t>.
>>> * 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 shou=
ld
>>> 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-20=
20-005-ur.md
>>> the BCR standard].
>>>
>>> Also refer to [
>>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-20=
20-015-account.md
>>> UR Type Definition for BIP44 Accounts] and [
>>> https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-20=
20-010-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 communicatio=
n
>>> 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 secur=
ity
>>> of all parties in the setup, but it can make it significantly harder fo=
r 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 addi=
ng 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 t=
o
>>> 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/0=
18385.html
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
--0000000000003f820105bb62b6f5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I would also like to add 2 notes for those who are concern=
ed about the potential complexity that comes with encryption - which is und=
erstandable:<br><br>1. As mentioned elsewhere in the thread, I've made =
the encryption aspect entirely optional. In scenarios where encryption is a=
n overkill -- such as when you're setting things up under an environmen=
t you control 100% -- you can turn encryption off, and things are unchanged=
from the way they are now. The "session" would be unencrypted an=
d XPUBs and descriptor records are simply shared in plaintext.<br><br>2. Mu=
ltisig setup is a one-time operation! After the multisig wallet has been se=
t up and registered with the Signers, you don't have to worry about sha=
ring XPUBs ever again (not even in PSBTs which is an additional benefit of =
the stateful registration approach). I believe this one-time cost is worth =
it if the amount of funds you are securing are significant, e.g., few milli=
ons of dollars or even billions of dollars. But it's important that we =
have this extra level of security if necessary IMHO.<br><br>Best,<br>Hugo</=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
Mon, Feb 15, 2021 at 6:19 AM Hugo Nguyen <<a href=3D"mailto:hugo@nunchu=
k.io">hugo@nunchuk.io</a>> wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex"><div dir=3D"ltr"><div>Hi Craig,<br>Thanks for the feed=
back! Sharing my comments inline.</div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Mon, Feb 15, 2021 at 5:53 AM Craig Raw =
<<a href=3D"mailto:craigraw@gmail.com" target=3D"_blank">craigraw@gmail.=
com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><div>Hi all,</div><div><br></div>Hugo and I have discus=
sed off-list, and I have two concerns with this proposal:<div><br></div><di=
v>1. I believe adding the TOKEN and encryption to the exchange adds complex=
ity to already notoriously complex multisig, without adding much in the way=
of security. </div></div></blockquote><div><br>I disagree that this doesn&=
#39;t add security. This proposal was inspired by a real vulnerability we d=
iscovered in the wild while experimenting with HWWs, and during that proces=
s I noticed that there is little in the way of a an attacker to pull off a =
MITM attack, where he/she can intercept and tamper with the multisig config=
uration file, potentially swapping in their own XPUBs. This is especially i=
mportant for remote multisig setups - which is not common now but I imagine=
will be a lot more common in the future.<br><br><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">This is because the shared secret (TOKEN) must stil=
l be shared securely, and if you have established an (off-protocol) secure =
channel to do this, why not just share the actual multisig configuration da=
ta directly in that channel? </blockquote></div><div><br>Because multisig i=
s inherently an interactive process. If we can create the multisig configur=
ation in one shot for everybody, you're correct that this is not necess=
ary! But the fact that multisig is by nature interactive and requires a few=
rounds of communication (since it needs each Signer to voluntarily share i=
ts=C2=A0XPUB before a wallet can be created) makes this necessary IMO.<br><=
/div><div><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If you are =
able to do so, you retain the advantage of being able to inspect the data d=
irectly.</blockquote><br>Note that some manual inspection is still part of =
the proposal. But instead of exclusively relying on manual inspection (whic=
h is error-prone, and also doesn't scale very well for a large number o=
f signers), we strengthen this process by automating some of the checks and=
making it harder to tamper with.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>2. As=
king the user to enter the derivation into the Signer also adds (IMO unnece=
ssary) complexity to the multisig setup process. A different way of doing i=
t, which is specified in the UR crypto-account format linked to previously,=
has the Signer provide as many common derivations (along with their xpubs)=
as it can support for a given BIP44 account number. This has the dual adva=
ntage of making things simpler for the user (they only have to provide an o=
ptional account number) and increasing the standardisation on common deriva=
tion paths. On receiving these derivation/xpub pairs, the Coordinator can s=
imply pick the appropriate one.</div></div></blockquote><div><br>Note that =
in the updated proposal, I added the option of the Signer automatically fil=
ling in the derivation paths on behalf of the user (and also should take ca=
re not to reuse XPUBs). Perhaps this can be made the default behavior.<br><=
br>Best,<br>Hugo<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><div><br></div><div>These concerns noted, I agree i=
t's a good idea to have Signers save the multisig configuration as prop=
osed, and it would be great to have standardisation in hww import and expor=
t formats (not just for multisig). On that note, I'd love to see greate=
r adoption of the efficient UR2.0 standard and associated formats for airga=
pped data transmission using QR codes.</div><div><br></div><div>Craig</div>=
<div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Mon, Feb 15, 2021 at 11:13 AM Hugo Nguyen via bitcoin-de=
v <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_b=
lank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi all,<br=
>I have updated the proposal based on further feedback. The new spec is inc=
luded at the bottom.</div><div><br></div><div>I have also created a public =
Github PR to make it easier to comment on the text of the spec itself:=C2=
=A0<a href=3D"https://github.com/nunchuk-io/bips/pull/1" target=3D"_blank">=
https://github.com/nunchuk-io/bips/pull/1</a> .<br><br>Could someone 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 update =3D=3D=3D<=
br><br>1. Define encryption modes<br><br># NO_ENCRYPTION: Encryption is dis=
abled.<br># STANDARD : the TOKEN is a 64-bit nonce.<br># EXTENDED : the TOK=
EN is a 128-bit nonce.<br><br>2. Define signature algorithm<br><br>Follow B=
IP-0322, legacy format allowed.<br><br>3. Multiple TOKENs (optional)<br><br=
>Also add an option where the Coordinator can choose to use one common TOKE=
N 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"g=
mail_quote"><div><br><br><pre><br>=C2=A0 BIP: To be determined<br>=C2=
=A0 Layer: Applications<br>=C2=A0 Title: Bitcoin Secure Multisig Setup (BSM=
S)<br>=C2=A0 Author: Hugo Nguyen <hugo at <a href=3D"http://nunchuk.io" =
target=3D"_blank">nunchuk.io</a>>, Peter Gray <peter at <a href=3D"ht=
tp://coinkite.com" target=3D"_blank">coinkite.com</a>>, Marko Bencun <=
;marko at <a href=3D"http://shiftcrypto.ch" target=3D"_blank">shiftcrypto.c=
h</a>>, Pavol Rusnak <<a href=3D"mailto:stick@satoshilabs.com" target=
=3D"_blank">stick@satoshilabs.com</a>>, Aaron Chen <aarondongchen at =
<a href=3D"http://gmail.com" target=3D"_blank">gmail.com</a>>, Rodolfo N=
ovak <rodolfo at <a href=3D"http://coinkite.com" target=3D"_blank">coink=
ite.com</a>><br>=C2=A0 Comments-Summary: No comments yet.<br>=C2=A0 Comm=
ents-URI:<br>=C2=A0 Status: Proposed<br>=C2=A0 Type: Standards Track<br>=C2=
=A0 Created: 2020-11-10<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 mechanism 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 multisi=
g experience has been greatly streamlined under [<a href=3D"https://github.=
com/bitcoin/bips/blob/master/bip-0174.mediawiki" target=3D"_blank">https://=
github.com/bitcoin/bips/blob/master/bip-0174.mediawiki</a> BIP-0174<br>(Par=
tially Signed Bitcoin Transaction)]. However, what is still missing is a st=
andardized process for setting up multisig wallets securely across differen=
t vendors.<br><br>There are a number of concerns when it comes to setting u=
p a multisig wallet:<br><br># Whether the multisig configuration, such as S=
igner membership, script type, derivation paths and number of signatures re=
quired, is correct and not tampered with.<br># Whether Signer persists the =
multisig configuration in their respective storage, and under what format.<=
br># Whether Signer's storage is tamper-proof.<br># Whether Signer subs=
equently uses the multisig configuration to generate and verify receive and=
change addresses.<br><br>An attacker who can modify the multisig configura=
tion can steal or hold funds to ransom by duping the user into sending fund=
s to the wrong address.<br><br>This proposal seeks to address concerns #1 a=
nd #2: to mitigate the risk of tampering during the initial setup phase, an=
d to define an interoperable multisig configuration format.<br><br>Concerns=
#3 and #4 should be handled by Signers and is out of scope of this proposa=
l.<br><br>=3D=3DSpecification=3D=3D<br><br>=3D=3D=3DPrerequisites=3D=3D=3D<=
br>This proposal assumes the parties in the multisig support [<a href=3D"ht=
tps://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki" target=3D"_bl=
ank">https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki</a> BIP=
-0032], [<a href=3D"https://github.com/bitcoin/bitcoin/blob/master/doc/desc=
riptors.md" target=3D"_blank">https://github.com/bitcoin/bitcoin/blob/maste=
r/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" target=3D"_=
blank">https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki</a> B=
IP-0322], legacy format accepted. Finally, the Signer encrypts the entire r=
ecord with <tt>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 s=
etup if the wallet setup session has expired.<br>* For each key record, the=
Coordinator decrypts it using <tt>ENCRYPTION_KEY</tt>. The Coo=
rdinator verifies that the included <tt>SIG</tt> is valid given=
the <tt>KEY</tt>.<br>* If all key records look good, the Coord=
inator 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 [<a href=3D"https:/=
/github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md#checksums" targe=
t=3D"_blank">https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors=
.md#checksums</a> BECH32 encoding].<br>* The Coordinator encrypts this desc=
riptor record with <tt>ENCRYPTION_KEY</tt>.<br>* The Coordinato=
r sends the encrypted descriptor record to all participating Signers.<br><b=
r>=3D=3D=3D=3D=3DSigner=3D=3D=3D=3D=3D<br><br>* The Signer imports the desc=
riptor record, decrypts it using the <tt>ENCRYPTION_KEY</tt> de=
rived from the open session.<br>* The Signer calculates and verifies the de=
scriptor=E2=80=99s <tt>CHECKSUM</tt>. Abort the setup if the &l=
t;tt>CHECKSUM</tt> is incorrect.<br>* The Signer checks whether on=
e of the <tt>KEY</tt>s in the descriptor belongs to it, using p=
ath and fingerprint information included in the descriptor. The check must =
perform an exact match on the <tt>KEY</tt>s, and not using shor=
tcuts 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>* F=
or 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.<br>*=
If all checks pass, the Signer persists the descriptor record in its stora=
ge.<br>* The Signer can choose to further restrict post-XPUB derivation pat=
hs, such as to those defined in [<a href=3D"https://github.com/bitcoin/bips=
/blob/master/bip-0044.mediawiki" target=3D"_blank">https://github.com/bitco=
in/bips/blob/master/bip-0044.mediawiki</a> BIP-0044].<br>* The Signer shoul=
d subsequently use the descriptor to generate and verify 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> : the <tt>TO=
KEN</tt> is set to <tt>0</tt>. Encryption is disabled.<br=
># <tt>STANDARD</tt> : the <tt>TOKEN</tt> is a 64-b=
it nonce.<br># <tt>EXTENDED</tt> : the <tt>TOKEN</tt&g=
t; is a 128-bit nonce.<br><br>The <tt>TOKEN</tt> can be convert=
ed to one of these formats:<br>* A mnemonic phrase using [<a href=3D"https:=
//github.com/bitcoin/bips/blob/master/bip-0039.mediawiki" target=3D"_blank"=
>https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki</a> BIP-003=
9] word list (6 words in <tt>STANDARD</tt> mode, 12 words in &l=
t;tt>EXTENDED</tt> mode)<br>* A decimal number (20 digits in <t=
t>STANDARD</tt> mode, 40 digits in <tt>EXTENDED</tt> m=
ode)<br>* A QR code<br>* Other formats<br><br>The flexibility in the data f=
ormat allows each Signer to customize the User Experience based on its resp=
ective capabilities.<br><br>=3D=3D=3D=3DKey Derivation=3D=3D=3D=3D<br>The k=
ey derivation function is [<a href=3D"https://tools.ietf.org/html/rfc2898" =
target=3D"_blank">https://tools.ietf.org/html/rfc2898</a> PBKDF2], with PRF=
=3D SHA512. Specifically:<br><br><tt>DK =3D PBKDF2(PRF, Password, Sa=
lt, c, dkLen)</tt><br><br>Whereas:<br><br>* PRF =3D <tt>SHA512&=
lt;/tt><br>* Password =3D <tt>"No SPOF"</tt><br>* =
Salt =3D <tt>TOKEN</tt><br>* c =3D <tt>2048</tt><br=
>* dkLen =3D <tt>256</tt><br>* DK =3D Derived <tt>ENCRYPT=
ION_KEY</tt><br><br>=3D=3D=3D=3DEncryption Scheme=3D=3D=3D=3D<br>The =
encryption scheme is [<a href=3D"https://tools.ietf.org/html/rfc3686" targe=
t=3D"_blank">https://tools.ietf.org/html/rfc3686</a> AES, CTR mode].<br><br=
>=3D=3DQR Codes=3D=3D<br>For signers that use QR codes to transmit data, ke=
y and descriptor records can be converted to QR codes, following [<a href=
=3D"https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-20=
20-005-ur.md" target=3D"_blank">https://github.com/BlockchainCommons/Resear=
ch/blob/master/papers/bcr-2020-005-ur.md</a> the BCR standard].<br><br>Also=
refer to [<a href=3D"https://github.com/BlockchainCommons/Research/blob/ma=
ster/papers/bcr-2020-015-account.md" target=3D"_blank">https://github.com/B=
lockchainCommons/Research/blob/master/papers/bcr-2020-015-account.md</a> UR=
Type Definition for BIP44 Accounts] and [<a href=3D"https://github.com/Blo=
ckchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md" tar=
get=3D"_blank">https://github.com/BlockchainCommons/Research/blob/master/pa=
pers/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 prop=
osal introduces two layers of protection. The first one is a temporary, sec=
ret token, used to encrypt the two rounds of communication between the Sign=
er and the Coordinator. The second one is through the descriptor checksum a=
nd visual inspection of the descriptor itself.<br><br>The token is only nee=
ded during the setup phase, and can be safely thrown away afterwards. The t=
oken does not guarantee that the Signer membership set is not modified, sin=
ce 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.<br><br>There ar=
e three ways an attacker can modify the membership set: by changing an exis=
ting member, by removing an existing member, or by adding a new member.<br>=
<br>For the first two methods, one of the Signers will be able to detect th=
at its membership has been changed or removed, and reject the final descrip=
tor. Thus, it is vital that all participating Signers check that their memb=
ership is intact in the descriptor. Even one Signer failing to check for it=
s membership means that the setup could be compromised.<br><br>For the thir=
d type of attack, the descriptor checksum and visual inspection of the desc=
riptor itself are the only way to guard against malicious members from bein=
g inserted into the set.<br><br>=3D=3DAcknowledgement=3D=3D<br><br>Special =
thanks to Dmitry Petukhov, Christopher Allen, Craig Raw and others for thei=
r feedback on the specification.<br><br>=3D=3DReferences=3D=3D<br><br>Origi=
nal mailing list thread: <a href=3D"https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2021-February/018385.html" target=3D"_blank">https://lists=
.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018385.html</a><br=
><br>=C2=A0</div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
--0000000000003f820105bb62b6f5--
|