Re: [pkcs11] Sensitivity and extractability of derived keys

[Michael StJohns <msj@nthpermutation.com>]

Plane has wifi - who knew?

On 8/14/2013 12:07 PM, Oscar So wrote:
> Thanks Michael.
>
> I think you are referring to 6.25.5 (Master key derivation).
> I still don't see 3).

It's 2.25.5 in the 2.40 first rev doc set - in the 
pkcs11-curr-v2.40-wd01.pdf.

It says:
> This mechanism has the following rules about key sensitivity and 
> extractability:
>  The CKA_SENSITIVE and CKA_EXTRACTABLE attributes in the template for 
> the new key can both be specified
> to be either CK_TRUE or CK_FALSE. If omitted, these attributes each 
> take on some default value.

Which is what I meant by (3).

> Say 3) is there, I believe it's still fine to have 3) , and having all 
> options open for the implementor.
> I also strongly believe that the implementor will have to reference 
> the Key Management Security Policy (set by Security Administrator), 
> and set these sensitivity attributes accordingly.

The issue is mostly that I can't get the PKCS11 module to prevent an 
attacker from repeating the derive (using the original key material and 
a new template) and setting the sensitivity to "not sensitive". As I 
said, my threat model is to protect against authorized but illegitimate 
users (e.g. the application using the HSM was hacked) being able to 
extract key material.

If the pre-master key had a CKA_DERIVE_TEMPLATE and that template had 
CKA_SENSITIVE=true and CKA_EXTRACTABLE=false (template set when the key 
was generated or derived from the DH or ECDH key) then the subsidiary 
keys should be protected against the type of attack I envisioned.

But right now there's no CKA_DERIVE_TEMPLATE and that is limiting PKCS11 
the ability to protect secondary key material.

BTW - 2.3.9, 2.3.10, 2.3.11, 2.4.10,   - ECDH and a bunch of others 
(search for "key sensitivity") also use (3) as their treatment. (*sigh* 
even SHA1 key derivation).



> -Oscar
>
>
>
>
> On 08/14/13 08:38 AM, Michael StJohns wrote:
> > On 8/14/2013 6:08 AM, Oscar So wrote:
> > > Michael,
> > >
> > > Can you point me to the section of the spec which mentions 3) ?
> >
> > Robert mostly copied the TLS12 stuff from TLS.  That text is in the 
> > TLS (2.25.5) section (and is in the SSL 2.24.5 section as well).  I 
> > haven't had a chance to look elsewhere.
> >
> > Mike
> >
> > > Also, I believe 3) is an option, an open option.
> > > You do 3) only if you absolutely need it.
> > > Otherwise, by default, one should not do 3).
> > >
> > > Thanks!
> > >
> > > -Oscar
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: msj@nthpermutation.com
> > > To: pkcs11@lists.oasis-open.org
> > > Sent: Sunday, August 11, 2013 12:25:45 PM GMT -08:00 US/Canada Pacific
> > > Subject: [pkcs11] Sensitivity and extractability of derived keys
> > >
> > > I'm editing the TLS12 mechanism section and I keep bumping up against
> > > the appropriate values for CKA_SENSITIVE and CKA_EXTRACTABLE for 
> > > derived
> > > keys.
> > >
> > > There are basically three different cases that are described in PKCS11
> > > document (pretty much over and over in different locations)
> > >
> > > 1) Keys get the same sensitivity values as the base key.
> > > 2) Keys can be set the same or more sensitive than the base key, but 
> > > not
> > > less sensitive - e.g. CKA_SENSITIVE=false for the base key can get 
> > > you a
> > > CKA_SENSITIVE=true for the derived key and CKA_EXTRACTABLE=true for the
> > > base key can get you a CKA_EXTRACTABLE=false for the derived key.
> > > 3) Keys can be set to any sensitivity level regardless of the base 
> > > key's
> > > sensitivity settings.
> > >
> > >
> > > TLS10 uses (1) for KEY_AND_MAC_DERIVE and (3) for the master key 
> > > derivation.
> > >
> > > CKM_EXTRACT_KEY_FROM_KEY uses (2).
> > >
> > > The draft TLS1.2 document currently follows TLS10, but I'm not sure
> > > that's the most correct approach.
> > >
> > >
> > > There are a few things I'd like some comments on:
> > >
> > > 1) Would it make sense to move the three cases to their own section and
> > > then use the superscript approach to tag each mechanism with how the
> > > derive sensitivity is handled (e.g. table 15 provides superscripts for
> > > how CKA_ values are treated - so do something similar for derives)?  If
> > > so, can this just be done as an editorial change?
> > >
> > > 2) Does (3) ever make sense?
> > > 2a) If (3) always makes sense, then how do you ensure that derived keys
> > > can be kept within the HSM?
> > > 2b) if (3) never makes sense how do you export session keys so they can
> > > be used in software (e.g. HSM is the public key accelerator, but 
> > > most of
> > > the encryption is done using a generic processor).
> > > 2c) if (3) only sometimes makes sense, then how do we configure the HSM
> > > to do the sensible thing for different cases?
> > >
> > >
> > > Mike
> > >
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this mail list, you must leave the OASIS TC that
> > > generates this mail.  Follow this link to all your TCs in OASIS at:
> > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php