The Sword of Damocles Hanging Over Hardware Wallets

/Jul 2, 2025

Key Takeaways

Not Invincible 🛡️ Hardware wallets securely store keys offline, but their biggest vulnerability is communicating with external software (your computer or phone).
Beware of MITM Attacks 👨‍💻 An attacker can act as a "man-in-the-middle" to intercept and alter data, like swapping a receiving address, leading to irreversible loss of funds.
Proven Threat 😈 A real-world demo proved that malware could alter communication between a Trezor wallet and MetaMask, tricking the user with a fake address.
Core Issue: Lack of Verification 🔍 The attack works because some wallet apps don't require address confirmation on the hardware device itself. The risk of "blind signing" (approving unreadable data) is also a major concern.
Security is an Ecosystem 🔗 True security depends on the entire chain—the hardware, the software client, and the communication channel. A weakness in one compromises the whole system.
Always Verify on Device 👀 The golden rule: Trust only what you see on your hardware wallet's screen. Always double-check the address and transaction details on the physical device before you approve.

In recent years, hardware wallets have been regarded as one of the most secure ways to store private keys in the blockchain industry. Once generated, private keys are stored in the wallet’s secure element (SE), and are only used to sign incoming external data. This air-gapped hardware design, combined with software mechanisms that prohibit key export, builds a strong protective barrier.

However, this security architecture has its Achilles’ heel — hardware wallets rely heavily on external client software and communication channels. If these external components are compromised, an attacker can perform a man-in-the-middle (MITM) attack, replacing information without the user’s awareness, leading to asset loss.

What Is a Man-in-the-Middle Attack?

A man-in-the-middle attack occurs when an attacker secretly intercepts, alters, or forges messages between two parties who mistakenly believe they are communicating directly.

This type of attack is common in network eavesdropping, data forgery, identity theft, and address substitution. It is especially dangerous in the crypto space — an attacker only needs to substitute a receiving address to potentially cause irreversible loss of assets.

A real-world analogy: imagine you mail an important letter to a friend. A “malicious mailman” intercepts the letter, modifies its content, reseals it, and delivers it. Your friend receives it unaware that the message has been altered.

In this example, the mailman plays the role of the man-in-the-middle, manipulating the message during transmission.

In blockchain systems, since most public chains only require a recipient address for transfers (with no name verification), MITM attacks are easier to execute and typically result in more significant, unrecoverable losses.

Hardware Wallet Communication Flow: The Invisible Mailman

Mainstream hardware wallets typically use one of four communication methods:

USB: The most common and stable, using data cables for bidirectional transfer
Bluetooth: BLE, often used with mobile devices
QR Code (airgap): A newer method involving mutual scanning for physical isolation
NFC: Near-field communication, currently less common

Of these, USB and Bluetooth are the most prevalent. Regardless of the method, the flow is similar:

The “wallet client” (browser extension or mobile app) initiates a connection
It sends a request to the “hardware wallet” — e.g., to fetch an address or sign data
The request is delivered through a communication channel
The device processes and responds
The client receives and displays the result

Although the hardware wallet is a secure “vault,” the communication relies on a chain of intermediaries — the client software and transmission channel — like an unseen mailman. If the mailman is hijacked or turns rogue, the data could be tampered with along the way.

This is the hidden threat — the “Sword of Damocles” hanging over hardware wallets: the man-in-the-middle attack.

A Real-World Example: MITM via Malicious Script

Disclaimer

All code and tests were conducted in September 2023, over 20 months prior to this article (June 2025).
The demo uses publicly available software versions; version numbers are noted.
The attack was disclosed and acknowledged by relevant teams.
This article is for educational and security research purposes only.
The author assumes no responsibility for consequences resulting from this information.

How Trezor Communicates

When Trezor connects to MetaMask via USB, it often communicates using Trezor Bridge:

The bridge runs a local HTTP server on port 21325 after installation
MetaMask loads the https://connect.trezor.io JS SDK
The SDK sends protobuf-encoded data to the local bridge server
The bridge then locates the Trezor device using libusb and transmits data

If the local Trezor Bridge is installed, all SDK traffic is routed through the local bridge, not WebUSB.

Bridge Implementation Details

Trezor Bridge v2.0.27 is written in Golang. It uses xgo for cross-platform builds (macOS, Windows, Linux). On macOS, it installs the binary to /Applications/Utilities/TREZOR Bridge/trezord and creates a LaunchAgent plist for auto-start, Link.

<key>KeepAlive</key>
<true/>
<key>ProgramArguments</key>
<array>
  <string>sh</string>
  <string>-c</string>
  <string>/Applications/Utilities/TREZOR\ Bridge/trezord -l $HOME/Library/Logs/trezord.log</string>
</array>

Attack Overview

When MetaMask connects to a Trezor device, it reads the ETH public key and derives multiple addresses atclient-side — without any hardware confirmation. This makes the system susceptible to MITM.

If Trezor Bridge is compromised by malware, the attacker can intercept and manipulate all data between the wallet and the device, making UI-displayed information inconsistent with the hardware’s real data.

Test Setup

Software used: Trezor Suite v23.8.1, Trezor Bridge v2.0.27, MetaMask v11.0.0
Two Trezor Model T devices were prepared: one for normal behavior, one for MITM testing
First, both devices behaved normally and displayed correct addresses
Then, a malicious script replaced the trezord process
The first device still worked fine
The second device’s address was tampered by the attacker

Youtube Video

Code Analysis

Logs were added to Trezor Bridge to monitor requests and responses:

1_RI1x-z_ULhghSN43aGjzOw.webp

if mode != core.CallModeWrite {
  hexbodyStr := hex.EncodeToString(binbody)
  
  a.logger.Log(fmt.Sprintf("hexbodyStr, %s", hexbodyStr))
  
  hexres := hex.EncodeToString(binres)

  a.logger.Log(fmt.Sprintf("hexres, %s", hexres))
  
  _, err = w.Write([]byte(hexres))
  if err != nil {
   a.respondError(w, err)
  }
 }

 
[28.178293 : 16:14:47] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 003700000000
[27.843938 : 16:14:47] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 000b0000001f08ac8080800808bc80808008088080808008080008002207426974636f696e
[27.843954 : 16:14:47] [server/api/api.go 228 server/api.(*api).call] hexres, 000c000000c70a4e080510f7c2896218002220520f8747876da744c2bf49fecc8562017c9be0ecf2f55eae8d9b98360dd72fc1322102bfb03b1c56e5a4bc3085acc16170c91fcb8903413291d6246ccbd0cfe769345b126f78707562364657475054416d5a386f636847554631716261436d4e6569685953636f53774d426177567232324b796666674c4a4635766d536d43364147537062325079565a59417a383337313147456d44486f42504d4b5775634d4a41376f47556831685a364874794646624d503918a3eeeb870d
[27.466270 : 16:14:46] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 000b0000001d08ac8080800808bc8080800808808080800808002207426974636f696e
[27.466317 : 16:14:46] [server/api/api.go 228 server/api.(*api).call] hexres, 000c000000c80a4f080410cec1b2da0a18002220f107c96b21b14c5a304af43e1187341dd153f4702d82a04fc712bd43b5d2d65332210201694395789981413027ef739b4360316a7d6878b18dcb9bc670a1a2bd8baad9126f7870756236456e76784c3665674737796d5a514b4d3141524e325670794c624e56624b68443168694d346555586333735967576574726e6461415a4b56626375466a523137755a68456a77447366516163387776576f4e78637738694144427466595663366d764b466e624157756318a3eeeb870d
[27.094882 : 16:14:46] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 001d0000002108ac80808008088180808008088080808008080008001207546573746e65742800
[27.094912 : 16:14:46] [server/api/api.go 228 server/api.(*api).call] hexres, 001e000000460a226d736a586538664d446e4c724a6877515675527332554462574c314d58324c6579581220258c7690ef920a9400c30705156b60dea068193e7d5e7d86f83e24682ca4b7b6
[24.027874 : 16:14:43] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 0000000000021800
[23.409576 : 16:14:42] [server/api/api.go 220 server/api.(*api).call] hexbodyStr, 003700000000

Returned identical serialized responses when replayed — no timestamps or unique parameters. Therefore, an attacker can hardcode responses and simulate fake hardware behavior.

In this demo, when the SDK requests an ETH public key, it receives a fake pre-encoded response from the attacker instead of the real one. The compiled malicious binary and helper daemon enable full address substitution.

Disclosure & Communication

The issue was reported to both MetaMask and Trezor teams:

MetaMask report: HackerOne Report #2166893
Trezor response email:

Core Issues & Recommendations

MetaMask Displays Full Address Without Hardware Confirmation

While hardware wallets are secure environments, MetaMask reads and displays full addresses without triggering a confirmation on the device.

Trezor’s SDK includes a showOnTrezor flag for displaying the address on-screen for confirmation. Most wallet apps support silent address reads but require confirmation when receiving funds.

However, MetaMask skips confirmation even on first use — opening a path for attack.

This attack highlights a deeper issue: any non-deterministic data from hardware is theoretically unsafe.

Even with on-device confirmation, if the message is unreadable (as in blind signing), the user can’t verify it, exposing them to MITM attacks.

Example: The Safe multisig incident, where server-side JS replaced the signing payload. The Ledger blind signature mechanism failed to detect the change:

Incident Context

Multiple Vectors for Communication Hijacking

MITM is not limited to local malware. Some wallets use servers to encode transactions, adding attack vectors. Unsafe cables, USB hubs, or even peripherals can be leveraged as physical entry points.

From hardware to software, every communication layer is a potential vulnerability.

Raising Awareness Is Key

Even with end-to-end encryption, client-to-hardware wallet security isn’t guaranteed. Hackers will always weigh effort vs. reward — not just difficulty.

Many crypto teams deprioritize MITM protections. As shown in MetaMask’s bug bounty page, MITM is excluded.

Users must remain vigilant. Use isolated machines, avoid untrusted networks, and only download from trusted sources — even when using hardware wallets.