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

[Michael StJohns <msj@nthpermutation.com>]

I really wish you'd leave in the quote markings.  It's getting painful to find what you are writing.


On 6/5/2013 6:16 PM, Chris Zimman wrote:

So the enforcement of this then becomes the responsibility of C_(Un/)WrapKey() and also requires the concept of the CKA_GLOBAL for presence?  Would it make more sense to just make a new key type for this mechanism?
 

No.  Keys can already be tied to specific mechanisms.  That's the way to do it.  And the "policy exception" stuff for a specifically designated key, will of course be enforced by C_Wrap/Unwrap -- where else would you do that?

	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.  

I guess I'm sort of missing the point here then - is the intention for me to be a good citizen and every time I'm done using a key to seal it and move it to offline storage to make more room on the token?  As a user of a token, this is not something I'd generally want to have to concern myself with.

No.  But the application that is actually talking to the token may choose to do exactly that.  

	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.

It does present issues in terms of atomicity and revocation.  As you've pointed out, if a key is deleted intentionally, it can also potentially be restored unwantedly.

	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.

Doesn't this present the same issue that this is trying to solve in the first place?  Where do you keep record of which (or copies) of these subordinate sealing keys are valid?

For this set of points, I'm going to defer.  Right now, the tokens only support role logins and not user logins.  And having a single key for the token and session to do sealing is probably sufficient.  The user is the token owner, regardless of who is actually using the user login.  That means that the "user" is responsible for content consistency.  If we get to the point where there user based logins then we will need to readdress a bunch of things, this included.

      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.

Yes, but the attack surface becomes much more open when you don't have to use the HSM to perform the attack against itself.  The "hardness" of the offline attack depends on the requirement that your sealing key is at least as strong as what it's sealing.

Fair.  But again, you're assuming the HSM is actually proof against hardware based attacks (DPA for example) and has better security than a blob at rest encrypted with appropriately strong keys.  Given all I know about the general HSM marketplace, I'd rate them similar in resistance to attack.

	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.

Ignorant or misguided does not necessarily imply stupid, but can be just as dangerous.

What I'm saying is that this isn't actually an implementation guide per se.  Saying PKCS11 does not imply "FIPS 140-2 level 4" guarantees of protection or other external guidance.  I'm not exactly sure we should go there.  (Mainly because that opens up a food fight where we become way too proscriptive and fight over each and every MUST....)