You are here:
Tenant Secrets, Root Keys, DEKs, and More
Central to encryption are the secrets and keys that the platform uses to encrypt and decrypt data. Throughout this guide, we refer to nearly a dozen types of secrets, materials, and keys that participate in the Shield Platform Encryption process. Before reading further, it’s helpful to understand how these parts relate to each other. A glossary at the end of the guide defines all the different secrets and material types that we discuss.
Data Encryption Keys
The algorithm that actually encrypts your data uses a data encryption key (DEK). By default Salesforce DEKs are derived by using a key derivation function (KDF). Because DEKs are derived, Salesforce never writes them to disk, which means that nobody ever has direct access to them. DEKs are created when they’re needed, and they’re stored in a secure memory cache. Customers can supply key material to be used in a KDF, or they can bypass the KDF and supply a complete DEK .
KDF Components
Each DEK is derived by using up to 3 types components, or key materials. One of these key materials is a cryptographic key that Salesforce contributes, known as the KDF seed. Another is a cryptographic key that you contribute which we call a tenant secret (or database tenant secret). And the encryption platform contributes the third one, which is an initialization vector (IV) or salt.
In this guide, we define the different types in these ways.
- seed — A value that’s used in a KDF function to generate a key, such as our KDF seed and database tenant secret.
- secret — The term “secret” can be confusing because people often use it in place of key, seed, or salt. A tenant secret or a database tenant secret is one of the inputs to a KDF to generate a DEK.
- salt — A generic term for a random number to a KDF algorithm to generate a DEK. The KDF salt is generated once per release, and a Database Encryption salt is generated for each fragment that’s encrypted.
- initialization vector (IV) — A random value produced for FLE and Database Encryption. We use IV for this term throughout this document.
Every release, Salesforce creates a new KDF seed and a new KDF salt for application tier encryption. Both are created during a High Assurance Virtual Ceremony (HAVC) by Salesforce cryptographic administrators. The KDF seed and KDF salt are used to create org-specific tenant secrets.
Every tenant can periodically create a tenant secret or a database tenant secret for rotation. Database Encryption creates a new per-fragment salt for each fragment that it encrypts.
The KDF seed, KDF salt, root key, tenant secret, root key, DEK, and database tenant secret are all secret cryptographic key components. It’s not necessary for the IVs to be secret, but they must be random.
When a DEK is needed, the required components are passed to the KDF. For the application tier, a DEK needs the KDF seed, the tenant secret, and the probabilistic or deterministic IV. For Database Encryption, a DEK needs the database tenant secret and the per-fragment database encryption salt.
Root Keys
Root keys are special keys that are used solely to wrap and unwrap DEKs.
Salesforce uses root keys in Search Index Encryption. These root keys are hosted in the regional Shield KMS or in an external KMS. They wrap secrets that are used either as a KDF component or as a final DEK for when customers opt out of derivation.
Wrapping Keys
Also known as key encryption keys (KEKs). These are separate cryptographic keys that are used to protect key material and DEKs when they’re moved or cached. Shield Platform Encryption uses several KEKs for transporting key material to the encrypted key cache. You read about them in the section How Shield Platform Encryption Works.
