Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secure Boot on ESP32 Platforms

thistle.tech

Post reply on HN
Print view View original

11–19 of 19 posts

Re: Secure Boot on ESP32 Platforms

#11

Post by ianlevesque »

flangola7 wrote: post #10
krasin wrote: post #9

Earlier quoted context omitted.

>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…

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,…

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.

Re: Secure Boot on ESP32 Platforms

#12

Post by [deleted] »

flangola7 wrote: post #10
krasin wrote: post #9

Earlier quoted context omitted.

>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…

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,…

[deleted]

Re: Secure Boot on ESP32 Platforms

#13

Post by westurner »

abelsson wrote: post #8
420official wrote: post #7

Earlier quoted context omitted.

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.

Re: Secure Boot on ESP32 Platforms

#14

Post by theamk »

flangola7 wrote: post #10
krasin wrote: post #9

Earlier quoted context omitted.

>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…

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,…

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.

Re: Secure Boot on ESP32 Platforms

#15

Post by randmeerkat »

flangola7 wrote: post #10
krasin wrote: post #9

Earlier quoted context omitted.

>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…

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,…

> 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..?

Re: Secure Boot on ESP32 Platforms

#16

Post by xnzakg »

ianlevesque wrote: post #3

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.

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 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!

Re: Secure Boot on ESP32 Platforms

#17

Post by ianlevesque »

xnzakg wrote: post #16
ianlevesque wrote: post #3

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.

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 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. Th…

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.

Re: Secure Boot on ESP32 Platforms

#18

Post by syncomo »

ianlevesque wrote: post #3

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.

Re: Secure Boot on ESP32 Platforms

#19

Post by fragmede »

ianlevesque wrote: post #17
xnzakg wrote: post #16

Earlier quoted context omitted.

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 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. Th…

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 soft…

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.
Post reply on HN