Extract eFuse content using a (electron) microscope

[dbahrdt]

I was wondering how difficult it is to read the eFuse state directly from the chip.
One first has to remove the packaging which seems to be pretty easy (https://fahrplan.events.ccc.de/congress ... ckmann.pdf).
It may then be possible to visually identify the eFuse state using a (electron) microscope (as shown in https://www.researchgate.net/figure/a-D ... _334624423).
What kind of resolution is necessary to determine the state?
I guess that heavily depends on the structure size of the eFuse?
Is it possible to locate the eFuses in the die shot (https://s.zeptobars.com/esp32-HD.jpg)?

I'm asking this because if we enable Flashencryption to protect the compiled firmware from inspection, then physically reading the eFuse and thus the Flashencryptionkey might be a feasible and cheap way of getting the compiled firmware.
Spending time at a SEM does not seem to be that pricey (https://medicine.iu.edu/research/suppor ... py/pricing) either. These are university level prices so I guess industry prices are likely a bit higher.

[ESP_Sprite]

There's more needed than that: you would also need to delayer the chip and find out how the physical efuses map to the logical ones. I'm not even sure if you could read out the eFuses (nowadays, I don't think they physically break on burning, rather they go though a phase change) but you might be able to read them out using microprobes or something, or FIB shenanigans. This certainly is not impossible given you have a fairly large resources and time. Do notice that none of the steps involved here is error-proof either, so I imagine an attacker would go through a fair amount of samples (and spend some amount of time and money on failing) before they get something they can work with.

However, you have to keep your threat level in mind. If you need to protect your firmware against state-level actors (or very determined companies or individuals), your hardware/software decision should be a lot more complicated than 'eh, let's throw an ESP32 at it'. For your generic WiFi-controllable desk lamp, on the other hand, no one is gonna bother trying to spend so much time and effort to get a compiled binary.

Also keep in mind what the purpose of extracting the firmware is. For instance, if you have an IoT product and want good security, you'll likely give each device its own private key it can use to access your network infrastructure. Getting the eFuses for one device allows you to make copies that all have the credentials of that single device. It's trivial to detect that on your network infrastructure and blacklist the compromised keys.

[dbahrdt]

Thank you for your very fast response!

There's more needed than that: you would also need to delayer the chip and find out how the physical efuses map to the logical ones. I'm not even sure if you could read out the eFuses (nowadays, I don't think they physically break on burning, rather they go though a phase change) but you might be able to read them out using microprobes or something, or FIB shenanigans. This certainly is not impossible given you have a fairly large resources and time. Do notice that none of the steps involved here is error-proof either, so I imagine an attacker would go through a fair amount of samples (and spend some amount of time and money on failing) before they get something they can work with.

That's why I'm mostly thinking in terms of cost. You can get a Zeiss Orion Nanofab for about 2M USD.
That's a lot of money. However if you can get this as a service or rent it for some time, then extracting the eFuse data might become more feasible. You don't happen to know the cost of operating these analysis devices? There does not seem to be a lot of information available in the scientific literature. I did find a lot of papers regarding Thermal Laser Stimulation. However that is likely not applicable to eFuses.

Also keep in mind what the purpose of extracting the firmware is. For instance, if you have an IoT product and want good security, you'll likely give each device its own private key it can use to access your network infrastructure. Getting the eFuses for one device allows you to make copies that all have the credentials of that single device. It's trivial to detect that on your network infrastructure and blacklist the compromised keys.

We're already doing that. Additionally all updates are encrypted and only authenticated devices are allowed to request an update.
We also assume that devices may be compromised and thus only absolutely needed operations are possible within our network.
However my company is more concerned about protecting their IP and as an additionally protection against security bugs.