The Inner Circle

 View Only
  • 1.  Hold Your Own Key (HYOK) vs Bring Your Own Key (BYOK)

    This message was posted by a user wishing to remain anonymous
    Posted 11 days ago
    This message was posted by a user wishing to remain anonymous

    Is anyone aware of a good source of information pertaining to Key Management options for SaaS? Specifically comparing Bring Your Own Key (BYOK) vs Hold Your Own Key (HYOK) options, benefits, and drawbacks. I've found snippets of information online from various vendors and Cloud Service Providers (CSP) but was hoping to find something from an independent author or resource. My understanding so far is that with HYOK, the client has complete ownership and management of the keys and encryption and decryption occur client side preventing the CSP from potentially accessing encrypted data. With BYOK master keys are created by the client and CSP, then a composite key is created that is used by the CSP to encrypt and decrypt the data. Clients can revoke access to the data by expiring the Client master key, but before then the CSP still has the potential to access encrypted data regardless of being provisioned access. Would like to check with the community for feedback to see if my understanding is correct.

  • 2.  RE: Hold Your Own Key (HYOK) vs Bring Your Own Key (BYOK)

    Posted 8 days ago

    CSA has a Working Group that is focused solely on cloud key management. Not surprisingly, it is called the Cloud Key Management Working Group, and it can be found here:

    We have not written a paper exclusively comparing BYOK (an acronym, by the way, that is meaningless and useless) and HYOK (ditto uselessness). We did, however, address this question in the first paper that our Working Group published, called "Key Management When Using Cloud Services", which of course you will find on the CSA web site.

    The reason that "BYOK" and "HYOK" are useless (actually, worse than useless - they are confusing) is that there is no standards body that defines them and any company - Microsoft, Amazon, Google, etc. - that uses the acronym gets to define it uniquely every time. In some cases the same cloud provider used different definitions of the same acronym among its own cloud services! A best practice is to avoid using those acronyms and instead describe goals and requirements. As you point out, if the customer is transmitting/storing only encrypted data with their CSP and the CSP has no ability to decrypt the customer data then privacy is preserved (other than potential metadata leakage). You seem to have a clear grasp of the dynamics where CSPs have key material and where they don't so my guess is that you didn't need those acronyms anyway. :-)  I encourage you to leverage our content and provide feedback if we need to add or improve coverage of any cloud key management topics.


    Paul Rich

    Paul Rich CIPP/US CIPP/G
    Executive Director