Feature request: QR code comms for signing

[Falkvinge]

As seen in the howto I posted a few weeks ago, Armory is now my primary wallet for security reasons, as I've chosen to not trust third-party services any longer *cough* Gox *cough*. I believe my fellow Armorists share the concern of coin security, and have chosen Armory for that primary reason.

Once you have your private keys in a manner that they will never ever touch a computer that has been, is, or will be connected to the internet, you need to examine the communications paths with this offline computer from a defense-in-depth perspective.

The weak link today is in how the unsigned transactions go to the offline computer, get signed there, and are moved back to the online computer. Email or clipboard is obviously out of the question, as that would require connecting the cold storage to a network. So realistically, that means a file is stored on some medium, that medium is physically moved to the offline computer and connected there, the transaction is signed, and the medium is moved back. The only medium that is used this way today is a USB stick.

Here's the vulnerable point. USB sticks contain firmware that can be exploited and malware embedded. That, in turn, can be used as an attack vector against a target system's USB drivers. Assuming we trust Armory, which we kind of have to, we want to be sure that no communication can get piggybacked by covert malware onto Armory's communication between its online and offline counterparts.

As long as we're doing that communication on multi-gigabyte USB sticks, the potential for a covert side channel is enormous.

Therefore, seeing how security has been the foundation and priority in building Armory, I'd like to see the ability for the online and offline computers to communicate signed/unsigned transactions optically using QR codes, instead. Have the online computer display the unsigned transaction on-screen with a QR code, have the offline computer use its webcam to read it, and vice versa for the return comms.

That way, we can be much more certain that no covert side channel is being used to extract information from the offline computer. We still must trust Armory, but this was about eliminating the possibility of piggybacking covertly on the transfer of Armory's data, which can be achieved if Armory communicates optically instead of via files.

Comments?

Cheers,
Rick

[drrussellshane]

I believe the reason than Alan has not yet implemented this is because some transactions are too big to fit in a QR code.

Otherwise, yeah, it would be pretty handy.

[Falkvinge]

I believe the reason than Alan has not yet implemented this is because some transactions are too big to fit in a QR code.

Otherwise, yeah, it would be pretty handy.

The advantage of synchronous optical communications with sender and receiver in one place, as opposed to asynchronous messaging across time or location, is that you can display a visual stream of QR codes. Therefore, there's really no limit to the amount of data transferrable.

Cheers,
Rick

[etotheipi]

Personally, I think QR code video is a great solution.  But that's significantly more challenging than simple QR codes.  And so far, Armory doesn't have a utility for scanning even regular QR codes.  It will have to be a robust solution, because there might be megabytes of data to transfer (could be fixed if we had something like SIGHASH_WITHINPUTVALUE). 

Also, I was hesitant to implement something that requires the user to have multiple webcams, and have their webcam drivers setup, and then try to figure out what to point where and when, and have wires everywhere.  It's doable, but it's also not necessarily user-friendly.

That doesn't mean we shouldnt' do it, it's just that it's not a perfect solution for a general purpose tool.  I'd rather people use USB, than get fed up with something complicated they can't get working and forego offline wallets entirely.

However, we have more resources on our team now... we may be able to prioritize it.  Right now we have an audio cable solution in the works, which also utilizes an analog channel which should be pretty darned secure.  But it's not ready yet.

[bitpop]

Someone made a custom android app as a proof of concept

[Falkvinge]

Personally, I think QR code video is a great solution.  But that's significantly more challenging than simple QR codes.  And so far, Armory doesn't have a utility for scanning even regular QR codes.  It will have to be a robust solution, because there might be megabytes of data to transfer (could be fixed if we had something like SIGHASH_WITHINPUTVALUE).

Hmm, good point. However, in the general case, a display cycling some 1-8 QR codes must surely be sufficient? I just aimed my phone camera at this QR code on Wikipedia, with some 1800 bytes, and it nailed it without blinking. I can't tell how many percent of transactions would be smaller than 6-7 kilobytes, but I imagine it would be the overwhelming majority.

So while there may be cases where this mode of communication is not available, is that a reason to exclude it from the 95%-98% of typical cases?

Also, I was hesitant to implement something that requires the user to have multiple webcams, and have their webcam drivers setup, and then try to figure out what to point where and when, and have wires everywhere.  It's doable, but it's also not necessarily user-friendly.

Is that really the case? The communication would be one-way, there's no need for ACKs as the receiving computer can read the sending screen until all codes have been read. No need for a two-way protocol. There's an operator there, after all, who is alerted to when the data transfer is complete in some way.

That doesn't mean we shouldnt' do it, it's just that it's not a perfect solution for a general purpose tool.  I'd rather people use USB, than get fed up with something complicated they can't get working and forego offline wallets entirely.

I totally agree that usability is key, and that secure usability is one of the bitcoin ecosystem's big problems right now - I'd even call it a showstopper until that problem is solved. However, Armory is already halfway to the point of solving this specific problem with its configurable user levels of advancedness.

However, we have more resources on our team now... we may be able to prioritize it.  Right now we have an audio cable solution in the works, which also utilizes an analog channel which should be pretty darned secure.  But it's not ready yet.

An audio channel is a clear improvement over a USB key, but still hijackable as a side channel in the dire case malware has found its way onto the computers: all operating systems I know of allow for multiplexing several simultaneous applications to/from audio. However, in the same vein, webcam access and screen real estate is exclusive to one application, giving an advantage to the operator knowing that Armory has exclusive control of the communications channel?

Oh, and also, I almost forgot: Thank you for this great piece of software.

Cheers,
Rick

[etotheipi]

Hmm, good point. However, in the general case, a display cycling some 1-8 QR codes must surely be sufficient? I just aimed my phone camera at this QR code on Wikipedia, with some 1800 bytes, and it nailed it without blinking. I can't tell how many percent of transactions would be smaller than 6-7 kilobytes, but I imagine it would be the overwhelming majority.

So while there may be cases where this mode of communication is not available, is that a reason to exclude it from the 95%-98% of typical cases?

The problem is, when the time that you fall outside that 95%, you have to resort to another solution (such as USBs), which compromises the whole thing.   We really need 100% in order to be useful.

Is that really the case? The communication would be one-way, there's no need for ACKs as the receiving computer can read the sending screen until all codes have been read. No need for a two-way protocol. There's an operator there, after all, who is alerted to when the data transfer is complete in some way.

It's bi-directional.  We need to transfer transaction data to the online computer, sign, then transfer the signatures off (though right now Armory expects the whole tx to be transferred off, but it wouldn't be difficult to change that).  Nonetheless, if you have a lot of inputs on the signed transaction, transferring 20+ signatures will require multiple QR codes.  We really need bi-directional video.  And if it's two computers with two webcams, it can get confusing quickly, and lots of messy wires.  Again, it's not that it's not doable, it's that it's not a clean solution. 

On the other hand, having two laptops facing each other might actually work, since the cameras are built-in.

However, we have more resources on our team now... we may be able to prioritize it.  Right now we have an audio cable solution in the works, which also utilizes an analog channel which should be pretty darned secure.  But it's not ready yet.

An audio channel is a clear improvement over a USB key, but still hijackable as a side channel in the dire case malware has found its way onto the computers: all operating systems I know of allow for multiplexing several simultaneous applications to/from audio. However, in the same vein, webcam access and screen real estate is exclusive to one application, giving an advantage to the operator knowing that Armory has exclusive control of the communications channel?

I would argue that audio is not really hijackable -- there is basically zilch remote-code execution potential, assuming the offline computer is not compromised.  We have to make that assumption because all bets are off, otherwise.  There's a countless number of ways to get the keys off the offline computer if you assume arbitrary code execution there.

On the other hand, assuming that only the online computer is compromised, there is nothing you can send over an audio channel that would induce code execution -- except for what Armory implements (or if you have some kind of voice recognition software running...?!).  Armory can make that band very narrow, and it will require direct audio cable connection, not just being in the same room.  We think it's an awesome solution, and will work well with mobile phones as well...

But it might be a while before we get that implemented.  We'll see how our priorities look after 0.91-beta is released.

[Falkvinge]

The problem is, when the time that you fall outside that 95%, you have to resort to another solution (such as USBs), which compromises the whole thing.   We really need 100% in order to be useful.

Good point, conceded. It's the one weak link in the chain that you want to eliminate, and on second thought, this is sound security practice.

It's bi-directional.  We need to transfer transaction data to the online computer, sign, then transfer the signatures off

Again, conceded. I pictured two one-way sessions, where an operator would have to change directions (pretty much like the USB key communications today), but the ability to communicate optically in the first place enables one single session which starts with the transfer of the unsigned transaction and ends with the broadcast of the signed transaction. For extra sci-fi points, there could be audible notifications in a synthetic voice as to what stage the session is in.

On the other hand, having two laptops facing each other might actually work, since the cameras are built-in.

Good thinking! I did a short test here, and a laptop plus a desktop computer is also feasible, as long as you have a webcam on top of the desktop computer monitor. You'll have to hold the laptop in place, but still.

I would argue that audio is not really hijackable -- there is basically zilch remote-code execution potential, assuming the offline computer is not compromised.  We have to make that assumption because all bets are off, otherwise.  There's a countless number of ways to get the keys off the offline computer if you assume arbitrary code execution there.

I'm going to be a total pain in the ass and disagree with that assumption. I know from myself that I really hate it when people do this, but hear me out and evaluate the thinking here:

Experience with security practices dictate the assumption that your code is the only piece that hasn't been compromised - that yours is the "last piece of code standing". If the Armory binaries have been corrupted through real-time code modification, then the game is over, but there are many cases where malware could have gotten into the offline computer without the ability to affect Armory.

So if Armory is compromised, the game is over. But I would take the position that the offline computer can be compromised in userspace without Armory getting compromised, and even if malware is running all over userspace, Armory could still be very able to perform its task securely. (Of course, if malware makes it to root or kernelspace, the game is over, but that's because of its ability to subvert the Armory I/O or binaries in that case.)

Also, remote code execution isn't the only vulnerability to watch out for. The offline computer can have had malware planted on it through a number of bad means - everything from USB-level exploits through an adversary physically gaining access to the machine and maybe installing a keylogger, sniffers, etc., maybe even in hardware. It's not just remote execution you want to prevent - you want to prevent any ability for the offline computer to communicate anything but signed transactions to the outside world. Having a keylogger or other sniffer is bad, but it may not mean any damage in practice, if and only if those pieces of malware are unable to report their findings to the outside world.

So I'm equally concerned about the elimination of known potential back channels from possible malware on the offline machine. If an Armory user isn't familiar with sound security practices, it could even be code running in a different, deliberately installed user account that is the adversary.

Again, thank you for a great piece of software, and thank you for considering the idea of optical communications. I appreciate that you're already considering sonic communications as a way to mitigate the original problem.

Cheers,
Rick

[bitpop]

Are there any ways armory can protect it self? Maybe using cpu technologies like data execution protection, virtualization, etc?
Maybe it can execute itself into a protected virtual machine. Take over the keyboard too to combat key loggers.
Maybe a protected state that basically takes over until it is shut down.

[goatpig]

The problem is, when the time that you fall outside that 95%, you have to resort to another solution (such as USBs), which compromises the whole thing.   We really need 100% in order to be useful.

Good point, conceded. It's the one weak link in the chain that you want to eliminate, and on second thought, this is sound security practice.

It's bi-directional.  We need to transfer transaction data to the online computer, sign, then transfer the signatures off

Again, conceded. I pictured two one-way sessions, where an operator would have to change directions (pretty much like the USB key communications today), but the ability to communicate optically in the first place enables one single session which starts with the transfer of the unsigned transaction and ends with the broadcast of the signed transaction. For extra sci-fi points, there could be audible notifications in a synthetic voice as to what stage the session is in.

On the other hand, having two laptops facing each other might actually work, since the cameras are built-in.

Good thinking! I did a short test here, and a laptop plus a desktop computer is also feasible, as long as you have a webcam on top of the desktop computer monitor. You'll have to hold the laptop in place, but still.

I would argue that audio is not really hijackable -- there is basically zilch remote-code execution potential, assuming the offline computer is not compromised.  We have to make that assumption because all bets are off, otherwise.  There's a countless number of ways to get the keys off the offline computer if you assume arbitrary code execution there.

I'm going to be a total pain in the ass and disagree with that assumption. I know from myself that I really hate it when people do this, but hear me out and evaluate the thinking here:

Experience with security practices dictate the assumption that your code is the only piece that hasn't been compromised - that yours is the "last piece of code standing". If the Armory binaries have been corrupted through real-time code modification, then the game is over, but there are many cases where malware could have gotten into the offline computer without the ability to affect Armory.

So if Armory is compromised, the game is over. But I would take the position that the offline computer can be compromised in userspace without Armory getting compromised, and even if malware is running all over userspace, Armory could still be very able to perform its task securely. (Of course, if malware makes it to root or kernelspace, the game is over, but that's because of its ability to subvert the Armory I/O or binaries in that case.)

Also, remote code execution isn't the only vulnerability to watch out for. The offline computer can have had malware planted on it through a number of bad means - everything from USB-level exploits through an adversary physically gaining access to the machine and maybe installing a keylogger, sniffers, etc., maybe even in hardware. It's not just remote execution you want to prevent - you want to prevent any ability for the offline computer to communicate anything but signed transactions to the outside world. Having a keylogger or other sniffer is bad, but it may not mean any damage in practice, if and only if those pieces of malware are unable to report their findings to the outside world.

So I'm equally concerned about the elimination of known potential back channels from possible malware on the offline machine. If an Armory user isn't familiar with sound security practices, it could even be code running in a different, deliberately installed user account that is the adversary.

Again, thank you for a great piece of software, and thank you for considering the idea of optical communications. I appreciate that you're already considering sonic communications as a way to mitigate the original problem.

Cheers,
Rick

My understanding is that we want to eventually offer both video and audio data channels. The question is priority and resources. So as it comes, audio will be first, then we'll have someone looking into animated QR codes.

As for the adversary scenario: a lot of Armory's code is in Python. It would be trivial for an adversary to compromise it. And to respond to bitpop as well, warding against this kinda of vectors is not only very difficult, it's out of Armory's scope. Armory functions on the assumption your offline signer is clean.

For protection against an adversary, my recommendation is to use 2-of-2 or 2-of-3 signing schemes involving a hardware wallet. This provides multiple factors, different platforms and protected data execution in case of the HW wallet. Hopefully, we plan on moving towards that direction too.