Open faisal-memon opened 1 year ago
After a bit of research, my recommendation is that we offer a custom WolfSSL key manager, and update the documentation to comment of FIPS compliance; but, this will not be enough to be truly FIPS compliant, as we would have to also move all of the signing validation logic into either the key manager interface or a new interface, again backed by WolfSSL libraries. The documentation would have to note this in detail.
The alternative recommendation is that we simply maintain no claims of FIPS compliance. Oddly enough FIPS compliance is not a controlled category. It is a non-controlled claim that your software uses FIPS Certified cryptographic modules, aka libraries and / or hardware where the algorithms have been validated by the NIST to be FIPS Verified, and then additionally issued a certificate stating that specific release / build / configuration is FIPS Certified. Any changes, including bug fixes, invalids the verification and certification.
Issuing images that advertise FIPS compliance is likely the wrong approach. WolfSSL is currently the only provider of FIPS Certified libraries, and the informal "FIPS Compliant" statement is based on using only FIPS Certified components. Software updates in dependent libraries would not advertise if the new updates have a registered NIST FIPS Compliance document, or even if they were FIPS Validated. By making FIPS compliance a configuration issue the SPIRE brand is protected when deployed in ways that use the wrong SSL libraries, or even the correct SSL libraries that lack NIST Certification or lack NIST Certification and NIST Validation.
Why the focus on WolfSSL? Their FIPS-OpenSSL offering is advertised as the only FIPS-2 compliant module in existence. Currently FIPS-2 is deprecated, replaced by FIPS-3. While FIPS-3 started in 2019, it only received its first submission for Validation in 2020 and to date no modules have been issued FIPS-3 Certification.
Criticism of the FIPS program is fierce.
I would ask the core maintainers to choose between the two options, and then we can decide on the answer to the question "Does SPIRE provide FIPS compliance?" being one of "FIPS compliance is dependent on the deployment configuration of SPIRE, where one needs to configure an maintain a valid configuration against a FIPS compliant key manager" or "No, SPIRE leverages the latest OpenSSL libraries to ensure the fastest path for bug and security fixes, and the latest OpenSSL libraries choose to value speedy repair of security issues over the delays that FIPS Certification by NIST require."
Once we have the guidance, we should update / create a "frequently asked questions" section of the SPIRE documentation to expose the decision.
Related:
I recently did a bunch of FIPS-related work in Aegis ( https://github.com/shieldworks/aegis/issues?q=is%3Aissue+FIPS )
What I did was
boringcrypto
flag that uses FIPS-compliant cryptoSharing here, in case it might help.
And that was pretty much it.
Since SPIRE is a single binary, maintaining compliance should not take too much work.
--
btw, +1 with WolfSSL.
@faisal-memon
What are the rough steps if we wanted to create a PR to ensure FIPS compliance. Can you give a step-by-step instruction, especially for newcomers?
Related:
By making FIPS compliance a configuration issue the SPIRE brand is protected when deployed in ways that use the wrong SSL libraries, or even the correct SSL libraries that lack NIST Certification or lack NIST Certification and NIST Validation.
That’s how Aegis considers FIPS-compliance by the way:
Quote from its documentation:
AEGIS_SAFE_FIPS_COMPLIANT
AEGIS_SAFE_FIPS_COMPLIANT is required for Aegis Safe to run in FIPS-compliant mode.
Defaults to "false", which means Aegis Safe will run in non-FIPS-compliant mode.
Setting it to "true" will make Aegis Safe run in FIPS-compliant mode.
Note that this is not a guarantee that Aegis Safe will actually run in
FIPS compliant mode, as it depends on the underlying base image.
If you are using one of the official FIPS-complaint Aegis Docker images,
then it will be FIPS-compliant.
As a FIPS-compliant base image you can choose from the following:
[aegishub/aegis-ist-fips-safe]
[aegishub/aegis-photon-fips-safe]
@faisal-memon
What are the rough steps if we wanted to create a PR to ensure FIPS compliance. Can you give a step-by-step instruction, especially for newcomers?
Hey @faisal-memon , did you find a chance to prepare this ? I was also looking into FIPS compliant binary and was wondering if you got any updates which can help me
I recently did a bunch of FIPS-related work in Aegis ( https://github.com/shieldworks/aegis/issues?q=is%3Aissue+FIPS )
What I did was
* swap the encryption algorithm with RSA (with an optional flag; the default algorithm is still Age Encryption) * use a fips-compliant go runtime during the build phase (go has an experimental `boringcrypto` flag that uses FIPS-compliant crypto
Sharing here, in case it might help.
And that was pretty much it.
Since SPIRE is a single binary, maintaining compliance should not take too much work.
This seems reasonable to me. @v0lkan would you be open to discussing this in an upcoming contributor sync (happens every Tuesday at 11.30 am pacific time). FIPS compliance is a big deal in restricted environments.
@shashankram Sure, I am busy for a week or two, but I can jump into the earliest contributor sync I can make. — I’ll let here know after I check my calendar.
@amartinezfayo is this expected to land in 1.9?
@shashankram We haven't assigned a milestone to this yet. We have discussed this and the SPIRE project is not in a position that could publish FIPS compliant images. Rather, we think that we could make it easier to have SPIRE built (and probably configured) in a manner that adheres to the standards that FIPS 140-2 establishes. To achieve this, users will need to build SPIRE with a FIPS validated cryptographic library. One option could be to build SPIRE with BoringSSL. BoringSSL as a whole is not FIPS validated, but a specific core library called BoringCrypto is. We can leverage the use of BUILD_GOEXPERIMENT=boringcrypto to enable integrating BoringCrypto in the Go toolchain when building SPIRE.
@shashankram We haven't assigned a milestone to this yet. We have discussed this and the SPIRE project is not in a position that could publish FIPS compliant images. Rather, we think that we could make it easier to have SPIRE built (and probably configured) in a manner that adheres to the standards that FIPS 140-2 establishes. To achieve this, users will need to build SPIRE with a FIPS validated cryptographic library. One option could be to build SPIRE with BoringSSL. BoringSSL as a whole is not FIPS validated, but a specific core library called BoringCrypto is. We can leverage the use of BUILD_GOEXPERIMENT=boringcrypto to enable integrating BoringCrypto in the Go toolchain when building SPIRE.
@amartinezfayo that sounds reasonable to me. Curious if this is scoped for the upcoming release.
This issue is stale because it has been open for 365 days with no activity.
It would be great to build FIPS compliant images for American government agencies and contractors. The scratch image is a good start. We need to meet other requirement like working with FIPS OpenSSL.