Espressif’s ESP32 microcontrollers come with a Flash encryption feature that when enabled ensures that the data and code stored on the (usually external) Flash chip is encrypted with AES-256 (ESP32) or better (ESP32-C3, -C6). For the ESP32 this encryption feature has been shown to be vulnerable to side channel attacks (SCA), leading [courk] to not only replicate this result with a custom ESP Correlation Power Analysis (CPA) board (pictured) that captures power usage of the MCU, but also to try his luck with the ESP32-C3 and ESP32-C6 parts that should be tougher nuts to crack.
Whereas the ESP32 uses a fairly straightforward AES-256 encryption routine that together with the exposed Flash communication lines on the QSPI bus make for a textbook SCA example, the ESP32-C3 ups the encryption to XTS-AES, which uses two 128-bit keys on the -C3 part (XTS-256). This particular MCU is still susceptible to the same SCA attack with CPA, making it somewhat harder to attack than the ESP32, but by no means impossible.
Following the advisory from Espressif (PDF) regarding the cracked ESP32 Flash encryption, anti-SCA measures were said to be implemented in future Espressif designs, which includes the ESP32-C6. These measure serve mostly to mask and obfuscate the internal operations in order make power trace data less useful. These countermeasures can be enabled in stages, which [courk] did, to see how much they affect a CPA-based SCA. Perhaps shockingly, none of these seemed to affect the CPA attack much, if at all.
As a bonus round, [courk] then decided to speed up the painfully slow process of recovering the encryption keys by fault injection, which just requires the first 128 bytes (one block) on the -C3 and -C6 parts. Using a voltage fault injection the Secure Boot feature is bypassed. The essential idea is that through a buffer overflow custom code can be run, which dumps the entire Flash content. After demonstrating this and report it to Espressif, an advisory was published that notes that there’s no defense against this SCA and fault injection attack, other than using an ESP32 part that has internal Flash and no access to the QSPI bus from the outside.
It would seem that with how leaky the Flash encryption is on these ESP32-family parts, placing your bets on an attacker having an aversion to decapping an IC might indeed be your best defense.
Top image: Block Diagram of the ESP CPA Board (Credit: Courk at courk.cc)
My ESP32 implementations have assumed the client iot device could be compromised. The ESP32 collects inputs and sends them to the cloud where logic is applied and combined with other datasets. The ESP32 may retrieve the results for display. No significant processing is performed on-device.
That’s a design choice that also comes with drawbacks, such as the complete unavailability of your device if the Internet link drops, or your device being unreliable of the link is.
Not saying it’s a bad choice – but these drawbacks may make it impossible to select such an implementation for certain applications, and as such the security issues raised by this article are a problem for at least a certain group of applications
How nice to make devices depend on “the cloud”… When keeping the servers active is no longer profitable, all those devices literally die.
Your making sound like those devices are now bricked? Install local server, fix dns and/or routing and your going again, its not the disaster your making it out to be. Arent we over hating “the cloud” yet?
Why do you presume that the protocols are open and you can use a local server?
Why do you presume they aren’t?
notmyfault2000 says: “Why do you presume they aren’t?”
Worst comeback ever.
Also what possible reason could there be to stop hating ‘the cloud’? Did something happen that I missed? Must have been quite the event… AFAIK it only gets worse and worse and worse and evidence of it being a bad thing is piling up and up.
I think his devices will fail before he stops using esphome.
That is not a necessary consequence of using cloud services, and it would happen just as much with privately owned servers if they are running proprietary software.
Open protocols and open source are the way to avoid vendor lock, no matter where the server runs.
+1
Use aes-512 bit then encrypt that with rsa1024 or 2048 on top of that
Good luck finding those keys
AES-512 isn’t a thing?
AFAIK the ESP32 parts with internal flash still expose the QSPI pins on the package, so I am not sure what you are referring to with the last part of this article. Perhaps a BGA part? Are there BGA ESP32s?
According to the ESP32-C3 datasheet (v1.5), the internal flash pins are not bonded for some specific P/N. For example, pins 19 to 24 are NC for the `ESP32-C3FH4AZ`.
Don’t seem to see the Epoxy pot used as a IP security measure much these days?
Epoxy potting will not stop someone that’s determined enough.