Key Management Service

Customers want the ability to keep their data safe from unauthorized modification and exposure. Here are some example use-cases

1. Applications wish to encrypt the data-at-rest and in-transit in private, public and edge clouds
2. An application running on the edge device would encrypt the data locally, and the data is periodically backed up to the cloud. A different application on the public/private cloud would decrypt the data for use in the cloud.
3. Application A performs a cryptographic signing of a chunk of data, passes to Application B, who would cryptographically verify the signature before using the data.
4. Customers have primary sites in private cloud and disaster recovery sites in the public cloud. Data is encrypted on the private cloud and continuously backed up to the disaster recovery site. Upon failure of the primate site, customer applications use data from the disaster recovery site, which requires the decryption of the data.

F5® Distributed Cloud App Stack offers Key Management Service (KMS) that solves the use cases listed above by managing the keys used for purposes such as encryption, decryption, signing, and verification, etc.

KMS Features

Key Management Service (KMS) provides the ability for customers to define strict policies around which applications have access to the keys and what operations can be performed using the key. The key operations supported are encryption, decryption, HMAC, HMAC verify, signature, signature verify and access to the key value. The KMS supports both symmetric and asymmetric encryption, digital signature, HMAC operations with strong cryptographic algorithms such as AES-GCM-AEAD, RSA-OAEP, RSA-PSS, and HMAC-SHA256. The KMS also supports versioning and rotation.

The KMS is used internally by F5 Distributed Cloud Services to keep customers’ configuration and data safe as well. All internal components that handle customer data use encryption keys from KMS for encryption of data-at-rest and in-transit.

The workflow to use the KMS is as follows

1. An administrator from the customer organization requests a key from the KMS on the F5® Distributed Cloud Console. The administrator is provided a key-handle and not the actual key.

2. The administrator configures a KMS policy to define which applications can access the key, and what operations can the application perform using the key. For example

   1. The administrator can specify that applications A and B have access to the key-id foo, but application A can only perform an encryption operation, while application B can only perform a decryption operation.
   2. The administrator can specify that applications C and D have access to the key-id bar, but the application C can only perform a signature operation, while application B can only perform a signature-verify operation.

3. The administrator also chooses the sensitivity level on the key from amongst low, medium and high

   1. Low sensitivity level - In this case, the key can be distributed to the Wingman security side-car that is injected into the customers’ POD. The key only exists in Wingman’s memory which is inside the customers’ POD.
   2. Medium sensitivity level - In this case, the key is stored in the F5 Distributed Cloud Services central control plane. If an application wishes to use a medium sensitivity level key for encrypting a chunk of data, for example, the application has to send the chunk of data to the central control plane where the data is encrypted and then sent back to the application wherever it maybe.
   3. High sensitivity level - In this case, the key is stored in an HSM. The application has to send the data to the central control plane just like it does in the medium sensitivity level scenario.

4. The administrator distributes the key-handle to applications that wish to use the Key Management services.

5. The application calls Wingman, the security side-car injected into customers’ POD, to perform an encryption operation for example.

6. Wingman reaches out to KMS to request access to the key using the key-id.

7. The KMS does an authentication check with F5 Distributed Cloud Identity Authority to validate the application’s identity

8. After the application’s identity is verified, the KMS does an authorization check using a KMS policy to determine if the particular application is authorized to access the specified key-id. Note that this authorization is only possible because of the generated application identity.

9. Wingman determines the sensitivity level of the key and does one of the following

   1. If the key sensitivity level is low,
      1. KMS performs the operation specified (e.g., encryption), and returns back the encrypted bytes and also provides the key to Wingman.
      2. Wingman returns back the encrypted bytes to the application.
      3. For future requests using the same key-id, Wingman caches the key-value and does not reach out to KMS again.
   2. If the key sensitivity level is medium and high,
      1. Wingman sends the data to KMS.
      2. KMS performs the operation specified (e.g., encryption), and returns back the encrypted bytes to Wingman.
      3. Wingman returns back the encrypted bytes to the application.
      4. For future requests using the same key-id, Wingman has to reach out back to KMS again to perform the operation

Concepts

The following topics are used by KMS features. Click on each one to learn more:

• Key Management and Data Security
• KMS Policy
• Application Identity
• Wingman