The Unclear Impact

gpl, licensing

sure wish gplv3 and derivatives weren't trash for secure boot on embedded systems

gpl, licensing

@jookia huh, I assume this is something to do with the tivoization clause?

gpl, licensing

@jookia What are the problems, besides the usual issues with the GPL?

gpl, licensing

like in completely get it but also you can't disable secure boot on embedded devices

gpl, licensing

@jookia I'm not sure I get that connection.

Also, there are embedded devices where you can choose to not use secure boot.

So now I'm doubly confused.

gpl, licensing

@anahata bit of a loaded question ;) gplv3 requires allowing users to replace a program with a modified version- this doesn't work with secure boot that can't be disabled

gpl, licensing

@a_breakin_glass yep. you can't replace secure boot bootloaders

gpl, licensing

@jens you can't ship gplv3 software if secure boot means users can't replace it

gpl, licensing

@jookia Ah, my mistake, I had mentally transposed secure boot and coreboot in my mind when reading this. Sorry!

gpl, licensing

@jookia thanks!

The issue is easily solved. Publish a signing key that the boot software accepts, but perhaps warns about.

gpl, licensing

@jens That's not really possible in the microcontrollers I've seen. One signing key allowed.

gpl, licensing

@jookia Huh, you probably have more experience with smaller/more embedded devices than me, then.

The one where were dealing with secure boot right now is the layerscape 1012A, specifically the grapeboards. It appears you can manage keys fairly flexibly there.

gpl, licensing

@jens the line i'm thinking of atm is the STM32 series

looking at https://github.com/ms-iot/lsdk/blob/master/docs/grapeboard_secureboot.md it looks like there's one security key for secure boot?

gpl, licensing

@jookia there's one master key, yes. If you make a key signed by the master key public, that would permit for users to run their own SW, whilst official builds use other keys signed by the master key.

My best understanding at the moment is that there's support for such a signature chain.

gpl, licensing

@jens ah. that could work. the other issue is if the device holds secrets from the user, which is kind of anti-user- but it can also prevent malware by other users

re: gpl, licensing

@jookia @jens Having a signed key with a publicly known private key doesn’t sound ideal, because malware authors could also use it. If it’s enabled by default, everyone is vulnerable. But even if you have to opt-in to booting custom signed firmware, hacking your device would mean losing nearly all security benefits.

Could the solution be to give the user a way to replace the signing key in the device with their own? Guess that’s not possible when the master key is fused in.

A solution like plugging in a security token on first boot and fusing the SecureBoot key to it (would this be possible with FIDO2, or would you need a full-blown smart card for it?) sounds nice for advanced users, but the tradeoffs for anyone not wanting to hack the firmware (impossible to do an unattended update, can’t update if the token is damaged) are quite bad. Also, there would be the problem of obsolescence (I can’t give away my used device to someone if they can’t use it without my private key).

replies
0
announces
0
likes
2

re: gpl, licensing

@kristof @jens like there's kind of a clear and intentional solution here: a shim bootloader that handles all this. but it can't be gplv3 because users can't replace it.

re: gpl, licensing

@kristof @jookia In my line of thinking, that's just key management. But you're right, of course! You can have a signing service, but if that's gated it's a problem.

The token thing seems like a different flavour of the same, or I didn't get it.

re: gpl, licensing

@jens @kristof

the other conflict of interest i see is that the gplv3 wants any user who has a copy of the software to be able to replace it without altering functionality

so someone i sell a gplv3 crypto key device to that i forget to wipe could install a key dumper

i believe its written this way to avoid blanket factory reset modes that lock you out of proprietary functionality, but it also hits this use case

there's no protection of user data

re: gpl, licensing

@jens @jookia The token idea comes from the “re-ownership” process for secure devices, like the Insurgo PrivacyBeast. Basically, the user provides their own keys (from some secure element), which get added to the hardware without any shim. Of course, if the master key lives in write-once memory (I don’t know whether this is the case for the Grapeboard, but the linked docs seem to talk about fuses in this context), it’s not a “re-ownership”, but an “ownership” process. Basically, the user would provide the secure element on first boot, which generates a key pair, and the public part would get written into the write-once memory.

This could solve the “keeping secrets from the user” part (there’s no shim; the user can verify that the secure element has indeed generated a new key pair, and firmware signed with the generated key can indeed boot on the device) without any centralized key management, but doesn’t solve the “giving the device away with the key” part of the problem.

re: gpl, licensing

@kristof @jookia It's a good idea.

The fuse is pretty specific: you can modify keys in the on-board secure element as much as you like *until* you trigger the fuse.

From a solution vendor point of you, you sort of want to put your keys on there and then trigger the fuse, so that you can guarantee to your customers that only verified firmware will run. For non-GPL points of view, this is a powerful argument.

re: gpl, licensing

@kristof @jookia This token works in allowing these customers some measure of control, and also opens the device for users who never care about official firmware.

But in order to provide similar kinds of guarantees, the solution vendor would have to validate the firmware and sign it as well, which is effort (validating modified firmware) that doesn't seem likely to be offered.

re: gpl, licensing

@kristof @jookia So the boot process is actually a little more complex, because the device first boots into coreboot, and the coreboot image can be signed and verified.

Next, the device can side-load some firmware blobs, which are signed by the vendor.

Then you can separately sign the kernel/boot image and root fs.

So there is e.g. the ability for some parts to be verified by the vendor, and some modified by the user, *as long as*. And it's quite possible to add an app fs.

re: gpl, licensing

@kristof @jookia Sorry, bad edit: as long as there are keys for each signing authority.

It would be possible for the vendor to provide *some* guarantees, but not all in this way.

gpl, licensing

@jookia So you need to provide a way for users to import their own key, or provide a shim. That’s great for user freedom. E.g. Chromebooks and Pixel phones solve this nicely.

gpl, licensing

@jookia @jens I think STM32 doesn’t have secure boot, but their “write but not read back” flash for code. You can flash something implementing secure boot in there, of course. But I’ve never seen an STM32 that does secure boot from the factory.

gpl, licensing

@js @jens a lot of stm32 does secure boots. the shim can't be GPLv3

gpl, licensing

@jookia @jens Of course it can be GPL3. E.g. you could read a pin to check whether secure boot is enabled or not. That would allow users to change it when they just solder a specific pin to ground.

gpl, licensing

@js @jens users couldn't replace the stub with their own, and you can't disable secure boot using pins

gpl, licensing

@js @jens

secure boot on microcontrollers tends to work like this:

1. you generate a key
2. you burn that key in to the device
3. you burn the setting and disable booting non-authenticated boot images

whatever gets booted, even if it's a shim that allows booting anything down the track, has to be signed by the key. there's no ways for users to run their own shim

gpl, licensing

@jookia @jens The STM32 I had were all factory resettable via SWD. What do you have?

gpl, licensing

@js @jens stm32mp1but the same process is true for some of their microcontrollers.

are you arguing with me over shims can be GPL3 or whether stm32 doens't provide resettable secure boot?