JDK-8226650 : PKCS11.C_EncryptInit does not forward the CK_GCM_PARAMS correctly
  • Type: Bug
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: 13
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86_64
  • Submitted: 2019-06-23
  • Updated: 2023-12-12
  • Resolved: 2019-08-15
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 14
14Resolved
Related Reports
Duplicate :  
Description
A DESCRIPTION OF THE PROBLEM :
Tested OpenJDK 13 EA with SoftHSM2 v2.5.1 (current development version). Calling PKCS11.C_EncryptInit ends always with the error CKR_ARGUMENTS_BAD. The following code block in SoftHSM.cpp is responsible for this error:

		case CKM_AES_GCM:
			algo = SymAlgo::AES;
			mode = SymMode::GCM;
			if (pMechanism->pParameter == NULL_PTR ||
			    pMechanism->ulParameterLen != sizeof(CK_GCM_PARAMS))
			{
				DEBUG_MSG("GCM mode requires parameters");
				return CKR_ARGUMENTS_BAD;
			}

It seems that PKCS11.C_EncryptInit() does not forward the CK_GCM_PARAMS correctly to the underlying Cryptoki library.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
No error.
ACTUAL -
Got error sun.security.pkcs11.wrapper.PKCS11Exception: CKR_ARGUMENTS_BAD

---------- BEGIN SOURCE ----------
  public static void main(String[] args) {
    try {
      final String pkcs11ModuleName = "/usr/local/lib/softhsm/libsofthsm2.so";
      final String functionList = "C_GetFunctionList";
      final boolean omitInitialize = false;
      PKCS11 pkcs11Module = PKCS11.getInstance(pkcs11ModuleName, functionList,
            null, omitInitialize);
      long slotId = pkcs11Module.C_GetSlotList(true)[0];
      
      //final long CKF_RW_SESSION     = 0x00000002L;
      //final long CKF_SERIAL_SESSION = 0x00000004L;
      long flags = PKCS11Constants.CKF_SERIAL_SESSION | PKCS11Constants.CKF_RW_SESSION;
      long hSession = pkcs11Module.C_OpenSession(slotId, flags, null, null);
      char[] pin = "123456".toCharArray();
      pkcs11Module.C_Login(hSession, PKCS11Constants.CKU_USER, pin);

      // generate an AES key
      CK_MECHANISM pMechanism = new CK_MECHANISM(PKCS11Constants.CKM_AES_KEY_GEN);
      List<CK_ATTRIBUTE> attrs = new LinkedList<>();
      attrs.add(new CK_ATTRIBUTE(PKCS11Constants.CKA_CLASS, PKCS11Constants.CKO_SECRET_KEY));
      attrs.add(new CK_ATTRIBUTE(PKCS11Constants.CKA_KEY_TYPE, PKCS11Constants.CKK_AES));
      attrs.add(new CK_ATTRIBUTE(PKCS11Constants.CKA_VALUE_LEN, 16));
      attrs.add(new CK_ATTRIBUTE(PKCS11Constants.CKA_SENSITIVE, true));
      
      long hKey = pkcs11Module.C_GenerateKey(
                    hSession, pMechanism, attrs.toArray(new CK_ATTRIBUTE[0]));
      
      byte[] iv = new byte[12];
      new SecureRandom().nextBytes(iv);
      byte[] aad = "hello".getBytes();
      CK_GCM_PARAMS params = new CK_GCM_PARAMS(128, iv, aad);
      pMechanism = new CK_MECHANISM(PKCS11Constants.CKM_AES_GCM, params);
      
      pkcs11Module.C_EncryptInit(hSession, pMechanism, hKey);
    } catch (Exception ex) {
      ex.printStackTrace();
    }
  }
---------- END SOURCE ----------

FREQUENCY : always



Comments
JDK-8229243
15-08-2019

Closing this as duplicate of JDK-8229243 as both have the same root cause, i.e. GCM parameter struct inconsistency. I expanded the checking on returned error code for that fix so the re-try would happen for this SoftHSM2 library also.
15-08-2019

see JDK-8229243 also. I think we need a fix.
09-08-2019

Thought about this some more, one possible solution is to retry with a structure containing ulIvBits when init call failed with CKR_ARGUMENTS_BAD or CKR_MECHANISM_PARAM_INVALID. If the submitter is willing to try out the patch, I can re-open this issue.
17-07-2019

I don't see how having two different typedefs with the same name would solve the issue. Using the structure containing ulIvBits will cause error with NSS as well. Perhaps the submitter can contact SoftHSM to fix it on their end and be consistent with the specification version.
03-07-2019

Additional information from submitter: I saw the issue will be not fixed since the error cannot be reproduced. However, the argument there cannot convince me. After further analysis, the root cause is that the definition of CK_GCM_PARAMS in the official header file pkcs11t.h and in the descriptive specification conflicts. Since the header file is also normative part, it is unclear which definition is correct. Some vendors may choose the one from descriptive specification (like NSS), and some may choose the one from the header file (like SoftHSM). At least, the JDK should implement two CK_GCM_PARAMS classes, one for the definition with "CK_ULONG ulIvBits" (as in header file pkcs11t.h) typedef struct CK_GCM_PARAMS { CK_BYTE_PTR pIv; CK_ULONG ulIvLen; CK_ULONG ulIvBits; CK_BYTE_PTR pAAD; CK_ULONG ulAADLen; CK_ULONG ulTagBits; } CK_GCM_PARAMS; and one for the definition without "CK_ULONG ulIvBits" (as in the descriptive specification) typedef struct CK_GCM_PARAMS { CK_BYTE_PTR pIv; CK_ULONG ulIvLen; CK_BYTE_PTR pAAD; CK_ULONG ulAADLen; CK_ULONG ulTagBits; } CK_GCM_PARAMS; Here is also issue discussing this topic: https://github.com/Pkcs11Interop/Pkcs11Interop/issues/126
01-07-2019

I cannot reproduce the issue. Test with NSS using 12-byte iv, 128-bit tag length and the 5-byte aad works fine and there isn't any error. Verified the returned cipher text against SunJCE provider and also got back the correct plain text. Closing this as non-reproducible. It'd be nice that the test code is not using internal PKCS11 APIs.
28-06-2019