[RFC] FIPS-140 Compliance Roadmap for OpenSearch

[kaimst]

Introduction

The Federal Information Processing Standard (FIPS), is a required standard for any software that will be used in the Government of the United States of America or the Government of Canada. It defines the security mechanisms that need to be implemented in software and hardware when working with information that will be used by state entities.

One key component of this standard is the 140 series, it specifies requirements for cryptographic modules in order to guarantee that the information is as secure as possible and algorithms that are known to be weak are not used for encryption.

Even though this standard is not required to be implemented in software used by private companies, many do increasingly prefer the FIPS compliant version of the software programs they use.

OpenSearch is a software that manages substantial volumes of diverse information. Therefore, it is crucial for user confidence that this information is handled as securely as possible. To this end there has been increasing interest in the community for implementing a mechanism that enables users of OpenSearch to operate a FIPS-compliant version of the software.

This RFC is related to and based on this issue and this issue and is intended to help facilitate a community discussion and provide a structured, iterative roadmap towards implementation.

Scope of this RFC

All work related to FIPS 140 must consider the current version of the standard, which is FIPS 140-3.

FIPS consists of hardware and software related security aspects, however, in this RFC only software related aspects are considered.

FIPS establishes different levels of security from 1 to 4, we currently only aim at level 1, to implement the starting point for further improvements in the future.

For OpenSearch to be FIPS compliant at level 1 as a software cryptographic module it is required that:

• OpenSearch needs to be able to run in a FIPS compliant environment with:
  • Operating system configured in FIPS mode
  • Java Runtime Environment configured in FIPS mode
• OpenSearch needs to be able to be configured to run in FIPS mode
• In FIPS mode, all cryptographic algorithms used in OpenSearch need to be algorithms that are approved by FIPS as listed under this link.
• It is recommended that all used security providers for algorithms are also software modules which have undergone FIPS validation and are listed under this link.
• Enabling FIPS mode at runtime, rather than at compile time prevents having to maintain two distinct code versions and is therefore the preferred solution.

To accomplish this, it is essential to utilize the Java Cryptographic Architecture (JCA), Java Cryptographic Extension (JCE), and Cryptographic Service Providers (CSP) in lieu of direct, hard coded implementations of specific security providers.

Implementation Summary

The following steps are proposed to be implemented sequentially and iteratively to reach the goal of OpenSearch FIPS compliance:

1. Verify currently used algorithms and if needed define FIPS compliant alternatives
2. Define the default security providers to be used
3. Adapt the policy and security files
4. Test the functionality by running OpenSearch in a FIPS compliant environment. If something fails, go back to step 1 and repeat
5. Implement a central security provider
6. Adapt the Gradle file(s)
7. Adapt and create new tests

Detailed description

1. Verify currently used algorithms and if needed define FIPS compliant alternatives.
   The initial step involves identifying all instances within the OpenSearch (core and plugins) code where cryptographic algorithms are utilized.
   A big part of this work has already been done by searching the codebase of OpenSearch and OpenSearch Security Plugin for uses of engine classes, these classes are part of the JCA / JSE and define algorithms for specific cryptographic tasks like hashing, encryption, random number generation and so on. The result of this search can be shared on request.
   Some security providers may have been hardcoded, requiring more detailed analysis for identification. Hence, our strategy involves pinpointing them during step 4, given the challenge of examining the entire codebase. Alternatively, we encourage the community to document any known instances of hardcoded security providers.
   After identifying all the algorithms in use, it is essential to check this list against the FIPS-defined list of approved algorithms as defined here
   If the algorithm is absent, an alternative must be specified when OpenSearch operates in FIPS mode.
   Following this step, a comprehensive list will emerge, detailing the cryptographic algorithms utilized in both normal and FIPS modes, which will be an important piece of documentation for future development and to define guidelines for security.

2. Define the default security providers.
   Having identified all algorithms that will be used in FIPS mode, the next step is to define a default security provider for each algorithm, therefore, it is recommended to use a software module which has undergone FIPS verification and is listed in the Cryptographic Module Validation Program (CMVP) of FIPS
   As a result of this step, a list of ordered security providers will be defined for use in normal mode and in FIPS mode, both of which can define default configuration options OpenSearch will be shipped with.
   If users instead desire to use their own security providers, they will be able to do so because the list of algorithms defined in step 1 will allow them to verify that their custom providers cover all required algorithms.

3. Adapt the policy and security files.
   The third step is to update the policy and security files of the project, to be able to use the defined security providers in step 2 and allow for all the algorithms defined in step 1 to be run correctly.
   As a result, base security and policy files will be created for use in either normal or FIPS mode, which will enable users to employ these files as parameters should they need to integrate alternative providers.

4. Test the functionality by running OpenSearch in a FIPS compliant environment.
   Before implementing significant changes or modifications in the code, it is necessary to test the configuration environment as defined in steps 1 to 3. For this test the following steps are required:

• Configure a FIPS compliant environment in FIPS mode, including operating system and JRE
  • Install the default security providers as defined in step 2
  • Configure the JRE with the FIPS enabled security and policy files as per step 3
• Replace non-FIPS compliant algorithms in the code with their FIPS compliant counterparts directly, while minimizing structural code changes
  • All places in the code that need to be changed are already identified in step 1.
    As a result of steps 1 to 3 OpenSearch should be able to run (and end to end tested) on a FIPS compliant environment, and thus assert that the algorithms, providers, policy and security configurations are implemented correctly. If non FIPS compliant providers were hardcoded or omitted, the test will fail and these cases will be identified, requiring the need to return to steps 1 to 3. For these cases, it will be required that FIPS compliant algorithms are implemented. As a result of this step, a FIPS-compliant version of OpenSearch will be operational.

5. Implement a central security provider.
   To avoid handling the specifics of FIPS and non FIPS compliant algorithms across the code base, a central security provider should be implemented.
   This provider should be able to offer any required cryptographic functionality declaratively, like hashing functions, symmetric and asymmetric encryption and decryption, random number generators, etc.
   The security provider should not only allow the definition of a specific algorithm, but also, based on the intended OpenSearch configuration, automatically define the appropriate algorithm to comply with FIPS if necessary or to keep the existing non FIPS algorithms.
   Having a centralized security provider in place would also ease the development towards future security standards.
   As a part of this task, all engine classes or direct security providers should be replaced with the central security manager. All places in the code where this would need to be changed are already defined in step 1.
   Following this step, OpenSearch will be capable of operating in either FIPS or non-FIPS mode, accommodating any security provider chosen by the user. Additionally, it will provide a stable set of default values to ensure the software runs smoothly in any mode, minimizing user inconvenience.

6. Adapt Gradle file(s).
   It is necessary to adapt the Gradle files to build the project correctly.

7. Adapt Tests.
   All the tests currently only support the non FIPS mode, if FIPS mode is enabled the tests are skipped.
   All relevant tests have to be adapted to allow FIPS and non FIPS mode. New tests must be implemented.

[varun-lodaya]

+1 to the FIPs offering. This will benefit a lot of users. But do we need to actually deep dive into individual ciphers and verify they are FIPs compatible? That will be a huge effort. Assuming all the crypto operations are embedded in some SSL library (Java SSL), there should be some way to switch to FIPs mode (assuming it has one) and recompile?

[varun-lodaya]

Btw, referencing the old GH issue - #593.

[stephen-crawford]

[Triage] Thank you for filing this issue @kaimst. Looking forward to seeing further discussion around this topic.

[reta]

It seems like OpenJDK is looking to have FIPS-140 compliant JCE implementation under Project Brisbane umbrella [1]

[1] https://mail.openjdk.org/pipermail/announce/2024-March/000347.html

[tallyoh]

+1

[mmomjya]

Could you please share the repos within openSearch project where cryptographic algorithms are utilized as described in step1?

[shiup]

+1, and further on the requirement - FIPS140-3 would be better, as 140-2 is a legacy now

Given NIST is behind in certification, my understanding is that even using the module that is in the queue to be certified for 140-3 will go a long way (this is a timed statement)

[aaronmcohen]

Is there something intermediate that can be done. I haven't found an update from OpenJDK Project Brisbane since the announcement. Both the Redhat build of OpenJDK and Semeru are FIPS 140-3 certified. Could the work be started with another JVM? If anything the move to a central security provider outlined above would make future adoption significantly easier.

[kaimst]

@aaronmcohen there is an open PR for this here