With the release of version 6.4.0, Elasticsearch is able to run in a FIPS 140-2 environment. This means Elasticsearch 6.4.0+ can be run in FIPS 140-2 mode when properly configured within an approved environment. Additionally, a Platinum subscription is required to enable this feature.
What exactly is FIPS 140-2 ?
FIPS 140-2 is a U.S. Government computer security standard authored by the National Institute of Standards and Technology (NIST). FIPS stands for "Federal Information Processing Standard", 140 is the Publication number, and 2 refers to the fact that this is the second version of this Standard. It governs security requirements that must be satisfied by hardware and software cryptographic components:
The security requirements cover areas related to the secure design and implementation of a cryptographic module. These areas include cryptographic module specification; cryptographic module ports and interfaces; roles, services, and authentication; finite state model; physical security; operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility (EMI/EMC); self-tests; design assurance; and mitigation of other attacks.
Yes, it’s complicated, but the stated goal was to create a minimum level of cryptography for data the government considered sensitive, but unclassified. There are four levels within FIPS 140-2, with each level increasing requirements on the components, like tamper-evident physical security mechanisms or access to important settings within the component. Not all levels are applicable for all component types. Typically software can only achieve level 1 certification, for example, because you can not physically access it directly: you need to interact with hardware.
Why should you care?
Cryptographic components help ensure that stored data (“data at rest” and “data in use”) and data moving between systems (“data in transit”) is not viewed or changed by unauthorized people. By encrypting data with a cryptographic function ‒ locking it ‒, the data cannot be read without the right key to unlock it. One can go a step further and “sign” data with a cryptographic key so if someone attempted to alter the data, the recipient could detect the tampering.
That’s the idea, anyway. Cryptographic strategies have a history of being beaten. It’s because of this history that the U.S. government wrote FIPS 140: so government systems with sensitive data could protect that data with “good” cryptography. More and more, governmental organizations are requiring that systems comply with FIPS 140-2, motivating us to add Elasticsearch to the list of compliant systems.
Good cryptography is desirable outside of the government too. Finance, healthcare, and legal companies, among others, want to protect their data...hopefully even when they’re not required to by law. That’s why this was done by NIST, since one of its roles is setting standards (like redefining the kilogram) for public and private concerns.
Adherence to FIPS 140-2 benefits everyone responsible for ensuring the confidentiality and integrity of very sensitive data, as well as those of us who entrust our sensitive data to others.
Elasticsearch and FIPS 140-2
How does FIPS 140-2 apply to Elasticsearch? Elasticsearch is not, nor does it contain, a software or hardware cryptographic module. Consequently, it cannot be "FIPS 140-2 Validated" or "FIPS 140-2 Approved". It can, however, be compliant with the FIPS 140-2 standard. What that means is that starting with version 6.4.0, Elasticsearch can be run in a Java Virtual Machine where cryptography is provided by a FIPS 140-2 approved or validated cryptographic module. Elasticsearch uses cryptography provided by the aforementioned validated cryptographic modules in various aspects, whether it's salting and hashing your users' passwords, securing your settings on disk or encrypting the communications between your browser and Elasticsearch and between your Elasticsearch nodes.
In order to satisfy the requirements of FIPS 140-2:
- Only FIPS Approved or NIST recommended cryptographic algorithms are used.
- The implementation of these algorithms is not internal to Elasticsearch, but delegated to Java Cryptography Architecture (JCA) and/or Java Cryptography Extension (JCE) providers that, as software cryptographic modules, can be FIPS 140-2 validated and approved.
Running Elasticsearch in a FIPS 140-2 JVM
FIPS 140-2 is complicated enough, so we've made it very simple to configure Elasticsearch to support it. First, you need to enable "fips_mode" by setting
xpack.security.fips_mode.enabled to true in elasticsearch.yml.
Among other things, this will offer a warning if any of your configuration would result in compliance issues if, for instance, you select to use an encryption algorithm that is not FIPS Approved / NIST recommended.
In previous releases, Elasticsearch only supported the bcrypt algorithm with configurable work factors for password hashing. While bcrypt is a highly adopted and well regarded choice, it's not FIPS 140-2 approved, and as such, cannot be used in a FIPS 140-2 JVM. To overcome this hurdle, and be as future proof as possible, the PBKDF2 key derivation function with a configurable computational cost (up to 1000000 HMAC-SHA512 iterations) is available for use. bcrypt remains the default option, but can be changed via the
xpack.security.authc.password_hashing.algorithm configuration option to something FIPS 140-2 compliant, such as pbkdf2_10000.
See the Elasticsearch hash algorithm documentation for all available values.
The default TLS configuration of Elasticsearch is compliant with FIPS 140-2, as only TLSv1.2, TLSv1.1 and TLSv1 are supported and all the enabled cipher suites can be used in a FIPS 140-2 JVM.
A Parting Note
We know that FIPS 140-2 support isn’t something everyone needs, but it’s one of the ways Elastic is showing its dedication to building security into the product. We plan to continue to expand our support for FIPS 140-2 across additional Elastic products. If you need more information about FIPS 140-2, other federal compliance standards, or want to contact us, please see our website for US Government Certifications and Accreditations.