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

We're talking about two different things here.

--I'm talking about a solution that can be employed by regular end-users, or small-scale business owners without being computer/linux-savvy.  I want to make it possible for people to access this level of security without being an expert in anything -- which includes avoiding anything with the command line, understanding hardware, or dealing with driver issues.  The audio solution is fantastic in this respect. 

--What you're talking about it a low-level interface for people who know what they're doing, to fill-in-the-blank.  In essence, implement the hooks to make it easy for other developers to dig in, and do it the way they want to do it.

What you're talking about is fantastic, and I actually plan to do that.  But I also want a fully-integrated solution that "works out of the box" on most systems -- both usable and secure.  If I integrate pieces of modem firmware into Armory and auto-detect the audio-link, a user only needs to plug in a cable and click an Armory button on each system.  Figuring out which /dev/* device and which protocol to use should not be part of that.  But it can be available for the hardcore users.

And I'm not entirely convinced that a "hosted solution" would not be willing to use something unique.  If Bitcoin becomes more widespread, and lots of business owners start trying to integrate Bitcoin into their web services, then why wouldn't there be some kind of customized solution for dealing with it?  As you said, it can be set up so they can use whatever device they want, but it wouldn't surprise me if something as crazy as this turned out to fit the bill, given that it is super-cheap, super-secure, and easy to setup without risk of doing it wrong.

Look into packet radio: http://en.wikipedia.org/wiki/Packet_radio Ham radio enthusiasts have already developed pretty well debugged code and protocols that does the data->audio->data chain over links far worse than any PC audio ever will be.

Maybe if you're running your web server out of your basement or your own data center. I really don't see a hosted solution of reasonable cost offering this feature at all. I still don't see how user-specified transport medium is an inferior solution. It would be easier for you to add to Armory, and allow for more flexibility for users. If someone wants a super secure audio connection, they could do that. If someone wants a perhaps equally secure serial or firewalled VPN connection, they could do that.

After doing some more research, and receiving my 12 ft male-male audio cable, I was able to play and record data between two systems over the audio jacks with no problem.  There are probably some physical risks associated with this (as kjj suggested), but the quality of this potential solution is worth breaking some hardware to find out

Additionally, a coworker pointed out that modem firmware is designed for exactly this kind of communication:  noisy analog channel, with unknown quality and potential bit-rate.  The job of the modem software is to figure it out, and give you a nice clean interface for error-free file transfer.   And modems over phone had pretty good transfer rates, relative to the data sizes we need here.

So now I come to those who are possibly more familiar with this process:  how the heck do I hook these things up together?  GKermit seems to be ideal tool for communicating over the audio cable, but I don't know how to set it up so that it knows to send out the headphone jack and receiving through the mic jack.  I also just found an article about how to "retask" your mic port as a headphone port, which means it's theoretically possible for two-way communication over one cable... but probably not ideal to try that if I don't have to.

On the upside, gkermit is part of the Ubuntu repos, which means it should be straightforward to setup on Linux.  And it looks like binaries are available for Windows.  So who wants to help me figure out how to hook these pieces together?  Hooking up Kermit to audio ports in linux is fine for now... I expect the solution will be 90% portable to windows when it works in Linux (Kermit project brags about this).

I do recognize this doesn't work for the Raspberry Pi or Android devices which don't have a Mic jack.  Perhaps I'll have to come up with something else for that situation.  Perhaps the difference in security between USB keys and this audio solution is only "important" for those who are protecting enough money that buying a $50-$200 laptop just for offline key management is completely in the noise.

On a related note:  I could also see this solution used as a half-way for webservers.  For instance, your online webserver will maintain the audio connection with the "offline" wallet, which will actually be automatically allowed to sign some transactions.  However, it would be programmed to not sign any transactions over amount X, and not more than Y BTC per day.  Any such transactions will be queued for manual confirmation.  X and Y could be set in such a way that accommodates 95% of standard customer use-cases, but limits loss due to server compromise to less than 2% of the offline wallet, or something along those lines.

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

Sending large amounts of data using QR-codes is a pain. However, you can compress an unsigned transaction pretty well is both sides agree on a simple protocol.

Broadcaster - The party that generates the unsigned transaction and broadcasts the resulting TX.
Signer - The party that creates the actual signature

To create a transaction we need to know something about the Receiver and the Funding Outputs:
 1) The receiving addresses:
 1.a) The address
 1.b) the amount to send
 2) a number of outputs used for funding inputs. For each we need to know:
 2.a) transaction hash and index of the output
 2.b) the script of each output point
 2.c) the key to use when creating the signatures for each input.
 2.d) the value of the output

Savings on Receiver
If we assume that there is always only one receiver, and that all change is sent-back-to-self, then there will only be one address and one amount to send. The Sender can then send the change to its own address. An address can be reduced to 20 bytes if we eliminate the network byte and the checksum (QR-codes have their own checksums). With this we are down to 20+8 = 28 bytes.

Funding Outputs
If we assume that there is only one key in play, and that we have always transmitted standard transactions, then we can guess the script of the outputs, as they always send to our own address. This means that we only need to transmit: tx hash, outout index and output value = 32 + 4 + 8 bytes = 44 bytes. That is 44 bytes for each input.

For simple transactions where we only have one input we are down to 28 + 44 bytes = 72 bytes. Can we represent that in a single QR-code?
If the transaction cannot be funded with a single unspent output we can ask the user to "compact" his wallet by a series of sends-to-self.

The Signer needs to send the transaction back to the Broadcaster. However since the Broadcaster can generate most of the transaction only the actual signature is needed. How big is that? I don't remember.

Unless I have forgotten something crucial this should work.

FYI:  someone asked about using a command-line script to sign your offline transactions, instead of using the Armory GUI/application.  This is a great idea.  So I went ahead and made a script for doing it.  I committed the script to the master branch, and showed what it looks like to run it on the main Armory thread:

https://bitcointalksearch.org/topic/m.1186265

I copied the script output at the bottom of this post, so you can view it without leaving this thread. 

Discussion:  I think if you are a bit linux-savvy, there's a bit of security improvement you can gain leveraging this script.  Instead of booting normally into your desktop manager, you can boot into runlevel 3, and then manually mount the USB key and execute this script to sign the transaction.  I bet runlevel 3, with no desktop manager would have dramatically less vulnerabilities associated with it.   I won't explain how to do this though:  if you don't know already, you will probably spend a lot of time with a semi-broken offline computer trying to figure out how to escape runlevel 3. 

---

@Jan:

I am saving anything to do with Android/smartphones until I get multi-sig implemented.  The plan was to simply implement two-factor auth using your phone, which holds one of the two wallets.  Then you create and sign the tx on your main system, and then perhaps QR codes to get the half-signed tx to your phone, then add second signature and broadcast from the phone. 

Although, admittedly, disabling the antenna on the phone may make Android very usable as an offline device.  The only problem I haven't fully evaluated yet is how to get the data to it:  I hate the idea of possibly needing to scan 25 different QR codes to get the data to the phone.  And dealing with webcam drivers on the primary system, etc.  But it's doable. 

Perhaps a "video" sequence repeating all 25 QR codes at 30 frames/sec, each frame will have something like "12 of 31" in it and the phone will keep watching and processing until it's got all the frames.  Probably a serious battery drain, but possible.

---

Here's example output of the CLI offline signing script:

I would use QR-codes and let an Android phone manage the private key. Setup:

• Buy a cheap android phone with a camera, remove the SIM-card, disable wifi/NFC/Bluetooth and nuke it to factory settings
• Install only one app on the device. "Bitcoin Key Manager" (does not exist, but functionality described below)
• Generate a private key and print it out on a piece of paper as a QR code (maybe using a 2 of 3 scheme with Shamir's Secret Sharing)

To send funds:

• On computer: Generate unsigned transaction on computer and show it as a QR-code on the display
• On android: Load private key into Bitcoin Key Manager on Android device by scanning your paper backup
• On android: Scan unsigned transaction with Bitcoin Key Manager, it will display which address get what amount of coins
• On android: Click Sign and Bitcoin Key Manager signs and displays the transaction as a QR-code on its display
• On computer: Scan signed transaction QR-code using a web-camera, and broadcast transaction
• On android: Close Bitcoin Key Manager, private key whiped from memory

If you keep your android device and the paper backup stored securely this is a damn safe setup. 

With the above scheme the computer could be replaced with another android device which is your primary phone.

I always get nervous plugging a stereo headphone output into a computer microphone jack.  The ring is connected in different ways in those two systems.  In the microphone jack, it is usually tied to a current limited +5v source.  In the headphone jack, it is a nominal +/-1V output.  I haven't seen any get burned out, but I don't like connecting them together.  Mono plugs are no better, since they have no ring, just a sleeve all the way to the tip insulator, which means that they are shorting the +5v bias to ground in the microphone, and the right channel output to ground in the headphone jack.

I actually did that exact same thing tonight, took the PA output from a device and plugged it into a computer microphone jack.  Worked just fine, actually, but I did spend a bunch of time in Radio Shack looking for an adapter that would let me leave the right channel and microphone bias floating.  (No luck, the stereo to dual mono Y adapter didn't split tip/ring like a sane person would expect, it tied both to both.)

But, yeah, you can totally transmit binary (mark=tone/space=silence) this way.  Hell, you could probably even do fancy stuff like FSK or QAM.  FSK is super easy to send, somewhat less easy to receive.  QAM is less easy to send, and much less easy to receive.

Are you going for bidirectional over two cables?  If so, you can just pretend to be a modem, but without the messy shared channel.  Start slow, handshake, then crank up until you start getting NAKs.

If unidirectional, start slow-ish, and give the user a button to "stop and try slower".  Have the receiver indicate errors fairly quickly, and make sure you can get it back into a start-able state ASAP.

You can probably even find DSP libraries if you don't want to mess around with coding and signalling.

Another downside... not all devices that could serve as offline wallets have sound cards with line-in ports. Case in point, the Raspberry Pi.

For the ones I've seen in the past this was relatively easy: using SCSI command blocks: get MODE SENSE(6), clear the appropraite bits (READD,WRITED,FORMATD,LOCKD), issue MODE SELECT(6) and then again MODE SENSE(6) to verify which bits took the change. Afterwards just do a "remount -o rw /dev/sdX". Other devices had more complex protocol, but it seems that "Lockable Mass Storage Specification" is no longer secret and is available at www.usb.org.

I'm disappointed.  I thought you were going to tell me how to override the write-protect.   You've got me wondering how difficult it is to do it... 


On another note, I just ordered a male-male analog TRS cable (double-ended headphone jack).  I determined that the audio coupling is now 100% perfect once you connect the headphone-out to mic-in with such a cable.  The SNR should be fantastic, and if both sound cards sample at 44.1 kHz there's a lot of room to get at least 1 kB/s, which would make me happy.  That's assuming that I can transmit and receive signal amplitude reliably.  I don't have much experience with it, but I look forward to digging into it in the kind of near future.  (I just ordered a couple double-ended audio headphone cables... whatever they are called...)

The downside, is that if the user's online computer is their primary computer, they will be inconvenienced by having to swap their speakers around all the time.  On the other hand, they can always get an extender, and keep both ends on their desktop, and just lean over and switch them when needed.

Recommendations welcome!

Thank you very much. Ritek Corp. device 0x0165 is not on my shortlist of known fraudulent devices. (Fraudulent meaning: fake encryption plus maybe fake write protect and other misrepresentations.)

I like the idea.  I will think about how to do it, though I have little experience at the device level, but my guess is it's not terribly complicated.  I might need to push-start on that, though.




I tried to grab a ton of info from the USB key, with the write protect in both states.  Here's the output of lsusb -v, and dmesg.  It pretty much looks the same, except for the device number changing between inserts, and the frequent mention of "device is write-protected":

Write Protection ON


Write Protection OFF

Crossposting this from the Armory thread:

Instead of explicitly defining the hardware layer, would it be possible to have Armory be agnostic about such things? I'm not sure how/if this would work in Windows, but I'm imagining that a *nix user could set up a device (/dev/foo) on each computer that when read from/written to would communicate with the other computer. Then in Armory, the user would just specify which device should be used for communication. The user would be liable for setting up the connection and making sure that connection was secure, and Armory would attempt to communicate with itself through that device, failing gracefully if unable.

You're right.  I should focus on things I understand.  Unfortunately, kernel modules and drivers are not my forte.  And while USB isn't foolproof, it's something that regular users can understand, and requires a resourceful attacker to compromise (should do a good job of preventing attacks of opportunity, and require a targeted attack).  Mainly because it requires analyzing the attack surface and automating a solution to run when it gets on the target system.  Instead of being able to log in, dig around, and figure it out with a human-in-the-loop.

The audio-coupling is looking interesting not only because there's no risk of remote code execution, but also because I'm a signal processing/statistics guy.  I'm sure lots of people have already looked at this problem in general, but I think I'd have fun figuring out how to improve throughput of the audio channel.  Unfortunately, there's plenty of other development for me do before I get to this, but I have some friends at work (who do signal processing with me) who might find this to be a wholly interesting problem to work on with me.

You aren't wrong. But you have to make a conscious choice whether you are trying to achieve security or security theater or cargo-cult security.

I would advise you to use the means of communication between the machines that you are sure you can understand. I don't like USB flash drives because of awfull and non-obvious failure modes they create. I do like OSTA-UDF formatted CD-R / CD-RW / DVD-RAM. It makes many thing obvious, eg. that the data actually stays there after the deletion, how to completely destroy the data, documentation is in the open, there is an open-source UDF format checker, etc.

The audio interface also looks like splendid idea for the near-field communication.

Next time I'm at work, I will try this.  I don't have any of the write-protected USB keys like we have at work.  However, I noticed that just about every SD card has a switch built-into it, but the one I have in my camera doesn't work.  I'll see if I can find another one and try it..


Well, okay.  I don't want to get into another useless-or-amazing debate, but I imagine there's still some value in it.  Both Linux and Windows refuse to mount in any way other than read-only.  Maybe I'm a n00b.  But, I just did some googling and didn't find anything, do it must not be trivial to do.  Therefore, even if true hardware switches aren't 100% foolproof, it probably does it make the attacker's job much more complicated (and probably restricts it to the few people that know how to read the manual in whatever native language it's written in). 

Unfortunately, I think it's still a little too clunky to have different transfer methods for each direction (not to mention the necessity to fiddle with the write-protect switch, which I've had break before from too much use). 

This.

True hardware write protection doesn't really exist, and never has, outside of rare special hardware.  It is always soft write protection.

Indeed, "a lot of stuff that goes on under the hood is completely unnecessary". This USB flash business is extremely competitive and very prone to fraud. I'm not talking about "format 4GB drive as 16GB drive" fraud. I'm talking about various supply chain manipulation schemes that would require separate essay.

You may think that the drive you use has a hardware write protect. But somebody who can read the Chinese or Russian documenation to the controller IC used therein will know that you are just couple of ioctl() calls away from disabling the write protect and enabling the USB CD-ROM drive functionality.

The only way to be safe is to know exactly what is the exact controller model used and know how to verify its operation. The popular Silicon Motion ICs are one of the worst offenders. Trawl the Internet for ChipGenius and then trawl the Chinese and Russian web sites for various utilities.

Can you post what "lsusb -v" says about your USB drives with write protect?