3
$\begingroup$

In my current project we will have to encrypt a lot of S3 objects (a few billions) with AWS KMS.

Our security department requires that we use KMS keys backed by CloudHSM. But since CloudHSM incurs some non-negligible extra charges in terms of pricing and key management (key rotation particularly), I was wondering if it was really better in terms of cryptographic security. So I started to learn more about how KMS works under the hood using AWS KMS cryptographic details, as well as these AWS papers :

I learned that KMS uses AES-GCM with randomly generated IVs and that in this case the NIST recommends avoiding more than 2^32 encryptions with the same key in order to keep the risk of (key, IV) collision under 2^-32.
Such a collision may lead to a loss of authentication guarantees for all ciphertexts encrypted under that key and can expose plaintexts encrypted under the repeated (key, IV) pair.
That was not conceivable for AWS considering that some customers may encrypt much more under a single key and also considering that they need to limit the risk across all their customers. So they decided to introduce a key derivation mechanism in order to raise the limit to 2^64 encryptions for each customer. For the record this number comes from Shay Gueron's explanation of their workaround that you can watch here.

On the other side, the specification of the HSMs that we use within the CloudHSM service is documented here.
In "Table 4 – FIPS Approved Algorithms Used in the Module", we can see that their implementation of AES-GCM uses 96 bits random IVs, just like AWS KMS. However there is no mention of a KDF mecanism similar to AWS KMS so we can assume that the 2^32 NIST recommendation applies.

To come back to our requirements, we will need to encrypt ~4 billions objects within a relatively short period of time which makes it impractical to rotate the key (CloudHSM keys rotation aren't as smooth as KMS ones, even using aliases). Also, we can't use the S3 bucket key option for security reasons so each object will require a new encryption directly under our CloudHSM backed KMS key.

My question is, in that case, aside from compliance reasons, would using native KMS rather than KMS with CloudHSM be preferable ? And to go further, in your opinion, should our requirements make CloudHSM a no go ? I'd like to have more information in order for me to balance between the two options and eventually be able to come to our security department with well-founded assertions.

$\endgroup$

1 Answer 1

0
$\begingroup$

Here is my opinion, I believe you should use AWS KMS. It has it's native HSM should be sufficient for most cases. Although I will say that CloudHSM has dedicated instances for better and more control. For that much data CloudHSM does not provide that much more of a benefit unless you have very specific uses as CloudHSM is also more expensive.

$\endgroup$
2
  • $\begingroup$ Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. $\endgroup$
    – Community
    Dec 31, 2023 at 23:25
  • $\begingroup$ Hi! Thanks for taking the time to answer but it is too vague for me to accept it. I'd like to have more information in order for me to balance between the two options and eventually be able to come to our security department with well-founded assertions. $\endgroup$
    – Florian
    Jan 2 at 14:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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