[HN Gopher] Secure Boot on ESP32 Platforms
___________________________________________________________________
Secure Boot on ESP32 Platforms
Author : pdubouilh
Score : 54 points
Date : 2023-08-29 09:13 UTC (2 days ago)
(HTM) web link (thistle.tech)
(TXT) w3m dump (thistle.tech)
| syncomo wrote:
| 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
| ianlevesque wrote:
| 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.
| syncomo wrote:
| 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.
| bitwize wrote:
| 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.
| ianlevesque wrote:
| 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.
| abelsson wrote:
| 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.
| 420official wrote:
| How could that work? A consumer would be required to build
| the firmware and flash it to the product themselves?
| abelsson wrote:
| 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.
| westurner wrote:
| 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.
| krasin wrote:
| >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.
| flangola7 wrote:
| 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?
| theamk wrote:
| 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.
| [deleted]
| randmeerkat wrote:
| > 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..?
| ianlevesque wrote:
| 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.
| xnzakg wrote:
| 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!
| ianlevesque wrote:
| 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.
___________________________________________________________________
(page generated 2023-08-31 23:01 UTC)