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

[Stephen Gornick]

(1) Physical cables connecting the two computers can make people really unconfortable.  I feel really uncomfortable, even knowing that nothing can happen
(2) There are some extra lockdown procedures to execute to make sure that your version of linux doesn't allow logins over the serial connection.  I was already aware of this, but it dawned on me that this could actually have a net negative impact if I convince people to use this system and a certain number of them don't set it up properly.

I was just reading about how the security industry doesn't like the "air gap" network concept (apparently) because it gives a false sense of security:

 - http://colinrobbins.me/2012/07/03/overcoming-air-gap-security-failures/
 - https://www.tofinosecurity.com/blog/1-ics-and-scada-security-myth-protection-air-gap
 - https://www.tofinosecurity.com/blog/scada-security-air-gap-debate-over
 - http://www.blog.beldensolutions.com/scada-air-gaps-a-philosophy-issue-not-a-technology-issue/

One weakness they identify though is that their data on the USB drive can be sensitive and needs to be wiped or destroyed but with Armory transactions that's not a concern.  To be fair, their systems are control systems and have a much higher frequency of transfers between the air gapped system and networked systems, where an offline Armory system conceivably would not need any more subsequent transfers after it is operational other than transaction data.

I'd rather use USB keys than risk impatient people just hooking up the cable and carrying forward because they don't realize that issue.

I see one step in their air gap checklist is one not considered so far here -- and that is to use yet another separate offline or otherwise well-secured system that scans the USB drive (they refer to it as "sheep dip").

[2112]

I was just reading about how the security industry doesn't like the "air gap" network concept (apparently) because it gives a false sense of security:

I tried to find some historical information about the use of the term "air gap" in network security. Curiously most of the original sources are now gone.

The guys who popularized it in the USA were the Israeli dudes from Whale Communications. They were later acquired by Microsoft.

http://en.wikipedia.org/wiki/Microsoft_Forefront_Unified_Access_Gateway

The original "air gap" was a RAM-disk (physical RAM sticks) with a SCSI interface and dual SCSI controllers.

But the most memorable were their sales seminars. They were always scheduled in the rooms with tall dropped ceilings and sometime in the midst of the sales spiel they would have an armed SWAT team to land in the room through the ceiling and secure the presentation area. (Not a real SWAT, some sort of a rent-a-cop SWAT.)

As you may understand this sales tactic received a very bifurcated response. Some were clearly impressed; some considered it ne-plus-ultra in cheesiness. I could not find any left over photo essays from that era.

I guess the opinion about "air gaps" will have to stay bifurcated forever.

[etotheipi]

I disagree with those articles on "air gaps".  Trust me, I get it -- there's lots of ways for bad stuff to still compromise your air-gapped system.  But the available attack vectors on such a network are so much more complex, you've wiped out 98%+ of the threats.  Most importantly, you've removed threats to opportunity, as opposed to threats by determined attackers.   You have to be targeted to be compromised, you're in much better shape than having some script kiddie stumble into your system because your mediocre IT guy forgot to re-enable the firewall/whatever after disabling it to SSH his MP3s from his home computer [insert other silly things that can go wrong].  

I mean, it's worth recognizing that threats still exist with an air gap.  But to brush it off as if it's useless is just someone begging for attention about how smart they are.    

And, by the way, there are USB keys with write-protect switches.  We have to use them at work for exactly this reason.  We disable write-protect to put data on it from the online computers, and enable it before plugging it into the sensitive computers.  We are required to attempt to write data to the key from the sensitive system and receive an error, before removing the key.  If the write succeeds for some reason, then we either destroy it or protect it the same as the sensitive systems.

This could be useful for Armory, though in increases the CONOPs complexity a bit.   But it works because the data you're moving from online to offline is the bulkiest (could be 100kb+, not quite right for QR codes).  But the data that has to come back is only a couple hundred bytes.  There's a lot more options for moving 100B vs 100kB (like audio-coupling).


In another direction, can't someone recompile the kernel and a few of the programs like nautilus, to basically remove all the USB key risks?  Basically turn it into a smart serial port?  Maybe that's an oversimplification (and I'm sure 2112 will let me know just how much).  But there's clearly a lot of stuff that goes on under the hood when you plug in a USB key, and I'm sure most of it is completely unnecessary if you know you are going to use the USB drive for exactly one purpose:  to move a few kB of text back and forth.

For instance, what would it take to modify/setup nautilus to just not do icons?  I guess GDM would need to be modified, too?  Skip the whole process of ever reading icons from files and just display a boring square.  Don't process anything on the USB key, just mount it and let me copy files back and forth.

It seems that such a modified system could solve a lot of solutions.  It doesn't stop employees from bringing virus-laden porn onto their secure system, but at least you've removed one vital piece of the attack surface.

[2112]

to basically remove all the USB key risks?  Basically turn it into a smart serial port?  Maybe that's an oversimplification (and I'm sure 2112 will let me know just how much).  But there's clearly a lot of stuff that goes on under the hood when you plug in a USB key, and I'm sure most of it is completely unnecessary if you know you are going to use the USB drive for exactly one purpose:  to move a few kB of text back and forth.

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?

[kjj]

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.

This.

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

[etotheipi]

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

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

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

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

[2112]

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

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.

[etotheipi]

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

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.

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.

[chrisrico]

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.

[etotheipi]

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.

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.

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

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

Code:

$ sudo mount /dev/sdc1 temp
mount: block device /dev/sdc1 is write-protected, mounting read-only

/dev/sdd1 on /media/disk-1 type vfat (ro,nosuid,nodev,uhelper=hal,shortname=mixed,uid=1000,utf8,umask=077,flush)


Bus 001 Device 011: ID 0b27:0165 Ritek Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0b27 Ritek Corp.
  idProduct          0x0165 
  bcdDevice            1.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               98mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               8


$ dmesg | tail

[445341.912213] usb 1-3: new high speed USB device using ehci_hcd and address 12
[445342.050773] usb 1-3: configuration #1 chosen from 1 choice
[445342.053600] scsi12 : SCSI emulation for USB Mass Storage devices
[445342.054349] usb-storage: device found at 12
[445342.054353] usb-storage: waiting for device to settle before scanning
[445347.052579] usb-storage: device scan complete
[445347.053557] scsi 12:0:0:0: Direct-Access     RiDATA                    0.00 PQ: 0 ANSI: 2
[445347.057410] sd 12:0:0:0: [sdd] 7946240 512-byte hardware sectors: (4.06 GB/3.78 GiB)
[445347.076676] sd 12:0:0:0: [sdd] Write Protect is on
[445347.076685] sd 12:0:0:0: [sdd] Mode Sense: 0b 00 80 00
[445347.076691] sd 12:0:0:0: [sdd] Assuming drive cache: write through
[445347.090903] sd 12:0:0:0: [sdd] 7946240 512-byte hardware sectors: (4.06 GB/3.78 GiB)
[445347.091649] sd 12:0:0:0: [sdd] Write Protect is on
[445347.091656] sd 12:0:0:0: [sdd] Mode Sense: 0b 00 80 00
[445347.091661] sd 12:0:0:0: [sdd] Assuming drive cache: write through
[445347.091669]  sdd: sdd1
[445347.200837] sd 12:0:0:0: [sdd] Attached SCSI removable disk
[445347.201066] sd 12:0:0:0: Attached scsi generic sg3 type 0

Write Protection OFF

Code:

$ sudo mount /dev/sdd1 temp
<no output>

/dev/sdd1 on /media/disk-1 type vfat (rw,nosuid,nodev,uhelper=hal,shortname=mixed,uid=1000,utf8,umask=077,flush)


Bus 001 Device 010: ID 0b27:0165 Ritek Corp. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0b27 Ritek Corp.
  idProduct          0x0165 
  bcdDevice            1.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 3 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           39
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               98mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk (Zip)
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               8


$ dmesg | tail

[445812.757116] usb 1-3: new high speed USB device using ehci_hcd and address 13
[445812.890705] usb 1-3: configuration #1 chosen from 1 choice
[445812.891042] scsi13 : SCSI emulation for USB Mass Storage devices
[445812.891351] usb-storage: device found at 13
[445812.891356] usb-storage: waiting for device to settle before scanning
[445817.889043] usb-storage: device scan complete
[445817.889989] scsi 13:0:0:0: Direct-Access     RiDATA                    0.00 PQ: 0 ANSI: 2
[445817.893332] sd 13:0:0:0: [sdd] 7946240 512-byte hardware sectors: (4.06 GB/3.78 GiB)
[445817.915219] sd 13:0:0:0: [sdd] Write Protect is off
[445817.915228] sd 13:0:0:0: [sdd] Mode Sense: 00 00 00 00
[445817.915233] sd 13:0:0:0: [sdd] Assuming drive cache: write through
[445817.924567] sd 13:0:0:0: [sdd] 7946240 512-byte hardware sectors: (4.06 GB/3.78 GiB)
[445817.925423] sd 13:0:0:0: [sdd] Write Protect is off
[445817.925429] sd 13:0:0:0: [sdd] Mode Sense: 00 00 00 00
[445817.925435] sd 13:0:0:0: [sdd] Assuming drive cache: write through
[445817.925444]  sdd: sdd1
[445818.034645] sd 13:0:0:0: [sdd] Attached SCSI removable disk
[445818.034875] sd 13:0:0:0: Attached scsi generic sg3 type 0

[2112]

I tried to grab a ton of info from the USB key, with the write protect in both states.
  idVendor           0x0b27 Ritek Corp.
  idProduct          0x0165

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

[etotheipi]

I tried to grab a ton of info from the USB key, with the write protect in both states.
  idVendor           0x0b27 Ritek Corp.
  idProduct          0x0165

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

[2112]

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

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.

[chrisrico]

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!

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

[kjj]

I tried to grab a ton of info from the USB key, with the write protect in both states.
  idVendor           0x0b27 Ritek Corp.
  idProduct          0x0165

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

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.

[Jan]

...

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

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

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.

[etotheipi]

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://bitcointalk.org/index.php?topic=56424.msg1186265#msg1186265

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:

~/armory$ python extras/cli_sign_txdp.py
USAGE: extras/cli_sign_txdp.py <wallet file> <unsigned.tx file>

~/armory$ python extras/cli_sign_txdp.py   /home/user/.armory/armory_2DTq89wvw_.wallet   armory_test_cli_sign.unsigned.tx

PLEASE CLOSE ARMORY BEFORE CONTINUING!  (press enter to continue)
<enter>

********************************************************************************
PLEASE VERIFY THE TRANSACTION DETAILS BEFORE SIGNING
********************************************************************************
   INPUTS:  (10.01000000)
      1245Fve8ZgXY474JidB3jQQfGUKn6NhxUK          -->           5.01000000
      1245Fve8ZgXY474JidB3jQQfGUKn6NhxUK          -->           5.00000000
   OUTPUTS: (10.01000000)
      1Jkch9f4CR9ZaUk67sqBYoE52dSNG2CYi7          <--           4.00058564
      1338g4yeBt3AtevqsGjKKnHFuvp3UMubfX (change) <--           6.00941436
      Fee                                         <--           0.00000000

Does this look right?  [y/N]: y
Please enter your passphrase to unlock your wallet:
Wallet Passphrase: <NOECHO>
Correct Passphrase.  Unlocking wallet...

Signing was successful!  The signed transaction is located:
   armory_test_cli_sign.signed.tx

Would you like to delete the old unsigned transaction? [Y/n]: n

The *.signed.tx file can now be broadcast from any computer running
Armory in online mode.  Click "Offline Transactions" and "Broadcast".

[Jan]

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

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.

[etotheipi]

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.

...

Unless I have forgotten something crucial this should work.

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

[etotheipi]

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.