1
$\begingroup$

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?

$\endgroup$
  • $\begingroup$ To get a good answer to your problem, you should provide all the specs, needs, and risks. For example, is there a TPM on your platform or similar to this? Why do you fear from user to download a malicious firmware? Do you fear that there is an attack on your servers? Do you fear the man in the middle attack? Did you consider the digital signature with a Trusted Authority chain? $\endgroup$ – kelalaka Feb 7 at 9:28
  • $\begingroup$ Assuming that you don't want to encrypt for each private key separately (what would be the benefit of that, if you only encrypt the firmware with it?) you'd have to distribute that same private key to each device. Is that still a private key? All parties would know the key after all... That private key might as well be called a secret key. $\endgroup$ – Maarten Bodewes Feb 7 at 9:33
  • $\begingroup$ @kelalaka No TPM. Device can be updated over Ethernet so theoretically from a remote hacker not blocked by the firewall at the customer's place, theoretically wanting to use our device as a trojan horse, so this includes man in the middle; I don't plan to used digital signature with Trusted Authority, I think a public-private key would be enough to authenticate the firmware. $\endgroup$ – BillyJoe Feb 7 at 9:59
  • $\begingroup$ @MaartenBodewes if I understand correctly what you are asking (I have little experience with cryptography and these concepts are a little hard for me), the private key on the device side regarding point 2 is saved in the "bootloader" firmware which is programmed only at the factory and cannot be read by anyone even having physical access to the device. $\endgroup$ – BillyJoe Feb 7 at 10:05
  • $\begingroup$ @kelalaka to complete, we want to protect also against reverse engineering of our firmware. $\endgroup$ – BillyJoe Feb 7 at 10:09
3
$\begingroup$

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.
| improve this answer | |
$\endgroup$
  • 1
    $\begingroup$ @mbjoe May I suggest that you do not accept the first answer right away, as this might discourage people from giving an alternate answer which might be better. $\endgroup$ – not2savvy Feb 8 at 8:12
1
$\begingroup$

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.

  1. 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.

| improve this answer | |
$\endgroup$
  • $\begingroup$ thank you for your answer. I don't have customer specific firmware. When programmed through Ethernet, firmware is written by a "bootloader" portion of the flash memory (programmed at the factory) that cannot be read even with direct physical access to the device, because the flash memory is protected from reading. The symmetric key for decryption is written there and thus it should be virtually impossible to leak it (unless using some sophisticated X-ray technique or something like that). $\endgroup$ – BillyJoe Feb 10 at 8:32
  • $\begingroup$ In this scenario, and provided you said that symmetric encryption is as secure as asymmetric encryption, do you think that signing the firmware with an asymmetric key in addition to symmetric encryption of the download data adds some value? Or is only a symmetric encryption enough? (If we consider my workplace enough safe for storing of the source bootloader firmware with the symmetric key inside). $\endgroup$ – BillyJoe Feb 10 at 8:32
  • $\begingroup$ A signature would add authenticity which could make sense: it would guarantee that the firmware has been provided by the signer. No one else could provide the firmware with this signature. $\endgroup$ – not2savvy Feb 10 at 8:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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