Application side data protection with FIPS 140-2 Level 3 : what to use out of Encryption SDK, KMS or Cloud HSM?


Hello there, I do have a requirement in my application to encrypt and decrypt data using a symmetric key algorithm (mostly AES/CBC/PKCS5Padding).

CONSTRAINT and Requirements are

  1. I need to use FIPS 140-2 Level 3 compliant key storage solution
  2. This is an existing encrypted data and hence I should be able to import my existing keys (plain keys) to whatever solution I use.
  3. Even in the future, keys should be open for EXPORT so that encrypted data with this new solution WILL NOT require another re-encryption with new keys.

Keeping the above points in mind, I came across below solutions so far and need guidance and help if someone finds that not a good solution or it will break any of the above requirements I listed.

  1. I can use AWS Encryption SDK with AWS KMS using a custom key store where the custom key store would be my own Cloud HSM.
  2. I can directly use Cloud HSM by leveraging standard Cloud HSM integration using Cloud HSM JCE provider and client SDK.
  3. I can AWS KMS with KMS API with a custom key store where the custom key store would be my own Cloud HSM.

I knew #2 will work without breaking any of my requirement and compliance list but I want to see if I can use Encryption SDK and/or KMS for my use case as I can get help of SDK to choose best industry practices to write cryptography code instead of I write whole code (in case of Cloud HSM integration) but below points will stop me.

  1. Custom key stores can not work with imported keys so it will break my requirement #2.
  2. I can use AWS Encryption SDK with KMS but as import does not work for custom key stores, it's not usable any more. Can I use AWS Encryption SDK somehow to help me with data encryption directly with Cloud HSM?
  3. Data enveloper protection (by AWS Encryption SDK) is really more secure for symmetric key encryption. If I use that today and later want to move to Cloud HSM, will it break the decryption flow?

Any suggestion/experience learning/insights or architectural direction is greatly appreciated.

1 Answer

From your requirements option 2/CloudHSM would be your best option.

It complies with FIPS 140-2 level 3\[1].
You import your own existing keys\[2].
Exporting key is also possible\[3].

The primary roadblock you face with attempting to use a KMS Custom Key Store is you cannot import key material into a KMS key Custom Key Store. KMS will instead generate the key material for the KMS key in the AWS CloudHSM cluster[4].

Primarily due to your FIPS 140-2 level 3 requirement, using CloudHSM with one of the Client SDKs[5] would be the best option.

Regarding your question about whether you can use the Encryption SDK with CloudHSM, I did come across the following section in our FAQ[6] for the Encryption SDK:

"You can use AWS KMS keys as wrapping keys in the AWS Encryption SDK, but it is not required. You can use encryption keys that you generate and those from your key manager or on-premises hardware security module. You can use the AWS Encryption SDK even if you don't have an AWS account."

From that line, it may be possible to use the Encryption SDK with CloudHSM but I was not able to find any specific examples of this so it may require some testing on your end.

[1] FIPS validation -

[2] Using the command line to manage keys - Import keys -

[3] Using the command line to manage keys - Export keys -

[4] Managing KMS keys in a custom key store -

[5] AWS CloudHSM Client SDKs -

[6] Frequently asked questions -

answered 2 years ago
  • Thanks Michael. I like to use AWS Encryption SDK with the keys generated out of the Cloud HSM. Reasons behind are:

    1. Envelope Encryption. Each message is encrypted using data key and data key is encrypted using another wrapping key (this would be wrapping key from Cloud HSM).
    2. I do have a requirement to have distinct keys for each region (app will be deployed to multi-regions). Though distinct keys, I want to keep supporting DR, Failover. Cloud Backup and generation of new cloud from that is an option but that is a manual route and keys don't sync once backup is done. Solution would be using Multi-keyrings ( I can have multi keys (one for region) and encryption SDK will encrypt the plain text with multiple wrapping keys and you should be able to decrypt the encrypted message by one region when you copy the same data to another region (as wrapping key (region 2) will be able to decrypt the envelope (encrypted by region 1).

    Do you think any issues in this approach? I can think of one like how do I know that how many wrapping keys I need in advance? Example: at initial stage, I can have 2 region so I will create two wrapping keys from Cloud HSM and start encrypting the plain text. Later on If I add another region, at that point, I will not have my plain text data encrypted with the wrapping key from that region. How can I handle this scenario if using ESDK?

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions