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

its not just the money, its the very abstract nature of the threat that makes it hard to stick to the rules.
in practice, most times people lost bitcoins the reasons were as simple as it gets. scams, no backups, unsophisticated attacks copying an unencrypted wallet.dat, stuff like that.
in my opinion, having a simple method for everyone to achieve a high level of security will have a much larger overall effect than having a perfect solution most people wont bother to use.

You don't actually need any custom hardware to use a TPM for secure wallets. It's possible to have the host OS put the display into text mode or a very simple graphics mode, and then enter the secure space. At that point only the wallet software is running and it can interact with the user, ask them to confirm the transaction etc without any interference or monitoring by malware. After the user confirms the wallet signs the transaction and hands it back to the untrusted host OS which broadcasts it.

Doing this is difficult and requires exceptionally good knowledge of operating systems level programming, but it can be done. I'm not going to say it's the best way to do it, just that it's possible.

I think you may under-estimate how secure a good old fashioned network connection can be. If you are careful to avoid buffer overflows and other parsing errors, the "offline" computer could just have an open network socket that receives signing requests.

The hard part about this setup really isn't the technology you use to move the transaction around. It's for people to resist the temptation of re-using the "offline" system for other things. After all, it's a general computer and that's pretty expensive to have just sitting in a corner holding a wallet.

A quick overview of Armory's offline wallets to setup the discussion for how to improve it (and for those that aren't familiar):

Setup Offline Wallet:
(1)  Create a wallet on a never-to-be-connected-to-the-internet-again laptop
(2)  Create a watching-only-copy of the wallet (no private keys), copy to online computer via USB key
(3)  Generate addresses and receive/verify payments online the same as any other wallet, but cannot send (and neither can an attacker)

Spending Bitcoins:
(1)  Create a transaction like normal, but "Send" button is disabled, instead "Create Unsigned Transaction"
(2)  Save unsigned transaction to USB key, take it to offline system
(3)  Review transaction and sign it, and take it back to online system via USB key
(4)  Broadcast!

This is the concept of "cold-storage", using BIP 0010 and a USB drive to initiate outgoing transactions. So far the offline wallets interface in Armory has been delightfully successful!  And I believe it is two orders-of-magnitude better security than maintaining a wallet connected to the internet!  But it's not 100% security .  

A very specialized USB autorun-based virus could compromise the offline system, getting it to sign different transactions than the user thinks he's signing, or copying private keys to the USB device and transmitting back to the attacker when connected online again.  Let me be clear: I believe that this attack vector is very complicated and difficult to execute, but it's theoretically possible.  And if it ever happens, it will be because USB drivers and behaviors are complicated and vulnerable.  If you think Linux doesn't have these vulnerabilities, think again.  (for those using offline wallets, I suggest looking up ways to disable autorun/autoplay on both computers to minimize this risk, especially the offline system -- here's one useful action you can take)

Improvements:
I believe that we can achieve 100% security (under the assumption that the wallets and software were setup securely), but we'll need a medium that can transfer the data between computers without any risk of remote code execution.  The transfer of data doesn't have to be secure (only tx data and signatures being transfered, no private data), and generally only moves a couple kB, but potentially up to 100 kB if it turns out to be an enormous sweep of a long-used wallet.  It's acceptable for the transfer to take 30 seconds under the rare circumstances that a huge transaction is being transferred, but should nominally be less than 5s for a few kB.  

It also preferably be simple.  If the user is confused by the process, they might just go to USB keys again, or skip offline wallets altogether.  Here's a list of different "media" with pros and cons:

• QR code + Webcams:  
   + QR codes are easy to generate
   + Plenty of existing software for scanning QR codes
   + Many laptops come with webcam, and can also be purchased inexpensively
   - Requires manually moving cameras and screens around to get QR codes into view
   - QR codes may not hold enough data: may need to use multiple codes
   - Need to design webcam-based UI, with feedback and possible UI for flipping&scanning multiple QR codes
   - Webcam support on all platforms is flaky (but it could be up to the user to get their webcam supported)
• Infrared (IR) Tx/Rx:
   + Many laptops already have IR receivers (transmitters, too?)
   + IR tx/rx devices are ridiculously cheap
   - Need transmit and receive on both systems, but might require manually enabling & disabling correct direction on each system (don't want a device rx'ing its own tx).  This can be confusing
   - May not be trivial to create custom IR tx/rx encoding/decoding, error correction, initiation, etc
  
• Bluetooth:  (I know very little about how Bluetooth works:  can it be setup solely for data transfer?)
   + Newer devices come with Bluetooth hardware, and drivers already included in OS
   + Data transfer should be fast
   - Older devices will need Bluetooth USB device (or other interface to offline system)
   - May allow remote code execution due to driver vulnerabilities
  
• Serial Ports:  
   + Should transfer bits very efficiently without code execution risk
   + I believe that it could be coded cross-platform easily
   - Most newer systems do not have serial ports
• Audio Transmission (using direct audio cables:  audio-out-to-mic-in):  
   + Will transfer bits very efficiently without code execution risk
   + Cross-platform
   + May be able to use existing modem software/firmware
   + Would work with smartphone-to-smartphone, smartphone-to-computer, computer-to-computer
   - Audio/signal processing might be a lot of work
• Trusted Platform Module (TPM):
   + No need for offline system at all:  all signing done on the device for which there is no functionality to read the private keys (can only sign data with them)
   - Probably expensive to create a custom TPM device, supporting ECDSA and has a display for display and verification of transaction
   - No flexibility to manage wallets & keys ... probably get to include one wallet ever (how does the wallet get on there?)
  

I would like to discuss various ways that this 100% security could be achieved, without requiring too much inconvenience for the user.  But all solutions seem like mediocre ones.   Perhaps the best solution is just looking up the most advanced ways to protect the offline system from autorun vulnerabilities and continue using USB keys (that's certainly the most convenient solution).  But I don't know how much risk you can actually reduce this way -- you'll never know for sure whether it's 100%.