2

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

  • I would not add the risk and complexity of a key agreement, especially not if this is not an interactive two way session establishment (use TLS otherwise). You would need a static DH key on one site which reduces the usefulness. Besides you would have to solve the MITM problem as well. You might need to rotate your CMKs more often to be safe. – eckes Nov 18 '18 at 21:08
  • @eckes So you think envelope encryption should be enough if I'm interpreting your answer correctly? We actually use TLS over this as well – KTrum Nov 19 '18 at 21:45
  • Always hard to give advice without knowing the whole picture, but AES Block cipher is designed to encrypt data without leaking the key. Especially if the cipher mode is used correctly. So I don’t see a weakness in this area. You might gain advantages from a PFS scheme, but that’s not a trivial protocol for disconnected operations. Besides a purely symmetric scheme is post quantum resilient which (EC)DHE is not. – eckes Nov 19 '18 at 21:52
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.

  • Good answer! Regarding aws KMS, it's not possible to extract the plaintext master key from the KMS, even if you have user access to it. I created a specifik masterkey for this client also, so not used for anything else. Regarding guessing the key, wouldn't this be possible always, even ECDH if you guess the shared secret and one private key you can decrypt any message. – KTrum Nov 18 '18 at 14:18

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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