1--- 2layout: "docs" 3page_title: "Vault Enterprise Seal Wrap" 4sidebar_title: "Seal Wrap / FIPS 140-2" 5sidebar_current: "docs-vault-enterprise-sealwrap" 6description: |- 7 Vault Enterprise features a mechanism to wrap values with an extra layer of 8 encryption for supporting seals 9--- 10 11# Seal Wrap 12 13Vault Enterprise features a mechanism to wrap values with an extra layer of 14encryption for supporting [seals](/docs/configuration/seal/index.html). This adds an 15extra layer of protection and is useful in some compliance and regulatory 16environments, including FIPS 140-2 environments. 17 18To use this feature, you must have an active or trial license for Vault 19Enterprise (HSMs) or Vault Pro (AWS KMS). To start a trial, contact [HashiCorp 20sales](mailto:sales@hashicorp.com). 21 22## Enabling/Disabling 23 24Seal Wrap is enabled by default on supporting seals. This implies that the seal 25must be available throughout Vault's runtime. Most cloud-based seals should be 26quite reliable, but, for instance, if using an HSM in a non-HA setup a 27connection interruption to the HSM will result in issues with Vault 28functionality. 29 30To disable seal wrapping, set `disable_sealwrap = true` in Vault's 31[configuration file][configuration]. This will not affect auto-unsealing functionality; Vault's 32master key will still be protected by the seal wrapping mechanism. It will 33simply prevent other storage entries within Vault from being seal wrapped. 34 35*N.B.*: This is a lazy downgrade; as keys are accessed or written their seal 36wrapping status will change. Similarly, if the flag is removed, it will be a 37lazy upgrade (which is the case when initially upgrading to a seal 38wrap-supporting version of Vault). 39 40## FIPS 140-2 Compliance 41 42Vault's Seal Wrap feature has been evaluated by Leidos for compliance with 43FIPS 140-2 requirements. When used with a FIPS 140-2-compliant HSM, Vault will 44store Critical Security Parameters (CSPs) in a manner that is compliant with 45KeyStorage and KeyTransit requirements. This is on by default for many parts of 46Vault and opt-in for each individual mount; see the Activating Seal Wrapping 47section below for details. 48 49[Download the current compliance letter](/docs/enterprise/sealwrap/Vault_Compliance_Letter_signed.pdf) 50 51### Updates Since The Latest FIPS Compliance Audit 52 53The following are values that take advantage of seal wrapping in the current 54release of Vault that have not yet been asserted as compliant by Leidos. The 55mechanism for seal wrapping is the same, they simply were not specifically 56evaluated by the auditors. 57 58* Root tokens 59* Replication secondary activation tokens 60* Client authentication information for the GCP Auth Backend 61* Client authentication information for the Kubernetes Auth Backend 62 63## Activating Seal Wrapping 64 65For some values, seal wrapping is always enabled with a supporting seal. This 66includes the recovery key, any stored key shares, the master key, the keyring, 67and more; essentially, any Critical Security Parameter (CSP) within Vault's 68core. If upgrading from a version of Vault that did not support seal wrapping, 69the next time these values are read they will be seal-wrapped and stored. 70 71Backend mounts within Vault can also take advantage of seal wrapping. Seal 72wrapping can be activated at mount time for a given mount by mounting the 73backend with the `seal_wrap` configuration value set to `true`. (This value 74cannot currently be changed later.) 75 76A given backend's author can specify which values should be seal-wrapped by 77identifying where CSPs are stored. If no specific CSPs are identifiable, all 78data for the backend may be seal-wrapped. 79 80To see the current list of seal-wrapped data per backend type, see the latest 81audit letter and updates in the FIPS 140-2 Compliance section above. 82 83Note that it is often an order of magnitude or two slower to write to and read 84from HSMs or remote seals. However, values will be cached in memory 85un-seal-wrapped (but still encrypted by Vault's built-in cryptographic barrier) 86in Vault, which will mitigate this for read-heavy workloads. 87 88## Seal Wrap and Replication 89 90Seal wrapping takes place below the replication logic. As a result, it is 91transparent to replication. Replication will convey which values should be 92seal-wrapped, but it is up to the seal on the local cluster to implement it. 93In practice, this means that seal wrapping can be used without needing to have 94the replicated keys on both ends of the connection; each cluster can have 95distinct keys in an HSM or in KMS. 96 97In addition, it is possible to replicate from a Shamir-protected primary 98cluster to clusters that use HSMs when seal wrapping is required in downstream 99datacenters but not in the primary. 100 101Because of the level of flexibility targeted for replication, values sent over 102replication connections do not currently meet KeyTransit requirements for FIPS 103140-2. Vault's clustering implementation does support best practices guidance 104given in FIPS 140-2, but the cryptographic implementation of TLS is not FIPS 105140-2 certified. We may look into providing certified TLS in the future for 106replication traffic; in the meantime, a transparent TCP proxy that supports 107certified FIPS 140-2 TLS (such as 108[stunnel](https://www.stunnel.org/index.html)) can be used for replication 109traffic if meeting KeyTransit requirements for replication is necessary. 110 111[configuration]: /docs/configuration/index.html 112