JRE with Bouncy Castle for FIPS or is PEM sufficient

[Kris_U]

I was able to get Elasticsearch working with the Bouncy Castle BCFKS keystore in Elasticsearch 7.17 (I will post the steps at the end of my post). But Kibana and Logstash will not accept the BCFKS keystore format. I am running eash on a different instance. I was able to make it work by using PKCS keystores on each (signed by the same ca as the BCFKS keystore). But As I understand it - that makes them out of compliance with FIPS. I see Kibana has FIPS in progress - but I have not been able to find anything out about Logstash.

I was able to make an Elasticsearch FIPS mode configuration work previously with PEM certificates on the ELK stack (as far as I can tell - FIPS validated modules and algorithms). But I could not make it work with the JRE with Bouncy Castle - it kept erroring out saying it could not find the BCFKS keystore (even though I wasn't using a keystore - I was using the PEM certificates and keys.

The Elasticsearch documentation says that in order to have FIPS 140-2 you need to: "Delegating the implementation of these cryptographic algorithms to a NIST validated cryptographic module (available via the Java Security Provider in use in the JVM"

Elasticsearch 7.17 FIPS Compliance

Also the support matrix specifies that it requires the Bouncy Castle FIPS security provider for FIPS 140-2:

Elastic Support Matrix

Does anyone know if that's still applicable if you're using PEM certificates created with a FIPS cryptographic module for http and transport? Does anyone know why elase you would need the JRE with Bouncy Castle to be used if it's not for the BCFKS keystores? Is there any other reason? Or could I theoretically skip that step if I am using PEM certificates instead of keystores?

To get FIPS mode with BCKFS working on Elasticsearch 7.17 (on Ubuntu 20.04):

1. Built the JRE with JDK 11 and the Bouncy Castle module using jlink (this post gave an idea how to do that).
2. I setup the yaml files, keystore conversion (fromo PKCS to BCFKS) java.security, java.policy, and the java options (see later replies) as specified in this post: ElasticSearch FIPS (BouncyCastle)
3. For the keystore and truststore passwords (instead of putting them in the elasticsearch.yml) I used the https://www.elastic.co/guide/en/elasticsearch/reference/7.17/elasticsearch-keystore.html and a password for the keystore itself - all sufficient length. ( I also set the ES_KEYSTORE_PASSPHRASE_FILE environment variable in the elasticsearch.service file but I won't go into the details here).
4. Edited the /etc/default/elasticsearch with the new JRE path and java options

I think that's it.

[TimV (Tim Vernum)]

Ultimately this depends on what your goal is with respect to FIPS 140 compliance.

If you have a requirement to meet some set of FIPS criteria then you will need to run Elasticsearch in a mode and environment that fits within that criteria.

In a strict environment "FIPS compliant" will mean that ever piece of cryptographic code has been audited/certified (by an official testing lab) to be implemented correctly and the API to any cryptographic functions enforces that those APIs are used in the correct manner (e.g. the API prevents you from creating encryption keys that are shorter that the length specified by the FIPS spec).

The cryptographic libraries that ship with the JDK are not FIPS certified. If you run a default JDK then any encryption that takes place within Elasticsearch (e.g. in TLS) will be using uncertified implementations.