In digital security, the principle of WYSIWIYS—What You See Is What You Sign—is often cited as a fundamental safeguard. But what does it truly mean, and can it be considered the silver bullet for wallet security?
For an end-user signing or approving a transaction, this principle demands that the user interface (UI) clearly conveys the transaction’s intent in a meaningful and understandable way.
Take a basic Ethereum transaction, for example. The intent should be presented like this:
{
"chainId": 1,
"nonce": 5,
"maxPriorityFeePerGas": "0x59682f00", // 1.5 Gwei
"maxFeePerGas": "0x59682f00", // 1.5 Gwei
"gasLimit": "0x5208", // 21000 gas
"to": "0x3535353535353535353535353535353535353535",
"value": "0xde0b6b3a7640000", // 1 ETH in wei
"data": "0x",
"accessList": []
}
Instead of just this—what is actually being signed under the hood:
0x02f86b0185059682f0085059682f00825208943535353535353535353535353535353535353580
The issue of blind signing is even more complex when you are working with smart contracts, since you have to ensure that you understand and are able to decode the data and the Application Binary Interface (ABI) correctly.
Ensuring Meaningful User Approval
The solution is to display the transaction’s intent to the user within the security boundary—on the signing device itself (such as a hardware wallet) or an approval device that has a pre-established trust relationship with the signing device.
The flow should work like this:
1. Establish a trust relationship between the user and the signing device.
2. Present the human-readable intent on the approval device for user verification.
3. Generate the transaction (tx) based on the approved intent.
4. Send both the intent and tx to the signing device.
5. Validate the intent against established policies.
6. Verify on the signing device that the approved intent matches the raw transaction.
7. Sign the transaction.
The Risk of Blind Signing
If the signing device cannot display or validate the intent or parts of its data, it effectively reduces the process to blind signing. In this scenario, the security of the entire signing process hinges on the security and integrity of the approval device. This creates a vulnerability, especially when dealing with non-standard smart contracts.
Mitigating Approval Device Compromise
The first line of defense in securing an approval device is mitigating supply-chain attacks. This involves two critical safeguards:
- Code Integrity: Ensuring that the code running on the approval device is authentic and has not been tampered with during distribution or deployment.
- Runtime Protection: Implementing defenses against attacks that could compromise the device while it is operational.
For highly sensitive approval scenarios—such as cold wallet approvals—it may be necessary to employ dedicated approval devices, which could even be air-gapped to provide an additional layer of isolation from network-based threats.
But what if the approval device is compromised despite these precautions?
In such cases, the signing device can serve as a last line of defense by enforcing throttling mechanisms or other security policies. These measures can help detect or prevent fraudulent activity by restricting the frequency or scope of approvals, effectively slowing down any potential attacks.
Further safeguards can include:
- Second-Level Verification: Introducing an additional layer of validation that checks the raw transaction data against the user-approved intent.
- Simulation for Critical Operations: For high-risk actions, such as smart contract upgrades, an extra step of simulation can be introduced to verify the outcome before final approval.
By combining these strategies, even if an approval device becomes compromised, the signing process remains resilient—adding layers of protection that help maintain the system’s integrity.
Finally, and perhaps at the top of the list for the wallet owner: provide training for your end-users.
