OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Ambiguity in PKCS#11 when unwrapping an AES key


Dear TC members,

 

We had an internal discussion about the correct usage of the CKA_VALUE_LEN attribute in the unwrap template when unwrapping an AES key with another AES key. The discussion was triggered by call of C_UnwrapKey to unwrap a 192 bit AES key with another 192 bit AES key, where our customer specifies the CKA_VALUE_LEN attribute in the template.

 

The following list summarizes our internal discussions (references to sections and tables refer to PKCS#11 3.0 Current mechanism specification if not mentioned otherwise):

  1. Section 2.10.2, Table 70, AES Secret Key Object Attributes: CKA_VALUE_LEN has footnote 6. Per base specification table 11, footnote 6 means “MUST not be specified when object is unwrapped with C_UnwrapKey”. CKA_VALUE_LEN is thus in invalid attribute in the unwrap template for an AES key, i.e. calling C_UnwrapKey and specifying CKA_VALUE_LEN results in return code CKR_ATTRIBUTE_TYPE_INVALID. But …
  2. Section 2.10.5, lines 2961-2963: “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.” Table 72 states for that the output length for unwrap is “determined by type of key being unwrapped or CKA_VALUE_LEN”. CKK_AES key type supports CKA_VALUE_LEN, and the key type itself does not determine the key length, thus if the unwrap template specifies an attribute CKA_VALUE_LEN it determines the key length and should thus be allowed. This is at least ambiguous compared to footnote 6.
  3. When wrapping an 192 bit AES key with another 192 bit AES key using CKM_AES_CBC, the wrapped key is 192 bit long. When unwrapping the 192 bit wrapped key with an 192 bit AES key, the length of the unwrapped key can be set to 192 bit if no CKA_VALUE_LEN is specified. It is this not really necessary to specify CKA_VALUE_LEN in this specific case (assuming I don’t want to shorten the original 192 bit AES key to 128 bit).
  4. When wrapping an 192 bit AES key with an RSA key using CKM_RSA_X_509 though, the length of the wrapped key will be k bytes (i.e. 256 bytes in case of RSA 2k); and according to  section 2.1.12, table 10 the length of the unwrapped key is “<= k (specified in template)”. The wording “specified in template” contradicts footnote 6 for AES key type because it means that you have to specify CKA_VALUE_LEN. And the unwrapping doesn’t reliably work without CKA_VALUE_LEN because the RSA unwrapping (i.e. decryption) operation will give a result of k bytes of which many are leading zeroes, i.e. it is not reliably possible to know whether a 192 bit AES key was wrapped or a 128 bit key or a 256 bit key (unless you “guess” the AES key size by removing all leading zeroes).

 

What is the understanding of the TC? Should CKA_VALUE_LEN be allowed (at least as optional attribute) or forbidden when unwrapping an AES key?

 

Can we please have this on the agenda of the TC meeting on January 18th.

 

Thanks,

Dieter




Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen – Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managementboard: Stefan Auerbach, Martin Stamm

This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]