You are here:
Key Derivation Architecture
Secrets and secret-wrapping keys used in the key derivation process are initialized by the HSM in the primary Shield KMS at the start of each release. For customer-provided tenant secrets, they’re initialized on demand in production environments by the HSMs in the regional Shield KMSs.
BYOK customers can opt out of the key derivation process by uploading their own data encryption keys. EKM customers don’t use derivation. Their DEKs are generated and then supplied wrapped by the external KMS. In both cases, the key materials are stored wrapped in Salesforce. Database Encryption customers using BYOK must provide a full data encryption key, so there is no need to opt out of derivation.
Customer-supplied DEKs are used to directly encrypt and decrypt data. They give customers more fine-grained control over the key material used to secure their data. Because these keys are applied directly to customer data, Salesforce recommends that customers take adequate safety measures to back up and control access to these keys.
Processes in Key Derivation Architecture
- HSM initialization
- Before being put to use, an HSM is initialized, which includes the creation of its respective encryption key pairs.
- Per-release secret generation
- At the start of each release, the per-release secrets are generated within the HSM during a High Assurance Virtual Ceremony (HAVC). The secrets are stored in the primary Shield KMS for consumption by the primary Shield KMS and regional Shield KMSs.
- Primary Shield KMS startup
- When the primary Shield KMS starts up, it accesses each release’s encrypted secrets stored in the HSM. It makes these secrets available to the Key Escrow server. Also, it decrypts the secrets and stores them in its encrypted key cache in preparation for key derivation requests.
- Regional Shield KMS startup
- When a regional Shield KMS starts up, a local key broker service requests secrets from the Key Escrow server. The key broker gets the key material and writes it into the regional Shield KMS. The regional Shield KMS then decrypts the secrets and stores them in its encrypted key cache in preparation for key derivation requests from app servers.
- On-demand root key and DEK generation
- For Shield Platform Encryption services that use root keys, such as Search, a customer generates both root keys and DEKs as needed. Root keys provide an added layer of protection for the KMS generated DEKs used by the service. The request is sent to the regional Shield KMS from the application server and authenticated. Root keys are generated either by the regional Shield KMS, or by the customer’s external KMS. The root key is visible on the key management page under the Root Key inventory. With an active root key available, compatible services have their DEKs generated by the same KMS as the active root key. The DEKs are wrapped on the KMS using the active root key before being sent back to the application server to be stored in the database.
- On-demand tenant secret generation
- One of the inputs into the key derivation function that creates your organization’s data encryption key is an org-specific, customer-managed tenant secret. Customers control the lifecycle of their DEKs by generating new tenant secrets. When a customer starts the process to generate a new tenant secret, the request is sent to the regional Shield KMS from the application server and authenticated. Then the regional Shield KMS generates and sends an encrypted tenant secret back to the application server to be stored in the database. This is the case for FLE tenant secrets and Database Encryption seeds.
- Key derivation in production environments
- When a customer attempts to read or write encrypted data and the corresponding data encryption key isn’t cached in the app server, the application server sends a derivation request to the regional Shield KMS. The regional Shield KMS authenticates the request and derives the key using the secrets in its own encrypted key cache. The key is then transmitted securely back to the application server.
Shield Platform Encryption Architecture Components
- Primary HSM (nShield® Connect HSM model XC High or XC Mid, depending on region)
- A FIPS 140-2 Level 3 hardware-compliant network appliance that generates per-release secrets and secret-wrapping keys. Access to the primary HSM is restricted to designated Salesforce security officers during controlled High Assurance Virtual Ceremonies (HAVCs)
- Primary Shield KMS Server
- The Shield Key Management Service consists of a single Primary KMS and multiple regional KMSs. The Primary KMS is the first KMS to receive the per-release secrets. It makes those secrets available to the Key Escrow server. In addition to supplying the Key Escrow, it also services key material requests like any regional KMS server.
- Key Escrow Server
- The Key Escrow Server acts as a go-between for the primary Shield KMS and the regional key brokers. It obtains wrapped secrets material from the Primary KMS and hands them off to key brokers on request.
- Regional Shield KMS Servers and Key Brokers
- Regional Shield key management servers are deployed to the Salesforce production data centers. The regional KMSs securely provide per-release key material to the application servers. The regional KMSs also generate tenant secrets. One key broker acts as the go-between for the Key Escrow and a regional Shield KMS.
- External Key Management Service
- Customers who use the BYOK or Cache-only Key features must manage their key material using an external KMS.
- Application Servers
- Servers in production environments that run Salesforce. When a customer attempts to read or write encrypted data or generate a tenant secret, the application server communicates with the regional Shield KMS to process the request.
- Database Fragment
- The smallest unit of data encrypted under Database Encryption. Referred to as a page or block in some transactional databases. Database Encryption uses a unique DEK to encrypt every fragment.
- Salesforce Search Index
- Servers in production environments that manage Salesforce searches. When a user attempts to query encrypted data, the search index processes the request.

