PKCS#11 support and proxy providers

[Carl-Johan Sveningsson]

Simon Josefsson <simon <at> josefsson.org> writes:

> 
> Craig Ringer <craig <at> postnewspapers.com.au> writes:
> 
> > Hi
> >
> > I've been doing some research into PKCS#11 support in GnuTLS and into
> > PKCS#11 proxy providers. There was some discussion on both some time ago
> > on the GnuTLS devel list, but I've been unable to find much more recent
> > than 2007. Current GnuTLS sources do not appear to support loading and
> > using a PKCS#11 provider module.
> >
> > Is there PKCS#11 support in GnuTLS that I'm missing? Or did the PKCS#11
> > work done in 2007 not come to anything?
> >
> > The reason I'm interested is that some apps I use, including Evolution
> > Data Server's Camel mail client module, use GnuTLS for their crypto
> > needs. This not only prevents them from talking to smart cards and other
> > hardware keys, but it prevents them from using centralized PKCS#11-based
> > certificate stores like the GNOME Keyring Daemon. Users must instead
> > configure each GnuTLS-using app to load their certificate from a PKCS#12
> > file.
> >
> > I'm looking into ways to get a centralized key store, including PKCS#11
> > proxying for smart cards and the like, into wider use on Linux desktops.
> > As part of that I'd be really interested in any progress on PKCS#11
> > support in GnuTLS. For my purposes I'd only need single-provider
> > support, since GnuTLS would talk to the proxy provider over a UNIX
> > socket and that'd manage the keystore as well as any smart cards and the
> > like.
> >
> > I've been unable to find any suitable existing proxy provider
> > implementations, so I was thinking of writing a thin PKCS#11 provider
> > module and a daemon that uses libnss to handle the keystore, card
> > proxying, and the like. Is anyone here aware of a suitable existing
> > PKCS#11 proxy daemon and provider that might do the job?
> 
> Hi.
> 
> You should be able to implement what you need using the sign callback in
> GnuTLS:
> 
>
http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#index-gnutls_005fsign_005fcallback_005fset-268
> 
> This lets you send back the sign request to where the private keys is,
> which can include a PKCS#11 provider.
> 
> However, I would agree with you that something more would be useful.
> 
> We have been thinking about a 'gnutlsd' daemon that can sit in the
> background and hold private keys, or tunnel them to PKCS#11 providers.
> See some ideas on:
> 
> http://redmine.josefsson.org/projects/gnutls/wiki/GnuTLSExternalValidation
> 
> Seahorse could implement the same protocol, and would then be able to
> hold private keys and serve GnuTLS clients.
> 
> I think it makes more sense for these daemons to do the PKCS#11
> integration than including that code in the TLS client library.  It
> makes things simpler and easier to debug.
> 
> I wish I had more time to work on this, it would be quite interesting.
> If you want to help, now is a good time to do it, since we have just
> opened the 2.9.x branch.
> 
> /Simon
> 



Hello everyone,

please pardon me if I'm confused about what I want to achieve or how to do it (I
have not been close to gnutls at all, only other peripherial stuff), but I have
been missing some sort of PKCS#11 proxy for a long time.

I can come up with a number of use-cases which I don't know how to solve today,
like letting an application in a virtual machine or vnc interact with a physical
local PKCS#11 device, decrypting data on-server in your webmail, accessing a
PKCS#11 device plugged into a lighter system than the one running the
application, like some thin client (on some level, probably all these situations
are analogue).

At which layer could such a proxy be placed, in order to enable flexibility but
with minimal complexity installed on the device holding the PKCS#11 device?

If someone could give me anything on this, even a pointer in the right
direction, it would be much appreciated.

Thanks, best regards
Carl-Johan Sveningsson