0

Shield Platform encryption provides 2 options for tenant secrets.Customer-supplied tenant secret upload(BYOK) and On-demand tenant secret generation. I am looking for advantages of BYOK over on-demand tenant secret generation. To me it seems like both are same. Either you upload a tenant secret to Salesforce or you let Salesforce generate a tenant secret. Does anyone have better ideas?

  • For some Financial companies have their own mechanism for hashing and creating keys and they frequently change tenant secrets for security reasons. So, it's up to their own process of regulations. – Santanu Boral Jul 28 '17 at 4:56
  • @SantanuBoral: As per this Salesforce doc, help.salesforce.com/… The first para itself mentions that "In either case, you manage your own tenant secret: you can rotate it, archive it, and designate other users to share responsibility for it." Hence it does not matter if tenant secret is generated by a customer or Salesforce, rotation, archiving remains same in both case. So even if salesforce generated tenant secret is used, companies can rotate it as per their policy. – Vishal Jul 29 '17 at 14:41
0

Absolutely, I completely agree with you.

We are expanding our BYOK capabilities in multiple steps

1/ Bring your own entropy, which is what we offer today

2/ Bring your own key

3/ Cahe only key

With 2/, you would be able to provide us the actual AES key we would be using for encrypting/decrypting the data. But your key would still be stored encrypted in our database, the same way that we store your entropy today, and we would use our HSM only for wrapping/unwrapping your key

With 3/, your key will only stay in memory and would never touch any of our system of records. We would keep it in our cache for an amount of time under your control, forcing us to go back to your HSM to fetch it again on a regular basis.

Everything is of course under the usual safe harbor, but as an FYI we are starting working on 2/ and we are in the middle of a 2-releases entire refactor of our caching strategy in preparation for 3/

  • This is really nice to hear. And how can i keep updated ? Anyway we can stay connected on this topic? – Vishal Sep 3 '17 at 0:45
0

The main principle behind the platform encryption key management is that a key used for encrypting/decrypting data can only be retrieved at runtime by our application via 3 mandatory pieces: 1/ The tenant secret that is under your control as a customer 2/ The salesforce secret that changes every release 3/ The special servers within our data centers that have the only HSMs that can derive the keys from these 2 secrets

Coming back to your original question, the difference between BYOK and the default is that in case of BYOK, you can use your own random number generator to provide the secret, as opposed to in the default case, we will rely on the random number generators coming with the HSM cards.

As an FYI, and under the usual safe harbor, we're looking at another version of BYOK, where as a customer, you can provide the actual encryption key, instead of only the secrets, giving even more control on the key generation.

  • So the only benefit is that the customer controls source of entropy. I will be interested to know the another version of BYOK. To me , a BYOK where your service will call customer's HSM for encryption key as needed gives more benefit and stronger assurance that Salesforce can never have persistent access to the key. What are your thoughts? – Vishal Aug 30 '17 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.