Linux in-kernel keys support

[David Härdeman]

On Wed, Jul 27, 2005 at 08:51:55PM +1000, Damien Miller wrote:
>David Härdeman wrote:
>
>>The disadvantage is that the kernel key storage doesnt support two things 
>>that
>>the agent supports: signing challenges and asking for confirmation before
>>allowing the use of a key. The former implies that secret keys are readable
>>(by the user who added them) from the kernel which might not be wise from a
>>security point-of-view.
>
>Yes, that is the point of the agent - you can load your private keys in,
>but not get them out.
>

Understood...and with time, it might be possible to get the same kind of 
functionality into the kernel...I've seen patches by David Howells which 
add RSA signing capabilities to the kernel (as part of the modsign 
patch, see http://people.redhat.com/dhowells/modsign/). If the RSA part 
would be added along with parts of the MPI math library, it should be 
quite trivial to also add DSA and then all ssh1 and ssh2 key types would 
be supported unless I'm mistaken.

>>On the other hand, if someone was to break into your account, and thus was
>>able to read the secret keys from the kernel....I imagine that he/she could
>>already do similar things by reading the memory of the ssh-agent and/or 
>>using
>>it to log into other machines...
>
>We take steps to avoid attackers reading keys out: we prevent coredumps
>and ptrace of the agent process. To prevent others accessing the agent
>it checks that uid of the user making requests on it matches the one who
>started it.
>
>This doesn't help so much against a hostile root, but they could grovel
>keys out of /dev/kmem anyway (this is where hardware tokens come in).
>
>An attacker who breaks your account can still log in using the agent
>that is there, but I guess that is a little better than being able to
>take your keys away to continue their attacks at their leisure. To
>reduce this risk further you can run with key restrictions, like
>confirm-on-use ("ssh-add -c ..." - highly recommended).
>

Yes, I could still add the functionality to ssh-agent to use the 
per-process keyring which is also provided by the same kernel key 
storage...that would only allow the ssh-agent to read the keys, and it 
should also make it virtually impossible to read keys for a non-root 
attacker (won't be swapped to disc, and coredumps and ptrace would be a 
non-issue, also even if the agent segfaults, we could be sure that the 
keys are really wiped from memory).

>>I hope that cleared things up a bit...now, is the idea somewhat sane or is 
>>it whack?
>
>Well, unless the kernel gets challenge-signing capabilities, then you
>would be sacrificing security because an who breaks your account can
>read your private keys.
>
>OTOH, if the kernel gets the ability to sign challenges then we could
>treat it as a hardware token using the existing OpenSC code. Writing a
>token interface to the kernel keystore would be a really cool project
>for someone interested.
>

Yes, but some might be willing to make that sacrifice (at least until 
the kernel gets signing capabilities, if ever)...much the same way that 
you can have unencrypted secret keys on-disc currently...

>If you are frustrated by managing keys between lots of agents, then you
>can ask it to puts its SSH_AUTH_SOCK in a well-known place using (e.g.)
>"ssh-agent -a ~/.ssh/agent-sock"

Yes, I know...but the hassle is apparently enough that people are 
creating workarounds such as keychain (see 
http://www.gentoo.org/proj/en/keychain/index.xml). I think in-kernel 
keys would be a more complete solution...

Regards,
David