Improving Offline Wallets (i.e. cold-storage)

[etotheipi]

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

[Mike Hearn]

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.

[fornit]

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.

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.

[etotheipi]

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.

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 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 problem with this is that the online computer will likely need to have two ethernet ports (unless it uses wifi for its primary connection).  But, it's an excellent suggestion: ethernet is obviously well-supported on all systems, and if it's easy enough, I could just do it for the users that can use it.  I just have to do some work to figure out crossover cables and initiating connections, exchanging, etc (I've never done much networking like this before...)

[pc]

If you're worried about an attacker which is specifically targeting your software (which is what it sounds like), I don't think it matters how the transaction gets from the online system to the offline system. The attacker will just make the transactions and addresses that you see on the online (and presumably infected) system be the attacker's address instead of the person you were trying to pay. Unless the user is going to verify all bits of the address that they're trying to send to via some non-online means, I don't see how the user is supposed to know what the addresses are supposed to be that they want to pay.

[jim618]

It sounds a bit off the wall, but you could also talk to your offline system by acoustic coupling:

Have a look at this old thread of mine:
https://bitcointalk.org/index.php?topic=53371.0

I think in there we worked out a small tx is about 1KB.
You could use the speaker on your networked computer to send the unsigned tx to your offline computer.
It hears the unsigned tx, decodes it, signs it and then send it back acoustically.

It is like using your old offline computer as an acoustic modem.

[Herbert]

As far as I know most Bluetooth implementations offer the serial port protocol, basically having a virtual serial port connecteded over Bluetooth. In this scenario you have the Bluetooth wireless connection with pairing protection (same PIN needs to be entered on both devices to establish the connection) and the simple-to-use serial port communication.

On the other hand in my experience the setup of this BT-Comport is complicated and unstable depending on operating system and hardware. I would prefer this solution if the setup would be really easy. But in the end tbh i would use the USB-approach. I consider myself educated enough to prevent all sorts of autoplay-attacks on the dedicated laptop 

[etotheipi]

I think, for most users, the USB key setup is absolutely fine.  I'll just add some warnings and links to information about protecting yourself against autoplay attacks.  However, some users with more $10,000 worth of BTC will happily battle a 100% solution, especially if it only needs to be done once.  A little inconvenience is worth the 100% peace of mind.  In that case, minor inconvenience is not a show-stopper, the only requirements are that it is truly 100% and that the process does not become remarkably complicated for mixed OS setups.

In that case, perhaps QR codes and webcams are the way to go.  It might be a little bulky, but getting two USB webcams that can be moved around by hand to scan the displays is probably acceptable.  The determined user will figure out how to get their webcam setup, and they really only need to do it once.  It's just a bit more work for me to setup the interface.  And the interface might be confusing or overwhelming, but I will hide it under an "Ultra-security" user-mode targeted at users that really want this solution.
 
P.S. - Jim618, I really like your idea.  I saw that thread a long time ago and thought it was kinda silly.  But nearly all systems have speakers and microphones, it would just be a bit of work to do the signal processing for it:  but that's actually my specialty at my job!  Hmm....  

[jim618]

Hi etotheipi,

It is a bit "1980s" but it is the data rate which I could not quite get there.   I could only get up to 500 baud which is too slow.
Tantalisingly close though.   Say 2000 baud and you are around 250 bytes per second.   1KB per 4 seconds.

Maybe it is something that "would do for 2012" i.e use it and then rip it out and put in a drop in replacement when something better came along.   It is the ubiquity of microphones and loudspeakers that made me look at it.


Whatever codec / data transmission route you go please make the protocol nice and open as then it brings the possibility of:

1) Multibit creates a transaction with a watch only wallet of a particular private key (not implemented yet)
2) Multibit passes it over using the "data exchange protocol" to Armory to an offline wallet with the same key in to sign.
3) Armory signs the tx, transmits it back to Multibit
4) Multibit broadcasts.

There is support in bitcoinj for each of the steps.
Whilst multibit does not have watch only wallets bitcoinj supports them so I would like to put them in eventually.

[etotheipi]

Hi etotheipi,

It is a bit "1980s" but it is the data rate which I could not quite get there.   I could only get up to 500 baud which is too slow.
Tantalisingly close though.   Say 2000 baud and you are around 250 bytes per second.   1KB per 4 seconds.

Maybe it is something that "would do for 2012" i.e use it and then rip it out and put in a drop in replacement when something better came along.   It is the ubiquity of microphones and loudspeakers that made me look at it.

Whatever codec / data transmission route you go please make the protocol nice and open as then it brings the possibility of:

1) Multibit creates a transaction with a watch only wallet of a particular private key (not implemented yet)
2) Multibit passes it over using the "data exchange protocol" to Armory to an offline wallet with the same key in to sign.
3) Armory signs the tx, transmits it back to Multibit
4) Multibit broadcasts.

There is support in bitcoinj for each of the steps.
Whilst multibit does not have watch only wallets bitcoinj supports them so I would like to put them in eventually.

That is why I created BIP 0010, to make sure that at least the data being transmitted is standardized in some way.  I'm currently using BIP 0010 in Armory for the offline transaction, but I haven't received any real feedback from any other developers about possible improvements to the "standard" to make it usable in more diverse settings.  In particular, I will have to change BIP 0010 to accommodate P2SH scripts -- BIP 10 originally assumed vanilla OP_CHECKMULTISIG transactions...

If I'm going to update BIP 0010, I might as well update it with over developers' feedback along with P2SH scripts and comment lines...  But that's probably for a different thread.  In fact, there is no official BIP 0010 thread... maybe I'll start one.

It's a shame that the bit-rate is too slow for the audio solution.  It was starting to look appealing, before you mentioned its speed.

[cypherdoc]

i vote for as close to a 100% solution as possible.

[etotheipi]

i vote for as close to a 100% solution as possible.

What I'm getting from this thread is that I should have two options:

(1) Default:  Current USB key transfer, with instructions for how to secure your offline system to minimize risk (and keeping up-to-date A/V, etc on the online computer).  I believe this method is working so far for the few people that have used it, and very straightforward since everyone knows how to use USB keys.

(2) Pseudo-Hidden Ultra-Security Option:  One of the above methods that achieves actual 100% (i.e. pure ASCII data transfer over very narrow-band, such as audio, or QR codes).  It will be available to those that seek it, but will not be the default and will require some work to get to it.   I believe that having it directly out there as a regular option would be counterproductive:  people will naturally select the "more secure" option, then probably give up on it entirely when it's too complicated.   

I'd rather let people use the USB option and feel safe about it, than risk them not using anything.  The ultra-paranoid users will be made aware of the "mythical" ultra-security option, and can go seek out how to set it up and use it (or may see it while sifting through menus/settings).

[etotheipi]

Anyone familiar with Panda USB Vaccine? 

It's a free tool that supposedly will disable autorun completely on the host machine, but also has a way of creating a dummy, write-proof autorun.inf file that can only be overwritten through a drive format.  This guarantees that that no other program can create a malicious autorun.inf.

Of course, there are other vulnerabilities with USB drives, but I believe the auto-run is the worst.  If I find enough favorable reviews, I will run this tool over all the USB keys that I distribute as crowdfunding rewards.  Hell, if it really is as good as it sounds, I might as well put Panda on the drive, to be used on the offline computer the first time (manually initiated, of course).

Anyone have other recommendations for securing USB keys and autorun vulnerabilities?    I remember there used to be a vulnerability having to do with file icons, that caused compromise the moment the file browser opens (I think it was a png library bug).  I think this thread is a perfect place to discuss these kinds of threats and how to avoid them.

[zer0]

wouldn't it be easier to just scp over the transaction info from the 'offline' computer to the reg system through internal lan? if you have a pf firewall setup and sshd disabled on the offline comp it's 99% security if set up correctly. set it to only ever allow outgoing connect to internal IP of your other comp and only allow SSH port you specify. use key based auth.

then nothing touches your offline system, except internal lan cable that is firewalled. when not in use unplug the lan cable if paranoid

[etotheipi]

wouldn't it be easier to just scp over the transaction info from the 'offline' computer to the reg system through internal lan? if you have a pf firewall setup and sshd disabled on the offline comp it's 99% security if set up correctly. set it to only ever allow outgoing connect to internal IP of your other comp and only allow SSH port you specify. use key based auth.

then nothing touches your offline system, except internal lan cable that is firewalled. when not in use unplug the lan cable if paranoid

Not everyone has a spare ethernet port on their online computer, and doing all the system configurations for one-way SSH is probably non-trivial and quite prone to error (some users will end up less security than the USB key solution because they did it wrong).  Plus we have to trust that SSH is secure the way we think it is.  Sure, it's a high-quality protocol, but still requires "trust" that no one has found some crazy vulnerability in it (and that it was setup correctly).  On the other hand, transferring raw ASCII tx through an IR stream is trust-less:  it's simply impossible for the online system to trigger arbitrary code execution on the offline system.  Hence why I call it 100%.

If users are going to be inconvenienced by this solution (i.e. do a lot of work to use it), it should be at 100% mark, not 99% (and I think USB keys with appropriate OS preparation is close to 99% already).    On the other hand, I'm not against the use of your proposal in general, but I don't think it's a good, cross-platform, any-regular-user-can-do-it idea.  Or perhaps I am overestimating the amount of work it takes.   But if the person is using a Windows online system, it may be tough to setup SSH server properly (or at all!).  The idea should use SW/HW supported across all platforms (with minimal driver fuss), and not require any complicated OS configurations.  (that's why I love the audio idea)

P.S. - I just executed a rather "large" offline transaction:  there were a lot of inputs and large supporting transactions (used for input value verification).  It is probably the longest I've seen so far.  And it was 14.5 kB.   Using the audio solution, that's about 1 minute to move the data one way.  Another minute to move it back after signing...  Hmm...

[jim618]

On the audio stuff I forgot to mention that I never looked at frequency multiplexing.
I chose PSK encoding as it is quite narrow bandwidth. PSK250 (250 baud) uses about 700 Hz bandwidth.
I think the 'common denominator' sample rate for sound sampling is 8kHz so it should be possible to frequency mux it a few times to get more throughput.

8kHz might give you 2000 baud for a software modem.

A 14.5 kB tx.  I think Andreas found he could compress tx with gzip by 25%.
Say 20%.
That is 11.6kB.
Say 10 symbols per byte (protocol overhead + error checking)

That is 116kSymbol to tx at 2000 baud. Just under a minute both ways as you mentioned.

You would want to leave some bandwidth for a backchannel but this would just be ACKs and a few bytes progress report so would not be much.

For point of sale it is laughably slow but for talking to an offline computer it is right on the borderline of doable (the most annoying place for anything to be!)

[kjj]

• 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

Don't write off serial just yet.  While new computers don't come with serial ports, thanks to USB, you can add a port to just about anything for like $10.  And two of the other things you listed, bluetooth and infrared, are just virtual serial ports.

Way back in June, I wrote up a plan to give the standard client the features that would be needed to let users detach their wallet nodes from their network nodes.  I saw it as the first step towards having small dedicated hardware wallets.

If you are planning to do a serious offline mode, you might want to take a look.

[etotheipi]

• 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

Don't write off serial just yet.  While new computers don't come with serial ports, thanks to USB, you can add a port to just about anything for like $10.  And two of the other things you listed, bluetooth and infrared, are just virtual serial ports.

Way back in June, I wrote up a plan to give the standard client the features that would be needed to let users detach their wallet nodes from their network nodes.  I saw it as the first step towards having small dedicated hardware wallets.

If you are planning to do a serious offline mode, you might want to take a look.

kjj,

Maybe you already know this, but just to clarify:  I already have a very serious offline mode.   Armory successfully implements offline wallets, but not quite the same way as was proposed in the thread you linked.  Instead of the offline computer creating and signing the transaction (which requires the blockchain), the online computer has a "watching-only wallet" and constructs the transaction for you (as well as generates addresses and verifies incoming payments for regular usage).  The unsigned tx is passed to the offline computer which doesn't even need the blockchain, it displays the tx data to the user who confirms+decrypts wallet+signs.  Then, it's transferred back and broadcast.  It doesn't use any kind of JSON interface, it's based on passing ASCII packets back and forth much like PGP ASCII-armored signature blocks.  And BIP 0010 was created so that if other clients implement it, you could have different clients online and offline and it will still work.  And none of it is sensitive, so there's no need to encrypt the data, or worry about wireless transmission.

Back to your idea:  I really like it, and I will look into the USB-serial-port adapters.  Maybe parallel ports, too (I'm seeing adapters for both).  If it's $20 to get this serial link established with no risk of arbitrary code execution, then it's a win!  As long as it's not too much work to get setup on different OS's -- I'll have to do some reasearch concerning the complexity of establishing serial links via USB adapters in Linux, Windows and Mac.   Ideally, each system would just see it as a native serial port and then it would just work... but I doubt it's ever that simple.

Anyone have experience sending bits over USB serial ports?  I envision that most old-laptops will have one, so many users would get away with just one adapter (online USB to offline serial).  But other users would need one for each:  one USB-to-Serial(M) and one USB-to-Serial(F).  Would these two setups have different charactistic (i.e. do I have to accommodate them separately in the code?)  I've never actually pushed data over serial/parallel ports, other than knowing it's a fairly simplistic interface.

[bitfoo]

Anyone have experience sending bits over USB serial ports?  I envision that most old-laptops will have one, so many users would get away with just one adapter (online USB to offline serial).  But other users would need one for each:  one USB-to-Serial(M) and one USB-to-Serial(F).  Would these two setups have different charactistic (i.e. do I have to accommodate them separately in the code?)  I've never actually pushed data over serial/parallel ports, other than knowing it's a fairly simplistic interface.

I've done this on Linux, and it's as simple as it can possibly get. You plug in the USB to serial adapter, and you magically get a serial device, "/dev/ttyUSB*". You then use some termios calls to set some attributes and baud rate, and just start communicating! Both sides are identical in terms of both hardware and code. (i.e, they're both either M or F, don't remember which).

[casascius]

Anyone have experience sending bits over USB serial ports?  I envision that most old-laptops will have one, so many users would get away with just one adapter (online USB to offline serial).  But other users would need one for each:  one USB-to-Serial(M) and one USB-to-Serial(F).  Would these two setups have different charactistic (i.e. do I have to accommodate them separately in the code?)  I've never actually pushed data over serial/parallel ports, other than knowing it's a fairly simplistic interface.

I've done this on Linux, and it's as simple as it can possibly get. You plug in the USB to serial adapter, and you magically get a serial device, "/dev/ttyUSB*". You then use some termios calls to set some attributes and baud rate, and just start communicating! Both sides are identical in terms of both hardware and code. (i.e, they're both either M or F, don't remember which).

I have done tons of serial.

Serial-to-USB adapters are male.  To wire two serial ports together, you need a cable which is often sold as a "null modem F-F gender changer".  The "F-F gender changer" part refers to both ends being female, and the "null modem" part means essentially the same thing as "crossover" does in the context of ethernet.  It means some wires are twisted to make up for the fact that two peers are being connected together.

Only three wires are needed for basic bidirectional communication, pins 2,3,5.  Pin 5 goes straight across, pins 2 and 3 are "crossed over".  Pin 2 of each interface connects to pin 3 of the other interface.

For experimentation, you can actually short pins 2 and 3 together, which causes a "loopback".  The serial interface will "receive" everything sent through it (it doesn't know it's sending to itself).  Shorting pins on a serial port won't hurt it.

Once connected, it really is simple and straightforward.  Open the port, set the parameters (e.g. termios in linux), and anything you write from one side will be read on the other, sort of like a pipe.

Settings you will typically set:

• baud rate - simply has to match on both sides.  9600 is a conservative balance between reliability and throughput, but if you need the throughput, by all means, feel free to increase it.  Increasing the rate simply lowers the maximum length of your cable, but anything not leaving the room should work flawlessly all the way up to the typical maximum of 115200, or 11Kb/sec.
• data bits - always choose 8
• stop bits - always choose 1
• parity - always disable - it's worthless error detection (use a hash or CRC on your messages instead)
• flow control - for bitcoin purposes, just disable this... this is used for asking the interface to wait, for throttling the flow of large files on slow connections or computers... the 1980's are over, your computers are now far faster than the serial interface and the interface itself is the only bottleneck, so there is no reason the interface should ever need to wait, hence this can be disabled and forgotten about

Serial has no error detection or correction, so you'll have to implement it.  However, in practice, the kind of errors you're most likely to see is stray characters when connecting or disconnecting cables - actual data loss on a solid connection is extremely rare.  Generally, just having a simple checksum on messages, ignoring messages with checksum failures, and retrying messages that got no response will work about 99.999% of the time.  In fact, even with no effort to detect or correct errors, it will still work perfectly about 99.999% of the time.

Offering a character-based interface (similar to telnet) is simple over serial, and is easy to troubleshoot.  If you create an inbound serial interface that accepts commands or messages that are plaintext terminated by carriage return, then you can use any off-the-shelf "terminal" program to interface with it and troubleshoot it.  You won't be able to calculate your hash/checksum by hand, but if you simply make it optional, then you won't have to.  (For example, common GPS receivers use this methodology to transmit messages, each is one line of text.  If the end of the message ends with an asterisk and some hex numbers, that's a checksum.)