Protection on the flash read

[chriselef]

Chris wrote:

I have a problem understanding on how to protect the firmware read from flash through the serial port
and the jtag..
What efuses should I burn ? is that operation reversible ?

thanks
Chris

ESP_Angus wrote:

You can't protect the flash from physical readout completely, because it's external to the chip in most cases. Even if the ESP32 disables readout we can't prevent the attacker from just connecting SPI probes to the flash chip (or the embedded flash pins for ESP32-D2 & ESP32-D4).

However you can protect the flash from unauthorised decryption, and disable JTAG, and this keeps the flash contents secure from an attacker with physical access.

There are two efuses DISABLE_DL_DECRYPT & DISABLE_DL_CACHE which disable decryption and flash cache (which can also decrypt) when the serial bootloader mode is running. These are burned by default on first boot when flash encryption is enabled, but you can also burn them manually.
The efuse JTAG_DISABLE will disable the JTAG peripheral. Also burned by default on first boot when either flash encryption or secure boot is enabled.
Enabling secure boot & flash encryption will mean the chip only boots authenticated firmware, and the contents of the flash becomes encrypted (and only readable by software running from the aforementioned authenticated firmware).


You can use the espefuse tool to view the state of each efuse and burn efuses manually, but if you use the default flash encryption & secure boot settings then they will be burned on first boot automatically.

(Moderator's note: This post is content from PM, has been reformatted to be easier to follow)

[bonmotwang]

Does that mean the read back protection is enable automatically?
I am using the ESP_PROG to program and test my software using UART0.

What is the should I put after "idf.py"?
And is it possible to "brick" the ESP32?

All I want is simply stop people from copying my software.

Thanks

[ESP_Sprite]

Read up on flash encryption then. And yes, as it involves key material and configuration being irreversibly burned into the ESP32s efuses, it is possible to brick an ESP32 if you do not do the steps in the right order and/or ignore warnings. Follow the document and you should be fine.

[bonmotwang]

Thanks. I was reading that article, but it seems like I have to use OTA to download the firmware.
So far my product isn't using WiFi or BLE. In production they only plan to use UART0 to download the software.

I will read the article again.

Another question, how to verify that my firmware is protected?

Thanks

[bonmotwang]

In that article.
What does this mean?
"Enabling flash encryption limits the options for further updates of the ESP32".
So I cannot update firmware anymore after the encryption??

[ESP_Sprite]

You can use any update mechanism you want as the update mechanism for encrypted programs is in the program itself. If you want to update using UART, you can modify your program to do this.

Enabling flash encryption does indeed limit updating options, as we need to make sure that there is no way to get non-authenticated code to run on the processor. If non-authenticated code can run on the processor, it can just read out the flash through the flash encryption layer and allow someone to get an unencrypted image. So things like the ROM UART0 upload feature can't be allowed to work 'through' the encryption.

You can check if your firmware is protected by reading out the flash chip using e.g. a flash reader and see if it looks like white noise instead of your binary.

[axellin]

You can use any update mechanism you want as the update mechanism for encrypted programs is in the program itself. If you want to update using UART, you can modify your program to do this.

I'm confused.
If I enable flash encryption, can I upload an "encrypted firmware" via OTA?
I might be wrong, I thought the encryption process is done by the device when writing to the flash so it need to upload non-encrypted firmware.

[ESP_Sprite]

If you use OTA, you would generally upload unencrypted firmware, as the encryption key ideally should be per-device and unknowable to anything but the flash encryption hardware. There is nothing stopping you from building (transport-level) encryption into an UART protocol, though.

[bonmotwang]

Thank you for the deep explanation.

The software development is finished, We are about into production now.

Just want a way to protect the product from copied.

I thought it is just like "turn on the read back protect" as I have done on other MPU's.

Understand this is the Flash outside of the CPU.
Seems to be too complicated. LOL

Can I just follow the Development mode.
Step 1) Enable those eFuse settings.
Step 2) idf.py flash monitor
And for firmware update just use
idf.py encrypted-app-flash monitor

Thanks

[bonmotwang]

After reading more about the encryption.
Development Mode should work for me.
(Forgot to mention that I am using ESP32-WROVER module)

This is why I think it works for me:

AES key is stored in the CPU, it is different on every ESP32-WROVER.

My application is stored in the external SPI flash, encrypted by the AES. Every ESP32-WROVER will have different image because different AES keys.

That image will only work with the "paired" CPU.
Anyone copied an image out of the external flash wouldn't do him any good because won't be able to use it on other ESP32 CPU.

Not sure if I got it right.
Please comment.
Much Much appreciated.

Thanks