JDK-8293345 : SunPKCS11 provider checks on PKCS11 Mechanism are problematic
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.crypto:pkcs11
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2022-09-02
  • Updated: 2024-11-12
  • Resolved: 2024-05-10
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 17 JDK 21 JDK 23 JDK 8
11.0.27-oracleFixed 17.0.15-oracleFixed 21.0.7-oracleFixed 23 b23Fixed 8u451Fixed
Related Reports
CSR :  
JDK-8329300 - SunPKCS11 provider checks on PKCS11 Mechanism are problematic
Relates :  
JDK-8272643 - Backout JDK-8176837 from 8u312
Relates :  
JDK-8334284 - InvalidKeyException: Unsupported key type: SunPKCS11-SmartCard
Sub Tasks
JDK-8329640 :  
Need to add the allowLegacy configuration attribute to SunPKCS11 provider - Resolved
JDK-8340337 :  
Release Note: the legacy mechanism check in SunPKCS11 provider is enhanced with service type - Resolved
Description
ADDITIONAL SYSTEM INFORMATION :
Windows 10 64 bits / CentOS 7 64 bits

A DESCRIPTION OF THE PROBLEM :
In France, french healthcare professionals use a card to authenticate and sign. 
Since jdk8 322 we have a problem. 
PKCS11 have been disabled : https://bugs.openjdk.org/browse/JDK-8176837

The problem is that the card mechanism is considered legacy and therefore disabled.
This check needs a little more flexibility.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
SunPKCS11 loading ---DummyConfig-1---
Information for provider SunPKCS11-VitCo-0
Library info:
  cryptokiVersion: 2.20
  manufacturerID: ANS                             
  flags: 0
  libraryDescription: CPS3 PKCS#11 WIN 64             
  libraryVersion: 2.13
sunpkcs11: Initializing PKCS#11 library C:\Windows\System32\cps3_pkcs11_w64.dll
All slots: 0, 1
Slots with tokens: 0
Slot info for slot 0:
  slotDescription: KAPELSE 00026351 KAP-LINK 0 0                                   
  manufacturerID:                                 
  flags: CKF_TOKEN_PRESENT | CKF_REMOVABLE_DEVICE | CKF_HW_SLOT
  hardwareVersion: 0.00
  firmwareVersion: 0.00
Token info for token in slot 0:
  label: CPS3v3-2800638708               
  manufacturerID: ASIP SANTE                      
  model: IAS ECC         
  serialNumber: 99231175        
  flags: CKF_RNG | CKF_LOGIN_REQUIRED | CKF_USER_PIN_INITIALIZED | CKF_TOKEN_INITIALIZED
  ulMaxSessionCount: CK_EFFECTIVELY_INFINITE
  ulSessionCount: 0
  ulMaxRwSessionCount: CK_EFFECTIVELY_INFINITE
  ulRwSessionCount: 0
  ulMaxPinLen: 4
  ulMinPinLen: 4
  ulTotalPublicMemory: CK_UNAVAILABLE_INFORMATION
  ulFreePublicMemory: CK_UNAVAILABLE_INFORMATION
  ulTotalPrivateMemory: CK_UNAVAILABLE_INFORMATION
  ulFreePrivateMemory: CK_UNAVAILABLE_INFORMATION
  hardwareVersion: 0.00
  firmwareVersion: 0.00
  utcTime:                 
Mechanism CKM_SHA_1:
  ulMinKeySize: 0
  ulMaxKeySize: 0
  flags: 1024 = CKF_DIGEST
Mechanism CKM_SHA256:
  ulMinKeySize: 0
  ulMaxKeySize: 0
  flags: 1024 = CKF_DIGEST
Mechanism CKM_RSA_X_509:
  ulMinKeySize: 512
  ulMaxKeySize: 2048
  flags: 272897 = CKF_HW | CKF_DECRYPT | CKF_SIGN | CKF_VERIFY | CKF_UNWRAP
DISABLED due to legacy
Mechanism CKM_RSA_PKCS:
  ulMinKeySize: 512
  ulMaxKeySize: 2048
  flags: 272897 = CKF_HW | CKF_DECRYPT | CKF_SIGN | CKF_VERIFY | CKF_UNWRAP
DISABLED due to legacy
Mechanism CKM_SHA1_RSA_PKCS:
  ulMinKeySize: 512
  ulMaxKeySize: 2048
  flags: 10240 = CKF_SIGN | CKF_VERIFY
Mechanism CKM_SHA256_RSA_PKCS:
  ulMinKeySize: 512
  ulMaxKeySize: 2048
  flags: 10240 = CKF_SIGN | CKF_VERIFY
DISABLED in configuration
sunpkcs11: login succeeded
sunpkcs11: user already logged in

ACTUAL -
javax.net.ssl.SSLException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_KEY_TYPE_INCONSISTENT
	at org.apache.hc.core5.reactor.ssl.SSLIOSession.convert(SSLIOSession.java:265)
	at org.apache.hc.core5.reactor.ssl.SSLIOSession.doWrap(SSLIOSession.java:272)
	at org.apache.hc.core5.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:319)
	at org.apache.hc.core5.reactor.ssl.SSLIOSession.access$300(SSLIOSession.java:71)
	at org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:175)
	at org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:124)
	at org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
	at org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:179)
	at org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:128)
	at org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:85)
	at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
	at java.lang.Thread.run(Thread.java:750)
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_KEY_TYPE_INCONSISTENT
	at sun.security.pkcs11.wrapper.PKCS11.C_SignFinal(Native Method)
	at sun.security.pkcs11.P11Signature.engineSign(P11Signature.java:608)
	at java.security.Signature$Delegate.engineSign(Signature.java:1382)
	at java.security.Signature.sign(Signature.java:698)
	at sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.<init>(CertificateVerify.java:609)
	at sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:761)
	at sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:421)
	at sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:182)
	at sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:377)
	at sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
	at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:981)
	at sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:968)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:915)
	at org.apache.hc.core5.reactor.ssl.SSLIOSession.doRunTask(SSLIOSession.java:288)
	at org.apache.hc.core5.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:362)
	... 9 common frames omitted

FREQUENCY : always
Comments
Well, without JDK-8176837 (introducing the legacy mechanism check), this particular provider which supports sign/verify/decrypt but not encrypt may cause problems - apps which attempt to use its Cipher impl to encrypt will error out. So, JDK-8176837 at least prevent this problem. Thus, this is certainly relates to JDK-8176837 but not too sure to call this a regression of JDK-8176837 as it doesn't quite work without JDK-8176837 in terms of Cipher. But it's true that the Signature impl become unavailable to users after JDK-8176837. As for Bug vs RFE, it's somewhat gray for this particular issue. I can see the argument for both sides.
13-09-2024
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/18387 Date: 2024-03-20 02:44:19 +0000
24-07-2024
Changeset: 1b476f52 Author: Valerie Peng <valeriep@openjdk.org> Date: 2024-05-10 16:53:27 +0000 URL: https://git.openjdk.org/jdk/commit/1b476f52ba85f9ceaabe785d36cb07df831fd0e8
10-05-2024
[~mullan] Yes, will do. Already mentioned about the doc changes in the CSR.
04-04-2024
[~valeriep] I think you should also file a docs subtask to document the "disableLegacy" attribute in the PKCS#11 reference guide: https://docs.oracle.com/en/java/javase/22/security/pkcs11-reference-guide1.html#GUID-C4ABFACB-B2C9-4E71-A313-79F881488BB9
26-03-2024
The particular LEGACY mechanisms supports sign/verify/decrypt but not encrypt. For this particular scenario, it can be addressed by enhancing the check basing on the type of service, e.g. disable Cipher if not supporting encrypt, Signature if not supporting sign. However, if applications still needs to use the LEGACY mechanisms for decryption or verification, then we may have to provider additional means to skip the LEGACY check and allow LEGACY mechanisms to be used (e.g. configuration option disableLegacy w/ default value: true)
14-03-2024
Additional Information from submitter: ============================ The bug has been turned into enhancement with P4. I'm not really ok with this categorization because it blocks all jdk updates for French health professionals. Moreover I think that the original modification is not in accordance with the IAS-ECC standard.
06-09-2022
This issue does not look like a bug but an enhancement. Moved to JDK for further investigations.
05-09-2022