On a CRM implementation, if you are asked to make a presentation on Salesforce Shield- Platform Encryption features then this can be it.

Salesforce Shield has three pillars- Platform Encryption, Event Monitoring and Field Audit Trail. This blog deals with Platform Encryption.

Key Points- Agenda

• Activation of Shield​
• Key Management
• Differences between Probabilistic & Deterministic encryption​
• Encryption by the state of Records​
• Reasons for failure to Encrypt​
• More FAQ’s on encryption​
• Best practices to implement shield

Activation of Shield

• Shield is activated by Salesforce — License​ has to be provisioned by Salesforce
• Assign permissions​
• Customize Application​
• Manage encryption keys​
• Probabilistic By default​
• AES 256 STANDARD – This is an encryption standard

Key Management in Salesforce Shield

• Encryption of Data is carried out by Keys​
• Tenant secret key is generated and managed by the Tenant​
• This key is combined with a per-release master secret to derive a data encryption key. ​
• This derived data encryption key is then used in encrypt and decrypt functions. ​
• You can also use the Bring Your Own Key (BYOK) service to upload your own key material, or store key material outside of Salesforce and have the Cache-Only Key Service fetch your key material on demand.​
• Tenant secret is unique to the org​
• Master secret is created for everyone before every release​
• Final key derivation is based on Master and Tenant secret​
• We can let Salesforce generate the Tenant secret​
• We can generate our tenant secret with the BYOK module​
• We can opt out of KMS altogether and generate a data encryption key and upload to KMS using BYOK — Key derivation is completely avoided
• When a Salesforce user saves encrypted data, the runtime engine determines from metadata whether to encrypt the field, file, or attachment before storing it in the database.​
• If so, the encryption service checks for the matching data encryption key in cached memory.​
• The encryption service determines whether the key exists.​
• If so, the encryption service retrieves the key.​
• If not, the service sends a derivation request to a key derivation server and returns it to the encryption service running on the Salesforce Platform.​
• After retrieving or deriving the key, the encryption service generates a random initialization vector (IV) and encrypts the data using 256-bit AES encryption.​
• The cipher text is saved in the database or file storage. The IV and corresponding ID of the tenant secret used to derive the data encryption key are saved in the database.

Differences between Probabilistic and Deterministic encryption​

• Deterministic is a specific type of encryption. ​
• In this type of encryption, the resulting converted information, called cipher text, can be repeatedly produced, given the same source text and key. For example, ​

If you know that the message ‘hello world’ has the cipher text ‘&yy/ m/jyp’ under some form of deterministic encryption, then that message will always produce the same cipher text.​

• Probabilistic is also a specific type of encryption, but unlike deterministic, it introduces an element of chance. ​
• Source text repeatedly encrypted with the same key will normally yield different cipher text. ​
• So, a simple message like ‘hello world’ won’t always correspond to the same cipher text. ​
• Instead, that message would produce one of many possible cipher texts each time it’s encrypted.​
• Deterministic is the filter preserving encryption.​
• It is easier to crack then probabilistic​
• Deterministic- case sensitive and non case sensitive encryption

Encryption by State of records​

• If a record is created after the encryption is activated with fields which are encrypted then the encryption is immediately active​
• For existing records the encryption is not activate- salesforce has to be contacted to get the encryption activated- This​
• can also be achieved by Sync feature on encryption statistics​
• If existing records are updated after the encryption then it is activated on them​
• For data loader uploads and mass uploads after encryption, it is activated​

Reasons for failure to encrypt

• Once encryption is applied to fields, following is checked​
• Criteria-Based Sharing Rules​
• SOQL/SOSL Queries- These queries are sorted on the encrypted fields​
• Formula Fields​
• Skinny Tables​
• Microsoft Integration Products​
• List View Filters – No effect​
• Report filters – No effect​

Faq’s on shield

• If reports are exported with encrypted data they will show data the normal way​
• Encrypted field values are searchable through global search​
• SQOL query will run the normal way- sort will not work​
• case comments field with more then 2959 characters will not let the record encrypt​
• Id encrypted field is involved in integration- no effect​

Best Practices to implement shield

• Only encrypt wherever required​
• Explore all data and org security options before deciding to encrypt​
• Don’t misinterpret encryption with masking​
• Key management should be carefully planned and executed​
• Keep in mind- encryption works only for unauthenticated users in the org​

Please note that I have not included test cases for Shield Platform encryption and differences between Shield and Classic encryption. I will cover them in a separate blog.

This can give you a good headstart on an implementation.

I hope you have liked reading it. I am motivated by your shares, comments and likes.