Topic: Request for comments: Developing guide for very high-security bitcoin storage (Read 2456 times)

Hmm, looks like a nice tip to create a clean and secure Bitcoin address. Can I apply this trick while creating a Bitcoin vanity address?

Thanks -- these suggestions seem particularly interesting -- will make note of them.

Yes, absolutely better to physically remove wireless capabilities.  Older computers are better for this purpose, with Pentium-era laptops being a more than sufficient. As far as open BIOS and CPU... you have to ask yourself on an isolated machine, what is the 'sophisticated malware' embedded in the BIOS or CPU capable of doing? Exhilarating keys... perhaps, but being aware of the higher level software to the extent of being able to compromise different applications (which most likely didn't even exist at the time the supposed malware was written) in an identical fashion, which in this example would have to mean making the multiples instances give the same incorrect address derivation, I don't think is a plausible vector.

But yes, a modern machine where the wireless capabilities cannot be disabled, that is certainly riskier. One solution is to go somewhere with no surrounding wireless signals, like a cabin in the woods.




Yeah, my post didn't address a procedure for spending from the secure private keys.  You are right that contaminated drives are a risk.

For big balances, I would manually type an archived key into a clean, offline computer that had wallet software capable of generating an offline-transaction. Compare the transaction to one generated by different software. Copy onto a fresh thumb drive, and bring over to an online computer to broadcast the transaction.

For the truly paranoid, use multiple clean intermediary computers, with different operating systems. Copy the transaction onto the intermediary computer, and then copy it onto a clean thumb drive. The more hops, the less likely the private key is secretly getting dragged along with the signed tx.

There is no clean pc if the BIOS and CPU firmware is closed source.

The wireless should be detached physically, disabling it in the BIOS is not good enough, a sophisticated malware that is embedded in the CPU can easily send out keys through the wireless port covertly, wtihout the host OS noticing it. It would be totally passive, no way to detect it.


Can't comment on the crypto & key generation part, that is not my area, but it seems flawed to manually mess around with the key.




A thumb drive can easily have a malware in the MBR sector that can just save your secret key there and wait for the PC to connect to the internet and send it out covertly.

There were actual cases of this happening at some corporation, some corporate secrets leaked this way from a secure offline computer, look it up in the news.

A short word of 4 - 6 characters does reduce the entropy over a truly random key, but there would still be so much entropy left that it wouldn't make a practical difference. Using the OS's RNG is a good idea, and I would still strongly suggest making some alterations by hand.

Also a potential side channel, its probably not much, but a key with a word in it is easier to guess than a key thats entirely random. If you dont trust the crappy java prng, just use the one the OS provides.

i especially like the part i bolded. word could be a hint as to what that key/addy is for, contains, whatever.

more work but more potential usefulness.

I think, the endpoint of security for Bitcoin is still the computer hardware part. It is no problem to use dice to create a secure entropy and paper as a storing medium (which burns pretty good and can be confiscated - which is something that a cold storage shouldn't have), but Bitcoin is still relying on closed source computers. Sure, regular people could build a open source power supply from scratch, but creating a open source processer is pratically impossible, so everyone who stores Bitcoins, will have to trust a few big electronic part manufacturers, that they are not storing your freshly created offline keys anywhere. So the Bitcoin system is not 100% trustless at all.

Check https://en.wikipedia.org/wiki/List_of_open-source_hardware_projects

Even using open source hardware doesn't protect you from chip manufacturers etc, so we still have to trust alot.
Also as long as the internet is something, that a few people can simply shut down, we have to trust a lot, that they don't.
You might still have your Bitcoins in your wallet then, but you will not be able to send them to another wallet - not even your own one.

The guide seems reasonable, and nice to see some work being put into this.

Here is my method for secure cold storage:

1) Start with clean, offline computer, with wireless capability disabled

2) Load a few different wallets and pieces of address generating software onto the computer

3) I used Bitaddress.org as my key generator. Crappy java-script RNG? No problem. Did I check the sigs? Nope. I let it generate a key pair, and use that as the starting point.

4) I modify the private key by hand! I make about 7 changes, including deletions, additions, and substitutions. I also add a short word to make visual confirmation easy. I just make sure the key ends up being the same length as it started out.

5) I import the modified private key into several other wallets, and confirm that every generated address is the same.

6) I archive private keys as appropriate, via encrypted thumb drives and paper backups which I cut (with scissors) into fragments and distributed.

7) The addresses I isolate and make available to online machines.


The nice part about this method is, between modifying the private keys by hand, and cross referencing address generation among different pieces of software, the opportunity for malicious software to compromise funds is severely limited.

But the ARM processor is not open sourced.


I could but I think it would be an overkill. Certainly as you have said for holdings of 100,000-500,000$ I would say that this guide is ok. If a person has more than that, he might go for a full manual key creation because certainly no digital machine can be trusted 100%. And there are other attack vectors too.

I would rate the guide 7/10, it's still orders of magnitude better than what the average bitcoin user has, and a thief would always start with the low hanging fruits.


When it comes to side-channel attacks, there are hundreds of possible attack vectors, and it's nearly impossible to defend against all. People should start with the most vulnerable ones, and defend against those first.

People should also build their own threat models, and see what kind of defense they need or don't. Not everyone has a lot of coins, and for smaller holdings, some of this stuff could be an overkill.

It's a pretty standard formula.  You can get it from the information theory entropy article on wikipedia.

Oh, this was targeted at developers of hardware wallets to give the hardware itself security against power analysis.
Other security possibilities are to enclose the chip in a thick case of a highly conductive metal to stop electromagnetic waves, add an ultrasonic noise source, much more powerful than the legitimate chip to foil acoustic cryptanalysis, and add a small TRNG to continually seed the PRNG.
Also, does the Trezor show the transaction in full before it is signed?
It most certainly should.
Also, it should be hard to confirm by accident (pin should be entered.)

Good starting point to foil power analysis attacks but couldn't it be designed in such a way that it is built-in or automated, part of security trigger?

I think we must remember that this guide is designed for newbies - any recommendation must put this consideration at foremost thought.

You should evaluate if your software decisions are consistent with best practices for selecting cryptographic software (see a talk I gave on the subject (third section) at https://youtu.be/Gs9lJTRZCDc?t=2240); or if you're taking potentially dangerous code that you found on the internet because its superficial feature set sounded good.

Thanks for your comments.  Can you propose a more secure alternative?  I'm curious if you have something in mind.  Keep in mind the computer in question needs to get the key generation software on it somehow, and we certainly don't want to accomplish that by connecting it to a network.


I saw that, thank you!  It will take us some time to review all comments, but look forward to doing so.


Having everything open source definitely helps, but open source can have important vulnerabilities too (e.g. Heartbleed).  And side channel attacks, like the power analysis attack you linked.  Perhaps that can be fixed, but what other undiscovered vulnerabilities might be out there?  That USB connection just creates an incremental risk any way you look at it. 

Take a look at the code yourself: https://github.com/trezor/trezor-mcu

You can compile from source and flash it to your device, so everything that is there is what is part of the Trezor firmware.

Is it all open source though? That is the big question, because usually there are always bits and blobs that control certain aspects of a chip that are closed source by design, and often they can't be reprogrammed at all, not by the vendor, but by the patents and other design secrets of the chip designer.

There are no open source processors currently for PC, that are feasible to use for general use, for example.


Thank you. My crypto skills are not that good, that is not my area of expertise.

Can you reference this formula that you have used?

You wouldn't need 600 bits, unless the die is very biased.

The entropy is equal to -sum(p(n) * log2(p(n)). 

Basically, the sum of the log of the probability of each state weighted by the probability of each state.

A fair coin would have 2 states with p = 0.5.

That gives

sum(0.5 * log2(0.5)) = -[0.5 * (-1) + 0.5 * (-1)] = 1 bit

An unfair coin with 60% chance of heads gives

[0.4 * log2(0.4) + 0.6 * log2(0.6)] = -[0.4 * (-1.32) + 0.6 * (-0.737)] = 0.971 bits

This means that a 60% coin gives you 97% of the entropy of a fair coin.

A fair dice gives you 2.584962501 bits worth of entropy. 

A dice with a 20% chance of a 1 and a 16% chance for the others gives.

[0.2 * log2(0.2) + 5 * 0.16 * log2(0.16)] = 2.57947 bits

That is pretty large loading and still barely effects the entropy.

A die with a 50% chance of a 6 and 10% of the others gives

[0.5 * log2(0.5) + 5 * 0.1 * log2(0.1)] = 2.16 bits

If you rolled one dice for every 2 bits you want, then you would have to be using very low quality dice not to get the entropy you require.

If the result of 80 dice rolls was run though a hash function, the output would have at least 160 bits of entropy and likely close to 206 bits.

The easiest way to eliminate power analysis is by using a capacitor and a resistor inside the wallet:

(1) Connect capacitor to USB to charge.
(2) Disconnect capacitor from USB.
(3) Connect capacitor to chip for some amount of computation.
(4) Disconnect capacitor from chip before it can possibly run out.
(5) Connect capacitor to resistor to drain all excess energy.
(6) Disconnect capacitor from resistor and loop back to step (1).

This prevents the computer from monitoring power use.

I will read it later, but thumbs up for OPs first post/topic already. Well done.