4 ms·

Espressif ESP32: Breaking HW AES with Power Analysis (2023)

99 points by transpute 3y ago

calibas 3y ago
The article just mentions firmware encryption, it looks like secure boot is compromised as well? Both features depend on HW AES keys.
- demondemidi 3y ago
  Secure boot uses asymmetric crypto for authentication.
demondemidi 3y ago
I don’t think anyone uses ECB mode for anything. At least CTR mode is used when an AEAD is not required. CTR mode would defeat this attack. Still, I really like seeing how this is done.
- Retr0id 3y ago
  CTR is just as vulnerable to side channels as ECB, although it might be mildly less convenient to collect the traces.
ChuckMcM 3y ago
Very nice analysis. I found the setup to be pretty neat, and of course if you break a key that is distributed with all the chips ... It is an interesting challenge to secure chips, and something I don't think anyone has a really excellent response to. Always interested in papers along this area.
ComputerGuru 3y ago
I found this interesting but not actually very informative and walked away really learning nothing from having read the article submitted itself. It’s all “we used this tool” and “we followed this guide” with no explanation of theory or process. (The links provided, I’m sure, are more helpful.) There wasn’t even a discussion on why the particular AES configuration deployed was used or how it affects the process.
- graphe 3y ago
  You really learned nothing? >Therefore, we decided, in similar fashion as Ledger’s scaffold, to make our own custom board where all the relevant signals are routed to dedicated pins. Explaination or theory: someone else did it the same way. >Throughout our research we used two acquisition techniques that are supported by our oscilloscope: normal block mode and rapid block mode. We used Picoscope’s Python bindings to communicate with the oscilloscope. We used their ps3000aRapidBlockExample.py as a reference to integrate rapid block mode into Riscure’s FiPy. Sounds like they used what worked on their hardware.
- jacquesm 3y ago
  The chip should not be leaking this much information but the scaffolding around the attack is such that I doubt whether this could be pulled off so easily on a random ESP32 with its flash encryption enabled.
- xw30992 3y ago
  That's because this article is more of a part 3 of a series of articles. Part 1: https://eprint.iacr.org/2023/090 https://eprint.iacr.org/2023/090 How to break ESP32 AES with power analysis Part 2: https://courk.cc/breaking-flash-encryption-of-espressif-parts https://courk.cc/breaking-flash-encryption-of-espressif-part... How to do it for no more than $100 Part 3: This article Improving the performance
jacquesm 3y ago
To what degree does the unknown key extraction rely on the knowledge of exactly when the AES engine is engaged? They use a trigger (on pin 26 of the ESP32) to tell their acquisition hardware when the AES engine is running to zoom in on the sample that carries the most information about the key bits. In the 'unknown key' example it seems as though that trick is still used as well, but the text isn't very clear around that part - at least, not to me, but in the code it looks clearly as though that pin is still cycled around the AES encryption call. In a real world attack you wouldn't have that information, you'd have to figure out some way of determining when the AES engine is operational first. And then this attack would suddenly become a lot harder.
- fulafel 3y ago
  Spotting the em fingerprint I guess. Why would it be hard?
  - jacquesm 3y ago
    It would be hard(er) because that's not what is demonstrated here, if it would be easy you wouldn't need all that scaffolding to focus on 'sample 410 of a block of samples that occurs exactly after a self generated trigger point'. That reduces the search space considerably, in the real world you don't have that luxury. Intercepting the powerline is easy, spotting the EM signature of the AES engine in a bunch of software is arguably a harder problem than the one that they've solved here, my guess is that if it was that easy they would have shown just that and then that pin 26 magic wouldn't be there. In essence, as far as I can follow the article what they've done is to first identify a sample in a block of samples taken after their own trigger goes off that has a high likelihood of leaking bits from the key by using a known key and running analysis to verify that that sample is the one to focus on. They then proceed to monitor just that one sample to retrieve an unknown key (this had a very high likelihood of working). But that's - to me - the same as knowing exactly where in the haystack the needle is buried and then to proceed to prove this by uncovering it. Whether the needle was known or unknown doesn't matter any more at that point it's simply a way of proving that the extraction itself can work. But the hard part is to find an unknown needle in an unknown location and identifying the location without knowing the key would be a lot harder. The article reads as if you can extract any key from any ESP32 in a couple of seconds but I don't think it is quite that simple. Keep in mind that normally the flash of the ESP32 would be encrypted so you wouldn't be able to conveniently patch in a helpful trigger event around the encryption engine.

99 points by transpute 3y ago

The article just mentions firmware encryption, it looks like secure boot is compromised as well? Both features depend on HW AES keys.

demondemidi 3y ago
Secure boot uses asymmetric crypto for authentication.

demondemidi 3y ago

I don’t think anyone uses ECB mode for anything. At least CTR mode is used when an AEAD is not required. CTR mode would defeat this attack. Still, I really like seeing how this is done.

Retr0id 3y ago
CTR is just as vulnerable to side channels as ECB, although it might be mildly less convenient to collect the traces.

ChuckMcM 3y ago

Very nice analysis. I found the setup to be pretty neat, and of course if you break a key that is distributed with all the chips ... It is an interesting challenge to secure chips, and something I don't think anyone has a really excellent response to. Always interested in papers along this area.

ComputerGuru 3y ago

I found this interesting but not actually very informative and walked away really learning nothing from having read the article submitted itself. It’s all “we used this tool” and “we followed this guide” with no explanation of theory or process. (The links provided, I’m sure, are more helpful.) There wasn’t even a discussion on why the particular AES configuration deployed was used or how it affects the process.

graphe 3y ago
You really learned nothing? >Therefore, we decided, in similar fashion as Ledger’s scaffold, to make our own custom board where all the relevant signals are routed to dedicated pins. Explaination or theory: someone else did it the same way. >Throughout our research we used two acquisition techniques that are supported by our oscilloscope: normal block mode and rapid block mode. We used Picoscope’s Python bindings to communicate with the oscilloscope. We used their ps3000aRapidBlockExample.py as a reference to integrate rapid block mode into Riscure’s FiPy. Sounds like they used what worked on their hardware.
jacquesm 3y ago
The chip should not be leaking this much information but the scaffolding around the attack is such that I doubt whether this could be pulled off so easily on a random ESP32 with its flash encryption enabled.
xw30992 3y ago
That's because this article is more of a part 3 of a series of articles. Part 1: https://eprint.iacr.org/2023/090 https://eprint.iacr.org/2023/090 How to break ESP32 AES with power analysis Part 2: https://courk.cc/breaking-flash-encryption-of-espressif-parts https://courk.cc/breaking-flash-encryption-of-espressif-part... How to do it for no more than $100 Part 3: This article Improving the performance

jacquesm 3y ago

To what degree does the unknown key extraction rely on the knowledge of exactly when the AES engine is engaged? They use a trigger (on pin 26 of the ESP32) to tell their acquisition hardware when the AES engine is running to zoom in on the sample that carries the most information about the key bits. In the 'unknown key' example it seems as though that trick is still used as well, but the text isn't very clear around that part - at least, not to me, but in the code it looks clearly as though that pin is still cycled around the AES encryption call. In a real world attack you wouldn't have that information, you'd have to figure out some way of determining when the AES engine is operational first. And then this attack would suddenly become a lot harder.

fulafel 3y ago
Spotting the em fingerprint I guess. Why would it be hard?
- jacquesm 3y ago
  It would be hard(er) because that's not what is demonstrated here, if it would be easy you wouldn't need all that scaffolding to focus on 'sample 410 of a block of samples that occurs exactly after a self generated trigger point'. That reduces the search space considerably, in the real world you don't have that luxury. Intercepting the powerline is easy, spotting the EM signature of the AES engine in a bunch of software is arguably a harder problem than the one that they've solved here, my guess is that if it was that easy they would have shown just that and then that pin 26 magic wouldn't be there. In essence, as far as I can follow the article what they've done is to first identify a sample in a block of samples taken after their own trigger goes off that has a high likelihood of leaking bits from the key by using a known key and running analysis to verify that that sample is the one to focus on. They then proceed to monitor just that one sample to retrieve an unknown key (this had a very high likelihood of working). But that's - to me - the same as knowing exactly where in the haystack the needle is buried and then to proceed to prove this by uncovering it. Whether the needle was known or unknown doesn't matter any more at that point it's simply a way of proving that the extraction itself can work. But the hard part is to find an unknown needle in an unknown location and identifying the location without knowing the key would be a lot harder. The article reads as if you can extract any key from any ESP32 in a couple of seconds but I don't think it is quite that simple. Keep in mind that normally the flash of the ESP32 would be encrypted so you wouldn't be able to conveniently patch in a helpful trigger event around the encryption engine.