envelope encryption (using KMS) vs ECDH

Question

at work I have implemented basic envelope encryption when sending messages to a client. I am using AWS KMS and have a master key there. I get a data key, encrypt the message with AES-GCM and send the message with the encrypted data key, IV, tag etc. The client then calls AWS KMS to decrypt the data key to decrypt the message. I have implemented this looking at the AWS docs. I am caching the data key for a while for reuse before generating a new one.

One colleague, that is better at cryptography than me, thinks this is unsafe due to sending the key with the message, that this might lead to figuring out the master key? He recommends ECDH which has better key distribution, using a shared secret with private/public keys to generate the AES key. The problem with this I feel is that I need to store public/private key pair somewhere, and both of these methods needs access to a secret (KMS key or private key).

I am looking for other opinions on how secure these different methods are. What are the difference really in vulnerability?

Edit: Clarification: The master key is a specific key created only for encrypting data keys for these messages to one specific client, nothing else. Docs from AWS that I used: https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping

Answer 1

Mathematically, you are correct that if your data key is properly generated using a cryptographically secure pseudorandom number generator, the master key can’t be reversed from a message (assuming AES is unbroken.) But operationally speaking, this scheme provides a “crib” to an attacker trying to guess the master key. It enables a “known plaintext” attack.

Consider the case where an adversary believes he has part of your master key. He can use any intercepted message from this system as a test to see if his guesses are correct. Or he can unwind the algorithm, should such an attack against AES ever become known.

This scheme isn’t following the principle of “a key should be used for a single purpose.” Because the master key still lives in each message, each data key is now sharing your master key with all other keys.

That said, I’m not familiar enough with AWS’s KMS to know how your system is configured, but all the KMS systems I work with perform key management by granting permission to individual users to access only their application’s keys. No user would ever have access to use the system’s actual master key to directly encrypt a data key. So it’s possible that your description isn’t complete, and what you have been referring to as a master key could simply be referring to an application-specific key. In that case, the leak of your key won’t lead to the leak of the other keys in your KMS. Your organization’s other keys wouldn’t be compromised even if your key was.

Even in that case I’d still consider taking your colleague’s advice and changing to use an asymmetric key solution like the one he described for exchanging keys, instead of encrypting the data keys directly with the master key. You can still have the sender and recipient use the KMS to decrypt the private keys, because the private keys are never sent with the messages. It removes the known plaintext attack against the master key.