mirror of
https://github.com/hashicorp/vault.git
synced 2025-08-06 06:37:02 +02:00
Upgrade FIPS 1402 -> 1403 (#30576)
* Upgrade FIPS 1402 -> 1403 * Clean up * changelog
This commit is contained in:
Luis (LT) Carbonell
GitHub
parent
6852fc4e60
commit
ed52371b10
10
.github/actions/containerize/action.yml
vendored
10
.github/actions/containerize/action.yml
vendored
@ -63,19 +63,19 @@ runs:
|
||||
redhat_container_tags='quay.io/redhat-isv-containers/5f89bb9242e382c85087dce2:${{ inputs.vault-version }}-${{ inputs.vault-edition }}-ubi'
|
||||
redhat_container_target='ubi-hsm'
|
||||
;;
|
||||
"ent.hsm.fips1402")
|
||||
"ent.hsm.fips1403")
|
||||
container_version='${{ inputs.vault-version }}+${{ inputs.vault-edition }}'
|
||||
docker_container_tags='docker.io/hashicorp/vault-enterprise:${{ inputs.vault-version }}-${{ inputs.vault-edition}} public.ecr.aws/hashicorp/vault-enterprise:${{ inputs.vault-version }}-${{ inputs.vault-edition }}'
|
||||
docker_container_target='ubi-hsm-fips'
|
||||
redhat_container_tags='quay.io/redhat-isv-containers/5f89bb9242e382c85087dce2:${{ inputs.vault-version }}-${{ inputs.vault-edition }}-ubi'
|
||||
redhat_container_target='ubi-hsm-fips'
|
||||
;;
|
||||
"ent.fips1402")
|
||||
# NOTE: For compatibility we still publish the ent.fips1402 containers to different
|
||||
# namespaces. All ent, ent.hsm, and ent.hsm.fips1402 containers are released in the
|
||||
"ent.fips1403")
|
||||
# NOTE: For compatibility we still publish the ent.fips1403 containers to different
|
||||
# namespaces. All ent, ent.hsm, and ent.hsm.fips1403 containers are released in the
|
||||
# enterprise namespaces. After we've updated the upstream docker action to support
|
||||
# multiple tags we can start to tag images with both namespaces, publish to both, and
|
||||
# eventually sunset the fips1402 specific namespaces.
|
||||
# eventually sunset the fips1403 specific namespaces.
|
||||
container_version='${{ inputs.vault-version }}+${{ inputs.vault-edition }}'
|
||||
docker_container_tags='docker.io/hashicorp/vault-enterprise-fips:${{ inputs.vault-version }}-${{ inputs.vault-edition }} public.ecr.aws/hashicorp/vault-enterprise-fips:${{ inputs.vault-version }}-${{ inputs.vault-edition }}'
|
||||
docker_container_target='ubi-fips'
|
||||
|
||||
2
.github/workflows/ci.yml
vendored
2
.github/workflows/ci.yml
vendored
@ -228,7 +228,7 @@ jobs:
|
||||
}
|
||||
name: fips
|
||||
go-arch: amd64
|
||||
go-tags: '${{ needs.setup.outputs.go-tags }},deadlock,cgo,fips,fips_140_2'
|
||||
go-tags: '${{ needs.setup.outputs.go-tags }},deadlock,cgo,fips,fips_140_3'
|
||||
runs-on: ${{ needs.setup.outputs.compute-test-go }}
|
||||
runs-on-small: ${{ needs.setup.outputs.compute-small }}
|
||||
test-timing-cache-key: go-test-timing-fips
|
||||
|
||||
@ -1 +1 @@
|
||||
1.24.2
|
||||
1.24.3
|
||||
|
||||
3
changelog/30576.txt
Normal file
3
changelog/30576.txt
Normal file
@ -0,0 +1,3 @@
|
||||
```release-note: improvement
|
||||
core: Updated code and documentation to support FIPS 140-3 compliant algorithms.
|
||||
```
|
||||
@ -1,12 +0,0 @@
|
||||
// Copyright (c) HashiCorp, Inc.
|
||||
// SPDX-License-Identifier: BUSL-1.1
|
||||
|
||||
//go:build !fips_140_3
|
||||
|
||||
package config
|
||||
|
||||
import "github.com/hashicorp/vault/internalshared/configutil"
|
||||
|
||||
func IsValidListener(listener *configutil.Listener) error {
|
||||
return nil
|
||||
}
|
||||
@ -38,7 +38,6 @@ import (
|
||||
"github.com/hashicorp/go-secure-stdlib/parseutil"
|
||||
"github.com/hashicorp/go-secure-stdlib/reloadutil"
|
||||
"github.com/hashicorp/vault/audit"
|
||||
config2 "github.com/hashicorp/vault/command/config"
|
||||
"github.com/hashicorp/vault/command/server"
|
||||
"github.com/hashicorp/vault/helper/builtinplugins"
|
||||
"github.com/hashicorp/vault/helper/constants"
|
||||
@ -443,7 +442,7 @@ func (c *ServerCommand) parseConfig() (*server.Config, []configutil.ConfigError,
|
||||
}
|
||||
|
||||
if config != nil && config.Entropy != nil && config.Entropy.Mode == configutil.EntropyAugmentation && constants.IsFIPS() {
|
||||
c.UI.Warn("WARNING: Entropy Augmentation is not supported in FIPS 140-2 Inside mode; disabling from server configuration!\n")
|
||||
c.UI.Warn("WARNING: Entropy Augmentation is not supported in FIPS 140-3 Inside mode; disabling from server configuration!\n")
|
||||
config.Entropy = nil
|
||||
}
|
||||
entCheckRequestLimiter(c, config)
|
||||
@ -3128,10 +3127,6 @@ func startHttpServers(c *ServerCommand, core *vault.Core, config *server.Config,
|
||||
return fmt.Errorf("found nil listener config after parsing")
|
||||
}
|
||||
|
||||
if err := config2.IsValidListener(ln.Config); err != nil {
|
||||
return err
|
||||
}
|
||||
|
||||
handler := vaulthttp.Handler.Handler(&vault.HandlerProperties{
|
||||
Core: core,
|
||||
ListenerConfig: ln.Config,
|
||||
|
||||
@ -21,14 +21,14 @@ scenario "dev_pr_replication" {
|
||||
arch = ["amd64", "arm64"]
|
||||
artifact = ["local", "deb", "rpm", "zip"]
|
||||
distro = ["amzn", "leap", "rhel", "sles", "ubuntu"]
|
||||
edition = ["ent", "ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
|
||||
edition = ["ent", "ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
|
||||
primary_backend = ["consul", "raft"]
|
||||
primary_seal = ["awskms", "pkcs11", "shamir"]
|
||||
secondary_backend = ["consul", "raft"]
|
||||
secondary_seal = ["awskms", "pkcs11", "shamir"]
|
||||
|
||||
exclude {
|
||||
edition = ["ent.hsm", "ent.fips1402", "ent.hsm.fips1402"]
|
||||
edition = ["ent.hsm", "ent.fips1403", "ent.hsm.fips1403"]
|
||||
arch = ["arm64"]
|
||||
}
|
||||
|
||||
@ -49,12 +49,12 @@ scenario "dev_pr_replication" {
|
||||
|
||||
exclude {
|
||||
primary_seal = ["pkcs11"]
|
||||
edition = ["ce", "ent", "ent.fips1402"]
|
||||
edition = ["ce", "ent", "ent.fips1403"]
|
||||
}
|
||||
|
||||
exclude {
|
||||
secondary_seal = ["pkcs11"]
|
||||
edition = ["ce", "ent", "ent.fips1402"]
|
||||
edition = ["ce", "ent", "ent.fips1403"]
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@ -21,11 +21,11 @@ scenario "dev_single_cluster" {
|
||||
artifact = ["local", "deb", "rpm", "zip"]
|
||||
backend = ["consul", "raft"]
|
||||
distro = ["amzn", "leap", "rhel", "sles", "ubuntu"]
|
||||
edition = ["ce", "ent", "ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
|
||||
edition = ["ce", "ent", "ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
|
||||
seal = ["awskms", "pkcs11", "shamir"]
|
||||
|
||||
exclude {
|
||||
edition = ["ent.hsm", "ent.fips1402", "ent.hsm.fips1402"]
|
||||
edition = ["ent.hsm", "ent.fips1403", "ent.hsm.fips1403"]
|
||||
arch = ["arm64"]
|
||||
}
|
||||
|
||||
@ -46,7 +46,7 @@ scenario "dev_single_cluster" {
|
||||
|
||||
exclude {
|
||||
seal = ["pkcs11"]
|
||||
edition = ["ce", "ent", "ent.fips1402"]
|
||||
edition = ["ce", "ent", "ent.fips1403"]
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@ -11,9 +11,9 @@ globals {
|
||||
build_tags = {
|
||||
"ce" = ["ui"]
|
||||
"ent" = ["ui", "enterprise", "ent"]
|
||||
"ent.fips1402" = ["ui", "enterprise", "cgo", "hsm", "fips", "fips_140_2", "ent.fips1402"]
|
||||
"ent.fips1403" = ["ui", "enterprise", "cgo", "hsm", "fips", "fips_140_3", "ent.fips1403"]
|
||||
"ent.hsm" = ["ui", "enterprise", "cgo", "hsm", "venthsm"]
|
||||
"ent.hsm.fips1402" = ["ui", "enterprise", "cgo", "hsm", "fips", "fips_140_2", "ent.hsm.fips1402"]
|
||||
"ent.hsm.fips1403" = ["ui", "enterprise", "cgo", "hsm", "fips", "fips_140_3", "ent.hsm.fips1403"]
|
||||
}
|
||||
config_modes = ["env", "file"]
|
||||
consul_editions = ["ce", "ent"]
|
||||
@ -51,7 +51,7 @@ globals {
|
||||
sles = var.distro_version_sles
|
||||
ubuntu = var.distro_version_ubuntu
|
||||
}
|
||||
editions = ["ce", "ent", "ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
|
||||
editions = ["ce", "ent", "ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
|
||||
enterprise_editions = [for e in global.editions : e if e != "ce"]
|
||||
ip_versions = ["4", "6"]
|
||||
package_manager = {
|
||||
|
||||
@ -58,7 +58,7 @@ scenario "agent" {
|
||||
artifact_type = ["package"]
|
||||
}
|
||||
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
|
||||
exclude {
|
||||
seal = ["pkcs11"]
|
||||
edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]
|
||||
|
||||
@ -63,10 +63,10 @@ scenario "autopilot" {
|
||||
// versions after our initial publication of these editions for arm64.
|
||||
exclude {
|
||||
arch = ["arm64"]
|
||||
edition = ["ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
|
||||
edition = ["ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
|
||||
}
|
||||
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
|
||||
exclude {
|
||||
seal = ["pkcs11"]
|
||||
edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]
|
||||
|
||||
@ -65,7 +65,7 @@ scenario "dr_replication" {
|
||||
artifact_type = ["package"]
|
||||
}
|
||||
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
|
||||
exclude {
|
||||
primary_seal = ["pkcs11"]
|
||||
edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]
|
||||
|
||||
@ -65,7 +65,7 @@ scenario "pr_replication" {
|
||||
artifact_type = ["package"]
|
||||
}
|
||||
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
|
||||
exclude {
|
||||
primary_seal = ["pkcs11"]
|
||||
edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]
|
||||
|
||||
@ -58,7 +58,7 @@ scenario "proxy" {
|
||||
artifact_type = ["package"]
|
||||
}
|
||||
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
|
||||
exclude {
|
||||
seal = ["pkcs11"]
|
||||
edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]
|
||||
|
||||
@ -63,7 +63,7 @@ scenario "seal_ha" {
|
||||
artifact_type = ["package"]
|
||||
}
|
||||
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
|
||||
exclude {
|
||||
primary_seal = ["pkcs11"]
|
||||
edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]
|
||||
|
||||
@ -57,7 +57,7 @@ scenario "smoke" {
|
||||
artifact_type = ["package"]
|
||||
}
|
||||
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1402.
|
||||
// PKCS#11 can only be used on ent.hsm and ent.hsm.fips1403.
|
||||
exclude {
|
||||
seal = ["pkcs11"]
|
||||
edition = [for e in matrix.edition : e if !strcontains(e, "hsm")]
|
||||
|
||||
@ -64,7 +64,7 @@ scenario "upgrade" {
|
||||
// versions after our initial publication of these editions for arm64.
|
||||
exclude {
|
||||
arch = ["arm64"]
|
||||
edition = ["ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
|
||||
edition = ["ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
|
||||
}
|
||||
|
||||
// PKCS#11 can only be used with hsm editions
|
||||
|
||||
@ -11,7 +11,7 @@ scenario "k8s" {
|
||||
EOF
|
||||
|
||||
matrix {
|
||||
edition = ["ce", "ent", "ent.fips1402", "ent.hsm", "ent.hsm.fips1402"]
|
||||
edition = ["ce", "ent", "ent.fips1403", "ent.hsm", "ent.hsm.fips1403"]
|
||||
repo = ["docker", "ecr", "quay"]
|
||||
}
|
||||
|
||||
@ -68,7 +68,7 @@ scenario "k8s" {
|
||||
tag = local.tag_version_ubi
|
||||
}
|
||||
},
|
||||
"ent.fips1402" = {
|
||||
"ent.fips1403" = {
|
||||
docker = {
|
||||
// https://hub.docker.com/r/hashicorp/vault-enterprise-fips
|
||||
repo = "hashicorp/vault-enterprise-fips"
|
||||
@ -102,7 +102,7 @@ scenario "k8s" {
|
||||
tag = local.tag_version_ubi
|
||||
}
|
||||
},
|
||||
"ent.hsm.fips1402" = {
|
||||
"ent.hsm.fips1403" = {
|
||||
docker = {
|
||||
// https://hub.docker.com/r/hashicorp/vault-enterprise
|
||||
repo = "hashicorp/vault-enterprise"
|
||||
|
||||
@ -27,8 +27,8 @@ case "${VAULT_EDITION}" in
|
||||
ce) version_expected="${vault_expected_version}${expected_build_date}" ;;
|
||||
ent) version_expected="${vault_expected_version}${expected_build_date}" ;;
|
||||
ent.hsm) version_expected="${vault_expected_version}${expected_build_date} (cgo)" ;;
|
||||
ent.fips1402) version_expected="${vault_expected_version}${expected_build_date} (cgo)" ;;
|
||||
ent.hsm.fips1402) version_expected="${vault_expected_version}${expected_build_date} (cgo)" ;;
|
||||
ent.fips1403) version_expected="${vault_expected_version}${expected_build_date} (cgo)" ;;
|
||||
ent.hsm.fips1403) version_expected="${vault_expected_version}${expected_build_date} (cgo)" ;;
|
||||
*) fail "(${VAULT_EDITION}) does not match any known Vault editions" ;;
|
||||
esac
|
||||
|
||||
|
||||
@ -32,8 +32,8 @@ case "$edition" in
|
||||
*ce) ;;
|
||||
*ent) ;;
|
||||
*ent.hsm) version_expected="$version_expected (cgo)" ;;
|
||||
*ent.fips1402) version_expected="$version_expected (cgo)" ;;
|
||||
*ent.hsm.fips1402) version_expected="$version_expected (cgo)" ;;
|
||||
*ent.fips1403) version_expected="$version_expected (cgo)" ;;
|
||||
*ent.hsm.fips1403) version_expected="$version_expected (cgo)" ;;
|
||||
*) fail "Unknown Vault edition: ($edition)" ;;
|
||||
esac
|
||||
|
||||
|
||||
@ -16,6 +16,7 @@ import (
|
||||
"fmt"
|
||||
mathrand "math/rand"
|
||||
"reflect"
|
||||
"runtime"
|
||||
"strconv"
|
||||
"strings"
|
||||
"sync"
|
||||
@ -991,11 +992,6 @@ func Test_RSA_PSS(t *testing.T) {
|
||||
t.Log(tabs[3], "Make an automatic signature")
|
||||
sig, err := p.Sign(0, nil, input, hashType, sigAlgorithm, marshalingType)
|
||||
if err != nil {
|
||||
// A bit of a hack but FIPS go does not support some hash types
|
||||
if isUnsupportedGoHashType(hashType, err) {
|
||||
t.Skip(tabs[4], "skipping test as FIPS Go does not support hash type")
|
||||
return
|
||||
}
|
||||
t.Fatal(tabs[4], "❌ Failed to automatically sign:", err)
|
||||
}
|
||||
|
||||
@ -1192,15 +1188,20 @@ func Test_RSA_PKCS1Signing(t *testing.T) {
|
||||
input = hash.Sum(nil)
|
||||
}
|
||||
|
||||
// Skip over SHA3 hash tests when running with boringcrypto as it still doesn't support it or hasn't been
|
||||
// validated yet. Wasn't available in FIPS-140-2, but should be in FIPS-140-3 eventually?
|
||||
if strings.Contains(runtime.Version(), "X:boringcrypto") {
|
||||
switch hashType {
|
||||
case HashTypeSHA3224, HashTypeSHA3256, HashTypeSHA3384, HashTypeSHA3512:
|
||||
t.Skip(tabs[4], "boringcrypto does not support SHA3")
|
||||
return
|
||||
}
|
||||
}
|
||||
|
||||
// 1. Make a signature with the given key size and hash algorithm.
|
||||
t.Log(tabs[3], "Make an automatic signature")
|
||||
sig, err := p.Sign(0, nil, input, hashType, sigAlgorithm, marshalingType)
|
||||
if err != nil {
|
||||
// A bit of a hack but FIPS go does not support some hash types
|
||||
if isUnsupportedGoHashType(hashType, err) {
|
||||
t.Skip(tabs[4], "skipping test as FIPS Go does not support hash type")
|
||||
return
|
||||
}
|
||||
t.Fatal(tabs[4], "❌ Failed to automatically sign:", err)
|
||||
}
|
||||
|
||||
@ -1246,15 +1247,3 @@ func Test_RSA_PKCS1Signing(t *testing.T) {
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Normal Go builds support all the hash functions for RSA_PSS signatures but the
|
||||
// FIPS Go build does not support at this time the SHA3 hashes as FIPS 140_2 does
|
||||
// not accept them.
|
||||
func isUnsupportedGoHashType(hashType HashType, err error) bool {
|
||||
switch hashType {
|
||||
case HashTypeSHA3224, HashTypeSHA3256, HashTypeSHA3384, HashTypeSHA3512:
|
||||
return strings.Contains(err.Error(), "unsupported hash function")
|
||||
}
|
||||
|
||||
return false
|
||||
}
|
||||
|
||||
@ -410,9 +410,6 @@ engine override the issuer as necessary.
|
||||
- `key_type` `(string: "rsa")` - Specifies the desired key type; must be `rsa`, `ed25519`
|
||||
or `ec`.
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `ed25519`.
|
||||
|
||||
- `key_bits` `(int: 0)` - Specifies the number of bits to use for the
|
||||
generated keys. Allowed values are 0 (universal default); with
|
||||
`key_type=rsa`, allowed values are: 2048 (default), 3072, 4096 or 8192;
|
||||
@ -2002,9 +1999,6 @@ used.
|
||||
- `key_type` `(string: "rsa")` - Specifies the desired key type; must be `rsa`, `ed25519`
|
||||
or `ec`.
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `ed25519`.
|
||||
|
||||
- `key_bits` `(int: 0)` - Specifies the number of bits to use for the
|
||||
generated keys. Allowed values are 0 (universal default); with
|
||||
`key_type=rsa`, allowed values are: 2048 (default), 3072, 4096 or 8192;
|
||||
@ -2149,9 +2143,6 @@ use the values set via `config/urls`.
|
||||
- `key_type` `(string: "rsa")` - Specifies the desired key type; must be `rsa`, `ed25519`
|
||||
or `ec`.
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `ed25519`.
|
||||
|
||||
- `key_bits` `(int: 0)` - Specifies the number of bits to use for the
|
||||
generated keys. Allowed values are 0 (universal default); with
|
||||
`key_type=rsa`, allowed values are: 2048 (default), 3072, 4096 or 8192;
|
||||
@ -2396,9 +2387,6 @@ generated depending on the `type` request parameter.
|
||||
- `key_type` `(string: "rsa")` - Specifies the desired key type; must be `rsa`, `ed25519`
|
||||
or `ec`. Not suitable for `type=existing` requests.
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `ed25519`.
|
||||
|
||||
~> **Note**: Keys of type `rsa` currently only support PKCS#1 v1.5 signatures.
|
||||
This includes any managed keys.
|
||||
|
||||
@ -3345,9 +3333,6 @@ request is denied.
|
||||
When `any` is used, this role cannot generate certificates and can only
|
||||
be used to sign CSRs.
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `ed25519`.
|
||||
|
||||
- `key_bits` `(int: 0)` - Specifies the number of bits to use for the
|
||||
generated keys. Allowed values are 0 (universal default); with
|
||||
`key_type=rsa`, allowed values are: 2048 (default), 3072, 4096 or 8192;
|
||||
|
||||
@ -168,9 +168,6 @@ This endpoint creates or updates a named role.
|
||||
with `ecdsa-sha2-nistp256` or `ed25519`), the value of the length is ignored (and
|
||||
can be zero).
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `ed25519`.
|
||||
|
||||
- `allow_empty_principals` `(bool: false)` - Allow signing certificates with
|
||||
no valid principals (e.g. any valid principal). For backwards
|
||||
compatibility only. The default of false is highly recommended.
|
||||
@ -589,9 +586,6 @@ overridden._
|
||||
`ecdsa-sha2-nistp384`, `ecdsa-sha2-nistp521`, or `ssh-ed25519`) or an
|
||||
algorithm (`rsa`, `ec`, or `ed25519`).
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `ed25519`.
|
||||
|
||||
- `key_bits` `(int: 0)` - Specifies the desired key bits for the generated SSH
|
||||
CA key when `generate_signing_key` is set to `true`. This is only used for
|
||||
variable length keys (such as `ssh-rsa`, where the value of `key_bits`
|
||||
|
||||
@ -70,8 +70,8 @@ values set here cannot be changed after key creation.
|
||||
- `ml-dsa` - ML-DSA (asymmetric) (experimental) <EnterpriseAlert inline="true" />
|
||||
- `hybrid` - hybrid signatures combining a post-quantum algorithm and an elliptic curve algorithm (asymmetric) (experimental) <EnterpriseAlert inline="true" />
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `chacha20-poly1305` and `ed25519`.
|
||||
~> **Note**: In FIPS 140-3 mode, the following algorithms are not certified
|
||||
and thus should not be used: `chacha20-poly1305`.
|
||||
|
||||
~> **Note**: All key types support HMAC through the use of a second randomly
|
||||
generated key created key creation time or rotation. The HMAC key type only
|
||||
@ -1270,10 +1270,6 @@ algorithm.
|
||||
- `sha3-384`
|
||||
- `sha3-512`
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `sha3-224`, `sha3-256`, `sha3-384`, and
|
||||
`sha3-512`.
|
||||
|
||||
- `input` `(string: <required>)` – Specifies the **base64 encoded** input data.
|
||||
|
||||
- `format` `(string: "hex")` – Specifies the output encoding. This can be either
|
||||
@ -1340,10 +1336,6 @@ be used.
|
||||
- `sha3-384`
|
||||
- `sha3-512`
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `sha3-224`, `sha3-256`, `sha3-384`, and
|
||||
`sha3-512`.
|
||||
|
||||
- `input` `(string: "")` – Specifies the **base64 encoded** input data. One of
|
||||
`input` or `batch_input` must be supplied.
|
||||
|
||||
@ -1479,10 +1471,6 @@ supports signing.
|
||||
- `sha3-512`
|
||||
- `none`
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `sha3-224`, `sha3-256`, `sha3-384`, and
|
||||
`sha3-512`.
|
||||
|
||||
~> ** Warning:** `sha1` should be considered a compromised algorithm and used
|
||||
only for legacy applications. Signing using SHA-1 can be blocked by operators by
|
||||
assigning the following policy corresponding to a named key:
|
||||
@ -1670,10 +1658,6 @@ or [generate CMAC](#generate-cmac) API calls.
|
||||
- `sha3-512`
|
||||
- `none`
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `sha3-224`, `sha3-256`, `sha3-384`, and
|
||||
`sha3-512`.
|
||||
|
||||
~> ** Warning:** `sha1` should be considered a compromised algorithm. Signatures
|
||||
verified using the algorithm could be forgeries. Verification using SHA-1 can
|
||||
be blocked by operators by assigning the following policy corresponding to a
|
||||
|
||||
@ -80,10 +80,6 @@ algorithm.
|
||||
- `sha3-384`
|
||||
- `sha3-512`
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
and thus should not be used: `sha3-224`, `sha3-256`, `sha3-384`, and
|
||||
`sha3-512`.
|
||||
|
||||
- `input` `(string: <required>)` – Specifies the **base64 encoded** input data.
|
||||
|
||||
- `format` `(string: "hex")` – Specifies the output encoding. This can be either
|
||||
|
||||
@ -22,7 +22,7 @@ from seals in priority order, using bytes from the first available and online se
|
||||
|
||||
A valid Vault Enterprise license is required for Entropy Augmentation.
|
||||
|
||||
~> **Warning** This feature is not available with FIPS 140-2 Inside variants of Vault.
|
||||
~> **Warning** This feature is not available with FIPS 140-3 Inside variants of Vault.
|
||||
|
||||
Additionally, the following software packages and enterprise modules are required for sourcing entropy
|
||||
via the [PKCS11 seal](/vault/docs/configuration/seal/pkcs11):
|
||||
|
||||
@ -10,7 +10,7 @@ description: >-
|
||||
@include 'alerts/enterprise-only.mdx'
|
||||
|
||||
<Warning>
|
||||
Entropy augmentation <b>is not</b> available with "FIPS 140-2 Inside" variants of
|
||||
Entropy augmentation <b>is not</b> available with "FIPS 140-3 Inside" variants of
|
||||
Vault.
|
||||
</Warning>
|
||||
|
||||
|
||||
@ -1,26 +1,26 @@
|
||||
---
|
||||
layout: docs
|
||||
page_title: Built-in FIPS 140-2 support
|
||||
page_title: Built-in FIPS 140-3 support
|
||||
description: >-
|
||||
Learn about the FIPS build of Vault, which has FIPS 140-2 support built into
|
||||
Learn about the FIPS build of Vault, which has FIPS 140-3 support built into
|
||||
the Vault binary for FIPS compliance.
|
||||
---
|
||||
|
||||
# Built-in FIPS 140-2 support
|
||||
# Built-in FIPS 140-3 support
|
||||
|
||||
@include 'alerts/enterprise-only.mdx'
|
||||
|
||||
Special builds of Vault Enterprise (marked with a `fips1402` feature name)
|
||||
include built-in support for FIPS 140-2 compliance. Unlike using Seal Wrap
|
||||
Special builds of Vault Enterprise (marked with a `fips1403` feature name)
|
||||
include built-in support for FIPS 140-3 compliance. Unlike using Seal Wrap
|
||||
for FIPS compliance, this binary has no external dependencies on a HSM.
|
||||
|
||||
To use this feature, you must have an active or trial license for Vault
|
||||
Enterprise Plus (HSMs). To start a trial, contact [HashiCorp
|
||||
sales](mailto:sales@hashicorp.com).
|
||||
|
||||
## Using FIPS 140-2 Vault enterprise
|
||||
## Using FIPS 140-3 Vault enterprise
|
||||
|
||||
FIPS 140-2 Inside versions of Vault Enterprise behave like non-FIPS versions
|
||||
FIPS 140-3 Inside versions of Vault Enterprise behave like non-FIPS versions
|
||||
of Vault. No restrictions are placed on algorithms; it is up to the operator
|
||||
to ensure Vault remains in a FIPS-compliant mode of operation. This means
|
||||
configuring some Secrets Engines to permit a limited set of algorithms (e.g.,
|
||||
@ -29,7 +29,7 @@ forbidding ed25519-based CAs with PKI Secrets Engines).
|
||||
Because Vault Enterprise may return secrets in plain text, it is important to
|
||||
ensure the Vault server's `listener` configuration section utilizes TLS. This
|
||||
ensures secrets are transmitted securely from Server to Client. Additionally,
|
||||
note that TLSv1.3 will not work with FIPS 140-2 Inside, as HKDF is not a
|
||||
note that TLSv1.3 will not work with FIPS 140-3 Inside, as HKDF is not a
|
||||
certified primitive. If TLSv1.3 is desired, it is suggested to front Vault
|
||||
Server with a FIPS-certified load balancer.
|
||||
|
||||
@ -41,8 +41,8 @@ A non-exhaustive list of potential compliance issues include:
|
||||
- Using a Derived Key (using HKDF) for Agent auto-authing or the Transit
|
||||
Secrets Engine.
|
||||
- Using **Entropy Augmentation**: because BoringCrypto uses its internal,
|
||||
FIPS 140-2 approved RNG, it cannot mix entropy from other sources.
|
||||
Attempting to use EA with FIPS 140-2 HSM enabled binaries will result
|
||||
FIPS 140-3 approved RNG, it cannot mix entropy from other sources.
|
||||
Attempting to use EA with FIPS 140-3 HSM enabled binaries will result
|
||||
in failures such as `panic: boringcrypto: invalid code execution`.
|
||||
|
||||
Hashicorp can only provide general guidance regarding using Vault Enterprise
|
||||
@ -50,11 +50,11 @@ in a FIPS-compliant manner. We are not a NIST-certified testing laboratory
|
||||
and thus organizations may need to consult an approved auditor for final
|
||||
information.
|
||||
|
||||
The FIPS 140-2 variant of Vault uses separate binaries; these are available
|
||||
The FIPS 140-3 variant of Vault uses separate binaries; these are available
|
||||
from the following sources:
|
||||
|
||||
- From the [Hashicorp Releases Page](https://releases.hashicorp.com/vault),
|
||||
ending with the `+ent.fips1402` and `+ent.hsm.fips1402` suffixes.
|
||||
ending with the `+ent.fips1403` and `+ent.hsm.fips1403` suffixes.
|
||||
- From the [Docker Hub `hashicorp/vault-enterprise-fips`](https://hub.docker.com/r/hashicorp/vault-enterprise-fips)
|
||||
container repository.
|
||||
- From the [AWS ECR `hashicorp/vault-enterprise-fips`](https://gallery.ecr.aws/hashicorp/vault-enterprise-fips)
|
||||
@ -90,15 +90,15 @@ reasons:
|
||||
|
||||
As such Hashicorp cannot provide support for workloads that are affected
|
||||
either technically or via non-compliance that results from converting
|
||||
existing cluster workloads to the FIPS 140-2 Inside binary.
|
||||
existing cluster workloads to the FIPS 140-3 Inside binary.
|
||||
|
||||
Instead, we suggest leaving the existing cluster in place, and carefully
|
||||
consider migration of specific workloads to the FIPS-backed cluster.
|
||||
|
||||
#### Entropy augmentation restrictions
|
||||
|
||||
Entropy Augmentation **does not** work with FIPS 140-2 Inside. The internal
|
||||
BoringCrypto RNG is FIPS 140-2 certified and does not accept entropy from
|
||||
Entropy Augmentation **does not** work with FIPS 140-3 Inside. The internal
|
||||
BoringCrypto RNG is FIPS 140-3 certified and does not accept entropy from
|
||||
other sources. On Vault 1.11.0 and later, attempting to use Entropy
|
||||
Augmentation will result in a warning ("Entropy Augmentation is not supported...")
|
||||
and Entropy Augmentation will be disabled.
|
||||
@ -121,9 +121,6 @@ Additionally, only the following key types are allowed in TLS chains of trust:
|
||||
- RSA 2048, 3072, 4096, 7680, and 8192-bit;
|
||||
- ECDSA P-256, P-384, and P-521.
|
||||
|
||||
Finally, only TLSv1.2 or higher is supported in FIPS mode. These are in line
|
||||
with recent NIST guidance and recommendations.
|
||||
|
||||
#### Heterogeneous cluster deployments
|
||||
|
||||
Hashicorp does not support mixed deployment scenarios within the same Vault
|
||||
@ -137,30 +134,30 @@ the system are not compliant with FIPS.
|
||||
|
||||
## Technical details
|
||||
|
||||
Vault Enterprise's FIPS 140-2 Inside binaries rely on a special version of the
|
||||
Vault Enterprise's FIPS 140-3 Inside binaries rely on a special version of the
|
||||
Go toolchain which include a FIPS-validated BoringCrypto version. To ensure
|
||||
your version of Vault Enterprise includes FIPS support, after starting the
|
||||
server, make sure you see a line with `Fips: Enabled`, such as:
|
||||
|
||||
```
|
||||
Fips: FIPS 140-2 Enabled, BoringCrypto version 7
|
||||
Fips: FIPS 140-3 Enabled, BoringCrypto version 7
|
||||
```
|
||||
|
||||
~> **Note**: FIPS 140-2 Inside binaries depend on cgo, which require that a
|
||||
~> **Note**: FIPS 140-3 Inside binaries depend on cgo, which require that a
|
||||
GNU C Library (glibc) Linux distribution be used to run Vault. We've
|
||||
additionally opted to certify only on the AMD64 architecture at this time.
|
||||
This means these binaries will not work on Alpine Linux based containers.
|
||||
|
||||
### FIPS 140-2 inside and external plugins
|
||||
### FIPS 140-3 inside and external plugins
|
||||
|
||||
Vault Enterprise's built-in plugins are compiled into the Vault binary using
|
||||
the same Go toolchain version that compiled the core Vault; this results in
|
||||
these plugins having FIPS 140-2 compliance status as well. This same guarantee
|
||||
these plugins having FIPS 140-3 compliance status as well. This same guarantee
|
||||
does not apply to external plugins.
|
||||
|
||||
### Validating FIPS 140-2 inside
|
||||
### Validating FIPS 140-3 inside
|
||||
|
||||
To validate that the FIPS 140-2 Inside binary correctly includes BoringCrypto,
|
||||
To validate that the FIPS 140-3 Inside binary correctly includes BoringCrypto,
|
||||
run `go tool nm` on the binary to get a symbol dump. On non-FIPS builds,
|
||||
searching for `goboringcrypto` in the output will yield no results, but on
|
||||
FIPS-enabled builds, you'll see many results with this:
|
||||
@ -228,30 +225,19 @@ with the FIPS integrity check succeeding.
|
||||
|
||||
### BoringCrypto certification
|
||||
|
||||
BoringCrypto Version 7 uses the following FIPS 140-2 Certificate and software
|
||||
BoringCrypto Version 7 uses the following FIPS 140-3 Certificate and software
|
||||
version:
|
||||
|
||||
- NIST CMVP [Certificate #3678](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3678).
|
||||
- BoringSSL Release [`ae223d6138807a13006342edfeef32e813246b39`](https://github.com/google/boringssl/commit/ae223d6138807a13006342edfeef32e813246b39).
|
||||
- NIST CMVP [Certificate #4735](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/4735).
|
||||
- BoringCrypto software version 2022061300
|
||||
|
||||
The following algorithms were certified as part of this release:
|
||||
-### Leidos compliance
|
||||
|
||||
- RSA in all key sizes greater than or equal to 2048 bits (tested at 2048
|
||||
and 3072 bits),
|
||||
- ECDSA and ECDH with P-224 (not accessible from Vault), P-256, P-384, and
|
||||
P-521,
|
||||
- AES symmetric encryption with 128/192/256-bit CBC, ECB, and CRT modes and
|
||||
128/256-bit GCM modes,
|
||||
- SHA-1 and SHA-2 (224, 256,384, and 512-bit variants),
|
||||
- HMAC+SHA-2 with 224, 256, 384, and 512-bit variants of SHA-2,
|
||||
- TLSv1.0/TLSv1.1 and TLSv1.2 KDFs,
|
||||
- AES-256 based CRT_DRBG CS-PRNG.
|
||||
Leidos evaluated Vault for compliance with the FIPS 140-2 version of BoringCrypto. HashiCorp will be seeking an evaluation against FIPS 140-3
|
||||
in the near future. In the meantime, Vault has not modified it's integration with BoringCrypto since the FIPS 140-2 evaluation except to
|
||||
enable TLS 1.3 as is now allowed by the standard, and BoringCrypto itself is largely unchanged and has been certified as FIPS 140-3 validated.
|
||||
|
||||
### Leidos compliance
|
||||
|
||||
See the updated [Leidos Compliance Letter (V Entr v1.10.0+entrfips) for FIPS Inside](https://www.datocms-assets.com/2885/1653327036-boringcrypto_compliance_letter_signed.pdf) using the Boring Crypto Libraries for more details. All [past letters](https://www.hashicorp.com/vault-compliance) are also available for reference.
|
||||
|
||||
What is the difference between Seal Wrap FIPS 140 compliance and the new FIPS Inside compliance?
|
||||
-What is the difference between Seal Wrap FIPS 140 compliance and the new FIPS Inside compliance?
|
||||
- Only the storage of sensitive entries (seal wrapped entries) is covered by FIPS-validated crypto when using Seal Wrapping.
|
||||
- The TLS connection to Vault by clients is not covered by FIPS-validated crypto when using Seal Wrapping (it is when using FIPS 140-2 Inside, per items 1, 2, 7, and 13 in the updated letter).
|
||||
- The generation of key material wasn't using FIPS-validated crypto in the Seal Wrap version (for example, the PKI certificates: item 8 in the updated FIPS 140-2 Inside letter; or SSH module: item 10 in the updated FIPS 140-2 Inside letter).
|
||||
@ -14,16 +14,16 @@ is a cryptography-focused certification standard for U.S. Government usage.
|
||||
|
||||
Hashicorp's Vault Enterprise supports the modes of FIPS compliance documented below.
|
||||
|
||||
## FIPS 140-2 inside
|
||||
## FIPS 140-3 inside
|
||||
|
||||
Vault Enterprise now includes release flavors with FIPS 140-2 compliant
|
||||
Vault Enterprise now includes release flavors with FIPS 140-3 compliant
|
||||
cryptography built into the Vault binary. More information on these releases
|
||||
can be found on the [FIPS 140-2 Inside](/vault/docs/enterprise/fips/fips1402) page.
|
||||
can be found on the [FIPS 140-3 Inside](/vault/docs/enterprise/fips/fips1403) page.
|
||||
|
||||
## Seal wrap
|
||||
|
||||
Before our FIPS Inside effort, Vault [depended on](https://www.hashicorp.com/vault-compliance)
|
||||
an external HSM for FIPS 140-2 compliance. This uses the [Seal Wrap](/vault/docs/enterprise/fips/sealwrap)
|
||||
an external HSM for FIPS 140-2/3 compliance. This uses the [Seal Wrap](/vault/docs/enterprise/fips/sealwrap)
|
||||
functionality to wrap security relevant keys in an extra layer of encryption.
|
||||
|
||||
## Comparison of versions
|
||||
|
||||
@ -3,7 +3,7 @@ layout: docs
|
||||
page_title: Wrap seals with encryption
|
||||
description: >-
|
||||
Wrap sealed data with an extra layer of encryption to honor increased
|
||||
compliance and regulatory requirements including FIPS 140-2.
|
||||
compliance and regulatory requirements including FIPS 140-2/3.
|
||||
---
|
||||
|
||||
# Wrap seals with encryption
|
||||
@ -13,7 +13,7 @@ description: >-
|
||||
Vault Enterprise features a mechanism to wrap values with an extra layer of
|
||||
encryption for supported [seals](/vault/docs/configuration/seal). This adds an
|
||||
extra layer of protection and is useful in some compliance and regulatory
|
||||
environments, including FIPS 140-2 environments.
|
||||
environments, including FIPS 140-2/3 environments.
|
||||
|
||||
To use this feature, you must have an active or trial license for Vault
|
||||
Enterprise Plus (HSMs). To start a trial, contact [HashiCorp
|
||||
@ -23,10 +23,10 @@ sales](mailto:sales@hashicorp.com).
|
||||
|
||||
Your Vault deployments can gain the following benefits by enabling seal wrapping:
|
||||
|
||||
- Conformance with FIPS 140-2 directives on Key Storage and Key Transport as [certified by Leidos](/vault/docs/enterprise/sealwrap#fips-140-2-compliance)
|
||||
- Conformance with FIPS 140-2/3 directives on Key Storage and Key Transport as [certified by Leidos](/vault/docs/enterprise/sealwrap#fips-140-2-compliance)
|
||||
- Supports FIPS level of security equal to HSM
|
||||
- For example, if you use Level 3 hardware encryption on an HSM, Vault will be
|
||||
using FIPS 140-2 Level 3 cryptography
|
||||
using FIPS 140-3 Level 3 cryptography
|
||||
- Enables Vault deployments in high security [GRC](https://en.wikipedia.org/wiki/Governance,_risk_management,_and_compliance)
|
||||
environments (e.g. PCI-DSS, HIPAA) where FIPS guidelines important for external audits
|
||||
- Pathway to use Vault for managing Department of Defense (DOD) or North
|
||||
|
||||
@ -15,10 +15,10 @@ advanced data protection features.
|
||||
|
||||
[Vault Enterprise supports IPv6](https://www.hashicorp.com/trust/compliance/vault-enterprise)
|
||||
in compliance with OMB Mandate M-21-07 and Federal IPv6 policy requirements
|
||||
for the following operating systems and storage backends.
|
||||
for the following operating systems and storage backends.
|
||||
|
||||
**Self-attested testing covers functionality related to HSM, FIPS 140-2, and
|
||||
HSM/FIPS 140-2.**
|
||||
**Self-attested testing covers functionality related to HSM, FIPS 140-3, and
|
||||
HSM/FIPS 140-3.**
|
||||
|
||||
## OS validation
|
||||
|
||||
|
||||
@ -93,7 +93,7 @@ types also generate separate HMAC keys):
|
||||
- `ml-dsa` - ML-DSA; supports signing and signature verification (experimental) <EnterpriseAlert inline="true" />
|
||||
- `hybrid` - combination of two signature algorithms; supports signing and signature verification (experimental) <EnterpriseAlert inline="true" />
|
||||
|
||||
~> **Note**: In FIPS 140-2 mode, the following algorithms are not certified
|
||||
~> **Note**: In FIPS 140-3 mode, the following algorithms are not certified
|
||||
and thus should not be used: `chacha20-poly1305` and `ed25519`.
|
||||
|
||||
~> **Note**: All key types support HMAC operations through the use of a second randomly
|
||||
|
||||
@ -2809,8 +2809,8 @@
|
||||
"path": "enterprise/fips"
|
||||
},
|
||||
{
|
||||
"title": "Built-in FIPS 140-2 support",
|
||||
"path": "enterprise/fips/fips1402"
|
||||
"title": "Built-in FIPS 140-3 support",
|
||||
"path": "enterprise/fips/fips1403"
|
||||
},
|
||||
{
|
||||
"title": "Seal wrap for FIPS compliance",
|
||||
|
||||
Loading…
Reference in New Issue
Block a user