CKM_AES_KEY_WRAP_KWP ignores the supplied mechanism parameters
Categories
(NSS :: Libraries, defect, P5)
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.
Comment 1•4 years ago
|
||
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?
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
yeah, I believe that's a good idea.
Description
•