Re: [pkcs11] Re: Updates to CKA_GLOBAL, CKM_CERTIFY_KEY and CKM_SEAL_KEY

[Tim Hudson <tjh@cryptsoft.com>]

On 6/06/2013 7:23 AM, Michael StJohns wrote:

This is all about extending the token storage outside the physical boundaries. 

I've been observing the exchange waiting to see if there was a general interest in tackling this area - I still haven't seen that - but given the on-list discussion here are my thoughts on the problem area.

Why do you have " all pertinent key attributes" in the seal-key document? It needs to be all attributes with no exceptions to be useful IMHO if the intent is off-device storage that is application managed.

I think you'll also find that you will need a real unique identifier for each object in this context - a problem which PKCS11 has not generally solved (most vendors end up defining a vendor-specific attribute for this purpose or actually make the allocated handles returned the persistent identifier). That approach would at least allow detection of attempted unwrapping of a key which already exists in the device. I see you have tackled this in the Global proposal - but it seems overly complicated there when it could just be a simple requirement for all objects to have a UUID defined - and I don't see the rational in the complications of various types of "Global" at all - that proposal could be simplified to a single new mandatory attribute.

Why limit sealing to a SECRET_KEY only? Why a symmetric approach only?
Why not define an actual output format? A requirement to protect the integrity of the attributes?
You have done that for the certify output - in the global values proposal - why not for seal?

The way I've read your proposals is all aimed with a particular solution in mind all tied together with a level of interdependence where there is a much simpler approach like the following relatively simple proposal that could handle the problem you've described that you are focused on solving:
1) define a single new attribute which is a unique identifier - CKA_UNIQUE_ID - allocated by the device - format unspecified - byte array
2) define a single new mechanism for usage with Wrap/Unwrap with a defined output that defines a format which contains the value (wrapped) all attributes and a MAC mechanism so attributes cannot be altered between being wrapped and unwrapped (almost like the Certify output but with a MAC involved)
3) define a single new attribute for objects which can be used in the Wrap/Unwrap context (i.e. those keys which are allowed to wrap)

The interesting item is how to control the setting of that new attribute which allows wrap/unwrap to be performed entirely independent of the setting of EXPORTABLE attribute. For the extending token storage context that can be as simple as a non-extractable, non-exportable, sensitive, token, local object (that I think is the combination you are looking for) - i.e. the attribute in 3) can be set to TRUE only if those other conditions are also TRUE and only by the SO and not by the USER.

This does not however solve the export-from-one-device, import-to-another-device context which is the other problem that these proposals I think are not discussing.

Mike - the question is basically why can the problem you are trying to address not be solved by the simple 1) 2) 3) approach above?

Now I don't see this as a v2.40 issue myself unless there are a pile of (key) vendors who plan to implement something like this - rather than a list of users (applications) who want to see something like this.

Tim.