Secure Boot on ESP32 Platforms(thistle.tech) |
Secure Boot on ESP32 Platforms(thistle.tech) |
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.
To do otherwise presents unnecessary risk.
>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.
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?
And secure boot on ESP32s is what will save us from this dystopian vision of the future..?
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.
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.