CertiK独家分析：针对MPC钱包的防御特权攻击

ZenGo 是一个使用多方计算（MPC） 技术 的 安全 Web 3 钱包 。

最近，CertiK 的 SkyFall 团队对众多移动钱包进行了彻底的审计和研究，发现 ZenGo 的 MPC 解决方案提供了比普通移动钱包更强大的安全防御措施——ZenGo 的钱包用户，尤其是那些高价值的钱包用户可以防御来自高级攻击者的直接攻击：例如利用零日漏洞或高级恶意软件在用户设备上获得 root 权限。

该威胁是最新出现且仅被 CertiK 团队发现，因此 MPC 钱包 开发者 请务必注意攻击细节！

防御特权攻击者是具有挑战性的。我们在报告结果中提出了一个新的攻击方式，与针对 ZenGo 中的 MPC 方法攻击向量。于是我们立即向 ZenGo 报告了这个安全问题，同时 ZenGo 也迅速做出了回应并修复了该问题。

本文我们将深入探讨该发现的技术细节，并分享我们是如何与 ZenGo 合作以提高 MPC 钱包的整体安全性的。

基于我们对 ZenGo 安全设计的彻底审查和他们对问题的专业回应，CertiK 认为 ZenGo 可以被称为目前市场上安全度较高的钱包解决方案。

什么是 MPC？

多方计算（MPC），有时也被称为安全多方计算（SMPC），是密码学的一个领域。它允许多方联合签署交易，同时确保每一方的密钥不被泄露。

因为 MPC 技术可以在多方之间分配密钥从而消除任何单点故障，因此可以让用户更好地保护 Web 3 私钥，这种方法也通常被称为 "阈值签名"，目前已被许多 Web 3 托管人和钱包开发者采用以保护 Web 3 资产。其中，ZenGo 是最广为人知且使用率最高的 MPC 钱包开发商之一。

如下图所示，该钱包并不是由一个传统的私钥来控制签署交易，而是由多个私钥分片参与交易签署过程，并产生一个最终签名从而进行验证。

产生签名的普通 MPC 设计

通过本次研究，我们已认识到与 MPC 方法相关的挑战和潜在的安全风险对于 Web 3 资产保护的重要性。于是我们想要通过探索和解决这些挑战来更好地保护Web3用户。

因此我们可以想一下这个问题：与传统的加密钱包相比，为什么 MPC 钱包可以提供更高的安全性？它又是如何做到的？

ZenGo MPC 设计和安全保证

通过本次研究，我们已认识到与 MPC 方法相关的挑战和潜在的安全风险对于 Web 3 资产保护的重要性。于是我们想要通过探索和解决这些挑战来更好地保护Web3用户。

因此我们可以想一下这个问题：与传统的加密钱包相比，为什么 MPC 钱包可以提供更高的安全性？它又是如何做到的？

在评估了不同 Web 3 钱包的设计后，我们研究了 MPC 的 Web 3 钱包——我们评估了市场上最受推崇的 MPC 钱包之一，同时也是头部的自我托管 MPC 钱包——ZenGo。

本次评估我们采用了与之前研究概述中相同的威胁模型：“如果你的设备被植入了恶意软件，那么该钱包还能保护你的资产吗？”

ZenGo 安全架构概述

如上图所示，ZenGo 钱包具备独特的安全设计，安全架构和恢复过程比传统的钱包更富有层次。ZenGo 提供的安全功能包括但不限于：

双方签名方案：ZenGo 的 MPC 设计实现了双方签名方案。每个用户在生成交易签名时都涉及两个密钥分片：一个存储在 ZenGo 的服务器上（主密钥①），另一个存储在用户的设备上（主密钥②）。ZenGo 和用户均不知道对方持有的密钥是什么。

基于 TEE 的保护：此外，为了防止 "中间人 "和 “APP 劫持"的攻击，ZenGo 应用程序使用了 TEE（可信执行环境）解决方案，并用 TEE 专用密钥签署 HTTPS 的通信内容来请求相关 API。这个基于 TEE 的设备密钥是在用户设置设备时在 TEE 内产生的，即使是操作系统本身也无法提取。

有了这些安全功能，攻击者就不能再从内存或存储文件中窃取用户的私钥并控制 ZenGo 用户的资产。ZenGo 还利用 TEE 来保护服务器和客户端之间的互动不能够被篡改。这也意味着“中间人”和 "APP 劫持"攻击被有效阻止和防御了。

我们的审计证实，ZenGo 确实有一个安全的设计和实现可以抵御这些攻击，并且这已是我们所接触过的被审计钱包中具备最高安全水准的设计。

ZenGo 的安全设计和实现成功地防御了包括来自特权的攻击及上述攻击。然而处理所有类型的特权攻击也并不是易事，特别是考虑到攻击者可以读取（以及在某些情况下写入）任意内存。

通过审计整个钱包，我们能够发现 ZenGo 中的一个实现问题那就是：该钱包允许我们作为特权攻击者从而绕过某些保护。

不过在讨论细节之前，让我们先回顾一下 ZenGo 钱包的安全机制。

ZenGo 钱包的安全做法

通过本次研究，我们已认识到与 MPC 方法相关的挑战和潜在的安全风险对于 Web 3 资产保护的重要性。于是我们想要通过探索和解决这些挑战来更好地保护Web3用户。

因此我们可以想一下这个问题：与传统的加密钱包相比，为什么 MPC 钱包可以提供更高的安全性？它又是如何做到的？

一个经典的 Web 3 钱包只需要一个私钥。然而用户总是有一定可能会透露私钥或助记词的。因此他们可能会丢失私钥，然后眼睁睁看着攻击者占有资产。

MPC 钱包的工作方式则不同。该钱包没有单一的私钥，用户现在只持有一份私钥分片，对其余的私钥分片一无所知。从这个角度看，攻击者即使获得了用户那一份的个人密钥，也不能直接转移资金。而为了进一步保护用户，ZenGo 使用了多种手段来加强他们的安全设计：不仅仅是上述的双方签名方案和基于 TEE 的设备保护，还有基于面部扫描的生物识别认证及额外密钥加密等。

用户注册和用户账号恢复过程中的保护措施

在用户注册和账号恢复过程中，ZenGo 采用了以下保护措施来保护用户资产。

用户识别保护： 双方签名方案要求只有当用户与另一方（ZenGo 的设定为服务器方）交互，才能动用他们的资金。为了能够识别用户和存储在服务器上的相关密钥份额，ZenGo 需要用户的电子邮件以便注册账户。

为了避免电子邮件被黑，ZenGo 使用了面部扫描技术（FaceTec 的 Zoom），将生物识别信息与用户账户绑定。在注册与电子邮件验证后的账号恢复过程中，用户需要“刷脸”来进行认证。

应用程序-服务器通信保护： 为了确保 ZenGo 服务器与合法用户的设备进行互动，ZenGo 在注册和账号恢复过程中在 TEE 环境中生成并注册了一个非对称密钥。ZenGo 应用程序和服务器之间的所有交互都需要由这个特定的密钥签署。因为它受到硬件支持的安全解决方案的保护，因此攻击者不能直接读取这个密钥，而该密钥也很难被滥用。

ZenGo 用户注册和账号恢复过程

用户密钥共享保护： 让用户存储和备份其密钥分片是有风险的，因为这或将危及到 ZenGo 提供的所有安全措施。而为了解决这个安全问题，ZenGo 在注册过程中生成了一个加密密钥。加密密钥对用户的密钥共享进行加密，并将密码文本存储在其服务器上。

但是，加密密钥不与 ZenGo 共享，而是强制与用户的 Google Drive 或 iCloud 进行同步。只有在用户通过电子邮件验证和基于服务器的生物识别认证后，才能将加密的密钥共享并进一步解密。其中基于服务器的生物识别认证（FaceTec 人脸识别）几乎不可能被常规的2D/3D人脸重建“蒙骗”。

交易签名的生成

ZenGo 的交易过程

为了签署一项交易，ZenGo 应用程序与 ZenGo 服务器进行了一系列的交互。在交互过程中，ZenGo 使用其开源的双方签名解决方案和用户密钥分片来生成双方签名。然后，ZenGo 服务器再进一步完成签名并广播交易。这个过程中的所有请求都有时间戳和 TEE 中的签名以保持信息的完整性和不可重放性。

ZenGo MPC 设计中的问题发现

正如我们之前所讨论的，ZenGo 的安全设计中涉及许多加密密钥，每一个密钥都有不同的职责。在下面的表格中，我们显示了 ZenGo 使用了哪些密钥以及它们是如何被保护的。

通过这个表格，我们可以看到，在客户端有三个密钥被使用：主密钥②，设备密钥和加密密钥。攻击者需要同时获得主密钥②和设备密钥，以便与 ZenGo 服务器互动，窃取用户资金。

正如前面交易细节部分所介绍的，主密钥②在内存中作为文本参与双方签名的生成，它允许攻击者读取进程内存并提取主密钥②。而作为一种一定程度上的解决方案，所有对 ZenGo 服务器的交易请求都需要由设备密钥签署，而设备密钥是不能被读取或提取的。这个过程是在 TEE 中完成的，攻击者无法控制。

然而，尽管 ZenGo 的安全设计考虑到了许多方面，CertiK 的 SkyFall 团队仍然在其中发现了一个漏洞。在对 ZenGo 应用程序中所有 API 进行细节审计后，我们注意到某些 API 允许攻击者欺骗 ZenGo 服务器，并轻松生成一个新的设备密钥，以便在其他设备上使用。

这种由设备密钥注册的 API 缺乏必要的安全保护措施：攻击者可以在其他设备上生成一个新的 NIST P-256 椭圆曲线密钥，然后攻击者可以利用设备密钥注册 API，并注册新生成的密钥对，假装新的用户设备并请求交易。

我们将这种攻击命名为设备 分叉 攻击。

对 ZenGo 钱包的设备分叉攻击

如上文所述，攻击者需要拥有 ZenGo 用户的主密钥②和有效的设备密钥来窃取其资产。

主密钥②：主密钥②是一个固定的密钥，在内存中作为明文使用，以便参与双方的签名过程。由于双方签名算法的复杂性和独特性，这个过程不能在 TEE 中完成。因此，一个有特权权限的攻击者可以简单地转储进程内存或劫持某些系统 API 来提取主密钥②。下方截图显示了我们在 iOS 平台上能够提取到的主密钥②。

设备密钥：在注册或账号恢复过程中，TEE 中的用户设备上会生成一个有效的设备密钥作为对前述明文提取威胁的解决方案。设备密钥并不能被有特权权限的攻击者读取，然而，攻击者可以使用相同的设备密钥注册 API，从而来注册另一对密钥并使用它。

设备密钥注册 API 只有一个非常基础的认证机制：攻击者可以使用一个普通的明文本地存储的 JWT 令牌和提取到的主密钥②进行 API 身份认证。根据设计，该 API 涉及到的服务器代码也应该经过 Face tec 生物识别认证。然而在实践中，由于逻辑缺陷，代码未能执行此环节。

在我们的模拟攻击中，我们模拟了一个具备特权权限的攻击者，并持续监控受害者的设备。一旦 ZenGo 应用程序被启动，我们便立即从内存中提取主密钥②，并从本地数据库中读取 API 令牌。而这些信息足以让攻击者盗取用户的全部资金！

一旦有了 API 令牌，我们就会生成一个新的设备密钥，并调用设备密钥注册 API 从而在 ZenGo 服务器上注册设备密钥。随后，我们构建了所有的 API 请求，与 ZenGo 服务器交互来发起交易。对于 MPC 钱包来说，生成双方签名是一个非常独特并且复杂的过程。不过好在 ZenGo 的开发过程始终秉承着开源精神，我们才能够编译官方 ZenGo 应用程序中使用的双方签名库并在本地运行。

上图中展示了我们是如何提取主密钥②并代表受害者注册一个新的设备密钥的。随后我们利用这两个密钥向“攻击者的账户”发送了 0.00222 ETH 。这整个过程只用了几秒钟，并且受害者也会完全意识不到。

为了解决这个问题，ZenGo 在服务器端为设备注册实施了 FaceTec 生物识别认证。服务器 API 级别的解决措施消除了这种攻击的可能性，且不需要更新客户端代码。

总结

在 CertiK 对 ZenGo 的评估中，我们彻底检查并审计了其为保护用户资产所采取的所有安全措施。这些措施包括双方签名方案、基于 TEE 的设备保护以及用来注册和恢复账号的生物识别。

尽管 ZenGo 有着较高的安全意识，并采取了诸多措施用来提高自己的安全性，CertiK 还是在 ZenGo 的实施中发现了一个关键的可被利用的 API 访问认证风险。该漏洞可以让持有特权的攻击者绕过现有的安全措施，并在用户的设备被破坏时窃取用户的资金。

ZenGo 及时解决了该问题并部署了一个补丁，CeritK 随后也进行了彻底的进一步审计并确定该补丁已修复报告中提到的风险。

随着补丁的部署，我们相信 ZenGo 在日后可以有效地预防特权用户非法访问用户资金。防御特权攻击者是一项艰巨的任务，而 ZenGo 的安全实践向我们展示了全面保护用户的安全方法。该钱包的做法超过了目前市场上绝大多数常规钱包。

我们很荣幸能够与 ZenGo 合作，并很荣幸能够与 ZenGo 在保护 Web 3 用户安全方面做出共同努力并解决安全挑战。同时也感谢 ZenGo 对我们发现漏洞的及时回应与高效的漏洞补丁出台行动。

作为安全行业的从业者，我们很高兴看到一个顶级 Web 3 钱包公司如此重视安全，对用户和用户的资金具备如此高的责任心。希望在未来的安全道路中，我们可为更多项目提升安全性，为其用户赋予“安心”。