Okay, thank you for the explanation. I guess apps should just be robust enough to anticipate tampering/erasing of NVS data. I will consider this for the future.

Is it possible to just disable the UART interface to the chip so that physical tampering is impossible?

jcsbanks wrote: ↑

Tue Aug 20, 2019 6:54 pm

You could encrypt it.

That's true, but there is still the possibility that an attacker can modify/corrupt the data, right?

Hello,

Is there a way to prevent unauthorized modification of data in the NVS partition (for example, via esptool write_flash)?

Thanks.

I am also having this issue.

Hello, I am trying to figure out how to classify popular IoT devices, including the ESP32. One of these classifications is MCU vs. MPU vs SoC, etc. It seems each of these terms refers to a completely different kind of device, e.g., MCUs are low-power ICs with a CPU, some memory, and some peripheral ...

Hello, I want to implement a modified flash encryption feature onto my ESP32 that uses a user-supplied 256-bit key to encrypt and decrypt flash contents, rather than eFuse Block 1. The reason for this is that I want to be able to test flash encryption functionality without making any permanent chang...

Hello, I am trying to configure the ESP32 with ATECC608. My goal is to connect to AWS over a TLS connection. However, I would like to utilize the HW acceleration/security features of the ECC608 during the TLS handshake (specifically, the ECDSA signature verification). It would be preferable to use e...

This makes complete sense. Thank you!

Hi all, This may seem like a trivial matter to most of you. For some reason, I'm just having trouble wrapping my head around it. My question is this: what is the inherent security advantage to placing a limit on (plaintext) serial updates once flash encryption is enabled? It seems to me that with fl...