#44: ESP32-C5 XTS-AES Encryption Vulnerability
Espressif just published a security advisory (AR2026-001) about a vulnerability in the ESP32-C5’s flash encryption. A researcher from Positive Technologies found a way to bypass the pseudo-round countermeasure in the XTS-AES peripheral using a Correlation Power Analysis (CPA) attack. Let’s break down what this actually means for a product using the C5.
What Happened
The ESP32-C5 uses XTS-AES encryption (recommended in NIST SP 800-38E) to protect the contents of flash memory. To make side-channel attacks harder, the chip inserts dummy encryption rounds with fake keys so the power consumption looks random to anyone trying to snoop. If an attacker is watching how much power the chip draws during encryption, the dummy rounds should make it nearly impossible to figure out which operations are real.
The researcher found that the transition between dummy rounds and real rounds produces a distinguishable power signature. Once you can tell the difference, you can isolate the real AES operations from the noise and start recovering keys.
How Bad Is It?
Before you panic, let’s look at what an attacker actually needs to pull this off.
Physical access to the device. Purpose-built measurement hardware (specialized ADCs, signal amplifiers). Controlled thermal conditions. A custom SPI flash emulator. Significant computational resources. And a lot of patience.
With the pseudo-round mechanism at its highest level and clock randomization enabled, recovering the key for a single 128-byte block takes several days. That’s 128 bytes. Attacking just 1 KB of flash content would take several weeks at the highest protection level. Decrypting the entire flash? Espressif calls it “impractical” and I’d have to agree.
XTS-AES uses a separate key per flash block AND requires recovering both the tweak value and the encryption key. The CPA attack can only recover the tweak value per block, not the tweak key directly. So even after days of work on a single block, you’re not done. You still need to break the second component.
And since each device has a unique flash encryption key, you can’t scale this attack across a fleet. You’d have to repeat the entire process per device. So unless you’re device is used by the CIA, this is unlikely to a problem for you.
Should You Care?
Almost certainly not but let’s talk about affected chips. This has been confirmed on the ESP32-C5 (Chip Revision v1.0 and v1.2). Espressif notes that the technique may be theoretically applicable to other chips with the same XTS-AES peripheral architecture, like the ESP32-P4. Interestingly, the ESP32-H2 (v1.2) was tested during the same research and was found NOT vulnerable. Differences in its internal power delivery architecture prevent the attacker from getting usable power signatures. So if you are really worried about this particular kind of attack, consider using the H2.
Mitigation Options
In Espressif’s own words “At present, there is no complete software or hardware fix available for this issue.” Espressif says future chips will have improved hardware countermeasures. In the meantime, here’s what you can do:
Hardware side: Physical access prevention is the single most effective countermeasure. If an attacker can’t probe the power lines, the attack doesn’t work. Tamper-resistant enclosures that detect and respond to breach attempts (resetting the device or clearing secrets) are your best bet here. Also consider using the SiP (System-in-Package) variant like the ESP32-C5HF4 where the flash pins are terminated internally. No exposed flash pins means no external flash emulator. Although honestly, given how sophisticated this attack is, internal pins are probably not stopping a would-be attacker.
Software side: Enable the pseudo-round mechanism at its highest strength AND enable clock randomization. Yes, the pseudo-round was bypassed, but the clock randomization at the highest level is what causes this to take weeks for just a 1KB flash block. Configure both protections during first boot.
Application side: Don’t use shared encryption keys across devices or manufacturing batches. If every device has a unique secret tied to its identity, the attacker can’t leverage one compromised device to attack the rest. And always enable Flash Encryption and Secure Boot together. Secure Boot prevents an attacker from rewriting firmware even if they manage to decrypt a portion of flash.
Conclusion
While very scary sounding, this is unlikely to be a security issue that has any meaningful impact on your product. For most of us, this is a good reminder that flash encryption is one layer in a security strategy, not a silver bullet. And it’s a great excuse to audit your security configuration if you haven’t already.