Can electrum cold storage be attacked through transactions?

[thoushed]

I may sound a bit paranoid, but I ask the following:

I have a pc without a network card
does not have usb
it will never be connected to the internet
run a live version of linux with electrum 3.3.8 loaded and its signatures verified
I use it with cold signatures through QR codes

Let's imagine that I create a transaction from the online version of electrum on my usual PC.
I bring it to my pc offline through a qr code and sign the transaction
I go through another qr code back to the online pc and launch it to the bitcoin network verifying the addresses and amounts in each case.

is there any way to break this system and attack it?

I also use trezor for another part of my coins but I don't like to put all the eggs in one basket or company

thanks so much

[ranochigo]

Side channels through the analysis of time delays and CPU spikes when signing could present an issue if someone with plenty of resources is really really interested in your coins.

The main vulnerability would lie with how Electrum is designed, might somehow generate weak keys. It's a possibility but you bet that's one of the few areas (address generation process) we look at when inspecting the code. Besides with RFC6979, you don't have to worry about address reuse. And this could happen with hardware wallets with a faulty firmware as well.

Aside from the lack of physical protection, I think it's a decent set up for a moderate amount of coins. I have a similar set up to yours and I've felt pretty safe with it.

[thoushed]

Side channels through the analysis of time delays and CPU spikes when signing could present an issue if someone with plenty of resources is really really interested in your coins.

what do you mean with that? Can any relevant information be obtained through how the transaction was signed?


Could you tell me some way to make my system stronger?

I am simply curious to know how people with more experiences do it, I am not a very specialized person in the technical field but I try to learn everything I can

thanks so much

[jackg]

I think the main one could be someone changing the change address you're sending too to another address without you recognising something's wrong until it's too late... They could also add another output if you don't click the advanced/preview tab and check it (not sure if it pops up by default at that point though).

[ranochigo]

I think the main one could be someone changing the change address you're sending too to another address without you recognising something's wrong until it's too late... They could also add another output if you don't click the advanced/preview tab and check it (not sure if it pops up by default at that point though).

That's a good point. Make sure that in the payment tab, the excess are sent to the change address which is highlighted in yellow.

Sidechannel attacks are troublesome to do and as long as you close the curtains and don't let anyone gain physical access to your cold storage, I think that's sufficient and the difficulty of executing a sidechannel attack is still fairly high.

If you do an analysis on the power consumption of the computer, you could see a tiny spike in the power consumption of the device. That could leak the keys to the attacker. EM wave radiation, cold boot attacks all could pose a problem. I don't think any computer is specifically designed against that and even so, it would be difficult/impossible to remove that as an attack vector. I would be much more concerned about who would have access to the device than a side channel attack. I cited that as an example of how devices that are not specifically designed for such usage could have lesser safeguards (duh).

Tldr; I think if you're not saving too much money in the cold storage, t'll be pretty sufficient. I've relied on my raspberry pi to store my funds for the past few years and it has never failed me. I'll be getting a coldcard though, not because I don't trust my raspberry pi set up but it's just that I'm intrigued by one.

[o_e_l_e_o]

Could you tell me some way to make my system stronger?

I would start by using the most up to date version of Electrum. Is there any particular reason you are still using 3.3.8? Even Tails has updated to Electrum 4.0.2.

I would be most concerned about physical access to your set up. Are you using full disk encryption on your airgapped device? I would suggest LUKS.

[adaseb]

Basically there was a phishing attack on electrum that started a few years back. You could go to send a transaction and you will get an error that an update is mandatory, it provided a clickable link in the popup dialog and if you downloaded that software it would basically steal your seeds/private keys instantely. It leads to millions of dollars of funds stolen.

Now if you used cold storage and this happened to you, you would be safe. Because after you signed the transaction on the offline PC and tried to broadcast it on the online you would get an error. If you downloaded the fake software, there is no keys stored on your online computer, nothing to steal. Even if the thief was more sneaky and basically replied the "Send to" address to one of his addresses, you would realise this when you loaded the transaction on your offline computer and see that the address doesn't match up.

You are using 2 cameras for your QR codes? Or do you reuse the same camera back and forth. There is a slim possibility here that the camera might hold some private info, however this is very highly unlikely.

[pooya87]

Side channels through the analysis of time delays and CPU spikes when signing could present an issue if someone with plenty of resources is really really interested in your coins.

As far as I can tell Electrum is using libsec256k1 library for its signing operations and this library is focused on preventing such attacks by making everything fixed time. Although more investigation into the library is needed (since I am not fully familiar with it) but this type of attack is not possible on it.

[o_e_l_e_o]

Because after you signed the transaction on the offline PC and tried to broadcast it on the online you would get an error.

I don't follow you here. Why would he get an error? If he signs a malicious transaction without paying attention on his airgapped computer and moves it back the online computer, it will broadcast just fine. Cold storage only protects from this attack (and many other attacks) provided you double check the transaction on your airgapped device before signing. If you just sign things blindly and then broadcast them, then the cold storage is no better than a hot wallet.

[NotATether]

As far as the QR core transportation is concerned, vulnerabilities cannot be stuffed into a QR code itself because it just encodes a query string (something like "address=bc1qabcdefg&amount=0.01&label=My address"), there is nothing an attacker can put in there to implant malware in Electrum, although they can of course change the address which'll generate a different QR code causing you to get scammed.

You did verify the checksum of the live ISO you downloaded, right? There have been cases of Linux distribution websites getting hacked and having malicious ISOs places instead. Somebody could place a package in the operating system specifically for snooping on Electrum private keys.

Sidechannel attacks are troublesome to do and as long as you close the curtains and don't let anyone gain physical access to your cold storage, I think that's sufficient and the difficulty of executing a sidechannel attack is still fairly high.

If you do an analysis on the power consumption of the computer, you could see a tiny spike in the power consumption of the device. That could leak the keys to the attacker. EM wave radiation, cold boot attacks all could pose a problem. I don't think any computer is specifically designed against that and even so, it would be difficult/impossible to remove that as an attack vector. I would be much more concerned about who would have access to the device than a side channel attack. I cited that as an example of how devices that are not specifically designed for such usage could have lesser safeguards (duh).

Different types of side channel attacks can be mitigated in different ways. For the attack that listens on keyboard taps and non-audible sound waves (acoustic side channel attacks) can be defeated by playing audible white noise near the airgapped computer.

Cache side channel attacks that rely on reading the processor's internal cache don't work if you're not running in a VM, or some cloud server running in a VM, because such attacks need the memory pages containing Electrum to be mapped in VMs as shared pages. (Running the OS unvirtualized also partially breaks Meltdown from 2018, because it uses a cache attack after a race condition.)

In a timing attack you are trying to guess state by correlating it with execution time of that step, on the assumption that different speeds indicate different states. Slowing down the fast parts of ECDSA which derive private keys and make signatures for transactions to make all steps take the same time can prevent this but you'd need to update the libsecp256k1 library bundled with the OS. The performance drop shouldn't matter because Electrum is the only thing being ran on an airgapped computer.

Differential fault analysis that relies on heating up, overclocking or otherwise making the CPU unstable some other way can be prevented by not overclocking the CPU, and if it already has heating problems, replace it with a new one.

There aren't any known mitigations against power analysis attacks because Intel, and possibly AMD, provide opcodes for monitoring the processor's power consumption, and there isn't a way to disable that. This method requires an oscilloscope anyway so I guess if you see a big ol' oscilloscope sitting next to your airgapped machine, that should obviously ring some alarms. They only work from close range anyway, and I don't think they can even get close enough to the CPU because the desktop tower case is too big (hopefully the airgapped computer is a desktop).

So In short, you gotta:

- Play reasonably loud white noise
- Slow down libsecp256k1
- Buy a really big desktop case, and disable the kernel modules for USB and serial ports and everything else you don't need
- run Electrum on a physical OS
- Leave your CPU clock speeds alone

And that should protect you from most side channel attacks. Some of these are probably outside of your abilities though, it would be easier if someone made a live OS specifically designed for running Electrum.

[thoushed]

Could you tell me some way to make my system stronger?

I would start by using the most up to date version of Electrum. Is there any particular reason you are still using 3.3.8? Even Tails has updated to Electrum 4.0.2.

I would be most concerned about physical access to your set up. Are you using full disk encryption on your airgapped device? I would suggest LUKS.

Thank you very much for the reply

i used 3.3.8 because every time i want update electrum, i need create a cd and destroy it.

The computer does not have any hard disk, it is a live system started in a USB, every time I use it I disconnect from the current to erase all the data stored in RAM, and the computer and USB are well protected from possible physical attacks

the theory says that no data is saved on the usb anyway

[thoushed]

As far as the QR core transportation is concerned, vulnerabilities cannot be stuffed into a QR code itself because it just encodes a query string (something like "address=bc1qabcdefg&amount=0.01&label=My address"), there is nothing an attacker can put in there to implant malware in Electrum, although they can of course change the address which'll generate a different QR code causing you to get scammed.

You did verify the checksum of the live ISO you downloaded, right? There have been cases of Linux distribution websites getting hacked and having malicious ISOs places instead. Somebody could place a package in the operating system specifically for snooping on Electrum private keys.

yes, I checked the iso image

Anyway, even if there was a malicious software in the linux iso that could spy on the keys, how could it send them out of the computer if it will never have access to the internet and the only information that comes out is via QR, with a transaction?

no usb
no network
this computer will never be used for anything else

[ranochigo]

yes, I checked the iso image

Anyway, even if there was a malicious software in the linux iso that could spy on the keys, how could it send them out of the computer if it will never have access to the internet and the only information that comes out is via QR, with a transaction?

no usb
no network
this computer will never be used for anything else

Generating weak keys. In theory, the OS could compromise Electrum and create a deterministic seed which would allow the attacker to compromise your funds without any connection to the internet. I don't find this much of a concern (if at all), I've never seen anything like this and Electrum might have implemented sanity checks (or the OS) to thwart such attempts anyways.

It doesn't hurt to validate the .iso file anyways.

[o_e_l_e_o]

i used 3.3.8 because every time i want update electrum, i need create a cd and destroy it.

Fair enough. Electrum is frequently updated with bug fixes though, some more important than others, so I would have a low threshold for burning a new CD with an updated copy of Electrum on it.

The computer does not have any hard disk, it is a live system started in a USB, every time I use it I disconnect from the current to erase all the data stored in RAM, and the computer and USB are well protected from possible physical attacks

Follow up question then: Do you have persistent storage which is saving your wallet file, or are you restoring it from seed every time you want to use it?

Generating weak keys. In theory, the OS could compromise Electrum and create a deterministic seed which would allow the attacker to compromise your funds without any connection to the internet.

Could be mitigated by generating your own entropy by flipping a coin and converting it to a seed phrase manually, although you would need to also confirm that the private keys Electrum generates for you are indeed derived from the seed phrase you entered.

[NotATether]

Generating weak keys. In theory, the OS could compromise Electrum and create a deterministic seed which would allow the attacker to compromise your funds without any connection to the internet.

Could be mitigated by generating your own entropy by flipping a coin and converting it to a seed phrase manually, although you would need to also confirm that the private keys Electrum generates for you are indeed derived from the seed phrase you entered.

(Is more of a reply to ranochigo's post, but system entropy is also used to derive private keys)

The kernel has its own entropy source, an ISO that fails the checksum check could have a backdoor implanted in the kernel random number generator /dev/random to discard entropy from hardware and return its own predictable entropy. This can even affect a verified version of Electrum, along with all other wallets like Core, even if a lot of programs might have already been read from /dev/random, as long as the sequence of bits generated since boot can be calculated. Just know how many bits Electrum uses for each secret and iterate through the entropy brute-forcing I..I+N bits with I beginning from 0 up to the total number of bits generated.

The problem here is that there is no system call to give the kernel RNG your own random bits to use. Even if there was, you wouldn't be able to provide it securely (It would have to go through the terminal, and then bash).

[thoushed]

Follow up question then: Do you have persistent storage which is saving your wallet file, or are you restoring it from seed every time you want to use it?

i dont have persitent storage, restore the seed manually.

thank you very much for response.

[thoushed]

Generating weak keys. In theory, the OS could compromise Electrum and create a deterministic seed which would allow the attacker to compromise your funds without any connection to the internet. I don't find this much of a concern (if at all), I've never seen anything like this and Electrum might have implemented sanity checks (or the OS) to thwart such attempts anyways.

It doesn't hurt to validate the .iso file anyways.

true I had not thought about it, thank you very much for giving me that point of view

although normally I use a passphrase and check with a test seed and on another pc with electrum if it derives different addresses.

(Is more of a reply to ranochigo's post, but system entropy is also used to derive private keys)

The kernel has its own entropy source, an ISO that fails the checksum check could have a backdoor implanted in the kernel random number generator /dev/random to discard entropy from hardware and return its own predictable entropy. This can even affect a verified version of Electrum, along with all other wallets like Core, even if a lot of programs might have already been read from /dev/random, as long as the sequence of bits generated since boot can be calculated. Just know how many bits Electrum uses for each secret and iterate through the entropy brute-forcing I..I+N bits with I beginning from 0 up to the total number of bits generated.

The problem here is that there is no system call to give the kernel RNG your own random bits to use. Even if there was, you wouldn't be able to provide it securely (It would have to go through the terminal, and then bash).

If the cold system will generate weak keys, if it uses the same seed and a passphrase in that system and in another pc, different keys should be generated, right?

[o_e_l_e_o]

i dont have persitent storage, restore the seed manually.

If you are accessing your seed phrase regularly, then presumably it is stored somewhere not too difficult to retrieve. It seems to me, then, that the most likely way for your set up to be compromised is by someone else accessing your seed phrase. Only you will know how likely or unlikely this is given your current set up, and whether you need to take any additional steps to mitigate against this risk.

If the cold system will generate weak keys, if it uses the same seed and a passphrase in that system and in another pc, different keys should be generated, right?

Not necessarily. If there is a vulnerability in the process used to generate the initial entropy, such that Electrum bases the whole key derivation process on pre-determined or deterministic entropy, then the seed phrase it produces will generate the same keys on other machines, while at the same time being known to the attacker. This is why I suggested that best way to mitigate would be to generate you own entropy by flipping a coin.

[thoushed]

Not necessarily. If there is a vulnerability in the process used to generate the initial entropy, such that Electrum bases the whole key derivation process on pre-determined or deterministic entropy, then the seed phrase it produces will generate the same keys on other machines, while at the same time being known to the attacker. This is why I suggested that best way to mitigate would be to generate you own entropy by flipping a coin.

yes, the entropy of the seed may be weak, but if I add a passphrase using the diceware list, with 6 word, will I be safe?

thanks for your reply

[o_e_l_e_o]

yes, the entropy of the seed may be weak, but if I add a passphrase using the diceware list, with 6 word, will I be safe?

If you assume that your seed is known, then the security of your coins depends entirely on your passphrase. 6 words from the diceware list is equal to 7776⁶ bits of entropy, which is roughly equivalent to 2^77.5 bits of entropy.

This is probably safe enough, but it is worth noting that it is significantly less safe than a secure 24 word phrase on its own, which provides 2²⁵⁶ bits of entropy.

To try to get a feel for the numbers involved. 7776⁶ is

Code:

221,073,919,720,733,357,899,776

Where as 2²⁵⁶ is

Code:

115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936

Also, how are you backing up your passphrase?