[RFC] Keychain for GPG, SSH, X.509 etc. (inspired by Split GPG)

[Andrey Utkin]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20151201/3bd1695a/attachment.sig>