Is QR Code Offline Signing Safe? Camera, Firmware, and Data Relay Risks

 / 
1

QR code offline signing can isolate private keys on a physically air-gapped device, but security is "conditional"—camera, firmware, and data relay: any vulnerability in these three links allows attackers to steal a signature without touching your device.

1. Where QR Code Offline Signing Is Safe—and Where It's Not

The core logic of offline signing is "cold-hot separation": the hot side (online device) only assembles transactions and generates QR codes; the cold side (offline device) only scans, signs, and displays the signature result; the signed data is then transmitted back to the hot side via QR code or USB drive for broadcasting.

This model itself has no problem. The real issues lie in three details.

Camera: The offline device relies on the camera to read QR codes. If the camera's firmware has a vulnerability, an attacker can use a carefully crafted malicious QR code to trigger a buffer overflow or command injection. In 2025, a CVE was exposed where smart home devices could execute arbitrary commands via malicious QR codes—the root cause being the firmware's lack of boundary checks when parsing QR code data.

Firmware: Many devices (including some cold wallet hardware and phone camera modules) lack signature verification in their firmware update mechanisms. Eclypsium's research shows that a large number of peripheral devices allow unsigned firmware updates; an attacker with normal user privileges can flash malicious firmware, turning the camera into a listening device or a data relay channel. Once the camera's firmware is tampered with, the attacker can see every QR code you scan.

Data Relay: The offline device has no internet, but the signature result must eventually return to the hot side to be broadcast. The relay relies on a QR code or a USB drive. Documents for solutions like AirGap explicitly state that the QR code is a "one-way transmission," and an attacker cannot interact back and forth with the offline device via QR code. The problem lies in the "man in the middle"—if the transaction QR code assembled on the hot side is tampered with, the amount displayed on the offline device after signing could be fake.

Key Reminder: A malicious QR code doesn't steal your private key—it steals your "hand." It makes you press confirm on what looks like a perfectly normal transaction, while you actually sign a completely different transaction that sends your assets to the attacker.

2. Practical Checklist: Do These Three Things Before Every Signature

Step 1: Verify the amount and receiving address shown on the offline device's screen

  • What to do: After the offline device scans and parses the transaction, do not rush to confirm.

  • How to do it: Compare every character of the "send amount" and "receiving address" on the screen against what you expect. Pay attention to the decimal point—the most common trick with a fake QR code is changing 0.1 into 1.0.

  • What counts as completed: The amount and address on the screen exactly match what you saw when assembling the transaction on the hot side, with no extra or missing zeros.

Step 2: Observe whether the QR code's density looks abnormal

  • What to do: Before showing the QR code to the offline device for scanning, look at the QR code pattern with your naked eyes.

  • How to do it: Normal transaction data (transfer amount + address) usually fits in a standard, medium-density QR code. If the QR code is abnormally dense (looking like a big black blob), it may contain extra data (such as a malicious payload or script).

  • What counts as completed: The QR code's density is similar to what you usually see during normal transactions, and it hasn't become noticeably more complex.

Step 3: Confirm the offline device's camera firmware comes from a trusted source

  • What to do: If your offline device is an old phone or tablet, ensure the camera firmware has security updates.

  • How to do it:

    • Case A (using an old phone as a cold wallet): Do not install any unnecessary apps on it, do not connect to unknown Wi‑Fi, charge using a power adapter instead of a computer USB port whenever possible, and avoid data transfer via USB that could trigger firmware update interfaces.

    • Case B (using a dedicated hardware wallet): Follow official security advisories. If the hardware manufacturer releases a firmware update, verify whether the update is signed. Unsigned firmware means an attacker could plant malicious code that cannot be detected.

  • What counts as completed: You are certain that the camera firmware on this offline device cannot be tampered with without your confirmation.

Prerequisite: The offline device must remain truly offline—never connect to the internet, never enable Bluetooth, never plug in an Ethernet cable. Once the device holding the private key has ever been online, its identity as a cold wallet is void.

Common Failure Reasons

"The transaction content displayed on the offline device differs from the hot side, but I didn't notice"—this is the most common and most insidious problem. The attacker tampered with the transaction QR code generated on the hot side, and the offline device faithfully displays the "tampered" content. If the user confirms without carefully checking, it's equivalent to personally handing over their money to the scammer.

Risk Reminder: Offline signing cannot guard against the user's own negligence—no matter how secure the device is, if you confirm without looking at the screen, all protections are useless. Taking 10 seconds to verify the amount and address before every signature is more effective than any technical defense.

After completing the above checks, how do you confirm the operation is safe?

After completing the signature on the offline device and before confirming the broadcast, double-check whether the transaction ID displayed on the hot side matches the signature data returned by the offline device. If you are using a cold wallet solution such as AirGap or imToken, a receipt will be displayed after the signature, confirming that this signature indeed corresponds to the transaction data you just verified. Only after receiving this confirmation should you broadcast it to the blockchain.