市场中的投资者通常引用的那句话“不是你的私钥，就不是你的加密货币”传达了纯粹主义者的加密密钥管理哲学。在这种钱包的安全模式中，只有个人对自己的私钥有直接和唯一的控制权，因此，对他们的加密资产有真正的所有权。坚持这种强硬做法的加密货币钱包被称为“非托管型”，这意味着没有任何外界人士能够接触到密钥。
只是，没那么快。情况并不那么简单。一些高调的“非托管”钱包黑客攻击——包括8月泄露8000多个账户的Slope钱包黑客攻击，2020年丢失的价值200多万美元IOTA代币的Trinity钱包黑客攻击，2017年允许攻击者窃取15万ETH的Parity钱包黑客攻击，加上发现的各种硬件钱包漏洞，以及其他事件，破坏了托管和非托管钱包之间的传统区别。在许多这样的案例中，认为自己在使用非托管钱包的受害者发现攻击者能够劫持他们梦寐以求的密钥。这不就矛盾了吗？
事实上，这个故事比一个口号所能捕捉到的更复杂。非托管钱包并没有真正让用户完全控制他们的私钥。这是因为钱包通常是由其他人的软件或硬件创建和操作的。用户不断把他们的信任放在其他人、产品和计算机程序上。他们接受使用区块链命令行界面、钱包软件和设备、中心化平台、智能合约代码、去中心化应用程序，以及中间的各种钱包连接集成。每个接触点都会增加风险；所有这些环环相扣的部分的总和打破了非托管钱包的假象。
保管权在现实中是非二元的。乍看之下可能是非托管的，实际上可能涉及许多托管要素，人们往往认为这些要素的可靠性是理所当然的。传统的二分法是一种错误的二分法。
相反，最好是以更细微的差别来看待钱包。要问的关键问题是：我可以接受多大的攻击面，在寻求消除对第三方的信任方面，我愿意承担多少责任？一般来说，密钥管理可以分为三个领域，每个领域都有独特的暴露机会。这些子类别如下：
密钥生成秘钥存储秘钥使用这个概述是为了帮助Web3用户更好地理解通过上述红线来保护他们的资产所涉及的错综复杂的问题。此外，我们的目的是帮助工程师识别和修复钱包开发中经常出现的故障点。我们希望应用本指南能够帮助投资者避免安全事故，无论他们是在与Web3技术互动、参与还是构建。
下面，我们将介绍目前存在的加密货币钱包安全和监管平台的共同特征和陷阱。我们还涵盖了我们认为在未来几个月和几年内需要最关注和发展的领域，以提高用户的Web3体验的安全性。
密钥生成钱包安全
任何关于钱包安全的讨论必须从密钥生成开始，即创建加密密钥的过程。无论钱包被认为是保管型的还是非保管型的，密钥生成步骤的安全属性对此后的密钥安全是最重要的。在密钥生成过程中，有三个首要问题需要牢记：使用可靠的代码，正确实现代码，以及安全处理输出。
如果你不是一个密码专家，可能很难验证以下所有因素都是按部就班进行的。检查一下你是否可以获得一份可信的审计报告，一些钱包供应商会在他们的官方网站或Github资源库中公布。取而代之的是，做你自己的研究，试图确定钱包背后是否有一个有信誉的公司。如果信息稀少，重要的用户和开发者活动可能是声誉的下一个指标。
遵循这些准则来减少你的风险暴露。如果一个钱包没有通过下面的检查，那就赶紧跑吧!
不要推出自己的加密货币钱包密码学家们有一句话：“不要推出你自己的加密货币”。其要点类似于“不要重新发明车轮”的格言。轮子现在已经很好了，任何试图从头开始重建的尝试都可能导致更糟糕的产品。密码学也是如此，这是一门很难完全正确的科学。组成钱包的代码应该有一个良好的工作声誉。选择写得不好的软件或试图从头开始开发自己的替代品可能会导致错误，如密钥泄漏或将秘密信息透露给未授权方。这就是最近Profanity的vanity地址工具中被利用的漏洞背后的原因。在做任何事情之前，应该明确有关的钱包使用的是经过审计的、有信誉的密钥生成库和程序。
使用两次测量并反复切割的钱包即使代码使用了信誉良好的密码学库，仍然必须正确地进行整合。经过审查的软件通常会在默认情况下设置正确的参数，但在执行中可能会出现漏洞。例如，需要一个强大的熵源，或数学随机性的剂量，以使将要生成的密钥不可预测，因此，更安全。对于某些密钥生成过程，如许多多方计算算法，其中必须生成和协调许多单独的密钥或碎片、密钥的片段，钱包应该遵循算法规定的精确协议。该算法可能还需要多轮计算以及刷新密钥，钱包必须适当地整合，以维护资金的安全。
使用一个可以保密的钱包密钥生成过程的最后阶段涉及软件的实际操作和输出。要注意秘钥是在哪里生成的，以什么形式生成的。
理想情况下，秘钥应该在隔离的硬件中生成，并且信息应该用有信誉的算法进行加密。要避免的一个弱的例子是数据加密标准，即DES，它今天被认为是坏的。留在明文中的秘钥——特别是在内存、磁盘上，或在这两个地方之间的中间地带，即“交换”--是一个主要的安全风险。一般来说，秘钥材料不应该离开它所产生的硬件，也不应该逃到其他人可以访问的网络上。(也就是说，除非秘钥材料是加密的，在这种情况下，加密秘钥也必须是安全的。)
今年夏天被黑客攻击的Slope钱包的密钥在生成后被以明文形式记录到外部服务器上。这种安全漏洞可能会在审计或代码的开放源码实施中浮现出来。缺乏透明度的钱包以闭源代码为特色，没有向公众提供第三方安全审计应该引起人们的警惕。
秘钥存储钱包的安全性
秘钥产生后，它们需要被藏在某个地方，绝不是明文，它应该总是加密的。但是，仅仅拥有储存秘钥的设备并不一定等同于秘钥所有权和控制权。必须考虑许多因素，如设备的供应链安全，设备的连接情况，以及设备与哪些其他组件互动。此外，每种存储方法在安全性、可访问性、可维护性和可用性之间都有自己的一套权衡。
下面，我们根据其相关的风险水平对最常见的类别进行细分。
风险较高：“热门”钱包
这个概念实际上与温度没有太大关系。当涉及到关键的存储选项时，如果一个钱包连接到互联网，就被认为是“热”的。另一方面，如果一个钱包是离线和隔离的，则被认为是“冷”钱包。在其他条件相同的情况下，冷钱包比热钱包更安全——但它们也更难访问和使用。一个连接到任何网络的钱包更容易受到黑客攻击，因为它允许攻击者有更多机会进入发现和利用漏洞。
热钱包可以有几种形式。
连接的软件：在线数据库、电话或网络服务器应用内存、浏览器扩展
这些是风险最大的选项。在这里，钱包软件，无论是否托管，都可以直接接触到秘钥——所有这些都是在与外部互联网连接的情况下。秘钥最好是加密的，用于加密的另一组秘钥应该存储在一个专门的秘钥管理系统中，具有高度限制的访问控制，如操作系统秘钥链或云秘钥管理系统。
对于基于软件的热钱包，将密钥管理和授权与软件组件的其他部分隔离是至关重要的。在记录、错误管理和内存管理方面可能会出现问题，所有这些都会错误地泄漏密码、加密密钥、签名密钥或其他敏感的加密材料。当这种情况发生时，干扰者可以通过连接的应用程序或网络服务器、侧渠道攻击或内部威胁获得未经授权的访问。
无论一项服务如何标榜自己，如果签署密钥在任何时候都没有在在线系统的内存中加密，那么该模型应该被视为一个热的软件钱包。(即使这些钥匙后来被储存在安全的飞地中)。
连接的硬件：特殊用途的设备、移动安全飞地、在线硬件安全模块。连接的硬件通常被认为比连接的软件风险小，但它仍然不如冷存储安全。在连接的硬件中，密钥只在特殊用途的硬件设备中产生和存在。然后这些设备可以连接到内部或公共网络。这种设备通常承担着与钥匙管理有关的多种责任，包括钥匙生成、签署和存储的安全性。
连接的硬件有几个种类。有一些硬件钱包，如Trezor和Ledger设备，稍微复杂的加密货币用户通常使用这些设备。(更多的人应该使用这些设备，因为它们比单独使用连接软件要安全得多）。还有硬件安全模块，即HSM，通常用于更传统的商业环境，如处理敏感数据的环境，如信用卡支付。
设备只有在生产和配置它们的供应链中才是安全的。当考虑连接的硬件时，问问自己。设备或固件在进入你手中之前被篡改的可能性有多大？为了减少这种风险，最好是直接从可信的供应商那里购买设备。让他们直接从源头发货。确保包装没有被破坏、没有裂缝、撕裂、破损的封条等。这可能表明在传输过程中被篡改。在使用前验证固件版本和配置也是明智之举。这样做的步骤因硬件而异，但都应该提供说明。
当然，总有一种可能性，即硬件钱包后来被盗或被未经授权的一方访问。考虑到这些威胁，确保硬件钱包也有安全的访问控制层是很重要的——保障措施确保他们不只是盲目地签署任何和所有交易。控制措施可以包括密码要求，提示要求交易的每一步都有明确的许可，以及描述交易实际操作的纯英文摘要。此外，大多数硬件钱包支持私钥加密，也被称为“密钥包装”。甚至更好的是，安全的钱包将不允许以原始明文的形式导出密钥，即使人们希望它们是这样。
这是真正保护加密货币资产所需的安全水平。
风险较小：“冷”钱包
更少的热量，更低的风险。在其他条件相同的情况下，冷钱包通常被认为比热钱包更安全，尽管它们通常也不太可用。冷钱包通常被称为“airgapped”钱包，意味着它们与任何内部或公共网络都没有连接。
在这种情况下，孤独是一种美德。Airgapping包括实施严格的物理隔离和授权措施。这些措施可以包括使用法拉第笼、生物识别访问、运动传感器和SCIFs，即敏感分类信息设施。
让我们更详细地审查一些冷钱包选项。
Airgrapped软件：离线服务器应用由于攻击者可以在任何时候偷窃或将机器带到网上，所以冷钱包的设计应该具有安全系统，即使它们被带到网上也能保持。秘钥应该通过标准的方法，如Shamir'sSecretSharing或Multi-PartyComputation，被分割成秘钥碎片，需要将碎片重新连接起来才能使用。强烈建议使用特殊用途的硬件，如HSM，而不是连接的软件，因为它们通常提供更多的控制。
Airgrapped硬件：离线硬件钱包，离线硬件安全模块。这种解决方案被认为是最安全的。与前一类相似，人们应该假定硬件可以被盗并被带到网上。出于这个原因，对这些系统来说，包括正确实施的访问控制层再次很重要，正如前面讨论的那样。许多HSM供应商要求在访问钥匙之前，必须有一个法定的物理智能卡凑在一起才可以解锁。即使设备没有显示屏幕，它也应该为用户提供某种方式来验证交易的细节。
由于冷钱包或airgapped钱包是最安全的一类，大公司管理的大多数资金都以这种方式存储。主要的散户服务，如Coinbase、Gemini、Kraken和其他，以及为机构用户提供的服务，如Anchorage，都是这样做的。许多这些玩家选择以备份和恢复的形式拥有另一道防线，以防万一他们失去访问权，或机器被损坏、偷窃或破坏。
备份和恢复
签名秘钥在加密后应始终进行备份。关键是要有加密的签名秘钥和密钥包装的冗余度。备份签名秘钥的方法各不相同，但人们应始终倾向于硬件原生解决方案。
对于硬件钱包来说，备份通常涉及一个12个字的明文种子短语，私钥就来自于此。这个种子短语应该以非数字的方式存储，并以最安全的方式。这个短语可以被分割成若干部分，在地理上分布，以防止整个秘密被轻易破坏。(人们有时会参照《哈利-波特》中黑暗巫师有效用于“备份”灵魂的虚构的角斗士来解释这种方法)。
许多HSM本身就可以处理与备份和恢复相关的一些挑战。标准的HSM有机制可以导出默认情况下带有访问控制的加密的密钥。如果访问控制得到满足，秘钥就可以被导入其他HSM。有用的是，HSM队列也可以用一个共同的加密密钥进行配置，该密钥来自于一个法定的智能卡。以这种方式将硬件与密钥材料解耦有助于避免单点故障。
最后，需要解决人为因素。恢复机制应该能够承受参与账户管理操作的任何个人暂时或永久的不可用。个人应确保为近亲属或其他受信任方提供在死亡或其他紧急情况下恢复秘钥的方法。同时，团体操作应该定义一个法定人数，比如说3人中的2人或5人中的3人，这样可以在生活事件、旅行、疾病或事故中合理地运作。
密钥使用的钱包安全
在密钥生成和存储之后，它们可以被用来创建授权交易的数字签名。混合中的软件和硬件组件越多，风险就越大。为了减少风险，钱包应该遵守以下授权和认证的准则。
相信，但要验证钱包应该需要认证。换句话说，他们应该验证用户是他们所说的人，并且只有授权方可以访问钱包的内容。这里最常见的保障措施是PIN码或口令。一如既往，这些密码应该足够长和复杂以达到最大的效果。更高级的认证形式可以包括生物识别或基于公钥加密的批准，如来自其他多个安全设备的加密签名。
不要推出你自己的加密钱包。钱包应该使用成熟的密码学库。做一些研究，以确保它们被审计和安全，从而避免密钥材料的泄漏或私人密钥的完全丢失。使问题复杂化的是，即使是受信任的库也可能有不安全的接口，最近像Ed25519库就是如此。要小心了!
非授权码的重复使用一个经过充分研究的密钥使用陷阱是某些加密签名参数的无意重复使用。一些签名方案可能需要一个nonce，意思是“使用一次的数字”，一个任意的数字，只在系统中使用一次。EllipticCurve数字签名算法就是这样的一个签名方案。如果一个nonce在ECDSA中被重复使用，就会导致密钥被破坏。其他各种算法不受影响，所以，像往常一样，确保正在使用完善的加密库。(某些加密库通过散列交易数据来确保唯一的nonces，这些数据包括其他独特的数据，如账户nonces）。但这种攻击手段以前在Web3以外的高调黑客中被利用过，例如2010年的索尼PlayStation3黑客。
每种用途一个密钥另一个最佳做法是避免将一把钥匙重复用于一个以上的目的。例如，应该为加密和签名保留单独的秘钥。这遵循了“最小特权”的原则，也就是说，对任何资产、信息或操作的访问应该只限制在系统运行绝对需要的一方或代码上。当正确实施时，“最小特权”原则可以极大地限制成功攻击的爆炸半径。不同的密钥会根据其目的，对备份和访问管理有不同的要求。在Web3的背景下，最好的做法是在资产和钱包之间分离秘钥和种子短语，所以一个账户的破坏不会影响其他账户。
结论
秘钥所有权的保管或非保管性质并不像传统思维所认为的那样黑白分明。秘钥管理中涉及的许多活动部件使情况变得复杂——从秘钥生成到存储到使用。链条上的每件硬件或软件都会带来风险，甚至使所谓的非保管型钱包选项暴露在保管型危险中。
对于未来，我们期望做更多的开发工作，以确保钱包免受攻击，并减轻上面讨论的风险。需要改进的领域包括：
在移动和桌面操作系统中共享安全的开源密钥管理和交易签名库共享开源的交易审批框架具体来说，我们会特别期待看到共享和开源的发展：
密钥生成库，在不同的存储后端实现一流的安全性。用于移动和桌面操作系统的密钥管理和交易签名库实施强因素验证的交易审批流程框架，如生物识别、基于PKI的审批、授权恢复等。上述清单并非详尽无遗，但它是一个很好的起点。所有这一切都意味着，情况比“不是你的秘钥，就不是你的加密货币”的口号所显示的要复杂。鉴于从生成和存储到使用的许多相互作用的部分和阶段，秘钥的拥有是一个棘手的问题。
如果你已经在做一个解决上述问题的项目，或者有兴趣这样做，请联系我们我们期待着在这些方面取得更多进展。
责编：Lynn
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。