Having read up a bit more on mokutil, seems that it doesnt enroll the key by itself, but gets the uefi firmware to prompt the user to add the key at next boot. Which in theory gets around the malware risk, although given how many people auto-click accept, maybe not.
The other way keys could be securely installed would be for the distros to produce a uefi “addmykey” binary, with their keys baked in to the binary. They then get that signed by the MS key, which would allow that image to boot and setup the key without ever disabling secureboot. You wouldnt need to have a trusted PC either, as if the binary was tampered, it wouldn’t boot.
100% agree on the risk profile though, far too many people think they are more important than they really are. Realistically, most of us aren’t worth the effort to individually break into our computers.
Having read up a bit more on mokutil, seems that it doesnt enroll the key by itself, but gets the uefi firmware to prompt the user to add the key at next boot. Which in theory gets around the malware risk, although given how many people auto-click accept, maybe not.
They already thought of that. You don’t just hit accept, you then have to type out a password that you set when you run mokutil. So if malware runs it instead, the user just won’t know the password at all.
They then get that signed by the MS key, which would allow that image to boot and setup the key without ever disabling secureboot. You wouldnt need to have a trusted PC either, as if the binary was tampered, it wouldn’t boot.
Yes, that’s exactly how it has worked up until now, more or less. The issue is that the original Microsoft SB key is expiring and old hardware, that’s no longer getting firmware updates by the manufacturer, then the new key isn’t going to be added ever. If those distros had a key included as well, they likely would have made its expiry a lot longer, because they support hardware for a lot longer. Microsoft doesn’t care because Win11 can’t run on most of these devices anyway.
Oh, well, if it requires a password that is pretty much solved. The original commentor made it seem a lot less hands on.
I was under the impression that the shim let OS’s boot all the way up, and that it was just a standard part of the boot process, I was suggesting instead that the signed binary only let’s you add a new key, which you can then use to boot without the shim.
Doesnt help when the key expires though.
Thanks for the additional info, greatly appreciated.
Having read up a bit more on
mokutil, seems that it doesnt enroll the key by itself, but gets the uefi firmware to prompt the user to add the key at next boot. Which in theory gets around the malware risk, although given how many people auto-click accept, maybe not.The other way keys could be securely installed would be for the distros to produce a uefi “addmykey” binary, with their keys baked in to the binary. They then get that signed by the MS key, which would allow that image to boot and setup the key without ever disabling secureboot. You wouldnt need to have a trusted PC either, as if the binary was tampered, it wouldn’t boot.
100% agree on the risk profile though, far too many people think they are more important than they really are. Realistically, most of us aren’t worth the effort to individually break into our computers.
They already thought of that. You don’t just hit accept, you then have to type out a password that you set when you run
mokutil. So if malware runs it instead, the user just won’t know the password at all.Yes, that’s exactly how it has worked up until now, more or less. The issue is that the original Microsoft SB key is expiring and old hardware, that’s no longer getting firmware updates by the manufacturer, then the new key isn’t going to be added ever. If those distros had a key included as well, they likely would have made its expiry a lot longer, because they support hardware for a lot longer. Microsoft doesn’t care because Win11 can’t run on most of these devices anyway.
Oh, well, if it requires a password that is pretty much solved. The original commentor made it seem a lot less hands on.
I was under the impression that the shim let OS’s boot all the way up, and that it was just a standard part of the boot process, I was suggesting instead that the signed binary only let’s you add a new key, which you can then use to boot without the shim.
Doesnt help when the key expires though.
Thanks for the additional info, greatly appreciated.
Ah yeah, I didn’t explain the process fully, my apologies.