crypto: obtain a FIPS 140-3 validation #69536
Comments
|
Related Issues and Documentation
(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.) |
|
I was just about to ask a question regarding Ed25519 usage in the other ticket when this was posted. Exciting news! |
Yes, we'll post a full list of algorithms once we are close to finalizing it, but it approximates to "everything that's NIST approved and not frozen, deprecated, or legacy-use". |
How this is going to be achieved? Build tags? |
Probably something more explicit, such as a
Yes. |
|
Change https://go.dev/cl/614495 mentions this issue: |
|
Change https://go.dev/cl/614656 mentions this issue: |
|
Change https://go.dev/cl/615235 mentions this issue: |
|
Change https://go.dev/cl/615816 mentions this issue: |
|
Out of curiosity, how will Go natively handle the key zeroization requirements of FIPS? |
|
Change https://go.dev/cl/616636 mentions this issue: |
|
Change https://go.dev/cl/616717 mentions this issue: |
|
Change https://go.dev/cl/616716 mentions this issue: |
|
Change https://go.dev/cl/616715 mentions this issue: |
Ensure separate implementations are implemented in different functions called from Go, and that they can be turned off from a GODEBUG. This will be necessary to test implementations separately for golang#69536. Change-Id: I3e081deb7abb01b0665265e39c72fd4037dd48b3 Cq-Include-Trybots: luci.golang.try:gotip-linux-arm64-longtest,gotip-linux-amd64-longtest,gotip-linux-ppc64le_power8,gotip-linux-ppc64_power8
This will be required for golang#69536 but is also good hygiene and required by go.dev/wiki/AssemblyPolicy. > The code must be tested in our CI. This means there need to be > builders that support the instructions, and if there are multiple (or > fallback) paths they must be tested separately. The new crypto/internal/impl registry lets us select alternative implementations from both the same package and importers (such as crypto/sha256 tests once we have crypto/internal/fips/sha256, or crypto/hmac). Updates golang#69592 Updates golang#69593 Change-Id: Ifea22a9fc9ccffcaf4924ff6bd08da7c9bd39e99 Cq-Include-Trybots: luci.golang.try:gotip-linux-arm64-longtest,gotip-linux-amd64-longtest,gotip-linux-ppc64le_power8,gotip-linux-ppc64_power8
For golang#69536 Change-Id: I1efa916e6e9fcddeffa52bc3d23286e6465dae54
For golang#69536 Change-Id: I38508a8de4ac321554a2c12ac70bcf9e25fad1aa
For golang#69536 Change-Id: If237226ba03e282443b4fc90484968c903198cb1
This is needed from inside the module, and we generally don't want to import the crypto tree from it. For golang#69536 Change-Id: I69e91e4df89ecac0016c671ccd28e733a7131533
For now just internally, pending a dedicated proposal for the exposed package API. In this CL the code is copied verbatim, for ease of review. Only the imports were replaced with the corresponding internal ones, and crypto.RegisterHash calls were disabled. DO NOT SUBMIT until CL 616635 is submitted, and this CL is synced, then specify here what commit was imported. Updates golang#65269 For golang#69536 Change-Id: Ia4735b50c99b9573a5c4889733c4a119930fe658
Adds a new crypto/internal/fips test binary that operates as both a unit test fetching/driving the BoringSSL acvptool, and an acvptool module wraper when invoked by the unit test. Initial support for testing the SHA2 family of digests, and the HMAC family of MACs is included. The BSSL acvptool "lowers" the NIST ACVP server JSON test vectors into a simpler stdin/stdout protocol that can be implemented by a module wrapper. The tool will fork our acvpwrapper binary, request the supported configuration, and then provide test cases over stdin, expecting results to be returned on stdout. See "Testing other FIPS modules" from the BoringSSL ACVP.md documentation for a more detailed description of the protocol used between the acvptool and module wrappers. Updates: golang#69642 Updates: golang#69536 Change-Id: I6b568c67f2a71144fbf31db467c6fd25710457f5
|
Change https://go.dev/cl/617357 mentions this issue: |
|
Change https://go.dev/cl/617359 mentions this issue: |
|
Change https://go.dev/cl/617535 mentions this issue: |
Background
FIPS 140 is a set of U.S. Government requirements for cryptographic modules. A number of companies must comply with them, for example as part of a broader FedRAMP compliance posture. (If that's not you, you can ignore this. Run!)
Current solutions for Go program compliance are based on cgo, and replace some of the crypto packages internals with FIPS 140 validated non-memory safe modules. These solutions come with varying levels of support (for example the Go+BoringCrypto solution is not officially supported and its compliance profile is left to the user to assess), introduce memory unsafe code, sometimes delay Go version updates, can have performance issues, affect the developer experience (for example inhibiting cross-compilation), and their compliance profile is debatable. As Go is adopted more and more in regulated settings, this is going to affect Go's adoption and developer experience.
The Go FIPS module
We plan to pursue a FIPS 140-3 validation for the NIST approved components of the Go standard library. The resulting module will be distributed as part of the standard library under the same license as the rest of the Go project, and will be transparently used by the relevant standard library packages with no API changes (wherever possible).
Users will be able to select the module to use at build time, for example choosing between a certified version, a version in the In Process list, or the latest unvalidated update. Moreover, we'll provide some mechanism for applications to disable the use of non-approved algorithms and modes at runtime.
Further planning details
The goal is shipping the module as part of Go 1.24, assuming our validation strategy is successful. This is the first time as far as we know that a Go library (or any non-Java memory safe library) is validated.
Unless completely unavoidable, we'll not compromise on security to achieve compliance. For example, we will inject random bytes from the kernel as additional input per SP 800-90Ar1, Section 8.7.2, every time we use the mandatory DRBG, and we'll use a dedicated DRBG for ECDSA to implement a "hedged" nonce generation equivalent to what crypto/ecdsa does now (safer than both NIST options of fully random and deterministic). Also, we'll try to add minimal complexity to regular non-FIPS builds.
NIST approved packages will be prioritized in being moved to the standard library (#65269) to get validated along the rest.
We'll test at least on Linux on amd64 and arm64. Further details will be available later in the process. (If you have specific requirements, please inquire about becoming a sponsor, see below.)
We aim to deprecate and hopefully remove Go+BoringCrypto once the module lands.
After the initial validation, we plan to revalidate at least every year, and every time a CVE affects the module with no standard library-side mitigation.
All work will be done on Gerrit, tracked in the issue tracker, and the testing harnesses will be committed in the tree.
This is an umbrella issue to track related issues and CLs, and to provide updates to the community. We'll file separate proposals for the exact build-time settings, for the FIPS-only policy mechanism, for any new APIs, and for any behavior changes.
We have started working with a CMVP testing laboratory, and contracted @cpu to help. This is an industry-sponsored effort that I (@FiloSottile) am leading as an independent maintainer, not a Google or Go team project (although it is coordinated with the Go team and @golang/security). We're funded by a few major stakeholders, and we're available to accept sponsorships and offer commercial support (reach out to filippo@golang.org if interested).
The text was updated successfully, but these errors were encountered: