High volume encryption: AWS KMS vs CloudHSM
In my current project we will have to encrypt a lot of S3 objects (a few billions) with KMS.
Our security department requires that we use KMS keys backed by CloudHSM. But since CloudHSM incurs some non negligeable 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 AWS KMS works under the hood using AWS KMS cryptographic details, as well as this and that 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 mecanism 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 requirement 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 ?
