In the last year we had a number of high profile hacks (WazirX, Radiant Capital and ByBit) totaling $1.7B of stolen funds due to the combination of compromised devices, and HSMs not being able to attest that the user intentions didn’t match the spoofed message. What happened?

All these users were tricked into signing messages they did not want:

1. The user accesses a seemingly legitimate dApp on a compromised computer.

2. The user interface decodes the intended transaction or message (e.g., sending a specific amount to a particular address)

3. Malware intercepts and modifies the actual data sent to the hardware wallet.

4. Due to UI limitations, the hardware wallet shows bytes and hashes, making it challenging to verify the altered parameters accurately.

5. The malicious message is signed, and funds are stolen.

What’s wrong with the hardware wallet threat model

Hardware wallets excel at safeguarding users' seed phrases, making mnemonic exfiltration nearly impossible while allowing users to sign transactions and messages. However, they were primarily designed for simpler protocols, like Bitcoin, which did not require users to verify the parameters of more complex transactions. Blackhats know this.

These wallets cannot verify whether the signing request aligns with the user’s true intent. While they attempt to decode the data and present the parameters for user attestation, this is inadequate. Humans are not good at processing long hexadecimal numbers and often fail at it. Moreover, an attacker controlling the user’s computer can intercept and forge the signing request, replacing legitimate interactions, addresses, and target contracts with malicious ones—even generating fake emulation results. Thus, the hardware wallet alone provides insufficient context for confirming a transaction’s legitimacy.

Emulating transactions on a computer isn't a silver bullet either. Any attestation or verification mechanism running on a compromised device is fundamentally untrustworthy. Attackers can emulate hardware wallet interactions, mask UI elements, and even display fraudulent confirmations to trick users into signing dangerous transactions. It creates an “interactive movie” scenario where everything seen and interacted with is controlled by the attacker, leading users to sign fraudulent messages.

Clear signing alone isn't enough

To address this issue, hardware wallets have started implementing more advanced decoding of messages and calldata during the signing process, often referred to as clear signing. These are baby steps in the right direction, allowing users to better understand what they are signing.

Here’s a sneak peek of some of the challenges and why clear signing alone is insufficient:

* Addresses as Identifiers: Addresses are poor identifiers for humans. Users can't easily memorize all the contracts they interact with, and they must also guard against address poisoning and spoofing. The reputation of an address is important and varies from user to user. Etherscan provides great insights on this.

* Complex Calldata: Calldata can become very complex. For example, a simple swap on 1inch might involve multiple hops that could be meaningless to the user, especially with abstract instructions seen in smart accounts. The decoder should be adept at handling userOperations, executeTransaction commands, and other increasingly popular functions.

* Changing Signing Requests: In today's era of intents and smart accounts, custom decoders are necessary and must be tailored to the target contract where these are executed.

* State Manipulation: Transaction results can vary depending on multiple factors, with calldata being just one of them. Blockchain state elements, such as balance values, contract code, nonces, and storage variables, can impact execution outcomes. Sandwich attacks are a prime example of how state manipulation affects transactions.

Not everything is bad: current industry recommendation

SEAL provides an extensive list of measures users can take to protect themselves against sophisticated attacks here.
In summary:

* Ensure the device used for wallet operations is updated, isolated, and regularly factory reset

* Use Antivirus and Endpoint Detection and Response software

* Conduct regular Red Teaming exercises

* Utilize Hardware Wallets with clear signing support

The community, also created tools like safe-tx-hashes-util for decoding transactions that gets us closer to understanding what we are signing.
However, this doesn't account for the scenario where this is run in the same device that could be compromised. We need something else.

Enter Web3 Semantic Second Factor

To mitigate the risks of compromised devices and blind signing, we propose a second-factor semantic attestation system using an independent device. This helps ensure the integrity of both transactions and messages.

Here's how it works:

1. Users interact with dApps to construct the signing request.

2. A wallet with Semantic Second Factor (SSF) enabled displays a QR code containing the complete unsigned message or transaction.

3. The SSF provider emulates and tests it, provides insights, and displays its hash.

4. Users must ensure that the hashes match on both the hardware wallet and the SSF device.

Intent Verification Through Emulation

This layer ensures that both transaction and message actions perform as expected:

* Transaction Emulation: The system emulates the transaction execution to predict outcomes and effects.

* Structured Data Analysis: In case the messages match standards like EIP-712, which are used for smart accounts like Safe and ERC-4337, they are emulated to extract their intent.

* Natural Language Summary: It provides a clear, user-friendly explanation of balance changes and any significant on-chain effects.

* Statistical Analysis: Conducts a statistical analysis of the involved addresses to estimate risk.

* Adversarial Scenario Testing: Providers could test the transaction outcomes over synthetic adversarial blockchain scenarios.

This significantly increases the attacker’s difficulty, as compromising a single device is no longer sufficient. The approach can be extended to additional devices or even decentralized networks, establishing a more robust security model, much like how 2FA became the industry standard for password security.

One of the key advantages of this security model is its seamless integration into existing security workflows. Since both wallets and hardware wallets already support the necessary features, this approach enhances protection without expanding the attack surface of the systems.

Seriously, Stop Blind Signing

We believe that combining hardware wallets, robust security operations, and second-factor semantic verification can enhance the security of the signing workflow. At BitFinding, we've been working on a comprehensive solution that not only strengthens the current security model but also enhances transaction emulation outcomes using smart account modules.

If you're interested in boosting your security model and want to test our prototype, contact us now using the form below.