| The cable is just what he had at his house: a smaller one is better. Not sure why you keep bringing up smartcards as alternative to long cable: two totally different things. Only realistic alternative to his cable w/out extra risk is point-to-point IR transfer: cheap & hard to grab if nearby (unlike Bluetooth/Wifi). It would be nice to get more people on GPG or Linux. It's what I use, too. The problem is their Trusted Computing Base [1] is ridiculously huge. Even amateurs regularly break NIX systems, browsers, and so on. The methods for designing things highly resistant to attack are out of reach for most projects. See my framework [2], for example, to see the gap between high quality coding and truly secure systems. Most developers, even many security "pro's," have no idea about so many of these things. Just ask anyone building one of these "NSA-proof" crypto tools to see their Covert Channel Analysis with breakdown of all residual storage, timing, and resource exhaustion channels. Observe the blank or confused stares. So, Markus was trying to shortcut around that using concepts he learned and we discussed. It had to be provably immune to software attack despite weaknesses in components. GPG on Linux/Android means GPG or Linux/Android must be breached. Although GPG is solid, Linux/Android breaches abound because they're insecure crap. So, that won't work against event a good black hat. He couldn't build a High Assurance Guard [3] by himself so he had to eliminate almost whole TCB. TFC was a clever workaround. TFC and Linux/Android-based clients have no comparison given only one can make a strong security argument under all conditions of software attack and the others just have so many real-world attacks... Apple to oranges, my friend. For cascading, it might be overkill and might not. Note that many real-world algorithms working in isolation had problems. Cryptophone used a AES + Twofish cascade as insurance. The idea is that one algorithm or trick failing won't compromise the system. It applies to regular crypto users as much as anyone else given we use same algorithms. I agree it might not be necessary for majority of people, though. They use Gmail or Facebook over HTTPS for their critical communications. Clearly different privacy needs, there. ;) I agree on the overlap: it's why I push the strong stuff. :) The reason, though, is that all the bad guys aim for the same thing. Plus, the nation-state methods (esp firmware attacks) are starting to be used by non-nation-states. The methods for stopping software attacks by nation-states are same as for anyone else. It's why our systems need to be redone (example [4]) to simply enforce fundamental protections to stop all that shit. And meanwhile, we have to use GPG, TFC, air gaps, and other kludgy solutions to make up for how bad we have it. [1] https://en.wikipedia.org/wiki/Trusted_computing_base [2] http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-m... [3] https://en.wikipedia.org/wiki/Guard_%28information_security%... [4] http://www.crash-safe.org/assets/ieee-hst-2013-paper.pdf |
True, a smart card doesn't give you separate input/output terminals. But it can isolate the key and encryption bit. It can be quite secure in case of theft, off-line access.
[ed: I wasn't talking about just the cable, I was thinking about all the devices soldered into it. They look big enough for there to be a possibility to embed a listening device. That is if you're a direct target by something like the Egyptian Secret Police etc]
Certainly this system has different and stronger security properties -- but also usability issues (even if you could probably sandwich most of it into a single laptop case. Would be interesting to have two screens side-by-side for input and output).
Do you know anything about throughput for this? Would it be viable for high-quality video chat?
> TFC and Linux/Android-based clients have no comparison given only one can make a strong security argument under all conditions of software attack and the others just have so many real-world attacks... Apple to oranges, my friend.
I meant and Android hw device, similar to running a stripped down OS on pc hardware. Sort of as a replacement for the hw in the terminals used here. I didn't mean a full Android software stack. Preferably a system without baseband, networking etc.
I'm not sure about your use of "NIX" here. Is this a combined hardware/software platform? Google wasn't very helpful.
It is of course true that if you can compromise the keyboard, display driver, kernel, i/o for gpg etc -- you can actively compromise the system.
As far as I know, typical Linux/bsd installs are not vulnerable to compromise either via a usb stick or via tcp/ip (assuming updates are disabled). So it would seem that using a dedicated (mostly) air-gapped laptop would practically be as secure. In such a case, keeping keys/crypto on an open-hw smartcard might be a prudent extra step that would add a little more security against certain threats.
> For cascading, it might be overkill and might not.
As long as one can show that cascading doesn't weaken the system (eg: perhaps a construction opened up some kind of oracle, along the lines of compression+encryption, perhaps key derivation would leak information on a master secret if one uses related keys) -- I don't see much of a reason not to.
On the other hand, if you double the number of crypto systems in use, you double the number of bugs. Of course, it might be that the attacker can't attack bugs in the inner systems easily, so perhaps by layering you get to choose which system are most easily exploited...
Either way, I think both an air-gapped computer+smartcard and this system would be secure enough, that if you are a target, someone might want to try and sell you special, compromised hardware. It might not compromise the system as such, but even just a microphone+transmitter in any one of the components might be enough to pick up sounds of typing, and be able to infer plaintext. Not sure what the easiest way to read the screen would be, but probably some kind of signal leakage from the gpu/cable/screen.