硬件钱包上的达摩克利斯之剑：隐秘的中间人威胁

2025年6月16日 17:49

作者：RevanZhang 来源：Medium

近年来，硬件钱包在Blockchain行业中，被视为相对安全的私钥存储方式之一。私钥生成后，会存储在硬件钱包的安全芯片（SecureElement）中，仅用于对外部传入的信息进行签名。这种无法联网的封闭式硬件设计，配合禁止导出私钥的软件机制，构建起了强大的保护屏障。

然而，这种安全架构也有其“软肋”—— 硬件钱包高度依赖外部客户端软件和通信通道。一旦这些外围环节被篡改，攻击者便可实施“中间人攻击”（MITM），在用户毫无察觉的情况下替换信息，造成资产损失。什么是中间人攻击

中间人攻击是指攻击者秘密地介入通信双方之间，拦截、篡改或伪造双方的通信内容，而通信双方误以为他们在直接交互。

这种攻击常见于网络监听、数据伪造、身份盗用和地址替换等场景。在加密资产领域尤其危险，因为攻击者只需替换一个地址，就可能造成巨大的资产损失。

举个生活中的例子：你寄给朋友一封重要信件。一个“坏邮差”在途中截获，将信件内容进行替换，然后重新封好寄出。朋友收到信件后，此时获取的信息因为被邮差替换，已经不再准确了。

在这个例子中，邮差扮演了中间人的角色，通过替换信件内容实施了中间人攻击。

在Blockchain系统中，由于大多数公链转账只需要收款地址，而不需要额外的诸如姓名的验证。这种场景的中间人攻击更容易得手，且造成的损失往往更大，更难追回。

硬件钱包通信流程：看不见的邮差

市面上主流的硬件钱包大致采用四种通信方式：

USB：最常见且稳定，通过数据线实现双向传输

蓝牙：低功耗蓝牙BLE，常用于移动端

二维码：airgap，较为新型的方式，物理隔离，通过互相扫码达到通信的目的

NFC：近场通信，暂时较少使用

其中，USB与蓝牙最为常见。无论采用哪种方式，通信流程大致相同：

“钱包端”发起连接，例如浏览器插件钱包或者手机APP钱包

向“硬件钱包”发送请求，例如获取硬件内部的地址，发起签名等等

请求经上述“通信通道”送达硬件设备

设备完成处理并返回响应

“钱包端”接收并显示结果

尽管硬件钱包自身是安全的“保险库”，但通信过程却依赖客户端、通信通道这一“邮差链条”。一旦“邮差”遭到劫持或者作恶，传递的数据信息就可能早已被调包。

这正是“达摩克利斯之剑”悬于硬件钱包之上的隐秘威胁——中间人攻击。实战案例：基于恶意脚本的中间人攻击声明

所有代码和操作均发生在 2023年9月，距本文发布时间（2025年6月）已超过20个月。

所有演示基于当时公开版本的官方软件，具体版本信息已在文中注明。

所涉及的攻击方式，已于当时向相关团队披露并确认。

本文所有内容仅供学习与安全研究之用，观点仅代表作者本人。

本文不对由此引发的任何行为或后果承担责任。Trezor通信的基本流程

Trezor通过USB连接Metamask浏览器钱包时可选择通过TrezorBridge进行通信，TrezorBridge的基本流程

安装软件之后，会在用户的电脑中，在本地21325端口启动HTTP服务器

Metamask连接Trezor硬件钱包时，会通过弹出 //connect.trezor.io 网页来加载JSSDK

Trezor的SDK会尝试的将基于protobuf的序列化数据，发送向这个本地服务器

TrezorBridge接收到数据后，通过lib-usb库查找本地满足条件的PIDVIDTrezor设备并传输数据

当检测到本地已安装TrezorBridge时，所有通过 //connect.trezor.io 网页，也就是TrezorSDK的序列化数据都会经由本地TrezorBridge服务器转发给设备，而不使用WebUSB。TrezorBridge的基本信息

TrezorBridge使用 Golang 开发，当前用户版本为v2.0.27。

从GitHub开源仓库可见，v2.0.27使用 xgo 进行跨平台编译，从而生成MacOS，Windows和linux的安装包。

以MacOS为例，安装时会在 /Applications/Utilities/TREZOR\Bridge/trezord 目录创建 trezord 服务器二进制文件，并在用户本地创建 com.bitcointrezor.trezorBridge.trezord.plist 文件，通过 KeepAlive 实现开机自启和进程守护。

SDK读取公钥阶段的 hexbodyStr 和 hexres 在多次调用时，对同一设备的不同时间操作参数和返回结果完全相同。通过日志筛选，发现Metamask读取ETH地址时的 call 函数调用数据如下：

根据日志比对，

003700000000 和 000b0000001f08ac8080800808bc80808008088080808008080008002207426974636f696e 等数据，均为发送、接收报文的序列化结果。

经过重放测试，在信息构建过程中并没有时间戳等参数，可以非常简单轻易的模拟攻击手法，即针对部分发送报文，硬编码返回的结果，进行结果替换：

在这个例子中，我们针对性的将数据进行了替换，当接收到SDK获取ETH公钥的请求时，不再使用硬件返回的结果，而是直接使用上述代码中硬编码的结果。重新通过文档编译后制作二进制文件，同时制作守护进程等攻击必要组件。

准备工作完成后，当用户不慎安装和运行恶意软件后。每当用户使用Metamask连接Trezor并且发送数据时，通过bridge通信的数据不再是硬件读取出来的信息，而是上述代码中硬编码的序列化数据，再基于业务SDK的反序列化，读取地址的信息即替换成功。完整的攻击如上述视频所示。与团队的沟通

整理好问题及操作之后，我第一时间已与Metamask和Trezor团队进行了沟通，以下是所有沟通信息及邮件信息

Metamask沟通记录：//hackerone.com/reports/2166893

Trezor邮件沟通信息：

盲签的威胁，可能比我们想象中的更大

按照这种攻击手段和攻击方式，我们可以得出结论：所有硬件非确定性的信息，都是理论上不安全的。

所有的盲签同理，虽然盲签硬件上有确认，但是这个确认的信息对于用户来说并不可读，所以他也满足硬件非确定性的信息，无法确保不被中间人攻击。

safe多签钱包的案件就是一个典型，钱包构造的签名信息被服务器恶意javascript代码替换，同时因为ledger钱包是盲签，导致这一次攻击的发生。通信通道的中间人攻击，方式众多

除了用户本地有恶意软件以外，一些钱包的通信和构建流程可能涉及到服务器（例如一些钱包encodeTx需要通过服务端进行构建）。这些都是潜在的攻击对象和被攻击点。

通信通道当然还包括硬件层面，例如不安全的电脑摄像头外设，不安全的USB数据线等等。从物理层到应用层，在通信层面，所有环节都有被攻击的可能。主动提升安全意识，任重而道远

客户端到硬件钱包的完整通信，核心流程理论上是不需要联网的。所以即使有端到端的加密通信，也无法100%确保流程安全。

增加端到端的加密之后，对于真正的黑客来说，增加的只是逆向客户端，对通信信道的破解成本。而对于攻击本身，从来都不是难度的较量，而是黑客付出的成本和法律后果的考量。

同时，大部分Blockchain的产品团队，一般在面对这类中间人攻击的威胁时，会将这部分的优化放在整个迭代中处于低优先级，变相等于允许一部分中间人攻击的风险出现。如上面的团队沟通邮件，如Metamask的bugbounty界面，就将MITM中间人攻击排除在外：//hackerone.com/metamask。

所以对于用户来说，更需要主动我们自身提高防范意识。对于重要资产，即使是使用硬件钱包，也最好隔离电脑，不连接不可信的网络，不访问不可信的网页等等等等。写在最后

硬件钱包的“安全神话”并非来自单一设备本身，而是建立在整个生态系统的协作安全。

当我们忽视客户端的可信性、放松对通信通道的防护，那把“达摩克利斯之剑”便悄然悬于我们的资产之上。

真正的安全，从不止于硬件，而在于每一个你以为“无关紧要”的细节。

免责声明:硬件钱包上的达摩克利斯之剑：隐秘的中间人威胁文章转发自互联网，版权归其所有。
文章内容不代表本站立场和任何投资暗示。加密货币市场极其波动，风险很高，可能不适合所有投资者。在投资加密货币之前，请确保自己充分了解市场和投资的风险，并考虑自己的财务状况和风险承受能力。此外，请遵循您所在国家的法律法规，以及遵守交易所和钱包提供商的规定。对于任何因使用加密货币所造成的投资损失或其他损失，本站不承担任何责任。

南宫28

硬件钱包上的达摩克利斯之剑：隐秘的中间人威胁

元宇宙最新

元宇宙热门