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: Re: [pkcs11] Ambiguity in PKCS#11 when unwrapping an AES key


On 1/6/23 4:06 AM, Dieter Bong wrote:

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).
That's not correct, when wrapping a 192 bit AES key with CKM_AES_CBC the wrapped key will be 256 bits long. AES block size is independent of key size.
  1. 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).
That's correct here. CKM_RSA_X_509 does not define the padding, so the key length is undefined unless it is determined by CKA__VALUE_LEN or the KEY_TYPE

Â

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?

My understanding is CKA_VALUE_LEN is required if the underlying unwrap mechanism does not preserve the length and it can't be determined from the type. So CKM_RSA_X_509, CKM_XXX_CBC, but not CKM_XXX_CBC_PAD, or CKM_RSA_PKCS. We should specify that in the mechanisms.

I'm agnostic about whether it should be optional. If it is optional, it needs to have a 'valid' value (so 156 would be invalid for an AES key, for instance).

Â

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

Yes, my understanding is just my 2 cents and we should lock this (or whatever other semantics we agree on).

Â

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]