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

I've seen that mentioned a few times... it seems that the python-parallel package is in the Ubuntu repos, and the cables are not necessarily expensive.  Is there an equivalent way to hook up two systems?  i.e. the equivalent of the two USB-port adapters and a null-modem adapter.  I am assuming this would not be overly expensive...

There is always printer port connection possible too, typically no getty running on those ports.

-MarkM-

What if the "offline" PC is only a passive listener in a network, e.g. WLAN?

That way, it would simply sniff network traffic until a certain transaction flies by that it could sign - it would sign it and store the signed transaction.
No bandwidth issues there and since no sending communication is allowed, there's no way that an attacker can do anything else than let it sign a transaction - something that's possible with any other method too. No way to get to the private keys though.

To get back the signed transactions (or even just the signatures, if you need to transmit even less data) you just select the ones to export and transfer them to the online machine using a write-once medium (e.g. QR code on paper, CD-R, morse code over the air...).

Using the "selective listener" approach, you just need to broadcast unsigned transactions in your network and they will be picked up and to get the signature, you'll get seomthing from the secure station that has never been in any other computer, so no way for infected USB sticks that get transferred between 2 PCs. The attack vector then would be that the secure station's network interface can be taken over/infected by passively listening to (potentially pre-filtered to only contain Armory relevant traffic by a hardware firewall) transaction data.

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)

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

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

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-

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

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-

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

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

Just my 2 cents/satoshis.

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.

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.

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.

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?

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:

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

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

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