On 28.11.2015 17:36, Peter Lebbing wrote: > On 27/11/15 22:55, Andrey Utkin wrote: >> Any comments? > > Could you outline a sequence of steps that goes wrong without your > solution and right with it? > > Like: > > - SSH to compromised PC > - Use SSH agent forwarding > - While logged in to compromised PC, SSH from there to another > > Wrong: > - Compromised PC opens whole host of SSH connections purporting to be you > > Right: > - Keychain confirmation server comes in guns blazing, data center > containing compromised server turns into mushroom cloud > - Mushroom clouds don't impersonate sysadmins > > I'd like to see a detailed usage scenario. Preferably with mushroom clouds. > > Peter. >
Thanks for your interest. Your joke describes one of usage scenarios quite well :) Let me describe how exactly this is supposed to work when key must be used. The whole process still looks similar to smartcard key usage, especially regarding user's action to enable key access operation (PIN entry). So it is easier to start with looking at using smartcard. Note: I have no practical experience with actual OpenPGP smartcards and I'm not convinced with their usability enough to spend couple of hundreds of bucks or more (with shipping cost) to try them. As far as I see there is a common problem with reviewing what exactly is being encrypted/signed. I was told on another forum that this issue is solved by pinpads with displays, like this one (sorry for russian): http://www.rutoken.ru/products/all/rutoken-pinpad/ , but this is what I otherwise see for "pgp smartcard pinpad": https://www.google.com/search?q=pgp+smartcard+pinpad&tbm=isch Why not to make such review and confirmation operation fully software-defined, overcoming limitations of hardware appliances? This idea is even more appealing when you consider the accessibility of both VPSs and handheld devices with great displays? VPS or handhelds are attackable, but their availability allows user to set up one dedicated to keys operation, keeping attack surface of key vault minimal. This is what is wrong with the case of smartcards in my opinion. In a word: - costs money ( -> won't be chosen by a lot of people despite the rise of interest to privacy); - costs even more money and/or time to get it in far countries (good stuff is not quite available locally, or is, but for very high price); - key length limitations on certain hardware solutions (can't say for all, but I guess that 's true for majority of available hardware); - hard to use large set of keys. Let's also look at the case when we use local keys just on a local machine (as I do now, being unwilling to go with smartcards). Consider the case that user has just one full-blown workstation at hand, and needs to use untrustworthy software like browsers and closed-source apps. The workstation is not powerful enough to jail all untrusted applications to virtual machines like Qubes OS project proposes. (Even if it is powerful enough, Qubes OS is far from being production-ready, and manual AppVM handling without Qubes is pain.) In this case, what is primarily important is to store keys (and, well, all sensitive data) anywhere but locally. This looks like the situation with SSH agent forwarding to untrusted host (regarding that we don't want to store keys on it), but with the difference that we _start_ on an untrusted machine and we are not ssh-ed to it from anywhere. So even without confirmation control, remoting the keys operation is beneficial. And if we add user confirmation interface, then we eliminate the risk of what you have described as "Compromised PC opens whole host of SSH connections purporting to be you". The confirmation interface can be implemented in any convenient way. E.g. the confirmation dialog may be raised on a network-enabled smartphone; keys may be stored on smartphone or on a remote server. So, my speculations make me think that I want to implement what I have described in original posting, and that I would want it the same way even if I used smartcards daily. I am sorry if all my long posts don't explain a lot to you or don't make a lot of sense. I raised the discussion here in hope to gather opinions or get directed towards ready-to-use solutions not known to me before. Now I see that it probably makes sense to try to implement this schema in a limited scope, see how it goes, describe it comprehensively (with mushroom clouds, as requested) and present it here for review. Thanks.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
