Advantages of encrypting a symmetric key with a public key vs using a fixed symmetric key

Question

I am new to cryptography concepts.

I am trying to protect some firmware download.

Reading some Wikipedia pages, I understand that asymmetric cryptography is time consuming, so, if I want to protect my download not only for authentication (I think I understood what to do for that), but also for sniffing, I need to crypt the download with a symmetric key.

This symmetric key can be either:

1. fixed and known by both parties;
2. or it can be crypted by the source with a public key and decrypted by the destination with the corresponding private key.

What is the real advantage of option 2?

If somebody has the firmware package (or reads it while it is downloading), a lot of machinery and time, he should be able to decrypt the message anyway, because it was crypted with a symmetric key. The only advantage I see is that once he has decrypted firmware package version 1, if the symmetric key changes in a newly released firmware package version 2 some months later, all the job must be repeated. So what I think is that option 2 is really useful only if sent messages are frequent, so decrypting one message won't help for the subsequent ones.

Am I right? Are there other advantages?

Answer 1

What is the real advantage of option 2 (asymmetric encryption of firmware)?

As correctly pointed by the question, not much. All I can think of:

• It allows to change the symmetric key at each firmware release (actually, the firmware will be encrypted with a random symmetric key, sent asymmetrically encrypted in a header). This advantage is mitigated by the fact that the asymmetric private decryption key can hardly be changed at each release, and must be secret.
• The developer/party encrypting the code needs no secret for that. This advantage is mitigated by the fact that the developer/party signing the code needs a private key, which must be secret.

Answer 2

From how I understand your question, I believe that you might have a few misconceptions about symmetric and asymmetric encryption. Let me try to clear things a little for you.

What is the real advantage of option 2?

Asymmetric encryption can be used in two ways:

1. Provider encrypts with the public key of the consumer

This is the scenario you are speaking of. This approach is used to make sure that only one consumer can decrypt the payload. This is very commonly used in email encryption where only the recipient should be able to read the message.

In your environment, this could be used to provide a customer specific firmware that only one customer should be able to use.

2. Provider encrypts with his own private key

In this scenario, any consumer could decrypt using the provider's public key. This approach could be used to make sure that only the provider could have encrypted the payload. However, to verify the origin of a payload, signing is commonly used. However, it uses the same principle: something only the provider can do with his private key, but can be verified by anyone using the provider's public key.

So, to answer your question about the real advantage of option 2, it does not seem to make sense in the scenario you describe, unless you want to provide customer specific firmware.

If somebody has the firmware package (or reads it while it is downloading), a lot of machinery and time, he should be able to decrypt the message anyway, because it was crypted with a symmetric key.

This sentence makes me think that you assume symmetric encryption is generally less secure than asymmetric encryption, and that, with enough resources, symmetric encryption can be broken but asymmetric encryption can't.

That is, in fact, not the case.

However, the one thing that makes asymmetric encryption preferable over symmetric encryption is key exchange problem. For symmetric encryption, it is necessary to somehow transfer the key to the consumer. This is problem part because the key might be leaked, and even worse, neither provider nor consumer might even notice it.

Interestingly enough, the common approach to this is in fact hybrid encryption. Asymmetric encryption is much more expensive and slower than symmetric encryption, but it has no key exchange problem. So we just use the best of both worlds:

First, we encrypt the payload using a symmetric key. Now to solve the key exchange problem, we asymmetrically encrypt the symmetric encryption key using the provider's private (asymmetric) key! The (asymmetrically) encrypted key is then usually attached to the (symmetrically) encrypted payload.

The consumer (and only this one consumer) can then decrypt the encryption key using his own private key and use it to decrypt the payload.