Open Bug 1728419 Opened 4 years ago Updated 4 years ago

CKM_AES_KEY_WRAP_KWP ignores the supplied mechanism parameters

Categories

(NSS :: Libraries, defect, P5)

3.57

Tracking

(Not tracked)

People

(Reporter: ycpeng, Assigned: rrelyea)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36

Steps to reproduce:

When using CKM_AES_KEY_WRAP_KWP mechanism with a 4-byte IV as in PKCS#11 v3.0 current mechanism spec, it seems the supplied IVs are always ignored and the hardcoded default value of "0xA65959A6" is used. If this is the only allowed/supported value, the enc/dec init and wrap call should fail with CKR_MECHANISM_PARAM_INVALID. Otherwise, callers would not know the supplied IV is not used.

Actual results:

Everything, i.e. enc/dec/wrap/unwrap finished successfully but using the default value instead of the user-supplied value. This may lead to confusion and interop problem if other vendors allow/support non-default IVs.

Expected results:

Return CKR_MECHANISM_PARAM_INVALID if the supplied IV is invalid or un-supported.

Thanks for this.

Section 2.16.2 of PKCS #11 says the IV can be provided as a parameter, but that's clearly incompatible with the requirement in Section 2.16.3 which says "Wrapping / encryption is done as defined in Section 6.3 of [AES KEYWRAP]."

Bob, can we return CKR_MECHANISM_PARAM_INVALID here?

Flags: needinfo?(rrelyea)
Severity: -- → S4
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5

yeah, I believe that's a good idea.

Assignee: nobody → rrelyea
Flags: needinfo?(rrelyea)
You need to log in before you can comment on or make changes to this bug.