Disadvantage of using Amazon KMS to encrypt / decrypt small application data

2
votes

A pair of Amazon Lambdas will symmetrically encrypt and decrypt a small piece of application data. I want to use Amazon KMS to facilitate this, because it solves the problems of secret storage and key rotation, and then some.

The Amazon KMS Developer Guide indicates:

These operations are designed to encrypt and decrypt data keys. They use an AWS KMS customer master key (CMK) in the encryption operations and they cannot accept more than 4 KB (4096 bytes) of data. Although you might use them to encrypt small amounts of data, such as a password or RSA key, they are not designed to encrypt application data.

It goes on to recommend using AWS Encryption SDK or the Amazon S3 encryption client for encrypting application data.

While the listed advantages of the AWS Encryption SDK are clear as day, and very attractive, especially to a developer who is not a cryptographer, let's assume for the purpose of this question that circumstances are not favorable to those alternatives.

If my application data is sure never to exceed 4k, why specifically shouldn't I simply use Amazon KMS to encrypt and decrypt this data?

Use case

My team is implementing a new authentication layer to be used across the services and APIs at our company. We're implementing a JWT specification, but whereas we intend to steer clear of the widely documented cryptographic grievances beleaguering JWE / JWS compliant token signing, we're symmetrically encrypting the payload. Thus, we keep the advantage of standard library implementations of non-cryptographic token validation operations (expiry and the rest,) and we leave behind the cryptographic "foot-gun."

2
encryptionaws-lambdaencryption-symmetricaws-kmsamazon-kms
FYI I posted this question here, and not under crypto, because I'm not aware that the question or the answer are rooted in a cryptographic detail, or if they have some other more architectural bearing. – Daniel B.
It's still not a good question for SO. SO is for programming questions. It's probably a good question for the aws stackexchange, but there is no such thing, so I don't really have any advice I'm sorry to say. I won't vote to close it, maybe you'll get a great answer. – President James K. Polk

2 Answers

4
votes

I suspect it's about performance: scaling and and latency.

KMS encrypt/decrypt has a limit of 5500 reqs/s per account, which is shared with some other KMS operations.

"Why?" Is also discussed a bit more thoroughly in the FAQ.

Why use envelope encryption? Why not just send data to AWS KMS to encrypt directly?

While AWS KMS does support sending data less than 4 KB to be encrypted, envelope encryption can offer significant performance benefits. When you encrypt data directly with KMS it must be transferred over the network. Envelope encryption reduces the network load for your application or AWS cloud service. Only the request and fulfillment of the data key through KMS must go over the network. Since the data key is always stored in encrypted form, it is easy and safe to distribute that key where you need it to go without worrying about it being exposed. Encrypted data keys are sent to AWS KMS and decrypted under master keys to ultimately allow you to decrypt your data. The data key is available directly in your application without having to send the entire block of data to AWS KMS and suffer network latency.

https://aws.amazon.com/kms/faqs/

1
votes

I am going through this issue with AWS support right now. There is the throttling limit mentioned in the accepted answer. Also, if you reuse and cache data keys as allowed by the SDK, you can save money at the expense of lowered security (one data key can decrypt multiple objects).

However, if neither of those are relevant to you, direct CMK encryption is appealing. The security is excellent because the data key cannot be leaked, every decryption requires a API call to KMS and can be audited. In the KMS Best Practices whitepaper, it states that encryption of credit card numbers in this way is PCI compliant.