Key management

Z0sickx

Hi all,

it’s been quite some time since my last post but looking to validate my thought process.

I have a requirement to have a cloud encryption solution that ensures my org owns the encryption keys. By own it mean  the cloud provider of choice could not be compelled to give up keys of customers. So far from what I can till is the big three would not have this capability if you use their Key management service with HSM. Additionally I must be able to distribute, and maintain control of key material

my thoughts are symmetric key material would be created offsite—>imported via secure tls session and key material  is wrapped —> plaintext keys secured in HSMs that in theory are tamper proof and CSP has no access. Data we have would not be collocated in same CSP platform (but could be later)

is there’s any other technology beyond this that can do this? Assuming this meets outcome (avoiding use of BYOK since this is a marketing term)

JDMurray

Do the keys needs to be stored in the CSP's system? Will the encrypted information be processed in the CSP (necessitating decrypting in the Cloud) or just stored there?

Z0sickx

An on premise solution would be out of the question so it would be stored in CSP. The key material generation would be on premise. The encrypted keys managed my CSP KMS would be utilized on demand by other SaaS/PaaS applications.

scasc

Usually you have 3 options with Cloud encryption.

1. Either adopt a HSM (however this is costly per API call made) and you need to manage and protect it as it is dedicated to you.
2. You adopt KMS - with either cloud managed keys or you can manage keys. The key store can be the default one issued by KMS or you can have your own key store to manage the encryption rotation per your scheduled requirements. Either way within the key store you can manage the encryption keys whereby AWS do not have access to the underlying keys. Usually called server side encryption
3. Client side encryption - which is what you mentioned above, but the keys are generated and stored on-prem and with each API call is presented to the solution to allow encryption/decryption to occur. 

So you can adopt a dedicated HSM - but bear in mind the cost and added burden to manage and protect this - harden, patch, ensure its in same region of workloads etc. Also, can adopt SSE-KMS with choice of the key store. 

JDMurray

@Z0sickx  Are you using AWS? If so, have you looked into the AWS Secrets Manager service?
I'm thinking you can't be the first org to have this problem and maybe this is (part of) the solution.

scasc

Secrets Manager is not for encryption keys. Only things like tokens, API keys and other secrets. Encryption keys is managed via KMS. 

Sounds like KMS with either own key store to manage key lifecycle or key material is required here. Just a guess based on use case. 

scasc

Hi Saima,

There are a couple of concepts here to remember. The KEK (key encryption key) is what should wrap around and protect the DEK (data encryption key - which is the encryptor). The encrypted DEK can stay with your data, however it is the KEK that needs to be in HSM. If you can generate the KEK in the HSM, so that it does not leave it - that would be ideal. Also, if you are loading it, you should set a pin/passcode to protect it from unauthorised use. 

The general process you have outlined seems fine. 

Depending on your setup, you can also generate keys via TPM or a RNG CPU processor. 

You may also want to know that with AWS for example, if you use AWS HSM it is completely for your use, and is not accessible. To be honest same with KMS, but you need to apply the KMS grant to determine who has access to the keys.