I've just ordered a cheap-o netbook on Amazon, with the intention of installing a Linux distro, and turning it into a permanently-offline high-security machine for sensitive tasks.

However, I'm no security professional, and I need some advice and tips, now that I'm finally undertaking this task. Amongst any general advice (or links to useful writeups!) you may have, I'm specifically curious about:

  • How do I install software, while keeping the machine ‘cold?’ For instance, in addition to the obviously-necessary updates and security patches for existing software, how would I go about securely installing new software if I found a new purpose to which I'd like to put the machine? (i.e. signing Bitcoin transactions, or something.)
  • What are the most security-conscious methods for transmitting ‘hot’ information to /from the machine? i.e. given recent concerns about USB-firmware exploits, how might you suggest I go about getting signed Bitcoin transactions to the 'net … or getting content I want to encrypt with my master-key to the cold machine?
  • Are there particular software choices you'd suggest? (i.e. which Linux distro, what software for managing keys, etceteras.)

(I intend to do a write-up of what I learn here, once I've worked through this process, to help others set up a relatively secure cold-storage for their Bitcoin and master signing keys.)

(Cross-posted here: http://redd.it/2k6jtw)

closed as too broad by Mark, Xander, AJ Henderson, TildalWave, schroeder Oct 25 '14 at 18:05

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


When you install the Linux OS, you have to assume that the software is the genuine one, free of backdoors. Linux distributions tend to use digital signature on packages; a digital signature does not guarantee absence of backdoor, but it prevents undetected alterations in transit: you know that the package you get is the one produced by the packager. Since you must make this basic assumption, the problem becomes one of networking: how do you get the packages into an offline system ?

There are several possibilities:

  • Burn a CD or DVD. On the plus side, most distributions can be obtained as a ready-to-burn ISO image, so you just have to make sure that you get the right one (download, compute the MD5 hash, compare with the value obtained from the source site over HTTPS), and you have a whole set of packages. On the minus side, a netbook won't have a CD/DVD reader, so you have to hook up a USB-driven reader.

  • Transfer the packages with some medium, e.g. an USB disk. As you note, this raises the possibility of a malicious firmware. An alternative is to use a CD/DVD writer, which is a lot more cumbersome, but arguably safer since a CD or DVD does not contain any firmware. In older times one would have used a magnetic support like Iomega Zip drives, but they have become rare nowadays, and are very expensive (in particular considering the size of individual disks: 100 MB... which is a lot when you think about it, but can be cramped with modern fat software).

  • Use the network. Of course, that's challenging on an offline machine, by definition. You may make a trade-off, with a machine which is mostly offline, but that you occasionally plug to the Internet. You would then want to use a direct ethernet cable, connected to another machine that will do some NAT and firewalling. That way, your security relies on the bridge machine not to be under hostile control at the time you connect.

One may note that for a truly offline machine, that never goes connected, then installing security fixes loses most of its relevance: a patch that prevents remote code execution in some server software is not needed if the said server software is never launched. You could simply run off a "base" set of packages, that you installed from an official ISO image initially.

Network attacks are definitely thwarted when there is no network at all, but you will want to consider other types of attacks, in particular wholesome theft of the device. This is a netbook; it is easy to carry and run away with. On the other hand, you will not keep it with you at all times (e.g. when you take a shower) so there will be periods when the device could be stolen. In that case, you want to make sure that the machine contains no intelligible secret when you are not using it. This points at encryption, unlocked with a master password that you keep in your head, and accept to type when you want to access the data.

You can do encryption on a per-file basis, in which case the tool of choice would be GnuPG (the opensource PGP implementation). To really use it safely, you have to use some care:

  • Don't configure swap space on your machine. You must run on physical RAM only. Most Linux distribution will want to setup some swap upon installation, so you may have to prevent it or deactivate it afterwards. Not using swap prevents potentially secret data elements from leaking to the physical medium underlying swap space: RAM contents disappear for good about one minute after poweroff.

  • Use a RAM-based filesystem. When GnuPG decrypts a file, it will write the cleartext as another file, and you don't want that file to hit a physical medium. Instead, you must make sure that you work in a filesystem backed by physical RAM only (type man mount, then search for tmpfs). This implies some care: encrypted files are stored on the disk, but when you want to decrypt them, you first copy them to a RAM-based filesystem and do the decryption/re-encryption there.

  • Make sure to select a strong password. That is, a random password, not a witty password. See this question for guidance.

You may have noticed that not using swap, and then carving up a chunk of physical RAM for a filesystem, implies higher RAM usage. If your cheap netbook has little RAM, then this may be a problem. A "raw" Linux can run in very little RAM (my first Linux could boot and run a graphical interface in as little as 8 MB of RAM without swapping, but it was in 1994). However, modern Linux distributions tend to eat up a lot of RAM (though not using a Web browser -- since the machine is offline -- will make your life much easier). In practice, I use Lubuntu; for the purposes you envision, you should be able to fit a comfortable Lubuntu with a 400 MB RAM-based filesystem in a netbook with 1 GB of RAM.

An alternative is full-disk encryption. If you use full-disk encryption, you can use swap and do not need a RAM-based filesystem. However, full-disk encryption will have to be done at installation time, and you don't get as much flexibility with regards to algorithms and tools.

Don't forget backup. You don't want to see your secrets stolen, but you don't want to lose them either, e.g. if the netbook, on day, refuses to boot. There again, you will need either encryption or physical protection (keep these CD in a safe), or both.

You will want to avoid forgetting your master password as well. For that, write it on a piece of paper, put the paper in a sealed envelope, and the envelope in a bank safe.

  • 1
    Wow. A lot here. You're amazing! It's hard to call something an “accepted” answer in this format; but I think you've earned it. :P – ELLIOTTCABLE Oct 27 '14 at 9:42

I would suggest using a live-Linux-system, that is completely readonly. I would suggest using a USB memory with a physical write-protect switch, that prevents any modifications to the system (here is one: http://www.amazon.com/Kanguru-Flashblu-4GB-Flash-Drive/dp/B0012WDFV6/ref=pd_sim_e_1?ie=UTF8&refRID=1XS70KSFXBNH0PFQF3T9 ). Some laptops have internal USB ports so the write-protected USB memory could easly be integrated in the laptop, but else, you could use a USB 2.0 to miniPCIe adapter, ( like this: http://www.drivestar.biz/converter-mini-pcie-to-usb-20-p-3414.html ) to replace the Wifi card with a write-protected drive. Whatever you do, Always remove the Wifi card and other Connection methods to computer. If you then use Armory or similiar bitcoin client, you can even make the keyseed read-only.

Then I would suggest using a "memory" smart card to transfer unsigned transactions to Cold computer and take the signed transactions from Cold to hot.

A memory smart card does not have any protection of its content, but its advantage is that the memory space is SMALL, so it would be cumbersome for a virus infection to be stored inside a memory smart card. Another thing is that data on smart card is NEVER EVER executed automatically by a OS, it will Always be treated as data. A third advantage is that you have very limited storage space on a memory smart card making buffer overflows simply impossible since you can allocate a buffer that is larger than the smartcard without any RAM problems.

I would suggest using a ExpressCard Smartcard reader, that can be inserted and then permanently affixed to the computer with expoxy glue or using tamper-resistant labels, OR making sure to gain a laptop computer with a built-in smartcard reader.

There you have a good Cold storage computer.

To make the initial setup of a Cold storage computer, boot a regular live-system off a standard USB drive, to use to "master" a new live-CD system on the write-protected USB drive (ofc with its write protection turned off). The mastered system should of course only contain the live-OS and the software used for signing (OpenSSL, Armory etc) AND generated keys. Since the computer is offline, the keys you generate on the "insecure" regular live-system will NEVER leak. Then you remove the memory you stored the regular live-system on. But IF you noticed the key leaked or you did a mistake, then its as easy as not using that key, and start over from step 1. So the key becomes secret once you decide the key is secure and unleaked and you decide to start using it. Before that, the key isnt even a key, its just a bunch of random bytes.

Destroy this USB memory, either physically, or overwriting the data with DBAN. (Note: NOT the write-protected USB memory, you destroy the USB memory used to boot the regular live system)

After this, you switch on the write-protect switch on the USB memory INSIDE computer, Before you boot up the live system for the first time. After this, you boot up the live system, then you VERIFY that all files are intact and unmodified. You could for example check SHA hashes of the armory client, check that OpenSSL is the official one, and check other Components of system until you are Confident that nothing modified the system.

Since the USB memory is now write-protected - NOTHING can change the content. Seal the write-protect switch with some tamper-resistant security tape, and then seal the doors on the laptop with tamper-resistant security tape. Seal all screw holes using tamper-resistant security labels. Now you are Confident that even someone with physical access to the computer cannot covertly install any software on the computer. Since its a laptop and all doors/screws sealed, they cannot even install keylogging hardware since the keyboard screws are sealed aswell.

Use expoxy glue to seal all ports on the computer, but leave one USB-port open in case the system goes bad and you need to recover/reinstall something. SEAL this open USB port with a tamper-resistant label.

Backup your secrets by displaying them on screen and Writing them down carefully on archival paper with a permanent marker pen. Then store this paper in a safe or something. A bank box is even better since all accesses to a bank box is audited. On Armory client, you simply write down the Words displayed. The Words contain all information required to restore the key. Of course, you can also write down the seal numbers on this paper, making a good record that you can backtrack to INCASE you suspect someone did replace the taper-resistant labels.

There you have a very secure setup.

  • I've a couple thoughts, but I'll stick to the most interesting one, to me, for now: is there any data supporting the idea that the write-protect switch on USB sticks actually means anything? Wouldn't that be mediated via the (assumed-compramised) firmware, too, anyway? – ELLIOTTCABLE Oct 27 '14 at 10:13
  • The stick I linked to is meant to be secure, thus that the write-protect switch will also prevent firmware update if there would be firmware update capabilities in the memory. Some memories are even constructed in the way that it will physically break the write enable line to the flash chips, making writes simply impossible while the switch is activated. The same thing is not true for those off-the-shelf cheap memories with WP switch, that may, yes, be vulnerable to BadUSB. – sebastian nielsen Oct 27 '14 at 12:49
  • That's so cool, if true. Can you provide any links regarding the hardware switch protecting the firmware? It seems so much more likely that the control is in the firmware, and that the data-writeprotect-switch signals that firmware … in which case it wouldn't be protected. /= – ELLIOTTCABLE Oct 27 '14 at 20:12
  • I dont Think Kanguru which is a Company that really does SECURE usb memories, would make a possibility to bypass the hardware switch in software. They even have one USB3 variant with signed firmware. And if it would be a real firmware update, it woulnt be hard to ask the end user to turn off write protection Before firmware update. – sebastian nielsen Oct 27 '14 at 22:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.