-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request] Support for FIPS 140-2 enforced mode. #1497
Comments
Thanks for reaching out. Also @setiah probably you might interested! |
@davidlago You might be interested in this as well :) |
FIPS 140-2 Mode would be an excellent feature |
A related discussion around making the crypto provider in security plugin configurable. https://github.com/opensearch-project/OpenSearch/issues/1487 As part of this, it should also enable users to provide a FIPS compliant provider. |
Please consider how/whether/when this will work on Windows, which has its own world of cryptographic providers. |
@davidlago any timeline/roadmap on FIPS compliance for opensearch on windows? |
Thanks for the interest, @bhupendra-mskhatri! We are not actively working on this issue at the moment, though it is a contribution we'd most definitely welcome. |
Thankyou @davidlago for your response. |
Hi @bhupendra-mskhatri, I tried to gather some information for you to be able to gauge the scope. For starters, we are going to have to rework the use of Bouncy Castle. If you look at their website you can see that while they do have FIPS certified APIs for Java, they are only certified for 1.7, 1.8, and 1.11. This means that the 2.x line and main which supports 1.17 will have to be run with 1.11 in order to be compliant. This is probably acceptable if a little bit confusing (there will be OpenSearch versions that are only compliant in one version configuration). You can see the Bouncy Castle FIPS versions here and some implementation details here. In effect, you would minimally need to replace any non-compliant algorithms with their certified counterparts from one of the linked Bouncy Castle API versions and make sure that the software then met the guidelines of the documentation. |
Thanks, @scrawfor99. OpenSearch crashes when it runs with FIPS on the mode by saying - Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=109, too big. ** @davidlago @saratvemulapalli, Please if anyone came across with similar situation?** FIPS settings turned on the windows box -
Java settings jdk-11.0.11.9-hotspot\conf\security\java.security |
@rathiyajiv That error message is based on the certificate being loaded, is it possible the cert isn't in PKCS12 format? Relevant StackOverflow question/answers https://stackoverflow.com/a/57683701/533057 |
Thanks @peternied, the observation here is an error occurs only when FIPS settings are on. Does PKCS12 format a must for FIPS mode from the opeansearch perspective? |
Referencing the bouncy castle guide, PKCS12 is not supported in approved-mode. More details from chapter 7 Key Stores https://downloads.bouncycastle.org/fips-java/BC-FJA-UserGuide-1.0.2.pdf After switch to a supported keystore this should get you around that error. |
Hi @rathiyajiv, thank you for following up. I see Peter already provided some more information to help you along your way, but I wanted to address your question about the format. PKCS12 is not a must that I am aware of. That being said, there are several factors that go into FIPS compliance which I am not an expert on. You will notice on the intial RFC that the requirements are listed for authentication as: FIPS does not have any specific guidelines for the type of algorithm used so long as it is compatible with these requirements. Instead you can use The annex of this draft has a list of some of the approved options for implementation. If there is a modification you wish to make to your local OpenSearch configuration in order to be able to run the enforced mode, I would encourage you to do so. If you were then able to let us know what you did, we may be able to make it a configurable option on the plugin so that it was easier to set up in the future. |
Thanks @peternied , @scrawfor99 - There are some traces around the FIPS in the code @ below All the version of security file fips_java_xx_x.security contains the security.provider.1 which points to the bouncycastle jcajce & jsse modules. While the java's /conf/security/java.security refers to SunJCE & SunJSSE. Can anyone suggest where to find the fips_java_bcjsse_11.security under Opensearch's deployed folder structure? We are on Opensearch version 2.4.1 |
I've been having a look at the security plugin, and I think the hard-coded dependency on the BouncyCastle provider will need to be broken for this to work. I think is mentioned on another related ticket about abstracting this particular dependency. So far from my digging, I see the security plugin uses BouncyCastle directly for:
If we can replace these with some non-hardcoded implementations or other libraries. Then it should be possible to try and run OpenSearch with another security provider - like the BouncyCastle FIPS provider. |
As you said BouncyCastle is hard coded means if we use BouncyCastle provider in JVM then Opensearch will Run in Fips mode automatically as BouncyCastle is by default provider |
Hi @iainjacksonsas, Thanks for the details on this. I know you are taking a further look, but to clarify, the major change to make OpenSearch FIPS compliant is swapping out Bouncy Castle use? If changes were made to make another library an option for running things, would that be enough to be considered compliant? Or would further changes on top of that be required? Thank you. |
Yes, looking at the usage of the BouncyCastle provider is a starting point. The key requirement is to run on a FIPS enforcing platform (e.g. RHEL 8) using FIPS certified cryptography. The major issue stems from OpenSearch Security plugin's direct use of classes in the BouncyCastle provider, which would need replaced with the FIPS certified version and run on a certified JDK (e.g. Java 11). However you cannot have both the FIPS and non-FIPS BouncyCastle providers on the classpath at the same time as they interfere with one another. You must use one or the other. I currently have a version of the OpenSearch Security plugin locally which does not have any direct dependencies on BouncyCastle. I did some code surgery to take from BouncyCastle just what was needed. This is not a solution, just working through what changes could and need to be made to make this work. I am currently working through trying to get it to start-up on a FIPS enforcing platform. Still not there, but i'm getting closer. |
Any update on FIPS implementation? I can see when I am using BC provide in java.security as below security.provider.1=org.bouncycastle.jcajce.provider.BouncyCastleFipsProvider C:HYBRID;ENABLE{All}; opensearch is starting fine . Can we assume its running in FIPS mode. |
I'm still pulling together my notes. But to answer your question, no it's not quite running in FIPS mode. The JVM - particularly on RedHat 8 - behaves differently when the kernel is set to FIPS mode. Also, to be running in a FIPS-compliant mode we can't use certain algorithms (e.g. BCrypt). I'm hoping to get a ticket raised this week with all the details on my investigation. |
Thanks for update. |
Hi @iainjacksonsas e.g. to @szwlhd query you responded that though after his changes opensearch started successfully, but it isn't running in FIPS mode. What are those references against which you cross checked to identify whether opensearch is running in FIPS mode or not. |
There isn't a checklist to verify. There's nothing you can simply check other than checking the output of 'fips-mode-setup --check' on RedHat to see if it's enabled. So far I've found for RedHat 8 that you should be using the JDK provided by the OS and not the one that ships with OpenSearch. The one that ships doesn't do anything special on FIPS mode - unless you start configuring it. It doesn't block the non-FIPS implementations which is what starts to cause issues. |
Hi @iainjacksonsas, But when I use my java not packaged with Opensearch with provider as BouncyCastleFipsProvider its working fine. Today going one step ahead set up the code locally for opensearch security plugin and changed the provider from Code which I changed. |
I initially started working through those steps, but hit into continual roadblocks (cryptography, Java security manager, etc). @szwlhd Here's a summary of the environment I have setup and what I have been working with and where I've got to so far:
I have the following additions in the security policy and properties files that I used with my no BouncyCastle implementation. I can get OpenSearch to boot with this and it have it running on TLS, but some of the code is still half-assembled and likely doesn't work. Security Policy
Security Properties
The RedHat JDK has a separate fips.xxx namespace in the security properties for the FIPS-settings which separates them from the non-FIPS settings. These are used instead on a FIPS-enabled system. Issues Found The major issues are the following:
This come baked in with all the FIPS restrictions on what cryptography you can and cannot use. So most of the policy configuration is done. All that remains is to plugin in the BC FIPS provider and get it wired up. If we can get OpenSearch to run in this very strict environment it should prove well for running in others (e.g. Windows, Mac).
Trying to have both on the classpath results in weird errors like missing keys, etc when it's initializing as it has the data from both providers from my testing. It's not a valid configuration.
Most of these are replaceable using the BC FIPS library instead - except BCrypt and Blake2b (see below). Switching to BC FIPS also means requiring the BC TLS FIPS and BC PKIX FIPS libraries too. We could ship all of them with the plugin, but ideally you would want to configure this at a JVM level and not through the plugin since these would only get instantiated when the plugin loads.
You can't have both FIPS and non-FIPS dependencies, so if you switch the compilation dependencies to BC FIPS (which is an option) you will be missing a number of classes. I have switched them out locally with other implementations to plug the gap to work through that issue later when investigating. However, to be running in a FIPS-compatible mode OpenSearch must only use cryptographic algorithms which have been FIPS-certified. So these two algorithms would need to be swapped for an implementation supplied by a FIPS-compliant module e.g. PBKDF2. At the moment there is no method to configure the default password hashing or data anonymization algorithms via settings - this is something that is missing from OpenSearch. New settings are really needed for:
Libraries I've been looking at to plug the gaps between BC FIPS and BC:
The ASN.1 parsing also needs to be implemented using another library. I've had no luck yet in tracking one down that's usable. |
Thanks for putting all the details. I completely agree with you we can use BC FIPS and BCPROV together. So I tried by removing BCPROV and including BC-FIPS. After that opensearch started but could not able to run https://localhost:9200 So I am at the place where you mentioned we have to replace the OpenBSDBCrypt algorithms. I was looking to BC FIPS documentation (https://www.bouncycastle.org/fips-java/BCFipsIn100.pdf) and thinking to implement something below. As of now I am not aware where it can be done or not need to evaluate. But please guide me if investigating in this direction worth it. Example 6 – ECB Mode Encryption Meanwhile I will look into these what you have suggested. My environment is RedHat Enterprise Linux 8.3 in FIPS-mode. I my java.security which is at location /home/user/java11/conf/security Security policy -- there other permission as well but mainly I have added these for BC fips |
Hi @iaindjackson, Today I implemented these two libraries
|
Could you please guide how to debug security plugin code in intellij IDEA ? |
This blog post may help in your BouncyCastle journey. |
Any update by when we can expect opensearch o FIPS enable ? |
Hi @iaindjackson |
Hi @szwlhd and @iaindjackson, just checking in on your efforts here. Is there a branch you are working on I could checkout or do you have your code set as private for the timing being. If you are able to share the stpes you have taken to reach your current state, I may have the bandwidth to contribute some when you run into a block. |
Hi @scrawfor99 Please find latest code below with my updates: This is not a production code but just implemented to see if OpenSearch is working in FIPS-mode.
My environment is I my java.security which is at location /home/user/java11/conf/security Let me know if you need running instance of opensearch in FIPS mode as well so that you can try the things quickly. |
Now using below code to connect with OpenSearch but getting error Code used is as below Security.addProvider(new BouncyCastleFipsProvider());
|
@scrawfor99 Did you get the change to look into my FIPS changes. |
I'm back to having a look at this with some of the team here. From looking into the changes, there's an important I think needs to be made with the usage of BC and BCFIPS. Do we switch to BCFIPS-only or remove BouncyCastle entirely? We need to decide whether we simply switch the BouncyCastle libraries for their FIPS counterparts in the code.
My major concern with the first option is that would also require bringing in the BC-TLS and PKIX libraries as well. These should really be configured at the JVM level for the running application, not injected directly by applications. There is also an advantage that we could also continue to use the utility functions provided by BCFIPS and not have to replace them with other implementations. The second option frees OpenSearch to just use standard Java cryptography methods, however we need to replace all usage of BouncyCastle utility classes with another implementation. We can ship some in-built algorithms, but the JVM could be re-configured to use any other cryptography library - it's not just a choice between BC and BCFIPS. The other advantage is that since BC would not longer be part of the distribution, and it would be one less library to maintain in the face of CVEs and other security vulnerabilities. There is a half-way house where we make BC a runtime dependency rather than compile, and load it if it's present. This would allow us to preserve some of the same behavior we have for deployments right now - but provide the option to remove BC if necessary and switch to BCFIPS or another. |
As a user, I would prefer having instructions to configure BCFIPS. Then it is my responsibility to "do the right thing" if necessary. That said, there should definitely be acceptance tests to ensure that the software works when correctly configured. 👍 I also definitely like the option to use any crypto library. |
link is broken @trevor-vaughan |
@yanivpaz And that's what I get for trying to improve my pages :-D. |
In some customer service contracts (especially Government contracts), there is a requirement to run all services in FIPS 140-2 compliant/enforced mode.
Elasticsearch supports this currently in their xpack security plugin.
We, and I imagine others could benefit greatly with the ability to run OpenSearch in a FIPS 140-2 enforced mode JVM.
I see there was also an OpenDistro community post asking for this feature as well.
The text was updated successfully, but these errors were encountered: