OASIS PKCS 11 TC

Michael, Can you point me to the section of the spec which mentions 3) ? 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

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

Thanks Michael. I think you are referring to 6.25.5 (Master key derivation). I still don't see 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. -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

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