Quote from: Falkvinge on February 22, 2014, 12:58:59 PM

Quote from: etotheipi on February 21, 2014, 05:14:32 PM

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.

Quote

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.

Quote

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.

Quote

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.