API/RSS

Social

听a16z讲安全：钱包的「非托管」谬论

22-10-17 16:16

阅读本文需 18 分钟

AI 总结

看总结

原文标题：《Wallet Security: The「Non-Custodial」Fallacy》

原文作者：Nassim Eddequiouaq、Riyaz Faizullabhoy，a16z

原文编译：Katie 辜，Odaily 星球日报

个人对自己的私钥（和加密资产）有直接和唯一的控制权（和所有权）——坚持这种理念的加密钱包被称为「非托管」钱包，这意味着外部无法访问密钥。

直到一系列「非托管」钱包黑客事件——9 月 Wintermute 私钥遭「暴力破解」损失 1.6 亿美元，8 月侵入超过 8000 个账户的 Slope 钱包黑客，2020 年盗取超过 200 万美元 IOTA 的 Trinity 钱包黑客，2017 年窃取 15 万 ETH 的 Parity 钱包黑客，以及各种硬件钱包漏洞，模糊了托管和非托管钱包之间的安全界限。在此类案件中，受害者认为自己使用的是一个非托管钱包，但发现私钥竟然被盗。

事实上，非托管钱包并不能真正让用户完全控制自己的密钥，因为钱包通常是由他人的软硬件创建和运行的。用户在不断地信任第三方产品。这些产品集成或使用着区块链命令行接口、钱包软件和设备、中心化平台、智能合约代码、去中心化应用程序，而每一个接触点都增加了风险。所有这些连接点加起来粉碎了人们对「非托管」概念的美好幻想。

「非托管」实际上可能涉及许多托管元素。

一般来说，密钥管理（钱包安全的基础）可以分为三个方向：

1.密钥生成（创建加密密钥）；

2.密钥存储（保护静态的密钥）；

3.密钥使用（使用密钥授权）。

每个方向都有独特的风险点。

本文将介绍加密钱包安全和托管平台的特征和缺陷，涵盖未来最需要关注和发展的领域，旨在帮助 Web3 用户更好地理解以非托管方式保护加密资产的复杂性。此外，我们也想帮助工程师识别和避免钱包开发中的常见故障点，借助我们多年来在 Docker、Anchorage、Facebook 和 a16z 加密系统中的综合经验，帮助用户和项目方避免安全事故。

密钥生成

密钥生成步骤的安全至关重要。在这个环节，有三个首要问题需要牢记：使用可靠的代码、正确地实现代码和安全地处理输出。

一些钱包提供商在他们的官方网站或 Github 存储库上发布的审计报告。自己做调查，试着确定钱包背后是否有信誉良好的公司。如果信息稀少，那么重要的用户和开发人员的活动可能会是参考指标。

遵循这些指导方针来减少风险。如果你的钱包没有通过以下检查，赶紧跑吧。

不使用没有经过足够长时间的检验的钱包

组成钱包的代码应该有良好的声誉。选择编写得很差的软件，或者尝试开发自己的替代方案可能会导致诸如密钥泄漏或向未授权方透露机密信息等「灾难事件」的发生。

使用有多重保险的钱包

即使代码使用信誉良好的密码库，也必须被正确集成。经过审核的软件通常会默认设置正确的参数，但在执行过程中可能会出现漏洞。对于某些密钥生成过程，例如许多多方计算（MPC）算法，其中必须生成和协调许多单独的密钥——或密钥碎片，密钥片段，钱包应该遵循算法指定的协议。该算法可能还需要进行多轮计算和刷新密钥，钱包必须正确集成这些密钥，才能维护资金的安全。

使用能「保守秘密」的钱包

密钥生成过程的最后阶段涉及到软件的实际操作和输出。注意密钥是在哪里生成的以及以什么形式生成的。理想情况下，密钥应该在独立的硬件中生成，信息应该使用可靠的算法进行加密。

今年夏天遭到黑客攻击的 Slope 钱包的密钥生成后，以明文形式登录到外部服务器。这种安全漏洞可能出现在代码的审计或开源实现中。缺乏透明度的钱包——以封闭的源代码为特征，对公众没有可用的第三方安全审计应该引起警觉。

密钥存储

密钥生成后，它们需要被隐藏在某个地方（不以明文形式，永远加密）。但是，仅仅拥有存储密钥的设备并不一定等同于密钥的所有权和控制权。必须考虑许多因素，如设备的供应链安全、设备的连接方式以及设备与哪些其他组件交互。此外，每种存储方法在安全性、可访问性、可维护性和可用性之间都有自己的权衡。

下面，我们根据相关的所知的风险水平对最常见的钱包安全类别进行了分类。

高风险：热钱包

在其他条件相同的情况下，冷钱包比热钱包更安全，但它们也更难用。连接到任何网络的钱包都更容易被黑客攻击，因为它让攻击者有更多机会发现和利用漏洞。

热钱包联网有两种形式：

· 连接软件：在线数据库或 Web 服务器应用程序内存、浏览器扩展

这些风险最高。因为钱包软件不管是否托管，都可以直接访问密钥——所有这些都与外部互联网相连。理想情况下，密钥应该是加密的，而用于加密它们的另一组密钥应该存储在专用的密钥管理系统（KMS）中，该系统具有高度限制的访问控制，如操作系统密钥链或云密钥管理系统。

· 连接硬件：专用设备、移动安全区域、在线硬件安全模块（HSM）

连接硬件通常被认为比连接软件风险更低，但它仍然不如冷存储安全。在连接的硬件中，密钥只生成在专用硬件设备中。然后这些可以连接到内部或公共网络。这类设备通常承担与密钥管理相关的多重责任，包括密钥生成、签名和存储的安全性。

还有硬件钱包，如 Trezor 和 Ledger。也有硬件安全模块，或称 HSM，通常用于更传统的业务设置，如处理敏感数据处理（如信用卡支付）的设置。

设备的安全程度取决于生产和配置它们的供应链。当考虑连接硬件时，最好直接从可信的供应商那里购买设备。直接从源头运过来，确保包裹看起来没有损坏。也可以在使用之前验证固件版本和配置。

当然，硬件钱包以后总是有可能被盗或被未经授权的一方访问。鉴于这些威胁，重要的是要确保硬件钱包也有安全的访问控制层——安全措施确保它们不会盲目地签署任何和所有的交易。控制可以包括密码要求、对交易的每一步要求明确许可的提示，以及描述交易实际操作的简单摘要。此外，大多数硬件钱包支持私钥加密，也称为「密钥包装」。

风险较小：冷钱包

在其他条件相同的情况下，冷钱包通常被认为比热钱包更安全，尽管它们通常也不太好用。冷钱包与任何内部或公共网络都没有连接。

让我们回顾一些冷钱包选项：

· 离线软件：离线服务器应用

因为攻击者可以在任何时候偷窃或使机器在线，冷钱包应该设计在线时的安全系统。与连接软件相比，强烈推荐特殊用途的硬件，如 HSM，因为它们通常提供更多的控制。

· 离线硬件：离线硬件钱包、离线硬件安全模块（HSM）

这种解决方案被认为是最安全的。与前面的类别类似，我们应该假设硬件可以被窃取并在线获取。因此，正如前面所讨论的，这些系统必须包含正确实现的访问控制层。许多 HSM 供应商要求在解锁密钥访问之前，必须有一定数量的物理智能卡聚集在一起。即使设备没有显示屏幕，它也应该为用户提供一些方法来验证交易的细节。

因为冷钱包或离线钱包是最安全的一类，所以大公司管理的大多数资金都以这种方式存储，如 Coinbase 、Gemini、Kraken 等，以及 Anchorage。这些玩家中的许多人还会选择另一道防线——备份和恢复，以防万一他们失去访问权限，或者机器损坏、被盗或被摧毁。

备份和恢复

签名密钥应该在加密后进行备份。加密签名密钥和密钥包装密钥的重复是至关重要的。备份签名密钥的方法各不相同，但应该始终选择硬件本机解决方案。

对于硬件钱包，备份通常涉及一个纯文本种子，从该短语派生出私钥。标准加密密钥具有可以导出密钥的机制，这些密钥在默认情况下使用访问控制进行加密。如果满足访问控制，则可以将密钥导入其他 HSM。大量的 HSM 还可以提供一个通用的加密密钥，该密钥来自于智能卡的法定数量。以这种方式将硬件与关键材料分离有助于避免单点故障。

最后，还要考虑人为因素。恢复机制应能够承受帐户管理业务中涉及的任何个人的临时或永久不可用的情况。个人应确保在发生停机或其他紧急情况时，提供收回密钥的方法。与此同时，群体运营应该确定一个人数，在突发事件发生时能继续运营。

密钥使用

在生成并存储密钥之后，可以使用它们创建授权交易的数字签名。软件和硬件的组合越多，风险就越大。为了降低风险，钱包应该遵守以下授权和身份验证指南。

可信任，但也要验证

钱包应该需要验证。换句话说，应该验证用户的身份，并且只有授权方才能访问钱包的内容。这里最常见的安全措施是 PIN 码或密码短语。更高级的身份验证形式可以包括生物识别或基于公钥加密的批准，例如来自多个其他安全设备的加密签名。

不要使用没有经过足够长时间的检验的钱包

钱包应该使用完善的密码学库。做一些调查，以确保它们被审计和安全，以避免密钥材料泄漏或完全丢失私钥。使问题更加复杂的是，即使是受信任的库也可能具有不安全的接口，正如最近这些 Ed25519 库的情况一样。

Nonce 重用

一个经过充分研究的密钥使用陷阱是某些加密签名参数的无意重用。有些签名方案可能需要一个一次性的意思，「只使用一次的数字」（一个任意的数字），意味着在一个系统中使用一次。因此，要确保正在使用完善的加密库。但这种攻击载体在 Web3 之外的高调黑客攻击中也曾被利用过，比如 2010 年的索尼 PlayStation 3 黑客攻击。

一密钥一用

另一个最佳实践经验是避免为多个目的重用同一密钥。例如，应该为加密和签名保留单独的密钥。这遵循了在妥协情况下的「最小特权」原则，这意味着对任何资产、信息或操作的访问应该仅限于对系统工作绝对需要的各方或代码。根据不同的用途，不同的密钥对备份和访问管理有不同的要求。在 Web3 生态中，最好的做法是在资产和钱包之间分离密钥和种子短语，这样一个帐户的泄露不会影响其他帐户。

总结

从生成到存储到使用的许多相互作用的部分和阶段，密钥的保管是一个棘手的问题。密钥所有权的托管或非托管性质并不像传统观念所认为的那样非黑即白。由于涉及到密钥管理的许多移动部分（从密钥生成到存储再到使用），情况变得复杂起来。这条链上的每一个硬件或软件都会引入风险，甚至会使原本不属于托管型钱包的选项暴露在托管型风险之下。

对于未来，我们希望做更多的开发工作来保护钱包免受攻击，并降低上面讨论的风险。有待改进的领域包括：

· 跨移动和桌面操作系统共享安全的开源密钥管理和交易签名库；

· 共享的开源交易审批框架。

还有共享和开源的开发：

· 在不同的存储后端（在磁盘上加密，安全硬件等）实现最佳的安全密钥生成库；

· 用于移动和桌面操作系统的密钥管理和交易签名库；

· 交易审批流程框架，实现专门验证，如生物识别、基于 PKI 的审批、授权恢复等。