Bug ID: JDK-8080076 PKCS#11 v2.40 Support for TLSv1.2 feature

Type: New Feature
Component: security-libs
Sub-Component: javax.crypto:pkcs11

Priority: P4
Status: Resolved
Resolution: Duplicate
OS: generic
CPU: generic

Submitted: 2015-05-11
Updated: 2018-08-01
Resolved: 2018-08-01

This is a feature tracking regarding availability of TLSv1.2 support by SunPKCS11 provider.

IoT Cloud Service does support and enforce TLSv1.2 while SunPKC11 provider does not allow to redirect TLSv1.2 handshake operations to an hardware token.

Hi Brad, SunPKCS11 provider aims/permits to: 1. have trust stores and Keystores handled by a PKCS11 hardware token so that keys and certificates are protected by the hardware token itself, 2. redirect cryptographic operations to a PKCS11 hardware token while cryptographic keys are coming from outside the hardware token, 3. redirect cryptographic operations to a PKCS11 hardware token while cryptographic keys are coming from inside the hardware token. What you described is related to the point 2. while we are interested on having the point 3. Actually, this is the one which makes sense to people focused on security: performing cryptographic operations within an hardware token while the cryptographic material does not leave the hardware token itself. Everything is in place for TLSv1.0 and TLSv1.1 in SunPKCS11 and now it should be put in place also for TLSv1.2 w/o requiring any calls to SunJCE provider. Here is a comment from SunPKCS11.java: /* * TLS 1.2 uses a different hash algorithm than 1.0/1.1 for the * PRF calculations. As of 2010, there is no PKCS11-level * support for TLS 1.2 PRF calculations, and no known OS's have * an internal variant we could use. Therefore for TLS 1.2, we * are updating JSSE to request different provider algorithms * (e.g. "SunTls12Prf"), and currently only SunJCE has these * TLS 1.2 algorithms. * * If we reused the names such as "SunTlsPrf", the PKCS11 * providers would need be updated to fail correctly when * presented with the wrong version number (via * Provider.Service.supportsParameters()), and we would also * need to add the appropriate supportsParamters() checks into * KeyGenerators (not currently there). * * In the future, if PKCS11 support is added, we will restructure * this. */ Our request is exactly about the future addition mentioned above. + Further comments inline. Please let me know for any further questions. Thanks in advance, Nicolas On 10/08/2015 23:23, Bradford Wetmore wrote: > > Some people aren't clear that RSA encryption, SHA* digests/signatures, > AES/etc can used in TLSv1.2 today. Just to be clear, our SunJSSE > provider does makes calls to SunPKCS11 for things like > RSA/SHA*/AES/etc when running in TLSv1.2. Would be good if you can let me know the way to achieve this properly. From what I know, "playing" with the java.security config file: - putting the SunPKCS11 provider as the default provider redirects everything to SunPKCS11 which is not what we want - putting the SunPKCS11 provider as the NIST JCE provider for JSSE fails when dealing with TLSv1.2 since dedicated algorithms are not supported.

11-08-2015

Brad Wetmore: Some people aren't clear that RSA encryption, SHA* digests/signatures, AES/etc can used in TLSv1.2 today. Just to be clear, our SunJSSE provider does makes calls to SunPKCS11 for things like RSA/SHA*/AES/etc when running in TLSv1.2. What our SunPKCS provider doesn't currently do is make calls to the TLSv1.2-specific mechanisms such as: http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/cos01/pkcs11-curr-v2.40-cos01.html#_Toc408227088 CKM_TLS12_MASTER_KEY_DERIVE CKM_TLS12_MASTER_KEY_DERIVE_DH CKM_TLS12_KEY_AND_MAC_DERIVE CKM_TLS12_KEY_SAFE_DERIVE CKM_TLS10_MAC_SERVER CKM_TLS10_MAC_CLIENT CKM_TLS12_MAC That's what this RFE is about, but there is a Java-based Sun provider that will handle those calls. Thanks, Brad

11-08-2015

The PKCS#11 Mech Specification v2.40 ( http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html ) lists mechanisms for SSL and TLS 1.2 under section 2.28 and 2.29 respectively: <SSL> The mechanisms are: CKM_SSL3_PRE_MASTER_KEY_GEN CKM_SSL3_MASTER_KEY_DERIVE CKM_SSL3_KEY_AND_MAC_DERIVE CKM_SSL3_MASTER_KEY_DERIVE_DH CKM_SSL3_MD5_MAC CKM_SSL3_SHA1_MAC <TLS> The mechanisms are: CKM_TLS12_MASTER_KEY_DERIVE CKM_TLS12_MASTER_KEY_DERIVE_DH CKM_TLS12_KEY_AND_MAC_DERIVE CKM_TLS12_KEY_SAFE_DERIVE CKM_TLS10_MAC_SERVER CKM_TLS10_MAC_CLIENT CKM_TLS_KDF CKM_TLS12_MAC When using some of these mechanisms, corresponding parameters are needed which would require new classes. For the SSL mechanisms, their corresponding parameters are defined "internally" and had not been made part of public API at the time of implementation. This should probably be addressed and made public along with the new corresponding parameters classes with the newly added support for TLS mechanisms.

10-07-2015