Topic: Improving Offline Wallets (i.e. cold-storage) - page 2. (Read 19605 times)

Etotheipi mentioned QR codes in his initial post and we've tried to work around the "minuses" he's mentioned for sending/receiving data that way. What we've come up with is VisualBTC - I've posted a thread on it here: https://bitcointalksearch.org/topic/ann-visualbtc-android-based-hardware-offline-wallet-using-animated-qr-codes-210371 .

It uses animated QR codes to send/receive data (update unspent outputs list and post transactions). The private key never leaves the device and it's never connected to the Internet (WiFi chip can even be disabled in the bootloader on the suggested hardware - a $50 capacitive-screen 4.3 inch Android tablet, see the original thread for more details).

Any suggestions on how to create a liveCD with preinstalled software? I'm familiar with making LiveCDs, but not with the preinstalled software portion.

EDIT: I found a better way, thanks to N.Z.'s post. I have created a hyperlinked Google word document tutorial (whose formatting was too much trouble to get embedded here).

Thanks for your support, since I was thinking about bitcoin security for past few days and it wasn't that easy for me to figure it out. Still, I don't know if it hasn't been proposed earlier. I think this proposal may compete with hardware wallets pluged to standard pc, as it is cheaper and a normal keyboard/screen is much more comfortable. While distribution of livecd would be even more secure that hardware, as you can easily download it from trusted source like mt.gox or theymos and verify.

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

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.

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

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.

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

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)

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.

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.

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 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.

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 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

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.

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

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

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

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*

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?