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

[Rampion]

No, that is not safe because you have to scan the key into an online computer to use it, at which point it is vulnerable. You could scan it into an offline computer and sign the transaction there, but then why not just keep the key there instead of on paper?

A Raspberry Pi costs $35 and can sufficiently run an offline Armory install. It's a cheap and effective solution.

I think you don't even need a dedicated machine (Raspberry Pi). You can run a live a persistent usb with linux, with Armory and your wallet in it.

1) you turn off your online computer
2) you boot the computer from the live usb
3) you sign the transactions with armory
4) you turn off the computer, remove the usb, and run your normal OS, online

For extra safety you can format the pendrive on each use, to avoid autoexecuting threats. Anyhow you can disable auto-executing in Linux.

Recommendations I come up:

a) never connect to the internet from the live usb environment (obviously)
b) don't mount your online computer hard drive from the live usb environment
c) for extra tin-foil hat mode, after using the live usb environment and turning off the computer, unplug it and leave it unplugged for a couple of minutes to be sure that all traces of your live environment have been wiped from RAM

Additionally you can make a clone of that usb for redundancy and print a paper backup of your wallet.

Didn't try this method, but it looks like pretty safe if you don't have an old computer/raspberry pi hanging around

[1715148554]

1715148554

[1715148554]

1715148554

[1715148554]

1715148554

[qbits]

No, that is not safe because you have to scan the key into an online computer to use it, at which point it is vulnerable. You could scan it into an offline computer and sign the transaction there, but then why not just keep the key there instead of on paper?

A Raspberry Pi costs $35 and can sufficiently run an offline Armory install. It's a cheap and effective solution.

- you scan a key with only 10 BTC on it so this is the maximum loss.
- you can use lot's of different computers and mobile phones and tablets to process your transactions
- rPi method is interesting, similar approach is undertaken by Slush & team with their hardware wallet, however their method and all methods that deliver security via dedicated hardware is the following:

1. let's say I would like to transfer 1000BTC to mtGox in hopes of selling the coins. With your approach I would open mtGox account from my online computer, generate bitcoin receive address on my mtGox account and then proceed to sign the transaction on my "offline" rPi super secure device

2. you see where I'm heading?

3. a black hat hacker does not need to hack into my super secure offline rPi device. All it needs to ensure is that the receive address displayed on mtGox account is not the receive address of mtGox but rather one generated by hacker who now receives coins on an address he has secrect key for. In order to do that hacker would "only" need to hack into an "online" computer which by your definition is possible.

[runeks]

No, that is not safe because you have to scan the key into an online computer to use it, at which point it is vulnerable. You could scan it into an offline computer and sign the transaction there, but then why not just keep the key there instead of on paper?

A Raspberry Pi costs $35 and can sufficiently run an offline Armory install. It's a cheap and effective solution.

- you scan a key with only 10 BTC on it so this is the maximum loss.
- you can use lot's of different computers and mobile phones and tablets to process your transactions
- rPi method is interesting, similar approach is undertaken by Slush & team with their hardware wallet, however their method and all methods that deliver security via dedicated hardware is the following:

1. let's say I would like to transfer 1000BTC to mtGox in hopes of selling the coins. With your approach I would open mtGox account from my online computer, generate bitcoin receive address on my mtGox account and then proceed to sign the transaction on my "offline" rPi super secure device

2. you see where I'm heading?

3. a black hat hacker does not need to hack into my super secure offline rPi device. All it needs to ensure is that the receive address displayed on mtGox account is not the receive address of mtGox but rather one generated by hacker who now receives coins on an address he has secrect key for. In order to do that hacker would "only" need to hack into an "online" computer which by your definition is possible.

I don't see how your proposal offers protection against this.

If your argument is that you'll discover whether the 10 BTC goes to the intended receiver, then just start out by signing a transaction - with the offline wallet - for 10 BTC to the supposed Mt. Gox receive address. If this goes through to your Mt. Gox account, you can proceed to send the remaining 990 BTC.

Imagine having to import keys from 100 different 10 BTC-paper wallets. Now that would be tiring.

[qbits]

Imagine having to import keys from 100 different 10 BTC-paper wallets. Now that would be tiring.

I does not need to be. Scanning QR codes with a camera should not take you more than a second or two per wallet.

[runeks]

The question still remains: why spend even a minute doing this if it offers no advantage?

[qbits]

The question still remains: why spend even a minute doing this if it offers no advantage?

Correct. This is what I've been thinking about on and off for the last year or so. The "man-in-the-middle" scenario I've described is a big problem for traditional on-line banking systems as well. I've even seen a version of it performed in a presentation at some security conference (can't remember which one).

My conclusion is that multiple paper wallets and multiple devices would at least make such an attack a bit more difficult.

BTW, when you type mtgox.com into your browser, you are redirected to mtgox site via some DNS server. You confirm identity of the mtgox site because of the corresponding mtgox certificate which is signed by Verisign global certificate, public copy of which you have in your browser.

is this really really safe? probably safe enough for a 1000 BTC ~= $50k transfer. but would you trust this with a $50M transfer?
would anyone? you see this may be much more of a problem than a hack into my relatively safe linux distro.

this is why I think it is a shame NMC project never took off the ground. even if it meant that we would register our domains under bitcoin.org domain.............

[etotheipi]

New ideas!  Food for thought:  I just talked to some people who are a bit better with hardware than me, and someone mentioned the idea of using "broken" cables.  For instance, using a serial cable with a null-modem connector that has some wires flipped.  My understanding was that there's no reason the other pins can't be used identically, it's just more "convention" that pins 2 and 3 are used for tx/rx...?    So if you connected that wacky cable, it is theoretically usable with the same bandwidths, but nothing on your system would recognize it as a usable serial cable.  You could probably do something similar with ethernet (which is easy to make yourself). 

Another variant of that was that you could use ethernet but configure one machine with "broken" settings.  You could set the machine so it would never even get itself an IP address, you could transmit data via byte-padding ping/arping packets.  That's a pretty crazy idea.  Basically take things one level lower than most apps operate at.


A more software-oriented solution came out of that conversation too.  One that might actually make me feel comfortable about serial if I can make it work.   Actually remove the /dev/ttySX devices from the system, create new files in their place with chattr +i them so they can't be removed, then make them root-only-everything.  Then create a new device file in, say, /home/username/armory-tty using mknod, using char blocks (4,64) (which is the block to identify that the device is to be assigned to the next serial device that is attached).  Then setup Armory to use /home/username/armory-tty for serial communications. 

That would pretty much kill everything.  Even things that are smart enough to search the /dev directory for serial-capable devices.  Any getty's would become invalid.  Could it be further modified, using chmod 700 for my username/group, so any other non-root processes couldn't access it even if they found it?  Would that interfere with the system assigning serial devices to it?

By the way, here's the code my friend sent:

Code:

# check inittab for a getty (look for a line containing ttyS0 that is not commented out)
cat /dev/inittab | grep ttyS0 | grep -v ^#

# check for a getty running on the serial port
ps ax | grep ttyS0

# check for anyone else using the serial port
fuser -v /dev/ttyS0

# try to kill the offending process(es)
fuser -k /dev/ttyS0

# remove the standard serial device and install an useless and immutable placeholder instead
rm -f /dev/ttyS0
rm -f /dev/cua0      # also remove legacy 'call-out' device if it exists, just in case
touch /dev/ttyS0
chown 0.0 /dev/ttyS0
chmod 000 /dev/ttyS0
chattr +i /dev/ttyS0

# create a 'new' serial device that no standard program will go looking for
mknod armory_ttyS0 c 4 64

# show configuration of serial device
setserial -a /dev/armory_ttyS0

[chrisrico]

New ideas!  Food for thought:  I just talked to some people who are a bit better with hardware than me, and someone mentioned the idea of using "broken" cables.

I still don't understand the attack vector this is trying to solve. Did the people who are better with hardware agree that plugging a device in to a compromized computer's serial port could allow the device to be compromised? What if all the serial TTY ports on the device are disabled?

[etotheipi]

New ideas!  Food for thought:  I just talked to some people who are a bit better with hardware than me, and someone mentioned the idea of using "broken" cables.

I still don't understand the attack vector this is trying to solve. Did the people who are better with hardware agree that plugging a device in to a compromized computer's serial port could allow the device to be compromised? What if all the serial TTY ports on the device are disabled?

Impatient user creates an offline computer, installs Armory, transfers 1,000 BTC, hooks up a serial cable to do one tx, then leaves it running with the serial cable attached.  

This is ripe for old OS subsystems that watch serial ports to be exploited.  Sure getty's are mostly disabled... but maybe not.  There may also be other processes which do something automatcally on the serial port to "make your life easier", which could be exploited.  Yes, I am being exceptionally paranoid... but it's a one-time cost for me to develop a solution that puts the serial port somewhere that no program or app can find it or use, then it nullifies the threat of latent processes exposing an attack surface.  An attack surface that is potentially much worse than the threat of USB viruses.

Keep in mind this is not to say that an attacker who has already compromised the offline system couldn't find it and use the new serial port... but the assumption here is that the offline system hasn't been compromised, and I want to prevent it from being compromised by making sure Armory is the only process on the system with access to the serial cable.

[oakpacific]

I got a kinda silly idea: how about creating a USB stick that could only be read/written in RAW mode by Armory?  The USB should contain no file system at all, so no executable can be run from it.

[Domrada]

I like the spirit of this thread very much. But it seems to me that we are way too focused on the medium of communication. Let's think about this.  What is it exactly that makes a serial cable or an audio modem a more secure connection than an ethernet cable? Can you really call your offline machine, "offline?"

Now I am not nearly as knowledgeable about this stuff as you guys, so maybe I'm just being simpleminded. But shouldn't we be more concerned about the way in which the secure machine interacts with the communications ports? Suppose I take a concrete block, fit it with an RJ45 jack and plug it directly into my cable modem.  Perfectly secure, no?

What if I had a slave machine running a simple, custom operating system that only runs armory. Offline Armory the operating system. All the attack vectors that depend on a general purpose OS would not exist.   I would feel perfectly safe putting that machine on the network, even if it did contain all my private keys. In my mind, the security would be equal to encasing a paper wallet in concrete, and putting that on the network. Anyone who comes knocking on the communication ports would not get any sort of meaningful response, unless it happens to be the Armory process on my primary machine.

[ShadowOfHarbringer]

- Most newer systems do not have serial ports [/li][/list]

Incorrect, it is trivial to buy a Serial-To-USB cable. It also works under Linux. Checked myself.

Just my 2 cents/satoshis.

[btchip]

For what it's worth, two proposals for a generic purpose USB secure device (smartcard / generic HID / whatever) without a display or buttons, supposing there are 2 computers / 1 computer - 1 smartphone involved and 1 meaningful output address in the transaction, to keep it simple for the user :

- Prepare the transaction on the first computer as described
- On the second computer, type the meaningful output address and the amount, compute and display a cryptographic checksum for those. The cryptographic checksum involves a shared key between the second computer and the USB secure device.
- Enter back the cryptographic checksum on the first computer, which is passed to the USB secure device and checked. Then the transaction is signed if the data matches.
- Send the signed transaction

And an alternative solution with a single computer :

- Prepare the transaction
- Disconnect all network connections
- Send the transaction to the USB secure device, which answers with an image containing the meaningful output address, the amount and a random code. The hard part here is to make it complicated to crack automatically.
- Read the random code, send it back to the device. If the random code is correct, the transaction is signed.
- Connect back and send the signed transaction

[markm]

And an alternative solution with a single computer :

- Prepare the transaction
- Disconnect all network connections
- Send the transaction to the USB secure device, which answers with an image containing the meaningful output, the amount and a random code. The hard part here is to make it complicated to crack automatically.
- Read the random code, send it back to the device. If the random code is correct, the transaction is signed.
- Connect back and send the signed transaction

Isn't the basic assumption that your online computer is compromised?

Once compromised, "forever" compromised. In particular, unplugging it from the net does nothing to remove trojans and worms, disable screen-scrapers and keyboard loggers and so on, all of which can phone home some day when they do see the net again.

-MarkM-

[btchip]

Isn't the basic assumption that your online computer is compromised?

Once compromised, "forever" compromised. In particular, unplugging it from the net does nothing to remove trjans and worms, disable screen-scrapers and keyboard loggers and so on, all of which can phone home some day when they do see the net again.

-MarkM-

yes, that's why the image sent back needs to be complicated to crack automatically (but it's ok if it can be cracked by a remote human processing farm, since the network connection is off)

the random code in the image is only valid once for this transaction, because it's generated by the USB device

[markm]

So where are you going to get code to use that image, that crackers can't also get?

I think I am not quite grasping the details of your protocol.

-MarkM-

[btchip]

So where are you going to get code to use that image, that crackers can't also get?

-MarkM-

That's the complicated part, the security of this scheme is the security of your "captcha" generation. I haven't looked into the security of existing open source algorithms yet.

the first solution is way more safe IMHO, but the second one can be a good incentive to make huge academic progress in this field ("break my code, get all my money" )

[etotheipi]

- Most newer systems do not have serial ports [/li][/list]

Incorrect, it is trivial to buy a Serial-To-USB cable. It also works under Linux. Checked myself.

Just my 2 cents/satoshis.

I know, that's why I posted, a few responses back more ideas for executing serial connections.  I already have two USB-serial cables and a null-modem connector and have been playing with them.  What I was hoping was to brainstorm on any possible, remaining attack surface exposed by it.  The getty's are a "hidden" snafu in the whole process, but easily disabled.  I am searching for more experience with this... since serial ports used to be "the cool thing", I'm sure there's tons of auto-enable subsystems that try to make your life easier by detecting and doing something when the serial device is plugged in. 

Hence why I liked the pure-software solution of destroying the usual device/file that is used for serial communications, and remaking it somewhere that no other subsystem can find it or use it.  This would seem to resolve any remaining "unknowns".

Unfortunately, the USB-serial cables are not cheap, but they're not ludicrously expensive, either if you are protecting a lot of money.  Maybe 2 * $20 plus a $2 null-modem connector.  In the long-run, it's actually a very reasonable solution for serious bitcoiners...

[btchip]

Hence why I liked the pure-software solution of destroying the usual device/file that is used for serial communications, and remaking it somewhere that no other subsystem can find it or use it.  This would seem to resolve any remaining "unknowns".

What about using a udev rule to set the group/owner of all serial devices to the Armory account + read/write permission only for this account instead ?

[etotheipi]

Hence why I liked the pure-software solution of destroying the usual device/file that is used for serial communications, and remaking it somewhere that no other subsystem can find it or use it.  This would seem to resolve any remaining "unknowns".

What about using a udev rule to set the group/owner of all serial devices to the Armory account + read/write permission only for this account instead ?

I wanted to iron out the base idea first, then later figure out how to make sure udev doesn't get in the way (or set it up to help out instead of destroying all my hard work)