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.

▲

Retr0id 8 hours ago | parent | next [-]

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

▲

jcgl 29 minutes ago | parent [-]

…how do the updates get booted then?

	▲	bigfatkitten 15 minutes ago \| parent [-]
		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 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/

▲

kogepathic 8 hours ago | parent | prev [-]

> 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 6 hours ago \| parent \| next [-]
		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 3 hours ago \| parent \| prev [-]
		> 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?