Topic: Securing your savings wallet (Read 8361 times)

I'm not saying attack surface is exactly 0.00, simply that I'm not aware of any transfer method that has less linkage between the content of the data stream and what code will be executed. (and subsystems of the OS that automatically operate when the link is detected)

If you want to discuss this further, please respond to the thread I linked above.  This would be a good discussion to have there.  

Your software will, if you're not careful about avoiding buffer overflows. Remember, treat all incoming data as hostile and don't assume it is properly formatted (especially with regard to the expected size of the decoded data structures).

Irrelevant.

Image displaying software isn't supposed to execute arbitrary code based on the content of a JPEG file, but it still happens sometimes.

That you aren't even acknowledging the existence of an entire category of vulnerabilities does not inspire confidence.

Do we really know sound is safe? Has anyone ever tried to crash the Linux sound drivers via malicious sounds sent to the line in port? Maybe the only reason we don't think a vulnerability exists is because until now nobody has ever had a reason to look for one. Even if the sound drivers and ALSA libs are safe, there's still the matter of hardening the decoding software.

If even a task as old and well-understood as transforming a JPEG image into a bitmap can result in arbitrary code execution you can't just assume that sound is safe without at least some kind of testing.

It's about as good as you're going to get.  There is no default software on any distribution (that I've ever heard of) that executes code based on the content of incoming audio streams.  Serial, on the other hand, some linux distributions have telnet logins enabled by default over serial ports!

The attack surface is  never truly zero. Would you bet your life that it's impossible to craft an audio packet that crashes the decoder in such a way to allow code execution?

That being said it's probably safer than anything in use currently.

Aren't there encoding methods with a higher limit that can be printed out?

If I was working with a savings wallet with > 10^4 USD equivalent I'd buy a printer/scanner for the offline computer and use paper to move the required data if that reduced the potential attack surface.
[/quote]

There are non-standardized ways to do it, but it will be a lot of work.  I have discussed a lot of ideas -- and associated strengths and weaknesses -- in my Improving Offline Wallets thread.  A lot of ideas have been discussed there, and you are welcome to contribute if you have more ideas.  I think I converged on a solution, though:  audio coupling.  Take two double-male audio cables and connect MicIn-to-SpeakerOut and transmit the data the same way a modem would. 

This has some tremendous benefits:

• (1) Zero surface for remote code execution between machines
• (2) Platform-independent (someone using an archaic/ancient version of Linux for offline computer may not be able to get webcam drivers working, but audio almost always works)
• (3) Simple, convenient and inexpensive for the user.
• (4) Bandwidth is sufficient to transfer a couple megabytes in less than a minute

I have not committed myself to this solution, but in the absence of new ideas, I believe this is how I'll go (when priorities become appropriate).  Before anyone mentions webcams, serial cables, IR, etc, please read that thread.  Those ideas were discussed, and may be appropriate for knowledgeable users, but I do not believe they are satisfactory solutions for the general user.

The answer is to find a transfer method that has higher bandwidth than QR codes.[/quote]Aren't there encoding methods with a higher limit that can be printed out?

If I was working with a savings wallet with > 10^4 USD equivalent I'd buy a printer/scanner for the offline computer and use paper to move the required data if that reduced the potential attack surface.

No matter how much you try to avoid it, the system must still be able to handle it.  Even if it was acceptable from the user perspective to use only a single address, users would still combine wallets, import keys, etc, and it would still happen.  Plus, many users may collect month for months without ever moving the coins once, which means there will be no opportunity to consolidate coins until it's already too late. 

Even if it was, it's not worth the effort just to use QR codes for this purpose.  The answer is to find a transfer method that has higher bandwidth than QR codes.  (though, I do agree that programs could do a better job in this regard for high-activity wallets)

I think for this use case it's reasonable to look at ways to prevent the number of possible inputs from getting that large that might not otherwise be desirable.

The first thing that comes to mind is only having a single address in the offline wallet (always send change back to the same address), and combine unspent outputs after every N deposits, where N is selected to be small enough to never run into the problem you referenced.

It's an attack that is possible, and can ruin someone.  Even if the attacker has no financial gain from it, money may not be their primary motive.  Not to mention, that someone with serious mining power could see financial gain -- and further, if someone has compromised the online computer to do this, they can intercept the transaction so that no one else sees it until they can mine it themselves.  Sure, it may take a couple days, but the person may just assume something is wrong with their client or the tx fee (the fee they thought they were paying). 

No matter how silly the hole may seem to you, it can cause epic financial damage to someone and it's easy to avoid (modifying BIP 10 for this took only a few hours).  Thus, it had to be done.

Nonetheless, even if those transactions were not included, the tx to be signed could still be huge.  The transaction I referenced in my previous post was 140 kB.  Still too big for a QR code.

Excluding exchange rate risk, it's perfectly safe for storage. The problem is safely moving funds out of storage without potentially exposing your private keys to malware.

Depending on who you talk to this is irrelevant or even beneficial.

There's a difference between petty cash and your retirement savings.

In the first case convienience is very important and losses, while still undesirable, are expected to occur from time to time.

In the second case no losses are acceptable.

You need different procedures for handling each case because the definition of success is different. I'm satisfied with the security of Bitcoin clients as the currently exist for storing small amounts of money that I could survive losing without taking additional security precautions. On the other hand, I see the existing clients as wholly unsuitable for safely manipulating large and critical sums of money. (not their fault - it's a hard problem that just hasn't been solved yet)

That's why I'm trying to work out now what would solve the problem in an acceptable way before I actually need the capability.

If the online computer which generate the transaction is compromised it can lie about the size of the inputs and cause you to pay a larger fee than you intended, but how credible of a threat is this? The only one who benefits is miners, and would it be profitable for them to fund a malware attack when they can't guarentee to be the ones to mine the blocks containing these transactions?

It's even a tad more complex than that.  Without the blockchain on the offline computer, it can't verify all the information on the transaction, and it may be tricked into signing something that you didn't intend.  i.e. -- someone hacks the computer holding the wallet you use to create the transactions, and the next time you create a transaction, it will put false information in the transaction, and it will look like you are paying a 0.0005 tx fee, but it turned out to be 500 BTC fee.

There is discussion of this in the BIP 10 document.  The punchline is that you need to transfer not just the transaction to be signed, but every transaction that provides inputs to it (so that it can manually verify amounts and hashes).  Because of this, the data to be transferred back and forth between online and offline computer can be way more than a QR code can handle.  It is usually less than a few kB, but someone recently submitted a bug report because Armory choked when trying to sign a transaction with 483 inputs -- and so there was 483 transactions to be transferred, totaling about 3 MB.  QR codes are just not feasible, here.

I want to get away from USB keys, but they are just so damned convenient and people already know how to use them, so I haven't been able to make it a priority, yet.   For now, USB keys are a 98% solution, and I'd rather people use this solution, than be greeted with something dramatically more complicated, and then they give up on offline wallets altogether. 

I don't understand why this needs to be a hard requirement.

In theory the offline computer only needs a private key, output amounts, and output addresses to generate a valid transation. Output addresses can be typed in manually and stored in an address book. Amounts can also be manually typed in.

Sure, there's a high potential for user error doing it that way but the biggest risk (incorrectly specifing the amount for the change address output and giving away most of your savings as a transaction fee) could be removed by reusing the input address as the change address or by basic sanity checking built in to the offline program.

Edit. I just found out in a different thread that my understanding of how an input is specfied was incorrect. So now I do understand the requirement to generate the transaction on an online computer.

I think this was discussed in the Armory thread (or maybe this one), but here's a quick run down. In order to use the offline Armory split wallet method, you must also have a computer with the block chain up to date and Armory installed, with the watching only copy of the wallet. The offline copy doesn't have any block or transaction information, so you can't even see your balance. The online copy is where you must initiate all transfers. In order for the offline copy to sign and verify the transaction, it must be supplied with the transactions for all outputs to be spent, along with the transaction to sign. So you first need to transfer more data than will fit in a QR code from the online to the offline computer, and then a smaller amount of data in the reverse direction.

I have some questions about using Armory in a fully air-gapped offline mode that are relevent to the same scenerio as the OP.

I want to store Bitcoins on a computer which, after the initial software installation and key generation, will never again communicate over a network or accept removable media.

Can Armory generate raw transactions without ever having any knowledge about the blockchain and display them on the screen as a QR code?

If it could do this, and if the QR code was formatted as a URL, it would be possible to create a lightweight web service that would accept raw transactions as a URL parameter, check them for validity, and broadcast them on the network.

Now spending funds from an offline wallet doesn't require a serial cable or a thumbdrive - it just requires a smartphone with a standard QR code reader app.

i personally have a large hoard in paper form printed to look like a bearer bond with instructions on the back how to redeem it. safe in a box stored away along with a CD containing the programs i hand crafted ready for the redeemer, in my demise to inherit the world... or i spend it one day   . i only hold smaller amounts on my personal wallet, so human memory is not an issue for me.

I'm sure your relatives will appreciate you taking your Bitcoins to the grave when you get hit by a bus.

Seriously, people:  if you want a "brainwallet", at least hand-write it onto a sheet of paper, with identifying markings, and pay the $5/mo for a safe deposit box.  I'm sure there's more stuff you'd like to store in there anyway (car title, birth certificate, etc).  Then, when you've forgotten your brainwallet after 2 years, or something unfortunately happens, your relatives will gain access to it and the coins won't be lost forever.

And of course, I don't condone brainwallets -- most people do not create strong enough "passphrases", and of course what I mentioned above about losing coins forever.  If you're going to go this route, boot up an offline computer wiht a linux Live-CD, and install Armory and use it to generate a high-entropy wallet.  Go to the "Print Paper Backup" dialog, and manually copy down all the information on the sheet (you can use a printer if you trust it).  Also copy down the first X addresses so that you have some addresses you can use for putting money into it.  Keep that address strings, and put the paper backups into envelopes.  Put one envelope in a safe-depost box, perhaps another one in a safe.  Live happily knowing that your coins are both secure and recoverable.

But if you're going to do this, you might as well use Armory offline wallets.  It is exactly what I said above, but you also get a watching-only wallet so you can monitor it online and distribute new addresses (private keys never touch the internet).  Spending is easiest if you keep the wallet on the offline computer, but you can just as easily reboot into a live session, and re-enter the paper-backup information to regenerate the wallet each time you need to sign something.  If you don't move the coins often, keeping the paper backup in your safe is sufficiently secure and convenient.

Nothing if the keys are hashed up offline, other than amnesia being very expensive.