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

[kjj]

kjj,

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

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

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

For PC to PC communication, you use a null modem cable.  Over time, I think that the more common case will eventually be PC to device, which would use a standard straight serial cable.  More likely, the hardware wallet can emulate a serial port over bluetooth or USB.  The USB option would pose a risk to the computer, but in this model, it is the hardware wallet that needs to be protected, so we don't care.

The nice thing about USB to serial is that it usually presents at a high level so that you don't need to mess with the gory details of working with a 8250/16550 UART chip.  As long as the two ends agree on the speed and framing (19200, 8N1 is common), you can usually deal with it as just a character stream.

I don't know if USB to parallel adapters are really usable in bidirectional mode.  In theory, they should all support a clean 8 bit channel, and can even be chained to connect multiple devices, but in practice, parallel links tend to be hacked up 5 bit point to point systems using custom cables and abusing the printer status registers.

There are two ways to do offline wallets.  In one system, the offline wallet doesn't need any block data at all, and merely signs transactions presented to it.  In the other system, the wallet needs a tiny subset of the block chain, just the transactions it wants to redeem, but it creates the entire transaction internally and signs it.

I prefer the second system, so that the wallet can't be tricked into signing a transaction that it doesn't understand.  But it means that the wallet must accept block data that it cannot confirm.  This doesn't seem to be too big of a problem, since the transactions would be sent either by the point of sale terminal that wants to get paid, or from the user's semi-trusted home computer.  The worst that an attacker could do would be to trick the wallet into creating an invalid transaction.

As to the format of communication between the two devices, I prefer JSON because it is so simple.  ASCII armor is more suitable if you are passing files around and need them to be portable across a bunch of different systems.  But if you have a live communication link, it doesn't seem ideal.

[finway]

Offline wallet is useful.

[etotheipi]

There are two ways to do offline wallets.  In one system, the offline wallet doesn't need any block data at all, and merely signs transactions presented to it.  In the other system, the wallet needs a tiny subset of the block chain, just the transactions it wants to redeem, but it creates the entire transaction internally and signs it.

I prefer the second system, so that the wallet can't be tricked into signing a transaction that it doesn't understand.  But it means that the wallet must accept block data that it cannot confirm.  This doesn't seem to be too big of a problem, since the transactions would be sent either by the point of sale terminal that wants to get paid, or from the user's semi-trusted home computer.  The worst that an attacker could do would be to trick the wallet into creating an invalid transaction.

As to the format of communication between the two devices, I prefer JSON because it is so simple.  ASCII armor is more suitable if you are passing files around and need them to be portable across a bunch of different systems.  But if you have a live communication link, it doesn't seem ideal.

kjj,

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

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

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

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

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

[etotheipi]

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:

Code:

import serial
ser = serial.Serial('/dev/ttyUSB0')
ser.write('Hello Serial Port!\n')
ser.close()

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

[Herbert]

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

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

[etotheipi]

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

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!

[kjj]

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.

[etotheipi]

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.

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?

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

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!

[kjj]

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.

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?

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

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!

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.

[casascius]

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.

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?

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.

[runeks]

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.

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.

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!

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?

[etotheipi]

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!

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?

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

[Foxpup]

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

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

[runeks]

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

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

Code:

/sbin/agetty 115200 ttyS0 vt100

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.

[grau]

After all, it's a general computer and that's pretty expensive to have just sitting in a corner holding a wallet.

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

[etotheipi]

After all, it's a general computer and that's pretty expensive to have just sitting in a corner holding a wallet.

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

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?

[etotheipi]

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

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


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

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

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!

[justusranvier]

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

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

[etotheipi]

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:

Luckily for the security of Linux desktop users everywhere, there's no option to automatically run autorun scripts when a device is inserted – this ability is specifically prohibited by the Desktop Application Autostart Specification (84).

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!

[Slushpuppy]

 If you think Linux doesn't have these vulnerabilities, think again.  

that was a VERY good video holy shit!