flash encryption (pre-generated key) procedure flow

[ESP_Angus]

I think that first option is probably the most straightforward: when the device contact the server it will pass its current running partition number and server will provide the corresponding bin file.

Yes, this is probably the best solution for what you are trying to do now.

What is the purpose of the "address" parameter in "espsecure.py" command? I have looked the python code and it seems that the address is needed for some tweaking...

The reason the key is "tweaked" based on each flash address is to avoid chosen ciphertext attacks. For example, if an attacker can determine that the contents of flash at offset X decrypt to some particular sequence of bytes, they could copy that ciphertext to some other address Y and know it would decrypt to the same value when moved there.

The matter seems to be become a little complex: we will see internally how and if going forward with this, unless there is a another solution at "esp-idf" level...

We recognise that a lot of people want this kind of option to protect their OTA updates from interception/readout. We are planning to release a separate "encrypted OTA" scheme where a different key (stored in encrypted flash) is used to encrypt OTA images on the host and decrypt them when they are flashed (at which point they are re-encrypted using the flash encryption scheme). This "encrypted OTA" would be totally independent to the flash encryption key and scheme. However I'm afraid there is no ETA for this feature yet.

[davdav]

Hello @ESP_Angus,

Thank for informations and explanation. Just a question:

Let's imagine application is running on ota_0 partition and it should be upgraded to ota_1 partition.
What if (for any reason), the upgrade pre-encrypted "ota_0" bin file is written on "ota_1" partition?
When the device is restarted and bootloader attempts to launch ota_1, is it able to fallback to "ota_0" (because for sure it will not able to decode) or device will continuosly boot loop?

You could tell me to try and see what happen; unfortunately it will take "some" work to do before arrive at this test and if there is a brief answer I can choose if going forward with this solution.

Thanks!

[ESP_Angus]

When the device is restarted and bootloader attempts to launch ota_1, is it able to fallback to "ota_0" (because for sure it will not able to decode) or device will continuosly boot loop?

The bootloader will try to verify the app before it boots it. If verification fails, it will try to fall back to a valid partition.

Also, if you call esp_ota_set_boot_partition() to change the selected boot partition, it will return the error value ESP_ERR_OTA_VALIDATE_FAILED if you try to set a boot partition which doesn't hold a valid app at that time.

[davdav]

Thanks @ESP_Angus for confirmation.

I will go through the proposed solution.

Thank you.