Key Management for Application Tier Encryption

With Shield Platform Encryption, Salesforce administrators can manage the lifecycle of their data encryption keys while protecting those keys from unauthorized access. To ensure this level of protection, data encryption keys are never persisted in plain text. If a customer has opted out of key derivation, then a wrapped DEK is persisted, but must be unwrapped by the regional Shield KMS or external KMS.

The KDF seed is generated by an HSM in the primary KMS at the start of each release. Access to the HSM and generation of primary keys is done by way of a High Assurance Virtual Ceremony (HAVC), a process conducted by a ceremony administrator in cooperation with several cryptographic administrators.

Key material is generated on demand by using the HSM and the primary Shield KMS, or it’s supplied by the customer using BYOK.

EKM gives customers the option for managing root keys and DEKs through their external KMS accounts. Root keys are stored in the external KMS. Shield Platform Encryption requests a wrapped DEK from the external KMS, and stores it in the Salesforce database. When the DEK is needed, Shield Platform Encryption sends the wrapped DEK to the external KMS. The external KMS unwraps the DEK and sends it back to the application where it’s securely cached for a limited time. The DEK is never persisted as plaintext.

BYOK gives customers more control and flexibility for managing key material via an API service. Customers can use open-source crypto libraries, their existing HSM infrastructure, or even third-party key brokering services to create and manage tenant secrets and data encryption keys outside of Salesforce. They can then give Salesforce’s KMS access to that key material. Customers can revoke this access at any time.

Each regional Shield KMS has access to the release-specific secrets for every Salesforce release. By default, when a data encryption key is needed to encrypt or decrypt customer data, the regional Shield KMS derives the key from the KDF seed and the tenant secret.

Customers can opt out of key derivation on a key-by-key basis and upload a final data encryption key, or they can store their keys in external key management systems for on-demand retrieval. By controlling the lifecycle of your organization’s key material, you control the lifecycle of the derived data encryption keys. Your Salesforce administrator specifies a user to manage the key material for your organization and assigns that user the Manage Encryption Keys user permission. This user permission allows the key administrator to generate, supply, archive, export, import, and destroy key material.

It’s possible to have more than one active tenant secret or data encryption key in an org. You can apply specific keys to data stored in different areas of Salesforce. For example, search index files are stored separately from other Salesforce data, so customers can apply key material to specific data in those files. Only the most recent tenant secret or DEK of a given type is active. Only that key material is used to derive the DEK used to encrypt data of a specified type. When you generate or supply key material, the active secret becomes archived. Archived key material is used to decrypt data that was last encrypted when the archived key material was active.

You can destroy an archived tenant secret or data encryption key. If you destroy a tenant secret, it’s no longer possible to derive the encryption key that’s required to decrypt the data that was encrypted using that key. Similarly, when you destroy a customer-supplied DEK, you can’t access data encrypted with that key. Take special care to back up and protect archived key material and encrypted data. After you destroy key material, it’s fully removed from the persistent layer and encrypted key cache, and it can’t be recovered.