Improving Offline Wallets (i.e. cold-storage)

[meefozio]

Has anyone mentioned burning the transaction files to CD-R or CD-RW to transfer them between the online and offline computer?  Given that you control exactly what files will be burnt to the disc and that it's finalized/locked immediately afterward, isn't that one way to achieve certainty that you aren't accidentally transfering malicious files between the two machines?

I know it's not an ideal solution, but it's a solution nevertheless and seems pretty simple for the overly-protective user.

Thoughts?

[kjj]

Heh.  Autorun.

Also, why do you assume that you have total control over what gets written?

[etotheipi]

i didn't see this explicitly stated in the thread, but is the goal with using serial ports for communication to avoid firmware exploits on the NICs?

never a good idea to store valuable data on a machine that doesn't use disk crypto, it has saved my ass on several occasions.

The disk crypto doesn't help in this case, because either (1) you use full-disk-encryption, which will be unlocked while the system is on, so a "copy" will copy the unencrypted data, or (2) The wallet file is encrypted only, in which they only need to keylog your passphrase to get it.  Though, I have received some good ideas for helping with keylogging, but any malware advanced enough to compromise your offline computer could easily pull your crypto key out of RAM next time you unlock the wallet. 

The goal is to avoid getting to that point at all:  a serial connection that doesn't possibly induce any subsystems to kick in and try to help out.

suffice it to say i have spent many moons doing computer security work and i cannot get a good idea of what your threat model is here.

in order to spend your coins, at some point the corresponding wallet must be on a computer, which i am assuming is offline in your threat model. in order to have some reasonable assurance that the computer's drive has not been tampered with while off, presumably stored in a safe or similar, you should use disk encryption. to suggest that disk encryption doesn't help reduce the chance of a compromise here is incorrect, afaict.

of course, if your machine is rooted, the attacker has DMA. the usual means of defeating keyloggers is authentication tokens, but that is only of limited use on an offline machine.

I never said that disk encryption is pointless.  But Armory already encrypts your wallet, and guarantees that if your wallet is created encrypted, the unencrypted keys never touch the disk.  By all means, you need encryption, but full disk-encryption is mostly redundant here.  In fact, in some environments, it's inferior -- if you were to use full-disk encryption and unencrypted wallet files, then you are protected the same when your computer is off but the encryption is completely useless while the computer is on (so it can run the OS and access your files).  Someone who gets on your compute for 1 minute can put in a USB key, and copy off the [unencrypted] wallet file to their key.  Ditto for serial.    At least with Armory encryption, the file on disk is always encrypted and inaccessible even when the computer is unlocked. 

The counterpoints to these thoughts are:  just hedge and use both -- disk encryption and Armory encryption.  And in the end it may not matter--anything advanced enough to get to your offline system is probably advanced enough to pull your private keys out of RAM when you unlock your wallet to sign a transaction.  No disk encryption can protect against that.

The security environment is this:  you have an offline computer setup securely, and it has not been compromised in any way.  You have a verified version of Armory installed and know it works perfectly (of course).  However, you assume an attacker has full control of your online computer, and knows you will be using <insert transfer method here> to move data back and forth between your [compromised] online computer, and you're not-yet-compromised offline computer.

If it's a serial connection that's not done correctly, they grab your Firefox password file and try every entry to TTY login to the offline machine.  Once there, they grab the encrypted wallet, and start trying to brute force it (probably also related to one of your firefox passwords...).  Or if that's not enough, they keylog your passphrase and send it back over the serial line to the online computer (which is compromised).

Similarly, if your transfer method is USB keys, there's undoubtedly lots of ways to exploit autorun.  Put a carefully crafted file on the USB key with a payload that gets executed when you plug in the USB key, and it carries your wallet out with it when the user brings the USB key back to their online computer. 

Any mention of Armory flaws, or initial install security is mostly out-of-scope.  We assume the user installed the correct software offline and that the software itself performs exactly as expected. 

[meefozio]

Heh.  Autorun.

Also, why do you assume that you have total control over what gets written?

Because you load whatever CD-writing software you prefer, then you manually add the transaction file.  The disc must be blank in order to write to it, and unless the malicious code has also compromised your burning software, only what you specify to be written will be written.  And once it's written, the disc is physically unwritable.

Is this not currently the best method to transfer the transaction files thus far?  How about it, etotheipi?

[kjj]

Heh.  Autorun.

Also, why do you assume that you have total control over what gets written?

Because you load whatever CD-writing software you prefer, then you manually add the transaction file.  The disc must be blank in order to write to it, and unless the malicious code has also compromised your burning software, only what you specify to be written will be written.  And once it's written, the disc is physically unwritable.

Is this not currently the best method to transfer the transaction files thus far?  How about it, etotheipi?

Not just the writer software.  Also the driver, the host interface driver, the driver's firmware, the host interface's firmware, the BIOS, etc.  If we are assuming a clever attacker, we have to assume that one or all of those is owned.  If we aren't assuming a clever attacker, then there are WAY easier ways to move files around.

I still prefer the serial port approach.  If a getty is running on a serial line, then armory won't be able to open it.  And if armory can open it, then the getty can't run.  If armory is the intended use, then the problem will be apparent soon enough.  For extra paranoia, we could make an armory distro with a stripped down inittab.  Hell, add a SE policy to disallow anything but armory from opening /dev/ttyS*

[Rampion]

Heh.  Autorun.

Also, why do you assume that you have total control over what gets written?

Because you load whatever CD-writing software you prefer, then you manually add the transaction file.  The disc must be blank in order to write to it, and unless the malicious code has also compromised your burning software, only what you specify to be written will be written.  And once it's written, the disc is physically unwritable.

Is this not currently the best method to transfer the transaction files thus far?  How about it, etotheipi?

Not just the writer software.  Also the driver, the host interface driver, the driver's firmware, the host interface's firmware, the BIOS, etc.  If we are assuming a clever attacker, we have to assume that one or all of those is owned.  If we aren't assuming a clever attacker, then there are WAY easier ways to move files around.

I still prefer the serial port approach.  If a getty is running on a serial line, then armory won't be able to open it.  And if armory can open it, then the getty can't run.  If armory is the intended use, then the problem will be apparent soon enough.  For extra paranoia, we could make an armory distro with a stripped down inittab.  Hell, add a SE policy to disallow anything but armory from opening /dev/ttyS*

An Armory distro would be great. Super secure and easy to use.

[harding]

Hi, Alan, and thanks for the wonderful work you do on Armory.

A portable media player which connects to the host computer in MTP mode might offer reasonable security and convenience:

    + Files need to be downloaded from the device to the host computer's OS before processing, so files accessed through MTP cannot be automatically executed on Windows[1] or Linux[2], blocking most viruses.

    + There are plenty of cheap MTP-enabled used MP3 players on eBay.

    + Uses standard USB connections found on practically all computers.

    + Runs at high speed for transferring media files, so small transaction info will transfer almost instantly.

    + On Windows and novice-friendly Linux distros, unprivileged apps can by default write to MTP so Armory doesn't need root access.

    + Open source MTP library and tools for Linux: http://libmtp.sourceforge.net/

    + Possible sample code for MTP support on Windows: http://addons.songbirdnest.com/addon/172

    - GNOME Virtual FS (GVFS) and probably Windows may autoload thumbnails and other metadata from MTP devices, creating possible attack vectors.  Removing the MTP GVFS module on an offline Linux machine would prevent autoloading there and not otherwise affect the user (unless he used MTP for other things on that machine).

Also notable:

    +/- Wikipedia seems to say that Windows can't do arbitrary autorun from non-volume devices such as MTP[3], but I recommend testing for verification.

    +? There's MTP over Bluetooth[4], which may provide an enhancement at minimal extra development cost (your time) for those users willing to tolerate a network connection.

I knew practically nothing about MTP an hour ago and the above points summarize everything I now know, so take it all with a grain of salt.

Thanks again for your work,

-Dave

[1] http://portableapps.com/node/3292
[2] http://intr.overt.org/blog/?p=153
[3] https://en.wikipedia.org/wiki/AutoPlay#Non-volumes
[4] https://en.wikipedia.org/wiki/Media_Transfer_Protocol#History

[harding]

Ah, I retract my suggestion.  A particularly crafty virus could infect the media device, install an autorun file, and get the device to switch from MTP mode to USB mass storage mode between the time it disconnects from the online (hot) computer and connects to the offline (cold) computer.  -Dave

[runeks]

So if we can make a secure QR reader

Just realize this is not a solved problem yet. Existing QR code applications and libraries do not appear to have been written with security hardening in mind:

http://www.kisc.meiji.ac.jp/~ethicj/USEC13/submissions/usec13_submission_02.pdf

Your URL isn't really relevant in this context. If the QR scanning application has correctly decoded the QR, and is not susceptible to remote code execution, it's done its job. Whether a user visits an URL pointed to by the QR code is not related to the security of the QR reader.

It should be fairly simple to write a secure QR scanning app. We know that the code must contain a transaction, so the first thing we do is check that the code is a valid transaction. Anything else and we report it as an error. If it's a valid transaction that we have the keys to sign, then we sign it. Done deal.

[Ente]

I enjoy this discussion a lot.
Both because I want to secure my bitcoins, like to feed my playful paranoia, and would like to experiment with a small secure computer.

My idea, so far:

- Use a Raspberry Pi for the offline computer

- Tiny LCD and keypad, something like:
http://i94.photobucket.com/albums/l114/TexyUK/DSC_5572_zps91532411.jpg
http://t1.gstatic.com/images?q=tbn:ANd9GcR_fJdo6VoL2kY6jW-60kqh17KlO8YM016KhYpGaymMneHp1V-- 

- Use a "USB sharing switch":
https://geizhals.at/p/303918.jpg
This guy connects two computers to one [or two] USB devices. Switch between them with a button

- Use a USB key to transfer the data. I like the idea of "raw formatted" keys from post #90

Now comes the candy:

- I have two USB device ports on the switch: one for the key, the other one has a USB-to-I/O adapter
- the I/O adapter can push the button to switch the USB-switch to the other computer

--> online-computer sees the USB key and the I/O. Writes the TX to the key and "pushes the button" via I/O
--> the USB switch does its thing, now the key and I/O is disconnected from the online computer, the offline computer sees it
--> offline computer verifies, asks user via LCD,  signs, and "pushes the button" via I/O, etc etc

There is no direct connection between both computers. Just a USB storage, which should be possible to secure on the offline-computer side.
The whole process only needs the user to use armory on the online computer and press "accept" on the offline computer once.

What else? Everything is USB-powered. We might even power the whole setup via the one USB connector from the online computer. This would then be the only wire to the offline computer. The offline computer would only be running when the online computer runs.
It would be a neat, tiny solution. We might fit everything into such a "money box", and securely fix it to the wall:
http://www.colourbox.de/preview/1632272-905639-rot-metall-box-zur-aufbewahrung-von-geld-isoliert-auf-weis.jpg
With the buttons and LCD visible from outside. At least noone will just grab it..

What do you guys think?

Ente

[TierNolan]

I enjoy this discussion a lot.
Both because I want to secure my bitcoins, like to feed my playful paranoia, and would like to experiment with a small secure computer.

My idea, so far:

- Use a Raspberry Pi for the offline computer

Speaking of Raspberry PI, it sounds like the difficulty with that is setting up a cross compiler.  You have to compile Armory for the the raspberry pi, but do the actual compilation on a different computer.

Etotheipi, it seems pointless everyone having to set up a cross compiler, ideally, you would generate the jar file when you release new versions.

[runeks]

etotheipi, what's the progress on integrating the code from chrisrico into Armory? With the increasing BTC price I'm getting more and more weary about storing my BTC on an online computer.

Is there a test version ready that I can help test?

I'd need to buy an additional Raspberry Pi first, and get it set up, but after that I'd be ready for some testing.

I enjoy this discussion a lot.
Both because I want to secure my bitcoins, like to feed my playful paranoia, and would like to experiment with a small secure computer.

My idea, so far:

- Use a Raspberry Pi for the offline computer

Speaking of Raspberry PI, it sounds like the difficulty with that is setting up a cross compiler.  You have to compile Armory for the the raspberry pi, but do the actual compilation on a different computer.

Etotheipi, it seems pointless everyone having to set up a cross compiler, ideally, you would generate the jar file when you release new versions.

I usually avoid cross-compilation whenever I can, and simply compile it directly on the Pi. It takes a while longer, but unless you're building a kernel it isn't really a problem to wait 10 minutes instead of 1 minute.

Apart from that I think it's a great idea for Armory to include an armhf build. In fact, I think it would be ideal if all Linux programs came with an armhf build, apart from the usual x86 and amd64 build.

[TierNolan]

I usually avoid cross-compilation whenever I can, and simply compile it directly on the Pi. It takes a while longer, but unless you're building a kernel it isn't really a problem to wait 10 minutes instead of 1 minute.

Fair enough, it is how the bounty tutorial recommended to do it.

Do you use the Raspbian OS and what happens with dependencies?  I assume you need to connect to the internet for initial setup? 

I guess you could compile on the PI and the reset everything.

[runeks]

I usually avoid cross-compilation whenever I can, and simply compile it directly on the Pi. It takes a while longer, but unless you're building a kernel it isn't really a problem to wait 10 minutes instead of 1 minute.

Fair enough, it is how the bounty tutorial recommended to do it.

Do you use the Raspbian OS and what happens with dependencies?  I assume you need to connect to the internet for initial setup? 

I guess you could compile on the PI and the reset everything.

I haven't actually used a Pi as an offline wallet, but the way I would do it is put the Raspbian image on the Pi, update all packages, download Armory, build it, then remove Ethernet cable, generate keys and never connect it again.

If you think the Debian repositories have been compromised then it doesn't make sense using Debian on the device, since the Raspbian image is essentially made from the Debian repository of packages.

[etotheipi]

Something just hit slashdot today, that I don't totally understand.  But it's definitely reinforcing my paranoia about serial ports:

http://threatpost.com/open-serial-port-connections-to-scada-ics-and-it-gear-discovered/

I'll just let others put that into context for me...

(My understanding is that these serial ports were exposed to the internet, and that no precautions were taken to secure them ... and thus something like tty-logins were trivial to execute from anywhere)

[luffy]

no offline system needed. only wallets locked with 2 factor authentication and wallet change periodically

[chrisrico]

Something just hit slashdot today, that I don't totally understand.  But it's definitely reinforcing my paranoia about serial ports:

http://threatpost.com/open-serial-port-connections-to-scada-ics-and-it-gear-discovered/

I'll just let others put that into context for me...

(My understanding is that these serial ports were exposed to the internet, and that no precautions were taken to secure them ... and thus something like tty-logins were trivial to execute from anywhere)

It sounds like these were devices with internet access that served as a gateway to devices with only serial access. The internet devices were insecure and allowed attackers access to the serial devices just as they would an authorized user. This is different than the model we're using in that we assume the online device can compromised and are designing a system such that the serial device can cope with that threat.

[Ente]

no offline system needed. only wallets locked with 2 factor authentication and wallet change periodically

So, two factors, eh?
Like, one password and one pin which comes from a paperlist or fob? Let's throw in a textmessage for good measure.
You have malware on your computer. What will happen is:
- the malware will copy your wallet file and send it home
- it will log all stuff (i.e. passwords) you type in
- it will replace the bitcoin-address you intended to send funds to
- ..and make everything look as it should, boith to your eyes as well as to any anti-malware-program you use

Heck, there are malware which run your whole windows inside its own, invisible virtual machine!

Once you have both the wallet and malware on the same computer - consider it gone. No matter what.

Ente

[gglon]

Here is a proposal for easy to use, cheap, and secure offline wallet with livecd.
Spending your funds step by step:
1. run livecd with preinstalled software
2. insert flash drive with wallet
3. decrypt wallet and import private key required for tx
4. remove flash drive
5. sign tx located somewhere on the local drive
6. connect to the blockchain and to the internet
7. send tx

So in the end, the worst that can happen is compromised 1 private key when connecting with local drive at points 5,6 . But the window of opportunity for attacker will be small, if we won't reuse addresses. And the whole procedure can be made trivial for the user: reboot, insert cd and flashdrive, type the password, remove flashdrive, wait, reboot. And what is more important, it can be made entirely foolproof, if dedicated flash drive would be used.

[Ente]

Here is a proposal for easy to use, cheap, and secure offline wallet with livecd.
Spending your funds step by step:
1. run livecd with preinstalled software
2. insert flash drive with wallet
3. decrypt wallet and import private key required for tx
4. remove flash drive
5. sign tx located somewhere on the local drive
6. connect to the blockchain and to the internet
7. send tx

So in the end, the worst that can happen is compromised 1 private key when connecting with local drive at points 5,6 . But the window of opportunity for attacker will be small, if we won't reuse addresses. And the whole procedure can be made trivial for the user: reboot, insert cd and flashdrive, type the password, remove flashdrive, wait, reboot. And what is more important, it can be made entirely foolproof, if dedicated flash drive would be used.

That's probably the best way for "regular users" with fat wallets. As long as you can trust the (source of the) livecd, it is pretty tight. And has the bonus that it doesn't need a dedicated hardware.
I prefer a dedicated hardware which makes everything quick and easy, once it is setup. I think the "market" for your solution is bigger though.

Ente