Network enabled SoftHSM

[Corentin Chary]

Hi Stef,

On Thu, Apr 14, 2011 at 5:20 AM, Stef Walter <stefw at collabora.co.uk> wrote:
> I hope it's okay if I CC the p11-glue mailing list.
>
> On 04/12/11 16:53, Simon Josefsson wrote:
>> Hi Stef!  I didn't meet you at FOSDEM, but the pkcs11-proxy project
>> reminded me about you again.. :-)
>
> I was looking forward to meeting you, but must have missed you. We had a
> great discussion about integration of applications crypto storage, which
> resulted in this:
>
> http://p11-glue.freedesktop.org/
>
>> My question is really about the gnome-keyring PKCS#11 protocol.  I have
>> been thinking about a serialized PKCS#11 protocol over network for quite
>> some time, and wanted to use something like that in a few projects.
>> Have you documented your wire protocol?
>
> No, I haven't, and I didn't really imagine that it's a sane 'general'
> solution to the problem. There are all sorts of corner case calls that
> are not supported by the protocol.
>
> In addition there's a fundamental problem: Multiple applications cannot
> use a module loaded into a single process (like a daemon). Those
> applications would see session objects of each other and PKCS#11
> security and containment guarantees would be broken.
>
> Gnome Keyring gets around this by using a dirty hack in its modules.
> Initially I was interested in making this protocol a 'general' and
> reusable component. But this is the main reason that I became less
> interested.

For the record, I'm using a stripped down version of gnome-keyring,
and it works great.

My usecase is:
- PKCS#11 device on windows (with pkcs11-daemon)
- Firefox on linux (with pkcs11-proxy)

And the code is here:

http://floss.commonit.com/pkcs11-proxy.html

It's currently based on the last svn revision of gnome-keyring, I'm
planning on rebasing it next week.

Important patchs are:
- Fix some endianess issues
- Fix C_Finalize/C_WaitForSlotEvent
- Port to windows/winsock
- Remove all glib dependencies

> Because of this problem, each client must have a separate process in the
> daemon. That said there has been some renewed interest in making this
> work. And perhaps we should split out the protocol into its own module.
> A while back Joe Orton (if I recall correctly) came up with code that
> did this.
>
> There was some discussion about unstable modules at FOSDEM, and whether
> we should split those into their own processes for security. This
> protocol could work with that.

Not each client (in term of network client), each "application". That
is because: