1.01 密钥/种子生成

Edit | History | Discuss | Top

该方面涵盖了将在加密货币系统内使用的加密密钥 和种子的生成。加密密钥和种子的安全创建需要确保两件事的安全性：机密性和不可猜测的数字。需要保密以确保计划外的第三方不会读取/复制新创建的密钥或种子。需要不可猜测的数字，以确保计划外的第三方无法猜测或确定新创建的密钥。下面列出的每个目标都保证了密钥和/或种子是以机密且不可猜测的方式创建的。

该方面的组件包括

• 1.1.1 操作员创建的密钥/种子
• 1.1.2 经验证的创建方法
• 1.1.3 遵守DRBG
• 1.1.4 熵(Entropy)池

• 

  • 加密密钥和种子是由将使用它的参与者创建。这是为了保护密钥的机密性。任何需要参与者在生成密钥或种子后将密钥或种子传送给另一个参与者的系统，除非是自动签名代理的初始配置，否则都无法达到I级。

  • 如果自动代理将使用加密密钥/种子，则建议该系统的管理员在适当的离线系统上以足够的熵生成密钥/种子，并将此密钥/种子安全传送 到目标设备上 ，然后使用符合CCSS的数据清理技术安全删除，以保护密钥/种子的机密性。

  • 值得注意的是，出于备份目的而传输加密机密不会违反“同一参与者”的要求，但是，这些机密必须以强加密的格式进行传输和存储。

  • 加密密钥和种子是在具有足够熵的系统上创建的，确保创建密钥时不会偏向于值范围缩小或其他确定性属性

• 

  • 密钥或种子的生成方法在使用前经过验证。用于生成种子的软件在生成的种子符合确定值以及将所存储的种子存储或传输给另一个参与者的功能方面应没有任何限制，除非这些功能增强了软件的有效安全性 (如 DRBGs).

  • 在对软件进行审计之后，应生成并发布数字签名。签名应在每次执行之前验证，以确保自通过安全审计以来该软件没有更改。

  • 如果密钥或种子是在不使用软件的情况下创建的（如骰子、纸牌或其他非数字熵源），则应验证创建方法，确保不存在确定性（即骰子没有重量不一致、纸牌中的每张牌都是唯一的，依此类推）。

• 

  • 密钥或种子是使用符合NIST SP 800-90A的确定性随机位生成器（Deterministic Random Bit Generator, DRBG）生成的，并使用了至少两个单独的加密安全熵（以加密的安全方式组合，如SHA256[UnguessableFactor1 + UnguessableFactor2]）。NIST SP 800-90A是一个标准，用于确保确定性生成的数字相对于确定性种子遵循随机分布。因此，确定这些随机数的能力会降低发现DRBG种子的能力。

  • NIST SP 800-90A的Dual_EC DRBG已被证明存在漏洞，不应使用。

  • 另外的选项是使用通过了针对随机性的行业标准统计测试的非确定性随机位生成器（NRBG）或“真实随机数生成器”（TRNG）生成密钥或种子，以代替具有上述两个种子的组合的符合NIST SP 800-90A的DRBG。这些行业标准有DIEHARD、Crypt-X,或NIST STS.

1.02 钱包创建

Edit | History | Discuss | Top

本方面涉及创建可以接收加密货币的钱包或地址。 钱包使用密钥签名方法创建，该方法可能需要单个密钥签名、多个密钥的签名或许多密钥中最少数量的签名。此外既可以单独创建钱包，通常称为JBOK钱包（Just a Bunch Of Keys），也可以使用确定的方式创建，该方式允许从单个主种子创建一组地址/密钥对。钱包创建的安全性源自面对的各种风险（例如丢失、被盗/损坏的密钥）的钱包完整性以及钱包的机密性，这将使钱包与特定的参与者关联。

• 

  • 对每笔交易强制使用新地址的系统会隐式缓解通过受损的钱包继续从参与者那里获得资金，而参与者没有得到受损的通知的情况，如2015年初BitStamp入侵后的几天里并没有被告知有关入侵的消息。由于先前生成的地址仍然有效，因此无法防止用户（意外或其他方式）向旧地址发送交易。建议在攻陷事件发生时，使用自动钱包清扫系统将发生给受损地址的资金转移到新的安全钱包中。

• 

  • 由钱包生成的任何地址必须至少需要2个签名才能使用资金，其中每一参与者持有每个签名的密钥。 在钱包上需要2个或更多签名，可以降低与受损的密钥或密钥持有者相关的盗窃风险，从而提高资金的完整性。 这通常称为多重签名（multi-sig）钱包。 参与者可以是人或系统（即两个人，两个系统或一个人和一个系统），但必须是单独的实体，每个实体都管理自己的钱包密钥。

  • 出于恢复目的，将冗余的密钥分配给每个钱包。 这样可以确保在由于任何原因无法访问主密码的情况下仍然可以使用资金。实现此目标的一种常见方法是创建一个钱包，该钱包需要3种可能的签名中的任意2种才能使用资金（即，有1个冗余密钥）

  • 根据保密的种子确定地为钱包分配地址。使用JBOK钱包需要对每个新生成的密钥定期备份，这会增加系统的复杂性。 这增加了人为错误的风险，如果备份不包含某些密钥，则可能导致业务中断或资金意外损失。 确定性分配的钱包消除了这种风险，并改善了系统的完整性。

  • 任何在单个钱包上具有签名权限的密钥必须存储在不同的位置 。 通过将钱包的密钥分布在多个位置，与局部业务中断（火灾、洪水、地震、闯入）相关的风险不会影响组织使用资金的能力。

• 

  • 钱包必须为每笔交易生成唯一的地址。 通过使确定哪个地址属于哪个 参与者 更加困难提高了隐私性。 实现此要求的最常见方法之一是使用确定性钱包生成所有地址。

  • 任何在单个钱包上具有签名权限的密钥必须由多个组织实体存储。通过将密钥提供给单独的法人实体，如律师、会计师或其他公司，可能损害业务的法律风险并不一定会损害您的资金。请注意，这不会违反“密钥/种子生成”级别1的要求，因为单独的组织无法满足对 参与者的定义。

1.03 密钥存储

Edit | History | Discuss | Top

此方面涵盖了不使用加密私有密钥和种子的方式。 为了最大程度地提高密钥材料（即密钥和种子）的机密性，应该按照业务考量所允许的安全方式存储，并在适当的情况下使用加密、私密共享和物理锁之类的策略。为了最大程度地提高密钥/种子的完整性，应该存在备份，从而在无法访问主密钥时可以恢复密钥/种子。应当注意确保备份存储的安全性至少与主密钥一样高（如果不是更高的话）。值得注意的是，由系统的最终用户生成的加密资产不受本节备份要求的约束，因为对最终用户强制实施良好的行为实际上是不可能的。

此方面组件包括

• 1.3.1 主密钥以加密方式存储
• 1.3.2 备份密钥存在
• 1.3.3 备用钥匙具有环境保护
• 1.3.4 备份密钥访问控制
• 1.3.5 备用钥匙具有防篡改印章
• 1.3.6 备份密钥以加密方式存储

• 

  • 加密密钥和/或种子在不使用时必须用强加密存储。

  • 加密的密钥/种子必须备份。备份可以采用任何形式（纸张、数码等）。

  • 必须通过访问控制保护备份，防止未经授权方访问备份。例如，保险箱、保管箱或带锁的抽屉只有操作员才掌握锁的钥匙/组合。

  • 必须保护备份免受环境风险，如火灾、洪水和其他不可抗力。尽管具体的环境保护机制可能会根据用于备份的介质类型不同而有所不同，但实现此目标的常用方法包括用于防洪的防水袋和用于防火的保险箱或防火箱。

• 

  • 备份必须至少具备与使用资金所需同等数量的密钥。例如，在需要3个密钥中的2个才能使用资金的3选2签名设置中，必须为这些密钥中的至少2个备份。在9选5的设置中，必须存在至少5个密钥的备份。

  • 备份密钥/种子必须存储在与主密钥/种子的使用位置地理位置不同的位置。例如，主密钥保存在办公室，则备用密钥可以存储在员工的个人住宅中。另一个示例可能涉及将备份由受信任的第三方托管。

  • 备份必须采用某种形式的防篡改机制，该机制允许操作员确定何时对其进行了访问。一种安全的方法是使用一个防篡改序列编号袋。但是，使用在印章上有手写签名的密封纸质信封也可以满足要求，前提是所使用的特定信封能够揭示篡改的证据。

• 

  • 对不使用的密钥和/或种子的备份使用的强加密至少必须与上述加密密钥/种子规定的安全性相同。如果备份使用的安全性机制低于密钥/种子本身，则不能认证该系统为III级

  • 备份可抵抗电磁脉冲，该电磁脉冲可能会在电子设备中感应出电流并损坏其中存储的数据。防范此风险的常用方法是将种子或密钥 存储在纸张、木材、金属或其他非数字媒体上，或将数字媒体放置在密封的法拉第袋中，法拉第袋可防止内容受到电磁干扰。

1.04 密钥使用

Edit | History | Discuss | Top

此方面涵盖使用加密密钥和/或种子，确保它们是以安全的方式使用，从而最大程度地降低私钥机密性和资金完整性的风险。本节不介绍密钥备份的用法，这些备份仅在主密钥丢失/损坏/不可访问的情况下使用。使用密钥时会带来各种风险，这些风险可能导致资金损失，包括肮脏签名漏洞（即重复使用的“ R”值），恶意软件复制或修改密钥的机会以及恶意内部人员使用授权访问权限发送未经授权的交易的风险。

此方面组件包括

• 1.4.1 密钥访问需要用户/通过/n个因素
• 1.4.2 密钥仅在受信环境中使用
• 1.4.3 操作员证明材料检查
• 1.4.4 操作员ID检查
• 1.4.5 操作员背景检查
• 1.4.6 签字前先验证支出
• 1.4.7 一台设备上没有使用两个密钥
• 1.4.8 DRBG合规性

• 

  • 要访问主密钥/种子，需要使用标识符（如用户名、电子邮件、GUID等）以及至少两个其他（双）身份验证因素，从而限制了对授权操作员的访问。身份验证的其他因素的示例包括Google Authenticator令牌、私钥中的数字签名、亲自进行的ID验证、物理密钥或令牌的拥有或可以远程证明密钥持有者真实性的签名组织。

  • 所有密钥/种子仅在受信环境中使用。这在某种程度上降低了恶意软件制作未经授权的副本的风险，并降低了（甚至不经意地）将密钥存储在机器上，从而允许其他用户或入侵者恢复的风险。有效的可信环境可防止未经授权的人员了解私钥、密码或其他敏感信息。

  • 所有密钥/种子持有人都必须先进行证明材料检查，然后才能信任他持有组织的某一密钥/种子。这有助于确保该人员的过去是真实的，并且不会因为以前的解雇而构成对组织的风险。

  • 所有密钥/种子持有人（个人和组织）都经过了身份验证，确保他们是他们所说的人。 这样可以减少与冒名顶替和社会工程攻击有关的风险，这些风险可能导致获得组织或客户资金。

  • 在同一台设备上没有两个密钥/种子具有相同的多重签名钱包。将同一钱包的两个密钥放在单个设备上会使密钥暴露给恶意操作员或恶意软件。确保钱包的每个密钥在专用设备上使用可以降低这些风险，从而提高安全性。

  • 数字签名必须使用永远不会重复的“ k”值。 这可以通过使用符合NIST SP 800-90A的确定性随机位生成器（deterministic random bit generator, DRBG）， 或与RFC 6979兼容的的确定性方案实现。必须使用强大的熵来源，防止可能导致攻击者恢复用于计算签名的私钥的“脏签名(dirty signature)”漏洞。常见的实现方式是使用流行操作系统提供的伪随机数生成器（pseudo-random number generator, PRNG）或RFC 6979兼容方案。

• 

  • 在使用密钥/种子之前通过已认证的通信通道验证资金目的地和金额。这可以由人在使用密钥/种子之前执行，从而确保将正确数量的资金发送到正确的地址/人员/公司，或者由执行自动签名的系统通过在应用签名之前对照白名单和支出限制检查目标地址实现。提供数字签名地址的支付协议的实现，或者使用显示图像和企业名称而不是加密货币地址的系统，可以大大简化这一验证过程。

• 

  • 要访问密钥/种子，需要使用标识符（如用户名、电子邮件、GUID 等等），以及至少三个其他（三）认证因素。与级别I中2个其他因素的要求相似，级别3中的其他3个身份验证因素可以采用任何形式提供对授权用户身份的确认。

  • 所有密钥/种子持有人均已由执法人员或调查公司进行背景调查。这样可以确保每个密钥/种子持有者都是他们所说的人。并且，如果他们拥有组织或用户资金的签署权限，根据他们过去的言行举止，他们不会给组织带来风险。

1.05 密钥妥协协议(Key Compromise Protocol, KCP)

Edit | History | Discuss | Top

此方面涵盖了协议的存在和使用，该协议规定了在加密密钥/种子或其操作员/持有人< / a>被认为受损时要采取的行动。组织必须做好准备应对私钥已知、可被确定或已被破坏的情况。适当的策略和程序管理这些事件，可以减少与资金损失和商业秘密泄露相关的风险，并提高信息系统对用户的可用性。缺少KCP会使组织无法获得III级认证。何时调用KCP的示例包括：识别对放置在关键材料上的防篡改印章的篡改、亲密的朋友和家人无法识别操作员下落的明显失踪，或收到可靠地信息表明操作员或密钥可能有泄露的风险。 密钥妥协协议的执行必须使用已认证的通信通道，确保仅由经过身份验证的参与者发送/接收KCP消息。

此方面组件包括

• 1.5.1 存在KCP
• 1.5.2 KCP培训和演练

• 

  • 存在所有密钥/种子的清单，并且知道哪些密钥对信息系统的成功在组织内部运行很关键。 尽管没有正式的 KCP 文档，但仍有一些员工能够指导操作员执行必要的程序，重新生成加密密钥、重新生成加密货币钱包，并在任何操作员或密钥受到威胁时将资金发送到这些新生成的钱包。

• 

  • 适当的密钥妥协协议概述了整个系统中使用的每个特定类别的密钥，以及应对威胁的详细计划，包括在执行过程中正确使用 已认证的通信通道。该计划通过角色而不是名称识别参与者，并且包括任何主要参与者无法执行KCP的情况下的备援参与者。

• 

  • 定期执行 密钥妥协协议的测试，确认程序的可行性，并确保在发生受损情况时员工使用程序的培训。存在已执行测试的日志，概述了该测试的任何/所有注释。在测试过程中确定的改进回写到协议中，确保始终保持最有效的协议。当更改信息系统时，将重新考虑“密钥妥协协议”，确保使用任何新的密钥类对协议进行更新。

1.06 密钥持有人授权/撤销策略和程序

Edit | History | Discuss | Top

此方面涵盖有关授予和撤消对存储组织或最终用户的资金的加密密钥或种子的访问策略和程序。在访问信息系统、调用特权限制操作以及代表组织面对向公众方面，员工通常具有更大的信息系统访问权限。对人员入职和离职管理不当会带来风险，员工离职时仍会保留特权帐户，未撤销的密钥也会持久保留某些交易的签名权限。

此方面组件包括

• 1.6.1 授予/撤销程序/清单
• 1.6.2 通过身份验证通信渠道发出的请求
• 1.6.3 授予/撤销审计追踪

• 

  • 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.

• 

  • 组织内部维护有对关键职位角色上人员入职或离职应该完成的任务的清单。 这些清单已由知识丰富的人员审阅，确保“最低特权原则”应用于信息系统，只在需要时进行必要的访问。这样就消除了与特权遗失以及拥有未撤消的密钥相关的风险。

  • 所有密钥持有人授予/撤销请求均通过认证的通信渠道进行

• 

  • 组织的清单包括审计信息，这些信息记录了执行授予/撤销操作的员工的身份。审计追踪中的每个条目均由执行该任务的工作人员证明。

2.01 安全审计/渗透测试

Edit | History | Discuss | Top

该方面涵盖了对安全系统、技术控制措施和策略的第三方审查，这些信息可保护信息系统免受各种形式的风险，以及旨在识别可绕过现有控制措施的途径的渗透和漏洞测试。 无论构建和维护信息系统的员工的技术技能、知识和经验如何，第三方审查都已证明经常能发现员工忽视或低估的风险和控制缺陷。与开发公司需要编写产品的人员以外的人员测试产品相同的原因，需要实施加密货币系统的人员以外的人员评估系统的安全性。第三方提供了不同的观点，独立于技术控制措施，客观且没有被报复的风险。

此方面组件包括

• 2.1.1 Security Audit

• 

  • 一位了解比特币安全性的开发人员协助信息系统的设计和实施。 在设计和实施阶段提供这些知识有助于确保遵循最佳实践以最大程度地降低风险。

• 

  • 第三方实体在启动之前或之后不久完成了一次审计和/或渗透/漏洞测试。 审计涵盖了源代码的静态和动态分析，确保在适用的情况下使用了安全的编程模式，并在在任何使用了加密库的地方正确地使用了加密库。 此外，文档显示，审计小组提出的所有疑虑都已由系统团队解决并在系统中消除。这些审计减少了机构盲目性带来的风险，并增强了对组织控制措施和程序的信心。

• 

  • 安全审计和/或渗透/漏洞测试按规定的时间表进行，每个日历年至少进行一次，并且存在说明如何解决审计中问题的文档。定期审计或渗透测试不仅可以降低未知缺陷带来的安全性风险，而且还可以降低安全性的总体成本，因为每次审计都基于最近的结果，从而可以进行更具针对性和成本效益的评估。

2.02 数据清理策略(Data Sanitization Policy, DSP)

Edit | History | Discuss | Top

本方面涵盖了从数字媒体中删除密钥。 由于文件系统在数字媒体上分配数据的方式，可以使用数字取证技术读取以前已删除的旧数据。正确清理数字媒体可确保正确删除所有密钥，从而消除了已退役设备（如服务器、硬盘驱动器和可移动存储）中信息泄漏的风险。

此方面组件包括

• 2.2.1 存在DSP
• 2.2.2 所有媒体清理的审计追踪

• 

  • 组织的员工知道数据在删除后如何在数字媒体上持久保存。员工也可以访问执行安全删除数据的工具，并了解何时使用此类工具永久销毁在信息系统的维护过程中可能需要使用的任何密钥的临时副本。

• 

  • 存在已制定的详细策略，该策略概述了清理保存/拥有加密密钥的数字媒体的要求，并且所有有权访问密钥的人员都可以阅读/理解。程序文档概述了流程中需要清理的地方。

• 

  • 除上述内容外，还为每个经过清理的介质维护一个审计追踪。 这些审计文件标识了执行清理的工作人员、已清理介质的特定标识符、用于执行清理的工具和配置以及所有其他相关信息。

2.03 储备金证明(Proof of Reserve, PoR)

Edit | History | Discuss | Top

这方面涵盖了信息系统应持有的所有资金的控制权证明。已知的情况是，应该以全部用户资金储备运行的信息系统以一部分储备运行，导致该系统无法覆盖所有用户的同时提款。这些储备证明 向公众保证系统可以使用所有资金，从而消除了资金损失的风险。

此方面组件包括

• 2.3.1 储备金证明审计

• 

  • 审计已完成并在线发布，可以证明对该信息系统拥有的所有资金都有完全的控制权。审计由独立的第三方签署，证明审计在执行时的准确性，从而降低了与不准确或误导性报告相关的风险。

• 

  • 该组织定期进行准备金审计的证明，证明该组织继续以全额准备金运作，并且在每次审计完成时可以使用所有用户资金。

• 

  • 信息系统的设计方式使得不必进行独立审计即可证明用户资金的完全可访问性。信息系统利用区块链之类的公共分类账向公众提供该信息，从而允许任何人独立进行审计。

2.04 审计日志

Edit | History | Discuss | Top

此方面涵盖了信息系统的审计日志维护，该日志提供了整个系统中所有信息更改的记录。 在发生意外行为或安全事件时，审计日志是非常有价值的工具，可以帮助调查人员了解意外症状是如何发生的以及如何解决不一致问题以使信息系统恢复一致性状态。审计日志的维护可大大降低与运营意识相关的风险，并增强信息系统纠正任何不准确性的能力。

此方面组件包括

• 2.4.1 应用审计日志
• 2.4.2 应用审计日志的备份

• 

  • 对于信息系统内所执行的操作子集存在审计追踪。示例包括记录该系统进行的所有提款和存款的审计信息。

• 

  • 记录所有用户的所有操作。这些记录为调查信息系统的意外行为提供重要帮助，并且可以帮助识别恶意行为者和负责的系统或人员。

• 

  • 除了记录系统内执行的所有操作外，该审计信息还将定期备份到单独的服务器上。 如果在对信息系统的攻击期间审计日志被更改/破坏，此行为有助于保留有价值的调查信息。