FAQ: The secure boot disaster

c't has reported several times on the current security problems surrounding UEFI Secure Boot. Microsoft's multiple changes to the plan have led to many questions. Here we answer some of the most frequently asked questions - but limit ourselves to those where we assume that the answers are still correct even if Microsoft changes its plans once again.

What it's all about

Secure Boot? UEFI? Certificates? Security problems? Huh?

It's about fending off malware, or more precisely "bootkits", which are a particularly nasty malware variant. This is because they nest in the bootloader and start before the actual operating system. This protects them particularly effectively against detection. "UEFI Secure Boot" serves as a countermeasure. The prerequisite is that the PC boots via UEFI. If it uses the boot mechanisms of a classic legacy BIOS instead, there is no secure boot. This also applies if the PC has a UEFI BIOS but emulates booting via legacy BIOS using the "Compatibility Support Module" (CSM).

If Secure Boot is active, after the PC is switched on, the BIOS only transfers control to boot loaders that are signed with a certificate stored in the BIOS flash memory. In most cases, the certificate comes from Microsoft. This also applies to Linux (Microsoft also signs Linux loaders).

The problem is that there are security gaps in the boot loaders that allow malware such as "BlackLotus" to be installed. This means that Secure Boot is currently undermined: even if a boot loader is signed with a valid certificate, this no longer means that it is trustworthy. So Microsoft had to take countermeasures, and that is what we are talking about here.

The current plan

I can't get my head around all the countermeasures Microsoft is announcing in response to the secure boot vulnerabilities. Can you summarize it briefly?

I'd be happy to, but just a warning up front: this is Microsoft's current plan, but not the first. So the company's statements are not entirely reliable. Microsoft is currently planning to revoke the certificate that was previously used to sign all Secure Boot-capable Windows boot loaders. As a result, a UEFI BIOS no longer trusts a single Windows boot loader when Secure Boot is active. So firstly, you need new boot loaders. Secondly, they must be signed with a new certificate, and thirdly, this must be stored in the BIOS flash memory.

Once again, only the Windows boot loaders published by Microsoft itself are affected by this plan. Microsoft has not yet said what will happen to all others.

Problems pre-programmed

What you write sounds as if Microsoft's plans could well give cause for panic. Do I understand that correctly?

Apart from the fact that panic does not solve IT problems: Microsoft wants to deliver both the new boot loader and the new certificate automatically via Windows updates. Microsoft already admits in its knowledge base article KB5025885 that there will be problems with this (see ct.de/ys9k). In addition, Windows' own update function has repeatedly proved to be a source of problems rather than solutions in recent years. It was only in January that an update went wrong on so many computers that Microsoft had to put up with the question of whether updates are still tested in Redmond at all.

I don't have Secure Boot

Secure Boot is not active on my PC, so I don't need new boot loaders or new certificates, do I?

In itself, yes. Nevertheless, Microsoft will install the new features via an update. Background: Microsoft's certificates used for Secure Boot have an additional problem: they expire in 2026. Microsoft will then no longer be able to use them to sign new boot loaders. So the company is simply installing new certificates everywhere in the BIOS and installing new boot loaders. Ideally, however, you will not notice this on your PC.

Check certificates in the BIOS

How can I find out which certificates are stored in my computer's BIOS under Windows?

There is no on-board tool that can do this easily, but there are PowerShell cmdlets for post-installation. They are called "UEFIv2" and come from (now ex-)Microsoft employee Michael Niehaus. He has published them online in the PowerShell Gallery. To reinstall, open a PowerShell running with administrator rights and type in the following three commands:

Install-Module -Name UEFIv2
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
Import-Module UEFIv2

The second command triggers a warning, which you must confirm. The command is required in the standard configuration (it allows the cmdlet to be executed), but if you have already entered it before, you can save yourself the trouble of repeating it.

Another command called Get-UEFISecureBootCerts then reads the certificates from the BIOS. Exactly which ones depends on the abbreviation you append to the command. Of interest here are: DB, DBX and KEK. The certificates stored in the DB are those that serve as proof of the trustworthiness of a bootloader signed with them. In principle, checksums can also be included here, but this is rather unusual. The DBX is the corresponding revocation list: What is contained here does not deserve trust. The DBX can also contain the checksums of individual loaders as well as certificates. The KEK (Key Exchange Key) authorizes changes to DB and DBX (more precisely: software signed with it may change).

We recommend appending a | fl to each command to make the output clearer as a list (fl stands for format-list). As the output of the contents of the DBX in particular can be confusing (many checksums are already stored here by default), you should at least redirect this output to a text file. A complete command for reading looks like this:

Get-UEFISecureBootCerts DB | fl >D:\Downloads\BIOS-Certs-DB.txt

Replace DB with DBX or KEK if desired. You can adapt the path and name of the text file as required.

Check bootloader

How do I find out which certificate was used to sign the bootloader of my Windows installation?

This is surprisingly complicated. It starts with the fact that the loader is located on a separate boot partition (EFI System Partition, ESP), which is not visible in Explorer and cannot be mounted via disk management. In addition, although you can see the certificate in the properties of the file, you have to click through various sub-dialogs to do so.

We therefore recommend the Sysinternals freeware SigCheck.exe from Microsoft. This allows you to determine the certificate used for signing, including the certification path and various checksums, in one go.

SigCheck is a command line program - this may seem daunting, but without a command line the check will not work anyway. Download the freeware via the direct download link. The zip archive contains three variants, two of which are for x86 PCs: SigCheck.exe is intended for 32-Windows, but also contains the SigCheck64.exe variant for 64-bit Windows, which it temporarily unpacks and uses at runtime if required. SigCheck64.exe is also included separately in the zip archive. Finally, SigCheck64a.exe is the version for 64-bit ARM Windows.

Unzip the SigCheck archive into any folder in which you have write permissions, such as D:\Downloads\SigCheck. In addition, select a drive letter that is currently free, as it will be needed temporarily, for example W:. The following commands then transfer all information about the boot loader to a text file in the SigCheck folder:

MountVol W: /s
D:\Downloads\SigCheck\SigCheck64.exe -i -h W:\EFI\Boot\Bootx64.efi > D:\Downloads\SigCheck\loaderinfo.txt
MountVol W: /d

Adjust the drive letter in the first and third command and the path of your SigCheck folder in the second. You can freely define the path and name of the text file. The name "bootx64.efi" applies to 64-bit Windows on x86 PCs, for other architectures you also adapt the name (32-bit/x86: bootx86.efi, 64-bit/Arm: bootaa64.efi). The command MountVol is only used to integrate the ESP mentioned.

The new boot loaders

Do you already know the details of the new Windows boot loaders?

Yes, during our first tests (don't copy this, who knows what else Microsoft will change!) we got new loaders installed. The version number was 10.0.26089.1001. It didn't matter whether we were experimenting with Windows 10 or 11, both got checksum-identical boot loaders. This is not surprising, as Windows 10 and 11 do not differ that much under the hood anyway. As announced, the new loader in our tests was signed with the new 2023 Windows certificate, which is valid until June 13, 2035.

BIOS changes

How is it actually possible for Microsoft to change the BIOS via a Windows update? Surely that shouldn't be possible?

Yes, and it's not new. Most old legacy BIOSes could also be overwritten (flashed) by software, i.e. replaced by a new version - and thus changed. The only difference is that they used proprietary procedures from the respective PC or BIOS manufacturer. With the UEFI BIOS, the methods for overwriting (UEFI Capsule Update) and for modifying the non-volatile configuration memory (NVRAM, actually flash) are merely standardized. They should also be protected against malicious manipulation by a cryptographic signature check.

Boot blocking via PCIe card

Just like the old legacy BIOS, a UEFI BIOS still executes so-called option ROMs from PCI Express expansion cards, which retrofit firmware for graphics cards and RAID host adapters, for example. Can this also lead to secure boot problems?

Yes, in secure boot mode, a UEFI BIOS only loads cryptographically signed option ROMs. Their signatures must therefore also be valid. If the key used for verification is revoked, the PC may no longer start or functions may be missing. The manufacturer of the respective expansion card must then supply a firmware update with a new signature or you can switch off Secure Boot.

SigCheck and Linux boot loader under Windows

In addition to Windows, Linux is also installed on my PC. When I check its bootloader with the Sysinternals tool SigCheck.exe as described by you, the following message appears: "Verified: A certificate chain was processed, but ended with a root certificate that is not trusted by the trust provider." What's going on?

This is due to a nasty trick by Microsoft. The company uses two different certificates to sign bootloaders: one exclusively for its own Windows bootloaders and one for everything else, including Linux bootloaders. This is usually not a problem in everyday use, because most PCs have both in the BIOS.

But, and this is the nasty thing: just because both certificates are usually in the BIOS, this does not mean that they are also included in Windows. The latter only includes the one for Windows bootloaders. Therefore, checking Linux bootloaders with SigCheck under Windows will fail with the error you are experiencing. Instead, check under Linux (example Ubuntu: sudo sbverify /boot/efi/EFI/ubuntu/shimx64.efi --list). There is only a problem if an invalid signature is also reported there. Otherwise, however, it is OK, even if Windows wants to suggest otherwise.

Build numbers

SigCheck also reads the build number of a Windows bootloader. But isn't there an easier way to do this, for example with Windows' own Winver.exe program, which directly states the version number and the build number on startup?

No. This information applies to Windows, but not to the bootloader. As a reminder: Microsoft's version numbers have the following structure (example Windows 10): 10.0.19045.4170. At the very front is the product family "10.0", which stands for both Windows 10 and 11. This is followed by the build number (here "19045") and then the patch level (here "4170"). The catch: Although the bootloader can have the same build number as Windows itself, this is by no means the rule.

Example: The current Windows 10 version 22H2 has 19045, but the corresponding bootloader still has 19041. Windows also used to have this build number, namely as version 2004 (officially released in April 2020). Since then, three more Windows versions have been released (20H2/19042, 21H1/19043 and 21H2/19044), all of which have the same bootloader from version 2004. Although it has received updates since then (recognizable by the patch level), it still has the old build number, which differs from Windows. Once Microsoft releases the new bootloaders (see above), the build numbers will also differ.

Incidentally, the Windows program "System information" (msinfo32.exe) also shows build numbers and patch levels, but these are not those of the bootloader either. Instead, the "Version" line shows the Windows version and the "Hardware Abstraction Layer" (HAL).

On, Off, Not supported

They recommended using msinfo32.exe to check what is in the "Secure boot state" line: "On" means Secure Boot is active, "Off" means the opposite. But in my case, it says neither, but "Not supported". What does this mean?

This means that your PC uses legacy BIOS mechanisms for booting, i.e. it does not boot via UEFI. Presumably, the CSM (Compatibility Support Module) is activated on your PC in the BIOS setup. You can also check this in msinfo32: If the "BIOS mode" line does not say "UEFI" but "Previous version", the CSM is active. Secure Boot cannot work in this mode because Legacy BIOS did not yet know about it. "Not supported" therefore stands for: Secure Boot is off, and nothing can be done about this without deactivating the CSM and the complex conversion of the Windows boot mode.

Windows on MBR disk

My Windows installation is on a data carrier that is set up with the MBR partitioning scheme. Since booting via UEFI requires GPT instead, Secure Boot cannot be switched on on my computer, can it?

If the MBR disk is the only one in the PC: yes. However, if there are several disks, UEFI and thus Secure Boot could still be active. Background: When Windows boots via UEFI, the bootloader is not located on C:, but on the EFI System Partition (ESP). And only the ESP must be located on a data carrier that is set up with GPT. Windows itself, i.e. drive C:, may be located on another data carrier, regardless of whether it is set up with MBR or GPT.

Therefore, do not rely on the partition scheme, but rather use msinfo32.exe to check what is in the "Safe boot state" line (see above).

Incidentally, the GPT constraint has no technical background, but is an arbitrary decision by Microsoft, which also only applies to internal hard disks. Windows PE, for example, can boot from a stick in UEFI mode even if the stick is MBR-partitioned.

"Released" before July 11, 2023

Microsoft's knowledge base article KB5025885 states (at least when I read it) that all bootloaders released before July 11, 2023 are insecure. They also pointed out that the information is vague because the release date of a file cannot be seen. Could this mean the date on which the file was signed?

We have Windows bootloaders in our collection that contradict this: One with the build number 22621.1702 was already signed on May 1, 2023, one with 22621.1992 on July 6, 2023. Nevertheless, both were allowed to boot unchanged in our tests of the original plan, so Windows classified them as safe. However, if Microsoft sticks with the new plan, the signing date will no longer play a role anyway because all bootloaders released to date will be blocked, regardless of whether they are unsafe or not.

Why 32 bit?

Until now, I thought that only 64-bit Windows could boot via UEFI, but in your articles you point out that 32-bit bootloaders will also be blocked. So, can I install the 32-bit counterpart alongside the 64-bit Windows on my UEFI-booting PC?

No, it's about something else. Just as operating systems can exist as 32-bit and 64-bit variants, these variants also exist for main board firmware. And if the PC is to boot via UEFI, the operating system and UEFI BIOS must have the same architecture. This means that 64-bit Windows only boots via UEFI on computers with a 64-bit BIOS, while 32-bit Windows requires a 32-bit BIOS. However, computers with a 32-bit UEFI BIOS are very rare and are practically no longer available. Nevertheless, there are security vulnerabilities in boot loaders published for this purpose, which is why they now also appear in the blacklists. (axv)