FIPS compliance

The content in the following adapters is now Federal Information Processing Standards (FIPS) compliant:

HTTP
Web Services (only for JAX-WS approach Message mode)

Click here fore more information about FIPS

Federal Information Processing Standards (FIPS) are a set of standards that describe document processing, encryption algorithms and other information technology standards for use within non-military government agencies and by government contractors and vendors who work with the agencies.

U.S. government agencies must only purchase security products that have undergone review by the National Institute of Standards (NIST) and received FIPS 140-2 validation. In addition, corporate customers increasingly rely on FIPS validation as an independent review of the security capabilities of the products that they buy. The FIPS validation is also accepted around the world as one of the most trusted security standards.

Why is FIPS validation important?

The FIPS 140-2 validation process gives government and commercial customers an objective assessment that they can use to reliably qualify the security of products, and organizations should not purchase encryption products that have not been FIPS 140-2 validated.

Different levels of FIPS validation

The National Institute of Standards and Technology (NIST) has established several levels of FIPS 140-2 validation. These usually conform to higher levels of security and design integrity.

Level 1: Provides the lowest level of security, used for software encryption products.
Level 2: Improves upon the security mechanisms of Level 1 by requiring tamper evidence. This criteria is for products that do their encryption in the hardware. These products typically offer more security, are harder to break into, and are easier for average users to use without accidentally turning off the encryption.
Level 3: Provides advanced security protection. This criteria is for hardware products, and includes robust cryptographic protection and key management as well as physical protection of the device against dis-assembly. It also requires hardware circuitry that minimizes critical security parameters in the event of physical attack or tampering.
Level 4: Offers the highest level of security, with advanced tamper protection, and is typically designed for products that operate in physically unprotected environments.

Configuring the java.security file

You configure the java.security file if you intend to change the default service provider. To install a provider, you must do the following:

Install the provider package classes by performing one of the following actions:

Copy the zip or JAR file containing the classes in the <jdkInstallDirectory>/jre/lib/ext directory.
Specify the provider JAR file as an "installed" or "bundled" extension.

Add the provider to the list of approved providers by performing the following steps:

Locate the java.security file in the lib/security directory of the SDK. For example, if the SDK is installed in a directory called j2sdk1.2, you would edit the file located at j2sdk1.2/lib/security/java.security.
Set the following property in the java.security file to declare a provider and specify its preference order, n:
security.provider.n=masterClassName
- The preference order is the order in which a provider is searched for in a requested algorithm. The precedence of the preference order is, 1--the most preferred, followed by 2, and so on.
- masterClassName specifies the provider's master class that is always a subclass of the provider class. The provider's documentation specifies its master class.

Examples:

To add the Crypto-J JCE provider, add the following line to the java.security file:
security.provider.<n>=com.rsa.jsafe.provider

To set the Crypto-J JCE provider as the default provider, set <n> to 1. To configure other preferred providers, edit the java.security file so that each provider has a unique number:
security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=sun.security.provider.Sun
security.provider.3=COM.acme.provider.Acme

Sample logs from BMC Atrium Orchestrator Grid Manager

The following log sample lists JsafeJCE as the security provider for the HTTP adapter:

Click here to expand...

02 Feb 2012 18:47:13,957 INFO HttpActorAdapter : perform operation start info log. Adapter request received <httpAdapterRequest>
<allow-unsigned-certificate>true</allow-unsigned-certificate>
<install-certificate>true</install-certificate>
<signature-properties mode="key-files">
   <private-key-file>C:\temp\server.key</private-key-file>
   <certificate-file>C:\temp\server.pem</certificate-file>
</signature-properties>
<action>https://10.128.249.45:8087/api</action>
<enable-json-conversion>true</enable-json-conversion>
<http-connection-properties>
   <Accept>text/json</Accept>
</http-connection-properties>
<data-format>XML</data-format>
<strip-namespace-from-response>true</strip-namespace-from-response>
</httpAdapterRequest> for adapter: http
02 Feb 2012 18:47:13,978 DEBUG HttpActorAdapter : HTTP Request:
<adapter-request>
<target-adapter>AdapterConfiguration1328182973204--670074188</target-adapter>
<peer-location>
   <location>any</location>
</peer-location>
<request-action>get</request-action>
<ttl>4611686018427387903</ttl>
<job-id>dae4cf25f535d3ab:-45305eef:1353d9fae58:-80001-1328188614036</job-id>
<request-data>
   <httpAdapterRequest>
     <allow-unsigned-certificate>true</allow-unsigned-certificate>
     <install-certificate>true</install-certificate>
     <signature-properties mode="key-files">
       <private-key-file>C:\temp\server.key</private-key-file>
       <certificate-file>C:\temp\server.pem</certificate-file>
     </signature-properties>
     <action>https://10.128.249.45:8087/api</action>
     <enable-json-conversion>true</enable-json-conversion>
     <http-connection-properties>
       <Accept>text/json</Accept>
     </http-connection-properties>
     <data-format>XML</data-format>
     <strip-namespace-from-response>true</strip-namespace-from-response>
   </httpAdapterRequest>
</request-data>
</adapter-request>
02 Feb 2012 18:47:13,978 DEBUG HttpActorAdapter : Request URL: https://10.128.249.45:8087/api
02 Feb 2012 18:47:13,978 DEBUG HttpActorAdapter : Protocol in the Request URL: https
02 Feb 2012 18:47:13,979 DEBUG HttpActorAdapter : secureConnection is : true
02 Feb 2012 18:47:13,982 INFO HttpActorAdapter : http: setting up adapter to communicate with 10.128.249.45 on port 8,087
02 Feb 2012 18:47:13,983 DEBUG HTTPUtils       : validating signature properties started
02 Feb 2012 18:47:13,983 DEBUG HTTPUtils       : Mode specified in signature properties : key-files
02 Feb 2012 18:47:13,983 DEBUG HTTPUtils       : PEM File Path : C:\temp\server.pem
02 Feb 2012 18:47:13,984 DEBUG HTTPUtils       : PEM Data ==>>

02 Feb 2012 18:47:13,988 DEBUG HTTPUtils       : DER File Path : C:\somename\Hardening\CDP7602SP3\tomcat\temp\server.DER
02 Feb 2012 18:47:13,994 DEBUG HTTPUtils       : Using keystore-file : C:\\somename\\Hardening\\CDP7602SP3\\tomcat\\temp\bmcaohttpclient_688d603e-b2a5-4d0f-b45e-90fb327a3c0c.jks
02 Feb 2012 18:47:13,997 DEBUG HTTPUtils       : Reading the private key file/data through Native Java API Failed. Trying to read the private key file/data using PEMReader
02 Feb 2012 18:47:13,998 DEBUG HTTPUtils       : Name of selected provider: JsafeJCE
02 Feb 2012 18:47:13,999 DEBUG HTTPUtils       : Info of selected provider: com.rsa.jsafe.provider.JsafeJCE
02 Feb 2012 18:47:14,114 DEBUG HTTPUtils       : One certificate, no chain.
02 Feb 2012 18:47:14,125 DEBUG HTTPUtils       : Key and certificate stored.
02 Feb 2012 18:47:14,125 DEBUG HTTPUtils       : Alias: bmcaohttpclient Password: bmcaohttp
02 Feb 2012 18:47:14,127 DEBUG HTTPUtils       : Deleting server.DER ....
02 Feb 2012 18:47:14,128 DEBUG HTTPUtils       : C:\somename\Hardening\CDP7602SP3\tomcat\temp\server.DER deleted successfully :: true