FIPS Compliance

[dlorenc]

We might need to make sure this is FIPS compliant.

[lukehinds]

I think we are:

https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf

[dekkagaijin]

We need to be using a FIPS-validated crypto implementation, i.e. not vanilla Go. We can use Go+BoringCrypto to accomplish this for linux/amd64, but we give up static linkage.

The work I did for GKE has a strong crossover here, I'd be happy to handle it.

[dlorenc]

Thanks for the overview! For now a doc or something explaining the plan is probably all we need, we can wait until someone actually asks for it to implement. That way we can be sure the design will work for the people that really need it.

[lukehinds]

I think we can stick with go crypto for upstream implementation.

I believe at Google you have a shimmed golang version to ease the use of Go+BoringCrypto when you compile. We do a similar thing at red hat where we automatically use openssl bindings on a system set in FIPS mode.

[dekkagaijin]

For now a doc or something explaining the plan is probably all we need, we can wait until someone actually asks for it to implement.

My argument to make support a first-class citizen (at least as a bonus release) is that it's a lot easier to offer a FIPS-compliant release from the get go with the pruned cypher-suite than it is to prune it later

I believe at Google you have a shimmed golang version to ease the use of Go+BoringCrypto when you compile.

It's at the point where we simply swap out OSS k8s's version of Go for the BoringCrypto equivalent. Build tags are sufficient to ensure compatibility for both toolchains

[lukehinds]

I would be ok with a bonus release e.g. 'cosign-fips' or 'cosign-gbc`, but not as main as a number of distros (rhel included) can't ship with Go+BoringCrypto, its not a technical decision, but on going support guarantees.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don’t recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

[dekkagaijin]

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don’t recommend that third parties depend upon it.

Hm. Goboring only relies on the the core cryptographic libs rather than the entirety of BoringSSL, but I don't suppose that changes the calculus much. It is API-compatible with the vanilla Go libraries, at least.

FWIW GKE relies on it being fully compatible with OSS, and is continuously validating it as such. It has a high practical level of support

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.

[lmarchione-r7]

We're trying to use cosign, but also require FIPS compliance.

I saw that in Go 1.19, boringcrypto was moved into Go's main branch as a GOEXPERIMENT.

I know that BoringSSL "is not intended for general use" (as per the README), but it seems good enough for Google and Cloudflare. I would vote to at least create an extra linux-amd64 version that is FIPS compliant.

If that's not possible, instructions on how to build with FIPS compliance (using boringcrypto) would be a great addition. I have this working, but would like some input from anyone else doing this (I'm not a go developer).

# assuming you have an older version of go installed, need to install a newer 1.19+ version of go
export GOPATH=$HOME/go
export PATH=$PATH:$HOME/go/bin
go install golang.org/dl/go1.19.4@latest
go1.19.4 download

# see differences between versions (need to use the go1.19.4 executable going forward)
go version
go1.19.4 version

# build cosign
mkdir ~/dev
cd ~/dev
git clone https://github.com/sigstore/cosign
cd cosign
GOEXPERIMENT=boringcrypto go1.19.4 install ./cmd/cosign
$(go env GOPATH)/bin/cosign version

# verify the binary is using FIPS
# https://kupczynski.info/posts/fips-golang/
# https://developers.redhat.com/articles/2022/05/31/your-go-application-fips-compliant#how_to_verify_fips_mode
go1.19.4 tool nm $(go env GOPATH)/bin/cosign | grep _Cfunc__goboringcrypto_
go1.19.4 tool nm $(go env GOPATH)/bin/cosign | grep FIPS

[haydentherapper]

I would caution saying that Cosign will be FIPS compliant with BoringSSL, without a more thorough review from your legal council (or if the Linux Foundation/OpenSSF would like to provide this legal council).

Providing instructions for building the application using boringcrypto seems reasonable.

[dekkagaijin]

@haydentherapper there's definitely more to it than that, but BoringSSL does provide big-G-approved FIPS compliance with regard to cypher suites. Counsel will be able to sign off on it, but ensuring continuous compliance is most of the work.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[AaronFriel]

Shush, bot.

Are there any concerns about requiring CGo and cross-compilation toolchains, would the project look at adopting another toolchain?

This has been a relevant area of interest at my workplace as I've seen users asking for FIPS compliance, and others asking for TLS 1.3 support. Satisfying both with a single binary using Google's Go distribution is currently impossible. The GOBORING experiment plus the compile time import forces the binary into FIPS only mode, with no opt out.

import _ "crypto/tls/fipsonly"

I've been evaluating both Red Hat and Microsoft's toolchains. The former is currently on Go 1.18, the latter I think is more interesting as it enables toggling FIPS compliance at runtime via an environment variable: https://github.com/microsoft/go#why-does-this-fork-exist. Being able to produce a single binary is a major plus.

Curious to hear the thoughts of the sigstore maintainers here as they weigh options.

[znewman01]

I think I'm okay with two binaries, to be honest. Seems harder to shoot yourself in the foot that way, and less headache than using something nonstandard.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 5 days with no activity.