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

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.

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.

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

that was a VERY good video holy shit!

Along the lines of improving USB-based Armory, I stumbled on an article that had good advice for disabling autorun stuff in Linux.  This is something worth doing if you are using Ubuntu/Gnome on your offline machine.  In fact it is quite simple, and provides a lot of extra security for very little effort.

Open a terminal and type "gconf-editor".  You'll end up with something that looks like the Windows registry. Navigate through the tree:  apps->nautilus->preferences.  There are 2 media-related keys that should be modified:

   media_automount_open  (OFF)
   media_autorun_never (ON)

The automount_open basically determines whether nautilus will open a file browser when the USB key is inserted.  This was the source of a small vulnerability at one point, and it's been patched, but for offline wallets you don't need it anyway.  

autorun_never should be self-explanatory:  there's a whole host of things that the system will try to do as a convenience to the user, when you insert media with images, videos, audio, etc.  There's no need for any of it, though, unless you want the convenience of being able to pop a DVD into your offline computer and watch it "offline"  However, it sounds like nothing really auto-runs anyway quoting the article:


You could also disable automount, but that is actually quite useful, and you have to mount the drive anyway when you insert the USB key.  There might be an advantage to doing it manually, I don't know.  Since I don't know if it's actually useful, I won't go through the process of explaining it, because it can be complicated depending on the USB filesystem and device ordering (in other words, I wouldn't do it unless you already know all the command line calls for it).


For windows, there is Panda USB Vaccine.  You can use it to hard-disable the autorun.inf file, such that a program needs to reformat the drive to put anything useful in there.  It also applies a set of removable-media settings on your Windows computer, to disable mostly-unnecessary operations when a key is inserted.

Any other recommendations are welcome!

That sounds suspiciously like, "what could possibly go wrong?"

You know what?!  I think this idea is perfect, after all.  Given all the problems with so many of the other techniques described... I will accept a speed bottleneck if it comes with all the other security and convenience features desired.  A user that really wants security and convenience can wait for it!

Most transactions will only be a couple-hundred bytes.  Some of them are bigger.  If you get 100 bytes per second that's a few seconds for most transactions.  1-2 minutes for somewhat larger transactions.  And the most extreme case?  Well they can wait 10 minutes.  Oh well, they wanted security and convenience, go respond to some emails and come back.


So a couple other comments about this:

• The speed issue is only in one direction -- for sending data back to the online computer, only signature data has to be sent.  Even with 20 inputs being signed, the signatures are only about 70 bytes, so 1.5 kB, so 15 seconds.
  
• I bet you could use a double-ended headphone cable to connect the output of one system to the microphone of the other.  In this case, I bet your baud rate could go way up.  Though, the convenience factor is reduced if the user wants to use their speakers for other things...
• I have a signal processing background... I would have a lot of fun with this
• All the problems with other techniques generally have to do with the ubiquity of using those communication channels for stuff.  There's already subsystems of code and drivers for auto-operating on signals over ethernet, USB, IR, bluetooth.  This is not true for audio -- I plug in a mic, worst case a program on that computer records it, but it's not executing any code with that as input.  I mean, it's an analog signal, how could it? (unless it was specifically designed to know what it was looking for, like Armory will have when I'm done)

This isn't in my immediate future, but I think I want to put it on my list of "awesome things to do" after Armory beta.  I think this could work... tell me I'm wrong!

I'm not too familiar with how VMs work, but I was under the impression that the host OS can access the VM memory space pretty easily.  That means it could just reach in and grab the key when its unencrypted.

However, there are some lower-level virtualization configurations that might offer a lot of security.  Someone contacted me to suggest Qubes OS which relies on Xen Hypervisor.  My naive understanding of it is that all the OS's are "guests" of the Xen Hypervisor, which keeps them completely sandboxed and unaware of each other.  So you have network on one, offline Armory on the other.  This would definitely be better than a VirtualBox/VMWare guest, but I can't really endorse it since I've only scratched the surface reading about it.

Who knows, maybe it would be better than a separate computer and USB key.  However, you might need a separate computer to use it, since most users probably wouldn't want to switch their host OS to this obscure distribution (even if it virtualizes Windows well, most users wouldn't want to deal with this obscure OS).  Anyone know about this?

What is you opinion on using a virtual machine, booted from an encrypted image that offers the single service that signs transactions?

Ouch. That's a serious issue, yes. And even if we disable it we can't really be 100% sure that it stays disabled, or if some process/kernel module enables it again because some developer thought "hey, it's a serial connection, no one uses that anyway". As far as I can see, it's a simple question of running
as root. So although it would require root, it would still make it unsafe, it seems.

Damn it. I just thought I had found something useful to use my Pi for. Plus, secure hardware wallets are really cool. I guess it's back to the drawing board.

I also thought of using the USB connection on the Pi. As far as I know, login is not possible via this route. But the Pi can't act as a USB client without some hacking, and I'd like it to be a fairly easy setup for the general population who would like to feel completely secure about their coins.

The Pi also has an Ethernet port, but that makes me even more nervous that the serial port.

I find it quite ironic that we have developed advanced cryptography and a digital currency built on top of this, but yet have no way to safely and easily transfer simple data from one device to another.

Yes. In Linux. Windows versions later than XP do not support serial ports.

I had spent a little bit of extra time looking at it, but not a lot.  I had been meaning to reply to this thread, with some updates on my philosophy on this topic:

(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'd rather use USB keys than risk impatient people just hooking up the cable and carrying forward because they don't realize that issue.

As such, I had started to think that maybe the serial cables wasn't the best idea, except as a "niche" technique for the ultra-motivated.  I imagine there are plenty of people capable of doing the serial cable version, but many of them may not want to even see the cable connecting the two computers where bits could theoretically be flowing.

However, I have not thought about any particular way I'd like to resolve this.  I think the ultimate solution is what you alluded to:  a handheld device with a small screen and a few buttons.  Outside a dedicated chip, the wallet itself would be write-only, and and the chip would simply be a blackbox with transaction data going in one side, and signatures coming out the other.  However, I'm not a hardware guy, so I wouldn't know the first thing about how to pursue this idea.  And I have ideas... I just can't make them realizable.

The end of this story is this:  I'm all for developing a serial-cable solution.  But I'm also dedicated to developing Armory for the general user, and I'm not sure serial cables are fitting in this case.  So I will be happy to contribute and even compile official instructions for how to do serial cables (and maybe put in a small interface for pulling tx data from a serial port), but I can't make it my personal priority right now.

Absent a dedicated device/dongle, I am still interested in other ways that might work.  The webcam+QR idea is in the right direction, but there's a variety of reasons why it's not good for the general user (I've mentioned it before).

Can any of the serial port experts in this thread tell me if the following cable will do the same as the above-mentioned combination of cables?

http://www.digikey.co.uk/product-detail/en/USB%20NMC-2.5M/768-1076-ND/2441364

As far as I can see, it's basically two USB-to-serial adapters with a null modem in between. All in a single USB-A to USB-A cable, so it should work as the three parts described above. I just want to be sure before I order it.

I have a spare Raspbery Pi lying around, because it didn't work so well for the purpose I originally intended it for (encrypted NFS). I'm thinking of turning this into the ultimate, unhackable offline hardware wallet using Armory's offline wallet system.

As far as I can see, the only vulnerability is the software running on the Raspberry Pi. If the OS (including the serial port and USB driver implementation) and Armory on the Pi are uninfected, there's no way to steal the private keys.

A brand spanking new Raspberry Pi can be had for just £25, making it a small investment to gain a completely safe offline wallet, if you ask me.

It would be necessary to have a keyboard, mouse and monitor connected to the Pi as well though, unless one wants to develop a completely custom solution, with a touch screen LCD on the Pi, with which you can check the destination address and amount of the transaction you're signing.

Have you spent a weekend looking at this yet? It would be cool if Armory already had it all built in. I had planned on making a custom solution, but it wouldn't get any easier if Armory already has what it takes.
Are you thinking of building the serial port communication directly into Armory, or what?

The implementation of XON and XOFF is directly in the kernel.  You should not use XON and XOFF or any kind of flow control - you should completely disable it so the kernel doesn't try to do you any favors if a 0x13 is received over a connection.  It makes no sense in this context.

Where it WOULD make sense is when you have a 56k modem that supports on-the-fly data compression to get a throughput beyond 56k for highly compressible data (such as text).  An application sends data to the modem well beyond the actual 56k connection speed (e.g. 115200bps) and the modem uses flow control (usually hardware, RTS/CTS pins) to ask the computer to pause for short periods of time so its input buffer doesn't overflow, forcing the net throughput over the serial port to match the throughput across the phone line.

There is no equivalent need in a terminal-to-terminal application when both sides have gigahertz-class processors.


All major OS's will handle the buffering for you to a minimum of one 4096-byte page, and very possibly much larger.  It functions much like a pipe in the OS.  You do not need to worry about the 16-byte UART hardware buffer in a user-mode application under an OS as the device driver handles this, you'll never see this limit.

The easiest way to not have to worry about the buffer size is to make sure all messages (i.e. the maximum amount of traffic you expect to receive between calls to read serial) are well smaller than 4096 bytes.  Design the protocol so the client sends you a line of text at a time and you acknowledge it before the client is allowed to continue.  Then each exchange will be too small to overflow any buffer.

When you deal with message sizes that may overflow the buffer, that's what flow control is for.  The OS will send XOFF to the client or drop RTS on your behalf if you have flow control enabled.  But you really don't want to enable that, because then by requiring the client to honor flow control you've just vastly increased the complexity for anyone implementing your interface.  Best keep it simple, at the cost of a small amount of (likely imperceptible) round-trip latency.

For XON and XOFF, you'd be better off using 0x11 and 0x13.  ASCII doesn't actually define flow control codes, which is odd considering how complete it is in other areas, but ASCII does define four "Device Control" codes, and people usually use DC1 for XON and DC3 for XOFF.  Pretty much every UNIX terminal responds to them too, which is how you can stop scrolling with CTRL-S and resume with CTRL-Q.

There are other named control codes in ASCII that may or may not be useful to you.  There is an enquiry code, an acknowledge code, a negative acknowledge code, an idle code, a whole set of separator codes (unit, record, group, file) and codes to indicate the start of a header, the start of the text, the end of the text, and the end of transmission.  A bunch of them have special meaning in UNIX too, like EOT (end of transmission) is CTRL-D, which hangs up your terminal and logs off, ETX (end of text) is CTRL-C which breaks, and SUB (substitute) is CTRL-Z which substitutes a new prompt for the running job.

Way back in the bad old days, the 8250 UART chip itself had only a pair of 8 bit buffers.  To send, you'd write your byte to the Transmit Holding Register and then set a bit in the control register, then the UART Would take over, generating the start signal, shifting each bit to the line, calculating the parity internally and signaling it (if set), and writing the stop signal (if set).  When receiving, it would do the reverse, listen for the start signal, shift each bit in, check parity (if set) and check for the stop signal (if set), and copy the shift register to the Receiver Buffer Register, then set a bit in the control register, and if you were really, really lucky, trigger an interrupt so that you didn't have to poll the damn thing all the time.

If a second byte came in before you had read the first one, one of them was just lost.  I think it was the newer byte, but I don't remember.  It's been a while.  Sending had similar issues, but wasn't quite as bad, because the chip would copy the THR into the shift register, so you only had to wait for as long as that took before writing the next byte, instead of having to wait for up to 10 baud periods for it to shift out to the line driver.

Over time, better chips like the 16450 and 16550 came out which had FIFO buffers, so that they could store up like 16 or 64 bytes at a time.  These were buggy as shit too, if I recall, but still a huge improvement.

In a modern system, you should be able to ignore all of that.  You should be able to call the read function in any given high level language and have it either return data, return null, or block until something comes along.  The OS should handle the hardware and buffering properly so that your read calls return everything since either the last read or since the open call.  Any computer should be fast enough not to have to worry about anything like that.

For the relatively small messages that will be involved here, you shouldn't need to worry about the buffers growing unreasonably.  It shouldn't take more than a few seconds to send a transaction request.  At 9600 baud 8N1, which is really slow, you can get out nearly a kilobyte every second.

What you will have to do is respect flow control signals coming in from other devices.  Your first implementation will probably be between two modern boxes running Armory, both of which should be able to handle maximum speed serial lines without any problems.  Looks like newer USB serial adapters can go up to 921,600 bits per second, which is probably faster than the the connectors on the null modem can physically handle without the signal turning to mush, but is still pathetically slow by computer I/O standards.  But, at some point, someone is going to build a little Arduino or other embedded system that they will want to use as a secure offline physical wallet.  Depending on the hardware they use it could even be a bit banging interface where the CPU literally spins in a loop raising and lowering an I/O line at the right times to generate the signals.  If one of those sends 00010101, it might really mean it.

It sounds like the pure-ASCII-ness of the tx proposals (TxDPs) will benefit me here, compared to coming up with a binary encoding scheme.  It will add a little more bloat, but guarantees I won't be sending any bytes that might trigger special character/command bytes by accident.  When you speak of XON and XOFF, I assume you are talking about "defining" such bytes, myself.  I will pick the XON, XOFF, TX_SEPARATOR, etc:  I will be defining this stupidly-simple protocol myself using only bytes across pins 2 and 3. ...?

How do the buffers work exactly?  If I do not execute a serialPort.read() or readline() in python, is the buffer accumulating the data being sent from the other system?  Does it only accumulate when I create the serial port object?  Perhaps I can clear the buffer the moment the user presses the Receive-Tx-Over-Serial button on the Sign-Transasction dialog.  Is there a "danger" in the buffer getting too big?


I'll stay away.  I don't mind doing a little extra work myself to add simplicity to device pairs with different OSes. 

Thanks for the reply.  It has been extremely useful!

Ok, now this is where things get strange.

A working serial connection needs only three pins, TxD, RxD, and SG (ground).  If you want maximum compatibility, only use those.  If you need flow control, send XOFF to tell the other side to stop sending, and XON to tell the other side that it can send again.  If you use this system, you'll need to ensure that you don't send those bytes under other circumstances.  The encoding you use for transaction proposals should be fine, and if not, there are plenty of other coding schemes available that work fine for serial or other pipes with in-band control.

There are also several hardware flow control lines, RTS, CTS, DSR, DTR and CD.  Using them is better in some ways, but opens you up to strange cabling problems.  Historically, it has been hard to get everything to line up right, because both sides and the cable all need to follow the same scheme, and serial ports aren't nearly as standardized as one might think.  If you don't mind restricting yourself to only particular serial adapters/cables/devices, go for it.  Just keep in mind that they were designed for communication between a terminal and a modem

1) In Linux, look in /sys/class/tty/ .  They should show up as ttyS* and/or ttyUSB*

2) Lots of ways to do this.  You could just blindly dump the request out and see if you get a reply.  Or you could have each device listen all the time and send a SYN? poll every few seconds/minutes.  Or you could do something in between, and only attempt the handshake when you actually need to send.

3) Communication is totally bidirectional and non-interfering.  Both sides can talk at any time, but buffer space may be limited.  You should expect the need to support some sort of flow control, either XON/XOFF or RTS/CTS.

4) Yeah, pretty much.  The ASCII control characters are surprisingly useful for these things.

5) There probably isn't any point in having the node confirm before broadcasting, under most circumstances.  The wallet should be assuming that the serial device attached to it is hostile, so anything it sends should be safe to broadcast instantly.

6) I'm not sure if there is any signalling of ports in use, other than the open call failing.

Yup, just got a Null-modem connector and it works like a charm.  I can't believe how ridiculously easy it is to use serial ports!  (at least, in Linux).   

For reference: I have combined two USB-serial cables and one null modem (F/F) adapter.  The total cost is about $40 after shipping.  Not too bad if you're protecting thousands of dollars.

With everything hooked up, the cable stretches about 4 ft, which is enough if you keep your laptop anywhere near your regular system.  You can get longer USB serial cables if necessary.

So now I want to start thinking about an actual interface to use them... I need to solve a few problems.  And I'm happy to do it purely in Linux for now, and figure out how to port it to Windows later.

• (1) Detect presence of serial port (looks like this is a good way to do it in Windows, and perhaps I can just search /dev/ on linux...?)
• (2) Detect presence of other device on serial port.  I think there's pins for this, but I don't know if it can detect just by being connected, or if one has to do something to make itself detectable
• (3) Can devices both read and write at the same time?  Can I have both devices always "reading" and pop up a message asking to accept incoming data?  Then one device can start transmitting when it's ready, the other will detect and ask for confirmation?  Or do I have to explicity put each device into receiving mode and not send while it is receiving?
• (4) Seems like the serial link will be very reliable.  I can probably have the sending node just keep transmitting the data over and over with a sha256 checksum at the end for integrity checking.  That way the receiving device only looks for the "beginning of tx" and "end of tx" markers, checks whether the data in between matches the checksum, and if not, just grab the next batch of bytes in the buffer and try again.
• (5) The online computer only needs to check for incoming data to know when to stop sending data.  Receiving data implies that the user has reviewed the unsigned transaction and signed it, and is sending it back.  Auto-receive from offline system and pop up "Confirm broadcast"? 
• (6) How do I check for other programs that may be running on the serial port?  I mean, there shouldn't be... but it would be silly not to verify.  Is there a way to query a device for processes "attached" to it? 

Btw, for those following Armory:  I won't be implementing this for a while, but it looks like it would be fairly easy to do once I have a plan, so I'm hoping to get input now to fill in the gaps in my own knowledge.  After RAM-reduction, compressed public keys, and address books, I might spend a weekend on this.  Given the simplicity of the interface, it might be doable in a day!

Yep, you need http://en.wikipedia.org/wiki/Null_modem for a direct PC-to-PC connection.

So I actually got two USB-serial-port-emulators and a F-F adapter.   It was surprisingly simple to get setup in Linux (I haven't tried Windows yet).  I simply plugged it in, and checked dmesg to see that it was creating the /dev/ttyUSB0 device.  After that, I used a spare computer screw to short pins 2 and 3 and used gtkterm to receive/display data.  Looked up how to access serial in python -- ridiculously easy, as expected:


And the text showed up on the gtkterm session.  Great!   But I couldn't get any further.  I installed gtkterm on a different Ubuntu system, connected both serial cables together using the F-F adapter, loaded the same programs, and tried to read/write between them:  no luck.  I tried disconnecting and shorting 2&3 again on the other computer to make sure it worked -- it successfully receives messages sent to itself.  But when connected via the F-F adapter to the other system, none of the messages make it across.  Perhaps the F-F adapter doesn't "crossover" the pins as I would hope?  I'm not phsyically savvy enough to hack a crossover connection between the two cables to test it.  Or I just don't have the right stuff...  

On a separate note, is there a way to guarantee that nothing else is listening on the serial port?  For instance, a coworker mentioned to me that really old Linux systems automatically enable console logins over serial ports!!  He said the same thing would happen with IR, too.  But that it's easy to disable, and any modern linux distro wouldn't have that to begin with.  Of course it concerns me, but I'm confident that there are some simple precautions that could be taken that would 100% guarantee there are no more programs acting on serial data.

EDIT: I just noticed on the product description page that the F-F adapter says:  "Pins:  straight through".  I guess that answers the question...