Is OTA Update of encrypted application possible?

[HighVoltage]

I have implemented OTA update in my application similar to this example:

https://randomnerdtutorials.com/esp32-o ... ogramming/

That works fine. My application has both secure boot V2 and flash encryption with manually generated key. When I am in development mode for flash encryption, I can still do the OTA update: it accepts the unencrypted bin and it installs. That makes sense, it can do the encryption itself.

Then I turned on "release mode" for flash encryption via my application calling esp_flash_encryption_set_release_mode(). Now I can't get the OTA update to work anymore. I just get "Wrong magic byte" messages.

I am uploading versions of the same .bin application I previously used in development mode that I was able to upload successfully, but I made encrypted versions myself with "espsecure.py encrypt_flash_data". Shouldn't this work? What does the "Wrong magic byte" message mean?

[ESP_Mahavir]

I am uploading versions of the same .bin application I previously used in development mode that I was able to upload successfully, but I made encrypted versions myself with "espsecure.py encrypt_flash_data". Shouldn't this work? What does the "Wrong magic byte" message mean?

Encryption of the application happens on the device with flash encryption enabled case and it is true for both development as well as release mode. Hence, during OTA updates, you must host plaintext (and signed if secure boot is enabled) image on the server.

This topic was discussed in https://github.com/espressif/esp-idf/issues/6172

If you would like to ensure that application hosted on server stays encrypted then please see example for that at: https://github.com/espressif/esp-idf/tr ... rypted_ota

[HighVoltage]

Encryption of the application happens on the device with flash encryption enabled case and it is true for both development as well as release mode.

Isn't that a gap in security: what is the point of flash encryption if passing around plain text application for updates?

I am using manually-created encryption key. I would like to distribute updates securely. What scenario can support this? Ideally via OTA. Or can only UART download support this? Is the best I can do is set development mode for flash encryption and disable download flash encryption, so end user can only UART download encrypted application? IE. a manually set up hybrid mode between the "Development Mode" and "Release Mode"?

The reference you cite says:

Pre-encrypted firmware binary must be hosted on OTA update server. This firmware will be fetched and then decrypted on device before being flashed.

Why should it be decrypted before flashing? The whole point is to keep it encrypted the whole way to the flash. I'm using manually-created key so there's no reason to be doing on-board encryption.

[ESP_Mahavir]

Hello,

Isn't that a gap in security: what is the point of flash encryption if passing around plain text application for updates?

Primary purpose of flash encryption feature is to ensure that application stays encrypted when stored in an external storage medium (flash). This ensures confidentiality of the firmware from someone with physical access to the device.

Regarding OTA updates, we recommend using HTTPS as the transport during OTA updates. Please see a detailed technical writeup on this topic at: https://blog.espressif.com/ota-updates- ... 5438e30c12

I am using manually-created encryption key. I would like to distribute updates securely.

Pre-encrypted OTA scheme should help here. This scheme ensures that application stays encrypted when hosted on the upgrade server as well as on the OTA transport.

Why should it be decrypted before flashing? The whole point is to keep it encrypted the whole way to the flash. I'm using manually-created key so there's no reason to be doing on-board encryption.

Pre-encrypted OTA is entirely different scheme than flash encryption and it only ensures that application stays encrypted over OTA transport. It can help in the scenario where OTA transport is non-secure, e.g. plain HTTP. Application is first decrypted on the device and then re-encrypted with flash enc scheme (if its enabled) before writing to the flash.

Please see earlier discussion on this topic and specifically comment here: https://github.com/espressif/esp-idf/is ... -884777914.

[HighVoltage]

Pre-encrypted OTA is entirely different scheme than flash encryption

I find that an odd explanation. Encryption is encryption: why should it be linked to the transport mechanism?

I did not want to use multiple encryption workflows depending how I program the module. Nor do I want to have plain texts versions of my firmware online, regardless if it's behind a web server.

The main difference between local serial flash and OTA flash is two partitions and different address. I have worked around this by distributing both versions and upload flow tells the user which one is required. I now use the same encrypted bin for OTA updates that I also use locally.

[devlat]

Can you please describe in more details your OTA procedure?
I agree with you that Espressif pre-encrypted method is overkill if you already have generated own flash encryption keys.
3072-key is absolutely not needed and you should store your BIN on server already encrypted with same flash key.
And when you download it via WiFi it should be written to flash as is, without decryption and re-encryption (obviously after some integrity and signature checks).

[MicroController]

And when you download it via WiFi it should be written to flash as is, without decryption and re-encryption

Except that is not possible when the flash encryption key is only known to the device itself. Which provides better security than having the key stored on some server or development PC...

[devlat]

We are talking about the case when we use manually generated keys, so we DO know the device key. And we can maintain database of all device keys during production and encrypt firmware on the server exactly for this device only.
>Which provides better security than having the key stored on some server or development PC
In which way it provides better security if you still need some 3072 key on your server or somewhere before you prepare image for OTA transmission? If this PC or server is compromised then anyone can make fake OTA image for your device and it will "happily" re-encrypt it and write to flash. So no - it is not more secure.

[HighVoltage]

Can you please describe in more details your OTA procedure?
I agree with you that Espressif pre-encrypted method is overkill if you already have generated own flash encryption keys.

You can duplicate the OTA procedure and switch to use esp_partition_write_raw to write the encrypted data.