Topic: Improving Offline Wallets (i.e. cold-storage) (Read 19719 times)

It totally depends on the software used.
But in genertal, the more complex and big a system is, the more points of failure there are. And here, we have two instead of one computer, they both are online, and you have a vpn in between. Enhanced physical security may be worth it, depending on the situation. Nice to know that noone can just break in, grab a computer, and has everything he needs.

Edit:
The important part is to distinguish two designs:
- "security measures in parallel", like a chain where you only have to break the weakest link (break one of the two computers or the VPN)
- "security measures in series", like layers where you have to break through all of them (like n-of-m, on paper wallets, encrypted)

Besides that, a "safe fallback" is good. "If anything irregular happens, it all shuts down and is fine" (like full hdd encryption for example). Also, consider every single component to be compromised. A million bonus points for designing a setup where every single component may be compromised at the same time, and you still don't lose :-)

Ente

Ente

So windows servers are not affected by this bug. Microsoft uses something called sstp to secure vpn.

If the VPN connection is based on OpenVPN, which uses OpenSSL by default, there would be for example the heartbleed bug, if it is not yet fixed on the machine you use.

Are there any problems with using a vpn connection instead of a usb ? What are some possible security risks?

The website has "offline bundles" you can use.  It has a link to Ubuntu 10.04-32bit and a bundle that you can unpack and install on the first boot of a never-touched-the-internet boot of 10.04.  you should try it out... I made it for exactly the same reasons your complaining about here

Having done this recently, one practical hurdle I found was getting a Linux distro that would run on the offline device, and then getting Armory to run on that distro. I gave up on the first step after a few failed attempts, partly because I figured that for the second step, I'd need to rebuild Armory from source, and it seemed like too much hassle, especially if the rebuild was to happen on the offline computer.

This is why I recommend using an ancient about-to-be-junked laptop.  I got a throwaway from work for free. You can get something on ebay or craigslist for about $50.  Anything with 256 MB of RAM or more will run Armory in offline mode.  Most users will have no interest in using a slow-as-dirt laptop that can hardly load a browser, for anything else but cold storage.

-- I think the best idea mentioned is the secure Armory OS.  Build it off of something small and stable.  No dependencies on any software the Armory team hasn't written or inspected.

On the usability side this could be implemented by having a smartphone app, which reads the QR-code and connects via UPnP (or similiar) to a daemon running in the armory client on the online pc.

I strongly disagree.
Antivirus software does a lousy job in protecting from malware.
It gives the user a false sense of security, maybe leading to more risky behavior.
It eats a whole lot of performance.

Good read on this:
http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_coder_and_botnet_operator_ama/

In short, consider your system compromised. And use a second system for bitcoin-only. An old 100$ netbook, a trezor, or even an old smartphone if you must. At least consider that as soon as your Bitcoin holding is non-trivial. The Armory wallet is your friend, by the way.

Well, that topic is a whole universe in itself..

Ente

I just want to point out, most virus protection software will pickup any malicious executable from running and will stop it from executing unless approved by the user. Memory hacks, especially calling any low level hooks, keyloggers can be easily caught by virus scanners. avg does pretty good job.

I never said that disk encryption is pointless.  But Armory already encrypts your wallet, and guarantees that if your wallet is created encrypted, the unencrypted keys never touch the disk.  By all means, you need encryption, but full disk-encryption is mostly redundant here.  In fact, in some environments, it's inferior -- if you were to use full-disk encryption and unencrypted wallet files, then you are protected the same when your computer is off but the encryption is completely useless while the computer is on (so it can run the OS and access your files).  Someone who gets on your compute for 1 minute can put in a USB key, and copy off the [unencrypted] wallet file to their key.  Ditto for serial.    At least with Armory encryption, the file on disk is always encrypted and inaccessible even when the computer is unlocked. 

The counterpoints to these thoughts are:  just hedge and use both -- disk encryption and Armory encryption.  And in the end it may not matter--anything advanced enough to get to your offline system is probably advanced enough to pull your private keys out of RAM when you unlock your wallet to sign a transaction.  No disk encryption can protect against that.

The security environment is this:  you have an offline computer setup securely, and it has not been compromised in any way.  You have a verified version of Armory installed and know it works perfectly (of course).  However, you assume an attacker has full control of your online computer, and knows you will be using to move data back and forth between your [compromised] online computer, and you're not-yet-compromised offline computer.

If it's a serial connection that's not done correctly, they grab your Firefox password file and try every entry to TTY login to the offline machine.  Once there, they grab the encrypted wallet, and start trying to brute force it (probably also related to one of your firefox passwords...).  Or if that's not enough, they keylog your passphrase and send it back over the serial line to the online computer (which is compromised).

Similarly, if your transfer method is USB keys, there's undoubtedly lots of ways to exploit autorun.  Put a carefully crafted file on the USB key with a payload that gets executed when you plug in the USB key, and it carries your wallet out with it when the user brings the USB key back to their online computer. 

Any mention of Armory flaws, or initial install security is mostly out-of-scope.  We assume the user installed the correct software offline and that the software itself performs exactly as expected. 

That's a valid point, I didn't think of, thanks for mentioning!
But the smartphone intermediate step should help. As long as the smartphone is not infected it still could verify the signature against the original transaction. Let's assume the malware on the online pc managed to get a malicious transaction onto the pendrive and the user did sign it on the offline pc, because armory was tricked into showing him the original transaction. Now the signature of the malicious transaction will be transfered to the smartphone. The smartphone acquires the original transaction from the online pc and checks the signature against the transaction. Now, because the online pc sent the original transaction, but the offline pc sent the signature for the malicious transaction, the verification will fail. On the other hand, if the online pc sends the malicious transaction, a careful user would notice the change on the smartphone.

I think the important part is indeed the intermediate check on the smartphone. The qr code for returning the signature alone won't defend against malicious transactions (as you pointed out).
However, since the smartphone still is connected via wifi it probably can be compromised rather easily, too. Nevertheless it increases the complexity for the attacker, while the complexity for the user doesn't increase that much.

But if the malware manages to control both Armory instances on the offline and the online computers, then they can make you supplying the online instance a signature signing a transaction created in secret to the attacker's address, while showing you the normal one on the screen......

I don't know if this has been proposed already, but would it be possible and/or improve the security to transfer the unsigned transaction to the offline PC on a write-locked medium (like USB drive with write-lock-switch or CD) and then use QR-codes to transfer back only the signatures? This way the only possibility for the private keys to get out of the offline PC would be the QR-codes. This should be detectable pretty early, because the QR-code would be bigger than normal. For most transactions 1-3 QR-codes should be enough (and if iQR-codes will be availiable, a single code should be sufficient for a majority of the cases).

On the usability side this could be implemented by having a smartphone app, which reads the QR-code and connects via UPnP (or similiar) to a daemon running in the armory client on the online pc. The online pc then matches the signature to the unsigned transactions. No webcams (besides in the smartphone) are needed this way. Even single-machine setups using a live-cd for the offline part could use this as the smartphone could act as an intermediate storage for the signature until the single machine has rebooted into online mode.
The smartphone can also act as an additional security layer, if it does some simple plausability checks on the data received through the QR-code. So even if the malware on the online pc makes it to the offline pc and tricks armory into putting the private keys into the QR-code, the smartphone would notice and prevent the data from going back to the infected online pc. So for this scenario to be fruitful for the attacker, he needs to also compromise the user's smartphone in addition to the online pc and the offline pc.

Unfortunately, it can't be that simple.  In fact, even for the simple case you describe, it is dramatically more complex.  Why?  Allow me to explain how offline wallets work in Armory, and why data sizes will never be that small.

Satoshi decided not to include the input values of the inputs being spent in the transaction inputs or explicit declaration of the fee in the transaction data to be signed.  This sounds arbitrary, because that information is located in the blockchain, so the node only needs to go look it up the OutPoints in the blockchain to know.  Right?   Well, offline wallets can't do that.  And part of the value of Armory for offline transactions is that the offline computer doesn't need the blockchain.  You might say "okay, well just throw that information in with the tx to be signed so that the offline computer knows."  If only it were that simple...

gmaxwell expressed concern, rightly, that if your online computer is infected, the next transaction you make might have a devastatingly malicious modification:  it completes your transaction, but sends the rest of the balance of your wallet to transaction fee.  But you don't know this, because the attacker also modified the "supplementary" information in the transaction, so that the offline computer thinks it's only signing a 1.01 BTC input, with 0.5 to recip, 0.5 to change, and 0.01 to fee.  But the attacker actually put a 300 BTC input on the tx-to-be-signed, but put in the "supplemental" information that the input is only 1.01 BTC.  The result will be the offline computer showing you that you are sending 0.5 BTC to the recipient with 0.01 fee.  But when you send the transaction, it's actually 299 BTC fee.

THEREFORE:  my BIP 0010 "protocol" includes the entirety of each transaction which supplies inputs to the transaction-to-be-signed.  For each input in the tx-to-be-signed, Armory sees the OutPoint (txHash, txOutIndex), and verifies that it was passed a transaction with the same TxHash.  From that transaction, it can verify the value of the input and the final tx fee. 

• If the attacker changes the recipient or the amount sent to recipient -- the user should notice because they can see the list of recipients and values before they sign it
• If the attacker changes the value specified on the supplementary tx -- the suppl tx hash will no longer match the OutPoint on the tx-to-be-signed, verification will fail
• If the attacker changes the supplementary tx value and the OutPoint hash -- the transaction is no longer valid, because that OutPoint doesn't actually exist

In fact, that pretty much clears up every possible avenue for tricking the offline computer.  Now, every piece of important information is verifiable by the offline computer.  If there is manipulation, the either the tx won't be valid, or the user will notice when they look at the transaction details.

---

Okay, so that gets us back to the original question of "how much data do we have to transfer between online and offline computer?"  Unfortunately, the simplest case is not relevant to this discussion:  you have to design the protocol around the 99.9'th percentile case:  which is the case that someone has an offline donation address that they want to clear out.  Let's say they have received 40 donations.

So the transaction will have 40 inputs and 2 outputs. 

The bulk of the data is the supporting transactions which can be anything (transactions created by the donors).  Each one itself may have dozens of inputs, and the signatures are necessarily included!  Let's assume 30 "standard" supporting transactions, and the other ten have 10 inputs each.

• Tx-to-be-signed:  30 inputs (unsigned) of 48 bytes each, and two outputs of 40 bytes each = 1.5 kB 
• 30 standard supporting tx:  250 bytes each = 7.5 kB
• Ten larger tx:  180 bytes for each input (signed), so about 2 kB each = 20 kB

So the online computer needs to communicate 30 kB to the offline computer in this case.  And the offline computer needs to transfer back 30 signatures, which is, at best, 2 kB at a minimum.  The "maximum" a QR code can handle is 3 kB of binary, so that's 10 QR codes from online to offline.  1-2 QR codes the other way.

So the protocol should handle 30 kB without causing a lot of pain.  If the user has to wait a little bit because of a slow communication rate, that's okay because this case is abnormal and waiting 60s for the transfer isn't the end of the world.  But if they can't succeed because it's confusing and they can't figure out how many and which QR codes have been scanned, or which webcam they're supposed to be pointing at which device, and frustrated there are wires everywhere, etc.  Then there's a problem...

As you can tell, I'm very sensitive to the "convenience" of a given feature.  I think the biggest barrier to security is convenience -- users just don't use things that are inconvenient.  But I also don't want to sacrifice security, at all, no matter how much work it is for me.  Which is why there are so many recommendations here that are great, but don't quite the bill.  But I'm pretty sure a solution exists where the user can actually have both, in which case everyone wins