Encrypt data in transit with Vault

1. Enable the transit secrets engine by executing the following command.

   $ vault secrets enable transitSuccess! Enabled the transit secrets engine at: transit/

   By default, the secrets engine will mount at the name of the engine. If you wish to enable it at a different path, use the -path argument.

   Example

   The following command enables the transit secrets engine at encryption/ instead of transit/.

   $ vault secrets enable -path=encryption transit

2. Create an encryption key ring named orders by executing the following command.

   $ vault write -f transit/keys/ordersSuccess! Data written to: transit/keys/orders

The steps in the API section are not expected to generate any output, except where an Example output code block is present.

1. Enable transit secrets engine using the /sys/mounts endpoint at sys/mounts/transit path, and pass the secrets engine type (transit) in the request payload.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \    --request POST \    --data '{"type":"transit"}' \    $VAULT_ADDR/v1/sys/mounts/transit

2. Create an encryption key ring named orders using the transit/keys endpoint.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \    --request POST \    $VAULT_ADDR/v1/transit/keys/orders

1. Open a web browser and launch the Vault UI and then login.

2. Select Enable new engine.

3. Select the Transit radio button and click Next.

4. Click Enable Engine.

5. Select Create encryption key and enter orders in the Name field.

6. Click Create encryption key to complete.

1. Create a policy named app-orders.

   $ vault policy write app-orders -<<EOFpath "transit/encrypt/orders" {   capabilities = [ "update" ]}path "transit/decrypt/orders" {   capabilities = [ "update" ]}EOF

   The policy is created or updated; if it already exists.

   Example output:

   Success! Uploaded policy: app-orders

2. Create a token with app-orders policy attached.

   $ vault token create -policy=app-orders

   Example output:

   Key                  Value---                  -----token                hvs.CAESIIGSlbFFoYgqdzTu2lwnoDteRshqcWdVSAUohC2w-gZ2GicKImh2cy54cjRiQ1lMaHptSm44eVAySmFNWk9FNk4ueU54TmkQlQQtoken_accessor       lzzyhDwNzO3wO9ai734Bf14g.yNxNitoken_duration       1htoken_renewable      truetoken_policies       ["app-orders" "default"]identity_policies    []policies             ["app-orders" "default"]

   The token is returned with the app-orders policy attached.

3. Re-run the command and create a APP_ORDER_TOKEN environment variable to store the generated client token value.

   $ export APP_ORDER_TOKEN=$(vault token create \    -policy=app-orders \    -format=json | jq -r '.auth | .client_token')

1. Create a request payload containing the stringified app-orders policy.

   $ tee payload.json <<EOF{  "policy": "path \"transit/encrypt/orders\" {\n   capabilities = [ \"update\" ]\n}\n\npath \"transit/decrypt/orders\" {\n   capabilities = [ \"update\" ]\n}\n"}EOF

2. Create a policy named app-orders.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \    --request PUT \    --data @payload.json \    $VAULT_ADDR/v1/sys/policies/acl/app-orders

   The policy is created or updated; if it already exists.

3. Create a token with app-orders policy attached.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \    --request POST  \    --data '{ "policies": ["app-orders"] }' \    $VAULT_ADDR/v1/auth/token/create | jq -r '.auth'

   Example output:

   {  "client_token": "hvs.CAESIE23IseSO32lbIk-Z1B1c5LuqqioDIW1",  "accessor": "RDQLS4k4f5rvVo48Poq8bJUb.XdilT",  "policies": [    "app-orders",    "default"  ],  "token_policies": [    "app-orders",    "default"  ],  "metadata": null,  "lease_duration": 3600,  "renewable": true,  "entity_id": "dd4807d5-ef38-dc22-577f-702ccdabe850",  "token_type": "service",  "orphan": false,  "mfa_requirement": null,  "num_uses": 0}

4. Re-run the API call and create a APP_ORDER_TOKEN environment variable to store the generated client token value.

   $ export APP_ORDER_TOKEN=$(curl --header "X-Vault-Token: $VAULT_TOKEN" \    --request POST  \    --data '{ "policies": ["app-orders"] }' \    $VAULT_ADDR/v1/auth/token/create | jq -r '.auth | .client_token')

1. Click the Policies tab, and then select Create ACL policy.

2. Enter app-orders in the Name field.

3. Copy and past in the following in the Policy text field.

   path "transit/encrypt/orders" {   capabilities = [ "update" ]} path "transit/decrypt/orders" {   capabilities = [ "update" ]} # List existing keys in UIpath "transit/keys" {   capabilities = [ "list" ]} # Enable to select the orders key in UIpath "transit/keys/orders" {   capabilities = [ "read" ]}

4. Click Create policy.

5. Click the Vault CLI shell icon (>_) to open a command shell. Execute vault write auth/token/create policies=app-orders in the CLI shell.

   

6. Copy the generated token value (e.g. s.U4I87snzLMNOPybPIpyozdHC.QttaO). You are going to use it to request data encryption and decryption.

1. Encrypt plaintext (using the shell to do the base64 encoding) using the orders encryption key.

   $ VAULT_TOKEN=$APP_ORDER_TOKEN vault write transit/encrypt/orders \    plaintext=$(base64 <<< "4111 1111 1111 1111")

   Example output:

   Key           Value---           -----ciphertext    vault:v1:cZNHVx+sxdMErXRSuDa1q/pz49fXTn1PScKfhf+PIZPvy8xKfkytpwKcbC0fF2U=

2. Re-run the command to store the encrypted value as an environment variable.

   $ export CIPHERTEXT=$(VAULT_TOKEN=$APP_ORDER_TOKEN vault write transit/encrypt/orders \    plaintext=$(base64 <<< "4111 1111 1111 1111")\    -format=json | jq -r '.data | .ciphertext')

1. Use base64 encoding to encode your secret.

   $ base64 <<< "4111 1111 1111 1111"NDExMSAxMTExIDExMTEgMTExMQo=

2. Encrypt your secret with the transit/encrypt endpoint and pass the base64-encoded plaintext in the request payload.

   $ curl --header "X-Vault-Token: $APP_ORDER_TOKEN" \    --request POST \    --data '{"plaintext": "NDExMSAxMTExIDExMTEgMTExMQo="}' \    $VAULT_ADDR/v1/transit/encrypt/orders | jq -r '.data'

   Example output:

   {  "ciphertext": "vault:v1:icoWIWuJ1Oa/Hdgbbmcsvn9Gz035zQtYy1uVu2aPZlqjfSML5bbuVTt4LmnRbMlr",  "key_version": 1}

3. Re-run the API call to store the encrypted value as an environment variable.

   $ CIPHERTEXT=$(curl --header "X-Vault-Token: $APP_ORDER_TOKEN" \    --request POST \    --data '{"plaintext": "NDExMSAxMTExIDExMTEgMTExMQo="}' \    $VAULT_ADDR/v1/transit/encrypt/orders | jq -r '.data | .ciphertext')

1. Sign out of the UI.

2. In the Token text field, enter the <client_token> value you copied in the previous step.

3. Click Sign in.

4. Under Secrets Engines, select transit/.

5. In the Key Actions tab, select Encrypt.

6. Enter 4111 1111 1111 1111 in the Plaintext field.

7. Click Encrypt.

   Vault does NOT store any of this data. The output you received is the ciphertext. You can click Copy to copy the resulting ciphertext and store it at the desired location (e.g. MySQL database) or pass it to another application.

   

1. Decrypt the ciphertext emitted in the encrypt secrets step.

   $ VAULT_TOKEN=$APP_ORDER_TOKEN vault write \    transit/decrypt/orders ciphertext=$CIPHERTEXT

   Example output:

   Key          Value---          -----plaintext    NDExMSAxMTExIDExMTEgMTExMQo=

2. The resulting data is base64-encoded and must be decoded to reveal the plaintext.

   $ base64 --decode <<< "NDExMSAxMTExIDExMTEgMTExMQo="4111 1111 1111 1111

1. Use the transit/decrypt endpoint to decrypt the ciphertext emitted in the encrypt secrets step.

   $ curl --header "X-Vault-Token: $APP_ORDER_TOKEN" \   --request POST \   --data '{"ciphertext": "'"$CIPHERTEXT"'"}' \   $VAULT_ADDR/v1/transit/decrypt/orders | jq -r ".data"

   Example output:

   {  "plaintext": "NDExMSAxMTExIDExMTEgMTExMQo="}

2. The resulting data is base64-encoded and must be decoded to reveal the plaintext.

   $ base64 --decode <<< "NDExMSAxMTExIDExMTEgMTExMQo="4111 1111 1111 1111

1. Select Decrypt under Key Actions and enter the ciphertext you wish to decrypt.

2. Click Decrypt.

3. Click Copy & Close.

4. The resulting data is base64-encoded and must be decoded to reveal the plaintext.

   $ base64 --decode <<< "NDExMSAxMTExIDExMTEgMTExMQo="4111 1111 1111 1111

1. To rotate the encryption key, invoke the transit/keys/<key_ring_name>/rotate endpoint. In this tutorial, the key ring name is orders.

   $ vault write -f transit/keys/orders/rotateSuccess! Data written to: transit/keys/orders/rotate

2. Encrypt the data with the new key.

   $ vault write transit/encrypt/orders plaintext=$(base64 <<< "4111 1111 1111 1111") Key            Value---            -----ciphertext     vault:v2:rmFFvJTbSu7+6a75SIUOfeBlhaF0Y7ImDk7PJHTLSI2AB5A48TjMp+bb68N1874Vkey_version    2

   Compare the ciphertext from the encrypt secrets step.

   Version 1:

   ciphertext    vault:v1:cZNHVx+sxdMErXRSuDa1q/pz49fXTn1PScKfhf+PIZPvy8xKfkytpwKcbC0fF2U=

   Version 2:

   ciphertext    vault:v2:rmFFvJTbSu7+6a75SIUOfeBlhaF0Y7ImDk7PJHTLSI2AB5A48TjMp+bb68N1874V

   Notice that the first ciphertext starts with "vault:v1:". After rotating the encryption key, the ciphertext starts with "vault:v2:". This indicates that the data is encrypted using the latest version of the key after the rotation.

3. Rewrap your ciphertext from the encrypt secrets step with the latest version of the encryption key.

   $ vault write transit/rewrap/orders \    ciphertext=$CIPHERTEXT

   Example output:

   Key            Value---            -----ciphertext     vault:v2:gHkxylYrff4TNbKIpQ/fDPmplwyqirxFtzBror+NigmlX1JKkX6gH3LzkXB/AACJkey_version    2

   Notice that the resulting ciphertext now starts with "vault:v2:".

   This operation does not reveal the plaintext data. But Vault will decrypt the value using the appropriate key in the keyring and then encrypt the resulting plaintext with the newest key in the keyring.

1. Invoke the transit/keys/<key_ring_name>/rotate endpoint using the orders key ring.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \     --request POST \     $VAULT_ADDR/v1/transit/keys/orders/rotate

2. Encrypt another base64-encoded plaintext string.

   $ base64 <<< "4111 1111 1111 1111"NDExMSAxMTExIDExMTEgMTExMQo=

3. Pass the base64-encoded plaintext in the request payload.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \     --request POST \     --data '{"plaintext": "NDExMSAxMTExIDExMTEgMTExMQo="}' \     $VAULT_ADDR/v1/transit/encrypt/orders | jq -r ".data"

   Example output:

   {  "ciphertext": "vault:v2:+Hsmlr7Da4lcTo1H+e7TCMkAWy/bHqU89wOj4nTP+BBp2XW7rTgpyuFt025JW7L4",  "key_version": 2}

   Compare the ciphertext from the encrypt secrets step.

   Version 1:

   {  "ciphertext": "vault:v1:icoWIWuJ1Oa/Hdgbbmcsvn9Gz035zQtYy1uVu2aPZlqjfSML5bbuVTt4LmnRbMlr",  "key_version": 1}

   Version 2:

   {  "ciphertext": "vault:v2:+Hsmlr7Da4lcTo1H+e7TCMkAWy/bHqU89wOj4nTP+BBp2XW7rTgpyuFt025JW7L4",  "key_version": 2}

   Notice that the first ciphertext starts with "vault:v1:". After rotating the encryption key, the ciphertext starts with "vault:v2:". This indicates that the data is encrypted using the latest version of the key after the rotation.

4. Rewrap your ciphertext from the encrypt secrets step with the latest version of the encryption key.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \   --request POST \   --data '{"ciphertext": "'"$CIPHERTEXT"'"}' \   $VAULT_ADDR/v1/transit/rewrap/orders | jq -r ".data"

   Example output:

   {  "ciphertext": "vault:v2:zZySQDuy+CSHOH4wbPKGHRm5J+jTMajyoD3DFReP41K3qQBl0kStboCb966T9U2t",  "key_version": 2}

   Notice that the resulting ciphertext now starts with "vault:v2:".

   This operation does not reveal the plaintext data. But Vault will decrypt the value using the appropriate key in the keyring and then encrypt the resulting plaintext with the newest key in the keyring.

1. Select the orders encryption key.

2. Select the Versions tab, and then select Rotate encryption key to rotate the encryption key.

3. Select Rotate at the confirmation dialog to proceed.

4. Select Key actions.

5. Select Encrypt. Notice that it gives you an option to select the desired key version to encrypt your secret with.

6. With 2 (latest) selected as key version, enter "5111 1111 1111 1111" in the Plaintext field.

7. Click Encrypt. Notice that the first ciphertext started with "vault:v1:". After rotating the encryption key, the ciphertext starts with "vault:v2:". This indicates that the data is encrypted using the latest version of the key after the rotation.

Vault will decrypt the value using the appropriate key in the keyring and then encrypt the resulting plaintext with the newest key in the keyring.

1. Read the orders key information.

   $ vault read transit/keys/orders

   Example output:

   Key                       Value---                       -----allow_plaintext_backup    falseauto_rotate_period        0sdeletion_allowed          falsederived                   falseexportable                falseimported_key              falsekeys                      map[1:1686228409 2:1686230400]latest_version            2...snip...

   The auto_rotate_period parameter configures the amount of time the key should live before being automatically rotated. A value of 0 (default) disables automatic rotation for the key.

2. Configure automatic rotation for the orders key every 24 hours.

   $ vault write transit/keys/orders/config auto_rotate_period=24hSuccess! Data written to: transit/keys/orders/config

3. Read the orders key information again.

   $ vault read transit/keys/orders

   Example output:

   Key                       Value---                       -----allow_plaintext_backup    falseauto_rotate_period        24hdeletion_allowed          falsederived                   falseexportable                falseimported_key              falsekeys                      map[1:1686228409 2:1686230400]latest_version            2...snip...

   Vault will automatically rotate the orders key every 24 hours.

1. Read the transit/keys/orders endpoint to review the orders key details and retrieve its auto_rotate_period parameter value.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" --silent \    $VAULT_ADDR/v1/transit/keys/orders | jq -r ".data.auto_rotate_period"

   Example output:

   0

   The auto_rotate_period parameter configures the amount of time the key should live before being automatically rotated. A value of 0 (default) disables automatic rotation for the key.

2. Configure automatic rotation for the orders key every 24 hours (86400 seconds).

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \    --request POST \    --data '{"auto_rotate_period": 86400}' \    $VAULT_ADDR/v1/transit/keys/orders/config

3. Verify the orders key configuration.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \    $VAULT_ADDR/v1/transit/keys/orders | jq -r ".data"

   Example output:

   {  "allow_plaintext_backup": false,  "auto_rotate_period": 86400,  "deletion_allowed": false,  "derived": false,  "exportable": false,  "keys": {    "1": 1647405195    "2": 1686436518  },  ...snip...}

   Vault will automatically rotate the orders key every 24 hours.

1. Select the orders encryption key.

2. Select the Details tab and then Edit encryption key.

3. Slide the Auto-rotation period toggle to enable automatic key rotation. Set the rotation period to be 24 hours.

4. Click the Update transit key button to save the changes.

Vault will automatically rotate the orders key every 24 hours.

1. Execute the key rotation command three times to generate multiple versions of the key.

   $ vault write -f transit/keys/orders/rotateSuccess! Data written to: transit/keys/orders/rotate

2. Read the orders key information.

   $ vault read transit/keys/orders

   Example output:

   Key                       Value---                       -----allow_plaintext_backup    falseauto_rotate_period        24hdeletion_allowed          falsederived                   falseexportable                falseimported_key              falsekeys                      map[1:1686228409 2:1686230400 3:1686231508 4:1686231519 5:1686231520]latest_version            5min_available_version     0min_decryption_version    1min_encryption_version    0name                      orderssupports_decryption       truesupports_derivation       truesupports_encryption       truesupports_signing          falsetype                      aes256-gcm96

   In this example, the current version of the key is now 5 because you previously rotated the key to version 2, then re-ran the rotate command 3 more times. However, there is no restriction about the minimum encryption key version (min_encryption_version), and any of the key versions can decrypt the data (min_decryption_version).

3. Enforce the use of the encryption key at version 5 or later to decrypt the data.

   $ vault write transit/keys/orders/config min_decryption_version=5Success! Data written to: transit/keys/orders/config

4. Verify the orders key configuration.

   $ vault read transit/keys/ordersKey                       Value---                       -----allow_plaintext_backup    falseauto_rotate_period        24hdeletion_allowed          falsederived                   falseexportable                falseimported_key              falsekeys                      map[5:1686231520]latest_version            5min_available_version     0min_decryption_version    5min_encryption_version    0name                      orderssupports_decryption       truesupports_derivation       truesupports_encryption       truesupports_signing          falsetype                      aes256-gcm96

   min_decryption_version is now set to 5.

1. Execute the transit/keys/<key_ring_name>/rotate endpoint three times to generate multiple versions of the key.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \    --request POST \    $VAULT_ADDR/v1/transit/keys/orders/rotate

2. Read the transit/keys/orders endpoint to review the orders key details.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \    $VAULT_ADDR/v1/transit/keys/orders | jq -r ".data"

   Example output:

   {  "allow_plaintext_backup": false,  "auto_rotate_period": 86400,  "deletion_allowed": false,  "derived": false,  "exportable": false,  "keys": {    "1": 1647405195,    "2": 1647409101,    "3": 1647409102,    "4": 1647409104,    "5": 1647409105  },  "latest_version": 5,  "min_available_version": 0,  "min_decryption_version": 1,  "min_encryption_version": 0,  "name": "orders",  "supports_decryption": true,  "supports_derivation": true,  "supports_encryption": true,  "supports_signing": false,  "type": "aes256-gcm96"}

   In this example, the current version of the key is now 5 because you previously rotated the key to version 2, then re-ran the rotate command 3 more times. However, there is no restriction about the minimum encryption key version (min_encryption_version), and any of the key versions can decrypt the data (min_decryption_version).

3. Enforce the use of the encryption key at version 5 or later to decrypt the data.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \    --request POST \    --data '{"min_decryption_version": 5}' \    $VAULT_ADDR/v1/transit/keys/orders/config

4. Verify the orders key configuration.

   $ curl --header "X-Vault-Token: $VAULT_TOKEN" \    $VAULT_ADDR/v1/transit/keys/orders | jq -r ".data"

   Example output:

   {  "allow_plaintext_backup": false,  "auto_rotate_period": 86400,  "deletion_allowed": false,  "derived": false,  "exportable": false,  "keys": {    "5": 1647409105  },  "latest_version": 5,  "min_available_version": 0,  "min_decryption_version": 5,  "min_encryption_version": 0,  "name": "orders",  "supports_decryption": true,  "supports_derivation": true,  "supports_encryption": true,  "supports_signing": false,  "type": "aes256-gcm96"}

   The output only displays the remaining valid encryption key versions (5) and sets min_decryption_version to 5

1. Select the orders encryption key.

2. Select the Versions tab and then select Rotate encryption key to rotate the encryption key. (Select Rotate to confirm and proceed.)

3. Repeat the steps a few times to generate multiple versions of the key. In the example, the current version of the key is 6. However, there is no restriction about the minimum encryption key version, and any of the key versions can decrypt the data.

4. Select the Details tab.

5. Select Edit encryption key.

6. From the Minimum decryption version drop-down list, select 5.

7. Click the Update transit key button. If you select the Versions tab again, the list only shows version 5 and 6.

$ curl --header "X-Vault-Token: $VAULT_TOKEN" \    --request POST \    $VAULT_ADDR/v1/transit/datakey/plaintext/orders | jq -r ".data"

Example output:

{  "ciphertext": "vault:v5:eTQ3GSHWBUP7E49BBbzy0XeiAKinuTQdLE3bIew6LYMupDT8b/+/sRB4MU6izHWSuyiG3QuOubwhJqA9",  "key_version": 5,  "plaintext": "JntU/jAiyrgHfUsOlSYjiEoxzI6zhrZ56YtdCqrp9fM="}

1. Select the orders encryption key.

2. Select Key actions.

3. Select Datakey, select plaintext from the Output format drop-down list, and then click the Create datakey button.

$ vault read -field=public_key transit/wrapping_key-----BEGIN PUBLIC KEY-----MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAuO1Gf6nIiD6fem4vOo96syUFOY7aUt85QlqaJrXoxtYQ3mxiAI4MTm4Wxd3uCmFa4CHtVRaPD+VuJRvOwVlZqRK3R6HMsJglElVZjpFovBBjwvThUSoTqqBGK/2cTR15PxeluhwcHIUjo9gT1SKmWSzSpfGXyNqwGLyZLGpip5FcB7p3CS9Yf77Bzxjnz66kUAqCCm0Q09lGkXyhuXWbqNAPHPCOVaKlY4b4SpJu921stZGmIC1Ik3r78fLs6ZNthfNt7yvVQGcRKdzrjlRLz9vv2XBllKsXJf88OWu2iMrU1ybmxPp0Is1pqaNCgGsNzkrWPDKmZIWuyCOHzlebTsp0AdjNU9K36AD5x+jztoEGYMumPDZwhzF9WzcyfGNroy2LonXUdza305BhBCKECw+rwchXLxDk9mqz8mJ4cmTvVA+c30dF1a89YReb4NLXVKNbG7VcoO2tgmnioBOjCUQhmpxLnvKZJ38QKpQzhqHnzOK72K5v3paOyqicPWQDBHhup6UL4+mB+0vfFESHrhkA0OGqYWEDf9QQ41toafNyuHZtGmzuD1MDBbKTemvhGYL7Gvv6H2UadFBr8MczBLi5V8j/QEjdt+jZ6ZGtIlFZSjLkaKTeqyq2pTLldyuRzm4vBDZ46+dS4whfrFMm/yg0pLHOE8ItLIqwq4vojscCAwEAAQ==-----END PUBLIC KEY-----

The output is the (4096-bit RSA) wrapping key.

$ curl --header "X-Vault-Token: $VAULT_TOKEN" --request GET --silent \    $VAULT_ADDR/v1/transit/wrapping_key | jq

Example output:

{  "request_id": "45a354b0-2f5f-6fe6-e404-24f28350cc4d",  "lease_id": "",  "renewable": false,  "lease_duration": 0,  "data": {    "public_key": "-----BEGIN PUBLIC KEY-----\nMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAuO1Gf6nIiD6fem4vOo96\nsyUFOY7aUt85QlqaJrXoxtYQ3mxiAI4MTm4Wxd3uCmFa4CHtVRaPD+VuJRvOwVlZ\nqRK3R6HMsJglElVZjpFovBBjwvThUSoTqqBGK/2cTR15PxeluhwcHIUjo9gT1SKm\nWSzSpfGXyNqwGLyZLGpip5FcB7p3CS9Yf77Bzxjnz66kUAqCCm0Q09lGkXyhuXWb\nqNAPHPCOVaKlY4b4SpJu921stZGmIC1Ik3r78fLs6ZNthfNt7yvVQGcRKdzrjlRL\nz9vv2XBllKsXJf88OWu2iMrU1ybmxPp0Is1pqaNCgGsNzkrWPDKmZIWuyCOHzleb\nTsp0AdjNU9K36AD5x+jztoEGYMumPDZwhzF9WzcyfGNroy2LonXUdza305BhBCKE\nCw+rwchXLxDk9mqz8mJ4cmTvVA+c30dF1a89YReb4NLXVKNbG7VcoO2tgmnioBOj\nCUQhmpxLnvKZJ38QKpQzhqHnzOK72K5v3paOyqicPWQDBHhup6UL4+mB+0vfFESH\nrhkA0OGqYWEDf9QQ41toafNyuHZtGmzuD1MDBbKTemvhGYL7Gvv6H2UadFBr8Mcz\nBLi5V8j/QEjdt+jZ6ZGtIlFZSjLkaKTeqyq2pTLldyuRzm4vBDZ46+dS4whfrFMm\n/yg0pLHOE8ItLIqwq4vojscCAwEAAQ==\n-----END PUBLIC KEY-----\n"  },  "wrap_info": null,  "warnings": null,  "auth": null}

The output is a JSON object with a data.public_key field containing the (4096-bit RSA) wrapping key.

$ vault write transit/keys/biometric-reader/import \    ciphertext=$IMPORT_CIPHERTEXT allow_rotation=true

Output:

Success! Data written to: transit/keys/biometric-reader/import

Create a JSON payload containing ciphertext value and any additional parameters.

$ cat > payload.json << EOF{  "ciphertext": "Q3Pf4qcMzWrq1BS4OKUfAIpZ4b3IXta68Rc4AuodE+S9JiCr2+OqemaU3OFPleeDTfY8jF1VykqE3DLwzrlD0qlvqg+AiVjOLnBRCf6hFtDM3DrncXZalSlKEyAxWQAt1ZtgccXK6Sje+j4+OchAM+FRNojhMgxTbYYY2zbJZpVH7Qqr9Sd6ypsD0k+RsGUncW3tvjUlea1u0Yvaj4buRlrEKs5W4bLzo8VSsfwporVyC764Xrk9D0sR3PFp0BcIzVEfklhYugUIXHtwdOVLRbtdKGzSeUSY6epS5br6BkLQLsoMEUToSZKo6RhgzS+6uoa6OjO0WsR2KoEjfzuW2VAZSZTDlbCCe+87TDgPBQO/tUm+BdXPh0JOSjJ/DuIbIH6iwkVhKwS/EJrEna88FbwGg8rLVmiVGicrHWTNyoGSnfTyzLza8zkTINlX23k++SMcFnhakFjSJq/jJp8jTjqZyqXzZIL4Bz9GFfhCL2cGBhIAAwvYrUEqEJeaYPtXkoyC8O/86qEvHnEpW1SpC/juWKMAxjQ2cYY2JPMIuote3Ihz+JEFItQSwi0dpoECRKTNdnoPVw3rbHcoffd5xO7vvUB9nObNA/nZ+s+iTcxZmRlbBda4fNRLzzKyrqMxWkb7HBQ7a0L8S0Nmmqah0993Qrbym8E7vz0QgS9TUqZDFtA6meUKy0I+f9+z+907TsS5U9XHhlJRPL6nvv7PDX+X6doPrjYS", "allow_rotation": true}EOF

Import the key.

$ curl \    --header "X-Vault-Token: $VAULT_TOKEN" \    --request POST \    --data @payload.json \    $VAULT_ADDR/v1/transit/keys/biometric-reader/import

Create a JSON payload.

$ cat > payload.json << EOF{  "plaintext": "$(base64 <<< "secret biometric data")"}EOF

Encrypt the data.

$ curl \    --silent \    --header "X-Vault-Token: $VAULT_TOKEN" \    --request POST \    --data @payload.json \    $VAULT_ADDR/v1/transit/encrypt/biometric-reader | jq

Example output:

{  "request_id": "14b2c81c-2a90-cfcc-eeb3-0f69ce022308",  "lease_id": "",  "renewable": false,  "lease_duration": 0,  "data": {    "ciphertext": "vault:v1:06OmrqB6EBSX+mMersFK4s4l705fpM+vEcnvo+e9B/CHHluq1awjciZ2fdtXFSdwNVc=",    "key_version": 1  },  "wrap_info": null,  "warnings": null,  "auth": null}

$ curl \    --silent \    --header "X-Vault-Token: $VAULT_TOKEN" \    $VAULT_ADDR/v1/transit/keys/biometric-reader | jq

Example output:

{  "request_id": "3cd853ff-48a6-9936-f8de-806157a262f3",  "lease_id": "",  "renewable": false,  "lease_duration": 0,  "data": {    "allow_plaintext_backup": false,    "auto_rotate_period": 0,    "deletion_allowed": false,    "derived": false,    "exportable": false,    "imported_key": true,    "imported_key_allow_rotation": true,    "keys": {      "1": 1665164440    },    "latest_version": 1,    "min_available_version": 0,    "min_decryption_version": 1,    "min_encryption_version": 0,    "name": "biometric-reader",    "supports_decryption": true,    "supports_derivation": true,    "supports_encryption": true,    "supports_signing": false,    "type": "aes256-gcm96"  },  "wrap_info": null,  "warnings": null,  "auth": null}

$ curl \    --silent \    --header "X-Vault-Token: $VAULT_TOKEN" \    $VAULT_ADDR/v1/transit/keys/biometric-reader | jq

Example output:

{  "request_id": "d34f3208-3e4e-0ec0-1e84-dcb4be2e9f6b",  "lease_id": "",  "renewable": false,  "lease_duration": 0,  "data": {    "allow_plaintext_backup": false,    "auto_rotate_period": 0,    "deletion_allowed": false,    "derived": false,    "exportable": false,    "imported_key": false,    "keys": {      "1": 1665164440,      "2": 1665165083    },    "latest_version": 2,    "min_available_version": 0,    "min_decryption_version": 1,    "min_encryption_version": 0,    "name": "biometric-reader",    "supports_decryption": true,    "supports_derivation": true,    "supports_encryption": true,    "supports_signing": false,    "type": "aes256-gcm96"  },  "wrap_info": null,  "warnings": null,  "auth": null}