Pwn the ESP32 Forever: Flash Encryption and SEC. Boot Keys Extraction
limitedresults.com
limitedresults.com
Physical access to the device is required. Security compromise is permanent.
My guess is that the e-fuse is checked on every bit-read, so sometimes you don’t get the true value because your glitch isn’t precise enough.
Possibly there’s some randomization in the timing of each read, but there’s a signature current draw before each read that you can use to trigger your glitch.
Owners have physical access to their devices, but so do others. It's far from obvious to me that as owner, I benefit from elevated privileges, when anyone with temporary physical access also get the same elevated privileges.
Two things,
1. You know you’ve made it when there is a Chinese clone of your product.
2. I’ll never use that chip again.
I could tell you about hardware security modules (HSM) or the new ARM trustzone for small micros, but I’m designing new products so that if I handed you the source - you still can’t clone a board. That requires a connection to a better trusted device.
I highly doubt that. From what I know, that feature was more of a nod to their customers from the West.
To most Chinese entrepreneurs, it makes no sense how your software being copied be an issue:
1. If you have a real specific reason why disclosure of your code be an end to your business, it will get hacked and copied anyways.
2. If you rely on that to stave away competition, you are already are in a such competitive market where this will make no difference, and your business will be cloned anyways.
3. You will get bad rep for that
1. Do not strike gold — look for an easily entrechable position in niche market, like a lot of companies in US do
2. Economies of scale — works until your competitor bribes a banker for a giant loan
3. Be one step ahead — look at FAB business. In microelectronics fabrication, everybody copy each other, and you can't do anything about it, but somehow companies still maintain their positions
But there's a big difference between being cloned in a month, and being cloned in a year.
Within a year, maybe you could build a brand, create v2, have some economies of scale in dealing with your suppliers(harder to bribe), create some internal expertise.
The last situation is somewhat similar to the fabless companies.
> 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.
Imo a platform is broken if the user can't control it.
Most consumers aren't going to write custom firmware for their lightbulbs.
Of course, I think this exploit is impractical for a lot of cases given how the ESP32 is typically used, but, ymmv.
A computer anyone—not just the owner—can root given physical access, is like a lock that anyone—not just the owner—can non-tamper-evidently pick open. It really is broken.
Security isn’t all or nothing, it’s about understanding what the different threats are and adequately protecting against them. Not everyone is trying to protect against attackers with millions of dollars at their disposal. There is plenty of value to deterring 99% of attackers with physical access.
The idea of security as all or nothing, and that physical access thus defeats all security measures, are security tropes that need to die. You can see how obviously wrong they are when you consider that just about every security system depends on proper behavior by trusted human beings, who are never 100% reliable.
If a malicious person has entered your home or workplace, access to your computer should be low on the list of worries.
ATMs. Parking meters. Building security/intercom systems. Digital billboards and transit information signage.
These are the IoT devices that need to be hardened against physical access.
I'd argue that if you want to use some kind of device as part of your security system, and that part has to endure temporary physical access from unauthorized third parties, then you need something that is designed for that. Considering a software broken when it's clearly not designed to withstand physical tampering ... is a bit silly. (Though considering it broken in terms of IP protection is not surprising, it was never really designed for that either.)
Though, of course, you're absolutely correct that compared to its price (or cost), it's a lot more secure than an empty floppy (yet similarly simple - except you can't toggle an efuse with hand), or early smart phones (or early anything, that was complex, ran every kind of software as root, and so naturally was full of holes).
...and I think that's perfectly fine and IMHO required. I've long been a proponent of the philosophy that a little bit of insecurity is what keeps society in general from turning into complete dystopia; but unfortunately, paranoia and the search of "perfect security" is driving it in that direction.
In other words, striving for perfect security is treacherous precisely because humans are not 100% reliable. The same way you would probably not want "perfect" law enforcement by the government.
More like calling a PC broken if you can install your own OS even after you've enabled Secure Boot and a TPM (in which case, the security features are objectively broken)
A perfect example of how this could be a problem would be the modification of a utility providers smart meter. The home owner hacks the firmware of their electicity meter to show a 10% reduction of power consumption.
Im sure there are several more applications of this exploit that would allow end users who are not the owners of the hardware to make it a threat large enough for manufacturers to consider using a more secure device.
In general most people are honest, most of the others are deterred by stiff penalties, and these issues are kept in check at "human scale". DRM schemes are more likely to be used to erode long-held precepts, rather than being needed to enforce them.
If so this is a fairly serious hack especially for devices that auto-update OTA.
So this hack will only work on a single esp32.
If you're the sort of person who buys wifi-based-internet-enabled door bells, but you don't want someone who steals your doorbell to (a) be able to extract your wifi password or (b) be able to get the thing to work at all, you might appreciate resistance to the thief's attacks.
Of course, you can also address this security concern by just not buying an internet-enabled doorbell.
Another solution is to use a second gateway inside the house that manages the Wifi part and secure communication with the doorbell via short range radio.
No kidding. What really grinds my gears is the fact that these authoritarian "security" people are effectively helping to tighten the nooses around everyone else, and very eager to do it too. It's one thing to post about an exploit you've found and help the community, but I'll never agree or help anyone who goes snitching to the company about it. In the "old school" hacking culture you would be called a corporate sellout, or worse, for doing that.
It is, of course, possible to replace an entire physical device with your own hacked one, and have nobody be the wiser. But the theory goes, that would be a lot harder than just copying rooted firmware into a device remotely. (The above system was hacked this year, though)
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.
Perhaps because it would use up more space in the ROM? If so, I wonder what functionality they dropped from the ROM to add it now? I somehow doubt they made the ROM bigger - that would be very expensive at this stage of the chips lifecycle.
At some point, the software has to be decrypted on the physical device to run. The best you can ever do is put enough physical hoops in the way to make it impractical to defeat.
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?
Of course the actual mechanism used in OTP memory is different...
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.
> 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 ?
And, the way all of those things work is by setting registers so that they're visible in the software either _still_ in a register, or mapped into the address space.
Edit: I checked your profile and see that you're an embedded engineer, so I must have missed some nuance in your question, because power glitching the boot sequence to mess with hardware init it a really popular vector for attacking embedded devices. Please feel free to disregard my reply.
Forgive my ignorance, but what would one use?
i.e. what's the high-sec equivalent of a esp32?
Disclaimer: used to work there but this is all public information
> Vulnerability n*2: No security settings (at all)
Since I first started work in OEM electronics in 2007, I only saw that being requested 3 times.
If so, there might be a bounty out for it...
Regaining control of your stuff is essential.