-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
Tests imported from x/crypto, but the actual implementation was simpler to implement ex-novo with a #61477-like API. Updates #61477 For #69536 Change-Id: I5a9e8a71d8abd5b2aa6b74e73bf7f631ed0115cd Reviewed-on: https://go-review.googlesource.com/c/go/+/621275 Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> Reviewed-by: Russ Cox <[email protected]>
The new implementation encodes the key schedule into the type system, which is actually nicer than what we had before. For #69536 Change-Id: Iddab62c2aae40bc2425a155443576bb9b7aafe03 Reviewed-on: https://go-review.googlesource.com/c/go/+/626836 Reviewed-by: Russ Cox <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Commit-Queue: Roland Shoemaker <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Daniel McCarney <[email protected]>
For #69536 Change-Id: If2477c5249a7c7db45c1af05e715ae0b61e7d940 Reviewed-on: https://go-review.googlesource.com/c/go/+/626837 Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Michael Knyszek <[email protected]> Reviewed-by: Russ Cox <[email protected]>
For #69536 Change-Id: I0788469400de6a39cb22a6936a74d71066c476b1 Reviewed-on: https://go-review.googlesource.com/c/go/+/626875 Reviewed-by: Russ Cox <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-by: Michael Knyszek <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]>
…ort salts For #69536 Change-Id: Ibe2623311c8be5fb3e7411b33e61bf66d026e14d Reviewed-on: https://go-review.googlesource.com/c/go/+/626877 Reviewed-by: Michael Knyszek <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Russ Cox <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Daniel McCarney <[email protected]>
For #69536 Change-Id: I6ecbe8b05f9f01afe2aa32c59fc56c9e1c6ea6b4 Reviewed-on: https://go-review.googlesource.com/c/go/+/626437 Reviewed-by: Daniel McCarney <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
In the process, replace out-of-module imports with their FIPS versions. For #69536 Change-Id: I83e900b7c38ecf760382e5dca7fd0b1eaa5a5589 Reviewed-on: https://go-review.googlesource.com/c/go/+/626879 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Russ Cox <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> Reviewed-by: Michael Knyszek <[email protected]>
For #69536 Change-Id: Id9d2f6553ab006d0d26986d22a4a756b9cf1bf71 Reviewed-on: https://go-review.googlesource.com/c/go/+/626936 Auto-Submit: Filippo Valsorda <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Russ Cox <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-by: Daniel McCarney <[email protected]>
As explained in fips_test.go, we generally want to minimize tests inside the FIPS module. When there is a relevant calling package, the tests should go there, otherwise in fipstest. This required redoing a bit the CAST failure tests, but the new version is actually more robust because it will fail if a _ import is missing. Since TestCAST doesn't print a line for each passed CAST anymore, made GODEBUG=fips140=debug do that, in case we need to show it to the lab. For #69536 Change-Id: I0c1b82a4e9ee39e8df9bbe95bebb0527753f51c8 Reviewed-on: https://go-review.googlesource.com/c/go/+/627955 Reviewed-by: Daniel McCarney <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Russ Cox <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
The changes below src/crypto/internal/fips/ are mechanical. See fipsdeps.go and fipsdeps_test.go for the rationale. For #69536 Change-Id: I292ce65237cd8d2fd87fab99814514dd0e69c4a7 Reviewed-on: https://go-review.googlesource.com/c/go/+/627956 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Russ Cox <[email protected]>
For #69536 Change-Id: I8ff3fdd70f540559d83abe006985bcee11ffde91 Reviewed-on: https://go-review.googlesource.com/c/go/+/628775 Reviewed-by: Russ Cox <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
For #69536 Change-Id: Id9d76aefbbe1f7c957973380c6eaeb5bfb9de967 Reviewed-on: https://go-review.googlesource.com/c/go/+/627957 Reviewed-by: Michael Knyszek <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Russ Cox <[email protected]> TryBot-Bypass: Filippo Valsorda <[email protected]> Commit-Queue: Filippo Valsorda <[email protected]>
This intentionally gives up on the property of not computing the public key until requested. It was nice, but it was making the code too complex. The average use case is to call PublicKey immediately after GenerateKey anyway. Added support in the module for P-224, just in case we'd ever want to support it in crypto/ecdh. Tried various ways to fix test/fixedbugs/issue52193.go to be meaningful, but crypto/ecdh is pretty complex and all the solutions would end up locking in crypto/ecdh structure rather than compiler behavior. The rest of that test is good enough on its own anyway. If we do the work in the future of making crypto/ecdh zero-allocations using the affordances of the compiler, we can add a more robust TestAllocations on our side. For #69536 Change-Id: I68ac3955180cb31f6f96a0ef57604aaed88ab311 Reviewed-on: https://go-review.googlesource.com/c/go/+/628315 Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> Reviewed-by: Russ Cox <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
For #69536 Change-Id: Ic096282c521958083d0ba816d62d908f6fcf7dbe Reviewed-on: https://go-review.googlesource.com/c/go/+/628676 Reviewed-by: Russ Cox <[email protected]> TryBot-Bypass: Filippo Valsorda <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
For #69536 Change-Id: I8794d75c11cdadd91e420541b26af35e62006af4 Reviewed-on: https://go-review.googlesource.com/c/go/+/628677 Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Russ Cox <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
For #69536 Change-Id: I85088acb3da788f688f78efff39320bd517e617d Reviewed-on: https://go-review.googlesource.com/c/go/+/628679 Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Russ Cox <[email protected]>
…ences The previous CL focused on moving the implementation as-is, while this makes it FIPS-compliant. For #69536 Change-Id: I75fa56c7e13ba20246bacf9fda4599c9f25a1c63 Reviewed-on: https://go-review.googlesource.com/c/go/+/628678 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Russ Cox <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
We'll use this for deterministic and hedged ECDSA. For #69536 Change-Id: Ifb3d963a084fb4914536826250589ff8862add9f Reviewed-on: https://go-review.googlesource.com/c/go/+/628680 Reviewed-by: Russ Cox <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]>
Since ECDSA private keys are irredeemably malleable, an application could construct one where the public key doesn't match the private key. They'd be very much on their own, but crashing the program feels a bit harsh. Add this one to the list of issues caused by exposing the ECDSA (and RSA) key values as big.Ints. For #69536 Change-Id: Iaa65c73d7145e74f860ca097fa9641448442fbf9 Reviewed-on: https://go-review.googlesource.com/c/go/+/628855 Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Russ Cox <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
Left most of the tests in for now as they are almost all internal and hard to externalize. String initialization in the FIPS module has some issues, so switched field.TestSqrtRatio to storing decoded byte slices instead. For #69536 Change-Id: If9e4a2bb780a37a8d102a22ffd13c5293d11a8a6 Reviewed-on: https://go-review.googlesource.com/c/go/+/628776 Reviewed-by: Russ Cox <[email protected]> TryBot-Bypass: Filippo Valsorda <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]>
For #69536 Change-Id: Ifba3e2bcb03966f2ed576d3f88e2e09193215b4a Reviewed-on: https://go-review.googlesource.com/c/go/+/628856 Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Russ Cox <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]>
The module must do the integrity self-check before any other operation in FIPS mode. For #69536 Change-Id: I8db52ea94e867812008a6e7a86ca2c648a0018c6 Reviewed-on: https://go-review.googlesource.com/c/go/+/629056 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Russ Cox <[email protected]>
Change https://go.dev/cl/629937 mentions this issue: |
Change https://go.dev/cl/630095 mentions this issue: |
Change https://go.dev/cl/629675 mentions this issue: |
Key generation is still missing and will come in a follow-up CL. For #69536 Change-Id: Ia17754fe31a39a48710673b51e30ca3125b19a20 Reviewed-on: https://go-review.googlesource.com/c/go/+/629937 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Russ Cox <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
The byte sequences match those in https://github.com/randombit/botan/blob/e5ec40828/src/lib/pk_pad/hash_id/hash_id.cpp For #69536 Fixes #43923 Change-Id: I8b4daea71c2f696ad67ddc13affefd1563c51266 Reviewed-on: https://go-review.googlesource.com/c/go/+/630095 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Russ Cox <[email protected]> Reviewed-by: Daniel McCarney <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
Consolidates handling of FIPS 140-3 considerations for the tls package. Considerations specific to certificates are now handled in tls instead of x509 to limit the area-of-effect of FIPS as much as possible. Boringcrypto specific prefixes are renamed as appropriate. For #69536 Co-authored-by: Filippo Valsorda <[email protected]> Change-Id: I1b1fef83c3599e4c9b98ad81db582ac93253030b Reviewed-on: https://go-review.googlesource.com/c/go/+/629675 Reviewed-by: Filippo Valsorda <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Russ Cox <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
This commit lifts the internals of crypto/pbkdf2 into crypto/internal/fips140/pbkdf2, in the FIPS module. The code remains unchanged except for the following adjustments: * The hash and hmac imports now come from the FIPS equivalents. * The FIPS service indicator status is set based on the SP 800-132 requirements for PBKDF2. For #69536 Change-Id: I61f47a652cef10505a5b40a70be5240b161a97ba Reviewed-on: https://go-review.googlesource.com/c/go/+/619236 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Derek Parker <[email protected]> Reviewed-by: Filippo Valsorda <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
Per IG 10 3.A a module implementing PBKDF2 must perform a CAST on the derivation of a master key. This commit adds the required CAST test. The salt length (16 bytes), and output length (14 bytes) for the test are selected to meet FIPS requirements. The iteration count must be at least 2 so we use that value exactly for the fastest self-test allowable. We test all underlying prerequisite algorithms (HMAC, digest algorithms) separately. For #69536 Change-Id: Iba9e87ab89eeec1c73adc7e56016674ac8065c39 Reviewed-on: https://go-review.googlesource.com/c/go/+/623195 Reviewed-by: Filippo Valsorda <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Filippo Valsorda <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Roland Shoemaker <[email protected]>
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 [email protected] if interested).
The text was updated successfully, but these errors were encountered: