JDK-8255409 : Support the new C_GetInterfaceList, C_GetInterface, and C_SessionCancel APIs in PKCS#11 v3.0
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2020-10-26
  • Updated: 2024-04-12
  • Resolved: 2021-12-08
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 18 JDK 19
18 b28Fixed 19Fixed
Related Reports
Relates :  
JDK-8244154 - Update SunPKCS11 provider with PKCS11 v3.0 header files
Relates :  
JDK-8330133 - libj2pkcs11.so crashes on some pkcs#11 v3.0 libraries
Relates :  
JDK-8328785 - IOException: Symbol not found: C_GetInterface for PKCS11 interface prior to V3.0
Sub Tasks
JDK-8278622 :  
Release Note: SunPKCS11 Provider Now Supports Some PKCS#11 v3.0 APIs - Closed
Description
Comparing to v2.40, PKCS#11 v3.0 added new APIs:
    C_GetInterfaceList
    C_GetInterface
    C_LoginUser
    C_SessionCancel
    C_MessageXXXInit, C_XXXMessage, C_XXXMessageBegin, C_XXXMessageNext, C_MessageXXXFinal where XXX can be Encrypt, Decrypt, Sign, Verify
Comments
Changeset: 83e6a4c0 Author: Valerie Peng <valeriep@openjdk.org> Date: 2021-12-08 23:04:15 +0000 URL: https://git.openjdk.java.net/jdk/commit/83e6a4c0e9e4a9474ae0c1252378b1a09d1d2df0
08-12-2021
Given that RPD1 is approaching, need to trim back on the changes. For this particular RFE, will cover the new APIs which does not require CSR nor new APIs and have been tested. To be specific: C_GetInterfaceList (when native DEBUG flag is set) C_GetInterface C_SessionCancel
01-12-2021
As for CHACHA20-POLY1305, its message parameter structure CK_SALSA20_CHACHA20_POLY1305_MSG_PARAMS also contains fields for both nonce (i.e. iv) and tag. Unless java API has separate APIs for set/get tag bytes, it is quite awkward to fit this new PKCS#11 message-based calling sequence under current javax,crypto.Cipher APIs.
30-10-2021
C_GetInterfaceList: can be used to query PKCS11 library for their supported list of PKCS#11 interfaces C_GetInterface: can be used to access the particular PKCS#11 interface based on the interface name and version if supplied. As for C_MessageXXXInit, C_XXXMessage, C_XXXMessageBegin, C_XXXMessageNext, C_MessageXXXFinal where XXX can be Encrypt, Decrypt, Sign, Verify, PKCS#11 documented the behavior for only these mechanisms, i.e. CKM_AES_GCM, CKM_AES_CCM, CKM_CHACHA20_POLY1305 or CKM_SALSA20_POLY1305. The main differences are - the tag may be returned separately and not part of the cipher text (see CK_GCM_MESSAGE_PARAMS structure and its fields "pTag" and "ulTagBits") - IV can be automatically generated and changed based on the additional field in the particular message parameters. Existing java API does not support this. C_SessionCancel can be used to terminate active sessions. However, it may not be supported by the underlying PKCS#11 library and its usage pattern seems a bit complicated, i.e.must set the flags to match an operation which has been initialized. So, how useful it is will depend on whether it's widely supported and impl correctness. C_LoginUser: for logging a user into a token. Comparing to C_Login(), this takes an additional user name argument. Again, need to check how widely supported it is.
28-10-2021
When trying against NSS 3.57, only two mechanisms, i.e. CKM_AES_GCM and CKM_CHACHA20_POLY1305, supports CKF_MESSAGE_ENCRYPT | CKF_MESSAGE_DECRYPT. No other mechanisms support CKF_MESSAGE_[SIGN/VERIFY]. PKCS#11 defines message-specific parameters for GCM and CCM which include tag field which is an output for encryption and input for decryption. This does not fit well with existing javax.crypto.Cipher API which tag is not supplied/returned separately from the plain text/cipher text. In addition, both GCM and CCM message-specific parameters support generator functions for IV and nonce, i.e. CKG_NO_GENERATE means the IV is passed in on MessageEncrypt and no internal IV generation is done. CKG_GENERATE means that the non-fixed portion of the IV is generated by the module internally. The generation method is not defined. CKG_GENERATE_COUNTER means that the non-fixed portion of the IV is generated by the module internally by use of an incrementing counter. CKG_GENERATE_RANDOM means that the non-fixed portion of the IV is generated by the module internally using a PRNG. In any case the entire IV, including the fixed portion, is returned in pIV. This also does not work well with existing SunPKCS11 JNI impl where the input values are short-lived, i.e. convert from java objects, passed to C calls, and then discard. However, the generator function requires the native IV buffer be kept through all operations. Also existing calls would need to keep querying the parameters whenever the IV values changed.
27-10-2021
Will need to add additional configuration options for C_GetInterface(...) calls in order to get the right one out of all supported interfaces. May need additional time than 17.
24-03-2021