Security: FIPS 140-2 Compliance roadmap

[elasticmachine]

Original comment by @jkakavas:

The purpose of this Meta issue is to help us keep track of the tasks necessary in order to assert FIPS 140-2 Compliance for Elasticsearch and X-Pack

A short introduction into the needs of FIPS 140-2 Compliance and the initial research into the possibility of becoming compliant is described in LINK REDACTED ( LINK REDACTED and LINK REDACTED )

• (Settings: Reimplement keystore format to use FIPS compliant algorithms #28255 Use readFully() to read exactly the number of bytes we expect from the Stream #28515) Modify Secure Settings keystore in order to only use FIPS 140 approved algorithms.
• (Limit the scope of BouncyCastle dependency #30358) Split out the functionality for reading keys/files from CertUtils
• (Remove BouncyCastle dependency from runtime #32193) Remove BouncyCastle deendency from runtime (so that users can use BCFIPS for their JVM)
• (Replace custom reloadable Key/TrustManager #30509) Replace ReloadableX509KeyManager and ReloadableX509TrustManager with X509KeyManager, X509TrustManager respectively and implement reloadability(sic) in a higher layer.
• (Make licensing FIPS-140 compliant #30251) Ensure that only FIPS 140-2 approved algorithms are used throughout our code base ( i.e. org.elasticsearch.license.CryptUtils, org.elasticsearch.xpack.security.authc.support.Hasher )
• (Configurable password hashing algorithm/cost #31234) Support PBKDF2 for password hashing and allow configurable algorithm and cost paramater selection
• (Enable testing in FIPS140 JVM #31666)(Allow Integ Tests to run in a FIPS-140 JVM #31989) Ensure our tests can run in a FIPS 140-2 JVM
• Ensure that we use sufficient lengths for salt and Key values
• Formalize the difference between FIPS 140-2 Compliant and FIPS 140-2 Validated and determine if there is a need to go down the (hard/expensive/long) road of the latter.
• (https://github.com/elastic/infra/issues/5735) Add CI for ES on a JVM in FIPS Approved mode.
• (Introduce fips_mode setting and associated checks #32326) Add fips_mode setting and associated bootstrap checks
• ([DOCS] Add FIPS 140-2 documentation #32928) Fips Documentation

[elasticmachine]

Original comment by @tvernum:

I added a task for CI as well.

[elasticmachine]

Original comment by @jaymode:

I am not sure that we should promote a specific provider for FIPS compliance. We currently depend on bouncycastle for:

• Certificate generation
• Reading PEM files

I'd like to see if we can remove our dependency on bouncycastle in the running of our plugin and limit our usage to CLI tools. There are a few reasons for this, but my main driver is to keep bouncy castle out of our codebase so the the bcfips provider can be installed by a user. Currently our use of bouncycastle results in jar hell with the bcfips jars.

In order to generate certificates, we will need to use bouncycastle as there is no Java API for doing so yet (LINK REDACTED). However for reading PEM files, we could look at other options.

[elasticmachine]

Original comment by @jkakavas:

We currently depend on bouncycastle for:
* Certificate generation
* Reading PEM files

Another thing we can't do AFAICT is read pem encoded password protected private key files, as we do almost transparently in
LINK REDACTED
with BouncyCastle. An option would be to write the code to read PKCS#8 encoded keys but I would lean towards using libraries as much as we can compared to "rolling our own crypto"

[elasticmachine]

Original comment by @rjernst:

Ioannis, can you expand on what the restriction is in FIPS which disallows
us from reading pem encoded key files?

On Fri, Feb 2, 2018 at 9:48 AM Ioannis Kakavas EMAIL REDACTED
wrote:

Another thing we can't do AFAICT is read pem encoded password protected
private key files, as we do almost transparently in

LINK REDACTED
with BouncyCastle. An option would be to write the code to read PKCS#8
encoded keys but I would lean towards using libraries as much as we can
compared to "rolling our own crypto"

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub

.

[elasticmachine]

Original comment by @jkakavas:

Ioannis, can you expand on what the restriction is in FIPS which disallows us from reading pem encoded key files?

None, probably I was not clear above. What I meant to say is that we can't read password protected ( that is to say encrypted) private keys stored in PEM format without using BouncyCastle, as we do now, or without reimplementing a large part of LINK REDACTED so that we can deal with PKCS#5 encrypted, PKCS#8 encoded ones.

It was meant as an addition to Jay's list as to what we currently depend on BC for.

[elasticmachine]

Original comment by @jaymode:

We currently do not support PKCS#8 encoded PEM files, see this LINK REDACTED. The encrypted private keys that we support is fairly limited in scope:

        if (parsed instanceof PEMEncryptedKeyPair) {
            char[] keyPassword = passwordSupplier.get();
            if (keyPassword == null) {
                throw new IllegalArgumentException("cannot read encrypted key without a password");
            }
            // we have an encrypted key pair so we need to decrypt it
            PEMEncryptedKeyPair encryptedKeyPair = (PEMEncryptedKeyPair) parsed;
            privateKeyInfo = encryptedKeyPair
                    .decryptKeyPair(new JcePEMDecryptorProviderBuilder().setProvider(BC_PROV).build(keyPassword))
                    .getPrivateKeyInfo();
        } else if (parsed instanceof PEMKeyPair) {
            privateKeyInfo = ((PEMKeyPair) parsed).getPrivateKeyInfo();
        } else if (parsed instanceof PrivateKeyInfo) {
            privateKeyInfo = (PrivateKeyInfo) parsed;
        } else if (parsed instanceof ASN1ObjectIdentifier) {
            // skip this object and recurse into this method again to read the next object
            return innerReadPrivateKey(parser, passwordSupplier);
        } else {
            String msg = "parsed an unsupported object [" + parsed.getClass().getSimpleName() + "]";
            if (parsed instanceof X509CertificateHolder || parsed instanceof X509TrustedCertificateBlock) {
                msg = msg + ". Encountered a PEM Certificate while expecting a PEM Key.";
            }
            throw new IllegalArgumentException(msg);
        }

@jkakavas what do you think now that the scope of what we'd need to do is fairly contained?

[elasticmachine]

Original comment by @jkakavas:

We do support PKCS#8 private keys, but we do not support PKCS#5 encrypted PKCS#8 private keys in PEM format. We also support PKCS#1 private keys, both PKCS#5 encrypted and not, again in PEM format.

So in summary our CertUtils needs to be able to read ( from PEM formatted files):

• PKCS#8 private keys, unencrypted. ( Those start with ----- BEGIN PRIVATE KEY ----- )
• PKCS#1 (RSA) private keys unencrypted ( Those start with ----- BEGIN RSA PRIVATE KEY ----- )
• PKCS#1 (RSA) private keys, PKCS#5 encrypted ( Those start with

  ----- BEGIN RSA PRIVATE KEY -----
  Proc-Type: 4,ENCRYPTED
  DEK-Info: <ALGORITHM>,<HEX ENCODED IV>
  

It narrows the scope, I think the only one that would need extra implementation is the latter, parsing the algorithm and IV from the header. I'll get to it

[elasticmachine]

Original comment by @jkakavas:

FYI BCFIPS 1.0.1. was recently certified : LINK REDACTED

[jkakavas]

Closing this as all subtasks have been concluded.