钱包安全：‘非托管’的谬误

“不是你的密钥，就不是你的加密资产（not your keys, not your crypto）”这一常用表达传达了密码学密钥管理中纯粹主义者的哲学。在这种钱包安全模型中，只有个人（或通过“multisig”实现的多方团体）对其私钥拥有直接且唯一的控制权——因此，对其加密资产拥有真正的所有权。遵循这种强硬方法的加密钱包被称为“非托管（non-custodial）”钱包，这意味着外部方无法访问密钥。

然而，情况并非如此简单。这并非一蹴而就。一系列备受关注的“非托管”钱包黑客事件——包括8月份导致8000多个账户受损的Slope 钱包攻击，2020年导致200多万美元IOTA代币丢失的Trinity 钱包攻击，2017年允许攻击者窃取15万ETH的Parity 钱包攻击，以及各种硬件钱包漏洞的发现，以及其他事件——都削弱了托管钱包和非托管钱包之间的传统区别。在许多这些案例中，那些自认为正在使用非托管钱包的受害者发现攻击者能够劫持他们珍贵的密钥。这难道不是一个矛盾吗？

事实上，这个故事比一句口号所能表达的要复杂得多。非托管钱包并没有真正让用户完全控制他们的密钥。那是因为钱包通常是由别人的软件或硬件创建并通过其运行的。用户不断地将信任寄托于其他人、产品和计算机程序。他们接受使用区块链 command-line-interfaces、钱包软件和设备、中心化平台、智能合约代码、去中心化应用程序，以及介于两者之间的各种钱包连接集成。每一个接触点都增加了风险；所有这些相互关联的部分的总和打破了非托管钱包的幻想。

实际上，托管是非二元的。最初看起来是非托管的，实际上可能包含许多托管元素，而人们往往认为这些元素的可靠性是理所当然的。传统的二分法——托管与非托管——是一个错误的区分。

相反，最好以更细致入微的方式看待钱包。需要提出的关键问题是：我愿意接受多大的攻击面？在消除对第三方的信任方面，我愿意承担多少责任？通常，密钥管理——钱包安全的基础——可以分为三个领域，每个领域都有独特的暴露机会。子类别如下：

1. 密钥生成（创建加密密钥）
2. 密钥存储（保护静止状态的密钥）
3. 密钥使用（将密钥投入使用）

本概述旨在通过上述准则帮助 web3 用户更好地理解保护其资产所涉及的复杂性。此外，我们旨在帮助工程师识别并弥补钱包开发中常见的故障点。我们希望通过应用本指南——源于我们在 Docker、Anchorage、Facebook 和 a16z crypto 构建加密和安全系统多年的综合经验——将有助于人们避免安全事故，无论他们是与 web3 技术交互、参与其中还是构建它。

下文将介绍当前加密钱包安全和托管平台的常见功能和缺陷。我们还将讨论我们认为在未来数月和数年内需要最多关注和开发以提高用户 web3 体验安全性的领域。

密钥生成：钱包安全

任何关于钱包安全的讨论都必须从密钥生成开始，即创建加密密钥的过程。无论钱包被认为是托管还是非托管，密钥生成步骤的安全属性对于密钥此后的安全至关重要。在密钥生成过程中，需要牢记三个主要关注点：使用可靠的代码、正确实现代码以及安全处理输出。

如果你不是加密专家，可能很难验证所有以下因素是否都按规范进行。请查看你是否能查阅受信任的审计报告，一些钱包提供商会在其官方网站或 Github repositories 上发布。如果没有，请自行研究，尝试确定钱包背后是否有信誉良好的公司。如果信息稀缺，大量的用户和开发者活动可能是信誉的下一个指标。

请遵循以下指南以降低你的风险暴露。如果一个钱包未能通过以下检查，请远离！

• 使用不“自创加密技术”的钱包

密码学家有句俗语：“不要自创加密技术（don’t roll your own crypto）。”其核心思想类似于“不要重复发明轮子”这句格言。轮子本身已经很好，任何从头开始重建它的尝试都可能导致更糟糕的产品。加密技术也是如此，这是一门很难做到尽善尽美的科学。构成钱包的代码应该以运行良好而著称。选择编写不佳的软件——或者尝试从头开始开发自己的替代品——可能导致密钥泄露或向未经授权方透露秘密信息等事故。这正是Profanity 的 vanity address tool 最近被利用的漏洞背后的原因。最重要的是，应明确所讨论的钱包使用了经过审计且信誉良好的密钥生成库和流程。

• 使用反复检查的钱包

即使代码使用了信誉良好的密码学库，它仍然必须正确集成。经过审查的软件通常会默认设置正确的参数，但执行中可能存在漏洞。例如，需要强大的熵源，或称数学随机性，才能使待生成的密钥不可预测，从而更安全。对于某些密钥生成过程，例如许多 Multi-Party Computation (MPC) 算法，其中必须生成和协调许多单独的密钥——或称为分片、密钥片段——钱包应遵循算法规定的精确协议。该算法还可能需要多轮计算以及刷新密钥，钱包必须正确集成这些以维护资金安全。

• 使用能保密的钱包

密钥生成过程的最后阶段涉及软件的实际操作和输出。请注意密钥是在哪里生成的以及以何种形式生成的。

理想情况下，密钥应在隔离的硬件中生成，并且信息应使用信誉良好的算法加密。一个应避免的弱算法例子是 Data Encryption Standard (DES)，它今天被认为已失效。以 plaintext 形式保留的密钥——尤其是在内存中、硬盘上，或介于这两者之间被称为“swap”的中间区域——是一个重大的安全风险。一般来说，密钥材料不应离开其生成的硬件，也不应泄露到其他人可访问的网络上。（除非密钥材料被加密，在这种情况下，加密密钥也必须得到保护。）

今年夏天被攻击的 Slope 钱包的密钥，在生成后以 plaintext 形式记录到外部服务器。这是一种安全漏洞，本可以通过代码审计或开源实现来发现。缺乏透明度的钱包——包括闭源代码、不向公众提供第三方安全审计——应该引起警惕。

密钥存储：钱包安全

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

下面，我们根据其感知风险水平对最常见的类别进行分类。

较高风险：“热”钱包

这个概念实际上与温度关系不大。谈到密钥存储选项，如果钱包连接到互联网，则被认为是“热”的。另一方面，如果钱包处于离线和隔离状态，则被认为是“冷”的。在所有条件相同的情况下，冷钱包比热钱包更安全——但它们也更难访问和使用。连接到任何网络的钱包更容易受到黑客攻击，因为它给攻击者更多机会访问以发现和利用漏洞。

热钱包有几种形式。

• 连接的软件：在线数据库、手机或网络服务器应用程序内存、browser extensions

这些是风险最高的选项。在这里，无论钱包软件是否托管，它都直接访问密钥——同时连接到外部互联网。密钥理想情况下应该被加密，用于加密它们的其他密钥集应存储在一个具有高度受限访问控制的专用密钥管理系统（KMS）中，例如操作系统密钥链或云密钥管理系统。

对于基于软件的热钱包，将密钥管理和授权与其他软件组件隔离开来至关重要。日志记录、错误管理和内存管理（尤其是基于堆的，其中密钥可能未正确“清零”或擦除）都可能出现问题，这些问题都可能错误地泄露密码、加密密钥、签名密钥或其他敏感的加密材料。当这种情况发生时，入侵者可以通过连接的应用程序或网络服务器、side channel attacks 或内部威胁获得未经授权的访问。

无论服务如何自称，如果签名密钥在任何时候在在线系统的内存中是未加密的，那么该模型就应被视为热软件钱包。（即使密钥随后在 secure enclave 中存储。）

• 连接的硬件：专用设备、移动 secure enclaves、在线硬件安全模块 (HSM)

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

连接的硬件有多种形式。有硬件钱包，如 Trezor 和 Ledger 设备，更专业的加密用户通常使用它们。（更多的人应该使用这些设备，因为它们比单独使用连接的软件安全得多。）还有硬件安全模块 (HSMs)，它们常用于传统商业环境，例如处理敏感数据（如信用卡支付）的环境。

设备的安全性取决于生产和配置它们的供应链。在考虑连接的硬件时，问问自己：设备或固件在到达你手中之前被篡改的可能性有多大？为了降低这种风险，最好直接从受信任的供应商处购买设备。让它们直接从源头运送。确保包裹没有被损坏的迹象——例如没有撕裂、破损、封条损坏等——这可能表明在运输过程中被篡改。在使用前验证固件版本和配置也是明智之举。执行此操作的步骤因硬件而异，但所有设备都应提供说明。

当然，硬件钱包总是存在以后被盗或被未经授权方访问的可能性。鉴于这些威胁，确保硬件钱包也具有安全的访问控制层至关重要——这些保护措施确保它们不会盲目签署任何及所有交易。控制措施可以包括密码要求、为交易的每一步明确请求许可的提示，以及用通俗易懂的语言描述交易实际在做什么的摘要。此外，大多数硬件钱包支持私钥加密，也称为“key wrapping”。更好的是，安全的钱包不允许以原始 plaintext 形式导出密钥，即使有人希望这样做。

这是真正保护加密资产所需的安全级别。

较低风险：“冷”钱包

热度越低，风险越小。在所有条件相同的情况下，冷钱包通常被认为比热钱包更安全，尽管它们通常也更不便于使用。冷钱包通常被称为“airgapped”钱包，这意味着它们不连接到任何内部或公共网络。

在这种情况下，孤立是一种美德。Airgapping 涉及实施严格的物理隔离和授权措施。这些措施可以包括使用 Faraday cages（屏蔽无线信号的罩子）、生物识别访问（如指纹或虹膜扫描仪）、运动传感器（在未经授权使用时触发警报），以及 SCIFs，即 Sensitive Compartmented Information Facilities（用于处理机密信息的特殊区域）。

让我们更详细地回顾一些冷钱包选项。

• Airgrapped 软件：离线服务器应用程序

由于攻击者可以随时窃取或将机器上线，因此冷钱包应设计具有即使在上线时也能保持安全的系统。密钥应通过标准方法（例如 Shamir’s Secret Sharing 或 Multi-Party Computation）分成密钥分片，要求这些分片重新组合后才能使用。强烈建议使用专用硬件，例如 HSMs，而不是连接的软件，因为它们通常提供更多的控制。

• Airgrapped 硬件：离线硬件钱包、离线硬件安全模块 (HSM)

这个解决方案被认为是所有方案中最安全的。与上一个类别类似，应假设硬件可能被盗并上线。因此，这些系统再次强调需要包含正确实施的访问控制层，如前所述。许多 HSM 供应商要求多张实体智能卡汇集才能解锁密钥访问。即使设备没有显示屏，它也应该提供某种方式供用户验证交易详情。

因为冷钱包或 airgapped 钱包是安全级别最高的类别，所以大多数由大公司管理的资金都以这种方式存储。主要的零售服务，如 Coinbase、Gemini、Kraken 等，以及面向机构用户的 Anchorage 等服务都采用这种方式。这些公司中的许多都选择通过备份和恢复来增加一道防线，以防万一——天意不测——他们失去访问权限，或者机器损坏、被盗或销毁。

备份和恢复

签名密钥在加密后应始终进行备份。加密签名密钥和 key-wrapping keys 都必须具有冗余性。备份签名密钥的方法各不相同，但应始终首选硬件原生解决方案。

对于硬件钱包，备份通常涉及一个12个单词的 plaintext seed phrase，私钥从中派生。这个 seed phrase 应该以非数字方式（例如纸张、金属）存储，并以最安全的方式（家中的物理保险库、银行保险库内）存储。该短语可以分成几部分，进行地理分布式存储，以防止整个秘密被轻易泄露。（人们有时通过引用《哈利·波特》中黑巫师有效“备份”灵魂的虚构 horcruxes 来解释这种方法。）

许多 HSMs 原生处理与备份和恢复相关的一些挑战。标准的 HSMs 具有可以导出密钥的机制，这些密钥默认通过访问控制进行加密。如果访问控制得到满足，密钥就可以导入到其他 HSMs 中。有用的是，HSMs 集群也可以通过智能卡仲裁派生出一个共同的加密密钥进行配置。以这种方式将硬件与密钥材料解耦有助于避免单点故障。

最后，需要解决人为因素。恢复机制应能够承受参与账户管理操作的任何个人的暂时或永久不可用情况。个人应确保为近亲或受信任的第三方提供恢复密钥的方法，以防死亡或其他紧急情况。同时，团体操作应定义一个仲裁——例如，2-of-3 或 3-of-5——能够在发生生活事件、旅行、疾病或事故时合理地运行。

密钥使用：钱包安全

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

• 信任，但要验证

钱包应要求认证。换句话说，它们应该验证用户是否是他们声称的那个人，并且只有授权方才能访问钱包的内容。这里最常见的安全措施是 PIN codes 或密码。一如既往，这些措施应足够长且复杂——使用多种不同类型的字符——以达到最大效果。更高级的认证形式可以包括生物识别或基于公钥加密的批准，例如来自多个其他安全设备的加密签名。

• 不要自创加密技术（再次强调！）

钱包应使用成熟的密码学库。进行一些研究以确保它们经过审计且安全，从而避免密钥材料泄露或私钥完全丢失。使问题复杂化的是，即使是受信任的库也可能存在不安全的接口，最近 这些 Ed25519 库就出现了这种情况。请务必小心！

• nonce 重复使用

一个被深入研究的密钥使用陷阱是某些加密签名参数的意外重复使用。某些签名方案可能需要一个 nonce，意为“仅使用一次的数字”，一个任意的数字，顾名思义，在系统中仅使用一次。Elliptic Curve Digital Signature Algorithm (ECDSA) 就是这样一种签名方案。如果在 ECDSA 中重复使用 nonce，可能导致密钥泄露。各种其他算法不受此影响，因此，像往常一样，请确保使用成熟的密码学库。（某些密码学库通过哈希交易数据来确保唯一的 nonce，其中包含其他唯一数据，例如账户 nonce。）但这种攻击向量在 web3 之外的高知名度黑客事件中曾被利用，例如2010年 Sony PlayStation 3 攻击。

• 一键一用

另一个最佳实践是避免将一个密钥用于多种用途。例如，加密和签名应该使用不同的密钥。这遵循了 最小权限原则，即在发生泄露的情况下，对任何资产、信息或操作的访问应仅限于系统正常工作绝对需要的当事方或代码。最小权限原则如果得到正确实施，可以大幅限制成功攻击的爆炸半径。不同的密钥根据其用途，对备份和访问管理有不同的要求。在 web3 的背景下，将不同资产和钱包的密钥和 seed phrases 分开是一种最佳实践，这样即使一个账户被泄露也不会影响其他账户。

结论

密钥所有权的托管或非托管性质并非像传统观念认为的那样非黑即白。密钥管理涉及的诸多动态部分——从密钥生成到存储再到使用——使得情况复杂化。链上的每一个硬件或软件都会引入风险，使得即使是所谓的非托管钱包选项也暴露在托管式风险之下。

展望未来，我们期待在安全钱包以抵御攻击和减轻上述风险方面有更多的开发工作。改进领域包括：

• 跨移动和桌面操作系统的共享安全开源密钥管理和交易签名库
• 共享开源交易审批框架

具体来说，我们特别乐见共享和开源方面的开发：

• 密钥生成库，用于在不同存储后端（磁盘加密、安全硬件等）实现一流的安全性
• 移动和桌面操作系统的密钥管理和交易签名库
• 交易审批流程框架，实施强因子验证，例如生物识别、PKI-based 审批、授权恢复等。 上述列表并非详尽无遗，但它是一个很好的起点。所有这一切都表明，情况比“不是你的密钥，就不是你的加密资产”这句口号所显示的要复杂得多。鉴于从生成和存储到使用等诸多交互部分和阶段，密钥的持有是一个棘手的问题。 如果你已经在从事解决上述任何一个问题的项目，或者有兴趣这样做，请联系我们！我们期待在这些方面取得更多进展。 编辑：Robert Hackett，@rhhackett

• 原文链接： a16zcrypto.com/posts/art...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～