> I hope it's okay that I've CC'd your email to gnome-keyring-list.Perfectly fine - I've been out on vacation so a little slower to respond than usual. I've just subscribed so hopefully relevant discussion can happen on-list.
> Interesting. I'm a intrigued/concerned about using such high level constructs for the transport mechanism, when PKCS#11
> can be and is used to implement things like SSH agents and stuff.PKCS#11 is a crypto-api and can be used at a pile of different levels - it is pretty much the only C API which is cross-platform for crypto which is supported by a range of separate vendor implementations so it is really the lowest common denominator and the 'right' place to interface to vendor devices (sufficiently high-level to be able to support a sensible range of security attributes and also sufficiently low-level to not force a particular security view onto an application).
> But the main problem I've run into, is the assumption that PKCS#11 can be generically remoted. I started with this assumption,
> but I was proven completely wrong.It can be generically remoted for special values of 'generic' - where conversion routines are provided for each of the mechanism specific data structures and knowledge of the size of underlying vendor attribute extensions in order to determine if they are meant to be CK_ULONG size or some other size. There is unfortunately not a defined way of communicating this information to an application - it just has to be encoded.
Many vendors who provide PKCS#11 interfaces to their devices support their devices being used over-the-wire and a number of vendors effectively serialise and deserialise PKCS#11 calls as their wire format - it can and does work in practical terms - as a typical context of usage is as simple as initialise, open-session, login, find-object-by-attribute, do-something, logout, close-session, finalise - and for a long-lived application all but the do-something can be performed a single time. Local network performance is fine, WAN usage is fine, even usage in an internet context remotely is possible (although it can be latency bound depending on the application).
> However large swaths of PKCS#11 either cannot be remoted easily, or do not make sense to remote. I'm simply going to have to agree to disagree on this one - they can all be remoted - and they all make sense to remote. The remoting is not as trivial as it could be if PKCS#11 had taken a different path for specification of mechanism specific parameters or provided some method of communicating meta-data to the application.
> First of all, PKCS#11 definitely assumes that the application and module share memory space. > For example, take a look at many of the CK_MECHANISM pParamater contents for various mechanisms. > They often contain pointers to random bits of memory, which would be a complete hack per mechanism to implement. It simply means mechanism specific code for those mechanism where the parameters are simply references to other data - it has to be serialised and deserialised. It is simple code to do this. It is mechanism specific - but it is well defined.
> Check out gck_rpc_mechanism_has_sane_parameters() and gck_rpc_mechanism_has_no_parameters() in gck-rpc-util.c Already did - and had to disable the mechanism filtering logic so I could see all the target mechanisms - I'd rather see the mechanisms as being available from the token and then fail in their usage than have them silently dropped - it probably should be configurable behaviour.
> Attributes with CKF_ARRAY_ATTRIBUTE like CK_WRAP_TEMPLATE and CK_UNWRAP_TEMPLATE are a real pain to implement Agree that they are annoying to have to implement - but is is simply code. And the result of being able to have any application talk to any PKCS#11 implementation not matter what platform you have the ultimate end vendor PKCS#11 interface available on is the payback for doing this work - universal HSM access is something rather important. Applications should not have to worry about the concept of how or where a security device is located.
> But the problems get worse ... A massive show stopper is the combination of multiple applications accessing a module living
> in the same memory area. A single instance of a PKCS#11I don't see an issue with this at all - either you can safely serialise and deserialise or you cannot. If you can then there is no problem. Now in my context of usage (as you can see in the patched code) I have a separate process per application so I actually do not have a shared server - however the point remains valid in that it could be a single server and there should be no difference in the security implications (absent any bugs being present in the code which deserialised etc).
> ... PKCS#11 does not have the concept of multiple applications using a PKCS#11 in a shared memory space. You'll have to expand on the issue you are talking about here - as PKCS#11 does indeed have the concept of applications and sessions and goes to some length to explain mappings etc - although that part of the specification is not what I'd call the easiest section to read through.
> One final thing, is that applications dealing with PKCS#11, by and large, assume they're dealing with an module nearby. Applications which do lots of 'chatty' things with PKCS#11 will get hit by latency issues - and there are some standard ways of dealing with certain types of behaviour with cached results which can fix specific poorly performing applications - however these same applications would have issues working with devices from a number of vendors which are network connected.
> PKCS#11 isn't really designed to be used like this.PKCS#11 is being used like this in production environments. It may have expanded over the last decade from a simple personal user token interface but the vast majority of HSM vendors support PKCS#11 as their primary interface (or one of their supported interfaces) for application integration. The specification could be changed in a number of areas and various vendors have raised the issue on the PKCS11 mailing list - however there is the reality of the existing installed base which needs to be handled - having to migrating applications tends to slow down the pace of radical change.
> It's an ok API for applications to keys, but really not much more.You may be surprised with some of the uses PKCS#11 gets put too - and for a lot more than access to a handful of keys - but that is another topic.
> If I had more than one lifetime, I probably would have chosen CDSA for use in gnome-keyring. CDSA doesn't solve the problem in any better manner and it really would paint you into a corner in terms of total lack of vendor support. There is no one-true-cryptoapi - PKCS#11 is about as close as it gets IMHO.
With the work you've done I think a generic cross-platform remoting interface for PKCS#11 is relatively easily achieved - I was working 32/64 bit across x86, sparc, and arm without a problem for 'standard' mechanisms and attributes with only some simple changes.
Tim.
Attachment:
PGP.sig
Description: PGP signature