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

[Michael StJohns <msj@nthpermutation.com>]

On 6/4/2013 2:52 PM, Chris Zimman wrote:
> 	Actually, no.  It takes a conscious effort to bypass this - the only way the normal controls are bypassed is if you use the CKA_GLOBAL seal key (defined in the other 	document).
>
> So who can use the CKA_GLOBAL seal key?
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.

> What happens if the key I happen to want is "paged out" at the time I request it?

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

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.

> 	This should be fine.  A number of devices already do this implicitly.  And we're doing a device that uses this concept to deal with storage.  I also refer you to several TPMs 	which support this and are FIPS140 certified.
>
> The idea of wrapping a blob and exporting it doesn't inherently concern me.  It's the concept of being able to wrap any key and export it, even if I don't want it being done.

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.

> 	I'll add this guidance to the draft, but I won't specify the mechanism.  That's up to each and every token manufacturer to select.  (But CKA_AES_KEYWRAP_PAD might be 	a good choice... )  The main reason for avoiding specifying this is that various regulatory domains (e.g. countries) may have specific guidance on which types algorithms 	can be used for this purpose.
>
> There is already specific guidance around which mechanisms can be used to wrap keys for other mechanisms.  The basic idea being that you cannot wrap a key for export with a mechanism/key that is weaker than the key which you're wrapping, since it'd become the weakest link in the chain.  How do you do something like that on a global scale?

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.

Later, Mike