4
$\begingroup$

In PKCS11 specification v2.40, we see some confusion with CKA_VALUE_LEN attribute and UnwrapKey behavior.

From PKCS11 spec 2.40 section 2.8.2,

enter image description here

2 -> MUST not be specified when object is created with C_CreateObject.

3 -> MUST be specified when object is generated with C_GenerateKey or C_GenerateKeyPair.

6 -> MUST not be specified when object is unwrapped with C_UnwrapKey.

In the AES-ECB and AES-CBC, spec tells to pass CKA_VALUE_LEN (section 2.8.4),

enter image description here

So what is expected from application? Do the applications need to pass CKA_VALUE_LEN during unwrap?

NOTE: Even PKCS11 spec 3.0 is also saying the same thing.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
3
$\begingroup$

Yes, I think that's sufficiently unclear to ask for clarification of the authors of the document, and it probably needs fixing.

However, what I do know is that the key size is definitely clear from the wrapped key itself. So there is definitely no need to specify CKA_VALUE_LEN during the call to C_UnwrapKey. There is no need to check it either; I'd be more worried about the value of the key then the size of the key if the key can be altered somehow.

What is possibly meant is that the key size of the wrapped key is determined using CKA_VALUE_LEN during key generation. Because in that case the type by itself doesn't specify the output length, i.e. the size of the key being unwrapped.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks for the answer, the problem is for AES-ECB/AES-CBC(no pad), in case of C_Wrap spec says to do zero pad for non-blocked size. If zero padding is done in wrap, in unwrap we must know the size of the key, otherwise we don't know whether the data is zero padded or data itself has zero data at the end. Just pointing the spec section 2.8.4, "For wrapping, the mechanism encrypts the value of the CKA_VALUE attribute of the key that is wrapped, padded on the trailing end with up to block size minus one null bytes so that the resulting length is a multiple of the block size." $\endgroup$
    – Brahmaji Kommanaboyina
    Nov 6, 2020 at 18:22
  • $\begingroup$ Hmm, oh yeah, I forgot about the zero padding. For some keys that may indeed be a problem. In the case of public / private keys the application can establish this from context (ASN.1 DER). So in that case I'd just supply the length with symmetric keys 'cause they are unstructured. $\endgroup$
    – Maarten Bodewes ♦
    Nov 7, 2020 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.