Linux and Secure Boot certificate expiration
lwn.net
lwn.net
It’s absolutely a minor “hey btw the certificate expired, check for an update” yet various systems treat certificate expiration as an end of the world lock it down scenario.
Sounds like a cleaner solution than any of the ones in the article too!
It's much more likely that someone will write a driver that adds an offset to the clock, keeping the hw date in a safe range.
Code signing certificates are trending down in length. Ot recently dropped down from a max of 39 months to about 15 months.
If however you have an expiry of multiple years you clearly have no reason to have an expiry date at all. You can't possibly justify a security benefit, imagine reassuring people with "the stolen certificate is only valid for a few years!"
As in it was clearly a mistake to have an expiry date at all for this use case and the multi-year expiry date should have been a smell that tipped people off and made them ask "why do we have an expiry date at all for this?".
With expiry dates, at least the pool of places you can break into to steal certificate signing keys isn't growing without bound.
If the resulting key works indefinitely, the expiration date on my signing key is utterly meaningless.
Microsoft's Authenticode has been doing this for a long time, allowing a signature to be considered as valid long after the signing certificate expired.
https://learn.microsoft.com/en-us/windows/win32/seccrypto/ti...
A different model would be to only allow a given EFI binary to be booted if it was installed before the deadline, but that might well have a different set of complications.
Lenovo, in their infinite wisdom, has decided to load an Nvidia blob signed by Microsoft before even being able to access the UEFI firmware interface. People who have tried to install their own secure boot keys found out the hard way that you can't even get into the firmware configuration interface to undo the change.
Their official workaround is to only load secure boot keys through their firmware interface (rather than the standard Linux utility) which refuses to wipe the certificate used to sign the Nvidia firmware. However, that workaround will obviously stop working when that certificate expires.
For your current laptop, you might be able to use the `--tpm-eventlog` to `sbctl enroll-keys` to enroll hashes of your OptionROM to whitelist that blob.
https://support.microsoft.com/en-us/topic/windows-secure-boo...
https://techcommunity.microsoft.com/blog/windows-itpro-blog/...
Really it seems like having any expiry date for these certificates is a mistake. The one thing it might protect against is a compromised signing key, but if you have to wait 15 years for a compromised key to stop being valid, it's not very useful!
Don't worry, the replacement MS certs expire in 2038 (a couple of months after the 32-bit unix time rollover).
It certainly wouldn't be the first evidence of that…
And of course, it gives the root certificate issuer enormous amount of power as well, good riddance from the POV of Microsoft.
However, I think if Microsoft REALLY care about security, they should not let application installed on their system to do anything that is unapproved by the user (such as installing a virus that encrypts all their data), which could actually enhance the user experience and security. But, with secure boot, at least you can be sure that your Windows kernel is not tampered so it can serve the virus correctly :)
Is Microsoft REALLY cares about security, they should fix their bugs and not make "new features" at every release.
In theory a KEK update will fix the expiry issue just like a CA package update on any normal operating system will do.
In practice, most UEFI firmware is written like trash, unmaintained, and mostly untested.
In my opinion the system firmware should do the absolute minimum possible. Find a piece of data somewhere that the processor can start executing, like in the BIOS days where it would just load in the first 512 bytes and start running that. Anything else like hardware configuration, power management, etc... should be left to the operating system.
That explains a lot. Was EFI also part of the strategy to destroy alternative architectures, like Itanium was ?
As a result, many of these devices are buggy, insecure & are never updated once shipped or updates get abandoned soon after.
You can flash all kinds of alternative firmwares to many motherboards if you know where to look, but those firmwares often end up reimplementing everything UEFI does to get an operating system to work in the first place. Some firmware distributions even use a full Linux kernel as a UEFI replacement.
I'll take UEFI over BIOS any time if only because it finally solved dual booting.
Wait, what? Did this thing at least have the courtesy to check that you were indeed booting Windows or would you just get random crashes if you tried to use the mainboard(!) with any other OS?
This stuff seems inches away from a supply chain attack.
It's more that Microsoft would read & execute a binary from a specific place in memory, allowing companies to maintain persistence / ensure their drivers are always installed / ...
With the BIOS i didn't needed to reinstall the bootloader every time i updated my BIOS. And also it was not updated every 2 months , like current UEFI.
The only thing a firmware really needs to is A) initialize RAM, B) initialize a display or serial port for boot comms, and C) load an OS. Anything else modern firmware does would be better as normal devices controlled by OS drivers without the ACPI/UEFI layer.
A third thing: it is of course super convenient if firmware provides some way to reliably identify the platform and provide data on devices that aren't connected to discoverable buses (such as bus controllers themselves), but even that's not really required. Linux lets you build a devicetree as part of the kernel.
And it's absolutely awful as an end user if you have anything even slightly unusual.
This issue only affects the people who don't want to bother being the root of trust.
Well-written firmware doesn't need to be updated for the key database to get updated. However, some vendors messed up and now require firmware updates, while others simply store the new key in NVRAM.
"New CPU needs a new software" shouldn't be an excuse to just let CPUs becoming its own computer with the real CPU you're paying for as one of many features. That's just fundamentally wrong.
Modern computers are distributed systems of components. Each component has its own cpu and OS running in firmware. And they talk over the system bus.
With the kind of penny-pinching that happens with NVRAM storage on boards like these, being able to reduce the size of CRLs can make a difference.
Idle thought - wonder if there are perfect hash-like constructions they could use for revoked certificate lists.
Another potential use is to facilitate managed deprecation of obsolete crypto functions / protocols / hash suites / etc.
That fits pretty well with a 10 year rotation period, and is probably more valuable in the long term than minimising DBX size.
Especially when most relevant attacks occur in the scenario where attacker has control over the system clock.
I've had to disable it on all my installations because of either nvidia drivers or virtual box modules. In general Arch based distros didn't seem too friendly for secure boot set up.
Fine for systems you physically manage, anything remote in a datacenter I wouldn't bother (without external motivation)
I hesitate based on that mitigation and the untold operational pain. Sometimes it's worth it, other times it isn't.
1. You can sign and verify initramfs, it's supported by bootloaders.
2. You can merge kernel and initramfs into UKI and sign the whole image.
I don't know why that's not implemented.
There was some systemd work on a spec for a boot partition to extend the efi partition for storing kernel images and initramfs, but I don't think any distro currently defaults to it on.
I think hibernation is currently also broken, since the hibernation file is stored unencrypted by default and thus can't be used with secure boot.
One of the ways you can introduce your own signing key is as a Machine Owner Key, using the "MOK Manager"
But a design goal of this software was: We don't want malware with root to be able to introduce a MOK without the user's consent, as then the malware could sign itself. So "MOK Manager" was deliberately designed to require keyboard-and-mouse interaction, early in boot before the network has been brought up.
Of course if your server has a KVM attached, you can still do this remotely, I guess.
The laptops I have gotten from eg Dell with Linux pre installed have just worked. Machines I have upgraded through many versions of Ubuntu (lts versions of 16-24) were weirdly broken for a while when I first turned secure boot on while I figured it out, but that seemed reasonable for such a pathological case. Machines I have installed Debian on in the last few years have been fine, except for some problems when I was booting from a software raid array, but that is because I was using 2 identical drives and I kept getting them confused in the UEFI boot configuration.
I have not used them on machines with nvidia, vbox, or other out-of kernel-tree modules though.
Still on Windows only for kids games. Linux user since last millennium.
I couldn't get it to run via Proton/Wine at all.
We do use Kubuntu for games that run in it without drama - Risk of Rain, Roblox (via Sober), browser games, CS2.
They also are expected to use Microsoft Office for school (UK), it's possible to work that online, but the experience is worse, slower, more prone to issues it seems.
Fwiw, I've been a Linux distro user for decades and was Linux only until the first child got to highschool. Microsoft's "educational" policy works for them!
IIRC the last time this happened it was the fault of Linux distros not updating their packages, it was just a Microsoft update updating the security requirements that affected distros that were caught slacking.
I know it's the norm to bash Microsoft and they do a lot of crappy things, but in this case it was just certain distros not taking security updates seriously, which is why a lot never broke (such as Fedora)
If you use a major distro like Ubuntu, you might find Secure Boot works out-of-the-box, with no need to dick about with 'machine owner keys' and suchlike.
Ubuntu has packages like "linux-modules-nvidia-550-generic" containing a version of nvidia's 550 drivers signed with canonical's keys. If the stars align and that package gets installed, you'll have nvidia drivers that work under secure boot.
They also have a second mechanism. You can set up a 'machine owner key' (MOK) then software updates will trigger automatically building new nvidia kernel modules, using 'dkms' then sign them with the MOK allowing them to work under secure boot.
The problem is this process can be a bit wonky. The MOK setup process involves rebooting and going through the "MOK Manager", an interface that looks like something from the 1980s. If you didn't know to expect it, or what it's there for, or you don't speak English, it's easy to hit the wrong thing and not set up your MOK. And it only shows up for a single boot, unless you know an arcane terminal command.
And if you run into any problems during the setup process - you're going to be researching the fix on your phone, because your PC isn't booting.
Meanwhile, the third option of just turning off secure boot is easy (assuming you know what the BIOS is) and it works every time. So a lot of 'how to set up nvidia drivers' guides just recommend doing that.
Although I complain about it, I find it impressive things like dynamically compiling and signing kernel modules works as well as it does - especially as so much of it is maintained by volunteers, selflessly giving up their free time when they could have simply turned off secure boot in their BIOS too.
If properly set up the only files you generate are:
- /efi/loader/random-seed
- /efi/EFI/Linux/arch-linux.efi
- /efi/EFI/Linux/arch-linux-fallback.efi
and the .efi are all automatically signed by hooks.
You can even skip a bootloader and boot the images directly.
Most of the guides focus on creating the PK, KEK, and db certs for enrolling/updating certs from userspace with signed .auth files but that is kind of pointless and seriously over-complicates it. I just created a 20-year db key pair with openssl (and PK and KEK just to make sbctl happy due to a bug), then installed the public db cert into the UEFI manually via the ESP. Didn't even need to use setup mode, although I suspended BitLocker on the Windows partition to let it reseal its key with the new PCR 7 measurement after the db update.
To finish securing it I have a separate key for PK and KEK and have already installed Microsoft's 2023 UEFI certs in the db (and added the 2011 cert to dbx with the updated bootmgr).
Windows 10 and then 11
What Linux is really lacking is a user-friendly method for enrolling your own keys, which would instantly solve all the Nvidia/firmware updater/custom bootloader problems. The command line tools are slowly getting easier to use, but there's no guided instruction flow.
Seems disabling these "features" is nearly impossible as well.
[1] https://en.m.wikipedia.org/wiki/Intel_Management_Engine
[2] https://en.m.wikipedia.org/wiki/AMD_Platform_Security_Proces...
Note sbctl is one of the easier tools to do this.
“Just” is doing a lot of heavy lifting in that solution.
https://wiki.archlinux.org/title/Unified_Extensible_Firmware...
So, believing this is very, very hard.
How the hell did we get ourselves into this situation? After Microsoft spent years secretly threatening people with lawsuits for running Samba and Linux VFAT, and describing open source as "cancer"?
I'd argue that it only helps check a tick box on corporate security manifest, as it indicates the kernel being booted, is not tampered with.
You can keep the Microsoft keys in there if you want to dual boot Windows, you just need to re-sign the keys themselves with your own PK.
If you want to be clean on "a moral basis", whatever that means, the FSF would have to create their own hardware standard and persuade OEMs to adhere to it. Good luck.
Just wondering what the technical reason would be that Microsoft had to control the whole of the PC??
Surely, the control of the boot environment and any the the boot shims could have been restricted to system that could boot out of said shim. Then the two worlds could have securely co-existed could they not ?
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 software, Grub will keep working.
Not updating is not a solution, unless the motherboard manufacturer really fucked up and doesn't validate the expiration date.
Luckily, fwupdmgr is integrated in the GUI updater tool on just about any Linux distro I know. As long as users don't ignore the "there are system updates available" popup and as long as the desktop vendor put out bare basic software support, things will probably go down fine.
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.
Qualifier: for personal computers that you don't take regular backups of, test backups, etc
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 automatically on boot, otherwise, you just have to input an extra password when turning on your machine.
My understanding is that at least on Android you can't modify the system: you have to format everything if you want to make a change at this level.
I don't understand that sentence. So instead of a bootloader in the ROM that starts the next bootloader and verifies that it is signed (I think that's how it is on Android?), on a laptop the first bootloader can be installed by the user and nothing checks its signature?
EDIT: what I read here [1] is that Secure Boot is verified from the ROM to the moment it starts "the Windows kernel" (on Windows). But it's not completely clear to me: say on Linux, if Secure Boot verifies up to my /boot partition (does it?), then it should be okay because I have FDE on the rest, right?
[1]: https://learn.microsoft.com/en-us/windows/security/operating...
It should be signed by the manufacturer, so you shouldn't be able to. Loaded by a shim even smaller in the CPU, part of Boot Guard and Platform Secure Boot, if I'm not remembering wrong.
> say on Linux, if Secure Boot verifies up to my /boot partition (does it?)
No. It verifies one signed file, usually Grub EFI shim. Which then should check everything you want. Unlike Windows, desktop Linux distros rarely have the best SB system. Poettering has described this issue in depth.
I presume words like "Crowdstrike" or "Microsoft Update" don't say anything to you. /s
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 is impossible to overwrite the system partitions unless the bootloader is unlocked from the already-installed OS (I assume that something makes sure that only the signed OS can unlock the bootloader?).
2. Once the bootloader is unlocked, it is impossible to overwrite only parts of the system: it's all or nothing, such that one cannot inject stuff into an existing system (evil maid style).
Still on Android, it's possible to add custom keys. That's what GrapheneOS and the likes use.
How is it on UEFI? It sounds like the "manufacturer keys" are always from Microsoft, but is there not a way to use custom keys?
AFAIK, that depends on the hardware used. Google Pixels allow it, but it's not universally permitted. Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
You're right! That's what I mentioned the few manufacturers who do it correctly. GrapheneOS only supports Pixels for other reasons than that. CalyxOS supports other devices (one constraint being to be able to relock the bootloader). /e/OS doesn't seem care so much about the secure boot.
> Plenty of stories can be found on XDA where people tried to lock their bootloader that bricked their phone.
That raises a question: what is the point of relocking the bootloader? If overwriting the keys means that the whole system will be formatted, then I don't see why it should ever be prevented at all? If an evil maid wants me to lose my data, they can leave with the laptop, right?
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 laptop, because GPU won't start anymore. That said, I'm using Lenovo Thinkpad T14s Gen4 Intel right now with all keys deleted and my custom key added and it works just fine. May be it's AMD issue.
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?
Then your motherboard firmware will be able to load your GPU and other third party blobs to UEFI memory. Similarly OSes like Linux and Windows enforce the same chain of trust (they don't have to but otherwise it is not really secure, just like a website can lie to you about encrypted storage) so you need your drivers/OS loaded firmware to be signed as well.
What Android does and what UEFI does are not really related. It is like comparing how SSH does authentication vs how HTTP with TLS does. Former is a SSH-specific open-ended implementation detail, latter is standardized by IETF.
Similarly UEFI standardizes how a motherboard manufacturer can write a compatible firmware and Secure Boot (capital letters) is a sub specification of UEFI. It is not the only secure boot implementation scheme.
With Android device manufacturers have complete control over the early boot firmware and the OS. As long as they boot the OS to run apps, how they do it is up to them. Only things like Google's SafetyNet will put certain requirements on them. No standard like UEFI exists in Android phone world or anywhere else except PCs / Servers.
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.
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.
The FUD that gets spread around SB helps no one, and other than a small list of exceptions, you are always in control of your system.
SB allows MS to transparently enable Full Disk Encryption by default, which I think is a win for all users. It allows you to do the same on Linux. It lets server operators be sure their systems have not been tampered with. While there are many problems with UEFI, SB is not one of them.
[1] https://discuss.privacyguides.net/t/grapheneos-is-taking-act...
EU mandates any hardware sold will only boot software signed by EU private key, with signatures only provided to software including government spyware and passing a billion euro certification process.
"No not like that!"
AFAICT you can still disable Secure Boot in most UEFI firmware, and boot anything you like (or not like, if an attacker tampers with your system).
"attacker tampers with your system" does not happen at least in the way you think it does or it does not protect you against meaningful attack at all.
On Windows, secure boot has worked pretty well when it comes to rootkits. MBR rootkits were trivial to write, but UEFI rootkits require UEFI firmware changes or exploiting the bootloader process itself, both of which are much more complex. If malware uses the Linux shim, the TPM will notice and refuse to provide the Bitlocker key, so your computer won't boot without going to the IT office and asking for the recovery key (which should prompt more investigation).
Boot sector viruses, or their modern equivalents. Basically, anything which injects itself into the boot chain before the antivirus can start; after that point, the antivirus is supposed to be able to stop any malware. That is, they wanted to prevent malware from being able to hide from the antivirus by loading before it.
The firmware validates the shim. The shim validates the boot loader. The boot loader validates the kernel. The kernel validates the kernel modules.
Once you have that chain of trust, you can also add in other factors; encrypt your disk using a key, seal the key in the TPM, and lock that key behind validation of the firmware and the boot loader. Your system boots, those different components are measured into the PCRs, and if the combination is correct the key is released and your disk can be decrypted automatically. Now if someone boots your system using a different firmware or boot loader, the TPM won't release the key, and your disk can't be decrypted except by someone with the passphrase, recovery key, etc.
Without secure boot, you can't trust that any of those components aren't reporting falsified measurements to the PCRs, lying to the TPM, and getting access to the key to decyrpt your disk despite booting from a compromised USB drive. That, of course, means you can just encrypt your disk using only a passphrase that you manually enter, but for a lot of users (sadly) that's too complex and they'll choose not to use disk encryption at all.
Case in point, TouchID and FaceID are seen as alternatives to using a PIN or passphrase to unlock your iPhone, but they're actually meant as alternatives to not locking your phone at all - a way to make device security transparent enough that everyone will use it. Without a secure chain of trust from the firmware to the kernel, that's not really an option.
The more realistic scenario would be exploiting a privilege escalation bug. Of which there have been and will be plenty of on both Windows and Linux.
Honestly I wish they(where they is them that designed this whole broken system) did it it right. On first boot you would set up some keys, now you are your own trust root, and when you you want Microsoft to manage your system, perfectly reasonable, managing systems is scary, you sign their keys and add them to the store. The problem is at a low level it all sort of just works, but nobody want to design that user interface. nobody wants to write the documentation required to explain it to joe random user. Nobody wants to run the call center dealing 24/7 walking people through a complicated process, patiently getting them unstuck when they loose their keys, explaining what a trust root is and why they now have to jump through hoops to set one up.
I like to believe that had they done it right initially, the ui would have been molded into something that just works and the client base would also get molded into expecting these key generations steps. But I am also an optimist, so perhaps not and it is exactly as scary and thankless a task as I described above. But we will never know, Microsoft took the easy way out, said we will hold the keys. And now you are a serf on your own machine. Theoretically there is a method to install your own keys, and it may even work, but the process is awkward(never really being meant for mass use) and you are dependent on the vendor to care enough to enable it. Many don't.
Microsoft showed they can semi-competently run a PKI. The end.
Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
Not out of malice, necessarily, but at least incompetence.
Likewise, having Microsoft signing the shim also means that any Linux installation with the signed shim can install on any system that supports Windows, whereas if RedHat had their own 100% comptent, rock-star PKI then a huge proportion of systems sold today would not be able to run Linux unmodified because the manufacturers wouldn't bother.
No. See certificate expiration.
MS uses three separate CA's to sign Windows boot loaders, third party bootloaders (including Linux bootloaders) and UEFI Option ROMs.
In theory, no manufacturer has to install all three as trusted. But it makes no business sense to do so - why have two separate hardware SKUs for the sole purpose of lock-in? Once word got out no one would buy from that manufacturer.
Reminds me back in the day some vendors of Win 9x systems put something in the BIOS to prevent one from installing NT/2000. Gotta get the corporate model for that.
This kind of victim blaming gets annoying very quick, as if the Linux ecosystem had any leverage at all on PC manufacturers…
Linux has 63% of the server marketshare, which is where Secure Boot and the whole chain-of-trust has utmost importance. Of course they have leverage.
Do you think overall Secure Boot is more important in the context of securing your bank's servers, or some porno jack machine throwaway laptop?
I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not.
the promise of secure boot and trusted computing is backdoor-free boot.
what is in your eyes evil and garbage about that?
"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 smartphone, gaming console, car, and even some PCs.
"Trusted Computing" is, and always was, about making sure that the user doesn't actually own his device. This is the real, tangible attack vector - and the target of this attack is user freedom and choice.
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 certs from your device, HTTPS sites will stop working. However, nothing is stopping you from adding your own keys to the system and signing your own software with it.
> happens with every other smartphone, gaming console, car, and even some PCs
How often are you trying to install custom drivers on a smartphone, console or car? Why would you have secure boot issues on those?
> the target of this attack is user freedom and choice.
Which is exactly why users have the freedom and choice to just disable Secure Boot?
The reason why Apple or Nintendo go out of their way to make this impossible isn't user security. It's the "security" of their 30% App Store cut.
Out in the wild, Secure Boot exists to "secure" vendor revenue streams - and PCs are the only devices where it's even possible for the user to disable it. Most of the time.
What's happening in smartphone space is enough of a reason to treat Secure Boot on PC like an ongoing attack. The only reason why there are still legitimate ways to disable or adjust it is that most PC manufacturers don't have their own app store.
Secure Boot being "a choice" on PC is an exception, not the norm. On just about every other device, the vendor is going to take a boot, shove it up your ass, and say "it's there to make your ass more secure" if you complain.
> most PC manufacturers don't have their own app store.
I feel like you misunderstand what Secure Boot does. It has absolutely nothing to do with userspace apps or app sideloading. It's true that you can't easily sideload apps on Apple devices - but that has absolutely nothing to do with Secure Boot, neither do userspace apps have anything to do with it on any other device.
There's some x86 hardware in the wild where the option to disable Secure Boot does not work. Which is part of the reason why Shim exists in the first place - it allows you to boot unsigned code with the machine owner's consent, even with Secure Boot enabled.
Weirdly I had to leave secure boot option turned off too after a while, because more and more games started to have issues with the nVidia GPU. There was a RPG I forgot the name, isometricish that would outright crash if secure boot was turned on.
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"
Not saying all of the web should switch to that while keeping everything else the same, but in some contexts it is just nice to use something simpler, as long as the risks are known to users.
The only reason there isn't a thriving community of third party OS's on most smartphones is because secure boot prevents it. And no, users do not have the freedom and choice to disable it (except on a very few models where the manufacturer has graciously allowed users to use their own devices how they want).
I might be misremembering it, but initial plans for Secure Boot were less open. It was only the stink raised that resulted in it being an option.
<< How often are you trying to install custom drivers on a smartphone, console or car? Why would you have secure boot issues on those?
Does it matter? Is it mine? If yes, then it should my concern. But that is the entire problem with trusted computing and recent trends in general. Corps become operators, users are downgraded to consumers.
That, and fear of antitrust enforcement. The only reason we're still allowed to disable secure boot, or enroll our own keys, is that alternative PC operating systems already existed and were popular enough, that attempting to restrict PCs to only run Microsoft-approved operating systems would raise serious antitrust concerns.
But we're still at a serious risk. Microsoft still has enough influence over PC manufacturers to dictate their hardware requirements, and it would only take them being less afraid of antitrust to require them to no longer allow an override. They are already making things harder with "Secured-core PCs" (https://download.lenovo.com/pccbbs/mobiles_pdf/Enable_Secure...).
That’s what trusted boot is, as predicted in 1997. It will come eventually.
Yes, the way trust is delegated in web PKI is absolutely insane as well. It should have been something more lilke DANE from the start.
Can someone give a _rational_ reason about why Google, Microsoft, Let's encrypt, Go lDaddy, Cloudfare etc. shall be "trusted" as opposed to "Achmed used cars and certificates" ?
You can? Delete the default (ie Windows certs) and import your own.
On ARM for example the hardware, including some hardware shipping with ARM version of Windows, does not need to provide the option to add custom certs and remove existing ones, so AFAIK in most cases it is not possible.
But yeah, many ARM boards don't use open UEFI firmware
Which basically are exactly what "infosec fucktards" as you named them warned about.
fine with me. I read GP as rejecting the whole idea.
to point at another elephant in the room: at some point I came to realize that the ME is a x468 running some BSD. that little bitch has full access to your machine.
if trust and security is the objective, we're in for a hard ride to find trustworthy hardware.
Boot from read-only media you control, or set up network boot from a source you trust - you have to trust the firmware anyway. Secure Boot itself is quite pointless.
If it's FLOSS wirh reproducible builds, your trust can be minimized, since the community verification is going on constantly. Also, your suggestion is quite inconvenient and cumbersome to use and set up.
and secure boot is still the antichrist, but we have to live with them.
A public signing institution (or at least, a not-for-profit one) would be a great idea, but it wouldn't solve the core issue that we're worried about.
I don’t care if it’s required for every installation of if it’s once per hardware. I want to install software without asking a third party for permission. I want this to be doable entirely offline.
Plus, keeping Microsoft’s CA installed greatest reduces any security which I’d get from SecureBoot.
Can't you just remove all CAs from the UEFI and import only your own anyways with most mainboard vendors?
I mean, your statement is self contradictory. Linux users demanded no signing etc. So, had the industry listened to Linux users, there would be no signing. We do not live in that universe.
There are some vendors that don't have secureboot. They are e.g. System76. You can enable your own SecureBoot if you want[1], though some things may not work, like checking GPU firmware signatures, because they are signed by Microsoft only (there are other issues, depending on how deeply Microsoft is assumed in your system, see e.g "On some devices, removing either of these keys could disable all video output.")
Microsoft uses separate CAs (read: separate root certificates) to sign Windows vs Linux bootloaders.
Both CAs have to be trusted. They could also, in theory, be revoked separately.
There is no reason the "third party" CA couldn't be run by Red Hat. It's done by MS out of convenience.
Check its various options
The 'Validity' field in the output will tell you the expiration date.
mokutil --kek | egrep '(Not |Subject:|^[^ ])'
What security benefit did adding an expiry date to the certificate provide? "Oh no! Someone has gotten our secret key and is certifying new shims! ... Not to worry, the certificate will expire in 14 years. Everything is fine!"
Does anyone know the rationale for such expiry?
Secure boot off Disk encryption off Tpm off mitigations=off in linux kernel cmdline
No I don't because I installed my own keys, and so should you, and can we please stop assuming that Secure Boot means Microsoft keys?
I'm kinda concerned here: as long as there's no mandatory security upgrade requiring a reboot, I'm the kind of person to reach six months of uptime with my desktop (yup, Linux is that stable, a far cry from Windows).
So I'm concerned about not being about to boot in x months and forgetting why (ah, yes, Microsoft having a key expiring).
Am I correct in my understanding that this only affects my installation media and not my already installed systems?
Lastest Debian stable FWIW.
Oh well, I take it it's going to be mokutil and whatnots when I get back home.
If you don't do secure boot, you need to secure your boot chain in other ways, to prevent attacker from modifying your software to log entered passphrase.
Secure boot allows to build a verifiable chain of software (UEFI -> Bootloader -> Kernel -> Initrd) which will protect against any modification, so you can be sure that your key presses are not being logged by the malicious software. That said, commonly used Linux distros have some problems protecting initrd, but that's issue of those distros.
Another link is TPM. I set up my system in a way to keep encryption key in TPM and release it only when secure boot is enabled. This allows to decrypt root automatically, without entering passphrase and my configuration only allows to boot UKI kernel signed with my key. It trades security with convenience, of course (because now attacker, who stolen my computer, only has to break through gdm or perform other ways of attacks like extracting RAM sticks), but for me it's acceptable.
Personally, I do both secure boot and encryption.
Or is this just some technical detail that in practice is under the same tools and settings?
If you want, you can pick a different set of registers to use. The Arch wiki has a bunch of them: https://wiki.archlinux.org/title/Trusted_Platform_Module#Acc...
Calling systemd-cryptenroll with --tpm2-pcrs would allow you to manually pick a set of options. I believe Bitlocker uses 0, 2, 7, and 11 (11 being an OS specific register rather than a spec-defined one), which is why firmware updates often make you re-enter your Bitlocker key. Some people choose to only record the secure boot state, relying on the firmware to validate its own updates and config, which means you don't need your recovery key after firmware updates as long as the secure boot state remains the same.
Not taking secure boot state into account makes the entire setup rather easy to bypass, but you could do it to make your setup harder to break while still protecting against the "thief steals my SSD but not my laptop" scenario.
Fast forward today, yall are getting fucked deep in the ass
Fuck Microsoft