Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
Moderated By dondu:Hover topic, as this is important information and would be good to be collected in one topic.
mipix wrote:.some future products with this controller will be blocked from changing the software.
dondu wrote:.This is how it can be understood, which will cause the problem of changing the software to address other security vulnerabilities. I think they have backed themselves into a corner all the more
khoam wrote:.dondu wrote:.This can be understood, which will cause a problem with software substitutions to address other security vulnerabilities. I think they have backed themselves into a corner all the more
I suggest reading the current eFuse documentation for ESP32:
https://www.espressif.com/sites/default/files...ation/esp32_technical_reference_manual_en.pdf (chapter 20), and
https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/efuse.html
Quote:.The attack works against eFuse, a one-time programmable memory where data can be burned to the device. The ESP32 official documentation describes why the attack works: "Each eFuse is a one-bit field which can be programmed to 1 after which it cannot be reverted back to 0." By burning a payload into the device’s eFuse, no software update can ever reset the fuse and the chip must be physically replaced or the device discarded.
dondu wrote:I just read the article indicated in the first post and in it:
.
dondu wrote:.Did I understand correctly that the average user of an ESP32 programmed e.g. in the Arduino environment does not use the recommended security features and is thus vulnerable to attack without having to physically access the chip?
khoam wrote:.dondu wrote:.I only read the article indicated in the first post and in it:
Well, that's exactly what it said, but it didn't include any more information, that this requires direct physical access to the MCU in the device in question and requires "some" modifications in the pcb itself and in some cases opening the metal case ESP32, if there is one - I'm not referring to the simple and cheap developer boards from AliExpress on which "penetration" tests have been done, because that was simpler.
Furthermore, Espressif's recommendations were and are clear on ESP32 security (as long as one needs, understands and uses them):
• Use per-device unique keys for Secure Boot and Flash Encryption.
• Generate per-device unique keys stored in flash for application uses, rather than using a single shared key across all devices. .
Following the above rules ensures that 'breaking' one ESP32 in one unit of a given device, will not result in 'breaking' the security in all other ESP32s in the same devices i.e. with the same firmware. The wise will listen and the foolish will 'save'.
This is what one of the 'hacking' steps looks like after removing the ESP32's metal casing:
vagteile wrote:.Espressif irresponsibly designed the validation and additionally upset the LR guy with its policy/curiosity, which hiccuped
vagteile wrote:Unique keys for Secure Boot and Flash encryption get very kludgy from a certain volume.
khoam wrote:Espressif has already designed and will release new versions of ESP32-D0WD-V3 this quarter that are resistant to this local attack.
TL;DR: ESP32 hardening relies on eFuses—"Each eFuse is a one-bit field … cannot be reverted." Burnt fuses can’t be undone in software, so fixes may require hardware replacement. [Elektroda, dondu, post #18317334]
Why it matters: Makers and teams shipping ESP32 products need clear steps to harden devices and plan realistic remediation without wishful OTA fixes.
.
