Is Armory vulnerable to USB-Stick viruses like BadBios?

[dacoinminster]

Hey Alan,

I just read about the "badbios" virus which can supposedly infect offline computers using USB sticks: http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/

Would you mind commenting about whether armory-offline users should be concerned about this virus, or ones like it, and whether we should find a different transport method for offline transaction signing? There has been some concern about this on reddit: http://www.reddit.com/r/Bitcoin/comments/1pmb82/malware_that_infects_at_the_hardware_level_can/

I sent you an email about this too. Thanks!

[1713282031]

1713282031

[1713282031]

1713282031

[1713282031]

1713282031

[1713282031]

1713282031

[Luckybit]

Hey Alan,

I just read about the "badbios" virus which can supposedly infect offline computers using USB sticks: http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/

Would you mind commenting about whether armory-offline users should be concerned about this virus, or ones like it, and whether we should find a different transport method for offline transaction signing? There has been some concern about this on reddit: http://www.reddit.com/r/Bitcoin/comments/1pmb82/malware_that_infects_at_the_hardware_level_can/

I sent you an email about this too. Thanks!

That is the least of it. There are a whole range of side channels based on differential power analysis which 99% of all computers are vulnerable to which means the encryption keys to most peoples machines are vulnerable. There are DMA attacks, hardware based trojans, all which most everyone is vulnerable to.

I think badbios just reveals that most people's machines are vulnerable to advanced persistent threats. Have a look at this: http://www.ma.rhul.ac.uk/static/techrep/2011/RHUL-MA-2011-07.pdf

For this reason if a government really wants your keys and they are determined enough to send some agents to target you specifically then its highly likely they will get them. But the point is that it is expensive and they wont do that to just anyone, at least not at this time. I'm not sure there is anything Armory can do about it, it's a hardware problem which can be solved by using hardware which blocks data emanations. I wonder if the new Trezor wallet will be vulnerable to differential power analysis?

 

[Vernon715]

I read the article about badbios and would like to present a possible solution to these problems.

To address the speaker/microphone avenue of communication, I recommend the raspberry pi model A. A model A has 256mb of ram, which happens to be the same as the minimum requirements to run armory offline. In addition, since the model A doesn't have wifi or an ethernet port, you won't do are less likely to do anything stupid, like connect it to the internet.

Now that you have a computer that is next to impossible to connect to the internet, you need a way of communicating with the outside world to sign transactions.

I'm not sure if this is possible at the present time, but it seems to me that the best way to do this would be through qr codes of some sort--I'm not smart enough to make this work, so that is a slightly fuzzy part of this suggestion.

If you want to go the uber-paranoid rout, you could use an external battery pack to power the pi, which completely isolates the pi from any possible source of malware.

I think that this system would be as secure as it gets, but if I anything I said is wrong, I'm sure you'll let me know.

[Rogue Star]

I've done some work for using QR codes to transfer data between computers specifically since I have moved to Armory. It is a Java based application, so it probably won't work well on a RPi with so little RAM. The source is out there on the interwebs, but I haven't fully thought out what license I'd like to use. If there is an increasing interest in it, I'll work through those issues so people can use it/build on top of it.

That said, I'm not convinced a hardened version of it would stand up to a persistent attacker. At the end of the day you're going to end up using a library or re-inventing the wheel and either one will have it's own set of vulnerabilities to side-channel attacks. I believe it to be safer than USB since there is no bootability issues and it is hopefully less likely to "auto-play". It also gives you a lot more control of how much/when data is transmitted or received and you can verify the payload against a third party device if you are paranoid.

[etotheipi]

The problem with QR codes is they aren't big enough.  They're big enough for 95% of transactions, but the first time you have to move 1 MB across that channel, you'll be SoL.  And you don't have control over it.  If I know one of the addresses in your offline system, I can send you a couple 100 kB transactions, and effectively DoS your offline solution.

There's a discussion thread about it here:  https://bitcointalk.org/index.php?topic=68482
And ironically: https://bitcointalk.org/index.php?topic=135423.0

But none of it is ready yet.  Though goatpig claims to be making progress on the audio solution.

I should clarify though: the article doesn't say that computers will be infected through audio or power-line communication.  But if your offline computer is already infected, it can use those methods to communicate with another infected machine.  It does sound the stuff of science-fiction, and I'm conflicted about whether to believe this is a real threat (since there's conflicting evidence).  But it does give us some hints about ways we can protect ourselves better. 

I would argue that assume-the-offline-system-is-already-compromised-by-the-most-advanced-malware assumption makes security a mostly intractible problem.  There's too many ways for a properly-secured-but-compromised offline system to leak information.  And depending on how good it is, it might only need one transaction to do it.    The best thing we can do is take appropriate precautions to minimize risk of infection, and be able to detect it when we fail.

Now that ATI has some money, we'll be spending some of it to get some real good crypto/security guys to help us shape our best practices to address threats like this, even if this particular one turns out not to exist [yet].

[Raize]

Yeah, I was just going to say, this is looking more and more like a Halloween hoax:
http://www.reddit.com/r/netsec/comments/1pm66y/meet_badbios_the_mysterious_mac_and_pc_malware/cd3u1az

Though it does sound like his high frequency audio transmission in badBIOS is more than just a theoretical:
http://smus.com/ultrasonic-networking/

[dacoinminster]

The problem with QR codes is they aren't big enough.  They're big enough for 95% of transactions, but the first time you have to move 1 MB across that channel, you'll be SoL.  And you don't have control over it.  If I know one of the addresses in your offline system, I can send you a couple 100 kB transactions, and effectively DoS your offline solution.

There's a discussion thread about it here:  https://bitcointalk.org/index.php?topic=68482
And ironically: https://bitcointalk.org/index.php?topic=135423.0

But none of it is ready yet.  Though goatpig claims to be making progress on the audio solution.

I should clarify though: the article doesn't say that computers will be infected through audio or power-line communication.  But if your offline computer is already infected, it can use those methods to communicate with another infected machine.  It does sound the stuff of science-fiction, and I'm conflicted about whether to believe this is a real threat (since there's conflicting evidence).  But it does give us some hints about ways we can protect ourselves better. 

I would argue that assume-the-offline-system-is-already-compromised-by-the-most-advanced-malware assumption makes security a mostly intractible problem.  There's too many ways for a properly-secured-but-compromised offline system to leak information.  And depending on how good it is, it might only need one transaction to do it.    The best thing we can do is take appropriate precautions to minimize risk of infection, and be able to detect it when we fail.

Now that ATI has some money, we'll be spending some of it to get some real good crypto/security guys to help us shape our best practices to address threats like this, even if this particular one turns out not to exist [yet].

Thanks Alan.

I'm actually a lot more worried about the "assume-the-ONLINE-system-is-already-compromised-by-the-most-advanced-malware assumption". That has basically been my assumption all along, which is why I find the concept of infections spread by USB keys really scary. Is that what you meant?

[etotheipi]

Thanks Alan.

I'm actually a lot more worried about the "assume-the-ONLINE-system-is-already-compromised-by-the-most-advanced-malware assumption". That has basically been my assumption all along, which is why I find the concept of infections spread by USB keys really scary. Is that what you meant?

In many ways, I have designed the system assuming the online system is compromised, but without the ability to spread USB viruses (easily).   As long as you check very carefully on the offline system that the amounts and addresses are what you expect, then it's an exceptionally safe setup (because we've assumed no USB viruses like this).  The data that is transferred over USB is public, non-sensitive, and contains everything the offline computer needs to fully verify all the details of the transaction.  I had even considered an operational mode where people could run just the wallet, and then send their watching-only wallets to a server, and the server would prepare the transactions for them to sign (for the people without the resources to run Armory online).  I could provide such a service confidently, because it would actually be a very safe system -- the downside would be how easy it is for the server to feed bogus UTXO information and effectively DoS the wallet (every signature produced would be invalid, thus making the system unusable -- but better than losing coins!).

So, under the offline-system-is-secure scenario, the worst that happens is having your transactions become invalid (though, you can lose coins because you didn't verify the addresses and amounts on the offline system before pressing "sign" -- the virus could exploit someone simply being non-attentive).  If the offline system is compromised, then it would be a pretty advanced virus (jumped through hidden data on USB), and thus should be sufficiently advanced to shuttle private key data back over USB.  Or hide data in transaction malleability.  Or if both systems are compromised, it just flat out jams the private key into the signature space, and tells you it's valid, and the online system recognizes and sweeps the funds to the attacker before you've even realized your broadcast transaction is invalid.

Because of this, it's worth visiting how to minimize damage of an offline computer compromise, but it's a very difficult problem and one I can't claim to solve.  Use anti-virus on your online computer, dedicate a small USB key to be used for only offline transaction shuttling, and really check all the addresses and amounts of the transactions before signing.  Also, if the transaction is sufficiently large, I recommend making a phone call to the recipient to manually verify the addresses.    This will keep you from being "low-hanging fruit" to the next piece of Bitcoin malware

[dserrano5]

Use anti-virus on your online computer, dedicate a small USB key to be used for only offline transaction shuttling

And use no other USB key on the online computer. Otherwise, as soon as any of them carries the virus and infects the machine, the dedicated key used for offline signing will get the virus too and transmit it to the offline node.

[Rogue Star]

The problem with QR codes is they aren't big enough.  They're big enough for 95% of transactions, but the first time you have to move 1 MB across that channel, you'll be SoL.  And you don't have control over it.  If I know one of the addresses in your offline system, I can send you a couple 100 kB transactions, and effectively DoS your offline solution.

QR codes can hold enough data. I've put some thought into this and have a working prototype. QR codes can hold up to 2KBs of data with standard readers. In practice, i expect a casual setup will be able to read 1KB QR codes. As far as data encoding goes, Base91 seems to be optimal for compatibility, so 364 bytes are available in an easily readable QR code. It's not high bandwidth by any means, but more than fine for today's usage. It may even be a feature for people using Armory now.

I can see how audio is a good solution coming from people with DSP experience. I just like how QR codes are easy enough for most people to understand.

I'm not sure I understand your point about DoS, the online computer will be creating the transaction, just use coin control to select non-DoS'd inputs. The 1 MB block limit will make DoS impractical for most until it's lifted. The blockchain will continue to have anti-DoS measures beyond the 1 MB block limit being lifted, so most users should be fine after that as well.

QR code + Webcams: 
 + QR codes are easy to generate
 + Plenty of existing software for scanning QR codes
 + Many laptops come with webcam, and can also be purchased inexpensively
 - Requires manually moving cameras and screens around to get QR codes into view
 - QR codes may not hold enough data: may need to use multiple codes
 - Need to design webcam-based UI, with feedback and possible UI for flipping&scanning multiple QR codes
 - Webcam support on all platforms is flaky (but it could be up to the user to get their webcam supported)

In my prototype I just use screen reading, no need to deal with drivers. I'm sure adding direct web cam capture capabilities you could push the QR codes to 2 KB. It's just that JMF is not a Java library I look forward to working with.

Multiple QR codes are not really a problem, in my prototype I allocated space to store information about the payload. Once you setup cameras in good positions it's easy enough to cycle through QR codes. You can easily read a QR code in under a second. It's easy enough to automatically split the data and re-assembles data to/from QR codes.

Here are some numbers showing how I handle payloads up 30 KB:

16 base91 bytes in metadata total (1 byte each for block index and count), leaves 1008 bytes for data
base 91 vs base 256 efficiency is a little over 35%
that gives 358 bytes of data per 1KB QR code
up to 91 QR codes can be created for a single payload containing 30 KB of data

I'm sure by reworking the protocol a bit I could get it close to the limits of QR code technology and whatever users are willing to put up with.

[Carlton Banks]

Use anti-virus on your online computer, dedicate a small USB key to be used for only offline transaction shuttling

And use no other USB key on the online computer. Otherwise, as soon as any of them carries the virus and infects the machine, the dedicated key used for offline signing will get the virus too and transmit it to the offline node.

If you're dealing with wallets containing large holdings to protect, it's worthwhile considering using a dedicated machine, to be used for broadcasting transactions and for no other reason. Even just a VM for broadcasting only would be a decent measure. After all, you would never fire up either a physical or a virtual machine for any other purpose if that was how you worked, it would at least shut off opportunities to attackers.

Liking the sound of goatpig's progress with analogue air-gap traversal.... I would happily contribute something to a development fund if he were to set up a thread outlining a proposal.  

[justusranvier]

The problem with QR codes is they aren't big enough.  They're big enough for 95% of transactions, but the first time you have to move 1 MB across that channel, you'll be SoL.  And you don't have control over it.  If I know one of the addresses in your offline system, I can send you a couple 100 kB transactions, and effectively DoS your offline solution.

There are people who are using Armory to store balances of sufficient value that they could easily justify buying a printer/scanner exclusively for the offline system to use.

How much data can fit on a single piece of paper if it's full of QR codes?

[goatpig]

If you're dealing with wallets containing large holdings to protect, it's worthwhile considering using a dedicated machine, to be used for broadcasting transactions and for no other reason. Even just a VM for broadcasting only would be a decent measure. After all, you would never fire up either a physical or a virtual machine for any other purpose if that was how you worked, it would at least shut off opportunities to attackers.

Liking the sound of goatpig's progress with analogue air-gap traversal.... I would happily contribute something to a development fund if he were to set up a thread outlining a proposal.  

I'm not trying to send data over an air gap. This library I'm developing is to enable sending data over soundcards linked together by double ended audio cables. I don't intent to allow it to function over speakers and mics unless Alan insists upon that feature.

Proof of concept is nearly done with a speed of 1 bit per Hz. I think I have a reasonable chance to achieve 2 bits per Hz without the need for massive research and protocol overhaul.

[Carlton Banks]

If you're dealing with wallets containing large holdings to protect, it's worthwhile considering using a dedicated machine, to be used for broadcasting transactions and for no other reason. Even just a VM for broadcasting only would be a decent measure. After all, you would never fire up either a physical or a virtual machine for any other purpose if that was how you worked, it would at least shut off opportunities to attackers.

Liking the sound of goatpig's progress with analogue air-gap traversal.... I would happily contribute something to a development fund if he were to set up a thread outlining a proposal.  

I'm not trying to send data over an air gap. This library I'm developing is to enable sending data over soundcards linked together by double ended audio cables. I don't intent to allow it to function over speakers and mics unless Alan insists upon that feature.

Proof of concept is nearly done with a speed of 1 bit per Hz. I think I have a reasonable chance to achieve 2 bits per Hz without the need for massive research and protocol overhaul.

Lol, I phrased that slightly ambiguously, I realise you were planning on using copper wires, and not loudspeaker and microphone! That could be difficult to get working, and it would bring a whole new concept of (literal) eavesdropping into the mix too. I would assume that all the bandwidth is in the high frequencies, and of course, higher pitched sounds travel further before their "information" dissipates. I don't think we need the added expense of sound proof transaction signing booths in our regular setups quite yet!

[Inaba]

Thanks Alan.

I'm actually a lot more worried about the "assume-the-ONLINE-system-is-already-compromised-by-the-most-advanced-malware assumption". That has basically been my assumption all along, which is why I find the concept of infections spread by USB keys really scary. Is that what you meant?

In many ways, I have designed the system assuming the online system is compromised, but without the ability to spread USB viruses (easily).   As long as you check very carefully on the offline system that the amounts and addresses are what you expect, then it's an exceptionally safe setup (because we've assumed no USB viruses like this).  The data that is transferred over USB is public, non-sensitive, and contains everything the offline computer needs to fully verify all the details of the transaction.  I had even considered an operational mode where people could run just the wallet, and then send their watching-only wallets to a server, and the server would prepare the transactions for them to sign (for the people without the resources to run Armory online).  I could provide such a service confidently, because it would actually be a very safe system -- the downside would be how easy it is for the server to feed bogus UTXO information and effectively DoS the wallet (every signature produced would be invalid, thus making the system unusable -- but better than losing coins!).

So, under the offline-system-is-secure scenario, the worst that happens is having your transactions become invalid (though, you can lose coins because you didn't verify the addresses and amounts on the offline system before pressing "sign" -- the virus could exploit someone simply being non-attentive).  If the offline system is compromised, then it would be a pretty advanced virus (jumped through hidden data on USB), and thus should be sufficiently advanced to shuttle private key data back over USB.  Or hide data in transaction malleability.  Or if both systems are compromised, it just flat out jams the private key into the signature space, and tells you it's valid, and the online system recognizes and sweeps the funds to the attacker before you've even realized your broadcast transaction is invalid.

Because of this, it's worth visiting how to minimize damage of an offline computer compromise, but it's a very difficult problem and one I can't claim to solve.  Use anti-virus on your online computer, dedicate a small USB key to be used for only offline transaction shuttling, and really check all the addresses and amounts of the transactions before signing.  Also, if the transaction is sufficiently large, I recommend making a phone call to the recipient to manually verify the addresses.    This will keep you from being "low-hanging fruit" to the next piece of Bitcoin malware

How does this address the issue of malware on the watching only system (online system) infecting the USB key with a bitcoin tailored bit of malware that will then infect the offline system when you insert the USB stick, steal the private keys from the offline system and then take the private keys back with it when the USB stick is back in the online system (to send the transaction after it's signed)?  Then the malware sends out the private keys through another channel of the infected system.  

There needs to be a way to isolate the offline system without putting a device into both systems.  I've got nothing off the top of my head, but that's what ultimately needs to happen.  

[justusranvier]

There needs to be a way to isolate the offline system without putting a device into both systems.  I've got nothing off the top of my head, but that's what ultimately needs to happen.

Dead trees.

The online system prints out the unsigned transaction via some kind of suitable encoding, then you install a scanner/webcam on the offline system to read it.

Data transfer offline->online could either use print, or even burn the signed transaction to a mini-CD that gets discarded after a single use.

[justanickname]

There needs to be a way to isolate the offline system without putting a device into both systems.  I've got nothing off the top of my head, but that's what ultimately needs to happen.  

Here is a thought.
if you have 2 camars : dirty camera(only allowed to be connected to online wallet PC)
                               clean camera(only allowed to be connected to offline wallet PC).

1) create offline transaction in online wallet PC.
2) take photo of the unsigned transaction text with clean camera.
3) copy picture from clean camera move to offline wallet PC.
5) convert photo to text and insert to offline armory.
6) sign transaction.
7) take photo of the signed transaction text with dirty camera.
8 ) copy picture from dirty camera move to online wallet PC.
9) convert photo to text and insert to online armory.
10)broadcast.

I think steps 3 and 8 are doable and it will be totally hermetic this way.

[balanghai]

Best thing to do is have linux pc handle all the removable media for additional security.

[goatpig]

Lol, I phrased that slightly ambiguously, I realise you were planning on using copper wires, and not loudspeaker and microphone! That could be difficult to get working, and it would bring a whole new concept of (literal) eavesdropping into the mix too. I would assume that all the bandwidth is in the high frequencies, and of course, higher pitched sounds travel further before their "information" dissipates. I don't think we need the added expense of sound proof transaction signing booths in our regular setups quite yet!

The protocol would be different, the data rate reduced, it would be exposed to external sources of noise, allow for possible man in middle attack vectors and an array of issues that I don't need to dwevle into.

The point is fundamental anyways: it is possible to get the data moved over the air gap, but such functionality potentially steps out of the current offline transaction signature paradigm currently delivered by Armory.

[flipperfish]

What about a raw/custom formatted USB stick?

I think a real danger after disabling autoplay is the filesystem itself. There have been exploits within several kernel modules for the different filesystems (e.g. http://www.cvedetails.com/cve/CVE-2013-1773, http://www.cvedetails.com/cve/CVE-2011-4330, http://www.cvedetails.com/cve/CVE-2009-4020). I don't know how severe these bugs are and if they could have been used for malicious code execution, but I think it is reasonable to expect an existing, unfixed bug, which can be used for code execution.

A custom format, which only defines the most necessary fields to transfer the raw transaction data should be much safer. The code to read the custom format should be much simpler and thus less error prone than conventional kernel filesystem modules. Additionally, any exploit of this custom format parser will be executed in the user space and not within the kernel, because only the signing application (e.g. Armory) must read and parse the data.


My thoughts about the USB stick infection of "badBIOS":
I don't think, that it is possible for a simple mass storage device to infect a pc just by plugging in (and not reading and interpreting any data on it). The circuit to read and write data on the drive is hardwired and can't be manipulated by software (correct me if I'm wrong). This should be true for the USB host interface in the mainboard, too. So as long as there is no data transfer it is impossible to infect anything. Things might change if data is transfered. However, even then, the hard wired host interface or the kernel code which handles the usb frames must be compromised by a malformed usb frame. This however should be prevented by the hard wired circuit on the drive itself.
Don't get me wrong, I think it is perfectly believable, that a system can be compromised by its USB subsystem. This has been demonstrated with the PS3. However, a special USB frame had to be crafted for this to happen. A simple mass storage device could not do this.