2
$\begingroup$

There appears to be some inconsistencies between the PKCS#11 v2.40 Current Mechanism Specification and the specification for AES Key Wrap Pad as defined in SP800-38F.

First, according to PKCS#11:

The mechanisms will accept an optional mechanism parameter as the Initialization vector which, if present, must be a fixed size array of 8 bytes, and, if NULL, will use the default initial value defined in Section 2.2.3.1 of [AES KEYWRAP].

The type of this parameter is CK_BYTE_PTR and the pointer points to the array of 8 bytes to be used as the initial value. The length shall be either 0 and the pointer NULL, or 8, and the pointer non-NULL.

However, according to SP800-38F, the ICV2 value for AES-Key Wrap PAD must be four bytes in order to correctly pad the input to the cipher routine (section 6.3 algorithm 5).

Secondly, PKCS#11 specifies that CKM_AES_KEY_WRAP_PAD is used for Encryption/Decryption only, not for Wrapping/Unwrapping operations (Table 65, in section 2.14 in the PKCS#11 current mechanism specification). This seems inconsistent with the goals of the AES KEY Wrap Pad algorithm.

So my questions are:

  1. Is this a known inconsistency and has Cryptoki released any updates to how the CKM_AES_KEY_WRAP_PAD algorithm can be used? I cannot find anything on Google but maybe I missed something.
  2. In my PKCS#11 implementation, can my solution be to inform the user (through documentation) that the IV for CKM_AES_KEY_WRAP_PAD will be truncated to 4-bytes?
  3. I know this appears to be out of spec, but can I in my PKCS#11 implementation allow the user to use CKM_AES_KEY_WRAP_PAD for Wrapping/Unwrapping as well as Encryption/Decryption.
Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

The PKCS#11 technical committee is currently working on standard version 3.0. You can find the latest working draft here: https://www.oasis-open.org/committees/download.php/64968/pkcs11-curr-v3.0-wd09.docx

In fact, reworked section "AES Key Wrap" (now 2.16) solves your problems:

  • It allows all mechanisms to be used with Encrypt&Decrypt and Wrap&Unwrap.
  • It clarifies that CKM_AES_KEY_WRAP and CKM_AES_KEY_WRAP_PAD actually refer to NIST SP800-38F section 6.2 ("KW"), which in fact require an 8 byte IV.
  • It introduces new CKM_AES_KEY_WRAP_KWP, which is algorithm KWP of NIST SP800-38F section 6.3 you are looking for.

Header files for the working draft can be found here: https://github.com/oasis-tcs/pkcs11/tree/master/working/3-00-wd-01

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks for the answer! v3.0 definitely clarifies those mechanisms. However, it does appear that they changed the meaning of CKM_AES_KEY_WRAP_PAD between v2.40 and v3.0. In 2.4, CKM_AES_KEY_WRAP_PAD refers to RFC5649 which is the KWP in SP800-38F, however they change it in v3.0 to be regular KW with PKCS#7 padding. I think in the end what I'll have to do is be non-compliant with 2.40 in regards to KWP (CKM_AES_KEY_WRAP_PAD) and note it in user documentation. Again, appreciate the answer! $\endgroup$
    – Mike
    Commented Apr 11, 2019 at 11:51
  • 2
    $\begingroup$ CKM_AES_KEY_WRAP_PAD is defined section 2.14 of the v2.40 mechanisms specification. There is no reference to RFC5649 there. In fact, there is no reference to any standard there as implementation guidance... When talking about the IV "Section 2.2.3.1 of [AES KEYWRAP]" is referenced - which does not exist any more or does not have this section. It COULD be RFC3394. Then, it's the same as today. RFC5649 is mentioned when CKM_AES_KEY_WRAP_PAD is applied in other sections - but this is not normative for this mechanism. Overall, v2.40 was really broken here... $\endgroup$
    – dannyM
    Commented Jan 28, 2020 at 13:02

Your Answer

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

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