[eridius]

What you've just described is a completely insecure hardware platform. Giving out a second private key that can still be used to install third-party updates is just as insecure as giving out their normal private key, the only real difference is if anyone actually looks at the code signature they can tell the difference between third-party and first-party code. Allowing the user to lock out that second key doesn't fix anything because 99.99% of users will never do that, or even know it exists.

> If Apple is behaving that way, it's Apple's own fault, not the GPLv3's. They could have chosen to design their software in a way that would have given them better options if they are ever forced to comply with the GPLv3, but they chose not to.

That makes no sense. What you said is basically equivalent to "That's Apple's fault, they could have just designed their hardware platform to be completely insecure".

GPLv3 is fundamentally incompatible with having a secure hardware platform. This is absolutely GPLv3's fault.

[dTal]

>GPLv3 is fundamentally incompatible with having a secure hardware platform

That's funny because Chromebooks ship with GPLv3 code.

[eridius]

I'm not familiar with the security model of Chromebooks. How does it work?

[dTal]

Out of the box, they only accept Google OS updates. For reference, the OS is basically Gentoo+Chrome.

If you've a mind to, you can put the Chromebook in "developer mode" with a magic sequence of commands (requiring physical access as it's a boot procedure). This gives you root. To protect naive users from being exploited, a Chromebook in developer mode will display a nasty warning on boot. This warning lingers on the screen for an annoying amount of time, accompanied by a beep. The only way (and it's undocumented) of skipping the wait and the beep is with Ctrl-D; pressing any other key while on this screen results in the Chromebook being completely reset. All this is to ensure that it's virtually impossible to run under developer mode unintentionally.

If all this gets too annoying and you want to use the Chromebook as a fully general device, you can blow it away by replacing the bootloader. Doing this requires disabling write-protection on the flash, which requires opening the case.

Disclaimer: I own a Samsung ARM Chromebook. For all I know the precise details may vary across the Chromebook line, though I believe they all work similarly. Fuller details are here: https://www.chromium.org/chromium-os/developer-information-f...

[eridius]

Interesting, but from your description it sounds like if I can get my hands on someone else's Chromebook I can still put it into developer mode and install my own software on it, right? Sure, this mostly prevents someone from using a Chromebook that someone else installed malicious software on, though if that other person had time to open the case they could even get around that. But this doesn't solve the case of I have a device with private info on it, you get the device, and want to bypass the security measures on the device to get at my data. Or in other words, it doesn't solve the situation seen in the recent Apple vs FBI case.

[gherkin0]

> Allowing the user to lock out that second key doesn't fix anything because 99.99% of users will never do that, or even know it exists.

That's easily solved: On initial device setup, the user could be asked to explicitly disable the key by asking something like "Would you like to secure your device by permanently disallowing the installation of untrusted software? Y/N"

Also, as someone else clarified below, the alternate key I was proposing is unique to the device. So any attack against you would have to be tailored to your device. That leaves the main threats as: 1) an NSA-like shipment-interception and 2) someone getting access to your user key after the device is in your possession. 1) can be mitigated by buying your device in a random retail shop, and 2) can be prevented by immediately permanently clearing the user the key.

[dTal]

Now you have a number of thorny design decisions.

For example, can the user change their own key? If yes, the device can never be trusted second-hand - the OS might have been modified to secretly accept more keys. If no, then the device also can never be trusted second-hand - the previous owner could well have retained the key. And which key is superior, the manufacturer key or the user key? Can the possessor of a key override actions attempted using the other key?

Also, as written, this is just a bad solution. So you ask the user on initial setup. Let's say 99% of users won't know what the question is asking. So maybe they hit "yes", and now we're just back to iPhones and no user freedom, for them or any subsequent device owners. Or maybe they hit "no", and now they're no more secure and there was really no point in asking them. Maybe it's a 50-50 split, depending on how they feel (and not related to how they would choose given informed consent). Or maybe the user is informed, in which case they are very likely to just hit "no", if for no other reason than to preserve the resale value.

Don't get me wrong, I do think this could be done right. But attempting to guarantee "security" (that is, the dubious sort of security that is manufacturer-only updates) to naive users, freedom to power users, and preserve those guarantees as the device changes hands... well, that's a Hard Problem. I think only Chromebooks have attempted it so far.

[gherkin0]

> If yes, the device can never be trusted second-hand - the OS might have been modified to secretly accept more keys.

That's always going to be a risk with second-hand devices (or even new devices). Who knows what kind sneaky things someone did to a device that they had long-term access to. You can never really totally trust something that you didn't build yourself from the ground up, so you always have to accept some level of risk.

That UI solution was just a random idea, I'm sure there are better ones. Like you said, it's a Hard Problem.

[malka]

Each user would get its own private key that could only be used on its own device. It could not be used to sign software for someone else device

[eridius]

Hmm, that's actually the first suggestion I've heard that's at least technically workable, though it's pretty darn impractical to do at any kind of scale.

[gherkin0]

> though it's pretty darn impractical to do at any kind of scale.

How so? It's a solved problem. Don't smartphones already have numerous device-specific identifiers and keys loaded to them? All they would really need to do is slap an extra sticker on the device with the device-specific key printed on it. For instance, my phone came with a sticker with its IMEI printed on it.

[eridius]

IMEI can be recovered once you throw the sticker away. A private key that can be used to install new software cannot be recovered, or if it can that's a huge security risk.

[gherkin0]

The device should not have the private key loaded onto it at all, just the corresponding public key. The private key would only exist on the sticker and thus be unrecoverable if you threw it out or destroyed it.

The IMEI example was just to demonstrate the ability to slap a device-unique code + matching sticker on something during manufacturing at scale.

[eridius]

Slapping stickers on something is not a scaling issue. The secure storage and transmission of private keys is. The idea that you'd just slap the private key on a sticker and have no other record of it is not something I even considered because that's very user-hostile behavior (unless they already have the intention to mod the device software before they buy it, they're unlikely to retain the sticker). It also screws with the secondhand market, both because secondhand devices won't have their key, and because the original owner obviously had access to the key and could have tampered with the software on the device before selling it.

[dTal]

As I mentioned in another comment in this thread, it is already done for randomized administrator and wifi passwords in consumer routers.

[jordigh]

Actually, I think Apple is already more or less compliant with this part of GPLv3, as they allow developers to self-sign the software, right? You just have to pay for a self-signing key. That's sufficient, because it means you can run modified software. All they have to do is lift the restriction to pay for the self-signing key.

[eridius]

I'm talking about the OS here. But the App Store is also incompatible with GPLv3 and GPLv2 for other reasons.