Securing your savings wallet

[cypherdoc]

No, I'm prepared to hear any answer. I just am frustrated with incomplete answers. Telling me it's not safe despite all these precautions is an incomplete answer. I know it's not 100%, I already said this. I already said I'm willing to forgo complete security for some convenience but what you told me is that you wouldn't trust my setup at all which I just can't take as anything but bullshit. Yes I can lose my money, but here's a newsflash for you, you can also lose your paper wallet if a thief breaks into your safe. Perfect security does not exist and I'm not asking for it. All I'm asking is for a setup that is reasonable safe but you are telling me that my setup is inherently unsafe which I just cannot understand without any further explanations.

I already said that most of what I'm afraid of is a keylogger because I'm already very careful, have keepass and strong, uniquie passwords for any service I use, I have noscript installed, I have an antivirus running...  My windows setup is already a lot safer than what most have but I'm not happy with it because I realize I'm actively browsing on this OS and a keylogging threat exists. All I wanted to do with my USB ubuntu setup is protect myself against that. Why? Because encryption takes care of the rest. And now you're telling me my USB Ubuntu setup will not even protect me against keylogging?

Modern computers are inherently insecure. They are slapped together quickly and cheaply. The prevelant debuging method employed is "ad-hoc" debugging, where the software or hardware is tweaked until it appears to work. Software and hardware is not proven correct, in part because it is perceived to be impossible. In truth, the halting problem only applies to Turing machines with infinite memory, which computers only imperfectly emulate.

I used to think that modern computers could be considered reasonably secure, if only they ran from Read-only memory. For over a year, I used a diskless computer booting from a live CD as my primary computer (a second computer acted as a file-server). For several more years my router was booting from a read-only floppy disk. Then I learned about an attack on a Voting machine using read-only memory. They leveraged a stack overflow bug in one of the configuration menus into a full machine compromise. Because the machine was battery-backed, they were able to emulate the boot process. To get around to read-only memory limitations, they used a technique called return-oriented programming.

The implications for your laptop booting a "secure" USB key are obvious. A sufficiently skilled attacker may decide to emulate the boot process and prevent you from rebooting the machine; instead putting the machine in standby when you think you are turning it "off" (possibly adjusting LED behaviour in the process). You may think the battery is simply degrading with age. When you boot into Ubuntu, it may be running in a virtual machine, such that the hypervisor can record all of your keystrokes. The best part of return oriented programming is that if you do manage to do a hard-reset on the machine (by removing the battery), there may be no trace of the attack left on your hard-disk: simply because the binaries were never modified. The attacker would simply reinstall the malicious code the next time they come into contact with your machine.

There is a reason people advocate "cold storage" for large ammounts of money, commonly referred to as "savings". As the Armory author told you, it reduces your attack surface considerably.

From your description of this USB key, I get the impression that you are keeping only one copy. This is a security risk too. If your USB key gets lost or damaged, you would not be able to spend the funds. You really should consider some kind of paper backup in a safe somewhere.

now you've done it.  hazek won't sleep for a week. 

[hazek]

No, I'm prepared to hear any answer. I just am frustrated with incomplete answers. Telling me it's not safe despite all these precautions is an incomplete answer. I know it's not 100%, I already said this. I already said I'm willing to forgo complete security for some convenience but what you told me is that you wouldn't trust my setup at all which I just can't take as anything but bullshit. Yes I can lose my money, but here's a newsflash for you, you can also lose your paper wallet if a thief breaks into your safe. Perfect security does not exist and I'm not asking for it. All I'm asking is for a setup that is reasonable safe but you are telling me that my setup is inherently unsafe which I just cannot understand without any further explanations.

I already said that most of what I'm afraid of is a keylogger because I'm already very careful, have keepass and strong, uniquie passwords for any service I use, I have noscript installed, I have an antivirus running...  My windows setup is already a lot safer than what most have but I'm not happy with it because I realize I'm actively browsing on this OS and a keylogging threat exists. All I wanted to do with my USB ubuntu setup is protect myself against that. Why? Because encryption takes care of the rest. And now you're telling me my USB Ubuntu setup will not even protect me against keylogging?

Modern computers are inherently insecure. They are slapped together quickly and cheaply. The prevelant debuging method employed is "ad-hoc" debugging, where the software or hardware is tweaked until it appears to work. Software and hardware is not proven correct, in part because it is perceived to be impossible. In truth, the halting problem only applies to Turing machines with infinite memory, which computers only imperfectly emulate.

I used to think that modern computers could be considered reasonably secure, if only they ran from Read-only memory. For over a year, I used a diskless computer booting from a live CD as my primary computer (a second computer acted as a file-server). For several more years my router was booting from a read-only floppy disk. Then I learned about an attack on a Voting machine using read-only memory. They leveraged a stack overflow bug in one of the configuration menus into a full machine compromise. Because the machine was battery-backed, they were able to emulate the boot process. To get around to read-only memory limitations, they used a technique called return-oriented programming.

The implications for your laptop booting a "secure" USB key are obvious. A sufficiently skilled attacker may decide to emulate the boot process and prevent you from rebooting the machine; instead putting the machine in standby when you think you are turning it "off" (possibly adjusting LED behaviour in the process). You may think the battery is simply degrading with age. When you boot into Ubuntu, it may be running in a virtual machine, such that the hypervisor can record all of your keystrokes. The best part of return oriented programming is that if you do manage to do a hard-reset on the machine (by removing the battery), there may be no trace of the attack left on your hard-disk: simply because the binaries were never modified. The attacker would simply reinstall the malicious code the next time they come into contact with your machine.

There is a reason people advocate "cold storage" for large ammounts of money, commonly referred to as "savings". As the Armory author told you, it reduces your attack surface considerably.

From your description of this USB key, I get the impression that you are keeping only one copy. This is a security risk too. If your USB key gets lost or damaged, you would not be able to spend the funds. You really should consider some kind of paper backup in a safe somewhere.

now you've done it.  hazek won't sleep for a week. 

I will sleep like a baby because my laptop is private and no one but me has access to it.

[johnyj]

I think the most secure way is evenly divide your savings into 5-7 different wallet, and spread them among different platform, medium, physical location, online services, etc... so that you don't have too high risk on any single of them

A distributed saving solution

[franky1]

if your going to forgo some security for convenience.. then DO NOT forgo this security:

downloading ready compiled end user bitcoin programs....

the best security is knowing what goes on your computer in the first place.

i personally grabbed the sourcecode for the bitcoinD daemon, read through it then compiled it myself, i then made a simple VB.net program that API calls the daemon with commands i wanted.

i have it on a 16gb memory stick and life is good.

the chances of you getting a bitcoin trojan randomly browsing google for real life stuff is low. but the chances of you getting one downloading ready compiled end user programs from people in the bitcoin community is higher.

so do not get anything ready compiled from within the community. even if they show you sourcecode separately to say their ready to rock compiled executeable is ok... dont do it. compile it yourself.

seeing something large, ready built is tempting.. so was the trojan horse.

this is where i think the world market would suffer with adopting bitcoin. too many naive consumers who dont know how to compile, wanting ready to rock solutions and trusting in a community of hackers, script kiddies and anonymous users they have never met.

[misterbigg]

What's wrong with using a brain wallet???

[nobbynobbynoob]

What's wrong with using a brain wallet???

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

[etotheipi]

What's wrong with using a brain wallet???

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

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.

[franky1]

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.

[justusranvier]

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.

[chrisrico]

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

[justusranvier]

The online copy is where you must initiate all transfers.

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.

[etotheipi]

The online copy is where you must initiate all transfers.

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.

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. 

[justusranvier]

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.

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?

[justusranvier]

If I understand you all correctly then using Bitcoin “on-line” is dangerous. You should want to keep your funds off-line but Bitcoin is on-line money. So it’s necessary to develop a good way to use completely constant on-line money while keeping it off-line to be safe. This is like a brain teaser puzzle.

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.

[justusranvier]

At this early stage in the game does Bitcoin have the ability to even come close to being a safe place for storage of large amounts of wealth?

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.

Its legal legitimacy is still in question.

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

[etotheipi]

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.

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

[justusranvier]

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.

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.

[etotheipi]

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.

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.

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)

[justusranvier]

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.

[etotheipi]

The answer is to find a transfer method that has higher bandwidth than QR codes.

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.