Air-Gapped Hardware Wallets and FUD - 4

Is an air-gapped Bitcoin hardware wallet more secure than non-air-gapped? Or is it just inconvenient security theater? A discussion of the claims of the article “Does airgap make Bitcoin Hardware wallets more secure?” (Bakkum, Shift Crypto AG, 2021-10-27) (a provider of a fine Bitcoin non-airgapped hardware wallet: BitBox02).

précis:

• part 1
  • Is an air-gapped Bitcoin hardware wallet more secure than non-air-gapped? Or is it just inconvenient security theater?
• part 2
  • Did the successful and notorious Stuxnet attack succeed because of insufficient inspection of the data being exchanged?
  • Is converting an existing desktop computer to a dedicated air-gapped device inherently flawed because it is “open to many attack vectors”?
• part 3
  • “The Myth Of The Unbeatable Airgap Security”: A takedown of a strawman?
  • Glossed Over: Perils of the USB Interface
• part 4 ☜ you are here
  • “Usability is a cornerstone of security” - especially for a HODL’r
  • Consolation Prize: “Still, Airgap can be useful”
• part 5
  • Summary: Useful reminder that threats to all hardware wallets exist; but no support at all for claim that air-gap provides “little-to-no” added security", and is full of unwarranted scary FUD besides…
  • Acknowledgements

“Usability is a cornerstone of security” - especially for a HODL’r

At this point the article turns to a clearly true assertion: That a complicated interface weakens security.

Any difficulty in the UI - choices to be made by the user that he doesn’t know how to choose between, vague or ambiguous messages leading to a question of what to do next, complex displays of data that the user can’t interpret, optional steps that can be skipped by the user even though they’re crucial for safety - compromises security of the process.

And these difficulties are magnified when the user isn’t used to dealing with them, and doesn’t remember from instructions (the manual, the documentation, user forums, whatever) how to proceed.

HODL’rs, specifically, won’t be doing transactions every day. So when they do need to send BTC it’s got to be an easy reliable safe procedure. Because it won’t be something that they’ll learn by rote - it’ll be something that they have to do once in awhile correctly even though there is a good long time between uses to forget how do it correctly.

And, HODL’r or not, there’s always a great temptation to skip an optional validation step - especially if it involves yet more hardware/software to deal with (an independent 3rd party check of a transaction, for example) or if it involves looking back and forth between multiple sources comparing a long sequence of unformatted letters and digits, or looking such a sequence up in a table to see if it is in a long list of similar sequences.

It is important for the builders of all wallets, software and hardware, to pay close attention to this to make things as easy as possible and as foolproof as possible without compromising the safety that is the entire goal.

This section of the article has two checklists of steps to take to sign a transaction. The USB-connected hardware wallet has a short 3-step list. The storage channel (SD Card) air-gapped wallet has a - OMG! - 10 step checklist! The optical channel air-gapped wallet is omitted! If it was present it would have only 5 steps: ¹

1. Create TX on Computer
2. Display QR Code on Computer and capture it on HW camera
3. Confirm TX details and sign TX
4. Display QR Code on HW wallet and capture on Computer camera
5. Broadcast TX

That doesn’t sound so hard. ^2 3

So, why was the optical channel air-gapped wallet omitted here when other parts of the paper speak of such HW wallets? Could it be that it doesn’t look so bad in their comparison so weakens their point?

(There’s another bit that’s off here too: The 10-step storage channel HW wallet checklist includes a step, after writing the TX from the software wallet to the SD card, to “Check contents of MicroSD on third party device.” A good practice to be sure! But it sure sounds inconvenient, and the USB-connected HW doesn’t have that step listed - better, right? Well, maybe. But the fact is you can’t check it with the USB-connected wallet - it’s just bits sent over the wire invisible to you - so you have to rely on the software wallet not being corrupted. But wasn’t one of the starting principles for a hardware wallet that you have to assume the computer is compromised? I’m confused as to what needs to be “verified” in this step of the storage-connected wallet checklist that doesn’t need to be - and can’t be - checked by the user in the USB-connected wallet checklist, and need to look at this more to understand it.)

The important point made here is that usability of the HW wallet/software wallet combination is crucial for a foolproof process of (occasionally!) signing a transaction. And the physical manipulation of the MicroSD card for storage-channel air-gapped wallets is an impediment. But it is much less so for optical channel HW air-gapped wallets, in fact, IMO, not much of a burden at all (and it will be even easier in the future as more attention is paid to the ergonomics and haptic design of such wallets - nothing is really wrong with the DIY form-factor of those wallets today, but it can be and will be improved).

Consolation Prize: “Still, Airgap can be useful”

Here the article makes some good points about how air-gapped HW wallets can be convenient for various purposes. Going along with the bias we’ve seen so far, these are small beer: mix/match software wallets with hardware wallets, QR Codes via camera are in fact convenient, and you might be stuck with an Apple iPhone “that restricts usage of USB connectivity” (along with so much more!).

More important for security: They point out that

Air-gapped communication can limit potential attacks that require consecutive communication to the hardware wallet, for example that continuously probe the device. A hardware wallet, however, is purpose-built with a strict communication protocol, … implementing a strict communication protocol is straightforward, and we’re not aware of such probing attacks being successfully demonstrated.

Wait - go over that last bit again? “We’re not aware of such probing attacks being successfully demonstrated.” Where was that caveat earlier when they were talking about using Stuxnet techniques and subverted SD Cards and such against air-gapped hardware wallets? Apparently a “successful demonstration” is required to consider a threat against USB-connected wallets but not air-gapped wallets; good to know. Harrumph.

Finally, the wrap up: Was the point made, does air-gap provide “little-to-no added security”? See part 5