Bitcoin Forum

This project (http://lwn.net/SubscriberLink/626559/91c24f6195e545a2/) does not yet protect against BadUSB style exploits, however their approach might be capable of being extended to doing so.

Can't be sanitized if bad usb is actively modifying the files on the fly

Presumably part of their solution would involve having hardware in which you could plug the dirty USB drive that would not have any modifiable firmware which BadUSB could infect.

Our solution is to side step USB entirely, but for the sake of the argument:

The industry standard is to sell programmable MCUs (with NVRAM), where the USB firmware shares the same address space with whatever extra code the 2nd stage manufacturer will purpose it for. For the USB storage class, there is very little custom code to add, however the implication is that the MCU is mounted on a PCB that is wired to allow updating the NVRAM, usually through ICSP.

Bottom line, you are often sold USB devices that could be entirely re-purposed through an easy firmware update, and this is where the vulnerability lies.

There are 3 solutions to this dilemma:

1) Use MCUs with cooked-in logic: there is a class of MOS (i think) to which you can burn in the firmware permanently the first time you program it in. This would create firmwares that can't be messed with. A firmware attack would have to limit itself to the device's RAM, and that won't survive a power cycle, which would limit the infection to the one machine.

2) Destroy the "commute to write" pin. To set the NVRAM to write mode you need to power a dedicated pin. However, destroying it might be complicated, those QFP style packages have some very small pin spacing, chances are you could damage the entire MCU or the board trying to take down a single pin. If you manage to, you got yourself into the same situation as 1)

3) Side step USB entirely: it's a "managed" port, that needs firmware on both host and client side, too many vulnerabilities.

Keep in mind that even a sane USB device (on which no firmware attack will survive a power cycle) is not safe vector per say. You could simply attack the data written on it rather than the firmware, like say, tamper the change address (Armory will warn you of that however).

I stress this point because in an adversary situation (when an attacker can run arbitrary code on your machine), it will be entirely easier to modify the data written to the USB key than attack its firmware. Granted, it may not yield as large a reward as the USB attack.

Right now the hardest-to-close attack vector with offline Armory is using a compromised USB device to allow malware to cross the air gap.

A piece of dedicated hardware that would securely transfer the necessary files from a possibly-malicious USB drive to a clean drive could help considerably.

Until you get the audio cable method, or maybe animated QR codes, working the next best thing is using CDRs instead of USB drives. That is a bit slow and wasteful, however.

Not that hard to do yourself: https://bitcointalk.org/index.php?topic=735111.0

It would be nice to see a movement to take hardware back to its EE roots and stop using Turing machines where they aren't strictly necessary.

Wow. Just wow. This audio modem approach is friggin' awesome :o