Test FIPS-validated crypto for Java app - Shibboleth (2/6)

[pburkholder]

As a compliance officer writing a FIPS 140 plan, I need to estimate the work involved, and timeline for, FIPS 140 in our Java apps, so we can provide our AOs with an meaningfully informed plan.

Implementation Steps

Run Shibboleth with FIPS 140 Java on a standalone VM, ideally using Ubuntu Advantage with FIPS, in a sandbox account.

Acceptance Criteria

A short playbook on what's involved in getting FIPS validated or FIPS enforcing to run.

Security considerations

Safe. This is running disconnected code in a disconnected account.

[pburkholder]

Changed the target application to test to Shibboleth from CredHub -- since if we need to run any java apps with FIPS-enabled it'll be shibboleth first. Also, taking out of current backlog since we can pause work on this until we get JAB TR feedback.

[jameshochadel]

Blocked on FIPS stemcells.

[jameshochadel]

Taking a look at this as part of https://github.com/cloud-gov/product/issues/2360. @pburkholder I think I wrote the previous comment during a standup, going off what someone else said. Do you know if it's true? As far as I can tell, our best choice for implementing FIPS modules in Java apps is to use the Bouncy Castle libraries, which their user guide seems to indicate can be done by placing them somewhere on the classpath for the application, i.e. somewhere it can find them. I don't see any reason we'd need OS support for that.

Edit: Answers in later comment.

[jameshochadel]

FIPS mode in Credhub: https://github.com/pivotal/credhub-release/blob/main/jobs/credhub/templates/init_key_stores.erb#L61-L67

[jameshochadel]

Notes from chat with @soutenniza:

• UAA has bouncy castle libraries already included, but requires FIPS mode enabled at an OS-level.
• Specifically, OS-level support is required in the pre-start script to generate a certificate with openssl: https://github.com/cloudfoundry/uaa-release/blob/66132b8f36a3b2f075da599707d425ee7d16897a/jobs/uaa/templates/bin/pre-start.erb#L133-L151
• Google Drive folder for FIPS 140 work: https://drive.google.com/drive/folders/1F9PZZBtyS6Bf0w2V-e5pJZn4_T43y_lP?usp=share_link
  • Presentation on cloud.gov FIPS (internal): https://docs.google.com/presentation/d/1Kg6HtPgOnJ89uZ-rhw5cW2WvHE_gknTBzmFysgicFd4/edit#slide=id.g106a32732c6_0_71
  • cloud.gov FIPS roadmap (internal): https://docs.google.com/document/d/1x9rGpBZwql8tpaSGvUIWkseA4N8lE-tXGLfQcqiTLdI/edit#heading=h.3etv46bank2a

Open questions for me:

• [ ] Can FIPS-enabled systems talk to non-FIPS-enabled systems?
• [ ] What about databases, ElasticSearch/OpenSearch? Think about dependencies in general.
• [ ] From Peter, research: Would re-hashing password reduce their security? (If we hashed twice, once using bcrypt to preserve backwards-compatability, and again using a FIPS-140 validated algo.)

[jameshochadel]

OpenSSL has a FIPS provider. Certificate here: https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282

So we could run OpenSSL in the mode that UAA requires, but UAA will check /proc/sys/crypto/fips_enabled to determine if it should use UAA. Need more research to see if we can turn that on OS-wide, or if we could place a custom packaging script in https://github.com/cloud-gov/uaa-customized-boshrelease, or something else.

[pburkholder]

Thanks for taking the time to focus on this and move it forward. Let's talk more about it once AA slows down.

[jameshochadel]

Running FIPS 140 workloads on Ubuntu: https://ubuntu.com/blog/running-fips-140-workloads-on-ubuntu

Based on this paragraph:

Note that the Linux kernel is itself a validated cryptographic module in the sense of FIPS, because it contains not only cryptography used by software (e.g., strongswan uses cryptography provided by it for IPSec), but also because it contains the random number generator that feeds all the user space applications and cryptographic libraries. Because of that the validated linux kernel is a dependency of the rest of the validated packages.

It sounds like the last piece of the puzzle is the kernel's PRNG. We won't get that until we have the FIPS compliant stem cells, and it's a dependency of the two direct crypto dependencies, openssl/libssl and Spring's bcrypt library (which uses java.security.SecureRandom, which in turn uses the PRNG).

So implementation today could be partial at best. We could update our custom Shibboleth code and our UAA release to use Bouncy Castle crypto modules and OpenSSL in FIPS mode, and accept that they won't be fully compliant because they won't be using a validated kernel under the hood. I think we should write this up and present it to the JAB, with the understanding that it'll get us most of the way there today, and all of the way there when we adopt the FIPS stemcells later this year. We can see if they'll accept that.

[pburkholder]

I'm going to close this as "Not Done". This is a partial duplicate of https://github.com/cloud-gov/private/issues/667, but more importantly it seems we're pursuing cloud-gov/private#985 as a solution here.