Programming Practices

Read these guidelines to ensure that you correctly reference the FIPS-compliant algorithms in your code.

Note:

The IBMJCEPlusFIPS and IBMJCEFIPS FIPS 140-2 cryptographic providers should be considered deprecated technology on platforms where FIPS 140-3 will be made available. Once the FIPS 140-3 IBMJCEPlusFIPS cryptographic provider is fully supported for production use, the FIPS 140-2 cryptographic providers on those platforms will be subject to removal in the future. All products and customers will need to move to the new FIPS 140-3 IBMJCEPlusFIPS provider for their FIPS certified cryptography.
The FIPS 140-2 cryptographic module certification for the IBMJCEFIPS provider, as documented in Cryptographic Module Validation Program CMVP, Certificate #2715, expired on 21 August 2021 and will not be renewed. The ibmjcefips.jar file will remain part of the SDK however you should upgrade to service refresh 7 or later and use the IBMJCEPlusFIPS JCE cryptographic provider to achieve FIPS 140-2 compliance of applications in future. (The IBMJCEPlusFIPS provider was added in service refresh 6, fix pack 10 but was signed with the SHA256withRSA signature algorithm in service refresh 7, for enhanced security.)

The FIPS JCE v1.1 provider was based on the non-FIPS JCE provider and provided only the FIPS-compliant algorithms. Later providers are also based on the non-FIPS IBM JCE provider but do contain non-FIPS approved algorithms. You must ensure that your application uses only the FIPS approved algorithms if you must comply with FIPS 140-2. Follow these guidelines:

If your application does not require the non-FIPS JCE provider, remove that provider from the java.security file provider list.
If you cannot remove the non-FIPS JCE provider from the provider list because it is required for functions such as Keystore, place the FIPS provider before the non-FIPS provider in the list.
To ensure that your application is requesting a FIPS algorithm, specify the provider name in every getInstance call.

See these examples:

//Create a DSA with SHA1 signature using the java.security provider list
Signature sig = Signature.getInstance("SHA1withDSA");

//Create a DSA with SHA1 signature specifying the non-FIPS IBMJCE explicitly
Signature sig = Signature.getInstance("SHA1withDSA", "IBMJCE");

//Create a DSA with SHA1 signature specifying the FIPS IBMJCE explicitly
Signature sig = Signature.getInstance("SHA1withDSA", "IBMJCEFIPS");

This process is the same for any other class that is obtained using a getInstance call. For a list of the algorithms used with each version of the IBMJCEFIPS provider, see IBM JCE FIPS v1.8 algorithms and the Security Policy documentation on the Computer Security Resource Center website, as linked to in IBM JCE FIPS 140-2 Cryptographic Module Security Policy.

Each cryptographic object must be unique and accessible only by an individual user. Therefore do not use static objects, because all users of the VM share these objects. Static objects are shared in the Java architecture and the creation of a static object would be counter to the unique object method of controlling access and data.

In order to stay FIPS-compliant, an application must use only the FIPS providers and the FIPS approved algorithms. Mixing non-FIPS and FIPS providers causes non-compliance.

The same is true for keys. Keys should be created by a FIPS-approved provider to be used by a FIPS-approved provider. However, the FIPS-generated keys can be used by the non-FIPS providers. Because the physical boundary of the cryptographic module is the whole computer, the keys generated by the FIPS provider are not encrypted. It is up to the application to wrap these keys if the keys are to be exported off the generating computer. Also, the IBM JCE FIPS provider does not contain a keystore. You must decide how to store the keys. The keys created by this provider are still within the physical boundary of the computer and, therefore, the keys do not have to be encrypted unless they are to be moved off the computer. This physical boundary allows the non-FIPS IBM JCE provider keystores to be used to store these keys.

Other notable programming practices are listed in the Security Policy document mentioned previously.