Hacker News new | past | comments | ask | show | jobs | submit login
The Keys to the Kingdom (acm.org)
45 points by zacwest on March 23, 2022 | hide | past | favorite | 18 comments



IMO, companies that build tivoized devices like these deserve to go out of business. This whole thing would have been a non-issue if they wouldn't have attempted to restrict the end-user in the first place.


I like the approach of Google Chromebooks. You can set up your own keys and chain of trust from day 1. Of course, then you are on your own.


That's a nice absolutist stance to take on the Internet, but it doesn't really work in the real world.

In any security-conscious environment, allowing updates without signature is not a winning move. You have to account for unauthorized access attempts somehow, and signed updates are a pretty standard way to do that.

And if you have signed updates, all the openness in the world doesn't help you with a lost key.


"Allowing updates without signature" isn't the same as forbidding the owner from applying updates. Whoever buys a device has the right to decide what updates are applied to the device. This isn't incompatible with requiring signed updates. It is incompatible with the manufacturer being the holder of the private keys, and rightly so, as having the ability to modify the running code is the true definition of hardware ownership.


"This client builds embedded devices found in offices around the world. [...] These devices are driven by firmware running on a microcontroller that delivers robust wireless communications"

Roughly none of the clients buying that kind of hardware want to install their own code. Come off your high horse - turnkey solutions are desirable for a large number of devices. And "hardware ownership" is not a sufficient enough proxy to allow firmware updates. Anybody in an office standing next to the device can exert physical ownership, and that's exactly the case you want to prevent.


Physical access is not ownership. A turnkey solution can provide reasonable defaults, along with the information needed to assert ownership and override those defaults.


> Anybody in an office standing next to the device can exert physical ownership, and that's exactly the case you want to prevent.

You mean like with a user/owner-set password? The kind you use to unlock your computer at startup?

Why is it any time manufacturer lockdown solves a security issue, people rush to pretend that only manufacturer lockdown can solve it, even when user-freedom-respecting solutions to the same issue are not only possible, but widely used and predate the lockdown solution?


I'm not advocating for "allowing updates without signature". I just want the owner of the device to be in control of which keys it will trust signed updates from, rather than only the manufacturer having that control.


There's not even a hint as to what the device actually was, but I guarantee "the right security features" were about protecting intellectual product, device lifespan control, and likely locking the customer into some completely stupid and unnecessary "cloud" management function. Not the customer's security.


If you're selling a computer, sure. If you're selling an appliance that happens to be implemented using a computer underneath, even RMS would say it's fine for the manufacturer to control the code.


Such as a printer?


I would think so; he wanted the source for the printer driver (i.e. the program that ran on his general-purpose computer), not the printer firmware.



Interesting; I would rather say it suggests the FSF has had some scope creep in the intervening years, but your point is taken.


Hopefully, he also patched some portion of the bug that let him rewrite the bootloader signature verification code... or someone else only has to look at your update to have their own keys to the kingdom.

One should also be sure that the signature verification is not based on simply an obscured symmetric key that easily allows key extraction and any code to be rewritten to those devices in the future once it is extracted. One assumes from his solution this isn't the case (or he'd only need one sample to get the key). You don't HAVE to do public/private keys, but it's the most convenient.


> Hopefully, he also patched some portion of the bug that let him rewrite the bootloader signature verification code... or someone else only has to look at your update to have their own keys to the kingdom.

Sounds like it from the article.

> The new firmware release also included fixes for these bugs.


I guess $10 for a couple of USB drives to store the signing key, to be placed into a safe in someone's house (or a bank) was out of the question?


I was once responsible for a private key of big operational value, and I printed it out, put it in an envelope and gave it to the CFO to hold.

It's not rocket science.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: