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

[Chris Zimman <czimman@bloomberg.com>]

> 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.
 
> 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.

> 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'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.

> 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.