Re: [pkcs11] CKM_SEAL_KEY

[Michael StJohns <msj@nthpermutation.com>]

On 7/2/2013 1:11 PM, Oscar K So Jr. wrote:
> Thanks Michael.
>
> You are suggesting this usage:
>
> rv = C_UnwrapKey(
> hSession,
> CKM_SEAL_KEY,
> hUnwrappingKey,
> pWrappedKey,
> ulWrappedKeyLen,
> NULL_PTR, /* pTemplate */
> 0, /* ulAttributeCount */
> &hKey /* handle to the unwrapped key blob */
> );

Pretty much.  Are you suggesting that I should add an unwrapping example 
as well?   I didn't think it was necessary, but it's pretty easy to add.


> And, any application calling this function with CKA_SEAL_KEY should 
> NOT receive error codes such as:
> CKR_ARGUMENTS_BAD
> CKR_TEMPLATE_INCOMPLETE,
> CKR_TEMPLATE_INCONSISTENT
> ?
>
> If that's the case, I think the above will work!

Right.   You can get CKR_ARGUMENTS_BAD if you've got no other applicable 
code, but the template errors shouldn't occur.

Mostly if you try and unwrap a badly wrapped key you're going to get a 
CKR_WRAPPED_KEY_INVALID error or something similar.  Anything except 
CKR_OK means you weren't able to unwrap and re-create a key.

> ------------------------------------------------------------------------------------------------------------------ 
>
> But, say, once we call C_Finalize, and how do we C_FindObjects of that 
> hKey later ?

If the unwrapped key is a token key (CKA_TOKEN = TRUE - and that's as 
it's marked in the opaque encrypted, integrity protected blob) it gets 
stored on the token by C_UnwrapKey and can be re-found after a 
C_Finalize using C_FindObject et al. in a new session using the various 
attributes of that key (generally CKA_OBJECT_CLASS, CKA_LABEL, CKA_ID, 
CKA_CHECK_VALUE, CKA_KEY_TYPE et al) that were also used to mark the 
object inside the encrypted blob.  You may already know them (because 
you are the one that stored the blob), or you can recover them from the 
key object via C_GetAttributeValue at a later time.

If its a session key, the key isn't recoverable once the session ends.


Mike

> Best,
> Oscar
>
>
>
>
>
>
>
>
>
>
>
>
> On 07/ 2/13 08:47 AM, Michael StJohns wrote:
> > On 7/2/2013 2:25 AM, Oscar So wrote:
> > > Michael,
> > >
> > > For your proposal on CKM_SEAL_KEY, at the 9th paragraph you wrote:
> > > "When this mechanism is used with C_UnwrapKey, ulAttributeCount 
> > > should be 0."
> > >
> > > Could you explain more about this ?
> > > Why does it have to be zero ?
> > >
> > > Thanks,
> > > Oscar
> >
> > Hi Oscar -
> >
> > The general contract of this mechanism is that what is wrapped is the 
> > internal, vendor-specific data related to the object being wrapped 
> > and that you get exactly the same thing back when you do the unwrap 
> > operation.  E.g. if K is all the data that describes a key in a 
> > vendor specific way then the following is true for this mechanism:
> >
> > K' == unwrap(wrap(K)) == K
> >
> > where K' is the unwrapped key.  K is indistinguishable from K' (key 
> > data, attributes etc) except for the handle of the key.
> >
> >
> > Normally with a C_UnwrapKey the template provides all (or most of) 
> > the information about the key material you're unwrapping, possibly 
> > along with the CKA_UNWRAP_TEMPLATE on the unwrapping key.    In the 
> > case of a private key some attributes (should) get set from the PKCS8 
> > structure that contains the private key. So you possibly have three 
> > different sources for any given attribute.    AND you have to get the 
> > combination of attributes correct for any given wrapped key blob.
> >
> > For this mechanism, the only source of attributes is the opaque blob 
> > that you wrapped.  You don't need to specify any attributes on 
> > unwrapping because the blob carries all the information necessary 
> > regardless of the underlying type of the key or object.  I briefly 
> > considered allowing mix-ins for other attributes (via the C_UnwrapKey 
> > call and via a CKA_UNWRAP_TEMPLATE on the unwrapping key), but came 
> > to the conclusion that it would violate the general goal of the 
> > mechanism and possibly provide some paths to manipulate the policy 
> > markers associated with PKCS11.
> >
> > Is there a use case you can think of where having attributes mixed in 
> > on unwrap makes sense and doesn't weaken the security goals?
> >
> > Mike