[Aurornis]

Forcing the release of signing keys would be a security disaster. The first person to grab the expired domain for the auto update server for a IoT device now gets a free botnet.

The only real way to make devices securely re-usable with custom firmware requires some explicit steps and action to signal that the user wants to run 3rd-party firmware: A specific button press sequence is enough. You need to require the user to do something explicit to acknowledge that 3rd-party software is being installed, though.

Forcing vendors to release their security mechanisms to the public and allow anyone to sign firmware as the company is not what you want, though.

[torginus]

Embedded devices that go on the internet by (to update) themselves are an anti-pattern.

I run a bunch of stuff using Home Assistant via the Zigbee integration - the Zigbee host on the local server gets to decide where to install updates from - which was the security mechanism for most most software for most of history.

Get your stuff from a reputable source. Signage keys are nice, but they don't work as the sole security measure in an unsound supply chain.

[Retr0id]

The OTA firmware update keys ideally shouldn't be the same as the secure boot keys.

[jcgl]

…how do the updates get booted then?

[bigfatkitten]

ROM bootloader loads a second stage bootloader (e.g. [1]). The ROM bootloader verifies that the second stage loader is signed with keys fused into the MCU. The second stage bootloader in turn verifies application images shipped by the vendor, using a different set of keys.

When the vendor discontinues support for the device, they make available to their customers an optional update to the second stage bootloader that allows any application image to run, not just images signed by the vendor. This updated second stage loader is signed with the keypair fused into the MCU, and so it will run as per normal. They ideally make it so this update can only be installed with some sort of local interaction with the device, not automatically over the air.

Devices in the field running ordinary OEM firmware continue to be protected from malicious OTA updates. Customers who wish to unlock their devices also have the means to do so.

This is very technically straightforward to implement, but it needs to be considered when the device is designed. Regulations would be required to make sure that happens.

[1] https://www.trustedfirmware.org/projects/mcuboot/

[jcgl]

That does sound better, but haven't you just made the unlocked seconds stage bootloader functionally equivalent to secure boot keys?

Instead of [get released SB keys] -> [boot arbitrary payloads]

It becomes [get unlocked second stage bootloader] -> [boot arbitrary payloads]

Although, I guess that the details matter in terms of the process used to supply OTAs and second stage bootloaders. If changing to the unlocked bootloader requires physical access (or some such thing), then I could see that working.

Is there anything else I'm missing?

[bigfatkitten]

Secure boot is desirable for a lot of reasons including design protection (stopping your product being cloned), supply chain security, preventing malicious updates etc.

The question is one of how you can hand control to the user without endangering your legitimate commercial interests as well as the security of the rest of the fleet, exactly how you tackle that will depend on the product.

[jcgl]

Don't get me wrong, I like secure boot and securing the boot chain more generally. Was just trying to respond on the merits here.

How would you envision the opt-in process for the unlocked second stage bootloader?

[kogepathic]

> Forcing the release of signing keys would be a security disaster. The first person to grab the expired domain for the auto update server for a IoT device now gets a free botnet.

Have you seen the state of embedded device security? It is already an unmitigated disaster.

Since you bring up botnets, there are far more exploited security vulnerabilities because a vendor EOLed support (or went bankrupt) and their firmware contained bugs that cannot be fixed because a signed firmware is required, or the source code was not provided than because their signing keys were leaked and someone is distributing malicious updates.

> Forcing vendors to release their security mechanisms to the public and allow anyone to sign firmware as the company is not what you want, though.

Yes, it is what I want. I am perfectly aware of the potential downsides and what I am proposing is worth it. The product is already EOL. In our current era of enshittification, vendor pinky promises to implement a user-bypass in their signed boot chain is not good enough. Look at the Other OS controversy on the PS3 if you want an example of this in practice, or Samsung removing bootloader unlocking in their One UI 8.0 update.

> The only real way to make devices securely re-usable with custom firmware requires some explicit steps and action to signal that the user wants to run 3rd-party firmware: A specific button press sequence is enough. You need to require the user to do something explicit to acknowledge that 3rd-party software is being installed, though.

The vendor has implemented an internal pad on the laser-welded, weather sealed, IP-rated smart watch that must be shorted to disable secure boot. Opening the device to access this will essentially destroy it, but we preserved the vendor's secure boot signing keys so missioned accomplished!

[IgorPartola]

But you can still do both. Put a key into escrow that unlocks the device fully, but the key can only be used if the device is physically manipulated. This could mean holding down a button as it boots ups to put it into “enter the unlock key” mode. The mode is useless until the key is published and the key is useless without physical access to the device. And you don’t need to open anything. This could be a purely software thing. As long as you can somehow externally communicate with the device via a button, Bluetooth, Ethernet, etc. you can create a system that would allow this. Hell, you could use a magnet to trigger it.

I agree that devices shouldn’t be locked by the manufacturer AND I think that silently unlocking all devices all at once could do harm.

[Aurornis]

> Have you seen the state of embedded device security? It is already an unmitigated disaster.

If security was an unmitigated disaster on every device then it would be trivial to root them all and install your own software, wouldn’t it?