from Hacker News

Pwn the ESP32 Forever: Flash Encryption and SEC. Boot Keys Extraction

by wolframio on 11/21/19, 8:59 PM with 76 comments

• by jws on 11/21/19, 9:30 PM

  Synopsis: Secret keys are embedded in the device's e-fuses and are not readable by normal means because of a protection e-fuse. By measuring current draw during power up an interval is determined to be the time when the CPU is reading the e-fuses. At that time the power supplies are "glitched" from 3.3v to 6v using unspecified patterns from a signal generator. This causes errors in the e-fuse reading, one of which is to make a bank of read protected fuses readable. The read values have errors in them, but multiple runs and statistical error correction can retrieve the actual values.

  Physical access to the device is required. Security compromise is permanent.

• by LeifCarrotson on 11/21/19, 9:33 PM

  This is an interesting attack, and certainly looks highly successful in terms of allowing a determined hardware hacker to gain root/bootloader access to a device that the manufacturer has attempted to lock them out of. Glitching with a 6V supply on a 3.3V bus is certainly something I'd want to be a little cautious of if the hardware was more expensive than a $10 dev board - I wouldn't buy a $800 IoT fridge and use this to install alternate firmware just for fun, but it's nice to know it's possible in case my fridge stops working because the manufacturer declares it end-of-life. It's just not clear to me if or how this is a bad thing. The author writes:

  > This FATAL exploit allows an attacker to decrypt an encrypted firmware because he is now in possession of the AES Flash Encryption Key.

  > Worst case scenario, he is now able to forge his own valid firmware (using the Secure Boot Key) then encrypt it (using the Flash Encryption Key) to replace the original firmware PERMANENTLY.

  > This last post closes my security investigation on ESP32, which I consider now as a broken platform.

  Isn't that a good thing for me as a consumer? I like the ability to decrypt and modify my own devices. I like that this is a permanent modification, unlike eg. dd-wrt where you have to prevent the bootloader from overwriting your software with that of the manufacturer.

  The only thing I can think of that would be really bad is if I had a device with an ESP32 inside physically stolen then reinstalled by an attacker (or a counterfeit sold to me with malicious code from the vendor) and this exploit allowed them to get private data from my network to an Internet location. But they could already just buy or build their own device, ESP32 or not, to do that.

  This is only bad for draconian IoT manufacturers who want to enforce their terms of service and artificial limitations on hardware they think consumers are leasing but consumers think they are buying.

• by wiremine on 11/21/19, 9:36 PM

  Some additional info is in Espressif's notification (CVE-2019-17391) which is linked to in the write up: https://www.espressif.com/en/news/Security_Advisory_Concerni...

  The fix is in ESP32-D0WD-V3 and ESP32-WROVER-E, but of course that doesn't do you any good if you've already shipped product.

• by gorgoiler on 11/22/19, 1:08 AM

  Something about e-fuses seems quite mystical. The idea of a computer program deliberately and permanently damaging its own hardware (or hardware it is attached to) using a mechanism so close to regular operation (current flowing in memory) but for a good reason rather than to cause harm, and in such an information rich way.

  Different to say a robotic tool using its tooltip to maim itself and different to one robot building another, because at the e-fuse level of detail it’s so much more information sense.

  Perhaps it’s like a tattoo? Perhaps I’m thinking of the ship tattoos in Surface Detail by Iain M Banks?

• by planteen on 11/22/19, 4:21 AM

  I've heard e-fuses in general are vulnerable to optical inspection under polarized light after deliding a part. So if someone capable really wanted to clone a device, it's very possible they already were able to get the e-fuse key values.

  I once used the e-fuse feature of another part for bootloader integrity. I wasn't worried about encryption, but the part would validate the bootloader integrity when encrypted. If integrity failed, the part would keep searching for a valid image. It was an easy way for some protection against flash corruption.

• by andrewstuart on 11/21/19, 9:08 PM

  I believe this requires physical access to the MCU.

• by _def on 11/22/19, 10:21 AM

  I didn't even know the ESP32 had these security capabilities, but I guess I've not been missing out ;)

• by chli on 11/22/19, 1:12 PM

  From the article:

  > I quickly identify a pure HW processing 500us before the beginning of the UART ascii strings ‘ets June 2018’ corresponding to the BootROM process.

  > This HW activity is probably the eFuses Controller initialisation, and a load of the eFuses values in some dedicated buffer memory, to be used by the Flash controller for further steps).

  How one would come to this specific conclusion without having any prior knowledge of the boot rom ?

• by MrBuddyCasino on 11/21/19, 9:34 PM

  Props for the effort, but who expects a cheap china MCU for consumer products to be resilient against glitching attacks? You don’t use that stuff in high-security settings anyway. For consumers products resilient to advanced hardware attacks, I can only think of the iPhone and some consoles. Anything else?

• by traverseda on 11/21/19, 10:40 PM

  If you're interested in this problem space you should definitely check out the chip whisperer. They make some great hardware for doing this kind of test.

  https://newae.com/tools/chipwhisperer/

• by kbumsik on 11/21/19, 9:49 PM

  I'm wondering, how many companies that use ESP32 actually use the firmware security feature?

• by throwaway77384 on 11/22/19, 11:34 AM

  Could this get around a locked bootloader on a Sony Xperia Z5 Compact? (As in, the normal sony-website-enabled bootloader unlock NOT allowed when checking in service menu)

  If so, there might be a bounty out for it...

• by crankylinuxuser on 11/21/19, 9:53 PM

  Permanent ownership of device that was previously under control from another is now enforced.

  Regaining control of your stuff is essential.