How do I get value of Tenant Secret Key by Apex Code?

Question

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?

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.