OASIS PKCS 11 TC

 View Only
  • 1.  CKA_VALUE_LEN and C_UnwrapKey

    Posted 06-10-2015 11:17
    Dear TC, A couple of things on key wrapping: - I checked the spec and the latest version already allows GCM and CCM mode for C_WrapKey and C_UnwrapKey (se table 60). That’s good. - However, while examine the minutiae for an implementation we came across the following issue:  For AES keys, the superscripts in table 47 (sec 2.8.2) specify that CKA_VALUE_LEN must *not* be given when unwrapping an AES key.  However, sections 2.8.4 and 2.8.5 (ECB and CBC unwrapping using AES) both say that:   For unwrapping, the mechanism decrypts the wrapped key, and truncates the result according to the  CKA_KEY_TYPE  attribute of the template and, if it has one, and the key type supports it, the  CKA_VALUE_LEN  attribute of the template.  Since a 192-bit AES key and a 256 bit AES key would both require two CBC or ECB blocks, I think the CKA_VALUE_LEN *must* be specified in order to be sure that the right object is created. So I propose that (in v2.41) we delete the superscript 6 from CKA_VALUE_LEN in table 48 and replace it with superscript 5.  Note that in testing implementations we found a variety of behaviours here, and one case where ambiguity around this allowed us to execute a padding oracle attack on unwrapping that a manufacturer thought they had prevented. Best, Graham Steel +33 (0)9 72 42 35 31 http://cryptosense.com Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail


  • 2.  Re: [pkcs11] CKA_VALUE_LEN and C_UnwrapKey

    Posted 06-10-2015 18:20
    Let's talk about this today, I will add it to the agenda. Thank you Valerie On 6/10/2015 4:15 AM, Graham Steel wrote: Dear TC, A couple of things on key wrapping: - I checked the spec and the latest version already allows GCM and CCM mode for C_WrapKey and C_UnwrapKey (se table 60). That’s good. - However, while examine the minutiae for an implementation we came across the following issue: For AES keys, the superscripts in table 47 (sec 2.8.2) specify that CKA_VALUE_LEN must *not* be given when unwrapping an AES key. However, sections 2.8.4 and 2.8.5 (ECB and CBC unwrapping using AES) both say that: For unwrapping, the mechanism decrypts the wrapped key, and truncates the result according to the *CKA_KEY_TYPE* attribute of the template and, if it has one, and the key type supports it, the *CKA_VALUE_LEN *attribute of the template. Since a 192-bit AES key and a 256 bit AES key would both require two CBC or ECB blocks, I think the CKA_VALUE_LEN *must* be specified in order to be sure that the right object is created. So I propose that (in v2.41) we delete the superscript 6 from CKA_VALUE_LEN in table 48 and replace it with superscript 5. Note that in testing implementations we found a variety of behaviours here, and one case where ambiguity around this allowed us to execute a padding oracle attack on unwrapping that a manufacturer thought they had prevented. Best, *Graham Steel* +33 (0)9 72 42 35 31 http://cryptosense.com