open-vault/website/source/docs/secrets/transit/index.html.md

layout	page_title	sidebar_current	description
docs	Secret Backend: Transit	docs-secrets-transit	The transit secret backend for Vault encrypts/decrypts data in-transit. It doesn't store any secrets.

Transit Secret Backend

Name: transit

The transit secret backend is used to encrypt/decrypt data in-transit. Vault doesn't store the data sent to the backend. It can also be viewed as "encryption as a service."

The primary use case for the transit backend is to encrypt data from applications while still storing that encrypted data in some primary data store. This relieves the burden of proper encryption/decryption from application developers and pushes the burden onto the operators of Vault. Operators of Vault generally include the security team at an organization, which means they can ensure that data is encrypted/decrypted properly.

Additionally, since encrypt/decrypt operations must enter the audit log, any decryption event is recorded.

Due to Vault's flexible ACLs, other interesting use-cases are possible. For instance, one set of Internet-facing servers can be given permission to encrypt with a named key but not decrypt with it; a separate set of servers not directly connected to the Internet can then perform decryption, reducing the data's attack surface.

Key derivation is supported, which allows the same key to be used for multiple purposes by deriving a new key based on a user-supplied context value. In this mode, convergent encryption can optionally be supported, which allows the same input values to produce the same ciphertext.

The backend also supports key rotation, which allows a new version of the named key to be generated. All data encrypted with the key will use the newest version of the key; previously encrypted data can be decrypted using old versions of the key. Administrators can control which previous versions of a key are available for decryption, to prevent an attacker gaining an old copy of ciphertext to be able to successfully decrypt it. At any time, a legitimate user can "rewrap" the data, providing an old version of the ciphertext and receiving a new version encrypted with the latest key. Because rewrapping does not expose the plaintext, using Vault's ACL system, this can even be safely performed by unprivileged users or cron jobs.

Datakey generation allows processes to request a high-entropy key of a given bit length be returned to them, encrypted with the named key. Normally this will also return the key in plaintext to allow for immediate use, but this can be disabled to accommodate auditing requirements.

N.B.: As part of adding rotation support, the initial version of a named key produces ciphertext starting with version 1, i.e. containing :v1:. Keys from very old versions of Vault, when rotated, will jump to version 2 despite their previous ciphertext output containing :v0:. Decryption, however, treats version 0 and version 1 the same, so old ciphertext will still work.

This page will show a quick start for this backend. For detailed documentation on every path, use vault path-help after mounting the backend.

Quick Start

The first step to using the transit backend is to mount it. Unlike the generic backend, the transit backend is not mounted by default.

$ vault mount transit
Successfully mounted 'transit' at 'transit'!

The next step is to create a named encryption key. A named key is used so that many different applications can use the transit backend with independent keys. This is done by doing a write against the backend:

$ vault write -f transit/keys/foo
Success! Data written to: transit/keys/foo

This will create the "foo" named key in the transit backend. We can inspect the settings of the "foo" key by reading it:

$ vault read transit/keys/foo
Key                     Value
cipher_mode             aes-gcm
deletion_allowed        false
derived                 false
keys                    map[1:1.459861712e+09]
latest_version          1
min_decryption_version  1
name                    foo

Now, if we wanted to encrypt a piece of plain text, we use the encrypt endpoint using our named key:

$ echo -n "the quick brown fox" | base64 | vault write transit/encrypt/foo plaintext=-
Key       	Value
ciphertext	vault:v1:czEwyKqGZY/limnuzDCUUe5AK0tbBObWqeZgFqxCuIqq7A84SeiOq3sKD0Y/KUvv

The encryption endpoint expects the plaintext to be provided as a base64 encoded strings, so we must first convert it. Vault does not store the plaintext or the ciphertext, but only handles it in transit for processing. The application is free to store the ciphertext in a database or file at rest.

To decrypt, we simply use the decrypt endpoint using the same named key:

$ vault write transit/decrypt/foo ciphertext=vault:v1:czEwyKqGZY/limnuzDCUUe5AK0tbBObWqeZgFqxCuIqq7A84SeiOq3sKD0Y/KUvv
Key      	Value
plaintext	dGhlIHF1aWNrIGJyb3duIGZveAo=

$ echo "dGhlIHF1aWNrIGJyb3duIGZveAo=" | base64 -d
the quick brown fox

Using ACLs, it is possible to restrict using the transit backend such that trusted operators can manage the named keys, and applications can only encrypt or decrypt using the named keys they need access to.

API

/transit/keys/

POST

Description

Creates a new named encryption key. The values set here cannot be changed after key creation.

Method

POST

URL

`/transit/keys/`

Parameters

• derived optional Boolean flag indicating if key derivation MUST be used. If enabled, all encrypt/decrypt requests to this named key must provide a context which is used for key derivation. Defaults to false.
• convergent_encryption optional If set, the key will support convergent encryption, where the same plaintext creates the same ciphertext. This requires _derived_ to be set to `true`. When enabled, each encryption(/decryption/rewrap/datakey) operation will derive a `nonce` value rather than randomly generate it. Note that while this is useful for particular situations, all nonce values used with a given context value **must be unique** or it will compromise the security of your key, and the key space for nonces is 96 bit -- not as large as the AES key itself. Defaults to false.

Returns

A `204` response code.

GET

Description

Returns information about a named encryption key. The `keys` object shows the creation time of each key version; the values are not the keys themselves.

Method

GET

URL

`/transit/keys/`

Parameters

None

Returns

```javascript
{
  "data": {
    "cipher_mode": "aes-gcm",
    "deletion_allowed": false,
    "derived": false,
    "keys": {
      "1": 1442851412
    },
    "min_decryption_version": 0,
    "name": "foo"
  }
}
```

DELETE

Description

Deletes a named encryption key. It will no longer be possible to decrypt any data encrypted with the named key. Because this is a potentially catastrophic operation, the `deletion_allowed` tunable must be set in the key's `/config` endpoint.

Method

DELETE

URL

`/transit/keys/`

Parameters

None

Returns

A `204` response code.

/transit/keys/config

POST

Description

Allows tuning configuration values for a given key. (These values are returned during a read operation on the named key.)

Method

POST

URL

`/transit/keys//config`

Parameters

• min_decryption_version optional The minimum version of ciphertext allowed to be decrypted. Adjusting this as part of a key rotation policy can prevent old copies of ciphertext from being decrypted, should they fall into the wrong hands. Defaults to 0.
• deletion_allowed optional When set, the key is allowed to be deleted. Defaults to false.

Returns

A `204` response code.

/transit/keys/rotate/

POST

Description

Rotates the version of the named key. After rotation, new plaintext requests will be encrypted with the new version of the key. To upgrade ciphertext to be encrypted with the latest version of the key, use the `rewrap` endpoint.

Method

POST

URL

`/transit/keys//rotate`

Parameters

None

Returns

A `204` response code.

/transit/encrypt/

POST

Description

Encrypts the provided plaintext using the named key. This path supports the `create` and `update` policy capabilities as follows: if the user has the `create` capability for this endpoint in their policies, and the key does not exist, it will be upserted with default values (whether the key requires derivation depends on whether the context parameter is empty or not). If the user only has `update` capability and the key does not exist, an error will be returned.

Method

POST

URL

`/transit/encrypt/`

Parameters

• plaintext required The plaintext to encrypt, provided as base64 encoded.
• context optional The key derivation context, provided as base64 encoded. Must be provided if derivation is enabled.
• nonce optional The nonce value, provided as base64 encoded. Must be provided if convergent encryption is enabled for this key and the key was generated with Vault 0.6.1. Not required for keys created in 0.6.2+. The value must be exactly 96 bits (12 bytes) long and the user must ensure that for any given context (and thus, any given encryption key) this nonce value is **never reused**.

Returns

```javascript
{
  "data": {
    "ciphertext": "vault:v1:abcdefgh"
  }
}
```

/transit/decrypt/

POST

Description

Decrypts the provided ciphertext using the named key.

Method

POST

URL

`/transit/decrypt/`

Parameters

• ciphertext required The ciphertext to decrypt, provided as returned by encrypt.
• context optional The key derivation context, provided as base64 encoded. Must be provided if derivation is enabled.
• nonce optional The nonce value used during encryption, provided as base64 encoded. Must be provided if convergent encryption is enabled for this key and the key was created with Vault 0.6.1. Not required for keys created in 0.6.2+.

Returns

```javascript
{
  "data": {
    "plaintext": "dGhlIHF1aWNrIGJyb3duIGZveAo="
  }
}
```

/transit/rewrap/

POST

Description

Rewrap the provided ciphertext using the latest version of the named key. Because this never returns plaintext, it is possible to delegate this functionality to untrusted users or scripts.

Method

POST

URL

`/transit/rewrap/`

Parameters

• ciphertext required The ciphertext to decrypt, provided as returned by encrypt.
• context optional The key derivation context, provided as base64 encoded. Must be provided if derivation is enabled.
• nonce optional The nonce value used during encryption, provided as base64 encoded. Must be provided if convergent encryption is enabled for this key and the key was created with Vault 0.6.1. Not required for keys created in 0.6.2+.

Returns

```javascript
{
  "data": {
    "ciphertext": "vault:v2:abcdefgh"
  }
}
```

/transit/datakey/

POST

Description

Generate a new high-entropy key and the value encrypted with the named key. Optionally return the plaintext of the key as well. Whether plaintext is returned depends on the path; as a result, you can use Vault ACL policies to control whether a user is allowed to retrieve the plaintext value of a key. This is useful if you want an untrusted user or operation to generate keys that are then made available to trusted users.

Method

POST

URL

`/transit/datakey//`

Parameters

• plaintext|wrapped (path parameter) required If `plaintext`, the plaintext key will be returned along with the ciphertext. If `wrapped`, only the ciphertext value will be returned.
• context optional The key derivation context, provided as base64 encoded. Must be provided if derivation is enabled.
• nonce optional The nonce value, provided as base64 encoded. Must be provided if convergent encryption is enabled for this key and the key was generated with Vault 0.6.1. Not required for keys created in 0.6.2+. The value must be exactly 96 bits (12 bytes) long and the user must ensure that for any given context (and thus, any given encryption key) this nonce value is **never reused**.
• bits optional The number of bits in the desired key. Can be 128, 256, or 512; if not given, defaults to 256.

Returns

```javascript
{
  "data": {
    "plaintext": "dGhlIHF1aWNrIGJyb3duIGZveAo=",
    "ciphertext": "vault:v1:abcdefgh"
  }
}
```