Secure Boot on ESP32 Platforms | Hacker News Reader

Secure Boot on ESP32 Platforms

thistle.tech

67 pointspdubouilh17 comments

Informative, but if you’re building ordinary consumer hardware please don’t enable secure boot on your ESP32 device. There’s a thriving ecosystem of open source software (for example ESPHome) that gives flexibility to how a device is used and long term support long after your project or company has failed. We don’t need more electronic landfill rubbish when motivated individuals could tinker with them instead.

Secure boot is a restriction put on a device, indeed. Whether secure boot should be enabled on a device or not depends on the perspective, and also on the threat model. For example, for an ESP32-based crypto wallet product like Jade (https://github.com/Blockstream/Jade) that's to be used to store Bitcoin, it's very likely a very good idea to enable secure boot, no matter it's an official or DIY device.

Came here to comment the same thing. I'm also personally not a fan of not being able to own your devices (or just not being able to keep them alive once the manufacturer turns off some server...), though there are two issues: One is people who buy IoT <thing> and then complain when it gets compromised because it was connected to the internet and someone somewhere found a way to turn their device into part of their botnet. The other is pressure from shareholders/management etc to ensure the code stays secret because imagine if a competitor had access to your IoT juicer's firmware and used it in their own product, oh no!

Secure boot doesn’t fix the first one because a buffer overflow exploit won’t get verified and prevented by the boot signature verification. As with all DRM schemes it mostly only hurts your legitimate customers.

The second is uninteresting because often they can just get your exact product off the same assembly line after hours.

I’ve heard of a third, which is a concern that having the option to load unapproved software somehow compromises the security of everyone else. I don’t buy it.

Even if you don't agree with it, the two lissues for the third point are that an RCE lets an attacker irreversibly modify the firmware remotely, or that the user will intentionally install an older unsupported version that contains an RCE. Vendor controlled firmware also has this issue, but that's the "compromises the security of everyone" with #3 because the attacker can now use the device as a VPN or as part of a DDOS botnet.

The future of computing is that all code running on a device is one of the two S's: Signed or Sandboxed.

To do otherwise presents unnecessary risk.

That perception is what we need collectively to fight. It turns a world of makers into passive consumers and we’re worse off for it. There’s been a couple examples, where indeed that was the perception, and the products ultimately did get discontinued and leave millions of units to rot. Such a waste.

>The future of computing is that all code running on a device is one of the two S's: Signed or Sandboxed.

>To do otherwise presents unnecessary risk.

Unnecessary risk to whom? To monopolies that want to control the devices?

I would say the future is requiring open-source flashable firmware to every programmable chip on every piece on industrial or consumer equipment sold.

My vision of the future is farther away than the Signed&Sandboxed, but we should collectively take efforts to minimize damage from the near future of locked down devices controlled by unknown parties.

Unnecessary risk to everything and everyone else on the internet eventually.

AI will create perfect Sybil attacks. The reality dictates our need of a signal for humanness. To know an interaction is a real human and not an indistinguishable simulation of one. Picture if the internet was flooded with 100 trillion malign actors and trolls, each tireless, merciless, skilled at both social manipulation and cyber attacks, with no way to tell if they are real people or not. Even a live video call with them cannot be trusted, not even if they look and sound like someone you know.

We're not there yet, but how far out do you feel confidant in saying that will still be the case? Two years? Five?

> Unnecessary risk to everything and everyone else on the internet eventually. AI will create perfect Sybil attacks. The reality dictates our need of a signal for humanness. To know an interaction is a real human and not an indistinguishable simulation of one. Picture if the internet was flooded with 100 trillion malign actors and trolls, each tireless, merciless, skilled at both social manipulation and cyber attacks, with no way to tell if they are real people or not. Even a live video call with them cannot be trusted, not even if they look and sound like someone you know.

And secure boot on ESP32s is what will save us from this dystopian vision of the future..?

We are talking about things like light bulbs and weather sensors.

They do not pretend to be humans, and will never run AI on the device itself, so there is no concerns about social manipulation.

But there are concerns (and many, many examples) of devices that rely on vendor's cloud.. and the vendor goes out of business, making devices useless. If there is no secure boot, people can flash alternative firmware and make devices usable again. If everything is signed, the device has to go to landfill instead.

It's unclear to me how locking down devices with signed firmware fits into that dystopia you are imagining, other than by making it impossible to fight back since you're not allowed to modify anything.

That’s fine, assuming we pass laws mandating that signing keys can be controlled by end users. Otherwise we end up where no-one really owns their devices any more, every device would be merely temporarily rented.

How could that work? A consumer would be required to build the firmware and flash it to the product themselves?

Of course not. Having the ability to add or modify root CAs in browsers doesn’t imply a requirement to sign every webpage yourself either.

NVIDIA GPU Linux kernel modules must be self-signed to work with SecureBoot enabled; they must be self-signed every time they're updated by an akmod package upgrade.

So, it is necessary to remove the MS SecureBoot ~CApubkey and add the OS and local ~CApubkeys to the SecureBoot cert list with BIOS, and re-sign every module install|&build in order to work with NVIDIA (and probably also AMD?) in containers.

It's necessary and a fair expectation that users will continue to be able to remove and add x86-64 SecureBoot bootloader signing keys.

This post is a follow-up to the first blog post (https://thistle.tech/blog/esp32-secure-boot-v2-enablement-1) on the topic of secure boot v2 enablement on ESP32 platforms

Reply on news.ycombinator.com