SunJSSE and SunPKCS11 (NSS + FIPS)

Xuelei Fan xuelei.fan at oracle.com
Wed Mar 13 14:05:51 UTC 2019


To use FIPS mode JCE provider, an application could:
1. implement the required algorithm in the FIPS mode JCE provider.
2. don't those algorithms that outside the scope of the FIPS mode JCE 
provider (restrict them).

Xuelei

On 3/12/2019 12:56 PM, Martin Balao wrote:
> Hi,
> 
> There is an issue that I'd like to bring here for discussion.
> 
> I've been trying to reproduce a purely-OpenJDK TLS 1.2 exchange between
> a client and server using SunPKCS11 crypto provider -with NSS software
> token configured in FIPS mode-, after JDK-8217835 change [1].
> 
> My 1st preference crypto provider is SunPKCS11 and my 2nd is SUN.
> 
> All my keys for this communication will then be non-extractable P11Key
> keys. This means that we cannot convert them to work with any other
> service from any other provider. Otherwise, FIPS constraints would be
> violated.
> 
> SignatureScheme considers multiple signing algorithms as available when
> there is at least one crypto provider that supports them. As an example,
> "RSASSA-PSS" is listed as available because I have "SUN" crypto provider
> enabled. SunPKCS11 does not currently support "RSASSA-PSS" algorithm.
> Even though it would be pretty easy to support it (CKM_RSA_PKCS_PSS
> mechanism), we may still be in a case in which the underlying SunPKCS11
> library does not implement it or where there is not a mechanism in the
> PKCS#11 latest standard.
> 
> Now, SignatureScheme.getSignature gets called with a P11Key [2]. Inside
> this method, Signature.getInstance(algorithm) will return a SUN service
> provider that cannot work with these P11Key keys.
> 
> Disabling SUN provider is not an option because we need support for
> X.509 certificates.
> 
> My understanding is that the previous experimental FIPS mode in SunJSSE
> provided consistency through a unique underlying crypto provider, used
> across the engine. I believe we still need to support the SunPKCS11 -
> FIPS case, as it's pretty common in enterprises.
> 
> In addition, I'm working towards re-introducing TestTLS12 to JDK. This
> test does not only reproduce this scenario, but has helped to find bugs
> such as JDK-8220513 [3].
> 
> Thoughts?
> 
> Kind regards,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8217835
> [2] -
> http://hg.openjdk.java.net/jdk/jdk/file/daec95ed6795/src/java.base/share/classes/sun/security/ssl/SignatureScheme.java#l469
> [3] - https://bugs.openjdk.java.net/browse/JDK-8220513
> 


More information about the security-dev mailing list