My manager claims that Salesforce has very weak and limited support of cryptography and encryption. I want to disprove this statement and prove that we could, for example, implement some custom encryption service on top of Salesforce Platform, using the Tenant Secret Key from Platform Encryption feature.

Is there any way to get value of Tenant Secret Key by Apex Code?

For example, if I want to use Tenant Secret Key to encrypt and decrypt data with Crypto class

Blob Key = Blob.valueOf(Apex.getPlatformEncryptionTenantSecretKey());
Blob encryptedData = Crypto.encryptWithManagedIV('AES128', key, data);
Blob decryptedData = Crypto.decryptWithManagedIV('AES128', key, encryptedData );
System.assertEquals(data, decryptedData );

Is there any method there, let's say, Apex.getPlatformEncryptionTenantSecretKey() to get it?

  • How would that increase your security? If you're using Shield Encryption, that data is already encrypted at rest. If you don't trust Salesforce, encrypting data in-platform doesn't defend you against them.
    – David Reed
    Feb 5, 2018 at 15:50
  • I think you don't understand me. When my client bought Platform Encryption feature, he was very confused that data is not masked and that users do not need View Encrypted Data permission to see unmasked data. If we implement custom encryption, this would help to decide for which users to show encrypted data and for which decrypted. Currently there is no such option (except Classic Encryption - but this works only for a specific field type and you can't encrypt picklist fields, well, using Platform Encryption we also can't do that).
    – Patlatus
    Feb 5, 2018 at 16:10
  • So basically implementing custom encryption will provide us two benefits. 1. Control of which users can see masked or unmasked data. 2. Support field types such as Picklist Fields which are not supported for Encryption neither by Classic nor by Platform Encryption
    – Patlatus
    Feb 5, 2018 at 16:11

1 Answer 1


Just to clarify, we do not provide the ability to our customers to encrypt arbitrary data with the shield keys themselves because it's not what we're trying to achieve.

Shield, at least as of today, is not about giving the ability to our customers to store keys for performing crypto operations.

You absolutely can encrypt data yourself with your own keys backed by your own HSM or some key management system, and store that data in our cloud as ciphertext. You will then be the only one being able to decrypt it. This is perfect security wise, but it means that our platform can not understand your data and hence you can't leverage most of the features that come with our platform and products

If we were giving you the ability to encrypt arbitrary data with the shield keys, then we would still not be able to understand it because we would not know what you decided to encrypt, and you would encrypt with a key that we have access to which actually lowers the security for you without giving you any additional feature.

The whole point of Shield is to give you as much feature as possible while encrypting the data at rest, provided that you are trusting our architecture to handle the keys.

On the masking part, we decided to retire it, mainly because shield is not about protecting the data from the user that is logged in the org, but rather protecting your data from other persons attempting to access your data, such as hackers. When it comes to protecting access to the data for users in the org, the platform comes with many ways for you to control it (CRUD, FLS, sharing, ...). If masking is a must have for your customer, the classic encryption still provides that ability.

On a side note, even if you were encrypting the picklist values yourself, that would actually not be that secure given how the picklists are handled in our system. The labels of the picklists would be encrypted, but if someone would peek in the database they could know which records use the same picklist value.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .