Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux and Secure Boot certificate expiration

lwn.net

Post reply on HN
Print view View original

81–90 of 272 posts

Re: Linux and Secure Boot certificate expiration

#81

Post by palata »

vbezhenar wrote: post #76
palata wrote: post #55

[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already] I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly: 1.…

Of course it is possible to use custom keys. At least it was possible on all EFI computers I owned. There are no "manufacturer keys". There's usually an option in BIOS to restore default configuration which resets to MS keys, but you can delete all MS keys. Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys and if you delete MS keys, you might brick your l…

> Now there might be further complications, for example some Lenovo laptops using firmware blobs signed by MS keys

Oh right! Yeah if you want to use custom keys, you need to be able to build and sign your OS, and proprietary firmwares are then a problem. Now I wonder why this is not a problem on Android... Is it because the firmware blobs come from the image that you sign yourself?

Would the solution be that the GPU should load the firmware from the OS?

Re: Linux and Secure Boot certificate expiration

#82

Post by eqvinox »

palata wrote: post #55

[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already] I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly: 1.…

> It sounds like the "manufacturer keys" are always from Microsoft,

The primary key is called "Platform Key" (PK) on UEFI, there can be only one, and it is generated by the mainboard manufacturer, not Microsoft. The PK is then used to sign Key Exchange Keys (KEK) which you will generally have 2…4 of, the Microsoft self-use one, the Microsoft third party one, a board vendor one, and a system/board specific one.

Re: Linux and Secure Boot certificate expiration

#84

Post by serbuvlad »

flexagoon wrote: post #66
ACCount36 wrote: post #49

Earlier quoted context omitted.

Who controls the fucking certs? "My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards. "My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartpho…

> Who controls the fucking certs? Cert authorities, just like in case of SSL. Is SSL also an evil technology designed to take away freedom from the internet? > vendor-selected boot certificates that can't be changed That's a lie. Certain drivers are signed with a specific key, and they can only be used when this key is installed, which makes sense. The same thing happens with SSL - if you remove pre-installed CA cert…

> Is SSL also an evil technology designed to take away freedom from the internet?

If it were not for Let's Encrypt, YES!

Secure boot would not be a problem if it were trivial to enroll keys. Give me a big message like:

"The OS you are trying to run is signed by an unknown key

sha256:whateverthefuck

IF YOU ARE NOT RUNNING AN INSTALLER YOU ARE MOST LIKELY CURRENTLY BEING ATTACKED AND SHOULD NOT PROCEED.

If you are running an installer VERIFY THE KEY with the one your OS vendor gave you.

Proceed? (Add the key as trusted)

yes NO"

Re: Linux and Secure Boot certificate expiration

#85

Post by palata »

eqvinox wrote: post #82
palata wrote: post #55

[Warning: I'm not interested in sarcasm or uninformed rants against secure boot, there are plenty already] I'm hoping to get insights from people who understand secure boot well here. My understanding on Android (for the minority of Android manufacturers that do it correctly) is that there is a "manufacturer key" burnt somewhere on the ROM that cannot ever be changed, and once a first system is installed properly: 1.…

> It sounds like the "manufacturer keys" are always from Microsoft, The primary key is called "Platform Key" (PK) on UEFI, there can be only one, and it is generated by the mainboard manufacturer, not Microsoft. The PK is then used to sign Key Exchange Keys (KEK) which you will generally have 2…4 of, the Microsoft self-use one, the Microsoft third party one, a board vendor one, and a system/board specific one.

And next to those you can load your custom keys?

Re: Linux and Secure Boot certificate expiration

#86

Post by eqvinox »

porridgeraisin wrote: post #45
xiconfjs wrote: post #29

Is there a reliable command in Ubutu to check for the secure boot key and its expiration date?

mokutil Check its various options The 'Validity' field in the output will tell you the expiration date.

mokutil is technically the wrong tool for this, it lists shim-installed machine owner keys (MOK). This is about UEFI-installed key exchange keys (KEK). If you don't know what's going on you'll be very confused about empty key lists. It can in fact show KEKs but you need to know that this is a KEK thing to begin with…

  mokutil --kek | egrep '(Not |Subject:|^[^ ])'
is the magic incantation if you really want to use mokutil

Re: Linux and Secure Boot certificate expiration

#87

Post by zozbot234 »

jeroenhd wrote: post #63
crinkly wrote: post #2

So is it a possibility that a grub update breaks an existing bootable node? That worries me as I have a couple of Linux desktops in the field which I can’t remember if secure boot is enabled on.

If users don't update their keyrings or firmware (through fwupdmgr for instance), Grub will probably stop booting with secure boot on when the certificate expires. If users update Grub once the old certificate is no longer used to sign the bootloader without updating their keyrings or firmware, Grub will probably stop booting with secure boot on when the certificate expires. If users do update their systems and softw…

> Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date.

The article mentions that most motherboards will probably not validate the expiration date. There is a residual concern that new versions of the Shim will not be signed with the expired key, and thus be unbootable on hardware that doesn't accept the new key.

Re: Linux and Secure Boot certificate expiration

#88

Post by zozbot234 »

flexagoon wrote: post #72
porridgeraisin wrote: post #43

Secure boot, disk encryption, etc are more trouble than they are worth IME. I have them all off. Qualifier: for personal computers that you don't take regular backups of, test backups, etc

Secure Boot's benefits are definitely not as strong (I don't think flashing custom backdoored firmware is a common attack vector for personal computers), but FDE is still useful in case your laptop gets stolen, because thieves looking for sensitive data on a hard drive is a thing that does actually happen. I also wouldn't really say it's much trouble. If you have a TPM and use systemd, you can set it up to unlock FDE…

SB does not protect against backdoored firmware at all. You would need something like BootGuard which is a separate feature.

Re: Linux and Secure Boot certificate expiration

#90

Post by eqvinox »

palata wrote: post #85
eqvinox wrote: post #82

Earlier quoted context omitted.

> It sounds like the "manufacturer keys" are always from Microsoft, The primary key is called "Platform Key" (PK) on UEFI, there can be only one, and it is generated by the mainboard manufacturer, not Microsoft. The PK is then used to sign Key Exchange Keys (KEK) which you will generally have 2…4 of, the Microsoft self-use one, the Microsoft third party one, a board vendor one, and a system/board specific one.

And next to those you can load your custom keys?

You need to replace the PK with one of your own, because that is used to sign all the other keys, and generally there can only be one PK. You can then re-sign the existing keys with your own PK (e.g. if you want to dual boot Windows) — or just ditch the existing ones¹, and/or you can generate your own keys of the other types (KEK & DB).

Ed.: ¹ there are cases where ditching the existing keys breaks the system, because the board vendor was stupid and signed the VGA UEFI driver with one of those keys instead of tying it directly into the BIOS/UEFI image. AFAIK this only affects a specific series of Lenovo laptops, but Google the details before breaking your system.

Ed.#2: actually I think the PK signature is only checked while installing keys into the KEK/DB list, so you don't need to re-sign the existing Microsoft keys, they just stay in the list by default. (Unless they got cleared somehow.) It's been a little while since I did this.

Post reply on HN