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.
