Description of problem:

This bug is to capture the effort to provide AES key wrapping mechanisms (with or without Padding) for HSM (specifically Thales HSM).  We have intention to support LunaSA as well. It is our hope that the eventual fix will work with both modules, but the initial attempt is focusing on Thales.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:

Here are the findings:
We discovered that Thales HSM SW 12.30 does not recognize the definitions defined by the PKCS#11 standard:
CKM_AES_KEY_WRAP 0x2109
CKM_AES_KEY_WRAP_PAD 0x210a
We were told at the time that the SW 12.50 would support it.

Testing with SW 12.50 reveals the following:
AES KeyWrap (NoPadding) yields the following error:
2019-05-07 08:20:41 [5298] t0067d2106c7f0000: pkcs11: 000008CC Application error: Mechanism 0x00002109 (CKM_AES_KEY_WRAP) not supported for wrapping private keys
2019-05-07 08:20:41 [5298] t0067d2106c7f0000: pkcs11: 000008CC <    rv 0x00000070 (CKR_MECHANISM_INVALID)

AES KeyWrap (with Padding) yields the following error:
2019-05-07 08:23:27 [5320] t00472998c37f0000: pkcs11: 000008CC Application error: 0x0000210A (CKM_AES_KEY_WRAP_PAD) not a wrapping mechanism
2019-05-07 08:23:27 [5320] t00472998c37f0000: pkcs11: 000008CC <    rv 0x00000070 (CKR_MECHANISM_INVALID)

According to Thales, the following is the reason why they will not support CKM_AES_KEY_WRAP for private key wrapping.
"
The answer is that the PKCS#11 specification is confused about how the mechanism handles inputs that do not exactly fit into the cipher blocks.  It says both that they should be zero-padded and that they should be rejected.
We don't believe that zero-padding is a good option and so we do not support the mechanism for private keys
"
Also: 
"
CKM_AES_KEY_WRAP_PAD will wrap private keys in V12.60
The AES_CBC and AES_CBC_PAD mechanisms will wrap private keys in V12.50.
Security World 12.60 is schedule for a late May/June release.
"
And:
"
V12.60 phase 1 release supporting windows and linux end of June 2019
V12.60 phase 2 release supporting other unix July 2019
"

Expected results:


Additional info:
Early on, I leaned from Bob Relyea that NSS has its own AES Key wrapping mechanism numbers, which are different from the PKCS#11 standard:
CKM_NSS_AES_KEY_WRAP
CKM_NSS_AES_KEY_WRAP_PAD
While waiting for Thales to respond to my inquiries, I tested out private key wrapping with CKM_NSS_AES_KEY_WRAP and found some odd behavior.  It would fail most of the time with the following error, but it would actually *sometimes work*:
    (-8188) security library has experienced an input length error.
I learned from Bob that "It works only when length is a multiple of the AES block length. In order to correctly wrap a private key with AES key wrap, you need to have the result padded. That's why CKM_NSS_AES_KEY_WRAP_PAD exists."

So the conclusion is to wait for Thales to support CKM_AES_KEY_WRAP_PAD in the next release.

As for now, I think there is no reason to add the PKCS#11 standard while waiting for Thales's new SW version.
Minimum test can still be conducted to at least see that the AES key wrapping mechanisms are recognized on 12.50, v.s. complete ignorance in 12.30.