ESP32 Forum

OK, it's clear that with the ability to change code over the air, the potential risk of being hijacked raises enormously.
But, as long as no OTA code is uploaded and the device is not on USB, will i have to care for security as long as no physical access to the device is given?

By safety I think you mean "security". There is always the opportunity for a bug introduced by your code or subtly lurking within the ESP-IDF or hardware that could compromise your ESP32 but that would be true for all hardware and all applications. Someone with physical access to the device is likely to be able to compromise it. For example, if I could get electrical access to it then I could boot it into flash mode and serially push my own application. I don't know if there is a security feature in the ROM bootloader that would prevent re-flashing (a write once capability that would check the ESP32 efuses and, if set, would check the content of flash against a hash to see if it had been tampered with). I am assuming that you are worried about someone maliciously replacing what would appear to be a "product" containing an ESP32 with an identical product that contains unwanted logic.

Later ... found this excellent documentation on secure boot:

http://esp-idf.readthedocs.io/en/latest ... -boot.html

rin67630 wrote:OK, it's clear that with the ability to change code over the air, the potential risk of being hijacked raises enormously.
But, as long as no OTA code is uploaded and the device is not on USB, will i have to care for safety?

You can enable encryption in the bootloader. Any code that you flash will be encrypted, but you only get 3 flashes. After that any new code needs to be OTA. The bootloader will encrypt the code that OTA burns. The encryption key is generated by the ESP32 and unknown to everyone including you. But the method that you use to initiate an OTA could be hijacked, so you need to make sure that's secure.

If you don't have the device doing OTA then it's probably pretty secure. But who knows if there are any backdoors lurking around.

John A

fly135 wrote: If you don't have the device doing OTA then it's probably pretty secure. But who knows if there are any backdoors lurking around.

Yes that was my concern. The device contains the WLAN password unencrypted, can one imagine to retrieve it remotely?
I am only concerned by WLAN/LAN attacks , not by anyone having physical access to the device.

If the ESP32 contains the WiFi password then that will likely be stored in flash. If you discount physical access then there should be no need to encrypt it. If you don't encrypt it, then someone with physical access could dump flash and gain access.

Discounting physical access, then there had better not be an ability to access the clear text password remotely. If we turn the question around and say that there is a mechanism for accessing the clear text password stored in an ESP32 then we are all in deep deep trouble. Obviously, you will need some mechanism to supply the ESP32 with your local password and that would be a weak point if not done properly but once safely stored, it shouldn't be able to "leak out".