JDK-8213008 : Cipher with UNWRAP_MODE should support the generation of an AES key type
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: 8u162,11,13
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_10
  • CPU: x86_64
  • Submitted: 2018-10-18
  • Updated: 2019-11-16
  • Resolved: 2019-03-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13
11.0.6-oracleFixed 13 b12Fixed
Related Reports
Duplicate :  
Description
ADDITIONAL SYSTEM INFORMATION :
Windows 10 64 bits.
jdk1.8.0_162.

A DESCRIPTION OF THE PROBLEM :
We are working with a Luna HSM from SafeNet/Gemalto and we need do an unwrap of an AES key that was wrapped by a RSA public key. For this purpose we were intend to use the SunPKCS11 provider.

Looking at the documentation of SunPKCS11 we see that the algorithm CKK_AES is supported and, in fact, we succeded to use it to generate secrets key and store then in HSM. However, when trying to use it with the unwrap method of javax.crypto.Cipher the parameter wrappedKeyAlgorithm it seems to be ignored and the key is generated with CKA_KEY_TYPE as CKK_GENERIC_SECRET in HSM. 

The logs generated by the hsm's pkcs11 library shows:
18:04:14 13008-2744:STRTUnwrapKey {Sesn=1 Mech=(CKM_RSA_PKCS,"") Obj=63 "2604ab458734727ee6f..." AttrList={CKA_CLASS="04000000" CKA_KEY_TYPE="10000000" } }

The code is pretty simple:
Cipher cipher = Cipher.getInstance("RSA/ECB/PKCS1Padding", provider);
cipher.init(Cipher.UNWRAP_MODE, privateKey);
Key keyUnwrapped = cipher.unwrap(wrappedContent, "AES", Cipher.SECRET_KEY);

Is this the expected behavior when using the unwrap method with SunPKCS11 provider?



FREQUENCY : always



Comments
Fix request (11u) Downport for parity with 11.0.6-oracle. Fix applies cleanly.
14-11-2019

Add noreg-other label since the existing PKCS11 library used by the regression tests does not reject CKK_GENERIC_SECRET keys, and thus we can't reproduce this vendor-specific behavior.
06-03-2019

Ok, I have raised this to P3.
20-11-2018

Additional information by submitter: Thank you for comment. The problem is that it's impossible to use SunPKCS11 library to do an unwrap directly inside the HSM because the object created is a key that don't have the expected type and we can't use the object afterwards to do cipher and decipher operations because it isn't an AES but a generic secret key.
16-11-2018

The current PKCS11 provider impl always use CKK_GENERIC_SECRET when calling native PKCS11 library. The algorithm is kept and checked at java level. It seems reasonable to fine tune it further and use algorithm specific key type, i.e. CKK_AES when AES is specified. However, besides being too general and not algorithm-specific, is this causing any unexpected failure? If not, the priority of this will probably be low.
09-11-2018