I am not sure the default key is actually accessible on the software side .
It is installed into the bios secure boot keys area and that is what is shown when using mokutil.
The key is obviously loaded when the OS is originally installed but I am unaware of how that is done.
Let’s make this a little more complicated… I have a dual-boot Beelink mini PC that has an AMI Aptio type BIOS along with Microsoft keys that were installed at the factory along with a PK named “DO NOT TRUST - AMI Test PK” (LOL). As I understand it, the PK currently is not used for anything except to sign the Window KEK (*). I can’t get verification from Beelink whether the PK is unique for each device or whether all Beelink devices of a production run are signed with the same PK. As I understand it, when you get a “real” PC from a “premium” US based retailer like Dell or HP each device will have a unique PK.) I can see PK, KEK, DB, and DBX keys when I put secure boot in custom mode, but the BIOS has no references to a MOK key section. Is my AMI BIOS just not capable of seeing the MOK key in BIOS? Or is the MOK key somehow embedded in the shim-x64.efi file?
vgaetera, byy “abandoned” do you mean the efitools package or the shim packages? (unsigned shim went away in F43.) If EFI tools is being retired, does this mean “sbsigntools” will replace it? Certainly, there will be some kind of tool remaining for users who want to install their own keys in the PK, KEK, etc.? Obviously this would be only for those who do not dual-boot Windows.
I enrolled my Windows 11 with Microsoft and it boots and I get updates in secure boot with no complaints, so I am confident the Windows keys are legitimate. I also cannot boot Memtest86+ without disabling secure boot, which is what I expect, so secure boot is giving me some protection against boot from (legit or bogus) 3rd party media.
As for Fedora, right now I am booting from the signed shimx64.efi and the kernel is “locked down”. As I understand it, the kernel is not signed my the MOK, but it “inherits its legitimacy” (for lack of a better term) from the signed shim. Will this process change in the future?
I would experiment more with secure boot but for now I need the dual boot capability.
(*) Note: The Windows KEK I have expires in 2026. Since the KEK is signed by my semi-bogus PK, Beelink is going to have a lots of users complaining about Windows not booting when that KEK expires! Maybe they will address it by emailing everyone a new PK and KEK in a zip file like they do when you request a BIOS update (rolls eyes!) Or maybe they have been installing the same “DO NOT TRUST - AMI Test PK” on millions of machines. (rolls sys again!)
I’m not sure I fully understand “The MOK keys can only be seen by the shim. Without the shim, the MOK does not exist.”
If not, how does mokutil “find” the key? Is it part of shim-x64.efi? It just “knows”?
What I actually expect to see is that the shim-x64.efi file has a signature that mas been signed not by a MOK, but by some cert that has its public key in my BIOS. Sure enough,
# pesign -l -i shimx64.efi
---------------------------------------------
certificate address is 0x7f48ab5fd6d0
Content was not encrypted.
Content is detached; signature cannot be verified.
The signer's common name is Microsoft Windows UEFI Driver Publisher
No signer email address.
No signing time included.
There were certs or crls included.
But this doesn’t match the CN’s of the Microsoft KEK keys in my BIOS:
# efi-readvar -v KEK
Variable KEK, length 1560
KEK: List 0, type X509
Signature 0, size 1532, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
Subject:
C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
Issuer:
C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
I have a Microsoft KEK and I’ve exported it from the BIOS but I’m not sure what’s in it, I can’t figure out the magic openssl command to get a hash from it.
I’m getting warmer, I think, but I still don’t see whether shim-x64.efi was signed by the same cert as a key in my BIOS.
These files are unknown to the UEFI firmware, but created and maintained by moktuil together with the UEFI program /boot/efi/EFI/fedora/mmx64.efi. mmx64.efi is the software which puts up the blue screen dialog when you enroll a new MOK key. There are mechanism in place which prevents directly installing new MOK keys from the Linux environment. Thus you, or someone else, can’t do that remotely.
Sorry, I accidentally posted a draft reply, and your reply got posted while I was writing a more detailed response…
How do I read the data in /sys/firmware/efi/efivars/MokList* files? They don’t seem to be x509 certs. I should be able to find the cert (or the hash of it) that signed shimx-64.efi in there, right?
At this level of details, you would need to read the source code. The X509 certs doesn’t start at byte 0, but there are some length and type prefix information.
Enabling secure boot is fairly pointless anyway, since the Beelink BIOSes can be factory reset from a front panel pinhole switch, which clears the BIOS password, thus enabling anyone with physical access to disable secure boot and do whatever they want.
I retired from devops about 4 years ago, but enabling secure boot on my own box had me thinking how I would approach boot security in a private cloud. There’s no real documentation out there, although the US NSA has a good document “UEFI Secure Boot Customization” that describes how you might do it in a non-virtualized environment.
It is a well known adage that having physical access to the hardware means the user owns it and can do anything with it no matter what has been done with software to make it secure.
The Beelink bios (and hardware) seems to have the same security faults as an x86 motherboard which has a jumper to allow reset of the bios to factory default. If a user can access the hardware they can bypass all security features.
You seem to be focusing on a known weakness of almost all hardware and blaming it on the software (secure boot). Laptops for the most part seem to have eliminated that weakness in the hardware but still can be accessed with the proper tools.
The only known secure features that work everywhere are to encrypt the drive data and that is still only as secure as the user makes the encryption pass codes.
I’m not blaming anything on the software, which works as intended. You’re correct, and I agree “If a user can access the hardware they can bypass all security features.” The Beelinks are set up like millions of other PCs, with a user-resettable BIOS.
I’ve also read various random postings saying “secure boot is broken in [Windows,Linux] blah blah blah” and it’s not. It works out of the box for both OSes on the Beelinks, which come with a fully signed WIndows 11 installed. If you have your own Windows 11 distro with your own key, you have more options, although I suspect it would be much easier to install Windows 11 first, then Linux.
I am just experimenting. I have two objectives:
I’d like to figure out how to self-sign memtest86+ so that I can boot it in secure boot. Right now, I don’t think it’s possible since I would need access to the private key of one of the known certs in my BIOS. I did submit a feature request for the Fedora Memtest86+ packagers to sign their EFI in the same way as shim. I suspect they will do this sooner or later. (Of course, right now one can just disable secure boot temporarily if one wants to boot memtest86+. My only use case for memtest86+ is to stress-test my PC.)
I’m thought-experimenting on how secure boot would run a secure boot enabled cloud. Vmware and AWS have their own methods, but what if one wanted to reinvent the wheel?
You can create your own key, for example by using the kmodgenca program that comes with the akmods package. Then enroll the key as per instruction in /usr/share/doc/akmods/README.secureboot.
Then you can use sbsign to sign memtest86+x64.efi.