3

In Envelope encryption a symmetric secret key is used to sign the data and then another key is used to encrypt the secret to produce an encrypted secret key. The encrypted messages is packaged with the encrypted secret key and sent to the client/consumer which then decrypted the encrypted secret key to get the secret key, which in turn is used to decrypt the message

There are 2 ways to implement it:

  1. Asymmetric encryption: The producer encrypts the secret key(s) with the consumers public key. The consumer uses a private key to decrypted the encrypted secret
  2. KMS (such as AWS KMS): The secret key is encrypted by the KMS, and client that needs access to the secret key has to ask the KMS to decrypt it

The advantage of the KMS approach is that key management is centralized, and revoking permissions from a client can be done by removing the client from the KMS and rotating the key.

Are there any good reasons to use asymmetric keys instead of KMS?

1
  • Besides the fact that a KMS is a separate service to maintain, manage, and becomes a single point of failure in a distributed environment? Is your question an "encryption" question or a "logistics" question?
    – schroeder
    Aug 24, 2015 at 18:28

2 Answers 2

2

If the KMS holds the key then they can read the message. If the KMS is breached, then an attacker can read all messages associated with all keys that they stole. Asymmetric keys where the private key is only held by the recipient only allow the recipient to read the message so there's no worry about peeping KMS systems. If the private key is stolen, it is only for emails to that user that used that key, not everyone in the system.

3

It's all about where you store the secret and who has access to it.

First a clarification: You are confused. KMS does not use asymmetric encryption (also called Public-Key encryption). It uses private key encryption to enable envelope encryption. They are two different things.

In asymmetric encryption the producer of the encryption never has to access the secret, they just need the public key. The producer uses the public key to encrypt, the consumer uses the corresponding private key to decrypt. In order to facilitate key rotation the producer sometimes appends the public key that was used to encrypt so that the consumer knows what private key to use to decrypt. No matter how much data is encrypted there are no hints at the private key. The algorithm for decryption is usually more compute intensive than private key encryption.

In envelope encryption the producer and the consumer must be the same (or both have access to the master key). You use a master key to generate a secondary key called a data key. You then encrypt the data key using the master key and the data itself using the data key, then you append the encrypted data key to the encrypted data. When you decrypt you use the master key to decrypt the appended data key, then use the decrypted data key to decrypt the data.

The advantage of this is that you can cost effectively store your master key in purpose-built Hardware Security Module and never expose it to anything else without having to pass all the data you encrypt into the HSM. You can even generate the key inside the HSM and not take it out so that there's no chance that it has ever been exposed to anything externally. KMS provides you with a cloud based HSM and it's backed by physical HSMs at Amazon.

If you don't care about keeping your master key in an HSM, then you can do the same kind of encryption using your own key that you try to keep safe by putting in on a jump server or something like that. Also as long as you aren't encrypting more than 250 million TB you can skip the envelope.

If you're looking for some example code you can snatch up to implement either simple AES encryption or envelope encryption you might want to check our open-source project. It's got an implementation for each you can leverage...

https://github.com/kunai-consulting/KeyStor

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .