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

[Michael StJohns <msj@nthpermutation.com>]

On 6/5/2013 9:42 AM, Chris Zimman wrote:

Any user of the token.  Just think of the combination of the seal key and this mechanism as unlimited storage within the cryptographic (NOT
physical) boundary  of the token.

Are there restrictions on what operations a sealing key can be used for?  Given the particular sensitivity of a sealing key, one might want to preempt chosen pt/ct attacks that could be potentially implemented by being able to use a sealing key for arbitrary secret key operations.  Also, perhaps a potential restriction on only sealing keys that were already marked as CKA_NEVER_EXTRACTABLE.  Presumably, if a key can/has been extracted, there was already a means to store it somehow outside of the token.  The overarching goal here being preventing sealing key compromise via intentional API misuse.

See the document I sent out a few days ago - this is covered:

Seal objects are always secret keys.  They may only be used with the CKM_SEAL_KEY mechanism

The "sealed" data is not a PKCS11 object, and sealing a key does not delete it from the token.  The client has to explicitly delete it if it wants to recover space on the token. 
Similarly, the client is responsible for "unsealing" the sealed data and re-creating a new key object (with generally a new CK_HANDLE).

Understood -- I need to think this through a bit.  This has interesting implications for things that will be proposed for 3.x -- e.g. the concept of identity based vs. role based credentials in the sense that you would only then be able to "seal" keys that you already own.

No.  This is tied to the token, not to the user.  If the key can be used by a particular user, it can be sealed.  This is all about extending the token storage outside the physical boundaries. 

But there's another point here that I need to think about.  If the key contains all the attributes, and an attribute changed once the key was sealed, unsealing the key is going to get you the old attributes and possibly reverse an access control decision.

Keep the same mechanism, but add way of generating/zeroizing persistent seal keys that are subordinate to the token seal key. That way you can group sealed keys by use, and zeroize a specific group of keys all by rolling over the key used to seal them.   Or still zeroize them all by re-initializing the token.

And yes, this allows you to bypass the COPYABLE control, but since you can't change any attributes of the key, all you end up with is two copies of the same key with the exact > same attributes. C_CopyObject notionally allows some attributes to be changed when the object is copied and hence the need for the CKA_COPYABLE=false control.

Again, my concern is not really so much with the idea of exporting wrapped keys, since there are already proprietary ways to do so.  It's more to make sure that adding something like this as a standard feature doesn't open up holes.

I do appreciate the comments.  They're making me revalidate my assumptions.

I'm not sure why you would care.  If the key you're doing the wrapping with is never ever exportable from the token, then the exported "sealed"
key is logically within the cryptographic boundary of the token.  The bits you store outside the token are pretty much nothing but random bits without the key.

With sufficiently careful and correct "seal" implementation yes, without, not so much.  If this is in place and used, the entire strength of the token rests on how correctly this was done.  Consider that once keys are outside of the token, wrapped or not, they are fair game to any offline attack that someone wants to mount against them.

Actually, any key you can use is subject to various attacks - but most of them (like the offline attacks) are no better than brute force.

You say it just like you did.  That the global seal key needs to be at least as strong as any key it wraps for whatever value of "strong" 
applies.  That allows someone in the US to use AES 256 and someone in say Russia to use the GOST family, and have both comply with local 
requirements.   If I just said that "the global wrap key MUST be an AES 256 bit key and the mode MUST be CKA_AES_KEYWRAP_PAD" I guarantee there would be great 
amounts of push back.

OK fine, but that's not mentioned in the proposal as it stands.  One of the things I'm considering here is what guarantees a token implementer makes to someone using their token if they use something like this.

A lot of times this is "don't be stupid" type of guidance to the implementer.  There are other places (e.g. FIPS) where it requires the relationship you mention above.  If I were going to try and fix this, I'd actually do it in the text for C_WrapKey and C_UnwrapKey rather than in this mechanism description.