FIPS 140 Compliant Mode for SunJSSE


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:
  1. edit the file ${java.home}/lib/security/java.security and modify the line that lists com.sun.net.ssl.internal.ssl.Provider to list the provider name of the FIPS 140 certified cryptographic provider. For example if the name of the cryptographic provider is SunPKCS11-NSS, change the line from
      security.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.security file.
  2. at runtime, call the constructor of the SunJSSE provider that takes a java.security.Provider object as a parameter. For example, if the variablecryptoProvider is a reference to the cryptographic provider, call new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider).
  3. at runtime, call the constructor of the SunJSSE provider that takes a String object as a parameter. For example if the cryptographic provider is calledSunPKCS11-NSS call new 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_SHA0x000a
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA0x0016
TLS_RSA_WITH_AES_128_CBC_SHA0x002f
TLS_DHE_DSS_WITH_AES_128_CBC_SHA0x0032
TLS_DHE_RSA_WITH_AES_128_CBC_SHA0x0033
TLS_RSA_WITH_AES_256_CBC_SHA0x0035
TLS_DHE_DSS_WITH_AES_256_CBC_SHA0x0038
TLS_DHE_RSA_WITH_AES_256_CBC_SHA0x0039
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA0xC003
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA0xC004
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA0xC005
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA0xC008
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA0xC009
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA0xC00A
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA0xC00D
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA0xC00E
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA0xC00F
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA0xC012
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA0xC013
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA0xC014
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA0xC017
TLS_ECDH_anon_WITH_AES_128_CBC_SHA0xC018
TLS_ECDH_anon_WITH_AES_256_CBC_SHA0xC019

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. 

 Linkage to the blog entry at blogs.sun.com

Popular posts from this blog

TLS Server Name Indication Extension and Unrecognized_name

Image
Heavy Pond, Jianfengling National Forest Park, Ledong, Hainan, China It's getting hot that some TLS/HTTPS server failed with "unrecognized_name". For example, the Adobe AIR 3 Code Signing Certificate Problem , the ADT handshake alert , and the jarsigner issue with timestamp.geotrust.com , etc. This entry will discussion some background of the "unrecognized_name" alert, and the TLS Server Name Indication (SNI) extension. Background "Unrecognized_name" is an error alert, define by RFC4366 .  In section 4 of RFC4366 : - "unrecognized_name": this alert is sent by servers that receive a server_name extension request, but do not recognize the server name. This message MAY be fatal. And in section 3.1 of of RFC4366 : If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal). From above sections, we see that "unrecognized...
Read more

Java™ SE 7 Release Security Enhancements - Weak Cryptography Control

Weak cryptographic algorithms can now be disabled in Java SE 7 release. The MD2 Message-Digest Algorithm was disabled by default in Sun PKIX provider and SunJSSE provider. The MD2 algorithm is a cryptographic hash function developed by Ronald Rivest in 1989 , and was published in 1992 as an Informational RFC (RFC 1319) .; RFC 6149 moves RFC 1319/MD2 to historic status, "Since its publication, MD2 has been shown to not be collision-free, albeit successful collision attacks for properly implemented MD2 are not that damaging. Successful pre-image and second pre-image attacks against MD2 have been shown." Although MD2 is no longer considered secure, it remains in use in public key infrastructures as part of certificates generated with MD2 and RSA. An a countermeasure of the vulnerability, Java SE has disabled MD2 algorithm in certification path building and validation. You may wonder, Java SE has disabled MD2 algorithm in certification path building and validation in ...
Read more

JEP 115: AES-GCM CipherSuites in JDK 8

Image
Chengdu, China RFC 5288 describes the use of AES in Galois Counter Mode ( GCM ) (AES-GCM) with various key exchange mechanisms as a cipher suite for TLS. AES-GCM is an authenticated encryption with associated data (AEAD) cipher (as defined in TLS 1.2 ) providing both confidentiality and data origin authentication. Java SE had already defined the AES-GCM interfaces in Java SE 7 .  In the coming Java SE 8, as an implementation of JEP 115 , AES-GCM algorithms is implemented in SunJCE provider, and AES-GCM cipher suites are implemented in SunJSSE provider. The following SSL/TLS AEAD/GCM cipher suites, in preference order, are enabled by default in SunJSSE provider for TLS version 1.2: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288) TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDH_RSA_WITH_AES_...
Read more