forked from CSAGCR/CCSS
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathDetails.html
912 lines (595 loc) · 50.1 KB
/
Details.html
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
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Details</title>
<meta name="description" content="The CryptoCurrency Certification Consortium (C4) establishes cryptocurrency standards that help ensure a balance of openness & privacy, security & usability, and trust & decentralization.
">
<link rel="stylesheet" href="/CCSS/css/main.css">
<link rel="canonical" href="https://cryptoconsortium.github.io/CCSS/Details/">
<link rel="alternate" type="application/rss+xml" title="CCSS" href="https://cryptoconsortium.github.io/CCSS/feed.xml" />
</head>
<body>
<header class="site-header">
<div class="wrapper">
<img src='/CCSS/images/CCSS_Logo_Color_Dark.png' class='logo' />
<nav class="site-nav">
<a href="#" class="menu-icon">
<svg viewBox="0 0 18 15">
<path fill="#424242" d="M18,1.484c0,0.82-0.665,1.484-1.484,1.484H1.484C0.665,2.969,0,2.304,0,1.484l0,0C0,0.665,0.665,0,1.484,0 h15.031C17.335,0,18,0.665,18,1.484L18,1.484z"/>
<path fill="#424242" d="M18,7.516C18,8.335,17.335,9,16.516,9H1.484C0.665,9,0,8.335,0,7.516l0,0c0-0.82,0.665-1.484,1.484-1.484 h15.031C17.335,6.031,18,6.696,18,7.516L18,7.516z"/>
<path fill="#424242" d="M18,13.516C18,14.335,17.335,15,16.516,15H1.484C0.665,15,0,14.335,0,13.516l0,0 c0-0.82,0.665-1.484,1.484-1.484h15.031C17.335,12.031,18,12.696,18,13.516L18,13.516z"/>
</svg>
</a>
<div class="trigger">
<a class="page-link" href="/CCSS/">CCSS安全标准</a>
<a class="page-link" href="/CCSS/Details.html">技术细节</a>
<a class="page-link" href="/CCSS/Matrix.html">评估矩阵</a>
<a class="page-link" href="/CCSS/Checklist.html">核验清单</a>
<a class="page-link" href="/CCSS/License.html">许可协议</a>
<a class="page-link" href="/CCSS/ChangeLog.html">更新日志</a>
<a class="page-link" href="/CCSS/Definitions.html">术语定义</a>
<a class="page-link" href="/CCSS/Caveats.html">注意事项</a>
</div>
</nav>
</div>
</header>
<div class="page-content">
<div class="wrapper">
<div class="home">
<ul class="aspect-list" name="top">
<li>密码资产管理</li>
<li><a href='#1.01'>1.01 密钥/种子生成</a></li>
<li><a href='#1.02'>1.02 钱包创建</a></li>
<li><a href='#1.03'>1.03 密钥存储</a></li>
<li><a href='#1.04'>1.04 密钥使用</a></li>
<li><a href='#1.05'>1.05 密钥妥协协议(Key Compromise Protocol, KCP)</a></li>
<li><a href='#1.06'>1.06 密钥持有人授权/撤销策略和程序</a></li>
<li>运营</li>
<li><a href='#2.01'>2.01 安全审计/渗透测试</a></li>
<li><a href='#2.02'>2.02 数据清理策略(Data Sanitization Policy, DSP)</a></li>
<li><a href='#2.03'>2.03 储备金证明(Proof of Reserve, PoR)</a></li>
<li><a href='#2.04'>2.04 审计日志</a></li>
</ul>
<ul class="post-list">
<li> <a name="1.01"></a>
<h1> 1.01 密钥/种子生成
<div class="contribution-links">
<a href="https://github.com/CryptoConsortium/CCSS/edit/master/_data/aspects/101-KeySeedGeneration.yml">Edit</a>
| <a href="https://github.com/CryptoConsortium/CCSS/commits/master/_data/aspects/101-KeySeedGeneration.yml">History</a>
| <a href="https://github.com/CryptoConsortium/CCSS/issues/new?body=Source%20File%3A%20101-KeySeedGeneration%0A%0A">Discuss</a>
| <a href="#top">Top</a>
</div>
</h1>
<p>该方面涵盖了将在加密货币系统内使用的<a href="../Definitions#key">加密密钥</a> 和<a href="../Definitions#seed">种子</a>的生成。加密密钥和种子的安全创建需要确保两件事的安全性：机密性和不可猜测的数字。需要保密以确保计划外的第三方不会读取/复制新创建的密钥或种子。需要不可猜测的数字，以确保计划外的第三方无法猜测或确定新创建的密钥。下面列出的每个目标都保证了密钥和/或种子是以机密且不可猜测的方式创建的。 </p>
<p>
<h3> 该方面的组件包括 </h3>
<ul class="component-list">
<li>1.1.1 操作员创建的密钥/种子</li>
<li>1.1.2 经验证的创建方法</li>
<li>1.1.3 遵守DRBG </li>
<li>1.1.4 熵(Entropy)池</li>
</ul>
</p>
<p>
<ul class="post-list">
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_1_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p><a href="../Definitions#key">加密密钥</a>和<a href="../Definitions#seed">种子</a>是由将使用它的参与者创建。这是为了保护密钥的机密性。任何需要参与者在生成密钥或种子后将密钥或种子传送给另一个参与者的系统，除非是自动签名代理的初始配置，否则都无法达到I级。 </p>
</li>
<li><p>如果自动代理将使用加密密钥/种子，则建议该系统的管理员在适当的离线系统上以足够的<a href="../Definitions#entropy">熵</a>生成密钥/种子，并将此密钥/种子<a href="../Definitions#strong-encryption">安全传送</a> 到目标设备上 ，然后使用符合CCSS的数据清理技术安全删除，以保护密钥/种子的机密性。</p>
</li>
<li><p>值得注意的是，出于备份目的而传输加密机密不会违反“同一参与者”的要求，但是，这些机密必须以<a href="../Definitions#strong-encryption">强加密</a>的格式进行传输和存储。</p>
</li>
<li><p><a href="../Definitions#key">加密密钥</a>和<a href="../Definitions#seed">种子</a>是在具有足够熵的系统上创建的，确保创建密钥时不会偏向于值范围缩小或其他确定性属性</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_2_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p><a href="../Definitions#key">密钥</a>或<a href="../Definitions#">种子</a>的生成方法在使用前经过验证。用于生成种子的软件在生成的种子符合确定值以及将所存储的种子存储或传输给另一个参与者的功能方面应没有任何限制，除非这些功能增强了软件的有效安全性 (如 <a href="../Definitions#drbg">DRBGs</a>).</p>
</li>
<li><p>在对软件进行审计之后，应生成并发布数字签名。签名应在每次执行之前验证，以确保自通过安全审计以来该软件没有更改。</p>
</li>
<li><p>如果密钥或种子是在不使用软件的情况下创建的（如骰子、纸牌或其他非数字<a href="../Definitions#entropy">熵</a>源），则应验证创建方法，确保不存在确定性（即骰子没有重量不一致、纸牌中的每张牌都是唯一的，依此类推）。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_3_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p><a href="../Definitions#key">密钥</a>或<a href="../Definitions#">种子</a>是使用符合<a href="http://http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf">NIST SP 800-90A</a>的<a href="../Definitions#drbg">确定性随机位生成器（Deterministic Random Bit Generator, DRBG）</a>生成的，并使用了至少两个单独的加密安全<a href="../Definitions#entropy">熵</a>（以加密的安全方式组合，如SHA256[UnguessableFactor1 + UnguessableFactor2]）。NIST SP 800-90A是一个标准，用于确保确定性生成的数字相对于确定性种子遵循随机分布。因此，确定这些随机数的能力会降低发现DRBG种子的能力。</p>
</li>
<li><p>NIST SP 800-90A的Dual_EC DRBG已被证明存在<a href="https://en.wikipedia.org/wiki/Dual_EC_DRBG">漏洞</a>，不应使用。</p>
</li>
<li><p>另外的选项是使用通过了针对随机性的行业标准统计测试的非确定性随机位生成器（NRBG）或“真实随机数生成器”（TRNG）生成密钥或种子，以代替具有上述两个种子的组合的符合NIST SP 800-90A的DRBG。这些行业标准有<a href="http://www.stat.fsu.edu/pub/diehard/">DIEHARD</a>、Crypt-X,或<a href="http://csrc.nist.gov/groups/ST/toolkit/rng/documentation_software.html">NIST STS</a>.</p>
</li>
</ul>
</li>
</ul>
</p>
</li>
<li> <a name="1.02"></a>
<h1> 1.02 钱包创建
<div class="contribution-links">
<a href="https://github.com/CryptoConsortium/CCSS/edit/master/_data/aspects/102-WalletCreation.yml">Edit</a>
| <a href="https://github.com/CryptoConsortium/CCSS/commits/master/_data/aspects/102-WalletCreation.yml">History</a>
| <a href="https://github.com/CryptoConsortium/CCSS/issues/new?body=Source%20File%3A%20102-WalletCreation%0A%0A">Discuss</a>
| <a href="#top">Top</a>
</div>
</h1>
<p>本方面涉及创建可以接收加密货币的<a href="../Definitions#wallet">钱包</a>或<a href="../Definitions#address">地址</a>。 钱包使用密钥签名方法创建，该方法可能需要单个密钥签名、多个密钥的签名或许多密钥中最少数量的签名。此外既可以单独创建钱包，通常称为JBOK钱包（Just a Bunch Of Keys），也可以使用确定的方式创建，该方式允许从单个主种子创建一组地址/密钥对。钱包创建的安全性源自面对的各种风险（例如丢失、被盗/损坏的密钥）的钱包完整性以及钱包的机密性，这将使钱包与特定的<a href = “ ../ Definitions＃actor”>参与者关联。</p>
<p>
<h3>此方面组件包括</h3>
<ul class="component-list">
<li>1.2.1 每笔交易的唯一地址</li>
<li>1.2.2 多个用于签名的密钥</li>
<li>1.2.3 用于恢复的冗余密钥</li>
<li>1.2.4 确定性钱包</li>
<li>1.2.5 密钥的地理分布</li>
<li>1.2.6 密钥的组织分布</li>
</ul>
</p>
<p>
<ul class="post-list">
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_1_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>对每笔交易强制使用新<a href="../Definitions#address">地址</a>的系统会隐式缓解通过受损的<a href="../Definitions#wallet">钱包</a>继续从参与者那里获得资金，而参与者没有得到受损的通知的情况，如2015年初BitStamp入侵后的几天里并没有被告知有关入侵的消息。由于先前生成的地址仍然有效，因此无法防止用户（意外或其他方式）向旧地址发送交易。建议在攻陷事件发生时，使用自动钱包清扫系统将发生给受损地址的资金转移到新的安全钱包中。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_2_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>由<a href="../Definitions#wallet">钱包</a>生成的任何<a href="../Definitions#address">地址</a>必须至少需要2个签名才能使用资金，其中每一<a href="../Definitions#actor">参与者</a>持有每个签名的<a href="../Definitions#key">密钥</a>。 在钱包上需要2个或更多签名，可以降低与受损的密钥或密钥持有者相关的盗窃风险，从而提高资金的完整性。 这通常称为<a href="../Definitions#multisig">多重签名（multi-sig）</a>钱包。 参与者可以是人或系统（即两个人，两个系统或一个人和一个系统），但必须是单独的实体，每个实体都管理自己的钱包密钥。</p>
</li>
<li><p>出于恢复目的，将冗余的<a href="../Definitions#key">密钥</a>分配给每个<a href="../Definitions#wallet">钱包</a>。 这样可以确保在由于任何原因无法访问主密码的情况下仍然可以使用资金。实现此目标的一种常见方法是创建一个钱包，该钱包需要3种可能的签名中的任意2种才能使用资金（即，有1个冗余密钥）</p>
</li>
<li><p>根据保密的<a href="../Definitions#seed">种子</a>确定地为<a href="../Definitions#hd-wallet">钱包</a>分配<a href="../Definitions#addresses"></a>地址</a>。使用JBOK钱包需要对每个新生成的<a href="../Definitions#key">密钥</a>定期备份，这会增加系统的复杂性。 这增加了人为错误的风险，如果备份不包含某些密钥，则可能导致业务中断或资金意外损失。 确定性分配的钱包消除了这种风险，并改善了系统的完整性。</p>
</li>
<li><p>任何在单个<a href="../Definitions#wallet">钱包</a>上具有签名权限的<a href="../Definitions#key">密钥</a>必须存储在不同的位置 。 通过将钱包的密钥分布在多个位置，与局部业务中断（火灾、洪水、地震、闯入）相关的风险不会影响组织使用资金的能力。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_3_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p><a href="../Definitions#wallet">钱包</a>必须为每笔交易生成唯一的<a href="../Definitions#address">地址</a>。 通过使确定哪个地址属于哪个<a href="../Definitions#actor"> 参与者 </a>更加困难提高了隐私性。 实现此要求的最常见方法之一是使用<a href="../Definitions#hd-wallet">确定性钱包</a>生成所有地址。</p>
</li>
<li><p>任何在单个<a href="../Definitions#wallet">钱包</a>上具有签名权限的<a href="../Definitions#key">密钥</a>必须由多个组织实体存储。通过将密钥提供给单独的法人实体，如律师、会计师或其他公司，可能损害业务的法律风险并不一定会损害您的资金。请注意，这不会违反“密钥/种子生成”级别1的要求，因为单独的组织无法满足对<a href="../Definitions#actor"> 参与者</a>的定义。</p>
</li>
</ul>
</li>
</ul>
</p>
</li>
<li> <a name="1.03"></a>
<h1> 1.03 密钥存储
<div class="contribution-links">
<a href="https://github.com/CryptoConsortium/CCSS/edit/master/_data/aspects/103-KeyStorage.yml">Edit</a>
| <a href="https://github.com/CryptoConsortium/CCSS/commits/master/_data/aspects/103-KeyStorage.yml">History</a>
| <a href="https://github.com/CryptoConsortium/CCSS/issues/new?body=Source%20File%3A%20103-KeyStorage%0A%0A">Discuss</a>
| <a href="#top">Top</a>
</div>
</h1>
<p>此方面涵盖了不使用加密私有<a href="../Definitions#key">密钥</a>和<a href="../Definitions#seed">种子</a>的方式。 为了最大程度地提高密钥材料（即<a href="../Definitions#key">密钥</a>和<a href="../Definitions#seed">种子</a>）的机密性，应该按照业务考量所允许的安全方式存储，并在适当的情况下使用加密、私密共享和物理锁之类的策略。为了最大程度地提高密钥/种子的完整性，应该存在备份，从而在无法访问主密钥时可以恢复密钥/种子。应当注意确保备份存储的安全性至少与主密钥一样高（如果不是更高的话）。值得注意的是，由系统的最终用户生成的加密资产不受本节备份要求的约束，因为对最终用户强制实施良好的行为实际上是不可能的。</p>
<p>
<h3>此方面组件包括</h3>
<ul class="component-list">
<li>1.3.1 主密钥以加密方式存储</li>
<li>1.3.2 备份密钥存在</li>
<li>1.3.3 备用钥匙具有环境保护</li>
<li>1.3.4 备份密钥访问控制</li>
<li>1.3.5 备用钥匙具有防篡改印章</li>
<li>1.3.6 备份密钥以加密方式存储</li>
</ul>
</p>
<p>
<ul class="post-list">
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_1_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>加密<a href="../Definitions#key">密钥</a>和/或<a href="../Definitions#seed">种子</a>在不使用时必须用<a href="../Definitions#strong-encryption">强加密</a>存储。</p>
</li>
<li><p>加密的<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>必须备份。备份可以采用任何形式（纸张、数码等）。</p>
</li>
<li><p>必须通过访问控制保护备份，防止未经授权方访问备份。例如，保险箱、保管箱或带锁的抽屉只有操作员才掌握锁的钥匙/组合。</p>
</li>
<li><p>必须保护备份免受环境风险，如火灾、洪水和其他不可抗力。尽管具体的环境保护机制可能会根据用于备份的介质类型不同而有所不同，但实现此目标的常用方法包括用于防洪的防水袋和用于防火的保险箱或防火箱。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_2_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>备份必须至少具备与使用资金所需同等数量的<a href="../Definitions#key">密钥</a>。例如，在需要3个密钥中的2个才能使用资金的3选2签名设置中，必须为这些密钥中的至少2个备份。在9选5的设置中，必须存在至少5个密钥的备份。</p>
</li>
<li><p>备份<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>必须存储在与主密钥/种子的使用位置地理位置不同的位置。例如，主密钥保存在办公室，则备用密钥可以存储在员工的个人住宅中。另一个示例可能涉及将备份由受信任的第三方托管。</p>
</li>
<li><p>备份必须采用某种形式的防篡改机制，该机制允许操作员确定何时对其进行了访问。一种安全的方法是使用一个防篡改序列编号袋。但是，使用在印章上有手写签名的密封纸质信封也可以满足要求，前提是所使用的特定信封能够揭示篡改的证据。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_3_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>对不使用的<a href="../Definitions#key">密钥</a>和/或<a href="../Definitions#seed">种子</a>的备份使用的<a href="../Definitions#strong-encryption">强加密</a>至少必须与上述加密密钥/种子规定的安全性相同。如果备份使用的安全性机制低于密钥/种子本身，则不能认证该系统为III级</p>
</li>
<li><p>备份可抵抗电磁脉冲，该电磁脉冲可能会在电子设备中感应出电流并损坏其中存储的数据。防范此风险的常用方法是将<a href="../Definitions#seed">种子</a>或<a href="../Definitions#key">密钥</a> 存储在纸张、木材、金属或其他非数字媒体上，或将数字媒体放置在密封的法拉第袋中，法拉第袋可防止内容受到电磁干扰。</p>
</li>
</ul>
</li>
</ul>
</p>
</li>
<li> <a name="1.04"></a>
<h1> 1.04 密钥使用
<div class="contribution-links">
<a href="https://github.com/CryptoConsortium/CCSS/edit/master/_data/aspects/104-KeyUsage.yml">Edit</a>
| <a href="https://github.com/CryptoConsortium/CCSS/commits/master/_data/aspects/104-KeyUsage.yml">History</a>
| <a href="https://github.com/CryptoConsortium/CCSS/issues/new?body=Source%20File%3A%20104-KeyUsage%0A%0A">Discuss</a>
| <a href="#top">Top</a>
</div>
</h1>
<p>此方面涵盖使用加密<a href="../Definitions#key">密钥</a>和/或<a href="../Definitions#seed">种子</a>，确保它们是以安全的方式使用，从而最大程度地降低私钥机密性和资金完整性的风险。本节不介绍密钥备份的用法，这些备份仅在主密钥丢失/损坏/不可访问的情况下使用。使用密钥时会带来各种风险，这些风险可能导致资金损失，包括肮脏签名漏洞（即重复使用的“ R”值），恶意软件复制或修改密钥的机会以及恶意内部人员使用授权访问权限发送未经授权的交易的风险。</p>
<p>
<h3>此方面组件包括</h3>
<ul class="component-list">
<li>1.4.1 密钥访问需要用户/通过/n个因素</li>
<li>1.4.2 密钥仅在受信环境中使用</li>
<li>1.4.3 操作员证明材料检查</li>
<li>1.4.4 操作员ID检查</li>
<li>1.4.5 操作员背景检查</li>
<li>1.4.6 签字前先验证支出</li>
<li>1.4.7 一台设备上没有使用两个密钥</li>
<li>1.4.8 DRBG合规性</li>
</ul>
</p>
<p>
<ul class="post-list">
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_1_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>要访问主<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>，需要使用标识符（如用户名、电子邮件、GUID等）以及至少两个其他（双）<a href="../Definitions#authentication-factor">身份验证因素</a>，从而限制了对授权操作员的访问。身份验证的其他因素的示例包括Google Authenticator令牌、私钥中的数字签名、亲自进行的ID验证、物理密钥或令牌的拥有或可以远程证明密钥持有者真实性的签名组织。</p>
</li>
<li><p>所有<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>仅在<a href ="../Definitions#trusted-environment">受信环境</a>中使用。这在某种程度上降低了恶意软件制作未经授权的副本的风险，并降低了（甚至不经意地）将密钥存储在机器上，从而允许其他用户或入侵者恢复的风险。有效的可信环境可防止未经授权的人员了解私钥、密码或其他敏感信息。</p>
</li>
<li><p>所有<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>持有人都必须先进行证明材料检查，然后才能信任他持有组织的某一密钥/种子。这有助于确保该人员的过去是真实的，并且不会因为以前的解雇而构成对组织的风险。</p>
</li>
<li><p>所有<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>持有人（个人和组织）都经过了<a href =“ ../ Definitions＃identity-verification”>身份验证</a>，确保他们是他们所说的人。 这样可以减少与冒名顶替和社会工程攻击有关的风险，这些风险可能导致获得组织或客户资金。</p>
</li>
<li><p>在同一台设备上没有两个<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>具有相同的<a href =“.。 / Definitions＃multisig“>多重签名</a>钱包。将同一钱包的两个密钥放在单个设备上会使密钥暴露给恶意操作员或恶意软件。确保钱包的每个密钥在专用设备上使用可以降低这些风险，从而提高安全性。</p>
</li>
<li><p>数字<a href="../Definitions#signature">签名</a>必须使用永远不会重复的“ k”值。 这可以通过使用符合<a href="http://http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf">NIST SP 800-90A</a>的<a href="../Definitions#drbg">确定性随机位生成器（deterministic random bit generator, DRBG）</a>， 或与<a href="https://tools.ietf.org/html/rfc6979">RFC 6979</a>兼容的的确定性方案实现。必须使用强大的<a href="../Definitions#entropy">熵</a>来源，防止可能导致攻击者恢复用于计算签名的私钥的“脏签名(dirty signature)”漏洞。常见的实现方式是使用流行操作系统提供的<a href="../Definitions#prng">伪随机数生成器（pseudo-random number generator, PRNG）</a>或RFC 6979兼容方案。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_2_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>在使用<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>之前通过<a href="../Definitions#authenticated-communication-channel">已认证的通信通道</a>验证资金目的地和金额。这可以由人在使用密钥/种子之前执行，从而确保将正确数量的资金发送到正确的<a href="../Definitions#address">地址</a>/人员/公司，或者由执行自动签名的系统通过在应用签名之前对照白名单和支出限制检查目标地址实现。提供<a href="../Definitions#signature">数字签名</a>地址的支付协议的实现，或者使用显示图像和企业名称而不是加密货币地址的系统，可以大大简化这一验证过程。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_3_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>要访问<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>，需要使用标识符（如用户名、电子邮件、GUID 等等），以及至少三个其他（三）<a href="../Definitions#authentication-factor">认证因素</a>。与级别I中2个其他因素的要求相似，级别3中的其他3个身份验证因素可以采用任何形式提供对授权用户身份的确认。</p>
</li>
<li><p>所有<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>持有人均已由执法人员或调查公司进行背景调查。这样可以确保每个密钥/种子持有者都是他们所说的人。并且，如果他们拥有组织或用户资金的签署权限，根据他们过去的言行举止，他们不会给组织带来风险。</p>
</li>
</ul>
</li>
</ul>
</p>
</li>
<li> <a name="1.05"></a>
<h1> 1.05 密钥妥协协议(Key Compromise Protocol, KCP)
<div class="contribution-links">
<a href="https://github.com/CryptoConsortium/CCSS/edit/master/_data/aspects/105-KeyCompromiseProtocol.yml">Edit</a>
| <a href="https://github.com/CryptoConsortium/CCSS/commits/master/_data/aspects/105-KeyCompromiseProtocol.yml">History</a>
| <a href="https://github.com/CryptoConsortium/CCSS/issues/new?body=Source%20File%3A%20105-KeyCompromiseProtocol%0A%0A">Discuss</a>
| <a href="#top">Top</a>
</div>
</h1>
<p>此方面涵盖了<a href="../Definitions#key-compromise-protocol">协议</a>的存在和使用，该协议规定了在加密<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>或其<a href="../Definitions#actor">操作员/持有人< / a>被认为受损时要采取的行动。组织必须做好准备应对私钥已知、可被确定或已被破坏的情况。适当的策略和程序管理这些事件，可以减少与资金损失和商业秘密泄露相关的风险，并提高信息系统对用户的可用性。缺少KCP会使组织无法获得III级认证。何时调用KCP的示例包括：识别对放置在关键材料上的防篡改印章的篡改、亲密的朋友和家人无法识别操作员下落的明显失踪，或收到可靠地信息表明操作员或密钥可能有泄露的风险。 <a href="../Definitions#key-compromise-protocol">密钥妥协协议</a>的执行必须使用<a href="../Definitions#authenticated-communication-channel">已认证的通信通道</a>，确保仅由经过身份验证的参与者发送/接收KCP消息。</p>
<p>
<h3>此方面组件包括</h3>
<ul class="component-list">
<li>1.5.1 存在KCP</li>
<li>1.5.2 KCP培训和演练</li>
</ul>
</p>
<p>
<ul class="post-list">
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_1_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>存在所有<a href="../Definitions#key">密钥</a>/<a href="../Definitions#seed">种子</a>的清单，并且知道哪些密钥对信息系统的成功在组织内部运行很关键。 尽管没有正式的<a href="../Definitions#key-compromise-protocol"> KCP </a>文档，但仍有一些员工能够指导操作员执行必要的程序，重新生成加密密钥、重新生成加密货币<a href =“ ../ Definitions＃wallet”>钱包</a>，并在任何操作员或密钥受到威胁时将资金发送到这些新生成的钱包。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_2_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>适当的<a href="../Definitions#key-compromise-protocol">密钥妥协协议</a>概述了整个系统中使用的每个特定类别的密钥，以及应对威胁的详细计划，包括在执行过程中正确使用 <a href="../Definitions#authenticated-communication-channel">已认证的通信通道</a>。该计划通过角色而不是名称识别参与者，并且包括任何主要参与者无法执行KCP的情况下的备援参与者。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_3_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>定期执行<a href="../Definitions#key-compromise-protocol"> 密钥妥协协议</a>的测试，确认程序的可行性，并确保在发生受损情况时员工使用程序的培训。存在已执行测试的日志，概述了该测试的任何/所有注释。在测试过程中确定的改进回写到协议中，确保始终保持最有效的协议。当更改信息系统时，将重新考虑“密钥妥协协议”，确保使用任何新的密钥类对协议进行更新。</p>
</li>
</ul>
</li>
</ul>
</p>
</li>
<li> <a name="1.06"></a>
<h1> 1.06 密钥持有人授权/撤销策略和程序
<div class="contribution-links">
<a href="https://github.com/CryptoConsortium/CCSS/edit/master/_data/aspects/106-KeyholderGrantRevokePoliciesAndProcedures.yml">Edit</a>
| <a href="https://github.com/CryptoConsortium/CCSS/commits/master/_data/aspects/106-KeyholderGrantRevokePoliciesAndProcedures.yml">History</a>
| <a href="https://github.com/CryptoConsortium/CCSS/issues/new?body=Source%20File%3A%20106-KeyholderGrantRevokePoliciesAndProcedures%0A%0A">Discuss</a>
| <a href="#top">Top</a>
</div>
</h1>
<p>此方面涵盖有关授予和撤消对存储组织或最终用户的资金的加密<a href="../Definitions#key">密钥</a>或<a href="../Definitions#seed">种子</a>的访问策略和程序。在访问信息系统、调用特权限制操作以及代表组织面对向公众方面，员工通常具有更大的信息系统访问权限。对人员入职和离职管理不当会带来风险，员工离职时仍会保留特权帐户，未撤销的密钥也会持久保留某些交易的<a href="../Definitions#signature">签名</a>权限。</p>
<p>
<h3> 此方面组件包括</h3>
<ul class="component-list">
<li>1.6.1 授予/撤销程序/清单</li>
<li>1.6.2 通过身份验证通信渠道发出的请求</li>
<li>1.6.3 授予/撤销审计追踪</li>
</ul>
</p>
<p>
<ul class="post-list">
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_1_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>An awareness of how roles should be managed when onboarding or offboarding staff from keyholder positions exists within the organization. A staff member who is knowledgeable about the system is able to ensure that permissions are granted/revoked to/from the affected staff appropriately.</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_2_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>组织内部维护有对关键职位角色上人员入职或离职应该完成的任务的清单。 这些清单已由知识丰富的人员审阅，确保“最低特权原则”应用于信息系统，只在需要时进行必要的访问。这样就消除了与特权遗失以及拥有未撤消的<a href="../Definitions#key">密钥</a>相关的风险。</p>
</li>
<li><p>所有密钥持有人授予/撤销请求均通过<a href="../Definitions#authenticated-communication-channel">认证的通信渠道</a>进行</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_3_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>组织的清单包括审计信息，这些信息记录了执行授予/撤销操作的员工的身份。审计追踪中的每个条目均由执行该任务的工作人员证明。</p>
</li>
</ul>
</li>
</ul>
</p>
</li>
<li> <a name="2.01"></a>
<h1> 2.01 安全审计/渗透测试
<div class="contribution-links">
<a href="https://github.com/CryptoConsortium/CCSS/edit/master/_data/aspects/201-SecurityAuditsAndPentests.yml">Edit</a>
| <a href="https://github.com/CryptoConsortium/CCSS/commits/master/_data/aspects/201-SecurityAuditsAndPentests.yml">History</a>
| <a href="https://github.com/CryptoConsortium/CCSS/issues/new?body=Source%20File%3A%20201-SecurityAuditsAndPentests%0A%0A">Discuss</a>
| <a href="#top">Top</a>
</div>
</h1>
<p>该方面涵盖了对安全系统、技术控制措施和策略的第三方审查，这些信息可保护信息系统免受各种形式的风险，以及旨在识别可绕过现有控制措施的途径的渗透和漏洞测试。 无论构建和维护信息系统的员工的技术技能、知识和经验如何，第三方审查都已证明经常能发现员工忽视或低估的风险和控制缺陷。与开发公司需要编写产品的人员以外的人员测试产品相同的原因，需要实施加密货币系统的人员以外的人员评估系统的安全性。第三方提供了不同的观点，独立于技术控制措施，客观且没有被报复的风险。</p>
<p>
<h3>此方面组件包括</h3>
<ul class="component-list">
<li>2.1.1 Security Audit</li>
</ul>
</p>
<p>
<ul class="post-list">
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_1_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>一位了解比特币安全性的开发人员协助信息系统的设计和实施。 在设计和实施阶段提供这些知识有助于确保遵循最佳实践以最大程度地降低风险。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_2_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>第三方实体在启动之前或之后不久完成了一次审计和/或渗透/漏洞测试。 审计涵盖了源代码的静态和动态分析，确保在适用的情况下使用了安全的编程模式，并在在任何使用了加密库的地方正确地使用了加密库。 此外，文档显示，审计小组提出的所有疑虑都已由系统团队解决并在系统中消除。这些审计减少了机构盲目性带来的风险，并增强了对组织控制措施和程序的信心。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_3_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>安全审计和/或渗透/漏洞测试按规定的时间表进行，每个日历年至少进行一次，并且存在说明如何解决审计中问题的文档。定期审计或渗透测试不仅可以降低未知缺陷带来的安全性风险，而且还可以降低安全性的总体成本，因为每次审计都基于最近的结果，从而可以进行更具针对性和成本效益的评估。</p>
</li>
</ul>
</li>
</ul>
</p>
</li>
<li> <a name="2.02"></a>
<h1> 2.02 数据清理策略(Data Sanitization Policy, DSP)
<div class="contribution-links">
<a href="https://github.com/CryptoConsortium/CCSS/edit/master/_data/aspects/202-DataSanitizationPolicy.yml">Edit</a>
| <a href="https://github.com/CryptoConsortium/CCSS/commits/master/_data/aspects/202-DataSanitizationPolicy.yml">History</a>
| <a href="https://github.com/CryptoConsortium/CCSS/issues/new?body=Source%20File%3A%20202-DataSanitizationPolicy%0A%0A">Discuss</a>
| <a href="#top">Top</a>
</div>
</h1>
<p>本方面涵盖了从数字媒体中删除<a href="../Definitions#key"></a>密钥</a>。 由于文件系统在数字媒体上分配数据的方式，可以使用数字取证技术读取以前已删除的旧数据。正确清理数字媒体可确保正确删除所有密钥，从而消除了已退役设备（如服务器、硬盘驱动器和可移动存储）中信息泄漏的风险。</p>
<p>
<h3>此方面组件包括</h3>
<ul class="component-list">
<li>2.2.1 存在DSP</li>
<li>2.2.2 所有媒体清理的审计追踪</li>
</ul>
</p>
<p>
<ul class="post-list">
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_1_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>组织的员工知道数据在删除后如何在数字媒体上持久保存。员工也可以访问执行安全删除数据的工具，并了解何时使用此类工具永久销毁在信息系统的维护过程中可能需要使用的任何<a href="../Definitions#key">密钥</a>的临时副本。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_2_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>存在已制定的详细策略，该策略概述了清理保存/拥有加密<a href="../Definitions#key">密钥</a>的数字媒体的要求，并且所有有权访问密钥的人员都可以阅读/理解。程序文档概述了流程中需要清理的地方。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_3_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>除上述内容外，还为每个经过清理的介质维护一个审计追踪。 这些审计文件标识了执行清理的工作人员、已清理介质的特定标识符、用于执行清理的工具和配置以及所有其他相关信息。</p>
</li>
</ul>
</li>
</ul>
</p>
</li>
<li> <a name="2.03"></a>
<h1> 2.03 储备金证明(Proof of Reserve, PoR)
<div class="contribution-links">
<a href="https://github.com/CryptoConsortium/CCSS/edit/master/_data/aspects/203-ProofOfReserve.yml">Edit</a>
| <a href="https://github.com/CryptoConsortium/CCSS/commits/master/_data/aspects/203-ProofOfReserve.yml">History</a>
| <a href="https://github.com/CryptoConsortium/CCSS/issues/new?body=Source%20File%3A%20203-ProofOfReserve%0A%0A">Discuss</a>
| <a href="#top">Top</a>
</div>
</h1>
<p>这方面涵盖了信息系统应持有的所有资金的控制权证明。已知的情况是，应该以全部用户资金储备运行的信息系统以一部分储备运行，导致该系统无法覆盖所有用户的同时提款。这些<a href="../Definitions#proof-of-reserve"></a>储备证明</a> 向公众保证系统可以使用所有资金，从而消除了资金损失的风险。</p>
<p>
<h3>此方面组件包括</h3>
<ul class="component-list">
<li>2.3.1 储备金证明审计</li>
</ul>
</p>
<p>
<ul class="post-list">
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_1_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>审计已完成并在线发布，可以证明对该信息系统拥有的所有资金都有完全的控制权。审计由独立的第三方签署，证明审计在执行时的准确性，从而降低了与不准确或误导性报告相关的风险。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_2_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>该组织定期进行<a href="../Definitions#proof-of-reserve"></a>准备金</a>审计的证明，证明该组织继续以全额准备金运作，并且在每次审计完成时可以使用所有用户资金。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_3_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>信息系统的设计方式使得不必进行独立审计即可证明用户资金的完全可访问性。信息系统利用区块链之类的公共分类账向公众提供该信息，从而允许任何人独立进行审计。</p>
</li>
</ul>
</li>
</ul>
</p>
</li>
<li> <a name="2.04"></a>
<h1> 2.04 审计日志
<div class="contribution-links">
<a href="https://github.com/CryptoConsortium/CCSS/edit/master/_data/aspects/204-AuditLogs.yml">Edit</a>
| <a href="https://github.com/CryptoConsortium/CCSS/commits/master/_data/aspects/204-AuditLogs.yml">History</a>
| <a href="https://github.com/CryptoConsortium/CCSS/issues/new?body=Source%20File%3A%20204-AuditLogs%0A%0A">Discuss</a>
| <a href="#top">Top</a>
</div>
</h1>
<p>此方面涵盖了信息系统的审计日志维护，该日志提供了整个系统中所有信息更改的记录。 在发生意外行为或安全事件时，审计日志是非常有价值的工具，可以帮助调查人员了解意外症状是如何发生的以及如何解决不一致问题以使信息系统恢复一致性状态。审计日志的维护可大大降低与运营意识相关的风险，并增强信息系统纠正任何不准确性的能力。</p>
<p>
<h3>此方面组件包括</h3>
<ul class="component-list">
<li>2.4.1 应用审计日志</li>
<li>2.4.2 应用审计日志的备份</li>
</ul>
</p>
<p>
<ul class="post-list">
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_1_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>对于信息系统内所执行的操作子集存在审计追踪。示例包括记录该系统进行的所有提款和存款的审计信息。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_2_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>记录所有用户的所有操作。这些记录为调查信息系统的意外行为提供重要帮助，并且可以帮助识别恶意行为者和负责的系统或人员。</p>
</li>
</ul>
</li>
<li>
<h2> <img class='level' src='/CCSS/images/CCSS_3_Color_Dark.png'/> </h2>
<ul class="level-list">
<li><p>除了记录系统内执行的所有操作外，该审计信息还将定期备份到单独的服务器上。 如果在对信息系统的攻击期间审计日志被更改/破坏，此行为有助于保留有价值的调查信息。</p>
</li>
</ul>
</li>
</ul>
</p>
</li>
</ul>
</div>
</div>
</div>
<footer class="site-footer">
<div class="wrapper">
<div class="footer-col-wrapper">
<div class="footer-col footer-col-1">
<ul class="contact-list">
<li><a href='https://cryptoconsortium.org'><img src='/CCSS/images/C4_Color_Dark.png' class='org_logo' /> </a></li>
</ul>
</div>
<div class="footer-col footer-col-2">
<ul class="social-media-list">
<li>
<a href="https://github.com/cryptoconsortium">
<span class="icon icon--github">
<svg viewBox="0 0 16 16">
<path fill="#828282" d="M7.999,0.431c-4.285,0-7.76,3.474-7.76,7.761 c0,3.428,2.223,6.337,5.307,7.363c0.388,0.071,0.53-0.168,0.53-0.374c0-0.184-0.007-0.672-0.01-1.32 c-2.159,0.469-2.614-1.04-2.614-1.04c-0.353-0.896-0.862-1.135-0.862-1.135c-0.705-0.481,0.053-0.472,0.053-0.472 c0.779,0.055,1.189,0.8,1.189,0.8c0.692,1.186,1.816,0.843,2.258,0.645c0.071-0.502,0.271-0.843,0.493-1.037 C4.86,11.425,3.049,10.76,3.049,7.786c0-0.847,0.302-1.54,0.799-2.082C3.768,5.507,3.501,4.718,3.924,3.65 c0,0,0.652-0.209,2.134,0.796C6.677,4.273,7.34,4.187,8,4.184c0.659,0.003,1.323,0.089,1.943,0.261 c1.482-1.004,2.132-0.796,2.132-0.796c0.423,1.068,0.157,1.857,0.077,2.054c0.497,0.542,0.798,1.235,0.798,2.082 c0,2.981-1.814,3.637-3.543,3.829c0.279,0.24,0.527,0.713,0.527,1.437c0,1.037-0.01,1.874-0.01,2.129 c0,0.208,0.14,0.449,0.534,0.373c3.081-1.028,5.302-3.935,5.302-7.362C15.76,3.906,12.285,0.431,7.999,0.431z"/>
</svg>
</span>
<span class="username">cryptoconsortium</span>
</a>
</li>
<li>
<a href="https://twitter.com/LearnMoreWithC4">
<span class="icon icon--twitter">
<svg viewBox="0 0 16 16">
<path fill="#828282" d="M15.969,3.058c-0.586,0.26-1.217,0.436-1.878,0.515c0.675-0.405,1.194-1.045,1.438-1.809
c-0.632,0.375-1.332,0.647-2.076,0.793c-0.596-0.636-1.446-1.033-2.387-1.033c-1.806,0-3.27,1.464-3.27,3.27 c0,0.256,0.029,0.506,0.085,0.745C5.163,5.404,2.753,4.102,1.14,2.124C0.859,2.607,0.698,3.168,0.698,3.767 c0,1.134,0.577,2.135,1.455,2.722C1.616,6.472,1.112,6.325,0.671,6.08c0,0.014,0,0.027,0,0.041c0,1.584,1.127,2.906,2.623,3.206 C3.02,9.402,2.731,9.442,2.433,9.442c-0.211,0-0.416-0.021-0.615-0.059c0.416,1.299,1.624,2.245,3.055,2.271 c-1.119,0.877-2.529,1.4-4.061,1.4c-0.264,0-0.524-0.015-0.78-0.046c1.447,0.928,3.166,1.469,5.013,1.469 c6.015,0,9.304-4.983,9.304-9.304c0-0.142-0.003-0.283-0.009-0.423C14.976,4.29,15.531,3.714,15.969,3.058z"/>
</svg>
</span>
<span class="username">LearnMoreWithC4</span>
</a>
</li>
</ul>
</div>
<div class="footer-col footer-col-3">
<p class="text">The CryptoCurrency Certification Consortium (C4) establishes cryptocurrency standards that help ensure a balance of openness & privacy, security & usability, and trust & decentralization.
</p>
</div>
</div>
</div>
</footer>
</body>
</html>