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

kjj,

There's a couple reason why the solution currently implemented in Armory is the way it is:

(1)  The offline computer does know what it's signing.  If you look at BIP 0010, you'll see that it includes all the supporting transactions of all the inputs it is signing for.  All inputs reference the TxOuts being spent by (TxHash, TxOutIndex).  By including those transactions themselves in the BIP 0010 packet, the offline system can hash the transaction, compare it to the hash of the input being signed, and then look at that transaction and see the value of the input.  Additionally, it will need the TxOut-script being spent, so the previous transaction provides that as well.  There's no way to manipulate or trick the offline system into signing different inputs or misrepresent input values.  Similarly, the outputs are part of the signature.  The target address/hash and the output value is all part of what's being signed.  

So, if someone manipulates the packet at any point, they either break the signature, produce an invalid tx, or the offline system confirmation dialog will show different info than the user is expecting.  This is secure, despite the offline computer not having any blockdata at all (or rather, the offline system is given just as much blockdata as it needs to know what it's signing).

(2)   The ASCII armored BIP 0010 was not designed for offline transactions.  It was designed for multisignature transactions, so that this "packet" could be passed around to relevant parties, and they can add their signatures to it, pass it on, combine with other packets, etc.  The ASCII-armoredness simply improves its "fluidity" so that it can easily be copied inline into emails, if necessary.  

It just so happens that it's useful for offline transactions, too:  offline transactions are simply 1-of-1 multisignature transactions, for which the online computer needs to collect signatures.  By creating BIP 0010, it allows for any combination of programs (that use BIP 0010) to be able to interoperate -- either offline transactions, or multisigs.

Offline wallet is useful.

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

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

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.

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.

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!)

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

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

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.

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

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

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.

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.

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

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 

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://bitcointalksearch.org/topic/the-sound-of-a-bitcoin-53371

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.

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.

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



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