That's one way to do this, Tim, but I
must say I am surprised how how this simple idea got carried away.
I think there is a clear use case for a simplest API that allows
applications to "manage" opaque blobs that are seen as objects by
the HSM (the objects that we care the most are keys).
Applications don't care which sealing key to use. The key can be
implicit.
There are best practices to follow in the design of the blob, but,
again, applications don't care about the method and this design
can be declared out of scope for the PKCS#11. The life-cycle of
the blob can be vendor-specific.
There is no weakening of the FIPS certification levels, because
whatever is wrapped strictly stays within the module security
boundary.
What are we loosing with this simplest approach?
On 06/05/2013 05:31 PM, Tim Hudson wrote:
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.
