Page 2 of 3

Re: Encrypted OTA firmware

Posted: Fri Nov 09, 2018 4:07 pm
by fly135
ESP_Angus wrote:
Mon Oct 01, 2018 11:22 pm
I believe the idea was to make it difficult to ship devices which use an insecure protocol for their OTA updates. Is HTTPS really that hard these days?
Also, supporting HTTPS is easy. No different than HTTP on the ESP32 side. It's the certificate that's extra work.

John A

Re: Encrypted OTA firmware

Posted: Tue Jan 08, 2019 1:37 pm
by brp80000
My device has factory partition and two OTA partitions.
Factory partition will be flash in the production of the PCB. Access to serial downloading will only be in production, then the PCB will be filled with a compound. The devices are then updated via OTA via TCP protocol from my server. I don't trust HTTPS its easy to crack.
I use esp-idf-v3.1.2 ...
How can I transfer already encrypted data through OTA?

Re: Encrypted OTA firmware

Posted: Thu Jan 10, 2019 8:51 am
by brp80000
ESP_Angus wrote:
Mon Oct 01, 2018 7:53 am
Hi zelea20,
Thanks for explaining your process so clearly. We'll add official support for pre-encrypted OTA updates in a future IDF update.
Was this added to the new IDF?
Can i use for it?
  • esp_ota_write

Re: Encrypted OTA firmware

Posted: Thu Jan 17, 2019 12:49 pm
by brp80000
Tell me the first time you compile the APP WITHOUT enabling flash encryption on boot. Then Encrypt the binary files and flash it.
Then you burn fuse FLASH_CRYPT_CNT
I do not understand when encrypted boot and partition table?

Re: Encrypted OTA firmware

Posted: Sat Jan 26, 2019 10:46 pm
by matiasalejandro
Hi, coul you please send your esp_ota_ops.c
because I can not patch it with mine
Thanks.

Re: Encrypted OTA firmware

Posted: Tue Jan 29, 2019 1:39 am
by brp80000
Comrades from support, see what an important topic this is, add this feature to IDF. As you promised.
Sorry, my file won't work for you. Because I don't use https or http. I settled on the tcp. If you still want to see my file, send me your email in a private message.

Re: Encrypted OTA firmware

Posted: Wed Jan 30, 2019 1:33 pm
by matiasalejandro
I, I cant send still private mesasge, my mail is matiasaleruizm@gmail.com Thanks.

Re: Encrypted OTA firmware

Posted: Wed Oct 09, 2019 5:48 pm
by kuhatovuk
ESP_Angus wrote:
Mon Oct 01, 2018 7:53 am
We'll add official support for pre-encrypted OTA updates in a future IDF update.
Hello ! Is "support for pre-encrypted OTA updates" now available somewhere ? Thank you

Re: Encrypted OTA firmware

Posted: Wed Oct 09, 2019 7:29 pm
by kuhatovuk
Or should I add a layer and encrypt/sign the firmware myself through another mean ? Then verify/decrypt it before using OTA functions.

This way I keep unique key for secure boot, unique key for flash encryption and only a shared key for the published encrypted firmware.

If yes, would you recommend a signing and encryption method already in esp-idf ? I noticed multiple and don't know which one to pick. aes-cbc and ecdsa ? Thank you.

Re: Encrypted OTA firmware

Posted: Thu Oct 10, 2019 12:28 am
by ESP_Angus
Hi kuhatovuk,

No, I'm afraid we still haven't implemented such a scheme yet.

Regarding encryption & authentication, if secure boot is enabled then you don't necessarily need authentication as the signature verification will cover this.

Something like AES-CBC should be suitable. Use a randomly generated IV and store it somehow (in a separate file or as a header) and have the device download the encrypted image and decrypt using a key stored in the existing firmware.

Note that if already using HTTPS then an equivalent scheme is to hide the firmware update behind a long randomly generated directory name, provided the firmware never logs the request URL and the server is configured to disable directory listings. (An attacker who can access an existing firmware will be able to find out this directory name, but they would also be able to find out the stored key for a pre-encrypted image.)

The other option is to configure the HTTPS server to verify each specific device somehow before serving the firmware. This has the advantage that if an attacker recovers a key for one device, it can't be reused on other devices - and you can blacklist a compromised device. This is more difficult to implement on the server side, though - the other schemes can be done with any generic HTTPS static fileserver.