[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Re: Updates to CKA_GLOBAL, CKM_CERTIFY_KEY and CKM_SEAL_KEY
On 6/4/2013 2:52 PM, 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.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?
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.