ESP32 Forum

Hi. I have still not found any downsides. Would love to hear official statement from Espressif why this method would not be the default one; I think it should be .

Hi, did you maybe try various data types in NVS, like longer strings or binary blobs? I would also like to hear from Espressif what they think about this.

I'm at the point where I need to decide the security features for my project before I finally lock the flash contents at which point I want all necessary partitions in place with correct setup. Not having to manage the NVS keys separately and using default flash encryption obviously seems like nice feature.

Hi, I'm the author of https://github.com/espressif/esp-idf/co ... f76a996491. Back in the day when I was working on NVS, we also thought about allowing NVS to use the generic flash encryption scheme. In the end, however, we figured that it would have required a bunch of changes that seemed too many and/or too risky to integrate into IDF. I don't remember all the details anymore, but I'll check this and then come back.

I do remember, however, that we also talked about the bootloader and about the bootloader encrypting an NVS partition on the device. A few general notes are:

• We're very, very conservative with updating the bootloader and adding new features to it. The reason is that it's a deeply involved in the bootup (obviously). Any changes, even small ones need to be very well tested in all situations down to the very last corner case. We have many customers with devices in the field that do over-the-air updates, that must not break in the field. Breaking these devices will upset customers, understandably.
• Another issue is that the bootloader can not be updated at the moment, producing further constraints with existing devices.
• Furthermore, changing the bootloader to recognize NVS partitions creates a dependency to NVS, while the bootloader should ideally be as agnostic as possible, e.g., to be flexible enough.
• Were also limited in size with the bootloader. Today, it's already likely you need to decrease logging verbosity or change partition tables when enabling secure boot and flash encryption. Any integration of additional NVS code would increase the size further.

A fact that should not be underestimated when doing any fundamental changes in NVS is that it is often used directly after startup to load important configuration values, which means we also want to make 120% sure that NVS works.

These are the main concerns I remember. As mentioned before, there might be others I have missed, but I'll check this. I hope this helps explaining why we sometimes don't integrate seemingly easy changes.

I just tested flash encryption with the mentioned changes, such as removing the line in nvs_partition_lookup.cpp and adding the encrypted flag to the NVS partition. I did this on a device that had worked unencrypted before and had already stored some data in the NVS partition. I recompiled the binaries and flashed the device with flash encryption enabled as described. During boot, I could verify how the bootloader, the partition table, the NVS partition, and the app partition got encrypted. Unfortunately, the previously saved data in the NVS partition could not be read.

When I afterwards store data with flash encryption enabled, everything works fine, and I can read from and write to the values inside the NVS partition. But I did not manage to write an existing partition to the flash and read its values which is often necessary for factory data, neither with nor with encryption enabled. This behavior indicates that it would not be possible to flash a (factory) partition on the device that gets encrypted during the first boot process and is readable for the NVS system. This is probably the downside of this procedure, or has anyone succeeded with this?

With the nvs_keys partition, it is possible to pre-encrypt a partition (e.g., factory partition), flash both the factory partition and nvs_keys partition to the device, and read from it.