Let's get this USB stick malware risk straightened out once and for all

[pf]

So from what I gather, a USB stick can pretend to be a keyboard, mouse, printer, and other devices. That's really all it can do.

On a Linux offline machine, does pretending to be other devices actually make it possible for the USB stick to gain access to an Armory wallet passphrase that is typed by me on the real keyboard? It would need sudo access for that at least, I imagine.

In addition, if it's pretending to be a keyboard and mouse, I guess one would notice visually on the screen as it does its thing. If we don't see the mouse cursor jumping around or the Terminal window popping up, can't we on Linux sort of safely assume the USB stick isn't doing anything nefarious?

I get the feeling that this whole risk of a USB stick grabbing your Armory wallet passphrase from your offline computer and then sending it, along with any encrypted backups of the Armory wallet it finds on your online computer, off to the internet when connected on the online computer is overblown.

Discuss. And correct me if I'm wrong.

[1713898924]

1713898924

[1713898924]

1713898924

[1713898924]

1713898924

[1713898924]

1713898924

[1713898924]

1713898924

[1713898924]

1713898924

[Carlton Banks]

So from what I gather, a USB stick can pretend to be a keyboard, mouse, printer, and other devices. That's really all it can do.

On a Linux offline machine, does pretending to be other devices actually make it possible for the USB stick to gain access to an Armory wallet passphrase that is typed by me on the real keyboard? It would need sudo access for that at least, I imagine.

sudo exploits are frequently patched, this is unlikely to stop. root privileges and/or MAC's are not adequate defense in today's world.

In addition, if it's pretending to be a keyboard and mouse, I guess one would notice visually on the screen as it does its thing. If we don't see the mouse cursor jumping around or the Terminal window popping up, can't we on Linux sort of safely assume the USB stick isn't doing anything nefarious?

No. You cannot and should not expect any indication or prior warning that you've been hacked.

I get the feeling that this whole risk of a USB stick grabbing your Armory wallet passphrase from your offline computer and then sending it, along with any encrypted backups of the Armory wallet it finds on your online computer, off to the internet when connected on the online computer is overblown.

There is no intermediate position though.

When you lose your Bitcoins to any kind of exploit, the first you will know is when you open your wallet to discover them gone.

[pf]

Okay, new principle: Never use USB on my offline laptop.

I'm going to buy a new offline laptop which has a built-in DVD reader. (My current laptop doesn't have an optical drive.) Then I can burn a DVD for installing Ubuntu and burn CDs for getting files onto the offline machine. To get signed Armory transactions back to online computer, I can use a camera and OCR software.

The thing is, it's hard to find such a laptop unless it's also a DVD writer too. So that begs the question: Could inserting a DVD/CD into a DVD/CD writer be potentially dangerous? Or maybe this is not really a risk like USB is a risk? In fact, reading CDs/DVDs also begs this same question. Can they do attacks like USB devices can?

[RustyNomad]

Why not just buy a Trezor?

I've also gone through this whole story, to USB or not, to CD/DVD or not, to air gap or not, second offline computer, paper wallets etc...

In the end I just bought a Trezor and I think it's the best thing I've done since getting involved with bitcoin, it was money well spent.

With all the other options you never have 100% peace of mind and its so easy to slip up once and by doing so to compromise everything.

[CIYAM]

The safest way to do comms is QR codes - unfortunately the Armory project have never wanted to do that as they always have wanted their offline storage to work like an online wallet (which I've always thought is silly).

Trezor won't help in that it uses USB also and therefore could be compromised in the same manner as other USB connections could (it is also vulnerable to "side-channel" attacks).

I created a 100% air-gapped solution years back (the CIYAM Safe) and although I didn't bother to make it very easy to use it is a bit disappointing that no-one seems to be interested in making such a solution available.

[pf]

The safest way to do comms is QR codes - unfortunately the Armory project have never wanted to do that as they always have wanted their offline storage to work like an online wallet (which I've always thought is silly).

Trezor won't help in that it uses USB also and therefore could be compromised in the same manner as other USB connections could (it is also vulnerable to "side-channel" attacks).

I created a 100% air-gapped solution years back (the CIYAM Safe) and although I didn't bother to make it very easy to use it is a bit disappointing that no-one seems to be interested in making such a solution available.

I really love Armory. The idea of having a SINGLE BACKUP no matter how many addresses I create is genius. The idea of transactions signed offline is also genius and sure they could add QR codes into that, but while they don't have it, can't we just make our own QR solution to use alongside Armory? Until we have that, I think we can use webcams and optical character recognition because Armory shows all the text data for the unsigned and signed transactions.

So I'm a fan of Armory. The only question now remaining is whether DVD/CD readers/writers are a security risk like USB devices.

Trezor is risky as you mentioned. Also, a dedicated bitcoin device shipped to my address? That's an obvious disadvantage as well. Getting a generic laptop shipped to my address is a different story.

[Carlton Banks]

discussed before in this sub-board, more detail to be found there

QR codes are datasize limited, they cannot encode the amount of information in one image that a typical transaction would require. Sequences of QR's are not impossible, but could be unreliable or unwieldy in practice. It would take some time to discover whether the average modern equipment would be up to the task.

Okay, new principle: Never use USB on my offline laptop.

I'm going to buy a new offline laptop which has a built-in DVD reader. (My current laptop doesn't have an optical drive.) Then I can burn a DVD for installing Ubuntu and burn CDs for getting files onto the offline machine. To get signed Armory transactions back to online computer, I can use a camera and OCR software.

That would handle the USB concerns, but remember the principle that goatpig has introduced us to: peripheral sockets of the various types found in computers may conform to one standard at the physical end, but may get handled electronically by an entirely different protocol. Investigate whether the candidate laptop is using SCSI, SATA, ExpressCard, USB, SD or whatever other interface to the motherboard the ROM disk device could use. If so, investigate that interface platform for the types of exploits that goatpig outlined when telling us about USB ports that aren't really 100% USB.

Also, 5cm CD's or CD-RW would be a good way of minimising the wastefulness of this method. Multi-sessioning the disks in pursuit of the same ideal is probably not such a good plan.

The thing is, it's hard to find such a laptop unless it's also a DVD writer too. So that begs the question: Could inserting a DVD/CD into a DVD/CD writer be potentially dangerous? Or maybe this is not really a risk like USB is a risk? In fact, reading CDs/DVDs also begs this same question. Can they do attacks like USB devices can?

Different kind of risk (as you identify) and not as risky at all. Burning information to ROM disks is just not surreptitious, you would (should...) notice. Contrary to my earlier post. Which means I don't think anyone would write an exploit with CD burning as a part of the attack vector, it doesn't make alot of sense.

[CIYAM]

QR codes are datasize limited, they cannot encode the amount of information in one image that a typical transaction would require. Sequences of QR's are not impossible, but could be unreliable or unwieldy in practice. It would take some time to discover whether the average modern equipment would be up to the task.

Seriously I have been using QR codes to do BTC txs for *years* without a problem so I think you are exaggerating any problems other than the problems of trying to use a "normal wallet" (that ends up with lots of UTXOs).

It is amazing that so many people like you post negative things about using QR codes for BTC when I have done literally hundreds of BTC txs this way without a single problem (my guess is that you have never actually tried to use QR codes yourself).

[goatpig]

Seriously I have been using QR codes to do BTC txs for *years* without a problem so I think you are exaggerating any problems other than the problems of trying to use a "normal wallet" (that ends up with lots of UTXOs).

It is amazing that so many people like you post negative things about using QR codes for BTC when I have done literally hundreds of BTC txs this way without a single problem (my guess is that you have never actually tried to use QR codes yourself).

What is the byte density of your QR codes? How many QR codes are you using per transaction? Are you attaching the relevant UTXOs to verify spend val and change on the offline signer?

[CIYAM]

What is the byte density of your QR codes? How many QR codes are you using per transaction? Are you attaching the relevant UTXOs to verify spend val and change on the offline signer?

In general one QR code can handle about 4K (so a private key from GPG can require two QR codes but a single UTXO BTC tx only requires one).

I am using 1 QR code per tx as the txs are only using one UTXO (which is all you need to if you are using offline storage).

The problem with Armory is that you always have wanted to treat the online and offline wallets as the same - I simply don't do that so I don't have the problem of UTXOs.

[Carlton Banks]

What is the byte density of your QR codes? How many QR codes are you using per transaction? Are you attaching the relevant UTXOs to verify spend val and change on the offline signer?

In general one QR code can handle about 4K (so a private key from GPG can require two QR codes but a single UTXO BTC tx only requires one).

I am using 1 QR code per tx as the txs are only using one UTXO (all you need to if you are using offline storage).

The problem with Armory is that you always have wanted to treat the online and offline wallets as the same - I simply don't do that so I don't have the problem of UTXOs.

Interesting, I based my knowledge about QR codes for bitcoin on what was said in the thread from this Armory sub-board, so perhaps that discussion wasn't comprehensive. Is your solution available for others to use?

[CIYAM]

Interesting, I based my knowledge about QR codes for bitcoin on what was said in the thread from this Armory sub-board, so perhaps that discussion wasn't comprehensive. Is your solution available for others to use?

Of course it is - https://susestudio.com/a/kp8B3G/ciyam-safe (I didn't want to put in the link before as it might have come across as some sort of advertisement).

All comms are done using QR codes (you would only use the USB for the OS itself which you would never need to reconnect to the computer you downloaded it from).

[goatpig]

The problem with Armory is that you always have wanted to treat the online and offline wallets as the same - I simply don't do that so I don't have the problem of UTXOs.

I don't understand what you are referring to, care to elaborate?

[CIYAM]

I don't understand what you are referring to, care to elaborate?

Okay - for a typical offline tx I use *one* UTXO (some address I sent a bunch of BTC to a long time ago that was not used for anything else).

Thus the tx has only one UTXO and is very small (so no issue with using a QR code).

Armory is trying to cater for people that gave out their address and so have multiple UTXOs for that same address (this also has the problem of their offline computer needing to know more and more about what the online computer knows).

None of this is at all complicated or difficult for you to understand.

[goatpig]

None of this is at all complicated or difficult for you to understand.

It isn't but not for the reasons you are insinuating. What you are describing is user pattern, not software design. Armory is specifically coded to provide a fresh address when you request a payment and never sends coins to the same change address. Splitting UTXOs is a good practice to help with privacy but we do not support this in code atm, so I don't get where your point comes from. Yes, some people reuse addresses. We do not encourage this, but can't prevent it either.

Using QR codes to pass transaction data around is definitely an advanced feature and we would expect anyone using it to be familiar with the limitations of QR codes and avoid fragmenting their holdings within several UTXOs. However that solution does not cover 100% of our users and a vocal minority that will do things completely wrong will end up clogging our support channel and badmouth us publicly at every corner. This is a consideration we have to deal with as well, which is why we prefer audio modems to QR code when it comes to analog data carriers. They simply are more efficient.

Then again there is a matter of priority and cost of development. I started working on Armory claiming the 2BTC bounty to port LevelDB to Windows and I intended on going after the 25BTC for the audio data library afterwards. Then I was hired as a full time developer and spent the next couple years on much higher priority work like reworking the C++ backend.

A year and a half later, we got a half time developer to whom etotheipi gave the task of finalizing the audio lib a user submitted to claim the 25BTC reward. He got pretty far and... was turned into a full time employee with the burden of several responsibilities, none of which being the audio modem lib.

I think you can see where I am getting at by now. We shifted our focus to enterprise products a while ago and the demand in that market is for HSM integration, not enthusiast exotic features like QR codes and audio modems. The reality is there are a lot of things we'd like to put in the in the public version, but the business reality is that they don't make sense in the enterprise version so we are not developing them at all atm.

[Carlton Banks]

I think you can see where I am getting at by now. We shifted our focus to enterprise products a while ago and the demand in that market is for HSM integration, not enthusiast exotic features like QR codes and audio modems. The reality is there are a lot of things we'd like to put in the in the public version, but the business reality is that they don't make sense in the enterprise version so we are not developing them at all atm.

Off topic, but I think an updated roadmap should be forthcoming seeing as your target userbase is now different to your actual userbase. I'm spending my own free time trying to help you guys with this, I need to know whether that time is being well spent. I expected to see more end user features developed, but you're telling me this is not necessarily the intention at all.

[pf]

...not enthusiast exotic features like QR codes...

I'm not entirely sure why this is a big deal either. There already exists software out there to turn text into QR codes and vice versa. And Armory shows you all the text data you need for an unsigned & signed transaction. So do we really need it in Armory? Doesn't seem that urgent to me. With Armory combined with other QR <-> Text programs we got all we need, don't we?

[goatpig]

Off topic, but I think an updated roadmap should be forthcoming seeing as your target userbase is now different to your actual userbase. I'm spending my own free time trying to help you guys with this, I need to know whether that time is being well spent. I expected to see more end user features developed, but you're telling me this is not necessarily the intention at all.

I'm sorry but I can't communicate on this by myself. etotheipi is preparing a public statement on that matter. I have no ETA to provide either.

I'm not entirely sure why this is a big deal either. There already exists software out there to turn text into QR codes and vice versa. And Armory shows you all the text data you need for an unsigned & signed transaction. So do we really need it in Armory? Doesn't seem that urgent to me. With Armory combined with other QR <-> Text programs we got all we need, don't we?

It's like saying do why do we need power plugs for passengers in a commercial flight? There're already getting individual multimedia stations.

The answer is "it's not necessary but it's nice to have and benefits our image".

[Carlton Banks]

Off topic, but I think an updated roadmap should be forthcoming seeing as your target userbase is now different to your actual userbase. I'm spending my own free time trying to help you guys with this, I need to know whether that time is being well spent. I expected to see more end user features developed, but you're telling me this is not necessarily the intention at all.

I'm sorry but I can't communicate on this by myself. etotheipi is preparing a public statement on that matter. I have no ETA to provide either.

Alot rides on that statement for me.

[pf]

Off topic, but I think an updated roadmap should be forthcoming seeing as your target userbase is now different to your actual userbase. I'm spending my own free time trying to help you guys with this, I need to know whether that time is being well spent. I expected to see more end user features developed, but you're telling me this is not necessarily the intention at all.

I'm sorry but I can't communicate on this by myself. etotheipi is preparing a public statement on that matter. I have no ETA to provide either.

I'm not entirely sure why this is a big deal either. There already exists software out there to turn text into QR codes and vice versa. And Armory shows you all the text data you need for an unsigned & signed transaction. So do we really need it in Armory? Doesn't seem that urgent to me. With Armory combined with other QR <-> Text programs we got all we need, don't we?

It's like saying do why do we need power plugs for passengers in a commercial flight? There're already getting individual multimedia stations.

The answer is "it's not necessary but it's nice to have and benefits our image".

Makes sense.

About the roadmap, I'm curious: 1) can we expect the free product to be reliable going forward? 2) do your enterprise customers also use the same free product we all use?