In the Java™ 6 Security Enhancements, it says that "The SunJSSE provider now supports an experimental FIPS 140 compliant mode. When enabled and used in combination with the SunPKCS11 provider and an appropriate FIPS 140 certified PKCS#11 token, SunJSSE is FIPS 140 compliant." Except that, we cannot find any more document on how to enable FIPS mode and how the FIPS mode works with SunJSSE. Normally, developers could a few hints from Andreas blog,. The Java PKCS#11 Provider and NSS, althought it is far from enough to understand the FIPS mode of SunJSSE. The following is a unpublished document, hope it helps.
FIPS 140 Compliant Mode for SunJSSE
In Sun's Java SE implementation version 6 or later, the SunJSSE provider, which contains the SSL/TLS implementation, can be configured to operate in a FIPS 140 compliant mode instead of its default mode. This document describes the FIPS 140 compliant mode (subsequently called "FIPS mode").
Configuring SunJSSE for FIPS Mode
SunJSSE is configured in FIPS mode by associating it with an appropriate FIPS 140 certified cryptographic provider that supplies the implementations for all cryptographic algorithms required by SunJSSE. This can be done in one of the following ways:
-
edit the file
${java.home}/lib/security/java.securityand modify the line that listscom.sun.net.ssl.internal.ssl.Providerto list the provider name of the FIPS 140 certified cryptographic provider. For example if the name of the cryptographic provider isSunPKCS11-NSS, change the line fromsecurity.provider.4=com.sun.net.ssl.internal.ssl.Provider
to
security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS
The class for the provider of the given name must also be listed as a security provider in the
java.securityfile. -
at runtime, call the constructor of the SunJSSE provider that takes a
java.security.Providerobject as a parameter. For example, if the variablecryptoProvideris a reference to the cryptographic provider, callnew com.sun.net.ssl.internal.ssl.Provider(cryptoProvider). -
at runtime, call the constructor of the SunJSSE provider that takes a String object as a parameter. For example if the cryptographic provider is called
SunPKCS11-NSScallnew com.sun.net.ssl.internal.ssl.Provider("SunPKCS11-NSS"). A provider with the specified name must be one of the configured security providers.
Within a given Java process, SunJSSE can be used either in FIPS mode or in default mode, but not both at the same time. Once SunJSSE has been initialized, it is not possible to change the mode. This means that if one of the runtime configuration options is used (option 2 or 3), the configuration must take place before any SSL/TLS operation.
Note that only the specified configured provider will be used by the SunJSSE for any and all cryptographic operations. All other cryptographic providers including those included with the Java SE implementation will be ignored and not used.
Difference Between FIPS Mode and Default Mode
In FIPS mode, SunJSSE behaves in a way identical to default mode, except for the following differences.
In FIPS mode:
-
SunJSSE will perform all cryptographic operations using the cryptographic provider that was configured as described above. This includes symmetric and asymmetric encryption, signature generation and verification, message digests and message authentication codes, key generation and key derivation, random number generation, etc.
-
If the configured cryptographic provider reports any error by throwing an exception, SunJSSE will abort the current operation and propagate the exception to the application.
-
If the configured cryptographic provider believes it had a critical error such as a self test failure per FIPS guidelines, it needs to remain in an error state until it is re-initialized. The application using the SunJSSE configured with the FIPS cryptographic module will have to be restarted. This ensures that the FIPS module will not allow critical errors to compromise security.
-
Only TLS 1.0 and later can be used. SSL 2.0 and SSL 3.0 are not available. Any attempt to enable SSL 2.0 or 3.0 will fail with an exception.
-
The list of ciphersuites is limited to those that utilize appropriate algorithms. The current list of possible ciphersuites is given below. Any attempt to enable a ciphersuite not on the list will fail with an exception.
Ciphersuites Usable in FIPS Mode
The following is the current list of ciphersuites which can be used by
SunJSSE in FIPS mode with their names and the id as assigned in the TLS
protocol provided that the configured cryptographic FIPS module supports the
necessary algorithms. Note that although SunJSSE uses the prefix
SSL_ in the name of some of these ciphersuites, this is for
compatibility with earlier versions of the specification only. In FIPS mode,
SunJSSE will always use TLS 1.0 or later and implement the ciphersuites as
required by those specifications.
-
SSL_RSA_WITH_3DES_EDE_CBC_SHA
0x000a
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
0x0016
TLS_RSA_WITH_AES_128_CBC_SHA
0x002f
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0x0032
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0x0033
TLS_RSA_WITH_AES_256_CBC_SHA
0x0035
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
0x0038
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0x0039
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
0xC003
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
0xC004
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
0xC005
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
0xC008
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
0xC009
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
0xC00A
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
0xC00D
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
0xC00E
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
0xC00F
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
0xC012
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
0xC013
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
0xC014
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
0xC017
TLS_ECDH_anon_WITH_AES_128_CBC_SHA
0xC018
TLS_ECDH_anon_WITH_AES_256_CBC_SHA
0xC019
Conclusion
When SunJSSE is configured in FIPS 140 compliant mode together with an appropriate FIPS 140 certified cryptographic provider, for example Network Security Services (NSS) in its FIPS mode, SunJSSE is FIPS 140 compliant.
Regarding the SunJSSE in fips mode, we found that any cipher suite that contains ASE_256 will not be able to run, for example TLS_RSA_WITH_AES_256_CBC_SHA. You can make a simple ssl server test it out. The jdk we are using is 1.6.0.x.
Posted by yanlin wang on August 16, 2009 at 09:55 AM GMT+08:00 #
By the way the unlimited strength policy is applied.
Posted by yanlin wang on August 16, 2009 at 09:57 AM GMT+08:00 #
I'd like to know the details, would you describe the configuration in detail, especially the crypto provider. By my understanding and test, there should be not problem for AES_256 after applying the unlimited crypto strength policy.
Posted by XueLei Fan on September 19, 2009 at 12:04 AM GMT+08:00 #