How about using the existing OpenSSH client's PKCS#11 support to isolate keying material in a dedicated process? A similar approach, "Practical key privilege separation using Caml Crush", was discussed at FOSDEM'15 with a focus on Heatbleed [1][2] but the ideas and principles are the same. Now this is easily done using the following available components: - SoftHSM to store the crypto keys - Caml-Crush server components load the SoftHSM middleware (access the keys) in a dedicated process - SSH client loads Caml-Crush PKCS#11 middleware that connects to its daemon and allows to sign SSH exchange to authenticate No patch needed. Hope this helps, Thomas [1] https://archive.fosdem.org/2015/schedule/event/caml_crush/ [2] https://github.com/ANSSI-FR/caml-crush On Fri, Jan 15, 2016 at 9:30 AM, Loganaden Velvindron <loganaden at gmail.com> wrote:> On Thu, Jan 14, 2016 at 7:12 PM, Alexander Wuerstlein <arw at cs.fau.de> wrote: >> Hello, >> >> in light of the recent CVE-2016-0777, I came up with the following idea, >> that would have lessened its impact. Feel free to ignore or flame me, >> maybe its stupid or I missed something :) >> > > Feel free to come up with a patch. In OpenSSH, it's a good idea to > follow-up with a patch :) > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Alexander Wuerstlein
2016-Jan-15 11:54 UTC
Proposal: always handle keys in separate process
On 2016-01-15T11:23, Thomas Calderon <calderon.thomas at gmail.com> wrote:> How about using the existing OpenSSH client's PKCS#11 support to > isolate keying material in a dedicated process? > > A similar approach, "Practical key privilege separation using Caml > Crush", was discussed at FOSDEM'15 with a focus on > Heatbleed [1][2] but the ideas and principles are the same. > > Now this is easily done using the following available components: > - SoftHSM to store the crypto keys > - Caml-Crush server components load the SoftHSM middleware (access > the keys) in a dedicated process > - SSH client loads Caml-Crush PKCS#11 middleware that connects to > its daemon and allows to sign SSH exchange to authenticate > > No patch needed.Well, yes, that could of course work, but there is already an easier, existing and included-in-OpenSSH solution that does separate keying material: ssh-agent. My proposal was just to automate spawning it, thereby making things transparent and easy for users. The solution you describe sounds[1] a bit more complicated than even the current state of manually starting ssh-agent and ssh-add-ing all keys. Ciao, Alexander Wuerstlein. [1] I may be wrong there, of course
OpenSSH already has an agent protocol, that is much more simple than this whole pkcs11 thing and already has both sides implemented. I could see an OpenSSH client starting an ephemeral ssh-agent that will do the key handling. Implicit identities could be removed from the default configuration, too. Most users already have an agent and aren't aware it exists, and having to type the passphrase every time encourages users to have unencrypted keys. Aris On 15/01/16 11:22, Thomas Calderon wrote:> How about using the existing OpenSSH client's PKCS#11 support to > isolate keying material in a dedicated process? > > A similar approach, "Practical key privilege separation using Caml > Crush", was discussed at FOSDEM'15 with a focus on > Heatbleed [1][2] but the ideas and principles are the same. > > Now this is easily done using the following available components: > - SoftHSM to store the crypto keys > - Caml-Crush server components load the SoftHSM middleware (access > the keys) in a dedicated process > - SSH client loads Caml-Crush PKCS#11 middleware that connects to > its daemon and allows to sign SSH exchange to authenticate > > No patch needed. > > Hope this helps, > > Thomas > > [1] https://archive.fosdem.org/2015/schedule/event/caml_crush/ > [2] https://github.com/ANSSI-FR/caml-crush > > > On Fri, Jan 15, 2016 at 9:30 AM, Loganaden Velvindron > <loganaden at gmail.com> wrote: >> On Thu, Jan 14, 2016 at 7:12 PM, Alexander Wuerstlein <arw at cs.fau.de> wrote: >>> Hello, >>> >>> in light of the recent CVE-2016-0777, I came up with the following idea, >>> that would have lessened its impact. Feel free to ignore or flame me, >>> maybe its stupid or I missed something :) >>> >> Feel free to come up with a patch. In OpenSSH, it's a good idea to >> follow-up with a patch :) >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
Another candidate might be ssh-keysign> Am 15.01.2016 um 12:54 schrieb Alexander Wuerstlein <arw at cs.fau.de>: > >> On 2016-01-15T11:23, Thomas Calderon <calderon.thomas at gmail.com> wrote: >> How about using the existing OpenSSH client's PKCS#11 support to >> isolate keying material in a dedicated process? >> >> A similar approach, "Practical key privilege separation using Caml >> Crush", was discussed at FOSDEM'15 with a focus on >> Heatbleed [1][2] but the ideas and principles are the same. >> >> Now this is easily done using the following available components: >> - SoftHSM to store the crypto keys >> - Caml-Crush server components load the SoftHSM middleware (access >> the keys) in a dedicated process >> - SSH client loads Caml-Crush PKCS#11 middleware that connects to >> its daemon and allows to sign SSH exchange to authenticate >> >> No patch needed. > > Well, yes, that could of course work, but there is already an easier, > existing and included-in-OpenSSH solution that does separate keying > material: ssh-agent. > > My proposal was just to automate spawning it, thereby making things > transparent and easy for users. The solution you describe sounds[1] a bit > more complicated than even the current state of manually starting > ssh-agent and ssh-add-ing all keys. > > > > Ciao, > > Alexander Wuerstlein. > > [1] I may be wrong there, of course > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
On 18/01/16 17:11, Aris Adamantiadis wrote:> Implicit identities could be removed from the default configuration, > too. Most users already have an agent and aren't aware it exists, and > having to type the passphrase every time encourages users to have > unencrypted keys. > > Aris+1 While they may be handy if you have a single key, once you start using several keys, they mainly just get on the way. It can't be simply removed though, as that could make some ssh clients to stop working. I would make sure the same behavior can be achieved with IdentityFile (it may need to be tweaked so you add keys at the end), and then remove the native support, moving it to the config file.