0
$\begingroup$

I have some embedded device for which I want to sign and encrypt firmware files. Firmware updates are generated by me and may be installed by the customer. The encryption is supposed to protect the intellectual property contained in the firmware and the signature prevents unauthorized modifications.

For the signature there are tons of resources, but I’m having problems with the encryption part. The simplest solution would be a shared symmetric encryption key. In case the encryption key gets extracted from the device one could not only decrypt the firmware, but also create your own encrypted firmware (without a valid signature). Are there a better alternatives using asymmetric encryption, so that less information is available when the device keys are extracted?

|improve this question
$\endgroup$
  • $\begingroup$ Do the devices have unique numbers that you can use in the protocol? $\endgroup$ – kelalaka Oct 14 '19 at 12:56
  • $\begingroup$ No, all devices are the same and share the same cryptographic keys. Also, it’s not an online protocol. Updates may be installed offline using a USB drive or similar. $\endgroup$ – sebi707 Oct 14 '19 at 13:04
  • $\begingroup$ How many devices are there? Is distributing an individually (per device) encrypted installation package an option? $\endgroup$ – mat Oct 14 '19 at 13:06
  • $\begingroup$ Consider sharing technical ideas with users instead of keeping them secret, and allowing users to modify their own devices? $\endgroup$ – Squeamish Ossifrage Oct 14 '19 at 19:15
0
$\begingroup$

No, asymmetric encryption or other known purely cryptographic techniques do not solve the problem stated in the question. When device keys are extracted, any (future, see below) firmware update for that device can be deciphered.

The best we can do in this direction without some trusted hardware:

  • After deciphering and installing a certain version of a firmware, the device can forget the key used to decipher it, and use a new key (e.g. embedded in the firmware just downloaded, or derived from the earlier key with a ratchet mechanism). This limits exposure of past firmware, with the side effect that firmware downgrade is not possible. Things can be arranged so that some firmware upgrades can be skipped.
  • We can use security by obscurity, including white box crypto, which aims at making key extraction impossible (in other words making simulation of the actual decryption the best way to decipher). That theoretically fails, but practicaly succeeds to some degree.
  • Deciphering keys can be device-unique, but then the encrypted/signed firmware is also device-unique.
  • By making the encryption process dynamic (which makes sense if the update process is online), the key protecting the firmware's confidentiality can be an ephemeral session key, so that extracting the device's long-term key is not enough to decipher the firmware from a line intercept. However such extraction is theoretically enough to impersonate the device, connect to the update server, and get the firmware enciphered under a known session key, thus this is security by obscurity.

Update: the last two points do not apply given new comment to the question that all devices are the same and share the same cryptographic keys. Also, it’s not an online protocol.

Update per comment to this answer: indeed, signature works to prevent the creation of valid firmware that installs on genuine devices. That's a strong mechanism, resisting extraction (but not replacement) of device keys, provided no exploitable bug in any firmware allows to take full control of the device and circumvent that signature mechanism. Firmware signature is Independent of firmware encryption, which the rest of this answer is about.

|improve this answer
$\endgroup$
  • $\begingroup$ I realize that you cannot protect the firmware from being decrypted when you have access to the device keys. However, it should not be possible to generate valid firmware files from this information. Since this is already guaranteed by the signature (the device has only the public key) is it fine to just use a shared symmetric key for the encryption part? $\endgroup$ – sebi707 Oct 14 '19 at 13:21

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.