Re: [pkcs11] CKM_SEAL_KEY used with CKA_COPYABLE =false and/or CKA_EXTRACTABLE = false

[Michael StJohns <msj@nthpermutation.com>]

On 7/3/2013 12:43 PM, Stef Walter wrote:

How does CKM_SEAL_KEY interact with CKA_COPYABLE. It seems like
CKM_SEAL_KEY can be used to get around CKA_COPYABLE.

I'm the stupid idiot that requested support for that item be added. I was actually trying to make it possible to create a seal key.  For various reasons, the semantics never made sense.

It may be that C_UnwrapKey + CKM_SEAL_KEY refuse unwrap a sealed key
when that key already exists on the token. In any case, it be defined in
the proposal after discussion.

The key difference between unsealing a wrapped key and  C_CopyObject is that it's possible to change attributes as part of the copy.  Prohibiting the copy seemed to be the only way to prevent changing the object privileges.

In the case of C_UnwrapKey using CKM_SEAL_KEY and a key marked specifically for sealing you get an exact copy of the object you output with no change in attributes or privileges.  E.g. you have two keys that have the exact same set of policies wrapped around them, the exact same labels and identifying information (except the handle).  For the life of me I couldn't come up with any case where this was an issue.

Secondly, there is no clear guidance on what kind of CKO_SECRET_KEY can
be used with CKM_SEAL_KEY. Since CKM_SEAL_KEY can operate on keys with
CKA_EXTRACTABLE = CK_FALSE, unless the sealing key meets at least all of
the following, CKM_SEAL_KEY can be used to circumvent token security:

 * CKA_NEVER_EXTRACTABLE
 * CKA_LOCAL
 * A strong key (ie: not DES)

I believe this latter point was brought up in our discussion on the
phone last week.

Have you come up with a solution for this?

*sigh* that guidance was in the object descriptions specific to the seal keys as part of the CKA_GLOBAL document.  I removed those paragraphs so that CKA_GLOBAL could be considered as a general mechanism without getting into arguments about the actual objects it covers.  I'm having whiplash from adding and removing stuff to try and deal with dependencies.  CKM_SEAL_KEY likewise is both a general mechanism that is subject to all policy constraints for most keys, but gets to "bypass" policy if used with one of the seal keys:

When used with a special class of wrap/unwrap keys, it is even possible to wrap keys that would normally be unextractable when the wrapping key is one of the defined seal keys (see [section on global objects, seal keys]). 

and

When used with one of the seal keys, the mechanism will allow C_WrapKey to wrap any existing key, whether exportable (CKA_EXTRACTABLE = TRUE) or not,  and will output an opaque byte array.  The information wrapped includes all pertinent key attributes in an implementation dependent form.  "Pertinent" here means all attributes that are actually meaningful for the key - e.g. don't include CKA_MODULUS for an CKK_EC key that are present on the key with a non-default value.

Here's the actual text from pkcs11-global-objects.docx with respect to the seal keys and what they should be:

Seal objects are always secret keys. They are used to "export" or wrap keys that normally couldn't be exported, mainly to free up internal space.  They are never exportable, they are always private (e.g. usable only when a token user is logged in).  They may only be used with the CKM_SEAL_KEY mechanism.

Cryptographically, these keys, when used with the CKM_SEAL_KEY mechanism allow the use of external storage, while still protecting the keys as if they were internal.  The sealed keys may only be unwrapped by the same token (or same session) that wrapped them. 

Since the seal keys are zeroized upon session close or token zeroization, any sealed key material external to the token becomes no better than random bits upon those actions.

As general guidance, the seal key should be greater than or equal to in strength to any key it wraps or unwraps.

Cheers,

Stef

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php