ESP32 Forum

Good morning everyone.

I'm building a commercial ESP32-based product that is physically exposed — it's installed in a street-facing box, so an attacker can reach the USB/serial pins. This creates a specific pair of needs that, as far as I can tell, no current configuration satisfies together.

What I need

1. A third party must never be able to read the stored Wi-Fi credentials, whether by esptool read_flash over serial/native USB, or by clipping onto / desoldering the flash chip and reading it externally.

2. Anyone should be able to re-flash the device in the field with their own firmware, without needing any key from me — because I want the product to be freely customizable.


At first glance these look contradictory, but I think there's a clean model that resolves them.

The proposed model

Two pieces working together:

1. Encryption key in an eFuse, inside the ESP32 — never in flash. The key is unreadable by software and, crucially, it does not live on the external flash chip. So desoldering the flash and reading it externally yields only ciphertext; the key simply isn't there to find. This part already exists in Flash Encryption and is exactly what I want.

2. A command-discriminating gatekeeper in the boot path that:

2.1 Refuses all read operations, unconditionally. There is no way to read flash contents back out over the serial/USB interface.
2.2 Allows writes with no key required — but only after a mandatory full erase of the NVS/credential region. Re-flashing is always permitted, but the act of re-flashing wipes the stored credentials first, before the new firmware is accepted.


The result: a stolen/exposed device gives up nothing. An attacker can re-flash it freely (keyless), but the erase-first guarantees the previous owner's credentials are gone before any new code runs. And direct reads are refused outright, while pin/desolder reads only ever see encrypted data because the key is in the eFuse.


Why current modes don't cover this

Flash Encryption Development mode: re-flashing is keyless ✓, but read_flash over serial returns plaintext ✗ — so credentials are exposed on the exact interface an attacker reaches.
Flash Encryption Release mode: reads are blocked ✓, but re-flashing over serial requires a pre-encrypted image using the per-device key ✗ — so keyless field re-flashing is impossible.


Neither mode offers the combination I need: keyless re-flash (with forced erase) AND reads fully disabled.

My questions

a. Is there any existing eFuse / secure-download-mode combination that achieves this behavior that I've missed?
b. If not, is a "wipe-on-write, deny-on-read" download mode something that could be considered? It seems like it would serve any exposed/tamper-accessible product that wants to remain user-customizable without leaking prior secrets.

Thanks in advance.

Can you tell us a bit more on what you want to use this for? I'm having a very hard time imagining a scenario where this would make sense.

Hello @Sprite.

There will be times that the product can be on the outside or really close to the street on someone's property. Think of an electrical meter box or water meter box, for example. Here in Portugal it is very common to find meters like this on the outside where someone can access it. This being said, from the stand point of security, I have to make sure that after the product is configured and connected to the WIFI of the customers, no attacker can access the product to get theirs WIFI's credentials. With current ESP configurations I can prevent this with Flash Encryption and Boot Secure but these two strategies do not work with my following requirement.

I am thinking a big buy will be techy/enthusiast people that would want to "open" the product by flashing a custom firmware without I need to have to provide any key (Flash encryption and Boot secure demand keys for new flashing or firmware signatures). Think about all the Tuya products that everyone wants to flash with ESPHome or Tasmota and it keeps getting more difficult. So my product needs to be "an open product for new flashing, easy as it can."

Combining this two requirements, as far as I investigated there is no solution for ESP32.

STM32 from ST Microelectronics seems to have RDP (Readout Protection) with three levels, being the RDP level 1 the one that works this way: no readouts and a new flash deletes all previous flash meaning that if an attacker is able to get access to an installed product he/she will never be able to get the WIFI credentials and prevent a silently connection to someone's WIFI to do malicious actions.

Also it seems Nordic nRF52/nRF53 has a mechanism called APPROTECT blocking the access to the flash and a ERASEALL erases all the flash and opens it to reflash again, meaning no access to previous WIFI.

I hope I gave you a more clear picture of why I am asking this and I hope this already exists because I really want to use an ESP32, and if not, I will be forced to use another product.

Thank you very much.

Well, the thing is that an ESP32 does not have internal flash (even the ones with the flash in-package still have it as a separate die), so reading out the flash is always an option; that is why flash encryption (and secureboot) is so important. The thing with mandatory erase with the encrypted flash available to physically mess with is that you could potentially create a hybrid - dump the flash chip, flash your own firmware, copy NVS partition back from the dump you made earlier, use your own firmware to read out encrypted NVS partition.

A theoretical way to have this would be to make the bootloader have some way to re-randomize the flash encryption key, but as this is stored in eFuses, you cannot really change that key after you've written it. You could come up with some harebrained scheme to make this work anyway (flash encryption key is XOR of something in efuses plus something read from flash?) but I'm not sure of the security implications of this.

Not sure if keys stored in the eFuses can be wiped/"overwritten", but if so, you may be able to come up with a scheme where you use a read-protected eFuse key for encryption/decryption of (only) sensitive data. Then you only allow (OTA) firmware flashing after having destroyed the key. That'd probably still leave you with a somewhat restricted ESP32, because flashing via the ROM bootloader would remain permanently disabled.

It may be easier to just stick an ESP module onto the board using pin headers. To "unlock" the device, the user would have to shell out 2 bucks for a new module, replace the one on the board, and then do with it as he pleases.

Thanks, both of these are really helpful — the hybrid attack (dump encrypted flash → reflash → restore the old encrypted NVS partition) is a flaw I hadn't accounted for, and it makes sense: the mandatory wipe erases the data, but the flash encryption key in eFuse stays the same, so an attacker can just put the old encrypted NVS back and let their own firmware decrypt it. The wipe destroys the data but not the key that reads it.

Two follow-ups:

1. On re-randomizing the key. I understand eFuses are one-time and can't be rewritten, which is what breaks the clean version of this. Conceptually what I'd want is a small rewritable secure store (something like a monotonic counter / anti-replay register) that gets reset on every firmware write, so any previously-dumped encrypted data becomes undecryptable after a reflash. Since the ESP32 doesn't have that on-die: is the recommended way to achieve replay resistance for sensitive stored data an external secure element (e.g. one with a monotonic counter / RPMB-style protection), or is there an on-chip mechanism I'm missing? The "encrypt sensitive data with a destroyable eFuse key, and only allow reflashing after destroying that key" idea seems to solve it too — is destroying/invalidating a single eFuse key block (while leaving the device otherwise functional) actually supported?

2. On the swappable module idea. I like it, but exposed pin-header contacts worry me long-term — the product lives in an outdoor street-facing meter box, so humidity, thermal cycling and mechanical stress on a non-soldered connector are a real reliability concern. My plan instead is to segment at purchase: a sealed/soldered "protected" variant, and an "open" variant for customers who want to run their own firmware — no field module swap. Does that seem like the sane commercial approach, or is there a reason people still prefer the socketed route?

Context: outdoor, physically accessible device (meter reader). Main goal is that a third party with physical access can't extract the previous owner's Wi-Fi credentials, while still allowing firmware customization for customers who want it.

1. On re-randomizing the key. I understand eFuses are one-time and can't be rewritten, which is what breaks the clean version of this.

Yes, every eFuse (bit) can either stay "0", or be written to "1" once; you could destroy a key by setting all its bits to "1".

is destroying/invalidating a single eFuse key block (while leaving the device otherwise functional) actually supported?

Not sure if the controller actually lets you do that for key material because of the error-correction codes.
TRM says "... can only be programmed once. Repeated programming is not allowed." It doesn't say what exactly happens when you try though. (Option 1: eFuse controller refuses operation, option 2: operation is performed, eFuse data gets corrupted/destroyed/unusable - which would be what we want here.)