Get Started with Shield Platform Encryption
Learning Objectives
After completing this unit, you’ll be able to:
- Identify the different types of key material in Shield Platform Encryption.
- Explain the relationship between primary secrets, tenant secrets, root keys, data encryption keys, salts, and initialization vectors.
- Identify the parts of a key derivation function.
- Explain the difference between probabilistic and deterministic encryption.
Get Ready for a Security Review
Zephyrus is a small company that offers comprehensive relocation management for corporate employees moving out of their native countries. The company helps employees acquire visas, find housing, locate schools, arrange for language training, acclimate to a new culture, and more. This means that Zephyrus handles a lot of personal, and sometimes sensitive, customer information.
Carolyn, Calvin, and Ernesto meet to discuss the company’s recent performance and data security. Carolyn, the CEO, highlights the company’s customer confidence in its data tracking and backup recovery, which is great news. Ernesto, the director of IT, raises concerns about data vulnerabilities identified in a recent security review, specifically for data at rest. Carolyn suggests they dig into the company’s current encryption practices. Calvin, the Salesforce admin, explains that Zephyrus uses Salesforce Classic Encryption, which provides 128-bit encryption on certain sensitive fields. However, Ernesto points out that the security review suggested an upgrade to 256-bit encryption and better key management.
Calvin mentions that Shield Platform Encryption offers many useful features.
- 256-bit encryption strength
- Full encryption of the transactional database
- Field-level encryption (FLE) for finer-grained protection
- Platform Encryption for Data 360 to secure their data sources
- Search Index Encryption that closes a vulnerability with queries on sensitive data fields
- Files and Attachments encryption for items not stored within the database
- Event Bus Data Encryption to protect Salesforce data captured for changes and events
Shield Platform Encryption also provides options for managing their own encryption keys. Carolyn tasks Ernesto to take a closer look at Shield Platform Encryption, and she tasks Calvin with finding out Shield Platform Encryption’s requirements and deployment process.
Learn the Different Encryption Key Materials
Ernesto loves to deep-dive into technology. He quickly finds out that Shield Platform Encryption uses several different components.
One thing about Shield Platform Encryption is that the data encryption keys (DEKs) are never stored in plaintext on disk. DEKs can be generated by the key derivation function (KDF). Or they can be generated directly, either by Salesforce or an external function. DEKs generated by a KDF, such as for field-level encryption, only exist in the encrypted key cache. DEKs in the cache expire quickly, and are removed from the cache until needed again.
DEKs that are generated directly, such as for Search, are stored in the TenantSecret table. However, they’re wrapped (doubly encrypted) by the root key, and only unwrapped when placed in the encrypted key cache.
Ernesto likes KDFs, because having several key components and a KDF increases their security. Having a root key to wrap DEKs is great too, because it’s compatible with external key management services.
Distinguish Between Probabilistic and Deterministic Encryption
Next, Ernesto looks at the types of encryption available. For field encryption, Salesforce provides for two encryption schemes, probabilistic and deterministic.
With probabilistic encryption, an Initialization Vector (IV) is randomly generated and submitted as part of the encryption function. Adding a random IV produces a different ciphertext every time the plaintext is encrypted, even if the plaintext hasn’t changed. It’s very secure, but can result in a loss of some functionality, such as for filtering operations.
As an alternative, you can opt for deterministic encryption. Instead of a random IV, a field-specific static IV is used instead. This IV never changes, and allows for more functionality. But because the IV never changes, encryption results in the same ciphertext every time if the plaintext hasn’t changed. So it’s a bit less secure.
Ernesto decides to recommend probabilistic encryption to start with, then let a test group try it and give feedback on any changes in performance and usability.
Review the Features of Externally Managed Keys
Ernesto discovers that by default, key materials that are generated within the Salesforce app, like root keys or tenant secrets, are stored within the Salesforce database. Though it’s not a requirement now, Ernesto knows that Zephyrus will have to eventually begin managing its own key materials. He's relieved to know that Salesforce provides several key management options.
-
External key management (EKM) lets you use an external KMS as the controller for secrets. Zephyrus already uses AWS KMS for other security functions, so this might be an easy way to go.
-
Bring your own keys (BYOK) lets you use key materials generated or stored in any secure key service as the source for secrets.
-
Cache-only keys (CoK) is a special feature where you can insert a BYOK DEK directly into the encrypted key cache, bypassing the KDF.
The EKM, BYOK, and CoK features require you to supply AES-256-bit keys. They’re used in whichever mode (probabilistic or deterministic) you’ve selected for the feature (FLE, Platform Encryption for Data 360, and so on).
Before going on to the next section, let’s review Shield Platform Encryption features, types, and modes.
Learn About Key Rotation
Key rotation is when you generate or supply new key material to use as your active secret. In his security review, Ernesto learned he should rotate the company encryption keys every 120 days, and that he should securely back up every old key. Ernesto has been wanting to set up a secure repo for secrets and keys anyway, and is looking forward to doing that (yeah, he likes his tech).
When you rotate key material, all the DEKs derived from that material rotate as well. New data is encrypted and decrypted by using the new DEKs, which are derived by default from the new, active tenant secret.
The primary Salesforce secrets are rotated each release (three times a year). Ernesto is relieved to see that he can rotate tenant secrets, root keys, and DEKs as frequently as every 24 hours—much more than he needs.
Ernesto is finished with his analysis, and is ready to let Carolyn and Calvin know what he’s found. But first, let’s see what Calvin has discovered about Shield Platform Encryption features in the next unit.